Solution
Who is accountable for what it does
AI governance
Once AI is doing work rather than demonstrating it, the questions change. Not whether the model is good, but what it is permitted to do without a person, what happens when it is wrong, who owns it in operation, and how anyone would notice if its behaviour drifted.
These are architectural questions before they are policy ones. A governance document describes intent. What holds under load is where the review point sits, what the system does while it waits, and what gets recorded at the moment a decision is made.
You are probably here because
- AI use has spread across teams faster than any shared agreement about it.
- A system is making or shaping decisions, and the accountability for those decisions is unclear.
- Something was wrong in production, and reconstructing why took days.
- A supplier changed their model version, and you found out from the behaviour rather than from a notice.
- Nobody can say whether a system that worked at launch is still working now.
What settles it
Decision rights, stated explicitly
What the system may do unattended, what it may propose, and what requires a person. Authority should be narrower than capability, and where the line sits is a design decision rather than a model property.
Review points where they matter
A person in the path where the cost of being wrong is high, and out of the path where it is not. Review applied everywhere is review applied nowhere, because it gets clicked through.
Traceability recorded as it happens
Sources, context, model and prompt version, and the action that followed. Provenance captured at the moment of the decision survives; provenance reconstructed later is a guess with a timestamp.
Evaluation that continues after launch
Measurements that keep running in production, because the assessment that mattered before go-live tells you nothing about behaviour six months and three model versions later.
Defined behaviour when the system is unsure
Refusing or escalating on insufficient evidence is correct operation, not failure. Both outcomes deserve to be designed, and a system that only knows how to answer will answer wrongly.
Settle the decision rights before the review points, and the review points before the tooling. Teams that work in that order end up trusting the system with more, because the cases where it must not act have somewhere to go.
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.
- Systems Architecture
Designing architectural foundations that allow complex organizations to operate reliably and evolve safely.
Where we have done it
- AI Operating Model
A practical operating model that aligns leadership governance with implementation teams and measurable outcomes.
- Decision Architecture
A decision-system redesign that embeds AI assistance while preserving accountability and control.
- Category Blueprint
A category blueprint that turns AI governance into a practical operating design for scalable transformation.
Further reading
- Your AI needs playback—not a blockchain
A trustworthy AI system should not merely retain an answer. It should let you return to that interaction and inspect the evidence, decisions, configuration, and controls behind it.
- The AI code trust gap: adoption is settled, ownership is not
Around 90% of developers use AI daily, more distrust its accuracy than trust it, and its security pass rate has not moved in a year. Read together, the 2025-2026 evidence says the constraint has shifted from writing software to owning it, and that is a specification and accountability problem rather than a tooling one.
- Why AI pilots stall before production
A working demo is not a working system. The difference between AI that ships and AI that stalls is operational integration, not model quality.
faq
Frequently asked questions
- Is this the same as AI Act compliance?
- They overlap heavily but are not the same. The AI Act sets obligations you must meet; governance is how you decide what your systems are allowed to do and how you know they are still behaving. Organizations that build the second usually find the first largely discharged as a consequence.
- Should AI be allowed to change data in our systems?
- It is a design decision rather than a technical necessity, and worth making explicitly. In much of our work AI drafts and proposes while a person approves wherever value is granted or an obligation is created. That combination is usually both defensible and genuinely faster than the alternative.
- How do we know a system is still working?
- By measuring it in production against something you defined in advance, and by recording enough about each decision that a sample can be checked. Systems degrade quietly: the model changes, the inputs shift, the process around it moves, and none of that announces itself.
- Does governance slow delivery down?
- Heavy governance does, and gets bypassed, which leaves you worse off than none. A small number of visible mechanisms - stated decision rights, a review point where the stakes are high, recorded decisions - is what teams actually apply, and it is what lets you expand what the system is trusted with.