AI Agent Governance: the 71-day compliance countdown.

AI agent governance sits at the intersection of five compliance frameworks — EU AI Act (Regulation 2024/1689), NIST AI RMF 1.0, ISO/IEC 42001:2023, SOC 2 (AICPA TSP 100), and GDPR — and most enterprise teams are trying to satisfy them independently, without a single source of truth for which article, clause, or control governs each agent design decision. This guide provides that source of truth, anchored to primary regulatory text and verified as of May 23, 2026.

The stakes for 2026 are concrete. EU AI Act Articles 8–17, 26, 27, and 73 — the high-risk obligations and the serious-incident reporting requirement — are not yet in force as of this post’s publication. They activate on August 2, 2026: 71 days from now. That is not enough time to rebuild an agent’s logging infrastructure or negotiate new data processing agreements from scratch. Organizations that treat governance as a post-launch task will miss the deadline.

This guide covers, in order: what is currently in force vs. what activates August 2, the EU AI Act articles directly relevant to agent builders, how NIST AI RMF and ISO 42001 structure the governance problem, SOC 2 common-criteria mapping for agent systems, the precise scope of GDPR Article 22, the centerpiece five-framework crosswalk table, audit-trail requirements under Article 12 and OWASP LLM06, the US state landscape, and a 71-day action plan. For the governance glossary of terms, see our EU AI Act and NIST AI RMF glossary.

The single most important fact for any AI governance team in May 2026 is the timeline. EU AI Act obligations did not all activate at once. They phase in over 36 months from the regulation’s entry into force on August 1, 2024 (EUR-Lex Regulation 2024/1689). Knowing exactly which obligations are live today versus which activate in 71 days determines whether your current agent deployment is in violation or simply approaching its compliance deadline.

Already in force (✅). Article 5 prohibited practices — social scoring, real-time biometric identification in public spaces, emotion recognition in workplaces and schools, and predictive policing based solely on profiling — have been in force since February 2, 2025. Chapter V (General-Purpose AI Model obligations: training-data summary, technical documentation, copyright policy) has been in force since August 2, 2025. Both of these apply to you today.

Activating August 2, 2026 (⚠️ 71 days — NOT yet in force). Articles 8–17 (high-risk AI obligations: risk management, data governance, technical documentation, record-keeping, transparency, human oversight, robustness), Article 26 (deployer obligations including 6-month log retention), Article 27 (Fundamental Rights Impact Assessment), and Article 73 (serious-incident reporting) all activate on August 2, 2026 per the European Commission timeline. These are the obligations most agent deployments will need to satisfy — and they are not yet law.

Activating August 2, 2027. Annex II regulated-product categories (machinery, medical devices, etc.) activate 36 months after entry into force.

Not every EU AI Act article applies to every agent deployment. The high-risk classification triggers Articles 8–17, 26, 27, and 73 — but even non-high-risk agent deployments face Article 5 prohibitions (already in force) and the GPAI obligations of Chapter V if they use a general-purpose model. The six articles below are the ones with the most direct engineering implications for agent architectures.

Article 12 — Automatic logging. High-risk AI systems “shall technically allow for the automatic recording of events (logs) over the lifetime of the system.” The word “automatically” is operative — manual log creation does not satisfy this requirement. Logs must capture, at minimum, the start/end of each session, the input data reference, the outputs generated, and any human override events. For LLM-based agents, this typically means structured append-only logging at every inference call, tool invocation, and state transition.

Article 14 — Human oversight. High-risk AI systems must be “designed and developed in such a way, including with appropriate human-machine interface tools, that they can be effectively overseen by natural persons during the period in which they are in use.” For agent systems, this means at minimum: (1) the ability to pause or terminate the agent mid-task, (2) a review interface for high-stakes outputs before they take effect, and (3) an override pathway that does not require re-deploying the system. Article 14(4)(d) specifically requires the option to “not use the AI system or to override its outputs.”

Article 15 — Accuracy, robustness, and cybersecurity. High-risk AI systems must achieve “an appropriate level of accuracy, robustness, and cybersecurity throughout their lifecycle.” Article 15 explicitly names resilience against “data and model poisoning, adversarial examples, model evasion attacks, confidentiality attacks.” This maps directly to OWASP LLM Top 10 threat categories.

Article 26(6) — Log retention. Deployers “shall keep the logs automatically generated by that high-risk AI system … for a period appropriate to the intended purpose of the high-risk AI system, of at least six months, unless provided otherwise in applicable Union or national law.” Six months is the floor, not the ceiling. Regulated sectors (finance, health) typically impose longer retention periods under sector-specific law.

Article 27 — Fundamental Rights Impact Assessment (FRIA). Required for public-body deployers, private entities providing public services, and deployers of Annex III(5)(b) and (c) systems (creditworthiness scoring, life and health insurance pricing). A FRIA requires the deployer to assess the impact on: the right to human dignity, non-discrimination, privacy, freedom of expression, consumer protection, and the rights of vulnerable groups.

Article 73 — Serious-incident reporting (effective Aug 2, 2026 — NOT yet in force). Once active, providers must report any “serious incident” — meaning a malfunction, unexpected use, or output that has caused or could cause death, serious harm to health, property damage, or a serious breach of fundamental rights — to market-surveillance authorities within 15 days (or immediately for critical infrastructure malfunctions and widespread infringements). This clock starts when the provider becomes aware of the incident. Article 73 is effective August 2, 2026 — it is NOT in force as of this post (May 23, 2026). Organizations building incident-response playbooks should target completion before August 2, not treat it as already required.

The NIST AI Risk Management Framework (AI RMF 1.0), released January 26, 2023, is the primary US governance reference for AI systems. It is voluntary and sector-agnostic — it does not carry the force of law. Organizations do not “comply” with the NIST AI RMF; they “align with” or “adopt” it. That distinction matters when briefing boards: NIST alignment is a best-practice credential, not a legal obligation.

The framework organizes around four core functions: GOVERN, MAP, MEASURE, MANAGE. For agent-specific deployments, the subcategories with the most direct application are:

GOVERN-1.5 — establishes roles and responsibilities for humans-in-the-loop; maps to Article 14 oversight requirements and SOC 2 CC6 access provisioning. GOVERN-1.7 — third-party risk management; maps to GDPR Article 28 data-processing agreements and SOC 2 CC9.2. GOVERN-6 (entire subcategory) — supply-chain AI risk, covering sub-model providers, plugin ecosystems, and tool integrations within multi-step agent workflows.

MEASURE-2.7 — continuous evaluation logs for AI system monitoring; maps directly to Article 12 automatic-log requirements and SOC 2 CC7.2/CC7.3 event monitoring. MEASURE-2.11 — bias evaluation; maps to Article 10 data-bias examination, Article 27 FRIA, and ISO 42001 Clause 8.4 impact assessment.

The companion document, NIST AI 600-1 (Generative AI Profile), published July 26, 2024, lists 12 GenAI-specific risk categories and ~200 suggested actions mapped to AI RMF subcategories. Relevant to agent systems: Confabulation (hallucinated tool calls), Information Security (prompt injection), Value-chain integration (LLM provider as sub-processor), and Human-AI configuration (over-delegation of autonomy — the risk OWASP LLM06 names as Excessive Agency).

ISO/IEC 42001:2023, published December 18, 2023, is the world’s first AI-specific management system standard designed for third-party certification. It mirrors the ISO 27001 structure: Clauses 4–10 cover context, leadership, planning, support, operation, performance evaluation, and improvement. The operative content for agent governance sits in two places: Clause 8 (operational planning) and Annex A (38 controls across 9 areas).

Important clarification: ISO 42001 is an AI management system standard; ISO 27001 is an information security management system standard. They are different certifications covering different domains. An ISO 27001 certificate does not substitute for ISO 42001 certification, and vice versa — though many controls overlap in practice (particularly in the data governance and access control areas).

The controls most directly applicable to agent systems:

A.6.2.5 (human oversight) — establishes controls for human review of AI system outputs, mapping directly to Article 14. A.6.2.6 (logging of AI system operation) — requires operational logging, mapping to Article 12 auto-log requirements. A.7.3 (access management) — covers least-privilege access, tool whitelists, and sub-agent permission scoping. Clause 8.4 (AI system impact assessment)— the ISO 42001 analog to Article 27’s FRIA: a structured assessment of intended use, reasonably foreseeable misuse, and impact on fundamental rights. A.10.2 / A.10.3 — third-party AI system transparency and supplier management; maps to GDPR Article 28 and NIST GOVERN-6 supply-chain risk.

One structural point for teams building compliance programs: ISO 42001 Clause 8.2 requires a documented AI risk assessment that explicitly links identified risks to Annex A controls. You cannot simply adopt all 38 controls without evidence of the risk analysis that justifies each selection. The risk assessment is the document that will be examined first in a third-party audit.

SOC 2 (AICPA Trust Services Criteria, TSP 100, 2017 with 2022 update) is the US assurance standard most enterprise B2B SaaS companies face from their customers. The Security category (mandatory) uses Common Criteria CC1–CC9. The four additional categories — Availability, Processing Integrity, Confidentiality, Privacy — are optional but frequently included in agent-specific audits.

Three Common Criteria categories have the most direct application to AI agent systems:

CC6 — Logical and physical access controls. CC6.1 requires logical access policies; CC6.2 covers user provisioning (and de-provisioning, which matters for automated agent credentials); CC6.3 requires role-based access with least-privilege principles. For agent systems: every agent identity, every tool API key, and every sub-agent token must be governed under CC6 policies. An agent with broader tool access than the role it serves needs violates CC6 in the same way an over-privileged human user would. OWASP LLM06 (Excessive Agency) is the adversarial framing of the same gap.

CC7 — System operations and event monitoring.CC7.2 requires continuous monitoring for unauthorized access; CC7.3 covers incident detection and response. CC7.5 is incident communication (mapping to Article 73’s 15-day incident reporting obligation once that activates August 2, 2026). For agent systems: structured, real-time log streaming to a SIEM or equivalent monitoring platform satisfies CC7.2/CC7.3 and simultaneously builds the audit trail needed for Article 12 compliance.

CC8 — Change management. CC8.1 requires formal change management processes including authorization, testing, and rollback capability. For agent systems: every model swap, tool addition, prompt update, and system-card revision is a CC8-relevant change. Automated deployment pipelines that push agent updates without a human-reviewed change record will have difficulty satisfying CC8 in a Type 2 audit period.

A note on SOC 2 type discipline: SOC 2 Type 1 is a point-in-time assessment of control design; Type 2 covers the operating effectiveness of controls over a defined period (typically 6–12 months). A fresh agent deployment should target Type 1 as a readiness assessment and plan a Type 2 audit after 6 months of operational history — particularly if the system is subject to Article 26(6)’s 6-month log-retention floor, since the audit period and the retention period conveniently align.

GDPR Article 22 is the most widely mischaracterized provision in AI compliance documentation. Most summaries describe it as a “right to explanation for AI decisions.” That is incorrect on two dimensions. Here is what Article 22(1) actually says:

“The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.”

Article 22 is a right to object to the decision— not a right to receive an explanation. Three exceptions apply: contractual necessity (the automated decision is required for a contract), EU or Member State law authorization, and explicit consent. When an exception applies, Article 22(3) requires that the controller implement “suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests, at least the right to obtain human intervention on the part of the controller, to express his or her point of view and to contest the decision.”

The right to “meaningful information about the logic involved” — the closest the GDPR comes to a right to explanation — lives in Articles 13(2)(f), 14(2)(g), and 15(1)(h), which require controllers to disclose the existence of automated decision-making and provide “meaningful information about the logic involved, as well as the significance and the envisaged consequences of such processing.” These are transparency obligations at the time of data collection or access request — not challenge rights triggered by a specific decision.

For agent systems: if your agent makes a consequential automated decision about a data subject (loan approval, insurance pricing, content moderation that produces legal effects), Article 22 requires either an applicable exception or not making that decision at all without human sign-off. Articles 13–15 separately require that you disclose the fact of automated decision-making in your privacy notice and honor access requests. The two provisions operate independently.

A second GDPR provision directly relevant to agent deployments: Article 28(3) requires that every data processing agreement with a processor (including LLM API providers, vector database vendors, and tool-call intermediaries) impose eight specific obligations: processing only on documented instructions, confidentiality, Article 32 security measures, sub-processor written authorization, controller assistance, deletion or return of data at contract end, audit rights, and prompt breach notification. Every LLM API provider your agent calls is a data processor under GDPR Article 4(8) — and each one requires a signed DPA containing all eight elements.

The table below maps five governance frameworks against ten design decisions that every AI agent architect makes. Each cell cites the article, clause, or control number that governs that decision under each framework. No public source we found — Vanta, Drata, Holistic AI, OneTrust, Credo AI, isms.online — publishes a single 5×10 grid with article-level citations. This crosswalk is the analytical asset compliance teams need for board-level documentation and for prioritizing engineering work before August 2, 2026.

All cell citations trace to primary sources verified at the research stage (May 24, 2026). EU AI Act article numbers reference artificialintelligenceact.eu; GDPR article numbers reference gdpr-info.eu; NIST subcategory IDs reference NIST AI RMF 1.0.

Three distinct requirements converge on agent logging architecture. Understanding them together — rather than satisfying each independently — prevents the common mistake of building three separate logging systems.

EU AI Act Article 12 (lifetime auto-logging).The “over the lifetime of the system” clause is architecturally significant: it means your logging infrastructure must survive model updates, redeployments, and infrastructure migrations. A logging system that resets on redeploy does not satisfy Article 12. The practical interpretation: use an append-only, immutable log store (not a rotating buffer) with a retention policy that starts at the system’s first deployment and runs until decommission, with Article 26(6)’s 6-month deployer-retention floor as the minimum.

EU AI Act Article 26(6) (6-month deployer retention).Deployers must keep auto-generated logs “for a period appropriate to the intended purpose … of at least six months.” For agents deployed in regulated sectors, sector-specific laws may require longer retention. Financial services (MiFID II, DORA) and healthcare (MDR) both impose 5–10-year retention floors that supersede the Article 26(6) 6-month floor.

OWASP LLM06: Excessive Agency. OWASP’s LLM Top 10 for 2025 defines Excessive Agency as over-functionality (the agent has access to more tools than its current task requires), over-permissions (the agent’s tool access exceeds what a human operator in the same role would have), and over-autonomy (the agent takes consequential actions without human sign-off). The logging implication: every tool call must be logged with the permission context at the time of invocation, not just the fact of the call. This enables post-incident analysis of whether the agent was operating within its authorized permission boundary.

The unified architecture that satisfies all three: an append-only, structured event log capturing session start/end, input data references (not the data itself, to avoid creating new GDPR processing activities), all inference requests with model ID and timestamp, all tool invocations with tool name and permission level, all output events, and all human override or sign-off events. Log entries should be cryptographically timestamped and stored in a system where deployer-level access cannot modify historical records.

For the detailed engineering patterns behind this architecture, see our post on audit trail design patterns that satisfy Article 12, which covers the seven implementation patterns in detail including the schema design for structured agent event logs.

US state AI legislation is in active flux. Two laws warrant specific attention for agent deployments: NYC Local Law 144, which is already in enforcement, and the Colorado AI Act, which has been through two statutory postponements and a federal court stay since its original passage.

NYC Local Law 144 (Automated Employment Decision Tools). In enforcement since July 5, 2023. Applies to employers and employment agencies using automated tools that make or substantially assist in employment decisions (hiring, promotion) for NYC-based jobs. Requirements: annual independent bias audit, public summary of the audit, 10-day candidate notice before the tool is used. Penalties: $500–$1,500 per day per violation from the NYC Department of Consumer and Worker Protection. If your agent assists HR workflows for NYC-based roles, this law applies to you today.

Colorado AI Act (SB 24-205) — timeline disambiguation.The original Colorado AI Act was signed in May 2024 with an effective date of February 1, 2026. That date is cited widely — and it is wrong. Governor Polis signed SB 25B-004 on August 28, 2025, moving the effective date to June 30, 2026. A federal magistrate then stayed enforcement on April 27, 2026. Replacement legislation SB 189 passed both Colorado chambers May 7–9, 2026 with a narrower scope focused on developer transparency and algorithmic impact disclosure, replacing the broader developer-deployer liability framework of the original SB 24-205.

Any source citing the Colorado AI Act as effective “February 1, 2026” is citing a date that was statutorily postponed before it arrived. The correct framing as of May 23, 2026: Colorado AI Act enforcement is stayed pending the outcome of SB 189, which is expected to be signed into law in June 2026 with a revised scope and new effective date.

For the broader US governance picture, see our per-risk-tier EU AI Act compliance checklist and our deep-dive on RBAC patterns for agent access control, which covers the technical implementation of the least-privilege controls that both NYC LL 144 and EU AI Act Article 14 require.

August 2, 2026 is the activation date for the EU AI Act’s high-risk obligations. This is not speculative — it is the 24-month anniversary of the regulation’s August 1, 2024 entry into force, hardcoded in Article 113. Seventy-one days from publication is a tight but workable window if teams start immediately. The following plan is sequenced by dependency: infrastructure changes (logging, access control) must precede documentation changes, which must precede third-party agreements.

For a complete implementation template across the 90-day window, see our 30-60-90 day governance rollout plan. For the SOC 2 controls side of the program, see our SOC 2 controls mapped to agent architectures. For the EU AI Act side, see our EU AI Act compliance guide for European businesses. And for the ROI case you need to make to your board to fund this work, see our enterprise AI agent ROI calculator and this week’s agentic AI review for the regulatory context.