Photo by AI25.Studio Studio on PexelsAI assurance
AI Assurance: Creating Safe Paths Through AI
Responsible AI depends on understanding where AI is really being used, creating practical routes for using it well, and testing whether those routes work.
The gap is not simply between compliant and non-compliant behaviour. It is between formal governance and the routes people can actually use when work, deadlines and sensitive information collide.
Responsible AI depends on more than policies and restrictions.
Organisations need to understand where AI is really being used, provide practical routes for using it well, and test whether those routes work.
It is Monday morning. A manager has a lengthy meeting transcript, a board deadline and several hours of other work waiting.
The organisation has an AI policy. It advises staff not to place confidential material into public AI services. That is sensible. What it does not provide is an approved alternative for summarising the transcript, extracting the decisions and producing a usable first draft.
So the manager removes the names, opens a personal AI account and pastes in the text.
They are not trying to evade governance. They are trying to do their job.
That distinction matters, because it reveals something about the way many organisations are approaching artificial intelligence. Policies are being written. Restrictions are being communicated. AI committees are being created. Yet the practical routes through which people can use AI safely, visibly and productively are often much less developed.
This creates a gap between formal governance and operational reality.
Inside that gap sits shadow AI: public tools used without approval, meeting bots invited into sensitive conversations, browser extensions added by individual teams, AI features activated inside existing software, and supplier systems whose underlying models or data practices are poorly understood.
The answer cannot simply be to prohibit more. Nor is it to make every use of AI pass through a heavyweight approval process.
Organisations need safe paths through AI: approved, usable ways of completing valuable work, with appropriate controls built into the workflow rather than left as warnings in a policy document.
AI assurance is how boards gain confidence that those paths exist, that people are using them, and that they remain safe as the technology, the workflow and the organisation change.
This is also an Internal Audit challenge. Boards need independent confidence that actual AI use aligns with governance, objectives and risk appetite. Internal Audit can test whether the controls and governance described by management operate in practice: across real workflows, decisions, suppliers and changes to the technology. That evidence matters more than policy statements, registers or management reporting taken at face value.
AI use is moving faster than organisations can see it
AI is no longer confined to experimental teams or formal transformation programmes.
In June 2026, the Office for National Statistics reported that 29% of UK businesses were using at least one type of AI technology, eight percentage points higher than a year earlier. Among businesses with 250 or more employees, adoption had reached 49%. Text generation using large language models was the most commonly reported use, followed by visual content creation.[1]
Those figures capture what businesses recognise and report as AI use. The operating reality is likely to be less tidy.
AI can enter an organisation through an obvious procurement decision, but it can also appear through an update to software the organisation already owns. A transcription service may be introduced by one team. A developer may install an AI coding extension. A supplier may add automated recommendations to its platform. An employee may use a personal account to draft, translate, classify or summarise work.
Some of this activity will be harmless and useful. Some will involve information or decisions that deserve much greater care.
The first assurance problem is therefore not necessarily whether AI is being used responsibly. It is whether the organisation can see enough of its real AI use to answer the question.
The UK Cyber Security Breaches Survey illustrates how quickly adoption and control can become separated. Around 31% of businesses surveyed were using AI, adopting it or actively considering it. Of that group, only 24% reported having cybersecurity practices or processes in place to manage AI-related risks.[2]
That is not proof that the remaining businesses had no AI governance at all. It does show that interest in AI is spreading more quickly than AI-specific risk practices.
Internal audit leaders recognise the wider pressure. The Institute of Internal Auditors’ Risk in Focus 2026 research found that digital disruption, including AI, was considered a top-five organisational risk by 48% of respondents, while only 32% placed it among internal audit’s five highest priorities.[3]
The risk has moved up the agenda. Assurance coverage is following, but not yet at the same pace.
Photo by Yan Krukau on PexelsAdoption is outpacing control
UK businesses using at least one type of AI technology
Increase from the previous year
Businesses with 250 or more employees using AI
AI users, adopters or active considerers with AI-related cybersecurity practices
Different routes, same evidence burden
Regulatory philosophies differ
The routes differ in form: the EU is legislative, the UK is principles-led and sector-based, and the US combines voluntary frameworks with sector and national-security evaluation.
The assurance demand converges
Across all three, organisations still need visibility, accountable ownership, proportionate controls, continuing monitoring and evidence.
Shadow AI is bigger than staff using ChatGPT
Shadow AI is often described as employees using public generative AI tools without permission. That is certainly part of it, but it is not the whole problem.
Photo by Oktay Köseoğlu on PexelsA better definition is:
That may include a member of staff pasting information into a public chatbot. It may also include a supplier using AI inside a service without explaining how, a department buying an AI-enabled product outside the normal technology process, or a feature arriving through a routine software update.
The UK Government’s AI Playbook draws attention to several different deployment routes: public AI applications, embedded functionality, plugins and extensions, public APIs, privately hosted models and locally operated open-source systems. It specifically highlights the risks associated with third-party transcription tools silently uploading meetings for processing.[7]
This matters because traditional asset-management and procurement processes may not identify all of these routes.
An organisation might have no formally approved generative AI programme and still have significant generative AI activity.
Its customer platform may draft replies. Its recruitment software may rank applications. Its security product may classify behaviour. Its meeting software may summarise conversations. Its marketing tools may create personalised content. Its employees may use AI search, translation and document-analysis features throughout the working day.
The question “Do we use AI?” has become too broad to be useful.
The better questions are where AI enters the organisation’s work, what information it can reach, what it produces, which people or decisions are affected, and who would know if its behaviour changed.
The aim is not to create an inventory of every automated feature in the organisation. It is to identify uses that may materially affect confidentiality, security, fairness, decisions, customer outcomes, legal obligations or the organisation’s ability to achieve its objectives.
Prohibition can create false confidence
Photo by Mikhail Nilov on PexelsAn organisation can reduce some risk by blocking public AI services, restricting plugins and telling staff not to upload sensitive information.
Those controls may be necessary. They are rarely sufficient.
Where people see a genuine benefit in AI, a ban does not always remove the use. It may simply remove it from view.
This is not an argument for indulging every employee preference. There are uses that should be prohibited, and organisations must be prepared to enforce those boundaries.
It is an argument for understanding why workarounds emerge.
Someone may use an unofficial tool because the approved process takes too long. An approved enterprise product may exist, but employees may not know about it. The organisation may have licensed a tool without giving people meaningful examples of what it can safely do. Approval may involve several committees but no clear decision owner. Policies may distinguish between public and confidential information in terms that make sense to specialists but not to the person doing the work.
In these circumstances, repeated workarounds are not only evidence of employee non-compliance.
They may also be evidence that the control has been poorly designed.
A control that looks strong on paper but consistently pushes legitimate work into unofficial channels is not necessarily reducing risk. It may be moving risk into places where it is harder to detect.
This is where assurance must look beyond the existence of policy.
It should ask whether the organisation’s intended behaviour is realistic, whether the approved route meets a genuine user need, and whether management information reflects actual rather than declared use.
Creating paved paths through AI
There is a useful idea in modern technology delivery: the paved path.
Photo by Julia Filirovska on PexelsA paved path is a recommended and supported way of doing something. It provides sensible defaults, known tools and built-in protections, while remaining useful enough that people choose it rather than trying to route around it.
Applied to AI, a paved path is not simply an approved product.
It is an approved way of completing a defined piece of work.
It may bring together a suitable AI service, clear data boundaries, access controls, approved source material, an effective interface, records of inputs and outputs, a defined human review, exception handling and monitoring appropriate to the risk.
The National Cyber Security Centre advises system developers to make it easy for users to do the right thing and, where possible, to make secure configurations the default.[8]
That principle is just as valuable for AI governance.
The safest route should not be so slow, confusing or detached from operational needs that the unofficial route becomes more attractive.
Consider the difference between two organisations.
The first publishes a broad AI policy. Staff must not use unapproved tools or place confidential information into AI systems. New use cases require permission from security, legal, data protection and procurement. The controls are defensible, but the organisation has provided no practical workflows, no list of approved tasks and no visible route for experimentation.
Management sees very few declared AI uses and concludes that exposure is low.
The second organisation sets the same core boundaries, but also provides approved routes. Staff can summarise non-sensitive documents in one tool. A controlled workflow is available for internal material. Customer-facing drafts require a named reviewer. High-impact use cases are escalated. New ideas can be proposed through a short triage process. Guidance is built around recognisable tasks rather than abstract warnings.
The second organisation has not removed AI risk. It has made more of that risk visible and governable.
Its controls operate in the same place as the work.
That is what makes the path capable of being assured.
| Policy without a path | A paved AI path |
|---|---|
| Broad restrictions | Defined use cases |
| Unclear approved uses | Approved tools and data boundaries |
| Slow permission process | Proportionate triage and escalation |
| Training centred on prohibited behaviour | Guidance centred on real work |
| Low reported adoption | Visible adoption through approved routes |
| Limited evidence of actual behaviour | Logging, monitoring and evidence |
Good AI governance does not merely tell people where they cannot go. It gives them a viable way forward.
Photo by Maor Attias on PexelsPolicy without a path
Policy without a path
Controls may be defensible, but staff have no practical route through real work and assurance sees little evidence of actual behaviour.
A paved AI path
Approved routes translate policy into usable workflows that can be seen, governed and tested.
The workflow, not the product, is the proper unit of assurance
An AI register may tell the audit committee that the organisation uses Microsoft Copilot, an internal language model or a particular customer-service platform.
That does not reveal enough about risk.
The same AI product may be used to generate informal ideas from public material, summarise sensitive records, advise a customer, rank job applicants or initiate actions in another system.
The model may be identical. The consequences are not.
AI risk is shaped by the workflow around the technology: the task the system has been given, the information it receives, the systems it can access, the people affected by its output, the degree of autonomy it has, the human judgement around it, and the organisation’s ability to identify and correct failure.
This makes workflow assurance more useful than product approval alone.
Consider an AI-assisted complaints process.
An organisation introduces AI to summarise customer complaints and draft suggested responses.
The approved description says the AI is only assisting staff. A human remains responsible for every response.
At first glance, this appears low risk.
Looking at the workflow may reveal something different.
Complaint records can include financial, personal and occasionally medical information. The AI summary becomes the main version read by busy staff. The original correspondence is rarely checked unless the customer challenges the outcome. Suggested responses are well written, so reviewers tend to concentrate on tone rather than accuracy. The workflow records that a review took place, but not what was checked or changed.
No individual control appears obviously reckless. Together, however, they may create an environment in which a confidently incomplete summary shapes the organisation’s response to a vulnerable customer.
Assurance should therefore go further than confirming that a human clicked “approve”.
It should examine whether the information was appropriate for the system, whether the intended purpose was clearly defined, whether staff understood the model’s limitations, whether reviewers had access to the original evidence, whether they had enough time and authority to challenge the draft, whether unusual cases were escalated and whether management could detect if AI-assisted outcomes were deteriorating.
The phrase “human in the loop” is often presented as though it completes the control design.
It does not.
A human presence is not evidence of human judgement.
Photo by Kampus Production on PexelsThe workflow is the unit of assurance
An AI register may name the product, but risk is shaped by the task, the information, the people affected, the human judgement around the output and the organisation’s ability to identify and correct failure.
When private or on-premises AI creates a safer route
Public AI services are not the only option.
Photo by Brett Sayles on PexelsFor some organisations, a privately hosted or on-premises system may form part of a safer path for sensitive work. A private model might allow employees to search technical manuals, summarise internal policy, query case files or work with commercially confidential material without sending the content into a public consumer service.
The UK Government’s AI Playbook identifies privately hosted models as a distinct deployment route. It notes the benefit of greater control over the model and the data it consumes, while also making clear that the organisation becomes responsible for security, updates, infrastructure and the specialist capabilities required to operate it.[7]
That is the essential trade-off.
On-premises AI does not remove the need for assurance.
It moves more of the assurance burden inside the organisation.
Imagine a business that places a private language model over thousands of technical, contractual and operational documents. Staff can ask questions in natural language and receive an immediate response grounded in the organisation’s own material.
The board may initially be reassured by one fact: the data does not leave the organisation’s environment.
That is useful, but it is not the whole assurance case.
A proper review would also need to establish who supplied the model and its components, how it was evaluated before release, which documents each employee can retrieve, how obsolete material is removed or identified, whether malicious content inside a document could manipulate the answer, how prompts and outputs are logged, how updates are assessed, whether the system can cite the material behind its response, how incorrect answers are detected and what happens when the service is unavailable.
Hosting location addresses one category of risk. It does not establish the trustworthiness of the service.
In some cases, a controlled API, managed private-cloud environment or carefully configured enterprise product may offer a better balance than running a model on the organisation’s own infrastructure. In others, an on-premises deployment may be justified by information sensitivity, resilience needs or operating context.
The purpose of assurance is not to favour one architecture.
It is to test whether the chosen route matches the organisation’s actual needs, capabilities and risk appetite.
Why Internal Audit has a distinctive role
Photo by Vlada Karpovich on PexelsThe Institute of Internal Auditors’ AI Auditing Framework provides a useful foundation for assessing governance maturity, AI-related risks and controls over data, algorithms and cybersecurity.[9]
The framework is principles-based and adaptable. It does not, by itself, establish that governance works.
The practical challenge is to turn that mandate into evidence over AI use that can enter through many routes and change quickly.
Internal Audit should not own the AI strategy, select models or design controls.
Management owns AI risks and controls. Specialist, risk and compliance functions provide oversight and expertise. Internal Audit provides independent assurance.
Its distinctive contribution is independent challenge.
It can compare the governance story presented to the board with operating reality.
That means testing whether management can see material use, whether approved routes attract real work, whether risk ratings reflect the workflow, whether human review can detect meaningful error and whether supplier claims are supported.
It should also consider AI within existing audits of procurement, HR, customer operations, cybersecurity and third-party management.
Treating AI only as a standalone subject risks missing where it has already changed the work being assured.
The aim is not to slow adoption.
It is to identify where stated controls and real behaviour diverge, and why.
This is where AI assurance connects with Littlechild & Haley’s Success-centred Assurance™ approach.
Independent assurance should show whether governance protects the organisation while supporting its objectives.
An organisation can be compliant and still have unusable controls; it can also move quickly without creating value.
Good assurance makes that distinction visible.
Visibility, Paths and Proof
A compact assurance model for moving from governance claims to tested operating evidence.
Visibility
Can the organisation see its material AI use, with enough context to understand workflow, data, people affected and consequences?
Paths
Has the organisation created controlled and usable ways of working with AI, built around defined workflows and meaningful oversight?
Proof
Can the organisation demonstrate that those paths work through testing, logs, sampled outputs, incidents, supplier assurance and independent review?
- VisibilityPathsSeen use can be shaped
- PathsProofDesigned routes can be tested
- ProofVisibilityEvidence improves the view
Photo by RDNE Stock project on PexelsFrom claim to assurance test
We know where material AI is used
Examine inventory, procurement records, software estate, staff declarations and supplier reviews. Reconcile the inventory against a sample of departments, systems and suppliers.
Humans review important outputs
Examine workflow records, review guidance, exceptions and override logs. Sample cases to establish what was reviewed, by whom and whether challenge was meaningful.
Sensitive information stays within our environment
Examine architecture, data flows, contracts, retention settings and subprocessors. Trace representative data through the service and its dependencies.
Our AI supplier is appropriately controlled
Examine due diligence, assurance reports, incident terms, model documentation and change notices. Test whether evidence covers the actual use case and material changes trigger review.
The system continues to perform as intended
Examine quality measures, complaints, incidents, drift monitoring and outcome data. Compare live outcomes with agreed tolerances and inspect management’s response to deterioration.
Visibility is not the same as maintaining a spreadsheet
An AI inventory is an important starting point, but it can create its own false reassurance.
A list updated once a year may record yesterday’s AI estate while missing the features, suppliers and workflows introduced since.
The inventory should be connected to the places where change happens: procurement, software updates, data-protection assessments, technology architecture, programme governance, supplier management, information security, incident reporting and internal audit planning.
Materiality also matters.
Not every AI feature deserves the same depth of governance. An internal drafting assistant using public information is not equivalent to a system affecting employment, eligibility, safety, healthcare or access to an essential service.
Risk attaches to the use of the system, not merely to the technology label.
A low-impact tool may still create material risk when used at scale or when its output quietly enters a more consequential process. A powerful model may be used safely within a narrow, well-controlled task.
Visibility therefore requires more than naming the tool.
It requires enough context to understand what could happen if it is wrong, misused, unavailable or changed.
What the audit committee should expect to see
Audit committees do not need a catalogue of models or a technical lecture.
They need an evidence-based view of material exposure, control effectiveness and the limits of current assurance.
The Committee should expect periodic Internal Audit assurance over whether material AI use is visible and governed in practice.
Reporting should distinguish between what management knows, what it believes and what has been independently tested.
It should show whether approved paths are followed, whether human and supplier controls work, and where evidence remains incomplete.
One useful measure is inventory confidence: the strength of the evidence that material uses have been identified, not the number recorded.
That supports a more honest discussion of uncertainty.
A small inventory may indicate limited use; it may also indicate limited discovery.
The Committee should also ask whether official routes are being adopted or bypassed in real work.
The board-level question is whether management’s account is supported by evidence.
It is:
Can management demonstrate that the organisation’s real use of AI matches the governance story being presented to the board?
Frameworks help organise the work. They do not prove it is working
Organisations do not need to invent AI governance from nothing.
ISO/IEC 42001 provides requirements for establishing, maintaining and continually improving an AI management system. NIST’s AI Risk Management Framework offers the functions Govern, Map, Measure and Manage. The EU AI Act establishes legal requirements for particular systems and models. UK guidance describes assurance mechanisms and practical principles for safe, responsible deployment.[4][5][6][10]
These are valuable foundations.
They provide shared language, structure and discipline. They can help organisations define expectations, identify gaps and connect AI governance to existing management systems.
They should not be mistaken for the assurance conclusion.
A framework can organise the questions. A certification can provide useful evidence about a management system. A supplier report can improve confidence in particular controls.
None automatically proves that a particular AI workflow is appropriate, that staff use it as intended or that it produces acceptable outcomes in the organisation’s own context.
That still requires judgement, evidence and testing.
A practical starting point
Organisations do not need to solve every part of AI governance before beginning assurance work.
A useful first review can focus on one material workflow.
Choose something real: AI-assisted customer service, document search, AI-enabled recruitment, fraud analysis, programme reporting or internal knowledge management.
Then follow it from beginning to end.
What starts the workflow? What data enters it? Which systems and suppliers are involved? What does the AI produce? Who relies on the output? Where is human judgement expected? What is recorded? What could cause harm? How would the organisation know?
That exercise often reveals more than a broad policy review because it shows how governance behaves under operational pressure.
From there, the organisation can widen its view by identifying similar workflows, improving the inventory, creating or refining approved paths, clarifying ownership, strengthening evidence requirements and building AI into the wider assurance plan.
AI assurance should ultimately operate at three levels.
At the enterprise level, it should consider strategy, policy, accountability, risk appetite and reporting.
At the use-case level, it should examine AI that has a meaningful effect on people, decisions, services or organisational objectives.
Within existing audit coverage, it should consider where AI has changed the risk profile of procurement, cybersecurity, HR, data, customer operations, programme delivery or third-party management.
The question is not simply whether AI deserves an audit of its own.
It is where AI has already changed the work the organisation intended to assure anyway.
Photo by Pavel Danilyuk on PexelsA practical first review
Organisations do not need to solve every part of AI governance before beginning assurance work. A useful first review can follow one material workflow from beginning to end.
Choose one real workflow
Focus on a material use such as AI-assisted customer service, document search, AI-enabled recruitment, fraud analysis, programme reporting or internal knowledge management.
Follow it end to end
Ask what starts the workflow, what data enters it, which systems and suppliers are involved, what the AI produces and who relies on the output.
Test judgement and evidence
Identify where human judgement is expected, what is recorded, what could cause harm and how the organisation would know.
Widen the assurance view
Use the review to improve the inventory, refine approved paths, clarify ownership, strengthen evidence requirements and build AI into the wider assurance plan.
Work at three levels
Consider enterprise governance, material use cases and the places where AI has changed risks within existing audit coverage.
Making responsible AI easier to do
AI governance can become dominated by restriction.
Some restriction is necessary. Certain information, decisions and uses need clear boundaries, and sometimes the right answer is not to use AI.
But governance that only blocks, warns and approves will struggle as AI becomes embedded in ordinary work.
Responsible adoption requires design.
It requires usable tools, proportionate workflows, meaningful human review and routes that hold up under operational pressure.
That is why safe paths matter.
They turn governance from an instruction into an operating model.
Assurance tests whether that model is credible: whether material use is visible, approved routes are followed and controls operate as intended.
The organisations best prepared for AI will not necessarily have the longest policies or the most restrictive controls.
They will be able to explain where AI is used, why each material use is appropriate, who remains accountable, how failure is detected and what evidence supports the trust placed in it.
AI assurance is not about making artificial intelligence risk-free.
It is about creating safe paths through uncertainty, then checking that those paths lead where the organisation believes they do.
Photo by Simon Brice MOUSSI on PexelsGovernance becomes confidence
Responsible AI is not made credible by restriction alone. Organisations need to see the use, shape the path and test the evidence — creating safe paths through uncertainty, then checking they lead where the organisation believes they do.
See the use. Shape the path. Test the evidence.
That is how governance becomes confidence.
How Littlechild & Haley can help
Photo by Vlada Karpovich on PexelsLittlechild & Haley supports organisations in assessing whether AI governance is visible, proportionate and operating in practice.
An initial AI Assurance Readiness Review can examine governance and executive accountability, visibility of material AI use, the maturity of the AI inventory, approved workflows and shadow AI exposure, risk classification, human oversight, third-party assurance, board reporting and the role of AI within the internal audit plan.
The purpose is not to apply a generic checklist or slow down responsible adoption.
It is to identify where confidence is justified, where evidence is incomplete, and what needs to change for the organisation to use AI safely and successfully.
From there, Littlechild & Haley can help translate the findings into proportionate AI governance assurance, integrate AI into the Internal Audit plan, and provide Boards and Audit Committees with an independent view of where confidence is justified.
Sources
- Office for National Statistics, Business Insights and Impact on the UK Economy, 2 July 2026.
- UK Government, Cyber Security Breaches Survey 2025 to 2026.
- Institute of Internal Auditors, Risk in Focus 2026.
- European Commission, official guidance and implementation material for the EU AI Act.
- Department for Science, Innovation and Technology, Introduction to AI Assurance.
- National Institute of Standards and Technology, AI Risk Management Framework, and Center for AI Standards and Innovation materials.
- UK Government, Artificial Intelligence Playbook for the UK Government.
- National Cyber Security Centre, Guidelines for Secure AI System Development: Secure Deployment.
- Institute of Internal Auditors, Artificial Intelligence Auditing Framework, second edition.
- International Organization for Standardization, ISO/IEC 42001: Artificial Intelligence Management System.
Photo by Vlada Karpovich on PexelsExplore
Explore an initial AI Assurance Readiness Review to examine visibility, accountability, approved workflows, shadow AI exposure and board reporting — then translate the findings into proportionate AI governance assurance and the Internal Audit plan.
