Category comparison
AI governance platforms, compared.
A taxonomy rather than a league table. Six categories, sorted by the artifact each one produces and the reader that artifact is for.
Published 13 August 2026 · Last updated 13 August 2026
Why this is not a ranked list
Most comparison pages in this market are written by a vendor who places themselves first. That format is easy to write and easy to see through. It is also useless to a buyer trying to work out which of six unrelated problems they actually have.
So the sort key here is the artifact. Ask what a product leaves behind when it has finished working, and who reads it. That question separates the category cleanly, and it survives the fact that most vendors now market across several boxes at once.
Glacis sits in one of the six. This page says which one, and says just as plainly where it does not belong.
The six categories at a glance
| Category | What it produces | Who reads it | Strongest when |
|---|---|---|---|
| 1. Governance program platforms | An AI registry, risk tiering, model cards, framework mappings | Internal governance, legal, risk committee | The estate is large enough that nobody can list it from memory |
| 2. Certification and program automation | Continuously collected control evidence for an audit | An auditor, and prospects reading a trust center | A certification has to be reached and then held |
| 3. Monitoring and observability | Traces, dashboards, drift and quality signals | The team operating the service | Something is in production and somebody is on call |
| 4. Evaluation and red teaming | Benchmark scores and adversarial findings | The team choosing, tuning, or approving a model | A release decision is pending |
| 5. Runtime protection and guardrails | A blocked, redacted, or escalated action | Nobody, usually. The value is the action rather than a record | The failure mode is a bad output reaching a person |
| 6. Runtime evidence | A signed, verifiable record of what a configured control reported | Somebody outside the company: customer, auditor, regulator, underwriter | A counterparty has asked a question the other five cannot answer |
Row five is the interesting one. A guardrail that fires and leaves nothing behind is an operational feature, and a good one. It becomes evidence only when the decision it made is recorded in a form somebody else can check.
The categories in detail
Governance program platforms
Representative: Credo AI, Holistic AI, IBM watsonx.governance, OneTrust AI Governance
This is the system of record for the AI estate: an inventory of models and use cases, a risk tiering scheme, intake and approval workflow, model cards and documentation, and mappings from all of it to the frameworks that apply. Several add policy libraries and jurisdiction tracking, which is real work: the obligations move several times a year and keeping a mapping current is a full-time job somebody has to do.
This is the category that answers what AI do we have, who owns it, and what rules apply. If a governance committee exists and cannot produce that list on request, this is the purchase to make first. An enterprise workflow platform such as ServiceNow can carry a good deal of the same load if teams already live in it.
Certification and program automation
Representative: Vanta, Drata, Secureframe
These platforms continuously collect the evidence that a security program exists and is being operated, projected against SOC 2, ISO 27001, ISO 42001, HIPAA, and more. Integrations pull the underlying facts straight from cloud accounts, identity providers, and ticketing, which removes a genuinely large amount of manual work and turns audit season from a fire drill into a review.
Both major vendors have extended into AI framework coverage, and it does the same job for an AI management system that their earlier work did for information security. If a certification is the goal, this category is the right purchase and nothing else on this page substitutes for it. There is a longer treatment in Vanta, Drata and runtime evidence.
Monitoring and observability
Representative: Datadog, Arize, Fiddler AI, WhyLabs, Arthur AI, LangSmith
The output is traces, spans, latency, spend, output quality scoring, embedding drift, and the ability to reconstruct a multi-step agent run after the fact. The AI-native vendors in this group solved problems classical monitoring never had to handle, and did it quickly.
A team running AI in production without observability has a more urgent problem than evidence and should fix it first. The distinction between this category and the sixth is set out in AI monitoring vs AI assurance.
Evaluation and red teaming
Representative: open-source suites such as PyRIT and Garak, alongside commercial evaluation platforms
The work here is benchmarks, adversarial probing, jailbreak suites, and offline scoring against a test set. It answers whether a model is fit to ship and what its failure modes look like under pressure, which is the right question at the point of a release decision.
Its limit is inherent rather than a shortcoming: a pre-deployment result describes what a system was designed to do, not what it keeps doing against real inputs six months and two model updates later. See the red teaming guide for how the practice is usually run.
Runtime protection and guardrails
Representative: Lakera and the prompt-security cohort, plus guardrail libraries and cloud-provider safety tooling
This is inline defense at the moment an AI system acts: prompt-injection detection, output filtering, data-loss prevention on model egress, tool-call restriction, and escalation to a human. This category has grown fast because the failure mode it addresses is concrete and the fix is measurable.
What most of it does not produce is a durable record. The control fires, the bad output is stopped, and the value has been delivered. That is a reasonable design choice for an operational tool, and it is the exact seam where the sixth category begins.
Runtime evidence
Representative: Glacis, writing to the OVERT open standard
For actions routed through a configured boundary, the implementation can leave a signed, hash-chained receipt recording the control identities and outcomes that path reported. Depending on the configured receipt profile, the record can carry hashes rather than input or output text. A reviewer must inspect the actual profile and surrounding data flows before concluding that no payload or sensitive metadata leaves the environment.
This category is thin, and it is worth saying so rather than implying a crowded field with one obvious winner. Standards work on verifiable record formats is being written in more than one venue right now, which is healthy: a format only one vendor can read gives a reviewer a weaker basis for independent checking. One useful test is whether a reviewer can check supported properties against a published specification with disclosed trust material and no vendor account. You can try that test against a sample record in the browser.
Choosing, in the order that actually works
Work backwards from the reader rather than forwards from the feature list.
- Nobody outside the company has asked anything yet. Start with categories one and three, so you know what you run and can operate it.
- An auditor is coming. Category two will pay for itself in the first cycle.
- A model release is contested internally, which is the argument category four exists to settle.
- The risk is a bad output reaching a patient, a claimant, or a customer. That is category five, and it is better treated as a safety control than a governance one.
- A customer security review came back with AI rows nobody can answer, or an underwriter asked how you would know a control operated through the policy period. That is category six.
Buying in a different order tends to produce artifacts nobody reads. Evidence assembled before anyone has asked for it is shelfware with a signature on it.
Where Glacis does not fit
This part deserves the same plainness as the rest of the page. Glacis does not maintain an AI registry or a model catalog. It does not run an intake or approval workflow. It does not automate a SOC 2 or ISO 27001 audit. It does not benchmark or evaluate models. It is a poor substitute for an observability platform and should not be bought as one.
It evaluates configured controls at the point an AI system acts and produces a signed record of the decisions the configured path reported. Verification establishes integrity and key attribution for covered reported fields. It does not establish factual truth, control effectiveness, complete capture, system safety, or compliance. An evidence pack states the scope it covered rather than implying it covered everything.
If the problem is one of the other five, one of the other five is the better purchase, and saying otherwise would waste everyone a quarter.
Questions we get asked
How many categories of AI governance platform are there?
Six are useful to separate: governance program platforms, certification and program automation, monitoring and observability, evaluation and red teaming, runtime protection and guardrails, and runtime evidence. Vendors increasingly market across several of them, so the boundary that matters to a buyer is not the vendor name but the artifact the product actually leaves behind.
Which category do we need first?
Work backwards from the reader. If nobody outside the company has asked a question yet, a governance program platform and a monitoring platform cover the ground. If an auditor is coming, certification automation pays for itself. If a customer security review has AI rows nobody can answer, that is the point at which runtime evidence starts to matter. Buying in a different order tends to produce artifacts nobody reads.
Do we need a dedicated AI governance platform if we already have a GRC tool?
Often not, at least at first. An enterprise GRC or workflow platform can carry an AI registry, an intake process, and a risk tiering scheme perfectly well, and the teams who already live in it will keep it current. The case for a dedicated platform strengthens when the AI-specific content becomes the bulk of the work: model cards, dataset lineage, jurisdiction-by-jurisdiction obligations, and framework mappings that change several times a year.
Is runtime evidence a category or a feature?
Today it is a thin category, and it is worth saying so plainly. Standards work on verifiable record formats is still developing in more than one venue. Buyers should ask whether a reviewer can check supported artifact properties against a published specification without a vendor account, and which claims still depend on operator-supplied identity, enrollment, instrumentation, coverage, and source evidence.
Can one vendor cover all six categories?
Several credibly cover three or four, and consolidation is making that more common. The one combination that does not work is a single system generating both the AI output and its own governance record, because that is self-attesting by definition. Independence is not a feature that can be added from inside the system being examined, so at least the evidence layer has to sit outside the thing it describes.
Where does Glacis sit, and where does it not?
Glacis sits in the runtime evidence category and nowhere else. It does not maintain an AI registry, it does not run an intake or approval workflow, it does not automate a SOC 2 audit, it does not benchmark models, and it is a poor substitute for an observability platform. It runs controls at the point an AI system acts and produces a signed record of what those controls decided. Anything else on this page is better served by one of the other five categories.
Related reading
Work out which one you actually need.
Start free, or talk to us about a consequential AI workflow.