At 10:15, a colleague notices that an agent has changed delivery details for the wrong customer. The team stops the interface and assumes the problem is contained. Ten minutes later, a scheduled job sends another batch of updates.
This hypothetical incident illustrates why AI response needs an operational plan. Closing a chat window does not necessarily stop background jobs, connected tools or queued actions. A business needs to know how to stop the actual authority it delegated, then establish what has already happened.
Contain the action without destroying the evidence
My first question is: which business action could still occur? Pause the affected workflow through the approved controls, disable relevant jobs and, where necessary, revoke the agent's tool access or credentials. Coordinate with the service owner so containment does not unintentionally disable an unrelated critical service.
Preserve the relevant evidence in controlled storage: timestamps, task identifiers, configuration versions, accessed records, tool calls and completed actions. Avoid indiscriminate copying of entire customer datasets into an incident chat. Logs can contain personal or confidential information and need suitable access and retention controls themselves.
The agent's generated explanation may help identify a lead, but it is not the authoritative transaction record. Compare it with the systems that actually sent the message, changed the order or granted access.
Build a record of affected work
For each affected case, record what was intended, what actually happened, who or what was affected, and what remains reversible. Distinguish prepared drafts from completed external actions. A queue of unsent messages requires a different response from messages already delivered.
In the delivery example, reconcile agent activity against the order system and outbound communications. Freeze uncertain items for human review. If a correction is needed, have an accountable employee confirm the right customer and details; do not ask the same uncontrolled workflow to repair itself at scale.
Give the response one operational owner and one decision log. Customer communication, technical containment and legal assessment can proceed in parallel, but they should not produce conflicting instructions.
Decide what must be reported
An AI error is not automatically a reportable personal data breach. Assess whether personal data security has been breached and the risk to people's rights and freedoms. GDPR Article 33 requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours after awareness, unless the breach is unlikely to result in such risk. Processors must notify the controller without undue delay.
Article 34 separately addresses communication to affected people where the breach is likely to result in high risk, subject to its conditions and exceptions. Do not wait for a perfect technical root-cause report before assessing those duties. In Norway, the relevant supervisory authority will commonly be Datatilsynet; confirm the actual jurisdiction and any additional sector or contractual notification obligations.
Keep the assessment and reasoning even where notification is not required. Involve the appropriate privacy, security and legal expertise for the incident rather than letting the tool supplier make the company's decision by default.
Restart on evidence, not reassurance
Before restarting, I would require a short record answering five questions:
- What path allowed the unwanted action, and what has changed to block it?
- Have completed and queued actions been reconciled, including downstream effects?
- Has the correction been tested against the original failure and representative normal cases?
- Are the remaining limitations acceptable for the reduced or restored scope?
- Who authorises restart, and what monitoring will detect a recurrence promptly?
A smaller restart may be appropriate: draft-only output, fewer case types or renewed approval for external actions. A patch that improves the prompt may be helpful, but it should not substitute for a missing permission boundary.
Rehearse the awkward handover
Run a tabletop exercise with the service owner, an ordinary user and whoever covers absences. Give them the delivery scenario and ask them to find the actual stop mechanism, identify the transaction record and name the notification decision-maker. Measure the gaps in the process, not the participants' confidence.
The exercise should feed into the production-readiness review and the board's autonomy limits. A recoverable mistake can still be costly; an undocumented mistake may become a repeated one.
Sources and scope
Sources checked on 11 October 2026. The operational sequence is my proposed playbook and the delivery incident is hypothetical. Legal reporting duties depend on the incident, organisational role and applicable rules; the 72-hour provision is not a general deadline for every AI error.