Skip to content
Data Protection

Data Protection Declaration

Status: being drafted

This document is being written

Bricks is preparing a comprehensive Data Protection Declaration aimed at the people whose personal data is processed by apps built on the platform — end users, members, visitors, and anyone else whose data a Bricks-hosted app collects. It is not yet published.

We are not silent about this gap on purpose: a Data Protection Declaration that misrepresents what actually happens is worse than no declaration at all. Drafting properly requires us to map exactly which platform-level data we collect about end users (BricksID account info, /account-view metadata, edge access logs), separately from the tenant-level data each controller collects through their own app, and explain both in plain language without lawyer-speak.

To be more specific about what is taking time: it is not the mapping of the data we process or of the techniques we use — we know both precisely. The real challenge is to make this material, which deals with advanced technologies (multi-tenancy, AI orchestration, per-tenant encryption, data-flow declarations), accessible in plain language to end users who have no reason to be experts. As proof of good faith, the public can already read our Data Processing Agreement: that document, more technical by nature, is already very complete and publicly readable. We are hiding nothing — we are working on how to make the same substance readable for a non-technical audience.

Who is responsible for data protection at Bricks

RainbowTop Softwares SRL has not designated a Data Protection Officer (DPO) in the formal sense of the GDPR. Under Article 37(1) of Regulation (EU) 2016/679, the designation of a DPO is mandatory only when:

  • the processing is carried out by a public authority or body (Art. 37(1)(a)) — RainbowTop Softwares is a private company, not concerned;
  • the core activities consist of processing operations which require regular and systematic monitoring of data subjects on a large scale (Art. 37(1)(b)) — RainbowTop Softwares does not engage in behavioural monitoring, advertising, or profiling of its users;
  • the core activities consist of processing on a large scale of special categories of data referred to in Article 9 or personal data relating to criminal convictions and offences referred to in Article 10 (Art. 37(1)(c)) — none of these are processed at the BricksID layer.

In the absence of a regulatory designation obligation, responsibility for data protection is taken on personally by Simon Mulquin, CTO and co-founder of RainbowTop Softwares SRL. This responsibility covers the periodic review of the platform's technical and organisational measures, the maintenance of the present Declaration and of the Data Processing Agreement, the handling of data-subject rights requests under Articles 12–22 GDPR, and the platform's relationship with its sub-processors.

Conflict of interest — transparency. RainbowTop Softwares acknowledges that performing the de-facto DPO role from a senior-management position sits in tension with the functional-independence requirement that GDPR Article 38(6) imposes on a formally designated DPO. At the company's current scale, and absent any obligation to designate, this tension is accepted for the following reason: someone has to hold the function, and in the current structure Simon Mulquin is, by role and by training, the most qualified person to do so — he has held this role in other organisations before. This trade-off will be revisited as soon as RainbowTop Softwares's structure or processing scale crosses any threshold of Article 37(1), or earlier if an independent qualified person joins the company.

For any data-protection question, write to simon@bricks-softwares.com.

What you can do in the meantime

  • If you have a BricksID account, sign in and visit /account. The "My data" view shows every field stored on your account at the platform level; "My apps" shows every Bricks-hosted app you've authenticated to and the controller behind each.
  • For per-app processing, the controller of each app is responsible for its own data-protection notice. Look on the app's site itself, or contact the organisation that operates the app (their contact appears in your /account view under "My apps").
  • For platform-level technical detail on isolation, encryption, sub-processors, retention, and AI orchestrator data protection, the Data Processing Agreement covers all of it — that document is written for business audiences but is publicly readable and may answer most technical questions an end user could have.
  • Direct questions to support@bricks-softwares.com. We will respond to individual data subject requests under GDPR Articles 12–22 even before the declaration is published.

What we can already tell you, in plain language

The substance below is preliminary and may be rephrased before the final declaration publishes. It is not the final document — but it is accurate as of today, and we would rather make it readable here than leave you with a stub.

Who holds what about you

Two distinct people may hold personal data about you when you use an app built on Bricks: Bricks itself (the platform) and the organisation that operates the app (your association, your employer, the small business whose service you are using — the "controller" in GDPR vocabulary). The split matters because the answers to "who do I write to about my data?" depend on it.

  • Bricks holds: your BricksID account information (email, hashed password, sign-in history, active sessions); the list of which Bricks-hosted apps you've authenticated to; and edge access logs (IP address, browser identification) for a rolling 30-day window for security and abuse-investigation purposes. Bricks does not run analytics, tracking pixels, advertising, or behavioural profiling on you.
  • Each organisation holds: the personal data its apps collect from you — your profile in its system, content you authored, your interactions with its service. An organisation that runs several apps on Bricks holds its data centrally for those apps (by design: the organisation, as controller, is accountable for the data of every app it operates and applies its own access rules across them). Two apps run by two different organisations, by contrast, are two fully separate sets of records — even if you sign in to both with the same BricksID.

How to see and exercise your rights now

You don't need to wait for the final declaration to see what's held about you or to exercise your GDPR rights.

  • For your platform-level data: sign in and visit /account. "My data" shows every field Bricks holds on your account; "My apps" shows every Bricks-hosted app you've authenticated to, with the name and contact email of the controller behind each. You can delete your BricksID account yourself from this interface — the deletion cascades according to the procedure described in §10 of the Data Processing Agreement.
  • For per-app data: the same "My apps" view shows you, per application, the list of automated processing the app runs that touches your data. This is structured information drawn from the app's actual workflow configuration, not a marketing summary — what you see is what the app actually does. Export and erasure requests for per-app data are routed from there directly to the controller of that app.
  • Direct questions: write to support@bricks-softwares.com. We respond to data-subject requests under GDPR Articles 12–22 even before the declaration is published.

What protects your data, in plain words

  • Each organisation's data is isolated from every other organisation's. Two different organisations running apps on Bricks cannot see each other's records — each tenant has its own dedicated database area, and the platform cannot construct a query that crosses that boundary. Within a single organisation, the apps it operates share its database on purpose: the organisation owns and accounts for its data across every app it runs, rather than having that data fragmented across as many silos as it has apps. Who can see which records inside that shared organisation database is then controlled by the organisation's own role-based access rules (row-level security) — and those rules are verified by an automated test that runs on every release.
  • Everything is encrypted in transit and at rest. Traffic to Bricks-hosted apps is always served over HTTPS (TLS); the underlying disks at our VPS hosting provider (Infomaniak, in Switzerland) are encrypted at the hardware level, and the managed database and file storage we use (both Scaleway, in France) are encrypted at rest by the provider.
  • The companies that handle your data on our behalf are named. The platform sends data to a small number of named providers — Infomaniak (CH) for VPS hosting and our own team mailboxes; Scaleway (FR) for the platform's database, file storage, and tenant-app outbound email when an organisation has opted in to bricks-emails.eu; Brevo for the automated emails the platform itself sends to you (sign-in and password-reset emails, organisation invitations, signup confirmations); Anthropic (US) for the Studio AI that helps the controller build their app; Mollie (NL) for payment processing; and optionally Scaleway again for Mistral language-model inference when an organisation has selected that sovereignty preset. The full breakdown — what each provider sees, in what jurisdiction — lives in §7 of the Data Processing Agreement.
  • One honest gap, named and in motion. The automated account-related emails the platform sends you (sign-in confirmations, password-reset links, magic sign-in links, organisation invitations) currently travel through Brevo. Brevo itself is a French company, but their email infrastructure routes through the United States. This is the only part of the platform that doesn't yet match the EU-resident posture we want. On 5 June 2026 we started the work to move these emails to Scaleway, an EU-resident provider; status is tracked openly in our internal debt log.
  • If a risky operation needs to happen, your data is snapshot first. When the AI that helps an app's operator build their app needs to make a destructive change (for example, dropping a column or changing a column's type), the platform takes a backup of that app's data before the change — automatically when the operator is working in the deeper "heavy reasoning" mode against a production tenant, or on the operator's explicit approval otherwise — and briefly puts the app into a "maintenance" state so visitors see a status page rather than a half-changed application while the change is applied. If the change produced an unintended outcome, the backup is the recovery point. When the AI explores a change inside its own internal sandbox before applying it to live, it does so against synthetic data it generates itself — your real records are never made available to the AI for this purpose.
  • No third-party scripts on Bricks-hosted apps. Apps cannot pull JavaScript, web fonts, or stylesheets from third-party origins; every external request the app might cause your browser to make has to be explicitly declared by the controller, with the vendor, the purpose, the data categories, and the lawful basis recorded. Anything not declared is blocked at the browser level.
  • The AI that helps build apps never reads your data. The Studio AI assists the controller in building their app, but it cannot read the deployed app's database rows or your content as a visitor. Anthropic, the AI provider, receives only the controller's own messages and the metadata about the controller's app code — not the personal data of the people who use it.
  • Authentication errors fail closed. Sessions are bound to strict expiry; tokens missing or carrying invalid expiry are refused at the API boundary itself, not after they have been used.

What is not done with your data

  • You are not tracked across apps for advertising or analytics purposes.
  • Your data is not sold to third parties.
  • Bricks staff cannot impersonate you. Access by Bricks staff to a tenant's infrastructure for support purposes is logged and requires a documented reason.
  • You are not silently consented to "AI training". The Studio AI runs against Anthropic's commercial API; under Anthropic's Commercial Terms of Service their generative models are not trained on customer API inputs and outputs by default. Anthropic retains inputs and outputs for a short window for abuse-detection and trust-and-safety purposes — the current published retention is documented on Anthropic's privacy portal. Bricks does not enable any extended-retention beta feature, does not attach end-user identifiers to API calls, and does not opt into any training-related programme; the platform's call to Anthropic is a plain commercial API request. As a separate matter, your data as an end user does not enter those API calls in the first place (see "The AI that helps build apps never reads your data" above).

Why we publish this placeholder rather than nothing

Bricks positions itself as an ethical, compliance-first platform. A platform whose Data Protection Declaration "is coming" without saying so explicitly would not match that position. This placeholder is the honest version of an in-progress document: what we're working on, why it isn't ready yet, and where to look in the meantime.

When will this ship?

No specific date. The declaration ships when it is accurate, complete, and reviewed. This page will be replaced by the full declaration in place — same URL, no breaking link change.

This page is published in English and French; the FR version is available at /data-protection-declaration/fr. Both versions are kept in sync as the placeholder evolves.