AI deployment — greenlight, expansion, retirement
Mission-critical risks demand board-level monitoring. Build the channel before you need it.
Note
Sectoral references — FINMA, Swissmedic, FDPIC, EU AI Act — should be verified against current guidance before reliance.
A credit-scoring model is proposed for deployment across Swiss retail loans. A triage algorithm is being expanded from one clinical pathway to four. A content-moderation system with customer-visible outputs is being re-trained on a new dataset. An internal document-review tool is being retired because a vendor is discontinuing it. Each of these is a board decision — at appropriate granularity — whenever the AI system materially intermediates outcomes the company is responsible for. The Marchand commentary frames the comparative doctrine; the Swiss transposition, through Art. 716a(1)(5) OR Oberaufsicht and the Art. 717 OR objective care standard, engages without a bad-faith gloss.
1. The duties that bear on this
Oversight reaches mission-critical AI. Where an AI system is mission-critical to the business — customer-facing, safety-critical, or financially consequential — board-level oversight is not a delegation to management. The content of oversight is the same as for any mission-critical operational risk: a defined owner, a cadence of substantive reporting, agreed KPIs, documented decisions, and minuted engagement.
The care standard calibrates to risk. Art. 717 OR measures the director against the standard of an orderly and conscientious manager for the company’s actual risk profile. A bank board overseeing an AI credit model is measured against what a competent director of a credit institution would know to ask. An internal summarisation tool is measured with less intensity. Calibration is the board’s, not the technology team’s.
Sectoral overlays apply in addition, not instead. FINMA supervisory expectations on AI governance, Swissmedic requirements for AI-integrated devices, FDPIC guidance on automated decision-making under the revised nDSG, and — for Swiss companies operating into the EU — the EU AI Act each layer on top of the corporate-duty framework. Where a sectoral requirement is engaged, it specifies what oversight must include at minimum.
2. The process
- Classify the deployment by risk. Customer-facing, safety-critical, financially consequential deployments go to the board or a delegated committee; lower-risk internal tools go to a standing working group.
- For higher-risk deployments, commission a written risk assessment covering intended use and boundaries; training data and data governance; performance monitoring and drift; failure modes and incident response; and third-party dependencies.
- Agree on deployment conditions: guardrails, human-in-the-loop for specified decisions, monitoring thresholds that trigger escalation, customer or regulator notification paths.
- Approve the deployment on a documented basis, with the conditions. Expansion of an existing deployment to new use cases or populations is a fresh approval, not a routine extension.
- Monitor. Regular reporting to the board or committee on the inventory, the performance of material deployments, incidents, and remediation status.
- Respond to drift and incidents. Thresholds that are hit should produce action; a threshold that is hit and ignored is worse evidentially than no threshold at all.
- Retire responsibly. Decommissioning produces continuity risks (customer migration, data preservation, audit trail) that are themselves a board matter.
3. Questions to ask management
- Exactly what is the model deployed for, and where are the use-case boundaries?
- Where are the guardrails — when does a human review, when does the system refuse, when does it fail safe?
- What data was this trained on, and is it representative of the population on which it will now be used?
- What monitoring is in place for drift, for bias, for degradation — and who decides when to act?
- What are the foreseeable failure modes, and what is our incident response for each?
- What third-party dependencies do we have, and what contractual protection do we have against vendor changes?
- How does this deployment interact with our data-protection obligations under the nDSG, and — if applicable — GDPR and the EU AI Act?
- What sectoral regulator has jurisdiction over this specific use (FINMA, Swissmedic, FDPIC), and what is their current expectation?
- What is our total inventory of AI deployments, and where does this one sit in it?
- If this system produced a material harm tomorrow — a mis-denied claim, a mis-triaged patient, a discriminatory pricing outcome — what is our incident-response plan and our exposure?
4. The record to leave
A written charter or policy that allocates responsibility for AI within the company; an up-to-date inventory of material deployments; the deployment-approval memo for each material deployment, with the risk assessment and conditions; periodic monitoring reports; the incident log; and — in the minutes — substantive board or committee engagement with the inventory, the material deployments, and any incidents of note. The AI Governance reference article treats the artefact set in detail.
5. Failure modes
The no-channel deployment. The company’s most important AI deployment has no board-level information channel. There is no committee that owns it, no periodic report, no minuted engagement. An incident occurs; the plaintiff pleads the oversight failure cleanly; the Marchand pattern applied to the Swiss setting produces exposure under Art. 716a(1)(5) and 717 OR.
Drift without action. The monitoring exists. It signalled declining performance for three quarters. Nobody with authority acted. When the resulting adverse outcomes surface, the existence of the monitoring is the aggravator, not the defence.
Scope creep without re-approval. A model approved for one use case is extended — at management’s discretion — to a materially different use case. The approval record shows the original scope; the deployment record shows the expanded use; the liability question is which oversight the board actually exercised over the expansion.
Cognitive register. AI deployment sits on a specific cognitive fault line. Automation bias (Parasuraman & Riley, 1997) is the systematic human tendency to over-trust outputs produced by machines — deciding with the model’s recommendation rather than against it — and the bias is stronger where the human is time-pressed or where the output is presented with confidence. Novelty bias amplifies this at the board level: new technology is assumed capable of more than it is, and its failure modes are under-imagined because they have not yet been seen. The five model-risk questions above — intended use, data governance, drift, failure modes, third-party dependency — are designed so that the board’s engagement with AI is concrete and sceptical rather than abstract and deferential. The objective is neither techno-enthusiasm nor reflexive distrust but calibrated trust, and the calibration requires the questions to be asked.