EU AI Act
A structured gateway to Regulation (EU) 2024/1689 — the world’s first comprehensive legal framework for artificial intelligence. The Act entered into force on 1 August 2024, with obligations applying progressively through 2027. Detailed AI governance definitions are available in the dedicated glossary.
Obligations apply in stages
The EU AI Act entered into force on 1 August 2024, with obligations applying progressively depending on the type of requirement and AI system.
Find out more Fines & penaltiesUp to €35M or 7% of turnover
Breach of prohibited practices carries the highest penalty tier. Three tiers of administrative fines apply, indexed to severity.
Find out more Risk-based architectureFour categories of risk
Unacceptable, high, limited, and minimal risk. Classification is use-based and determines the obligations that apply.
Find out moreWhat you’ll find here.
A guided view of the EU AI Act — from risk classification and obligations to the full legal text. Select a topic to jump directly to that section.
Five essentials for understanding the Regulation.
Drawn from the official text and framed for quick reference. Each point anchors to a detailed section below.
First horizontal AI law worldwide.
The first comprehensive legal framework dedicated to artificial intelligence, applicable across all sectors and Member States.
Risk-based architecture.
Four tiers determine obligations. Classification is use- and context-based; the same system can sit in different categories.
Governance for general-purpose AI.
Documentation, transparency and copyright duties on GPAI providers, with additional obligations for systemic-risk models.
Phased application 2024 – 2027.
Prohibitions from Feb 2025, GPAI obligations from Aug 2025, full application Aug 2026, Annex I products Aug 2027.
Penalties up to 7% of turnover.
Breach of Article 5 prohibitions carries fines of up to €35 million or 7% of worldwide annual turnover, whichever is higher.
Two audiences. One unified page.
The structure serves legal and executive readers in parallel. Use the path that fits how you need to work today.
Work with the official text.
Every expandable panel contains wording drawn directly from Regulation (EU) 2024/1689, with article-level citations.
Start with the risk classification and prohibited practices, then open the Legal framework section for key provisions and penalties.
Start with summaries and implications.
Each section leads with a concise summary. Detailed legal text is one click away when your team needs to verify a specific obligation.
Focus on the risk tiers, phased timeline, and fines & penalties — the structural shape of what the Act requires.
Four categories. Different obligations.
The Regulation distinguishes AI systems by the risk they pose. Classification is use- and context-based. Select any tier to reveal the official wording.
Prohibited AI practices.
Banned in the EU. AI practices considered a clear threat to safety, livelihoods, or fundamental rights. Exhaustively listed in Article 5.
The following AI practices shall be prohibited. See the full list of eight prohibited practices in the Prohibited AI practices section below.
High-risk AI systems.
Permitted, subject to strict obligations. Systems with significant potential to affect health, safety or fundamental rights. Classification arises from product-safety integration or Annex III use.
Irrespective of whether an AI system is placed on the market or put into service independently of the products referred to in points (a) and (b), that AI system shall be considered to be high-risk where both of the following conditions are fulfilled:
(a) the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I;
(b) the product whose safety component pursuant to point (a) is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment, with a view to the placing on the market or the putting into service of that product pursuant to the Union harmonisation legislation listed in Annex I.
Transparency obligations.
Permitted, subject to transparency. AI systems that interact with natural persons, perform biometric categorisation or emotion recognition, or generate synthetic content — including deepfakes.
Providers shall ensure that AI systems intended to interact directly with natural persons are designed and developed in such a way that the natural persons concerned are informed that they are interacting with an AI system, unless this is obvious from the point of view of a natural person who is reasonably well-informed, observant and circumspect, taking into account the circumstances and the context of use.
Voluntary application.
No specific obligations. All other AI systems. The Regulation encourages voluntary application of the requirements for high-risk systems, and the adoption of codes of conduct.
The AI Office and the Member States shall encourage and facilitate the drawing up of codes of conduct, including related governance mechanisms, intended to foster the voluntary application to AI systems, other than high-risk AI systems, of some or all of the requirements set out in Chapter III, Section 2 taking into account the available technical solutions and industry best practices allowing for the application of such requirements.
Eight categories of prohibited AI.
Article 5(1) prohibits specific AI practices altogether. The repeated legal stem is shown once below, followed by the eight categories as a structured legal map.
“The placing on the market, the putting into service or the use of an AI system that …”
Subliminal, manipulative or deceptive techniques.
… deploys subliminal techniques beyond a person’s consciousness or purposefully manipulative or deceptive techniques, with the objective, or the effect of materially distorting the behaviour of a person or a group of persons by appreciably impairing their ability to make an informed decision, thereby causing them to take a decision that they would not have otherwise taken in a manner that causes or is reasonably likely to cause that person, another person or group of persons significant harm.
Exploiting age, disability or social/economic vulnerability.
… exploits any of the vulnerabilities of a natural person or a specific group of persons due to their age, disability or a specific social or economic situation, with the objective, or the effect, of materially distorting the behaviour of that person or a person belonging to that group in a manner that causes or is reasonably likely to cause that person or another person significant harm.
Evaluation or classification based on social behaviour.
… for the evaluation or classification of natural persons or groups of persons over a certain period of time based on their social behaviour or known, inferred or predicted personal or personality characteristics, with the social score leading to either or both: detrimental treatment in contexts unrelated to those in which the data was originally generated, or detrimental treatment that is unjustified or disproportionate to the behaviour or its gravity.
Risk assessments of criminal offence based solely on profiling.
… for making risk assessments of natural persons in order to assess or predict the risk of a natural person committing a criminal offence, based solely on the profiling of a natural person or on assessing their personality traits and characteristics. This prohibition does not apply to AI systems used to support human assessment already based on objective and verifiable facts directly linked to a criminal activity.
Untargeted scraping to build or expand databases.
… creates or expands facial recognition databases through the untargeted scraping of facial images from the internet or CCTV footage.
Inferring emotions at work and in education.
… to infer emotions of a natural person in the areas of workplace and education institutions, except where the use of the AI system is intended to be put in place or into the market for medical or safety reasons.
Inferring race, politics, religion, sexual orientation.
… uses biometric categorisation systems that categorise individually natural persons based on their biometric data to deduce or infer their race, political opinions, trade union membership, religious or philosophical beliefs, sex life or sexual orientation. This does not cover labelling or filtering of lawfully acquired biometric datasets in the area of law enforcement.
Real-time remote biometric ID in public spaces.
… uses ‘real-time’ remote biometric identification systems in publicly accessible spaces for law enforcement, unless and in so far as such use is strictly necessary for: the targeted search for victims of abduction, trafficking or sexual exploitation and missing persons; the prevention of a specific, substantial and imminent threat or terrorist attack; or the localisation of suspects of specified serious criminal offences.
Two routes into high-risk classification.
A system is high-risk when it is either a product-safety component under Annex I, or when it falls within one of the Annex III use-case domains.
Product-safety systems.
AI embedded in products already covered by EU harmonisation legislation — including medical devices, machinery, toys, aviation, lifts, cableways and pressure equipment.
Classification arises when the AI is a safety component and the product requires third-party conformity assessment.
Irrespective of whether an AI system is placed on the market or put into service independently of the products referred to in points (a) and (b), that AI system shall be considered to be high-risk where both of the following conditions are fulfilled:
(a) the AI system is intended to be used as a safety component of a product, or the AI system is itself a product, covered by the Union harmonisation legislation listed in Annex I;
(b) the product whose safety component pursuant to point (a) is the AI system, or the AI system itself as a product, is required to undergo a third-party conformity assessment, with a view to the placing on the market or the putting into service of that product pursuant to the Union harmonisation legislation listed in Annex I.
Use-case systems.
Stand-alone AI systems deployed in high-impact domains — biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice.
The Commission may update Annex III to add or modify use-cases over time.
High-risk AI systems pursuant to Article 6(2) are the AI systems listed in any of the following areas:
1. Biometrics, in so far as their use is permitted under relevant Union or national law.
2. Critical infrastructure — as safety components in the management and operation of critical digital infrastructure, road traffic, or the supply of water, gas, heating or electricity.
3. Education and vocational training — admissions, evaluation of learning outcomes, assessment of appropriate level of education, monitoring during tests.
4. Employment, workers’ management and access to self-employment — recruitment, promotion, termination, task allocation, performance monitoring.
5. Access to and enjoyment of essential private and public services — public assistance benefits, creditworthiness, insurance pricing, emergency call triage.
6. Law enforcement — victim risk assessment, polygraphs, reliability of evidence, profiling in the course of investigations.
7. Migration, asylum and border control — polygraph-like tools, risk assessments, examination of applications.
8. Administration of justice and democratic processes — assistance to judicial authorities, influence on election outcomes.
Obligations apply progressively.
The Regulation entered into force on 1 August 2024. Different parts of the Act become applicable on different dates, as set out in Article 113.
Entry into force
The Regulation enters into force on the twentieth day following its publication in the Official Journal of the European Union. The compliance clock starts.
Prohibitions apply
Chapters I and II shall apply from 2 February 2025. The prohibitions of AI practices under Article 5 take effect across the Union.
Governance and GPAI obligations
Chapter III Section 4, Chapter V, Chapter VII and Chapter XII and Article 78 shall apply from 2 August 2025, with the exception of Article 101. This covers notifying authorities, general-purpose AI models, governance, penalties, and confidentiality.
Full application
The Regulation shall apply from 2 August 2026. The remaining provisions become applicable, including obligations for high-risk AI systems listed in Annex III.
Annex I high-risk systems
Article 6(1) and the corresponding obligations in this Regulation shall apply from 2 August 2027. Obligations for AI systems embedded in products regulated under Annex I harmonisation legislation become applicable.
Three tiers of administrative fines.
Non-compliance carries administrative fines indexed to the severity of the breach. Figures below are drawn verbatim from Article 99.
€35,000,000administrative fine, up to
orNon-compliance with the prohibition of the AI practices referred to in Article 5 — whichever is higher.
Article 99(3)€15,000,000administrative fine, up to
orNon-compliance with obligations of providers, authorised representatives, importers, distributors, deployers, notified bodies, or transparency obligations under Article 50 — whichever is higher.
Article 99(4)€7,500,000administrative fine, up to
orSupply of incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request — whichever is higher.
Article 99(5)Key provisions in structured reference.
A working reference to the Regulation’s purpose, general-purpose AI regime, and penalty structure.
Purpose of the Regulation.
Improving the functioning of the internal market while ensuring a high level of protection of health, safety, and fundamental rights.
The purpose of this Regulation is to improve the functioning of the internal market and promote the uptake of human-centric and trustworthy artificial intelligence (AI), while ensuring a high level of protection of health, safety, fundamental rights enshrined in the Charter, including democracy, the rule of law and environmental protection, against the harmful effects of AI systems in the Union and supporting innovation.
Obligations for providers of GPAI.
Dedicated rules covering technical documentation, transparency to downstream providers, and copyright policy.
Providers of general-purpose AI models shall:
(a) draw up and keep up-to-date the technical documentation of the model, including its training and testing process and the results of its evaluation, which shall contain, at a minimum, the information set out in Annex XI for the purpose of providing it, upon request, to the AI Office and the national competent authorities;
(b) draw up, keep up-to-date and make available information and documentation to providers of AI systems who intend to integrate the general-purpose AI model into their AI systems;
(c) put in place a policy to comply with Union law on copyright and related rights, and in particular to identify and comply with, including through state-of-the-art technologies, a reservation of rights expressed pursuant to Article 4(3) of Directive (EU) 2019/790;
(d) draw up and make publicly available a sufficiently detailed summary about the content used for training of the general-purpose AI model, according to a template provided by the AI Office.
The obligations in (a) and (b) do not apply to open-source GPAI models whose parameters, weights, architecture and usage information are publicly available — with the exception of models classified as posing systemic risk.
Administrative fines.
Three tiers of maximum administrative fines tied to the severity of the obligation breached.
Non-compliance with the prohibition of the AI practices referred to in Article 5 shall be subject to administrative fines of up to EUR 35 000 000 or, if the offender is an undertaking, up to 7% of its total worldwide annual turnover for the preceding financial year, whichever is higher.
Non-compliance with any of the following provisions related to operators or notified bodies, other than those laid down in Articles 5, shall be subject to administrative fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 3% of its total worldwide annual turnover for the preceding financial year, whichever is higher.
The supply of incorrect, incomplete or misleading information to notified bodies or national competent authorities in reply to a request shall be subject to administrative fines of up to EUR 7 500 000 or, if the offender is an undertaking, up to 1% of its total worldwide annual turnover for the preceding financial year, whichever is higher.
Phased application schedule.
The dates at which different chapters of the Regulation become applicable.
This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union.
It shall apply from 2 August 2026. However:
(a) Chapters I and II shall apply from 2 February 2025;
(b) Chapter III Section 4, Chapter V, Chapter VII and Chapter XII and Article 78 shall apply from 2 August 2025, with the exception of Article 101;
(c) Article 6(1) and the corresponding obligations in this Regulation shall apply from 2 August 2027.
Definitions on a dedicated page.
The full glossary of AI governance concepts and EU AI Act terminology lives as a standalone, searchable reference.
AI Governance Glossary
Explore key AI governance concepts, definitions, and legal references under the EU AI Act.
Ten questions on the EU AI Act in practice.
Each question is structured into a short executive answer, the operative legal basis under Regulation (EU) 2024/1689, and concrete steps to operationalise it. Expand any item to see the full breakdown.
How do you determine the “intended purpose” of an AI system in practice?
Intended purpose is the legally binding context defined by the provider — and it must be coherent across documentation, instructions, and marketing. Get this wrong and your risk classification, customer contracts, and oversight design all unravel.
What the EU AI Act says
- Intended purpose = the use specified by the provider in instructions, marketing materials, and technical documentation. Art. 3(12)
- Must include context and conditions of use, not just function. Art. 3(12) Annex IV
- The system’s actual objectives may diverge from the documented intended purpose in a specific context.
- Tied directly to high-risk classification. Art. 6 Annex III
- Frames the boundary between intended use and reasonably foreseeable misuse. Art. 3(13) Art. 9
How to operationalise it
- Document each deployment by domain, output type, user population, environment, and human-override pattern.
- Use a single, coherent description verbatim across technical documentation, instructions for use, and marketing.
- State both what the system is for and explicitly what it is not for (e.g., excluded contexts).
- Test the documented purpose against Annex III; if any use matches, treat as high-risk unless a carve-out applies.
- Bind customers contractually to respect the documented intended purpose.
- Trigger re-classification if a customer materially changes the use — they may become providers.
When does a modification become a “substantial modification”?
A modification is “substantial” when it either affects high-risk compliance or changes the intended purpose. Either trigger demands a new conformity assessment and may shift provider responsibility downstream.
What the EU AI Act says
- Substantial modification = post-market change not foreseen in the initial conformity assessment that affects compliance or alters intended purpose. Art. 3(23)
- Changes to OS, software architecture, or intended purpose qualify. R.128
- Pre-determined learning changes covered in the initial conformity assessment are not substantial.
- Triggers a new conformity assessment for high-risk systems. Art. 43
- The party making the modification may become a provider with full obligations. Art. 25
How to operationalise it
- Treat as substantial when: new functions move the system into Annex III, decision logic or data sources change in ways affecting safety or rights, architecture changes affect compliance, or intended purpose changes.
- Treat as not substantial only if pre-planned and explicitly assessed (continuous learning bounds documented in the initial conformity assessment).
- Run every change through a formal change-control procedure with an impact assessment template.
- Required questions: Is the change foreseen? Does it alter intended purpose? Could it affect compliance?
- Route triggered changes to regulatory review and re-conformity assessment for high-risk.
- Document every decision and rationale — including non-substantial classifications.
How do you assess “reasonably foreseeable misuse”?
Predictable misuse must be addressed through technical design first, not user training. Identify it before deployment, mitigate it in the system itself, and feed real-world incidents back into your risk register.
What the EU AI Act says
- Reasonably foreseeable misuse = use not in accordance with intended purpose but predictable from human behaviour or system interaction. Art. 3(13)
- Risk management must cover known and reasonably foreseeable risks, including misuse and environmental interactions. Art. 9
- Predictable misuses must be included in the instructions for use. Art. 13
- Provider duty of care extends to predictable human behaviour. R.65
How to operationalise it
- Map predictable behaviour for each deployment: workarounds, shortcuts, over-reliance, repurposed outputs, interactions with other systems.
- Run scenario workshops and red-teaming with engineers, domain experts, and end-users.
- Quantify each scenario by likelihood and impact on health, safety, and fundamental rights.
- Prioritise technical and design controls first: input constraints, usage limits, monitoring, alerts, default settings.
- Document key scenarios and mitigations in instructions for use so deployers can act on them.
- Feed misuse reports and incident logs into post-market monitoring to update the risk register.
Who carries which obligations across the AI value chain?
The Act assigns distinct duties along the value chain. Providers carry the heaviest compliance load; deployers carry operational duties; importers, distributors, and modifiers can be re-classified as providers if they substantially modify, rebrand, or change intended purpose.
What the EU AI Act says
- Provider duties: risk management, data governance, documentation, transparency, oversight, robustness, QMS, technical documentation, logs. Art. 16–21
- Deployer duties: use per instructions, technical/organisational measures, human oversight, monitoring, incident reporting, FRIA where required. Art. 26 Art. 27
- Importers and distributors: verify conformity, hold documentation, refuse non-conforming systems, trigger corrective actions. Art. 23 Art. 24
- Any party who rebrands, substantially modifies, or changes intended purpose becomes a provider. Art. 25
- Third-party suppliers must contractually provide information, capabilities, technical access, and assistance. Art. 25(4)
How to operationalise it
- Map who is provider, deployer, importer, or distributor for each product in each market.
- Use written agreements to allocate documentation duties, incident reporting, info-sharing, and modification responsibilities.
- Define explicitly when downstream integrators become providers (substantial modification, new intended purpose).
- Build modification clauses into vendor and customer contracts requiring notification before any change.
- Train deployer-side oversight teams on their distinct legal duties — not generic AI awareness.
- Test role allocation against complex chains: GPAI provider › integrator › reseller › end-deployer.
How do you classify a system that could fall under multiple Annex III use cases?
If any use matches an Annex III category and no narrow carve-out applies, the system is high-risk. Multiple matches don’t dilute the obligation — they aggregate it. Carve-outs require documented justification.
What the EU AI Act says
- Annex III lists high-risk domains: biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration, justice. Annex III
- Some Annex III systems may not be high-risk if cumulative carve-out conditions are met. Art. 6(3)
- Carve-out requires the system to perform only narrow procedural tasks, improve completed human work, detect patterns, or be merely preparatory.
- Profiling of natural persons remains high-risk regardless of carve-out. Art. 6(3)
- Providers claiming non-high-risk status must document the assessment and register the system. Art. 6(4) Art. 49
How to operationalise it
- Classify by intended purpose per deployment, not per system at the abstract level.
- Multiple Annex III matches mean designing risk management for the most demanding combination — not partial relief.
- Apply the Art. 6(3) carve-out only if the role is unambiguously narrow, supportive, or preparatory.
- Confirm the system performs no profiling — that disqualifies the carve-out automatically.
- Produce a short, lawyer-readable memo for every “not high-risk” decision, tied to intended purpose and technical design.
- Register systems claiming non-high-risk status as required. Art. 49
What does a compliant risk management system look like in practice?
Risk management under Article 9 is a continuous lifecycle obligation, not a one-time document. It must integrate technical controls, governance, and post-market feedback — and must demonstrate that residual risk is acceptable.
What the EU AI Act says
- Risk management is a continuous, iterative lifecycle process for high-risk AI. Art. 9
- Must identify and analyse known and reasonably foreseeable risks under intended use and misuse, including environmental interactions. Art. 9(2)
- Must estimate, evaluate, and adopt measures to reduce risk as far as technically feasible. Art. 9(3–4)
- Must integrate post-market monitoring data into ongoing evaluation. Art. 9(2)(c) Art. 72
- Residual risk must be acceptable and balanced against all requirements. Art. 9(5)
How to operationalise it
- Assign risk owners and embed AI risk management in your QMS and product lifecycle.
- Identify hazards to health, safety, and fundamental rights for each high-risk system, under intended use and foreseeable misuse.
- Maintain a risk register linked to specific technical and organisational controls, rated by likelihood and impact.
- Prioritise design-level controls (data quality, model constraints, robustness, logging, explainability, human oversight) over policy or training.
- Feed incidents, near-misses, and drift observations from post-market monitoring back into the risk register.
- Document major risk decisions and the rationale for accepting residual risk.
How do you operationalise human oversight without it becoming a tick-box exercise?
Effective oversight is structural, not procedural. It must be designed into the system, supported by trained competent staff, and measured by override patterns — not by completed checklists.
What the EU AI Act says
- High-risk systems must be designed for effective human oversight via human-machine interfaces. Art. 14(1)
- Oversight must be commensurate with risk, autonomy, and context — built into the system or implemented by the deployer. Art. 14(3)
- Must enable understanding capabilities and limitations, monitoring, avoiding automation bias, interpreting outputs, overriding decisions, and stopping the system safely. Art. 14(4)
- Deployers must assign oversight to competent, trained natural persons with appropriate authority and support. Art. 26(2)
How to operationalise it
- Design UI elements that show model confidence, limitations, and key input factors.
- Make override, disregard, and stop options normal user paths — not exceptional escalations.
- Define oversight roles in procedures (reviewer, approver) with real authority to block or change decisions.
- Train assigned humans specifically on system capabilities, failure modes, and automation bias — not generic compliance.
- Embed mandatory checkpoints for high-impact decisions (credit denial, hiring, welfare benefits) with documented agreement or disagreement rationale.
- Log overrides, disagreements, and error patterns; use them to refine both the system and the oversight procedure.
How do you manage general-purpose AI (GPAI) models integrated into your systems?
Integrating a GPAI model into a product makes you the AI system provider for EU purposes — even if you didn’t train the model. The GPAI provider supports your compliance; you carry the system-level obligations.
What the EU AI Act says
- GPAI models are components, not AI systems on their own. Art. 3(63)
- A system using a GPAI model that can serve a variety of purposes is a general-purpose AI system. Art. 3(66)
- GPAI providers must cooperate with downstream high-risk system providers. Art. 25 Art. 53
- GPAI providers have transparency and documentation obligations to support downstream compliance. Art. 53
- Stronger obligations apply to GPAI models with systemic risk. Art. 51 Art. 55
How to operationalise it
- If you integrate a GPAI model into your product, you are typically the provider of the AI system — even if you are not the GPAI model provider.
- Obtain upstream technical documentation, usage constraints, and systemic-risk information needed for your own risk management, data, robustness, and oversight obligations.
- Define your system’s intended purpose and high-risk status based on concrete uses (credit scoring vs. chat assistant).
- Build additional controls (filters, guardrails, logging, oversight) around the GPAI model tailored to that purpose.
- Use written agreements to secure the technical access and assistance the GPAI provider must provide.
- For systemic-risk GPAI models, ensure your system-level risk management considers those systemic risks and that you can evidence reliance on the model provider’s obligations.
When is a Fundamental Rights Impact Assessment (FRIA) triggered and how do you run one?
FRIA is mandatory for public-sector deployers and certain private deployers in employment, credit, and essential services. It must be done before first use, complement (not replace) the GDPR DPIA, and be notified to the market surveillance authority.
What the EU AI Act says
- FRIA required for deployers that are public bodies, private entities providing public services, and deployers of high-risk AI in Annex III points 5(b) and (c). Art. 27
- Critical infrastructure systems (Annex III point 2) are excluded from FRIA scope. Art. 27(1)
- FRIA must cover processes, frequency of use, affected persons and groups, fundamental rights at stake, mitigation measures, and governance. Art. 27(1)
- Required at first use; can rely on earlier assessments (e.g., GDPR DPIA) but does not replace them. Art. 27(4)
- Framed as essential to efficient fundamental-rights protection. R.96
- Must be updated when circumstances change. Art. 27(2)
How to operationalise it
- Determine in-scope status: public body, private provider of public services, or deployer of high-risk AI in Annex III 5(b) or 5(c).
- Cover at minimum: processes and decisions, frequency and duration of use, affected groups (especially vulnerable), specific rights at stake, mitigation, governance (oversight, complaint handling, redress).
- Leverage existing GDPR DPIAs as inputs; complement rather than duplicate.
- Notify the market surveillance authority using the AI Office template.
- Treat FRIA as a living document — update when purpose, data, users, environment, or risk profile change.
- Note: separate sector-specific FRIA may apply for real-time remote biometric identification by law enforcement.
How do you govern third-party AI systems and suppliers?
The Act treats supplier governance as a regulated activity. Contracts must secure documentation, technical access, and incident-reporting flows from upstream providers — and you must absorb modifications and treat open-source components as your own provider obligation.
What the EU AI Act says
- Multiple parties supply components to high-risk AI; written agreements must give the provider the information, capabilities, technical access, and assistance needed for compliance. Art. 25(4)
- Open-source tools and components (other than GPAI models) released under free and open-source licences are not directly burdened with these obligations. Art. 2(12) R.103
- Original providers no longer in scope must still cooperate by providing necessary information and technical access. Art. 25(4)
- Transparency and instructions must help deployers understand precluded uses, oversight measures, and risk-relevant conditions. Art. 13
- The AI Office may issue voluntary model contract terms. Art. 25(4)
How to operationalise it
- Classify suppliers by impact: GPAI providers, model/component vendors, integrators, resellers; prioritise controls on those affecting data, model behaviour, or high-risk classification.
- Contract for: technical documentation sufficient for your risk management; notification of changes that may amount to substantial modification; incident detection and reporting SLAs; corrective action duties.
- Allocate the provider/deployer roles explicitly for each integrated component, including the case where a customer becomes a provider through substantial modification.
- Run onboarding due diligence: evidence of conformity readiness, security, data governance, logging, oversight support.
- Treat yourself as primary provider for compliance purposes when relying on open-source AI building blocks; produce internal documentation to substitute for absent contractual duties.
Make the AI Act a governance advantage.
We work with leadership teams to design AI governance postures that go beyond compliance — cleaner AI estates, sharper accountability, and the trust of regulators and customers.
