A step-by-step guide to making AI agents compliant with the EU AI Act, covering risk classification, Article 12 logging, human oversight, and post-market monitoring, with a hands-on implementation using the open-source ZizkaDB audit trail database.
Most AI compliance advice was written for models: an input goes in, a prediction comes out, and you document it. Agents don't work that way. They plan, call tools, read and write memory, hand work to other agents, and act in the real world. When a regulator or a customer's auditor asks "why did your system do that?", the answer is spread across many steps that no single log line explains.
This guide walks through what the EU AI Act expects from teams building or deploying agents, in the order you'd tackle it. It also shows how to build the runtime evidence layer with ZizkaDB, an open-source audit trail database for AI agents.
The timeline: deferred, not cancelled``
Date What applies
- Feb 2, 2025 Prohibited practices
- Aug 2, 2025 General-purpose AI (GPAI) model obligations
- Aug 2, 2026 Transparency duties under Article 50
- Dec 2, 2027 Standalone high-risk systems (Annex III), after the Digital Omnibus deferral
- Aug 2, 2028 High-risk systems embedded in regulated products (Annex I)
The Digital Omnibus moved the high-risk dates back but didn't change what the obligations are. Article 12 logging, human oversight, and post-market monitoring are still coming. Logging is the one obligation you can't fix retroactively, because you can't produce records of decisions that were never captured.
Penalties are real: up to €35 million or 7% of worldwide turnover for prohibited practices, and up to €15 million or 3% for breaches of most other obligations, including those for high-risk systems. Verify these dates against the final published text, since this area is still moving.
Step 1: Work out what your agent is under the Act
"AI agent" isn't a legal category. The Act cares about what your system does and who it affects.
Your role. If you build an agent and place it on the market or put it into service under your name, you're a provider. If you use someone else's agent in your business, you're a deployer. Both carry logging duties: providers under Article 19, deployers under Article 26(6). Many companies are both.
Your risk tier.
Prohibited: manipulative techniques, social scoring, and similar practices.
High-risk: systems used in areas like employment, credit and essential services, education, law enforcement, migration, and critical infrastructure.
Limited-risk: systems that interact with people or generate content, which triggers Article 50 transparency duties.
Minimal-risk: everything else, with no specific obligations.
The agent-specific wrinkle. An agent's capabilities can grow without anyone rewriting its core code. Add a tool, widen a permission, or connect a new data source, and its effective purpose may move from "drafts emails" to "screens candidates." Treat every change to tools, permissions, and model versions as a potential compliance event, and record it.
Step 2: Map obligations to evidence
For high-risk systems, the core requirements look like this:
Article What it asks What an auditor will want to see
9 Risk management system Documented risks, mitigations, testing results
10 Data governance Data provenance, quality checks, bias examination
11 Technical documentation Architecture, capabilities, limitations, change history
12 Record-keeping Automatic, lifetime event logs
13 Transparency to deployers Clear instructions for use
14 Human oversight Proof humans can understand, intervene, and stop the system
15 Accuracy, robustness, cybersecurity Test results, resilience measures, integrity controls
72 Post-market monitoring Ongoing performance and behavior data
73 Serious incident reporting Ability to reconstruct and report incidents
Articles 9, 10, 11, and 13 are mainly documents you write once and maintain. Articles 12, 14, 72, and 73 depend on runtime evidence: records generated while the agent operates. For agents, that second group is where most teams are underprepared.
Step 3: Lay the paperwork foundation
Before the runtime layer, get the static documents right and keep them alive:
A risk register that names agent-specific hazards: tool misuse, prompt injection, runaway loops, silent behavioral drift.
Data governance records for training, fine-tuning, and retrieval sources.
Technical documentation covering the agent's tools, permissions, and model versions, with a change log.
A quality management process that ties releases to testing.
These are necessary but not sufficient. A perfect risk register won't help when an auditor asks what your agent did for a specific user on a specific Tuesday.
Step 4: Solve record-keeping, the hard part for agents
Article 12 requires high-risk systems to technically allow automatic recording of events over the system's lifetime. The logs must help identify situations that may create risk or involve a substantial modification, support post-market monitoring, and support the deployer's monitoring of operation. Deployers must keep the logs under their control for at least six months, and sector rules may require longer.
Why ordinary application logs fall short for agents:
Non-determinism. The same input can produce different action sequences, so you can't reproduce behavior by re-running it.
Multi-step chains. A decision emerges from planning, tool calls, and intermediate results. A "final answer" log hides the path.
State. What the agent knew at the moment of a decision often matters more than the decision itself.
Handoffs. Responsibility passes between agents, and the trail must follow it.
Observability tools tell you how a system performed. An audit trail has to answer a different question: why did this decision happen, and who was responsible? That requires explicit cause-and-effect links between steps, not just timing data.
What to capture for each session:
Agent identity, plus the model, prompt, and tool configuration in effect
Inputs received and the context available
Each planning or reasoning step, at a level you can defend
Every tool call with arguments and results
Every output or action, and its recipient
Human interventions: approvals, overrides, stops, and who performed them
Configuration changes such as new tools, changed permissions, or model swaps
Three design tensions to resolve deliberately:
Integrity. Logs are only credible if you can show they weren't altered after the fact. The Act doesn't prescribe a mechanism, but tamper-evidence, such as checksummed, ordered events, is what turns a log into evidence.
Retention. Keep logs long enough to meet the six-month floor and your sector rules, but not indefinitely by default. GDPR's storage limitation still applies.
Privacy. Article 12 doesn't mean "log every personal detail." Use pseudonymous references instead of raw identifiers and keep sensitive payloads out of event data where you can. This keeps erasure requests rare and manageable.
Step 5: Implement the audit layer with ZizkaDB
ZizkaDB is an open-source, self-hosted audit trail database for AI agents. Its central idea fits Article 12 well. Every agent step is logged with a parent_id pointing to the step that caused it, so you can pick any action and walk back to its root cause with db.why(). That causal chain is what turns a pile of logs into an explanation.
The open-source repo contains the API, a tenant dashboard, the SDKs, and the MCP server. Data lives in your own Postgres, so you decide where it's hosted. That matters for teams with EU data-residency requirements.
Get it running
You need Docker. The first image pull can take 5 to 10 minutes.
bash
curl -fsSL https://raw.githubusercontent.com/Zizka-ai/ZizkaDB/main/scripts/quickstart-remote.sh | bash
As with any script piped into a shell, read it before you run it. Or self-host from a clone:
bash
git clone https://github.com/Zizka-ai/ZizkaDB.git && cd ZizkaDB
bash scripts/setup-local.sh
You get the API at localhost:8000, the dashboard at localhost:3001/login, and Swagger docs at localhost:8000/swagger. The local setup uses a built-in dev key, so treat that as a local-testing convenience and configure your own credentials for anything real, following the self-hosting guide in the repo.
Log decisions with causal links
Here's the pattern applied to a high-risk scenario: an agent screening credit applications, which falls under the Annex III creditworthiness category. The event names and payload fields are illustrative. The agent, event, data, and parent_id parameters are the ones the repo documents.
`python
python
import asyncio
from zizkadb import ZizkaDB
async def main():
async with ZizkaDB(host="http://localhost:8000") as db:
request = await db.log(
agent="credit-screening-agent",
event="user_message",
data={"applicant_ref": "app_7f3a", "task": "assess application"},
)
lookup = await db.log(
agent="credit-screening-agent",
event="tool_call",
data={"tool": "credit_lookup", "applicant_ref": "app_7f3a"},
parent_id=request.event_id,
)
decision = await db.log(
agent="credit-screening-agent",
event="llm_response",
data={"model": "gpt-4o", "prompt_version": "v14", "recommendation": "refer_to_human"},
parent_id=lookup.event_id,
)
approval = await db.log(
agent="credit-screening-agent",
event="human_review",
data={"reviewer_ref": "rev_212", "outcome": "approved_with_conditions"},
parent_id=decision.event_id,
)
(await db.why(approval.event_id)).print()
asyncio.run(main())
`
Notice what this gives you.
The applicant appears only as a pseudonymous reference, the model and prompt version are recorded with the decision, and the human review is a first-class event linked to the recommendation it followed. Running db.why() on the approval walks the whole chain back to the original request. You can do the same from the terminal with zizkadb why , or in the dashboard by opening an event under Activity and choosing the Why? (causal) tab.
Native integrations
You don't have to hand-write logging for every framework. ZizkaDB ships packages for the stacks agent teams actually use:
Stack Install Notes
Python pip install zizkadb-sdk Core async SDK
TypeScript npm install zizkadb-sdk Same package name on npm
LangChain pip install zizkadb-langchain Guide
CrewAI pip install zizkadb-crewai Guide
LiveKit (voice) pip install zizkadb-livekit One call becomes one session; transcript only, no audio stored (guide)
MCP uvx zizkadb-mcp For MCP clients such as Cursor (README)
Any other agent REST API Swagger docs on your instance
The transcript-only design of the LiveKit integration is useful for compliance. You get an auditable record of what a voice agent said and did without retaining audio you'd then have to govern.
How the features map to the Act
Requirement ZizkaDB capability
Art. 12: automatic recording SDKs, framework packages, MCP, and REST let agents write events as they run
Integrity of records Tamper-evident, checksum-backed decision logs
Art. 73: incident reconstruction db.why() and session replay walk any action back to its cause
"What did it know at that moment?" db.at() reconstructs what the agent knew at a given timestamp
Art. 72: post-market monitoring db.baseline() detects when behavior drifts from past sessions
Finding relevant history db.search() runs semantic search over agent history
GDPR erasure requests db.forget() erases by metadata filter
Deployment notes
Licensing. The repo is AGPL-3.0, and the MCP server is MIT. Running it unmodified for your own agents is generally straightforward. If you modify it and offer it over a network, AGPL's network clause applies, so involve counsel.
Telemetry. You can turn off ZizkaDB's telemetry with ZIZKADB_TELEMETRY=false, which compliance-minded teams will want to do.
Erasure versus integrity. db.forget() handles GDPR erasure, but deleting from a tamper-evident record deserves a deliberate test. Keep personal data out of payloads by design, then verify in your own environment how erasure interacts with your integrity requirements.
Managed option. If you'd rather not run infrastructure, there's a hosted version at db.zizka.ai.
What ZizkaDB doesn't do
It doesn't classify your system, write your risk management file, run your data governance, or complete a conformity assessment. It supports record-keeping and monitoring, the parts of compliance that depend on runtime evidence. Treat it as one component of a compliance program, not a substitute for one.
A practical rollout
Define your event schema first, using the capture list from Step 4. Decide what's logged in full, what's pseudonymized, and what's stored by reference.
Instrument your highest-risk agent end to end, not your easiest one.
Log configuration changes as events so new tools, permissions, and model swaps sit in the same trail as decisions.
Set retention and access rules, and restrict who can read the audit trail itself.
Establish a baseline and use drift alerts as inputs to your risk register.
Run an audit drill (Step 8).
Step 6: Design human oversight you can prove
Article 14 requires that people can understand what the system is doing, notice when it misbehaves, avoid over-trusting its output, override or disregard it, and stop it.
For agents, that means real control points: approval gates before high-impact or irreversible actions, a working stop mechanism, and interfaces that show reviewers why the agent proposes something, not just what.
"We have a human in the loop" isn't evidence. A record of who reviewed what, when, and what they decided is. In the example above, the human_review event is linked to the recommendation it followed, so an auditor sees the agent's action and the human's response in one causal chain.
Step 7: Monitor after deployment and be ready to report
Providers of high-risk systems need post-market monitoring (Article 72) and must report serious incidents (Article 73). Agent behavior can shift when a model provider updates a model, when retrieved data changes, or when users find new ways to use the system.
Track behavior, not just uptime. Compare action patterns and outcomes against a baseline. In ZizkaDB, that's what db.baseline() is for.
Have an incident playbook. Define what counts as a serious incident, who decides, and how fast you can assemble the facts. Reconstruction speed depends on record quality.
Feed findings back. Monitoring results should update your risk file and documentation.
Step 8: Run an audit drill
The best test of your setup is simulating the audit. Pick a random session from three months ago and try to answer:
What was the agent asked, and what context did it have? (db.at())
What steps did it take, and why? (db.why())
Which model, prompt, and configuration was live at the time?
Did a human review or override anything?
Can you prove the record hasn't changed since?
If any answer takes more than an hour, or comes from someone's memory instead of a record, you've found a gap while it's still cheap to fix.
Common mistakes
Logging outputs only. Auditors care about the path to a decision.
Treating compliance as documentation. Documents describe intent. Runtime records prove behavior.
Ignoring configuration changes. A new tool can change your risk class overnight.
Logging too much personal data. Over-collection creates a GDPR problem while solving an AI Act one.
Waiting for the deadline. You can't backfill records. The trail starts when you start logging.
Overclaiming. Calling your system "compliant" before conformity assessment is a risk in itself. Say "supports" until you can prove "meets."
Compliance checklist
Role (provider, deployer, or both) and risk tier documented
Agent capabilities, tools, and permissions inventoried
Risk register includes agent-specific hazards
Data governance and technical documentation maintained
Automatic event recording with causal links between steps
Tamper-evidence, retention schedule, and access controls defined
Personal data minimized or pseudonymized in logs
Human oversight controls built and their use recorded
Post-market monitoring with drift detection running
Incident playbook written and tested
Audit drill completed and gaps closed
Conclusion
Making an AI agent EU AI Act compliant comes down to building a system that can explain itself after the fact: what it did, why, under whose oversight, and with what integrity guarantees. The paperwork matters, but the parts that depend on runtime evidence are where agents differ from traditional software, and where retrofitting is impossible.
Start with classification and documentation, then put an audit layer under your highest-risk agent now. You can clone ZizkaDB from GitHub, connect it through the Python or TypeScript SDK, LangChain, CrewAI, LiveKit, or MCP, and start recording decisions today, so that when the obligations arrive, the records already exist.
This article is general information, not legal advice.
Top comments (0)