A reference for the teams who vet AI vendors. It sorts the AI supplier
landscape into seven categories, maps each to the SRF layers and
accountability boundaries it touches, and lists the attestations and
evidence to demand before you sign.
Practitioner aid. This page operationalizes the CoSAI
Shared Responsibility Framework for vendor risk work. It is a proposed
extension developed to demonstrate the approach, not part of CoSAI SRF
v1.0 and not an endorsement of any named vendor. Validate every control
and contract term with your security, legal, and compliance functions
before use.
Vendor risk teams protect the company from supply-chain exposure. With
AI suppliers that job gets harder, because risk no longer sits in one
place: it spreads across the data a vendor touches, the model behind a
feature, the autonomy you grant an agent, and the sub-processors none
of those vendors named. A SOC 2 report alone will not tell you who is
accountable when an agent takes the wrong action or a model leaks a
prompt.
The fix is to know, per vendor type, which SRF responsibilities the
vendor owns and which stay with you, then ask for evidence that proves
the vendor holds up its side. Each category below gives you that split
plus a concrete evidence list. Start with the risk tier to decide how
deep to go.
Depth of assessment should track the risk a vendor introduces, not the
size of the contract. Score each vendor on three axes: the sensitivity
of data it touches, the autonomy it exercises, and how deep into the
SRF stack it reaches. The highest of the three sets the tier.
Tier
Triggers (any one)
Assessment depth
Tier 1 · Critical
Regulated or highly sensitive data; autonomous actions on your systems; deep platform or model access (L4 or L5).
Full assessment, all evidence asks, contractual SRF responsibility matrix, continuous evidence rather than point-in-time, named incident path.
Tier 2 · Elevated
Internal business data; human-in-the-loop; application-layer AI features (L3).
Core attestations plus the AI-specific asks for the category, data-use and sub-processor disclosure, admin controls review.
Tier 3 · Standard
Low-sensitivity data; bounded scope; no autonomy; no training on your data.
Baseline attestation (SOC 2 or ISO 27001), acceptable use terms, data-retention and deletion commitment.
Step 2
Assess by vendor category
Seven categories cover the AI supplier market. Filter by the SRF layer
you care about to narrow the list. Asks flagged
AI-specific
go beyond a standard security questionnaire and are the ones most VRA
checklists miss.
SRF layer
Category 1
Core AI platform & infrastructure
Cloud AI services, MLOps pipelines, model hosting, GPU infrastructure. For example AWS AI, Azure AI, Google Cloud AI.
L4 AI PlatformL5 (partial)IaaS · AI-PaaSAI Platform Provider
Vendor is accountable for
Tenant isolation, platform and infrastructure security, encryption services, availability, and the platform telemetry it exposes.
You stay accountable for
Workload and key configuration, data classification, identity and access, app-layer controls, and deciding which AI events and logs you collect.
Risk area
Attestation baseline
Evidence to ask for
Multi-tenant data isolation
SOC 2 / ISO 27001
Architecture diagrams showing how one customer is prevented from reaching another's data, and where data resides.
Encryption at rest and in transit
SOC 2 / ISO 27001
Key-management description and bring-your-own-key options.
Security certifications
SOC 2 / ISO 27001 / FedRAMP
Current attestation reports under NDA, with scope and exceptions.
Incident response and monitoring
SOC 2 +
Which AI events the platform generates, how models are monitored, and which logs you are expected to collect.
Shared responsibility boundary
Documented matrix
A responsibility matrix that states who owns what, plus the adversarial or bias testing the platform expects you to run.
Category 2
Pre-trained model & algorithm providers
Foundation and domain-specific models reached by API: LLMs, vision, and speech models. For example OpenAI, Anthropic, Mistral, Meta, Google.
L5 AI Model ProviderAI-PaaSModel Provider
Vendor is accountable for
Training and model integrity, safety tuning, model and system cards, API security, and not training on your prompts where contracted.
You stay accountable for
Use-case risk classification, prompt and output handling, application guardrails, and human oversight of model output.
Risk area
Attestation baseline
Evidence to ask for
Model integrity and benchmarks
SOC 2 +
Third-party benchmark certification and robustness metrics against adversarial attacks and jailbreaks.
Training-data provenance and bias
ISO 42001
Proof of data opt-out (GDPR, CCPA) and a list of third-party datasets used.
Responsible AI and explainability
ISO 42001
System and model cards covering intended use, limits, and evaluation.
Licensing and IP indemnification
Contract
License and acceptable-use terms, plus an IP indemnity clause for model output.
Regulatory alignment
EU AI Act
Mapping of the model to EU AI Act risk categories and proof that prompts are not used for training.
Model supply-chain integrity AI-specific
ISO 42001
Model provenance and signing, weight-integrity controls, and a vulnerability disclosure process.
Category 3
AI-enabled SaaS applications Added
SaaS products with embedded AI features: copilots, assistants, and AI inside tools you already buy. For example CRM copilots, support bots, document AI. The category most companies actually procure.
L3 AI ApplicationAI-SaaSApplication Developer
Vendor is accountable for
Application logic, in-app guardrails, output filtering, feature-level access control, and the foundation models it selects underneath.
You stay accountable for
What data you feed the app, user permissions, acceptable use, and monitoring AI output for your own context and accuracy.
Risk area
Attestation baseline
Evidence to ask for
Underlying model and sub-processors
Disclosure
Which foundation models and sub-processors power the feature, and the data flow to each.
Prompt injection and output safety AI-specific
ISO 42001
Input and output filtering, indirect prompt-injection defenses, and jailbreak test results.
Data use for training
Contract
Contractual proof that tenant data is not used to train shared models.
Feature governance
SOC 2 +
Admin controls to disable AI features and audit logs of AI actions taken in your tenant.
Tenant isolation
SOC 2 / ISO 27001
Isolation evidence and data-residency options.
Category 4
Agentic AI & autonomous systems Added
Autonomous agents, tool-using copilots, workflow automation, and the tool and connector ecosystems (for example MCP servers) that agents act through.
L3 AI ApplicationL4 AI PlatformAgent-PaaSAgentic Platform Provider
Vendor is accountable for
The agent runtime, tool and permission scoping, guardrail enforcement, action logging, and the autonomy and override controls it exposes.
You stay accountable for
Which tools and scopes you grant, how you configure human override and approval gates, and the blast-radius limits you set.
Risk area
Attestation baseline
Evidence to ask for
Autonomy and human override AI-specific
Disclosure
The autonomy levels (L0 to L5) and override tiers (T1 to T5) the product supports, and its default settings.
Tool and action authorization AI-specific
ISO 42001
The permission model, scope limits, and the ability to require human approval per action class.
Guardrail bypass monitoring
SOC 2 +
Detection of guardrail bypass, runtime integrity verification, and a complete action audit trail.
Blast-radius containment
Contract
Rate limits, spend caps, rollback, and a documented kill-switch.
Indirect prompt injection AI-specific
ISO 42001
Defenses for the case where an agent reads untrusted content or tool output and acts on it.
Category 5
Data, labeling & retrieval services
Managed labeling, RLHF, and crowdsourcing platforms, plus retrieval and vector-data providers that feed RAG systems. For example Scale AI, LXT, Toloka.
L2 AI InformationData Provider
Vendor is accountable for
Workforce vetting, confidential-data controls, annotation quality, retrieval-index security, and secure deletion on request.
You stay accountable for
Classifying data before you share it, defining the retention policy, and accepting the quality thresholds you contract to.
Risk area
Attestation baseline
Evidence to ask for
Workforce vetting and background checks
SOC 2 +
Which roles or regions are exempt from screening, and the re-screening cadence for gig workers and contractors.
Confidential-data controls
SOC 2 +
DLP evidence, GeoIP and embargo restrictions, and penetration-test results for any contractor-provided VDI.
Annotation QA and accuracy
ISO 9001 +
QA methodology documentation and the prior-quarter metrics dashboard.
Sub-processors and cross-border flow
Disclosure
Sub-processor list with change control, a data-flow diagram with geographies, audit results, and opt-out options.
Retention and secure deletion
SOC 2 +
Whether you can define the retention policy, plus certificates of data deletion or destruction.
Retrieval and RAG integrity AI-specific
ISO 27001
Access controls on the vector store, data-poisoning defenses, and tenant isolation of embeddings.
Category 6
AI consulting & professional services
Strategy, custom model development, and system integration. For example Big-4 consultancies and boutique AI shops.
L1 AI Business & UsageCross-layerAI System GovernanceApplication Developer
Vendor is accountable for
Secure development practice, deliverable quality, the firm's own security posture, and clean exit from your environment.
You stay accountable for
Scope definition, environment-access boundaries, IP terms, and acceptance criteria for what the engagement produces.
Risk area
Attestation baseline
Evidence to ask for
Scope, SLAs, and success KPIs
Contract
Examples of AI KPI dashboards and prior-project scorecards.
Access controls in client environments
SOC 2 +
Restricted data and system-access requirements such as VPN, VDI, Jupyter Hub, and IDE.
Ownership of code and models produced
Contract
Contracts addressing IP or joint ownership, plus SBOM and AIBOM breakdowns of what was delivered.
Security posture of the firm
SOC 2 / ISO 27001
Third-party attestation results for the consulting firm itself.
Post-engagement data destruction
SOC 2 +
Destruction certificates, the process for sanitizing IDE and repos (Jira, Confluence, Git), and wiping developer workstations and VDI caches.
Category 7
Software, VARs & distributors
Bundled AI software, marketplace sellers, and OEM integrators that resell or repackage AI built by someone else.
L3 AI ApplicationL4 AI PlatformReseller of OEM
Vendor is accountable for
Passing through the OEM's controls without weakening them, delivering patches, and providing support and escalation.
You stay accountable for
Validating the OEM behind the reseller and holding both to the contract terms and the downstream supply chain.
Risk area
Attestation baseline
Evidence to ask for
Patch and update responsibility
Contract
Model, dataset, and tool patch schedule, plus an end-of-life matrix by product.
Reseller controls aligned to OEM
Disclosure
A controls-hardening benchmark and a contract clause ensuring the vendor cannot weaken security settings over time.
Support and escalation path
Contract
Named contacts and numbers, and the incident-response process.
Downstream supply-chain vetting
Disclosure
Current sub-provider inventory with geographic locations and data roles, audit results, and opt-out options.
Licensing terms and warranty
Legal review
Licensing and warranty coverage, with legal sign-off.
No categories touch that layer. Clear the filter to see all seven.
Step 3
Cross-cutting AI risks to check on every vendor
These risks do not belong to one category. They apply to any vendor
that builds, hosts, resells, or services AI, and they are where a
traditional third-party questionnaire goes quiet.
Prompt injection, direct and indirect
Whether the vendor defends against malicious instructions in user input and in content the system retrieves or a tool returns.
Model and weight supply chain
Provenance, signing, and poisoning or backdoor defenses for models and weights. Ask for an AIBOM alongside the SBOM.
Training-data provenance and IP
What the model was trained on, opt-out handling, and indemnity for IP claims arising from output.
Data residency and sub-processors
Where data and inference run, the full sub-processor chain, and notice and opt-out on changes.
Continuous vs point-in-time evidence
Whether the vendor can show controls operating over time, not just a once-a-year attestation snapshot.
Versioning and decommissioning
How model and feature versions are tracked, notified, deprecated, and rolled back without breaking your controls.
Liability for AI-generated harm
Contractual allocation of liability when model output causes financial, legal, or safety harm.
AI management system maturity
Whether the vendor runs a governed AI program. ISO 42001 certification and a NIST AI RMF profile are the signals.
Reference
What each attestation actually proves
Attestations are not interchangeable. Security certifications say
nothing about AI governance, and an AI-management certification says
nothing about quality control on a labeling floor. Match the
attestation to the risk.
Attestation
What it covers
What it does not cover
SOC 2 Type II
Operating effectiveness of security, availability, and confidentiality controls over a period.
AI-specific risk, model behavior, bias, or autonomy.
ISO/IEC 27001
A certified information security management system.
AI governance and model-lifecycle controls.
ISO/IEC 42001
A certified AI management system: governance, risk, and lifecycle controls for AI. The AI-specific signal.
Point-in-time security control testing of infrastructure.
ISO 9001
Quality management. Relevant to labeling and annotation accuracy.
Security or AI-specific risk.
FedRAMP
US federal authorization for cloud services at a defined impact level.
AI governance beyond the underlying cloud platform.
NIST AI RMF
A voluntary AI risk-management profile. Shows the vendor has a structured AI risk process.
Independent certification; it is self-applied unless audited.
EU AI Act
Risk categorization and the legal obligations that follow for in-scope systems.
A security or quality attestation on its own.
Templates
Contract clauses and RFP language
Copy-ready starting points that move the assessment from a spreadsheet
into the agreement and the RFP. Edit the bracketed terms to fit, and
have counsel review before use. These are drafting aids, not legal
advice.
Contract clauses
Shared-responsibility matrix
Vendor shall maintain and attach as an exhibit a responsibility matrix that assigns one accountable party to each control across the applicable SRF layers (L1 to L5). Where a control is jointly operated, the matrix shall separate the portion Vendor controls from the portion [Customer] controls and assign each to a single owner. Vendor shall not characterize any control as "shared" without this split.
Data use and no training on customer data
Vendor shall not use [Customer] data, prompts, inputs, or outputs to train, fine-tune, or evaluate any model that is made available to other customers, and shall not retain such data beyond the period required to deliver the service. Vendor shall provide written confirmation of this control and evidence of technical enforcement on request.
Sub-processors, residency, and change notice
Vendor shall maintain a current list of all sub-processors, including any model, infrastructure, and labeling providers, with each provider's geographic location and data role. Vendor shall process [Customer] data only in [permitted regions] and shall give [Customer] at least [30] days' written notice before adding or replacing a sub-processor, changing a processing location, or changing the model that powers the service, with a right to object.
AI liability and IP indemnification
Vendor shall indemnify [Customer] against third-party claims that the service's AI output infringes intellectual property rights. The parties shall allocate liability for losses arising from AI-generated output, including erroneous, harmful, or non-compliant output, as set out in [Schedule X], and such liability shall not be excluded by general limitations on consequential damages to the extent it arises from Vendor's failure to meet the controls in this agreement.
Agentic controls and kill-switch
For any autonomous or agentic capability, Vendor shall provide [Customer] with configurable controls over autonomy level and human override, scope and rate limits on tool and action use, the ability to require human approval for [defined high-impact actions], a complete audit trail of agent actions, and a documented mechanism to immediately suspend agent activity. Vendor shall not change default autonomy or override settings without prior written notice.
Continuous evidence, re-assessment, and secure deletion
Vendor shall provide evidence that the controls in this agreement are operating, on a [continuous / quarterly] basis rather than only at point-in-time, and shall permit [Customer] to re-assess on any material change to the model, sub-processors, or autonomy configuration. On termination, Vendor shall securely delete all [Customer] data and provide a certificate of deletion within [30] days.
RFP question language
AI-specific RFP questions
1. Which SRF layers does your offering touch (L1 to L5), and what is your operating model (AI-SaaS, AI-PaaS, Agent-PaaS, IaaS)?
2. Provide a responsibility matrix stating which controls you own and which remain with us.
3. List the foundation models and sub-processors behind the service, with their geographic locations and data roles.
4. Confirm in writing that our data, prompts, and outputs are not used to train shared models, and describe how this is enforced.
5. Provide your current attestations (SOC 2 Type II, ISO/IEC 27001, ISO/IEC 42001) and, for AI governance, your ISO 42001 certification or NIST AI RMF profile.
6. Describe your defenses against prompt injection, including indirect injection from retrieved content or tool output.
7. Provide model and weight provenance, signing, and an AI bill of materials (AIBOM).
8. For agentic features, state the autonomy levels and human-override tiers supported, the permission model, and the kill-switch mechanism.
9. Describe how you notify customers of model, sub-processor, and autonomy changes, and the notice period.
10. Provide your data-retention and secure-deletion policy, including certificates of destruction on exit.
The downloadable VRA workpaper includes these clauses, the RFP questions, and an attestation-to-evidence mapping as separate tabs.