Getting the technical response right and getting the communication right are two separate problems, and a well-handled incident can still turn into a lasting trust problem if the second one goes badly. This guide is for the specific task of communicating about an AI security incident, internally and, where warranted, externally, once something has happened that involves an AI agent or system behaving in a way it shouldn't have. It's written for whoever owns incident communication, often a mix of engineering leadership, legal, and comms, working alongside whoever is running the technical response. The sequence below moves from the first internal notification through to a final account once the investigation is actually closed, and skipping steps in between tends to produce either premature over-sharing or a damaging silence that looks like it was hiding something.
Get the right people informed internally, first
The first communication should go to whoever needs to act immediately: the technical responders, relevant engineering leadership, and legal or privacy if there's any chance of data exposure. This isn't the moment for a wide company-wide announcement or a polished summary; it's a factual, brief notice that something is being actively investigated, what's known so far, and who's leading it. Broader internal stakeholders, other teams, executives without a direct role, can get a later summary once there's more than a suspicion to report. Speculating about root cause or scope in this first message, before the audit trail has actually confirmed anything, tends to spread an inaccurate version of events that's hard to walk back later.
Loop in legal and privacy before any external statement
If there's a real possibility of data exposure, a regulatory notification trigger, or contractual notice obligations, legal and privacy need to be involved before anyone drafts anything meant for outside the company, not after a draft already exists. This isn't about slowing things down for its own sake; it's about making sure the specific wording, the specific claims, and the specific timing of an external statement don't create legal exposure or box in a later, more accurate correction. Even if external communication ultimately isn't needed, this check should happen deliberately rather than get skipped because the incident initially looked contained.
Be precise about what's confirmed versus what's still under investigation
Every statement made during an active investigation should draw a clear line between what the audit trail and investigation have actually confirmed and what's still being worked out. Overstating certainty early, claiming a full picture before the investigation has actually reached one, creates a real risk of having to walk back a claim later, which damages credibility more than an honest "we're still confirming this" would have. At the same time, avoid language that sounds more alarming than the confirmed facts warrant; an unconfirmed possibility described with dramatic certainty causes unnecessary anxiety on both sides of the conversation.
Tailor the message to each audience
A single message rarely serves every audience well. Customers generally need to know what happened to their data or their experience specifically, what's being done about it, and what they should do if anything. Regulators, where notification is required, need a level of factual and procedural detail that customer-facing language usually doesn't include. Internal stakeholders outside the response team need enough context to answer questions from their own teams without needing the full technical detail. Engineering teams elsewhere in the organization often need the technical mechanism specifically, since a similar gap might exist in a system they own. Drafting one message and reusing it everywhere tends to either overwhelm one audience or underserve another.
Follow up with a final, confirmed account
The initial communication, by necessity, is partial. Once the investigation actually closes, follow up with each relevant audience with a final account that reflects what was actually confirmed, including anything that turned out different from the initial understanding. Leaving the first, partial statement as the last word on record, even when it turns out to have been roughly accurate, misses the chance to demonstrate that the investigation was thorough and that the organization follows through, and it leaves an inaccurate detail uncorrected if the early read turned out to be wrong in some respect.
Where TELEON fits
TELEON's audit trail, available through the gateway or supported middleware, is what turns "what we think happened" into "what we can confirm happened," giving the team drafting communication something to point to instead of relying on impressions from whoever first noticed the incident. That distinction between confirmed and speculative is one of the more useful things a reliable record provides during a fast-moving incident.
The actual drafting, audience judgment, legal coordination, and decision about what to disclose and when remain work for the team responsible for the incident. TELEON's record supports accuracy in that communication; it doesn't decide what should be said or to whom.
A short checklist
- Notify the immediate response team and relevant leadership first, factually and briefly.
- Involve legal and privacy before drafting anything for outside the company.
- Separate confirmed facts from open questions in every statement.
- Tailor depth and framing to each specific audience.
- Close with a final, confirmed account once the investigation wraps up.
One thing that's easy to overlook is that communication quality gets judged over the whole arc of an incident, not just the first message. An organization that stays quiet after an accurate but partial first statement, and never circles back with the full picture, often leaves a worse impression than one that communicated imperfectly but consistently followed up as more became known.