AI Regulatory Frameworks

A product manager drops a link to a hosted resume-screening tool into a channel and asks whether the team can switch it on next Monday. Two questions decide the answer, and neither is technical: which rules reach this particular deployment, and what actually happens if one of them is ignored. Call the second one force and the first one reach.

This page owns the obligations that arrive from outside the organisation. The internal machinery you build to satisfy them, the AI inventory, the risk register, the testing and evaluation regime and the audit cycle, belongs to ai-lifecycle-grc-integration; the ethical questions regulation gestures at without answering, fairness, bias, explainability and acceptable use, belong to responsible-ai-use. When this page says a regime demands human oversight, the design of that oversight sits on those pages, not here.

Force: four classes, four very different consequences

Sort every instrument you meet into one of four classes, because the class predicts the consequence better than the document's title does.

Class	Example	Who enforces it	What failure costs
Binding regulation	EU AI Act, General Data Protection Regulation (GDPR)	Public authorities	Administrative fines, orders to stop processing, withdrawal of the product from the market
Certifiable standard	ISO/IEC 42001:2023	An accredited certification body	Loss of a certificate a customer or a tender demanded
Voluntary framework	NIST AI Risk Management Framework (AI RMF) 1.0	Nobody	Nothing legally; you lose a shared vocabulary and ready-made evidence
Government guidance	Joint Guidelines for Secure AI System Development	Nobody directly	Nothing legally, though a regulator may cite it as the expected practice

The practical use of this sorting is that only the first class makes "we decided not to" an indefensible sentence. The other three are choices, and a choice can be justified by cost, timing or scope. Treating a voluntary framework as if it were law wastes budget; treating a regulation as if it were a framework is the failure mode that ends in an enforcement file.

Reach: the trigger condition, tested per use case

Reach is the condition that pulls a deployment into a regime, and each regime uses a different one. The EU AI Act is triggered by placing an AI system on the Union market, putting it into service in the Union, or having the system's output used in the Union, and it says so irrespective of where the provider is established (Article 2(1)^[1]). The GDPR is triggered by processing the personal data of people in the EU, wherever the servers sit. Sectoral regimes are triggered by the business you are in. The two voluntary instruments are triggered by your own decision, or by a contract in which you already made that decision.

Because the triggers differ, the answer differs per use case, not per company. A single organisation can run a minimal-risk internal code assistant that no regime reaches, and a credit-scoring model that three regimes reach at once. Answering "are we in scope?" at the level of the org chart produces an answer that is wrong for most of the systems it covers.

One word, three meanings: watch "risk"

The word risk carries a different meaning in each regime, and the pages around this one use it differently again. Under the AI Act, a risk tier is a legal classification of an AI system based on its intended purpose, and it decides which obligations attach. Under the GDPR, high risk in Article 35^[2] describes risk to the rights and freedoms of the people whose data is processed, and it decides whether an assessment is mandatory. On the neighbouring governance page, risk means organisational risk recorded in a register and owned by a person. Three separate scales that never convert into each other. When a question or a policy uses the word, pin down which scale it means before answering.

The rest of this page walks the regimes in the order a practitioner meets them: the AI Act's tiers and roles, the general-purpose AI model track, the GDPR duties an AI deployment triggers, the voluntary instruments that produce the evidence, and the sectoral and national rules that sit underneath all of it.

Classification is a property of the system and its intended purpose, never of the company that bought it, the size of the model, or how much the vendor charged. Regulation (EU) 2024/1689, the EU AI Act^[3], sorts systems into four tiers, and the tier decides how heavy the obligations get. Figure 1 below shows the ladder and pairs each rung with the obligation it triggers.

Unacceptable risk: prohibited, with no compliance route

Article 5^[4] lists eight prohibited practices, points (a) to (h): subliminal or purposefully manipulative and deceptive techniques that materially distort behaviour; exploitation of vulnerabilities tied to age, disability or socio-economic situation; social scoring that leads to unjustified detrimental treatment; predicting criminal offending based solely on profiling or personality traits; untargeted scraping of facial images from the internet or CCTV to build facial-recognition databases; inferring emotions in the workplace and in education institutions; biometric categorisation to deduce race, political opinions, religious beliefs or sexual orientation; and real-time remote biometric identification in publicly accessible spaces for law enforcement, subject to narrow listed exceptions.

The list is exhaustive as adopted, though several entries carry their own carve-outs, so the practitioner move is to read the specific point rather than the summary phrase. The Digital Omnibus on AI adds one further prohibited practice, generating non-consensual intimate or sexual content and child sexual abuse material, which bites once that amending regulation applies. What distinguishes this tier is that there is no control set that makes the practice acceptable. Documentation, human oversight and a risk assessment do not unlock it. The only compliant response is not to build or use it in the Union.

High risk: two routes in, one narrow route out

A system is high risk by either of two routes (Article 6^[5]). The first route: it is a safety component of, or is itself, a product covered by the Union harmonisation legislation in Annex I, and that product requires a third-party conformity assessment. The second route: it falls in one of the eight areas of Annex III^[6], which are biometrics; critical infrastructure; education and vocational training; employment, workers management and access to self-employment; access to and enjoyment of essential private and public services and benefits; law enforcement; migration, asylum and border control management; and administration of justice and democratic processes. Credit scoring sits in the essential-services area, and resume screening sits in the employment area, which is why so many ordinary business systems land here.

Article 6(3) is the one route out, and it is narrower than it first reads. An Annex III system is not high risk when it does not pose a significant risk of harm and it meets one of four conditions: it performs a narrow procedural task, it improves the result of a previously completed human activity, it detects decision-making patterns or deviations without replacing or influencing the previously completed human assessment, or it performs a preparatory task to an assessment. The catch sits at the end of the same provision: a system that performs profiling of natural persons, the automated evaluation of personal aspects of a person, stays high risk regardless. Reaching for the derogation on a system that profiles people is therefore not a judgement call, it is simply wrong.

Transparency risk, and why it is not a slot on the ladder

Article 50^[7] attaches disclosure duties to specific system behaviours rather than to a risk score. Providers must tell people they are interacting with an AI system unless that is obvious to a reasonably well-informed, observant and circumspect person, and must mark synthetic audio, image, video and text in a machine-readable format that is detectable as artificially generated or manipulated. Deployers must inform people exposed to emotion-recognition or biometric-categorisation systems, and must disclose deep-fake content as artificially generated or manipulated, with narrower duties for artistic, creative or satirical work.

The two statements that follow could read as a contradiction, so take them together: transparency is described as a tier, and yet a high-risk system also carries Article 50 duties when it interacts with people or generates synthetic content. Both are true because the tiers partition the heavy obligations, not every obligation. Article 50 attaches on its own trigger, on top of whatever tier the system sits in.

Minimal risk: the default, and the place most systems land

Everything not caught by the three tiers above carries no tier-specific obligation under the Act. The European Commission's own framing is that the vast majority of AI systems currently used in the EU fall into this category, giving spam filters and AI-enabled video games as examples (regulatory framework for AI^[8]). Nothing stops an organisation applying controls here anyway, but those controls are a business decision, not compliance.

The takeaway to carry into any scenario question: find the tier first, because the tier decides whether you are reading a prohibition, a heavy conformity regime, a disclosure duty, or nothing at all. Only once the tier is fixed does the next question, who carries the duty, become answerable.

The same system hands two organisations completely different duty lists, and the split is the role each one occupies. Article 3^[9] defines a provider as the party that develops an AI system or a general-purpose AI model, or has one developed, and places it on the market or puts it into service under its own name or trademark. A deployer is the party that uses an AI system under its own authority, except where the use is a purely personal, non-professional activity. Importers, distributors and authorised representatives sit between the two with narrower obligations of their own. Most organisations that buy a tool are deployers.

What a deployer of a high-risk system actually owes

Article 26^[10] is a short and concrete list, and it is the one a practitioner is most likely to be handed. Deployers must take appropriate technical and organisational measures to use the system in line with the provider's instructions for use. They must assign human oversight to people with the necessary competence, training and authority, plus the support to exercise it. Where the deployer controls the input data, that data must be relevant and sufficiently representative in view of the intended purpose. They must monitor operation, and where they have reason to consider that use in line with the instructions presents a risk, inform the provider or distributor and the market surveillance authority without undue delay and suspend use. They must keep the automatically generated logs for a period appropriate to the intended purpose, of at least six months, unless other law says otherwise. An employer deploying a high-risk system at work must inform workers' representatives and the affected workers before putting it into use. Deployers must inform individuals that they are subject to a high-risk system, cooperate with competent authorities, and use the information the provider supplies to meet their data protection impact assessment duties under the GDPR.

That last clause is the seam between the two regimes: the AI Act does not perform the GDPR assessment for you, it obliges you to feed the provider's information into it. The GDPR section below covers that assessment, which the regulation requires before high-risk processing begins rather than after it.

Where a deployer becomes a provider

Roles are not permanent, and inheriting the provider role is the expensive surprise in this subject. Article 25(1)^[11] names three circumstances in which a distributor, importer, deployer or other third party is considered a provider of a high-risk system and takes on the full Article 16 obligations: (a) putting their name or trademark on a high-risk system already placed on the market or put into service; (b) making a substantial modification to such a system so that it remains high risk; and (c) modifying the intended purpose of a system, including a general-purpose AI system not previously classified as high risk, so that it becomes high risk under Article 6. Figure 2 below traces those three checks in order, with the deployer duty list as the outcome only when all three come back no.

Putting your own brand on a bought screening tool, or white-labelling, is the trap here precisely because it feels commercial rather than regulatory. That marketing decision silently converts a short Article 26 checklist into conformity assessment, technical documentation, a quality management system, and registration in the EU database.

What non-compliance costs

Penalties are tiered to match (Article 99^[12]). Breaching the Article 5 prohibitions draws administrative fines of up to EUR 35 000 000, or up to 7 % of total worldwide annual turnover for the preceding financial year if the offender is an undertaking, whichever is higher. Breaching most other operator obligations, including the provider and deployer duties, draws up to EUR 15 000 000 or 3 %. Supplying incorrect, incomplete or misleading information to notified bodies or national competent authorities draws up to EUR 7 500 000 or 1 %. For small and medium-sized enterprises including start-ups, each fine is capped at whichever of the percentage or the amount is lower, which reverses the normal rule.

The pattern worth memorising is the ordering rather than the exact figures: prohibitions are punished hardest, ordinary obligation failures sit in the middle, and lying to the regulator has its own tier. Answer a scenario by identifying which of those three things happened.

Not everything the AI Act regulates is an AI system with a risk tier. A general-purpose AI (GPAI) model is regulated as a model, on a separate obligation track that runs alongside the tiers rather than inside them. Someone who fine-tunes and ships a foundation model can therefore hold GPAI provider duties without any of their downstream systems being high risk, and a deployer who calls that model through an API holds neither. Figure 4 below traces the three questions that decide which of these duties you actually carry.

Article 53(1)^[13] gives providers of a GPAI model four obligations. They draw up and keep current the technical documentation of the model, including its training and testing process and evaluation results, and make it available to the AI Office and national competent authorities on request. They draw up and keep current the information and documentation that downstream providers need in order to understand the model's capabilities and limitations well enough to integrate it. They put in place a policy to comply with Union copyright law, including the reservation of rights under the copyright directive. And they draw up and publish a sufficiently detailed summary of the content used for training, following the template the AI Office provides.

Article 53(2) carves out the first two of those for models released under a free and open-source licence whose parameters, including weights, architecture and usage information, are made publicly available. The carve-out does not extend to the copyright policy or the training-content summary, and it disappears entirely for a model classified as carrying systemic risk. Weight availability alone is not the test; the licence has to be a free and open-source one and the model must not carry systemic risk.

Systemic risk, and the one number the Act puts in the text

Article 51^[14] classifies a GPAI model as carrying systemic risk when it has high-impact capabilities judged against appropriate technical tools, benchmarks and indicators, or when the Commission decides it has equivalent capability against the Annex XIII criteria. It then adds a presumption: a model is presumed to have high-impact capabilities when the cumulative amount of computation used for its training, measured in floating point operations, is greater than 10^25. That threshold is a rebuttable presumption and a trigger for extra obligations, not a definition of the model class, and the Commission can adjust it.

The practitioner consequence is short. If you consume models rather than train them, you are not a GPAI provider, and the documentation the provider owes downstream integrators is the raw material for your own duties: what the model can and cannot do, how it was evaluated, and what its known limitations are. If you cannot get that documentation from a supplier, that is a procurement finding, because it leaves you unable to evidence your own Article 26 and GDPR positions later.

The General Data Protection Regulation did not pause for machine learning. The moment an AI system touches personal data, four questions arrive together, and none of them is an AI-specific rule; they are ordinary data-protection law that AI deployments walk straight into. Figure 3 below groups the four questions around the deployment they attach to.

One: what is the lawful basis? Every processing operation needs a basis under Article 6^[15], and that includes assembling and using a training set, not just the live inference call. Where the data is special-category data such as health, biometric data processed to uniquely identify a person, or trade-union membership, an Article 9^[16] condition is needed on top of the Article 6 basis, not instead of it. The two most common failure patterns are reusing data collected for one purpose as training data for another, and treating a legitimate-interests basis as automatic rather than as something to be assessed and documented.

Two: is the decision taken solely by the machine? Article 22(1)^[17] gives a person the right not to be subject to a decision based solely on automated processing, including profiling, that produces legal effects concerning them or similarly significantly affects them. Article 22(2) allows it where the decision is necessary for a contract, authorised by Union or Member State law with suitable safeguards, or based on explicit consent; where the contract or consent route is used, Article 22(3) still requires safeguards including, at least, the right to obtain human intervention, to express a point of view, and to contest the decision. Article 22(4) restricts these decisions when they rest on special-category data.

The load-bearing word in that provision is solely. A screening pipeline that routes every rejection past a reviewer who has neither the time, the information nor the authority to overturn it is exactly the case regulators and courts scrutinise, so treat a nominal reviewer as a legal exposure to raise with counsel rather than as a safe harbour you have already reached. Whether the oversight in a given design is meaningful is a legal determination, not an engineering one; the design of that oversight is covered in responsible-ai-use.

Three: is an assessment required before you start? Article 35(1)^[2] requires a data protection impact assessment (DPIA) before processing that is likely to result in a high risk to the rights and freedoms of natural persons, and it explicitly flags processing that uses new technologies. Article 35(3) then lists cases where a DPIA is required in particular, and point (a) is a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions producing legal or similarly significant effects are based. Point (b) covers large-scale processing of special-category data and point (c) systematic large-scale monitoring of a publicly accessible area. A scoring or screening model normally lands squarely on point (a), so the assessment is a precondition to launch rather than a document produced afterwards.

Four: does the data leave the European Economic Area? Calling a hosted model in another country is a transfer, and Article 44^[18] opens Chapter V by allowing transfers only where the conditions in that chapter are met. Choosing a model endpoint is therefore a data-transfer decision as much as an architecture decision.

Rights against a system that already learned from the data

Two further duties reach AI deployments without being on that list. The right to erasure under Article 17^[19] is real but not absolute; Article 17(3) preserves processing necessary for compliance with a legal obligation, for the establishment, exercise or defence of legal claims, and for archiving, research or statistical purposes under Article 89(1). Deleting a record from the training corpus is also not the same operation as removing whatever that record contributed to a set of trained weights, and the technical means of doing the second are an active research question rather than a settled control, so the honest position is to say what your pipeline can and cannot do and let counsel judge the consequence. Separately, Article 33(1)^[20] requires notifying the supervisory authority of a personal-data breach without undue delay and, where feasible, not later than 72 hours after becoming aware of it. A model that leaks personal data through its outputs is a personal-data breach on the same clock as any other.

The takeaway is a sequencing one. Lawful basis and the impact assessment are pre-launch gates, the Article 22 safeguards are design requirements baked into the decision flow, and the transfer question is settled when you pick where the model runs. All four are cheaper to answer before the system ships than after a data subject asks.

Nothing in a voluntary framework makes an organisation compliant with anything, and presenting a certificate as a legal defence is a category error. Their value is narrower and more useful than that: they turn an abstract legal duty into artefacts an auditor or a supervisory authority can actually read. The three instruments below are the ones a practitioner meets most often rather than the whole field.

NIST AI RMF 1.0 is the reference framework, published by the United States National Institute of Standards and Technology as NIST AI 100-1 and released on 26 January 2023 for voluntary use^[21]. Its core has four functions, GOVERN, MAP, MEASURE and MANAGE. GOVERN is cross-cutting rather than a stage in a sequence: it is the culture, policy and accountability layer that the other three run inside, which is why the framework draws it around them rather than before them. There is no fifth function, and no certification. The Generative AI Profile, NIST AI 600-1, released on 26 July 2024, is a companion profile that names the risks specific to generative systems and suggests actions against them.

ISO/IEC 42001:2023 does a related job in a different shape. It specifies requirements for establishing, implementing, maintaining and continually improving an artificial-intelligence management system (AIMS), and it was published in 2023 as the first AI management system standard (ISO/IEC 42001 landing page^[22]). The commercially important property is that it is a management-system standard, so an accredited certification body can certify against it and a buyer can therefore demand that certificate in a contract. Its clause text is paywalled, so cite its identity, scope and publication date and stop there rather than quoting requirements you have not bought. ISO/IEC 23894 is the neighbouring guidance document on AI risk management, and it is guidance rather than a certifiable requirements standard.

Government guidance sits below both. The joint Guidelines for Secure AI System Development^[23], published on 27 November 2023 by the UK National Cyber Security Centre with the US Cybersecurity and Infrastructure Security Agency and a large group of international partner agencies, is organised around four lifecycle stages: secure design, secure development, secure deployment, and secure operation and maintenance. It carries no enforcement of its own. Its practical weight is that a regulator or a customer can point at it as the expected practice, which makes ignoring it a defensible position only when you can say what you did instead.

How to choose between them, and where the work goes

The selection rule is short. Reach for AI RMF when you need a vocabulary and a structure to organise AI risk work and nobody is asking for proof. Reach for ISO/IEC 42001 when a customer, a tender or an investor asks for third-party proof of an operating management system. Reach for the joint guidelines when the question is engineering practice across the build rather than governance structure. Adopting all three is normal, because they answer different questions and none of them satisfies a binding regime on its own.

What none of them does is run itself. Building and operating the inventory, the risk register, the evaluation and testing regime, the incident channel and the internal audit cycle these frameworks call for is the subject of ai-lifecycle-grc-integration. This page stops at which external instrument made you produce the artefact and how much force stands behind the request.

The EU AI Act and the GDPR are horizontal law: they apply across sectors and sit on top of whatever already regulated your industry. Neither displaces the sector regulator, so a hospital deploying a diagnostic model answers to its medical-device regime, its health-data rules and the AI Act at the same time, and satisfying one says nothing about the others. Expect obligations to stack rather than to supersede.

Three sectoral patterns recur often enough to recognise on sight, and they are patterns rather than an exhaustive list of regulated industries.

Healthcare. AI built into a regulated medical device reaches the AI Act through the Annex I route rather than the Annex III list, because the trigger there is being a safety component of a product that already requires a third-party conformity assessment under Union harmonisation legislation. In the United States, protected health information stays governed by its own health-privacy regime whether or not a model is involved, so a vendor that trains on clinical records inherits those duties alongside anything the AI Act asks. The pattern to carry: in healthcare, the product regulator usually arrives before the AI regulator.

Finance. Governance of models used in credit and risk decisions predates the current AI wave, and supervisors have long expected documented model development, independent validation and ongoing monitoring. The AI Act adds to that rather than replacing it: creditworthiness evaluation of natural persons sits in the essential private and public services area of Annex III^[6], which makes such a system a high-risk candidate. A bank therefore runs its existing model-governance process and the AI Act obligations together.

Critical infrastructure. Annex III also covers safety components in the management and operation of critical digital infrastructure, road traffic, and the supply of water, gas, heating and electricity. Operators in these sectors typically already carry security and resilience obligations from other law, and the AI-specific duties attach on top.

The United States: no single statute, several sources

There is no single omnibus federal AI statute in the United States. Obligations instead arrive from three directions at once: existing sector regulators applying existing law to AI-driven decisions, consumer-protection and anti-discrimination enforcement against unfair or deceptive practices and disparate outcomes, and a growing patchwork of state and municipal laws that impose duties such as bias auditing or notice for automated employment decisions. Federal policy direction has changed with successive administrations, which is precisely why the durable reference in the United States is the voluntary NIST AI RMF rather than a statute.

For a practitioner, the consequence is that the United States question is answered per state and per sector, and the answer moves. Track it as a live register with a named owner and a review date rather than as a fact you learned once. The exam-relevant contrast is structural and stable: the EU regulates the technology horizontally through one binding regulation with tiers and roles, while the United States regulates the use through existing regulators plus state law, with a voluntary federal framework as the common vocabulary.

The AI Act applies in stages rather than all at once. The Article 5 prohibitions and the AI literacy duty applied from 2 February 2025, and the general-purpose AI model, governance and penalty provisions from 2 August 2025, with the general application date set at 2 August 2026 and product-embedded high-risk systems following later (Article 113^[24]). That calendar has since been amended. The Digital Omnibus on AI, approved by the European Parliament on 16 June 2026, moves high-risk obligations for stand-alone systems in the Annex III areas to 2 December 2027 and for high-risk AI integrated into regulated products to 2 August 2028, and the European Commission now publishes those dates (regulatory framework for AI^[8]). At the time of writing the amending regulation had not yet appeared in the Official Journal, so no consolidated text of the Act^[3] yet carries them. Quote the deferred dates as adopted rather than as settled law.

Take the durable lesson rather than the calendar. The risk tiers, the role definitions and the substance of the obligations have been stable since the Act was adopted, while application dates have moved and may move again. Design to the obligation. When a date has to appear in a board paper, a customer contract, or an answer you would have to defend, read it off the Official Journal on the day you write it rather than off memory.

Questions in this area are almost always scenarios, and they reward a fixed reading order rather than recall of article numbers. Read the stem for reach first (whose market, whose data, which sector), then for tier, then for role. Most distractors are correct statements about the wrong one of those three.

Stem patterns and the discriminating detail

What the stem describes	What it is testing	The answer discipline
A company buys a hiring or scoring tool and uses it as supplied on EU candidates	Role, not tier	Deployer duties under Article 26: instructions, competent human oversight, input-data relevance, logs, informing workers. Conformity assessment belongs to the provider
The same company puts its own brand on that tool, or retunes it for a new purpose	The Article 25 role flip	The organisation becomes the provider and inherits the full Article 16 duty set
A non-EU company whose model output is used by EU customers	Reach	In scope through Article 2(1); server location and place of establishment do not decide it
An automated decision with legal or similarly significant effect on a person	GDPR, not the AI Act	Article 22: human intervention, the ability to express a view, the right to contest
A new scoring system about to launch on personal data	GDPR Article 35	The DPIA is a precondition to processing, not post-launch documentation
A customer or tender demands independent proof of AI governance	Certifiable versus voluntary	ISO/IEC 42001 certification by an accredited body. NIST AI RMF cannot be certified
A social-scoring or workplace emotion-recognition use case	Article 5	Prohibited: no control set makes it compliant
A fine figure attached to a prohibited practice	Article 99 tiering	Up to EUR 35 000 000 or 7 % of total worldwide annual turnover, whichever is higher

The four distractor families

Wrong instrument for the duty. An answer that assigns a GDPR duty to the AI Act or the reverse. Automated decision-making rights, lawful basis and impact assessments are GDPR; risk tiers, conformity assessment and CE-marked market placement are the AI Act. Both may apply to one deployment, so the question usually names the one it wants by naming the harm.

Wrong role. Offering conformity assessment, technical documentation or EU-database registration to an organisation that merely uses a bought system. That answer is correct law attached to the wrong party unless the stem contains a rebranding or a substantial modification.

Framework as compliance. Offering NIST AI RMF adoption or an internal policy as the answer to a binding obligation. Frameworks produce evidence; they do not discharge a legal duty. Similarly, an ISO/IEC 42001 certificate is a commercial and organisational proof, not an AI Act conformity assessment.

Geography as scope. Concluding that hosting outside the EU, or having no EU establishment, removes an obligation. Reach follows market placement, use of output in the Union, and the personal data of people in the EU.

One last habit worth building: when a stem offers a date, prefer the answer that names the obligation over the answer that hinges on a specific application date. The tiers and the roles have been stable since adoption, while the application calendar has already been amended once, and an exam item that turns on the obligation is testing something that has not moved.