When does the clock start on an AI incident—when it happens, when it is detected or when the provider confirms it?
This material is practical governance guidance, not legal advice. Reporting duties depend on the organization, sector, jurisdiction, facts and applicable contracts. Confirm legal obligations with qualified counsel.
There is no single clock
An AI provider alerts your organization that its service may have exposed customer information. The underlying event began four days ago. Your security team saw unusual activity yesterday. The provider has not completed its investigation.
When did your reporting clock start?
The wrong answer is: “when the provider confirms it.”
The more accurate answer is: which clock, under which rule?
An incident may generate several timelines at once. A statute may tie notification to when the organization determines that a breach occurred. A regulator may require notice within a fixed period after discovery. Another regime may start when the organization determines that the event is material. A customer contract may require notice after actual or suspected unauthorized access. An internal escalation standard may start at detection.
These triggers are not interchangeable, and a provider’s terminology does not decide the organization’s obligations.
Five moments that should never be collapsed
Every AI incident record should preserve at least these times:
| Moment | What it answers |
|---|---|
| Occurrence | When did the harmful event begin or happen? |
| Detection | When did any relevant party first observe it? |
| Organizational awareness | When did your organization receive facts indicating a potential incident? |
| Legal or materiality determination | When was the applicable reporting threshold met or determined? |
| Notification | When was each required notice authorized, sent and acknowledged? |
Provider confirmation may be another useful timestamp. It should not overwrite the others.
Why? Because “confirmation” can mean many things: validation by a technical team, completion of root-cause analysis, approval by the provider’s legal department or simply a change in the label used in a status update. None automatically controls a duty imposed on the customer organization.
Canadian rules demonstrate the difference
Under Canada’s federal private-sector privacy framework, PIPEDA requires reporting and notification where a breach of security safeguards creates a real risk of significant harm. The Office of the Privacy Commissioner of Canada states that reporting and notification are to occur as soon as feasible after the organization determines that the breach occurred. Its breach-report form also makes clear that the organization should report even if the cause or planned mitigation is not yet known or confirmed.
For payment service providers subject to the Retail Payment Activities Act framework, the Bank of Canada says an initial notice must be made without delay and no later than 48 hours after the PSP determines that an incident is material. If an incident becomes material later, the 48-hour outside limit runs from that determination.
OSFI’s technology and cyber incident reporting guidance uses another formulation for federally regulated financial institutions: report within 24 hours, or sooner if possible.
These examples do not create a universal rule for all AI incidents. They show why an organization must identify the applicable trigger rather than adopt one convenient enterprise definition.
Provider confirmation is evidence—not permission to wait
A provider may hold essential telemetry, but outsourcing the service does not outsource the customer’s reporting analysis. The customer knows facts the provider may not: the affected business process, sensitivity of the information, downstream customers, regulated activities and contractual promises.
Waiting for provider confirmation can therefore create three problems:
- 1. The wrong trigger: the applicable obligation may start from the organization’s discovery, determination or awareness—not the provider’s conclusion.
- 2. Lost decision time: legal, privacy, security and business teams receive the issue too late to assess it properly.
- 3. Weak evidence: the organization cannot show what it knew, when it knew it or why it delayed notification.
The safer operating model is to open an internal incident record on credible indication, preserve uncertainty explicitly and update the assessment as facts develop. An initial notification can say that an investigation is ongoing where the relevant regime permits or expects preliminary information. Accuracy matters, but certainty about every fact is rarely the prerequisite for beginning the process.
Build a multi-clock incident record
For each potentially reportable AI incident, capture:
- first known occurrence and last known exposure;
- provider detection time and customer detection time;
- when the organization received each notice or indicator;
- source, confidence and unresolved facts;
- systems, models, agents, data and people potentially affected;
- each applicable law, regulatory rule and contract;
- the exact trigger language and outside deadline;
- who made the reportability or materiality determination and on what evidence;
- approval, delivery and acknowledgement time for every notice;
- subsequent corrections, interim reports and final findings.
The record should retain the original timestamps. Do not replace the detection time when the incident is later confirmed or reclassified. A chronology that evolves is evidence; a single overwritten status is not.
Contracts with AI providers should support this operating model. Define notice triggers, maximum notification periods, required content, continuing updates, evidence access, preservation duties and cooperation. Avoid clauses that make customer action dependent on the provider completing its own legal characterization.
The board-level question
Ask: “Could we demonstrate, for every applicable obligation, the facts we had, the trigger we applied, the person who made the determination and the time remaining when we acted?”
If the incident system stores only “opened,” “confirmed” and “closed,” the organization may not be able to answer.
The goal is not to choose occurrence, detection or confirmation as the one true clock. It is to maintain an evidence-grade timeline and apply the right clock to each duty.
Clariantix perspective
AI incident governance should convert fragmented provider updates, internal observations and legal decisions into one defensible chronology. Clariantix’s approach separates detection, confirmation, potential reportability, authorization, delivery and acknowledgement so the organization can show not just that it reported—but why it reported when it did.
Because the question after an incident will not only be “What happened?” It will also be “When did you know enough to act?”
Runtime Governance Series
- Your AI agent can access the website. Does that mean it is authorized to submit the form?
- When does the clock start on an AI incident—when it happens, when it is detected or when the provider confirms it?
- AI governance is moving into the operating system. Is your governance record connected to what the system actually enforced?
- Office of the Privacy Commissioner of Canada, PIPEDA breach report form and guidance.
- Office of the Privacy Commissioner of Canada, Assess if a privacy breach poses a real risk of significant harm.
- Bank of Canada, Reminder: PSP reporting obligations under the RPAA, 29 June 2026.
- Bank of Canada, Incident notification supervisory guideline.
- Office of the Superintendent of Financial Institutions, Technology and Cyber Security Incident Reporting.
Accuracy note: This material is practical governance guidance, not legal advice. Reporting duties depend on the organization, sector, jurisdiction, facts and applicable contracts. Confirm legal obligations with qualified counsel.