Your AI Incident Plan Is Probably a Cybersecurity Plan. That Is the Problem.

•  01 / THE SYSTEM MAY WORK PERFECTLY

The system may work perfectly

The comforting story about technology failure begins with a defect. A bug corrupts the software. A hacker steals the password. A machine breaks its instructions and does something strange.

AI often produces a less cinematic problem. The system follows its instructions, but the instructions were inadequate. It uses authorised data in a context nobody examined.. It gives a plausible answer that a rushed employee treats as a reliable one. An agent acts within its technical permissions and outside the organisation’s actual intent.

This is why we cannot treat an AI incident as merely a cybersecurity event.

An AI incident does not need an attacker

The OECD defines an AI incident broadly: an event, circumstance or series of events in which the development, use or malfunction of one or more AI systems directly or indirectly causes harm. That harm may affect health, critical infrastructure, human rights, property, communities or the environment. The definition covers more than hostile attacks. It can include overreliance, human error, wrongful use, a system’s failure to act and an AI system contributing to harm without being its sole cause.

India’s AI Governance Guidelines adopt this wider view. They recommend a national system for collecting evidence about AI harms, an India-specific risk framework and safeguards for sensitive sectors. The guidelines treat incident reporting as a way to learn what AI is doing in the world, not merely as a channel for announcing that somebody breached a network.

“A cyber plan asks whether someone compromised the system. An AI incident plan must also ask what the system did while operating normally.”

•  02 / REPORTING STARTS BEFORE REPORTING

Reporting starts before reporting

The phrase ‘incident reporting’ makes the work sound administrative. Something happens; somebody completes a form; the organisation returns to normal. The form is the final visible object. The real work begins much earlier.

To report an incident, an organisation must first know which AI systems it uses. It must know who owns them, what they can access, which model and version were active, which data entered the system, what output or action followed and whether a person intervened. It must preserve that evidence long enough to reconstruct the event.

This is why an AI incident cannot be reduced to a cybersecurity event.

Can you trace the decision?

An investigation must connect the technical event to the organisational consequence.

“If an AI-enabled workflow caused harm at 3pm today, could the organisation identify the system owner, model provider, affected process and decision trail by 4pm?”

•  03 / SIX HOURS IS AN OPERATING TEST

Six hours is an operating test

CERT-In’s six-hour requirement applies to the cyber incidents listed in its directions. But the window offers a useful test of organisational reality. Six hours is long enough to write a policy. It is not long enough to invent ownership.

Within the first few hours, an organisation should be able to answer at least these questions:

This is why an AI incident cannot be reduced to a cybersecurity event.

The first six hours

You do not need every answer before reporting. You need evidence, authority and an honest first account.

The six-hour CERT-In window does not apply automatically to every AI failure. It is used here as a test of operational readiness.

This is not a checklist for producing certainty. It is a method for preventing confusion from becoming evidence loss.

• 04 / SOMEONE MUST BE ALLOWED TO SAY STOP

Someone must be allowed to say stop

Most AI governance diagrams are generous with committees. They are less precise about verbs. Someone must have the authority to suspend the system, revoke an agent’s credentials and halt a customer-facing workflow.

A usable incident model needs clearly separated roles: the detector, the incident commander, the system owner, the technical owner, legal/privacy/compliance, communications, an authorised executive, and an independent reviewer.

“A kill switch that requires six approvals, a vendor call and a meeting of the risk committee is not a control. It is a decorative button.”

Who is allowed to do what?

• 05 / LOGS ARE ORGANISATIONAL MEMORY

Logs are organisational memory

After an AI incident, people remember intentions. Logs remember actions. Yet AI evidence is unusually fragile. The model may change between the event and the investigation. A provider may update a system without exposing the exact revision.

For consequential AI workflows, evidence should connect: the user or agent identity, the request or triggering event, relevant input data, the model version and configuration, the generated output, any tools the system called, human reviews or overrides, and the final business action.

Can you reconstruct the decision?

The OECD’s common framework includes 29 criteria across incident metadata, harm, affected people, economic context, data, model characteristics, task, autonomy and mitigation.

• 06 / YOUR VENDOR CANNOT CARRY YOUR CONFUSION

Your vendor cannot carry your confusion

When a third-party AI system causes harm, the first organisational instinct is often contractual: ask the vendor to investigate. That is necessary. It is not a response plan.

Contracts and operating procedures should establish: notification speed, log provision, evidence preservation, regulatory reporting leadership, suspension rights, subcontractor investigation access, and post-termination support.

Vendor responsibility split-screen

The vendor understands the model. The organisation understands the consequence. A credible investigation needs both.

“An organisation can outsource a model without outsourcing its knowledge of the workflow or its responsibility to act.”

• 07 / COMMUNICATION IS PART OF CONTAINMENT

Communication is part of containment

Incident communication is often treated as work that begins after technical teams establish the facts. In fast-moving AI incidents, that separation is artificial.

How to communicate before certainty

Affected people do not need a seminar on transformer architecture. They need to know what happened, how it may affect them, what the organisation has done and what they should do next.

• 08 / RUN THE FAILURE BEFORE IT RUNS YOU

Run the failure before it runs you

The best time to test an AI incident plan is when the incident is fictional. Choose one consequential workflow. Introduce a plausible signal. Then run six hours on the clock.

The exercise should produce changes, not applause. At minimum, the organisation should leave with: a definition of an AI incident, an inventory linking systems to owners, a documented route for raising suspected harm, named authority to contain and restore, evidence requirements, vendor clauses, short templates for notifications, and a review process.

Could you manage an AI incident today?

If three or more answers are “no”, the organisation has an AI policy – not an AI incident capability.

• 09 / THE FORM IS NOT THE PLAN

The form is not the plan

India’s reported move towards tighter AI incident reporting should not trigger a frantic search for a new compliance template. No final template exists. That is not the urgent gap.

The urgent gap is organisational memory before the event, authority during it and honesty afterwards.

“The warning has arrived before the rulebook. That is useful.”

---