An AI model is updated, fine-tuned, retrained, or replaced in the time it takes to merge a pull request. These two speeds are not compatible. One of them is generating risk. The other one is trying to govern it.
This is not a complaint about governance being slow. Governance is slow by design. Deliberation, approval chains, documentation, stakeholder alignment — these are not bureaucratic failures. They are the mechanisms that make governance trustworthy. The problem is that AI systems were not designed around governance cycles. They were designed around development velocity. And in the gap between those two rhythms, risk accumulates without oversight.
Every commit that changes a model's behavior, every dataset update that shifts a system's outputs, every integration that routes AI decisions into a new business process — these are risk events. They happen continuously. They do not announce themselves to the governance team. They do not pause for a quarterly review. By the time the risk committee is evaluating the AI program, the AI program that was evaluated and the AI program that is running may be materially different.
The governance program that reviews AI systems quarterly is reviewing what the system was, not what the system is. In a development environment with weekly or daily deployments, quarterly review is a historical record of a system that has moved on.
The Commit as a Risk Event
Software development teams think in commits. A commit is an atomic change — a specific set of modifications to code, configuration, or data that moves from development into the deployment pipeline. In traditional software, commits change logic. In AI systems, commits can change behavior in ways that are qualitatively different and harder to predict.
A commit that updates a model's training data changes the population the model has learned from. A commit that adjusts a model's prompt template changes the framing that shapes its outputs. A commit that modifies the threshold at which a model's recommendation triggers an automated action changes the model's operational impact. None of these changes are necessarily visible in the commit message. All of them are risk events that a governance program built around quarterly reviews will not see.
The velocity problem compounds in organizations that have adopted continuous integration and continuous deployment. CI/CD pipelines are designed to move changes from development to production as fast and as safely as possible. Safety in a CI/CD context means the system works as expected. It does not mean the system's risk profile has been assessed. Governance gates that operate at the speed of CI/CD are rare. Governance programs that review AI systems quarterly are not reviewing CI/CD-deployed systems. They are reviewing the last stable release before the review meeting.
Where the Governance Gap Lives
Model Updates Outside the Governance Perimeter
Foundation model updates from AI vendors are among the most consequential and least governed AI risk events in enterprise environments. When an organization uses a third-party AI model via API, the model vendor updates that model continuously. Some updates are minor. Some are significant enough to change model behavior in ways that affect the organization's AI system outputs. The organization typically learns about updates through vendor release notes, if they are reviewed, and not through a governance process that assessed the risk of the update before it affected production systems.
Fine-Tuning That Changes More Than Intended
Fine-tuning a foundation model on organization-specific data is increasingly common. The process adapts a general-purpose model to a specific domain, use case, or organizational context. The governance challenge is that fine-tuning is not a precise surgical intervention. It changes the model's behavior in the intended domain and in ways that may not be fully anticipated in adjacent domains. A model fine-tuned on customer service data may exhibit changed behavior in edge cases that the fine-tuning dataset did not cover. Those behavioral changes are not assessed in most governance programs because the governance program is not structured to detect them.
Fine-tuning changes what the model has learned. It does not change only what you intended it to learn. The governance program that approves the fine-tuning without testing the model's behavior across the full operational envelope is approving a change it has not fully assessed.
Integration Changes That Expand AI Decision Scope
AI systems that begin as recommendation engines evolve into decision engines through integration changes that expand their role incrementally. A model that initially flagged transactions for human review is integrated into an automated workflow where its output triggers action without human review. The model did not change. The governance implications of the model's role changed significantly. Most governance programs assess AI systems at deployment and do not have a mechanism for detecting when integration changes have materially expanded the system's decision authority.
The Data Pipeline as a Governance Blind Spot
AI system behavior depends on the data it receives. Changes to the data pipeline — new data sources, changed data schemas, modified feature engineering logic — change what the model is actually processing. These pipeline changes may originate in data engineering teams who are not within the scope of the AI governance program. The model is unchanged. The inputs are different. The outputs may be meaningfully different in ways that the governance program has not assessed because it does not own the pipeline.
What Frameworks Are Actually Asking For
The EU AI Act's Article 9 risk management requirements are explicit that risk management for high-risk AI systems must be continuous throughout the system lifecycle, not only at deployment. The word continuous appears in the regulation because the drafters understood that AI systems change after deployment. Continuous risk management requires governance mechanisms that operate at a frequency compatible with the rate of change of the system being governed.
ISO 42001's AI management system requirements include monitoring and measurement of AI system performance and behavior throughout the operational lifecycle. The standard recognizes that an AI management system that only assesses systems at deployment is not managing the AI lifecycle — it is managing the deployment event. Post-deployment monitoring is an explicit requirement, not an optional enhancement.
The NIST AI Risk Management Framework's Govern function includes ongoing monitoring as a core component. The framework distinguishes between initial risk assessment and continuous risk monitoring, and it is explicit that both are required. An organization that has implemented initial risk assessment without continuous monitoring has implemented half of the Govern function.
The frameworks converged on the same requirement independently: AI risk management must be continuous. The governance programs that review AI systems quarterly and call that continuous have read the requirement and not operationalized it.
Practical Reconciliation
Reconciling governance cadence with AI development velocity does not require slowing down development. It requires building governance into the development process rather than running it parallel to the development process. The organizations that have made the most progress on this problem have done three things specifically.
They defined governance trigger events in the development process. Not every commit is a governance event. A commit that changes a model's core decision logic is a governance event. A commit that updates UI presentation is not. Defining what constitutes a material change to an AI system's risk profile — and building automated detection of those commits into the CI/CD pipeline — creates governance visibility at development speed without requiring governance review of every commit.
They built behavioral testing into the deployment pipeline. Automated behavioral test suites that run on every deployment detect changes in model output distributions, edge case handling, and decision threshold behavior. When a deployment changes behavior outside defined tolerances, a governance flag is raised before the change reaches production. Governance does not review every deployment. Governance reviews every deployment that crosses a behavioral threshold.
They created a model change log that the governance program actually reads. A simple, maintained record of what changed in the AI system since the last governance review — model version, training data version, integration changes, vendor model updates — gives the governance program the information it needs to conduct meaningful reviews rather than reviewing the same system it reviewed last quarter.
The Conversation Worth Having
The most productive governance conversation about AI risk velocity is not about slowing down development. It is about defining what the governance program needs to know in order to maintain meaningful oversight of systems that change faster than its review cycle.
That conversation typically reveals that the governance program does not currently have visibility into the inputs it needs: model change logs, behavioral test results, pipeline modification records, vendor update notifications. Building that visibility is a governance infrastructure investment that enables meaningful oversight at the pace AI development actually runs.
Governance that runs at a cadence incompatible with the systems it governs is not governance. It is record-keeping of historical states.
Build the governance infrastructure that can see what the AI system is doing today. The risk does not wait for the quarterly meeting.
Enterprise practitioner perspective. Not legal advice. Part of the Deep Trust Governance Series by Verisq. Get the free weekly Breach Digest.