At a glance
Competency IV.C is the largest in Domain IV (it carries the most exam items) and the most operational. Deployment is not a finish line — it starts an ongoing governance loop. The seven performance indicators map to the lifecycle after go-live: apply your policies, monitor and maintain, periodically assess, document incidents, forecast and reduce downstream harm, communicate externally, and keep a control to deactivate or localize the system.
The two frameworks behind this are the NIST AI RMF “Manage” function (respond to and monitor risks of deployed systems) and EU AI Act deployer obligations (human oversight, monitoring, logging, incident reporting, transparency). Keep both in mind throughout.
IV.C.1 — Apply policies, procedures, best practices and ethics to deployment
Governance designed on paper must actually bind the deployed system. The BOK calls out four areas:
- Data governance — control over the data flowing through the system in production: access controls, quality, retention, lineage and (for RAG) the knowledge base.
- Risk management — the live risk register and treatment plan continue to operate; deployment doesn’t close it.
- Issue management — a defined process to triage, escalate, track and resolve problems users or monitoring surface.
- User training — operators and end users are trained on correct use, limitations and when to escalate or override (AI literacy, EU AI Act Art. 4) — and this includes human oversight by competent people (Art. 14).
IV.C.2 — Continuous monitoring and a maintenance/update/retraining schedule
Because models drift, a deployed system must be watched and refreshed on a schedule, not assumed stable.
- Continuous monitoring — track accuracy, latency, error rates, bias metrics, data drift, and anomalous or abusive inputs/outputs. Log enough to investigate later (EU AI Act logging duties).
- Maintenance & updates — patch security issues, update dependencies, refresh prompts/RAG sources, and manage vendor model changes.
- Retraining schedule — a planned cadence and triggers (e.g., a performance threshold breach) for retraining — balanced against the re-validation every retrain demands.
IV.C.3 — Periodic assessment: audits, red teaming, threat modeling, security testing
Beyond passive monitoring, run active, periodic evaluations of performance, reliability and safety:
- Audits — internal or independent reviews against policy, regulation or standards (e.g., bias audits like NYC LL144; ISO 42001 management-system audits).
- Red teaming — adversarial testing that tries to break the system or elicit harmful output (especially important for generative/agentic systems).
- Threat modeling — map how the system could be attacked or abused, then prioritize defenses.
- Security testing — test for ML-specific threats: data poisoning, adversarial examples, model inversion/extraction, prompt injection.
| Activity | Question it answers |
|---|---|
| Audit | Are we compliant and performing as claimed? |
| Red teaming | Can someone make this produce harm or fail? |
| Threat modeling | How could this be attacked or abused, and where do we defend first? |
| Security testing | Is it resilient to known ML attacks? |
IV.C.4 — Document incidents, issues, risks and post-market monitoring plans
Governance must be evidenced. Maintain living documentation:
- Incident and issue logs — what happened, impact, root cause, remediation, and timing.
- Risk records — the risk register kept current through the system’s life.
- Post-market monitoring plan — how performance and incident data are collected and reviewed after deployment (an EU AI Act provider duty and deployer good practice).
This documentation feeds regulatory reporting: the EU AI Act requires serious-incident reporting (Art. 73) within set timeframes, and deployers must inform providers/authorities of incidents they observe and keep logs.
IV.C.5 — Forecast and reduce secondary/unintended uses and downstream harms
Systems get used in ways their designers never intended (function creep), and outputs cause effects far from the point of use. The deployer must look ahead:
- Forecast secondary/unintended uses — anticipate how the system could be repurposed or misused beyond its validated scope.
- Reduce downstream harms — constrain use to the intended purpose with acceptable-use policies, technical guardrails, access controls and output limits, and re-assess when the use case expands.
This is where the dual-use nature of AI from I.A becomes an operational duty: a tool validated for one population or purpose may be unsafe or unfair for another.
IV.C.6 — Establish external communication plans
Decide in advance what you tell the outside world, and to whom:
- Transparency to users / affected people — disclose that AI is in use, its role, and (where required) provide explanations or contest/appeal routes (EU AI Act transparency duties; GDPR Art. 22 for automated decisions).
- Regulator communications — channels and templates for incident reports and inquiries.
- Public / stakeholder communications — a plan for responding when something goes wrong, so messaging is consistent and timely.
A pre-built plan turns a crisis into a process. Improvising disclosure during an incident erodes trust and risks regulatory missteps.
IV.C.7 — Policy and controls to deactivate or localize the system
Finally, you need the ability — and the policy authorizing it — to stop or contain a system.
- Deactivation / kill switch — a defined control to rapidly disable, roll back to a safe version, or take the system offline when it malfunctions, causes harm, or becomes non-compliant. The policy must say who can trigger it, on what criteria, and how.
- Localization — restrict or adapt the system by jurisdiction: disable a non-compliant feature in a given region, or keep data in-region, to meet differing regulatory requirements.
These are governance controls, not just engineering features: they require pre-defined authority, triggers and procedures so the organization can act decisively under pressure.
How this shows up later
- IV.C is the operational expression of everything earlier: the I.A characteristics (drift, opacity, autonomy) justify monitoring, red teaming and kill switches.
- It maps directly onto the NIST AI RMF Manage function and EU AI Act deployer obligations (oversight, logging, incident reporting, transparency) — high-yield to connect on the exam.
- The documentation and reporting duties tie back to the impact assessment and contract terms from IV.B.