De belofte, en de eerlijke reikwijdte
De inhoud van klantdossiers (documenten, persoonsgegevens, contracttekst) wordt versleuteld opgeslagen. Alleen Jan (notaris) en Louis (advocaat), en de klant zelf, kunnen die inhoud ontsleutelen. Wij als ontwikkelaars beheren het systeem en zien de structuur (welke dossiers, status, wie-wat-wanneer), maar niet de inhoud van dossiers die Jan of Louis aanmaken.
Dit is niveau B: de sleutel leeft buiten ons bereik in een Europese sleutelkluis, wij staan niet op de toegangspolicy, en elke poging wordt geweigerd en gelogd. Het is geen wiskundige onmogelijkheid (dat is niveau A, waarbij alleen Jan/Louis de sleutel bezitten). Het verschil staat verderop expliciet uitgelegd.
De vertrouwensgrens
De kern is het scheiden van metadata (die wij nodig hebben om te beheren) en inhoud (die vertrouwelijk is). Iedereen zit in hetzelfde systeem, maar niet iedereen kan hetzelfde ontsleutelen.
Kan de sleutel gebruiken in de kluis en dus documenten en persoonsgegevens ontsleutelen, alleen van de eigen dossiers.
Beheert het systeem en ziet structuur en status, maar krijgt voor Jan/Louis-dossiers alleen onleesbare cijfertekst. Geen sleuteltoegang.
De opslag (Supabase) staat zelf ook buiten de grens: daar ligt alleen cijfertekst. De sleutel ligt ergens anders.
Envelope-encryptie: twee sleutels op elkaar
Elk dossier krijgt zijn eigen datasleutel (DEK) waarmee de inhoud wordt versleuteld (AES-GCM). Die datasleutel wordt zelf versleuteld ("gewrapt") door een hoofdsleutel (KEK) die in de Europese sleutelkluis van Scaleway (Key Manager) leeft.
Om iets te lezen moet je de kluis vragen de DEK te "unwrappen" met de KEK. Dat mag alleen wie op de policy staat, en elke vraag wordt gelogd.
Waarom wij niet kunnen ontsleutelen
Voor de vertrouwelijke dossiers (aangemaakt door Jan/Louis) gebruikt het systeem een aparte hoofdsleutel, KEK-client. Drie feiten samen maken dat wij daar niet bij kunnen:
- Wij staan niet op de policy. De toegangsregels van KEK-client in Scaleway Key Manager noemen de developer-identiteiten niet. Een ontsleutel-verzoek van ons wordt geweigerd.
- De sleutel is niet te exporteren. Een KMS-hoofdsleutel verlaat de kluis nooit. Er is dus geen kopie die wij uit de database of code kunnen vissen.
- Elke poging wordt gelogd. Scaleway registreert elk sleutelgebruik en elke geweigerde poging, met identiteit en tijdstip.
Log in als developer en open een dossier van Jan: het systeem vraagt de kluis om te ontsleutelen, geweigerd, de dataroom toont "versleuteld, geen toegang", en in het Scaleway-logboek staat de geweigerde poging. Log in als Jan: ontsleutelen lukt, inhoud zichtbaar. Datzelfde logboek laat over vijf jaar zien dat KEK-client nooit door een developer is gebruikt.
Niveau B rust op een scharnierpunt: wie beheert de policy van de kluis? Daarom is Jan de KMS-beheerder, niet wij. Als wij de beheerder waren, konden wij onszelf toegang geven (wel gelogd). Nu ligt het beheer bij Jan, en kunnen wij de policy niet zelf wijzigen. Wil je "wiskundig onmogelijk", dan is dat niveau A: de sleutel uitsluitend bij Jan/Louis, wat automatische AI-verwerking beperkt.
Wie het dossier aanmaakt, bepaalt de zichtbaarheid
| Dataroom aangemaakt door | Hoofdsleutel | Wij (developers) zien |
|---|---|---|
| tal@ / jelle@ / naut@workflowautomations.nl | KEK-dev | Leesbaar, voor testen |
| Jan (notaris) of Louis (advocaat) | KEK-client | Versleuteld, niet zichtbaar |
| De klant (via portaal-link) | KEK-client | Versleuteld, niet zichtbaar |
Zo kunnen wij blijven ontwikkelen en testen met onze eigen datarooms, terwijl echte klantdossiers standaard buiten ons zicht vallen.
Onversleuteld naar de AI, zonder namen en zonder dat wij meekijken
Het belangrijkste AI-gebruik is due diligence bij overnames: de AI loopt met een vaste regelset door complete documenten en controleert op veelvoorkomende fouten. Twee beschermingen tegelijk: (1) de tekst wordt alleen ontsleuteld in een verwerkings-laag onder een eigen identiteit (niet de developer-identiteit) die niets logt, en (2) voor verzending worden namen, adressen en bedragen vervangen door tokens (pseudonimisering), zodat het model geen identificerende gegevens ziet.
Juridisch: ja, vrijwel identiek. In beide gevallen draait het model op de hardware van een EU-verwerker (Scaleway = Frans, Hetzner = Duits, beide buiten de Amerikaanse Cloud Act). Zelf hosten geeft dezelfde juridische positie voor veel meer werk.
Alleen eigen hardware haalt de derde partij echt weg, maar dan word jij de operator die bij de data kan, wat botst met "wij kunnen er niet bij". Gelaagd (encryptie + geblokkeerde verwerker + pseudonimisering + audit) verslaat monolithisch ("ons eigen kastje").
De AI-opstelling, per keuze afgewogen
1 · Gedeelde EU-API (Scaleway Generative APIs)
licht gebruikServerless, goedkoop, EU, geen training. Maar gedeelde infra: contractueel privé, niet geïsoleerd. Zwakker verhaal voor beroepsgeheim dan dedicated.
2 · Scaleway Managed Inference (dedicated)
aanbevolen basisEén model, één GPU, één klant, in je eigen VPC. Geen opslag/training/derden-toegang. EU, geen Cloud Act. Vaste uurprijs, gunstig voor grote DD-batches. Verwerker onder DPA + afgeleide geheimhoudingsplicht. KNB en NOvA staan cloud/verwerkers toe mits passende waarborgen. (Geen juridisch advies, laat toetsen + DPIA.)
3 · Zelf hosten (Hetzner / EU-cloud GPU)
afgeradenZelfde juridische positie (Hetzner is nog steeds een verwerker) voor veel meer werk (GPU-ops, patches, uptime). En jullie worden operator, wat botst met "wij kunnen er niet bij".
4 · Eigen hardware (Rotterdam)
toekomstoptieGeen derde partij meer, maar jullie worden zelf de operator (zwakker "devs niet"-verhaal) en hoge kosten/moeite. Verbetert de juridische positie niet t.o.v. een EU-verwerker onder DPA. Bewaren voor als een klant het eist.
5 · Pseudonimiseringslaag (bovenop elke optie)
vaste laagIdentificerende gegevens worden voor verzending vervangen door consistente, omkeerbare tokens; de mapping blijft binnen de grens. De AI-leverancier ziet geen namen. Werkt voor DD-foutcontrole omdat structuur en inhoud intact blijven. Zie de implementatie →
Optie 2 + Optie 5: Scaleway Managed Inference met een vaste pseudonimiseringslaag, boven op de encryptie (Jan's sleutel) en de audit. Simpel te beheren, juridisch verdedigbaar, en het sterkste verhaal.
Alles is aantoonbaar gelogd, ook over vijf jaar
- Applicatie-logboek, onwijzigbaar geketend. Elke gevoelige gebeurtenis staat in een append-only tabel waarin elke regel de hash van de vorige bevat, zodat elke wijziging opvalt.
- Weggeschreven buiten ons bereik. De logs stromen naar onwijzigbare opslag (object-lock/retentie) in een aparte omgeving.
- Sleutel-logboek van Scaleway. De kluis registreert onafhankelijk elk sleutelgebruik en elke policy-wijziging. Dit toont dat KEK-client nooit door een developer is gebruikt.
Rollen × rechten
| Kan … | Developer | Jan & Louis | Klant |
|---|---|---|---|
| Dashboards, dossierlijsten, status zien | ja | ja | nee |
| Systeem beheren, deployen, support | ja | nee | nee |
| Inhoud van klant-dossiers lezen | nee | ja | eigen |
| Documenten toevoegen | test | ja | ja |
| Dataroom verwijderen | test | ja | nee |
| AI-analyse op klantdata | gepseudonimiseerd | ja | nee |
Levend document, concept ter bespreking. De sterkere varianten (kluis-beheer bij een neutrale partij, confidential computing, of volledig niveau A) zijn hardeningsstappen die later kunnen worden toegevoegd zonder het model om te gooien.