This is a ready-to-use boundary statement for any AI or machine learning capability delivered by a vendor. A vendor’s general claim of “validated AI” almost never covers the specific model trained on your data for your intended use; the regulatory accountability for that trained instance stays with you. This form makes the boundary explicit in writing so it is never assumed. Replace every <<FILL: ...>> placeholder. A worked filled specimen follows the template.
Document control header
| Field | Entry |
|---|---|
| Document title | AI Vendor and Trained-Instance Boundary Statement |
| Document number | <<FILL: reference>> |
| System / vendor product | <<FILL: SYSTEM NAME, VENDOR>> |
| Owner | <<FILL: role, e.g. System Owner>> |
| Linked supplier assessment | <<FILL: reference and date>> |
1. Purpose
This statement records, for a specific AI-enabled vendor product, exactly what the vendor’s validation and quality claims cover, what the site validated independently, and how a vendor-driven model change is governed. It closes the gap where a vendor’s “fully validated” marketing claim is mistaken for site-level evidence.
2. What the vendor validated (the platform)
| Item | Description |
|---|---|
| Platform / infrastructure covered by vendor validation | <<FILL: e.g. the ML pipeline infrastructure, the base model architecture, the hosting environment>> |
| Evidence available from the vendor | <<FILL: e.g. SOC 2 report, ISO certification, vendor validation summary>> |
| What the vendor’s evidence does NOT cover | <<FILL: e.g. performance of the model as configured/trained on this site's specific data and use case>> |
3. What the site validated (the trained instance)
| Item | Description |
|---|---|
| The specific trained or configured instance | <<FILL: e.g. the model as trained on our environmental monitoring data for our specific alert-flagging use case>> |
| Site’s own performance evidence | <<FILL: reference to the site's validation summary report>> |
| Intended use as validated | <<FILL: the decision the model drives at this site, matching the model documentation on file>> |
For an API-delivered model the site cannot fully inspect or version (a hosted large language model, for example), record what the site owns and controls in lieu of the model itself: the prompt, the retrieval or grounding setup, guardrails, and output handling. These are the artifact the site validates and defends when the underlying model is not directly in the site’s control.
| Item (API model context) | Description |
|---|---|
| Pinned model version (where the vendor allows) | <<FILL>> |
| Prompt / retrieval / guardrail configuration owned by the site | <<FILL>> |
| Output handling and human review step | <<FILL>> |
4. Vendor model-change behavior
| Question | Answer |
|---|---|
| Can the vendor change the deployed model without site notification? | <<FILL: Yes / No, and the contractual basis>> |
| Notification lead time contractually committed | <<FILL: e.g. 30 days, or "not committed," stated plainly if so>> |
| Site’s response when notified of a vendor model change | <<FILL: re-run the confirmatory test set before continuing to use the new version, per the site's change control>> |
| Site’s response if a vendor change is discovered without notification | <<FILL: treat as an unplanned change event; hold use pending confirmatory testing; escalate to the supplier relationship owner>> |
5. Reliance justification
Where the site relies on vendor evidence in lieu of independent testing for any part of this system, state the justification here. Reliance is acceptable when the supplier assessment supports it; it is not acceptable as an unexamined shortcut.
<<FILL: e.g. "The site relies on the vendor's SOC 2 Type II report for infrastructure security controls, per supplier assessment SA-2026-014. The site does not rely on the vendor's general AI validation claim for model performance; performance evidence is the site's own, per VSR-AI-011.">>
6. Acceptance criteria
- The boundary between vendor-validated and site-validated is written down, not assumed or verbal.
- The site holds its own performance evidence for the trained instance, independent of any vendor “validated AI” marketing claim.
- Vendor model-change behavior is documented and is captured in the site’s own change control, not left to the vendor’s discretion alone.
- Any reliance on vendor evidence is justified against a named supplier assessment.
7. References
GAMP 5, Second Edition (ISPE), and the FDA computer software assurance approach, for the principle that supplier evidence may be reused only where a supplier assessment supports it. EU GMP Annex 11 clause 3.2, on supplier and service provider competence and reliability.
Confirm the current version of each reference before issue.
8. Revision history
| Version | Date | Author | Summary of change |
|---|---|---|---|
<<FILL: 1.0>> | <<FILL: date>> | <<FILL: author>> | Initial issue. |
9. Approvals
| Role | Name | Signature | Date |
|---|---|---|---|
| Author (System Owner) | <<FILL>> | ||
| Reviewer (QA) | <<FILL>> |
Filled specimen
The following shows the statement completed for an example vendor anomaly-detection platform used in environmental monitoring, so you can see the level of detail expected. The vendor and system are illustrative; replace them with your own.
| Field | Entry |
|---|---|
| Platform covered by vendor validation | The vendor’s ML pipeline infrastructure and base anomaly-detection architecture, per the vendor’s SOC 2 Type II report |
| What vendor evidence does NOT cover | Performance of the model as trained on this site’s environmental-monitoring data for this site’s alert thresholds |
| Site’s trained instance | The model retrained quarterly on the site’s own EM plate-count history, validated per VSR-AI-009 |
| Vendor model-change behavior | Vendor commits 30 days’ notice of base-model version changes per the quality agreement; site re-runs its confirmatory test set on notification before continuing use |
| Reliance justification | Site relies on vendor SOC 2 report for infrastructure security (SA-2026-014); site does not rely on any vendor performance claim, all performance evidence is site-generated |
An investigator who reads a vendor claim of “fully validated AI” and asks what that covers gets, from this statement, a precise answer: the vendor validated the platform, the site validated the model trained on its own data, and a vendor-driven change is a governed event, not a silent update.
Common inspection findings this form prevents
- A vendor “validated AI” claim accepted at face value with no site-level performance evidence for the trained instance.
- No record of the vendor’s model-change behavior, so a vendor-driven update reaches production ungoverned.
- The boundary between vendor-validated and site-validated never written down, leaving accountability ambiguous when a model behaves unexpectedly.
- Reliance on vendor evidence with no named supplier assessment justifying it.
How to adapt this form
- Complete one boundary statement per AI-enabled vendor product; do not write one blanket statement for every vendor tool.
- For an API-delivered model you cannot inspect, focus section 3 on what you do own and control (prompt, guardrails, output handling), since that is the artifact you validate and defend.
- Confirm the vendor’s contractual notification commitment in section 4 against the actual quality or technical agreement, not an assumption.
- Review and re-approve this statement whenever the supplier assessment is renewed or the vendor’s contract terms change.