The mechanism doesn't change the legal duty. Whether a leak came from a stolen password or an AI tool doing something nobody expected, PIPEDA runs the same test.
Short answer
There's a specific, sequenced duty: assess whether the exposure creates a “real risk of significant harm,” and if it does, report to the federal Privacy Commissioner and notify the affected individuals — both “as soon as feasible.” A less-known fourth step applies regardless of that threshold: keep a written record of every breach of security safeguards for 24 months, whether or not it was reportable.
PIPEDA doesn’t require reporting every incident — it sets a specific trigger. Section 10.1(1) requires reporting to the Commissioner “if it is reasonable in the circumstances to believe that the breach creates a real risk of significant harm to an individual,” and s.10.1(3) sets the identical test for notifying the individual directly (PIPEDA, s.10.1(1) and (3)). “Significant harm” is defined broadly at s.10.1(7): it “includes bodily harm, humiliation, damage to reputation or relationships, loss of employment, business or professional opportunities, financial loss, identity theft, negative effects on the credit record and damage to or loss of property.”
Once that threshold is met, both the report to the Commissioner and the notice to the individual must happen “as soon as feasible after the organization determines that the breach has occurred” (PIPEDA, s.10.1(2) and (6)) — a rolling clock tied to when the organisation figures out what happened, not a fixed number of days. A Treadstone Law walkthrough of this same duty covers what a notification actually has to include and who counts as affected, in the general breach-reporting context, not specific to AI (Treadstone Law, on mandatory breach reporting).
A separate obligation applies even when the harm threshold isn’t met. The Breach of Security Safeguards Regulations require that “an organization must maintain a record of every breach of security safeguards for 24 months after the day on which the organization determines that the breach has occurred,” and that record must contain enough detail “that enables the Commissioner to verify compliance with subsections 10.1(1) and (3)” (SOR/2018-64, s.6). That duty exists whether or not the AI-related leak ever crossed the reporting line — a small, low-severity exposure still has to be logged, not just judged and forgotten.
If the leak happened on an AI vendor’s side — a misconfigured setting, a model exposing one customer’s data to another — the organisation that collected the information still runs this whole sequence; PIPEDA’s third-party processing clause makes clear that accountability for the data does not transfer to the vendor along with the data itself (PIPEDA, Schedule 1, clause 4.1.3). Whether the same underlying data was ever safely de-identified in the first place is a separate question, covered at is anonymised data still personal information.
A breach-response sequence only works if it's built before an incident happens — deciding who assesses, who reports and who keeps the record is an operations design question.
