In a recent episode of The Hitchhiker’s Guide to the GRC Technology Galaxy podcast, Michael Rasmussen (CEO GRC Report GRC Analyst) of sat down with Anthony Habayeb (CEO of Monitaur), and what started off sounding like a routine conversation about AI governance slowly turned into something much harder to ignore the longer it went on. Anthony introduced a framing that doesn’t really let you stay comfortable once you hear it, that a meaningful portion of what enterprises are buying today falls into what he called compliance theater, where documentation, workflows, and approvals create the appearance of control while the actual system continues running outside of anyone’s line of sight.
A governance dashboard shows green across every control, everything approved, everything signed off, and yet the model it cleared a few months ago is already drifting in production while nobody in the room can actually see it happening, which, if you pause on it for even a moment, starts to feel less like a technical gap and more like a blind spot that people have learned to live with. That distance between what gets recorded and what is actually happening is exactly what that framing is pointing at, and once it clicks, you start noticing how often those two realities quietly separate.
The conversation didn’t stop at pointing that out, it moved into how governance is supposed to function when it is actually doing its job. Rasmussen brought it back to something simple but easy to overlook, that governance is about achieving outcomes reliably while dealing with uncertainty as it shows up, not just documenting that a process happened and assuming it holds. When you apply that to AI systems, the tension becomes difficult to ignore. Platforms can show you that something was reviewed, approved, signed off at a moment in time, though they tend to go quiet when you ask what happens after deployment, when the system starts interacting with real inputs that don’t stay stable. The homeostasis analogy stayed for a reason, the body doesn’t check once and move on, it keeps watching, adjusting, correcting, because conditions keep shifting whether you pay attention or not.
After sitting with that, we went back through the vendor landscape with one question in mind, and honestly, it changed how everything lined up. Which platforms are actually observing deployed models, and which ones are organizing everything around them. The answer leaned heavily in one direction. Most of what is marketed as governance never touches production systems, it lives entirely at the documentation layer. The platforms that do connect to real behavior, that detect drift and validate outputs against what is actually happening, have largely been absorbed by major enterprise companies, and that pattern tells you more than any positioning statement ever will. You cannot govern what you cannot see, and if a platform has never connected to your deployed models and observed how they behave once they are live, then whatever it is doing, it is governing the record around the system rather than the system itself, which is usually where things begin to break once real pressure shows up.
Key Terms
Compliance Theater
Documentation, workflows, and approvals that create the appearance of governance without direct visibility into system behavior.
Real Governance
Control systems that connect to deployed models, observe their behavior, and enforce constraints based on what actually happens in production.
Production Monitoring
Continuous observation of model outputs, performance, and behavior after deployment, where the system is actively in use.
Model Observability
The ability to inspect, trace, and understand how a model behaves across inputs, outputs, and internal states over time.
Continuous Governance
An approach where governance operates in real time alongside the system, rather than through periodic checks.
Episodic Assessment
Point-in-time evaluations, such as audits or reviews, that assume system behavior remains stable between assessments.
Control Testing
Validation of whether governance controls function correctly when applied to real model outputs, not just documented processes.
AI Lifecycle Management
Oversight across the full lifecycle of an AI system, from development through deployment and ongoing operation.
Drift Detection
Identification of changes in model behavior, performance, or data patterns that move away from the approved baseline.
GRC
Governance, Risk, and Compliance, traditionally focused on policy, process, and documentation rather than direct system observation.
The Three Levels of AI Governance Maturity
Most teams, if we’re being honest, don’t actually realize they’re operating at completely different layers, mainly because everything gets labeled the same way during procurement, and that kind of flattens the differences until something breaks and suddenly the gap becomes obvious. The distinction isn’t sitting in a feature list somewhere. It shows up in what the system can actually see, react to, and keep up with once it’s live.
Level 1: Documentation Only
At this level, governance lives in forms, policies, mappings, and approvals, and to be fair, those pieces do matter because they establish intent and create a record someone can go back and review later. You get risk assessments, control libraries, regulatory mappings, approval workflows, and clean audit trails that show who signed off and when. It all looks organized, it feels complete, and in a lot of organizations it lines up nicely with existing GRC processes, which is exactly why it gets adopted so easily.
What it includes: risk assessment forms, policy documents, regulatory mapping, approval workflows, audit trails from human attestation
What it cannot do: observe how the model behaves after deployment or detect when that behavior shifts
Who lives here: IBM OpenPages, SAP GRC, ServiceNow AI Governance module, Archer, MetricStream, LogicGate, Navex, Diligent, Riskonnect, ProcessUnity, Prevalent
Why it gets bought: existing vendor relationships, no new procurement motion, familiar architecture that feels complete from the outside
Where this starts to strain, and you can almost feel it once systems go live, is after deployment. The model begins interacting with real inputs, conditions shift, and suddenly the documentation no longer reflects what is actually happening. The controls are written down, approvals are recorded, though nothing is actually watching whether those controls are still holding up.
Level 2: Monitoring Only
This layer shifts the focus toward the system itself, which is where things begin to feel more grounded, a bit more real. Platforms here connect to models in production and track behavior over time, looking for drift, performance changes, and output patterns that don’t quite match expectations. You start to see what the model is doing, not just what it was supposed to do, and that alone changes how teams react when something moves outside the baseline.
What it includes: real-time behavior observation, drift detection, performance tracking, output evaluation, production alerts
What it cannot do: connect those observations back to policy requirements, regulatory obligations, or coordinated governance workflows
Who lives here: Arize AI, Fiddler AI, Arthur AI, Evidently AI, Superwise, Censius, Seldon, Deepchecks, Aporia, Lakera
Why it keeps getting acquired: it provides the visibility layer enterprises realize they were missing, which is exactly why we’ve seen Cisco acquire Robust Intelligence, Snowflake acquire TruEra, and CoreWeave move on Weights and Biases to pull that visibility closer to infrastructure
The platform can tell you something changed, sometimes very precisely, though it can't tell you what that change actually means from a governance perspective or who is responsible for acting on it. The signal is there. The structure around it just isn’t.
What starts to become clear here, and this is where a lot of teams quietly get stuck during evaluation, is that Level 3 doesn’t replace this layer. It builds on it. You still need everything Level 2 provides, though it has to plug into something that can interpret and act on it in context.
Level 3: Governance Plus Monitoring Integrated
This is where the two sides finally start to come together, and you can feel the shift when it works. It’s harder to build, no question, though once you understand what to look for it becomes easier to evaluate. Platforms at this level connect policy requirements directly to what the system is doing, so controls aren’t just defined somewhere, they are actively tested against real outputs as the model runs.
What it includes: policy requirements connected to technical controls, controls tested against actual outputs, audit trails generated from system execution, regulatory documentation derived from operational evidence, coordination across the full lifecycle
Who is attempting this: Monitaur, Credo AI, ValidMind, Holistic AI, Adeptiv AI, Dynamo AI, Galileo AI, Patronus AI
Why so few are fully here: it requires solving both the documentation problem and the observation problem at the same time, which most vendors historically treated as separate efforts
You can trace a requirement from a policy document to a control, then to a test against real model behavior, and finally to an audit trail that reflects what actually happened rather than what was reported. It starts to feel less like maintaining records and more like managing a system that is continuously proving whether it is still within bounds.
The Acquisition Pattern Everyone Can See Once They Look For It
Over the last few years a few large infrastructure companies made moves that did not get enough attention at the time. Cisco picked up Robust Intelligence. Snowflake went after TruEra. CoreWeave moved on Weights and Biases. Different companies, different timing, though when you look at what each of them was actually buying the function is almost identical across all three deals.
Every one of those companies focused on what happens after a model is already deployed and running. Not during training, not during evaluation, but after the system is live and operating against real data that changes day to day and breaks assumptions that seemed reasonable when the model was first reviewed. That is the moment in a model's life that most teams do not have a clean way to observe, and that is exactly the gap these tools were built to close.
None of them were selling policy frameworks or approval workflows. None of them were built around documentation or checklists or regulatory mapping. What they provided was the ability to watch a model perform as conditions around it change, rather than relying on a snapshot of behavior from whenever the system was last formally reviewed.
Here is the thing about that, though. The word governance gets applied to all kinds of enterprise software, and most of the time it means documentation. It means records, approvals, controls. But none of the companies acquired at the highest valuations were governance platforms in that sense. They were monitoring platforms. They were the tools that actually sat inside the production layer and watched what systems were doing while they were doing it. The realization that follows from that is worth a moment of actual attention because it means the most valuable governance capability in the market right now is not the ability to document that a system was approved. It is the ability to observe what that system does after approval.
In production, behavior moves and the record does not move with it. Data shifts, inputs vary, and outputs drift in ways that do not surface immediately. Teams reference approvals from months ago because that is what the record shows, even when the system has evolved well past the state it was in when those approvals were issued. The companies that got acquired were sitting at exactly that gap, measuring the distance between what a system was supposed to do and what it was actually doing on any given day.
Those capabilities did not stay as standalone tools after the deals closed either. They moved closer to infrastructure, closer to compute, closer to the pipelines where models actually live and execute. That placement tells you something about how the buyers understood the problem they were not treating observability as a reporting layer that sits on the side. They were pulling it into the core.
The Decision Point Buyers Keep Avoiding
At some point in every evaluation, the same question surfaces, even when nobody frames it directly in the room. The platform demonstrates policies, approvals, mappings, and everything appears structured and complete, though there is always a brief pause where someone considers what happens once the system is no longer being reviewed but is instead operating against live inputs. That pause rarely holds. The conversation redirects toward features that can be shown, because those are easier to validate within the constraints of a buying process.
What complicates this further is that both sides present as complete during procurement. Documentation is organized, workflows are defined, and controls are mapped in a way that creates confidence during review. Monitoring platforms show activity, alerts, and performance metrics that feel equally sufficient when viewed on their own. Each component appears capable within its own boundary, and procurement treats those boundaries as interchangeable even when they are not operating at the same depth once deployed.
The tension does not appear during evaluation. It appears later, once the system is already in use and behavior begins to move outside what was visible during review. Teams return to the artifacts they approved. They check prior approvals, they review logs, and they attempt to reconstruct what changed and when it shifted. The answers remain incomplete because the system was never being observed in a way that ties behavior directly back to the controls it was expected to follow. The record exists, though the connection between that record and live behavior was never maintained.
This is where the separation becomes operationally clear. Some platforms maintain a clean history of what was defined and approved, which supports audit and review but stops at the boundary of execution. Others remain attached to the system itself and continue tracking behavior as it evolves over time, creating a continuous link between what was defined and what is happening. Both appear in the same category during evaluation, even though they diverge once the system is exposed to real conditions.
In practice, the difference becomes visible the moment behavior shifts. Teams either have a direct line of sight into how outputs are changing and how those changes relate back to defined controls, or they attempt to rebuild that sequence after the fact using whatever records were captured earlier. One path supports immediate interpretation tied to system behavior. The other introduces delay, interpretation, and dependency on incomplete context that was never designed to support real-time understanding.
Procurement does not fully account for that divergence, though the market response has already started to reflect it. Capabilities that remain connected to system behavior are being placed closer to where models execute and where data moves through production environments. That placement changes how teams rely on them, because they are no longer treated as optional validation steps. They become part of how system behavior is interpreted as it unfolds.
Even with that shift, buyers continue to evaluate both approaches as if they resolve the same underlying requirement. The difference only becomes clear once the system is operating under real conditions, at which point the architecture has already been set and the ability to change approach becomes constrained. That delay between evaluation and realization is where most of the risk accumulates.
What ultimately determines the outcome is whether the platform remains connected after deployment and continues observing how the system behaves as inputs change and conditions evolve. That connection defines whether governance remains a historical record of decisions or becomes an active function that operates alongside the system as it runs.
The Platforms Worth Evaluating
What follows groups vendors by what they stay connected to after deployment, because that connection determines how control holds once systems begin operating under changing inputs. The same product can feel complete during a demo and still leave a gap in production; placement here reflects what continues to be observed and enforced when the model is live.
Level 3 — Governance Plus Monitoring Integrated
Monitaur runs governance as an ongoing process across development and deployment, coordinating multiple stakeholders while testing controls against real model outputs; the company’s framing through its conversation with Michael Rasmussen helped bring this distinction into focus, and its differentiator shows up when controls are validated against behavior rather than attested by people.
Credo AI connects policy requirements directly into model development pipelines so that regulatory obligations map to what models do as they run, not to documents maintained alongside them.
ValidMind anchors model risk management in financial services by tying automated testing to actual outputs, with compliance artifacts generated from those results instead of written separately.
Holistic AI executes deep pre-deployment risk and bias evaluations through technical testing, covering the front half of the lifecycle while its continuous post-deployment monitoring remains in progress.
Adeptiv AI links governance and runtime observation through a broad set of metrics connected to deployed models and multiple regulatory frameworks at once, with architecture pointing toward full coverage while large-scale enterprise validation is still developing.
Dynamo AI evaluates models adversarially by running red teaming and compliance tests against outputs in operation, focusing on how systems behave under pressure rather than on self-reported checks.
Level 2 — Monitoring Worth Knowing
Arize AI observes production behavior and tracks changes over time, with recent movement toward inference-layer integration reflecting where observation is being placed
Fiddler AI maintains performance monitoring and explainability in regulated settings, while Arthur AI emphasizes interpretability for teams responsible for oversight.
Aporia enforces rules directly in the output path as responses are generated, and Lakera concentrates on prompt injection defense and runtime behavioral control at the same point of execution.
Patronus AI evaluates outputs continuously against defined criteria tied to policy and quality, and Galileo AI focuses on hallucination detection with feedback loops that inform model improvement.
Evidently AI provides strong visibility into drift and data movement with an open foundation, and Deepchecks tests model behavior across defined scenarios connected to pipelines.
These platforms consistently attach to running systems and produce evidence from behavior; that is also why they continue to be acquired or positioned for acquisition, aligning with the pattern where capabilities closest to execution are pulled toward infrastructure and data layers.
Level 1 — One sentence
If your current governance vendor introduced AI support as an extension to an existing risk or compliance platform, the earlier three-level framework describes what that means for visibility once the system is in production.
The next section moves from categorization to action, focusing on how buyers apply this distinction during evaluation and what to look for in live environments.
What Buyers Do Next When Systems Are Already Live
Most teams reading this already have models in production and existing vendors in place, so the task is deciding what to change within that reality rather than restarting evaluation from zero.
There is one question that consistently separates platforms once systems are live: after my AI model is approved and deployed, how does your platform know if it starts behaving differently. A credible answer walks through how the platform connects to running models, how it establishes a behavioral baseline, how it observes outputs continuously, how it detects drift as inputs change, and how those observations are evaluated against defined controls inside a pipeline that runs during operation; it names the data paths, the checks being applied, and where evidence is generated. Another type of answer describes scheduled reviews, reassessment workflows, escalation paths, and periodic audits that revisit the system at intervals; it explains process and ownership, and it stays centered on when people return to the system. Ask the question exactly as written and record the response word for word, because that record becomes a reference point you can compare against what the platform actually delivers several months after deployment.
Before bringing in anything new, count how many AI systems are currently running in production and how many of those have production monitoring attached right now. The difference between those two numbers is the exposure that exists regardless of documentation, mapped frameworks, or completed approvals, and it can be measured without any new contract or budget because it is an internal accounting exercise. Governance discussions often focus on systems under review, while the systems approved months ago continue operating with less attention, even though those are the ones most likely to have moved away from the conditions under which they were cleared.
During any evaluation, require a live technical demonstration that connects the platform to a deployed model and shows what it observes once that connection is established, and keep that requirement in place before the conversation shifts toward pricing or procurement. The demonstration needs to include the data flowing through the system, the outputs being produced, and the checks being applied in that environment, so that what is being shown reflects operation rather than presentation. When that demonstration cannot be performed during evaluation, the buyer is being shown documentation tooling, regardless of how the product is labeled, because an observation capability that does not appear against a real model during a sales process will not appear later when the system is under load.
Most organizations will not replace existing governance platforms immediately, given contract commitments, internal processes built around current tools, and procurement cycles that extend over time. A workable path keeps current documentation systems in place for regulatory mapping, audit trails, and policy management, while adding a monitoring layer that connects to production and closes the visibility gap between approval and the next formal review, which in many organizations spans months and sometimes longer. That interim architecture carries some complexity, though it restores a continuous connection to behavior while longer-term decisions are made about consolidating into a single platform that handles both documentation and observation within one system.
Decisions made here shape how governance operates under real conditions across organizations, and they set the direction for how regulated AI deployment will function over the next several years.
Our Take
AI Governance Take
Enterprises bought AI governance as a compliance exercise because that is how the category was introduced and sold, and the result is programs that can produce records showing review and approval while lacking a direct connection to what systems are doing in production. This outcome follows the structure of early market entry, where vendors with established GRC infrastructure and enterprise relationships defined the category in terms they could deliver immediately, so governance was framed around documentation, workflows, and audit readiness. That definition carried forward into procurement, and over time it normalized a model where control is inferred from records rather than verified against behavior. The gap that followed is specific and persistent: buyers were told governance meant documenting decisions and approvals, while operating systems require continuous visibility into how models behave after deployment under changing inputs.
The major frameworks shaping enterprise AI governance already point to that requirement in concrete terms. The NIST AI RMF GOVERN function assigns accountability across the full lifecycle, including third-party dependencies and behavior after deployment, and the MEASURE function requires ongoing monitoring and evaluation rather than point-in-time assessment. The EU AI Act requires continuous risk management under Article 9 and imposes post-market monitoring obligations under Article 61, which means providers must actively collect and review performance data once systems are live. ISO 42001 defines an AI management system as a continuous process with ongoing monitoring, review, and improvement. In practice, these requirements converge on the same operational need: observation of deployed system behavior over time. Documentation platforms can generate records that align with the letter of these frameworks, though the intent centers on continuous visibility into what systems actually do, and as enforcement becomes more specific, the distance between record and behavior becomes harder to reconcile.
Even with that direction, several issues remain unresolved. Cross-vendor interoperability is still limited, so enterprises running models across multiple environments and external APIs cannot rely on a single system to maintain consistent visibility and control across boundaries. Systems introduced outside formal review processes remain outside governance workflows, which leaves a portion of deployed activity without monitoring, without audit trails, and without any connection to policy controls. Decisions around building internally, purchasing platforms, or combining both approaches are still unsettled for many organizations, especially while consolidation continues and capabilities move closer to infrastructure layers. The market is advancing, though the pace varies between what organizations can operationalize and what vendors present during evaluation.
Enterprises are deploying AI systems into production environments today, and in many cases the governance layer responsible for those systems remains centered on documentation that is not connected to runtime behavior, while the frameworks requiring continuous monitoring are already in effect and the gap between requirement and delivery can be measured as deployment expands. GAIG tracks vendors building governance and monitoring infrastructure that connects directly to deployed models and produces evidence from system behavior in operation. The marketplace at GetAIGovernance.net organizes these platforms by category so enterprise teams can evaluate which options close the visibility gap described here; if the question from the previous section produced a process-based answer from your current vendor, the marketplace provides a starting point for reviewing platforms that operate against live systems.
