AI Governance Platform Buyer's Guide: Criteria and RFP

Many AI governance programmes still run on a spreadsheet of use cases that is out of date the day it is circulated, while models, copilots and agents keep appearing in places the governance team never sees. AI governance platforms promise to fix that with an AI inventory, risk classification, impact assessments, approval workflows and regulatory mapping in one place. Products range from questionnaires with a dashboard to platforms that discover AI assets and pull evidence from monitoring tools. This vendor-neutral buyer's guide is for CISOs, AI risk and compliance leads, data protection officers and AI platform owners who are writing requirements or running an RFP. It covers what to define first, the criteria to score, the questions that expose weak answers, and a proof of concept you can run with your own AI estate.

Key takeaways

The inventory decides everything. A platform that relies on people registering use cases will miss shadow AI, embedded SaaS AI features and agents. Score automated discovery and reconciliation highest.
Classification must be explainable and versioned. Risk tiers against the EU AI Act, NIST AI RMF and ISO/IEC 42001 should show the rule that produced them and change when the law changes, as it did with the 2026 Digital Omnibus.
Documentation should be generated from systems, not typed. Model cards, technical documentation and impact assessments are only credible when they pull from registries, evaluation results and monitoring data.
Third-party AI is most of your AI. Supplier models, SaaS copilots and API providers need the same tiering, contract terms and monitoring as models you build.
The platform's connectors are privileged non-human identities. Read access to cloud accounts, model registries, code and SaaS tenants makes the platform a high-value target. Score its security as hard as its features.

Define requirements

Agree the following internally before talking to vendors, and write them into the RFP.

Your role under each regime: under the EU AI Act you may be a provider, a deployer or both. A deployer that puts its name on a high-risk system, makes a substantial modification or changes its intended purpose so it becomes high-risk is treated as a provider under Article 25(1). The platform must record role per use case, because obligations follow it.
Frameworks in scope: list the regulations and standards you must evidence: Regulation (EU) 2024/1689 (the AI Act) as amended by Regulation (EU) 2026/1744, the NIST AI RMF 1.0 and its Generative AI Profile (NIST AI 600-1), ISO/IEC 42001:2023, ISO/IEC 42005:2025 for impact assessment, sector rules and internal policy. See the AI Governance Guide.
Discovery sources: which systems can tell the platform that AI exists: cloud accounts, model registries, code repositories, the identity provider (OAuth grants to AI apps), SaaS management, network and browser telemetry, procurement and expense data. See the Shadow AI Discovery Guide.
What counts as an AI system for you: internally built models, fine-tuned foundation models, retrieval-augmented applications, agents with tools, AI features inside SaaS and AI used by suppliers on your data. For agents, record identities, tools and data access.
Workflow owners and integrations: who submits, reviews and approves a use case and who grants exceptions; which GRC, ticketing, monitoring and data catalogue tools the platform must connect to.

Obligation	What the platform must hold	Check during evaluation
EU AI Act risk classification (Article 6)	Tier per use case: prohibited, high-risk (Annex I or Annex III), transparency or minimal; documented Article 6(3) derogation assessments, which must be registered under Article 49(2)	Annex III dates moved to 2 December 2027 and Annex I to 2 August 2028 by the Digital Omnibus: is that reflected?
Technical documentation (Article 11, Annex IV)	Documentation drawn up before a high-risk system is placed on the market and "kept up-to date"; simplified form for SMEs and small mid-caps	Versioned documents linked to model versions, not static uploads
Logging and monitoring (Articles 12, 26 and 72)	Evidence that logs are kept (deployers keep them for at least six months) and that providers run post-market monitoring that will "actively and systematically collect, document and analyse relevant data"	Links to the systems that hold logs and monitoring results
Impact assessments (Article 27, ISO/IEC 42005, DPIA)	Fundamental rights impact assessments where required, AI system impact assessments and data protection impact assessments, linked to one use case	One assessment reused across regimes, not three questionnaires
NIST AI RMF	GOVERN 1.6 inventory mechanisms, GOVERN 6.1 third-party risk, MAP, MEASURE and MANAGE outcomes per system	Profile view of current versus target outcomes
ISO/IEC 42001	AI management system records: policy, objectives, risk treatment, Annex A control applicability, internal audit and management review	Statement of applicability export with justifications

Size changes the answer. A few dozen use cases, mostly SaaS copilots, may be served by an existing GRC platform's AI module plus shadow AI discovery. A provider of high-risk systems, or a bank with formal model risk management, needs documentation, evaluation integration and audit trails a bolt-on module rarely provides. See the GRC Platform Buyer's Guide.

Evaluation criteria

Weight these to your requirements. An illustrative split is 25% inventory and discovery, 20% classification and assessments, 20% documentation and evidence, 15% integrations and monitoring, 20% platform security, data handling and exit.

Criterion	What good looks like	Weak signs
AI inventory and discovery	Automated discovery from cloud, registries, code, IdP OAuth grants and SaaS; shadow AI and agents reconciled against registered use cases; each entry with owner, model version, data sources and identities	Inventory is a web form; no way to find what nobody registered
Risk classification	Rule-based tiering against EU AI Act Article 6 and Annex III, NIST AI RMF and internal policy; rationale stored; reclassification triggered by changes to purpose, data or model	A single risk score with no visible logic; tiers never revisited
Impact assessments	Configurable templates for AI system impact assessment (ISO/IEC 42005), fundamental rights impact assessment and DPIA, sharing common answers; reviewer sign-off and expiry	Separate questionnaires per regime; no link to the inventory record
Model cards and documentation	Model cards and Annex IV documentation generated from registry metadata, evaluation results and data lineage; import of machine-readable bills of materials such as CycloneDX ML-BOM	Documents uploaded as PDFs and never updated
Policy workflows and approvals	Use case intake, conditional routing by tier, segregation between submitter and approver, exceptions with expiry, decommissioning workflow	Approval is a status field anyone can change
Monitoring and evaluation integration	Pulls evaluation, drift, red-team and incident data from MLOps and observability tools; flags systems whose evidence is stale or failing	"Monitoring" means a periodic attestation by the owner
Third-party AI risk	Supplier and model provider tiering, AI-specific questionnaires, contract clause tracking (training on your data, sub-processors, Article 25(4) information duties), continuous monitoring of supplier changes	Generic vendor questionnaire with an AI tab
Regulatory content updates	Versioned regulatory libraries with change notes; impact analysis showing which use cases are affected by an amendment	Content updates are silent overwrites, or an extra-cost service
Audit evidence	Immutable history of who classified, assessed and approved what and when; evidence linked to controls; auditor read-only access; export by system and period	No tenant audit log; evidence assembled by hand for each audit
Platform security and data	SSO with enforced MFA, role-based access, named hosting regions, clear sub-processors, independent assurance, documented data export at exit	Vague data location; prompts or documents used to train the vendor's models

Connectors are privileged non-human identities

Automated discovery means the platform holds API keys, OAuth tokens, service principals and cloud roles with read access to your cloud accounts, model registries, repositories, identity provider and SaaS tenants. A compromised tenant could map every AI system you run and the data each one touches. The relevant risks are in the OWASP Non-Human Identities Top 10: NHI5:2025 Overprivileged NHI, NHI7:2025 Long-Lived Secrets, NHI2:2025 Secret Leakage and NHI3:2025 Vulnerable Third-Party NHI. Require read-only scopes, federated or short-lived credentials instead of static keys, a named owner per connector and an exportable connector inventory. The Salesloft Drift breach and the Vercel Context.ai OAuth breach both show how tokens held by one connected product open other organisations' systems. See the SaaS and OAuth App Governance Guide.

Questions to ask vendors

Connect to one of our cloud accounts and our identity provider and show us AI assets and OAuth-connected AI apps that are not in our register. How are agents and their tool permissions represented?
Show the rule that classified this use case as high-risk under Annex III. What happens to the classification when the intended purpose changes, or when we fine-tune the model?
How did you update your content for Regulation (EU) 2026/1744, and how did you tell customers which of their use cases were affected?
Can one assessment satisfy ISO/IEC 42005, an Article 27 fundamental rights impact assessment and a DPIA without duplicate questions?
Which fields in a model card or Annex IV document are filled automatically, and from which systems?
Which evaluation, monitoring and red-teaming tools do you integrate with, and how is stale evidence flagged?
For each connector, which permissions does it request, is it read-only, and does it support federated or short-lived credentials?
Where are our documents, prompts and metadata stored, are they used to train any model, and what independent assurance covers your platform?
What does pricing count (AI systems, users, frameworks, connectors) and what do we receive at contract end?

Red flags

"Automated compliance" claims with no visible classification logic or legal rationale.
An inventory that depends entirely on self-registration.
Regulatory libraries that still show pre-Omnibus deadlines, or that change without version history.
Connectors that need global administrator or owner rights, or only work with long-lived API keys.
No registry or monitoring integration, so documentation goes stale.
Vague answers on whether your documents and prompts train the vendor's own AI features.
No tenant audit log, or no export of assessments and evidence at exit.

Proof of concept

Scope it: pick ten real use cases covering an internal model, a retrieval-augmented assistant, an agent with tools, a SaaS copilot and a supplier model. Include at least one likely Annex III case. Agree weights and pass criteria first.
Connect with least privilege: create dedicated, read-only connector identities with named owners and expiry for one cloud account, the model registry, the IdP and one SaaS tenant. Record every permission requested; never use an administrator's personal token.
Test discovery: plant two unregistered AI assets (for example a model endpoint and an OAuth-connected AI app) and measure whether, and how fast, the platform finds them.
Classify and assess: run all ten use cases through classification and one full impact assessment. Have legal and privacy review the rationale for accuracy.
Generate documentation: produce a model card and an Annex IV-style document for one system and check how much is filled automatically and whether it updates when the model version changes.
Exercise third-party risk: tier one model provider and one SaaS supplier, send the AI questionnaire and track an issue to closure.
Run a mock audit, then exit: give an auditor read-only access to trace one approval end to end, then export everything, revoke every connector credential and confirm the connectors stop working.

Keep tracking after go-live: percentage of discovered AI assets with a registered owner, intake-to-approval time by tier, share of high-risk systems with current documentation and monitoring evidence, stale or failed connectors, and exceptions past expiry.

How NHI Mgmt Group can help

We provide independent AI governance and AI identity advisory, requirements and evaluation support. Browse vendors in our products directory or contact us.

AI Governance Platform Buyer’s Guide