For several years, enterprise AI governance concentrated primarily on the decisions made before deployment. Organizations created responsible AI principles, approved-model lists, data-use standards, model-validation procedures, risk assessments, and governance committees.

But production changes the nature of the risk. In the enterprise AI systems I have helped build and operate, the most difficult governance questions often emerged after model selection or initial approval. They appeared after the application began interacting with changing documents, live data, user permissions, retrieval pipelines, enterprise platforms, APIs, and business workflows.

These experiences changed one of my assumptions about AI governance. I initially viewed governance largely as a set of controls that had to be satisfied before a system entered production. Production experience showed that approval only confirms that a system met expectations under a defined set of conditions at a specific point in time.

Those conditions do not remain fixed. The data changes. The documents change. The users change. The infrastructure changes. The permissions change. The business process changes. As those components evolve, the behavior and risk profile of the AI application can change with them.

Model approval is therefore not the end of governance. It is the point at which operational accountability begins.

When retrieval quality became an AI governance issue

One of the most important lessons came from operating retrieval-augmented generation applications. During development, retrieval quality was treated primarily as an engineering and evaluation problem. We tested whether the system selected relevant passages, grounded its answers in source material, and responded accurately to representative business questions.

But production exposed a different category of risk: the knowledge environment did not remain static. Documents were revised, internal pages were moved, and some sources contained current guidance while others remained accessible but were no longer authoritative.

The system could therefore retrieve a highly relevant passage and still provide the wrong answer for the business.

The answer was grounded but outdated

Consider an enterprise assistant designed to answer questions about internal servicing procedures.

During testing, the application consistently retrieved the correct policy document and produced grounded responses. Several weeks after deployment, the policy team revised the procedure and uploaded a new version. The older document, however, remained accessible in another repository and was still represented in the vector index.

When an employee asked about the procedure, the system retrieved the older version because its wording more closely matched the question.

From a conventional evaluation perspective, the answer appeared strong. It was coherent, specific, and fully supported by the retrieved document. The system did not hallucinate.

But the answer was operationally wrong.

For a Chief Data Officer (CDO), this is not merely a retrieval-tuning issue. It raises broader questions:

• Who owns a document after it enters an AI knowledge system?
• How does the organization identify the authoritative version?
• Who is responsible for notifying the AI application when a source changes?
• Should the system continue answering when it cannot verify the effective date of a policy?

The practical lesson is that source relevance is not enough. Production AI systems also need to account for source authority, effective dates, version history, access eligibility, and freshness.

An enterprise knowledge source should not be treated as a static file that is ingested once and trusted indefinitely. It should be treated as a governed asset with an owner, lifecycle, update expectation, and retirement process.

Platform migration can trigger new AI validation 

Another important lesson emerged when AI applications and evaluation pipelines were moved or adapted across enterprise platforms. At the architectural level, two environments might appear equivalent, but the same application can behave differently because of changes in embedding models, document-processing logic, retrieval parameters, model versions, orchestration, or access controls.

Consider an AI assistant moved from one cloud-based environment to another enterprise data and AI platform.

The high-level architecture remained similar. However, the new environment used a different embedding configuration and slightly different preprocessing logic. Those changes altered which documents were retrieved for some queries.

For common questions, the difference was negligible. For more ambiguous or specialized questions, the new system retrieved a broader but less precise set of passages. The model still generated plausible answers, but the supporting evidence was weaker.

A standard migration checklist might have declared the deployment successful because the services were running, latency remained acceptable, and no major application errors occurred. From a governance perspective, however, the system had changed.

The question was not simply whether the application functioned on the new platform. The question was whether it continued to produce equivalent business behavior.

This experience led to an important operational principle: a material platform change should be treated as a new validation event. Platform approval does not automatically transfer application approval.

CDOs may therefore face a choice between platform consistency and behavioral continuity. The solution is not to resist standardization. It is to recognize that AI migration requires more than technical parity.

Ownership became more complex after deployment

Before deployment, ownership often appears straightforward. A data science or AI team builds the application. A risk or compliance team reviews it. A business sponsor approves the use case. A platform team deploys it.

After deployment, accountability becomes fragmented. The model may be selected by one group. The data may be owned by several business units. Retrieval infrastructure may be managed by a central platform team. Identity controls may belong to cybersecurity. Policies may be defined by compliance. The workflow may be owned by operations.

Consider an internal AI assistant that supports multiple employee groups. The underlying repository contains both general operating procedures and restricted financial guidance. Access permissions are correctly applied in the source system. However, during indexing, some permission metadata is not carried forward correctly.

The model itself has not failed. The source repository is secure. The retrieval engine is operating as configured. But the assembled AI system may still retrieve a restricted passage for a user who should not receive it.

Who owns that failure?

This is why production AI benefits from an explicit operating model. Every system should have a business owner accountable for the use case and its consequences, a technical owner accountable for the application’s operation, identified owners for critical data and knowledge sources, and a clear incident-escalation path.

Ownership does not mean assigning every failure to one executive. It means defining responsibilities and decision rights before an incident occurs.

Agent authority should be treated as a business decision

The ownership problem becomes more consequential with agentic AI. Traditional assistants primarily generate information. Agents may retrieve information, call tools, update records, send communications, modify workflows, or initiate business actions.

This introduces a critical distinction:

Capability is not authority.

A model may be technically capable of selecting an action, but the organization must decide whether the system is authorized to execute it.

Consider an AI application that analyzes a service request and recommends the next operational step. In its initial form, the system presents the recommendation to an employee. The employee reviews the supporting information and decides whether to proceed.

The organization later considers allowing the agent to update the workflow automatically.

When the system only recommends, an employee remains accountable for the action. When the system executes, the organization must determine:

• Which actions can be automated
• Which actions require approval
• What happens when information is incomplete
• What evidence must be retained
• Who can immediately disable the capability

The difficult decision is not whether the model is intelligent enough to act. It is whether the organization is prepared to delegate that authority.

In many cases, graduated autonomy is more appropriate than full automation. Low-impact, reversible actions may be automated. Medium-impact actions may require confirmation. High-impact or irreversible actions may always require human approval.

These boundaries should be established before deployment, not discovered after an agent takes an inappropriate action.

Governance should produce operational evidence

Many governance programs are measured by the existence of policies, inventories, model cards, risk assessments, approval records, and an AI governance board. These artifacts remain important, but they do not prove that an AI system is behaving appropriately in production.

A policy expresses intent. Operational evidence demonstrates control.

Leadership teams should be able to determine which information a system accessed, which sources influenced an answer, which tools it attempted to use, whether a user was authorized for retrieved content, and when a control blocked or escalated an action.

This does not mean recording every prompt, response, or sensitive value indefinitely. The goal is to capture sufficient evidence to reconstruct consequential behavior without creating an uncontrolled repository of sensitive interactions.

Suppose an agent attempts to call an API that falls outside its approved scope. A strong runtime control blocks the request and requires human review. Nothing harmful occurred, but the attempted action is still important. It should become governance evidence.

Leadership may not need to review every blocked call, but patterns should be visible. A rise in unauthorized tool attempts could signal a design problem, a misuse pattern, or a change in user behavior.

Controls should also be tested against realistic failures. Production users do not always ask questions in the format represented in the evaluation set. Documents conflict. Context is incomplete. External systems become unavailable. A policy that has never been evaluated against realistic failure conditions remains an assumption.

Testing should not be treated as a one-time predeployment exercise. It should continue as tools, data sources, permissions, and workflows change.

What CDOs can establish before scaling AI

Achieving AI governance success doesn’t require another governance committee; it needs an operational approach to governing AI in production.

Before scaling an AI system, CDOs and their leadership partners should be able to answer several questions:

• Who owns the business outcome?
• Which sources are authoritative?
• What changes trigger reevaluation?
• What is the system permitted to do?
• What happens when confidence is insufficient?
• Who can intervene?
• What evidence demonstrates control?

The purpose is not to create another dashboard filled with disconnected metrics. It is to give leaders evidence that policies are influencing behavior and that the organization can identify and respond when assumptions no longer hold.

Trust is an operating capability

The enterprise AI race is often described as a competition for stronger models, more proprietary data, and faster deployment.

A more durable advantage will come from an organization’s ability to deploy AI into consequential business processes while maintaining control over the data it uses, the decisions it influences, and the actions it can take.

My experience operating enterprise AI systems has shown that the most important risks often arise not because the approved model suddenly changes, but because everything around it does.

The documents change. The data changes. The infrastructure changes. The tools change. The permissions change. The users change. The business process changes.

Governance must be designed for that reality.

The most mature organizations will not be those that approve the greatest number of AI models. They will be those that can detect when system behavior has changed, trace the information and controls that influenced an outcome, assign responsibility across organizational boundaries, and intervene before a technical failure becomes a business incident.

AI trust will not be established through approval alone. It will be earned through the discipline of operating AI responsibly after deployment.