🔄 You Approved the AI System Six Months Ago. Is That Approval Still Valid?

🔥 This is Part 5 of When AI Governance Meets Reality, a series exploring what happens when clean AI governance frameworks collide with the messy realities of enterprise adoption.

Your organization reviewed the AI system.

Legal looked at it.

Security assessed it.

The business owner documented the use case.

Governance classified the risk.

Approvals were collected.

The system went live.

Six months later, someone asks:

“Are we still comfortable with this?”

At first, the answer might seem obvious.

The system was already approved.

Why would the organization need to review it again?

Because the system that exists today may not be the same system that was approved six months ago.

The model may have changed.

The vendor may have introduced new functionality.

The business may be using it differently.

The data may be different.

The system may now operate in another geography.

Employees may have expanded the workflow beyond the original intended purpose.

Or the regulatory environment may have changed.

That creates a fundamental governance problem:

AI approval is usually based on a set of assumptions at a specific point in time.

When those assumptions change materially, the original decision may no longer be sufficient.

Most governance decisions implicitly answer a question like:

Based on what we know today, is this AI system acceptable for this use, with these controls, under these conditions?

That sentence contains several assumptions.

This AI system.

This use.

These controls.

These conditions.

Change one of them enough, and the reasoning supporting the original approval can start to break down.

Imagine an AI system approved to summarize internal customer-service conversations.

At approval, the organization determines:

Six months later:

The organization may still call it the same system.

The original vendor contract may still be in place.

The application name may not have changed.

But the actual risk profile may have.

That is why approval should not be treated as a permanent status.

It is better understood as a decision tied to a particular configuration and context.

A common response is to establish periodic reviews.

Every six months.

Every year.

At contract renewal.

That is better than never looking again.

But calendar-based review has a weakness.

It assumes meaningful change happens on schedule.

AI systems do not work that way.

A low-risk system may remain unchanged for 18 months.

Another system may materially change two weeks after approval.

So the more useful governance question is not:

“How often should we reassess AI systems?”

It is:

“What changes should trigger reassessment?”

That distinction matters.

Periodic reviews are time-driven.

Reassessment triggers are change-driven.

And for dynamic technology, change is often the more relevant signal.

There is no universal list that fits every organization.

But several categories of change should at least force the question:

Does this alter the assumptions behind the original approval?

A vendor replaces the underlying model.

A major version is introduced.

The organization moves from one model provider to another.

A foundation model is fine-tuned or materially reconfigured.

That does not automatically mean the system must go through a complete governance process again.

But it may affect:

If those were part of the original assessment, the change may matter.

This may be one of the most important triggers.

A system originally approved to assist employees begins influencing decisions about people, customers, patients, applicants, suppliers, or other consequential outcomes.

For example:

Original use:

AI summarizes candidate interview notes.

Later use:

Managers begin using those summaries to rank candidates.

Same tool.

Same vendor.

Very different role in the decision process.

Governance cannot only track what technology exists.

It also needs visibility into what the organization is actually doing with it.

The system begins processing:

The AI capability may be unchanged.

But the consequences of failure may now be different.

A system approved for public information may require a different assessment once confidential customer data starts flowing through it.

A pilot used by 20 employees becomes an enterprise deployment used by 20,000.

A tool originally restricted to specialists becomes available to frontline employees.

External customers gain access.

A system moves from one business unit into several.

Scale can change risk.

It can increase:

A governance decision made for a controlled pilot may not automatically scale with the deployment.

An AI system moves from:

Suggesting

to

Recommending

to

Acting

Consider the difference between:

“Here are three possible responses.”

and:

“The system automatically sends the response.”

Or:

“Here are the accounts that may require review.”

versus:

“The system automatically suspends the accounts.”

The technology may look similar.

The governance implications are not.

Increasing autonomy can materially change the control environment.

Third-party AI adds another layer of complexity.

The vendor may change:

Your organization may not control those changes.

But it may still inherit the consequences.

This is why vendor monitoring should connect to AI governance rather than sit completely outside it.

An AI system moves into a new country.

A new legal entity begins using it.

The organization launches it for a new customer population.

The workflow becomes subject to additional regulatory requirements.

The system itself may not change.

The context around it does.

And governance decisions are often highly context-dependent.

What if the technology begins behaving differently?

Accuracy declines.

Hallucination rates increase.

Bias testing reveals new disparities.

Users begin overriding recommendations more frequently.

Exception rates spike.

Complaints increase.

Governance should not only respond to design changes.

Observed system behavior can itself become a reassessment trigger.

The system may stay exactly the same while the rules around it change.

New regulations become applicable.

Regulators issue guidance.

Industry standards evolve.

Internal policies change.

A new risk appetite is approved.

A court or regulator clarifies an obligation that affects the use case.

That can change the organization’s assessment even if the technology has not moved at all.

There is an obvious danger here.

If every software update sends an AI system back through a complete governance review, the organization creates a new bottleneck.

That is not sustainable.

The goal should not be:

Change detected → Start governance from the beginning

A better model is:

Change detected → Assess materiality → Route appropriately

For example:

The change does not materially affect risk, intended use, data, autonomy, or applicable obligations.

Possible response:

Document the change and continue monitoring.

The change affects part of the existing assessment but does not fundamentally alter the system.

Possible response:

Conduct targeted reassessment.

Maybe Privacy needs to look again.

Maybe Security needs updated evidence.

Maybe the business owner needs to confirm the intended use.

Not everyone needs to restart the entire process.

The system’s purpose, risk profile, autonomy, data usage, or regulatory classification may have fundamentally changed.

Possible response:

Reclassify, reassess, and potentially seek renewed approval.

This creates a governance system that is sensitive to change without treating every change equally.

The concept sounds simple.

The implementation is harder.

Someone still has to decide:

Is this change material enough to matter?

That requires organizations to define what material change means in practice.

Useful questions might include:

The objective is not to create a perfect mathematical formula.

It is to make the reasoning consistent, documented, and repeatable.

Two similar changes should not produce completely different governance responses simply because different reviewers happened to receive the request.

There is another practical implication.

If an organization wants to know whether an approval is still valid later, it needs to remember why it approved the system in the first place.

That means an approval record should capture more than:

✅ Approved

It should capture the key conditions supporting that decision.

For example:

Approved use

Customer-service call summarization.

Approved model

Vendor Model X, Version Y.

Approved data

Internal call transcripts excluding specified sensitive data.

Human oversight

Employee review required before downstream use.

User population

Customer-service operations team.

Geography

United States.

Key controls

Access restrictions, logging, output review, vendor monitoring.

Now imagine one of those variables changes.

Governance can compare the current state against the approved baseline.

Without that baseline, reassessment becomes much harder because nobody can reconstruct what exactly was approved.

This is where the inventory becomes more than a list.

A mature AI inventory should help answer:

What was approved?

Under what conditions?

What has changed since approval?

Was the change assessed?

What decision followed?

That turns the inventory into part of the governance control environment.

The record becomes dynamic.

Not simply:

System A — Approved

But:

System A — Approved under defined conditions — Last reassessed after material change — Current status

That distinction becomes increasingly important as enterprise AI environments become more dynamic.

Many governance models implicitly look like this:

Identify → Assess → Approve → Deploy

Then the process stops.

A stronger lifecycle looks more like:

Identify

↓

Assess

↓

Approve

↓

Deploy

↓

Monitor

↓

Detect Change

↓

Assess Materiality

↓

Reassess Where Necessary

↓

Continue / Modify / Restrict / Retire

Governance becomes a lifecycle rather than a gate.

That is the important shift.

Because the job of governance is not merely determining whether an AI system can launch.

It is ensuring that the conditions supporting that decision continue to hold.

AI approval should have a memory.

Organizations need to know:

What did we approve?

Why did we approve it?

What assumptions did the decision depend on?

What has changed since then?

Does that change matter?

Without those answers, an approval can quietly become detached from the system it supposedly governs.

The approval remains.

The technology evolves.

The use expands.

The data changes.

The vendor updates the product.

And eventually the organization is relying on a governance decision that was made for a system that no longer exists in quite the same form.

That is why the better question is not:

“Was this AI system approved?”

It is:

“Are the conditions that justified its approval still true?”

Because responsible AI governance cannot only decide when systems are allowed to begin.

It also needs to recognize when the original decision deserves another look.

If your organization is building AI governance processes, reassessment triggers, AI inventories, classification workflows, or lifecycle controls, reply to this email.

The goal should not be to send every system through governance repeatedly.

It should be to create a disciplined way to recognize when something important has changed and route that change to the right level of review.

🔜 Coming next in Part 6 of When AI Governance Meets Reality:

Your AI System Passed Governance. Then It Started Performing Differently.

We’ll look at the gap between pre-deployment assessment and real-world performance and what monitoring should actually trigger after an AI system goes live.

This article is for general informational purposes only and does not constitute legal, regulatory, compliance, or professional advice. Organizations should evaluate AI governance requirements based on their specific technologies, use cases, jurisdictions, risk profiles, and applicable obligations.