AI Voice Agent Compliance Checklist for UK Contact Centres: Everything You Need to Verify Before Go-Live

Arkadas Kilic 11 min read · 2026-06-08

Rel8 CX is an AWS Advanced Partner that builds autonomous AI voice agents for regulated UK contact centres, delivering production deployments in 4 to 6 weeks. This checklist is drawn from real go-live processes across financial services, collections, and insurance clients.

Deploying an AI voice agent in a regulated UK contact centre is not the same as deploying one anywhere else. You're operating under a layered compliance framework: FCA Consumer Duty, UK GDPR, Ofcom's rules on automated calls, PCI DSS if you're handling card payments, and sector-specific obligations that vary by vertical. Miss one item and you're not just facing a failed audit. You're facing enforcement action, customer complaints to the FOS, and reputational damage that takes years to recover from.

Most AI vendors hand you a system and walk away. We've done enough go-lives in regulated environments to know that the last 20% of a deployment, the compliance verification phase, is where projects either succeed or quietly die. This checklist covers what we actually verify before we flip the switch.

Who Should Use This Checklist

This is for:

• Contact centre operations leaders preparing for an AI voice agent go-live
• Compliance and risk teams reviewing AI deployments for sign-off
• Technology leads building on Amazon Connect or similar platforms
• Procurement teams evaluating vendor readiness

It's not a theoretical framework. Every item here maps to a real regulatory requirement or a real failure mode we've seen in production.

The UK Regulatory Landscape for AI Voice Agents

Before the checklist, here's the framework you're operating in. Most teams underestimate how many regulators have jurisdiction over a single AI voice call.

You may not be subject to all of these. But if you're in financial services, collections, or insurance, you're almost certainly subject to at least four.

The Checklist

1. FCA Consumer Duty

Consumer Duty came into force in July 2023 and it fundamentally changed what "good" looks like for automated customer interactions. The FCA is explicit: firms cannot use automation to deliver outcomes that would be unacceptable from a human agent.

• [ ] The AI voice agent can identify signals of customer vulnerability (financial distress, emotional distress, cognitive difficulty) and route to a human agent within a defined threshold. We typically configure this to trigger within 2 exchanges of a vulnerability signal.
• [ ] The agent does not use dark patterns: urgency language, misleading framing, or pressure tactics that a human agent would be prohibited from using.
• [ ] Outcomes monitoring is in place from day one. You need data showing the AI is delivering fair outcomes, not just completing calls. Define your baseline metrics before launch.
• [ ] The agent can handle "I want to speak to a human" at any point in the call, without friction. This is not optional. The FCA's guidance is clear that customers must be able to exit automated journeys easily.
• [ ] Your firm has documented the AI's decision logic at a level sufficient to explain outcomes to a customer or to the FOS. Black-box models with no explainability are a regulatory liability.
• [ ] Vulnerable customer pathways have been tested with synthetic scenarios, not just happy-path calls. We run a minimum of 47 vulnerability scenario tests before sign-off on any financial services deployment.

2. UK GDPR and ICO Requirements

Every AI voice call processes personal data. The question isn't whether GDPR applies. It's whether you've documented your compliance position well enough to defend it.

• [ ] Lawful basis for processing is documented. For most contact centre use cases this is legitimate interests or contract performance, but it must be recorded in your ROPA (Record of Processing Activities).
• [ ] If the AI makes any automated decisions with legal or significant effects (credit decisions, debt prioritisation, eligibility determinations), you have a DPIA in place and have identified the lawful basis for automated decision-making under Article 22.
• [ ] Call recording consent is handled correctly. If you're recording AI-handled calls (you should be, for QA and compliance), the consent mechanism must be equivalent to what you'd use for human-agent calls.
• [ ] Data minimisation is enforced at the infrastructure level. The AI should not retain or log more data than it needs to complete the interaction. We enforce this via Lambda-level data scrubbing before anything hits long-term storage.
• [ ] Retention schedules are defined and automated. "We'll review it quarterly" is not a retention schedule. Automated deletion jobs must be in place before go-live.
• [ ] Your AI vendor's data processing agreement is signed and covers sub-processors (the LLM provider, the telephony platform, any third-party integrations).
• [ ] If any call data leaves the UK or EEA, you have a transfer mechanism in place (adequacy decision, SCCs, or BCRs).

3. Ofcom Rules on Automated Calling

Ofcom's rules on automated and predictive dialling are specific and enforceable. They're also frequently misunderstood by teams who've only operated in inbound contact centres.

• [ ] If the AI is making outbound calls, your abandoned call rate is below 3% over any 24-hour period. Ofcom's threshold is strict and measured across all campaigns, not per campaign.
• [ ] Abandoned calls play an information message within 2 seconds of the called person saying hello. The message must include the company name and a freephone number.
• [ ] CLI (Caller Line Identification) is presented on every outbound call. Withheld numbers are non-compliant. The CLI must be a number the customer can call back on.
• [ ] You are not calling numbers registered with the Telephone Preference Service (TPS) unless you have specific prior consent. Your dialler suppression list must be updated at least monthly.
• [ ] Call frequency limits are enforced at the system level, not just in policy documents. If your system can physically make 4 calls to the same customer in a day, your policy saying "maximum 2" is not a control.
• [ ] If the AI identifies itself, it does so accurately. Ofcom and the FCA both have concerns about AI systems that mislead customers about whether they're speaking to a human.

4. PCI DSS v4.0 (If Handling Card Payments)

If your AI voice agent takes card payments, you're in scope for PCI DSS. v4.0 introduced new requirements that affect AI-assisted payment flows specifically.

• [ ] DTMF masking is active. When a customer enters card digits via keypad, those tones must be masked in the call recording and suppressed from any real-time transcription stream. This is a hard requirement, not a best practice.
• [ ] The AI does not speak back card numbers, CVVs, or expiry dates at any point in the call flow.
• [ ] Your payment processing path is out of scope for the AI's data environment where possible. The cleanest architecture routes the customer to a DTMF-only payment IVR for card capture, with the AI rejoining after. This keeps your AI infrastructure out of PCI scope.
• [ ] If you're using real-time transcription (e.g. for agent assist or QA), the transcription pipeline is either excluded from card capture moments or is certified to handle cardholder data.
• [ ] Your QSA has reviewed the AI voice agent architecture. Don't assume your existing PCI scope assessment covers a new AI layer. It almost certainly doesn't.
• [ ] Agent-assisted payment flows (where a human agent uses AI suggestions during a payment call) are assessed separately. The human agent's screen must not display full card numbers.

5. Debt Collection and CONC (If Applicable)

If you're in collections, you're operating under the FCA's Consumer Credit sourcebook (CONC) as well as Consumer Duty. The FCA has been explicit that CONC obligations apply equally to automated and human interactions.

• [ ] The AI does not contact customers at times prohibited by CONC (generally before 8am or after 9pm, and not on Sundays without consent).
• [ ] Contact frequency limits are enforced at the system level. CONC does not specify a hard number but the FCA's guidance and FOS decisions suggest more than 3 contacts per week without response is likely to be considered harassment.
• [ ] The AI can identify and record customer payment arrangements and immediately suppress further collection contact for that account.
• [ ] Breathing space (Debt Respite Scheme) suppression is automated. If a customer is in breathing space, the system must suppress all collection contact without relying on a human to action it.
• [ ] The AI's script has been reviewed by a compliance officer against CONC 7 (arrears, default, recovery). This is not a legal nicety. It's a sign-off requirement.
• [ ] Vulnerable customer identification is more sensitive in collections than in any other vertical. Your vulnerability detection threshold should be lower, not higher, than in a standard service context.

6. Operational and Technical Controls

Beyond the regulatory specifics, there are operational controls that every production AI voice agent deployment needs before go-live.

• [ ] A kill switch exists and has been tested. You must be able to take the AI offline in under 5 minutes without taking down your entire contact centre. We build this as a feature flag in AWS, not a manual infrastructure change.
• [ ] Human escalation SLAs are defined and monitored. If the AI transfers a call to a human agent, what's the maximum wait time before that becomes a compliance issue? Define it, measure it.
• [ ] Fallback behaviour is specified for every failure mode: LLM timeout, AWS service degradation, CRM unavailability. "Falls back to human" is not a specification. "Plays hold message X, transfers to queue Y within 8 seconds" is.
• [ ] QA sampling is in place from day one. We recommend a minimum of 5% of AI-handled calls reviewed in the first 30 days. That's not a random sample. It should be stratified: vulnerability triggers, complaints, payment arrangements, and escalations reviewed at 100%.
• [ ] Your complaints process covers AI-handled interactions. A customer who had a bad experience with your AI agent must be able to complain, and your complaints team must be able to reconstruct what happened. This requires call recording, transcription, and interaction logs to be linked at the case level.
• [ ] Staff training covers AI handoff scenarios. Human agents receiving transfers from the AI need to know what context the AI has already gathered, how to access it, and how to handle customers who are frustrated by the automated interaction.
• [ ] Your incident response plan covers AI-specific scenarios: the AI giving incorrect information at scale, a prompt injection attack, a data leak from the transcription pipeline.

7. Pre-Launch Testing Requirements

Compliance verification is not the same as functional testing. These are the specific tests that need to pass before a regulated go-live.

These aren't aspirational targets. They're the minimum bar we require before signing off a go-live.

Frequently Asked Questions

The firm is responsible, not the vendor. Your AI vendor can build compliant architecture, but the regulatory obligation sits with the regulated entity. Your MLRO, Head of Compliance, or equivalent must sign off before go-live.

In our experience, 2 to 3 weeks if the compliance groundwork has been done in parallel with the build. Teams that leave compliance to the end typically add 4 to 6 weeks to their timeline. We build compliance controls into the architecture from week one, not as a final gate.

Yes. The FCA has confirmed that Consumer Duty applies to all customer interactions, automated or otherwise. The obligation to deliver good outcomes does not have a carve-out for AI.

You need a documented remediation process and a kill switch. Regulators are more concerned about your ability to identify and fix problems than about perfection at launch. But you need to be able to demonstrate both.

What We See Most Teams Get Wrong

After building production AI voice agents for regulated UK contact centres, here's where teams consistently fall short:

1. Vulnerability detection is an afterthought. Teams spend 80% of their testing budget on happy-path calls and 20% on edge cases. Regulators will look at the edge cases first.

2. Compliance sign-off happens too late. If your compliance team sees the AI for the first time two weeks before go-live, you've already got a problem.

3. Sub-processor chains are undocumented. The DPA with the primary vendor is signed. The sub-processors processing UK customer voice data are not.

4. Outbound calling rules are underestimated. Teams with inbound heritage don't have Ofcom's outbound rules in their muscle memory. The abandoned call rate calculation catches them every time.

5. There's no kill switch. "We can take it down if we need to" is not a kill switch. A tested, documented, sub-5-minute shutdown procedure is.

How Rel8 CX Approaches Compliance

We don't treat compliance as a final gate. It's built into the architecture from the first sprint.

On every regulated deployment, we:

• Embed compliance controls at the infrastructure level (Lambda-level data scrubbing, DTMF masking in the telephony layer, automated retention schedules via S3 lifecycle policies)
• Run the full pre-launch testing matrix above before any go-live conversation
• Deliver compliance documentation packs that your internal compliance team can use for sign-off and ongoing audit
• Build kill switches and fallback flows as standard, not optional extras

We go from contract to production in 4 to 6 weeks. That timeline includes compliance verification, not despite it.

Ready to Build a Compliant AI Voice Agent?

If you're planning an AI voice agent deployment in a regulated UK contact centre and you want to get compliance right from the start, let's talk through your specific regulatory context.