De laag die je als eerste tekent en als laatste leest

Een bedrijf dat soeverein had moeten zijn

Enige tijd geleden werkte ik met een organisatie die op papier volledig eigenaar was van haar data.

De hardware was van hen. De server stond in een ruimte waarvan zij de sleutel hadden. Ze onderhielden de software erop zelf. Ze konden inloggen op de database, hem bevragen, het schema wijzigen, rijen bijwerken en verwijderen.

Toen wilden ze die data koppelen aan een nieuw platform, en het contract zei nee. Of eigenlijk: ja, maar alleen via de oorspronkelijke leverancier, en tegen een stevige aanvangsprijs. Ze bezaten de data; het ergens anders heen verplaatsen liep via de leverancier die het systeem jaren eerder had gebouwd.

Op elke laag die ze konden zien, waren ze soeverein. Op de laag die ze niet konden zien, niet.

De vierde laag

Deel 1 beschreef datasoevereiniteit als drie rechten, om te bezitten, te gebruiken en weg te doen, gehouden over drie technische lagen heen: de hardware waarop de data draait, de software die deze verwerkt, en de data zelf. Volgens die toets faalde de gemeente uit deel 1 onderaan de stack: ze bezat de data van haar inwoners terwijl de hardware en software eronder van iemand anders waren. De organisatie hierboven is het spiegelbeeld. Ze bezat alle drie de lagen volledig en kon toch niet handelen. Zet de twee gevallen naast elkaar en het patroon wordt zichtbaar: soevereiniteit faalt bij de zwakste laag, en niet elke laag bestaat uit technologie.

Onder de andere drie ligt een vierde laag, en die bepaalt of de rechten überhaupt uitgeoefend kunnen worden. Noem het de organisatorische laag: de contracten, licenties, servicevoorwaarden en governance-afspraken die tussen jou en je data in staan. Dat is waar het recht om te handelen daadwerkelijk wordt toegekend. Het academische model uit deel 1 kent de overeenkomst hetzelfde gewicht toe: in het zeven-aspectenmodel van von Scherenberg, Hellmeier en Otto bevindt de contractuele overeenkomst zich “in the middle, as it consists of the main conditions for maintaining control over data assets” (von Scherenberg et al., 2024). Het data-asset is wat het model beschermt; de overeenkomst is waar die bescherming wordt bepaald.

Deel 1 eindigde bij handhaving: een contract op zich is niet meer dan een belofte tot infrastructuur het toepast. Dat werkt twee kanten op. Infrastructuur kan alleen rechten afdwingen die de overeenkomst daadwerkelijk verleent, en geen van beide waarborgen dekt het risico op zichzelf af (Irion, 2012). De wet voegt nog een beperking toe: de rechten op toegang en dataportabiliteit die het EU-datarecht verleent zijn, zoals één analyse van het concept van de Data Act het verwoordde, “rights in personam”, aanspraken die je tegenover een specifieke partij hebt in plaats van zeggenschap over een ding (Geiregat, 2022). Je soevereiniteit is nooit sterker dan je overeenkomst met wie de sleutels heeft.

De eerste drie lagen zijn zichtbaar. Je kunt de server aanwijzen, de database openen, de code lezen. De vierde is onzichtbaar tot het moment dat je wilt handelen, en dan heeft ze het antwoord al bepaald.

Waarom dit de laag is die bijt

Twee dingen maken de organisatorische laag gevaarlijk.

Het eerste is timing. Het contract wordt aan het begin getekend, voordat iemand alles weet waar de data voor gebruikt gaat worden. De organisatie hierboven had haar voorwaarden afgesproken toen het systeem voor het eerst werd gebouwd; de koppeling die door die voorwaarden werd geblokkeerd lag toen nog niet eens op tafel. Dit is de gewone vorm van “lock-in”, en de economie erachter is al decennia bekend: overstapkosten zijn laag om binnen te komen en hoog om te vertrekken, dus een zittende leverancier kan het werk goedkoop binnenhalen en daarna voor elke wijziging rekenen (Klemperer, 1987, 1995). De vergrendeling is niet alleen commercieel. Gewoonte en traagheid doen hetzelfde werk van binnenuit (Murray & Häubl, 2007; Polites & Karahanna, 2012), en mijn eigen onderzoek vindt hetzelfde patroon in gereguleerde organisaties (Everaars, 2024).

Het tweede is aandacht. Het publieke debat gaat over de lagen die je kunt zien: “soevereine cloud”, “soevereine software”, open datastandaarden. In de projecten die wij zien, wordt het contract pas echt onder de loep genomen zodra er al iets geblokkeerd is: deze organisatie tekende haar voorwaarden op dag één en las ze pas jaren later nauwkeurig, op de dag dat ze wilde verhuizen. Een handtekening wordt ook makkelijk aangezien voor bescherming op zich, terwijl voorwaarden die op basis van slikken-of-stikken worden aangeboden je binden zonder je te beschermen (Rhoen, 2016).

Dezelfde valkuil is zichtbaar bij overheidsorganisaties, omdat zij moeten publiceren. In oktober 2023 zette de gemeente Kampen, die de Centric-applicaties waar ze al lang op leunt inkoopt via een shared service center (SSC ONS) met Zwolle en de provincie Overijssel, in een formeel besluit uiteen waarom ze de standaardvoorwaarden van de leverancier opnieuw wilde onderhandelen: die voorwaarden waren “éénzijdig, geschreven vanuit opdrachtnemers kant”, waarbij de risico’s en aansprakelijkheden vooral bij de klant lagen. Haar antwoord was om het nieuwe raamwerk in plaats daarvan te baseren op de standaard inkoopvoorwaarden voor IT van de gemeentesector (GIBIT) (Gemeente Kampen, 2023). Niets hiervan is dramatisch: het is de gewone prijs van het tekenen van de papieren van de leverancier, en die is het goedkoopst te bevragen voordat de architectuur en het budget vastliggen.

Wat het contract eigenlijk bepaalt

Het helpt om de organisatorische laag te lezen door dezelfde drie rechten uit deel 1, want dat is wat ze verleent of onthoudt.

Bezitten. Heb je je eigen kopie van de data, in een bruikbare vorm, met het recht om die te houden? Of zit de enige gezaghebbende kopie in het systeem van de leverancier, alleen voor jou beschikbaar zolang de relatie duurt?

Gebruiken. Kun je de data koppelen, bevragen en erop voortbouwen met tools naar keuze? Of moet elk nieuw gebruik, zoals de koppeling die die organisatie wilde, weer via de leverancier lopen?

Wegdoen. Kun je de data verwijderen en aantonen dat die weg is, en, minstens zo belangrijk, kun je vertrekken? Exit is de clausule waar we het eerst naar zoeken en die we het minst vaak vinden: het recht om alles in een open formaat te exporteren, en om de kopieën van de leverancier te laten vernietigen als je weggaat. Het EU-recht is hier gaan duwen. De Data Act verplicht cloudproviders nu om overstappen makkelijker te maken (Reg. (EU) 2023/2854), en het recht op dataportabiliteit uit de AVG was bedoeld als exitmechanisme, niet alleen als toegangsrecht (De Hert et al., 2018). Toch concludeert een recente analyse dat de nieuwe EU-regels soevereiniteit maar deels leveren (Ryan et al., 2024). Een wet legt een ondergrens vast; het contract regelt de rest.

Onder alle drie ligt één vraag: wie kan de data nog meer bereiken? Subverwerkers, offshore support, een analytics-partner in een andere jurisdictie. Waar de wet van een ander land een provider kan dwingen om data af te geven, zoals de Amerikaanse CLOUD Act kan (Daskal, 2015; Cross-Border Data Forum), bepaalt het contract ook je blootstelling.

Voordat je tekent

Dit alles komt neer op één vraag die het waard is om te stellen vóór welke handtekening dan ook: als we willen handelen, wie moet er dan akkoord gaan?

Als het eerlijke antwoord “de leverancier” is, koop je een dienst, geen soevereiniteit, hoeveel van de hardware en software je ook bezit. Nog een paar vragen maken de laag zichtbaar terwijl je hem nog kunt veranderen, en ze zijn het goedkoopst te stellen voordat de architectuur is gebouwd en het budget is getekend:

• Als we deze data over twee jaar naar een ander platform willen verhuizen, kan dat dan, en tegen welke kosten?
• Als we die willen verwijderen, kunnen we dan elke kopie verwijderen, inclusief die van de leverancier, en aantonen dat we dat gedaan hebben?
• Wie kan deze data vandaag lezen zonder onze uitdrukkelijke toestemming?
• Als de leverancier zijn prijs verhoogde, zijn voorwaarden wijzigde of verdween, wat zouden we dan op eigen kracht kunnen doen?

Hoe wij het aanpakken

Daarom behandelen we portabiliteit als een ontwerprandvoorwaarde in plaats van een feature, en daarom zijn we bewust bezig met onze eigen contracten. Een platform dat gebouwd is om te verhuizen voorkomt dat de technische lagen je gevangen houden. Voorwaarden die je rechten op de broncode, exit-ondersteuning en de optie van escrow geven voorkomen dat de organisatorische laag hetzelfde doet, en de onze leggen dat schriftelijk vast (algemene voorwaarden, artikelen 11 en 22): geen enkele leverancier zou de code van je platform mogen “gijzelen”, en dat geldt ook voor ons. Je zou HOIST IT net zo makkelijk moeten kunnen verlaten als je binnenkwam.

Wat er hierna komt in deze serie

Deel 1 definieerde datasoevereiniteit; dit deel keek naar de contractlaag die bepaalt of je die kunt gebruiken. Deel 3 gaat over de technische lagen in de praktijk: de architectuur, tooling en data spaces die voorkomen dat hardware, software en data je opsluiten, tot de enige laag die nog te onderhandelen valt de laag op papier is.

Bronnen

• Daskal, J. C. (2015). The un-territoriality of data. Yale Law Journal, 125(2), 326–398. https://www.yalelawjournal.org/article/the-un-territoriality-of-data
• De Hert, P., Papakonstantinou, V., Malgieri, G., Beslay, L., & Sanchez, I. (2018). The right to data portability in the GDPR: Towards user-centric interoperability of digital services. Computer Law & Security Review, 34(2), 193–203. https://doi.org/10.1016/j.clsr.2017.10.003
• Everaars, R. (2024). Cognitieve lock-in bij Microsoft 365 (research paper). Nyenrode Business University.
• Geiregat, S. (2022). Who owns “your” (business’s) digital data? Oxford Business Law Blog (blog post). https://blogs.law.ox.ac.uk/oblb/blog-post/2022/12/who-owns-your-businesss-digital-data-new-eu-law-making
• Irion, K. (2012). Government cloud computing and national data sovereignty. Policy & Internet, 4(3–4), 40–71. https://doi.org/10.1002/poi3.10
• Klemperer, P. (1987). Markets with consumer switching costs. The Quarterly Journal of Economics, 102(2), 375–394. https://doi.org/10.2307/1885068
• Klemperer, P. (1995). Competition when consumers have switching costs. The Review of Economic Studies, 62(4), 515–539. https://doi.org/10.2307/2298075
• Murray, K. B., & Häubl, G. (2007). Explaining cognitive lock-in: The role of skill-based habits of use in consumer choice. Journal of Consumer Research, 34(1), 77–88. https://doi.org/10.1086/513048
• Polites, G. L., & Karahanna, E. (2012). Shackled to the status quo: The inhibiting effects of incumbent system habit, switching costs, and inertia on new system acceptance. MIS Quarterly, 36(1), 21–42. https://doi.org/10.2307/41410404
• Rhoen, M. (2016). Beyond consent: Improving data protection through consumer protection law. Internet Policy Review, 5(1), Article 404. https://doi.org/10.14763/2016.1.404
• Ryan, M., Gürtler, P., & Bogucki, A. (2024). Will the real data sovereign please stand up? An EU policy response to sovereignty in data spaces. International Journal of Law and Information Technology, 32(1), eaae006. https://doi.org/10.1093/ijlit/eaae006
• von Scherenberg, F., Hellmeier, M., & Otto, B. (2024). Data sovereignty in information systems. Electronic Markets, 34(1), Article 15. https://doi.org/10.1007/s12525-024-00693-4

Verder lezen

• EU Data Act, Reg. (EU) 2023/2854 en Data Governance Act, Reg. (EU) 2022/868
• Deel 1: Wat het echt betekent om eigenaar van je data te zijn