After an AI provider incident, what must change before your workflow resumes?

A provider says its chat service is back online. Can your team resume summarising documents?

Service restoration is not workflow clearance. It tells you something about the provider’s system, but not which of your accounts were involved, what information staff entered, where outputs went or which restrictions your firm still needs.

What must change before restarting is not necessarily the software. It is the basis for the decision: someone must establish the permitted scope, assess the relevant evidence, verify necessary controls and explicitly authorise the work.

This article offers a proposed decision method for one affected workflow. It is not a complete incident-response plan or legal advice.

Start with the notice, not a conclusion

Save the provider’s exact notice, including its URL or message reference, publication and revision times, and the time your firm received it. Record:

• the product and feature described;
• the reported incident window, including time zone;
• whether the notice identifies your account or describes a general incident;
• what the provider confirms, what it considers possible and what remains under investigation.

Keep later updates alongside the original. A revised notice may change the scope of your assessment.

A historical example—not evidence of a current incident

OpenAI’s account of the 20 March 2023 ChatGPT incident, published 24 March 2023, illustrates why scope matters.

OpenAI reported that a bug could allow some users to see another active user’s chat-history titles and possibly the first message of a newly created conversation when both users were active around the same time. It also described possible payment-information visibility for a subset of active Plus subscribers during a specified window.

The provider said it patched the bug and restored ChatGPT and chat history, except for a few hours of history. Its report also describes investigation and notifications. See OpenAI’s incident report for its exact account.

That report does not establish that a particular Australian firm was affected, that every user was exposed, that the API was affected or that a leak exists now. Nor does a provider’s statement about removing an ongoing risk establish that your firm’s use can resume without further assessment.

Date distinction: the incident and report are from March 2023. The 9 October 2026 documentary review compared selected retained primary-source passages. Checking a historical report now does not make it evidence of current service conditions.

Reconstruct the work that could be affected

Consider Harbour Practice, a fictional Australian professional-services firm whose staff use a chat service to summarise documents before preparing advice. The following scenario is hypothetical and is not a claim about the 2023 incident affecting that firm.

After receiving a provider notice, the practice owner asks the operations lead to assess the document-summary workflow.

The lead should establish the review window and use authorised records to identify potentially affected activity. Relevant evidence might include account notices, staff activity records, the approved workflow register, retained prompts and outputs, and the locations where summaries were saved or used.

For each candidate run, record only what the assessment needs:

• time, account reference and product used;
• information category, such as public material, internal papers or client documents;
• output location and subsequent use;
• whether the activity falls within the provider’s reported scope;
• the evidence supporting that conclusion and its limitations.

Keep sensitive details in protected records, not a broad incident chat. The decision sheet should link to those records rather than reproduce their contents.

A missing log is not a clean result. State which accounts or periods could not be checked, why, and who will seek further evidence. Ask the provider focused questions about affected features, relevant times, account-specific notices and available activity evidence.

This is a targeted reconstruction of affected work, not a replacement for the firm’s full data-flow and retention inventory.

Contain the workflow and preserve the evidence

Within existing authority, pause new submissions to the affected workflow or apply a justified restriction. Tell staff exactly what it covers, who owns questions and when it will be reviewed.

Do not treat “non-client material” as automatically suitable for continued use. Internal papers may still contain personal information, confidential material or information subject to contractual restrictions. Define any permitted category positively—for example, specified public documents whose use has been approved—and check the accounts, connectors, storage and output destinations it relies on.

Do not silently delete chats or outputs as clean-up. Preserve relevant evidence securely under the firm’s response and retention requirements. Any necessary deletion or other containment action should be coordinated with the response lead so that its consequences for evidence are considered.

Other workflows need dependency checks too. A separately approved workflow may warrant different treatment, but “different task” does not necessarily mean “unaffected”: it may share an account, connector, data store or output.

A provider notice alone supports neither an automatic firm-wide shutdown nor unrestricted continuation.

Assess exposure and output reliability separately

Two different questions need answers:

1. Information exposure: could information have been accessed or disclosed outside its intended boundary?
2. Output reliability: is there reason to doubt the summaries or the decisions that relied on them?

A reported disclosure mechanism does not, by itself, prove that generated summaries were altered or inaccurate. Equally, restored service does not validate earlier outputs.

Trace the affected summaries and decide what review is proportionate to the incident mechanism, available records and consequences of error. Where reliability is in doubt, hold the relevant output from further use until an appropriately qualified person checks it against its source.

If an output has already informed advice or another consequential decision, assign someone to assess whether further action is needed. Do not assume that restarting new work resolves earlier use.

Keep response duties separate from restart permission

The OAIC quick reference guide for responding to data breaches, published 29 June 2026, describes containment, assessment, notification if required, and review.

For entities with relevant Notifiable Data Breaches obligations, the guide distinguishes assessment of a suspected breach from a finding that an eligible data breach has occurred. It says covered entities must take all reasonable steps to complete the relevant assessment within 30 calendar days.

That is not a generic instruction to notify within 30 days, or permission to wait before containing and assessing an incident.

Whether the scheme applies, whether notification is required and what other duties arise depend on the entity and the facts. Contractual, confidentiality and professional obligations may also matter. Seek appropriate advice rather than turning a general provider report into a legal finding.

The OAIC’s guidance on preparing a data breach response plan, updated February 2025, is a broader reference for response roles, escalation, communication and records. It does not validate the worksheet below as a compliance tool.

For the wider allocation of incident-response responsibilities, see Governing an AI-enabled workforce in Australia.

Assign owners to both the incident assessment and the operational decision. In a small firm, one person may hold both roles, but the decisions should remain distinct and linked.

A restricted operational restart may leave incident-assessment work open. It cannot waive applicable obligations.

Choose a state against written criteria

Write the criteria before recording the decision. These four states provide a practical vocabulary:

State	When it may be defensible	Boundary to record
Hold	A material uncertainty or unmet control prevents a justified restart	Work prohibited, evidence needed and next review
Restricted restart	A defined subset can meet its criteria despite remaining uncertainty	Exact users, information, tasks, destinations, controls and expiry
Full restart	The previously approved workflow meets its restart criteria	Approved scope; any new use still needs separate assessment
Migration or manual alternative	Another assessed process can handle the work	Authority for transfers, access, retention, review and handover

Migration is an alternative operating decision, not evidence that the original service is cleared. It also does not remove duties arising from earlier activity.

For any restart, ask:

• Does current provider evidence address the relevant product and incident mechanism?
• Is firm-specific activity sufficiently understood for the proposed scope?
• Are necessary controls in place, with evidence that they work as intended?
• Have prior outputs been assigned an appropriate treatment?
• Can the named approver explain why remaining uncertainty does not defeat this particular decision?
• Are staff instructions, review timing and stop conditions explicit?

A proposed control is not an implemented control. Where verification is needed, record the method, result, date and limitations. An unsuccessful or unperformed check should remain visible—not become a tick through omission.

The approver can accept an operational decision only within their authority. Approval does not override legal, professional or contractual restrictions.

Copyable restart decision sheet

Use one sheet per affected workflow. Label entries verified fact, provider statement, inference or unknown, and link to protected evidence.

This is a decision aid, not legal advice or proof of compliance.

Field	What to record
Workflow and decision scope	Approved purpose; product, accounts and dependencies; current restriction and start time; exact work being considered
Notice and chronology	Original and revised notices; publication, receipt and incident times with time zones; provider statements and limits
Firm activity and coverage	Records checked, period covered, candidate runs and missing accounts or logs; do not equate missing evidence with no exposure
Information and exposure	Categories involved; possible affected people or parties in protected records; possible versus confirmed exposure
Outputs and onward use	Locations and downstream decisions; review or other action required; rationale for outputs needing no incident-specific action
Containment and preservation	Restrictions actually applied, evidence secured, access boundaries and retention considerations
Response duties	Response owner, advice sought, applicability questions, communication decisions and next assessment date
Restart criteria and checks	Each criterion; required evidence; status as met, unmet or unknown; verification result or “not yet performed”
Control changes	Proposed versus implemented changes; who verifies them and by when; rationale if no change is needed
Unresolved issues	Each gap, its consequence for the proposed scope, owner, due date and why it blocks—or does not block—that scope
Decision and rationale	Hold, restricted restart, full restart or alternative; permitted and prohibited use; reason the evidence supports that boundary
Authority and activation	Named approver and decision time; activation conditions; who applies the change and confirms staff instructions
Review and stop triggers	Review or expiry date; owner; events requiring a pause or reassessment, and who acts

An evidence sheet is incomplete as a decision record if it merely lists outstanding actions. It must show which state applies now, why that state is defensible and what must happen before it changes.

Hypothetical example: a hold, not an implied clearance

Suppose Harbour Practice’s operations lead finds activity during the provider’s reported window but cannot reconcile one staff account. The public notice provides no firm-specific finding.

In this example, the available records are preserved, client-document submissions are paused, and two draft summaries are identified for human review before use. That review is a precaution arising from the workflow assessment—not a claim that the provider incident corrupted those drafts.

The decision record would say:

• Current state: hold for client-document summaries.
• Blocking gap: unreconciled account activity; an assigned owner must seek further evidence by a specified date.
• Prior outputs: the two identified drafts remain held pending review; no review result is claimed.
• Possible restricted scope: specified public documents only, subject to separate dependency, information-use and control checks.
• Authority: restricted use remains a proposal until the accountable approver explicitly authorises it.
• Reconsideration: a revised provider notice or new affected-account evidence triggers reassessment; the sheet must also contain an actual review date.

Calling the possible scope “low risk” would not fill the evidence gap. If the firm cannot demonstrate a defensible boundary for it, that work remains on hold too.

The decision to take away

Resume only the work for which the evidence supports a defined, authorised operating state. Record the permitted scope, necessary controls, treatment of earlier outputs and remaining uncertainty. Give the decision an owner, a review date and clear reasons to stop again.

For the broader allocation of work and decision rights, return to AI workforce orchestration for professional services. This guide’s narrower job is to make one affected workflow’s next step explainable from evidence—not to declare the provider, the firm or every AI task “safe”.