A policyholder rings to report a smashed phone. An AI agent takes the call, records it, transcribes it, pulls the policy, asks for photos by text, runs the device's IMEI against a stolen register, and passes a computer vision model's damage rating to an assessor. Eight separate things happened to that person's information in about four minutes, and every one of them is covered by the Privacy Act 2020.
None of that is a reason to avoid AI in claims. Our founder spent sixteen years in device repair and insurance assessment, and the claims AI built there ran inside the same law. It is a reason to know which parts of the Act each step touches, because the Act was written around what an agency does with information, and AI does a lot more with it, a lot faster.
This guide walks through the claim from first call to final decision and maps each step to the Information Privacy Principles. It covers the change most insurers and brokers have not caught up with yet, IPP 3A, which started on 1 May 2026, and the Biometric Processing Privacy Code, which now applies in full. It is general information to help you ask better questions. It is not legal advice, and a claims AI project should have a privacy lawyer and a Privacy Impact Assessment behind it.
Which privacy principles apply to AI in insurance claims?
All of them, at different points in the claim. The Office of the Privacy Commissioner's guidance on AI and the Information Privacy Principles groups them into three stages: how you collect information (IPPs 1 to 4), how you use and protect it (IPPs 5 to 10), and how you share it (IPPs 11 and 12). The OPC is plain that the Privacy Act applies to everyone using AI tools in New Zealand. There is no separate AI law to wait for.
The numbering still runs 1 to 13. The new principle slots in as IPP 3A, so there are fourteen in practice. For a claims team, the useful way to hold them is against the stages of a claim.
| Claim stage | What AI does there | Principles that matter most |
|---|---|---|
| Intake | Answers the call, transcribes, collects details and photos | IPP 1 purpose, IPP 3 telling the claimant, IPP 4 fair collection |
| Gathering from others | Pulls repairer reports, assessor notes, witness details, database checks | IPP 2 source, IPP 3A telling people you collected indirectly |
| Assessment | Rates damage, summarises documents, scores fraud risk | IPP 8 accuracy, IPP 10 use limits, IPP 5 security |
| Decision | Recommends settle, repair, replace or investigate | IPP 8 accuracy, IPP 6 and 7 access and correction |
| Sharing | Sends data to repairers, the insurer, cloud and AI providers | IPP 11 disclosure, IPP 12 overseas, IPP 9 retention |
What does the Act require at claims intake?
Three things, in plain terms. Collect only what you need for a lawful purpose (IPP 1). Tell the person what you are collecting, why, who will receive it and how they can see and correct it (IPP 3). And collect it in a way that is lawful, fair and not unreasonably intrusive (IPP 4).
For an AI agent on the phones, IPP 3 is the one to design first. The claimant should hear early in the call that they are speaking with an AI, that the call is recorded and transcribed, and what it will be used for. We made the same argument about disclosure in the escalation experience post, and it holds twice over in claims, where the caller is often stressed and the information is sensitive. The OPC's expectations for generative AI say it directly: if a tool is used in a way likely to affect customers and their information, they must be told how, when and why.
IPP 1 is where AI intake scripts drift. A conversational agent can ask anything, and it is tempting to have it ask everything. Write down the fields each claim type needs to open a file, and keep the agent to those. Our claims triage guide covers the intake flow itself. The privacy discipline is deciding what it will not ask.
What is IPP 3A and why does it matter for claims?
IPP 3A is a new notification duty for information you collect from someone other than the person it is about. It came in with the Privacy Amendment Act 2025 and has applied since 1 May 2026 to information collected from that date. The OPC's IPP 3A guidance uses an insurance claim as its example: an insurer asks a repairer about damage to a claimant's car, including whether the repairer thinks she was responsible. That opinion is her personal information, collected indirectly.
Claims run on indirect collection. Repairer quotes, assessor reports, loss adjuster notes, IMEI and stolen-device lookups, third-party driver details, witness statements. When AI pulls these together automatically, the volume of indirect collection goes up and nobody sees it happen. Under IPP 3A, unless an exception applies, you must take reasonable steps to tell the person, as soon as reasonably practicable, that the information was collected, why, who will receive it, who holds it, any law authorising the collection, and their rights to access and correct it.
There are exceptions, and two of them matter for claims. One applies where the person is already aware. Another applies where telling them would prejudice the purpose of the collection, which is the ground a fraud investigation would need to rely on. Relying on an exception should be a recorded decision for a specific situation. It is not a setting you switch on for the whole pipeline.
How do accuracy and fairness apply to AI assessment?
IPP 8 says an agency must take reasonable steps to make sure personal information is accurate, up to date, complete, relevant and not misleading before it uses it. In claims, an AI output is often exactly that kind of information. A damage rating, a transcript summary, a fraud score. Each one is information about the claimant that the insurer is about to act on.
The OPC's AI guidance asks a pointed question here: how are you testing that AI tools are accurate and fair for your intended purpose? For a claims model that means testing on real claims, measuring where it gets things wrong, and knowing which kinds of claimant or damage it performs worst on.
We learned this on Smart Assess, the computer vision model we trained on more than 216,000 device photos. Every AI determination was confirmed by an authorised technician, and every correction fed back into training. We built it that way for the insurers' confidence. It also happens to be what IPP 8 looks like when you engineer it in. The OPC recommends the same pattern for generative AI: have a person review the output before the agency takes action because of it.
Can AI make claims decisions on its own?
The Privacy Act does not ban automated decisions outright, but the OPC's expectations point firmly towards a person reviewing AI outputs before the agency acts on them. For anything adverse to the claimant, such as a decline, a reduced settlement, or a referral to fraud investigation, we would not ship a system without that review step. The practical design is the one that worked in our assessment work: AI handles the clear-cut approvals at speed and flags everything else, with its reasons, for a person.
IPPs 6 and 7 add a second reason to keep a person in the loop. A claimant can ask for the information held about them and ask for it to be corrected. If a fraud score or damage rating sits on their file, you need to be able to find it, explain what it is and correct it. The OPC notes that some AI tools make access and correction hard in practice, so build the record so that each AI output is stored as a field on the claim, with the model version and the inputs it saw.
How should fraud detection be handled?
Carefully, and mostly with the same rules. Fraud checks are a legitimate part of claims handling, and our IMEI verification case study shows how much a single well-placed check can catch at intake. The privacy questions are about purpose and fairness. Was the claimant told that their device and claim details may be checked against external registers? Is the information used for the fraud check the same information collected for the claim (IPP 10)? Is the flag accurate enough to act on (IPP 8)?
A fraud flag should route a claim to a person with the evidence attached. It should not decline the claim by itself.
Does the Biometric Processing Privacy Code apply to claims AI?
Sometimes, and it depends on what the system does with a voice or a face. The Biometric Processing Privacy Code 2025 came into force on 3 November 2025, and agencies that were already processing biometrics had until 3 August 2026 to comply. It covers automated processing of biometric information to verify, identify or categorise people, and the OPC lists voice among its examples.
Our reading of the OPC's guidance is that recording and transcribing a claims call is not, on its own, biometric processing. Using the caller's voice to verify who they are would be. So would a system that analyses the voice to infer emotion, stress or mental state, and the code's rule 10 restricts that kind of biometric categorisation unless a specific exception applies. Some vendors sell "sentiment" or "stress detection" on claims calls as a fraud signal. Get legal advice before you switch that on.
The same logic applies to images. A photo of a cracked phone screen is not biometric information. A selfie matched against a driver licence photo to confirm identity is.
What about cloud providers, overseas models and security?
Sending claim data to an AI or cloud provider that holds and processes it only on your behalf is generally not a disclosure under the Act, which means IPP 12 on overseas disclosure does not usually apply. You remain responsible for the information. The OPC's guidance on sending information overseas is clear that the position changes if the provider uses the information for its own purposes. For AI, the obvious own purpose is training its models. Check the provider's terms, and if they use your data for training, treat that as a disclosure and deal with IPP 11 and 12 properly. The OPC's generative AI expectations say not to put sensitive information into a tool unless you have confirmed the provider will not retain or disclose it.
IPP 5 requires reasonable security safeguards, and the OPC's guidance names prompts and training data specifically. In a claims system that means the recordings, transcripts, uploaded photos, prompts sent to the model and the model's outputs. IPP 9 means none of it should be kept longer than you need it for a lawful purpose, so set retention periods for recordings, transcripts and photos, and delete on that schedule.
What happens if AI causes a privacy breach?
The same thing that happens with any breach. If a breach has caused or is likely to cause serious harm, it is a notifiable privacy breach, and you must tell the Privacy Commissioner and the affected people as soon as practicable. The OPC's breach guidance says it expects notification within 72 hours of becoming aware of a notifiable breach. Failing to notify the Commissioner without reasonable excuse is an offence under section 118, with a fine of up to $10,000.
AI adds new ways for a breach to happen. A transcript sent to the wrong claimant. A model summary that pulls in details from another file. A shared upload link that was not tied to the right claim. Build the breach assessment for these into your incident process before launch.
How do you start a claims AI project that holds up under the Act?
Start with a Privacy Impact Assessment, and do it before you choose a vendor. The OPC recommends a PIA before any use of AI, and its generative AI expectations add that senior leadership should explicitly approve the tool after considering the risks. A PIA written for a specific claims workflow is also the fastest way to find the design decisions that matter, because it forces you to trace every piece of information from intake to deletion.
We run this as the first step of our three-phase delivery model, and it is where most of the useful design happens. The build that follows is simpler because the questions have already been answered.
Privacy checklist for AI in NZ insurance claims
1. Do a Privacy Impact Assessment first.
Trace every piece of claim information from intake to deletion, including what goes to AI providers. Get senior leadership sign-off on the tool.
2. Disclose the AI at intake.
Tell claimants early that they are dealing with an AI, that the call is recorded and transcribed, and why. Update the privacy statement to match.
3. Map your indirect collection.
List every source the system pulls from other than the claimant: repairers, assessors, registers, third parties. Build the IPP 3A notice into the workflow and record any exception you rely on.
4. Keep a person on adverse decisions.
AI can approve clear-cut claims and flag the rest. Declines, reduced settlements and fraud referrals go to a person with the evidence attached.
5. Store AI outputs as correctable records.
Damage ratings, summaries and fraud scores sit on the claim with the model version and inputs, so you can answer access and correction requests.
6. Check the biometrics line.
Transcription is fine. Voice verification or emotion analysis brings in the Biometric Processing Privacy Code. Get advice before using either.
7. Read your AI provider's data terms.
Confirm it does not train on or retain your claim data for its own purposes. Set retention periods for recordings, transcripts and photos.
Claims AI is where we started, and it is still the work we know best. ClaimPilot and our insurance and property practice are built on the same human review and audit trail patterns described here. If you are scoping AI for intake, assessment or fraud checks and want the privacy design done before the build, talk to us.