An AI prototype can look convincing in ten minutes. A dependable business system has to keep working after the demonstration, with real data, uneven user behaviour, changing source material and consequences when the output is wrong.
That difference explains many disappointing AI projects. The model may be capable, but the surrounding delivery system is weak. Nobody owns the outcome. The data is less reliable than expected. Success is described in general terms. Review exists on a diagram but not in somebody's working day. The team launches without a clear view of failure, then discovers it through customers or colleagues.
Why promising AI projects fail
AI projects can fail commercially even when the technology works. A useful classification model that solves a low-value problem is still a poor investment. An assistant that saves time in isolation may create extra checking work elsewhere. A workflow that performs well in a test set may become unreliable when source documents, policies or customer behaviour change.
Common failure patterns include:
- Tool-first planning: the team chooses a model or platform before defining the business pressure.
- Unowned outcomes: technology owns the build, but nobody in the business owns adoption, quality or realised value.
- Unclear boundaries: the system can answer or act beyond the cases the team has actually evaluated.
- Weak evidence: a few good demonstrations are treated as proof of reliable performance.
- Paper oversight: a person is nominally in the loop but lacks time, context or authority to challenge the output.
- No operating model: source changes, incidents, user feedback and performance drift have no defined route.
These are governance and delivery problems, not reasons to avoid AI. They are reasons to build the system around the work instead of around the novelty.
Start AI governance with accountability
Governance is sometimes reduced to a policy document or approval board. Those may be useful, but practical governance begins with decisions and owners.
For each use case, name the business owner accountable for the outcome, the product or delivery owner responsible for day-to-day performance, the technical owner responsible for the system and the people responsible for privacy, security, legal or sector-specific review where relevant. Smaller organisations may combine roles, but the decisions still need names beside them.
| Decision | What must be clear | Typical owner |
|---|---|---|
| Why the system exists | Business objective, users, expected value and current baseline | Business sponsor |
| What it may do | Permitted tasks, data, tools, actions and exclusions | Product and technical owners |
| What counts as acceptable | Evaluation criteria, risk tolerances and release threshold | Business, risk and delivery owners |
| When a person intervenes | Review points, escalation rules, fallback and stop conditions | Operational owner |
| How it changes | Approval for model, prompt, data, workflow and integration updates | Product owner with relevant reviewers |
The UK's AI assurance guidance describes accountability and governance as clear oversight across the AI lifecycle. That does not require a large bureaucracy. It requires the organisation to know who can approve, challenge, change, pause and retire the system.
Map risk to the actual workflow
A generic list of AI risks is not enough. The same model can create very different risk depending on what it is asked to do.
An internal assistant that retrieves approved policy passages creates one kind of exposure. A system that drafts a customer reply, updates a record or influences an employment decision creates another. Assess the inputs, outputs, people affected, systems touched and reversibility of each action.
Walk through the workflow and ask:
- What information enters the system? Consider personal data, confidential material, intellectual property, licence terms, source quality and freshness.
- What does the system produce? Separate suggestions, classifications, decisions, external communications and actions.
- Who could be affected? Include customers, employees, applicants, suppliers and people represented in the data.
- What happens when it is wrong? Examine harm, delay, financial loss, unfairness, privacy, security, reputation and operational recovery.
- Can the result be checked and reversed? A reversible draft is not the same as an irreversible payment, deletion or published statement.
If personal data is involved, the Information Commissioner's Office highlights accountability, transparency, lawfulness, accuracy, fairness, security, data minimisation and individual rights. The practical review must follow the data and decisions through the real process rather than assume that buying a familiar product transfers the organisation's responsibility.
Build a reliability stack, not one accuracy score
Reliability is broader than whether an answer looks correct. A business system must use appropriate sources, behave consistently within its scope, fail visibly, protect information, support review and recover when a dependency breaks.
A practical reliability stack has several layers:
1. Controlled inputs
Define the approved sources, expected formats, access permissions and freshness rules. Where possible, validate structured inputs before the model sees them. Do not ask a model to compensate silently for missing operational controls.
2. Bounded instructions and tools
Describe the task, exclusions and escalation conditions. Give the system only the data and permissions it needs. Put deterministic rules around actions that must always behave the same way.
3. Representative evaluation
Test routine cases, difficult cases, ambiguous requests, missing information, adversarial inputs and high-consequence edge cases. Use examples from the real operating environment and keep a stable evaluation set so changes can be compared.
4. Evidence at the point of use
Where the task depends on source material, make the evidence visible. Citations, retrieved passages, confidence signals or a structured explanation can help reviewers judge an output. The right mechanism depends on the workflow; a fluent answer alone is not evidence.
5. Human control that can work in practice
Place review before external, consequential or irreversible actions. Give the reviewer the source context, criteria and authority to reject or edit. Measure the review burden. If people approve everything because the queue is unmanageable, the control has failed.
6. Safe failure and fallback
Decide what the system should do when knowledge is missing, an integration fails, confidence is low or a user asks for something outside scope. It may ask a clarifying question, route to a person, produce a draft only or stop. Silent improvisation is rarely the safest default.
NIST's AI Risk Management Framework places trustworthiness across design, development, use and evaluation. That lifecycle view matters because no single pre-launch test can represent every condition a live system will encounter.
How to govern AI without creating gridlock
Bad governance is vague, centralised and slow. Good governance is proportionate to the use case and gives teams a known route from idea to decision.
Use tiers. A low-risk internal drafting aid with no sensitive data should not face the same process as a system making or influencing high-impact decisions. Define the criteria that move a use case into deeper review: the people affected, sensitivity of data, autonomy, reversibility, legal duties and severity of a wrong outcome.
Use standard artefacts so every team answers the same core questions:
- a one-page use-case brief with outcome, owner and users;
- a workflow and data map;
- an impact and risk assessment;
- an evaluation plan with release criteria;
- an oversight and escalation design;
- a change log and monitoring plan;
- an incident and retirement route.
Keep these artefacts alive. A form completed before approval and never revisited is administration, not governance. The record should change when the model, data, prompt, integration, user group or operating purpose changes.
Reliability work continues after launch
Production changes the evidence. Users ask questions the team did not predict. Source information becomes stale. Integrations fail. Workarounds appear. A useful monitoring plan combines technical, operational and human signals.
| Signal | What it can reveal | Possible response |
|---|---|---|
| Successful task completion | Whether the workflow produces the intended operational result | Investigate failure stages, not only model output |
| Correction and rejection rate | How often people must repair or refuse the result | Review instructions, sources, scope or user training |
| Escalations and fallback use | Where the system meets uncertainty or missing capability | Add knowledge, narrow scope or improve routing |
| Review time | Whether oversight is creating hidden workload | Improve evidence, interface or automation boundaries |
| Incidents and near misses | Consequences and controls that almost failed | Contain, investigate, change and retest |
| User feedback by group | Uneven performance, access or impact | Examine data, design and fairness implications |
Set thresholds for investigation, rollback or pause. Review measures on an agreed cadence and after significant changes. Compare realised value with the original case. A system that is accurate but unused, or fast but expensive to supervise, is not delivering the intended outcome.
A practical AI governance and reliability checklist
- Name the business outcome and owner. Record the current baseline and the decision the project must earn.
- Define scope and exclusions. State the users, tasks, data, tools, actions and forbidden behaviour.
- Map people and impact. Identify who is affected and involve the right operational, legal, privacy, security or domain expertise.
- Design controls in the workflow. Place checks, approvals, escalation and fallback where they can change the result.
- Create representative tests. Include normal work, edge cases, poor inputs, changing sources and high-risk scenarios.
- Agree release criteria. Combine quality, safety, security, operational and user measures rather than relying on one score.
- Release in stages. Begin with bounded users and permissions. Expand only when evidence supports the change.
- Monitor use and outcomes. Track corrections, escalations, incidents, review effort, completion and realised value.
- Control changes. Retest meaningful changes to models, data, prompts, tools, permissions and purpose.
- Plan the stop. Know how to pause, fall back, investigate and retire the system safely.
Supersede Media AI treats governance as part of product and workflow design. The aim is not to produce the largest policy pack. It is to create enough clarity, evidence and control for useful systems to operate without hiding risk from the people responsible.
Further reading: NIST AI Risk Management Framework, UK government Introduction to AI assurance and ICO AI and data protection risk toolkit.
Frequently asked questions
What is AI governance?
AI governance is the set of decision rights, responsibilities, policies, processes and evidence used to direct and oversee AI across its lifecycle. In practice, it should make clear who owns an outcome, what a system may do, how it is evaluated and when it must be changed or stopped.
How is AI assurance different from governance?
Governance defines how decisions and accountability work. Assurance measures, evaluates and communicates evidence about whether the system is trustworthy, works as intended, has known limitations and has appropriate controls.
Does every AI use case need the same controls?
No. Controls should be proportionate to the data, people affected, autonomy, reversibility, legal duties and consequence of error. A low-risk internal drafting aid and a system influencing consequential decisions require different levels of evidence and oversight.
How do you measure AI reliability?
Use measures tied to the workflow, including task completion, corrections, rejections, escalations, failure types, review time, incidents, user impact and realised value. Model accuracy may be one measure, but it is not a complete view of system reliability.