AI Governance
Not every system we build falls under the EU AI Act, and plenty of our work sits outside it entirely. When a project does need to meet it — or when you would simply rather it were built that way — this is the track we run: how the duties get divided, when each part of the work happens, and what you are left holding at the end.
When clients choose it
You sell into the EU, or your own customers do.
Procurement, an auditor or an insurer has asked how the system is governed.
It is the standard you would rather be held to, wherever the system runs.
Where none of that applies, we build to whatever standard does — your sector's rules, your customer's contract, or straightforward good engineering. This page is an option, not a house style, and nothing here is billed as compliance work you did not ask for.
Responsibilities
On a project like this, the first thing we settle is which role each of us holds. The Act assigns duties by role rather than by who wrote the code, so it goes in the contract — statute decides it, and an agreement cannot move it somewhere more convenient.
We build a system you put into service under your own name.
The provider duties stay with you. Our part is to hand over what those duties need — the intended purpose, the technical documentation, the evaluation results, the logging design and the instructions for use — in a form you can give to an auditor without rewriting it first.
You use one of our own products, supplied under our name.
The duties are ours rather than yours. Which documentation and conformity route applies depends on how that product is classified, so before you commit we tell you what exists for the release you are getting and what is still being produced. We also set out which obligations move to you once it is running in your business.
You operate the system in your organisation, whoever built it.
Human oversight, the quality of the input data and keeping the logs are yours to run. Our job is to make them possible rather than nominal: an override that works when the system is busy, and a log still legible six months later.
We use AI inside our own engineering work.
That gives us duties of our own, set out further down. It matters to you because our tooling touches your code, so the terms we hold ourselves to are worth reading.
Rebranding a system, changing what it is for, or modifying it substantially can move the provider duties onto whoever did it — sometimes onto a client who only meant to adjust a workflow. We raise it before the change, not after.
How we work
Where we are doing this work, it is folded into the ordinary delivery steps rather than run as a project of its own. Left to the end, the answers have to be reconstructed; done as we go, the record accumulates while the system is built.
01
Before we start
We work out together whether what you have in mind is an AI system under the Act at all, which roles apply, and whether any part of it is off-limits. Occasionally this changes the brief — which is considerably cheaper to hear at this point.
02
During design
Oversight, logging, evaluation and disclosure get decided alongside the architecture. These are the parts that cannot be added cheaply later, so they are not deferred to a hardening phase that may never arrive.
03
While building
The record is written as the decisions are made: what was chosen, what was measured against which threshold, and who accepted the residual risk. Dated as it happens rather than assembled afterwards from memory.
04
At handover
You receive the documents your side of the duties needs, and a walk-through with the people who will actually operate the system. Training the operators is part of the work, not an extra.
05
After release
We agree in advance which changes reopen the question — a new model version, a new data source, a new territory, a new decision the system touches — so nobody has to guess whether a release needs another look.
Engineering
These are the controls that turn the requirements into code rather than a policy document. They are our default on anything that might come into scope, whichever framework it answers to, and the same patterns run in Codexta, our own agent platform.
Someone who can genuinely intervene, rather than a record that says they could.
Answering for a decision later means being able to show what was decided and on what basis.
A model cannot be unit-tested, so its quality has to be measured instead.
In practice most incidents with these systems begin as access problems.
Article 50 applies to a good deal of ordinary software, high-risk or not.
Handover
If you hold the provider duties, these are the documents that let you answer for the system without coming back to us for every question.
Written as it is produced and dated accordingly. The same decision recorded months later carries much less weight.
Our own tooling
We use AI in our own engineering, which makes us a deployer with duties of our own. Since that tooling touches your code, here are the terms we hold ourselves to.
Approved tools only, and the rule covers retention and training-use settings as much as the model itself. Ask for the list that applies to your project, or ask us to exclude something from it, and we will put it in writing.
No customer code or data in public consumer tools — a contracted enterprise tenant with agreed data terms, or nothing.
Secrets, credentials and production personal data do not go into a prompt.
Generated code is reviewed and tested like any other code. It is not trusted because a model produced it.
The engineer who commits and the engineer who reviews remain accountable. AI does not approve its own change or stand in for the second reader.
Agents run sandboxed, with least privilege and a full action log. Nothing destructive or irreversible runs unsupervised.
Limits
This part is not optional, and it does not depend on which framework a project runs under. Article 5 prohibits a handful of uses outright, a risk acceptance does not make them available, and we would rather mention it in the first conversation than at contract stage.
Social scoring — rating people on their behaviour over time so they can be treated worse elsewhere for it.
Inferring emotions in a workplace or a school, outside the narrow medical and safety exceptions.
Biometric categorisation that deduces protected characteristics from someone's face or body.
Untargeted scraping of facial images to build or expand a recognition database.
Predicting an individual's criminality from profiling or personality traits alone.
Interfaces built to manipulate or deceive people into decisions that harm them.
Generating non-consensual intimate imagery or child sexual abuse material, including the misuse controls that keep a general-purpose tool from being turned to it.
This page describes how we work. It is not legal advice, and it is not a statement that any particular system has completed a conformity assessment. Where a project needs a formal position, we say so and involve counsel.