01
Workflow and professional boundary
- Users, inputs and output
- Decision and human owner
- Prohibited uses
- Failure behaviour and consequences
Checklist
Regulated AI procurement checklist
What to ask an AI vendor before you approve them: where the data goes, who operates it, what the certificate covers and how you would leave.
Updated 21 Aug 2026
Definition
Procurement should ask an AI vendor for the workflow and professional boundary, evidence that each part of the product is implemented, a data-flow map, identity and permission tests, named operating owners, current certification scope, and the commercial and exit terms. A useful checklist turns each unknown into a named evidence request or a blocking decision.
02
Product evidence
Ask for proof that a surface is implemented and for representative evaluation results covering retrieval, citations, uncertainty, permissions and your specific workflow. A feature list answers none of that.
- Implemented-surface proof
- Representative evaluation results
- Retrieval, citations and uncertainty
- Not a generic feature list
03
Architecture and data
Map every place data rests or passes through for the deployment you are proposing, and who holds it there.
- Stores, processors and models
- Logs, backups and support routes
- Location and retention
- Deletion and subprocessors
04
Identity and governance
- Organisation separation and roles
- Source permissions and revoked access
- Administrator powers
- Trace coverage and evidence export
05
Operations
Assign monitoring, incident, recovery, change, update, vulnerability, support and business-continuity responsibilities.
- Monitoring and incident response
- Recovery and change control
- Updates and vulnerability response
- Support and business continuity
06
Corporate and certification evidence
Review product controls separately.
- Legal operator and certificate holder
- Scope and issuer
- Accreditation and dates
- Product controls reviewed separately
07
Commercial and exit
- Scope and dependencies
- Service, support and price terms
- Renewal and termination
- Data export and portability
08
Decision record
Mark each requirement evidenced, open, accepted with a named risk owner, or blocking. Keep hard constraints outside any weighted preference total.
- Evidenced or open
- Accepted with a risk owner
- Or blocking
- Hard constraints kept separate
Procurement checklist
What to see before you approve
Mark each row evidenced, open, accepted with an owner, or blocking. A blank is not a low-risk answer.
| Review area | Evidence needed |
|---|---|
| Workflow | Named users, decision, documents, failure cost and human owner |
| Evidence quality | Known, synthesis, conflict, stale, no-answer and permission tests |
| Data flow | Stores, processors, locations, retention, deletion, support and backups |
| Identity | Organisation, role, source permission, revoked access and administrator tests |
| Operations | Monitoring, incident route, recovery, change, update and vulnerability ownership |
| Commercial | Scope, dependencies, service terms, exit, export and evidence commitments |
What this page does not prove
- B1The checklist is not legal advice or certification.
- B2Completion does not prove a deployment safe or compliant.
- B3Evidence must match the exact product release and architecture.
- B4Material changes trigger re-review.
Related pages
Ask for the current Marella procurement route
The public checklist remains available without a form. Use this only to request current Marella-specific evidence categories or an approved route for a confidential questionnaire; do not paste one here.