Skip to main content

The AI safety and privacy checklist for New Zealand club committees

General information for committees adopting AI tools — the questions to ask any vendor about member data, the approval and audit rules that keep humans accountable, a simple club AI policy you can adapt, and the red flags that should stop a rollout.

By The ClubHelix team · Published 31 July 2026 · 7 min read

Editions: AustraliaNew ZealandUKUSACanadaIrelandSouth Africa

New Zealand edition. This guide is written for volunteer-run clubs in New Zealand. Where rules differ — grants, tax, incorporation, safeguarding — follow the New Zealand-specific pointers below or check with your national body.

Clubs hold surprisingly sensitive data for organisations run from kitchen tables: children's names and dates of birth, medical notes, home addresses, payment records, sometimes safeguarding matters. So when AI tools arrive — and they've arrived — the committee question isn't "is AI safe?" in the abstract. It's concrete: what will this specific tool see, what can it do without a person, and who answers for it?

This guide is the checklist version of those questions. It's general information to help your committee think clearly, not legal advice — privacy law differs by jurisdiction and club structure, and your governing body may have its own AI guidance worth checking first.

Part one: the member-data questions for any AI vendor

Put these to any product that touches club data with AI — including us. A good vendor answers all five in plain language; a vague answer to any of them is your answer.

1. What data does the AI actually see? The right architecture is minimum necessary: the assistant sees what's needed to answer the question asked, not a standing copy of your database. Aggregates instead of records where possible — "142 paid members" rather than 142 names. In ClubHelix, for example, the membership tool an assistant can call returns counts by status, not personal details, and every request goes through the same permission checks as a human admin.

2. Is our member data used to train models? The answer must be an unqualified no. Training on customer data means your members' details could influence outputs shown to strangers. Get it in writing — it's usually in the vendor's privacy documentation, and its absence is a red flag.

3. Whose permissions does the AI inherit? An assistant should act as a named person, bounded by that person's actual role — never as an all-seeing system account. If the person loses their role, the assistant's access must die with it, automatically. Ask specifically: "if the admin who set this up leaves the club, what happens to the AI's access, and when?" The only good answer is "instantly, without anyone remembering to do anything."

4. Can the AI reach beyond our club? Multi-club platforms must isolate clubs from each other at the database layer, and AI access must inherit that isolation — a token or connection issued for your club should be structurally incapable of reading another club's data, and vice versa. "Our AI respects tenant boundaries" is the claim; "row-level security applies to every AI request" is the mechanism. Ask for the mechanism. (Our security page documents ours.)

5. Where's the audit trail? Every AI read and write should be logged with the acting person's name, timestamp, and what was touched — in a log the committee can search, like the club's normal audit log. If AI activity is invisible, accountability is impossible.

Part two: the approval rules that keep humans in charge

Data protection is half the story; the other half is action protection. These four rules are the difference between AI as a drafting assistant and AI as an unsupervised volunteer with the club's keys:

  • Nothing member-facing without approval. Emails, SMS, news posts, website changes — AI may draft, humans approve and send. The platform should enforce this (drafts that structurally cannot send themselves), not merely recommend it. In ClubHelix, an assistant's newsletters land unsent with no audience selected, its news posts land unpublished, and its page edits wait in the editor as drafts — a person always completes the action.
  • Never money. Fees, refunds, payouts, pricing: no AI write access, full stop. Read access for reporting ("what did the shop take last month?") is fine and useful.
  • Never bulk member changes. Approvals, deletions, status flips across many records are exactly where one wrong AI assumption scales into a season-sized mess.
  • Explicit confirmation for every change. Even permitted, draft-only changes should require the assistant to state what it's about to do and receive an explicit go-ahead — a "dry-run first" discipline that turns AI mistakes into previews rather than incidents.

Every AI action lands in the same admin queues people use — drafts to review, never faits accomplis.

Part three: a club AI policy you can adapt

Most clubs need one page, not a framework. Adapt this:

[Club name] AI use policy

  1. AI tools may help draft communications, website content and reports, and answer questions from club data through approved, committee-authorised connections only.
  2. Every AI-drafted item is reviewed and approved by a committee member before it is sent or published. The approver is responsible for the content as if they wrote it.
  3. AI connections are set up by named admins, use read-only access unless the committee approves drafting, expire at most every 12 months, and are revoked immediately when the owner leaves their role.
  4. AI tools are never given member personal or medical details in prompts, and never make decisions about individual members (selection, discipline, refunds, safeguarding).
  5. Sensitive communications — injuries, disciplinary matters, bereavements, safeguarding — are written by people.
  6. The secretary keeps a list of active AI connections and reviews it each committee cycle.

Clause 4's first half deserves emphasis because it's about your volunteers' habits, not the vendor: the biggest real-world leak risk is a helpful person pasting a member's medical form into a general-purpose chatbot to "summarise it". Platform-connected assistants with scoped access exist precisely so nobody needs to paste anything — see how a scoped connection works.

Scoped, revocable, logged - the connection settings a committee should expect to see.

Part four: red flags that should pause a rollout

  • The AI can send or publish by itself. Any tool where a model's output reaches members without a human click is mis-designed for volunteer organisations, whatever its other merits.
  • One shared "AI login". If the assistant acts as a shared account rather than named people, your audit trail is theatre.
  • No off switch. Revocation should be self-service and instant. "Contact support to disable" means days of exposure after a laptop goes missing.
  • Vague data answers. "We take privacy seriously" is not an answer to "is our data used for training?".
  • Pressure to skip review. If a vendor's pitch centres on removing the human from the loop ("fully autonomous club admin!"), remember that the loop is where your club's accountability lives.

The mindset that makes this easy

Committees sometimes brace for AI as a governance ordeal. It isn't, if you notice one thing: these are the same rules you already apply to people. New volunteers don't get the banking login on day one; access dies when someone leaves; two people check the newsletter; the committee minutes record who decided what. AI governance is volunteer governance with better logging. Adopt the checklist, write the one-page policy, start read-only, and treat the assistant like a capable new volunteer on probation — trusted with drafts, never with the send button, reviewed until the trust is earned. That posture gets you the genuine benefits with none of the 2am-email horror stories.

Frequently asked questions

Do we need to tell members we use AI?

Transparency costs nothing and buys trust: a line in your privacy communications ("we use AI tools to help draft communications and answer administrative questions; a committee member reviews everything before it's sent, and your personal details are not used to train AI models") covers most clubs well. If your club is subject to specific privacy legislation, check its notice requirements or ask your governing body.

A volunteer already pasted member details into a chatbot. How bad is it?

Treat it like any small data spill: work out what was shared, delete the conversation where the tool allows it, remind the team of the policy, and note it at committee. Then remove the temptation — give people a scoped, connected assistant that can answer the question properly, so pasting stops being the path of least resistance.

Can we use AI for team selection or member decisions?

Analysis, yes — "show attendance by player" is reporting. Decisions, no. Selection, discipline and refunds are judgement calls the committee owns, and outsourcing them to a model is unfair to members and indefensible when questioned. Keep AI on the information side of decisions about people.

Who on the committee should own AI?

Whoever owns club data today — usually the secretary or registrar. They maintain the connection list, run the annual review, and are the named owner of at least one connection. Making it a named role (an hour a season, honestly) prevents the classic failure where everyone assumed someone else was watching.