Mosaic Privacy Policy
Last updated: 5 October 2026
This privacy policy is issued by Campainless Pty Ltd (ACN 668 774 856, ABN 18 668 774 856), an Australian proprietary company with its principal place of business at 83 Princes Highway, St Peters NSW 2044, Australia ("Campainless", "we", "us"). It covers Mosaic — our organisational-knowledge and AI-coworker platform at app.mosaicailab.ai, including its Slack application and its connections to your other work tools ("the Service") — and our public websites.
We have written this policy to be read, not skimmed past. Where the law lets us choose between a vague statement and a precise one, we have chosen the precise one. If anything here does not match what the product actually does, that is a defect: tell us at the contact address in Section 12 and we will fix the product or the policy.
1. The two kinds of data we handle, and our two different roles
Mosaic is a business tool. Almost all of the information flowing through it belongs to the organisation that signed up ("your organisation"), not to us. That gives us two distinct roles:
- Customer Content — we process it on your organisation's behalf. The messages, documents, and connected-tool data your organisation gives Mosaic access to, the knowledge the Service curates from them, and the questions your people ask the coworker. Your organisation controls this data; we handle it only to provide the Service, under our agreement with your organisation. We do not sell it, we do not use it for advertising, and — as Section 5 sets out in detail — neither we nor our AI providers use it to train AI models.
- Account and operational data — we are the primary decision-maker. The information we need to run the Service itself: account details (name, work email, authentication identifiers), billing records, usage analytics, support correspondence, and security logs.
Where Australian privacy law applies, we handle personal information in both categories in accordance with the Australian Privacy Principles ("APPs") under the Privacy Act 1988 (Cth). We apply the APPs as our operating standard regardless of whether an exemption might technically be available to a company of our size.
2. What we collect
From you directly: - Account data: name, work email address, password hash or Google sign-in identifier, organisation name and workspace details. - Billing data: plan, transaction history. Card details go directly to Stripe, our payment processor — we never see or store full card numbers. - Support and feedback: what you send us when you contact us.
From your organisation's connected tools, with your organisation's authorisation: - Slack: messages in channels the coworker has been invited into, direct messages sent to the coworker, and the workspace, channel, and user profile information needed to operate the app (names, work email addresses, time zones). The coworker only sees channels it is a member of. The Service keeps a durable copy of these messages as the coworker's memory — that copy is what lets it recall context, answer questions about past discussion, and build your organisation's knowledge base. Edits made in Slack update the stored copy, and deletions remove the stored content. - Google Workspace and other connected tools (via our connector platforms, Composio and Pipedream): the content your organisation's administrators authorise per connection — for example email or documents in scope of an onboarding scan. - The knowledge the Service builds from these sources: curated summaries, extracted facts, and the organisation's own governed knowledge documents.
Generated by the Service: - Usage analytics: which features are used, by whom, with what outcome — as identifiers, counts, and outcomes. We do not record document bodies, message text, or form-field values in product analytics. - Audit records: a tamper-evident record of consequential actions (who approved a knowledge change, who granted access, when), kept because governance is a core feature of the Service — consequential actions cannot be silently rewritten. - Security and operational logs: request metadata, error traces, cost and model-usage records.
We do not collect data from data brokers, and we do not use advertising cookies or cross-site trackers. Cookies we do use are for sign-in sessions and the analytics described above (this paragraph is our cookie notice — there is deliberately no separate cookie policy to chase).
3. What we use it for
- Providing the Service: running the AI coworker, building and searching your organisation's knowledge base, executing the skills and scheduled work your organisation configures.
- Operating the business: billing, support, capacity planning, and product analytics as described above.
- Security and integrity: detecting abuse, enforcing access controls, investigating incidents, and maintaining the audit trail.
- Legal obligations: tax and corporate record-keeping, and responding to lawful requests (Section 9).
We do not use Customer Content to market to anyone, to build profiles of individuals, or to train AI models.
4. AI processing — what actually happens to your content
Mosaic's core function is applying large language models to your organisation's content. Because this is the part of the Service most deserving of scrutiny, here is precisely how it works:
- Your content is sent to AI providers to be processed, not to be kept. When the coworker answers a question or a skill runs, relevant content is sent to one or more of the AI providers listed in Section 6, processed to produce the response, and returned. Which provider serves a given request depends on the model your organisation has enabled and the task.
- No training, contractually. Every AI provider we route Customer Content to operates under commercial terms in which content is not used to train or improve their models by default, and we do not opt in to any data-sharing or feedback programme that would change that.
- Bounded retention at providers. Providers may retain API inputs and outputs for a short period for abuse monitoring (typically up to 30 days, with longer retention only for content their systems flag as violating their usage policies). Several of the model hosts we route to hold content in memory only for the duration of the request. Our provider-by-provider record, with sources and the dates we verified each claim, is available to customers on request and summarised on our subprocessor page.
- Human review at providers is exceptional, not routine. Provider staff do not read your content in the ordinary course; the documented trigger is automated abuse-detection flagging, under need-to-know controls.
- Routing is deliberately restricted. For models we reach through an intermediary (OpenRouter), each model is pinned to one named downstream host whose data-handling terms we have verified; your content is not sent to hosts we have not verified.
- Three providers come with the Service. The models included with every workspace span Anthropic, OpenAI and Google, and the terms accepted at signup cover all three. The Google models are reached through Google Cloud's Vertex AI on a zero-retention endpoint via OpenRouter, and that endpoint has no Australian data residency — those requests are processed in the United States or at another of Google's global locations. Section 8 covers what that means under APP 8.
- The models change. The set of models we use may change over time; material changes to how Customer Content is processed are reflected on our subprocessor page and notified to organisation administrators.
What the AI produces is subject to your organisation's own governance inside the Service: proposed knowledge changes require human approval before they take effect, and the audit trail records who approved what.
5. AI outputs and their limits
AI-generated content can be wrong. The Service is designed to show its work — answers carry citations to their sources where available, an independent automated review annotates recommendations it could not verify, and unverified statements are labelled rather than polished away. These are engineering controls, not guarantees: your organisation remains responsible for decisions made on the basis of AI output, as the Terms of Service set out.
6. Who else touches the data (our subprocessors)
We use a small set of service providers, each for a specific job. The current list — maintained as the authoritative version on our subprocessor page — is:
| Provider | Role | Content exposure |
|---|---|---|
| Amazon Web Services | Hosting (Australia and/or the United States — current regions on our subprocessor page) and the AI agent execution environment; Amazon Bedrock as an AI lane where enabled | Full (hosting); per-request (AI) |
| Anthropic | AI models (the coworker's primary models) | Per-request |
| OpenAI | AI models (delegate tasks) | Per-request |
| Google Cloud (Vertex AI) | AI models (Gemini — part of the core set included with the Service), reached through OpenRouter on a zero-retention endpoint with no Australian data residency | Per-request |
| OpenRouter | Transport for the Gemini core models and for the additional AI models your organisation may enable in-product; each model is pinned to one named, zero-retention-verified host, disclosed at enablement | Per-request |
| Google sign-in | Sign-in identifiers only; never Customer Content | |
| Composio | Connector platform linking Mosaic to your organisation's tools | Data in scope of each authorised connection |
| Pipedream | Connector platform for additional tool connections, where your organisation uses them | Data in scope of each authorised connection |
| Slack | The messaging platform the coworker lives in | Messages the coworker can see |
| Stripe | Payments | Billing details only; never Customer Content |
| Postmark | Transactional email (invites, password resets, notifications) | Work email addresses and the content of those emails |
Most of these providers process data in the United States. Section 8 covers what that means legally.
7. Retention and deletion
- Customer Content — your knowledge base, its approved documents, and the coworker's conversation history — is retained while your organisation's subscription is active, because a knowledge base that forgets is not a knowledge base. Raw connected-tool data may be cleaned up once it has been processed into the knowledge base. When your organisation leaves the Service, its tenant data is deleted on request or per the offboarding terms in our agreement.
- Slack API data has an additional, automatic rule: if your organisation uninstalls the Mosaic Slack app or revokes its access, the stored Slack messages, identifiers, and workspace metadata are deleted within 14 business days — without waiting for an offboarding request. This matches what Slack's platform rules require of apps like ours. Knowledge documents in your organisation's knowledge base are your organisation's own content and follow the Customer Content rules above.
- Audit records are retained for the life of the tenant; they exist so that consequential actions cannot be silently rewritten.
- Coworker conversation history and session logs are retained while your organisation's subscription is active — they are part of the working memory that makes the coworker useful — and are deleted with your tenant's data when you leave. Transcripts of conversations held in Slack are part of your Slack data, so they follow the Slack deletion rule above if you uninstall the app; the knowledge and Activity records built from them remain yours.
- Account data is kept while your account exists and for a limited period afterwards as required for tax, dispute, and security purposes.
- AI provider copies expire on the providers' own schedules described in Section 4 — typically within 30 days, and immediately for memory-only hosts.
- Backups age out on a rolling schedule; deleted data disappears from backups as they rotate.
Individuals can ask us to access or correct their personal information (Section 11). For Customer Content, we will usually need to direct the request through your organisation, which controls that data.
8. Where data goes (cross-border disclosure)
We are an Australian company. The Service is hosted in Australia and/or the United States — the current hosting regions are listed on our subprocessor page, and dedicated hosting arrangements are available under separate agreement. Model processing takes place on hosts in the United States, except Google Cloud, which serves from several regions and is not pinned to one country. The companies that process your content to run the models are Anthropic, Baseten, DeepInfra, Fireworks AI, Google Cloud, OpenAI, SiliconFlow and xAI. None of them trains on your content. None retains it after the request, with narrower exceptions: Anthropic holds it for 30 days, reviewed by a human only if a request is flagged; OpenAI holds it for 30 days, reviewed by authorised staff only if a request is flagged. Some operational subprocessors are US-based. Under APP 8, we take reasonable steps to ensure overseas recipients handle personal information consistently with the APPs: we route Customer Content only to providers under verified commercial terms of the kind described in Section 4, we maintain the verification record described there, and we remain accountable under Australian law for those disclosures. By using the Service, your organisation authorises these disclosures as necessary to provide it.
For customers subject to the EU or UK GDPR: we do not currently market the Service into the EU/UK, and we do not claim GDPR compliance as a certification. If your own obligations require additional data-processing terms, contact us at the address in Section 12 and we will work with you.
9. When we would disclose data otherwise
Only: (a) to the subprocessors above, for the jobs above; (b) when your organisation directs us to; (c) when the law compels us — in which case we will notify your organisation unless legally prevented; (d) in a genuine emergency threatening someone's safety; or (e) as part of a corporate transaction (merger, acquisition), in which case this policy continues to bind the successor until replaced with notice.
We have never sold personal information and have no plans that involve doing so.
10. Security and data breaches
Access to Customer Content inside Campainless is restricted and logged; tenants are isolated from one another; credentials and tokens are encrypted at rest; consequential actions are recorded in the tamper-evident audit log; and the AI execution environment runs with least-privilege access scoped per run. No security description survives contact with reality unedited, so we would rather understate: our full security posture is available to customer security reviewers on request.
We maintain a data-breach response plan aligned with the Notifiable Data Breaches scheme. If a breach involving personal information is likely to result in serious harm, we will notify affected organisations and individuals and the Office of the Australian Information Commissioner as the scheme requires — promptly, and with what we actually know rather than reassurance.
11. Your rights
If you are an individual whose personal information we hold, you may request access to it, correction of it, or (where it is not Customer Content controlled by your organisation, and no retention obligation applies) deletion of it. Write to the address in Section 12; we respond within 30 days. If you are unsatisfied with our response, you may complain to the Office of the Australian Information Commissioner (oaic.gov.au).
The Service is operated under Australian law. If you are in a US state with specific privacy rights (such as California), or in the EU or UK where additional rights may apply to you, you may contact us at the address in Section 12 with a request and we will respond consistently with applicable law.
12. Contact and changes
Privacy contact: privacy@mosaicailab.ai (or by post to the registered address above).
When we change this policy materially, we will notify organisation administrators and require re-acceptance where the change affects what we may do with data. Each version is dated and prior versions remain available.