Academy learning group 4 · Academy module (not an ISO clause) M07 · Chapter 7 of 8
Control model supply chains and updates
About 5 minutes · ISO/IEC 27090:2026 · Published AI-security guidance
Session only. Enable saving or download a backup from this course’s hub.
Completion is self-reported and does not certify understanding.
See it · Try it · Recall it
Picture the topic
Remember this: An approved version must remain identifiable from build to deployment.
Explore the anchors
Record component data and model origins.
Concept matching activity
Match this task or description to its concept:
Approve evidence and known limitations.
Choose a concept before checking the explanation.
A quick way to study this topic
- Hide the explanation and redraw these three anchors from memory.
- Explain the difference between the anchors in your own words.
- Apply the distinction to the worked example below. Check the full lesson for assumptions and exceptions.
- Recall it again tomorrow, then after a few days. A memory hint is a retrieval cue, not a replacement for understanding.
Original academy illustrations and fictional exercises. These are learning simulations, not a real virtual machine, network assessment or measure of job readiness. Activities reset when you leave or reload; they do not change quiz scores.
What this chapter explains
- Concepts and distinctions
- Apply the process and collect evidence
Concepts and distinctions
AI releases can change through new data, retraining, model replacement, dependency updates and configuration changes. A model identifier without the associated dataset, evaluation configuration and serving conditions may be insufficient to reproduce observed behavior. Treat the pipeline as an operating system of trust decisions, not merely a sequence of file transfers.
Third-party models and components introduce their own access, integrity, support and use constraints. Signatures and hashes help connect artifacts to trusted references when keys and verification are protected. They do not establish that the model’s learned behavior meets every organizational requirement. Release integrity and behavioral acceptance must both be evaluated.
Apply the process and collect evidence
Separate change proposal, evaluation and deployment authority where appropriate. Retain artifact versions and approval evidence, check the deployed version, and rehearse rollback or service restriction for a problematic release. Assess changes in external model services as dependencies even when the organization does not control their training pipeline. Record limitations rather than approving a release from a benchmark number alone.
| Concept | What to remember |
|---|---|
| Provenance | Record component data and model origins |
| Release gate | Approve evidence and known limitations |
| Deployment | Verify the intended version and rollback path |
Worked example
A model passes evaluation, but a deployment script points to an unversioned “latest” artifact that changes overnight. The team cannot reproduce the output reported by a learner. Bind the release to approved identifiable artifacts and relevant configuration. Preserve the observed version and evidence, investigate the mismatch and restore an authorized state if necessary. A successful test of one artifact does not approve every artifact later found under a moving label.
Check your understanding
What is the main problem with deploying an unversioned latest artifact?
Show explanation
The deployed system may differ from the model and configuration that were evaluated. A moving identifier breaks the connection between approval evidence and runtime state.
Source and study boundary
Official standard overview. The reference identifies the topic being taught. Explanations and examples are original academy material; a topic link does not establish independent approval or sufficient exam mastery.