Most enterprises can now describe, in reasonable detail, how they approved a given AI system. There was a risk assessment, a review, probably a named sign-off. Far fewer organizations can describe, with any confidence, whether that approval still reflects what the system is actually doing today. The model may have been retrained since. The use case may have quietly expanded from the one that was originally assessed. The vendor may have swapped the foundation model behind the product without telling anyone. None of that requires a new procurement cycle or a new vendor relationship — which means none of it necessarily triggers a new review under a governance program built around point-in-time approval.
A 2026 empirical analysis of 480 real-world AI incidents, drawn from the AI Incident Database and spanning 2020 through 2026, put a number on how wide that gap runs in practice. Across the incidents studied, 77.1% showed no evidence of the post-market monitoring the EU AI Act requires for high-risk systems, and 99.6% lacked documented evidence of a data-protection impact assessment. Governance failures were not isolated to one regime either — 9.8% of incidents were simultaneously non-compliant under two or more regulatory frameworks at once. The picture that emerges is not one of organizations lacking AI policies. It is one of AI systems operating, unmonitored, well past the point where their original approval could still be trusted.
The same study surfaced a finding that should reframe how boards, internal audit teams, and AI governance leaders think about monitoring investment: incidents caught through internal monitoring showed 87.5% documented EU AI Act compliance, against just 5.3% for incidents that surfaced externally — through a researcher, a journalist, an affected customer, or a regulator. Under NIST-aligned criteria, the same pattern held at 95.8% versus 58.1%. This is Crest.Digital's existing "Day 1 versus Day 100" framing — assessment tells you the risk at approval; monitoring tells you whether that decision is still valid later — applied to AI systems with a data set behind it for the first time.
See how a vendor and AI risk intelligence platform extends continuous monitoring from vendor relationships to the AI systems themselves — tracked at the model-version level, not just the point of purchase.
Explore Crest IntelligenceDay 1 Tells You the Risk. Day 100 Tells You Whether It's Still True.
An AI risk assessment answers a narrow, important, and time-bound question: given what this system does, what data it touches, and how it will be used, is it acceptable to approve today. That question has a defensible answer at the moment it's asked. The problem is that almost nothing about an AI system stays fixed after approval the way a piece of software once did. A model can be retrained on updated data. A provider can swap the underlying foundation model behind a product feature without changing the product's name or its contract terms. A business team can extend an approved use case — a summarization tool becomes a decisioning tool — without that expansion ever crossing a desk that would flag it as a new assessment trigger.
None of this is a criticism of assessment quality. A well-built AI risk assessment, applied consistently at approval time, is necessary groundwork — and organizations that skip it have a more foundational problem than the one this article addresses. The point is narrower: an assessment is a snapshot, and AI systems move fast enough that the snapshot ages out of relevance on a timeline measured in weeks or months, not years. Vendor risk programs learned this lesson about vendors a decade ago and built continuous monitoring to answer it. AI governance is now being asked to learn the same lesson about the systems themselves, on a compressed timeline.
What the Incident Data Actually Shows
The 480-incident analysis is worth sitting with because it moves the argument for continuous AI monitoring out of the realm of intuition and into measured outcomes. Two findings matter most for how an enterprise should prioritize its AI governance investment this year.
The first is the scale of the documentation gap itself. Post-market monitoring evidence was absent in more than three-quarters of the incidents studied, and data-protection impact assessment evidence was absent in nearly all of them. These are not edge cases or unusually opaque organizations — the sample spans six years of publicly documented AI incidents across sectors. The second, and more actionable, finding is the compliance gap between how incidents are discovered. Internally detected incidents showed 87.5% documented EU AI Act post-market monitoring compliance; externally detected incidents showed 5.3%. That is not a marginal difference — it is close to a sixteen-fold gap, and it isolates monitoring capacity, specifically, as the variable that separated the two groups.
The interpretation worth taking seriously is not that internal detection makes an incident less serious — the underlying event is the same either way. It is that organizations with functioning monitoring capacity had already assembled the evidence, assigned an owner, and begun a response before anyone outside the organization asked a question about it. Organizations without that capacity were caught flat-footed, reconstructing an evidence trail under the worst possible conditions: after the fact, under scrutiny, with a regulator, journalist, or customer already asking why nobody caught it sooner. That is the practical stakes behind the abstract phrase "continuous monitoring" — it is the difference between finding the problem yourself and having it found for you.
Crest.Digital pairs configurable AI risk assessments with continuous, model-version-level monitoring and agentic AI workflows — so drift, expansion, and vendor changes surface internally, before they surface anywhere else.
Why "It's a Feature Our TPRM Platform Already Has" Isn't Enough
Most mature vendor risk programs already run some form of continuous monitoring — a watchlist alert, a financial health signal, a cyber posture change on a vendor's record. It's tempting to assume that coverage extends naturally to AI, since a growing share of enterprise AI arrives through vendor relationships. It doesn't, for a structural reason: vendor-level monitoring watches the entity, not the system. A vendor's sanctions status, ownership structure, and financial health can all stay unchanged while the AI model embedded in their product is quietly retrained, re-versioned, or swapped for a different foundation model entirely under a subcontracted arrangement the buyer never sees.
That gap is exactly where undisclosed AI subprocessors live — a vendor risk assessment can pass cleanly while the AI actually doing the work sits several layers removed from anything the organization formally reviewed. And it compounds for AI built internally, where there is no vendor relationship to monitor at all: the system exists purely as an internal asset, and if the governance program's monitoring layer is scoped to third parties, an internally built system may not be watched by anything.
Article 72 of the EU AI Act (Regulation (EU) 2024/1689) is instructive here because it does not frame post-market monitoring as a vendor-management add-on. It requires providers of high-risk AI systems to establish and document a monitoring system, proportionate to the technology's risk, that actively and systematically collects and analyzes performance data across the system's full lifetime — evaluated against the system itself, its behavior, and its continued compliance, not against the reputation of the entity that built it. Deployers carry a parallel obligation to monitor operation and flag issues back to providers. Regulators are, in effect, already treating AI monitoring as its own governance discipline, distinct from vendor oversight, even where the two overlap.
Analyst guidance is converging on the same conclusion from a different angle. Gartner's AI TRiSM (trust, risk and security management) guidance argues explicitly that AI governance needs more than policy documents — it needs continuous monitoring, validation, and runtime enforcement embedded into how AI systems actually operate, rather than managed entirely from the outside through static documentation. That is the shift this piece is pointing at: continuous monitoring stops being a nice-to-have capability inside a broader TPRM platform and becomes a governance requirement that has to be scoped to AI systems specifically — purchased, embedded, and internally built alike — tracked down to the model version, not just the product or the vendor name attached to it.
An 8-Point Framework for Continuous AI Monitoring
Building this capability doesn't require a governance stack separate from the one already used for third-party and vendor risk. It requires extending the same monitoring discipline — track, alert, route, act, evidence — down to the level of individual AI systems and their versions.
AI System & Model-Version Inventory
Track every AI system — purchased, embedded, or internally built — down to the specific model or version in production, not just the product name.
Baseline Approval Record per Version
Capture the specific risk assessment, data scope, and approval conditions each version was cleared under, as the reference point for future monitoring.
Risk-Proportional Monitoring Signals
Define what to watch per system — drift, use-case expansion, vendor or subprocessor change, incident reports — scaled to its risk tier.
Continuous Data Collection Across the Deployment Lifecycle
Collect performance and usage data on an ongoing basis, from deployment through decommissioning, not as a one-time evaluation.
Internal Detection Capability
Prioritize catching monitoring signals internally — the evidence shows internally caught issues carry a far stronger compliance record than externally discovered ones.
Alert Routing to a Named Owner
Ensure every monitoring signal reaches a specific, accountable reviewer with authority to act — not a shared dashboard nobody is assigned to check.
Monitoring-Linked Reassessment Triggers
Connect monitoring signals directly to the conditions that automatically route a system back for formal reassessment.
Audit-Ready Monitoring Trail
Keep the monitoring record — signals watched, alerts raised, actions taken — retrievable in a form that can be produced on request.
Points five and six are where most programs currently fall short, and they're the two the incident data most directly supports. A framework with well-defined signals but no internal detection capability, or no clear owner for the alert once it fires, produces exactly the outcome the research describes: a monitoring system that exists on paper but doesn't catch the problem before someone outside the organization does.
Building the Program: A Six-Step Playbook
Turning the framework into an operating capability starts with the AI systems already running in production today, rather than waiting to design a perfect monitoring architecture before watching anything.
Continuous AI Monitoring Build Checklist
- Inventory every AI system down to model version: Include purchased AI, embedded AI features inside vendor products, and internally built systems alike.
- Capture the Day-1 approval as a baseline: Record what was assessed and approved, so later monitoring has something concrete to measure drift against.
- Define monitoring signals proportional to risk: Higher-risk systems warrant more frequent, more detailed monitoring than low-risk ones.
- Build internal detection capacity first: Treat the ability to catch a signal internally as the priority investment, not an eventual nice-to-have.
- Route every alert to a named owner: A signal with nobody assigned to act on it produces the same outcome as no monitoring at all.
- Connect monitoring to reassessment triggers: Close the loop between watching a system and formally reviewing it when a signal warrants it.
The step organizations most often skip is the first one — inventorying AI down to the model-version level rather than the product or vendor level. Without that granularity, a monitoring program can report that "the vendor is fine" while missing that the specific model doing the work has already changed underneath it. Getting the inventory right is less glamorous than building a monitoring dashboard, but it's the precondition that makes the dashboard mean anything.
Where Agentic AI Fits — Watching at a Scale Manual Review Can't Match
Continuously watching every AI system in an enterprise portfolio for drift, use-case expansion, vendor changes, and incident signals is not a task a compliance or risk team can sustain through periodic manual review — the volume and pace simply outrun a scheduled quarterly check-in. It is precisely the kind of ongoing, cross-referencing work agentic AI is well suited to, applied specifically to the monitoring layer of AI governance.
Continuous Signal Correlation Across the AI Portfolio
An agentic workflow can continuously pull together performance signals, usage patterns, and vendor or subprocessor status for every AI system in the inventory, converting what would otherwise be a manual, periodic check into a live, always-current view. This extends the same operational discipline Crest.Digital applies to real-time vendor risk monitoring to the AI systems sitting inside and alongside those vendor relationships.
AI-Assisted Drift and Expansion Detection
Once monitoring signals are centralized, an agentic layer can flag systems whose behavior has moved away from their approved baseline, whose use case has quietly expanded, or whose underlying model or provider has changed — prioritizing which signals warrant fastest attention based on the sensitivity of the data or decision involved. This is the same forward-looking discipline behind Crest.Digital's approach to connecting AI compliance policy to actual evidence: the goal is surfacing a gap internally, before it surfaces externally.
Human-in-the-Loop on Every Determination
What the agentic layer does not do is decide whether observed drift is acceptable, whether a system should be paused, or whether an exception should be granted. Those determinations stay with a named, accountable reviewer — informed by the signal the agent surfaced, not replaced by it. That division of labor is consistent with how Crest.Digital frames accountability for AI-related decisions more broadly, and with the audit-trail discipline behind reconstructing what an AI agent actually did: automation handles the continuous, volume-heavy watching, while judgment on what the signal means stays with a human.
Enterprises that already run continuous monitoring on their vendor and third-party risk programs hold a structural advantage extending it to AI systems — the underlying discipline is the same one: watch continuously, catch internally, route to an owner, and keep the evidence. What changes is the object being watched, and the pace at which it needs watching.
Frequently Asked Questions
Vendor monitoring tracks a third-party relationship over time — sanctions status, financial health, adverse media, cyber posture. Continuous AI monitoring tracks the AI system itself, at the model-version level, whether it is purchased from a vendor, embedded inside a broader product, or built internally. A model can be retrained or a subprocessor can change without the underlying vendor relationship changing at all, which means vendor-level monitoring alone can miss the exact events that matter most for AI governance. Continuous AI monitoring adds a layer that watches the system and its version history specifically, not just the entity that supplies it.
Article 72 of Regulation (EU) 2024/1689 requires providers of high-risk AI systems to establish and document a post-market monitoring system, proportionate to the technology and its risks, that actively and systematically collects, documents, and analyses data on the system's performance throughout its lifetime — so continuous compliance can be evaluated on an ongoing basis rather than assumed from a one-time approval. Deployers carry a parallel obligation to monitor operation against the instructions for use and inform providers of relevant issues. This makes post-deployment monitoring a documented legal obligation for in-scope systems, not an optional governance enhancement.
A 2026 empirical analysis of 480 real-world AI incidents found that incidents caught through internal monitoring showed far higher documented compliance than incidents that came to light externally — 87.5% versus 5.3% for EU AI Act post-market monitoring evidence, and 95.8% versus 58.1% under NIST-aligned criteria. The gap doesn't mean internally caught incidents were less serious — it means organizations with functioning monitoring capacity had already assembled the evidence, ownership, and response record before anyone outside the organization asked for it.
The same monitoring signals that feed continuous oversight double as reassessment triggers: a change to the underlying model or its version, measurable performance or output drift against baseline, an expansion of the approved use case, a change in data categories processed, a change in vendor, provider, or subprocessor, a security or privacy incident, or the passage of a defined review interval appropriate to the system's risk tier. Programs that define these triggers in advance can route a system back for review automatically. Programs that don't tend to discover the gap only after an incident forces the reassessment.
Watching every AI system in an enterprise portfolio for drift, usage expansion, vendor changes, and incident signals, continuously and at scale, is not a task a compliance or risk team can sustain through periodic manual review. An agentic AI layer can continuously correlate monitoring signals across the AI system inventory, flag systems whose behavior has moved away from their approved baseline, and route the finding to the accountable owner faster than a scheduled review cycle would catch it. It does not decide whether the drift is acceptable or whether an exception should be granted — those determinations stay with a named human reviewer, informed by the signal the agent surfaced.