Step 1: Classify every agent under the EU AI Act
The EU AI Act (Regulation (EU) 2024/1689, in force August 2024) regulates AI by risk tier: unacceptable (banned, Article 5), high-risk (heavy obligations, Annex III), limited-risk (transparency obligations, Article 50), minimal-risk (none). The general-purpose AI model rules apply from August 2025; the high-risk system obligations apply from August 2026; full applicability is August 2027. Before anything else, classify every agent in your registry against the tiers. Most business agents (a support assistant, a copywriting agent, an internal research tool) are limited-risk and mostly need transparency: tell people they are talking to an AI, label AI-generated content, label deepfakes. Some (agents used in hiring, credit scoring, essential public or private services, education access decisions, biometric categorisation) are high-risk under Annex III and carry real documentation, logging, human-oversight, and post-market monitoring obligations. The expensive mistake is not knowing which of your agents is which until a customer asks. Walk Annex III against your registry today.
Step 2: GDPR Article 22 and automated decision-making
GDPR Article 22 gives individuals the right not to be subject to a decision based solely on automated processing that produces legal or similarly significant effects. The European Data Protection Board guidance (most recently updated in 2023 with the SCHUFA referral) interprets "similarly significant" broadly: a credit refusal, a job rejection, a fraud-driven account suspension, a pricing decision that excludes someone from a service. If your agent decides something consequential about a person with no meaningful human involvement, Article 22 is in scope. You need a lawful basis (consent, contract necessity, or authorising EU/Member State law), you need to disclose the automated decision-making and provide meaningful information about the logic involved, and you must offer the right to obtain human intervention, express a point of view, and contest the decision. The fix is rarely to remove the agent. It is to add a meaningful human checkpoint (not a rubber-stamp), publish the disclosure, and document the appeal route. India DPDP and Brazil LGPD have parallel provisions; the pattern is the same.
Step 3: Extend SOC 2 scope to the agent
Most SOC 2 reports were scoped before the company had agents. The agent processes customer data, calls external models, takes actions, retains logs, and none of it is in the report. If the agent touches anything in your SOC 2 system boundary, the AICPA Trust Services Criteria (Security, Availability, Confidentiality, Processing Integrity, Privacy) have to cover the agent too, or your next report has a hole an auditor or a customer will find. Extending scope is straightforward when you do it deliberately at the start of the audit period: add the agent to the system description, map the relevant controls (access management, change management, monitoring, incident response, vendor management for the model provider), and document the testing. It is painful when a customer security questionnaire forces it mid-cycle and you have to issue a bridge letter. The 2024 update to the AICPA description-criteria explicitly addresses AI as part of system descriptions, so the framework already accommodates this; the question is whether you do.
Step 4: Build the audit trail
Every consequential decision an agent makes needs a record: what the inputs were (with PII redacted to the extent possible), what the agent decided, which model and provider produced it, which prompt version was active, when the decision was made, what tools the agent called, what data those tools returned, and what action ultimately fired. Immutable, timestamped, reproducible. The minimum schema is twelve fields, the practical schema is closer to twenty, and you want it in a write-once store (S3 Object Lock, Azure Blob immutability policies, or an append-only log table with an integrity hash). "The model decided" is not a defensible answer to a regulator, an auditor, or a customer dispute. The audit trail is also what makes an incident investigable: when something goes wrong at 2 AM, you can reconstruct what the agent saw, what it considered, and why it acted. Build it as the agent ships; reconstructing it later from scattered logs is expensive and usually incomplete.
Step 5: Map the sector rules
Horizontal rules (EU AI Act, GDPR, SOC 2) are not the whole picture. If you are in healthcare, HIPAA applies to what the agent can see and say, and the HHS guidance from 2024 explicitly covers AI as part of the Security Rule. In financial services, SR 11-7 model risk management guidance (US Federal Reserve) and the fair-lending rules (ECOA, Reg B) apply to any agent that influences a credit or pricing decision; the EU equivalent is the EBA guidelines on machine learning in IRB models. In children-facing products, the UK Age Appropriate Design Code and the COPPA Rule restrict what an agent can do. In life sciences and clinical decisions, the FDA Software as a Medical Device guidance applies. The gap we find is that the agent was built to the general standard and the sector controls were never mapped onto its behaviour. List your sector regulations, then walk each one against what the agent actually does, line by line.
Step 6: Document model provenance
When an auditor or a customer asks "what model is this, where does it run, what was it trained on, what version is in production today, what is the data retention policy", you should be able to answer in under a minute. Document the model name and version, the provider, the deployment region, the API endpoint, the data retention agreement (zero, 30 days, abuse monitoring only), the date it went live, and the eval score at launch, per agent, in the registry. The NIST AI RMF generative AI profile (NIST AI 600-1, published 2024) lists model provenance as a foundational requirement, and the EU AI Act Article 53 obliges general-purpose AI model providers to publish a training data summary that downstream deployers can cite. Provenance is a small artefact that answers a large share of every AI security questionnaire you will ever receive, including the SIG, the CAIQ, and the Vendor Security Alliance questionnaires.
The compliance-as-design checklist
Six steps, and every one is cheaper before the agent ships. Classify the agent under the EU AI Act risk tiers using Annex III. Check GDPR Article 22 if it decides about people, and document the human-review path. Extend SOC 2 scope to cover the agent in the next audit period. Build the immutable, twelve-field audit trail into the agent from day one. Map the sector rules (HIPAA, SR 11-7, COPPA, FDA SaMD) onto the agent behaviour. Document model provenance in the registry. Compliance treated as a design input costs a few days per agent. Compliance treated as a retrofit, triggered by a customer questionnaire or a regulator, costs a quarter, an external counsel, and a lot of goodwill. The cost curve is the entire argument; we have not seen it run the other way.
Further reading
Real, named sources the editor can swap in for specific URLs. We do not auto-link these because the right link changes over time. If you find a great primary source, write us and we will update the note.
- EU AI Act (Regulation (EU) 2024/1689). The risk-tier framework. Read the Annex III high-risk list against your own agents. Obligations phase in through 2026-2027.
- GDPR Article 22 (automated individual decision-making). The article that triggers the moment an agent decides something significant about a person.
- India Digital Personal Data Protection Act (DPDP). India's parallel regime. Consent, residency, and data-fiduciary obligations relevant to any agent serving Indian users.
- SOC 2 / AICPA Trust Services Criteria. The control framework most B2B customers ask for. Make sure the agent is inside the system boundary.
- NIST AI Risk Management Framework. The voluntary framework that maps cleanly onto most of the EU AI Act documentation obligations.
- ISO/IEC 42001. The certifiable AI management system standard. Useful when a customer wants an external attestation.
Comments