AI Governance RFP Template (Free): Platform Requirements

Preview Download Ms Word Template
13 pages
0 downloads
Updated October 5, 2026

Use this AI governance RFP template when you're choosing a platform to inventory, assess and approve the AI your organization builds, buys and uses inside vendor products, and to keep the documentation and evidence that show how each system is governed.

It's written for the risk, compliance, legal, privacy, data science and procurement team running the evaluation, and it covers the whole process: when to issue an RFI first, the requirements to send, the questions that separate vendors, and how to score the answers.

What’s inside this template

  • A step-by-step plan for running the evaluation, with an example schedule and advice on when to issue an RFI first
  • Requirements for AI inventory, intake, risk classification, impact assessments, policy management, framework mapping, model documentation, testing evidence and monitoring, each marked Must-have or Nice-to-have
  • Third-party AI risk requirements, including AI features inside the software you already license
  • Questions that expose thin framework content, manual-only connectors and roadmap-only features
  • A weighted scoring rubric with 1-to-5 definitions
  • An editable Word RFP with response codes, a pricing table and a timeline

Download the editable Microsoft Word version below. Every requirement, vendor question and scoring weight on this page is in the document, ready to tailor and send.

More Templates

GPU Cloud RFP Template: AI Infrastructure Requirements

Paste-ready GPU cloud requirements (capacity commitments, cluster networking, storage, scheduling, isolation, inference, pricing), vendor questions that separate providers, and a scoring rubric.
View Template

LLM Gateway RFP Template (Free): AI Platform Requirements

Paste-ready LLM gateway requirements (routing and fallback, per-team keys, budgets, caching, logging, guardrails, data residency), vendor questions that separate platforms, and a scoring rubric.
View Template
Synthetic Data Generation Solution RFP Template

Synthetic Data Generation Solution RFP Template

Identifies and selects a comprehensive synthetic data generation platform that can create artificial datasets mimicking real-world data patterns while maintaining privacy and statistical accuracy.
View Template

How to run an AI Governance RFP

An AI governance platform sits between legal, risk, privacy, security, data science and procurement, so much of the early work is agreeing who owns which decision and which frameworks your program follows. The example schedule below runs about 13 weeks from kickoff to contract award; allow longer if your risk tiers and approval process aren't written down yet.

  1. Agree on scope and frameworks (weeks 1-2). List the AI you need to govern: models you build, generative AI applications and agents, and AI features inside the software and services you buy. Name the frameworks your program follows, such as the EU AI Act, ISO/IEC 42001, the NIST AI RMF or sector model-risk rules, and have counsel confirm which obligations apply to you. Record the numbers vendors will price against: AI systems, users, legal entities and AI vendors to assess.
  2. Assemble the buying team. Include an executive sponsor, the AI governance or risk lead, legal and privacy counsel, information security, data science and ML engineering, procurement and third-party risk, and internal audit. Decide early who owns the inventory and who approves higher-risk systems, because the platform's workflows will encode those decisions.
  3. Write down your process, and decide whether you need an RFI (weeks 2-4). Draft your risk tiers, intake questions and approval steps before vendors shape them for you. If you're unsure whether you need a dedicated platform or an AI governance module in your existing GRC or ML platform, or your long list has more than five vendors, issue a short RFI first and use the answers to build a shortlist.
  4. Tailor and issue the RFP (weeks 4-7). Delete requirements that don't apply, adjust priorities, and add your environment and framework list to Section 1. Give vendors three weeks to respond, with a written question-and-answer window in the first week.
  5. Score the responses (weeks 7-8). Have each evaluator score independently against the rubric before comparing notes, and set aside any vendor that misses a Must-have. For every framework a vendor says it supports, check who maintains the content, how it is reviewed, and whether it is generally available today or still on the roadmap.
  6. Run a proof of concept with two or three vendors (weeks 8-12). Load a sample of real systems: one higher-risk model you built, one generative AI application or agent, and one vendor product with embedded AI. Take each through intake, classification, assessment, approval and evidence collection, connect at least one ML platform and your ticketing system, and time how long a reviewer takes to answer an auditor's question from the record. Call references of a similar size and regulatory scope.
  7. Negotiate and award (weeks 12-13). Use the pricing table to compare like for like. Settle the pricing metric (AI systems, users, entities or assessments), framework content fees, renewal caps and full data export before you sign, not after.

AI Governance RFP requirements

Each line is written to paste straight into your RFP. Must-have means a vendor that cannot meet it is out; Nice-to-have earns extra points. Change the priorities to fit your situation, and delete what doesn't apply.

Functional

ID Requirement Priority
F1 A central inventory of AI systems, models, datasets, prompts, AI agents and use cases, with defined relationships between them, a named owner and accountable executive, business purpose and lifecycle status for each. Must-have
F2 Inventory records for AI used inside third-party products and services, including AI features enabled in software we already license, linked to the vendor and contract record. Must-have
F3 An intake workflow for proposed AI use cases, with configurable questions that route each request to the right reviewers (for example, legal, privacy, security or model risk) based on the answers. Must-have
F4 Risk classification against our own risk tiers and against the risk categories of the frameworks we follow (for example, the EU AI Act) [confirm with counsel], with the rationale recorded for every classification decision. Must-have
F5 Configurable risk and impact assessment templates with conditional logic, covering dimensions such as privacy, safety, fairness, security and effects on individuals, so lower-risk systems get a lighter review than higher-risk ones. Must-have
F6 Inherent and residual risk scoring, with mitigations, accepted risks and exceptions recorded against each system. Exceptions must carry a named approver, an expiry date and a review reminder. Must-have
F7 Reassessment triggered on a schedule, by material changes (a new model version, new training data or a new use) and by monitoring alerts. Must-have
F8 A policy library with versioning, approval workflow and effective dates, where each policy statement maps to controls and to the AI systems in scope, and a policy change flags the systems it affects. Must-have
F9 Attestation campaigns in which staff acknowledge our AI acceptable-use policy, with completion tracking by team. Nice-to-have
F10 A control library that maps one control to requirements in each framework we name (for example, the EU AI Act, ISO/IEC 42001 and the NIST AI RMF) and to our own internal and sector frameworks, so evidence collected once counts toward each. Must-have
F11 Templates for model cards, system cards and dataset documentation, versioned with the model or system they describe, with role-based editing, review and sign-off, and export to PDF and structured formats. Must-have
F12 Automatic population of documentation fields (metadata, metrics and lineage) from connected ML platforms and model registries. Nice-to-have
F13 Storage of testing evidence against each system version, including bias and fairness, robustness and accuracy results and, for generative AI, evaluation and red-team results, with thresholds that can block an approval. Must-have
F14 Built-in bias, robustness or generative AI evaluation tests that run before release and on a schedule, in addition to importing results from our own tools. Nice-to-have
F15 Configurable approval gates at lifecycle stages (intake, before deployment, before material changes and at retirement), with sequential or parallel reviewers by role. Must-have
F16 Ingestion of monitoring signals for deployed systems (drift, performance, fairness and generative AI quality metrics) from our ML platforms and monitoring tools, with thresholds that open findings and notify the system owner. Must-have
F17 AI-specific third-party risk questionnaires and evidence requests, with tracking of supplier responses, provider documentation, attestations and reassessment dates. Must-have
F18 An AI incident workflow: intake from users, monitoring alerts and ticketing; severity levels we configure; links to affected systems and controls; corrective actions; and deadline tracking for any regulatory reporting our counsel identifies [confirm with counsel]. Must-have
F19 Dashboards and on-demand reports by framework, AI system, business unit and period, including gap analysis per framework, overdue assessments, open findings and audit packs for auditors and customers. Must-have
F20 Discovery of unregistered AI use from sources such as single sign-on logs, SaaS and cloud accounts and code repositories, with a workflow to register, approve or block what is found. Nice-to-have
F21 Records specific to AI agents: the tools and data each agent can use, the identity and permissions it acts under, and the human oversight that applies, with review triggered when any of these change. Nice-to-have

Technical and architecture

ID Requirement Priority
T1 Multi-tenant SaaS with a choice of hosting region, or single-tenant or customer-cloud deployment. State which options you offer and any feature differences between them. Must-have
T2 A configurable data model for AI systems, models, datasets, agents, vendors, controls and evidence, with custom fields and record types we can add without vendor coding. Must-have
T3 Support for multiple legal entities, business units and regions, with separation of data and workflows between them where we require it. Must-have
T4 Bulk import from spreadsheets and existing GRC records, registration of systems and evidence through the API, and full export of the inventory, assessments and evidence in documented formats. Must-have
T5 Support for [number] AI systems, [number] users and [number] vendors without loss of performance. State the largest volumes you have tested. Must-have
T6 Export of inventory records as an AI bill of materials in a standard format, such as CycloneDX (ML-BOM) or the SPDX 3.0 AI profile. Nice-to-have
T7 Built-in AI assistance, for example drafting assessment answers or documentation, or suggesting control mappings, with every AI-generated entry labeled and requiring human review. State which models are used and where they run. Nice-to-have

Integration

ID Requirement Priority
I1 Single sign-on with our identity provider via SAML 2.0 or OIDC, with user and group provisioning via SCIM. Must-have
I2 Connectors to our ML platforms, model registries and cloud AI services [list yours] that register models, pull metadata and metrics, and keep the inventory current. State which connectors are native and which need custom work. Must-have
I3 Two-way integration with our GRC platform, so controls, risks, issues and evidence are not maintained twice. State which objects sync, in which direction, and which system owns each record. Must-have
I4 Integration with our ticketing and IT service management platform to create remediation tasks, findings and incident tickets, with status synced back to the governance record. Must-have
I5 Integration with our third-party risk management and procurement tools, so an AI vendor assessment starts from the existing vendor record or purchase request. Must-have
I6 Integration with our data catalog to bring in dataset lineage, provenance and licensing metadata. Nice-to-have
I7 A documented REST API and webhooks covering all core objects, plus export of audit and activity logs to our SIEM and data warehouse. Must-have

Security and compliance

ID Requirement Priority
S1 A current SOC 2 Type II report and ISO/IEC 27001 certification covering the proposed services, available under NDA. Must-have
S2 ISO/IEC 42001 certification of the vendor's own AI management system. State whether you hold it and what it covers. Nice-to-have
S3 Encryption in transit and at rest. State whether customer-managed encryption keys are supported. Must-have
S4 Role-based permissions down to the system, assessment and evidence level, so sensitive records such as legal advice or incident details are limited to named roles, with administrator access through SSO and MFA. Must-have
S5 A tamper-evident, time-stamped audit trail of every decision, approval, change and evidence upload, kept for [retention period] and exportable. Must-have
S6 Read-only access for internal and external auditors, scoped to selected systems, frameworks and periods, without exposing unrelated records. Must-have
S7 A data processing agreement, a current list of sub-processors, a choice of region for storing our data, and a contractual commitment to notify us of security incidents within a defined time. State the time. Must-have
S8 A contractual commitment that our data, including inventory records, assessments, documents and prompts, is not used to train the vendor's or any third party's models. Must-have

Implementation and support

ID Requirement Priority
M1 A phased implementation plan covering configuration of our risk tiers and frameworks, workflow design, integrations and migration of our existing inventory, assessments and evidence, with named roles and the effort expected from both sides. Must-have
M2 Identification of who delivers the implementation (vendor, partner or both) and the named team's experience with organizations of similar size and regulatory scope. Must-have
M3 Vendor-maintained framework content, with advance notice of changes and a review step before updates apply to our controls. State who writes and reviews the content and whether updates are included in the subscription. Must-have
M4 A service-level agreement for platform availability, with service credits. State how availability is measured. Must-have
M5 Support with response-time targets by severity. State your support hours and targets. Must-have
M6 Training for governance reviewers, system owners and administrators, plus sample policies and assessment templates we can adapt. Nice-to-have

Commercial and pricing

ID Requirement Priority
C1 Pricing broken down by module, metric (AI systems, users, entities, vendors assessed or assessments) and term, showing list price, discount and net price. Must-have
C2 A statement of what is included and what costs extra, including framework content, connectors, AI-assisted features and non-production environments. Must-have
C3 Prices for adding modules, AI systems or users mid-term, co-terminated with the main agreement, and the terms that apply if we exceed licensed volumes. Must-have
C4 A cap on price increases at renewal. State the cap. Must-have
C5 A proof of concept at no charge, with the vendor's implementation support. Nice-to-have
C6 Exit terms covering export of the full inventory, assessments, documentation, evidence files and audit trail in usable formats, plus transition assistance at the end of the contract. Must-have

Questions to ask AI Governance vendors

These questions are designed to separate vendors, not to collect brochure answers. Ask for evidence: a demo, a document or a reference.

  1. A SaaS vendor switches on a new AI feature in a product we already license. How would we find out, and how does it reach the inventory and the third-party risk workflow?
  2. Which frameworks ship as maintained content today, and which are on the roadmap? For each, who writes the mappings, who reviews them, and how are changes communicated before they affect our controls?
  3. Show one control mapped to the EU AI Act, ISO/IEC 42001 and the NIST AI RMF, and the evidence that satisfies it under each. Provide your mapping methodology and a sample crosswalk.
  4. In a live demo, take a proposed higher-risk use case from intake to approval: classification, impact assessment, testing evidence, sign-off and the resulting audit record.
  5. Which ML platforms, model registries and cloud AI services have native connectors today? For each, what does the connector pull automatically, and what still has to be entered by hand?
  6. Do you run bias, robustness or generative AI evaluations yourselves, or import results from other tools? Show how a failed test blocks an approval and opens a finding.
  7. When a new model version appears in our model registry, what happens in your platform? Which documentation updates automatically, and which assessments are reopened?
  8. How do you discover AI use that hasn't been registered, which data sources does discovery rely on, and what privacy safeguards apply to that data?
  9. How do you govern AI agents? What do you record about the tools, data and permissions an agent has, and how does a change to any of them trigger review?
  10. What does your AI vendor questionnaire ask, and how do supplier answers and documents feed into risk scores? Can we reuse answers across assessments of the same vendor?
  11. How do you sync controls, risks and issues with our GRC platform without creating two sources of truth? Which system owns which record?
  12. If your platform uses AI to draft assessments, suggest mappings or summarize evidence, which models are used, where do they run, and how are AI-generated entries marked for human review?
  13. Which features in your proposal are generally available today, and which are in preview or on the roadmap? Give dates for the roadmap items.
  14. If we leave, what does a full export contain (inventory, assessments, documents, evidence files and audit trail), and in what formats?
  15. Provide a reference customer of similar size and regulatory scope that runs AI approvals and audits from your platform today.

Scoring rubric

Score each criterion from 1 to 5, multiply by its weight, and add the results. The weights below are a starting point; agree on your own before any proposals arrive so the scoring can't be bent around a favorite.

Criterion Weight What a strong response shows
Inventory, intake and risk assessment workflows 20% Every Must-have met in a generally available release, demonstrated live with your own use cases, including AI inside vendor products.
Framework mapping and content quality 15% Maintained, reviewed content for the frameworks you follow, a clear crosswalk methodology, and the ability to add your own frameworks.
Documentation, testing evidence and audit trail 10% Versioned documentation, evidence tied to system versions, and an auditor's question answered quickly from the record.
Integration with ML platforms, GRC and ticketing 15% Native connectors that pull metadata and metrics automatically, a clear split of records with your GRC platform, and two-way ticket sync.
Third-party AI risk and monitoring 10% AI-specific vendor assessments tied to your third-party risk process, and monitoring signals that open findings automatically.
Security, privacy and data handling 10% Current certifications, permissions that protect sensitive records, region choice, and a commitment not to train models on your data.
Implementation and support 10% A credible phased plan, an experienced named team, a clear content update process, and stated SLAs and support targets.
Commercials and total cost 10% A clear pricing metric, content and connector costs stated up front, a renewal cap, and full export at exit over a three-year view.
Total 100%

Scoring scale

  • 5 Exceeds: meets every Must-have and most Nice-to-haves, shown in a demo or proof of concept, with a matching reference customer.
  • 4 Strong: meets every Must-have and some Nice-to-haves, with clear evidence.
  • 3 Adequate: meets most Must-haves; gaps have a credible workaround or a dated roadmap commitment.
  • 2 Weak: misses one or more Must-haves, or the answer is vague.
  • 1 Poor: does not meet the requirement, or no answer.

Frequently asked questions

What should an AI governance RFP include?

The AI you need to govern, including AI inside vendor products, and the frameworks your program follows; requirements for inventory, intake, risk classification, impact assessments, policy management, framework mapping, model documentation, testing evidence, approvals, audit trail, third-party AI risk and monitoring, each marked Must-have or Nice-to-have; integration requirements for your ML platforms, GRC and ticketing tools; security, support and pricing terms; and the rubric you'll score with. This template includes all of them.

What does an AI governance platform do?

It's the system of record for your AI program. It keeps an inventory of the AI you build, buy and use inside vendor products, runs intake, risk classification, assessment and approval workflows, maps your controls to the frameworks you follow, and stores the documentation, testing evidence and audit trail behind each decision. It works alongside your ML platforms, GRC and ticketing tools rather than replacing them.

Can a GRC platform handle AI governance?

Some GRC and ML platforms offer AI governance modules, so include them in your RFI if you already own one. Compare them on the AI-specific work: intake, classification, model documentation, testing evidence and connectors to your ML platforms. If a module meets your Must-haves, it may be enough; if not, choose a dedicated platform that integrates with your GRC tool so risks and controls aren't maintained twice.

Does an AI governance platform make you compliant with the EU AI Act?

No. A platform organizes the inventory, assessments, documentation, approvals and evidence your program needs and maps them to the frameworks you choose, but deciding which obligations apply to you and whether you meet them is a legal judgment. Have counsel confirm your obligations, check that the vendor's framework content is maintained and reviewed, and treat its mappings as a starting point rather than legal advice.

How long does an AI governance RFP take?

The example schedule in this template runs about 13 weeks from kickoff to contract award, including three weeks for vendor responses and about four weeks for a proof of concept. Allow more time if your risk tiers and approval process aren't written down yet, or if several legal entities and regions need to agree on one process.

Further reading

Related RFP templates

Download Ms Word Template