A contact centre can have an AI policy, an approved supplier and a named owner, and still have half its people pasting customer detail into a chatbot nobody assessed. The policy is not the governance. The governance is whether the approved path is the easiest one to take on a busy Tuesday.
What follows is what an AI governance process actually covers in a UK contact centre, which standards procurement and compliance will raise, and what has to exist on paper before an AI agent goes anywhere near a live queue.
What does an AI governance process actually cover?
Four things, in every framework worth reading. A record of what the system does and whose data it touches. An assessment of what happens when it gets something wrong. A named person accountable for the decision to run it. Evidence that a human can see what it did and step in.
Everything else is detail hung off those four. Most organisations we assess have the first and the third. They are weakest on the second, because nobody wants to write down the failure modes of something they have already bought, and on the fourth, because oversight gets designed after go live rather than before it.
Scope matters more than people expect. An AI agent answering billing queries, a summarisation tool writing up calls, and a quality system scoring agents are governed differently, because the risk to the person on the other end is different in each. Treating them as one AI programme is how firms end up with governance that is too heavy for the harmless use and too light for the one that matters.
Which standards will procurement and compliance ask about?
Two come up repeatedly. ISO/IEC 42001 is the management system standard for AI, structured like ISO 27001, covering policy, roles, risk assessment and continual improvement. The NIST AI Risk Management Framework is the other, built around four functions: govern, map, measure and manage.
Neither is a legal requirement in the UK. Both are what a compliance function reaches for when asked to approve something it has no precedent for, and what enterprise procurement teams increasingly put in questionnaires. Knowing which one your supplier certifies against, and which one your own business is being measured by, saves a fortnight of circular email.
A word of caution on certification. A platform holding ISO 42001 tells you how that supplier manages its own AI development. It says nothing about whether your configuration of it is safe. The assessment of the deployment stays with you.
Does the EU AI Act apply to a UK contact centre?
Often, yes. The Act reaches providers and deployers outside the EU where the output of the system is used inside it. A UK business handling calls or chats from EU customers is in scope even though the UK has no equivalent statute.
Three obligations land on contact centres specifically. People must be told they are interacting with an AI system rather than a person. Systems classified as high risk carry human oversight requirements, which means a named route for a person to intervene rather than a theoretical one. And there is an AI literacy obligation, which in practice means your agents and supervisors need to understand what the system does and where it fails.
The obligations are phasing in rather than arriving at once, so check the current position against the text rather than against a summary written last year. The direction is settled even where the dates are not.
What does UK data protection require on top of that?
The parts that bite in a contact centre are narrower than people assume, and easier to get wrong. UK GDPR restricts decisions taken solely by automated means where they have a legal or similarly significant effect on someone. An AI agent that routes a call does not meet that bar. One that declines a claim or a credit application does.
Then there is the recording itself. Transcription for AI training is a different purpose from recording for quality or dispute resolution, and it needs its own lawful basis rather than inheriting the old one. Retention is where this usually unravels. Call recordings might be kept for six years under a regulatory obligation while transcripts and AI outputs sit on a platform with a default retention nobody has looked at.
Data residency deserves a direct question rather than a reassuring answer. Ask where the transcript is processed, where it is stored, whether the model provider retains it, and whether any of that changes when a feature is enabled. Suppliers answer that question well when it is asked precisely and vaguely when it is not.
What documentation gets an AI agent signed off internally?
A workable pack runs to six documents. Most organisations already have versions of four of them sitting in other programmes.
- A system description in plain English: what it does, what it cannot do, which data sources it reads and what it is allowed to write to.
- A data protection impact assessment covering the new purpose, not a copy of the one written for the phone system.
- A risk assessment that names the failure modes and what each one costs, including the wrong answer given confidently.
- Test evidence from real traffic, not a scripted demo, with the containment and escalation numbers that came out of it.
- The oversight design: who reviews what, how often, and what triggers a human taking over mid conversation.
- A rollback position, because the question every board asks is how quickly it can be switched off.
On who signs, the usual set is the data protection lead, the operations owner who carries the service, and IT security. In a regulated business the compliance function joins them, and in financial services the accountability sits with a named senior manager whether or not anyone has said so out loud. Getting that name agreed early is the single biggest saving on approval time we see.
Why does governance fail when the policy is good?
Because people route around friction, and leadership tends not to know it is happening. The clearest measurement of this comes from the legal sector, where the stakes are high enough that somebody went and counted.
59% of UK legal professionals admitted using unapproved AI applications, including free ChatGPT, for client work. In the same research, 68% of firm leaders believed they had full visibility of AI use and faced zero risk of unapproved deployment.
That research, run by Censuswide for Access Legal across 200 legal professionals and 100 legal leaders and published in May 2026, put paralegal use at 71%. It also found that half of fee earners wanted AI inside their case management system while only a quarter of firms had it. The gap between those two numbers is the whole problem, and it is not a training problem.
The consequences stopped being theoretical this year. In Munir v Secretary of State for the Home Department, the Upper Tribunal observed that uploading confidential documents into open source AI tools waives client confidentiality and legal professional privilege. Several major firms have since written the same warning to their own people.
A contact centre is not a law firm, but the mechanism is identical. Where the approved tool is slower, harder to reach, or missing from the screen someone works in all day, a proportion of your people will use something else with customer data in it. Prohibition does not fix that. Availability does.
Where to start if none of this exists yet
Before writing a policy, run an audit of what is already in the building. Which AI capability is already licensed inside the platforms you pay for, who has access to it today, what it is configured to do, and what leaves your estate when it runs. In our experience most organisations are surprised twice: by capability they own and have never switched on, and by tools in daily use that appear on no register.
That audit is also the cheapest governance you will ever do, because it tells you which of the six documents above you actually need and for what. Write the policy afterwards. A policy written first describes a business you do not have.