Loading
Loading
3366 Members
Join Permit's SlackQuick answer: EU AI Act Article 12 requires high-risk AI systems to technically support automatic event logging over their lifetime. Use it as a design target when your agent is high-risk or takes actions with side effects. Don't treat it as binding for every chatbot or internal assistant: systems that are not high-risk fall outside Article 12, and ISO 42001 alignment alone does not make you AI Act compliant.
EU AI Act Article 12 requires high-risk AI systems to support automatic recording of events (logs) over the system's lifetime. That record-keeping duty does not apply to every AI agent, but it is still the right design target for agent authorization: if an agent can take side effects, you need logs that show what happened and why it was allowed.
ISO 42001 sits alongside that as the AI governance management-system standard: event logging at least while the AI system is in use. For the broader governance picture, see AI identity governance best practices and Permit's AI compliance hub. Together they push the same engineering habit: capture authorization evidence at the tool-call boundary, not only model telemetry. (This post is not legal advice. Article 12 is scoped to high-risk systems, so check whether your system qualifies before assuming these obligations apply.)
The official legal text is Regulation (EU) 2024/1689, the AI Act, available on EUR-Lex. A readable version of Article 12 is also available at artificialintelligenceact.eu/article/12.
The European Commission's AI Act Service Desk publishes Article 12(1) as follows:
High-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system.
Source: Article 12: Record-keeping, EU AI Act Service Desk (European Commission)
In careful summary, Article 12 says that high-risk AI systems shall technically allow for the automatic recording of events, meaning logs, over the lifetime of the system.
Those logs must enable the recording of events relevant for:
Article 12 also includes additional minimum logging requirements for certain remote biometric identification systems referred to in Annex III, point 1(a).
There are three important takeaways.
First, Article 12 is about technical capability. The system must be able to automatically record relevant events over its lifetime. This is not the same as an ad hoc debug log or a spreadsheet assembled after an incident.
Second, Article 12 connects logging to operational governance. The logs are there to support risk identification, post-market monitoring, and user monitoring obligations.
Third, for agentic systems, "events" should not be limited to model inputs and outputs. If an agent can invoke tools, the authorization decision before the tool call is one of the most important events in the system.
A model suggestion is not usually the side effect. The tool call is.
Article 12 applies to high-risk AI systems. It does not apply to all AI systems, all AI agents, or all MCP agents.
High-risk classification is determined under Articles 6 and the relevant annexes of the AI Act, including Annex I and Annex III. Examples can include certain AI uses in employment, creditworthiness, critical infrastructure safety components, certain biometric uses, education, law enforcement, migration, and access to essential private or public services, depending on the exact use case and classification criteria.
This distinction matters. An MCP client that lets an internal engineering assistant search documentation is not automatically high-risk. MCP is a protocol and integration pattern. It is not, by itself, a regulatory classification.
The classification turns on what the AI system does, where it is used, which decisions or recommendations it supports, and the legal category it falls into.
The applicability timeline has also changed. Per artificialintelligenceact.eu, Article 12 obligations are tied to the high-risk application dates: 2 December 2027 for high-risk systems under Annex III, and 2 August 2028 for high-risk systems under Annex I, with Digital Omnibus amendments reflected in the consolidated version as of 27/07/2026. Readers should check the current consolidated EUR-Lex text and not rely on secondary summaries alone.
So the compliance answer is precise:
That last point is where security teams should focus. The audit question will not be "was this an MCP call?" The audit question will be "can you prove what happened and why it was allowed?"
ISO/IEC 42001:2023 is an AI management system standard. The ISO page is here: ISO/IEC 42001:2023.
Annex A.6.2.8 requires the organization to determine at which AI system life-cycle phases event-log record keeping should be enabled, but at minimum when the AI system is in use.
That is a very practical control for agents.
It does not mean you must log every token forever. It means the organization needs to decide, document, and operate event-log record keeping across the relevant phases of the AI system life cycle, with runtime use as the minimum.
For agent systems, runtime use is where the risk concentrates:
If you only log model prompts and responses, you miss the control plane. If you only log application errors, you miss intent and authorization. If you only log SaaS API activity, you miss why the agent called the API in the first place.
The right traceability model connects all of these events with a common request ID, actor identity, policy decision, and resource context.
That is why authorization logs are so valuable: they are structured, deterministic, and tied to an explicit decision point.
On certification: ISO/IEC 42001 certification is issued by accredited certification bodies that audit your AI management system as a whole. The standard does not publish a verbatim list of log fields you must emit. What auditors look for is that you decided where logging is enabled (A.6.2.8 requires at least the in-use phase), documented that decision, and can show logs that actually support traceability, monitoring, and incident handling. Authorization decision logs at the tool-call boundary are strong evidence for that. They are not a certificate by themselves.
An agentic system should treat every meaningful tool call as an authorization event.
This applies whether the tool is exposed through MCP, a direct API integration, an internal service, a database query layer, a workflow engine, or a SaaS connector. The pattern is the same:
The authorization boundary should capture enough information to answer six questions:
A practical logging schema looks like this:
| Category | What to capture | Why it matters |
|---|---|---|
| Correlation | Request ID, session ID, trace ID, workflow ID | Reconstructs the full chain of events |
| Actor | Human user, service account, agent ID, agent instance, tenant | Establishes accountability |
| Delegation | "Agent acting on behalf of user X", impersonation context, approval chain | Separates user intent from agent execution |
| System context | Agent version, model identifier, prompt template version, tool registry version | Supports reproducibility and change analysis |
| Tool action | MCP server, tool name, API endpoint, method, operation | Identifies the actual side effect boundary |
| Resource | Object ID, customer ID, document ID, environment, data domain | Shows what was accessed or changed |
| Attributes | Region, purpose, data classification, risk tier, time, device, network context | Supports ABAC and audit review |
| Decision | Allow, deny, allow with approval, allow with constraints | Records the control result |
| Policy | Policy ID, policy version, bundle hash, rule matched, PDP version | Proves which policy was enforced |
| Obligations | Approval required, masking required, step-up authentication, read-only mode | Shows conditional controls |
| Inputs | Redacted parameters, hashes, size, sensitivity labels | Enables investigation without overexposing data |
| Output | Execution status, error code, result hash, changed fields | Connects authorization to actual outcome |
| Human review | Approver ID, approval time, justification, expiry | Proves human-in-the-loop control |
| Data distribution | Policy/data snapshot version, OPAL update timestamp if applicable | Shows what the PDP knew at decision time |
| Retention | Log classification, retention period, access control, tamper evidence | Makes logs usable for audit and forensics |
Do not treat this as a reason to collect sensitive data blindly. The goal is useful evidence, not maximal surveillance.
For many systems, you should log metadata, identifiers, classifications, hashes, and redacted parameters rather than raw prompts or raw data. Security leaders should align this with privacy, data minimization, retention, and access control requirements under GDPR and other applicable regimes.
The core design principle is simple: the log should let you replay the decision, not necessarily expose the entire content.
MCP makes tool use easier to standardize, which is good. It also makes it easier for agents to discover and invoke capabilities, which increases the importance of authorization.
For every MCP tool call with non-trivial access or side effects, capture:
The most important architectural point: do not rely on the agent to self-police.
The agent can propose. The policy layer decides. The tool gateway enforces.
That separation is essential because agents are probabilistic, while authorization should be deterministic. A model may misunderstand context, overgeneralize from prior examples, or be manipulated by prompt injection. Your authorization layer should not be a suggestion embedded in a prompt. It should be an external control plane that evaluates every sensitive action at runtime.
The AI Act sets a minimum retention floor for high-risk AI systems.
Providers (those who develop or place the system on the market): Article 19(1) requires providers to keep automatically generated logs "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, in particular in Union law on the protection of personal data." See Article 19.
Deployers (those who use the system under their authority): Article 26(6) applies the same six-month floor. Deployers shall keep logs "to the extent such logs are under their control, for a period appropriate to the intended purpose... of at least six months, unless provided otherwise in applicable Union or national law." See Article 26.
In both cases, "unless provided otherwise" means that other Union or national law (including data protection law) may require a different period, shorter or longer. Six months is the floor, not a ceiling.
Practically: for high-risk systems, design for at least six months of log retention. Align retention with privacy and data-minimization rules, and confirm against the current consolidated EUR-Lex text for your specific role and use case.
Even if your system is not high-risk under the AI Act, this logging model is still where the market is going.
Customers and auditors are already asking the same questions:
Retrofitting this later is painful. If agent actions are already spread across SaaS APIs, internal tools, scripts, queues, and workflow systems, there may be no single place to prove what happened. You end up with fragmented evidence and a weak control story.
Building the authorization boundary early gives you a cleaner architecture:
This is exactly how mature authorization systems already work for human and service access. Agents do not need a separate governance universe. They need to be added to the same authorization model, with additional context for delegation, autonomy, and tool use.
At Permit.io, we see authorization as the control plane for agentic systems.
The architecture we recommend is policy-as-code with a hybrid PDP model: keep policy management centralized, but enforce decisions close to the application, gateway, or service where latency, privacy, and availability matter. Policy and authorization data can be distributed to PDPs using OPAL, so decisions do not require shipping every sensitive authorization query to a remote SaaS service.
That matters for regulated systems because the log should show not only the final allow or deny, but also the policy and data snapshot used at decision time.
A Permit-style agent authorization flow looks like this:
You can start with the Permit documentation and the OPAL project to understand the policy distribution model behind this approach.
The compliance posture here is not "Permit makes you EU AI Act compliant." No vendor should claim that by itself. The real claim is more concrete: deterministic authorization, PDP decision logs, policy-as-code, MCP gateway enforcement, and approval flows give your security and GRC teams the evidence they will need when customers, auditors, or regulators ask how agent actions are controlled.
For the authorization-log evidence shape, see Why Was This Allowed? and Explainable Deny. (Those posts focus on evidence quality. Whether Article 12 applies to your system depends on its risk classification, not on the logging pattern alone.)
No. Article 12 applies to high-risk AI systems under the AI Act. High-risk classification depends on Articles 6 and Annexes I and III. Do not assume that every MCP agent or internal assistant is high-risk.
For high-risk systems, Article 12 requires technical support for automatic event logs over the system's lifetime, sufficient for risk identification, post-market monitoring, and operational oversight. Additional minimum fields apply for certain remote biometric identification systems. Read the official text on EUR-Lex and the readable Article 12 page at artificialintelligenceact.eu.
For high-risk AI systems, the AI Act sets a minimum retention period of at least six months. Article 19(1) requires this for providers, and Article 26(6) requires it for deployers (for logs under their control). Other Union or national law, including data protection law, may require a different period. Six months is the floor, not a ceiling. Plan for investigation, post-market monitoring, and audit needs, then confirm against the current Regulation text and guidance for your role and use case.
ISO 42001 does not mandate a fixed field list. You need a documented decision on which AI life-cycle phases have event logging (at minimum while the system is in use, per A.6.2.8), and logs that let you reconstruct system operation: who or what acted, on which data, with what outcome. For agents, authorization decisions at the tool call are the most useful records. Your certification body assesses whether the whole management system works, not a single log.
No. ISO/IEC 42001 is an AI management system standard. The EU AI Act is binding regulation. Aligning with ISO 42001 logging and governance practices can support your control design. It does not by itself make you AI Act compliant.
For agent systems, the authorization decision before a tool call is the key event. It connects identity, resource, policy, approval, and side effect in one deterministic record. See also AI Agent Audit Logs: The 12 Fields Auditors Expect and audit logs.
Co-Founder / CEO at Permit.io
