AI Governance After Close

AI deployment is an operating decision

AI becomes useful after an acquisition when it improves a defined operating behavior: a faster response, a cleaner handoff, a more reliable forecast, or earlier visibility into an exception.

It also introduces risk. A system can act on incomplete information, expose sensitive data, produce an incorrect answer with confidence, or become embedded in a workflow before management has defined who is accountable for the result.

That is why AI governance should begin with the operating plan rather than a technology policy written in isolation. The relevant questions are practical. What decision or workflow is changing? What information will the system use? What happens when the output is wrong? Which person can stop or override it? How will management know whether the deployment is improving the asset?

The National Institute of Standards and Technology organizes its voluntary AI Risk Management Framework around four functions: govern, map, measure, and manage. That structure is useful because it treats risk management as a continuous operating discipline rather than a one-time approval.

Tier use cases by materiality

Not every AI use case requires the same level of control.

Drafting a routine internal summary is different from recommending a price, evaluating a job applicant, communicating a legal position, approving a payment, or directing a safety-related response. The greater the consequence of an error, the stronger the requirements should be for data quality, validation, human review, access control, logging, and escalation.

A practical portfolio framework can group use cases into three levels:

• Assistive: The system drafts, summarizes, classifies, or retrieves information for a person who reviews the result before use.
• Operational: The system routes work, sends approved communications, updates records, or triggers routine actions within defined limits.
• Material: The system influences decisions involving capital, pricing, employment, legal rights, safety, credit, or other consequential outcomes.

Assistive use cases may move quickly when information is appropriately protected. Operational use cases need stronger acceptance criteria and exception handling. Material use cases generally require explicit accountable review and a documented basis for determining whether AI should be used at all.

The classification should reflect the context, not the sophistication of the model. A simple automated rule can create material risk if it controls an important decision.

Define the data boundary

AI governance is inseparable from data governance.

Before deployment, the operating team should identify what information enters the system, where that information is stored, whether a provider can use it for training, who can access the output, and how long records are retained. Customer, tenant, employee, investor, financial, legal, and building-security information may require different treatment.

The data boundary should also address derived information. A summary, classification, or prediction can reveal sensitive facts even when the underlying record is not shown directly.

At minimum, management should know:

• Which data categories are permitted for the use case.
• Which systems and vendors process the data.
• Whether information leaves the controlled environment.
• Which roles can access prompts, outputs, and logs.
• How records are retained, corrected, or deleted.
• What contractual and legal requirements apply.

These questions belong in diligence for any technology that may become part of the first operating plan. Resolving them after a tool is embedded creates avoidable risk.

Keep accountable human judgment where it matters

"Human in the loop" is only meaningful when the person has authority, time, and context to challenge the system.

A reviewer who routinely approves hundreds of outputs without adequate information is not a control. Neither is a workflow that allows the AI recommendation to become the default before the reviewer acts.

Effective oversight defines:

1. The person accountable for the final decision.
2. The information that person must receive.
3. The circumstances that require additional review.
4. The actions the system may take without approval.
5. The process for correcting or reversing an output.

The standard should be higher when a decision is difficult to reverse or may materially affect a person, customer, tenant, employee, or investor.

Human judgment also matters during design. Frontline operators often understand edge cases that are not visible in a management workflow diagram. Their input can reveal when a model is likely to misclassify an event, omit context, or create a new burden elsewhere in the process.

Test the operating outcome, not only the model

Technical evaluation is necessary, but the investment case depends on operating performance.

A system may produce acceptable outputs in isolation and still fail inside the workflow. It may create more exceptions than the team can review, slow down a handoff, generate communications that require extensive editing, or shift work to a different part of the organization.

Acceptance criteria should therefore include both model behavior and operating impact. Depending on the use case, measures may include:

• Accuracy or error rates against an agreed test set.
• The frequency and type of human overrides.
• Response time, cycle time, or backlog.
• Customer, tenant, or employee complaints.
• Security, privacy, or access-control exceptions.
• The economic measure connected to the original operating thesis.

The baseline should be captured before deployment. Without it, management cannot distinguish genuine improvement from activity.

Prepare for failure before scaling

Every material workflow needs a fallback.

The operating team should know how to pause the system, continue the process manually, notify affected stakeholders, preserve relevant logs, and investigate what happened. A named owner should decide when the system can return to service.

Incident planning should cover more than technical outages. It should include incorrect outputs, unauthorized data exposure, harmful or inappropriate communications, unexpected vendor changes, and material drift in performance.

The same principle applies to vendors. Management should understand which capabilities depend on a third party, what contractual protections exist, how a provider communicates changes, and whether the organization can retrieve its data or transition the workflow if the relationship ends.

Governance should accelerate trusted adoption

Good governance is sometimes treated as friction. In practice, clear boundaries can make adoption faster.

When teams know which tools are approved, which information is permitted, when review is required, and how incidents are handled, they can move with greater confidence. Management can compare use cases across the portfolio. Ownership can evaluate whether the technology layer is producing measurable operating value without creating unmanaged exposure.

The goal is not to maximize the number of AI systems inside an asset. It is to use the right systems in the right workflows with enough control to trust the result.

For an investment firm, that is the relevant standard. AI should improve the quality and speed of execution after close. Governance is what makes that improvement durable.