The EU AI Act entered application in stages through 2024 and 2025. By August 2026, the full compliance framework applies to all high-risk AI systems operating in EU markets — including systems deployed by non-EU organisations whose AI affects EU users. If you are deploying AI agents that touch European customers, employees, or regulated activities, the clock is running.
The good news is that the EU AI Act is more actionable than its reputation suggests. It is a long and complex document, but for AI agent operators, the core obligations concentrate in about four articles, one annex, and a handful of technical requirements. Understanding those clearly is the foundation for building a credible compliance programme.
What Makes an AI System "High-Risk"?
Before addressing the compliance requirements, it is essential to determine whether they apply to your specific deployment.
The EU AI Act creates a risk-based framework with four tiers: unacceptable risk (banned), high-risk (heavy obligations), limited risk (transparency requirements only), and minimal risk (no obligations). The tier that matters for most AI agent operators is high-risk.
Annex III of the AI Act lists the categories of AI systems that are automatically classified as high-risk. They include:
- AI systems used in critical infrastructure (energy, water, transport, finance)
- AI systems used in educational or vocational training contexts
- AI systems used in employment and workforce management (including automated hiring and performance evaluation)
- AI systems used to determine access to essential private and public services, including credit scoring
- AI systems used in law enforcement
- AI systems used in migration and border control
- AI systems used in the administration of justice
If your AI agents operate in any of these domains, you are subject to the full suite of high-risk requirements. This includes, but is not limited to: AI agents handling loan applications, insurance underwriting, trading decisions, HR screening, fraud detection, and healthcare diagnosis support.
The question of whether a specific AI agent deployment falls within Annex III is ultimately a legal determination. But the practical heuristic is: if the agent's outputs affect decisions about people's access to opportunities, services, or legal status, assume it is high-risk until you have legal advice saying otherwise.
Article 13: Transparency Requirements
Article 13 requires operators of high-risk AI systems to ensure that the system's design and functioning can be understood to a reasonable degree by users and affected individuals. This is the transparency requirement.
For AI agents, transparency obligations have two dimensions.
Technical transparency means the AI system must be documentable. You need to be able to describe what the system does, how it makes decisions, what data it uses, and what its known limitations are. This documentation must be kept up to date.
User-facing transparency means that people who are affected by the AI system's outputs must be informed that AI is involved. An AI agent that makes credit decisions cannot operate in a black box — affected applicants must be told that AI was involved and have a right to explanation.
Kakunin's audit trail supports both dimensions. Every agent action is logged with the agent's identity, the inputs it processed, and the decision it generated. This creates the technical documentation base that Article 13 requires. The human oversight capability — the ability to review, intervene, and explain any specific decision — is built into the audit trail architecture.
For a detailed mapping of Article 13 requirements to specific system capabilities, see the compliance concepts documentation.
Article 14: Human Oversight
Article 14 is arguably the most operationally significant requirement in the EU AI Act for AI agent operators. It requires that high-risk AI systems be designed to allow effective oversight by natural persons during the period in which the AI system is in use.
This requirement has two components.
Intervention capability: You must be able to stop or override the AI system at any time. This is not "we could stop it if we really needed to" — it requires that the stop capability is built into the system's normal operational architecture, tested, documented, and maintained. An AI agent for which the only way to stop it is to take down the server it runs on does not satisfy Article 14.
Monitoring capability: You must be able to identify when the AI system is not functioning as intended and respond appropriately. This directly links to the behavioural monitoring requirements we discussed in Behavioral Monitoring for AI Agents: The Compliance Layer.
Kakunin's auto-revocation capability is the technical implementation of Article 14's intervention requirement. The manual kill switch (POST /api/v1/agents/{id}/halt) allows immediate human-initiated halting of any agent. The automated revocation at risk score 0.85 is the system-level safeguard that Article 14 specifically contemplates: an automatic response when the monitoring system detects non-intended functioning.
The enforcement documentation covers the specific API calls and operational procedures for implementing Article 14 oversight capability.
Article 15: Accuracy, Robustness, and Cybersecurity
Article 15 requires that high-risk AI systems achieve appropriate levels of accuracy, robustness, and cybersecurity throughout their lifecycle. This is a broad requirement, but for AI agent operators, three specific implications stand out.
Accuracy monitoring: The system must be designed to enable ongoing monitoring of its accuracy. For AI agents, this means instrumenting the agent to capture outputs alongside the ground truth when available, and maintaining metrics on whether the agent's decisions are achieving the intended outcomes. An AI fraud detection agent, for example, should be tracking its false positive and false negative rates over time.
Adversarial robustness: The system must be able to withstand attempts to alter its functioning. For AI agents, this directly addresses prompt injection — the most significant active attack vector. An agent that can be manipulated into ignoring its instructions by embedding adversarial content in its inputs is not robust within the meaning of Article 15.
Cybersecurity: The system must implement appropriate cybersecurity measures. For AI agents, the minimum requirements include: encrypted communication, credential protection (KMS, not environment variables), audit logging, and access controls.
The cryptographic identity architecture that X.509 certificates provide is foundational to Article 15 cybersecurity compliance. An agent whose identity can be verified independently, whose private keys are stored in a hardware security module, and whose audit trail is cryptographically signed satisfies the core cybersecurity requirements at the identity layer.
See Why AI Agents Need X.509 Certificates, Not Just API Keys for the full architecture discussion.
Article 12: Logging and the WORM Requirement
Article 12 is the technical core of the EU AI Act for AI agent operators. It requires that high-risk AI systems automatically generate event logs throughout their operation, with sufficient detail to enable post-hoc monitoring of the system's functioning.
The word "automatically" is significant. Manual logging — someone on the team reviewing outputs and recording notable events — does not satisfy Article 12. The logging must happen at the system level, without requiring human initiation.
The phrase "post-hoc monitoring" sets a specificity requirement. The logs must be granular enough that, after the fact, you can reconstruct what the system was doing and why at any given moment. "The agent made 1,000 transactions today" is not sufficient. "Agent A processed transactions T-001 through T-1000, with inputs I-001 through I-1000, generating outputs O-001 through O-1000, all cryptographically signed with certificate serial 0x1234" is.
Article 12 also has a specific integrity requirement: logs must "have the appropriate level of integrity to ensure they cannot be manipulated." This is the WORM (Write Once, Read Many) requirement. Your audit log cannot be a database table where rows can be updated or deleted. It must be an append-only structure where historical entries are immutable after creation.
Kakunin's audit log is WORM-backed from the ground up. The database enforces immutability at the PostgreSQL rule level — audit_log_no_update and audit_log_no_delete rules prevent any modification of existing entries. This is not just a policy — it is enforced at the database layer, making it impossible to delete audit records even with full database credentials.
The compliance concepts documentation covers the specific technical implementation of the WORM audit log and its alignment with EU AI Act Article 12.
Annex III in Practice: A Sector-by-Sector View
To make the high-risk classification concrete, here is how it applies across the sectors where AI agents are most actively being deployed.
Financial services: AI agents involved in credit decisions, insurance underwriting, or investment recommendations fall under the "access to essential private and public services" category in Annex III. Trading agents may also fall under critical infrastructure depending on the scale of their market impact. MiCA compliance requirements for AI agents (Articles 61–75) overlap significantly with EU AI Act high-risk requirements — compliance with both is manageable with a shared infrastructure foundation.
Healthcare: AI agents involved in diagnostic support, treatment recommendations, or patient triage clearly fall under critical infrastructure or essential services. Healthcare AI agents deployed in EU settings require full Article 13–15 compliance plus specific clinical validation requirements under the Medical Devices Regulation.
HR and recruitment: AI agents that screen CVs, score interview performance, or recommend candidates for rejection or advancement are explicitly listed in Annex III. This is one of the most heavily enforced categories — several EU member states have already initiated investigations of AI-powered recruitment screening.
Fraud detection and AML: Agents that make or influence decisions about whether to flag a transaction as suspicious, or whether to approve or deny a payment, are likely in scope under critical infrastructure or essential services.
Customer service with decision authority: An AI agent that can approve or deny a refund, apply or remove an account restriction, or make binding offers to customers is acting in a way that affects "access to essential private and public services" for those customers.
The EU AI Act text remains the definitive source, but the sector-by-sector analysis above reflects the current consensus interpretation among EU AI Act compliance practitioners.
Building Your Compliance Roadmap
A practical EU AI Act compliance roadmap for AI agent operators has five phases.
Phase 1: Inventory and classify (1–2 weeks). List all AI agents in production and development. For each, determine whether it operates in an Annex III category. Be conservative — if uncertain, treat as high-risk. Document the inventory and classification reasoning.
Phase 2: Gap assessment (2–4 weeks). For each high-risk agent, assess current compliance state against Articles 12, 13, 14, and 15. The compliance checklist provides a structured format for this assessment.
Phase 3: Infrastructure implementation (4–8 weeks). Implement the technical requirements: cryptographic identity (X.509 certificates), behavioural monitoring (event streaming and risk scoring), intervention capability (manual and automated revocation), and WORM audit logging.
Phase 4: Documentation (2–4 weeks). Create and maintain the technical documentation that Article 13 requires. Map your compliance posture to specific system capabilities and audit evidence. The documentation should be structured so that a regulator or auditor can follow the compliance argument without extensive explanation from you.
Phase 5: Ongoing operation (continuous). Maintain the monitoring systems, review alerts, manage certificate renewals, update documentation when systems change, and respond promptly to regulator inquiries.
For organisations currently in Phase 1 or 2, the EU AI Act conformance assessment guidance from ENISA provides a useful reference for the technical security requirements underlying Articles 12–15.
The Compliance Officer's Toolkit
For compliance officers specifically tasked with EU AI Act readiness, the most useful practical tools are:
1. A structured inventory of AI agents — which agents, what they do, which Annex III categories they potentially fall under
2. A gap analysis framework — mapping current capabilities against Article 12, 13, 14, and 15 requirements
3. A monitoring dashboard — real-time visibility into agent risk scores and any alerts generated
4. An audit trail export capability — the ability to produce a formatted compliance report for any agent on demand
5. A revocation runbook — documented procedures for each revocation scenario (auto, manual, regulatory)
Kakunin provides the technical infrastructure for items 2–5. The compliance officer page is designed specifically to address the compliance officer's workflow, from ongoing monitoring through regulatory inquiry response.
The EU AI Act compliance journey is not a sprint. It is an ongoing operational posture that requires sustained investment in technical infrastructure and institutional processes. But the organisations that build this infrastructure systematically — rather than in response to enforcement action — will be better positioned for the regulatory landscape that is now taking shape across the EU.
---
Kakunin maps to EU AI Act Articles 12, 13, 14, and 15 with cryptographic agent identity, WORM audit logging, real-time monitoring, and auto-revocation. Start with the compliance checklist or explore the for-compliance-officers overview.