CERT-In's April 2022 directions predate ChatGPT's enterprise adoption curve by a matter of weeks. They were written with the incidents of that moment in mind — ransomware, data breaches, unauthorized network access — not "an employee pasted a customer list into a chatbot." That gap creates a real, practical question for anyone trying to comply: does a prompt-driven data exposure actually trigger the six-hour reporting clock?
We covered the rule itself in the glossary. This is the harder, more specific question: how do you classify an AI-related exposure against a list of incident categories that doesn't mention AI at all?
The categories are about outcome, not mechanism
CERT-In's published list of reportable incidents is organised around what happened to data and systems, not how it happened. "Unauthorised access to IT systems or data," "data breach," and "leakage of personal data" are all outcome-based categories — they don't specify network intrusion, insider threat, or misconfiguration as the required cause.
Read that way, a prompt that sends a database export or a set of customer records to a third-party AI provider is a data breach in the same outcome sense: personal or sensitive data has left the organisation's control and reached a party that wasn't supposed to have it. The fact that an employee typed it, rather than an attacker exfiltrating it, doesn't change what happened to the data — though it does change how you'd describe intent, and it's worth being precise about that distinction in any report you file.
Where the ambiguity actually lives
The genuinely unclear cases are narrower than "any AI usage." A single employee asking a public chatbot to summarise a document that happens to contain one customer's name is a different scale of event than a bulk export of a customer database pasted for analysis. CERT-In's directions don't give a bright-line threshold for "how much data, to how many people, counts."
In our experience the organisations that get this wrong in both directions exist: some report every minor incident and bury CERT-In (and their own team) in noise; others wait for certainty that never comes, because certainty about scope is exactly what the six-hour window doesn't allow time for. The more defensible default, in a genuinely ambiguous case, is to report with the information available and follow up as the picture clarifies — a preliminary report that gets updated reads far better in hindsight than a decision not to report that later looks like it was made to avoid the obligation.
Why the record has to already exist
The practical blocker isn't usually the judgment call — it's not having the information to make it. If nobody can say which AI tools were used, by whom, or what categories of data went where, there's no basis for even a preliminary report, and "we didn't know" is a materially worse position than "here's what we know so far."
This is what a per-decision audit trail is for: a record of which tool, which detected category, what action was taken, and when — assembled continuously, not reconstructed from browser history after someone asks. It doesn't need to contain the prompt itself; category, tool, and timestamp are enough to scope an incident and answer the Board's first questions.
A reasonable default
When in doubt about whether a specific AI-related exposure meets CERT-In's bar: treat scale and sensitivity as the deciding factors, not mechanism. A handful of email addresses in a single prompt is a different conversation than a customer database, an Aadhaar list, or source code under an NDA. Build the record before the ambiguous case arrives, because six hours is not enough time to build it after.
This is a practitioner's read, not legal advice — CERT-In's directions and their interpretation are ultimately a matter for your compliance and legal teams to confirm against the current guidance.