AI incident response: first hour, first day, first week

The worst time to decide how to handle an AI incident is after the evidence has started to disappear.

AI incidents can be quiet: client data pasted into the wrong tool, an unexpected meeting bot recording, a connected assistant surfacing confidential information, an agent sending a file, or an AI-generated answer reaching a client before anyone checks the source.

Some are privacy breaches. Some are policy failures, fraud events, near misses, or operational mistakes.

The first job is to preserve enough evidence for the business, IT, legal counsel, the insurer, and any regulator to understand what happened.

That window can close quickly.

If this just happened

Do this now:

• Stop active harm.
• Preserve the screen, chat, file, transcript, link, or output.
• Call the owner and IT provider.
• Call the bank, payroll provider, payment processor, or vendor immediately if money may be involved.
• Check cyber-insurance instructions before hiring outside responders, unless immediate action is needed to stop active loss.
• Tell staff not to delete, retest, or clean up.
• Assign one incident owner.
• Start the intake checklist.

Do not wait for perfect facts before escalating. In AI incidents, the evidence can disappear before the business understands what happened.

What counts as an AI incident

An AI incident is any event where AI creates, exposes, changes, misdirects, retains, fabricates, or acts on business information in a way the business did not intend.

Examples include:

• Confidential data entered into an AI tool that should not have received it.
• Client, employee, financial, legal, regulated, credential, or confidential content exposed through prompts, uploads, screenshots, transcripts, connectors, or saved chats.
• AI output sent to a customer and later found to be wrong, misleading, fabricated, stale, or contaminated with another client's information.
• A meeting tool recording, transcribing, sharing, retaining, or resurfacing meeting content outside the expected control path.
• Connected AI reading more data than expected and surfacing it in a draft, summary, search result, or answer.
• Prompt injection or hidden instructions in an email, document, web page, image, transcript, or file metadata manipulating an AI output.
• An AI agent, workflow, or automation sending email, creating a sharing link, changing a record, submitting a form, deleting content, buying something, or moving data without the expected approval.
• AI-assisted fraud, impersonation, fake voice or video, or AI-amplified phishing.
• AI-generated scripts, macros, commands, automations, or code damaging data, exposing information, or changing systems.
• AI-driven tooling turning an ordinary endpoint into an unmanaged automation or developer-capable machine.
• Staff using an approved AI tool to fabricate documents, impersonate someone, hide misconduct, inflate activity, or prepare company information for removal.

Every AI incident gets triaged. The triage decides whether it is a breach, a near miss, a policy issue, a fraud event, a client issue, a workflow failure, or a control gap.

Why AI incidents are different

AI incidents are different from traditional cyber incidents in three practical ways.

First, there may be no attacker to chase.

The harm may come from an approved tool, a staff workflow, a vendor feature, a bad configuration, a retained chat, a meeting bot, or an agent that did what it was allowed to do. The business still has consequences to contain, but there may be no malware, no external login, and no obvious hostile actor.

Second, the evidence often lives outside the business.

Prompts, outputs, uploaded files, chat histories, transcript archives, memory settings, workspace settings, connector logs, OAuth grants, sharing links, agent traces, model responses, and vendor audit logs may sit inside vendor-controlled systems. The business may not control the retention window. The vendor may retain detailed logs for only a short time, or only on certain plans.

Third, the evidence has a short half-life.

Chats get deleted. Logs roll over. Browser history clears. Tokens rotate. Memory changes. Meeting transcripts are edited. Projects are renamed. Sharing links expire. Vendor retention windows close. Staff forget exactly what they pasted, clicked, approved, or changed.

The first hour matters because AI incident response often depends on preserving a disappearing record of what the tool saw, what it produced, what it retained, what it connected to, and what happened next.

First hour: preserve and stabilize

The first-hour goal is simple: preserve evidence and stop active harm.

The first action is escalation, not solo investigation.

Call the business owner and the business's IT contact immediately. If IT is provided by an outside provider, call that provider as the IT contact.

If the incident may involve personal information, client data, fraud, money movement, regulated data, operational harm, or customer impact, call the cyber insurer or broker early and follow the policy instructions for breach counsel, forensics, and notice. Many cyber policies require the business to use approved breach counsel, approved forensics firms, and specific notice channels. Hiring your own breach counsel or forensics firm before calling the insurer can create coverage problems. Engage legal counsel through the insurer's process or through existing counsel where appropriate, unless immediate action is required to stop active loss.

If money movement, payroll routing, vendor banking details, or payment instructions may be fraudulent, call the bank, payroll provider, payment processor, or affected vendor immediately. Bank recall windows close quickly, so treat this as immediate.

Do not start by cleaning up. Do not delete the chat, uninstall the tool, clear browser history, reset every password, revoke every connector, or ask the user to "start fresh" unless harm is still actively happening. Cleanup can destroy the only evidence that explains the incident.

The rule is:

Capture before cleanup when safe. Stop active harm immediately when it is still happening.

If a non-technical staff member is the first responder, start simple. Screenshot the screen with the system clock visible if possible, save the page or chat URL, and write down what happened in plain language. That is enough to start.

Then work with IT, the outside IT provider, legal counsel, the insurer, or the vendor to capture the technical evidence:

• Identify the AI tool, vendor, workspace, project, account, meeting bot, browser extension, workflow, agent, or endpoint involved.
• Identify the user account, device, meeting, mailbox, file store, SaaS system, or business process involved.
• Preserve prompts, outputs, chat titles, chat IDs, links, screenshots, uploaded file names, transcript links, meeting IDs, project names, workspace settings, and memory settings.
• Export available vendor logs immediately where the tool allows it.
• Capture connector details: OAuth grants, app consent records, scopes, connected accounts, recent sign-ins, token state, and sharing permissions.
• Capture external exposure: recipients, sharing links, public links, forwarded messages, transcript shares, exported files, and customer-facing outputs.
• Preserve the endpoint state if a script, browser extension, coding tool, local AI tool, or automation tool is involved.
• Record what containment action was taken, who took it, and the exact time.

If the harm is ongoing, contain it first:

• Disable public sharing links.
• Suspend the agent or automation.
• Stop a meeting bot from recording or sharing.
• Isolate the endpoint.
• Revoke a connector that is actively moving data.
• Freeze or disable an account that is still sending, sharing, deleting, buying, or changing records.
• Pause customer-facing AI answers if they are giving harmful or wrong responses.
• Contact the bank, payroll provider, payment processor, or vendor if payment fraud may be in progress.
• If AI changed, deleted, renamed, or corrupted business data, stop the workflow and check backups, version history, recycle bins, audit logs, and restore options before overwriting more evidence.

If containment destroys evidence, document that tradeoff. "We revoked the connector at 10:14 because it was still exporting files" is much better than pretending the evidence was never lost.

Tell affected staff what to do while triage is underway:

• Pause use of the affected AI tool, workflow, connector, meeting bot, or automation until told otherwise.
• Do not delete chats, transcripts, files, browser history, extensions, or tool settings.
• Do not keep testing the tool to "see if it happens again" unless IT or the response lead asks for it.
• Report similar outputs, unexpected actions, suspicious prompts, or customer questions to the incident owner.
• Use one internal contact point so the business does not create conflicting stories while facts are still incomplete.

First 24 hours: decide what this is

The first day is for triage. The business needs to decide what happened, what data or systems were involved, who may be affected, and which obligations are triggered.

Ask these questions:

• What AI tool or workflow was involved?
• Was personal information involved?
• Was client confidential information involved?
• Was employee, financial, legal, health, public-body, credential, or regulated data involved?
• Did anything leave the business?
• Did an external person receive, access, view, download, or rely on the output?
• Did the AI tool retain the content, add it to memory, save it in a project, or share it with a vendor-side workspace?
• Did a connector, agent, workflow, script, meeting bot, or browser extension take action?
• Was the incident accidental, adversarial, fraudulent, or intentional staff misuse?
• Is harm still possible if nothing else is done?

For Alberta SMBs, the default privacy-law triage starts with Alberta PIPA. PIPA is Alberta's private-sector privacy law for most provincially regulated private-sector organizations. If personal information was lost, accessed without authorization, or disclosed without authorization, the business needs to assess whether a reasonable person would consider there to be a real risk of significant harm to an individual.

That threshold is often called RROSH.

If RROSH exists under Alberta PIPA, the organization must notify the Alberta Office of the Information and Privacy Commissioner without unreasonable delay. The Commissioner may require the organization to notify affected individuals. The organization can also decide to notify affected individuals directly before being required to do so.

Do not treat the PIPA question as the only question. Additional triggers may apply:

• Health information: Alberta's Health Information Act may apply if the business is a health information custodian or is acting for one. "Custodian" is a defined term. Do not assume every business that touches health information is a custodian, and do not assume it is not.
• Public-body data: Alberta's Protection of Privacy Act came into force on June 11, 2025 and applies to public bodies. A private SMB's obligations usually arrive through the public-body client contract, procurement terms, data-sharing terms, or incident notice clause.
• Federal privacy law: PIPEDA may apply if the business is federally regulated, such as a bank, airline, interprovincial transportation operator, or telecommunications company. It may also apply to interprovincial or international personal-information flows in commercial activity, even where Alberta PIPA governs other parts of the business.
• Outside-Canada service providers: Alberta PIPA has its own obligations when a service provider outside Canada is used to collect, use, or disclose personal information. The organization's policies and practices need to identify the country where this occurs or may occur and the purposes for which the service provider is authorized to handle the information. Individuals must be able to access those policies and reach someone who can answer questions about the service provider.
• Other provincial privacy laws may apply where the incident involves non-Alberta residents, clients, operations, or contractual commitments. Quebec Law 25 is a common example that may be called out by name in client questionnaires and contracts; where non-Alberta obligations may be in play, get legal review early.
• Contracts and insurance: client contracts, vendor contracts, professional rules, cyber insurance, payment-card rules, and sector-specific rules may impose shorter notice windows or different reporting duties than the privacy statute.

The first 24 hours should produce a short written incident position:

• What happened, based on evidence available now.
• What is confirmed, suspected, and unknown.
• What data types are involved.
• Who may be affected.
• What has been contained.
• What evidence has been preserved.
• Which legal, client, insurance, vendor, and regulator notifications are required or still under review.
• What decisions are due next and who owns them.
• Whether the cyber insurer requires panel counsel, panel forensics, specific vendors, or a specific claim process.
• Whether any client or customer communication is likely, and who owns the first draft.

This can be rough. It needs to be factual, timestamped, and good enough for counsel, the insurer, and leadership to work from the same record.

If clients or customers may need to hear from the business, prepare a short draft position statement during the first day. Hold it for legal and leadership review where legal, privacy, fraud, client, or confidential-business exposure exists, but start writing before the last minute. The draft should say what is known, what is not yet known, what has been contained, and when the business expects to provide the next update.

First week: close the loop

By the end of the first week, the incident should move from active response into correction.

Complete the scope determination:

• Which prompts, files, transcripts, chats, workspaces, projects, connectors, agents, scripts, extensions, users, meetings, systems, and recipients were involved?
• What data was exposed, changed, retained, deleted, fabricated, or relied on?
• Did the issue happen once, or is it part of a repeated workflow?
• Did the AI retain the content in memory, project context, transcript archives, saved chats, or vendor logs?
• Did any external party receive, access, or act on the information?
• If data was changed, deleted, renamed, or corrupted, which backup, version-history, recycle-bin, export, or audit-log path can restore it?

Complete required notifications:

• Alberta OIPC, where PIPA reporting is triggered.
• Affected individuals, where required or where the business decides direct notice is appropriate.
• Clients, where client data, contractual notice clauses, or trust require it.
• Legal counsel and insurer, where they have not already been engaged.
• Vendors, where vendor logs, deletion, retention, support access, or contractual answers are needed.
• Other regulators, where health, public-body, federal, non-Alberta provincial, professional, sector, payment, or contractual rules apply.

Get vendor answers in writing:

• What content did the vendor receive?
• Was it retained?
• For how long?
• Can it be deleted?
• Was it used for training, product improvement, analytics, support, or abuse monitoring?
• Which subprocessors or support personnel could access it?
• Where was it processed or stored?
• What logs exist, and when do they expire?
• Can memory, project context, workspace context, transcript archives, or saved chats be purged?
• Can the vendor confirm deletion or only process a deletion request?

Then identify the root cause by mapping the incident back to the relevant article:

• Shadow AI or personal-account use.
• Confidential data entered into AI.
• Connected AI reading business systems.
• Prompt injection.
• Meeting AI.
• AI-amplified phishing or fraud.
• Voice or video impersonation.
• Vendor AI features inside existing software.
• Agentic AI.
• AI-generated scripts or automation.
• AI development tooling on an endpoint.
• Wrong or invented AI output.
• Insider misuse.

The point of mapping is not filing. It tells the business which rule failed and which control needs to change.

Close the loop:

• Update the relevant policy rule.
• Remove, restrict, or redesign the unsafe workflow.
• Change vendor settings, memory settings, connector scopes, meeting-bot rules, sharing defaults, or endpoint controls.
• Restore or rebuild affected data from a known-good backup, version history, export, or authoritative source where data was changed or corrupted.
• Add monitoring or approval where the incident showed a blind spot.
• Train the staff involved on the specific failure, not on AI in general.
• Hold a short post-incident review with the business owner, IT lead or outside IT provider, affected leaders, and legal or insurance contacts where appropriate.

The review should answer four questions:

• What happened?
• What did we do quickly enough?
• What evidence was hard to get?
• What control changes before this happens again?

AI incident intake checklist

Use this checklist when an AI incident is reported. This is a working document. Fill what you know, leave what you do not know, and come back as you learn more. The first person receiving the report preserves the right facts so the response lead can work.

Minimum first capture: what happened, which tool was involved, which user or account was involved, what data may be affected, whether harm is ongoing, what evidence exists, and who has been notified.

Policy rule this creates