Making an Enterprise AI-Ready: The Programme, the KPIs, the Guardrails and the Governance
A sequenced programme for getting an organisation from AI-curious to AI-operating: the readiness gates, the KPIs that predict production, the guardrails that belong in front of a model, and what 2026 governance requires.
Most AI programmes do not fail on the model. They fail because nobody defined what a correct answer looks like, nobody owned the outcome, and the data the system needed was never in a state it could use. Those are organisational problems that arrive wearing a technical costume, and they are solvable in a specific order.
This is that order. It assumes you are a CIO or a head of engineering with budget, pressure from above to "do something with AI", and an estate that was not designed for it.
The one-paragraph version#
Pick a problem where the output can be checked. Write the evaluation set before the system. Put a named human on the outcome. Get the data into a state where lineage can be shown. Ship something narrow into production and measure it. Then, and only then, widen. Everything below is that sentence with the detail restored.
Stage 0: the honest baseline#
Before any of it, establish what is true today. This takes about two weeks and it is the stage most often skipped, which is why so many programmes cannot later prove they worked.
| What to establish | Why it decides everything downstream |
|---|---|
| The process baseline, in numbers | Without what it costs today, no saving can ever be checked. A benefit claim with no baseline is unfalsifiable and will be treated as such at review. |
| Who owns the outcome, by name | Not a committee. A person whose objectives change if this fails. |
| The data position per use case | Where it lives, who owns it, whether it is accurate enough, and whether you may lawfully use it this way. |
| The regulatory position | Which regimes apply to this use case, and whether it is likely to be high-risk under the EU AI Act. |
| What happens if you do nothing | Sometimes the honest answer, and much cheaper to reach now than in month nine. |
Stage 1: choose a use case that can succeed#
The pattern is consistent across everything we have seen work and everything published. Winning use cases are high volume, repetitive, and have a verifiable output. All three, not two.
Verifiability is the one teams trade away, and it is the one that decides whether the project can be improved. If you cannot tell whether an output was right, you cannot measure a change, so you cannot iterate, so the system is frozen at whatever quality it launched with.
Where it reliably fails: work requiring guaranteed correctness with no human check; work where the knowledge was never written down; and organisations whose data is not yet in usable shape. If your candidate use case is in one of those, the readiness work is upstream and no model changes that.
Stage 2: the evaluation set, before the build#
This is the gate that separates programmes that reach production from those that do not. In published 2026 data on agent pilots, evaluation gaps are the single most-cited blocker at 64%, ahead of governance friction at 57% and model reliability at 51%. Model quality is third.
An evaluation set is a collection of real cases with known-correct outcomes, agreed with the people who own the work, before the system exists. It gives you three things nothing else does:
- A definition of "good enough" that a sceptical executive can inspect.
- The ability to tell whether a change improved anything.
- A regression test, so quality cannot silently degrade after launch.
Build it from real historical work, not invented examples. Include the awkward cases and the ones your best person got wrong, because those are where the value and the risk both live.
Stage 3: readiness gates#
Do not let a use case pass a gate on optimism. Each of these is answerable with evidence or it is not passed.
Data gate. Can you name the system of record for every input? Is there one authoritative definition per concept, with the query behind it? Can you show lineage from source to output? Are access controls correct for the population who will see the results?
Legal gate. Do you have a lawful basis for this use of this data? Are you inside the terms of whatever contracts the data arrived under? If personal data is involved, has a DPIA been done?
Evaluation gate. Does a scored evaluation set exist, agreed with the process owner, with a stated pass threshold?
Operational gate. Who is on call when it misbehaves? What is the rollback? What is the manual fallback if it is unavailable for a day?
Commercial gate. What is the baseline, what is the forecast, and which assumptions would have to break for the forecast to be wrong?
Stage 4: guardrails, in front of the model#
Guardrails are controls that sit around the system, not instructions inside a prompt. A prompt is a request; a guardrail is a constraint the system cannot talk its way out of.
The set worth having, in rough order of how often their absence causes an incident:
- Input provenance. Content from outside your system is DATA, never instruction. Retrieved passages, uploaded documents and API responses must be delimited and never concatenated into the instruction section. Prompt injection is not covered by traditional input validation.
- Output contract. Define the shape you will accept, validate against it, and fail closed. Does the JSON parse? Are required fields present? Do the line items sum? Is there no personal data in a field that should not carry it?
- Authority limits. For anything that acts rather than answers: an explicit allow-list of systems and actions, a value or blast-radius ceiling, and a human in front of anything irreversible.
- Reversal path. Every action the system can take needs a defined way to undo it. Where none exists, that action requires a human, whatever the measured accuracy says.
- Disclosure. Users must be able to tell they are dealing with an automated system, and to reach a person. This is now a legal requirement in the EU as well as a decency one.
- Rate and cost ceilings. Per user, per task, per day. Agents loop; a wandering agent is expensive as well as unreliable.
- Logging that would survive an investigation. Inputs, outputs, model version, prompt version, who was affected, and what happened next. If you cannot reconstruct a decision six months later, you cannot defend it.
Stage 5: the KPIs that actually predict production#
Most AI dashboards measure activity. Activity does not predict value. These do.
Readiness KPIs, before launch#
| KPI | Target | Why it predicts success |
|---|---|---|
| Evaluation coverage | Every launch case has a scored test | The 64% blocker, measured directly |
| Named accountable owner | 1 per use case | Committees do not get paged |
| Data lineage documented | 100% of inputs | Determines whether a disputed number can be defended |
| Baseline captured | Before build starts | Determines whether the benefit can ever be proven |
| Gate pass rate on first attempt | Track it | A high pass rate usually means the gates are too soft |
Operating KPIs, after launch#
| KPI | What it tells you |
|---|---|
| Task success rate against the evaluation set | The only quality number that means anything. Everything else is proxy. |
| Human intervention rate | Rising means quality is drifting or scope has crept. |
| Cost per completed task | Not cost per call. An agent that loops looks cheap per call and is not. |
| Time to detect a quality regression | If this is measured in weeks you are shipping blind. |
| Supervision hours returned | The hours that come back as checking output. Omitting this is why business cases die at review. |
| Share of freed capacity actually redeployed | Freed time is capacity, not cash, until someone is doing something else you can name. |
| Incidents with a complete audit trail | Should be 100%. Anything else is a governance failure discovered late. |
Inference readiness KPIs#
If you are running models rather than calling somebody else's, these decide whether it holds:
| KPI | Note |
|---|---|
| p95 and p99 latency, not mean | The mean hides the experience that makes users abandon it |
| Tokens per task, trending | The clearest early signal of prompt or agent bloat |
| Cache hit rate | Usually the largest single cost lever available |
| Capacity headroom at peak, evidenced | Size against a peak you can show, not one you fear |
| Failover behaviour, tested | A provider outage is a question of when |
| Model and prompt version pinned per deployment | Silent upgrades change behaviour; pin, then test before moving |
Stage 6: governance, and what 2026 actually requires#
Two useful frameworks and one binding regulation. Use the frameworks to structure the work; treat the regulation as a deadline.
NIST AI Risk Management Framework is voluntary, US-originated and the most practical starting structure: govern, map, measure, manage. NIST publishes crosswalks to ISO/IEC 42001, so adopting one does not strand you from the other.
ISO/IEC 42001 is the certifiable AI management system standard. If you will eventually need to demonstrate governance to a customer or a regulator, this is the artifact they will recognise.
The EU AI Act is the binding one, and the dates matter more than the detail:
| Date | What applies |
|---|---|
| 2 August 2026 | AI Office and Member State authorities are responsible for implementation, supervision and enforcement. Transparency rules in effect. Prohibited practices, transparency requirements for certain AI systems, and rules for general-purpose AI models are enforceable. |
| 2 December 2027 | Rules for high-risk areas: biometrics, critical infrastructure, education, employment, migration, asylum and border control. |
| 2 August 2028 | Systems embedded in regulated products, such as lifts and toys. |
If you operate in or sell into the EU and your use case touches employment, education, credit or biometrics, the December 2027 date is your planning horizon and the work required is substantial: risk management system, data governance, technical documentation, logging, human oversight and accuracy and robustness evidence.
Governance that is worth having, minimum viable version: an inventory of AI systems in use including the ones nobody approved; a named owner and a risk classification per system; a decision record for anything that acts autonomously; and a review cadence with teeth. Most organisations have none of this and will discover it during an incident or a procurement questionnaire.
The sequence, in one place#
- Baseline what is true today, in numbers, and name an owner.
- Choose a high-volume, repetitive, verifiable use case.
- Build the evaluation set before the system.
- Pass the data, legal, evaluation, operational and commercial gates on evidence.
- Put guardrails around the model, not instructions inside it.
- Ship narrow into production and measure task success, intervention rate and cost per task.
- Prove the benefit against the baseline before widening.
- Build the governance inventory in parallel, not afterwards.
Steps 1 to 3 are where programmes are won and are the ones under pressure to skip. They are also the cheapest steps in the list.
What we would tell you not to do#
Do not start with the most impressive use case. Do not buy a platform before you have one working outcome. Do not let "AI strategy" become a document rather than a shipped system. Do not report adoption as a success metric: adoption has roughly doubled across enterprises in two years while the share realising value has barely moved, and those are the same companies.
Sources#
- AI Risk Management Framework, NIST
- NIST AI RMF to ISO/IEC 42001 crosswalk, NIST AIRC
- AI Act regulatory framework, European Commission
- AI Act Service Desk FAQs, European Commission
- BvLogic State of Enterprise AI 2026
- BvLogic AI Agent Adoption Report 2026
What else is coming for AI Readiness
Pillar Guide Ready
The definitive explainer, start here.
Tutorials Not yet
Step-by-step, with working examples.
Best Practices Not yet
What holds up in production, and what quietly doesn't.
Checklists Not yet
Run through before you ship.
Sample Reports Not yet
What the output should look like.
Worked Examples Not yet
A real case, with numbers.
Diagrams Not yet
The architecture, drawn.
Downloads Not yet
Templates and starter files you can edit.
Videos Not yet
Walkthroughs.
FAQs Not yet
The questions people actually ask.