The EU AI Act entered into force on 1 August 2024 and begins applying in full from August 2026. For organisations deploying autonomous AI agents — trading bots, compliance assistants, document processors, customer support agents — it creates concrete technical obligations that most engineering teams have not yet operationalised.
This whitepaper maps the Act's requirements onto the specific implementation patterns that matter for AI agent operators: audit logging, identity management, human oversight hooks, risk classification, and incident reporting.
What Counts as a High-Risk AI System
The EU AI Act creates a tiered risk structure. Most autonomous agents deployed in regulated sectors fall into the high-risk category via Annex III, which lists eight domains:
- Biometric identification and categorisation
- Critical infrastructure management
- Education and vocational training
- Employment and worker management
- Access to essential private and public services
- Law enforcement
- Migration and border control
- Administration of justice and democratic processes
The eighth category is the broadest. But the one operators in financial services must focus on is the general provision in Article 6(2) read with Annex III point 5(b): AI systems that make or materially influence decisions about access to financial services or their terms.
An autonomous trading agent that executes transactions, adjusts positions, or manages a portfolio on behalf of a client qualifies. So does an AI credit decisioning assistant, an automated AML screening tool, or a document review agent used in underwriting.
GPAI Models and Foundation Model Obligations
If your agent is built on a general-purpose AI model (GPAI) with systemic risk — defined in Article 51 as models trained with more than 10^25 FLOPs — additional obligations apply to the model provider. For operators using hosted models via API (GPT-4, Claude, Gemini), the model provider carries primary GPAI obligations. However, operators retain obligations for their high-risk use case deployment under Article 16.
The Six Technical Obligations That Matter Most
1. Logging and Audit Trail (Article 12)
Article 12 requires high-risk AI systems to automatically log events throughout operation, to the extent necessary to identify causes of problems and ensure regulatory oversight.
The minimum log content includes:
- System start and stop timestamps
- Input data where technically feasible to store
- Verification against reference databases
- Identity of persons who accessed the system
- The sequence of decisions made
In practice for an AI agent, this means every action the agent takes must be logged with a timestamp, the agent's identity, the input that triggered the action, and the output or decision. The log must be retained for the period specified in the Act — a minimum of five years for high-risk AI under Article 12(1)(c), cross-referenced with sector-specific retention requirements (EMIR, MiFID II, DORA) which may require longer.
Implementing this with Kakunin means every call to your agent's behavioural event endpoint (POST /api/v1/events) creates an immutable audit record. The S3 WORM bucket enforces seven-year retention with Object Lock Compliance mode, which satisfies both the Act's five-year minimum and MiFID II's seven-year requirement simultaneously.
2. Technical Documentation (Article 11)
Before deploying a high-risk AI system, operators must prepare technical documentation demonstrating compliance. This documentation must be kept updated throughout the system's lifecycle.
The documentation must include, per Annex IV:
- A general description of the AI system including its intended purpose
- A description of the elements of the system and the development process
- The risk management documentation (Article 9)
- Description of the training, validation, and testing procedures
- Post-market monitoring plan
The compliance report generated by Kakunin (GET /api/v1/reports) provides a machine-readable summary of an agent's certification status, behavioural risk profile, and certificate chain. It is designed to slot into Article 11 documentation as the technical evidence layer.
3. Risk Management System (Article 9)
Article 9 requires operators of high-risk AI systems to implement a risk management system — a continuous, iterative process that runs throughout the AI system's lifecycle.
The risk management system must:
- Identify and analyse known and foreseeable risks
- Estimate and evaluate risks that may emerge
- Adopt appropriate risk management measures
- Test the system against the defined risk mitigation measures
Risk management is not a one-time checklist. It is a live process. For AI agents, this means ongoing behavioural monitoring that can detect when the system's risk profile has drifted outside its registered operating parameters.
Kakunin's risk scoring engine calculates a composite risk score across five dimensions on every behavioural event: volume deviation, distribution shift, novelty score, velocity anomaly, and authentication failure rate. When the rolling 30-day score exceeds 0.85, the certificate is automatically revoked — implementing the "circuit breaker" required by Article 9(2)(d).
4. Human Oversight (Article 14)
Article 14 is the provision most operators underestimate. It requires that high-risk AI systems be designed to enable effective human oversight during their operation. This means the system must be capable of being interrupted, stopped, or overridden by a human operator.
Three specific requirements:
1. The AI system must be interpretable to the degree necessary for oversight
2. Natural persons must be able to monitor the system's operation in real time
3. Natural persons must be able to intervene through a stop command or override
The certificate.revoke endpoint (POST /api/v1/certificates/{id}/revoke) is the operational implementation of Article 14(4)(e): the ability to decide not to use the AI system in certain situations. When an operator calls revoke, the certificate is invalidated within 60 seconds across the CDN-distributed verification layer, and all subsequent requests from that agent return 403.
For real-time monitoring, the SSE event stream (GET /api/v1/agents/{id}/events/stream) provides a live feed of behavioural events that triggers no additional latency on the agent's operation — it reads from the existing event store.
5. Accuracy, Robustness, and Cybersecurity (Article 15)
Article 15 requires high-risk AI systems to achieve appropriate levels of accuracy and be resilient against attempts by third parties to alter their use or performance.
For AI agents operating in financial markets, the cybersecurity requirement is particularly important. An agent operating under a compromised identity — whether through API key theft, session hijacking, or prompt injection — creates both financial and regulatory risk.
X.509 certificates provide the cryptographic binding between agent identity and authorised scope. Unlike API keys, which can be exfiltrated and replayed without detection, a certificate-based identity:
- Cannot be forged without access to the private key, which never leaves AWS KMS
- Carries scope constraints in the
financial_scopeextension (permitted instruments, position limits, venue restrictions) - Expires automatically after 365 days, forcing annual renewal and review
- Can be revoked within 60 seconds globally with no coordination required from the agent
6. Conformity Assessment (Article 43)
For Annex III high-risk systems, conformity assessment is required before market placement. In most categories, operators can self-assess using the internal control procedure defined in Annex VI. For biometric identification systems, third-party assessment is mandatory.
Self-assessment requires demonstrating compliance with Articles 9–15 via the technical documentation produced under Article 11. The Kakunin compliance report provides structured evidence for each of the Articles above.
Registration in the EU Database (Article 49)
Operators of high-risk AI systems must register their systems in the EU AI Act database maintained by the Commission before deploying them. Registration requires:
- Name and contact details of the provider
- Trade name and commercial registration number
- Category of the AI system (Annex III reference)
- Purpose and intended use
- Status of the conformity assessment
Registration is distinct from certification. It is a notification to the regulator that a high-risk system is in operation. Kakunin's POST /api/v1/agents endpoint creates the technical record that maps to the registration entry — the name, model, version, and model_hash fields provide the minimum technical fingerprint required.
What Applies to GPAI-Powered Agents Under MiCA
For agents operating in crypto-asset markets, MiCA adds a parallel compliance layer. Where the EU AI Act focuses on the AI system's properties, MiCA Article 72 focuses on what the agent does — specifically its market conduct and record-keeping obligations.
MiCA Article 72(1) requires CASPs using algorithmic trading to have systems and controls that ensure the trading systems cannot create or contribute to disorderly trading conditions. Article 72(2) requires records of algorithmic trading strategies, parameters, and limits.
The combination of X.509 certificate scope constraints (enforcing permitted_instruments and position limits) and behavioural event logging (recording every trade decision with its input context) addresses both requirements from a single integration point.
Implementation Roadmap
A pragmatic path to EU AI Act compliance for AI agent operators:
Phase 1: Identity and Audit Foundation (Week 1–2)
- Register all production agents via
POST /api/v1/agentswith accuratemodel,version, andmodel_hash - Issue X.509 certificates via
POST /api/v1/agents/{id}/certify - Instrument agents to emit behavioural events on every decision via
POST /api/v1/events - Verify audit log retention is writing to WORM storage
Phase 2: Risk Management System (Week 3–4)
- Configure risk score thresholds appropriate to your risk appetite
- Implement SSE monitoring stream for real-time oversight (
GET /api/v1/agents/{id}/events/stream) - Test the human override path: verify
certificate.revokepropagates within SLA - Set up webhook handler for
certificate.revokedandrisk.alertevents
Phase 3: Technical Documentation (Week 5–6)
- Generate baseline compliance report for each agent (
GET /api/v1/reports) - Compile Article 11 Annex IV documentation using compliance reports as the technical evidence layer
- Establish a recurring compliance review process tied to certificate renewal (annual)
Phase 4: Conformity Assessment and Registration (Week 7–8)
- Complete internal control procedure self-assessment against Articles 9–15
- Register high-risk AI systems in the EU database
- Retain self-assessment documentation in immutable audit storage
The Cost of Non-Compliance
Under Article 99, the Act establishes three tiers of administrative fines:
- €35 million or 7% of global annual turnover — for prohibited AI practices
- €15 million or 3% of global annual turnover — for violations of high-risk AI obligations (Articles 9–15, 49)
- €7.5 million or 1.5% of global annual turnover — for providing incorrect information to authorities
For a pre-revenue startup deploying AI agents in a regulated context, the reputational damage and enforcement action from even a minor violation during the Act's initial enforcement period would be material. The cost of compliance infrastructure — at the scale Kakunin targets — is a rounding error against that exposure.
Conclusion
The EU AI Act creates a concrete set of technical obligations for AI agent operators. The six obligations that matter most — logging, technical documentation, risk management, human oversight, cybersecurity, and conformity assessment — map directly to the infrastructure that Kakunin provides.
The window to implement before the Act applies in full is short. Operators who treat compliance as an engineering problem — and instrument their agents now — will be in a materially stronger position with regulators, insurers, and enterprise customers than those who wait for guidance.