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. The vote opened final negotiations with member states in the Council. The Parliament kept the Commission’s risk-based approach: 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. It added obligations for providers of foundation models and generative AI, such as disclosing that content is AI-generated and publishing summaries of copyrighted training data. It renamed the organizations that use AI systems “deployers” and proposed that they assess impacts on fundamental rights. Credit scoring, access to essential public services and benefits, and employment decisions were among the uses listed as high-risk.

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. 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 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.

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. 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.

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. A public agency that builds its own eligibility triage model for benefits is in the same position.

The provider duties look familiar to banks with mature model risk management. 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. Gap analysis against the existing model inventory was the sensible first step, not a separate AI program.

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. 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 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. Contracts for AI-enabled products sold into the EU needed to name those deliverables. Procurement templates written for ordinary software rarely did.

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.

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.

The model developer’s obligations help, because they require documentation that downstream builders can use. They do not transfer the downstream organization’s responsibilities. 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.

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. In November 2025 the Commission proposed delaying parts of the high-risk timetable. In May 2026 the Parliament and Council reached provisional agreement to move stand-alone high-risk obligations to December 2027 and product-embedded ones to August 2028. Organizations should confirm the dates in force. 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 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.