An AI incident is not limited to a model going offline. Harmful output, unauthorized action, sensitive-data exposure or a pattern of unreliable decisions can require coordinated response across the business, technology, risk and control functions.
Preparation defines what counts and who responds
The bank defines event and incident criteria according to the use case's materiality and possible customer, compliance, financial, operational and security effects. Not every incorrect output becomes a major incident, but recurring or high-impact behavior should not be dismissed as ordinary model noise.
Inventories identify the use case, owner, model or service version, data, prompts, tools, users, providers and downstream processes. Response plans assign decision rights and connect business, model-risk, technology, security, legal, compliance, privacy, communications and customer-service responsibilities before time pressure arrives.
Detection can come from systems or people
Monitoring may reveal an unusual performance change, prohibited output, unauthorized tool use, data leakage or a breakdown in a human-review control. Complaints, employee escalation, overrides, audit findings and provider notices can be equally important signals.
Triage confirms the affected use, time period, population and decisions while assessing whether activity is continuing. The team records what is known and uncertain, prioritizes actual or plausible harm and avoids assuming that a fluent output or normal availability means the system is operating safely.
Containment limits harm without erasing evidence
Depending on the event, the bank can pause the use case, remove a tool connection, restrict a feature, revoke access, block a model or provider version, require additional human approval or move the process to an approved fallback. The response should be proportionate because abruptly stopping a critical service can create a different customer or operational risk.
Teams preserve relevant versions, logs, inputs, outputs, approvals and system context under applicable privacy and recordkeeping controls. They also identify urgent customer protection, transaction, notification or reporting steps rather than waiting for a perfect root-cause conclusion.
Investigation reconstructs the decision path
Investigators compare the incident with the approved design and determine whether data, prompts, retrieval sources, code, model behavior, user actions, access, monitoring or a third-party change contributed. They distinguish the triggering event from deeper control weaknesses and check for similar exposure in related uses.
A proposed correction is tested against the failure and representative normal activity. Material model or system changes follow validation, security review and change approval, and a controlled return to service includes heightened monitoring, rollback criteria and confirmation that the fallback can be retired safely.
Recovery includes customers and lasting control improvement
The bank reviews affected decisions, transactions and communications and corrects or remediates them when required. Clear records support customer explanation, management and board reporting, regulatory obligations and accountability across any service-provider relationship.
Closure requires evidence that immediate harm is addressed and the durable actions operate as intended. Lessons can change test cases, thresholds, training, contracts, data controls, escalation rules and use-case limits; a restored system alone does not prove that the incident has been resolved.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.