Yes, if you set it up properly. UK GDPR does not ban AI transcription of customer calls. You need a lawful basis, a notice given before recording starts, a stated purpose, a retention period, and a data protection impact assessment where the risk is high. Where the software runs on hardware you own, no outside processor sits in the path.
Can you use AI to transcribe customer calls under UK GDPR?
Yes. Nothing in UK GDPR prohibits transcribing or summarising a customer call with software, and it does not treat an automated transcript differently from a note typed by an agent. What it does is attach conditions, and they apply at every stage: the audio, the transcript derived from it, and the summary derived from that.
All three are personal data about the caller. Each needs a lawful basis, a stated purpose, a retention period and a place in your records. Most projects fail not on the software but because the recorded announcement was written years ago for a recording system, the retention schedule covers the audio and forgets the transcript, and nobody wrote down what the summary is actually for.
Two questions are worth separating. Is the processing lawful, and can you show where the audio went. The first is answerable with documents. The second depends on how the system was built, and it is the one that catches firms out, because a contract is only a promise about something you cannot see.
What lawful basis covers call recording and transcription?
In practice it is legitimate interests, legal obligation, or performance of a contract. Consent is the basis people reach for first and it is usually the wrong one for a service call.
Consent has to be freely given, which means it has to be refusable. If a caller says no and your only route is a recorded line, the consent was never real. Some organisations do run an unrecorded route. Most cannot.
Legal obligation is clean where a regulator requires the recording: a firm inside the FCA's rules on recording telephone conversations about client orders is not choosing to record. Legitimate interests is the usual basis for quality, training and dispute evidence, and it needs a written balancing assessment before you switch anything on, not after the first complaint.
Two traps sit here. The basis for recording does not automatically stretch to a new purpose: adding sentiment scoring, or using transcripts to improve a model, is a new purpose with its own analysis. And callers volunteer special category data without being asked, so if your transcripts will contain it you need an Article 9 condition alongside your Article 6 basis. Voice biometrics is separate again: a voiceprint used to identify a person is special category data, while an ordinary recording of a voice is not.
A separate interception regime in UK law also covers the monitoring and recording of communications on a business's own system. It sits outside data protection law and carries its own conditions, so take advice on it separately.
What must you tell callers, and when?
Before the recording starts, in words that describe what actually happens. The announcement most contact centres still use says calls may be recorded for training and monitoring purposes. That sentence does not cover automated transcription, and it certainly does not cover a written summary that a colleague later reads instead of listening to the call.
So say it. Calls are recorded and transcribed. Software produces a written summary. Here is what it is used for, how long each part is kept, and where the full notice lives. If audio goes to an outside service, say that as well.
Then make the full privacy notice match, on the terms Article 13 sets out. The part organisations most often leave out is the honest part: that a summary is generated, that people act on it, and how a caller can challenge what it says.
Does an AI summary count as new personal data?
Yes, and it is the riskiest data in the chain. A recording is a faithful copy of something that happened. A summary is new personal data that you created about a person, it can be wrong, and the caller cannot see it to correct it.
UK GDPR requires personal data to be accurate. A transcript can mishear a name, a figure or a negation. A summary can compress a conditional into a commitment, or assert a tone the caller would dispute. If that summary then supports a decision, a complaint outcome, an eligibility step, an account action, then the accuracy principle and the right to rectification are live, and you may be inside the rules on automated decision-making too. The ICO's guidance on AI and data protection covers those wider design questions.
The control is unglamorous. Keep the summary tied to the evidence it came from so a person can check it against what was said. Then decide explicitly whether the summary or the recording is your record of truth. Deleting audio early and keeping the generated summary as the surviving account of the call is a decision, not a default.
How long can transcripts and summaries be kept?
Only as long as the stated purpose needs, with the period written down. The common mistake is treating a call as one object. There are usually three clocks: audio, transcript, summary. Different periods for each are legitimate and often sensible: short for the audio, longer for a redacted transcript, longer again for a summary in a case file.
Sector rules set the floor. Firms covered by the FCA's call recording requirements in SYSC 10A of the FCA Handbook keep certain records for five years, and up to seven where the FCA requests it. Nothing in data protection law overrides a retention obligation like that. What it requires is that you can say which rule applies to which artefact.
Deletion also has to be real. If a transcript has been indexed for search or turned into embeddings for retrieval, removing the original file does not remove the personal data. Find out where copies come to rest before you write the policy.
Do you need a DPIA for AI call transcription?
Usually yes, and it is quicker to do one than to argue about whether you needed it. Article 35 requires a DPIA where processing is likely to result in a high risk to people, and the ICO publishes criteria for when a DPIA is needed.
Call transcription tends to hit several at once. It is large scale by nature, because it covers every caller. It uses technology the organisation has not run before. Special category data arrives in it unbidden. And where agent speech is analysed it is also worker monitoring, which the ICO addresses in its own guidance on monitoring workers.
Do it before go-live and keep it alive. The useful output is not the document. It is the list of residual risks with a named person against each one who accepted it. The threshold question is set out in more detail in do you need a DPIA before deploying AI.
What changes when transcription runs on your own hardware?
It removes the part of the assessment you cannot verify. Everything else stays exactly where it was: lawful basis, notice, purpose limit, retention, DPIA, individual rights. Those are yours wherever the software runs.
What changes is the section about somebody else. Send audio to an outside service and you take on processor terms under Article 28, a sub-processor chain that can change, a transfer assessment if the audio leaves the UK, and retention promises you have no way to inspect. You are accountable for all of it and you can audit almost none of it. Keep the processing inside your own boundary and those questions stop needing answers: there is no third party in the path.
This is not an argument against cloud. For work that is not regulated it remains the sensible choice, and I am not in competition with the companies building the compute and cloud layer. A regulated organisation should not have to take a vendor's word for what happened to a recording of its own customer.
That boundary is what the Mickai Sovereign Intelligence Operating System is built around. It runs on hardware the customer owns, within stated requirements, and it is designed to work offline with no data egress.
Two design decisions matter for a compliance file. Consequential actions wait for a named person to approve them, so a human sits in the record by construction. And each consequential action is sealed in the Open Audit Record under ML-DSA-65, the post-quantum signature scheme NIST published as FIPS 204 in 2024. An auditor exports that record and verifies it offline with a public key, using tools that are not ours.
That makes the record tamper-evident, which is not the same thing as tamper-proof. Tamper-proof would mean the record cannot be altered, and I will not claim that about any file. Tamper-evident means that if it is altered, verification fails, and the person checking finds out rather than taking our word for it.
I will be straight about scope. SIOS is in closed beta, with one regulated company onboarding as a design partner. The speech path is not part of what we install today. A local OCR runtime has read scanned PDFs in controlled tests, and extraction and ingestion integration is still being completed. The compliance work above is worth doing whichever system you choose.
Frequently asked questions
Do we need consent to record and transcribe customer calls?
Usually no. Consent is one of six lawful bases and it is rarely the best fit for a service call, because you must be able to honour a refusal and still serve the caller. Most organisations rely on legitimate interests, or on legal obligation where a regulator requires the recording. Special category data in the transcript needs its own condition on top.
Can we send call recordings to a cloud transcription service?
Lawfully, yes, if you do the work: processor terms under Article 28, a named sub-processor chain, a transfer assessment where audio leaves the UK, and a retention commitment you can evidence. The harder question is whether you can verify any of it afterwards. You remain accountable for processing you have no practical way to inspect.
Do our own agents have separate rights when calls are transcribed?
Yes. Your agents are data subjects as well, and analysing their speech is worker monitoring, which the ICO covers in dedicated guidance. Tell staff what is analysed, why, and what happens to the output. Do not let a quality tool quietly become a performance surveillance tool without saying so and reassessing the balance.
How long should we keep AI call summaries?
Set a period for each artefact, because audio, transcript and summary can each carry their own clock. Start from the purpose, then check any sector floor such as the FCA's requirements on recording calls about client orders. Write the periods into policy, and make deletion real across backups, search indexes and derived copies.
Can a caller ask for their transcript to be deleted?
Often yes. The right to erasure reaches the recording, the transcript and the summary, but it is not absolute: a legal obligation to retain the record can override it. Assess each request on its facts, respond within a month, and tell the caller plainly which parts you are keeping and on what basis.
Related briefings
Data protection and UK GDPR
- UK GDPR and AI: Does Your Data Have to Stay in the UK?
- UK Data Storage vs AI Processing: What Is the Difference
- Controller or Processor? AI Suppliers and UK GDPR Roles
- Right to Erasure in an AI Knowledge Base: How to Comply
- Employee Pasted Client Data Into AI: Is It a Breach?
Governance, audit and oversight
- Tamper-Evident vs Immutable Log: The Real Difference
- Human on the Loop vs In the Loop: AI Oversight Explained
Part of a series of 60 briefings on deploying and governing AI in UK regulated organisations, archived with a DOI at 10.5281/zenodo.22975756.
Evaluating AI for a regulated organisation? Mickai runs on hardware you own, offline. Consequential actions wait for a named person to approve them, and what the AI did is sealed into a signed record an auditor can check without us. Applications for the invitation-only closed beta are open. Apply for the closed beta.
Written by Micky Irons, founder and chief executive of Mickai LTD.
Top comments (0)