This is the next how-to guide in the series. The earlier guides covered individual functions, such as lineage, replay, drift, at(), forget(), and SHA-256 checksums. This one puts them together around a single goal: being ready when an auditor, regulator, or enterprise customer asks you to prove how your AI system behaves. It is written for CTOs, heads of compliance, and vertical AI teams who would rather prepare now than scramble later.
Before you start: what an audit will actually ask
Auditors rarely ask whether you have an AI system that works. They ask for evidence. In practice the questions fall into five groups:
What did the system do, and can you show the record? (traceability and logging, Article 12)
Can you explain why it did it? (transparency toward deployers, Article 13)
Was a human able to oversee and intervene? (human oversight, Article 14)
Can you show the system’s behavior over time, and how you monitor it? (post market monitoring, Articles 72 and 79)
Is the record reliable, secure, and handled lawfully? (Article 15 and GDPR)
Whether your system falls under the high risk rules depends on its use case, for example creditworthiness assessment. Confirm that classification with legal counsel. The steps below are useful either way, because the evidence they produce is what most audits and customer security reviews ask for.
Step 1: Inventory your agents and classify them
List every agent in production or planned, with its purpose, the data it touches, and who is affected by its decisions. Mark which ones may be high risk under the Act. Start the rest of this guide with the highest risk agent first, not all of them at once.
Step 2: Turn on continuous event logging
Connect the agent to ZizkaDB so every event is captured as it happens: user messages, decisions, LLM calls, tool invocations, and responses. This is the foundation for Article 12 style traceability.
Check completeness before moving on. Run test sessions and confirm each one can be reconstructed from the first message to the final response. Gaps in capture become gaps in your evidence, and they cannot be filled in later.
Step 3: Set retention per tenant
Decide how long each category of record must be kept, based on legal requirements and your own policy, and configure retention per tenant. Do this before the first audit, not during it. Auditors often look back six months or more, so a retention period that is too short quietly destroys evidence you may need.
Step 4: Secure the record
Evidence is only useful if it is trustworthy. Set up tenant isolation and scoped API keys so each agent and team can only reach its own records. Every ZizkaDB event carries a SHA-256 checksum, so you can show that a record is unchanged since it was written. Where your requirements are strict, choose self hosted or VPC deployment, and consider exporting checksums to storage your administrators cannot modify.
Be precise about the claim you make. Checksums make tampering detectable, not impossible, and they work best alongside access control and monitoring.
Step 5: Build the explanation workflow
For any contested or sampled decision, your team should be able to follow the same short procedure:
Open the session with Session Replay and review the full sequence in order.
Use why() on the key step to see the inputs, retrieved context, tool results, and decision points behind it.
Use at() to confirm which prompt, tools, and model were live on that date.
Verify the checksums on the events involved.
Save the findings in a case file.
Write this as a standard procedure so any trained analyst can run it, not only the engineer who built the agent.
Step 6: Define human oversight
Article 14 is about humans being able to understand and intervene, not just about having a person somewhere in the loop. Decide for each agent which decisions require human review, who reviews them, and what they see when they do. ZizkaDB lets reviewers inspect full action chains and system state at any point in time, so interventions rest on evidence rather than screenshots or manual notes. Document who has authority to pause or override the agent.
Step 7: Set up behavioral monitoring
Let the agent run long enough to build a baseline, then use drift detection to compare recent behavior against it. Decide who reviews drift alerts and how often, for example after every prompt change or model upgrade plus a weekly check. Keep the records of these reviews, since they are direct evidence of ongoing monitoring.
Remember that drift tells you something changed, not whether it is good or bad. Pair it with error rate and session length, then use replay and lineage to investigate flagged changes.
Step 8: Prepare for erasure requests
GDPR applies to every agentic system that touches personal data. Define how erasure requests are received and verified, and test forget() on synthetic data first. Confirm that deletion covers both event logs and vector stores, and that the audit trail for other users stays intact afterwards.
Step 9: Build an evidence pack template
Create a reusable template so an audit request does not start from a blank page. It should include:
The agent inventory and risk classification from Step 1
Retention and security configuration from Steps 3 and 4
Sample session replays and lineage reports for representative decisions
Point in time configuration records from at()
Drift review records from Step 7
Erasure procedure and test results from Step 8
Be clear internally about what this pack is. It is evidence that supports your technical documentation and compliance reporting. It does not replace your formal risk management system, quality management, or any conformity assessment by a notified body.
Step 10: Run a mock audit
Before a real request arrives, pick a date from three months ago and a decision from that date, then ask a colleague outside the build team to play the auditor. Can they get from the question to a complete, verified answer using only the procedure and the pack? Note where it took too long or where evidence was missing, fix those gaps, and repeat each quarter.
What the business case looks like
These figures are modeled assumptions, not measured results. Replace them with your own.
Assume 4 audit or customer evidence requests a year, each needing 2 engineers and 1 compliance person at about 100 euro per hour. Reconstructing evidence by hand from scattered logs, deployment history, and memory takes around 5 working days, costing about 12,000 euro per request, or 48,000 euro a year. With a prepared pack and direct queries, it takes about 1 day, costing about 2,400 euro per request, or roughly 9,600 euro a year. That is a saving of around 38,000 euro annually.
Add enterprise sales. If 10 deals a year stall for about 2 weeks on questions about logging, oversight, and data handling, a prepared and demonstrable answer can pull a meaningful share of that time back. Earlier revenue usually matters more than the labor saved.
The larger number is exposure. Under the EU AI Act, breaches of most obligations can bring fines of up to 15 million euro or 3 percent of global annual turnover, whichever is higher. Logs either existed at the time or they did not, and that cannot be fixed after the fact.
Common mistakes to avoid
Starting logging late. Evidence for the period before you instrumented the agent does not exist.
Treating the tool as the compliance program. ZizkaDB supplies evidence. You still need governance, risk management, and legal review.
Skipping the procedures. If nobody owns the explanation workflow or the evidence pack, the data sits unused when it matters.
Never testing. A mock audit finds gaps cheaply. A real one finds them expensively.
Where to go from here
Auditability is far cheaper to build before the questions arrive than after. Start with one agent, get the logging, security, and explanation workflow right, then expand.
If you tell me your sector and how many agents you run, I can tailor the evidence pack and the numbers to your case.
Want to test ZizkaDB on your agent? Try our open source version here: https://github.com/ZIZKA-AI-SL/ZizkaDB
Interested in a design partnership? Fill in the form on our site or reach me directly at founder@zizka.ai
Top comments (0)