Privacy Policy

1. Controller

Calico AG, Riedmatt 2, 6300 Zug, Switzerland is the controller of the personal data described here. Reach us at hello@getluminaid.com. Where you use Luminaid for your company and put your own customers' or prospects' data into it, your company is the controller of that data and we process it on its behalf.

The contact addresses our crawler collects from publishers' own pages, and the ones a data vendor supplies when a customer asks us to look a domain up (§2, §4), work the other way round: no customer asked for them, they are not part of any workspace's content, and one table of them serves every workspace. Calico AG is the controller of those and answers for them directly — §5 says how long they are kept and §6 how to have one removed.

2. What we collect

• Account data — email address, name if you give one, the Google account identifier if you sign in with Google, workspace memberships and roles, sign-in events.
• Workspace content — the keywords, buyer personas, brand names, domains and pages you configure; the answers the answer engines returned, the sources they cited, the pages we read for you, and the analyses, recommendations and drafts the Service produced.
• Contact details published by the sites that are cited — for every domain an answer engine cited in one of your runs, the email addresses that domain's own website publishes: shared mailboxes such as press@ or editor@, and addresses that name a person, with the name and job title where the page states them and the page each address was found on. We collect these from the publisher's pages rather than receiving them from anyone (§4). They are stored per domain in one table that every workspace reads, not inside your workspace, and are not linked to you or to your run.
• Contact details obtained from a data vendor — a member of your workspace can ask us to look one domain up with Hunter.io (Hunter, United States), a service that sells business email addresses it has gathered from across the web. We then ask it what addresses it holds for that one domain and keep those: shared mailboxes and addresses that name a person, and nothing else about the person — we do not keep the name or job title the vendor offers, and we ask it no other question. These addresses did not come off the publisher's own pages: we bought them, and each one is marked in the list as coming from the vendor rather than from the site, because the difference matters. There are two ways we come to ask, and both are one domain at a time: a member asks us about a domain they are working on, or a run reads a publisher's own website and finds that it publishes no address anywhere we can see — in that case, and only in that case, we ask the vendor about that domain. We ask never for a list of domains at once, never about a publisher whose robots.txt told us not to read its pages, and the number of domains any one run may ask about is capped well below the number of domains it reads, so a run buys addresses for a handful of domains at most. An address somebody has objected to (§6) is not stored even if the vendor returns it. They are kept in the same shared per-domain table, on the same terms and for the same periods as the addresses above (§5).
• Feedback you send us — when you report a problem or suggest something from the app or through its assistant: what you wrote, your email address, your workspace, organization, role and brand, and what your browser reports about the page you were on — its address, the app version, browser, operating system, screen size, language, time zone and its last console messages.
• Usage and billing data — runs started, credits consumed, provider and model usage per run (opaque workspace and run identifiers only), plan and payment status. Card details are held by our payment processor, never by us.
• Technical data — server logs with IP address, user agent, request path and timing, kept for security and operations. Logs never contain your keywords, the engines' answers or your content.
• Marketing site — if you request an audit through the form, the details you enter. The site sets no analytics or advertising cookies.

3. Why and on what basis

To provide the Service you asked for (performance of the contract): running analyses, storing results, billing. To keep the Service secure and reliable and to improve it (our legitimate interest): logs, alarms, aggregate usage. To meet legal obligations (accounting records). We do not sell personal data, do not use your content to train models, and do not profile you for advertising.

The contact details of cited sites rest on our legitimate interest in telling a customer who to approach about a page that was cited. What we keep is limited to that: business contact details, whether the site publishes them itself, on its own pages, for exactly this purpose, or a data vendor supplies them for one domain a customer asked us to look up (§2). We do not profile anyone, we ask the vendor nothing beyond the addresses at that domain, and we do not combine either source with anything else we hold. We do not send mail to them; the customer decides whether to write and does so themselves. If you would rather we did not hold yours, §6 is the route, it covers both sources, and we act on it.

4. Sub-processors and where data is processed

The Service runs on Amazon Web Services in the EU (Ireland, eu-west-1) region: your workspace data, results and files are stored there. To produce an analysis, your keywords and personas — never your account data — are sent to the answer engines and search providers your workspace has selected. Our crawler then reads pages on the open web: the pages the engines cited, the pages you configure as your own, and, for every domain a run cited, that domain's publisher — its home page, up to four contact pages that page links to, and its /.well-known/security.txt, the file whose purpose is to publish a contact address. It reads only what is publicly reachable without signing in, identifies itself as Luminaid-ContactReader, and honours robots.txt when it reads a publisher this way, so a site that disallows it is not read. Model calls made through Amazon Bedrock use a global inference profile and may be served from AWS regions outside the EU. Our sub-processors:

• Amazon Web Services (hosting, storage, Amazon Bedrock model access, Cognito sign-in) — Ireland; Bedrock global inference profiles may route to the United States.
• Answer engines your workspace selects: OpenAI, Perplexity, Google (Gemini), Anthropic — United States.
• Search and crawl providers your workspace selects: Brave Search, Tavily, Exa, SerpApi, Firecrawl — United States.
• Google (optional "Sign in with Google") — the identifier and email of the Google account you choose.
• Stripe (payments) — card data and invoices; we hold only the payment status and references.
• GitHub (source hosting and deployment automation) — no customer data.

Transfers outside Switzerland and the EU rest on the recipients' standard contractual clauses or an adequacy decision. We update this list when a sub-processor changes and announce material changes in the Service.

5. How long we keep it

• Analysis results and raw provider answers — for the retention window of your plan: 90 days on Free and Starter, 365 days on Pro and Business, as agreed for contract plans. A nightly job deletes what is older; a storage-level rule removes anything it missed after 400 days. The screenshots we take of the pages the answers cite follow the same window, by the day they were taken.
• Workspace configuration (keywords, personas, brand details) and account data — while the workspace and account exist.
• Usage, credit and audit records — for the life of the organization plus the legal accounting period (ten years under Swiss law) in aggregate, identified by opaque identifiers.
• Server logs — 30 days.
• Contact addresses — kept while the publisher still publishes them, and no longer. Each row carries an expiry of 365 days for a shared role mailbox (press@, editor@ and the like) and 180 days for an address that names one person, counted from the last time we read it on the publisher's own pages — shorter for a person because it identifies an individual rather than a function. A later read refreshes the one row and moves its expiry out, so an address the publisher keeps publishing stays, and one that leaves the page, or whose domain stops being cited, expires on its own: the database deletes it without anyone acting. Before that, a row also leaves in one of two ways — somebody objects and the address is suppressed (§6), or we remove it by hand. One caveat we would rather state than let you assume: the database keeps a rolling 35-day recovery window, so for up to 35 days a deleted or expired row still exists in a backup we could restore. A suppression takes effect immediately and the record of it is permanent, but it is not an instant erasure of every copy.
• Feedback reports — kept with no expiry, so the history of a problem stays with it. They are held apart from your workspace's content, so deleting a workspace does not delete them; to have yours deleted, write to hello@getluminaid.com (§6).
• Deleted workspaces — every row and file of a workspace is deleted within 30 days of the deletion request, verified, and a deletion record with counts is kept; a data export is offered before deletion. The feedback reports its members sent are the exception (above).

6. Your rights

Under the Swiss Federal Act on Data Protection and, where it applies, the GDPR, you may ask for access to, correction, export or deletion of your personal data, object to processing based on legitimate interest, and complain to a supervisory authority (in Switzerland, the FDPIC). Write to hello@getluminaid.com; we answer within 30 days. Workspace owners can export and delete their workspace's data from the Service directly.

If we hold your address and you never gave it to us. The addresses described in §2 come off publishers' pages, or from the data vendor a customer can ask us to look one domain up with, so the person they belong to is usually not our customer. The same rights apply and you need no account to use them. Write to privacy@getluminaid.com, name the address, and say that you want it removed: we tell you whether we hold it, delete the row, and record the objection so that neither a later read of the same site nor a later look-up with the vendor can store the address again. That record is a one-way hash of the address, not the address — enough to recognise it if it turns up again, and nothing we could read back. It covers every site we hold the address for. We answer within 30 days. You can also keep our crawler out in the first place: it identifies itself as Luminaid-ContactReader and honours robots.txt when it reads a publisher. That keeps us off your pages, but it does not reach the data vendor, which gathers addresses independently of us and would not know about it — for that, the objection above is the route, and it is permanent.

7. Security

Data is encrypted in transit and at rest; each workspace's data is stored under its own key prefix and is reachable only with credentials scoped to that workspace; access by our staff is limited to support you request and is logged. We notify affected customers without undue delay if a breach affects their data.

8. Changes

We update this policy when the Service or our sub-processors change and announce material changes in the Service or by email. The current version is always at this address.