Kula Ops + Intelligence Privacy Policy
Version 2.0 · 31 October 2026
Version 2.0 · 31 October 2026. This Policy replaces the Kula Intelligence Privacy Policy (Version 1.0, 19 June 2026). Kula Ops is part of Kula Intelligence, so one document now covers both. It is separate from the Kula Fitness Privacy Policy, which governs the execution platform. The substance reflects how the service works today.
This Privacy Policy is published by Kula Holdings Pty Ltd (ABN 53 676 723 452) of Sydney, New South Wales, Australia (“Kula”, “we”, “us”, “our”). It describes how we handle personal information in connection with Kula Ops and Kula Intelligence, consistent with the Australian Privacy Principles (APPs) under the Privacy Act 1988 (Cth).
1. What this Policy covers
Kula Intelligence connects the systems a business already runs, builds a model of the business from them, and answers questions in plain language from the business’s own numbers. It is reachable through the Kula Ops app and, as a Model Context Protocol (MCP) server, from an AI client the business chooses.
Kula Ops is the app a team opens every day, published as “Kula” for iPhone, iPad and Mac, for Android and for Windows, and also available in a browser. It gives each person the shift brief, the situations and work that need them, their team’s messages, the Apps the business has switched on, and a way to ask Kula about the business by typing or speaking.
This Policy covers the app, the MCP server, the console and the Team app used to set them up, and the services behind them. It does not cover the AI client a business connects (see §7), the systems a business connects (their own policies apply), or Kula Fitness. Visitors to the kula.digital website are covered by the website section of the Kula Fitness Privacy Policy.
2. Our roles, and whose data this is
Kula operates in two roles, and your rights and our obligations depend on which applies:
- Controller of account information. For the people who open and run a Kula account, and for the staff a business invites into Kula Ops, we are the controller of the account and contact details described in §3.1.
- Processor of business data. For the operational data a business connects to or creates through the service (its members, bookings, sales, accounts, rosters, documents, and the records its team makes in Kula Ops), the business is the controller and Kula acts as a processor on the business’s instructions. We do not decide the purposes for which a business’s data is used. A staff member’s records in Kula Ops (a decision, a task, a message, a timesheet correction) belong to the business they work for.
Health and other sensitive information. A business’s data may include health-related or other sensitive information (for example injury notes or medical limitations). Such information receives heightened protection and is handled only as needed to provide the service on the business’s instructions.
Consents and notices are the business’s responsibility. As controller, each business is responsible for the consents and notices required for it to collect its members’ and staff’s personal information and to instruct us to process it, including any notice its workplace laws require before staff activity is recorded, and any consent the law requires before a conversation is recorded. Kula relies on the business’s representation that it holds them.
3. What we collect
3.1 Account and contact information (Kula as controller)
- Account holders: name, work email, business name, region, timezone, and sign-in identifiers from our identity provider. Billing details if the business subscribes (card data is handled by our payment processor; we hold at most a last-four reference).
- Staff members: display name, work email and/or mobile number, the business and sites they belong to, their role, and the times those details were verified. Nobody is asked for a password. A shared front-desk device may use a short PIN, which is stored encrypted.
- Devices: for each signed-in device, a device credential, the device type and app version, a push address (an installation identifier from Firebase and the push token it maps to), and when the device was last seen. On Apple devices, genuine builds also register with Apple App Attest.
- Preferences and profile: quiet hours, labels, and the job profile a person writes for themselves (their title, duties, what they are good at, how they want Kula to work for them, and their usual working days and hours).
- Support and diagnostics: what you send us when you ask for help, and an app host log a person can choose to paste into a report. Nothing on a device is sent unless the person sends it.
3.2 Business operational data through connections (Kula as processor)
On the business’s instructions, Kula reads and stores a working copy of records from the systems it connects. Depending on the systems, this can include:
- Members and contacts: names, email addresses, phone numbers, membership status and plans.
- Bookings and attendance: classes, visits, check-ins, cancellations.
- Sales and payments: amounts, plans, payment method and status, and limited payment metadata. We hold at most the last four digits of a card and never receive full card numbers.
- Accounting: contacts, invoices and transactions, and where the plan allows, general-ledger data.
- Rosters and timesheets, where a business switches on an App that connects its third-party rostering or time product: who is rostered when and where, shifts worked, start, end and break times, the employing entity and its payroll code for each person. Pay never enters Kula. No pay rate or pay rule is read or stored; the connector drops those fields.
- Marketing and web analytics: advertising performance and spend, and aggregated website metrics (not individual visitor identities).
- Documents: the ops manuals, checklists, job descriptions and other files the business uploads so Kula can work from its own procedures.
What each connector reads, and what it does not, is listed on each connector page.
3.3 What the team creates in Kula Ops (Kula as processor)
Because Kula Ops is where a team works, it also holds the records that work produces:
- Conversations with Kula: the questions a person asks Kula in the app, by typing or speaking, and the answers Kula gives, kept as the business’s record and so Kula can learn how that business works (§6).
- Captures and work items: what a person typed or said to capture a job, the task that came of it, who it is for, and its status.
- Situations and decisions: the picture Kula assembled, the move it suggested, the choice a person made and the reasons they gave, recorded with their name.
- Messages: staff inbox threads and replies, with any photos, PDFs or voice notes attached. A voice note is stored as the words the device wrote out and the sound clip the person chose to send.
- Photos and files: a photo of a docket, a fault, a delivery or a receipt, and a PDF or image shared into Kula, each stored inside the business’s own database or document store.
- Meetings: the words of a meeting a person chose to record, written out on the device, and the summary and actions drawn from them. The sound of a meeting never leaves the device.
- Time entry corrections, through the time entries App: a corrected start, end or break, the original times, and who approved the change.
- Expense claims: the claim and its receipt photo, and the contact the business chose to send it to.
- Agent runs: where a business has switched on an agent, what the run was given, what it did and what it produced.
- Notifications delivered: exactly what each push notification carried, so the record the person saw can be shown again.
3.4 Provider credentials
The keys and tokens a business supplies to connect a system are stored encrypted at rest (AES-256-GCM) in the business’s own database, with the encryption key held separately. They are used only for that connection and are never shared between businesses.
3.5 Usage and audit data
To operate the service, support you and keep an audit trail, we record how the service is used: which tools were called, when, with which credential, how long they took and whether they succeeded; every privileged action; and, for each Kula Ask run, the model used, the number of tokens, the cost, the tools called and the outcome. This is operational telemetry. Conversations with Kula inside the app are the business’s records (§3.3); conversations with an AI client a business connects itself never reach us (§4).
4. What we do not collect or do
This matters as much as what we collect. The service:
- Does not see the conversations a business has with an AI client it connects itself. When a business connects Claude, ChatGPT or another client to the MCP server, Kula receives the tool calls and returns the results; the prompts and answers stay with that client and its provider, and we keep only the tool-call record. Conversations with Kula inside the Kula Ops app are different: those are kept for the business (§3.3).
- Does not access your AI client’s memory, chat history or uploaded files. The MCP server reads only the business’s connected data from the business’s own database.
- Does not record sound without a person starting it, and never receives it. A meeting is recorded only when a person starts it, the app shows that it is recording, and the sound stays on the device. Speech is turned into text on the device where the device can; on older devices Apple’s speech recognition service may be used under Apple’s terms.
- Does not ask for your location. The app has no location permission.
- Does not move money. It never charges a card, issues a refund, transfers funds or runs payroll, and no pay rate enters the service.
- Sends nothing outside the business on its own. Kula may message a staff member inside Kula Ops. A message to a member, a supplier or any outside party, or a change to an outside system, happens only when a person explicitly asks for it.
- Does not use third-party analytics or advertising SDKs in the app. There is no tracking, no advertising identifier and no profiling for advertising.
- Does not sell personal information, ever, and does not disclose it for third parties’ marketing.
- Does not use one business’s data for another business. There is no cross-business read path.
- Does not let its AI providers train on business data, and engages them under terms that do not permit it. Kula’s own learning across businesses uses de-identified information only (§6).
5. How we use data
- To provide the service: to assemble the brief, raise situations, file work, carry messages, read connected systems and answer questions, within the access each business grants.
- To read and act on the team’s communications for the business: to file a task a person asks for in a message, brief the right person, answer a question that refers to a thread, and, where the business instructs it, review communications for workplace concerns such as bullying or harassment, or confidential information leaving the business, and report to the people the business nominates.
- To carry out what a person asks: through the Apps the business has switched on, to write a confirmed timesheet correction back to its rostering product, send a member message a person approved through the business’s own messaging account, email an expense claim to the contact the business chose, and, where the business also uses Kula Fitness, pass a person’s messages, files and cover decisions to Kula Fitness to carry out.
- To notify: to message a staff member inside the app and send push notifications for the shift brief, a time-bound situation and a new message. A notification may carry a member’s or colleague’s name. Never a sound, never a badge.
- To learn and improve: to keep a business’s conversations, captures and decisions so Kula answers that business better over time, and to improve Kula’s models, classifiers and skills for every business using de-identified, aggregated information (§6).
- To operate and support: diagnostics, troubleshooting, security, audit and billing.
- Optional semantic search: only where a business opts in, to generate embeddings from its text so its data is easier to search. This is off by default.
Direct marketing
We may send account holders service communications about the product (onboarding, security and feature updates). Where we send promotional messages, we include a way to opt out and honour it promptly, consistent with the Privacy Act 1988 (Cth) and the Spam Act 2003 (Cth). We do not use a business’s members’ or staff’s personal information for our own marketing.
6. How Kula uses AI
Kula uses AI in four places, and each reply in the app says which produced it.
- Rules and assembly, with no model. The shift brief is assembled in code. Many answers come from rules.
- Apple’s on-device model, which runs on the person’s own iPhone, iPad or Mac. Nothing leaves the device.
- Apple’s Private Cloud Compute, which runs on Apple’s servers under the device’s own Apple Intelligence allowance. Apple does not keep the request. Neither Apple path is paid for by the business or passes through Kula’s servers.
- Kula’s cloud path (Kula Ask and agents). Where a business switches it on, Kula sends the question, the relevant results from the business’s data, and for an agent the task’s items, comments and notes, to an AI model provider, currently Anthropic, under commercial terms that do not permit the provider to train on that data. We are not tied to one provider; the current providers are listed in §8. Before an agent run leaves Kula, names, email addresses and phone numbers are replaced with placeholder tokens; a meeting’s transcript keeps the names as said because the meeting is internal, with email addresses and phone numbers removed. The receipt or document reader sends the image or PDF to the model and keeps nothing. Kula Ask is locked to genuine builds of the app through Apple App Attest and runs within the daily and monthly allowance the business sets.
- Capture classification. When a person captures a job by voice or text, the words are sent, with names, phone numbers and email addresses replaced by tokens, to a classification provider, currently TypeSafe, so Kula can tell what kind of job it is.
How Kula learns
Kula keeps a business’s conversations, captures, decisions and their outcomes so it can learn how that business works: which questions come up, what the team calls things, which answers were acted on and which were left. That learning serves the business it came from.
Across businesses, Kula improves its models, classifiers and skills using de-identified information. Names, contact details, identifiers and any free text that could identify a person or a business are removed or replaced before the data is used, and what remains is aggregated. One business’s identifiable data is never used for, or shared with, another business, and our third-party AI providers never train on it. Every business benefits from Kula getting better, and a business can ask us about this at privacy@kula.digital.
Kula Ops decides nothing on its own. It raises situations with the picture it assembled and the move it would make; the decision, including “leave it”, is a person’s. Every agent starts in advise mode, moves to staging changes for a person’s approval only when the business turns that on, and may carry out changes only where the business’s owner switches that on for that agent.
7. Connected AI clients and permission levels
A business may connect its own AI client (for example Claude or ChatGPT) to Kula Intelligence. When someone asks that client a question, the relevant results are sent to the AI provider under the business’s agreement with that provider, not under this Policy, and that provider’s terms govern what it does with them.
Every connection and AI client is issued at a permission level that controls how much personal data it can see, for example limiting names and contact details so the client works with aggregates. Redaction is applied on our servers, so a lower level cannot be coaxed into revealing more. Access is least-privilege by default and revocable at any time; revocation takes effect within about a minute.
8. Who we share data with (sub-processors)
We use a small set of providers to run the service. Each processes data only to provide its part of it.
| Provider | Role | Privacy policy |
|---|---|---|
| Neon | Managed Postgres: each business’s own database | https://neon.tech/privacy-policy |
| Google Cloud Platform | Cloud hosting, document storage, secrets, and the optional embeddings service (Vertex AI) | https://cloud.google.com/terms/cloud-privacy-notice |
| Google Firebase Cloud Messaging | Push notification delivery to the app on iPhone, iPad and Android (installation identifier and push token) | https://firebase.google.com/support/privacy |
| Cloudflare | Network security, edge delivery and, where used, AI model hosting | https://www.cloudflare.com/privacypolicy/ |
| Apple | App Attest device attestation; Apple Intelligence on-device and Private Cloud Compute models; speech recognition where the device cannot run it locally | https://www.apple.com/legal/privacy |
| AI model providers, currently Anthropic | AI models for Kula Ask, agents and the document reader, where a business switches Kula’s cloud path on | https://www.anthropic.com/legal/privacy |
| Classification providers, currently TypeSafe | Classification of captured jobs (names, phones and emails tokenised first) | https://typesafe.ai |
| Kinde | Account holder sign-in and identity | https://kinde.com/privacy-policy/ |
| Vercel | Hosting for the console and web apps | https://vercel.com/legal/privacy-policy |
| Resend | Transactional email: invitations, sign-in codes, connector notifications, and expense claims a business chooses to email | https://resend.com/legal/privacy-policy |
| Twilio | SMS delivery of sign-in codes and invitations from Kula | https://www.twilio.com/en-us/legal/privacy |
| Stripe | Payment processing for Kula subscription billing | https://stripe.com/privacy |
In addition:
- The business’s own messaging account. A member text message a person approves is sent through the business’s own Twilio account, under the business’s agreement with Twilio. An approved email is handed to the person’s own mail app.
- Third-party systems a business connects through an App (for example its rostering product) receive the changes a person asks Kula to make there.
- Kula Fitness receives the messages, files and cover decisions a person makes in Kula Ops where the business also uses Kula Fitness, under the Kula Fitness Privacy Policy.
- The AI client a business connects receives query results as described in §7.
- Apps from external providers that a business switches on operate under their own terms, and what they read is governed by the access the business grants them.
We may update this list as the service evolves; the current list will always be here. Material changes are notified under §15.
9. Where data is stored and cross-border handling
A business’s own database is stored in the cloud region it is provisioned in. Australian businesses’ databases are stored in Australia.
Some processing takes place outside Australia. Our AI model and classification providers (currently Anthropic and TypeSafe), email and SMS providers (Resend and Twilio), push delivery (Google), Cloudflare and parts of our hosting operate in the United States, and the directory that routes a person to their business is hosted there. Where we disclose personal information to an overseas recipient, we take reasonable steps to ensure it is handled consistently with the Australian Privacy Principles, including APP 8, through contractual data-processing terms. Where a business connects its own AI client, that disclosure is directed by the business and governed by its agreement with that provider.
10. How long we keep data
| Data | Kept for |
|---|---|
| A business’s canonical data (the transformed working copy that answers questions and shows history) | While the account is active |
| The raw imported copy of connected data | 30 days, then purged |
| Conversations with Kula, captures, work items, situations, decisions, messages and photos | While the account is active, as the business’s records |
| Meeting transcripts | 90 days; the summary and actions are kept with the meeting |
| Drafts of member messages | 7 days |
| Files uploaded but never attached to a message | 1 day |
| Events from embedded Apps | 30 days |
| Push addresses for devices not seen | 60 days |
| An agent run’s working memory | 1 hour after the run; the run’s record is kept |
| Kula Ask and usage records | Token counts, cost and tool names, kept for billing and audit |
| De-identified, aggregated information used to improve Kula (§6) | Retained; it no longer identifies a person or a business |
When a business disconnects a system, the raw copy from that system is purged within 30 days; the canonical data already derived from it is kept while the account stays active so history is preserved.
When a business closes its account, it can ask us to transfer its database to it; otherwise it is purged. Either way the copies we hold are removed within 30 days of closure, except where we must retain limited records to meet a legal, tax or accounting obligation, and minimal audit records of privileged and write actions.
When a staff member leaves a business, the business revokes their access and their device credentials stop working. Their records in the business’s Kula Ops (decisions, tasks, messages) remain the business’s records. A person can ask us to delete the account information we hold about them as controller (§12).
On the device, the app keeps the person’s working copy of Now, Work, Inbox, meetings and conversations in protected storage that is excluded from iCloud and device backups, and the device credential in the Keychain. Signing out of a business removes everything the device holds for it.
11. Security
- Per-business isolation. Each business’s data lives in its own database. A request is bound to exactly one business from its verified credential, never from a parameter a caller can set. There is no cross-business read path.
- Encryption. In transit (TLS) and at rest, including AES-256-GCM encryption of provider credentials with the key held separately.
- No passwords in the app. Every way in is a short single-use code exchanged for a device credential; on Apple devices genuine builds also register with Apple App Attest; shared-device PINs are encrypted and every attempt is logged.
- Scoped access and auditing. Permission levels limit what personal data each connection sees, and every privileged action and write is recorded.
- Revocable access. A business can revoke any person, device, connection or AI client at any time, and revocation takes effect within about a minute.
- Human approval on consequential actions. Agents start in advise mode; staging and execution are the business’s switches, and execution is also capped by cost, turn and money limits.
For more detail see Security & data handling. To report a vulnerability, see Responsible disclosure or write to security@kula.digital.
Notifiable Data Breaches. Where an eligible data breach occurs, we will act in accordance with the Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth), including notifying affected individuals and the Office of the Australian Information Commissioner (OAIC) where required, and supporting controller businesses in meeting their own notification obligations.
12. Your rights and choices
Account holders and staff members. You may ask us for access to, or correction of, the account information we hold about you as controller by emailing privacy@kula.digital. We respond within a reasonable period, generally 30 days. Access to your own account information is free; if a request is complex we may charge a reasonable, cost-based fee and will tell you beforehand. If we cannot provide access or make a correction, we will tell you why in writing and how to complain, and you may ask us to attach a statement noting your view. You can request deletion of your account and the data we hold as controller at kula.digital/user/deleteme, which confirms by email before anything is erased, or from Profile in the app.
Members and other people in a business’s records. Because the business is the controller of its data, members, staff and other people should direct access, correction and deletion requests to the business. As its processor, we will support the business in responding.
Notifications and permissions. A person controls push notifications, and the camera, microphone, photo and speech permissions, in their device settings and in Profile. Kula Ops works without them, apart from the features that need them.
Member message opt-out. A member who replies STOP to a text message sent through the business’s messaging account is recorded as opted out of that channel, and further sends to it are refused.
13. Complaints
If you have a privacy complaint, contact privacy@kula.digital. We will acknowledge your complaint within 5 business days and work to resolve it promptly. If you are in Australia and not satisfied with our response, you may escalate to the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.
14. Children
Kula Ops and Kula Intelligence are workplace tools for businesses and their teams. They are not directed at children and we do not knowingly collect personal information directly from children. Where a business’s records include information about minors, that information is handled on the business’s instructions, and the business remains responsible, as controller, for holding any required consents.
15. Changes
We may update this Policy from time to time. Where changes are material, we will take reasonable steps to notify businesses in advance. The version and date at the top of this page indicate the current edition.
16. Contact
- Privacy: privacy@kula.digital (attn: Privacy Officer)
- Security: security@kula.digital
- Legal: legal@kula.digital
- Support: support@kula.digital
Kula Holdings Pty Ltd, ABN 53 676 723 452, Sydney, New South Wales, Australia. Governing law: New South Wales, Australia. The parties submit to the non-exclusive jurisdiction of the courts of New South Wales.
Version 2.0 · 31 October 2026.