EU AI Act
also called Regulation (EU) 2024/1689 · Artificial Intelligence Act · AI Act · EU AI Act deployer obligations
The Act sorts systems into four bands. Article 5 prohibits a short list of practices outright. Article 6 defines high risk by two routes: systems that are safety components of products covered by the Union harmonisation legislation in Annex I, and systems used for a purpose listed in Annex III — biometrics, employment, essential services including creditworthiness assessment, and law enforcement among them. Article 50 adds transparency duties for a limited-risk band; everything else is unregulated beyond Article 4’s AI-literacy duty. The band is a property of the use case rather than the model, so one model is unregulated in one product and high-risk in another.
The role split is where agent teams most often misplace themselves. An organisation building agents on somebody else’s licensed model is normally a deployer under Article 3(4) rather than a provider under Article 3(3) — but Article 25(1) converts a deployer into a provider where it puts its own name on a high-risk system, substantially modifies one, or modifies the intended purpose of a system that was not classified as high-risk, including a general-purpose one, so that it becomes high-risk under Article 6. Building an agent is very often that third act, and Article 2(1)(c) reaches operators outside the Union whose output is used inside it.
Articles 12 and 14 are the two most quoted here, and both are commonly misattributed. They sit in Chapter III Section 2, the requirements for high-risk systems, and are addressed in the first instance to the provider. Article 12 requires that a high-risk system technically allow the automatic recording of events over its lifetime, at a traceability level appropriate to its intended purpose and expressly so that the deployer’s own monitoring under Article 26(5) is supported. Article 14 requires the system to be designed so natural persons can effectively oversee it in use, and 14(4)(e) is the limb everyone cites: intervene or interrupt through a stop button or a similar procedure that brings the system to a halt in a safe state. Article 14(3)(b) is how those articles reach an operator — some oversight measures are identified by the provider for the deployer to implement.
The deployer’s own duties are enumerated in Article 26, and each is individually testable. 26(1): technical and organisational measures to use the system in accordance with its instructions for use. 26(2): human oversight assigned to natural persons with the necessary competence, training, authority and support. 26(5): monitor operation on the basis of the instructions and inform the provider under Article 72; where use may cause the system to present a risk within Article 79(1), inform the provider and the market surveillance authority without undue delay and suspend use. 26(6): keep the automatically generated logs under the deployer’s control for a period appropriate to the intended purpose and at least six months, unless other Union or national law — data protection law in particular — provides otherwise. 26(9): use the information supplied under Article 13 in any GDPR Article 35 impact assessment. 26(12): cooperate with the competent authorities. 26(4), 26(7) and 26(11) cover input data, worker information, and telling people subject to an Annex III decision.
Article 99 tiers the penalties: up to €35 million or 7% of total worldwide annual turnover for the Article 5 prohibitions, up to €15 million or 3% for operator obligations including the Article 26 deployer duties, and up to €7.5 million or 1% for supplying misleading information to notified bodies or authorities; SMEs and start-ups pay the lower figure. Dates have moved under amending proposals since late 2025, so read them from the current consolidated text.
No product makes an operator compliant, and software vendors keep leaving that sentence out. A control in the request path can produce the record Article 12 contemplates, the stop capability of 14(4)(e), the approval records evidencing 26(2), a retained log for 26(6) and an export for 26(12). Classifying the system, assigning competent people, running an Article 27 assessment where one is required, choosing a retention period that satisfies both the six-month floor and the storage-limitation duty in GDPR Article 5(1)(e), informing workers and notifying an authority remain acts of the deploying organisation, and evidence produced by a tool discharges none of them.
The same team is both roles at once
A bank builds an internal agent on a commercially licensed general-purpose model to triage credit applications. In relation to the model it is a deployer. But Annex III point 5(b) makes the evaluation of the creditworthiness of natural persons a high-risk use, and by giving the system that intended purpose the bank falls under Article 25(1)(c): it is now the provider of a high-risk AI system it created, carrying the Chapter III Section 2 requirements, a conformity assessment and CE marking, and not only the Article 26 deployer duties it was planning for. It is also inside the class of deployers Article 27 requires to carry out a fundamental rights impact assessment, because point 5(b) is one of the two Annex III entries named there. Nothing in the model licence changes any of this, and the model provider’s own compliance posture is not transferable.
What eu ai act is routinely confused with
- GDPR
- GDPR regulates the processing of personal data; the AI Act regulates the AI system, including systems that process no personal data at all. They meet at Article 26(9), which routes AI Act information into a GDPR Article 35 DPIA, and they can pull in opposite directions on retention: Article 26(6) sets a six-month floor for keeping logs while GDPR Article 5(1)(e) forbids keeping personal data longer than necessary. Reconciling those two is a decision with a named owner, not a default setting.
- Provider and deployer
- A provider develops a system and places it on the market or puts it into service under its own name (Article 3(3)); a deployer uses one under its own authority (Article 3(4)). The duties differ almost entirely. The trap is Article 25(1)(c): modify the intended purpose of a general-purpose system so that it becomes high-risk and you have become its provider, with the full Chapter III Section 2 requirements, conformity assessment and CE marking, not merely Article 26.
- FRIA and DPIA
- A fundamental rights impact assessment under Article 27 is required only of a defined subset of deployers — public bodies, private operators providing public services, and deployers of the creditworthiness and life-and-health-insurance systems in Annex III points 5(b) and 5(c). A data protection impact assessment under GDPR Article 35 has an entirely different trigger. Article 27 says the FRIA complements the DPIA; neither substitutes for the other.
Related terms
ISO/IEC 42001
ISO/IEC 42001:2023 is the international standard specifying requirements for an artificial intelligence management system — the governance structure, processes and records an organisation puts in place to develop or use AI responsibly. It is the first AI standard an organisation can be certified against by an accredited certification body, and, like ISO/IEC 27001, it certifies a management system within a declared scope rather than any product, model or software.
NIST AI RMF
The NIST AI Risk Management Framework (AI RMF 1.0) is voluntary guidance published by the United States National Institute of Standards and Technology in January 2023 for identifying, measuring and managing the risks of AI systems across their life cycle. Its core organises that work into four functions — GOVERN, MAP, MEASURE and MANAGE — and, unlike a management-system standard, it carries no conformity or certification scheme, so an organisation adopts it and evidences its own adoption rather than being certified against it.
AI agent governance
AI agent governance is the practice of deciding, outside the agent and before it acts, whether the authority it is about to exercise is authority somebody actually delegated to it — and of recording afterwards what it did with that authority in a form that survives the people who could edit it. What separates it from model safety, from observability and from identity management is where the decision sits: in the path the action must travel, where it can refuse, rather than in a policy document, a dashboard, or a nightly reconciliation.
Where Token Observe does this
The definition above is the field's, not the product's. This is the part of the product that implements it, for a reader who wants to see one.
Flight recorder
Every governed request in a timeline a compliance officer can read, and a search box that never writes SQL.
The filter cannot group, count or correlate across traces
Human approvals
One human decision, bound to one exact payload, spendable once.
An approval takes effect only when the agent retries
Agent registry
One record per agent, and it is the record the gateway enforces against.
An overdue review never suspends the agent itself
Audit chain
Every administrative act hash-chained; seal it under a key held off the box, and anchor it with a signature your auditor can check alone.
Unkeyed, a rewrite that re-hashes everything verifies clean
The terms next to this one
The substrate everything here conforms to, and the four regulatory instruments that decide what evidence an operator has to be able to produce.
Definitions are the easy part.
The glossary is written to be useful whether or not you ever buy anything. If you have got to the point of deciding how to implement one of these in your own estate, say what your agents do and you will get a straight answer about what it would actually take.
no form · no qualification step · no sales desk · the other three ways in