Is your organization actually ready for AI?

A ranked portfolio of AI use cases, each with a named business owner

Candidate use cases are written down, sized by the value and the effort, ranked against each other, and every funded one has an owner accountable for the business outcome — not just for delivery.

Funded work starts from a business problem, not from a technology

Projects are justified by a process that is slow, expensive or error-prone today. Nothing is funded primarily because a vendor shipped a capability or a competitor announced something.

A stated position on build versus buy versus embed

There is a written default — which categories you buy off the shelf, which you build because they are differentiating, and where you embed AI into software you already own.

A named executive sponsor with budget authority and a stake in the outcome

One executive owns the AI programme, controls a real budget for it, and carries a business metric that AI is supposed to move. Not a steering committee.

The systems of record behind AI-facing data are identified and owned

For each domain the AI touches, you know which system is authoritative, who owns it, and which copies are derived. Ambiguity here becomes confidently wrong answers later.

Engineers can get governed access to production data without a multi-week ticket

There is a defined, fast path to read production data under policy — masked, logged and time-bounded. Access is granted in days, not quarters, and revoked automatically.

The documents your AI reads are current, deduplicated and permission-aware

Retrieval corpora have an owner and a refresh cadence, superseded versions are removed, and results respect the permissions of the person asking rather than the permissions of the indexer.

Sensitive data is classified, and what may leave your boundary is written down

Data is labelled by sensitivity, and there is an explicit, published rule about which classes may be sent to which model providers — including whether a zero-retention agreement is required.

Model access runs through a shared gateway rather than per-team keys

Calls to model providers pass through one internal service that handles authentication, routing, rate limits, cost attribution and logging. Teams do not hold provider keys directly.

Every AI feature has an automated evaluation set that runs before release

Each feature has a versioned set of cases with expected behaviour, scored automatically, run in CI, and blocking on regression — the same status a test suite has for ordinary code.

Prompts, models and configuration ship through the same reviewed pipeline as code

Prompt and model changes are version-controlled, reviewed, deployed and rolled back exactly like application code. Nobody edits a production prompt in a console.

Traces, token counts and failures are captured per request and are queryable

For any request you can retrieve the inputs, retrieved context, model, tokens, latency, cost and outcome — and query across them to find patterns rather than anecdotes.

A published acceptable-use policy that people have actually read

A short, specific policy says which tools are approved, what may be pasted into them, and what to do when unsure. Specific enough to be followed, short enough to be read.

Decisions are tiered, and the consequential tiers require a human

You have classified where AI may decide alone, where it recommends and a human approves, and where it must not be used. The tiering is enforced in the systems, not just described.

Agents run with scoped, revocable credentials and leave an audit trail

Anything that acts — writes, sends, pays, changes state — has its own identity with least-privilege scopes, a revocation path, and an immutable log of what it did on whose behalf.

A defined path for reporting, triaging and rolling back a bad AI output

Staff and customers know how to report a harmful or wrong output, it reaches an owner, and there is a rehearsed way to disable a feature quickly without a full release.

Enablement is role-specific rather than a single all-hands demo

Training is built around what a particular role does all day, with their own data and their own tasks. A generic launch webinar is not enablement.

Each major function has someone who builds with the tools, not just uses them

Named people inside the business — not only in engineering — build their own automations, answer colleagues, and feed real problems back to the platform team.

Adopted tools have changed a documented process, not just added a tab

Where AI is in use, the underlying process has been redesigned around it: steps removed, handoffs cut, procedures rewritten. Otherwise you have added work rather than removed it.

Users can flag a bad output and see that something happened

Feedback is one click, it lands somewhere a person reads, it becomes an evaluation case, and the reporter learns the outcome. A loop that goes nowhere trains people to stop reporting.

You know the cost per request, per user or per resolved case

Spend is attributed to a unit the business recognises, not just a monthly provider invoice. You can say what one resolved support ticket costs in inference.

Spend limits and alerts exist per team and per workload

Budgets are set below the level of the whole account, alerts route to the team that caused the spend, and there is a hard ceiling that stops a runaway loop.

Each deployed use case has a pre-AI baseline it is measured against

You recorded how long it took, what it cost or how often it was wrong before deployment. Without a baseline, improvement is a matter of opinion forever.

There is a rule for retiring a use case that is not paying

Deployed use cases are reviewed on a schedule against their baseline, and there is an agreed threshold and process for switching one off. Someone has actually done it.