This is a ready-to-use addendum that bolts the AI-specific obligations onto a standard quality agreement, which was written for stable, deterministic products and does not cover a model that can change behavior without a version bump. Attach it to your existing quality agreement rather than rewriting the agreement. Replace every <<FILL: ...>> placeholder. A filled specimen of the key clauses follows. This content is educational and general, not legal advice; route it through your own legal and procurement functions before use.
Addendum control
| Field | Entry |
|---|---|
| Addendum title | AI and Machine-Learning Obligations Addendum |
| Parent quality agreement | <<FILL: agreement ID and date>> |
| Customer | <<FILL: regulated company>> |
| Supplier | <<FILL: AI/SaaS vendor>> |
| Product / model in scope | <<FILL: product and AI capability>> |
| Risk class of the use | <<FILL: advisory / automated classification / process-influencing>> |
| Effective date | <<FILL: date>> |
1. Purpose and scope
This addendum supplements the parent quality agreement with obligations specific to the AI or machine-learning capability in the product named above, as used for a GxP purpose. Where this addendum and the parent agreement conflict on an AI-specific matter, this addendum governs. It does not reduce any obligation in the parent agreement.
2. Model change notification
2.1 The supplier will give the customer advance written notice of any change to the model that could affect its behavior, including base-model updates the supplier initiates, retraining, and architecture changes, at least <<FILL: lead time, e.g. 30 days>> before the change is live in the customer’s environment.
2.2 The notice will describe the nature of the change, the capabilities affected, and any change in performance the supplier is aware of.
2.3 The customer may assess each notified change against its intended use before the change applies to its GxP use, and the supplier will <<FILL: pin the prior version / delay activation>> for that assessment window where the product allows.
3. Performance evidence and re-evaluation
3.1 The supplier will provide validation or test evidence for the model, stating the metrics, the thresholds, and that performance was measured on data the model did not see in training (a held-out test set), with the test population described.
3.2 The supplier will provide updated performance evidence after a material model change and on a <<FILL: cadence, e.g. annual>> periodic basis.
4. Drift and monitoring information
4.1 The supplier will surface the platform-level performance or drift signals it offers, listed at <<FILL: reference>>.
4.2 The customer has the right to the data it needs to monitor performance in its own context, including <<FILL: e.g. per-decision confidence, input characteristics>>.
5. Data handling, ownership, and reuse
5.1 The supplier states whether the customer’s data is used to train or improve the supplier’s models. As agreed here, customer data <<FILL: is / is not>> used for that purpose.
5.2 Customer data is segregated, retained for <<FILL: period>>, and deleted on request per <<FILL: mechanism>>. Customer data remains the customer’s data.
6. Transparency obligations
6.1 The supplier will make available the explainability information the product supports (for example confidence scores, feature attributions, source grounding for generative outputs) and the documented limitations of each, sufficient for the customer’s human review to be meaningful.
7. Audit and access rights
7.1 The customer may audit the supplier’s processes relevant to this product, including the model lifecycle, training-data governance, and change control, scaled to the risk class in the header, on <<FILL: notice period>> notice, or for cause.
8. Version pinning
8.1 Where the product is delivered by API or otherwise allows the supplier to change the model, the customer may pin a model version for <<FILL: duration / terms>>, or the supplier will provide compensating advance notice and an assessment window under clause 2.
9. Incident and escalation
9.1 The supplier will notify the customer within <<FILL: timeframe>> when it detects a model defect or performance problem that could affect the customer’s use, and will cooperate on the customer’s investigation.
10. Consistency and review
10.1 This addendum is consistent with the shared-responsibility matrix for this product (<<FILL: matrix ID>>); the matrix is the operational view and this addendum is the contractual one.
10.2 This addendum is reviewed on a change to the product, a change to the intended use, or at periodic review.
Acceptance criteria
The addendum is fit to sign when:
- It is signed by both parties before the AI is used for a GxP purpose.
- It contains a change-notification clause with a defined, usable lead time covering vendor-initiated model changes.
- It states whether and how customer data is used to train vendor models.
- It grants audit and access rights scaled to risk, covering the model lifecycle and change control.
- It is consistent with the shared-responsibility matrix.
Filled specimen (key clauses)
The following shows the load-bearing clauses completed for a deviation-triage SaaS model. Illustrative content; replace with your own.
| Clause | Completed entry |
|---|---|
| 2.1 Change notice lead time | 30 days advance written notice of any base-model change, retraining, or architecture change |
| 2.3 Assessment window | Prior model version pinned for the customer’s 30-day assessment window |
| 3.1 Performance evidence | Recall and precision on a described held-out set of 5,000 documents, with metric definitions |
| 5.1 Data reuse | Customer deviation data is NOT used to train the supplier’s models |
| 7.1 Audit rights | Annual audit of model lifecycle and change control on 30 days notice, plus for-cause |
| 8.1 Version pinning | Customer may pin the deployed version for up to 12 months |
| 9.1 Incident notice | Supplier notifies within 5 business days of a defect affecting the customer’s use |
The clause the customer negotiated hardest is 2.1, the change-notification lead time, because without it the validated state can lapse silently when the vendor updates the model. Everything else in the addendum protects a specific failure the standard agreement left open.
Common inspection findings this addendum prevents
- A quality agreement that predates the AI feature and never addresses model change, performance, or data reuse.
- No change-notification obligation, so vendor model updates arrive unannounced.
- Silence on whether customer data trains the vendor’s models.
- An AI agreement that contradicts the shared-responsibility matrix because the two were written by different functions.
How to adapt this addendum
- Attach it to your existing quality agreement; do not rewrite the parent agreement.
- Size the lead times, cadences, and audit rights to the risk class of the use.
- For an API-delivered model, sharpen clauses 2, 8, and 9; for an on-platform model some may not apply.
- Reconcile every clause with the shared-responsibility matrix before signature.
- Have legal and procurement finalize the contractual mechanics.