Your AI Will Fail. The Question Is Whether Anyone Notices
AI incident response is not a technology recovery task — it is a control that decides whether a model failure stays a near-miss or becomes a reportable event.
Most AI failures in regulated firms are not dramatic. They are silent — a model quietly stops flagging what it used to flag, and onboarding carries on regardless. The firms that stay out of trouble are not the ones whose AI never fails. They are the ones that notice.
Every firm now plans for the AI that works. Fewer plan for the times it does not. In Jersey financial services, where the same compact set of firms carries a disproportionate share of the world's cross-border structuring, an unnoticed model failure is not an IT inconvenience — it is a weakened control that keeps running as if nothing has changed.
The JFSC's July 2026 guidance is explicit that firms remain accountable for AI outcomes exactly as they are for any other technology, and it names the failure modes that matter. This piece is about the discipline that sits between a model degrading and a regulator asking why nobody caught it: AI incident response, and the near-miss register that makes it real.
The failure that looks like success
The JFSC guidance describes a fraud-detection model that degrades over time and goes unnoticed until a significant incident occurs. This is the failure pattern I return to most often, because it runs counter to the instinct every operations team has: to watch for the alert. A model that has drifted does not raise an alarm. It produces fewer alerts, the queue looks healthier, and everyone congratulates the tool for making the team more efficient — right up until the case that should have been stopped was not.
An AI incident is not always an outage. It is any moment the model's real-world behaviour diverges from the behaviour the firm's controls assume. That includes a third-party tool going dark, but it also includes silent drift, a prompt-injection attempt that alters an output, and an output that is confidently fabricated. Treating only the visible outage as an incident is how the failures that matter most go unaddressed.
Three failure modes the regulator has already named
The guidance does not leave firms to imagine what could go wrong. It sets out illustrative scenarios, and three of them are incident patterns a Jersey firm can plan against today.
1. The dependency that fails quietly
The guidance describes a third-party onboarding tool that goes down, red flags stop surfacing, and onboarding continues anyway — a weakened AML control and a resilience gap in one event. The lesson is that a failure in a system you do not own is still your incident.
2. The model that drifts
The fraud-detection scenario: performance degrades gradually, detection thresholds are never revisited, and the gap only becomes visible through the incident it should have prevented. Drift is not an edge case — it is the default behaviour of any model whose world keeps changing while its training does not.
3. The output that is confidently wrong
The guidance warns that generative tools can fabricate content and that staff must be trained to spot it, particularly in regulatory reporting where the firm remains responsible for accuracy regardless of how the report was produced. A fabricated figure that clears review is an incident whether or not anyone files it.
The near-miss register: the instrument almost no firm keeps
Regulated firms already keep incident logs. What they rarely keep is a near-miss register for AI — the record of the failures that were caught before they became events. This is the single highest-value control I recommend, because near-misses are the only early-warning data a firm gets for free, and most firms throw it away by never writing it down.
A near-miss register is not the same as the AI register the JFSC expects firms to maintain. The AI register catalogues what the firm uses; the near-miss register catalogues how it has nearly gone wrong. Table 1 is the instrument I would put in front of an operations lead this week.
Table 1 — AI near-miss register: the fields that turn a caught error into an early-warning signal.
| Field | What it captures | Why it matters |
|---|---|---|
| Use case & tier | The workflow and its materiality tier | Links the near-miss to the firm's own risk classification |
| What was caught | The output or behaviour that was wrong | Distinguishes drift, fabrication, outage, injection |
| How it was caught | Human review, threshold alert, chance | Reveals whether the control worked or luck did |
| Detection lag | Time between failure and detection | The metric that predicts the next real incident |
| Action taken | Recalibration, fallback, retraining | Creates the audit trail of proportionate response |
The detection-lag column is the one that earns its place. A register full of near-misses caught instantly is reassuring; a register where the lag is creeping upward is the clearest leading indicator of an incident a firm will ever get — and it costs nothing but the discipline to record it.
An incident plan proportionate to materiality
The JFSC guidance is risk-based throughout: it asks for proportionate measures for material use cases, not uniform heavyweight process for everything. An AI incident plan should inherit that proportionality directly from the materiality tier of the use case involved.
For a low-impact use case, the response can be lightweight: log it, review it at the periodic cadence, move on. For a higher-impact or material use case — anything touching AML onboarding, sanctions screening, or regulatory reporting — the guidance points to explicit fallback and manual override, and to a competent person remaining responsible for high-impact or unusual cases. The incident plan is where those clauses stop being policy language and become a sequence someone can actually run at four o'clock on a Friday.
The test I apply is simple: for every material AI use case, can the firm name the person who is paged, the manual process that takes over, and the threshold that triggers both? If any of the three is missing, the firm does not have an incident plan. It has an intention.
Prompt injection and poisoning: the incidents nobody logs
The JFSC guidance names two AI-specific threats that most firms have no incident category for: prompt injection, where crafted input manipulates a model into behaving against its instructions, and data poisoning, where the data a model learns from is corrupted to skew its outputs. It also warns of attempts to extract confidential information from AI outputs. These are not hypothetical — they are named in the guidance precisely because they are foreseeable.
What makes them difficult to catch is that they do not look like outages. A successfully injected prompt produces a confident, well-formed, wrong output; a poisoned model performs normally until the corrupted pattern is triggered. The guidance's answer is to fold AI into existing cyber and incident-response processes rather than treating it as a separate silo — which means a firm's security incident playbook needs AI failure modes written into it, not bolted alongside. An incident response plan that covers the server going down but not the model being manipulated is protecting against the failure that is easiest to see, not the one most likely to be exploited.
Why this is a board question, not an IT one
It is tempting to file AI incident response under technology resilience and hand it to the people who run the systems. That is a mistake. The JFSC places accountability for AI outcomes with boards and senior managers, and an AI incident is, by definition, a control failure — which is a governance event before it is a technical one.
The board does not need to understand the model. It needs to see the near-miss register, watch the detection-lag trend, and ask the one question that a technology team cannot answer on the firm's behalf: if this control failed silently today, how long before we knew? A board that can answer that has AI incident response. A board that assumes the tool would tell them does not.
For every material AI use case in your firm, can you name the person who gets paged, the process that takes over, and the moment you would know it had failed — or are you trusting the model to raise its own alarm?
Next in the series: governing the AI you do not own — what happens when the model failing is inside your vendor's product, not yours.
Sources: JFSC, Guidance on the use of AI in Jersey's financial services sector (July 2026) — Principle 2 (cybersecurity, incident response, third-party outsourcing), Principle 3 (regulatory reporting accuracy), and illustrative scenarios on third-party outage and model drift; Government of Jersey et al., Jersey AI Playbook (2026).
Professional disclaimer: The views expressed are my own and are shared for general informational purposes. This content is intentionally non-confidential and does not include proprietary, client-specific, or employer-sensitive information. It is not legal, regulatory, investment, or professional advice; readers should seek appropriate advice for their circumstances.
Financial services leader (20+ years) | Lean Six Sigma Green Belt | London School of Economics (LSE) AI Leadership Accelerator
See where your firm stands
The free diagnostic scores your firm across the twelve operating-model instruments in about eight minutes.
Take the diagnostic →A version of this article was first published on LinkedIn as part of the Sequence body of work. This is the canonical version.
The views expressed are the author's own and shared for general information. This content is intentionally non-confidential and does not include proprietary, client-specific or employer-sensitive information. It is not legal, regulatory, investment or professional advice. © 2026 Paul Soares. Sequence is the trading name of Sequence Advisory Limited (in formation) · hello@sequenceadvisory.com