AI Assurance Academy · Part 3
Supplier and Foundation-Model Assurance
Chapter 9 of 20 · Commercial AI creates a layered supply chain: SaaS application, foundation-model provider, cloud host, retrieval service, monitoring tools, and data subprocessors. Supplier leverage is essential, but it cannot replace customer understanding of intended use and configured risk.
Commercial AI creates a layered supply chain: SaaS application, foundation-model provider, cloud host, retrieval service, monitoring tools, and data subprocessors. Supplier leverage is essential, but it cannot replace customer understanding of intended use and configured risk.
Published: September 4, 2026 | Version 1.0
Editorial owner: CSV to CSA Knowledge Hub | Review status: Open for practitioner peer review
THE SUPPLY-CHAIN MAP
Identify:
- Contracted application supplier
- Foundation-model provider and model family
- Cloud and region
- Embedding, reranking, moderation, and monitoring services
- Data storage and logging providers
- Human annotation or evaluation providers
- Open-source components and licenses
- Support or implementation partner
The vendor of record may not control the component that changes model behavior.
RISK-BASED SUPPLIER QUESTIONS
Governance and quality
- Who owns AI quality, safety, security, and change decisions?
- Which lifecycle procedures are controlled and audited?
- How are requirements, risks, testing, defects, and releases managed?
- Which independent certifications or assessments apply to the exact service?
Model and data
- What model and version serve the use case?
- Can traffic be routed among models?
- Is customer data used for training, tuning, or service improvement?
- What are the known limitations, excluded uses, context limits, and supported languages?
- How are training-data rights, provenance, and quality governed?
Evaluation
- Which capabilities and risks are evaluated before release?
- Are results available by task, language, subgroup, and failure type?
- How are hallucination, harmful content, prompt injection, privacy leakage, and tool misuse assessed?
- Which unresolved defects or limitations remain?
Change
- What can change without customer action?
- Is advance notification available?
- Can the customer pin a version?
- How are emergency changes handled?
- What evidence accompanies a release?
Operations
- What is logged, retained, and available to the customer?
- How are incidents detected, classified, communicated, and investigated?
- What are availability, recovery, and data-export commitments?
- Can the service be disabled or rolled back?
THE EVIDENCE LEVERAGE DECISION
For each feature, determine whether supplier evidence is:
Applicable
Same model, version, configuration, input type, language, and use condition.
Credible
Produced under controlled methods with defined criteria, representative data, issue handling, and qualified review.
Complete enough
Covers the important failure, not only average capability.
Current
Remains valid after model, prompt, retrieval, safety, infrastructure, or data changes.
Then choose:
Accept → directly supports the use.
Confirm → verify a small customer-specific condition.
Supplement → perform targeted customer evaluation.
Do not rely → use stronger independent evidence, restrict use, or select another solution.
FOUNDATION-MODEL LIMITATIONS
A provider may not disclose training data, weights, or complete test details. Lack of access does not automatically make the service unusable, but it increases reliance on black-box evaluation, contractual control, monitoring, restricted authority, and fallback.
Do not infer that a general benchmark proves performance for deviation narratives, SOP retrieval, complaint coding, or manufacturing data.
CONTRACT CONTROL CHECKLIST
- Approved service, model options, and use restrictions
- Customer-data ownership and training exclusion
- Confidentiality, privacy, region, retention, and deletion
- Security, vulnerability, and incident notification
- Subprocessor transparency and material change
- Model and service change notification
- Release and evaluation evidence
- Logging and audit information
- Availability, recovery, and continuity
- Version pinning or controlled migration where available
- Suspension, exit, and data export
- Right to audit or credible alternative assurance
WORKED EXAMPLE: LLM INSIDE AN eQMS
The eQMS vendor embeds a third-party LLM for document Q&A. The eQMS vendor controls prompts and retrieval, while the foundation provider controls model weights and safety layers.
Supplier-level evidence:
- eQMS architecture and retrieval design
- Approved-document filtering and access control
- Foundation-provider security and privacy terms
- eQMS evaluation of supported functions
- Release and incident processes
Customer-specific evidence:
- Tenant document states and access groups
- Index completeness and supersession
- Representative SOP question set
- Citation correctness and source access
- Unanswerable and conflicting-source behavior
- User interface and training
- Production monitoring and feedback
The customer should not duplicate provider model development. It must verify the configured knowledge boundary and actual intended use.
RED FLAGS
- “Enterprise grade” replaces evidence
- Model identity is unknown
- Provider can use prompts for training by default
- Change notification excludes model routing or safety updates
- Only aggregate benchmarks are provided
- Logs cannot connect an output to a version or configuration
- Contract permits unannounced subprocessors with data access
- Customer has no export or shutdown path
- The supplier markets the feature as “validated” without defining scope
SUPPLIER REVIEW RECORD
Supplier and service:
Critical sub-suppliers:
Intended use supported:
Data flow and regions:
Model/version controls:
Evidence reviewed:
Known limitations:
Change commitments:
Incident and continuity commitments:
Customer-specific gaps:
Supplemental assurance:
Residual risk and approval:
Next review and triggers:
PROFESSIONAL INTERPRETATION
The correct output of supplier assessment is not an approved questionnaire. It is a defensible statement of what the supplier controls, what evidence is trusted, what remains uncertain, and what the customer must test, monitor, or constrain.
PRIMARY SOURCES
FDA CSA final guidance, vendor evaluation and SaaS example:
www.fda.gov/media/188844/download
NIST Generative AI Profile:
ISPE, GAMP Guide: Artificial Intelligence. Industry guidance; not a regulation:
ispe.org/publications/guidance-documents/gamp-guide-artificial-intelligence