Category comparison
AI governance platforms, compared.
A taxonomy, not 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, easy to see through, and 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. It is stated plainly where, and stated equally plainly where it does not belong.
The six categories at a glance
| Category | What it produces | Who reads it | Strongest when |
|---|---|---|---|
| 1. Governance programme 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 programme automation | Continuously collected control evidence for an audit | An auditor, and prospects reading a trust centre | 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, not a record | The failure mode is a bad output reaching a person |
| 6. Runtime evidence | A signed, verifiable record of what a control decided | 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 programme platforms
Representative: Credo AI, Holistic AI, IBM watsonx.governance, OneTrust AI Governance
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 programme automation
Representative: Vanta, Drata, Secureframe
Continuous collection of the evidence that a security programme 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
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
Benchmarks, adversarial probing, jailbreak suites, and offline scoring against a test set. This work 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
Inline defence 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
Controls run at the action boundary inside the operator infrastructure, and each governed action leaves a signed, hash-chained receipt recording which controls ran and what each one decided. A receipt carries a hash of the input and a hash of the output rather than the text of either, so it is safe to hand to a party who should never see the payload.
This category is thin, and it is worth saying so rather than implying a crowded field with one obvious winner. Standards work on verifiable receipt formats is being written in more than one venue right now, which is healthy: a format only one vendor can read is not evidence. The single test a buyer should apply is whether a reviewer can check the artifact against a published specification, with no account and no cooperation from whoever produced it. You can try that test against a real receipt 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. Categories one and three. Know what you run, and be able to operate it.
- An auditor is coming. Category two, and it will pay for itself in the first cycle.
- A model release is contested internally. Category four.
- The risk is a bad output reaching a patient, a claimant, or a customer. Category five, and treat it as a safety control rather 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. 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
Stated as plainly as the rest of it. Glacis does not maintain an AI registry or a model catalogue. 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 runs controls at the point an AI system acts and produces a signed record of what those controls decided. That record proves faithful recording under an enrolled identity. It does not prove every action was captured, it does not prove a system is safe, and it is never a compliance certificate. 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 programme platforms, certification and programme 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 programme 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. Very few products produce a record a third party can verify without trusting the operator, and standards work in this area is still being written in more than one venue. Buyers should treat a claim of verifiable evidence sceptically and apply one test: can a reviewer check the artifact using a published specification, with no account and no cooperation from the vendor who produced it.
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 and sign your first governed action today, or talk to us and we will tell you honestly if a different category fits better.