Privacy Policy
Version beta-1.0 · Effective 2026-07-19 · Beta — early access
Edward Neppl (ABN 39 804 625 526) trading as Caira (“we”, “us”) provides software for NDIS and disability support providers in Australia to record shifts, progress notes, incidents, and related care documentation.
Contact for privacy: admin@caira.net.au · 60 Fawcett Street, Mayfield NSW 2304, Australia
This Policy explains how we handle personal information and sensitive information (including health information) under the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs). It applies to provider organisations, their workers, and individuals (including NDIS participants) whose information is recorded in Caira.
Participant and care records. When a provider organisation (“Provider”) enters or authorises records about participants and supports, the Provider determines why and how that information is handled for service delivery. We process that information on the Provider’s documented instructions under our customer agreement and Data Processing Addendum (DPA). In industry terms: the Provider is the controller; Caira is the processor for those records.
Where more than one Provider organisation shares a participant record, each Provider is an independent controller (not a joint controller). Caira is the processor for each.
Our own records. We are an independent APP entity (controller) for limited account, billing, security, support, and product-operations information we need to run Caira.
If a DPA or enterprise agreement conflicts with this Policy for a Provider’s customer data, that agreement governs for that data.
We collect information that Providers and users submit, that is generated by use of the service, and that we need for security and billing.
We use personal information to:
We do not sell personal information. We do not use participant information for advertising. We do not use participant care content to train third-party foundation models. Production generative AI runs on Google Vertex AI Paid in australia-southeast1 (Sydney) under contracts that prohibit customer-content training. The Gemini Developer API may be used for local/development only and is not Australia-region-pinned.
Some features use AI (Google Vertex AI Gemini in Australia when configured, or Gemini API for development) to help draft notes, ask clarifying questions, summarise meetings, or (if enabled) transcribe audio / OCR images.
Text processing. Before free-text care notes are sent to an AI provider for drafting assistance, we apply a local scrubbing step that removes structured personal identifiers (emails, phone numbers, NDIS/Medicare numbers, and dates of birth). Names, place names, and other narrative context in care notes are kept so summaries stay accurate. Scrubbing reduces risk for those identifier types; it is not a guarantee that no identifying information remains in the text sent to the model.
Audio and images. Shift spoken notes prefer on-device transcription where available. Meeting recordings (when the Meetings feature is enabled) send raw audio to Google Vertex AI Gemini in australia-southeast1 (Sydney) for transcription — audio cannot be scrubbed beforehand and may contain sensitive health or support information. Every person present must give informed consent in-product before recording starts. After transcription, meeting summaries are generated from a scrubbed transcript. Images sent for OCR also cannot be fully scrubbed beforehand and are consent-gated / feature-flagged.
AI output is assistance only. Caira does not make clinical or NDIS funding decisions. Humans must review and confirm records before relying on them.
We disclose personal information:
A current sub-processor list is in the DPA. We give Providers reasonable advance notice of material sub-processor changes that process their data.
Primary storage. Production primary database, authentication, and file storage are configured with Supabase on AWS Sydney (ap-southeast-2) so core participant and record data resides in Australia. Non-production staging may use other regions and must not hold real participant data.
Overseas processing. Some sub-processors may process information outside Australia (including default PostHog analytics in the US, Stripe, Sentry, Resend, Vercel edge, and Gemini Developer API if used). Disclosures of sensitive information (including Gemini text prompts that may contain health/behavioural content, and all unscrubbed audio/OCR) require express informed consent (APP 8.2) obtained by the Provider. Lower-sensitivity tooling (Stripe billing; consent-gated PostHog without care content; scrubbed Sentry) proceeds under APP 8.1 contractual steps as set out in the DPA. Providers must accept the Privacy Notice & Consent for AI tools (Admin → Settings) before real participant data.
We implement safeguards appropriate to the sensitivity of disability/health records, including encryption in transit, encryption at rest for primary storage, tenant isolation (row-level security), role-based access, least-privilege staff access, audit logging of sensitive actions, and monitoring. No method of transmission or storage is perfectly secure.
We retain information for as long as needed to provide the service and to support Providers’ record-keeping obligations.
Default for care and support records: retained to support Providers’ obligations, including 7 years for incident and reportable-incident records under the NDIS (Incident Management and Reportable Incidents) Rules 2018, and any longer period required by applicable state or territory medical-record laws. Other record types follow the schedule configured for the Provider or required by law.
On subscription termination, Providers may export data during a reasonable window; thereafter we delete or de-identify in line with the DPA.
Erasure / APP 11.2. Where a right-to-erasure workflow is used, de-identification is treated as a form of destruction under APP 11.2 where a non-identifying operational or compliance record must be kept. Identifying fields are stripped; mandatory retention clocks for incidents may still apply to the de-identified or lawfully retained record.
Backups are retained for a limited period and then overwritten.
Individuals may request access to, or correction of, personal information we hold, subject to Privacy Act exceptions.
For participant information we process for a Provider, we will direct the request to that Provider and assist them as described in the DPA. Providers remain responsible for responding to participants/nominees as APP entities.
Complaints: contact admin@caira.net.au. If unsatisfied, contact the Office of the Australian Information Commissioner (OAIC) — oaic.gov.au · 1300 363 992.
We maintain an incident-response process (see our Data Breach Response Plan). For participant and care records we process for a Provider, that Provider retains the primary duty and the decision under the Notifiable Data Breaches scheme to assess and notify the OAIC and individuals. We notify affected Providers without undue delay (within 24 hours of identifying a potential breach, and in any event within 72 hours) and assist with forensics and notification logistics. We assess and notify in our own right for information we hold for our own purposes. Nothing in our customer terms excludes liability that cannot be excluded under the Privacy Act or the Australian Consumer Law.
Caira records information about people receiving disability support, who may be children or otherwise vulnerable. We treat this as sensitive, limit access on a need-to-know basis, and require Providers to obtain any consents needed before entering information.
Caira uses AI to assist humans who draft and review records; it does not make automated decisions that alone determine NDIS funding, clinical care, or Commission reporting outcomes. Ahead of the Privacy Act reform transparency obligations expected from 10 December 2026 (APP 1.7 style automated-decision transparency), we will update this Policy if our product begins making decisions of that kind without meaningful human review.
We will post material changes here with a new version and effective date. Enterprise customers also receive notice under the customer agreement. Continued use after the effective date constitutes acceptance where permitted; material changes may require re-acceptance for organisations.
Related: Terms of Service · Data Processing Agreement