Deployment

Deployment is the moment of going live, and the practices that decide whether that is done safely: a monitoring plan, contingency measures, a phased rollout where the risk warrants it, trained users, and the approvals in place. It is one of the seventeen areas in the MindForge AI Risk Management Toolkit, the Singapore industry's practices for the AIRG. MindForge is the practices; the AIRG is the expectations and standards. I wrote the AIRG, and this guide sets out the practice and the expectation it meets.

What the AIRG expects

The AIRG expects a deliberate deployment step: residual risk inside the firm's appetite before go-live, and, for high-risk use cases, contingency plans with fallback options and, where kill-switches are used, activation protocols that are tested. The outcome it wants is that nothing material ships without the plan for when it goes wrong already in place. For how deployment fits the lifecycle, see the AIRG in practice.

What MindForge says to do

A monitoring and contingency plan, before go-live

Before a use case enters production, set out the risk-related metrics and thresholds to track, how often, and the escalation when a threshold is breached. For higher-materiality use cases, track near misses with lower warning thresholds so issues can be caught early. Define safeguards - rollback to a previous stable version, and kill-switches to deactivate while an issue is investigated - and test them before deployment, not after. Name an accountable person with the authority and capability to act on what monitoring finds, and fold AI incidents into existing incident-management processes.

A phased rollout where risk warrants it

Because AI outputs are probabilistic, a phased rollout - a pilot, parallel testing, or a canary deployment - limits exposure while performance is validated with real users and data. Keep the scope, features, user count and duration of each phase tightly limited, add extra monitoring, and set clear success and failure criteria, with failure triggering deactivation.

Trained users and completed approvals

Equip users before go-live: make them aware of the system's limits and their oversight responsibilities, especially where they act as the human in the loop. Then complete the existing pre-deployment controls - access, security, logging, documentation, retention - and obtain the required approvals, with AI-specific findings added to what the firm already records.

How banks do it

The MindForge Implementation Examples show firms setting contingency plans and fallbacks for their high-risk use cases before go-live, and using phased rollouts - pilots and limited releases - to validate generative AI tools with real users before widening access.

My take

The rule that matters is simple: the residual risk sits inside appetite before it ships. And a kill-switch you have never tested is a kill-switch you do not have.

Deployment is where good intentions meet a date, and the contingency plan is the first thing dropped under pressure. If it was never tested, it was never a plan. (From my book, AI Risk Management for Directors.)

Work with me

I train and advise financial institutions on deploying AI with the monitoring and contingency in place, as part of the wider AIRG programme. See the courses and workshops, read more on AI risk management, or get in touch.