Data architecture and security

The founding principle

Your data is not hosted in the AI. It resides in a dedicated database, isolated per client, on servers located in the European Union. AI models are called on demand, via API, at the precise moment a task is executed, with only what is strictly necessary.

The full circuit fits in three blocks. Your systems (e-commerce, ERP, POS, PMS, marketing tools): your contracts, your credentials; BOUCLR reads what is necessary, on your instruction. The BOUCLR platform (European Union): PostgreSQL database on Hetzner infrastructure, strict per-client isolation, secrets encrypted with AES-256-GCM; this is where, and only where, your data is stored. The AI models: called at execution time, minimal extract, pseudonymised when the task allows, response returned to the platform, no training on your data; the model retains none of your data, it processes one request, then it is over.

1. Where the data is stored

• A single database per platform, compartmentalised per client. Every record is attached to a client identifier. All application queries are filtered on that identifier: a company user can technically only access their company’s data.
• Hosted in the European Union. The platform runs on Hetzner infrastructure (European operator, data centres in Germany and Finland), behind a hardened proxy. The application is never directly exposed to the Internet.
• PostgreSQL database in production, with regular backups and persistent volumes located on the same European infrastructure.
• Structural deletion. The data model is built with cascading deletion: deleting a client mechanically deletes all data attached to it.

2. How the AI intervenes, precisely

One-off, stateless calls. When a BOUCLR agent executes a task (analysing indicators, preparing a recommendation, drafting a campaign), the platform builds a request, sends it to the model via API, receives the response and stores it on its own systems. The model has no permanent access to the database: it only sees the content of the request, at the moment of the request.

Minimisation and pseudonymisation. The platform applies the minimisation principle: only the elements necessary for the task are transmitted. A concrete example, the churn prevention agent: the profile sent to the model is a pseudonymised summary (recency, frequency, amount, home store, reachable channels) together with an opaque reference. Neither the name, nor the email, nor the phone number of the end customer appears in the request. The mapping between the reference and the identity stays in the BOUCLR database, in the European Union.

No training on your data. The selected model providers (including Anthropic for the Claude models) contractually undertake, as part of their commercial API offering, not to use submitted data to train their models. Your data feeds no public model and cannot “resurface” elsewhere.

A dedicated key per client. Each client may have their own API key with the model provider. That key is encrypted (AES-256-GCM) in the platform and used exclusively for that client’s processing: direct contractual attachment, compartmentalised calls, cost transparency.

Complete traceability. Every agent execution is logged in the platform: which agent, when, on which perimeter, with which result. This traceability enables a complete audit and feeds transparency towards the client. These logs are subject to the same isolation and deletion rules as the rest of the data.

3. What third parties see (and do not see)

• The hosting provider (Hetzner, EU) sees the server infrastructure. It has no application-level access to the data; secrets are encrypted.
• The AI model provider sees the content of each request, at the moment of the request (minimised, pseudonymised when the task allows). It has no access to the database, no durable copy, no training on this data.
• Other BOUCLR clients see nothing. Isolation by client identifier on every table and every query.
• The IKKI’S DIGITAL OÜ team has named, logged operations and support access. No use outside the service; client secrets are unreadable without the environment master key.

4. Humans stay in the loop

Data security is not only about encryption: it is also about control. BOUCLR operates through four execution modes, chosen by the client, from manual mode (BOUCLR proposes, your team executes) to automatic mode (BOUCLR executes, your team supervises). In every case, thresholds and business rules are defined by humans, the agent proposes and the human validates at the chosen level. No outgoing action towards your end customers escapes the framework you have set.

5. Security measures at a glance

• Secrets encryption: AES-256-GCM (authenticated encryption) for all client API keys and connection credentials; per-environment master key, outside the source code; clear-text storage technically impossible.
• Encryption in transit: end-to-end TLS, automatic certificates, hardened proxy upstream, application never directly exposed.
• Isolation: logical per-client compartmentalisation across the entire data model, systematic application-level access controls.
• Access: three-level RBAC, per-company named authorisations, no self-escalation of rights.
• Authentication: OAuth SSO (Google, Microsoft) with minimal scopes and no token retention; hashed passwords where applicable; signed, httpOnly, time-limited sessions.
• Operations: containerisation, separated environments (pre-production / production), regular backups, log rotation, security review before every production release.
• End of contract: return of data in a structured format on request, then complete cascading deletion.

6. Resilience, backups and continuity

Protecting data also means guaranteeing it is not lost and that service can resume quickly after an incident (failure, attack, human error). The setup relies on several independent layers.

• Encrypted off-site backups: the database is backed up regularly to object storage located elsewhere than the application servers (European Union). These backups are independent from the production infrastructure.
• Tested restoration: the full restoration procedure is verified, so that recovery is not a hypothesis but a proven capability.
• Independent copy: a copy of the backups is kept on a second server, in another data centre, out of reach of a compromise of the primary server.
• Real-time replication: a live copy of the database is continuously maintained on a second server (another data centre), ready to take over. Files uploaded to the platform are also replicated at short intervals.
• Proven failover: the recovery setup is not theoretical; it is measured and proven through real failover exercises to the standby server, carried out under production conditions.
• Network protection: public traffic goes through a network protection service (filtering, denial-of-service attack mitigation).
• Detection and response: server health is continuously monitored; an alert is triggered on incident, and a documented recovery procedure allows immediate action.
• Data breach: in the event of an incident affecting personal data, the affected clients are notified without undue delay, within the 72-hour timeframe set by the GDPR.

7. Frequently asked questions

• Is my data used to train an AI? No. The model providers used via API undertake not to train their models on submitted data. Your data remains your data.
• Is my data stored at the AI provider? No. Storage is handled by the BOUCLR platform, in the European Union. The model receives a one-off request and returns a response; it retains none of your data.
• Can another BOUCLR client see my data? No. Every record is attached to your client identifier and every application query is filtered on it. The compartmentalisation is structural, not declarative.
• Where are the servers physically? In the European Union, on Hetzner infrastructure (Germany / Finland), behind a network protection proxy.
• Who holds the access to my systems (e-commerce, marketing, ERP, POS)? You do. BOUCLR uses the credentials you provide, stores them encrypted with AES-256-GCM, and uses them exclusively for the subscribed services. You can revoke them at any time from your own tools.
• What happens if we stop? Your data is returned to you in a structured format on request, then completely deleted from the platform, backups included at their normal purge cycle.
• Can an action go out to my customers without validation? Only if you chose automatic mode for that type of action, within the framework and thresholds you defined. By default, the agent proposes and your team validates.