AI — Won't That Steal All My Data?
The number-one question NZ business owners ask before any AI conversation. Here's the honest technical answer, with a real case study from a regulated NZ finance customer where we built data security in first and the AI features second.
It's the first question I get asked in basically every introduction.
"AI? Won't that steal all my data?"
Fair question. The honest answer is: it depends entirely on how it's built. A consumer ChatGPT account, used carelessly, can absolutely leak your data into model training. A purpose-built application running on the right infrastructure, with the right controls, can be more secure than the spreadsheets and email threads it replaces.
This post is about the difference between those two worlds. With a real example.
The customer
Without naming names: a New Zealand non-bank finance company. Regulated. Customer data is sensitive — loans, IDs, financial statements, beneficial owner records. The kind of business where one data breach ends the company.
They came to us with a problem they'd had for years. Too much time was being eaten by admin — meeting notes that nobody had time to write up, drawdown letters that had to be typed by hand, customer records that lived across email, spreadsheets, and a CRM nobody trusted. The team wanted to spend more time with customers and less time chasing paperwork about customers.
AI was the obvious lever. But this is also a business where "let's just pipe everything into ChatGPT" was an instant non-starter.
What "data security first" actually meant
Before we wrote a single AI feature, we made the platform decisions. In this order:
1. Data lives in Australia, not the United States
We deployed on Supabase with the database hosted in Sydney (AWS ap-southeast-2). That puts customer data inside the Australia-NZ legal jurisdiction. NZ Privacy Act 2020 IPP 12 — the restriction on sending personal information offshore — is satisfied without us having to negotiate model clauses with US providers.
2. App servers also in Sydney
The Next.js application runs on Fly.io, with the production app machine pinned to the Sydney region (syd). Application traffic never traverses a US datacentre. Latency for NZ users is single-digit milliseconds.
3. Both vendors are SOC 2 Type 2 audited
Supabase: SOC 2 Type 2 + HIPAA (the Pro plan). Fly.io: SOC 2 Type 2.
Which means: an independent auditor has verified, over a sustained period, that the operational controls these providers claim to have actually work. Not "we say we're secure" — "we've been audited that we're secure". For a regulated finance customer, this is non-negotiable.
4. Row-level security on every single table
This is where it gets technical, and it matters.
In a normal database, every row is accessible to whoever has the connection string. The application code has to remember to filter to the right user. If a developer forgets, data leaks between tenants.
We used PostgreSQL Row-Level Security (RLS) policies on every single customer-facing table. The database itself enforces the rules. A query from User A for User B's data returns zero rows — not because the app filtered, but because the database refused. Even a bug in the application can't leak data across the boundary.
This is the most under-appreciated security control we ship. We test it the same way we test functionality — with cross-tenant access tests in CI that try to read another tenant's data and verify they fail.
5. Hash-chained, append-only audit log
Every write to the database — every record update, every document signed, every login, every export — writes a row to a single audit_log table.
Each row contains a SHA-256 hash of the previous row's hash plus the new row's contents. A daemon process re-walks the chain nightly. If a single row has been altered or deleted, the chain breaks and we're paged.
This turns the audit log into something you can hand to a regulator and say "here's every action taken in this system in the last six months, mathematically proven to be intact". Banks have been spending money on this kind of integrity since the 1970s; we ship it as standard.
6. MFA-required, work-email-only sign-in
No public sign-up. No personal Gmail accounts. Sign-in is via Microsoft Entra ID (the customer's existing Microsoft 365 tenant) with MFA enforced at the IdP. We don't store passwords; we don't handle them. The auth flow is OAuth + OIDC, not a password form.
If the customer offboards a staff member from Microsoft 365, they lose access to the platform instantly. No "we need to remember to disable their account" admin debt.
7. Customer prompt data never trains anyone's model
When the platform calls an AI provider (Anthropic / Deepgram), it uses the API tier with training opt-out by default — and we configured the explicit no-train headers on every call. Customer transcripts, customer data, customer documents are processed inline and discarded. They never become training data for anyone.
This is the single biggest misconception about AI in business: that "using ChatGPT" means your data trains the model. The API tier doesn't work that way, and we configure it explicitly.
What we built on top
Once the security posture was in, the AI features were straightforward.
Meeting recordings → structured records
The team spends most of their day in customer meetings. Recording was already happening, but the recordings sat unused — nobody had time to listen back.
We shipped a live diarised transcription pipeline. Recording starts when the meeting starts; transcript appears live; speakers are auto-identified; an AI summary lands on the customer record within a minute of the meeting ending. Action items get extracted, attached to the right person, and surfaced on the deal.
The recording goes into encrypted Supabase Storage. The transcript is searchable. The customer's file is up to date by the time the team member is back at their desk.
Document generation
Drawdown letters, sign-off documents, client correspondence — all of which used to be typed by hand. We built a template + AI fill pipeline where the template defines the legally-reviewed structure and the AI fills the variables from the customer record. Every generated document is reviewed by a human before it goes out. The human is faster, the legal team is happy that the structure can't drift, and the customer gets the letter the day they needed it instead of three days later.
New CRM, designed around the way they actually work
The old CRM was a generic SaaS tool that the team hated. We replaced it with a custom CRM built around the actual flow of a deal at this business — application → review → approval → drawdown → ongoing relationship management. Pipeline visible at a glance. Tasks attached to stages. Voice notes that update the record without a human typing.
The net result the team noticed wasn't "we have AI now". It was "I'm spending more time talking to customers and less time documenting customers".
What changed for the business
We don't share customer numbers without permission. What we can say:
- More face time with customers. The senior team reclaimed the time that used to go on writing up notes and drafting documents. That time goes back to talking to customers, which is the actual job.
- Faster turnarounds. Drawdown letters that used to take a day now take 10 minutes. Customer queries that used to wait until someone "had time" get answered same-day.
- No data security concerns. Their compliance team signed off on the architecture before we shipped. The platform has been running with zero security incidents.
The short version
AI doesn't have to steal your data. Built well, on the right infrastructure, with the right controls, it's safer than the email threads and spreadsheets it replaces.
The things that matter:
- Where the data lives — Sydney, not Virginia.
- Who has access — RLS, not "we trust the app".
- What's logged — every write, mathematically signed.
- Who signs in — your existing identity provider, MFA enforced.
- What the AI sees — only what you tell it, never trained on.
If you're considering AI for a business where data sensitivity is the gating concern, talk to us. We've done this before. We'd rather you build it right the first time than have to fix it later.
Daniel Thomson runs AiTearoa — AI consulting + custom builds for New Zealand businesses. We build data security in first and the AI features second.