Most businesses plan for a serious cyber event, but an AI-related problem can begin more quietly. A generated quote contains the wrong condition. A summary omits an important warning. An agent sends a message to the wrong person. A staff member pastes confidential information into an unapproved tool.
These events need a calm, repeatable response. AI incident response NZ planning helps a small business stop the activity, understand what happened, correct the result and improve the process without turning the first few minutes into blame or guesswork.
This is general operational guidance, not legal, privacy, cybersecurity, employment, financial or medical advice. Specialist advice may be needed for a data breach, safety event, regulated decision, contractual commitment or harm to a person.
The business does not need to predict every failure. It does need to know who can pause the workflow, who assesses impact, who communicates and who decides when the process is safe to restart.
Recognise the different kinds of AI incident
An incident may involve accuracy, privacy, security, fairness, customer service, staff work or system behaviour. Examples include a fabricated fact presented as true, a personal detail sent to an unintended service, an automated action outside permission, a biased recommendation or an output that cannot be traced to a trusted source.
Some incidents are discovered before anyone relies on the result. Others are noticed after a customer, supplier or staff member has been affected. The response should be proportionate, but every report deserves enough attention to decide what happened.
1. Make the first action a pause
Stop sending, publishing, approving or changing records through the affected workflow. If an agent has connected permissions, pause or revoke them. Do not keep testing the live process while the team is still unsure what it did.
Give staff a simple stop instruction. They should know who to contact and how to prevent the same output from being sent again. A pause is not an admission of failure; it is a control that limits the impact.
2. Preserve the useful evidence
Record when the issue was noticed, what the system produced, who used it, what information was involved and what action occurred. Keep the relevant source, prompt, approval record, output and system log where it is safe and appropriate.
Do not copy sensitive information into extra places simply to create a record. Limit access to people who need to investigate and follow the business’s existing information-handling process.
3. Contain the immediate problem
Identify whether the output was sent, stored, published, acted on or shared. Remove or correct material that is still under the business’s control, and stop connected actions that could extend the problem.
If confidential information may have been disclosed, avoid further sharing while the business assesses the path. If an account or connector may be compromised, use the appropriate technical response rather than relying on the AI tool to fix itself.
4. Work out who may be affected
List the people, customers, suppliers, records and systems touched by the event. Distinguish what is known from what is suspected. Do not minimise the issue because the output looked like a draft, and do not exaggerate it before the facts are checked.
Consider accuracy, privacy, safety, fairness, financial impact, reputation and the effort required for a person to correct the result. The same incorrect sentence can have very different consequences in an internal brainstorm and a customer decision.
5. Decide what must be communicated
Tell the internal owner and the right decision-makers early. Depending on the event, the business may need to contact affected people, a supplier, an insurer, a professional adviser or an authority. The correct action depends on the facts and obligations.
Communication should be clear about what is known, what is being done and how people can ask questions or correct information. Do not make promises the business cannot keep, and do not hide a material problem behind technical language.
6. Correct the output and the record
Use a trusted source and a responsible person to prepare the correction. Check that the replacement message does not repeat the original error or create a new promise. Update records that were changed and confirm that the correction reached the people who received the first result.
If the incident affected a decision, give the appropriate person a route to review the outcome. The aim is not merely to replace a sentence; it is to restore an accurate and fair process.
7. Find the cause without blaming a person
Ask what allowed the incident to happen. Was the source outdated, was the prompt unclear, was a permission too broad, did a reviewer misunderstand the task, did the tool change, or did staff lack a safe alternative?
Separate deliberate disregard from a process that made the wrong action easy. Blame can make people hide the next near miss. A useful review creates a clear improvement rather than a story about one person’s mistake.
8. Fix the control
Possible fixes include narrowing data access, adding approval, updating the source, changing the task, improving the prompt, limiting a connector, changing the retention setting, adding a warning or requiring a different reviewer.
Choose a fix that addresses the cause. Telling staff to be more careful is rarely enough if the workflow still makes an unsafe action the easiest option.
9. Test before restarting
Use safe examples to reproduce the failure and confirm that the change works. Test ordinary requests and the conditions that triggered the incident. Check the human handoff, logs, permissions and fallback, not only the final sentence.
Write down who can approve the restart and what evidence they need. A short pause followed by a well-tested restart is safer than quietly resuming because the immediate pressure has passed.
10. Learn from near misses
An output caught before it affected anyone can still reveal a weakness. Record near misses in the same improvement process, without keeping more sensitive content than necessary.
Review patterns across tools and teams. Similar errors may indicate that staff need a clearer rule, that approved sources are poorly maintained or that a supposedly low-risk use has become more important over time.
Keep a one-page response card
A small business does not need a complex emergency manual for every AI use. A response card can say: stop the workflow, contain the information or action, record the facts, contact the owner, assess who may be affected, correct what happened, communicate appropriately and approve the restart.
Put the card where staff can find it. Practise the first few steps using a harmless example so people do not have to learn the process during a stressful event.
Know when specialist help is needed
Escalate when the incident involves personal or sensitive information, safety, employment, financial loss, a significant customer outcome, cultural or community interests, a compromised account or an obligation the business does not understand.
Do not let the desire to keep an issue small prevent the business from getting appropriate advice. Early specialist input can clarify the response and reduce further harm.
Build resilience into ordinary work
Incident response works best when it is connected to tool approval, staff training, quality review, data governance and business continuity. The business should know its important manual process before an AI workflow fails.
For a New Zealand small business, responsible response is a sign of maturity, not a reason to stop experimenting. Start with a narrow use, keep an owner, make the pause possible and learn from every error. That is how AI becomes more useful without making recovery an afterthought.
Frequently asked questions
1. What is an AI incident?
It is an event where an AI system produces, exposes or acts on information in a way that is wrong, unsafe, unauthorised, unfair or impossible to explain.
2. What is the first step after an AI error?
Pause the affected workflow and prevent further sending, publishing, approvals, record changes or connected actions while the business assesses what happened.
3. What evidence should be kept?
Keep the relevant time, source, prompt, output, approval, action and system information, using the business’s normal safeguards and avoiding unnecessary copies of sensitive data.
4. Does every wrong AI answer require an incident response?
Every reported error deserves assessment, but the response should match the impact. A harmless draft correction needs less escalation than a disclosure or consequential decision.
5. Who should own AI incident response?
Nominate an owner who can pause the workflow and coordinate the right people, while involving specialist advisers or decision-makers when the impact requires them.
6. Should a business tell customers about an AI error?
That depends on what happened and the applicable obligations. Communication should be truthful, timely and clear about correction and support when people may be affected.
7. How can a business prevent a repeat?
Find the process cause, then change the source, permission, approval, training, connector, prompt or fallback that allowed the error instead of relying only on reminders.
8. What is the best first step for AI incident response NZ planning?
Write a one-page response card that tells staff how to stop the workflow, contain the issue, contact the owner, record facts and start a safe correction.
Leave a Reply