Legal
Privacy Policy
Last updated
1.Who this policy covers
This policy explains how Zeevaa(“we”, “us”) handles personal information in connection with Studio Zeevaa — the web application, the documentation, the public assistant pages, the embeddable widget and the API (together, the Service).
It covers three kinds of people, who are treated differently:
- Customers — people who create an account and build assistants in a workspace.
- Visitors— members of the public who talk to an assistant a customer has published, on a shared link or on the customer’s own site.
- Website visitors — anyone reading the marketing pages or the documentation without signing in.
2.Our two roles
The distinction below decides who you should contact about your data, so it comes before everything else.
We are the controller of account information: who signed up, which workspace they belong to, what they were billed, and how they used the product. We decide what to collect and why, and this policy governs it.
We are a processor of everything a customer puts into their workspace and everything said to their assistants — documents, catalogues, transcripts, form answers. That content belongs to the customer. We act on their instructions, we do not decide what it is used for, and we do not mine it for our own purposes.
So if you spoke to an assistant on a company’s website and want your conversation deleted, that company is the one who decides. See section 13.
3.What we collect
Listed as the system actually stores it, rather than as broad categories.
Account and workspace
- Your name, email address and profile image, as held by our identity provider and cached by us so that listing the members of a workspace does not require a round trip for every row.
- The workspace you belong to and your role in it (owner, admin or member).
- Account creation and update timestamps.
We never receive or store your password. Authentication is handled entirely by our identity provider.
What you put in your workspace
- Documents you upload (PDF, DOCX, TXT, Markdown), the text extracted from them, and the numeric embeddings computed from that text so it can be searched by meaning.
- Catalogue data you import from spreadsheets, stored as structured records.
- Assistant configuration: instructions, persona, model and voice settings, tools, limits, permitted embed origins, and the automations attached to it.
- Provider credentials you supply — your own model, voice or webhook keys. These are encrypted at rest under a versioned key and are never returned to the browser after being saved.
If you upload personal information about other people, you are the controller of it and are responsible for having a lawful basis to do so.
Conversations
- The transcript: every message in and every reply out, whether it arrived by voice or by text, with timings.
- Which tools the assistant used, what it passed to them and what came back.
- Session metadata: a generated title, a one-paragraph summary, the channel, which interface it came through, how it ended, and the token usage it cost.
- Answers to any pre-chat form the operator configured.
- The visitor’s browser user-agent and the page that referred them.
- A salted hash of the visitor’s IP address — never the address itself. It is enough to enforce a per-visitor rate limit and to spot abuse, and not enough to retain an identifier for every anonymous member of the public who opens a link.
Technical and usage records
- API request logs: which key was used, which endpoint, the response status, how long it took, and when. These are what rate limits and usage reporting are counted from.
- Diagnostic logs and error reports generated by our hosting and database providers.
We do not collect precise location, we do not buy data about you from brokers, and we run no advertising or behavioural analytics trackers.
4.Where the information comes from
- From you directly — when you sign up, configure an assistant, upload a file or write to us.
- From your visitors — when they talk to an assistant you published.
- From your own systems — when your code calls the API on your key, or when an automation you built calls a webhook of yours.
- Automatically — the technical records described above, generated as the Service runs.
5.Why we use it, and on what basis
| Purpose | What it uses | Basis |
|---|---|---|
| Providing the Service — running assistants, answering from your data | Workspace content, conversations, credentials | Performance of a contract |
| Authenticating you and keeping workspaces separate | Account information | Performance of a contract |
| Rate limiting, fraud and abuse prevention | Hashed addresses, request logs | Legitimate interests — keeping the Service available |
| Metering, billing and usage reporting | Request logs, session counts | Performance of a contract |
| Support, and diagnosing failures you report | Logs, and content only where you point us at it | Legitimate interests |
| Improving reliability and performance of the product | Aggregated and technical data | Legitimate interests |
| Service notices and, separately, marketing email | Account contact details | Contract; consent for marketing |
| Meeting legal, tax and accounting obligations | Account and billing records | Legal obligation |
Where we rely on legitimate interests, we have weighed them against your rights and use the least data that achieves the purpose — the hashed rather than raw IP address is the clearest example. Where we rely on consent, you can withdraw it at any time without affecting what came before.
6.Artificial intelligence and your content
Answering a question means sending the relevant part of your content to a model provider. Specifically: the assistant’s instructions, the conversation so far, and whichever passages or records were retrieved as relevant. Speech is sent to a voice provider to be synthesised, and audio from a visitor is sent to be transcribed.
- We do not train models on your content. Not our own, and we use model and voice providers under API terms that do not permit them to train on content submitted through those endpoints.
- Your content is not shared between workspaces. Every query is resolved through a workspace membership, and there is no path in the data layer that crosses that boundary.
- You may use your own provider keys.When you do, the request is made on your account and the provider’s own terms apply directly between you and them.
- Output can be wrong. An assistant produces text; it makes no decision about anyone. We do not use it for automated decision-making that produces legal or similarly significant effects, and it should not be used that way without a human deciding.
8.International transfers
The Service and its providers operate across more than one country, so your information may be processed outside the country you are in. Where information moves from a region whose law restricts that, we rely on a recognised transfer mechanism — an adequacy decision where one exists, and standard contractual clauses with the receiving party otherwise — together with technical measures such as encryption in transit.
Customers with a data residency requirement should contact us before onboarding; it is a constraint we can sometimes meet, but not one we can retrofit quietly.
9.How long we keep it
| What | Kept for |
|---|---|
| Conversation transcripts | A retention period the operator sets per assistant, 90 days by default. Older transcripts are purged automatically. |
| Workspace content — documents, catalogues, configuration | Until you delete it, or until the account closes |
| Account records | For the life of the account, then up to 30 days |
| API request logs | 12 months, for metering and abuse investigation |
| Billing and tax records | As long as accounting law requires, typically 6–7 years |
| Backups | Rolling, and expire within 35 days of deletion |
An operator may set an assistant to keep transcripts indefinitely. If you are a visitor and want to know what a particular assistant is set to, ask the organisation that published it.
10.How we protect it
- Encrypted in transit over TLS, everywhere.
- Provider credentials encrypted at rest under a versioned key, so keys can be rotated without a re-entry of every secret.
- Tenancy enforced at the data layer rather than in routing: a request that cannot resolve a workspace membership gets no data at all, which is what makes a forgotten check fail closed.
- Visitor IP addresses stored only as salted hashes, and never in raw form.
- Framing of embedded assistants restricted to the origins each operator has allowed, so an assistant cannot be lifted into a hostile page.
- Access to production limited to the people who need it, over multi-factor authentication.
No system is perfectly secure. If you believe you have found a vulnerability, please write to contact@zeevaa.ai rather than disclosing it publicly, and we will work with you on it.
12.Your rights
Depending on where you live, you may have the right to: get a copy of the personal information we hold about you; have it corrected; have it deleted; receive it in a portable format; restrict or object to certain processing; withdraw consent you previously gave; and complain to your data protection authority.
Write to contact@zeevaa.ai. We will respond within 30 days, and will tell you if we need longer and why. We will ask you to verify who you are before acting — that check protects you, not us. Exercising a right never costs you anything and never degrades the Service.
Most of it you can also do yourself: workspace content, assistants and transcripts can be deleted from the dashboard at any time, and deleting the account removes the workspace with it.
13.If you talked to an assistant someone else built
The organisation that published the assistant decides what it collects, what it does with the transcript and how long it is kept. We only hold it for them. So:
- Requests to access or delete your conversation should go to that organisation first. They can act on it immediately from their dashboard.
- If you cannot identify or reach them, write to contact@zeevaa.ai and we will pass the request on and, where the law requires it, follow up.
Whatever you tell an assistant is stored as a transcript the operator can read. Do not send payment card numbers, government identifiers or health information to an assistant unless the organisation running it has told you it is set up for that.
14.Children
The Service is for business use and is not directed at children. We do not knowingly collect personal information from anyone under 16. If you believe a child has provided us information, write to contact@zeevaa.ai and we will delete it.
15.Changes to this policy
We update this policy when the product changes what it does with data. The date at the top always reflects the current version. For a change that materially affects you — a new category of data, a new purpose, a new sub-processor handling content — we will give notice by email or in the app before it takes effect, so that you have the chance to object or to leave.
16.How to contact us
Privacy questions, rights requests and security reports all reach us at contact@zeevaa.ai. Put Privacy or Security at the start of the subject line and it will be routed accordingly.
If you are unhappy with how we handled a request, you may complain to the data protection authority where you live or work.