How to build real ownership around AI

Assign direct ownership for AI initiatives

Every production AI system needs one named owner. Shared responsibility becomes weak when an AI system makes a bad decision, exposes sensitive data, or triggers an action that costs the business money.

Joe Wilson, SVP and CIO of customer experience, billing, and payments software provider CSG, puts the requirement clearly: “Shared accountability is not accountability. You need a direct owner.” At CSG, AI initiatives pass through governance reviews involving executive leadership. The company assigns direct ownership at the start of each project. Wilson, who oversees CSG’s AI governance and deployment strategy, has also established “CIO reps” within business units and product groups. Their role is to maintain accountability throughout the AI lifecycle.

This matters because production AI crosses traditional organizational boundaries. A single system can use enterprise data, call APIs, access external models, interact with applications, and influence business processes. Infrastructure teams, security teams, data scientists, application developers, and business owners may all contribute. A failure can therefore have several technical causes while still requiring one person to own the business response.

Many companies have yet to make this distinction operational. David DuChene, manager of data and AI pre-sales at SHI International, says organizations can have responsible parties documented and still reopen the question of responsibility after a failure. “They may have responsible parties on paper, but once a system actually breaks down, everything gets relitigated,” he says. Responsibility then tends to move toward whoever is “closest to the pain point.”

Executives can test their operating model with one concrete scenario. DuChene asks: “If your AI deployment generates a wrong answer and costs the business money tomorrow, who’s going to write the postmortem?” A postmortem documents what happened, why it happened, its impact, and the actions required to prevent a recurrence. If leadership cannot immediately name its owner, the accountability model is incomplete.

The key nuance is that direct ownership does not mean one executive performs every governance, security, or technical task. Specialists still own specific controls. The accountable owner ensures those controls work together and has authority to drive remediation when they fail. This distinction becomes more important as AI systems gain permission to take actions inside business workflows.

Executives should therefore define ownership before production approval. The owner needs a clear scope, decision rights, escalation authority, and responsibility for incidents and subsequent corrective actions. That turns accountability from an organizational chart entry into an operating mechanism.

Integrate governance before scaling AI deployment

An enterprise can spend 18 months building an AI system and still end with nothing it can deploy. Seth Dobrin, CEO of deterministic AI model maker Arya Labs and former global AI leader at IBM, encountered this outcome at an insurance company. Its team developed an intelligent system for 18 months before legal teams blocked deployment. The work had to be discarded because governance had entered the process too late.

The central constraint was sequencing. AI development can move faster than the controls required to operate it safely. David DuChene of SHI International says teams frequently scale deployments before establishing data classification, AI-aware identity and access controls, data lineage and provenance, audit capabilities, and clear escalation channels. Fixing these gaps after development creates expensive rework and can make an otherwise functional system unsuitable for production.

Governance therefore belongs inside the development workflow from the start. Teams need to know which data an AI system may use, which systems it can access, which actions it may perform, who can approve exceptions, and how decisions will be reconstructed after an incident. These requirements affect architecture and product design. They become costly to change once a system is complete.

Dobrin identifies workflow integration as the critical issue. “How do you integrate it into the workflow?” he asks. “If you don’t get that right, it’s going to fall apart.” His insurance example shows the business consequence. Earlier legal and governance involvement could have changed the design while changes were still practical. “Had they started earlier, they would have steered it to a place where they could have gotten to yes,” he says.

This changes how executives should measure effective governance. The goal is safe deployment at useful speed. Dobrin says, “The objective should never be to say no. It should always be to figure out how to say yes.” Governance teams contribute most when they translate legal, security, privacy, and operational requirements into design constraints that engineers can implement early.

There is an important management nuance. More approval gates do not automatically produce stronger governance. A long committee process can still miss material risks if controls remain disconnected from daily engineering and operations. Effective governance defines requirements early, assigns decision rights, records evidence, and makes escalation predictable. This gives product teams a known path to production.

Wilson at CSG makes the same operational case. “Our intention is not to slow things down,” he says. “Our intention is to speed stuff up, but also when you get into rough terrain, to be able to navigate that terrain.” For the C-suite, that means treating governance as part of AI delivery capacity. Mature controls reduce late-stage surprises and give organizations a safer path for scaling successful systems.

Establish data governance as the accountability foundation

AI accountability starts with the data a system can access. If a company cannot trace that data, control access to it, and identify its owner, investigating an AI failure becomes difficult.

Joe Wilson, SVP and CIO of customer experience, billing, and payments software provider CSG, says the company focused on data governance before expanding AI across the business. Its work began with data synchronization and privacy impact assessments. “The foundation is data,” Wilson says. “If we don’t have clean, synchronized, and governed data across the board, we’re not going to win this battle.”

The challenge grows as AI systems connect previously separate data environments. An AI assistant summarizing customer interactions could retrieve regulated or confidential information from enterprise systems that were never designed to provide data to generative AI applications. The model can then use that information in an output or pass it into another part of an automated workflow.

Quais Taraki, CTO of EnterpriseDB, identifies fragmented enterprise data as a major accountability problem. Companies need to know which information entered an AI system, where it originated, who had permission to use it, and how it contributed to the resulting action. Those questions become difficult to answer when data is copied across applications, transformed multiple times, or stored without consistent controls.

Four capabilities are especially important: classification, access control, lineage, and provenance. Classification identifies the sensitivity and regulatory status of data. Access controls determine who or what can use it. Lineage records how data moves and changes across systems. Provenance establishes its origin and relevant history.

These records become critical during an incident. “Without lineage and provenance, you can’t do root-cause analysis,” Taraki says. “You won’t know what to change, or how things mutated in ways you didn’t expect.” A company may detect a harmful AI output and still struggle to fix the underlying problem if investigators cannot reconstruct the data path that produced it.

For executives, ownership is the deeper organizational issue. AI systems commonly span infrastructure, data science, application development, security, and business teams. Taraki argues that accountability should follow governed data products. A data product is a managed dataset or data service with defined users, controls, quality requirements, and ownership. Assigning responsibility at this level creates a clearer chain of accountability as information moves into AI applications.

Data quality also deserves careful treatment. Clean and synchronized data can improve reliability, but accuracy alone does not make data appropriate for AI. A dataset can be factually correct while its use violates privacy restrictions, customer commitments, access policies, or regulatory requirements. Governance therefore has to cover permitted use as well as technical quality.

The executive requirement is clear: map the critical data feeding each production AI system and assign owners to it. Those owners need enforceable access rules, classification standards, lineage records, and provenance. This gives management the evidence required to investigate failures, correct them, and establish responsibility.

Extend observability across the full AI system

Production AI needs a detailed record of what it did. Traditional monitoring can show whether a server is running or an application is responding. AI operations require additional evidence: what the system received, which resources it accessed, which tools it invoked, what it produced, and which actions followed.

Nik Kale, a member of the Coalition for Secure AI (CoSAI) and a participant in AI security and agent identity standards efforts, describes this record as an “Investigation Graph.” It captures what an AI system observed, the tools it accessed, the conclusions it reached, and the actions it took.

“When something breaks, the first instinct is always to ask, ‘Why did the AI make that decision?’” Kale says. “Honestly, I think that’s the wrong question. The right question is, ‘What did the system actually do?’”

That distinction matters because the model is only one component of a production AI system. Models operate through credentials, APIs, applications, databases, policies, retrieval systems, and automated workflows. A harmful outcome can emerge from interactions among several of these components. Kale summarizes the issue directly: “The model didn’t act. The system around the model acted.”

Observability must therefore span the full execution path. Organizations need logs for prompts, model outputs, tool calls, data-access events, API activity, and agent actions. These records should connect with conventional application, security, and infrastructure telemetry. Together, they allow investigators to reconstruct the sequence that led to a business outcome.

This requirement becomes more important with AI agents. An agent may receive a task, retrieve information, choose a tool, call an API, and change a business system. Each step can carry different permissions and risks. Executives need enough telemetry to determine which identity initiated an action, what authorization it used, which information influenced it, and what changed as a result.

Detailed logging also creates governance obligations. Prompts and outputs can contain personal information, trade secrets, customer records, or security-sensitive data. Companies should define who may access AI logs, how long those records are retained, and how sensitive information is protected. Observability itself becomes part of the data governance environment.

The same capabilities help expose shadow AI: employee use of AI services outside approved enterprise processes. Unusual data-access patterns, unexpected calls to external APIs, traffic to unapproved AI services, and unexplained transfers of sensitive information can provide early warning.

David DuChene, manager of data and AI pre-sales at SHI International, describes the central problem with unauthorized systems: “If it’s shadow IT, we don’t even know it exists. We don’t know what data of ours is going into it, how it’s being used, or how it’s being distributed.”

For the C-suite, the objective is traceability. Every material AI action should leave enough evidence for the company to reconstruct what happened and determine its business impact. Strong observability shortens investigations, improves incident response, exposes unauthorized activity, and gives accountable owners the information required to make corrective decisions.

Build explicit escalation and stop mechanisms

A production AI system needs defined limits on autonomous action. The critical control is knowing when the system must stop, escalate an issue, and transfer authority to a person.

Nik Kale, a member of the Coalition for Secure AI (CoSAI) and a participant in AI security and agent identity standards efforts, identifies this as a weak point in many enterprise deployments. “Most enterprises have figured out how to monitor their AI systems,” he says. “But nobody has really built the third piece, which is, when does the system actually stop and ask for help?”

The answer needs to be designed before deployment. Organizations should define conditions that trigger an escalation, the actions a system can take before approval is required, and the conditions that require operations to stop. These rules can cover confidence thresholds, sensitive transactions, unusual data access, policy violations, financial exposure, security alerts, and other risks relevant to the business process.

The human decision point also needs a named owner with sufficient authority. “You don’t want a rubber stamp, you want a human in the loop,” Kale says, adding that the person should be identified in advance and have the power to reject an action. For executives, this is a question of decision rights. A human review step provides little protection when the reviewer lacks context, authority, or enough time to intervene.

AI also changes the pattern of operational failures. Joe Wilson, SVP and CIO of CSG, explains: “A traditional IT incident typically looks like it’s an up or down scenario. AI failures are a little more subtle than that.” A model can remain available while its output quality gradually declines. Behavior can drift as data changes. An automated workflow can continue running while producing increasingly unexpected results.

These failure modes require clear operational thresholds. Teams need measures for acceptable output quality and behavior, along with triggers for investigation, human review, restricted operation, or shutdown. High-impact use cases should have tighter thresholds because a single incorrect action may carry financial, legal, safety, privacy, or reputational consequences.

Incident response must also bring the right functions together. Wilson sees a growing need for legal, communications, security, audit, business teams, and IT operations to respond simultaneously. This matters because an AI incident can create several types of exposure at once. A technically functioning system could produce a compliance issue, disclose confidential information, make an inappropriate customer decision, or trigger an external communications problem.

For C-suite leaders, escalation design should be treated as part of production readiness. Every material AI workflow should answer four questions before launch: what causes escalation, what causes a stop, who makes the decision, and how quickly that person can act. Clear answers place a hard boundary around autonomous behavior and make accountability enforceable during an incident.

Apply continuous oversight to AI systems

AI deployment is the start of an operating responsibility. Models change. Prompts change. Retrieval systems change. Available information changes. Third-party providers update their services. Each change can alter system behavior after the original approval.

Kale argues that ongoing supervision is therefore essential. “You cannot just deploy once and be done,” he says. “Like workers, they need ongoing oversight.” The management implication is straightforward: approval at launch cannot establish that an AI system will remain acceptable throughout its operating life.

Continuous oversight should track the factors most likely to change business outcomes. These include output quality, error patterns, model drift, data access, tool usage, security events, policy compliance, and changes to prompts or retrieval components. Material changes should trigger reassessment when they alter the system’s permissions, data exposure, decision scope, or potential business impact.

Version control becomes especially important. Executives should expect teams to know which model, prompt configuration, data sources, tools, and permissions were active when a significant decision occurred. Without that record, a company can observe that behavior changed while still struggling to identify what caused the change.

Third-party AI adds another layer of operational risk. Enterprises can approve a provider after security, privacy, legal, and technical reviews, yet the service can continue evolving afterward. Vendors may change models, introduce capabilities, modify supporting software, or alter how individual features work.

“The vendor we approved last quarter is functionally a different vendor this quarter,” Kale says. This makes vendor oversight an ongoing process. Procurement and initial due diligence establish the starting position. Technical monitoring, change management, periodic risk reviews, and contractual controls help maintain visibility as the service develops.

The governance model also has to account for responsibilities distributed across several companies. An enterprise may operate an application built by one software vendor, use a model from another provider, and run the system on infrastructure supplied by a third. Kale points to CoSAI’s AI Shared Responsibility Framework as an emerging effort to clarify responsibilities across enterprises, software vendors, model providers, and infrastructure operators.

Executives should therefore assign an enduring owner to every significant production AI system. That person needs responsibility for monitoring performance, reviewing material changes, reassessing risk, and deciding whether continued operation remains acceptable. Security, legal, compliance, engineering, and business teams can own their respective controls, while the designated owner maintains the overall accountability chain.

The operating principle is simple: production approval has a limited shelf life when the underlying system keeps changing. Continuous oversight gives management a way to detect meaningful changes early, reassess their impact, and keep AI behavior within defined business and risk boundaries.

Make AI accountability an enforceable operating capability

AI accountability becomes meaningful when an organization can enforce it during normal operations and failures. Policies can identify responsible teams and define acceptable behavior. Production controls determine whether those responsibilities hold when an AI system takes an unexpected action.

The core requirement is an unbroken chain of responsibility. Every significant AI system needs a named owner. Its data needs defined ownership, classification, access controls, lineage, and provenance. Its actions need sufficient logging for investigators to reconstruct events. Its operating rules need escalation thresholds and stop mechanisms. Its performance and risk need continuous review after deployment.

These controls reinforce each other. Ownership has limited practical value when the responsible executive cannot determine what a system did. Observability provides that evidence. Observability becomes more useful when investigators can trace the underlying data. Escalation procedures convert detected problems into action. Continuous oversight identifies changes that can make earlier approvals obsolete.

The shift toward AI agents makes this operating model more urgent. Systems that can retrieve information, call tools, access APIs, and execute workflow steps can create direct business consequences. Each additional permission increases the importance of clear decision rights and traceable activity. Executives need to know who authorized the system’s capabilities, what boundaries apply, and who can restrict or terminate those capabilities.

Accountability must also extend across organizational and supplier boundaries. A production AI service may depend on enterprise data, internal applications, an external model provider, third-party software, and cloud infrastructure. Nik Kale, a member of the Coalition for Secure AI (CoSAI) and a participant in AI security and agent identity standards efforts, points to CoSAI’s AI Shared Responsibility Framework as an emerging effort to clarify responsibilities among enterprises, software vendors, model providers, and infrastructure operators.

This distribution of responsibilities makes contractual and operational clarity important. A company can outsource technology while retaining responsibility for its business use. Leaders should know which party monitors each component, who reports material changes, who retains the relevant records, and how incidents move across company boundaries. Those responsibilities should align with internal incident response and governance processes.

David DuChene, manager of data and AI pre-sales at SHI International, provides a useful test for accountability: “If your AI deployment generates a wrong answer and costs the business money tomorrow, who’s going to write the postmortem?” That question forces an organization to move from general responsibility statements to a specific operating decision.

The postmortem itself is only part of the process. The responsible owner needs access to logs and data lineage, authority to involve security or legal teams, a mechanism to stop further harmful activity, and a process for implementing corrective changes. Accountability becomes enforceable when the organization can move from detection to decision to remediation without reopening basic questions about ownership.

For the C-suite, this is the final test of AI governance. Ask whether the company can identify a responsible owner, reconstruct a material AI action, determine which data and permissions were involved, stop the system when required, coordinate an incident response, and verify the corrective action afterward. If each step has an owner and an operational control, accountability can survive contact with production AI.

In conclusion

AI accountability is an operating requirement. As AI systems gain access to data, tools, APIs, and business workflows, every increase in autonomy creates a stronger need for clear ownership and control.

For executives, the test is practical. Can you name the person accountable for each critical AI system? Can your teams reconstruct what the system did and which data it used? Can someone stop it quickly when behavior crosses an agreed boundary? Can you reassess the system when its models, data, permissions, or vendors change?

Strong governance makes those answers clear before an incident occurs. It connects named owners with governed data, end-to-end observability, escalation authority, and continuous oversight. These capabilities also support faster AI adoption because teams enter production with known requirements and decision rights.

The next stage of enterprise AI will put more systems in a position to act independently. Leadership should scale autonomy at the same pace as accountability. That is what turns responsibility from a policy statement into a control the business can enforce.