The software changes every week. The model changes. The prompt changes. The data changes. The vendor changes. Yet the governance record often still says the same thing it said six months ago. 

There is a strange asymmetry inside modern AI teams.

The engineers know exactly which version of the application is running. The model has a version. The code has a commit hash. The deployment has a timestamp. The container has an image tag. The dataset may have a version or hash. The pipeline has logs. Even the infrastructure can usually tell you what was deployed, when and by whom. Then someone from risk or compliance asks a seemingly simple question:

“Which version of the AI system did we approve?”

The room gets quieter. Not because the organization has no documentation. It probably has plenty. There is an AI policy. There is a risk assessment. There may be a model card, approval record, vendor assessment, testing report and committee sign-off. 

The problem is that these artefacts often describe a version of the system that existed at a particular point in time, while the production system has continued moving. This is becoming a serious governance problem because AI development is increasingly behaving like software development: iterative, versioned, continuously deployed and dependent on a chain of models, datasets, prompts, configurations and external services. A 2026 Frontiers in Artificial Intelligence paper on “Audit-as-Code” describes exactly this gap: governance reviews can become stale while models, datasets, prompts, configurations and dependencies are modified across frequent releases. The paper argues for versioned policies and evidence linked to the specific artefacts being evaluated.

The uncomfortable part is that most organizations already understand version control. They just haven't applied the same discipline to governance.

Your engineers already know how to answer “Which version?”

Ask an engineering team what is running in production and you will rarely get:

“The latest one.”

You will get something closer to:

Model credit-risk-v17
deployed at 14:32 UTC
from commit a83f91c
using dataset customer_training_2026_09
with container prod-2.4.17.

That level of specificity exists because software teams learned a long time ago that you cannot reliably operate a system if you cannot identify its state. If something breaks on Tuesday, the team needs to know what changed between Monday and Tuesday. If a deployment has to be rolled back, someone needs to know what the previous state was. If an incident happens three months later, someone needs to reconstruct what actually ran. Version control is therefore not simply a developer convenience. It is part of how modern technology organizations establish reproducibility, accountability and operational control.

AI governance, however, has often developed on a different timeline. The governance record might say:

Model assessed: September 2026
Risk rating: Medium
Owner: Head of Credit
Approval: AI Governance Committee
Status: Approved

That may have been perfectly accurate when the assessment was performed. But what does it tell you about the system running today? Did the model change? Did the training data change? Did the prompt change? Did the decision threshold change? Did the surrounding application change? Did a vendor change the underlying model? Did the system gain access to another data source? Did a new retrieval layer get introduced? Did the business process itself change?

And, most importantly:

Which of those changes were part of the system that was actually approved?

That is where the governance version-control problem begins.

An approval is not a version

This distinction sounds obvious until you look at how enterprise governance actually works. An organization might approve an AI use case in January. The approval could include:

• a model assessment
• a data assessment
• an impact assessment
• security review
• human oversight requirements
• permitted use cases
• risk classification
• control requirements
• named owners.

Everything looks appropriately governed. Then the system evolves. The model is upgraded. A new prompt is introduced. The data pipeline is modified. The application starts using a new retrieval source. The vendor changes its underlying model. A business team changes the threshold at which the AI recommendation becomes actionable. 

None of these necessarily feels like “a new AI system.” The application still has the same name. The business owner is still the same. The dashboard still says “Approved.” The governance record still exists. But the thing operating in production may no longer be equivalent to the thing that was assessed.

This is precisely why the EU AI Act does not treat AI as something that is simply assessed once and forgotten. For high-risk AI systems, Article 12 requires automatic logging over the lifetime of the system, with logging designed to support traceability, identify situations that may lead to risk or substantial modification, and facilitate post-market monitoring. The regulation also defines a “substantial modification” in terms of changes after deployment that were not foreseen in the initial conformity assessment and that affect compliance or intended purpose.

The important idea here is not that every software update creates a new regulatory event. It is that the state of an AI system matters. Governance cannot meaningfully assess something whose state it cannot identify. 

The missing object in AI governance: system state

This is where the analogy with Git becomes useful. Git does not merely tell a developer: 

“This application exists.”

It allows the team to identify a particular state of that application. The commit tells you what code existed. The history tells you what changed. The branch tells you where it came from. The deployment system can tell you where it went. The repository can preserve the relationship between states.

AI governance needs a similar concept. Not necessarily Git itself. Not necessarily another developer tool. What it needs is a way to answer:

What exactly constituted this AI system at the moment we assessed, approved, deployed or relied upon it?

That state could involve several layers:

1. Model: Which model or model version was being used?
2. Data: Which dataset, retrieval source or data configuration was involved?
3. Prompt / instructions: What instructions governed the system's behavior?
4. Code / application: Which application version connected everything together?
5. Configuration: Which thresholds, rules, feature flags and settings were active?
6. Dependencies: Which external models, APIs, libraries, infrastructure or vendors were involved?
7. Permissions: What could the system access or do?
8. Governance: Which policy, risk assessment, control set and approval applied to that state?

The last item is where the traditional technology version-control model stops being enough. Because an AI system can change while the governance record remains frozen. 

The governance record needs a relationship to the thing it governs 

Imagine a bank has an AI system supporting credit decisions. In April, it completes its governance review. The review is linked to:

Model v4.2
Dataset v18
Prompt configuration A
Credit threshold 720
Vendor API version X

The committee approves the system. In June:

Model → v4.3
Dataset → v21
Prompt → configuration B
Threshold → 680
Vendor → silently upgrades underlying service

Now ask:

Is the April approval still describing the production system? There isn't necessarily a simple yes-or-no answer. Some changes may be immaterial. Some may already have been anticipated. Some may require testing. Some may require reassessment. Some may change the risk profile substantially.

The governance problem is therefore not simply:

“Did something change?”

Engineering already has tools for that. The harder question is:

“Which governance conclusions were attached to the previous state, and do they still apply to the current one?”

That requires a relationship between system state and governance state. Without it, organizations end up with two parallel histories. The engineering history says what the system became. The governance history says what the organization once approved. They may slowly diverge without anyone noticing. 

This is already becoming a recognized problem 

This isn't merely a philosophical concern.

NIST's 2026 work on monitoring deployed AI systems identifies fragmented logging across distributed infrastructure, detecting performance degradation and drift, navigating complex policy environments, and scaling human-driven monitoring alongside rapid rollouts as significant challenges. It also explicitly raises the unresolved question of how monitoring should relate to auditing.

The NIST AI RMF Playbook similarly treats post-deployment monitoring as involving change management, incident response, recovery, appeal and override, decommissioning and ongoing evaluation. It also calls for monitoring risks from third-party resources and pretrained models.

And the 2026 Audit-as-Code research pushes the idea further: governance requirements can be represented as versioned policy specifications and evaluated against structured evidence tied to data, models, provenance, performance, decisions and explanations. Its traceability approach specifically links outputs to the exact data, code, configuration and model versions involved.

The direction is clear. AI governance is moving away from:

“Here is the assessment we completed.”

toward:

“Here is the state of the system, the controls that applied to it, the evidence generated under that state, and the reason the governance conclusion still holds.”

That is a very different operating model.

The dangerous part is that most changes don't look important

This is where enterprises can get into trouble. A model version changing from 4.2 to 4.3 looks like an engineering detail. A prompt changing from version A to B looks like configuration. A threshold moving from 720 to 700 looks like a business decision. A retrieval source being added looks like a feature enhancement. A vendor upgrading its foundation model looks like the vendor doing maintenance. A permissions change looks like an IAM matter.

Individually, each can be explained. The governance problem appears when these changes interact. Suppose the model is upgraded, the training population changes, the approval threshold is lowered and the system receives access to a new customer-data source. No single change may trigger someone to say:

“Stop. We need to reassess the entire AI system.”

But collectively, the system may now behave differently from the one originally approved. This is why a governance system that only stores approval documents is insufficient. It needs to understand relationships between versions. 

Think of governance as a dependency graph, not a filing cabinet 

A traditional governance record often looks like a folder:

AI System

• Policy
• Risk Assessment
• Model Card
• Approval
• Testing Report
• Review

That is useful documentation. But it doesn't necessarily tell you how the pieces relate to the production system. A more useful representation looks closer to:

AI System

• Application version
• Model version
• Data version
• Prompt/configuration version
• Vendor version
• Permissions
• Business process
• Controls
• Governance decision
• Evidence

Now imagine the model changes. The question isn't merely:

“Did model version 4.2 become 4.3?”

The question becomes:

Which controls, assessments, approvals and evidence were attached to 4.2, and what must be reconsidered because 4.3 is now running?

That is the difference between recording change and understanding governance impact.

The strangest thing about AI governance may be its lack of a rollback button

Engineers have another useful concept that governance rarely gets in the same form:

rollback.

If a deployment introduces a problem, the team can often return to a known previous state.

But imagine an auditor asking:

“Show me the exact state of the AI system that produced this decision six months ago.”

The answer cannot simply be:

“We have the old policy.”

The organization may need to reconstruct:

• the model
• the data
• the configuration
• the prompt
• the application
• the vendor dependency
• the relevant controls
• the approval
• the evidence

That is effectively a governance rollback problem. If the organization cannot reconstruct the previous state, it may have an audit trail without having a reliable history. And that distinction matters. Because a history of documents is not necessarily a history of the system.

So what would “Git for governance” actually mean?

It does not mean putting compliance documents into GitHub and calling the problem solved. The deeper idea is version-linked governance. Every meaningful AI state should be connected to the governance state that applied to it.

For example:

System State 17

• Model: v4.2
• Data: v18
• Prompt: B
• Threshold: 720
• Vendor: X
• Permissions: P3

Governance State 17

• Risk assessment: RA-2026-04
• Policy: AI-POL-3.1
• Controls: C12, C18, C21
• Approval: AGC-042
• Owner: Credit Risk

Evidence State 17

• Testing results
• Monitoring records
• Decision samples
• Human review records
• Exceptions
• Incidents

Then System State 18 arrives. Something changes. The governance system should be able to show:

What changed?

More importantly:

What governance artefacts were associated with the previous state?

And:

Which conclusions may now need review?

That is much closer to how software organizations already think about controlled change. 

The real problem isn't that AI changes

AI changing is not the problem. Software has been changing for decades. Models will improve. Prompts will evolve. Data will refresh. Vendors will release new versions. Applications will be rebuilt. Business requirements will change.

The problem is losing the relationship between those changes and the decisions made about the system. That is what makes the governance problem fundamentally different from ordinary change management. A system can have excellent version control and still have poor governance. A company can have excellent governance documentation and still be unable to reconstruct what actually happened. The mature organization needs both.

The questions your AI governance team should be able to answer

Before the next governance review, ask five uncomfortable questions.

1. What exact state of the AI system did we approve?

Not just the system name. The actual model, data, configuration, dependencies and relevant operating conditions.

2. What has changed since that approval?

Not only deployments. Include vendor changes, data changes, permissions, prompts, thresholds and business-process changes.

3. Which governance conclusions were attached to the previous state?

Which risk assessment, control requirements and approval decisions depended on the old configuration?

4. What evidence proves that the current state is still covered?

Not that the system was once assessed. That the system as it exists now remains within the assumptions and controls that justified the conclusion.

5. If an auditor asked about a decision from six months ago, could we reconstruct the AI state that produced it?

That last question is the real test. Because if the answer is:

“We have the assessment somewhere.”

you may have documentation. You may not have traceability. The next generation of AI governance will look less like a binder and more like a system history This is the shift that organizations need to prepare for. The old mental model was:

AI system → assessment → approval → periodic review

The emerging model is closer to:

AI state → governed state → change → evidence → reassessment when necessary

The difference is subtle but important. Governance no longer sits outside the technical lifecycle as a document produced around it. It has to maintain a relationship with the thing being governed as that thing evolves.

That is why the title isn't really a metaphor. Your AI has Git. Your governance doesn't. And eventually, that mismatch becomes impossible to ignore. Because the hardest question in an AI audit may not be:

“Was this system approved?”

It may be:

“Show me exactly what you approved, show me what changed, and show me why your approval still applies.”

That is the point at which governance stops being a collection of documents and starts becoming a living system of record.

KlaritiQ is built around that gap: connecting AI changes, governance decisions, ownership and evidence so organizations can understand not only what their AI looks like today, but what changed, what those changes affected, and which governance conclusions still hold.