The security model we are building RiOS on.
RiOS is in development. This page sets out the security and privacy model we are building the platform to, alongside how the Revenue Audit already handles your data today. We would rather show the model early than overstate what is live.
How the audit handles your data today.
The audit is live and runs on its own setup, separate from RiOS. These are the parties involved, per step.
Pseudonymised is not anonymous: we treat this data as personal data.
- 01Free scanThe calculation runs in your browser and uses no AI. Your details are stored with Supabase and the notification goes out through Microsoft 365.
- 02Audit questions in the portalYou answer five blocks of questions. No system of yours is connected and there is no data export. Answers are stored with Supabase; the region is recorded in the DPA.
- 03AnalysisAn AI provider in the US (Anthropic) receives pseudonymised figures and scores, without company or customer names, under EU standard contractual clauses.
- 04ReportWe check the findings by hand and send the report through Microsoft 365. The full list of subprocessors is in the DPA.
How data is designed to move through RiOS.
A simple map of the intended flow, from the systems you already use to the numbers on your dashboard. This is the target architecture for the platform, currently in build.
- Your existing systemsCRM, ERP, finance, marketing tools
- RiOS reading layerReads, never replaces
- Tokenisation layerPersonal data removed before any AI
- AI engineRow-level security · Invented numbers refused
- Leak detection & scoringOne agreed set of numbers
- Dashboard & recommendationsWhat your team acts on
- 01Your existing systems
Everything starts in the systems you already run: your CRM, ERP, finance and marketing tools. RiOS asks for read access only, and you decide which systems it may see.
- 02RiOS reading layer
The reading layer pulls data out of those systems and never writes back on its own; automations only run after you approve them. Your tools stay the source of truth.
- 03Tokenisation layer
Before anything reaches an AI model, a processing step replaces names, email addresses and other identifying data with tokens. That is pseudonymisation, not anonymisation: under the GDPR the result is still personal data, and we treat it that way.
- 04AI engine
The AI engine is built inside two hard rules. Row-level security in the database decides what each user may see, and an answer containing a figure that was not in the evidence is refused before anyone sees it.
- 05Leak detection & scoring
Findings from every system are combined into one agreed set of numbers: what leaks, what it costs in euros and how sure we are. No two dashboards that disagree.
- 06Dashboard & recommendations
Only checked results land on the dashboard: the leak, the euro amount and the suggested fix. That is what your team acts on, with the trail back to the source data.
In the RiOS code there is one route to an AI model, and it runs through the tokenisation step: a model call without it does not compile. Names and contact details become tokens first, and what a model answers is checked before anyone sees it. Tokens are pseudonymised data, not anonymous data, so the GDPR still applies in full.
What is built, what is set up, what is agreed.
Every measure carries its status. Tested means automated tests in our own code that try to get around the rule and have to fail. That is not an external pentest or a certification, and RiOS does not run at customers yet.
- In the code, tested
- Configured
- Agreement
- In the code, testedA privacy boundary the compiler enforces
An AI model is reachable only through one type that only the tokenisation step can create. Code that tries to go around it does not compile. If tokenising fails, nothing is sent.
- In the code, testedRow-level security in the database
Postgres decides per organisation what is visible, not the app. Tests try to read another organisation's data and must be refused.
- In the code, testedAccess through a verified domain
Staff get in through the company domain you confirm with a DNS record. One domain belongs to one organisation, enforced in the database.
- In the code, testedInvented numbers are refused
An AI answer with an amount or figure that was not in the evidence is not shown. The model never picks the action either; a rule does.
- In the code, testedWrite-back only after approval
Connections read first. A change in your systems needs a named approver and a way back before anything is sent.
- ConfiguredHosting set up in Frankfurt
The RiOS services are configured for Frankfurt and AI models run through an EU region; any other region switches them off. The database region is recorded per environment in the DPA.
- AgreementA DPA before anything is connected
Signing a data processing agreement, with every subprocessor listed, is part of onboarding. Nothing is connected before that.
- AgreementDeleted when you stop
Your own systems stay the source of truth. What RiOS holds is deleted when you leave, in line with the privacy policy.
What RiOS reads, and what it never touches.
Read access to business data, nothing more. This is the exact split.
- Deals, pipelines and account activity from your CRM
- Invoices and payment status from billing and finance
- Campaign spend and results from your ad platforms
- Support tickets and response times
- Send personal data to AI models: it is tokenised first
- Write or change anything without your approval
- Reach systems you haven't connected
- Sell your data, or share it for marketing
The questions procurement and legal actually ask.
Only your answers to the audit questions and our own notes. Nothing gets connected to your systems for the audit; there is no integration, no data export, no access to grant.
For RiOS, the services are configured for Frankfurt and AI models are only reachable through an EU region. The database region is confirmed per environment and recorded in the DPA, together with every subprocessor, before you onboard. For the Revenue Audit, one AI provider processes pseudonymised figures outside the EU under EU standard contractual clauses; no names go there.
Yes: signing a DPA (verwerkersovereenkomst) is part of onboarding, before anything is connected. Ask us and we'll walk your legal team through the data flows ahead of that.
The platform is built on two rules: access tied to your verified company domain (checked by DNS), and row-level security in the database deciding what each user may see. No hand-managed permission lists to drift out of date.
Tokens, not people. The pipeline is designed so personal and identifying data is removed before anything reaches an AI model. That holds for every model we use, not only the ones outside the EU: all of them receive pseudonymised tokens. Pseudonymised is not anonymous, so we treat that data as personal data.
Your own systems were always the source of truth, so nothing needs to be migrated back. The data RiOS holds is deleted; we keep nothing longer than necessary, in line with our privacy policy.
The Revenue Audit follows proven business-analysis methods, including MECE issue trees, the Pyramid Principle and Three Horizons planning, used the same way across all five blocks.
Questions from procurement or legal?
Ask us anything about the data flows, the DPA, or the architecture. You'll talk directly to the person building it.