An AI assistant gave the wrong instruction. What do you do first?

Establish what actually happened

Begin with the reported answer, time, affected task and any action taken. An incorrect explanation and an unauthorized downstream change are different incidents. A suspected disclosure needs the established security and privacy route. Do not use a general editorial checklist to replace your incident response policy or legal obligations.

Assign an incident owner under the existing process. Record confirmed facts separately from hypotheses. An employee's screenshot is a useful starting point, but it may not show the source version, identity context or destination outcome. Ask for the minimum evidence needed without moving private records into an unrestricted chat or spreadsheet.

Contain the affected path proportionately

The authorized owner decides whether to suspend a source, audience, action or the whole workflow. If the failure concerns one unapproved source, that may suggest a narrower containment than disabling every knowledge service, but security and operating consequences must guide the decision. Preserve a usable manual path for the affected task.

Do not assume the model is the cause merely because the failure appeared in its answer. The wrong source, missing applicability or excessive tool permission may be the primary problem.

Illustrative editorial photograph, not a customer result.

Preserve a reproducible case

Under your retention and access rules, record the release version, source configuration, relevant question, answer, retrieved evidence and tool outcome. Prefer references or redacted/synthetic reproductions when they are sufficient. Keep incident evidence in the authorized store, not in a new shared folder everyone can read.

Reproduce safely in an approved test environment. Do not repeatedly query a live system for restricted information to prove a disclosure. Your security owner determines the verification method. The objective is to establish the failure and its scope without increasing exposure.

Repair the cause, then test neighboring cases

If a stale guide caused the answer, correct the maintained source and verify propagation. If generation invented an unsupported instruction, add the case to the held-out evaluation and test related questions. If authorization failed, do not treat a softer refusal prompt as the completed repair. Verify enforcement with permitted and denied users.

A single successful retest is useful but may not establish that neighboring cases work. Include a question with missing context, a changed source and the ordinary successful task. Record the exact candidate release and reviewer decision. The responsible owner authorizes restoration; the team that made the fix should not silently redefine the acceptance standard.

Close with evidence and follow-up ownership

List affected outputs that need correction or review. Saved drafts and downstream records may outlive the assistant configuration. Record what was actually inspected, what remains uncertain and who will resolve it. Communicate the correction in a way affected employees can use, with the current procedure and manual contact.

Put this to work this week

Use a synthetic wrong-answer case for a tabletop review with your existing incident owner. Ask participants to name the containment authority, evidence store, source owner and restoration decision. Record unanswered questions as gaps in the operating plan. Do not simulate disclosure with real private records. Add the repaired case to the production gate review so restoration depends on evidence and authorization, not simply the developer saying the issue is fixed.

Use the AI Knowledge Access Test Sheet to preserve the regression case. The NIST AI RMF provides broader governance context; this article is practical planning guidance, not an incident-policy replacement. Request a resilience-focused demo and ask SimplSolutions to explain containment, source correction, retesting and ongoing ownership for the proposed task.