“Who owns AI?” sounds like a governance question. For most operating teams, it is the wrong place to start.
AI is a capability, not a department. The useful question is: who owns the business outcome, and what authority does that team need to improve it?
That shift changes the work. Assigning AI to a box on the org chart may settle a turf dispute, but it does not produce a reliable system. An outcome gives the team a process to redesign, a result to measure, and a reason for each function to participate.
Why voice AI projects stall
Voice AI projects rarely stall because the wrong executive claimed them. They stall for more practical reasons:
The first use case expands until it depends on every system and exception in the business.
The prototype can hold a conversation but cannot reliably complete the task.
Required data is unavailable, APIs are closed, or call-routing and handoff paths are undefined.
Internal teams must fit implementation and maintenance around their regular jobs.
The business has not agreed on a valuable, measurable outcome.
Every improvement enters a vendor queue or engineering backlog, stretching the learning cycle from days into weeks.
These are operating-model problems. Moving ownership from one executive to another leaves them intact.
Consider a technical scoping call for an inbound sales agent at JTV. “Take an order” initially sounds like one use case. Completing that order can require current on-air product data, scheduled pricing, inventory, promotions, warranties, ring sizing, saved payment methods, installment-payment rules, cart and order APIs, telephony, and a reliable human fallback. JTV also wanted a high completion rate; transferring a large share of callers would undermine the experience it was trying to create.
The team had to expose the real process, cut a viable phase-one scope, assign technical work, and give that work priority. No ownership label could substitute for those decisions.
Omaha Steaks encountered a different version of the problem. An analyst and a group of developers spent six months building an agent with tools inside the company’s contact-center platform. They reached 20% containment on one use case. Because the system was deterministic, every path had to be mapped by hand. A caller who offered the right information at the wrong step could derail the flow.
The project needed more than a handoff to IT. Conversational systems require specialized expertise, live-call feedback, and continuous iteration. Treating the agent as a finite software build produced an expensive system that was hard to improve.
A Renewal by Andersen operator described the cost of a slow learning cycle with a previous vendor: minor fixes could take days, then stretch into weeks. The operator cared less about who had signed the contract than about the time between hearing a problem, changing the agent, and testing the result.
Functions own outcomes; shared teams set the guardrails
No single department should own AI for the entire company. Each function should own the outcomes it is already accountable for and have enough authority to improve the processes behind them.
In a contact center:
CX defines the experience customers should receive.
Operations decides how work moves between AI and people.
Quality turns real conversations into a prioritized improvement queue.
IT makes the system secure, reliable, observable, and connected to the right data.
Finance tests whether the economics hold.
Legal and security define the boundaries within which the team can move quickly.
This is shared authority around one result, not a relay race of handoffs.
For a voice agent handling sales, the outcome might be completed revenue at or above the company’s customer-experience standard. CX can reject conversations that misrepresent the brand. Operations can change a handoff that creates repeat work. IT can block a release with an unsafe transaction path. The commercial owner can challenge a high containment rate if the calls produce low-value orders or avoidable refunds.
The team does not need consensus on every prompt change. It needs clear decision rights tied to a common scorecard. A revenue agent and a deflection bot should be evaluated differently, even if both use the same underlying models.
Centralize the foundation, not every decision
A central AI team can provide approved models, security patterns, evaluation tools, data-access standards, vendor rules, and reusable infrastructure. Its job is to create leverage: functions should be able to improve a bounded process without launching a new enterprise technology program for every change.
The practical test is whether the people closest to the outcome can learn quickly while staying inside agreed guardrails.
A workable operating model gives the responsible function five things:
A measurable outcome. Completed orders, recovered calls, booked appointments, lower abandonment, faster resolution, or another result the business already values.
A bounded first process. One call type, route, or transaction, with explicit exceptions and a working human fallback.
The minimum access needed to finish useful work. Deep integration is valuable when the task requires it, but it should follow the task rather than precede it.
A short learning cycle. The team reviews real conversations, identifies failure patterns, changes the agent, and measures the result in days rather than quarters.
A path to expand. New intents, permissions, and integrations are earned with evidence instead of bundled into a giant first release.
A home-services operator showed why minimum viable access matters. Its CRM platform kept direct API access closed, so the team launched outbound campaigns by uploading a CSV and receiving results by email. That lightweight process generated six figures in two days of limited testing. The launch did not match the ideal end state, but it was enough to prove the outcome and learn what to build next.
The same principle applies to telephony. Voice AI can sit in front of selected call paths without forcing a CCaaS replacement. A narrow, reversible deployment often teaches more than a long integration program designed around hypothetical future scope.
Use AI to question the process, not just automate it
The larger opportunity is not to insert AI into a workflow exactly as it exists. It is to use the new system to see the workflow more clearly and redesign it.
Omaha Steaks believed its calls were roughly 70% sales and 30% service because that was what callers selected in the phone tree. Once the agent classified the conversations themselves, the sales share proved closer to 45% to 50%. Phone-tree selections had been distorting the company’s view of customer intent, which in turn shaped staffing and training decisions.
The deployment also created a faster feedback system. During peak season, call data surfaced a broken add-to-cart experience before the existing QA process had finished encoding the relevant calls. The voice agent was not only answering calls; it was helping the web team find a revenue problem.
That is the standard functions should work toward. A sales team should ask whether AI makes previously uneconomic lead pools worth pursuing. A quality team should ask what changes when every conversation is searchable. Operations should ask how queues, roles, and customer journeys should change when routine work no longer has to wait for a person.
AI creates value when it expands the set of viable decisions. Automating an unquestioned process captures only part of that value.
Start with the outcome
The company does not need one owner of AI. It needs accountable owners for the results AI is meant to change.
Start with four questions:
Who owns the outcome?
Which process limits that outcome today?
What does AI make possible that was previously too expensive, slow, or difficult?
Which data, tools, guardrails, and cross-functional decisions does the responsible team need?
Answer those clearly and the ownership debate becomes manageable. The function leads the outcome. Shared technical and governance teams make that work safe, reusable, and scalable.
