Private AI for crisis communications drafting
A crisis statement goes through several drafts before it's approved, and every one of those drafts says things the company hasn't decided to say yet. That's what makes the drafting process itself sensitive, independent of what the final statement ends up being.
What a draft holding statement actually contains
Comms teams often draft a holding statement, or several versions of one, before all the facts of an incident are confirmed: a data breach, a product recall, an executive departure, an accident at a facility. Early drafts tend to include speculation about scope and cause, internal assessments of how bad the situation might be, and language the legal team hasn't cleared yet. If an early draft describing a breach as "affecting an estimated 40,000 accounts, likely including payment data" leaked before the confirmed number was public, that's a worse outcome for the company than the incident itself, because it looks like the company knew more, sooner, than it disclosed.
Using AI to speed up that drafting, working through tone, structure, or a first pass at a statement under time pressure, is a legitimate use of the technology. Crisis response is exactly the kind of high-pressure writing task where a fast first draft helps. The question is where that draft text goes while it's being written.
What changes when drafting happens on your own hardware
Sending a crisis draft to a third-party AI API means the company's unreleased, unapproved characterization of its own crisis sits on a vendor's infrastructure, under that vendor's retention terms, at the exact moment the company has the least control over the narrative. Running the drafting model on a dedicated DGX Spark instead keeps every draft, from the first rough pass to the version legal signs off on, inside infrastructure the company controls. Nothing about the incident touches an external server until the company itself decides to publish it.
In practice that's Open WebUI as a drafting interface the comms lead uses directly, iterating on tone and structure the same way they would with any drafting tool, except the text never leaves the building.
Why speed matters here specifically
Crisis response has an unusual time pressure most drafting work doesn't: the first few hours after an incident becomes known, internally or publicly, often set the tone for how the whole event is covered. A comms lead working through several versions of a holding statement in that window doesn't have time to also think carefully about which details are safe to put in front of a general-purpose AI tool and which aren't, so the practical outcome is usually that everything goes in, including speculation and unconfirmed numbers, because slowing down to redact isn't realistic under deadline. Having the drafting tool already be private, set up before any incident happens, removes that tradeoff instead of asking a stressed comms lead to make it correctly in the moment.
It also helps to have this ready in advance rather than provisioned during the incident itself. A Spark instance that's already running with the comms team's usual tools configured means the first crisis draft can start within minutes of the incident being flagged, not after someone requests access to a new AI tool and waits for it to be approved, which in a fast-moving situation is time the team doesn't have.
A worked example
Say a manufacturing company discovers a defect in a product already shipped. The first internal draft of a customer notice might describe the defect's likely cause before engineering has confirmed it, estimate how many units are affected before a recall scope is set, and include a rough cost estimate for legal to review. None of that first draft is meant for publication, it's a working document meant to get the team aligned quickly on what the eventual statement needs to cover. If that draft sat in a third-party AI vendor's logs, a data request, a subpoena, or simply a vendor breach could surface an internal document that looks like the company privately estimated a defect's scope well before its public statements said so, even if the early estimate was wrong and got revised twice before anything went out. Keeping that entire drafting history on infrastructure the company controls means it's the company's decision, not a vendor's data retention policy, whether and how that history is ever produced.
What this doesn't solve
A private model doesn't make a statement legally accurate, doesn't replace review by legal and executive leadership before anything goes out, and doesn't manage who inside the company has access to draft versions, that's still an internal access-control question. What it removes is one specific window of exposure: the period between an incident happening and a statement being approved, when the company's own words about itself are at their most sensitive and least final.