When you send a prompt to an AI inference provider, what happens to it? The optimistic answer is “it’s processed and discarded.” The honest answer is: it depends — on the provider’s infrastructure, their terms of service, their fine print, and how they interpret phrases like “we don’t train on your data.”
These two statements are not the same thing. And for developers building applications in regulated industries, the difference matters enormously.
The Problem With “We Don’t Train on Your Data”
Most major AI providers offer some variation of a data-use opt-out. They’ll tell you that prompts submitted through the API aren’t used to train their models. That’s useful, but it doesn’t tell the whole story.
What about logging? What about storage for debugging, abuse detection, or billing reconciliation? What about data that crosses jurisdictional borders before it’s processed? What happens if a subprocessor has different retention policies?
For a developer building a general-purpose chatbot, these questions might feel academic. But if you’re building for healthcare, legal services, finance, or public administration — sectors where data handling is governed by GDPR, NIS2, ISO 27001, or industry-specific regulations — they’re not academic at all. They’re requirements. Failure to answer them correctly can mean non-compliance, liability, or losing a contract.
Zero Retention vs. Zero Logging: Know the Difference
Before evaluating any provider, it’s worth getting precise about terminology. These claims are not equivalent:
- “We don’t train on your data” — Prompts may still be retained for other purposes: abuse monitoring, debugging, analytics.
- “Data is deleted after 30 days” — 30 days of exposure is 30 days of breach risk.
- “Zero data retention” — Means nothing is stored after inference completes. Verify this in the Data Processing Agreement (DPA), not just the marketing page.
- “Zero logging” — More stringent; means no server-side logs contain your content at all.
When evaluating a provider, ask for a copy of their DPA and look for explicit contractual language about retention periods. Marketing pages are not sufficient — the DPA is the legally binding document. If a provider can’t or won’t produce one with specific retention clauses, that’s an answer in itself.
The Legal Case for Zero Retention
Zero retention has moved from a marketing claim to a legal expectation in the EU.
GDPR’s Article 5(1)(e) requires that personal data be kept “for no longer than is necessary” for its stated purpose — a principle the European Data Protection Board applies strictly to AI systems. In practice, Data Protection Authorities across Europe have pushed back on blanket retention policies and required providers to demonstrate that retention serves a specific, documented, necessary purpose. “Model improvement” is increasingly not accepted as sufficient justification.
The EU AI Act adds another layer: for high-risk AI systems, logging requirements must be under the deployer’s control — not the provider’s. This means ZDR at the provider level is fully compatible with deployer-side audit logging, and actually the cleaner architectural choice. Your application controls what gets logged; the inference provider stays out of it.
For developers building in regulated sectors, this matters beyond compliance checkboxes. When retention becomes a business model — think cases where user-generated content has been sold for LLM training — the incentive structures work against user privacy. A provider who never retained the data cannot monetize it. ZDR eliminates that risk category entirely.
How Regolo.ai Does It
Regolo.ai, built by Italian cloud company Seeweb, has made zero retention an architectural property rather than a policy claim. The distinction matters: policy can change; architecture is harder to walk back.
Here’s how it works: when a request arrives, Regolo.ai forwards it directly to the inference engine running on Seeweb’s GPU infrastructure in Italian data centers. The model generates a response; that response is returned to the user. After the request completes:
- No prompt content is written to persistent storage
- No response content is logged
- No conversation history is retained server-side
- Only minimal metadata (timestamps, token counts) is kept for billing and statistical purposes
Regolo.ai functions as a gateway to the models it operates — not a data processor accumulating user content. The data flows through; nothing is kept.
A practical consequence of this design: conversation state is the developer’s responsibility. There is no server-side session. If your application needs multi-turn context, you pass it explicitly with each request. This is actually the right design from a privacy standpoint — you control exactly what context is sent, and you decide the retention policy for your users’ conversation history.
A Concrete Use Case: Aegis by Euraika
To see why this matters in practice, consider Aegis, a compliance management platform built by Euraika.
Aegis is designed to help organizations manage security and regulatory requirements across frameworks like NIS2, GDPR, and ISO 27001. It uses AI to enrich risk assessments, enhance policy documentation, and provide contextual analysis across compliance controls.
The problem Euraika faced was straightforward: their customers are organizations handling sensitive compliance data — internal policies, risk registries, audit evidence, vendor assessments. Sending that data to a standard inference provider, even one with opt-outs, creates a data governance problem. Their customers would reasonably ask: where is this going? Who can see it? How long is it kept?
By running inference through Regolo.ai, Euraika can answer those questions cleanly. The data doesn’t leave the request-response cycle. There’s no retained copy sitting in a provider’s infrastructure. The AI capabilities work; the compliance story holds.
This is the kind of architectural decision that usually doesn’t make headlines but determines whether a product can actually be sold into regulated markets.
Practical Considerations for Developers
If you’re evaluating Regolo.ai for a project, here’s what’s worth knowing:
API compatibility. The platform exposes a standard API for model inference, similar in structure to other providers. Integration lift is low if you’re already working with inference APIs.
Model availability. Regolo.ai hosts a range of open-weight models. Check their model catalog for current availability — it’s worth verifying that the model you need is supported before committing.
Pricing. The platform offers a pay-as-you-go option and flat monthly plans (Core at €39/month and Boost at €89/month). There’s a 30-day free trial with no credit card required, which makes evaluation low-friction.
Documentation. API docs are available at docs.regolo.ai.
Where it fits best. Regolo.ai is a good fit for applications where data privacy is a first-class requirement, where EU data residency matters, or where you need to demonstrate regulatory compliance to customers or auditors. It’s less differentiated for use cases where none of those constraints apply.
The Broader Point
The AI infrastructure market is consolidating fast, and most of the major providers are US-based, proprietary, and designed for scale at the expense of specificity. That’s fine for a lot of use cases. But “fine for a lot of use cases” isn’t the same as “right for yours.”
If you’re building applications in regulated sectors, or for European customers with serious compliance requirements, the question of where inference happens — and what happens to the data in transit — deserves more scrutiny than it typically gets. Regolo.ai is one of the few providers that has made data non-retention a structural property of their platform rather than a policy claim.
That’s a meaningful distinction. Whether it matters for your use case is for you to decide — but it’s worth understanding the difference.
Regolo.ai is available at regolo.ai. It is developed by Seeweb S.r.l., an Italian cloud infrastructure company.
