Who is responsible for AI Act compliance as a deployer?

Somebody in the meeting always asks it the same way. Who is responsible for this? And somebody always answers in the same wrong voice — a name, a role, a person who will "own AI".

That answer cannot be correct, because the duty in the AI Act is not written against people. It is written against deployers, and a deployer is an organisation, not an employee. What a board actually needs to know is not who feels responsible. It is where the obligation lands, what discharges it, and what happens to the organisation when nobody did.

The duty attaches to the body, not the badge

Article 26 of Regulation (EU) 2024/1689 opens by placing the obligations on the deployer, and the deployer is the natural or legal person using an AI system under its authority in the course of a professional activity. For an association, that is the association. Not the head of IT. Not the membership director. Not the committee that approved the budget.

This distinction matters more than it sounds, because it changes what an inquiry looks for. If the duty attached to a person, the question would be whether that person did their job. Because it attaches to the body, the question is whether the body can demonstrate the duty was discharged — and a body demonstrates things with records, not with assurances.

That is why the honest answer to who is responsible is a sentence with three parts. The association holds the obligation. A named executive owns the work. The board is accountable for the evidence. All three, or the answer is incomplete.

Your supplier's contract does not move it

The most common misunderstanding in the sector is that buying from a responsible vendor makes you a responsible deployer. It does not. A vendor selling you a high-risk system can hold every provider obligation in the Act and still leave you holding every deployer obligation. The two sets are not a queue, where one party's work covers the other's.

A contract can allocate cost. It can allocate indemnity. It cannot allocate a statutory duty that the Regulation places on you, because the Regulation is not a party to your agreement. If the market surveillance authority comes asking, "the supplier said they had it covered" is a sentence about a commercial relationship, not a sentence about compliance.

What a good contract does is give you the things you need in order to discharge your own duty: the instructions for use, the logs, notice of a serious incident, and clarity on whether the system is high-risk at all. Those are the deliverables worth negotiating. The indemnity clause is what you argue about afterwards.

What Article 26 actually asks of a deployer

The deployer obligations are lighter than the provider's, and most of them only bite on high-risk systems. Article 26 sets them out in a list that reads as unremarkable until you notice that every item is evidenced by a document you may not have.

• Use it as instructed. Deployers use the system in accordance with the instructions for use accompanying it. Deviating from the intended purpose is not a configuration choice; it can change your role entirely, which is covered below.
• Assign human oversight to real people. Article 26(2) requires oversight to be given to natural persons with the necessary competence, training and authority, and with the necessary support. Not a committee. Not a policy statement. A person, competent, supported, with the standing to stop the system.
• Monitor, and know what "monitoring" means. Article 26(5) requires you to monitor the operation of the system on the basis of the instructions for use, and to inform the provider where relevant. If nobody has been told what normal looks like, nobody is monitoring.
• Keep the logs. Article 26(6) requires the logs generated by a high-risk system to be kept for a period appropriate to the intended purpose, of at least six months, unless other Union or national law provides otherwise. Logs are the cheapest evidence in the Act and the one most often deleted by a retention policy written for a different purpose.
• Tell the workers, and their representatives. Article 26(7) requires deployers to inform workers' representatives and the affected workers before a high-risk system is put into service at the workplace. For an association, which is an employer as well as a membership body, this is the obligation most often skipped — and the one most likely to be raised by a staff side that has read the Act.
• Stop when it looks wrong. Article 26(11) requires a deployer who considers the system presents a risk to health, safety or fundamental rights to inform the provider or distributor and the market surveillance authority, and to suspend use.

That list has a shape. Two items are about informing people, one is about stopping, and the rest are about producing a record. Nothing in it requires an AI department. All of it requires somebody to have decided, in advance, that these are things the association does.

The moment you stop being the deployer

Article 25 is the short article that catches associations that thought they were only using something. A deployer becomes a provider of a high-risk system — and inherits the manufacturer's obligations — where it does any of three things: puts its own name or trademark on the system, substantially modifies it, or modifies its intended purpose.

The badged member assistant is the case to watch. A vendor builds it, the association's logo goes on it, the association's name appears in the interface, and the association starts describing it as "our AI". That is not branding. That is a role change, and the obligations that arrive with it are the ones designed for the party that built the thing.

If an association wants the badge without the role, the question to ask before signing is not can we brand it but who is the provider of record, and does the contract say so in those words. Article 25 is a definition, not a preference. It applies whether or not anybody read it.

What the record looks like

A defensible position is one page, and it is not a policy. It states the systems in use, the named owner of each, the classification and who confirmed it, the oversight arrangement with the names in it, where the logs live and for how long, and the date the board last saw it. One page, reviewed on a cycle, with a version history.

That is the artefact that answers who is responsible without anybody having to be brave in a meeting. The association holds the duty. A named person does the work. The board owns the evidence — and the evidence is the only part of it that survives contact with an authority.

If the association cannot produce that page, the honest answer to the question is not a name. It is nobody, yet — and knowing that is worth more than a comfortable answer.

---

Running an association? The AI Act for associations — what your body must actually do sets out the whole thing on one page: whether you are a provider or a deployer, the four duties that reach a membership body, the dates that matter, and the five items of evidence a board will ask for.

If the one page does not exist yet, that is the first job rather than the last: First Build is ten working days on one deferred job — the inventory, the oversight record or the policy — and it comes back done.