Home/Guides/AI governance solutions: the three categories, and how to choose
Guide

AI governance solutions: the three categories, and how to choose

AI governance solutions fall into three groups. Learn what each one solves and the question that sorts a shortlist quickly.

The three categories, and what each actually solves

These are the three names used across every Difinity.ai page that categorises this market. The split is real, and vendors move between the groups. Every vendor fact below was read on 2 September 2026, and positioning here changes quickly.

  • AI inventory and registry tools. Catalogue what exists: discovery, ownership, classification, then a record of what was assessed when. Credo AI is the name that comes up most. Its product page also describes a Runtime Governance module doing trace ingestion and continuous evaluation, while the enforcement integration with CI/CD pipelines, cloud access security brokers and API gateways is described as planned. That makes this the group most likely to shift.
  • GRC and policy suites. Assess each system against the obligations that apply, hold the documentation, and support attestation. IBM watsonx.governance sits here, with a model inventory, monitoring for bias and explainability, and an Agent Monitoring and Insights capability added in Q1 2026 that tracks agent decisions and behaviour against threshold alerts. Holistic AI reaches the same job through testing, advertising more than 100 automated tests that cover bias and hallucination through to red-teaming, plus compliance mapping and shadow-AI inventory. Both monitor and alert rather than blocking an action before it runs.
  • Runtime enforcement platforms. Sit in the execution path and govern what agents do while they run, which means deciding before the action happens rather than describing it afterwards. This is where the agent problem lives, because an agent's failure mode is an action, and an action cannot be un-sent. It is also the thinnest group. Most products that use the phrase runtime governance are ingesting traces and evaluating them, which is a faster feedback loop rather than a control.

Match the category to your situation

NIST's AI Risk Management Framework gives a vendor-neutral structure for placing yourself. Its four functions are Govern, Map, Measure, Manage. Inventory and registry tools serve Map. GRC and policy suites serve Measure and the documentation side of Govern. Runtime enforcement is what Manage looks like when it happens during the work rather than after it.

  • If you cannot list the AI already running in your organisation, start with an inventory and registry tool. Nothing else works on an unknown estate.
  • If a regulator or an auditor is asking for documentation you do not have, a GRC and policy suite is the shortest path. Mapping to the EU AI Act, NIST AI RMF and ISO/IEC 42001 is standard across that category rather than a point of difference.
  • If a model is making or influencing decisions about people, you want the evaluation and monitoring those suites provide.
  • If an agent can act inside another system, you want a runtime enforcement platform. A record of the action it took is not a control over the action it takes next.
  • If more than one of these describes you, buy for the enforcement gap first. The other capabilities are easier to add later than to retrofit underneath a live agent.

The one test that separates the categories

OWASP's Top 10 for Agentic Applications, published on 9 December 2025, is a useful neutral checklist for this, because its entries describe things an agent does rather than things a model says: identity and privilege abuse, tool misuse, rogue agents. Pick three of those and put the same question to every vendor. Can the product stop this class of action before it executes, or does it tell me afterwards? Then ask for a demonstration of the refusal rather than a tour of the dashboard. A recorded refusal shows that the control exists; a chart of policy coverage does not.

How to evaluate a shortlist

Bring one real use case with a real system attached. A demonstration against a sample dataset tells you nothing about enforcement.

  • Ask the vendor to refuse an action live, in front of you, and then to show you the record of that refusal.
  • Ask what happens when the check itself fails or times out. A product that defaults to permit under failure is a logging product with extra steps.
  • Ask who can approve an exception, and whether that person is shown the actual action with its real arguments or a summary of them.
  • Ask which capability is shipped and which is on a roadmap. At least one vendor in this market currently labels part of its enforcement integration as planned.
  • Ask what can change the record after the fact, including the vendor's own support team.
  • Ask how the product behaves on the day one of your connected systems is down, because that is the day the defaults show.

Where Difinity sits

Difinity is in the third category. It does not extend a registry with an enforcement module bolted on; the governed run is the product. An organisation configures its use cases, its agents and its connections in Hub, and every run, chat or agent, goes through the same pipeline: checks on the incoming message, routing on the redacted text, the model call, then a check on the answer, in a fixed order that lives in the code rather than in a configuration option. Anything that changes something elsewhere is judged before it runs. The action leaves through the tool gateway, which holds the credential and decides, rather than through a log that describes what already happened. What happened is written to an append-only run trail as it happens, and it cannot be edited. Governed run records can contribute operational evidence to wider EU AI Act, ISO/IEC 42001, risk, and audit processes. Difinity does not determine that an organisation or AI system is compliant, and it does not provide ISO/IEC 42001 certification.

What this guide cannot tell you

Three caveats. The vendor facts above are a single dated snapshot taken on 2 September 2026 from each vendor's own material, and one of those pages could not be fetched directly, so the IBM detail came from search results rather than from the product page itself. Vendor self-description is also not evidence: a module named for runtime governance may ingest traces rather than refuse actions, which is why the demonstration test above matters more than the feature list. And no independent analyst category map for this market was located during the research for this guide, so the three-way split here is how we categorise these products, not a published taxonomy you can cite back to an analyst firm.

Frequently asked questions

Is an inventory and registry tool enough on its own?

It is enough to answer what AI you have and to satisfy a documentation request. It cannot stop anything. Once an agent can act in a production system, a registry tells you afterwards which agent did it, which is useful for the incident review and useless for preventing the incident.

Do we need a separate product for agents?

Not necessarily separate, but you do need enforcement in the execution path. Check whether the agent capability is a monitoring view over the same data or a control that sits between the agent and the system it wants to touch.

A vendor maps to ISO/IEC 42001. Does that make us compliant?

No. Mapping means the product organises evidence against the standard's clauses. Compliance is a determination about your organisation, made by your own accountable owners and, where applicable, by a certification body. Any product in this market contributes evidence to that process rather than concluding it.

How many of these do we need to buy?

You may need fewer than three. Start with the inventory, documentation and enforcement capabilities you already have, then buy for the missing control. Do not buy a second product from the same group unless it replaces the first.

Sources and further reading

Have an agent that needs production authority?

See the agent governance requirements checklist