What to Demand from Enterprise AI Before You Approve It

Most enterprise AI compliance reviews are a one-time event. A set of queries gets tested, outputs get reviewed, access controls get verified. Someone signs off. The system goes live.

Six months later, the system you approved is no longer the system running in production — and nobody flagged the change.

This isn't a hypothetical. It's the structural problem with how most enterprises think about AI governance: as a launch gate, not an ongoing requirement. If you're a compliance lead or IT decision-maker being asked to sign off on an AI system, here are three questions that most approval processes skip — and what you should build in before you say yes.

1. What happens when the underlying data changes?

The system you're approving is validated against a specific snapshot of your knowledge base, policies, and regulatory guidance. That snapshot will change. Documents get updated. Regulations get revised. Policies get amended.

What usually doesn't happen:
a governance review gets triggered when those documents change.

Before you approve, ask:
Does this system have a mechanism to flag when the data it was validated against has materially changed?
If the answer is "we'll handle that manually," that's not a governance process — it's a hope.

What good looks like:
automated monitoring that detects document changes and routes them for review before users encounter the drift.

2. What happens when users go off-script?

AI systems get deployed for defined use cases. Users immediately find others.

A clinical documentation tool gets used to draft patient communications. An internal search tool gets used to answer customer-facing questions. A contract analysis tool gets applied to regulatory filings nobody anticipated.

These adjacent use cases often seem harmless — until a compliance team realizes they're outside the governance perimeter the system was designed for. The access controls, output validation, and audit logging were built for the original use case. Not the ones users discovered.

Before you approve, ask:
What happens when a user asks a question this system wasn't designed to answer?
If the system has no defined boundary behavior — no escalation path, no graceful decline — then the governance perimeter you're approving doesn't actually hold.

3. What happens when the model changes underneath you?

Most enterprise AI applications sit on top of a foundation model accessed via API. When that model gets updated by the provider — which happens regularly, sometimes without notice — the behavior of the application can shift in ways that aren't immediately obvious.

Outputs might be slightly different. Edge cases get handled differently. The validation logic tuned for one model version may not behave the same against the next.

The compliance sign-off you're being asked to give is for a system whose foundation can change without your knowledge or approval.

Before you approve, ask:
Is the system pinned to a specific model version in production, and is a model update treated as a change event that requires governance review?
If the answer is no, you're approving a moving target.

Governance Is a Condition of Approval, Not a Follow-Up Task

The failure modes above don't require exotic circumstances to surface. They're the ordinary consequences of treating AI compliance as a launch checkpoint rather than an ongoing operational requirement.

Here's what the distinction looks like in practice. A governed AI system has three properties that don't exist at launch — they have to be built in from the start:

Continuous data monitoring.
The system knows when the content it was validated against has changed, and it routes those changes for review automatically. Not a manual audit once a quarter. An ongoing signal.

Defined boundary behavior.
The system has explicit rules for what it can and can't answer — and when a request falls outside its governance perimeter, it escalates or declines rather than improvises. The governance perimeter doesn't just exist on paper. It's enforced at runtime.

Change management for the model itself.
Model updates are treated as change events, not infrastructure maintenance. Version pinning, pre-release testing, governance sign-off before migration. The foundation doesn't shift without a review.

These aren't advanced features. They're table stakes for a system that will hold up over time in a regulated environment. If a vendor can't point to all three during your evaluation, that's the answer.

If you want to go deeper on the framework behind this — how to govern what AI sees, does, and outputs on an ongoing basis — we wrote about it here → Context Engineering: The Missing Discipline in Enterprise AI

If you're evaluating enterprise AI for a regulated environment, let's talk.