Build an AI Incident Log Before the Next Failure
Matthew Leo · Published October 23, 2026 · Guides
When an AI system does something harmful or unauthorized, the first question is often simple: what exactly happened? Many teams cannot answer it quickly because the model, prompts, tool calls, human approvals and outside services sit in different records.
That gap is becoming harder to ignore. Microsoft president Brad Smith has called for legal requirements to write AI incident reports, notify affected victims and provide an emergency brake. The UK’s AI minister has also argued that governments cannot rely entirely on technology companies to police their own models. These are policy positions, not a new Canadian reporting law, but they point toward the same operational need: keep a record that can survive scrutiny.
Canadian organizations do not need to wait. The Office of the Superintendent of Financial Institutions recommends AI-focused incident playbooks, monitoring of prompts and outputs, and logging of agent activity for regulated financial institutions. The Canadian Centre for Cyber Security gives broader incident-response guidance that is useful well beyond cyberattacks.
Decide what counts as an AI incident
Do not limit the definition to a data breach. An AI incident can include a model or agent that reaches an unauthorized system, exposes confidential information, sends a message without approval, makes a material decision on bad evidence, produces unsafe code that reaches production, or keeps acting after a stop command.
Set a low threshold for opening a record. A report can be closed later as a harmless alert. Reconstructing a missing timeline after logs have expired is much harder.
Record these facts first
- Detection: date, time, time zone, who noticed the issue and how it was detected.
- System identity: application, model and version, provider, agent name, environment and the business process it supported.
- Inputs and actions: relevant prompts, retrieved data, tool calls, API requests, files touched and downstream actions.
- Human control: who approved the task, which approval checkpoints fired, which ones failed and who had authority to stop it.
- Impact: confirmed and suspected effects on people, data, money, operations and outside organizations. Keep those two categories separate.
- Containment: credentials revoked, tools disabled, sessions stopped, traffic blocked, records preserved and manual fallbacks started.
- Notifications: legal, privacy, security, executive, provider, customer, insurer or regulator contacts, including the decision and time.
Preserve original evidence rather than pasting only a summary. Where possible, keep immutable copies of logs and note retention periods. Do not put secrets or unnecessary personal information into a broadly accessible incident ticket.
Make the first hour repeatable
The incident owner should freeze relevant logs, identify the affected system and stop further high-risk actions. Someone else should establish a timeline while responders work. If the AI touched an outside service, record the destination and contact that organization through an approved channel.
Do not let a provider’s investigation replace your own record. A hosted model company may see model-side telemetry, while your organization sees permissions, retrieved documents and business consequences. Both sides can hold essential evidence.
Mapletechie’s guide to approval gates for AI agents can reduce the blast radius before an incident. Its reporting on an AI that submitted a false police tip during testing shows why form submissions and other seemingly ordinary tools belong in the action log.
Keep reporting duties separate
An internal AI incident record does not decide whether a privacy commissioner, cyber authority, customer or other party must be notified. That depends on the facts, contracts and applicable law. Assign an owner to make that decision and document the reasoning.
Federally regulated financial institutions have specific OSFI technology and cyber incident-reporting expectations. Organizations covered by privacy laws may also have breach duties. An AI failure is not automatically a reportable privacy breach, and the absence of stolen personal information does not make the operational failure unimportant.
Review patterns, not just single failures
Once a month, group incidents and near misses by model, provider, tool, permission and business process. Look for repeated overrides, missing logs, expired evidence and alerts that arrive too late. Feed those findings into access reviews, vendor terms, testing and staff training.
Mapletechie has already examined proposed AI-agent reporting rules in Australia and a proposed notification channel between the United States and China. The practical lesson for a Canadian team is narrower: if a serious failure happens tomorrow, the organization should be able to explain the system, the sequence, the impact and the response without guessing.
Sources
- Reuters: Microsoft calls for AI incident reports and victim notification
- The Guardian: UK minister calls for stronger AI safety efforts
- OSFI: Generative and agentic AI risk bulletin
- Canadian Centre for Cyber Security: Developing an incident response plan
Tags: AI incident response, AI governance, incident management, Canada