Why the AI Act’s obligations follow your role, not your sector

The week

On June 14, 2023, the European Parliament adopted its negotiating position on the Artificial Intelligence Act, which the European Commission had proposed in April 2021. EU laws are usually made by three institutions: the Commission proposes, and the Parliament and the Council, which represents member state governments, each settle their own version before negotiating a final text together. The vote opened those final negotiations with member states in the Council.

The Council had settled its own position, known as a general approach, in December 2022. In Parliament the file was handled jointly by two committees, on the internal market and on civil liberties, with Brando Benifei and Dragoș Tudorache as co-rapporteurs. The committees adopted their report in May 2023. The plenary vote on June 14 passed by 499 votes to 28, with 93 abstentions, a wide margin for a law of that scope.

The vote came as generative AI was everywhere. Chatbots that could write essays, code and legal memos had gone from curiosity to boardroom topic in a few months, and Europe’s lawmakers were taking a big step toward the world’s first broad law on artificial intelligence.

The timing shaped the text. The Commission’s 2021 proposal predated the public release of ChatGPT in November 2022, and it said little about general-purpose models. Parliament’s committees wrote their foundation model provisions in the spring of 2023, while public attention was at its height. Negotiators also faced a political clock: European Parliament elections were due in June 2024, and a file left unfinished before them risked being reopened.

The Parliament kept the Commission’s risk-based approach. Rather than regulating all AI the same way, the law sorts uses by how much harm they could do: some practices prohibited, “high-risk” systems subject to detailed requirements, and others facing lighter transparency duties.

It widened the prohibitions, including a ban on real-time remote biometric identification in publicly accessible spaces, meaning systems that recognize people by their faces or other physical traits from a distance, live, in places like streets and stations.

The list of banned practices grew in other directions too. It covered biometric categorization based on sensitive characteristics, predictive policing based on profiling, emotion recognition in law enforcement, border management, workplaces and schools, and the untargeted scraping of facial images to build recognition databases. Several of these were later narrowed or qualified in the final negotiations.

Parliament also changed how the high-risk category worked. Under its text, a system in one of the listed areas would count as high-risk only if it posed a significant risk of harm, an added filter the Commission’s proposal had not contained. It added systems used to influence voters in elections, and the recommender systems of the largest online platforms, to the high-risk list.

It added obligations for providers of foundation models and generative AI. A foundation model is a very large AI model trained on vast amounts of data that can be adapted to many tasks, the engine underneath many chatbots. Generative AI is AI that produces new content such as text or images. The duties included disclosing that content is AI-generated and publishing summaries of copyrighted training data.

Parliament proposed maximum fines of up to €40 million or 7 percent of worldwide annual turnover for the most serious breaches. It also proposed a right for individuals to file complaints about AI systems and to receive explanations of decisions based on high-risk systems that significantly affected their rights.

It renamed the organizations that use AI systems “deployers” and proposed that they assess impacts on fundamental rights, the basic rights protected under EU law, such as privacy and non-discrimination. Credit scoring, access to essential public services and benefits, and employment decisions were among the uses listed as high-risk.

Parliament also proposed that public authorities using high-risk systems register that use in a public EU database, a duty the Commission’s text had placed only on providers.

Most coverage focused on chatbots. For banks, hospitals and public agencies, the more important story was in the structure underneath.

In June 2023 the AI Act was still a draft, and much of its final shape was uncertain. One feature was stable across the Commission, Parliament and Council texts, and it was the most useful for planning. Obligations depend on an organization’s role in relation to a specific AI system, not on its sector or on whether it thinks of itself as an AI company.

That runs against intuition. Many executives expect regulation to say “banks must do X, hospitals must do Y.” The AI Act instead asks, system by system, “What is your relationship to this particular piece of AI?” A regional bank, a hospital group or a public agency can hold different roles for different systems, and sometimes two roles for the same one.

The design has a history. The AI Act was built on the EU’s product safety model, the same family of laws that governs machinery, toys and medical devices. Under that model, the manufacturer certifies the product, the importer and distributor check it, and the user follows the instructions. Duties attach to positions in a supply chain. Applied to AI, that logic produced roles rather than sectors, and it explains why a hospital and a bank can owe identical duties for similar systems.

The planning exercise was to sort every AI use into one of three roles: building a system, deploying a system someone else built, or building on top of a general-purpose model.

Providers, deployers and other terms of art

An AI system, for practical purposes, is software that takes in information and produces outputs such as predictions, recommendations, decisions or content, using techniques that learn from data rather than following only hand-written rules. A credit score model, a tool that flags suspicious transactions and a chatbot are all examples.

A provider is whoever builds an AI system and puts it out under its own name, whether selling it to others or using it internally. In car terms, the provider is the manufacturer.

A deployer is whoever uses an AI system under its own authority. The deployer is the company that runs a fleet of those cars: it did not design them, but it decides who drives, where and how, and it must keep them maintained.

A general-purpose model is a large model, like those behind popular chatbots, that is not built for one task but can be adapted to many. The draft called these foundation models. Companies increasingly build their own applications on top of them.

High-risk is a legal category, not a judgment about how clever the technology is. It covers uses where errors could seriously affect people’s lives, such as deciding who gets credit, a job or public benefits.

A conformity assessment is a check, before a high-risk system is put to use, that it meets the law’s requirements.

Three further terms carry most of the weight in practice. Intended purpose is the use the provider specifies for the system, in its instructions and documentation. Most of the deployer’s duties are measured against it, and departing from it is what turns a user into a provider. Placing on the market means first making a system available in the EU, whether for payment or free of charge. Putting into service means supplying it for first use, including to oneself. Together, those two phrases explain why an in-house system can bring provider duties without any sale.

Substantial modification is a change after a system was placed on the market that the provider did not plan for and that affects compliance or the intended purpose. Retraining a model within a range the provider documented in advance is usually not one. Repurposing it for a new kind of decision may well be.

Role one: building a system

An organization that develops an AI system and places it on the market, or puts it into service under its own name, is a provider. Putting a system into service for the organization’s own use counts. That last point is the one most often missed: you do not have to sell anything to be a provider.

Providers of high-risk systems carry the heaviest duties. They need a risk management system, governance of training and test data, technical documentation, logging, instructions for deployers, designed human oversight, accuracy and robustness requirements, a quality management system and a conformity assessment before use. Each item has an everyday meaning: know the risks, know your data, write it all down, keep records of what the system did, tell users how to use it safely, make sure humans can step in, make sure it works reliably, manage it with a proper process, and have it checked before it goes live.

Many regulated organizations assumed this role did not apply to them because they buy most of their technology. That assumption deserved checking. A bank that builds its own consumer credit scoring model for EU customers is a provider of a high-risk system even if the model never leaves the bank. A hospital group that develops a clinical decision support tool qualifying as a medical device faces the AI Act alongside medical device rules. (Clinical decision support tools help clinicians make diagnostic or treatment decisions, for example by flagging patients at risk.) A public agency that builds its own eligibility triage model for benefits is in the same position.

Which uses are high-risk, and which are not

The high-risk list matters more to regulated organizations than any other part of the law. Uses relevant to banks, health systems and agencies include evaluating creditworthiness and setting credit scores for individuals, and risk assessment and pricing for life and health insurance. The list also covers eligibility for public assistance benefits and services, emergency call triage, and recruitment and other employment decisions. The final text carved out AI used to detect financial fraud from the credit scoring entry. A bank’s fraud model and its credit model can therefore sit in different categories even if the same team built both.

Parliament’s “significant risk” filter survived in another form. The final law lets a provider conclude that a system in a listed area is not high-risk in some cases. Examples include a system that performs a narrow procedural task or only prepares an assessment for a human. A system that profiles individuals cannot use that exemption. The provider must document the reasoning, and authorities can ask to see it. That exemption is useful but easy to over-claim, and it deserves review by counsel rather than a quick self-certification.

Health systems and agencies as providers

Hospitals face a two-track question. AI that is itself a medical device, or a safety component of one, and that requires third-party assessment under EU medical device rules, is high-risk through that route. Its conformity assessment runs through the notified bodies that already review devices, with AI requirements added. A hospital group that develops such a tool in-house for its European sites takes on manufacturer-style duties under two regimes at once. A tool that does not qualify as a device, such as a scheduling or capacity model, may fall outside the high-risk category altogether.

For most high-risk uses on the list, by contrast, the conformity assessment is an internal check by the provider rather than a review by an outside body. That lowers the cost but raises the importance of the provider’s own documentation, because it is the evidence an authority will examine later. High-risk systems in those listed areas must also be registered in an EU database before use. Public authorities that deploy them must register their use as well, which makes a public agency’s AI portfolio partly visible to anyone who looks.

Public agencies have their own reason for care. The listing of benefits eligibility as high-risk reflected European experience with automated welfare decisions. The Dutch childcare benefits affair, in which thousands of families were wrongly treated as fraudsters, led to the resignation of the Dutch government in January 2021. An agency that builds an eligibility model is building in the area legislators watched most closely.

What the provider role costs to run

The provider duties continue after launch. A provider of a high-risk system must run post-market monitoring, collecting and reviewing data on how the system performs in use. It must report serious incidents to the relevant authority. It must keep technical documentation current as the system changes, and it must keep that documentation available for years after the system is withdrawn. Each duty needs a named owner and a budget line.

For a bank, those owners usually exist in some form within model risk management, compliance and operational risk. For a hospital group or a public agency, they often do not, and the first provider system can require a small new function. The cost scales with the number of high-risk systems an organization provides, which argues for knowing that number early and for asking whether each in-house build is worth its compliance overhead.

Familiar ground for banks, with two new pieces

The provider duties look familiar to banks with mature model risk management. Model risk management is the discipline, long expected by bank supervisors, of checking that the mathematical models a bank relies on are sound, documented and monitored. Validation, documentation and change control map onto much of what the draft required.

Two parts were usually new: a formal quality management system covering the AI lifecycle, and logs designed so that deployers and authorities could reconstruct individual outputs. The first means a documented, repeatable process for how AI is designed, tested, released and changed, the way a manufacturer manages product quality. The second means being able to answer, for a specific customer on a specific day, “why did the system say that?”

Gap analysis against the existing model inventory was the sensible first step, not a separate AI program. Most banks already keep a list of their models. The job was to check which of them count as AI systems in high-risk uses, and what is missing compared with the draft’s requirements.

The final law recognized the overlap with bank supervision. Financial institutions already subject to internal governance rules under EU financial services law can satisfy parts of the quality management duty through those rules. Financial supervisors act as the authorities for AI used by the institutions they oversee. That reduces duplication for EU-regulated banks. It does less for a US bank serving EU customers from outside the EU. That bank still needs to map its own model risk framework, such as the US supervisory guidance known as SR 11-7, onto the Act’s requirements.

Role two: deploying a system someone else built

An organization that uses an AI system under its own authority is a deployer. This is the role most regulated organizations hold most often, because most AI arrives inside products bought from vendors: a fraud screening service, a résumé screening tool, a hospital imaging product.

Deployers of high-risk systems have narrower but real duties. They must use the system according to its instructions, assign human oversight to competent people, make sure input data under their control is relevant, monitor operation, keep logs, and in some cases tell affected people that a high-risk system was used. The Parliament also pressed for a fundamental rights impact assessment before use, a structured look at how a system might affect people’s rights, such as fairness or privacy, before switching it on.

What deployers owe, by type of organization

The final law made those duties concrete and added a few that depend on who the deployer is. Deployers must keep the logs generated by a high-risk system, to the extent the logs are under their control, for at least six months unless other law requires otherwise. An employer must inform workers’ representatives and affected workers before putting a high-risk system into use at the workplace. A deployer that uses a high-risk system to make or assist decisions about people must generally tell them that such a system is involved.

The fundamental rights impact assessment ended up narrower than Parliament wanted. It applies to public bodies and to private entities providing public services, and to deployers of credit scoring and of life and health insurance pricing systems. A county agency in an EU member state and a lender using a credit model both fall within it. A hospital using a scheduling tool generally does not. Affected individuals also gained a right to an explanation of the role an AI system played in a decision that significantly affects them.

One duty applies to nearly everyone. From February 2025, providers and deployers must take measures to ensure a sufficient level of AI literacy among staff who operate or use AI systems. That requirement reaches well past high-risk uses. It covers the bank teller using a chatbot and the caseworker using a summarization tool.

Branding can also change the role. An organization that puts its own name or trademark on a high-risk system someone else built can take on the provider’s duties. A bank that offers a vendor’s credit decisioning engine to its customers under the bank’s own brand should check, with counsel, which side of that line it is on. White-label arrangements are common in financial services, and the contract should say clearly who carries the provider role.

You can only comply if your vendor helps

A deployer can only meet these duties if the provider supplies what they depend on. Instructions must be specific enough to define correct use. Logs must be accessible to the deployer. Performance information must cover populations like the deployer’s own. A tool tested mainly on one country’s population, for example, may behave differently on another’s.

Contracts for AI-enabled products sold into the EU needed to name those deliverables. Procurement templates written for ordinary software rarely did. They covered uptime, support and data security, not “please provide logs that let us reconstruct each decision” or “please show us accuracy for customers like ours.” Updating those templates is an unglamorous, high-value task for procurement and legal teams.

Vendors push back, and some of their objections are reasonable. Detailed performance data can reveal proprietary methods. Per-decision logs can contain personal data, which then needs its own protection under data protection law. Smaller vendors may not have measured performance across the populations a client cares about. Contracts can handle these points with confidentiality terms, defined log formats and a commitment to produce population-specific performance data within a set period. A vendor that refuses all of them is telling the client something useful about how hard compliance will be.

Human oversight that is real

Human oversight is the duty most easily done badly. Assigning a reviewer is simple. Making sure that reviewer has the time, training and authority to overrule the system is harder. A reviewer who confirms nearly every recommendation, at a rate set by a throughput target, is a signature, not oversight.

Deployers can measure override rates and review time per case, and act when either looks implausible. Take a county benefits office where caseworkers review an automated eligibility recommendation. If reviewers almost never disagree with the system and spend only seconds per case, the oversight exists on paper only. If the numbers look like genuine judgment, the organization has evidence that humans are really in charge.

The final text names the underlying problem. It requires that people overseeing high-risk systems be made aware of the tendency to rely on automated output, known as automation bias. Training addresses part of it. Workflow design addresses more: showing the reviewer the evidence before the recommendation, sampling cases for second review and rotating reviewers on high-volume queues. Each adds cost and time, which is the trade-off a throughput target hides.

Role three: building on a general-purpose model

The Parliament’s most visible addition placed duties on the companies that develop large general-purpose models. For most regulated organizations the more important question was what happens when they build an application on top of such a model. That is where roles can shift without anyone noticing.

A bank that builds a customer service assistant on a general-purpose model becomes the provider of that assistant. It owes transparency duties, such as telling customers they are dealing with an AI system. If the same bank uses the model to help assess creditworthiness, it may become the provider of a high-risk system, with everything that follows.

A deployer that substantially modifies a purchased high-risk system, or changes its intended purpose so that it becomes high-risk, can also take on provider duties. A procurement team that bought a summarization tool and a business unit that started using it in lending decisions may have created a new provider without either noticing. Nobody signed a document saying “we are now building a high-risk AI system.” A new use simply crept in.

The model developer’s obligations help, because they require documentation that downstream builders can use. They do not transfer the downstream organization’s responsibilities. Buying a well-documented engine does not make the car you build with it safe by default.

What the model developers owe downstream

The final law turned Parliament’s foundation model article into obligations for providers of general-purpose AI models. They must keep technical documentation and give downstream providers the information they need to understand the model’s capabilities and limits. They must also adopt a policy to comply with EU copyright law and publish a summary of the content used for training. Models trained with very large amounts of computing power are presumed to carry systemic risk and face further duties, including evaluations, incident reporting and cybersecurity measures.

For a bank or hospital building on such a model, the useful output is the downstream documentation. It should describe what the model was designed for, known limitations and the conditions under which the developer advises against use. A downstream provider of a high-risk application will need that material for its own technical file. Procurement should ask for it at contract signature rather than when a regulator asks.

Fine-tuning, retrieval and the line between user and builder

Organizations adapt general-purpose models in different ways, and the differences matter. Writing prompts and connecting a model to internal documents through retrieval leave the model itself unchanged. The organization is building an application on the model, and its duties attach to that application. Fine-tuning changes the model’s weights. Commission guidance in 2025 set a compute-based test for when such modification makes the modifier the provider of a new general-purpose model, and most enterprise fine-tuning falls well below it. The application built on the tuned model still brings its own duties, whatever happens to the model.

The register that holds it together

The practical control is a register of every application built on a general-purpose model, recording its intended use, its owner and whether that use is high-risk. Changes of use should go through the same review as a new system.

The same register serves outside the EU. The NIST AI Risk Management Framework and several US state proposals distinguish developers from deployers in similar ways, and counsel can map each regime onto one record of roles. (NIST, the US National Institute of Standards and Technology, publishes widely used voluntary frameworks.)

The register does not need to be sophisticated. A shared table with a row per application, columns for purpose, owner, role, risk category and date of last review, and a rule that nobody changes the purpose without updating the row, will do most of the work. What matters is that it is complete, current and actually consulted when someone proposes a new use.

The register needs a gate. The most reliable one is at the points where a new use becomes visible anyway: a request for new data access, a change to a vendor contract, a new integration or a funding request. If each of those forms asks whether AI is involved and which register entry it relates to, the register stays current without a separate reporting process. A register maintained only by an annual survey will always be behind the business.

One lender, three roles

Suppose a mid-sized lender has customers in several EU countries. It is not a technology company, and its executives would not describe it as an AI business. Yet a quick inventory turns up three systems that each put it in a different role.

First, its own data science team built a model that scores applications for personal loans. The bank is the provider of that system. Because it is used for credit scoring of individuals, it falls into a high-risk category, and the bank carries the full set of provider duties, even though the model never leaves its own servers.

Second, it bought a fraud-screening service from a specialist vendor and runs it on its card transactions. For that system, the bank is a deployer. Its duties are narrower, but they depend on the vendor providing clear instructions, access to logs and performance information that reflects the bank’s own customers.

Third, its digital team built a customer service assistant on top of a general-purpose model from a large AI developer. The bank is the provider of that assistant and owes transparency duties, such as telling customers they are chatting with an AI system. So far, it is not high-risk.

The fraud service is a useful contrast. The Act’s credit scoring entry excludes AI used to detect financial fraud, so the vendor’s fraud model is generally not a high-risk system under that heading. The bank still owes the deployer basics, such as AI literacy for the staff who use it. Data protection law also continues to apply to the transactions it screens. The heavy deployer duties fall away, which is why the classification is worth getting right before building controls around it.

Then, six months later, a lending manager notices that the assistant writes excellent summaries and starts pasting loan files into it to help decide borderline applications. Nobody files a request. Nobody updates a register. But the use has changed, and with it, potentially, the bank’s role: it may now be the provider of a high-risk system it never set out to build. This is the scenario a register and a change-of-use review are designed to catch, and it is far more common than a dramatic failure.

A change-of-use review would have caught it in a week. The reviewer asks what decision the assistant now informs, finds that it touches creditworthiness and routes the case to model risk management. The bank then has three options: stop the use, treat the assistant as a high-risk system and build the provider file, or redesign the workflow so the tool only performs a narrow preparatory task. Each is defensible. Drifting into the second without deciding is not.

The same exercise would look similar at a hospital group or a public agency. The labels differ; the logic is identical. A hospital group might provide an in-house deterioration model that qualifies as a medical device. It might also be a deployer of a vendor’s imaging product, and the builder of a documentation assistant on a general-purpose model. A public employment agency might be the provider of a job-matching model, a deployer of a vendor’s fraud analytics and the builder of a citizen-facing assistant. The test is never whether the organization is an AI company, but what its relationship to each system is, and whether that has changed.

Reach beyond Europe, and what it costs

The AI Act matters even to organizations headquartered outside Europe, because it attaches to systems used for EU customers and residents. The law applies to providers placing systems on the EU market wherever they are established, and to deployers located in the EU. It also reaches providers and deployers outside the EU where the output of a system is used in the EU. For a bank with EU clients, a hospital group with European operations or a vendor selling into the EU, the questions are practical.

Cost: provider duties for high-risk systems require documentation, testing, quality processes and assessment, all of which take time and specialist staff. Knowing early which systems fall in scope avoids expensive retrofits. Risk: an organization that becomes a provider by accident, through a change of use, faces duties it has not planned for. Customers and citizens: the law exists to protect people affected by automated decisions, and the same controls that satisfy regulators also make decisions fairer and easier to explain. Reputation: few things damage trust like a public story about an algorithm that treated people unfairly with nobody really checking.

The exposure differs sharply by type of organization. A US community bank or credit union with no EU customers and no EU operations is largely outside the Act. A US broker-dealer or wealth manager serving clients resident in the EU may be in scope for systems whose output is used for those clients. A global bank’s EU subsidiary is plainly in scope as a deployer, and often as a provider. A US health system with no European patients or sites has little direct exposure. A technology vendor selling AI-enabled products into the EU is a provider, and its clients will expect it to carry the provider’s documentation burden.

The case for waiting

A US-based organization with a small EU footprint could reasonably have argued in 2023 that the Act was a draft, its timetable long and its reach uncertain. Some of that caution was justified, since details changed repeatedly and the high-risk timetable later moved. The argument for early work rests on the parts that did not change. An inventory of AI systems, a role for each and contract terms that secure vendor information are useful under any regime that distinguishes builders from users. US frameworks such as NIST’s and state laws like Colorado’s 2024 AI act draw similar lines. Work on those three items was unlikely to be wasted, whatever Brussels finally decided.

Organizations with no EU exposure at all can still borrow the structure. The role question clarifies accountability inside any organization, because it forces someone to say who designed a system, who decided to use it and who approved a change in how it is used.

Folding AI into existing controls

A well-prepared organization can produce a single list of its AI systems, with its role for each, an owner, and whether the use is high-risk. It has folded AI into existing model risk and procurement processes rather than inventing a parallel bureaucracy, its vendor contracts name instructions, log access and performance data, and it can show its human reviewers are actually reviewing.

The evidence an authority would ask for is mostly documentary. For a high-risk system the organization provides, it includes the technical documentation, the risk management record, the conformity assessment and the post-market monitoring plan. For a high-risk system it deploys, it includes the provider’s instructions, the assignment of human oversight, the retained logs and, where required, the fundamental rights assessment. For every system, it includes the register entry showing the role and the date of the last review. Organizations that can assemble that file in a day are in a strong position; those that need a project to find it are not.

The familiar failures:

• “We buy, so we are not a provider.” In-house models used for EU customers, even purely internally, can make you one.
• Organizing by sector instead of by system. Asking “what does the AI Act say about banks?” rather than “what is our role for this system?”
• Old procurement templates. Contracts that never ask for the information a deployer needs to comply.
• Rubber-stamp oversight. Reviewers with throughput targets and no real power to disagree.
• Unwatched changes of use. A tool bought for one purpose adopted for a high-risk one without review.
• A separate AI program in isolation. Building new governance from scratch instead of extending model risk management.

Roles have to be tracked system by system

The questions below are ordered by role: inventory first, then the systems the organization builds, the systems it buys, the reviewers who oversee them and the applications built on general-purpose models. Each can be answered from records an organization should already hold.

1. Do we have one list of every AI system we build, use or build on a general-purpose model, with our role and an owner for each?
2. Which in-house models touch EU customers or residents, and do any fall in high-risk categories such as credit scoring, benefits or hiring?
3. Do our AI procurement contracts require specific instructions for use, access to logs and performance data for populations like ours?
4. For high-risk uses, what are our reviewers’ override rates and time per case, and do they have the authority to say no?
5. What applications have we built on general-purpose models, and who approves a change in how one is used?

With hindsight

EU institutions reached political agreement in December 2023. The AI Act was published in July 2024 and entered into force that August. Prohibitions applied from February 2025 and duties for general-purpose model providers from August 2025. Most high-risk requirements were scheduled for August 2026. The staggered timetable gave organizations time, but it also meant the most demanding obligations for banks, hospitals and agencies arrived last.

Parliament gave its final approval in March 2024 and the Council in May. The law was published as Regulation (EU) 2024/1689. The Commission issued guidelines on the definition of an AI system and on the prohibited practices in February 2025. A code of practice for general-purpose model providers was published in July 2025, giving developers a voluntary route to show compliance.

In November 2025 the Commission proposed delaying parts of the high-risk timetable. Those changes, adopted as an amending regulation, entered into force on 27 July 2026: obligations for stand-alone high-risk systems now apply from 2 December 2027 and for product-embedded ones from 2 August 2028. That is breathing room, not a reprieve. The requirements themselves remain; only the start dates moved.

The provider and deployer roles survived intact, and the final law kept the fundamental rights assessment for public bodies and for deployers of credit scoring and certain insurance pricing systems. The structural insight from June 2023, that duties follow role rather than sector, held through every revision. Organizations that sorted their systems by role early did not have to redo that work as details changed.

Some of Parliament’s June 2023 positions did not survive in full. The fundamental rights assessment was narrowed from all deployers of high-risk systems to public bodies, providers of public services and certain financial uses. The maximum fine for prohibited practices settled at €35 million or 7 percent of turnover. The foundation model article became a tiered regime for general-purpose models, with heavier duties only for models presumed to carry systemic risk.

Other law moved alongside the Act. In December 2023 the EU Court of Justice ruled in a case involving the German credit bureau SCHUFA. It held that producing a credit score can itself be an automated decision under the GDPR when lenders rely on it heavily. In the United States, Colorado enacted an AI law in May 2024 that also distinguishes developers from deployers, with an effective date that was later pushed back. The federal executive order on AI issued in October 2023 was revoked in January 2025, and federal agency AI policy was reissued under new OMB memoranda that year.

The order in which duties arrived surprised some organizations. The prohibitions and the AI literacy requirement applied from February 2025. As a result, the first concrete AI Act tasks for many banks, hospitals and agencies were organization-wide deployer tasks rather than the high-risk provider work they had expected. Training records and a check that no prohibited practice was in use came well before any conformity assessment.

The role register has proved one of the most reusable pieces of AI governance, because the same record answers questions under the AI Act, US state laws and internal model risk policies. It is the rare compliance artifact that pays for itself several times over: built once, kept current, and consulted by legal, risk, procurement and technology teams alike.

The most durable preparation for AI regulation is knowing, system by system, what you built, what you bought and what you built on. Timetables shift and rules get amended; that basic map stays useful whatever the final details turn out to be.