AI governance platforms are often bought on the strength of a polished questionnaire workflow, then found unable to discover the AI nobody registered or to produce evidence an auditor will accept. This template is for issuing a request for proposal (RFP) for an AI governance platform: software that holds the AI system inventory, classifies risk, runs impact assessments, generates documentation, tracks third-party AI and produces audit evidence against the EU AI Act, the NIST AI Risk Management Framework and ISO/IEC 42001. Requirements are numbered, typed and written so each answer can be tested and scored, and the template ends with a proof of concept plan. It is vendor-neutral and written for AI governance leads, risk and compliance teams, security architects and procurement panels. The capability areas and weighting are explained in the AI Governance Platform Buyer's Guide; this page turns them into contract-ready questions and does not repeat them.
How to use this template
- Replace text in square brackets, such as [Organisation], [GRC platform], [identity provider], [SIEM] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example AGP-INV-01) and a type: M mandatory (pass or fail), S scored (0 to 5) or I informational. Keep M items few: automated discovery, audit trail integrity, connector security and data handling are the strongest candidates.
- Before issue, complete Appendix A with three to five real use cases: for example a supplier SaaS copilot, an internally built retrieval application, an AI agent with tool access and, if relevant, a system you expect to be high-risk under the EU AI Act. Bidders answer against these and the proof of concept runs them.
- Weights in section 8 are illustrative. Fix them, and the scoring rules, before responses arrive.
- Issue sections 1 to 8 to bidders. The implementation guidance is for the panel only. Ask for responses in a spreadsheet with one row per requirement ID and an evidence column.
1. Purpose and scope
[Organisation] invites proposals for an AI governance platform to manage approximately [number] AI systems and use cases, of which about [number] are supplied by third parties, across [business units and regions], within [period]. The platform must maintain a reconciled AI inventory, apply risk classification, run impact assessments, generate and version documentation, manage policy workflows and exceptions, track third-party AI, ingest monitoring evidence, and produce audit-ready records against [EU AI Act / NIST AI RMF 1.0 / ISO/IEC 42001:2023 / sector rules / internal policy]. In scope: the platform, its connectors and discovery functions, workflow and reporting, regulatory content, APIs and deployment options. Out of scope: model hosting, AI gateways, guardrail runtime products and general GRC functions, unless offered as options in section 7.
2. Current state and intended use
- Existing records: [where the AI register lives today, for example a spreadsheet or GRC module], [number] entries, last reconciled [date].
- Discovery sources available: [cloud accounts], [model registries], [code repositories], [identity provider OAuth grant data], [SaaS management tool], [network or browser telemetry], [procurement and expense system].
- Frameworks to evidence: [list, with our role under the EU AI Act per use case: provider, deployer or both].
- Integrations required: [GRC platform], [ticketing], [MLOps and evaluation tools], [data catalogue], [SIEM], [identity provider].
- Constraints: data residency [region], hosting [SaaS / customer cloud / either], languages [list], users [number of submitters, reviewers, approvers, auditors].
3. Instructions to bidders
- Answer each requirement as Met, Met with configuration, Roadmap (with date) or Not met, and attach evidence: documentation link, screenshot, configuration export or independent report.
- State in one availability note per section which features need a higher tier, add-on module or professional services.
- Where regulatory content or classification logic is supplied, state who writes it, how it is reviewed and how amendments are released.
- List every connector, the permissions it requires in each source system and whether it can run read-only.
- Shortlisted bidders must take part in the proof of concept in section 8 using the Appendix A use cases and our own discovery sources.
4. Functional requirements
4.1 AI inventory and discovery
| ID | Requirement | Type |
|---|---|---|
| AGP-INV-01 | The platform discovers AI systems automatically from [list of discovery sources in section 2] and reconciles findings against registered entries, flagging unregistered AI for triage. | M |
| AGP-INV-02 | Each inventory entry records owner, business purpose, lifecycle stage, model and version, provider, data sources and categories, deployment location, user groups and the identities and tools the system uses. | M |
| AGP-INV-03 | AI features embedded in SaaS products and AI used by suppliers on [Organisation] data can be recorded and linked to the supplier record. | S |
| AGP-INV-04 | AI agents are recorded with their non-human identities, delegated permissions, tools, connected data stores and human owner. | S |
| AGP-INV-05 | Machine-readable bills of materials, such as CycloneDX ML-BOM, can be imported and linked to the model version in the inventory. | S |
| AGP-INV-06 | A change to model, data source, purpose, user group or tool access is detected or captured and triggers reclassification and reassessment (see 4.2 and 4.3). | M |
| AGP-INV-07 | Decommissioning is a workflow with evidence (access removed, data retained or deleted, documentation archived), not a status change. | S |
NIST AI RMF GOVERN 1.6 calls for mechanisms to inventory AI systems, resourced according to organisational risk priorities, and GOVERN 1.7 for safe decommissioning. See the AI Register and AI Inventory Template and the Shadow AI Discovery Guide.
4.2 Risk classification
| ID | Requirement | Type |
|---|---|---|
| AGP-CLS-01 | Classification rules for [EU AI Act risk categories / internal risk tiers] are configurable, and each result stores the rule version, answers and rationale that produced it. | M |
| AGP-CLS-02 | Our role per use case (provider, deployer, importer, distributor) is recorded and drives the obligations shown. | S |
| AGP-CLS-03 | When a regulatory library or internal rule changes, the platform lists the use cases affected and opens reclassification tasks. | S |
| AGP-CLS-04 | Classifications can be challenged, overridden with a recorded justification and approver, and expire for review on a set date. | S |
| AGP-CLS-05 | Describe any AI assistance used in classification, how its suggestions are shown to reviewers and how human decisions are recorded. | I |
See the AI Use Case Risk Tiering Guide.
4.3 Impact assessments
| ID | Requirement | Type |
|---|---|---|
| AGP-IMP-01 | Configurable templates for AI system impact assessment aligned with ISO/IEC 42005:2025, fundamental rights impact assessment under EU AI Act Article 27 and data protection impact assessment, sharing common answers so one use case is not assessed three times. | S |
| AGP-IMP-02 | The Article 27 template covers the deployer's processes, period and frequency of use, affected groups, specific risks of harm, human oversight measures and measures if risks materialise. | S |
| AGP-IMP-03 | Assessments have reviewer sign-off, segregation between author and approver, an expiry date, and are invalidated by a material change under AGP-INV-06. | M |
| AGP-IMP-04 | Assessments link to the inventory record, the risks raised and the treatment actions, with status visible on one page. | S |
See the AI Impact Assessment Template.
4.4 Documentation and evidence
| ID | Requirement | Type |
|---|---|---|
| AGP-DOC-01 | Model and system cards and technical documentation are generated from inventory, registry and evaluation data, versioned and linked to the model version they describe. | S |
| AGP-DOC-02 | Evidence is mapped to controls in [EU AI Act / NIST AI RMF / ISO/IEC 42001 Annex A / internal policy]; one artefact can satisfy several controls. | S |
| AGP-DOC-03 | An ISO/IEC 42001 statement of applicability, with justifications, can be produced and exported. | S |
| AGP-DOC-04 | Evidence older than its review period, or older than the last material change, is flagged as stale. | M |
| AGP-DOC-05 | Documentation and evidence can be exported per system and per period in [PDF / JSON / CSV] for auditors and regulators. | M |
See the Model Card and System Card Template.
4.5 Policy workflows, oversight and monitoring
| ID | Requirement | Type |
|---|---|---|
| AGP-WFL-01 | Use case intake routes by risk tier to the right reviewers, with segregation between submitter and approver enforced by the platform. | M |
| AGP-WFL-02 | Policy exceptions carry an owner, justification, approver and expiry, and expired exceptions raise alerts. | S |
| AGP-WFL-03 | Human oversight assignments for each system are recorded, with the competence and training evidence of the people assigned. | S |
| AGP-WFL-04 | Evaluation, drift, red-team and incident data can be ingested from [MLOps and observability tools] by API, and systems with failing or stale monitoring evidence are flagged. | S |
| AGP-WFL-05 | AI incidents and near misses can be logged, linked to the system and routed for regulatory reporting decisions, with timers configurable to the applicable rule. | S |
| AGP-WFL-06 | For deployed high-risk systems, the platform records where logs are kept and the retention period, so the EU AI Act Article 26 duty to keep automatically generated logs under the deployer's control for at least six months can be evidenced. | S |
| AGP-WFL-07 | AI literacy and role training completion can be imported from [learning system] and shown per system owner, reviewer and overseer. | I |
See the AI Incident Management and Escalation.
4.6 Third-party AI risk
| ID | Requirement | Type |
|---|---|---|
| AGP-TPR-01 | AI suppliers and model providers are tiered, with AI-specific questionnaires; state whether the CSA AI-CAIQ can be used or imported. | S |
| AGP-TPR-02 | Contract terms are tracked per supplier: training on our data, data retention, sub-processors, model change notification and information needed for our own obligations. | S |
| AGP-TPR-03 | Supplier changes (new model, new sub-processor, new AI feature) can be recorded and trigger reassessment of linked use cases. | S |
| AGP-TPR-04 | Supplier records can be synchronised with [GRC or third-party risk platform] rather than duplicated. | S |
NIST AI RMF GOVERN 6.1 expects policies and procedures for AI risks from third-party entities. See the Third-Party AI Risk Guide and the AI Vendor Security Questionnaire Template.
5. Security, audit trail and data handling
The platform reads cloud accounts, code, model registries and SaaS tenants, so its connectors are privileged non-human identities and it holds a detailed map of [Organisation]'s AI estate.
| ID | Requirement | Type |
|---|---|---|
| AGP-SEC-01 | Connectors run with read-only, least privilege permissions; list the exact scopes, roles or API permissions per source system. | M |
| AGP-SEC-02 | Connectors authenticate with workload identity federation or short-lived credentials where the source supports it; any static secret is held in [secrets manager] or an encrypted vault, rotatable without downtime. | M |
| AGP-SEC-03 | User access uses [identity provider] single sign-on with MFA and SCIM provisioning; roles separate submitter, reviewer, approver, administrator and read-only auditor. | M |
| AGP-SEC-04 | Every classification, assessment, approval, override and configuration change is recorded in a tamper-evident audit trail showing who, what and when; state retention and how integrity is protected. | M |
| AGP-SEC-05 | Audit and administrative logs can be streamed to [SIEM] in a documented format. | S |
| AGP-SEC-06 | The platform does not copy prompts, training data or model outputs from source systems unless configured; describe exactly what data each connector stores. | M |
| AGP-SEC-07 | State whether any AI feature in the platform uses customer data to train models, and how this is switched off. | M |
| AGP-SEC-08 | Provide current independent assurance (for example ISO/IEC 27001 certificate with scope, SOC 2 Type 2 report) and, if held, ISO/IEC 42001 certification for the vendor's own AI management system. | S |
| AGP-SEC-09 | Data is hosted in [region]; list sub-processors and their locations. | M |
See the Workload Identity Federation Guide.
6. Integration and reporting
| ID | Requirement | Type |
|---|---|---|
| AGP-INT-01 | A documented REST API covers inventory, classifications, assessments, evidence and findings for read and write. | S |
| AGP-INT-02 | Out-of-the-box integrations with [GRC platform], [ticketing], [data catalogue] and [MLOps tools]; list each and what it synchronises. | S |
| AGP-INT-03 | Dashboards report programme KPIs such as inventory completeness, assessment coverage, stale evidence and exception age, filterable by business unit and risk tier. | S |
| AGP-INT-04 | Board and committee report packs can be produced from live data, with a dated snapshot retained. | S |
The KPIs to put on those dashboards are in the AI Governance Programme Health Check and AI Governance Metrics.
7. Services, support, pricing and exit
- AGP-SVC-01 (S): implementation plan, roles and duration for the Appendix A scope, including connector set-up and regulatory content configuration.
- AGP-SVC-02 (S): support hours, severity definitions and response times; named customer success contact.
- AGP-SVC-03 (I): pricing model (per AI system, per user, per connector, per module) with a three-year cost for [number] systems and [number] users, and what triggers a price change.
- AGP-SVC-04 (M): full export of inventory, assessments, evidence and audit trail in open formats at any time and on exit, with data deletion certified within [number] days.
- AGP-SVC-05 (I): optional modules (for example AI gateway, guardrails, model evaluation) priced separately and not required for any M requirement.
8. Evaluation method and proof of concept
Mandatory items are pass or fail; a fail removes the bid. Scored items are weighted as follows (illustrative): inventory and discovery [25%], classification and assessments [20%], documentation and evidence [20%], workflows, monitoring and integrations [15%], security, audit trail and data handling [20%]. Commercial terms are scored separately.
Proof of concept plan for shortlisted bidders, over [number] weeks, using read-only test connectors with time-limited credentials:
- Connect to [two discovery sources] and report AI found that is not in our current register; the panel verifies a sample.
- Register the Appendix A use cases and classify each; inspect the stored rationale and rule version.
- Change one use case (new model version and new data source) and confirm reclassification and reassessment tasks open and old evidence is flagged stale.
- Run one impact assessment covering ISO/IEC 42005, Article 27 and DPIA questions and confirm shared answers are reused.
- Generate a system card and export the evidence pack for one system; an internal auditor reviews it.
- Attempt self-approval of a submitted use case and confirm it is blocked; review the audit trail entry.
- Export audit logs to [SIEM] and confirm each connector's permissions match the bid response.
- Revoke all test credentials at the end and confirm connectors stop.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Run discovery before issue: even a manual sweep of OAuth grants, expense lines and cloud AI services sizes the RFP and gives a baseline to test AGP-INV-01 against.
- Weight discovery and evidence over forms: questionnaire builders are similar across products; the ability to find unregistered AI and keep evidence current is where they differ.
- Score the platform as a privileged system: its connectors read sensitive estates. Treat section 5 like any other high-value non-human identity review; see the NHI Security Checklist.
- Small vs large organisations: a small estate of mostly SaaS copilots may be served by an AI module in an existing GRC platform plus shadow AI discovery; make AGP-INV, AGP-SEC and AGP-SVC-04 the M items. A provider of high-risk systems or a firm with formal model risk management should also make AGP-DOC and AGP-WFL-04 mandatory.
- Use the CSA AI Controls Matrix for supplier depth: AICM v1 sets 243 control objectives across 18 domains, mapped to ISO/IEC 42001, NIST AI RMF and the EU AI Act; the AI-CAIQ questionnaire can supplement section 5.
- Confirm regulatory status yourself: application dates and obligations under the EU AI Act have been amended; check the current text on EUR-Lex before fixing which obligations are mandatory, and score how quickly the vendor's content reflected the change.
Standards and references
- EUR-Lex: Regulation (EU) 2024/1689 (Artificial Intelligence Act)
- NIST: AI RMF Playbook, Govern
- ISO: ISO/IEC 42005:2025 AI system impact assessment
- Cloud Security Alliance: AI Controls Matrix
- CycloneDX: Machine Learning Bill of Materials (ML-BOM)
- EU AI Act Explorer (unofficial): Article 27 Fundamental rights impact assessment
This template is provided for guidance and must be adapted to your organisation. Related NHI Mgmt Group resources: AI Governance Platform Buyer's Guide · AI Governance Guide · AI Governance Programme Health Check · Security Vendor Evaluation and RFP Guide