Solution
A regulation now applies to us
EU AI Act compliance
Most organizations meet the AI Act as a deployer rather than a provider: they use AI systems built by someone else, inside processes they own. That distinction matters, because the obligations that land on a deployer are narrower than the ones the headlines describe, and almost all of them are decided by how the system is built and run.
The work is rarely a legal exercise. Knowing which systems are in use and in which risk class, making human oversight real rather than nominal, logging what the system did, and being able to show it: these are properties of an architecture. A policy document can assert them. Only the system can hold them.
You are probably here because
- Someone has asked which AI systems you use, and the list took longer to produce than expected.
- A supplier has told you their system is compliant, and it is unclear what that leaves you responsible for.
- Human oversight exists on paper, but the person named for it has no practical way to intervene.
- A tender or a client questionnaire is asking for evidence you do not currently produce.
What settles it
An inventory that stays current
Which AI systems are in use, who owns each one, what it decides or assists with, and which risk class it falls into. Produced from how systems are registered rather than from a survey that is out of date the week after it is collected.
Human oversight that can actually intervene
Oversight is only real when the reviewer sees the decision before it takes effect, has the context to judge it, and can stop it. That is an architectural property: where the review point sits, and what the system does while it waits.
Logging that answers the question later
What the system was given, what it produced, which version of the model and prompt, and what followed. Recorded at the moment it happens, because it cannot be reconstructed afterwards with any honesty.
Transparency toward the people affected
Where a person is interacting with an AI system, or a decision about them was assisted by one, saying so in the interface rather than in a policy nobody opens.
Evidence an authority can be shown
The documentation obligations discharged as a by-product of running the system, rather than as a project that starts when someone asks.
Start with the inventory, then take the highest-risk system on it. Oversight and logging are the expensive part, and they take exactly as long as changing those systems takes.
how this gets delivered
Capabilities, cases, and further reading
Delivered through
- Operational AI
AI systems that integrate with existing platforms and workflows, with control, traceability, and operational reliability.
Where we have done it
- Decision Architecture
A decision-system redesign that embeds AI assistance while preserving accountability and control.
- AI Operating Model
A practical operating model that aligns leadership governance with implementation teams and measurable outcomes.
- Sovereign AI Gateway
A unified gateway that centralizes model routing, policy enforcement, and auditability.
Further reading
- The EU AI Act: what it asks of deployers
Most organizations buying or building on AI are deployers rather than providers. That distinction decides which obligations land on you, and most of them are architectural.
faq
Frequently asked questions
- Are we a provider or a deployer under the AI Act?
- Most organizations using AI in their own processes are deployers: someone else built and placed the system on the market, and you put it to use. The distinction matters because a deployer's obligations are considerably narrower. It can shift, though, notably if you substantially modify a system or put your own name on it, and that is worth establishing early rather than assuming.
- Do the obligations apply to systems we already run?
- Generally yes, and that is the part organizations underestimate. Compliance is not only about what you procure next; it covers what is already in production, which is usually where the inventory work turns out to be larger than expected.
- Our supplier says their product is compliant. Is that enough?
- It settles their obligations, not yours. A compliant system used without meaningful oversight, without logging on your side, or outside the purpose it was assessed for does not make the deployment compliant. The division of responsibility is worth writing down explicitly, in the contract and in the architecture.
- How do we tell which risk category a system falls into?
- Classification follows from what the system is used for, not from how it was built, so the same underlying technology can land in different categories in two different processes. That makes it a determination about your own use, with a named owner and a recorded rationale, rather than something a supplier can answer on your behalf. Where a case is genuinely borderline, it is worth taking legal advice on that specific use rather than on the technology.
- How long does this take?
- The inventory and the risk classification are usually weeks rather than months. Making oversight and logging real in systems that were not built with them takes as long as changing those systems takes, which is why starting from the highest-risk use rather than from the full estate is normally the right sequence.