Canada AIDA AI Incident Reporting: The PIPEDA Breach Test That Applies
AIDA never became Canadian law. AI incident reporting in the private sector instead turns on PIPEDA: report to the Privacy Commissioner and notify affected individuals when a breach of security safeguards creates a real risk of significant harm, act as soon as feasible, and retain a record of every breach for 24 months. This guide applies that test to prompts, responses, and LLM destinations.
The Artificial Intelligence and Data Act never became Canadian law. AIDA was Part 3 of Bill C-27, and the official parliamentary record shows that committee consideration remained unfinished when Parliament was prorogued on 6 January 2025.
For private-sector AI incidents within PIPEDA's scope, the live federal rule is the breach framework in sections 10.1 through 10.3. It applies to personal information exposed through a prompt or response in the same way it applies to personal information exposed through another system.
TL;DR
- AIDA created no Canadian AI incident-reporting duty because Bill C-27 died before passage.
- PIPEDA requires reporting to the Privacy Commissioner and notice to affected people when a breach creates a real risk of significant harm.
- The report and notice must go out as soon as feasible after the organization determines the breach occurred.
- Every breach of security safeguards needs a record, even below the reporting threshold, retained for 24 months.
- LLM investigations need identity, prompt classification, destination and time, plus the policy outcome to apply the test.
The PIPEDA trigger is real risk of significant harm
PIPEDA section 10.1 sets one threshold for reporting to the Office of the Privacy Commissioner of Canada and notifying affected individuals. The organization must reasonably believe that a breach of security safeguards involving personal information under its control creates a real risk of significant harm.
The statute names bodily harm, humiliation, damage to reputation or relationships, loss of employment or business opportunity, financial loss and identity theft, as well as other harms. The assessment must consider the sensitivity of the information and the probability that it has been, is being, or will be misused.
An LLM incident therefore needs a factual assessment. A support transcript containing a customer's diagnosis carries a different sensitivity profile from a prompt containing a public product description. A response displayed to one authorized analyst presents a different probability of misuse from the same response returned to an external user. The model label alone settles neither factor.
Reporting, individual notice, mitigation contacts, and third-party notice
Once the threshold is met, section 10.1 requires a report to the Commissioner and notice to affected individuals as soon as feasible after the organization determines that the breach occurred. The individual notice must explain the significance of the breach and give the person enough information to take available protective steps.
The Breach of Security Safeguards Regulations supply the required fields. A report includes the circumstances and cause, the day or period, the personal information involved, the number of affected individuals or an approximation, mitigation steps and planned notice, plus a contact. Individual notices cover the circumstances and timing, affected information, risk-reduction steps and the organization's contact, along with the Commissioner's complaint process.
PIPEDA also requires notice to another organization or government institution when it may reduce or mitigate the harm. In an LLM event, that could include the model processor or an identity provider able to terminate an exposed session.
Every breach needs a 24-month record
Reporting starts at a defined harm threshold, while record keeping covers every breach of security safeguards involving personal information under the organization's control. PIPEDA requires the record, and section 6 of the regulations fixes a 24-month retention period beginning on the day the organization determines that the breach occurred.
That distinction matters for an AI incident that ends below the real-risk threshold. The organization still needs a record that lets the Commissioner verify compliance with sections 10.1 and 10.2. A one-line ticket saying "prompt issue closed" leaves the threshold analysis unsupported.
The physical detail I look for is a timestamped row that can be placed beside the incident ticket on one screen: named identity, content category, destination endpoint, response recipient, policy version and decision, plus the mitigation event. That row turns the sensitivity and probability analysis into evidence. The AI incident response playbook covers the wider response sequence, while AI audit-log retention requirements addresses the record lifecycle.
LLM incidents need request-level reconstruction
A conventional database incident starts with a schema. Investigators can identify columns and affected rows. Prompt traffic carries free text, retrieved documents, tool output, and conversation history inside one HTTPS request. Provider telemetry may show a model identifier and token count, plus the time while leaving the personal-information categories unknown.
A defensible reconstruction needs five fields captured near the event: the authorizing identity, the content classification and model destination, the response recipient, and the policy outcome. Those fields answer who was affected, what information was involved, where it went, and which safeguards operated.
My view is blunt: an incident plan that starts classifying prompts after the breach has already failed its first evidence test. Classification belongs before transmission. The AI data-classification guide explains that control point, and the Canada AIDA audit-evidence article places the resulting record in a Canadian review file.
Safeguards determine both cause and response
PIPEDA Schedule 1 requires safeguards appropriate to the sensitivity of the information. It names protection against loss, theft, unauthorized access, disclosure, copying, use, or modification, regardless of format. For LLM traffic, the relevant safeguard sits where prompt content can be evaluated before it reaches an external model.
Transport encryption protects the request in transit. It still delivers the payload to the selected recipient. The incident question is often authorization: did this identity have permission to send this category of personal information to this endpoint for this purpose? Per-role model authorization, prompt classification, redaction, and a refusal policy address that question at the request boundary.
The same control record then supports the breach analysis. A denied request demonstrates that the safeguard operated. A permitted request records the policy state investigators need to identify a control gap. This is narrower than full incident response, which also covers endpoint forensics, legal privilege, containment, and communications.
DeepInspect
DeepInspect sits at the HTTP AI request boundary. For routed traffic, it evaluates the identity context supplied by the application, classifies prompt content, checks model authorization, and records the destination and policy outcome before the request reaches the LLM.
Each decision produces a signed, tamper-evident record outside the calling application's write path. During a PIPEDA investigation, that record supports the sensitivity analysis, the probability-of-misuse analysis, the affected-data description, and the 24-month breach file. It contributes evidence for the AI channel; your incident team still owns determination, containment, notice, and regulatory communication.
Book a technical deep dive at deepinspect.ai.
Frequently asked questions
- Does PIPEDA set a fixed number of hours for notification?
PIPEDA uses "as soon as feasible" after the organization determines that the breach occurred. It supplies no fixed 72-hour or three-day period. The incident file should record when the organization determined the breach occurred, who made that determination, when the report and notices were sent, and the reason for any interval. That chronology matters because the legal clock turns on the determination, while technical detection may have happened earlier.
- Must a below-threshold AI incident be documented?
Yes. PIPEDA requires a record of every breach of security safeguards involving personal information under the organization's control. The 24-month retention rule applies even when the organization concludes that the event created no real risk of significant harm. The record should preserve the facts and reasoning behind that conclusion so the Commissioner can verify compliance on request.
- Where does DeepInspect stop in an incident workflow?
DeepInspect covers HTTP AI traffic routed through it between authenticated users or agents and LLM endpoints. It can enforce identity-bound content and model policy and produce per-decision records for that channel. Endpoint compromise, local model execution, employee interviews, legal analysis, notification delivery, and regulator communications remain outside that boundary.