Voice AI Programme Risk Register: Enterprise Guide

Most enterprise voice AI programmes track the wrong risks. They run a data protection impact assessment before launch, they write an incident runbook for the day something breaks, and they assume that between the two, the risk is covered. It is not. The largest risks to a voice AI programme are commercial and strategic: the containment rate that never reaches the business case, the vendor that gets acquired, the benefit that erodes as the call mix shifts, the model that drifts six months after go-live. None of those belong to the DPIA or the runbook. They belong to a risk register, and most programmes do not have one.

The stakes are not abstract. In its November 2025 State of AI survey, McKinsey found that 88% of organisations now use AI somewhere, but only 33% have it in production and just 14% report material earnings impact. The Stanford AI Index 2026 puts the share of enterprises that have fully scaled AI in any single function below 10%. Value leaks out at every stage, and most of the leaks are governable risks that nobody named early enough. Gartner is blunter still: it predicts that over 40% of agentic AI projects will be cancelled by the end of 2027, citing escalating costs, unclear business value and, in its own words, inadequate risk controls.

This guide is about the third of those. It is not a list of risks to fear. It is the operating model for the register itself: how a voice AI risk gets scored, who owns it as opposed to who is merely told about it, the threshold at which it escalates to the steering committee, how often it is reviewed, and what evidence is allowed to close it. That machinery is what separates a register that governs a programme from a spreadsheet that decorates a slide.

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.

What is a voice AI programme risk register?

A voice AI programme risk register is the single live log of every delivery, commercial, technical, regulatory and operational risk a voice AI deployment carries, each one scored, assigned to a named owner, and tracked to closure. Dilr Voice programmes treat it as the governance spine of the whole engagement. It sits above the DPIA and the incident runbook, it is owned by the programme, and unlike a launch document it is never finished until the programme ends.

The register is a working artefact, not a compliance formality. Each entry records the risk in one sentence, its likelihood and impact, the named owner, the current mitigation, a residual score after that mitigation, and a review date. It is the only place in the programme where a strategic risk such as vendor acquisition sits next to an operational one such as a telephony outage, scored on the same scale so that leadership can compare them honestly. Standing that register up early, before launch rather than after the first incident, is one of the disciplines that separates a governed voice AI programme from a hopeful one.

Why do voice AI programmes need a risk register the DPIA does not cover?

Because the DPIA answers one narrow question, data protection risk to individuals, and the risk register answers a much broader one: everything that can stop the programme delivering its business case. A voice AI DPIA is a regulatory instrument scoped to personal data. It will never capture vendor lock-in, benefit erosion, model drift or a containment shortfall, because those are not data protection harms. The register exists to hold precisely the risks the DPIA is not designed to see.

Think of three separate instruments that programmes routinely conflate. The DPIA covers data protection risk and is driven by the ICO and UK GDPR. The incident response runbook covers what you do operationally when a live call goes wrong. The risk register covers the forward-looking delivery, commercial and strategic risks that neither of the other two touches. NIST makes the point directly in its AI Risk Management Framework: "AI risk management should be integrated and incorporated into broader enterprise risk management strategies and processes." A dedicated register is how a voice AI programme plugs into that broader enterprise view rather than sitting in a silo.

The chart below is the reason the register matters. It is the McKinsey adoption funnel, and every step down it is a place a real programme loses value it planned for.

The gap between 33% in production and 14% with earnings impact is not a technology gap. It is a governance gap, and a well-run register is the instrument that keeps a programme from falling into it. The same logic runs through the DATS methodology: name the risk, place the owner, measure the mitigation.

The same governance thinking sits inside our AI execution office, the standing team that runs a live programme after launch and keeps its register current rather than letting it fossilise on a shared drive.

What risks belong on a voice AI risk register?

Every risk that can stop the programme delivering its business case, grouped so leadership can see the whole surface at once: delivery, commercial, technical, regulatory and operational. The point of a voice AI risk register is coverage, not depth on any one line. Each risk is examined in detail elsewhere, so the register names it, scores it, and points to where the mitigation actually lives. Below is the standing taxonomy Dilr Voice programmes start from.

The regulatory line deserves a number. The ICO received 42,315 data protection complaints in 2024/25, up from 39,721 the year before, and UK GDPR Article 83(5) sets the upper fine tier at 17.5 million pounds or 4% of global annual turnover. That is one register row, with a named owner, not a reason to panic. Frameworks are converging on the same expectation: the EU AI Act asks providers of high-risk systems to run a risk-management system across the lifecycle, and NIST and ISO 31000 say the same in voluntary terms.

How do you score a voice AI risk?

You score it on two axes, likelihood and impact, on a fixed scale defined once and applied consistently, then record a residual score after mitigation. Dilr Voice programmes use a simple five-by-five scale: likelihood from rare to almost certain, impact from negligible to severe, multiplied into one number that ranks the register. The discipline is not the maths; it is defining what each level means in advance so two owners score the same risk the same way.

Impact has to be defined in the programme's own currency, not a generic one. For a voice AI programme that usually means containment, customer harm, regulatory exposure and cost, each with a written definition of what a severe versus a moderate case looks like. A risk that could breach UK GDPR is severe on the regulatory axis by definition; a risk that shaves two points off containment is moderate on the delivery axis. Recording both the inherent score, before mitigation, and the residual score, after it, is what tells leadership whether the current controls are actually working. The register moves each risk through a fixed lifecycle, shown below.

Aligning that scale with ISO 31000 and the NIST AI Risk Management Framework means the voice AI register speaks the same language as the enterprise risk function, which is what lets a programme risk roll up into the corporate risk report without translation. Getting the scale right early is one of the first things our readiness assessment checks before a programme is allowed to deploy.

Who owns a risk on the register, and who is only informed?

Every risk has exactly one owner, a single named individual who is accountable for its mitigation, and a wider group who are consulted or informed but not accountable. The failure mode a voice AI risk register is built to prevent is the shared risk that everybody watches and nobody moves. If a risk is owned by "the programme" or "IT and CX", it has no owner. It has an audience.

The clean way to hold this is a simple responsibility split: one accountable owner per risk, named contributors who do the mitigation work, and a consulted-or-informed list for everyone else. Ownership follows expertise, not seniority. A model-drift risk is owned by the engineering lead who can actually see the observability traces, not by the executive sponsor who reads the summary. A vendor-concentration risk is owned by whoever holds the commercial relationship. The steering committee does not own individual risks; it owns the threshold at which a risk becomes its problem, which is the next question. This is the same accountability discipline that underpins shadow AI governance across the wider estate.

When does a voice AI risk escalate to the steering committee?

At a pre-agreed threshold on the register's own scoring scale, not at the discretion of whoever happens to notice. A voice AI programme should decide in advance that any risk scoring above a set number, or any risk crossing into the severe impact band regardless of likelihood, is automatically escalated. Fixing the threshold in advance removes the judgement call and the politics from the moment a risk gets serious.

Escalation is a path, not a jump. A risk owner manages the risk day to day and reviews it on cadence. When the residual score crosses the review threshold, it goes to the programme lead. When it crosses the escalation threshold, or when the mitigation is failing, it goes to the steering committee, whose job is to allocate resources or accept the risk formally. Truly strategic risks, a regulatory breach or a vendor collapse, reach the board. The path below keeps every step deliberate.

The register is also what feeds the board pack. Rather than a fresh narrative every quarter, leadership sees the top five residual risks, their owners, and whether each moved up or down since the last review. That continuity is what makes the reporting credible, and it is a standing output of an AI execution office that runs the programme after launch.

How often should the voice AI risk register be reviewed?

On a fixed cadence that matches the programme's pace, typically monthly for a live programme, with the register also revisited at every major change: a new call type, a model upgrade, a vendor change or a regulatory shift. A voice AI risk register that is reviewed once and filed is worse than useless, because it gives false assurance. The value is entirely in the review rhythm that keeps scores honest as the programme and the risk landscape move.

A monthly review does three things: it re-scores anything whose likelihood or impact has changed, it checks that mitigations are actually being delivered rather than merely planned, and it closes risks that no longer apply. Event-driven reviews catch the risks a calendar misses, and the biggest of those is call-mix shift, where a change in what customers call about quietly erodes the benefit case the programme was signed off against. Pairing the register review with your benefits realisation tracking is what catches that erosion before it shows up in the numbers. The cadence itself should be written into the programme's operating rhythm, not left to whoever remembers.

What is the best way to run a voice AI risk register in 2026?

The best tool is the one your organisation will actually keep current, and for most enterprise voice AI programmes that is a disciplined spreadsheet or an existing GRC platform, not a bespoke build. The honest answer concedes the point: a well-structured spreadsheet with the fields defined above beats an expensive governance tool that nobody updates. What matters is the operating model around it, not the software.

There are scenarios where a dedicated tool wins. An organisation already running an enterprise GRC platform such as a corporate risk system should keep the voice AI register inside it, so it rolls up automatically. A programme spanning many voice AI vendors, or one under DORA or heavy regulatory scrutiny, benefits from tooling with proper audit trails and workflow. And one warning that holds regardless of tool: a vendor's own dashboard, whether Vapi, Retell AI or PolyAI, is not your risk register. It shows their platform's health, not your programme's exposure. The register is yours, it is vendor-neutral, and it must survive a change of vendor. If you want that discipline built in from the start, that is exactly what a Dilr Voice engagement and the DATS operating model put in place.

What closes a risk on the voice AI register?

Evidence, not opinion. A risk is closed when the mitigation is demonstrably in place and the residual score has fallen into the acceptable band, or when the risk genuinely no longer applies. On a voice AI register, closing a containment risk means the measured containment rate is above target and holding, not that someone believes it will be. Every closure records who closed it, when, and on what evidence, so it can be reopened if that evidence proves wrong.

Is the voice AI risk register the same as a DPIA?

No. A DPIA is a data protection instrument required under UK GDPR, scoped to risks to individuals from processing personal data, and largely fixed once completed. The voice AI risk register is a living log of the programme's full risk surface, most of it commercial, technical and strategic rather than about personal data. The two work together: the DPIA feeds the register's regulatory line, but the register is the broader instrument, and the DPIA guide covers it in depth.

Want to see this in production? Try Dilr Voice live, book an AI placement diagnostic, read about Dilr.ai, or browse more voice AI strategy guides.

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.