The procurement team sent the contract back with one more document attached, a questionnaire nobody on the project had seen before.
It asked where the personal data in the system was processed, and which direction it moved.
It asked who had approved the model for this particular use, and on what basis.
It asked what happened on the day the system disagreed with the person using it, and who was accountable for that call.
Nobody on the call could answer all three in one sitting. The engineers had the technical detail. Nobody had, written down anywhere, the thing a customer's own security team would actually ask for — and the contract was two weeks from signing.
Why we build it this way
Those three questions are not paperwork wrapped around a finished system. They are the same decisions an architecture has to make, asked back at you after the fact. Where data moves, who signs off on a model, what happens when a person disagrees — none of that is a form. It is the shape of the thing you built.
The common approach treats this as a review that happens near the end: build the system, then book time with legal or compliance before it ships. That ordering assumes the reviewer's job is to find problems. In practice their job becomes reconstructing, after the fact, decisions nobody wrote down when they were made — who approved what, which data crossed which line. That reconstruction is slow precisely because nothing was built to answer it.
The EU AI Act and GDPR are not, underneath the paperwork, asking for a certificate. They are asking architecture questions: who is accountable for this use, what happens on the day it fails, and can you show the record. A system drawn with those questions in mind answers them as a by-product of how it works. A system that was not has to invent the answer under deadline, which is the worst time to be inventing anything.
The EU AI Act and GDPR shape the architecture from the first drawing, not a compliance review at the end. If you sell into Europe, this is now a commercial requirement, not a nice-to-have.
So the questionnaire stops being a surprise. It becomes a form you are already able to fill in, because the answers were decided before anything was built, not reconstructed after.
How it works, roughly
Before we design anything, we classify the use case against questions a regulator or a customer's own security team will eventually ask:
- What happens when this use case is wrong, and who is affected
- Which data crosses the boundary between the system and the rest of the business, and in which direction
- Who is accountable for approving this use case before it runs, not after
That classification sets how much oversight the use case earns — heavier where a wrong answer costs more, lighter where it does not — and names, in writing, the person who must sign specific decisions before the system may proceed. Every retrieval, action and approval is recorded from the first day it runs, not added once someone asks for it.
When a person disagrees with what the system produced, the disagreement goes to that same named person. It is recorded as a decision, so the next person asking the same question — a regulator, an auditor, the customer who sent the questionnaire — finds an answer already waiting.
A year on, the questionnaire is no longer a scramble. The answers it asks for were decided when the system was drawn, not reconstructed under a signing deadline, and the record of every approval lives in your own building, not ours. A person still decides what counts as approved — the architecture just makes sure that decision was never skipped.
See how we build it in →