All writing
Governance

What Happens When Your AI Model Updates and Nobody Tells Compliance

The compliance team spent six weeks documenting an AI system. By the time they finished, the model it described no longer existed.

The compliance team spent six weeks documenting an AI system. They mapped the data flows. They catalogued the training data. They assessed the model's outputs against fairness criteria. They produced a thorough, defensible governance artifact — the kind you want to have when a regulator asks how you're managing AI risk.

There was one problem. By the time they finished the documentation, the model it described no longer existed.

The silent governance event

Model retraining doesn't announce itself. There's no alarm. No notification goes to compliance, legal, or risk. The data science team retrains a model because that's what responsible data science looks like — new data becomes available, performance metrics shift, edge cases emerge. The team pulls fresh data, adjusts parameters, sometimes swaps in a different architecture entirely. They validate the new model against their test sets. Performance improves. They push it to production.

From the data science team's perspective, this is routine maintenance. It's the responsible thing to do. A model that isn't retrained is a model that's degrading.

From the governance team's perspective, something fundamental just changed and nobody told them.

The model that compliance documented — the one with the specific training data, the specific parameters, the specific behavioral characteristics — is no longer running. The system in production is a different model. It was trained on different data. It may behave differently in ways that matter. The risk assessment that took six weeks to produce now describes a system that doesn't exist.

The version gap

I watched this happen in real time. A risk assessment had been completed on a model three months prior. The assessment concluded the model met the organization's fairness and transparency requirements. It was thorough and accurate — for the model that was assessed.

During a routine audit, someone on the governance team asked a simple question: "Is the model currently running in production the same model that was assessed?" The data science team checked. It wasn't. The model had been retrained twice since the assessment. The training data had been expanded. A hyperparameter had been adjusted to improve precision. The model's behavior had changed in measurable ways.

Nobody had done anything wrong. The data science team retrained the model according to their standard process. The governance team documented the model according to theirs. The two processes simply didn't talk to each other. The data scientists didn't know governance needed to be notified. Governance didn't know retraining was happening.

The risk assessment that leadership was relying on — the one that said the system met fairness requirements — was governing a ghost. The model it described was already gone.

Why this keeps happening

The root cause isn't negligence. It's that model lifecycle management and governance operate on different timescales, in different tools, with different vocabularies, and usually in different parts of the org chart.

Data science teams work in experiment trackers, model registries, and CI/CD pipelines. Their workflow is built for iteration. A model isn't a finished product — it's a living artifact that improves over time. Retraining is part of the normal lifecycle. It happens on a schedule, or when triggered by performance thresholds, or when new data becomes available. The team tracks versions internally. They know which model is running.

Governance teams work in document management systems, risk registers, and compliance frameworks. Their workflow is built for assessment and documentation. A model, from their perspective, is an artifact to be evaluated at a point in time. The assessment captures the model's characteristics at that point. It doesn't automatically update when the model changes, because the governance team has no mechanism to detect that a change occurred.

These two workflows run in parallel. They don't intersect. The data science team doesn't think of retraining as a governance event. The governance team doesn't have visibility into the retraining pipeline. The gap between them grows silently with every retraining cycle.

What's actually at stake

This isn't an administrative inconvenience. It's a material governance failure.

If a model is retrained on expanded data that includes a demographic category that wasn't in the original training set, the fairness assessment may no longer be valid. If a model's architecture changes in a way that affects explainability, the transparency documentation may no longer be accurate. If a model's performance characteristics shift in a way that changes its error profile, the risk assessment may no longer reflect reality.

When a regulator asks to see your governance documentation for an AI system, they expect that documentation to describe the system that's running. If it describes a previous version — if you've been governing v1 while running v3 — you don't have a documentation problem. You have a governance gap. And you won't discover it until someone asks the question nobody thought to ask: is this still the same model?

Closing the gap

The fix is structural, not cultural. Telling data science teams to "remember to notify compliance" doesn't work. It relies on individual memory in a workflow designed for speed and iteration. The notification has to be automatic.

Model retraining needs to be a triggerable governance event. When a model is retrained and promoted to production, the governance pipeline should be notified the same way the deployment pipeline is notified. Not as a request. As a fact. The model changed. The documentation needs to be re-evaluated. The risk assessment may need to be updated.

This means connecting the model registry to the governance workflow. It means defining which changes constitute a material change that requires reassessment and which are minor updates that can be logged and reviewed periodically. It means treating model versioning as a governance input, not just a technical implementation detail.

The organizations that get this right treat retraining as a lifecycle event with governance implications. The organizations that don't are governing systems that no longer exist, and they won't know it until someone asks the right question at the wrong time.