Most writing on this subject describes what the technology can do. For a regulated institution that’s the less interesting half of the question, because capability was never the binding constraint.
What limits deployment is whether you can explain a decision afterward, whether the interaction crossed into licensed territory, and whether the record you keep is the one a supervisor would accept.
What Changes When the Contact Centre Is Regulated
An unregulated retailer deploying a virtual assistant faces commercial risk. A bank deploying the same capability faces commercial risk plus supervisory consequence, and the second one moves considerably slower.
Three differences drive nearly everything below:
- Decisions affecting customers must be explicable, sometimes years later, to somebody who was not present
- Communications are records, subject to retention rules that predate any of this technology
- Certain conversations are licensed activities, meaning the content of the exchange determines whether a rule applies
None of that prohibits deployment. It does mean the sequence differs from what a general implementation guide would suggest, and that copying a retail playbook produces something your compliance function will stop.
There’s an organizational wrinkle too. The people who understand what these systems do sit in technology; the people who understand what may be deployed sit in risk and compliance; and in many institutions those groups meet formally rather than continuously. Projects that stall usually stalled at that boundary, months after a vendor selection that nobody in the second group was asked about. Involving them at requirements stage rather than at approval stage costs a few uncomfortable meetings early and saves a rebuild later.
The Real Constraint: Explainability and Record-Keeping
Here’s the reframing I’d offer anybody starting this work. The question is not “is the model accurate enough?” but “can we reconstruct why it produced that output, for this customer, on that date?”
Accuracy is a performance property. Explainability is an evidentiary one, and supervisors care about the second in a way vendors rarely anticipate. A system achieving high accuracy while producing outputs nobody can account for is harder to defend than a less capable system whose reasoning is traceable.
Practical implications:
- Version everything. The model, the prompt, the knowledge source and the configuration all need capturing at the moment of use, since a system that changed last Tuesday cannot explain a conversation from last March.
- Log the inputs and the outputs, not just the outcome.
- Retain the chain, because a summary without its source conversation proves nothing.
- Record the human decision, including when somebody overrode a suggestion and why, since override patterns are among the more useful signals you will collect about whether a system is working.
COPC’s current standard release includes built-in AI governance among its requirements (COPC), which is a reasonable signal that the frameworks buyers assess you against are catching up faster than most deployment plans assume.
Where AI Carries Low Risk: Assisting the Agent
The safest deployments share one property: a qualified human remains accountable for what reaches the customer.
- Real-time speech recognition producing a live transcript the agent can see
- Agent assist surfacing relevant knowledge articles during a conversation
- Next-best-action prompts the agent may accept or ignore
- Post-call summarization drafted for agent review before saving
- Conversational analytics applied to completed interactions for quality and trend work
- Real-time insights flagging compliance phrases an agent should or should not have used
Each of these leaves the accountable human in place. The system proposes; a person decides. That single structural property is what makes this category deployable inside a regulated institution in months rather than years.
Worth being honest about the limits of that reasoning, though. Human oversight only counts where the human genuinely exercises judgment, and a system producing suggestions that agents accept automatically under time pressure has effectively become a decisioning system wearing an assistive label. Monitor override rates. Where they sit near zero across thousands of interactions, the accountability you described in your governance documentation may not be the accountability operating on the floor.
Quality monitoring deserves particular mention, since applying speech analytics to completed conversations lets you review a far larger sample than manual scoring allows. Regulated operations frequently monitor a few percent of calls by hand; automated screening across the full set finds the compliance phrase somebody missed at three in the afternoon.
Where AI Carries High Risk: Deciding or Advising
The picture changes when the system determines an outcome rather than supporting somebody who does.
| Deployment | Human accountability | Risk profile |
| Live transcription | Agent handles the conversation | Low |
| Knowledge retrieval for agent | Agent selects and delivers | Low |
| Draft summary for review | Agent approves before saving | Low |
| Automated identity verification | System decides | Moderate to high |
| Eligibility or affordability assessment | System decides | High |
| Product suitability guidance to customer | System advises | High, potentially licensed |
| Complaint outcome determination | System decides | High |
That table is the article’s argument compressed. Where the technology assists, deploy reasonably quickly. Where it decides, treat the project as a governance exercise that happens to involve software.
The middle rows are the contested ones. Automated identity verification sits awkwardly because it looks operational rather than consequential, yet a wrongly rejected customer experiences a service failure and a wrongly accepted one is a fraud loss. Institutions frequently classify it as low risk on the grounds that it merely checks something, which understates what happens when it checks incorrectly at scale.
The Regulated Advice Boundary
This one gets underestimated, and I think it’s the most likely place for a well-intentioned deployment to go wrong.
In most jurisdictions, advising a customer on the suitability of an investment, an insurance product or a credit facility is a licensed activity. A virtual assistant answering “which account should I open?” or “is this policy right for me?” may have crossed from information into advice without anybody designing it to.
The boundary is rarely bright. Explaining product features is information. Comparing two products on stated attributes is probably still information. Recommending one based on what the customer has said about their circumstances starts looking like advice, and the customer’s perception matters as much as your intent.
Generated language makes this harder than scripted language did. A decision tree says what somebody wrote into it; a model produces phrasing nobody reviewed, and helpfulness is exactly the behavior it was built for. Asked whether a savings product suits someone who has just described their circumstances, an unconstrained system will attempt an answer, and that answer may be perfectly sensible while still being something your institution is not permitted to say through that channel.
TabaTalk recommends writing explicit refusal behavior into any customer-facing deployment in a regulated institution: a defined list of question types the system must decline and route to a qualified person, tested as part of acceptance rather than assumed. Then test it adversarially, because customers phrase things unpredictably and a system trained to be helpful will try.
What Counts as the Record When AI Writes the Summary
A genuinely awkward question, and one I haven’t seen addressed well anywhere.
Financial institutions retain communications with customers. Where a model generates a summary of a conversation and that summary enters the case file, you now hold two artifacts: the recording and a paraphrase. If the paraphrase is subtly wrong, which one is the record?
Sensible practice, as far as I can tell:
- Treat the recording or transcript as the authoritative record, always
- Store generated summaries as derived material, clearly labeled as such
- Require agent approval before a summary is saved, with the approval logged
- Ensure deletion of a source recording also removes its derivatives
That last point catches people out. Transcripts, sentiment scores and generated summaries frequently live in separate stores with their own retention rules, so deleting a recording may leave its derived material in place indefinitely. Worth asking your platform provider directly, and it appears in our CCaaS vendor security questionnaire for that reason.
Retention periods create a second complication. Where regulation requires you to keep customer communications for a set number of years, that obligation attaches to the record rather than to whatever technology produced it, so summaries generated today must remain retrievable and interpretable years from now. A summary referencing a model version and prompt configuration that no longer exists is retrievable without being explicable, which is not quite the same thing as compliant.
Who Regulates a Financial Services Contact Centre in the UAE
Regional operations face a supervisory structure that surprises institutions arriving from other markets, since more than one authority holds a stake.
Under the UAE’s telemarketing framework, the Ministry of Economy supervises implementation, the Telecommunications and Digital Government Regulatory Authority runs the registry consumers use to block marketing calls, the Central Bank covers calls relating to banking, financial and insurance services, and the Securities and Commodities Authority covers securities-related outreach (UAE Ministry of Economy).
The underlying rules sit in Cabinet Resolution No. 56 of 2024, which requires prior approval for telemarketing activity, restricts calling to a defined daytime window, and obliges businesses to disclose the source of their customer database to the regulator on request (UAE Legislation portal; Morgan Lewis).
Read that as a deployment constraint rather than a legal footnote. An automated outbound campaign is still telemarketing when a system places the call, so approval, calling hours and registry screening apply regardless of whether a human dialed. Institutions sometimes assume automation sits outside a framework written before it existed, which is an expensive assumption. TabaTalk’s guide to outbound compliance covers the operational controls.
Arabic Language Performance Is a Real Constraint
Vendor material rarely mentions this, and it determines whether a deployment works in this region.
Speech recognition and language model performance vary substantially by language, and Arabic presents specific difficulty: Modern Standard Arabic differs considerably from the dialects people actually speak, and Gulf, Levantine and Egyptian varieties differ from each other. A customer in Abu Dhabi speaking Emirati Arabic, an agent responding in a Levantine dialect, and a model trained predominantly on Modern Standard Arabic is a combination that produces worse results than an English deployment would.
Code-switching compounds it. Speakers move between Arabic and English mid-sentence routinely here, sometimes mid-phrase for product names and technical terms, and transcription systems handle that unevenly. Financial vocabulary makes it worse again, since account types, regulatory terms and product names frequently stay in English inside an otherwise Arabic sentence, and those are precisely the words a compliance monitoring application needs to capture correctly.
TabaTalk recommends testing any AI capability separately per language and per dialect, using recordings from your own customers rather than vendor demonstrations, and setting different accuracy thresholds per language rather than one global standard. Where transcription quality falls below what a compliance use requires, deploy the capability in the languages where it performs and wait on the others. That’s an unsatisfying answer, and I’d rather give it than pretend the gap isn’t there.
The same applies across Hindi, Urdu and Tagalog for institutions serving the wider resident population.
Voice Authentication and Synthetic Speech
Voice biometrics looked like a clean win for financial institutions: faster verification, less friction, fewer security questions. Synthetic speech has complicated that considerably.
Where voice is a primary authentication factor, generated audio is a plausible attack path, which argues for treating it as one signal among several rather than as proof of identity on its own. Combining voice with device, behavioral and knowledge factors keeps the friction reduction while removing single-factor dependence.
Worth pairing with detection on the other side. Systems flagging suspected synthetic audio during a call give agents something actionable, though the arms race here means any specific capability dates quickly. Ask vendors what they detect, when the capability was last updated, and what happens on a false positive, since wrongly accusing a genuine customer of being synthetic is its own problem.
Consider the internal direction as well. Where staff authorize transactions or approve exceptions by phone, a synthetic voice imitating a senior colleague is a plausible attack on your own controls rather than on your customers. Institutions tend to assess this risk on the customer-facing side first and the internal side considerably later, which is the wrong way round given how much authority moves through internal calls.
Building a Governance Model Before Deployment
Institutions that deploy well tend to have settled these questions first.
- Who owns model risk? Usually an existing model risk function rather than the contact centre, and involving them late is the most common sequencing error.
- What is the approval path for a new capability, and does it differ for assistive versus decisioning use?
- What monitoring runs continuously, as distinct from testing at launch? Performance drifts.
- What is the rollback plan if quality degrades, and who can trigger it without a committee?
- How are customers informed that they are interacting with an automated system, and at what point?
- What review sampling applies to automated outputs, and by whom?
- Where does human escalation sit, and what context transfers with it?
Point seven determines more customer outcomes than most deployment teams expect. A system that fails and hands over without context creates a worse experience than never deploying it, because the customer has already explained themselves once. CEB’s research published in Harvard Business Review found customers wanted simple, quick solutions to their problems rather than exceptional gestures (Harvard Business Review), and a broken handover is the clearest way to deliver the opposite.
A Phased Deployment Sequence
Roughly the order I’d suggest for a regulated institution starting now:
Phase one, internal only. Transcription, conversational analytics on completed calls, quality screening. No customer contact, no decisioning, immediate value in compliance monitoring. Establishes your accuracy picture per language before anything is at stake.
Phase two, agent-facing. Agent assist, knowledge retrieval, draft summarization with mandatory review. A person remains accountable throughout. Measure whether handling time and resolution both move, since one without the other suggests the tool is shifting work rather than removing it.
Phase three, customer-facing but narrow. Automated handling of clearly non-advisory transactions: balance inquiries, statement requests, appointment booking, card activation. Explicit refusal behavior for anything approaching advice. Our overview of contact centre automation covers containment measurement.
Phase four, everything harder. Identity verification, eligibility, complaint handling. Full model risk governance, supervisory engagement where appropriate, and considerably more patience than phases one through three required.
Most institutions I’d expect to spend a year on the first two phases and consider that time well spent. The temptation to start at phase three because it demos better is strong, and it’s where projects get stopped.
One caveat about that sequence, since I’ve presented it more neatly than reality usually allows. Competitive pressure does not wait for governance maturity, and an institution watching a rival launch customer-facing capability will feel the pull toward skipping ahead. The defensible compromise is narrowing scope rather than skipping phases: launch phase three for two clearly non-advisory transaction types rather than for the whole contact reason list, and treat that as a supervised pilot with a defined review date rather than as a rollout.
Frequently Asked Questions
Does AI in a contact centre require regulatory approval?
The capability itself generally does not, though its application may. Automated outbound calling remains telemarketing under the UAE framework, requiring the same prior approval, calling-hour restrictions and registry screening as human dialing. Where a system performs activities your licence conditions govern, such as advising on products, existing permissions apply. Engage your compliance function early, since the question is rarely whether a rule exists but which existing rule the deployment falls under.
Can automated systems handle payment card details safely?
Only with specific controls. Where card data enters a conversation, PCI DSS obligations apply to every system touching it, including transcription and analytics stores that may retain the digits indefinitely. Suppression of keypad tones and automatic pausing during payment capture are the standard controls, and both need confirming as engineering capabilities rather than policy commitments. Verify what your platform does with transcripts specifically, since those are frequently overlooked in scoping exercises.
How should accuracy be measured before deployment?
Test against your own recordings rather than vendor samples, segmented by language, dialect and contact type. Set thresholds by use rather than globally: a compliance monitoring application needs higher transcription accuracy than a knowledge retrieval prompt an agent can ignore. Measure on a held-back sample the vendor has not seen, and repeat periodically after launch, since performance drifts as vocabulary, product names and customer language change over time.
What should customers be told about automated handling?
Disclose clearly and early. Beyond any regulatory requirement, customers who discover mid-conversation that they have been speaking to a system frequently escalate, which costs more than the interaction saved. State it at the outset, offer a route to a person, and make that route genuinely available rather than buried. Institutions that handle disclosure well tend to see fewer complaints about automation than those treating it as something to obscure.
Does automation reduce contact centre headcount in financial services?
Less than vendors suggest, at least initially. Automation removes simpler contacts first, leaving a harder residual mix that takes longer to handle and requires more experienced staff. Total volume falls while average complexity rises, so the headcount reduction is smaller than the deflection rate implies. Plan for capability changes in your workforce rather than straightforward reduction, and revise handle time and satisfaction targets when deflection is introduced.
How does data residency apply to AI processing?
It applies to inference as well as storage, which teams frequently miss. Where a model processes conversation content in another region, data has left your jurisdiction even if the recording never moved. Ask specifically where inference occurs, whether third-party model providers are involved, and whether content is retained by them. Get the answer written into the contract rather than confirmed informally, since this is exactly the detail an audit will examine.
Should AI outputs be included in customer data access requests?
Generally yes, where they constitute personal data about the individual. Generated summaries, sentiment scores and risk classifications derived from a customer’s conversation are information about that person, and treating them as internal analytics rather than personal data is a position worth testing with your legal team before an actual request arrives. Build the ability to retrieve derived material per customer during implementation, since retrofitting it is considerably harder.
Working out what your institution can actually deploy?
The useful first step is usually unglamorous: transcription and analytics on completed conversations, tested per language, with nothing customer-facing until the accuracy picture is clear.
TabaTalk provides cloud contact centre software built for Gulf operations, covering omnichannel routing, conversation analytics, configurable retention and residency options, and account-level separation your compliance team can inspect. Contact our sales team to review your financial services setup, or ask us to run an accuracy test against your own recordings before you commit to anything.
