AI RFP Template: Score Evidence, Demo Tests, Contract Terms, and Rejection Rules

A polished AI demo can answer a prepared prompt and still leave procurement with no evidence about identity and data handling or failure behavior and audit access. An AI RFP template should force those claims into artifacts and tests before price negotiation begins. My rule is blunt: an answer that cannot be demonstrated or contracted earns no points.

TL;DR

• Score vendor responses against named evidence and controlled demo tests. Bind accepted claims into contract language. Marketing assertions receive zero evidence credit.
• Organize governance and use-case mapping together. Then cover measurement and ongoing risk management before adding generative AI risks specific to the proposed system.
• Define rejection conditions before bids arrive, including missing data-use terms and weak identity. Unavailable logs or unsafe failure behavior should also block a bid, along with blocked exit rights.
• Preserve the scoring record and test results. Keep exceptions and approvers with the final contract as one procurement evidence file.

Define the use case before issuing the RFP

Write the business process with affected users and the data classes with related decisions on the first page. Add the model actions with their integrations and the deployment boundary. Name the environments and jurisdictions in scope. Identify any automated action that can change a customer record or invoke an external tool.

The NIST AI Risk Management Framework is intended for voluntary use across the design and development of AI systems. It also covers their use and evaluation. Its Core uses GOVERN and MAP. It also uses MEASURE and MANAGE. NIST states that these functions organize outcomes and actions, rather than forming a simple ordered checklist.

That structure fits procurement when the buyer converts it into evidence requests:

• Govern: ownership and policy; roles and training; third-party oversight; accountability.
• Map: intended context and affected parties; data and dependencies. Include foreseeable misuse in the map.
• Measure: testing methods and limitations; monitoring; incident criteria; independent review.
• Manage: priorities; treatment decisions; production controls and escalation; retirement.

Avoid asking a vendor to self-certify that it is "NIST compliant." The framework is voluntary, and a broad alignment statement reveals little about the proposed deployment.

Use a scored requirement format

Each requirement should contain an identifier with its question and a rationale with the required evidence. It should also contain a test method with a risk-based score and weight, followed by a contract destination and rejection flag. This structure prevents evaluators from awarding points for a confident narrative that lacks support.

A practical score can use four evidence states:

• No credit: the vendor omits the answer or supplies an assertion without evidence.
• Partial credit: the artifact covers only part of the proposed service and plan. It may instead cover only part of the proposed region or workflow.
• Substantial credit: current evidence covers the proposed scope, with a minor gap that has a named owner and date.
• Full credit: the submitted artifact with its scope and the demo result satisfy the requirement, and the proposed contract language does too.

Weights should follow the risk assessment, not the sales team's preferred differentiators. Identity enforcement and restricted-data handling can carry more weight than interface preferences in a regulated workflow.

The AI risk assessment template should feed these weights. Record the rationale before opening responses so evaluators cannot reshape the rubric around a favored bidder.

Ask for evidence by control family

Group each request by the control it tests and the evidence needed to score the response.

Identity and authorization

Ask the vendor to demonstrate human and workload identity. Cover SSO integration and administrator MFA in the same evidence pack. Review service-account governance and delegated agent authority. Test tenant isolation and session revocation. Require evidence for privileged access review and a list of roles with permitted actions.

For an LLM API route, request the policy decision record for an allowed call and a denied call. The record should show the authenticated principal with its role and the route with its model. It should also show the policy version. Record the outcome and reason code with it. Shared keys without downstream identity should be disclosed clearly.

Data handling and model use

Require a data-flow diagram for the proposed configuration. Ask which customer data reaches each subprocessor, including content supplied through prompts and attachments. Include retrieval content in that diagram. Record training use, retention, deletion, residency, encryption, and customer-controlled key conditions separately.

Evidence must match the plan and mode being purchased. Make the vendor mark each answer with the applicable product and tier. Record the region and configuration too.

Testing, monitoring, and incidents

NIST published the Generative Artificial Intelligence Profile on July 26, 2024 as a cross-sector companion to AI RMF 1.0. It discusses generative AI risks including value-chain and component integration, where opaque third-party components can weaken transparency and accountability.

Ask for the test methodology and representative datasets. Require known limitations and red-team scope. Request incident definitions and customer notification terms. Require root-cause reporting and remediation tracking. Evidence should identify the model and system version tested.

Audit and lifecycle evidence

Require the audit event schema and retention settings. Request the export method and administrative-change logs. Require recorded model and policy versions, along with integrity controls. Ask who can alter records, then run a timed retrieval during the demo.

The AI vendor due diligence questionnaire supplies detailed questions. The RFP adds points and tests. It also adds contract terms and rejection rules.

Run controlled demo tests

Send every finalist the same test pack against the configuration being purchased.

Test an approved user and a wrong role. Submit restricted prompt data and a disallowed tool action. Test a revoked session and missing identity. Test an unavailable policy dependency as well. Export the decision records and submit a deletion request. Add failure conditions from the use-case risk assessment.

For each test, record the setup and expected result. Record the actual result and event ID. Add the product version, evaluator, and date. A green check on a slide has no evidentiary value. A failed test can remain open only with written remediation and a deadline. It also needs a retest owner and a contractual consequence.

Use production-like identity and policy shape without loading real customer content. Synthetic fixtures should contain recognizable markers so the team can confirm that blocked data never reached the provider and that approved records contain the right classification.

Move accepted claims into the contract

A scored response describes the offer. Translate material commitments into the signed contract documents that govern the purchased service.

Contract terms should identify the exact service and plan. They should name the subprocessors and set training restrictions. Add other data-use restrictions and retention terms. Define the deletion and residency requirements together. State the security controls and audit access. Set the incident notice and rules for material model changes. Apply those rules to provider changes too. Define service levels and remediation duties explicitly. Cover termination assistance and evidence export. Require verified deletion after contract exit.

Attach the final RFP response or incorporate named representations when counsel approves. Define precedence across the contract documents.

The procurement lead AI risk checklist should remain active after signature, with named owners for recurring evidence and material service changes.

Set rejection conditions before scoring

Define rejection conditions before bids arrive and obtain risk-owner approval.

Rejection conditions can include undisclosed material data flows and prohibited training use. Missing tenant isolation or no revocation path can also block a proposal. Block proposals that lack evidence for privileged actions or audit export. Required residency and model-change control should remain hard gates when the use case depends on them. The same applies to incident notice and exit rights.

A failed denial test should block a route that depends on that control. The buyer can narrow scope or add an external control. The buyer can also reject the bidder. Record every exception with compensating controls and an expiry. Name the accountable executive and residual risk. Permanent exceptions with no expiry become hidden requirements debt.

I would rather reopen an RFP than explain to an auditor that a mandatory control lost to a prettier demo.

Preserve the procurement evidence file

Keep the issued RFP and bidder questions with final responses and source artifacts. Preserve the score record and demo evidence. Keep documented exceptions and their approvals. Preserve negotiation changes and the signed contract. Hash or version key artifacts so a later review can establish which evidence supported the decision.

The file should show scoring changes and their approvers. At renewal, rerun the high-risk tests and update evidence that changed with the product.

Map each required test and evidence field to the relevant NIST Generative AI Profile risk. The procurement file should show the result and the contract clause that carries the requirement into this deployment.

DeepInspect

DeepInspect can provide an external policy and decision-evidence layer for LLM calls that the buyer deliberately routes through an authenticated HTTP boundary. Procurement teams can test role denials and data policies. They can also test route restrictions and fail-closed behavior. They can test decision exports against the proposed configuration too.

That evidence covers the controlled user or agent-to-LLM request path. The RFP should keep separate requirements for vendor-hosted workflows and local execution. It should cover endpoint controls and model development, along with every data flow outside that route.

Book a technical deep dive at deepinspect.ai.