Voice AI right to rectification: a 2026 guide

A voice AI agent takes a call, mishears a surname by one letter, a date of birth by one digit or a policy reference by one character, and writes the wrong value into the CRM, the case note and the wrap-up summary. Weeks later the caller sees the error on a letter or a statement and asks you to correct it. That request has a precise legal name: the right to rectification under Article 16 of the UK GDPR. The Information Commissioner's Office received 42,315 data protection complaints in 2024/25, up from 39,721 the year before, and inaccurate personal data is a recurring theme in the casework that follows.

Rectification is easy to underestimate because it sounds administrative. It is not. A rectification request tests whether you know where a piece of call-derived data went, whether you can correct it at source, and whether you can prove you told everyone downstream. In 2026 it also runs against a rebuilt response clock: the Data (Use and Access) Act 2025 replaced the old inline deadline with a new "applicable time period" defined in Article 12A, in force from 5 February 2026.

This guide is written for the compliance, operations and engineering leaders who own that workflow. It covers what Article 16 actually requires, when it bites on voice AI records, how it differs from erasure and from a subject access request, the new response timetable, what "inaccurate" means when an opinion is disputed, the Article 19 duty to tell downstream recipients, the cost of getting it wrong, and how to build a rectification process that holds up under scrutiny.

This guide is shipped by the team behind Dilr Voice, enterprise voice AI built for regulated deployments. Or see DATS, our five-stage AI consulting system for placing AI where compliance and the P&L both hold.

What is the right to rectification under UK GDPR Article 16?

The right to rectification is the individual's right to have inaccurate personal data about them corrected, and incomplete data completed. Under Article 16 of the UK GDPR, a data subject can ask the controller to fix data that is wrong, and to add missing detail, including by a supplementary statement. It applies to any personal data you hold, so a voice AI transcript, a CRM field or a wrap-up summary is squarely in scope.

"The data subject shall have the right to obtain from the controller without undue delay the rectification of inaccurate personal data concerning him or her. Taking into account the purposes of the processing, the data subject shall have the right to have incomplete personal data completed, including by means of providing a supplementary statement."
UK GDPR, Article 16, legislation.gov.uk

Article 16 has two limbs that people routinely conflate. The first is correction of data that is factually wrong. The second is completion of data that is accurate but partial, where a supplementary statement can be attached rather than the record overwritten. Both limbs sit alongside the accuracy principle in Article 5(1)(d), which requires that personal data be "accurate and, where necessary, kept up to date", and that "every reasonable step must be taken to ensure that personal data that are inaccurate ... are erased or rectified without delay". The Data (Use and Access) Act 2025 left both Article 16 and Article 5(1)(d) unchanged, so the substance of the duty is the same in 2026 as it was before, even though the timetable around it moved.

When does a voice AI system create records the right to rectification applies to?

A voice AI system creates rectifiable records at almost every step. The agent transcribes the caller, extracts entities such as names, dates and reference numbers, writes them into fields in Salesforce or HubSpot, generates a wrap-up summary, and pushes a case note into Zendesk. Each of those is personal data derived from the call. When any value is wrong, the caller can ask for it to be rectified, and the request reaches into every system the value touched.

The reason the volume climbs is that adoption is climbing. McKinsey's State of AI, published in November 2025, found that 88% of organisations now use AI somewhere, 71% use generative AI weekly, yet only 33% have it in production and 6% describe themselves as AI-mature. Stanford's AI Index 2026 puts fully scaled deployment in any single function below 10%. The gap matters here because scaling a voice agent multiplies the number of records it writes, and every new record is another place an error can be recorded and later challenged.

It is worth separating two things that sound alike. Rectification is about the accuracy of the written record, not the accuracy of the speech recognition. Whether your model mishears an accent or fumbles a reference number is an engineering question covered in our guides on reference number capture accuracy and post-call summaries. Article 16 starts once that error has been written down and a person asks you to fix it. The two connect, because poor capture creates the inaccurate records that rectification then has to unwind, which is why a strong AI operating model treats capture quality and correction as one loop.

How is rectification different from erasure and from a subject access request?

Rectification, erasure and access are three separate rights that arrive through the same inbox and are easy to confuse. Rectification, under Article 16, corrects or completes data. Erasure, under Article 17, deletes it. A subject access request, under Article 15, gives the person a copy of what you hold. A caller who says "your record of me is wrong" wants rectification, not deletion, and answering with the wrong process wastes the one-month clock and irritates the complainant.

The practical distinction shapes your workflow. Erasure asks whether you can justify keeping the data at all, and we cover that decision in the right to erasure guide. A subject access request asks you to find and disclose, including call recordings. Rectification asks you to change a value and keep the corrected record in service. It is also frequently paired with the right to restriction under Article 18, which lets a person freeze processing while you check the accuracy, and with the accuracy work described in our data minimisation and redaction guide. Getting the routing right at intake is the difference between a clean response and a complaint to the ICO.

How long do you have to respond to a rectification request in 2026?

You have one month. The Data (Use and Access) Act 2025 removed the deadline from the body of Article 12 and put it in a new Article 12A, which defines "the applicable time period" as "the period of one month beginning with the relevant time". That change came into force on 5 February 2026 under SI 2026/82. The one-month duration is unchanged in length, but where the clock starts, and when it can stop, is now set out explicitly.

The mechanics repay careful reading, because they change how you calculate the deadline in practice.

Three points follow from Article 12A. The "relevant time" is the latest of when you received the request, when you received any clarification you reasonably asked for, and when any fee was paid. The clock can stop while you are waiting to confirm the person's identity or to get that clarification, so the period awaiting a genuine answer does not count against you. And you can extend by up to two further months where the request is complex or where there are several requests, provided you tell the person within the first month. Building those states into your AI execution office is what keeps a busy queue lawful rather than merely well intentioned.

What does "inaccurate" mean, and what about a disputed opinion?

The UK GDPR does not define inaccurate, but the ICO does. In its rectification guidance the regulator states that personal data is inaccurate "if it is incorrect or misleading as to any matter of fact". That fact-based test governs a voice AI record: a misheard name, a wrong date or a transposed reference number is inaccurate and must be corrected before anything else happens.

You should still take reasonable steps to satisfy yourself the data really is wrong, weighing what the caller tells you against your own records, before you change it. Opinions and records of events need more care. If a voice agent captured a note that a caller "sounded aggressive", that is a recorded opinion, not a matter of fact, and it may not be inaccurate simply because the caller disagrees with it. Similarly, a record that documents a genuine past event or a mistake that actually happened is not made inaccurate by later regret. The correct response is often not to rewrite history but to add a supplementary statement noting the dispute, which is exactly the second limb of Article 16. Where accuracy is genuinely contested, restriction under Article 18 lets you pause processing while you resolve it. Our UK and EU voice AI compliance overview sets this alongside the other data-subject rights.

Do you have to correct data you already shared with other systems?

Yes, and this is the limb most teams miss. Article 19 requires the controller to communicate any rectification to each recipient the data was disclosed to, unless that proves impossible or involves disproportionate effort, and to tell the data subject who those recipients are if they ask. For a voice AI deployment, correcting the CRM field alone is not compliance.

A single misheard value rarely lives in one place: it may have flowed from the transcript into Salesforce, into a Twilio message log, into a downstream analytics warehouse, and out to a business process outsourcer. That makes rectification an architecture problem before it is a legal one. You need to know the lineage of every call-derived value, so that a correction at source propagates to every recipient rather than stopping at the first system. The diagram below shows the lifecycle we build into regulated deployments.

The teams that handle this well treat the source of truth, the propagation path and the audit log as first-class parts of the DATS methodology rather than afterthoughts. A rectification you cannot prove you cascaded is a rectification you cannot defend. The same logic underpins our approach to AI placement, which maps where each value goes before you ever take the first live call.

What does getting rectification wrong cost?

It sits in the top fine tier. Under Article 83(5) of the UK GDPR, infringements of the basic principles in Articles 5, 6, 7 and 9 and of the data-subject rights in Articles 12 to 22D attract administrative fines of up to £17,500,000 or 4% of total worldwide annual turnover, whichever is higher. Rectification failures fall squarely inside that tier.

That single tier covers both the accuracy principle in Article 5(1)(d) and the rectification right in Article 16, so a failure to keep records accurate and a failure to correct them on request are exposed to the same maximum. The financial ceiling is rarely the whole story. Most rectification failures surface first as complaints, and the ICO received 42,315 data protection complaints in 2024/25, a steady rise on the previous year. A complaint about an uncorrected record is cheap for the complainant to make and expensive for you to answer once it is on the regulator's desk. There is also operational cost: wrong data drives wrong letters, wrong decisions and wrong routing, and the EU AI Act adds transparency duties for any system that interacts directly with people. Treating rectification as a governance discipline, run through the AI execution office, is far cheaper than treating it as a fire drill.

What is the best way to handle rectification for voice AI in 2026?

The best approach depends on how many systems your call data touches. For a single-line deployment where an operator can open one record and edit one field, a lightweight platform such as Vapi, Retell AI or Synthflow is sufficient, and PolyAI is a credible enterprise voice option. If the correction never has to travel, you do not need heavy machinery, and many small teams are well served by exactly those tools.

Rectification becomes hard, and platform choice starts to matter, when a corrected value has to reach many recipients and you have to prove it did. At that point the differentiator is not the voice quality but the data lineage, the propagation path and the audit trail, which is where Dilr Voice and our DATS five-stage methodology are built for regulated, multi-system estates. The best choice is the one that lets you find every copy of a value, correct all of them within the applicable time period, and show your working. Judge any platform, including ours, against that test rather than against a demo.

Can you refuse a rectification request?

Sometimes. You can refuse where a request is manifestly unfounded or excessive, or where, after reasonable steps, you are satisfied the data is in fact accurate. You must still respond within the applicable time period, explain your reasons, and tell the person they can complain to the ICO or seek a judicial remedy. Refusing quietly, or missing the deadline, is what turns a routine request into a regulatory problem for a voice AI deployment.

Does correcting a transcript change the original call recording?

No. The call recording is a factual record of what was actually said, so you do not edit the audio. What you rectify is the derived data: the transcript field, the extracted values and the wrap-up summary that a voice AI system writes into your systems. Where the recording itself contains an inaccuracy about the person, the usual remedy is a supplementary statement attached to the record, not deletion of the evidence of the call.

Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, read the voice AI compliance guides, or see our approach to placing AI inside regulated systems.

Written by the Dilr.ai engineering team, practitioners who ship enterprise AI in production. Follow us on LinkedIn for shipping notes, or subscribe via the RSS feed.