Against compliance-driven architecture

Here is a pattern I have watched play out several times since August, when EU AI Act enforcement began.

Someone reads Article 12. It requires automatic logging of events relevant to risk and traceability, tamper-evident, retained for six months, and twenty-four for biometric and law-enforcement uses. An engineering team is asked to make the pipeline compliant. Eight weeks later there is a log. It is append-only, it is retained, it is genuinely tamper-evident, and when an auditor asks which agent made a change to the pricing engine in March and on whose instruction, nobody can answer, because the log records that events occurred rather than what they were about.

The clause is satisfied. The question the clause exists to ask is not.

My position: architecture driven by regulatory text produces systems that pass the letter and fail the purpose, and the fix is to invert the order. Design for answerability, then map what you already produce onto whatever the current rule names.

The failure has a consistent shape

It is not that people are lazy or that regulations are badly written. It is that a regulation is necessarily a general statement, and a system is necessarily specific, and the translation loses the thing that mattered.

A clause says “log events relevant to traceability”. A team reads that as a technical requirement about durability, immutability and retention, all of which are things engineers know how to build. What it is actually asking is: can you reconstruct what happened and why. That is a question about the contents of the record, and contents are exactly what a general clause cannot specify.

So you get controls that are technically excellent and semantically empty. A tamper-evident log of “deployment occurred”. An approval workflow where the approval is a click with no relationship to a reading. Retention of everything, indexed by nothing.

Regulations change, questions do not

The second argument against building to the text is durability.

The specific obligations in force today are recent, and they will be amended, interpreted, supplemented by guidance, and joined by whatever other jurisdictions decide. If your control layer is shaped like the current wording, every revision is a re-architecture, and you will be doing it under time pressure with a deadline set by someone else.

The underlying questions are far more stable. They have been roughly the same for decades, across financial services, medical devices, aviation and safety-critical software generally.

Answer those, and a new rule is a mapping exercise. Build to the clause, and a new rule is a project.

Where the record has to be captured

The operational point that decides whether any of this works: the record has to be produced where the facts exist, at the moment they exist.

For software changes, that moment is the merge. At merge, the change, the instruction it was produced against, what checked it, and who accepted it are all simultaneously available and cheap to record. An hour later they are already dispersed across a tracker, a chat thread and someone’s memory. Six months later, reconstructing them is an archaeology project whose output is a document you would rather not sign.

This is why bolt-on compliance tooling disappoints so consistently. A system that reads your repository afterwards can tell you what changed. It cannot tell you why, because why was never written down at the point where anybody knew.

And to be explicit, because this is the sentence that vendors in this space avoid: no tool makes an organisation compliant with the AI Act or with anything else. Compliance is a determination about your organisation made by people qualified to make it. A record lets you answer questions truthfully and fast. That is the entire claim, and it is worth making because the alternative is answering slowly and approximately.

Where this breaks down

Sometimes the regulation genuinely does dictate architecture, and pretending otherwise is dangerous. Data residency is the clearest case: if the rule says the data does not leave the jurisdiction, that is a topology requirement and no amount of designing for good questions substitutes for it. My argument applies to record-keeping and process controls. Applied to substantive technical constraints it is wrong, and someone will misapply it.

Auditors work from checklists, and “we designed for the underlying question” is a bad answer in the room. This is the strongest objection. An assessor with a control matrix wants the control named in the matrix, and an elegant argument about purpose reads as an excuse for not having it. The practical answer is that you need both, the record and the mapping document that says which part of it satisfies which clause, and that mapping is real work I have described here as trivial.

A regulatory deadline is a budget you will not get twice. Compliance-driven architecture is often bad architecture funded properly, and the alternative is good architecture funded never. Leaders who have got a control layer built by pointing at an obligation are not being cynical. They are being effective, and telling them not to do that is advice with no route to a budget line.

We sell tooling that produces merge-time records. So an argument concluding “capture at merge, do not bolt on afterwards” is directly commercial. Discount it. The part that is free: most of the six questions can be answered from your existing tracker, repository and CI if you decide to capture the link between them at the point of merge, and if you have the platform capacity to do that, do it yourselves.

And designing for questions requires knowing which questions. I have listed six that I believe are durable. If a genuinely novel obligation arrives, say a requirement to demonstrate something about model provenance that nobody currently records, then my stable-questions framing is just a different guess that happened to be wrong, and the team that built literally to the text will be closer to the answer than I will.

The takeaway

A control that satisfies a clause and cannot answer the question behind it is worse than no control, because it converts an open risk into a documented false assurance.

Design the record around what someone will need to reconstruct: what changed, why, produced by what, checked by what, accepted by whom, and provably unaltered. Then write the mapping to whichever framework applies. That order survives the next amendment. The other one does not.

If you take one thing into next week: take one control you built for a regulation and ask what question it exists to answer. Then try to answer that question using only the control’s output. The gap between those two things is your actual exposure.