Academy module 7 · ISO/IEC 27090 · Lesson 7 of 8
Control model supply chains and updates
About 8 minutes · Introductory draft · Checked 2026-10-23
AI-authored and AI editorially reviewed; independent review pending. Read course scope and remaining gaps.
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 you will learn
- Record component data and model origins.
- Approve evidence and known limitations.
- Verify the intended version and rollback path.
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.
Work through a scenario
Fictional facts for learning. This exercise is not scored.
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.
Compare your reasoning
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.
Remember
- An approved version must remain identifiable from build to deployment.
- Record component data and model origins.
- Verify the intended version and rollback path.
Orientation and further reading
- ISO: ISO/IEC 27090:2026 · Published AI-security guidance
- NIST AI 100-2 E2025: adversarial machine learning
Original examples and explanations. Background references do not establish complete exam coverage.
Try ISO/IEC 27090 practice questions · Report a content correction