AI Incident Response for Banking: What Counts as an AI Incident, RBI 6-Hour Notification, and the 5-Stage Response Process

Banks have mature incident response for IT and cybersecurity: a SIEM flags an anomaly, a playbook activates, a team assembles, regulators get notified. That process works because IT incidents are detectable — they throw off signals in infrastructure monitoring that a trained team can catch. AI incidents break that assumption in the most dangerous way possible: the most consequential failures often produce zero infrastructure signal at all. A credit model that has drifted toward systematically lower approvals for a protected demographic keeps serving requests at normal latency the entire time. An LLM that's been successfully prompt-injected keeps processing queries — it just produces the outputs the attacker wanted. A fraud model adversarially manipulated to suppress alerts on specific transaction patterns keeps running — it just stops catching the fraud it was built to catch.

That's the failure mode that actually ends careers, in my experience — not the obvious outage that pages everyone at 2am, but the quiet one that runs for weeks looking completely normal on every dashboard anyone's watching. Extending incident response to AI needs a different detection philosophy, a wider definition of what counts as an incident, and a governance process built for AI's specific containment and remediation paths.

AI incident severity tiers

Severity 1 — active customer harm with regulatory exposure. A model systematically harming a protected class; a security breach exposing customer data; agentic AI taking unauthorized financial actions; prompt injection triggering fraudulent transactions; AI-generated regulatory misinformation delivered to customers at scale. This tier requires immediate regulatory notification and model suspension pending investigation.

Severity 1 — performance failure on a critical use case. Fraud detection accuracy dropping below a defined minimum; a credit model producing decisions inconsistent with credit policy at scale; AML monitoring degrading enough to create filing exposure. Escalate immediately to the CRO and model risk committee, with temporary fallback to manual decisioning or a prior model version as a live option, not a theoretical one.

Severity 2 — detectable drift with potential for harm. Fairness metrics degrading below threshold with no confirmed adverse action yet; performance trending toward a breach; LLM behavioral inconsistency on regulated use cases; a vendor model change deployed without the advance notice the bank's contract requires. Escalate to the committee with a re-validation assessment due within 5 business days.

Severity 2 — AI security event with no confirmed data exposure. A confirmed prompt injection attempt blocked by guardrails but still requiring investigation; a jailbreak attempt; a pattern suggesting systematic probing of model behavior. Investigate without necessarily suspending the model, as long as the guardrails are confirmed effective — but intensify monitoring regardless.

Severity 3 — monitoring threshold breach with no confirmed harm. A single metric breaching threshold but within the validation-acceptable range; a fairness metric movement needing investigation but no confirmed disparate impact; a vendor notification of a change still inside its contractual notice window. Investigate and plan re-validation within 10 business days — this tier is about catching drift before it becomes a Severity 2.

Severity 3 — documentation or process gap. A system running without current validation documentation, past its scheduled re-validation date, or with an expired committee approval nobody renewed. No immediate customer harm, but real regulatory exposure if it surfaces during examination rather than through the bank's own process first.

The 5-stage AI incident response process

1. Detection and initial triage (0-2 hours). AI incidents surface through automated monitoring alerts, unusual customer complaint patterns, external reports (security researchers, regulators, media), or internal observation. Triage has to answer fast: which system, what behavior, is there active harm, is containment urgent, and what's the initial severity call? The on-call AI incident owner or model risk team closes this stage with a severity classification and a ticket carrying the first facts — not a full investigation.

2. Containment decision (2-6 hours for Severity 1). The incident commander — CRO, Head of Model Risk, or a designated lead — chooses: suspend the model and fall back, filter known adversarial input patterns while investigating, hold adverse outputs pending review, or continue serving with enhanced monitoring. Document who authorized the decision, the rationale, and the fallback plan; for vendor AI incidents, invoke the vendor's contractual incident notification clause and require a response within a defined window. Lower-severity incidents get an investigation plan and timeline instead of an immediate containment call.

3. Regulatory notification, on whatever timeline actually applies. A confirmed AI security incident — adversarial attack, data breach through an AI system — falls under RBI's cyber security reporting expectations and CERT-In's 2022 directions, both of which call for prompt reporting generally within a short window, commonly cited as 6 hours from detection. These timelines run independently of each other, so a single incident can trigger several parallel notifications at once — and the person managing regulatory communication should never be the same person running the investigation; splitting that role is one of the cheapest process fixes available.

4. Root cause analysis (2-7 days for Severity 1). AI root cause analysis has to isolate which of five things actually happened: a data quality issue (input distribution shifted), an architecture issue (the model generalized badly to production), an adversarial attack, an environment issue (behavior diverged from the validation environment), or an unexpected interaction outside the model's validated scope. Each maps to a different remediation path, and the finding has to be specific enough for the committee to act on — "the model drifted" tells nobody anything; "the model's performance on thin-file applicants degraded because the training distribution underrepresented them and the monitoring threshold was set too loosely" tells the committee exactly what to fix.

5. Remediation, validation, and return to production. The remediation path follows the root cause: a scoped patch, a full retrain with fairness retesting, a full replacement with parallel run, or security hardening with adversarial retesting. Returning a suspended model to production needs committee approval, not a technical sign-off alone — documenting the root cause as confirmed resolved, the fix tested, new monitoring thresholds set to catch recurrence, a customer remediation plan if customers were harmed, and regulatory communication completed. The full record — detection through return-to-production — goes into the audit trail as one connected chain, not five separate documents that have to be reassembled later.

Regulatory notification requirements

India-specific incident types with no international equivalent

A proxy variable fairness incident is a fairness incident regardless of model intent. If an AI system produces outcomes disproportionately harming customers along caste, religion, language, or disability proxy lines, that's a fairness incident whether or not the model ever used a protected attribute directly. Catching it requires continuous India proxy variable monitoring in production — without it, the incident accumulates silently until an examiner or a journalist finds it instead.

A PMJDY population exclusion incident deserves its own internal threshold. If monitoring shows an AI credit system systematically declining PMJDY-enrolled customers at a rate creating a financial inclusion gap, treat it as a High severity incident, especially against a stated inclusion commitment. PMJDY enrollment isn't a protected attribute in the legal sense, but examiners treat systematic exclusion of this population as a real governance finding — set an internal trigger threshold now, rather than waiting for an examiner to find the gap first.

What to fix in the incident response process now

1. Separate the regulatory notification owner from the incident commander role in your playbook — don't let one person do both under pressure.
2. Set explicit internal notification-timeline targets for performance/fairness incidents and get board sign-off, rather than citing an unconfirmed regulatory deadline.
3. Build continuous India proxy variable monitoring so a fairness incident surfaces from your own systems, not from an examiner's.
4. Define an internal PMJDY exclusion threshold that triggers automatic incident review.
5. Confirm current DPDP Rules status with counsel before quoting a specific breach-notification hour count to anyone, internally or externally.

Zytra monitors production AI systems for performance drift, fairness degradation, and behavioral anomalies — generating incident tickets automatically with severity classification, notification timeline tracking, and audit trail generation from detection through resolution. Request a demo to see the complete incident log an examiner would actually receive.