The Prompt Is Born Clean: Why Consentless Analytics Makes Private AI Simple
Almost every AI privacy control on the market is cleanup: redact this, contract for that, delete after ninety days. All of it exists because the data was personal before the model ever saw it. Collect nothing personal and the whole layer becomes unnecessary.
Key Takeaways
- Redaction, DPAs and retention limits are damage limitation — they manage a risk created upstream, at collection.
- SealMetrics never collects IPs, cookies, fingerprints or visitor identifiers, so there is no personal identifier available to put in a prompt in the first place.
- A Seal AI prompt carries your question, aggregated metrics and grouping labels. Visitor-level data is absent because it never existed, not because it was stripped out.
- EU-only inference, zero retention and no training on your data then sit on top as defence in depth — a second layer, not the first one.
Read enough vendor documentation about AI and privacy and you start to notice that it is all written in the same tense: the past perfect of a mistake already made.
Personally identifiable information is redacted before the request. Data processing agreements are in place with the model provider. Logs are purged after a retention window. Prompts are scrubbed of email addresses. Every one of those controls is competent engineering, and every one of them exists to manage a problem introduced earlier — at collection, long before anyone typed a question into a chat box.
There is another order of operations. Do not collect the personal data, and the prompt is clean when it is born.
Privacy starts before the AI
SealMetrics is consentless analytics. That is not a claim about cookie banners being optional; it is a statement about what the tracker records. It never collects IP addresses, never sets cookies, never builds device fingerprints and never assigns visitor identifiers — not hashed, not pseudonymised, not "anonymised." Those fields do not exist in the data model.
Which means that when an AI layer sits on top of that database and runs a query, there is no identifier in the result set to worry about. Not because a filter removed it. Because there was never one to remove.
This is the difference between privacy-by-design and privacy-by-policy, and it shows up most clearly in failure modes. A redaction rule can be misconfigured. A retention job can silently stop running. A new engineer can add a field to a payload without realising what it makes possible. An identifier that was never collected has no failure mode.
What is actually in the prompt
Concretely, here is what travels to the model when you ask the SealMetrics assistant a question — and what cannot, because it does not exist anywhere behind it.
| Goes into the prompt | Cannot go in — it never existed |
|---|---|
| Your typed question (“why did organic drop last week?”) | IP addresses, in any form — raw, truncated or hashed |
| Aggregated metrics: entrances, conversions, bounce rate, revenue | Cookies or any device-side stored identifier |
| Grouping labels: channel, campaign, source, medium, term | Device fingerprints or probabilistic identity signals |
| Dimension breakdowns: page, landing page, device type, country | Visitor or user IDs linking sessions to a person |
| The date range and comparison window you selected | Cross-site or cross-device behavioural profiles |
| The report structure the assistant asked its own tools for | Raw visitor-level rows that could be re-identified |
The mechanism behind the left-hand column is worth spelling out. The assistant does not answer from memory or from anything it absorbed in training. It answers by calling tools — a 63-tool inventory covering overviews, channels, campaigns, funnels, segments and the rest — against your account's data, and then writing up what came back. The model is a language layer over your own reports.
That design has a privacy consequence and a quality consequence. The privacy one: the payload is bounded by what the reporting tools can return, and those tools cannot return a person. The quality one: figures in the answer come from a live query rather than the model's general knowledge, which is exactly why weak open-world factual recall in a model matters far less for grounded analytics than benchmark tables suggest. We went through that trade-off in detail in the model selection write-up.
The second layer: defence in depth
None of the above is an argument for being careless with the processing chain. A clean prompt is still your commercial data — your revenue, your channel mix, your campaign performance. That is not personal data, but it is not something you want sitting on someone else's training corpus either.
So the second layer is built as if the first did not exist. Inference for Seal AI runs on Scaleway Generative APIs in Paris, France, only. Scaleway is a French company whose parent is the Iliad group, with no US ownership, and it states explicitly that its AI services are not subject to extraterritorial laws such as the American CLOUD Act. It applies Zero Data Retention by default, with one documented exception: on a severe service error the failing request may be held for up to two weeks for root-cause analysis. It does not train on customer data.
On our side, the metering layer persists only token counters — organisation, model, input and output token counts — for quota and billing. Prompt and response content is never persisted by it. Transport is TLS 1.2 or above with certificate verification. And because nothing leaves the EU and the processor has no US parent, GDPR Chapter V is not engaged at all: no Standard Contractual Clauses, no Transfer Impact Assessment, no dependence on the EU-US Data Privacy Framework surviving its next hearing.
There is no setup to get wrong, either. No API keys to paste, no AI vendor account to open, no toggle a colleague can flip the wrong way. Customers who specifically want a different model can supply their own OpenAI, Anthropic, Gemini or DeepSeek key, and their prompts then travel to that provider under that provider's terms — a deliberate, per-customer choice, kept clearly separate. Seal AI is the default precisely so that privacy does not depend on configuration.
The order of operations
If you are evaluating an AI analytics feature, the most useful question is not "how do you protect the data you send to the model?" It is "what personal data do you have to protect in the first place?"
A vendor with a long, detailed answer to the first question and no answer to the second is doing careful work on a problem they chose to have. The cheapest personal data to protect is the personal data you never collected — and it is the only kind that cannot leak, be subpoenaed, or turn up in a training set by accident.