The EU AI Act,
by responsibility.
A high level map of the EU AI Act's high-risk obligations. For each one, three questions: who is responsible, what the AI system must be built to do, and what a governance or GRC platform does about it. The scope is high-risk AI systems under Regulation (EU) 2024/1689. It is vendor-neutral, and it is a map for teams building or governing AI systems, not a control library and not an implementation plan.
One duty, two sides
The AI Act does not put every obligation in one place. It assigns each duty to a legal actor, and then that duty usually has two sides: something the AI system must be built and operated to do, and something the organization must define, evidence, and report around it.
So each row below answers three questions: who is responsible, what the AI system must do, and what a GRC or governance platform does about it. If you build AI systems, read the system column. If you run a governance or compliance platform, read the last column. And note the responsible-actor column, because some duties, staff training for example, are the organization's own, and a platform can only record them, not perform them.
The actors, and the two kinds of work
The actors, as the Act defines them
Under Article 3(3), the party that develops an AI system, or has one developed, and places it on the market or puts it into service under its own name or trademark. The "own name or trademark" test is what matters: the party that stands behind the system, not one that merely resells or runs it. Providers carry most of the high-risk obligations.
Under Article 3(4), the party using an AI system under its own authority, an enterprise running it in its operations. Deployers carry the use-time duties.
Provider and deployer may be the same company or different ones. Both are organizations with staff, and a few duties, such as AI literacy under Article 4, fall on the organization itself, whichever role it holds.
The two kinds of work, per obligation
Capabilities engineered into the system and exercised while it runs: recording events, allowing a human to step in, staying accurate and robust, emitting monitoring signals. The provider builds these; the deployer operates them.
The rules, records, and proof around the system: policies, risk and quality management, documentation, defining what must be captured, collecting and testing that evidence, and reporting. This is the work a GRC or governance platform is built to support. Important: the platform supports the responsible actor, it does not replace them. It can track that staff were trained; the organization still has to train them.
An obligation is only met when the responsible actor has done its part in both places. Most confusion in AI compliance is one side assuming the other handles the whole thing.
This split, what the system does versus what the program defines and proves, runs parallel to the three-layer governance model: enforcement lives in the system, while definition and evidence live in the program.
The map
High-risk obligations, by article. Who is responsible, what the system must do, what a platform does about it.
| Article | Obligation | Who is responsible | What the AI system must do | What a GRC / governance platform does |
|---|---|---|---|---|
| Article 4 | Sufficient AI literacy among staff operating AI systems | Provider and Deployer (the organization) | Nothing, this is not a system feature | Tracks and holds evidence of staff training; the organization does the training |
| Article 6 / Annex III | Determine whether the system is high-risk | Provider | Provide the facts needed to classify it | Runs and records the classification decision |
| Article 9 | A continuous risk management process across the lifecycle | Provider | Surface system-level risks; support mitigations | Runs the risk process; maintains the register and reviews |
| Article 10 | Data governance for training, validation, test data | Provider | Implement data quality, relevance, and bias controls in the pipeline | Defines the data policies; evidences they were applied |
| Article 11 / Annex IV | Technical documentation, kept current | Provider | Produce the technical documentation | Holds it, tracks completeness, keeps it audit-ready |
| Article 12 | Automatic logging of events over the system's lifetime | Provider (system); Deployer keeps logs | Engineer automatic event logging into the system | Defines what must be logged; collects and tests the logs |
| Article 13 | Transparency and clear instructions for deployers | Provider | Produce the instructions and disclosures | Ensures they are delivered; holds and tracks them |
| Article 14 | Effective human oversight during operation | Provider (design) and Deployer (exercise) | Build the ability for a human to monitor, override, and interrupt | Defines the oversight procedures; evidences interventions happened |
| Article 15 | Accuracy, robustness, cybersecurity | Provider | Engineer the accuracy, robustness, and security measures | Sets acceptance thresholds; collects the test and resilience results |
| Article 17 | A documented quality management system | Provider | Follow the quality system across the lifecycle | Defines and runs the quality management system; the record of how the system is built and changed |
| Article 26 | Deployer duties: use as intended, monitor, ensure oversight, keep logs | Deployer (the enterprise using it) | Enable monitoring and oversight in the deployment | Runs the deployer duties; monitors use; retains logs |
| Article 43 | Conformity assessment before going to market | Provider | Provide the system and its evidence for assessment | Assembles readiness; manages the assessment record |
| Article 72 | Post-market monitoring of real-world use | Provider | Instrument the system to emit real-use signals | Defines the monitoring plan; collects and analyzes the data |
| Article 73 | Serious-incident reporting: immediately, and within 15 days (10 for a death, 2 for critical-infrastructure disruption or widespread infringement) | Provider (and Deployer notifies) | Detect and surface serious incidents | Runs the reporting workflow, meets the clock, holds the evidence |
In one line: the AI system is built to act and to emit. The organization, using a governance or GRC platform, has to define, collect, prove, and report. The Act is satisfied where the two meet, under the actor who is responsible for the duty.
Where autonomous agents break the map
The map above is stable for conventional high-risk AI. Autonomous agents expose a gap at the seam between the two kinds of work.
Article 12 requires automatic logging of events over the system's lifetime, but for high-risk systems in general it does not say which events. The one place it gets specific, Article 12(3) for remote biometric identification systems, names only a minimal, biometric-specific set: the period of each use, the reference database, the input data, and the persons involved in verification. None of it was written with autonomous agents in mind. It does not describe what an agent must emit to show that it stayed within the authority it was delegated, that it did not move data across a boundary it should not have, or that a limit held. So a system can log exactly what Article 12 asks for and still produce nothing that answers the question that matters for an agent. The same gap appears under Article 14 (what proves oversight of an autonomous agent was real) and Article 72 (what to monitor in an agent's behaviour).
For agents, the obligation is clear and the evidence is undefined.
The system side does not yet know what to emit, and the governance side does not yet know what to require. Defining that set of signals, what an agentic system must emit to be governable, at what granularity, and how to trust it, is the open frontier. It is not settled by the Act, and it is not yet settled by the emerging standards.
This undefined record is the evidence layer of the three-layer governance model, and the gap that Position 04 (Governance Debt Compounds) and Position 05 (Identity Answers Who, Governance Answers What) describe.
- EU AI Act, consolidated text (Regulation (EU) 2024/1689). eur-lex.europa.eu
- Article 4 (AI literacy). artificialintelligenceact.eu/article/4
- Article 9 (risk management). artificialintelligenceact.eu/article/9
- Article 12 (record-keeping). artificialintelligenceact.eu/article/12
- Article 14 (human oversight). artificialintelligenceact.eu/article/14
- Article 15 (accuracy, robustness, cybersecurity). artificialintelligenceact.eu/article/15
- Article 17 (quality management system). artificialintelligenceact.eu/article/17
- Article 26 (deployer obligations). artificialintelligenceact.eu/article/26
- Article 43 (conformity assessment). artificialintelligenceact.eu/article/43
- Article 72 (post-market monitoring). artificialintelligenceact.eu/article/72
- Article 73 (serious incident reporting). artificialintelligenceact.eu/article/73
- prEN 18286 (draft standard operationalizing Article 17). digital-strategy.ec.europa.eu
Where does your deployment
sit on this map?
If you are deploying agents into high-risk workflows and the evidence question is still open, that is the conversation. Most take 20 minutes.
Start the conversation