> For the complete documentation index, see [llms.txt](https://docs.kula.digital/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kula.digital/trust-and-legal/privacy.md). # Privacy policy > *Version 1.0 · Last updated 19 June 2026.* This policy is **specific to Kula Intelligence**, the MCP connector described below. It is separate from the privacy policies of other Kula products. The substance reflects how the product works today. Kula Intelligence is operated by **Kula Holdings Pty Ltd** (ABN 53 676 723 452) ("Kula", "we", "us"), Sydney, Australia. This policy explains what data Kula Intelligence handles, why, how long we keep it, who we share it with, what we deliberately never do, and the choices and rights you have. ## 1. What this policy covers Kula Intelligence is a **Model Context Protocol (MCP) control-plane** for boutique fitness studios. It gives an AI client **you choose** (such as Claude or ChatGPT) a private, scoped, read-mostly window onto **your own studio's data**, so you can ask questions in plain English and get answers built from your numbers. This policy applies to that connector and the operator apps used to set it up. It does not govern the separate Kula products you may also use, nor the AI client you connect — see [Connected AI clients](#6-connected-ai-clients). ## 2. Our two roles * **For studio operators (our customers):** we are the **controller** of your account information. * **For a studio's own data (members, sales, bookings, accounting, marketing):** the studio is the **controller** and Kula acts as a **processor** on the studio's instructions. We access that data only to provide the service to the studio that connected it. Some studio data may include **health or other sensitive information** (for example injury notes or health-related attendance flags), which receives stronger protection under the Privacy Act 1988 (Cth). As the controller of its member data, the studio is responsible for obtaining any consent required to collect that information and disclose it to us, and we process it only on the studio's instructions as its processor (see your [responsibilities under the Terms](/trust-and-legal/terms.md)). ## 3. What we collect **1. Account information.** When you create an account: your name, email, studio name, region, timezone, and sign-in identifiers from our identity provider. Billing details if you subscribe (processed by our payment provider, Stripe — see [sub-processors](#7-who-we-share-data-with-sub-processors)). **2. Studio operational data (via connectors).** When you connect a data source, we read and store a working copy of the relevant records so the AI can answer questions. Depending on which sources you connect, this can include: * **Members & contacts** — names, email addresses, phone numbers, membership status and plans (e.g. from your booking platform or Wix). * **Bookings & attendance** — classes, visits, check-ins, cancellations. * **Sales & payments** — sale amounts, plans, payment method and status, and limited payment metadata. We store at most the **last four digits** of a card; we never receive or store full card numbers. * **Accounting** — contacts, invoices, transactions, and (where your plan allows) general-ledger data from Xero. * **Marketing & web analytics** — advertising performance and spend from Meta, and **aggregated** website metrics from Google Analytics 4 (not individual visitor identities). Exactly what each connector reads — and what it does not — is listed on each [connector page](/your-data-sources/connectors.md). **3. Provider credentials.** The keys or tokens you provide to connect a source are stored **encrypted at rest (AES-256-GCM) in your studio's own database**, with the encryption key held separately. They are used only to read from that provider and are never shared between studios. **4. Connector usage & audit data.** To operate the service, support you, and keep an audit trail, we record **metadata about how the connector is used** — which tools were called, when, by which credential, how long they took, whether they succeeded, and privileged actions. This is operational telemetry about tool calls, not the content of your conversations (see the next section). ## 4. What we do **not** collect or do This is as important as what we collect. Kula Intelligence: * **Does not collect your AI conversations.** We never receive or store the text of your prompts, the AI's responses, conversation transcripts, conversation summaries, or token counts. Our "usage" data is limited to tool-call metadata as described above. * **Does not access your AI client's memory, chat history, or uploaded files.** The connector reads only your studio's connected data, from your studio's own database. It has no access to anything else in your AI client. * **Does not move money or generate media.** It never makes payments, issues refunds, transfers funds, runs payroll, or generates images, audio, or video. * **Does not write back to your connected tools.** It is read-mostly; the limited writes it makes are confined to your own Kula database (e.g. saved views, notes), never to the source systems. * **Does not receive full payment card numbers**, and **does not track individual website visitors** (GA4 data is aggregated). * **Does not sell your data, ever**, and does not share it with third parties for their own marketing. * **Does not use one studio's data to answer another studio's questions** — there is no cross-studio read path (see [Security](#10-security)). * **Does not use your studio's data to train cross-customer or general-purpose AI models.** ## 5. How we use data * **To provide the service** — to let the AI client you connect answer questions about your studio. * **To operate and support** — diagnostics, troubleshooting, security, audit, and billing. * **Optional semantic search** — only if you opt in, we generate embeddings from your text to power similarity search; that data stays in your provisioned cloud region. We do **not** use your studio's data to train cross-customer or general-purpose AI models, and we do not profile your members for any purpose other than answering your own questions about your own studio. ### Direct marketing We may send you service and product communications about Kula Intelligence (for example onboarding, security, and feature updates). Where we send promotional messages, we include a way to opt out and honour your request promptly, consistent with the Privacy Act 1988 (Cth) and the Spam Act 2003 (Cth). We do not use your studio members' personal information for our own marketing, and we never sell data or disclose it for third parties' marketing. ## 6. Connected AI clients Kula Intelligence is the bridge between your data and **an AI client you choose**. When you ask a question, the relevant results are sent to that AI provider so it can answer you. That exchange is governed by **your agreement with that AI provider**, not by Kula, and the AI provider's own privacy terms apply to what it does with the prompt and the data it receives. * You choose a [**permission level**](/connect-claude-and-access/scopes.md) that controls how much personal data the assistant can see — for example, limiting names and contact details so the AI works with aggregates instead. * Where we engage AI providers as our own sub-processors (for the optional embeddings feature), we do so under data-processing terms that **restrict use of your data for AI-model training**. ## 7. 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 the service: | Provider | Role | Privacy policy | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------- | | Neon | Managed Postgres — your studio's database | | | Google Cloud Platform | Cloud hosting, document storage, secrets, and the optional embeddings service (Vertex AI), processed in your provisioned region | | | Kinde | Operator sign-in / identity | | | Vercel | Hosting for the operator web apps | | | Resend | Transactional email — connect-link invites, secure token-reveal emails, and connector notifications to operators | | | Twilio | SMS delivery — secure one-time token-reveal links (where SMS handoff is enabled) | | | Stripe | Payment processing for Kula subscription billing (where you subscribe to a paid plan) | | In addition, the **AI client you connect** (e.g. Claude / Anthropic, ChatGPT / OpenAI) receives your query results at the moment you ask a question, under your agreement with that provider, as described in [Connected AI clients](#6-connected-ai-clients). We may update this list as our infrastructure evolves; the current list will always be here. We do not share your data with third parties for their own marketing. ## 8. Where data is stored and cross-border transfers Your studio's data is stored in the **cloud region you are provisioned in**. Australian studios' data is stored in Australia. Some sub-processors operate outside Australia — in particular Google Cloud Platform (United States and other regions), Resend and Twilio (United States), and, where you connect them, AI providers such as Anthropic (United States) or OpenAI (United States). 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 through contractual data-processing terms. The AI client you connect receives your query results under your **own agreement with that provider**; because you choose and direct that disclosure, the provider's handling of that data is governed by your agreement with it rather than by us. ## 9. How long we keep data * **While your account is active**, we retain your studio's transformed (canonical) data so the service keeps working — this is what makes 12-month trends and history possible. * **The raw imported copy** — the verbatim vendor data we land before transforming it — is kept only long enough to re-process safely: **30 days, then it is purged.** The canonical data it produced is unaffected. * **When you disconnect a data source**, the raw copy we hold from that source is purged within **30 days**. The canonical data already derived from it is retained while your account stays active, so your history and trends are preserved. * **When you close your account**, you can ask us to transfer your studio's database to you; 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. ## 10. Security We protect data with: * **Per-studio isolation** — each studio's data lives in its **own database**. There is no cross-tenant read path; one studio's data is never used to answer another studio's questions. * **Encryption** — in transit (TLS) and at rest, including AES-256-GCM encryption of the provider credentials you supply, with the key held separately. * **Scoped access and auditing** — every privileged action is recorded, and the permission level you choose limits what personal data is exposed. * **Revocable access** — you can revoke a connection or token in one click from the operator app, and revocation takes effect on the connector promptly (near real-time). For more detail see [Security & data handling](/trust-and-legal/security.md). To report a vulnerability, see [Responsible disclosure](/trust-and-legal/disclosure.md) (****). ### Data breaches If we become aware of a data breach affecting personal data we hold that is likely to result in serious harm, we will assess it and, where the Notifiable Data Breaches scheme under the Privacy Act 1988 (Cth) applies, notify affected individuals and the Office of the Australian Information Commissioner as soon as practicable, consistent with our legal obligations. Where a studio is the controller of affected member data, we will notify and support that studio (as its processor) so it can meet its own notification obligations, and we will assist with containment and remediation. ## 11. Your rights Depending on where you are, you may have rights to access, correct, export, or delete personal data, and to object to or restrict certain processing. * **Operators:** you may ask us to access or correct the personal information we hold about you by emailing ****. We will respond within a reasonable period (generally within 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 the basis beforehand. If we cannot provide access or make a correction, we will tell you why in writing and how to complain, and where you dispute the accuracy of information and we do not correct it, you may ask us to associate a statement noting your view. * **A studio's members:** because the studio controls its member data, direct requests to the studio; we will assist the studio in fulfilling them as its processor. ## 12. Complaints If you have a privacy concern, contact us first at **** and we will acknowledge your complaint within **5 business days** and work to resolve it. If you are in Australia and are not satisfied with our response, you may escalate to the Office of the Australian Information Commissioner (OAIC) at [oaic.gov.au](https://www.oaic.gov.au). ## 13. Children Kula Intelligence is a business tool, not directed at children and not intended for the collection of children's data. ## 14. Changes to this policy We will update this page when our practices change and revise the "last updated" line. We will communicate material changes to operators. ## 15. Contact Questions or requests: **** (attn: Privacy Officer) — Kula Holdings Pty Ltd (ABN 53 676 723 452), Sydney NSW, Australia *(registered office address to be confirmed)*. For security matters: ****. For other support: ****. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kula.digital/trust-and-legal/privacy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.