Voice AI Delivery Team RACI: Who Runs the Agent

A voice AI programme is usually launched by a project team: a sponsor, a delivery partner, a handful of engineers, and a deadline. Then the project ends, the team disbands, and the agent keeps answering calls. Six weeks later a price changes, a prompt drifts, a caller is mishandled, and the question nobody wrote down surfaces: who owns this now? The launch team told you how to go live. It never told you who runs the thing on a wet Tuesday in month seven.

That gap is where value quietly leaks. In its November 2025 State of AI survey, McKinsey found that 88% of organisations now use AI somewhere, yet only 6% have reached the maturity where it delivers material EBIT impact. The difference is rarely the model. It is whether a named, standing team runs the system with clear accountability after the excitement fades. This guide sets out that team as a RACI: the recurring run tasks, and who is responsible, accountable, consulted and informed for each one. It sits within our wider voice AI strategy coverage for enterprise programmes.

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.

Who actually runs a voice AI agent once it is live?

Once a voice AI agent is live, it is run by a standing delivery team, not the project team that launched it. That team is a small group of functions: an AI ops lead who owns the running service, a conversation designer, a QA analyst, a compliance owner, plus IT and CX support. These are roles, not always five separate hires; at low volume one person can hold several, provided every recurring task has a named owner.

Those role titles are defined in detail in our guide to the voice AI steering committee charter, which names the same functions at the governance layer. This post does not re-teach what each role is. It answers a narrower and more practical question: for the day-to-day work of keeping the agent accurate, compliant and available, which role holds which task? That is the difference between a team that has an org chart and a team that can be held to a decision.

The distinction between the launch team and the run team matters because they optimise for different things. A launch team is measured on getting to go-live. A run team is measured on keeping a live service accurate over years, which is a different discipline with a different cadence, closer to the rhythm set out in our operating cadence guide than to a project plan. It also outlives the workforce planning done at launch, because the people who remain are the ones who run the agent every day.

Why does a voice AI programme need a run RACI, not just an org chart?

A voice AI programme needs a run RACI because an org chart shows who reports to whom, not who is answerable for a specific decision. When an agent gives a wrong answer, "the AI team" is not an accountable party. A RACI forces one accountable name per task, so tuning, sign-off, incidents and quality each have an owner who cannot defer. Without it, every recurring decision becomes a meeting, and every failure becomes an orphan.

This is not only good operating practice; it is the shape of the law. UK GDPR Article 5(2) states that the controller "shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability')." That word, accountability, is doing precise work. It is not enough to be compliant. You have to be able to show who was responsible and evidence the decisions they made. A run RACI is the operating artefact that makes that demonstrable, mapping each task that touches personal data to a named owner and a record.

The alternative is the failure pattern we see most often across engagements: a capable agent, a real use case, and nobody who can say with confidence who signed off the last change or who is on the hook for the next incident. Closing that gap is exactly what our AI execution office is built for. The technology is rarely the constraint. The accountability grid is.

What are the recurring run tasks for a live voice AI agent?

The recurring run tasks for a live voice AI agent fall into five buckets: prompt and flow tuning, release change sign-off, incident response, QA and accuracy review, and model or version updates. Each recurs on its own cadence, each touches the caller experience, and each needs a single accountable owner. Naming these five tasks first is what makes a RACI grid meaningful, because the columns are roles but the rows are the actual work the team does every week.

Prompt and flow tuning is the steady editorial work of correcting how the agent handles real calls. Release change sign-off is the go or no-go decision before any change reaches a live caller, covered in depth in our release management and change control guide. Incident response is what happens when the agent fails in production, governed by an incident response runbook. QA and accuracy review is the independent quality gate. Model or version updates are the platform-level changes, a new model or provider, that can shift behaviour underneath a prompt that never changed.

Keeping these five distinct matters because they carry different risk. A tuning tweak and a model swap can produce the same symptom, a changed answer, but they demand different owners, different testing and different sign-off. QA and accuracy review, in particular, is a standing discipline in its own right, set out in our guide to voice AI accuracy evaluation. Collapsing all five into "maintenance" is how a low-risk edit and a high-risk platform change end up treated the same way.

What does the voice AI run RACI grid look like?

The voice AI run RACI grid puts the five run tasks in rows and the delivery roles in columns, with exactly one accountable owner per task. The AI ops lead is accountable for most operational tasks because someone must own the running service end to end, while the QA analyst holds the quality gate so no one marks their own homework. Responsibility, consultation and information are distributed across the rest of the team.

Legend: R responsible does the work, A accountable owns the outcome, C consulted gives input before the decision, I informed is told after. Legal is consulted through the compliance owner rather than sitting as its own column, which keeps the grid readable while preserving the escalation path. The single deliberate split is QA: the analyst who reviews accuracy is accountable for that gate and is not the person who ships the change, so quality has an independent voice.

Read the grid as a contract, not a diagram. Every cell is a commitment about who acts, who decides, and who must be told. When a new person joins the run team, this is the one page that tells them what they own before they touch a prompt. When an auditor asks who approved a change, this is the artefact that answers, which is exactly the evidence UK GDPR accountability expects a voice AI programme to hold.

How does a change to the agent get signed off across the team?

A change to a voice AI agent is signed off through a fixed sequence of gates, each owned by a different role, so no single person both writes and ships a change unchecked. A tuning request is drafted by the conversation designer, validated independently by the QA analyst, reviewed by the compliance owner when it touches regulated handling, then signed off by the accountable AI ops lead. The path is the same every time, so it stays auditable.

The value of a fixed path is that it turns sign-off from a judgement call into a checklist. A small copy fix and a change to how the agent verifies a caller both travel the same gates, but the compliance step means the risky one gets the scrutiny it needs without slowing the trivial one to a crawl. This is the operational spine that our release management discipline builds on, and it is why a run RACI and a change process are two halves of the same control.

Who is accountable when a voice AI agent gets something wrong?

When a voice AI agent gets something wrong, accountability sits with a named owner, usually the AI ops lead, not with a committee or a vendor. Accountability is the duty to answer for the outcome and show what was decided and why. Responsibility for the fix may be shared across QA, compliance and IT, but one person owns the answer to who is on the hook. A RACI that spreads accountability across several roles has assigned it to none.

This is where UK GDPR Article 5(2) becomes concrete. The controller must be able to demonstrate compliance, which means the accountable owner has to evidence the decision trail: what the agent did, who reviewed it, what changed as a result. The ICO's data protection audit framework sets out the kind of governance and record-keeping a regulator expects to see, and a run RACI feeds it directly by making every task traceable to an owner. Accountability that cannot be evidenced is not accountability; it is hope.

Naming the accountable owner does not offload the risk from the organisation. The controller remains liable regardless of who runs the agent day to day, which is why the compliance owner is consulted on every task that touches personal data and why the governance framework sits above the run team. Executive sponsorship keeps that accountability funded and visible above the delivery layer. The run RACI does not replace governance. It makes governance operable, connecting a board-level duty to the person who actually edits the prompt.

The same discipline underpins our AI operating model consulting, where we help enterprises stand up the standing run team, not just the launch project, before a deployment commitment is made.

What is the best way to structure a voice AI delivery team in 2026?

The best way to structure a voice AI delivery team in 2026 depends on volume, risk and how much you keep in-house. For a low-volume internal line, one or two people wearing several RACI hats is proportionate, and a managed platform can absorb most run work. For a regulated, high-volume deployment, the five functions should be separate, with QA and compliance held independently of the team that ships changes. There is no one right shape, only one matched to exposure.

The build-versus-buy choice interacts with this directly. Self-serve platforms such as Vapi, Retell AI, Bland AI and Synthflow put the run RACI entirely on you: you hold every role, because the vendor supplies the tooling and nothing else. Managed and governed providers such as PolyAI and Dilr Voice take on parts of the operational grid, typically the platform, model-update and incident columns, leaving you the conversation-design and business-accountability rows. Neither is better in the abstract. The honest answer is that a lightly-used internal assistant nobody will audit does not need a formal delivery team, while a customer-facing agent in a regulated sector needs every row of the grid owned by a name.

Where a managed provider does hold part of the run, the vendor relationship itself becomes a run task, which is why the accountable owner should track it the way our guide to in-house versus vendor delivery sets out. The grid does not disappear when you buy; it changes columns. What never changes is that the controller stays accountable, so the internal owner of that accountability, and the evidence trail behind it, has to exist whoever operates the platform.

Want to put names against these roles? Try Dilr Voice live, book an AI placement diagnostic, see our DATS methodology, or read about our approach to placing AI inside enterprise operations.

How is the run RACI different from the steering committee charter?

The run RACI and the steering committee charter operate at different altitudes. The steering committee charter, covered in our committee guide, governs strategic decisions: budget, scope, risk appetite and escalation. The run RACI governs daily operational tasks: who tunes, who signs off, who responds to an incident. The committee decides whether the programme continues; the run team keeps the live agent accurate between those decisions. Both are needed, and they reference the same role names.

Does the RACI change when a vendor runs the agent?

Yes, the RACI changes columns when a vendor runs the agent, but it never disappears. A managed provider typically takes the responsible and accountable cells for platform, model-update and incident-execution tasks, while your organisation keeps accountability for conversation design, compliance and the business outcome. The controller remains legally accountable regardless, so an internal owner for each ceded task still has to exist to hold the vendor to it and evidence the arrangement.

How large does a voice AI delivery team need to be?

A voice AI delivery team is sized by workload and risk, not by a fixed headcount. The five RACI functions are roles, so at low volume one or two people can cover all of them, while a high-volume regulated deployment may need a dedicated person per function plus IT and CX support. The test is not how many people you have; it is whether every run task in the grid has one accountable name and an independent quality gate.

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.