RFP checklist
AI and Workflow Governance RFP Checklist
Any vendor you shortlist must prove four things: it enforces your rules while the work runs, it keeps an immutable audit trail of every run, it carries the work from the front office to the back office without a gap, and it is live in weeks.
Published by Callvu. Vendor-neutral: use it to evaluate any vendor.
Start here
The four non-negotiables.Any vendor must prove all four.
Runtime enforcement
Policies are enforced at every step while the work runs, whether a person or an AI started it. Checking compliance afterward in a GRC review, then redoing the work by hand, does not count.
Immutable audit trail
Every run produces a step-level record of what happened, who decided, and why each AI action was allowed. The record cannot be edited and is produced by the system, not assembled by people.
Front-to-back handoff
The platform runs the work between the front door (form, call, chat, AI agent) and the system of record: prefill, classify, chase documents, route decisions, write back. Capturing the request is not enough.
Live in weeks
A first regulated process in production in weeks, not a multi-quarter IT project, with the vendor building and maintaining it.
How to score
Must is pass or fail.Should is 0 to 3.
Must
Pass or fail. A vendor that fails any Must is out.
Should
Scored 0 to 3: 0 not offered, 1 roadmap or custom build, 2 available but not in production at a comparable company, 3 in production with a named or referenceable customer.
Pick your industry
The core list, plusyour regulations.
Each industry page adds its own requirements and regulations to the 41 core requirements.
Banking RFP checklist
CFPB · OCC · FDIC · Federal Reserve
10 added requirements
Mortgage RFP checklist
CFPB · TRID · RESPA and Reg X · Reg Z
9 added requirements
Insurance RFP checklist
state insurance departments and market conduct rules · NAIC Model #668 · NAIC unfair claims settlement practices models and the state rules built on them · NAIC privacy models
10 added requirements
Healthcare RFP checklist
HIPAA Privacy and Security Rules · HITECH · 42 CFR Part 2 · the No Surprises Act (good faith estimates)
10 added requirements
Telecom RFP checklist
FCC SIM swap and port-out rules · CPNI · the Safe Connections Act · TCPA
9 added requirements
Utilities RFP checklist
state PUC and PSC customer protection rules · disconnection rules · deposit and billing rules · seasonal disconnection protections
9 added requirements
Travel and eCommerce RFP checklist
PCI DSS · US DOT refund rules · EU261 · consumer protection and chargeback rules
9 added requirements
Core requirements
41 requirements,in seven groups.
Columns: the requirement ID, the requirement, its priority (Must or Should) and the evidence to require from the vendor. Ask to see it, not to hear it.
Group 1A
Runtime enforcement
| ID | Requirement | Priority | Evidence to require |
|---|---|---|---|
| C1 | Policies (regulations and company SOPs) are enforced at every step while the work runs, not checked after the fact | Must | Live demo: a run that violates a policy is blocked or escalated before anything is written |
| C2 | A required step that fails fails the run. No step can be skipped, reordered or substituted by a person or by AI | Must | Demo: remove a consent or ID check mid-run and show the run stops |
| C3 | The same enforcement applies whether a person, a form, a call, an API or an AI agent started the process | Must | Demo the same process started from two doors, one of them an AI agent, with identical controls and records |
| C4 | Each action is evaluated before it executes, with a deterministic decision: execute, execute with safeguards, escalate to a person, or block | Must | Architecture document showing where the decision is made and that it is deterministic, not a model's output |
| C5 | The applicable regulations for your industry come preloaded as policies; your own SOPs are added as company-level policies and enforced the same way | Must | List of preloaded policies for your vertical; demo adding a company SOP without code |
| C6 | When a regulation changes, the vendor updates the policy, not your developers | Should | Contract language and the last three regulatory updates shipped, with dates |
| C7 | When a person must decide, the case goes to a named reviewer (inside or outside the company) with only the allowed choices, and nothing is written until they decide. Decisions by email reply do not count | Must | Demo an approval by an outside reviewer with no account |
Swipe sideways for the priority and the evidence.
Group 1B
Immutable audit trail
| ID | Requirement | Priority | Evidence to require |
|---|---|---|---|
| C8 | Every run produces a step-level record: what the customer saw and agreed to, data captured, each check, each decision and who made it, each write to the system of record | Must | A real sample record from production, redacted |
| C9 | For every AI action, a record of why it was allowed (which policies were evaluated, with what result) | Must | Sample record of an AI-started run |
| C10 | Records are immutable: no one, vendor included, can edit them after the fact | Must | Technical description of how immutability is enforced, and SOC 2 control mapping |
| C11 | Any single transaction can be reconstructed for an examiner in minutes, with no one assembling it from emails, logs or screenshots | Must | Timed demo: pick a random run from the demo and produce its full record |
| C12 | Records stream in real time to your GRC and BI tools | Should | Named GRC and BI integrations in production |
| C13 | Retention of at least 12 months by default, extendable by contract | Should | Retention policy in the security document |
Swipe sideways for the priority and the evidence.
Group 1C
Front-to-back handoff
| ID | Requirement | Priority | Evidence to require |
|---|---|---|---|
| C14 | Runs the process end to end, from the front door to the system of record, not just intake or just the back office | Must | Demo one process from first contact to the write-back in the system of record |
| C15 | Prefill: reads what your systems of record already know, so the customer and staff only enter what is missing | Must | Demo with prefill from your CRM or core (or a stand-in) |
| C16 | Classify: each request becomes a unit of work the moment it lands, with work type, skill needed, effort and due date | Must | Demo of a request landing with owner, skill and due date set |
| C17 | Chase and verify: missing documents are requested from the right party (customer, broker, provider, agency, other company) on a clock, read on arrival and checked against what the case needs | Must | Demo a document arriving wrong (wrong form, unsigned, out of date) and being rejected automatically |
| C18 | Write back: results go to the system of record by API; a failed write is retried, then flagged to a person. No case is silently dropped | Must | Demo with the system of record offline |
| C19 | Regulatory clocks run inside the process and act when they run out (escalate, reassign, notify) | Must | Demo a timer tied to a regulatory deadline |
| C20 | A case still waiting as its deadline nears is reassigned automatically to someone who can act | Should | Demo |
| C21 | Back-office visibility from the moment the front end starts: what came in, what is due and for whom, what is stuck and on whom, who did the work, the skills to staff | Must | Live operations report; integration with your WFM tool, or one built for you |
| C22 | Runs on top of your existing core, CRM, contact center and AI tools. No replatforming | Must | Production references running alongside the same class of systems you own |
Swipe sideways for the priority and the evidence.
Group 1D
AI governance
| ID | Requirement | Priority | Evidence to require |
|---|---|---|---|
| C23 | AI (yours or the vendor's) can start a governed process but cannot write to the system of record directly; the process runs deterministically underneath | Must | Architecture diagram; demo an AI agent starting a process |
| C24 | Works with the AI agent you already use (for example over MCP or API), not only the vendor's own | Must | Demo with a third-party agent |
| C25 | Sensitive data (card numbers, health details, bank details) never goes into an AI chat; must-not-skip steps such as consent and signature move to a secure, process-controlled screen, prefilled | Must | Demo the handover from chat to the secure screen |
| C26 | If the AI fails or times out, the process keeps running under a configured fail-safe | Must | Demo |
| C27 | Sensitive data (for example PHI) is masked by policy before it reaches anyone or anything that should not see it | Must for health data, Should otherwise | Demo of masking in a live run |
| C28 | All AI features can be switched off for a tenant in one setting | Should | Admin demo |
Swipe sideways for the priority and the evidence.
Group 1E
Time to value and delivery
| ID | Requirement | Priority | Evidence to require |
|---|---|---|---|
| C29 | First regulated process live in production in weeks, not quarters | Must | Two production references with go-live dates, measured from kickoff |
| C30 | The vendor designs, builds, maintains and optimizes your processes for the life of the contract, and trains your team | Should | Statement of work and what the license includes |
| C31 | Policy changes ship in hours or days, and new processes in weeks, without a development project | Must | Change log from a production customer |
| C32 | A proof of value on one of your real processes, with pass/fail gates for completion and compliance, before any long-term commitment | Must | Written proof of value terms: scope, gates, duration, what happens if it fails |
Swipe sideways for the priority and the evidence.
Group 1F
Security, hosting and vendor risk
| ID | Requirement | Priority | Evidence to require |
|---|---|---|---|
| C33 | Current SOC 2 Type II report with an unqualified opinion | Must | The report |
| C34 | PCI DSS attestation where payments are taken | Must where payments apply | Attestation of compliance |
| C35 | Annual independent penetration test | Must | Summary letter |
| C36 | Each customer's data in its own isolated database; exported or securely deleted at contract end | Should | Architecture and security document; contract clause |
| C37 | Uptime commitment in the contract (99.9% or higher) | Should | Contract SLA |
| C38 | Named enterprise customers in production in regulated industries, with references matched to your process | Must | Customer list; reference calls |
Swipe sideways for the priority and the evidence.
Group 1G
Commercial
| ID | Requirement | Priority | Evidence to require |
|---|---|---|---|
| C39 | Pricing tied to outcomes (governed, completed runs), with every billable unit backed by a record you can inspect | Should | Pricing model and a sample usage report |
| C40 | No replatforming or rip-and-replace cost; implementation, hosting, updates and support included in the license | Should | Line-item total cost of ownership over three years |
| C41 | A cost-of-inaction model built from your own volumes, with the formula shown | Should | The model |
Swipe sideways for the priority and the evidence.
Red flags
What to hear,and what it means.
| Red flag | Why it matters |
|---|---|
| "Guardrails" on an AI that runs the process | Guardrails reduce errors some of the time. They do not stop AI from inventing a step, skipping one, or polluting the system of record. The process itself must run deterministically. |
| Compliance is reported after the fact (dashboards, scoring, QA sampling) | Finding a violation weeks later means redoing the work by hand. Ask what stops the violation before it happens. |
| The audit trail is application logs | A log is not an audit record. Ask for a per-run record an examiner would accept, and how it is protected from edits. |
| The AI can write directly to the system of record | Generative AI is non-deterministic. Nothing it writes should reach the core, CIS, BSS, EHR or LOS without enforced controls. |
| It captures the request but stops at the front door | Containment and deflection metrics hide the work that still happens after: re-keying, chasing, emailed approvals. Ask to see the write-back. |
| Approvals happen by replying to an email | No enforced choices, no record, no clock. |
| Each new process is a services project measured in months | Regulated processes change constantly. If a policy change needs developers, it will lag the regulation. |
| Enforcement is "on the roadmap" | Require a contractual delivery date and a production reference, or score it zero. |
| No proof of value with pass/fail gates | A vendor confident in its outcome will stake the first contract on it. |
The live proof test
Eight steps,before you sign.
Questions
What buyers ask,answered plainly.
What should an RFP for AI and workflow governance require?
Runtime enforcement: Policies are enforced at every step while the work runs, whether a person or an AI started it. Immutable audit trail: Every run produces a step-level record of what happened, who decided, and why each AI action was allowed. Front-to-back handoff: The platform runs the work between the front door (form, call, chat, AI agent) and the system of record: prefill, classify, chase documents, route decisions, write back. Live in weeks: A first regulated process in production in weeks, not a multi-quarter IT project, with the vendor building and maintaining it.
How do you score vendors on AI governance?
Pass or fail. A vendor that fails any Must is out. Scored 0 to 3: 0 not offered, 1 roadmap or custom build, 2 available but not in production at a comparable company, 3 in production with a named or referenceable customer.
What are red flags in an AI governance vendor?
"Guardrails" on an AI that runs the process. Compliance is reported after the fact (dashboards, scoring, QA sampling). The audit trail is application logs. The AI can write directly to the system of record.
How do you test an AI governance vendor before buying?
Run the live proof test before you buy: Start the process from two doors: one human channel and one AI agent; prefill from your system of record (or a stand-in) so only missing data is asked; break a rule mid-run (missing consent, failed identity check, a medical hold, an ineligible refund). The run must block or escalate before anything is written; send a decision to an outside reviewer with no account; the decision must happen inside the platform, not by email. Then let a regulatory clock run out and show what the system does; take the system of record offline at write-back and show the retry and the flag; pick any completed run at random and produce its full, uneditable record in under five minutes; show how long it took to put this scenario live, and who built it.
Take the checklist into your RFP.
The spreadsheet carries every requirement, the scoring and the proof test, ready to send to any vendor.