AI governance tools: what the categories actually do
The phrase "AI governance tool" currently covers at least four distinct product categories that solve different problems. Evaluations go wrong when a buyer compares a documentation platform against a runtime enforcement point as though they were alternatives. They are usually complements, and the useful first step is deciding which problem you actually have.
By Agent Trust Cloud · Last updated
The four categories
Each is legitimate. They are rarely substitutes for one another.
- Governance and documentation platforms — model inventories, risk assessments, control mappings and audit artefacts. Strong for demonstrating a programme exists; they do not sit in the request path.
- Model observability and evaluation — quality, drift, bias, hallucination and regression testing. Concerned with output, not authority.
- AI security posture management — discovery of AI assets, misconfiguration and exposure. Tells you what exists and how it is configured, mostly out of band.
- Runtime control planes — identity, policy and enforcement at the point of action, producing evidence as a by-product. The only category that can stop something.
Questions that separate them quickly
Three questions usually establish which category a product is in, regardless of how it is marketed.
- Can it deny an action in flight, or only report on it afterwards?
- Does it know which agent and which human initiated a specific action, or only which application?
- Is its evidence generated by a control decision, or assembled from documentation people maintain?
Matching the tool to the problem
If the requirement is an auditor asking to see a governance programme, a documentation platform addresses it directly. If it is a model producing poor outputs, observability is the right instrument. If it is not knowing what AI exists, posture management finds it.
If the requirement is that an agent must not be able to release a payment above a threshold without approval, none of the first three can satisfy it — that needs a decision point in the path of the action.
The categories compared, by what each one is for
This comparison is Agent Trust Cloud's own framing, not an industry standard, and it names no vendors: we cannot verify other companies' products from here, so the table compares kinds of tool by what they do. It groups the market the way a buyer meets it. The four-way split above separates documentation, observability, posture and runtime control by function; the table below separates the tools by purpose, owner and limits, and puts the free baseline, spreadsheets, beside the products. Model observability is left out of it, because it is about the quality of outputs rather than governance of authority.
| Aspect | GRC and compliance-automation platforms | AI governance and model-registry platforms | AI security and runtime-control tools | Spreadsheets and templates |
|---|---|---|---|---|
| What it is for | Running a compliance programme across several regimes: controls, policies, evidence collection and audits. | Documenting AI systems: a register of models and use cases, risk assessments and control mappings. | Finding AI agents and keeping them inside what they are allowed to do. | Starting: a first inventory, a first risk triage, a first policy. |
| What it records or enforces | Records controls, owners, tasks and evidence. Enforces process, such as reminders and approvals, not the behaviour of a running system. | Records systems, assessments and approvals. Mostly records, and sits outside the request path. | Records what exists, what it can reach and what it did, and can enforce a decision at the moment of action. | Records whatever people type. Enforces nothing. |
| Who typically owns it | Compliance, risk or internal audit. | Risk, legal, data or an AI governance lead. | Security or platform engineering. | Whoever starts the work, often one person. |
| Where it stops | A control is only as true as the evidence someone attaches. It does not see an agent act. | Is as current as the people who maintain it. It cannot tell you that an agent's tool list changed last week. | Does not replace a compliance programme, a legal review or a judgement about an agent's purpose. | Goes stale, keeps no audit trail of its own and stops scaling once nobody can keep it current. |
| When to choose it | You already run a compliance programme and need AI to sit inside it. | You need an AI register and assessments you can show an auditor or use for the EU AI Act. | Agents can already take actions that matter, and you need to know what they can reach or to stop them. | You need a first pass this week, or want to see what an inventory should contain before buying anything. |
Where Agent Trust Cloud fits
Agent Trust Cloud sits in the third column. It is an AI security and runtime-control product, and it is not a GRC platform or a replacement for one. Its concepts are these, and they are the ones to test any candidate against:
- Inventory: agents and the machine identities they run as are recorded, from any framework, with the model, framework, tools, MCP servers, data sources, permissions and secrets each one holds.
- Owners: every agent has an owner field, and an identity with no owner is a finding rather than a blank cell.
- Reach: what each agent and credential can reach, and which agents depend on a given credential.
- Evidence: records produced by the decisions the system makes, exportable as an evidence pack, rather than assembled by hand afterwards.
- Runtime controls: policy checks before an action and enforcement at the point of action, starting in monitor mode so you can see the gap before anything is blocked.
What the standards say about tools
NIST AI RMF, ISO/IEC 42001 and the EU AI Act describe outcomes and duties: govern, map, measure and manage; operate a management system; meet obligations by date. We are not aware of one that requires a particular category of tool. Any category above can be part of meeting them, and the sources below are the places to check what each asks for.
A note on overlap
Vendors expand across these boundaries, so categories blur in marketing faster than in product. The evaluation that survives contact is a real scenario run end to end: pick one consequential action, and ask each candidate to show the action being attempted, the decision being made, the enforcement taking effect, and the record it produced.
Common questions
- What are the main categories of AI governance tools?
- In our own framing: GRC and compliance-automation platforms, AI governance and model-registry platforms, AI security and runtime-control tools, and spreadsheets and templates. They differ in what they are for, who owns them and where they stop, so they are usually complements rather than alternatives.
- When is a spreadsheet enough for AI governance?
- When you have a small number of agents and need a first inventory or risk triage quickly. It is a good start and a poor control: it records only what people type, goes stale, and enforces nothing.
- What is the difference between an AI governance platform and AI security tooling?
- Governance platforms document programmes and map controls; they generally sit outside the request path. Security tooling — particularly runtime control planes — makes and enforces decisions at the moment of action.
- Do we need more than one?
- Often, because they solve different problems. The mistake is treating them as alternatives and concluding you are covered because one of them is in place.
- How should we evaluate?
- Run one real consequential action end to end and require each candidate to show the attempt, the decision, the enforcement and the resulting record. Marketing categories blur; that sequence does not.
Sources
- NIST AI Risk Management Framework (primary source)
- ISO/IEC 42001:2023 (primary source)
- EU AI Act on EUR-Lex (primary source)
Related
Running AI agents in production?
A 90-day founding pilot of Agent Trust Cloud, bought and started online.
Start a founding pilot