Side by side
Seven dimensions decide which route suits you. The first three are usually settled in the first meeting. The last four are the ones that show up eighteen months later.
| Dimension | A consultancy engagement | Governed build (FLYTEBIT) |
|---|---|---|
| What you receive | A strategy and a roadmap | A system running in production |
| Who builds it | Your team, or a vendor you then manage | We build it inside the stack you already run |
| Who owns it | Often the vendor, licensed back to you | You, with no dependency on us to keep it running |
| Who answers for a decision | Spread across a committee | One named owner, with the authority to stop it |
| What evidence exists afterwards | The deck, and the meeting notes | A record of each decision, the policy version, and the reason |
| Time to first value | Months of discovery | A working system inside the feasibility window |
| When the engagement ends | The deck lands | You hold a running asset |
Why a good plan rarely becomes a running system
The model is seldom the constraint. Ownership and enforcement are. A roadmap that recommends AI does not put AI into production, and a pilot nobody owns tends to stop when the sponsor changes teams. The projects that ship are the ones built for production from the start, with the boundary and the owner settled before any code is written.
Regulation has started to describe this in the same terms. Under the EU AI Act, high-risk systems carry obligations across Articles 9 to 15 covering risk management, data governance, technical documentation, record-keeping and human oversight. Every one of those describes a system that runs. None of them describes an intention to build one.
The standards work the same way. ISO/IEC 42001 asks for an AI management system rather than a policy document, and the OWASP agentic risk work treats enforcement as a runtime concern. An auditor asks what the system did, and what stopped it doing anything else.
What governed AI means here
Governed AI is a property of a running system, not a document. Four things have to be true at once.
A defined authority boundary
Someone decided what the system may do and wrote it down, in terms of actions rather than topics.
Policy enforced outside the model
The model proposes an action. A separate component compares it against the boundary and returns a verdict.
A record of each decision
The verdict, the reason, the policy version, and the input it was reached on. Traces show what happened.
Authority that can be withdrawn
And withdrawing it changes what the system is able to do, including the work already in flight.
Where Flytebit sits
We do the advisory work and the build in the same engagement. The boundary that governs a system is a design decision, and design decisions made in a document tend to arrive at the code as suggestions. Keeping the two close means the control an auditor asks about is the one that was built.
That shapes how an engagement runs. It opens with a feasibility study to agree the use case and the boundary, continues into the build, and ends with your team operating the system. Where a regulated workflow is involved, the controls come from the governance and risk work rather than being added after launch.
What to ask for before you sign
Five questions that separate a governed build from a well-presented proposal. They work on any supplier, including us.
Who is the named owner?
Accountability that sits with a committee is accountability nobody holds. Get a person and a role.
What is the authority boundary, in writing?
The boundary covers actions, not topics. "It can approve a claim under £2,000" is a boundary. "It can help with claims" is not.
Where does the record live?
Not a log of API calls. The verdict, the reason, the policy version, and the input it was reached on.
How does an action get reversed?
A stop button that halts execution without reverting what already ran is a pause. Ask what happens to the work in flight.
Who holds the code at handover?
If the answer involves a licence, you are renting the system rather than owning it.
Common questions
How is governed AI different from hiring a consultancy? ▾
A consultancy engagement ends with a recommendation. A governed build ends with a system in production that your team operates, with a record of the decisions it made. Both can be useful, and they answer different questions. If you need a plan before you commit budget, that is a consultancy question. If you need a system you can stand behind, it is a build question.
Is governed AI just AI governance with a different name? ▾
No, and the difference is the whole point. AI governance is the discipline: the policies, the roles, the oversight. Governed AI is the property a system carries once that discipline is enforced at runtime. Most organisations have written the first and built the second far less often.
Does this mean we should not use a consultancy at all? ▾
Not at all. A governance consultancy is the right call when the unresolved question is accountability: risk appetite, regulatory mapping, who holds decision rights. The build question starts once the control model is settled. What goes wrong is buying one and expecting the other.
What does a governed build cost, and how long does it take? ▾
We start with a feasibility study from $2K, which takes two to four weeks and asks for four to six hours of your team's time. It answers which use case to do first, whether to build or buy, and what the boundary should be. The build is scoped from there, so the number you get is based on your system rather than a rate card.
Do we own the system at the end? ▾
You own the code, the models, the documentation, and a trained team. There is no licence to renew and no dependency on us to keep it running. That is the same standard we hold our own products to.
What if AI turns out not to be the right answer? ▾
Then the feasibility study says so, and you have spent two to four weeks rather than a budget. We would rather write that down than build something you cannot justify. The governance and risk work covers what it takes to run AI safely when the answer is yes.