AI governance platform: a buyer's guide

An AI governance platform is a system of record and workflow for how an organisation builds, buys and uses AI. It links each AI system to an owner, a risk level, the obligations that apply, the controls that address them, the evidence that they work and the decisions that approved the system. Search results also call it AI governance software or AI governance tools; the labels overlap.

It solves a coordination problem. AI use spreads across teams, vendors and unsanctioned tools, while laws such as the EU AI Act, standards such as ISO/IEC 42001 and frameworks such as the NIST AI RMF expect organisations to know what they run and to show how they manage it. Without a shared record, answers live in inboxes and slide decks and go stale quickly.

A platform does not replace legal advice, a risk committee or technical testing. It gives those people one place to work and a traceable history.

A capable platform covers the whole path from discovering AI to evidencing and reviewing it. These are the capabilities most buyers should expect to evaluate.

• AI system inventory (AI registry): one record per system, covering purpose, owner, model and vendor, data used, affected people and lifecycle stage, plus discovery of shadow AI that teams adopted without approval.
• Risk classification: a repeatable way to place each system in a risk tier, for example against the EU AI Act categories, with the reasoning recorded.
• Regulatory and framework mapping: obligations from laws and standards mapped to your systems, with a visible release or version history so you know which text you are working against.
• Controls and evidence: defined controls, owners, tests and linked evidence such as documents, logs and reports, with review dates.
• Assessments: structured workflows for data protection impact assessments (DPIA), fundamental rights impact assessments (FRIA) and other risk reviews.
• Approvals and decision records: routing by role or risk, with a durable record of who decided what, when and why.
• Monitoring and incident handling: change triggers, drift or performance signals, incident logging and corrective actions.
• Reporting and audit export: board summaries, regulator-ready packs and exports that auditors can read without platform access.
• Vendor and third-party AI oversight: records of suppliers, model providers and dependencies, with due-diligence evidence.
• Integrations: ways to pull in inventory and signals from the tools you already run, and to push tasks to ticketing and messaging.
• Access control and audit trail: role-based permissions, separation of duties and an immutable log of changes.

Dedicated software is strongest when many systems, teams and obligations must be tracked together; spreadsheets are fine at small scale; GRC suites and MLOps tools cover adjacent ground. The table summarises what each is generally good at. Individual products vary, so test against your own use cases.

These approaches are complementary. Many organisations run MLOps tooling for technical signals and a governance system for decisions and evidence.

Start with your own scope, then test vendors against it with real systems. Use this checklist.

1. Define scope: which AI you build, buy and allow staff to use, which laws and standards apply, and who will use the tool.
2. List must-have capabilities from the features above and mark the rest as optional.
3. Run a pilot with three to five real AI systems, including one purchased tool and one high-impact use case.
4. Check how obligations and framework content are maintained, who updates them and how changes are shown.
5. Test evidence: can you attach, review, expire and export it, and trace it back to a control and a system?
6. Review security, hosting, data retention and access control, and ask for independent assurance documents.
7. Confirm which features are live today and which are planned, in writing.
8. Compare total cost over three years, including seats, systems, services and renewals.

Ask questions that force specific, checkable answers rather than marketing claims.

• Which capabilities are generally available today, and which are on a roadmap? Can we see the capability list with dates?
• How is framework and regulatory content authored, reviewed and versioned, and how are we told when it changes?
• How does the platform discover AI we have not registered, and what are the limits of that discovery?
• Where does AI inside the product itself operate, which models and sub-processors are involved, and can it be switched off?
• What does the audit trail record, can it be edited, and can we export decisions and evidence in an open format?
• How are roles, approvals and separation of duties configured, and what is supported for single sign-on?
• What happens to our data if we leave: export formats, deletion and timelines?
• How do you describe what the product does and does not do for compliance, and can we have that in the contract?

Build when your needs are narrow, you already run a GRC or workflow platform and you have engineers to maintain it; buy when you need AI-specific content, faster rollout and a maintained product. Building underestimates the ongoing work of tracking regulatory change, permissions, evidence and audit history.

Common pricing models are a platform fee by tier, per user or seat, per AI system or project, per workspace or client, or a custom enterprise agreement. Per-system pricing tends to suit small inventories, while seat-based pricing suits large governance teams. Ask what happens to price as your inventory grows, and which features sit behind higher tiers.

As a rough guide, a focused rollout takes several weeks to a few months, depending on the number of systems, the quality of existing records and how quickly owners respond. Treat these phases as indicative, not a promise.

1. Weeks 1 to 2: confirm scope, roles and risk tiers; configure workspaces and permissions.
2. Weeks 2 to 6: build the inventory, starting with the highest-risk systems and known shadow AI; classify each system.
3. Weeks 4 to 10: link controls, assessments and evidence for priority systems; set up approval routing.
4. Weeks 8 to 12: switch on monitoring and incident processes, produce a first management report and review gaps.
5. Ongoing: periodic reassessment, framework updates, new-system intake and evidence refresh.

The slowest step is usually people, not software: owners must supply accurate facts about each system.

Be wary of any vendor that implies the tool settles your legal position. No software can do that.

• Claims of automatic compliance, guaranteed compliance or a compliance score presented as proof you meet the law.
• Promises that using the tool will earn ISO/IEC 42001 certification or pass an audit; certification is decided by an accredited body.
• Features shown in demos that cannot be traced to a documentation page or a dated release note.
• No way to see how regulatory content is maintained, or no version history.
• Closed data: no export of the inventory, evidence index or decision history.
• Vague answers on where data is stored, which sub-processors are used and how AI inside the product is governed.
• Pressure to sign multi-year terms before a pilot with your own systems.

AIGovernr is one option among several. It organises work around each governed AI system: registration and risk classification, a governance plan, controls, assessments such as DPIA, linked evidence, findings and risks, approvals with a decision ledger, monitoring and incidents, a shadow AI registry and vendor records. It maps work to versioned framework releases, including the EU AI Act and NIST AI RMF, and ISO/IEC 42001 readiness, and states that framework coverage measures content mapping, not certification or legal validation.

Some capabilities are not yet released, including connectors that pull data from other tools, OIDC and SAML sign-in, and a public developer API; its capability ledger separates live from planned items. AIGovernr supports governance work and does not make an organisation compliant or certified.