MANAGE: The Controls That Actually Stop AI Failures
Why testing before launch isn't the same as monitoring after, and where most organizations go blind
You deployed an AI system six months ago. Your governance structure is in place. Your risk mapping is done. Then your model starts returning inconsistent predictions for edge cases nobody caught in testing. Your legal team wants to know: who’s watching this? How did we not see this coming? When does it get fixed?
That’s MANAGE. It’s where the concrete work of risk control happens—the part most organizations skip because it’s unglamorous and continuous, not a checkbox you complete and move on.
MANAGE is four things: evaluating AI systems against your risk tolerance, building controls that actually mitigate identified risks, monitoring performance so you catch drift before customers do, and documenting failures so you learn instead of repeat them.
What MANAGE Actually Requires
Risk evaluation and treatment. Before deploying any AI system—or continuing to run one already live—you weigh documented risks against your established risk tolerance. This isn’t abstract. If you said in GOVERN that you accept 2% error rate for a chatbot but zero tolerance for bias in loan decisions, MANAGE is where you prove the system meets that bar. If it doesn’t, you treat the risk: add a control, reduce the model’s scope, require human review, or don’t deploy. Residual risks—the ones you can’t fully mitigate—get documented and disclosed to stakeholders who need to know.
Control design and implementation. This is the technical and operational infrastructure that actually prevents bad outcomes. It includes data quality controls (ensuring training data is representative and documented), model performance controls (continuous testing against the metrics you defined), and human-in-the-loop workflows for high-stakes decisions. A loan approval system flagged by your monitoring as drifting doesn’t automatically approve loans while engineers debug it—there’s a control requiring a human reviewer. Better: an automated circuit-breaker control that diverts inference requests into an async queue for human-in-the-loop validation whenever prediction confidence drops below 85%. A recruiting AI showing bias against candidates over 50? There’s a control that either retrains the model on debiased data or surfaces that category explicitly to human hiring managers. Controls aren’t theoretical. They’re the actual processes that operate every day.
Continuous monitoring. Your AI system’s performance at deployment isn’t its performance three months later. Data drift, adversarial attacks, shifts in user behavior, or unintended feedback loops can degrade performance and trustworthiness over time. Monitoring protocols capture this: metrics on model accuracy, fairness by demographic groups, explainability, and alignment with organizational values. You’re not running annual audits. You’re tracking performance continuously and raising alerts when things move outside acceptable ranges. Most organizations have no visibility here—they test before launch and hope nothing breaks after.
Error and incident documentation. When something does break—a model produces unexpected results, a system is used for purposes outside its original scope, or unforeseen bias emerges—you document it systematically. How was it identified? What was the impact? What corrective actions were taken? Why did current controls miss it? This isn’t punishment. It’s the feedback loop that improves your entire AI governance system. Organizations that don’t document incidents repeat them.
Managing third-party and pre-trained AI. Your organization’s AI risk isn’t limited to systems you built. It includes every vendor tool using AI: the CRM that scores leads, the cloud service that flags anomalies, the SaaS platform using pre-trained models. MANAGE requires applying the same risk controls to third-party AI as to internal systems. That means vendor transparency (how was their model trained? what data did it use?), independent testing of their system before you rely on it, and continuous monitoring of third-party performance in your environment. Many organizations discover too late that they have no visibility into how vendor AI behaves with their data. Pre-trained models—foundation models adapted for your use case—add another layer: you inherit both their performance characteristics and their risks. Controlling these requires documenting what you’re using, tracking performance independently, and knowing your vendor’s support and incident response procedures if something fails.
Why Most MANAGE Efforts Stall
Companies usually fail at MANAGE in predictable ways:
They build controls for deployment and stop. Testing before launch is critical. But testing before launch isn’t monitoring. Once an AI system is live and processing real data with real users making real decisions, the conditions have changed. Pre-deployment TEVV (Testing, Evaluation, Verification, and Validation) catches known unknowns. Post-deployment monitoring catches unknown unknowns. Many organizations invest heavily in one and completely neglect the other. Three months into production, when the system is silently degrading, there’s no one watching.
They treat monitoring as an engineering problem alone. Monitoring is technical—data pipelines, dashboards, alert thresholds. But acting on monitoring findings is organizational. When monitoring flags that a model’s accuracy has dropped below acceptable levels, who has authority to pull it from service? Is it the same engineer who built it? An independent risk function? Legal? If those decisions aren’t clear, your monitoring generates findings nobody acts on. You have visibility without governance. Assign clear operational ownership using a tripartite structure: Data Science/Engineering owns detection and technical triage (what’s happening?); Risk/Compliance holds stop-work authority (can pull or downgrade a live model unilaterally); Product/Business Owners sign off on residual risk before re-deployment. This separation keeps detection honest and ensures authority sits outside the build function.
They separate post-deployment monitoring from pre-deployment testing. If your pre-deployment testing was rigorous on fairness but your post-deployment monitoring doesn’t measure fairness, you’re only catching part of the picture. The control gaps are the risks you’re most likely to miss. NIST’s language is explicit: MANAGE requires integrating trustworthiness characteristics throughout monitoring. If your pre-deployment testing measured bias, your monitoring should too. Rule of thumb: Every metric evaluated during pre-deployment TEVV—demographic parity, toxicity scores, hallucination rates, accuracy baselines—must map directly to an active telemetry stream and alerting threshold post-launch. If it was important enough to test before deployment, it’s important enough to track after.
They confuse monitoring with compliance auditing. Annual audits are useful. Continuous monitoring is different. You can’t wait until next year to know a system has drifted. Monitoring happens at the operational tempo the risk demands. High-stakes systems get daily or weekly checks. Lower-risk systems might be quarterly. But the cadence is defined by risk, not by audit schedules.
The Practical Starting Point
Start with three things:
First, name the risk controls for each deployed AI system. For every system you identified in GOVERN and MAP, write down the specific controls preventing known risks. A bias risk? Control is: measure demographic parity weekly and alert if variance exceeds threshold. A performance degradation risk? Control is: track accuracy metrics daily and flag if they drop more than 5% from baseline. Ambiguous controls don’t protect anything. Specific, measured controls do.
Second, establish monitoring baselines. Before you can detect that something’s gone wrong, you need to know what “normal” looks like. Run three months of monitoring data and establish ranges for your key metrics. That becomes your baseline. Deviations from baseline become alerts. Without baseline data, you’re flying blind.
Third, document one incident end-to-end. Take a real issue—maybe a bug, maybe unexpected behavior, maybe a complaint—and walk through your incident documentation process. Who was notified? How long did investigation take? What root causes were identified? What changes did you make? If that process takes 30 days and you have 10 deployed systems, you need it to work reliably. Documenting once in a controlled environment beats learning it under crisis. For organizations managing third-party AI across their stack, tools like Enclave-AI can help inventory what you have, document control requirements by system and risk level, and track monitoring metrics centrally. The goal is the same: every deployed AI system has named controls, baseline performance data, and a documented incident response path.
MANAGE isn’t where AI risk gets interesting. It’s where it gets controlled. Every control you establish is a failure mode you’ve planned for and won’t have to react to in crisis.
So here’s the question for you: Can you name every deployed AI system in your organization today and describe the specific controls preventing its top three risks?
If the answer takes longer than a few minutes or requires piecing together information from multiple teams, you’ve found your MANAGE gap. That’s where to start.
The next article in this series covers MEASURE: how to know whether your controls are actually working and your trustworthiness commitments are real.