The EU AI Act: what it asks of deployers

The first question to settle is which role you occupy under the AI Act. Providers place an AI system on the market. Deployers use one under their own authority. The obligations differ substantially, and most organizations we work with are deployers who assume they are providers, or providers who have not noticed they became one.

This article is written from an architecture perspective rather than a legal one. Treat it as a description of what these obligations mean for system design, and take the legal reading from your own counsel. The timetable in particular has been subject to amendment since the regulation entered into force, so confirm the current dates before you plan against them.

How you become a provider without meaning to

Deployer status is not permanent. Put your own name or trademark on a high risk system, make a substantial modification to one, or change the intended purpose of a system so that it becomes high risk, and the provider obligations transfer to you.

That matters for a common pattern: taking a general purpose model, wrapping it in retrieval and prompting, and deploying it for a purpose the original provider never described. Whether that constitutes a substantial modification is a legal judgement, but it is one worth making deliberately rather than discovering during an audit.

What deployers are actually asked to do

For high risk systems the obligations are mostly operational, which is why they land on architecture rather than on a policy document.

• Use the system according to the provider's instructions, which requires that those instructions exist inside your operational documentation rather than in a PDF nobody opened
• Assign human oversight to people with the competence and the authority to override an output, not only to review it
• Ensure input data is relevant and sufficiently representative for the intended purpose, which is a data pipeline property
• Monitor operation and inform the provider and authorities when a serious incident or risk emerges
• Retain automatically generated logs for a defined period, which means logging has to be designed in rather than sampled
• Inform workers and their representatives before putting a system into use in the workplace

Read that list as a system specification. Every item is something an architecture either supports or does not, and retrofitting any of them into a running deployment costs more than designing for it.

Transparency applies well below high risk

Systems that interact with people generally have to make clear that a person is dealing with a machine, and synthetic content generally has to be marked as such. These duties are lighter than the high risk regime and catch a much wider set of deployments, including the assistant someone stood up in a service desk without telling anyone.

There is also a competence obligation. Organizations are expected to ensure that staff working with these systems have sufficient understanding of them. That is a training and documentation commitment with a real cost, and it is easy to leave out of a project plan.

Why this is an architecture problem

Compliance is usually approached as documentation produced after a system is built. For these obligations that sequence fails, because most of them can only be satisfied by properties the system either has or lacks.

You cannot retain logs you never generated. You cannot demonstrate human oversight if the interface offers no way to reject an output. You cannot show that input data was appropriate without lineage. You cannot mark synthetic content after it has been distributed. Each of these is decided during design and is expensive to add afterwards.

A policy states what should happen. Only the system determines what does happen, and only the system can produce the evidence.

Where to start

Inventory first. Most organizations cannot list the AI systems already running in their estate, and an obligation you cannot enumerate is one you cannot meet. Record for each system what it does, who is accountable for it, what data it touches, and which role you occupy for it.

Then classify honestly. The temptation is to argue every system down a tier. That reasoning has to survive scrutiny later, so it is cheaper to be conservative now, and cheaper still to redesign a borderline system so it clearly sits below the line.

Classifying a system honestly is an architecture judgement before it is a legal one: what the system actually decides, and for whom, has to be traceable in the design rather than argued after the fact. That is the same starting question behind any systems architecture review we run — not which tier a system should sit in, but what would have to be true about it for the answer to be obvious.

Are we a provider or a deployer under the EU AI Act?

If you use an AI system under your own authority, you are a deployer. You take on provider obligations if you put your own name or trademark on a high risk system, substantially modify one, or change its intended purpose so that it becomes high risk. Building a product on top of a general purpose model can move you across that line.

What do deployer obligations mean for how a system is built?

Most of them are properties of the system rather than paperwork: retained logs, an interface that lets a human actually override an output, data lineage sufficient to show inputs were appropriate, and monitoring that surfaces incidents. They are cheap to design in and expensive to retrofit.

Does the AI Act apply to internal tools?

Use inside your own organization is still use. Internal deployments are frequently overlooked in inventories, and workplace deployments carry an additional duty to inform workers and their representatives before the system is put into use.

Where should an organization start?

With an inventory of the AI systems already running, including the ones adopted without a project. Record purpose, accountable owner, data touched, and your role for each. Classification and remediation are tractable once the list exists, and impossible before.