Start from the agent's actions, not from the regulations. Build one library of controls around what agents can do: scope, depth, holds, sources, testing, logging, oversight and vendors. Then translate each regulation's requirements into plain statements and link each one to the controls that meet it. One control, one piece of evidence, many rules satisfied.
Why does mapping rule by rule fail for agents?
Most firms start with a separate checklist per regulation: one for the EU AI Act, one for GDPR, one for DORA, one for model risk. Each checklist produces its own controls and its own evidence. For agents, this goes wrong fast. The same agent action, say issuing a refund, is touched by conduct rules, data protection, operational resilience and model risk at once. Four checklists produce four partial views of one action, and nobody can say whether the action itself is controlled.
Agents also change often. A new source or a wider limit should trigger a review against every regulation, and with four checklists, it usually triggers one or none.
How do you build the map, step by step?
- List each agent and its capabilities. For each capability, record what it can read, what it can change, the depth it needs, and which customers and markets it reaches.
- Write an obligation register. For each regulation that applies, write the requirements in substance, in plain words. "Keep automatic logs of a high-risk system's operation" is better than an article number alone.
- Define a common control library around agent actions: role scope, the agent's depth and the depth each action needs, holds for named people, source provenance, testing before use, change re-testing, decision logging, outcome monitoring, vendor oversight and staff literacy.
- Link requirements to controls, many to many. One logging control may meet the EU AI Act, GDPR accountability, DORA incident reconstruction and model risk monitoring.
- Define evidence once per control, in a form every regulator would accept.
- Resolve conflicts by the stricter rule where markets differ, unless the cost of one design for all is clearly higher than running two.
- Re-run the map on change: when an agent's capability changes, every linked requirement is reviewed.
The NIST AI RMF's Map function is a useful frame for steps 1 and 2; see NIST AI RMF Map function for AI agents.
What does a mapped control look like?
| Control | EU AI Act | GDPR | DORA | Model risk (SR 11-7, SS1/23) | FCA Consumer Duty |
|---|---|---|---|---|---|
| Per-action decision log with sources | Article 12 logging | Accountability, Article 30 records | Incident reconstruction | Ongoing monitoring | Outcome evidence |
| Hold on adverse decisions for a named person | Article 14 oversight | Article 22 safeguards | No direct link | Model use limits | Fair treatment |
| Testing on real cases before use | Article 9 risk management | Article 35 assessment input | Resilience testing | Independent validation | Foreseeable harm |
| Vendor terms on model changes | Information from providers | Processor terms | Third-party risk | Vendor models | No direct link |
This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What may an agent do in the mapping work, and what stays with a person?
An agent can draft the obligation register from source texts, propose links between requirements and controls, and flag controls with missing evidence. Testing controls with agents is discussed in whether an AI agent can test compliance controls. A person must decide what each requirement means for the firm, accept or reject every link, and sign off the map. Interpretation of law stays with people and counsel.
An illustrative example
Take an EU-based payments firm with a UK subsidiary and agents in operations, support and fraud. Its compliance team first counted more than a hundred separate agent controls across five checklists. After rebuilding the map around actions, it had about twenty, each with one evidence source, linked to every requirement they meet. When the fraud agent's limit was raised, the map showed every requirement touched by that limit across both markets, and the change went through a single review rather than five.
What should you watch for?
- False equivalence. Two rules that sound alike may differ in substance. Article 22 safeguards and a model risk use limit are not the same thing.
- Frameworks posing as controls. Frameworks such as the NIST AI RMF organise thinking; they are not controls. The argument is in the NIST AI RMF is a useful map, not a control set.
- Standards as a base. A certifiable system such as ISO/IEC 42001 can supply the control library's skeleton; see ISO/IEC 42001 controls mapped to AI agents.
The full regulation-to-control map is in AI agent regulation, mapped to controls.
Questions people ask
Should the map live in a spreadsheet or a system?
Start where your team works, but link controls to live evidence as soon as you can. A map whose evidence is collected by hand goes stale between reviews.
Who owns the map?
Usually compliance, with risk and the agent owners contributing. Each control should have a named owner who produces its evidence.
How often should the map be reviewed?
On every material change to an agent or a rule, and on a fixed cycle besides. Changes to agents are the more frequent trigger.