Govern the release, monitoring and maintenance of the AI system

At a glance

This competency owns the back half of the life cycle — release and everything after. It is the densest part of Domain III (the BOK weights it 8–10 questions) and lives mostly in NIST AI RMF MANAGE, with periodic assessment looping back into MEASURE.

Six moves:

1. III.C.1 — Release. Assess readiness; build the model card; satisfy conformity.
2. III.C.2 — Monitor. Continuous monitoring plus a maintenance/update/retraining schedule.
3. III.C.3 — Assess periodically. Audits, red teaming, threat modeling, security testing.
4. III.C.4 — Handle incidents. Manage and document incidents, issues and risks.
5. III.C.5 — Root-cause. Work cross-functionally to understand why incidents arise.
6. III.C.6 — Disclose. Make public/transparency disclosures.

The unifying idea: an AI system is never “done.” Because models degrade as the world changes (drift), governance after launch is continuous, not a one-time sign-off.

III.C.1 — Assess readiness and prepare for release

Release is a gate, not a formality. Before production you confirm:

• The system meets its acceptance thresholds (the metrics/thresholds set in III.A.3 / tested in III.B.3).
• Documentation is complete — technical documentation, test results, risk register.
• A model card exists — intended use, training data summary, performance across conditions and groups, limitations, ethical considerations.
• Conformity requirements are satisfied — for EU high-risk AI, the provider completes the conformity assessment (Art. 43), draws up the EU declaration of conformity, affixes the CE marking, and registers the system in the EU database before placing it on the market.
• A rollback / deactivation plan and monitoring are in place for day one.

III.C.2 — Continuous monitoring, maintenance and retraining

Once live, the system must be watched and kept current. Continuous monitoring tracks:

• Performance against the thresholds set at design time (accuracy, error rates, latency).
• Drift — the dominant reason models silently decay.
• Inputs and outputs — for anomalies, misuse, out-of-distribution inputs, harmful outputs.
• Operational health — uptime, throughput, cost.

Two drift types the exam loves to contrast:

Both degrade performance and are addressed by retraining on fresh data — which is why you set a regular schedule for maintenance, updates and retraining, plus event-driven triggers (drift alarm, performance breach, data/threat change).

Safe update patterns. When a retrained or replacement model is ready, you don’t have to swap it in blind:

• Champion/challenger — the live model (champion) keeps serving while one or more challengers run against the same inputs; a challenger is promoted only when it demonstrably outperforms in production conditions.
• Shadow deployment — the new model receives real traffic but its outputs aren’t acted on; used to validate behaviour at scale before go-live.
• Canary / phased rollout — release to a small slice of traffic first, watch the metrics, then expand.

These patterns matter to governance because they make model updates evidence-based and reversible — a controlled experiment instead of a leap.

III.C.3 — Periodic assessment: audits, red teaming, threat modeling, security testing

On top of continuous monitoring, run scheduled deep assessments. Know how the four named activities differ:

• Audit — systematic, often independent assurance that the system conforms to criteria (policy, standard, law). Answers “does it comply?”
• Red teaming — adversarial testing where a team actively tries to break the system, elicit harmful output or find misuse. Answers “how can this fail or be abused?”
• Threat modeling — structured analysis of attackers, assets and attack surfaces to prioritise defences. Answers “what could go wrong and where?”
• Security testing — technical probing for vulnerabilities (poisoning, adversarial examples, model inversion/extraction, prompt injection). Answers “is it exploitable?”

III.C.4 — Manage and document incidents, issues and risks

An AI incident is harm, near-harm, failure, or out-of-bounds behaviour from the system. A governed incident process:

1. Detect — via monitoring, user reports or audits.
2. Triage and contain — assess severity; throttle, roll back or deactivate if needed.
3. Investigate and root-cause (feeds III.C.5).
4. Remediate — fix, retrain, patch, update controls.
5. Document — what happened, impact, cause, response, lessons.
6. Report — notify required parties. Under EU AI Act Art. 73, providers must report serious incidents to authorities within set deadlines.

Documentation closes the loop: incidents feed the risk register, update the impact assessment, and inform the next retraining and the public disclosures.

This maps onto the classic named incident-response lifecycle (borrowed from security): preparation → identification/detection → containment → eradication → recovery → lessons learned. The AI twist is that “eradication/recovery” often means retraining or rolling back a model, and “lessons learned” feeds the risk register and monitoring thresholds — plus AI-specific regulatory reporting duties on top.

III.C.5 — Cross-functional root-cause of incidents

Understanding why an incident happened is a cross-functional exercise — data scientists, engineers, domain experts, legal and affected-business owners — because causes span data, model, software and context. The BOK names the usual culprits:

• Brittleness / lack of robustness — the model fails on edge cases or out-of-distribution inputs it wasn’t hardened against.
• Lack of quality data — biased, incomplete or mislabelled training data surfaces as bad behaviour later.
• Insufficient testing — a failure mode that pre-deployment testing should have caught but didn’t.
• Model or data drift — the world moved and the model wasn’t retrained (links to III.C.2).

Mapping the symptom to the right root cause drives the right fix: drift → retrain on fresh data; brittleness → harden / adversarial-train; data quality → fix data and lineage; insufficient testing → strengthen the test plan (III.B.3).

III.C.6 — Public disclosures to meet transparency obligations

Transparency does not stop at launch. The BOK names three external disclosure artefacts:

• Technical documentation — the provider’s full record (EU AI Act Annex IV), kept current and available to authorities.
• Instructions for use to deployers — how to operate the system safely, within its limits and intended purpose (EU AI Act Art. 13). This is how a provider equips a deployer to use the system responsibly.
• Post-market monitoring plans — the provider’s documented plan to collect and review field performance after deployment (EU AI Act Art. 72), feeding corrective action and incident reporting.

Other transparency duties that ride alongside: telling people when they are interacting with AI, and labelling AI-generated content / deepfakes (EU AI Act Art. 50).

How this shows up later

• The post-market monitoring and instructions for use the provider produces here are exactly what the deployer in Domain IV receives and must act on.
• Drift, audits, red teaming and incident management recur in IV.C from the deployer’s perspective for systems they did not build.
• The deactivation/localization control hinted at in III.C.4 becomes an explicit deployer obligation in IV.C.7.
• Incident root causes feed back into the design and data controls of III.A and III.B for the next version — closing the life-cycle loop.