A small business often knows that an AI tool could save time before it knows exactly what might go wrong. One person is using it to draft customer replies, another is summarising meetings, and a third is testing an automated connection to internal files. Each use may look harmless on its own. Together, they can create unclear ownership, inconsistent data handling and decisions nobody can easily explain.
That is where an AI risk register NZ approach becomes useful. A risk register is a short, living record of the AI uses a business is considering or already operating, the possible impacts, the controls in place and the person responsible for reviewing them. It turns vague concern into a practical conversation about what to do next.
This is general operational guidance, not legal, privacy, cybersecurity, financial, employment, medical or cultural advice. Seek appropriate specialist input when an AI use involves sensitive information, regulated work, safety, important decisions about people or matters requiring Māori governance.
An AI risk register is not a document designed to stop experimentation; it is a working view of where the business needs more care.
The aim is proportionate oversight. A low-risk drafting task may need a light check, while a customer decision, staff assessment or connected action needs a much stronger control.
Start by listing real uses, not abstract fears
Begin with what people are actually doing. Ask where AI is being used to draft, summarise, classify, recommend, predict, search, create images or take actions in another system. Include approved experiments and informal uses that staff may have started without a formal process.
Record the business purpose in plain language. “Helps prepare a first draft of a routine internal update” is more useful than “AI productivity”. A clear purpose makes it easier to decide whether the use is still appropriate when the tool, data or audience changes.
Give every use an owner
Ownership does not mean one person must do all the work. It means someone is accountable for making sure the use has a purpose, suitable controls, a review date and a route for concerns.
The owner may be the business operator, a team leader or a person responsible for a particular process. Name a backup where practical. If nobody owns a use, it can continue long after the original experiment has changed into a dependency.
Describe who and what could be affected
For each use, note the people, information, systems and business outcomes involved. A private brainstorming task may affect only the staff member using it. A tool that drafts customer messages may affect reputation, trust and a person’s ability to get accurate information.
Consider privacy, security, accuracy, fairness, accessibility, confidentiality, intellectual property, cultural interests, cost, reputation and operational resilience. You do not need a long essay for every row. A few specific sentences are better than a long list of generic warnings.
Separate likelihood from impact
A risk register becomes more useful when it distinguishes how likely a problem is from how serious it would be. A wrong internal headline may be easy to correct. A wrong eligibility explanation, disclosure of personal information or unauthorised system action may require a much stronger response even if it seems less frequent.
Use a simple scale such as low, medium and high, with a short description of what each level means for the business. Avoid pretending that the score is mathematically exact. Its value is in helping the team prioritise attention and agree on what extra control is required.
Record the main failure modes
Think about how the use could fail in practice. The output may be wrong, incomplete, biased, out of date or too confident. The input may contain personal or confidential information. A connector may expose more files than intended. A person may approve the result without checking it. A tool change may alter behaviour without anyone noticing.
Write failure modes as events rather than labels. “Customer receives an incorrect delivery condition” gives the team a clearer starting point than “accuracy risk”. It also makes the right control easier to discuss.
Match controls to the use
Controls should change the workflow, not merely decorate the register. Possible controls include approved tools, limited permissions, anonymised test data, source checks, human approval, two-person review, activity logs, a manual fallback, staff training, a stop instruction and a clear correction process.
For low-risk drafting, a person may review the final result before sharing it. For work involving money, health, safety, legal rights, employment or eligibility, the business may need a qualified or authorised person to make the final decision. An AI suggestion should not quietly become an approval.
Ask where information is processed
Record what information the use needs, where it is stored or processed, who can access it and how long it may be retained. A tool that handles only public facts presents a different concern from one that receives customer messages or staff records.
Keep the data minimised. If a workflow works with a general description or an anonymised sample, do not use identifiable information simply because it is convenient. Check supplier terms and settings carefully, especially when processing may occur outside New Zealand or when the data has cultural significance.
Make human review meaningful
A line in a policy saying “a human checks the output” is not enough if the reviewer has no time, information or authority to reject it. Define what the reviewer is checking and what happens when the answer is uncertain.
For an important customer message, the reviewer might confirm the source, names, dates, conditions, tone and next action. For an internal summary, the reviewer may compare the key points with the original record. For a recommendation, the reviewer should understand the evidence and make the decision independently.
Add triggers for escalation and pausing
Write down when the business must slow down. Triggers might include a new data type, a new connector, a changed audience, a repeated error, a sensitive customer situation, a result that cannot be explained or a use that begins influencing a person’s opportunity or outcome.
Make the stop action practical. Staff should know who to contact, how to prevent another output from being sent and how to preserve the relevant information without making unnecessary copies. A risk register is only useful if it supports action during pressure.
Set a review date and a change trigger
Every row needs a date for review, but calendar reviews are not the only trigger. Revisit the use when the tool changes, the business adds a connector, the source material changes, a new audience is introduced or an incident or near miss occurs.
Ask whether the benefit is still real. A use that once saved time may now require so much correction that it is no longer worthwhile. Retiring a weak use is a sign of control, not a failure of innovation.
Use the register in weekly decisions
A register should not disappear into a shared folder. Use it when approving a pilot, choosing a supplier, preparing staff guidance, reviewing an incident or deciding whether to scale a workflow.
Keep the format simple enough to update. Useful columns may include use name, purpose, owner, data involved, affected people, risk level, failure mode, controls, evidence of testing, escalation trigger, review date and current decision. A small business can begin with a spreadsheet or a page in its normal records system.
Build trust through visibility
Staff are more likely to raise concerns when the process is clear and blame is not the default response. Explain why a use is approved, what must not be entered and how people can question an output. For customer-facing systems, decide how the business will be transparent and how a person can request help or correction.
Keep additional care in mind when AI touches Māori data, iwi, hapū, whānau or Māori organisations. The right governance may involve people and principles beyond a general business checklist. Do not assume that a generic control is enough for every context.
Start small and improve the register
Choose five real uses and complete the register with the people who perform the work. Prioritise the use with the biggest potential impact or the weakest existing control. Run a short pilot, record what happened and update the row.
For a New Zealand small business, an AI risk register does not need to become a corporate bureaucracy. Used well, it gives the owner a shared picture of where AI helps, where human judgement must remain visible and what the business will do if conditions change.
Frequently asked questions
1. What is an AI risk register?
It is a living record of AI use cases, possible impacts, owners, controls, review dates and decisions that help a business manage adoption responsibly.
2. Does every AI experiment need a detailed risk assessment?
No. The assessment should be proportionate, but every use deserves enough review to identify its purpose, information, affected people and basic controls.
3. What should an AI risk register include?
Include the use, purpose, owner, data, affected people, failure modes, risk level, controls, escalation triggers, review date and current decision.
4. Who should own an AI risk?
A person who understands the process and can arrange controls, pause the use or escalate concerns should be named, with a backup where practical.
5. How should a business score AI risks?
Use a simple likelihood and impact scale with clear descriptions. The score is a prioritisation aid, not a claim of mathematical certainty.
6. When should an AI use be paused?
Pause when sensitive information is involved, errors repeat, a connector changes, the output cannot be explained or the use starts affecting important decisions about people.
7. How often should an AI risk register be reviewed?
Set a regular review date and revisit the entry sooner when the tool, data, audience, process or risk changes, or when an incident or near miss occurs.
8. What is the best first step for AI risk register NZ planning?
List five real AI uses in the business, name an owner for each and add one specific failure mode and control before approving any wider rollout.



Leave a Reply