AI Shared-Responsibility Matrix

1. Which ways do you use AI?

Pick every deployment model you have. Most organisations have more than one.

Tap a row to see what each side does for every model you picked.

3. Your responsibilities

“Provider” here means the model API provider. Tick items as you put them in place; ticks stay in this browser.

• Prompt injection (direct and indirect) SharedSeparates instructions from untrusted content, filters retrieved data and limits what the model can trigger in your app.Get evidence that the provider does its part: trains the model to resist manipulation and may offer optional safety or moderation features.
• Data and model poisoning SharedProtects any fine-tuning data you upload and the documents your app retrieves.Get evidence that the provider does its part: protects the integrity of the data the base model was trained and tuned on.
• Evasion and adversarial examples ProviderTests the model on your own use cases and adds checks where a wrong answer is costly.Get evidence that the provider does its part: owns the robustness of the model itself.
• Model theft and extraction ProviderProtects your API keys, system prompts and access to any fine-tuned versions.Get evidence that the provider does its part: protects the model weights and limits extraction through its API.
• Model inversion and data reconstruction ProviderAvoids exposing raw scores or stored embeddings from your own app to its users.Get evidence that the provider does its part: decides what the model reveals about its training data and what scores the API returns.
• Membership inference ProviderGets a privacy review before fine-tuning on records about real people.Get evidence that the provider does its part: owns privacy protections for the base model's training data.
• Supply chain and model provenance SharedSecures the SDKs and libraries you use, does supplier due diligence and records the model in your AI inventory.Get evidence that the provider does its part: secures its own model build pipeline, dependencies and sub-processors.
• Insecure output handling CustomerValidates, encodes and schema-checks model output before showing, storing or executing it.
• Excessive agency and tool abuse CustomerDecides which tools the model can call, with what permissions, and which actions need a human approval.
• Denial of wallet and resource abuse SharedSets per-user quotas and spend caps in your app and protects keys from misuse.Get evidence that the provider does its part: protects its service capacity and may offer usage limits and alerts.
• Sensitive data leakage SharedDecides what data you send, keeps secrets out of system prompts, filters output and secures your own logs.Get evidence that the provider does its part: handles prompts and responses under its terms: retention, use for training, staff access and encryption.

Questions to ask the provider

• Prompt injection (direct and indirect): How do you test the model or feature against direct and indirect prompt injection, and can we see a summary of the results?
• Prompt injection (direct and indirect): Which guardrail or filtering features exist, are they on by default, and what do they not cover?
• Data and model poisoning: How do you check the integrity and provenance of the data the model is trained and tuned on?
• Data and model poisoning: Is our data ever used to train or tune models other customers use, and can we opt out?
• Evasion and adversarial examples: How do you evaluate the model against adversarial or unusual inputs before each release?
• Evasion and adversarial examples: How are we told when a model update changes behaviour?
• Model theft and extraction: How are model weights and our fine-tuned versions protected from unauthorised access or extraction?
• Model theft and extraction: What access logs can we get for our endpoints and keys?
• Model inversion and data reconstruction: Does the API or feature return confidence scores, log probabilities or embeddings, and can we turn them off?
• Membership inference: What privacy protections apply to training data, and has anyone measured how much of it can be inferred?
• Supply chain and model provenance: Which third-party models, datasets and sub-processors does the service depend on, and how are we told about changes?
• Supply chain and model provenance: Can you provide provenance details or an AI bill of materials for the model?
• Denial of wallet and resource abuse: What usage limits, spend caps and alerts can we set, per user and per account?
• Sensitive data leakage: How long are prompts, responses and logs kept, who can access them, and where are they stored?
• Sensitive data leakage: How does the feature respect each user's existing permissions when it answers?