Matrix: AI Supplier Shared-Responsibility Allocation

This is a ready-to-use shared-responsibility matrix for an AI or SaaS product with a machine-learning or generative component used in a GxP process. It closes the accountability gap that is the most common AI-supplier failure: each side assuming the other validated the model, tested for drift, or controlled a change, so nobody did. The matrix names an owner for every lifecycle duty and, for every shared duty, the specific information that must flow and in which direction. Replace every <<FILL: ...>> placeholder. A filled specimen follows. This content is educational and general; adapt it and verify it before use.

How to use this matrix

List the AI capabilities the product actually exposes in your workflow, not the marketing list, the functions you rely on for a GxP decision.
Write the intended-use sentence for each: what the model outputs, what action it triggers, who owns the consequence.
Assign an owner to every lifecycle row below (Supplier, Customer, or Shared). For every “Shared” row, name the information that must pass and its direction.
Resolve every blank. An unassigned cell is the accountability gap you are closing. If the vendor will not commit to a row, that is itself a risk finding; document it and decide your own mitigation.
Sign it with both parties and reference it from the quality agreement. Review it on a defined trigger (product change, intended-use change, periodic review).

Ownership key

S = Supplier owns and performs.
C = Customer owns and performs.
Sh = Shared; the row names the information flow that makes it work.

The allocation matrix

#	Lifecycle duty	Owner (S / C / Sh)	What the owner does	Information flow (for Sh rows)
1	Model architecture and development	`<<FILL: S>>`	Builds and documents the model with a disciplined lifecycle and version control	—
2	Base-model training data governance	`<<FILL: S>>`	Sources, labels, and governs the base training data; describes sources, coverage, and known limitations	—
3	Customer-specific training / fine-tuning data	`<<FILL: C (Sh for tooling)>>`	Customer governs lineage, labeling SOP, labeler qualification, dataset versioning; supplier provides the tooling	Supplier to customer: tooling and constraints
4	Base-model performance evidence	`<<FILL: S>>`	Provides held-out test results, metric definitions, and the test-population description	—
5	Intended-use definition and risk class	`<<FILL: C>>`	Writes the intended-use statement and assigns the risk class that sizes everything	—
6	Acceptance criteria for this use	`<<FILL: C>>`	Sets thresholds tied to the cost of an error in your context	—
7	Performance verification on customer data	`<<FILL: C>>`	Confirms fitness on a representative sample of your own data	—
8	Configuration of the instance	`<<FILL: C>>`	Configures workflow, thresholds, the human step; verifies the configuration	—
9	Infrastructure and platform security	`<<FILL: S>>`	Secures hosting, encryption, availability; provides compliant logging	—
10	Access control and user provisioning	`<<FILL: C within S controls>>`	Supplier provides the controls; customer provisions and governs its users	Supplier to customer: available controls
11	Data handling and reuse	`<<FILL: Sh>>`	Whether customer data trains vendor models; segregation, retention, deletion	Supplier to customer: written attestation
12	Change notification	`<<FILL: S>>`	Gives advance written notice of model changes with usable lead time	Supplier to customer: notice per agreement
13	Change impact assessment and approval	`<<FILL: C>>`	Assesses each notified change against intended use; runs confirmatory testing; approves for GxP use	—
14	Drift and performance monitoring	`<<FILL: Sh>>`	Vendor surfaces platform-level signals; customer monitors against intended use in its context	Both directions: platform signals out, override-rate/anomalies back
15	Transparency and explainability	`<<FILL: Sh>>`	Vendor provides available explanations and their limits; customer uses them for review	Supplier to customer: explanation methods and limits
16	Audit trail and record integrity	`<<FILL: S provides / C configures>>`	Supplier provides compliant logging; customer configures, reviews, retains	—
17	Periodic re-evaluation	`<<FILL: Sh>>`	Vendor provides updated evidence; customer re-confirms fitness on its data	Supplier to customer: updated evidence on cadence/after change
18	Incident and defect notification	`<<FILL: S>>`	Notifies the customer of a model defect or performance problem affecting use	Supplier to customer: incident notice
19	Version pinning	`<<FILL: Sh>>`	Whether and for how long a version can be pinned, especially for API models	Supplier to customer: pinning terms
20	Human review in operation	`<<FILL: C>>`	The human confirms or overrides model output and owns the final decision	—

The principle that survives every product variation: the supplier owns what it builds and operates, the customer owns fitness for the specific GxP intended use and the integrity of customer data, and anything that needs information to flow is shared, which is where most of the interesting risk lives.

Acceptance criteria

The matrix is defensible when:

Every row has a named owner; no cell reads “unassigned” or “to be determined.”
Every “Shared” row names the specific information flow and its direction.
The matrix is signed by both parties and referenced from the quality agreement.
It maps to the capabilities you actually use, not a generic template.
It is reviewed on a defined trigger.

Filled specimen

The following shows selected rows completed for a SaaS platform whose model triages incoming deviations into a preliminary criticality tier that a QA reviewer confirms or overrides within one business day. Illustrative content; replace with your own.

#	Lifecycle duty	Owner	What that party does	Information flow
4	Base-model performance evidence	S	Provides held-out recall/precision on 5,000 general quality documents, with metric definitions	—
6	Acceptance criteria for this use	C	Sets recall threshold tied to the cost of a missed critical deviation	—
7	Performance verification on customer data	C	Confirms recall on a held-out sample of the company’s own labeled deviations	—
11	Data handling and reuse	Sh	Vendor attests customer deviations are not used to train its models and are segregated	Vendor to customer: signed attestation
12	Change notification	S	30 days advance written notice of base-model changes	Vendor to customer: notice
14	Drift monitoring	Sh	Vendor surfaces platform confidence signals; customer tracks override rate and input distribution	Signals out; override-rate/anomalies back
20	Human review in operation	C	QA reviewer confirms or overrides each tier and owns the final classification	—

Read as a story: the supplier builds and runs a competent product and tells you when it changes; you decide what the model may drive, prove it fits your deviations, control your data and users, govern every change, and keep a meaningful human in the loop. Nothing is unassigned, so when an inspector asks who is responsible for knowing the model still performs, there is one clear answer with evidence behind it.

Common inspection findings this matrix prevents

No documented division of responsibility, so the customer cannot say who is accountable for model performance.
A generic responsibility template that does not match the product actually bought.
“Shared” duties with no defined information flow, so in practice neither side acts.
The customer treating a vendor’s “validated” claim as discharging the customer’s own responsibility.

How to adapt this matrix

Add or remove lifecycle rows for the specific product (an API-delivered model needs rows 12 and 19 sharpened; an on-platform model may not).
For every Sh row, write the real information flow and the mechanism that carries it (a portal alert, a quarterly report, a monitoring feed).
Reconcile the matrix with the AI quality-agreement addendum so the operational and contractual views match.
Set the review trigger and re-sign on a product or intended-use change.