e bouwers en de beslissers weten vaak niet van elkaar
De mensen die de techniek bouwen en de mensen die de koers bepalen, staan in veel organisaties ver uit elkaar. De tracking zit in de code, maar de directie weet niet altijd wat er gebeurt, en de coder niet altijd waarom. Zo ontstaat een misstand die niemand bewust koos.
Twee werelden in dezelfde organisatie¶
In veel organisaties staan de mensen die de techniek bouwen en de mensen die de koers bepalen ver uit elkaar. De tracking zit in de code. De directie weet niet altijd wat er in die code gebeurt. En de programmeur weet niet altijd waarom het erin staat, of wie erom heeft gevraagd. Ze werken aan hetzelfde product en spreken zelden dezelfde taal.
Ik zie dit terug in mijn eigen metingen. Ik open een app, ik lees het netwerkverkeer, en ik vind een advertentie-SDK die je toestel aanbiedt op een veiling. Als ik dat voorleg, gebeurt er vaak iets herkenbaars. De directie is oprecht verbaasd. De ontwikkelaar haalt zijn schouders op, want die SDK was de standaardmanier om iets werkend te krijgen. Niemand in het gebouw kan me in één zin vertellen waarom die specifieke partij meekijkt. Dat is geen incident. Dat is de normale toestand in een keten die te lang is geworden om te overzien.
Hoe een misstand ontstaat die niemand koos¶
Zet de twee kanten naast elkaar en de mechaniek wordt zichtbaar. De bouwer plaatst een SDK omdat het handig is. Het bespaart weken werk, het werkt meteen, en de documentatie zegt niets verontrustends. Hij denkt in werkende software. De datastromen eronder ziet hij niet als zijn taak. De beslisser tekent een verwerkersovereenkomst die hij niet leest, of die hij leest zonder te begrijpen wat de technische bijlage betekent. Hij denkt in contracten en aansprakelijkheid. Van de SDK's die eronder draaien heeft hij geen beeld.
Tussen die twee valt de verantwoordelijkheid op de grond. De bouwer neemt aan dat de jurist het contract heeft gecheckt. De jurist neemt aan dat de bouwer alleen gebruikt wat is afgesproken. Geen van beiden liegt. Toch staat er aan het eind een tracker in het product die je toestel aan derden aanbiedt, en die niemand bewust heeft gekozen. Het is een misstand door optelsom van kleine, op zichzelf redelijke beslissingen. Zo krijg je advertentie-infrastructuur in een product waar het niet hoort, bijvoorbeeld in een zorgcontext, wat ik apart bekijk in Advertentie-infrastructuur in een zorgjas is een bouwkeuze.
Waarom de verklaring geen vrijbrief is¶
Deze verklaring is verleidelijk, want ze klinkt als een verontschuldiging. Niemand wilde het, dus niemand is schuldig. Zo werkt het niet. De verklaring beschrijft hoe iets ontstaat. Ze zegt niets over wie ervoor opdraait.
De AVG kent het begrip verwerkingsverantwoordelijke. Dat is de partij die het doel en de middelen van de verwerking bepaalt. Bij een app is dat de organisatie die de app laat maken en uitgeeft. Die verantwoordelijkheid is niet deelbaar in "de bouwer wist het niet" en "de directie las het niet". De wet kijkt naar de organisatie als geheel. Wie laat bouwen, is aansprakelijk voor wat er draait, ook als de twee helften van het bedrijf nooit met elkaar spraken. Het gebrek aan interne communicatie is een intern probleem. Het verplaatst de aansprakelijkheid niet naar buiten, en al helemaal niet naar de gebruiker.
Bewijsniveau hierbij: dat de verantwoordelijkheid bij de verwerkingsverantwoordelijke ligt, staat in de AVG en is hard. Dat organisaties intern langs elkaar heen werken, leid ik af uit wat ik in metingen en gesprekken tegenkom, en het is een patroon dat ik vaker zie dan een enkel geval.
De keten is langer dan twee schakels¶
Het beeld van twee werelden, de bouwer en de beslisser, is nog te eenvoudig. In werkelijkheid zit er tussen die twee een keten die langer is dan beide partijen vermoeden. De bouwer neemt een SDK op. Die SDK laadt op zijn beurt code van derden. Die derde partij verkoopt of deelt data door aan vierde partijen die niemand in de organisatie ooit heeft gezien. Wat begon als één handige integratie, eindigt als een stroom naar een handvol bestemmingen die op geen enkele tekentafel stond.
Dat maakt de situatie erger dan een gebrek aan overleg tussen twee afdelingen. Zelfs een organisatie die haar bouwer en haar jurist wél met elkaar laat praten, ziet de onderkant van die keten niet vanzelf. Je moet er actief in graven om te weten waar je data uiteindelijk belandt. Precies dat graven is wat ik doe met een netwerkopname, want de keten toont zich pas als je het verkeer leest dat de app werkelijk uitstuurt. Op papier staat de eerste schakel. In het verkeer staan ze allemaal.
De juridische consequentie hiervan is streng. De verwerkingsverantwoordelijke moet weten met wie hij data deelt, en dat vastleggen in verwerkersovereenkomsten en in het verwerkingsregister. Onwetendheid over de diepere schakels is zelf een tekortkoming, want de wet verwacht dat je die keten kent voordat je hem in je product opneemt. De lengte van de keten is een verklaring voor hoe het misgaat. Ze is geen excuus, want het in kaart brengen van die keten is precies de plicht die op de organisatie rust.
Wie bouwt, bepaalt meer dan de organisatie denkt¶
Er zit een kant aan dit verhaal die de directie vaak onderschat. De bouwer maakt keuzes die de koers van het product bepalen, ook als niemand die keuzes ooit als beleid formuleerde. De keuze voor een bepaalde SDK, een bepaalde analytics-tenant, een bepaalde manier van loggen, dat zijn technische beslissingen met beleidsgevolgen. Ze bepalen wat het product over de gebruiker weet en aan wie het dat doorgeeft.
Daarmee heeft de kant die de knoppen bedient meer macht dan het organigram suggereert. Wie bouwt, bepaalt in de praktijk wat er gebouwd wordt, ook als de formele beslissing ergens anders lijkt te vallen. Dat werk ik uit in De maker en de aandeelhouder willen niet hetzelfde. Het omgekeerde bestaat ook, waar iemand zonder technisch inzicht beslist en het echte vakmanschap wordt weggeschoven. Dat spanningsveld staat in Op IT-afdelingen beslist wie het vak nooit beoefende.
Wat dit voor mijn werk betekent¶
Voor mij heeft dit een praktisch gevolg. Ik richt mijn onderzoek op het product en op de organisatie die het uitgeeft. De individuele programmeur die een regel code schreef, laat ik erbuiten. Die persoon aanwijzen is zinloos en meestal onrechtvaardig, want hij zat in het gat tussen de twee werelden en had zelden zicht op het geheel. De organisatie aanspreken is wel terecht, want die kan de keten overzien als ze dat wil, en de wet verplicht haar dat te doen. Een organisatie die zegt dat ze het niet wist, geeft daarmee toe dat ze een plicht heeft verzaakt, want het weten was haar taak.
Het betekent ook dat ik in mijn rapportage niet blijf hangen in "iemand heeft een fout gemaakt". Ik beschrijf welke datastroom ik meet, naar welke partij, en met welke gevolgen. Wie het intern heeft veroorzaakt, is voor de aansprakelijkheid niet doorslaggevend. Het is aan de organisatie om haar eigen twee helften met elkaar in gesprek te brengen. Als dat gesprek niet plaatsvindt, komt het bij mij op tafel, en dan telt het als een meetbare verwerking waar iemand voor tekent. Van interne miscommunicatie is op dat punt geen sprake meer. Waarom ik vaak de enige lijk die dat spoor uitloopt, staat in Waarom ben ik de enige die dit doet?.
Zie ook Advertentie-infrastructuur in een zorgjas is een bouwkeuze, De maker en de aandeelhouder willen niet hetzelfde en Waarom ben ik de enige die dit doet?.
- Melvin Conway, "How Do Committees Invent?", Datamation, 1968de wet van Conway: een systeem weerspiegelt de communicatie van de organisatie