AI incident response — the first 24 hours

Most AI-related incidents are discovered by accident. A partner sees an associate’s screen. An IT team notices unusual browser activity. A client asks a question that the staff member answers a little too confidently. And suddenly the firm has to decide what to do next, without having planned for it.

This is a practical checklist for that first day. It is not a substitute for legal advice — for anything at the notifiable-breach end, that is exactly the advice you need — but it is a framework for making the initial decisions well.

The first hour

Do not delete anything yet

The reflex is to have the staff member delete their conversation history immediately. Understandable, and almost always wrong.

The deletion does not un-transmit the data. What it does is destroy the only evidence you have of what was actually disclosed. If this later needs to be assessed as a notifiable breach, you will need to state what personal information was disclosed and about whom. Without the conversation history, you are relying on the staff member’s memory of what they pasted, possibly weeks earlier.

Preserve the record. Screenshot the conversation. Export it if the service allows. Then decide what to delete, when, and after consultation.

Do not confront the staff member alone

The staff member needs to be able to answer questions honestly. That is far more likely to happen in a conversation framed as “we need to work out what to do” than one framed as “you’re in trouble”. If the person feels this is a disciplinary matter first, they will minimise, hedge and disclose less — exactly the opposite of what you need.

Bring a second person if there is any prospect of this becoming an HR matter later. Take notes. Keep it factual.

Establish the basic facts

Before any external calls:

1. What service was used — the specific product, tier and account (personal or firm)
2. When it happened — dates and times as precisely as recallable
3. What was pasted — content, not just topic. If the source documents can be identified, do so
4. Whose information was involved — client(s), matter(s), and whether personal, sensitive or health information was included
5. Where the conversation history now sits — the account, and whether the person still has access
6. What the person did with the AI’s output — sent to a client, filed in a matter, discarded

These facts determine everything that follows. Get them straight before you make any decision about what to do about it.

The rest of the first day

Is this notifiable?

The Notifiable Data Breaches scheme applies when there has been unauthorised access to or disclosure of personal information, and a reasonable person would conclude the access or disclosure is likely to result in serious harm.

Not every AI disclosure meets this test. Some do not involve personal information at all. Some involve personal information whose disclosure would not reasonably cause serious harm. But the assessment must actually be made, and it must be defensible.

The scheme allows up to 30 days for assessment. Use that time properly — do not rush the assessment to feel like you’ve “handled it”.

Where the material clearly involves:

• Health information about identifiable individuals
• Financial information sufficient to enable identity theft or fraud
• Legal matter details of a sensitive nature (family, criminal, child protection)
• Information about vulnerable people
• Information whose disclosure could realistically enable harassment, stalking or coercive control

…the case for notifiability is stronger, and the assessment should reflect that.

Get legal advice, appropriate to scale

For any material that plausibly involves personal information at scale, sensitive information, or a client relationship where disclosure would be significant — take advice. Your professional indemnity insurer may also have views and may need to be notified early.

For smaller incidents involving low-sensitivity information, internal management may be adequate. Do not overreact; also do not under-react.

Client conversation, if it is required

If the disclosure affected client material and a reasonable client would want to know, tell them. Sooner is much better than later, both for the relationship and for any downstream regulatory or litigation dynamic. A client who learns from a data breach notification months later is a client relationship that does not survive.

The conversation is difficult. It is also less bad than any alternative, and firms that handle these conversations directly retain more client trust than firms that discover them.

Preserve, then decide about deletion

Once the record is preserved and the initial assessment is underway, you can decide about deletion. Some considerations:

• If the material may need to be produced in later proceedings, deletion may itself become a problem
• The provider’s retention policies may mean deletion by the user does not actually delete the data from their systems
• If the account was a personal account, the firm has no authority to delete from it
• Deletion by the staff member should be documented, if it occurs

The internal follow-through, by the end of the week

Understand how this happened

Not to punish, but to understand. This is essentially always a workflow and tooling failure, not a discipline failure. Ask:

• Was there a sanctioned AI tool available?
• If so, why was it not used in this case?
• If not, was the staff member trying to do work they were expected to do without the tools to do it safely?
• Was there any effective friction between the person and the disclosure?

The answer is usually some combination of “the sanctioned tool was slower, harder to reach, or did not exist”. That is not the individual’s fault to fix.

Change what needs changing

If the answer is “we did not have a sanctioned tool”, the response is to provide one. Continuing to prohibit and hope, after an incident has demonstrated the prohibition is ineffective, is not a response — it is a repetition.

If the answer is “the sanctioned tool was too hard to reach”, the response is to remove that friction. Single sign-on, saved sessions on mobile, actually usable interfaces. Whichever tool you sanction — enterprise cloud, on-premise, or a hybrid — it has to be the path of least resistance or the incident will repeat.

Consider whether the incident indicates a wider pattern

If one staff member did this, others probably have. That is not paranoia; it is how workplace behaviour usually works. Consider whether a broader amnesty conversation is warranted, without consequences attached, to understand the actual scope before the next incident.

What not to do, at any point

Do not conduct a witch hunt. It destroys the trust that lets staff tell you about future incidents, which is exactly the visibility you need.

Do not create a paper trail of the incident that would be worse than the underlying disclosure. Internal emails debating the seriousness of the breach in detail can themselves become discoverable material later. Keep the analysis structured and factual.

Do not tell the client “it was probably fine” if you have not actually done the assessment. Making commitments to a client on the basis of an unfinished analysis is how a manageable incident becomes an unmanageable one.

Do not brief the whole firm on the incident. Circulating a firm-wide “urgent reminder that our AI policy prohibits…” after an incident tells anyone who is paying attention that something has happened, and it invites uncomfortable questions from clients. Handle it at the necessary level of scope.

The prevention question

Every firm we speak with about AI incidents ends up at the same conclusion: they do not have a discipline problem, they have an infrastructure problem. Staff will use AI. They will use whatever is easiest. The only durable answer is to make the safe option also the easy option.

That is a design question about your tooling, not a message on the staff kitchen noticeboard. Firms that solve it stop having AI incidents. Firms that keep circulating memos have them again.