Europe decided how it wants AI to behave. The EU AI Act is law, and its obligations are arriving in phases — record keeping, transparency, human oversight, risk controls. Every member state is standing up authorities to enforce it. If you build AI systems for European organisations, compliance is no longer an abstract debate. There are named offices that can ask you questions, and the questions are already written.
Most engineers treat this as bad news. I have spent months reading the stack and testing what it means in practice, and I came out with the opposite view: compliance is not the enemy of good AI engineering. It is a spec for it.
The trace and the audit log are the same thing
Remove the legal language and the rules ask for a short list: know what your system did, explain why, keep records, let a human step in, protect the data. Now read that list as an engineer. It is a trace, a log, an audit trail, an approval gate, and access control. The trace you want for debugging is the same record a regulator wants for oversight. Build it once and it serves both. Teams that treat compliance as paperwork glue documents onto a black box. Teams that treat it as architecture get a better system for free.
I tested this on real law
I wanted a testbed where the whole regulatory stack fits in one head. I picked Malta — the EU’s smallest member state, which in 2025 brought AI rules into national law and named its data protection commissioner as the watching authority. I built a RAG system over that legal corpus and measured it the way I would measure any production system.
One result changed how I think about citations. I wrote a citation validator — about 30 lines of Python that check whether a cited chunk actually exists. I ran it against 25 real recorded responses. It caught 3 fabricated citations. Two of them were answers that looked correct when I read them. I would have approved them by eye. In regulated work, a fabricated citation is not a quality bug. It is a false compliance claim, produced at machine speed. Thirty lines of code catch what careful reading misses.
Another test: I poisoned the corpus with a fake “official amendment” and asked the system questions. The injection worked — the model repeated the fake amendment with full confidence. A provenance check (does this chunk come from a source we trust?) is what caught it. The lesson: in a legal corpus, the least defended attack surface is the corpus itself.
Workflow first, agent second
An autonomous agent that improvises its own steps is very hard to audit. A workflow with fixed steps is easy to audit: the LLM fills defined slots, a validator checks the output, and an approval gate pauses before anything important happens. In a regulated context that is not the boring option. It is the only honest one. Use agent autonomy only where flexible decisions are the actual value — and even then, keep it bounded: a tool registry, schema checks, a cost meter, a human gate. Each of these is also evidence of control when the regulator asks.
Where does the data go?
The first question I push clients to answer: where does the data physically travel? A RAG system over your own documents keeps the sensitive content local and sends out only small queries — and when someone asks “what informed this answer?”, you can point to a list of documents. Pushing whole knowledge bases into a hosted model’s context window sends everything, every time, and cannot answer that question at all. The two designs look similar in a demo. They are completely different in front of a European regulator.
Start where the rules are small
My advice to engineers staring at the AI Act: do not start from the full text. Start from a corner of it small enough to read completely — a single member state, a single use case, a single system — and build something real against it. That is what Malta gave me: a whole regulatory stack small enough to hold in my head and test honestly. Learn to build auditable AI where the rules are small enough to read. Then you are ready for the places where they are not.