Incident Classification for AI Failures

The war room was a WhatsApp group named AI Issues. On Monday the agent cited a repealed circular. On Tuesday it sent a student the wrong exam date. On Wednesday a connector wrote twenty sanction flags that finance had not approved. All three were logged as medium because that was the default in the integrator's ticket tool. The CIO only learned that Wednesday was different when treasury called. Severity had been a dropdown, not a decision.

This is a classification framework for AI failures in Indian departments, PSUs and universities. It is not a new CERT-In circular. CERT-In has not, as of this writing, published a special taxonomy titled for agentic AI that replaces the 28 April 2022 directions. Do not invent one in your file. Use CERT-In where a listed cyber incident applies. Use this framework for the rest so you page the right human and tell the truth in the note.

It is not legal advice. Breach-notification clocks under DPDP, once the operational duties apply, and any sector regulator's incident rules still have to be read in the original. This article stops you from treating every fluent mistake as the same event.

Classify harm, not embarrassment

Offices under-classify incidents that are reversible but public, and over-classify incidents that are merely embarrassing. A Hindi typo on a helpdesk answer is not a Sev-1 because a minister saw it. A silent write to a payment file is a Sev-1 even if nobody outside the building knows yet.

Three axes are enough. Harm: what class of person or public function was touched — money, marks, liberty-adjacent action, personal data, safety, mere convenience. Reversibility: can you unwind it with a keystroke, a corrigendum, a recall, or only with a court or a re-exam. Containment: is the artefact still inside systems you control.

Model mood is not an axis. 'The model was confused' is a cause hypothesis. It is not a severity. Write the harm first. Then write the cause.

A severity table you can adopt this month

Adjust the names to match your existing IT incident policy so you do not run two taxonomies. The content matters more than the labels. What you must not do is let the vendor's SaaS severity — usually about uptime — classify a wrongful sanction as a P3 because the API was up.

If an event sits in two rows, take the worse one. A leaked question paper that is also a personal-data incident is not averaged into medium.

Draft severities for departmental agents. Map them onto your existing incident policy. Do not invent a CERT-In 'AI Sev' code.

Class	Examples	Who is paged	First containment
S1 — irreversible or mass harm	Wrongful pay / deny at scale; exam paper leak; safety instruction that could injure; mass personal-data export	CIO, CISO, business owner, DPO, competent authority	Disable write tools and send paths. Preserve logs. Do not 'fix forward' by deleting traces.
S2 — limited official harm, still inside estate	Wrong sanction on a handful of cases still reversible; wrong eligibility flag not yet paid; corrupted corpus chunk	Business owner, CISO, platform admin	Freeze the workflow. Reverse if the system of record allows. Hash the model and prompt.
S3 — wrong official speech, reversible	Bad citation; wrong date in a draft; rude or off-policy reply not yet sent	Workflow owner, content owner	Stop send if in flight. Correct the corpus or prompt. Note the case ids.
S4 — availability and hygiene	Queue stuck; GPU down; login failures; stale index	Platform admin	Fail closed to human desks. No unofficial workaround on public chatbots.
Cross-cut — cyber as already listed	Compromise of the agent host, ransomware, specified CERT-In events	CISO / CERT coordination as your policy already says	Follow CERT-In directions and your cyber runbook. Do not invent a parallel clock.

CERT-In and DPDP are not your internal taxonomy

The 28 April 2022 CERT-In directions require reporting of specified cyber incidents within stated clocks and retention of specified logs for 180 days in Indian jurisdiction. Some AI failures will be cyber incidents — a compromised agent host, a stolen key, a ransomware event on the RAG store. Those already have a path. A hallucinated scheme name, by itself, is usually not a CERT-In event. Do not file a decorative CERT-In report to look diligent. Do not skip a real one because 'it was just the model'.

DPDP will care when personal data is processed in a way you cannot defend, or when a personal-data breach duty is triggered once those operational provisions apply. MeitY notified the Act and Rules on 13 November 2025; most remaining operational duties apply from 13 May 2027. Read the live text for clocks and thresholds. Do not let a vendor paraphrase them on a slide.

The India AI Governance Guidelines of 5 November 2025 may urge incident readiness. They do not give you a statutory severity ladder. Your signed internal policy does.

Evidence you must freeze

Every class above S4 should freeze the same bundle: model hash, prompt hash, retrieval-set identifiers, tool calls, officer token or its absence, input artefact, output artefact, and the time the workflow was disabled. If you 'fix forward' by hot-editing the prompt and deleting the bad traces, you have destroyed the incident.

Conversation logs without those bindings are diaries. CERT-In already told you logs matter. Your auditor will tell you bindings matter.

Name the person who may declare the incident closed. It should not be the SI who caused it and it should not be the model vendor's account manager.

• S1/S2: write tools disabled until a named officer re-enables them in writing.
• Personal-data suspected: DPO in the first hour, not as a courtesy copy on day three.
• Exam or tender artefacts: isolation of the vault, not a polite email to faculty.
• Public mis-statement already sent: corrigendum path with the same owner who would correct a human circular.

What not to put in the severity policy

Do not put model brand names. Do not put a claim that open weights reduce severity. Do not put a sentence that DPIIT recognition changes the clock. Do not put invented penalty percentages. Do not copy a US NIST playbook's numbering and pretend it is an Indian circular.

Do put the phone tree, the disable path, and the rule that unofficial public chatbots are not an approved workaround when the official agent is down. Availability incidents that spill into shadow AI are how S4 becomes a leak.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.

We already have an IT incident policy.

Good. Add the AI rows. Uptime severity will mis-grade a wrongful write. If you refuse to add rows, at least add one sentence: unexpected writes and data leaving the estate are never graded by uptime.

The vendor's SOC will classify for us.

The vendor can propose. You own the class. A vendor SOC optimises for their SLA, not for your treasury.

If we write S1 too broadly we will be in war rooms forever.

Then write S1 tightly around irreversible harm, mass personal-data export, exam and safety. Do not make S1 mean 'the secretary is upset'.

Reporting to CERT-In will make us look incompetent.

If the event is a specified cyber incident, you already have a duty. Looking competent is not the test. Follow the live direction. For non-cyber AI failures, do not invent a CERT-In filing.

A 14-day classification addendum

Attach this to the existing incident policy. Do not start a new manual that only the AI team has read.

1. Days 1–3: list the agent's write paths, send paths and corpora. Those are your S1/S2 candidates.
2. Days 4–7: draft the five-row table, phone tree and disable path. Name the closer for each class.
3. Days 8–10: table-top one S1 write, one sent-wrong S3, and one outage that must not spill into shadow AI.
4. Days 11–14: competent authority signs the addendum. Put the table in the SOC and the section WhatsApp is not the war room.

How this shows up in the file

The signed addendum, the table-top minutes, and the disable runbook belong in the AI register. When an incident happens, the file gets the frozen bundle and the class you actually used, not the class you wish you had used.

If the first real incident is classified in a WhatsApp group, your framework does not exist.

This article is informational field guidance for Indian public institutions, not legal, procurement, security-accreditation, academic-regulation or engineering advice. Confirm against the current Gazette, DPDP text and Rules, CERT-In direction, India AI Governance Guidelines, UGC/AICTE/NAAC notices, NEP documents, GFR, departmental manual and your counsel before you file it. Guidelines are not statute. Circulars move.