Data en beveiliging bij AI-systemen

Wij bouwen op de systemen die er al staan. Dat is geen prijsargument, het is de reden dat het antwoord op de datavraag kort kan zijn: je gegevens blijven staan waar ze vandaag ook staan. In je mailbox, in je documentenmap, in het boekhoudpakket, in de database onder je eigen applicatie.

Wat wij toevoegen is een programma dat daar leest en schrijft. Het haalt op wat het voor die ene stap nodig heeft, doet er iets mee, en zet het resultaat terug in het systeem waar je toch al kijkt. Een tweede voorraad van jullie gegevens ontstaat alleen als de route er echt om vraagt, en dan spreken we vooraf af wat erin komt en hoe lang het blijft.

Waar het kan draait het systeem in jullie eigen omgeving en jullie eigen accounts. Het cloudaccount staat op jullie naam, de opslag is jullie opslag, de database is jullie database, en de postbus waaruit iets vertrekt is die van jullie. Wij krijgen toegang, wij nemen niets mee.

Soms kan dat niet, omdat een onderdeel een server nodig heeft die wij beheren. Dat onderdeel draait dan in een EU-regio en staat met naam in de verwerkersovereenkomst.

Er zit ook een praktische kant aan. Draait het in jullie accounts, dan zien jullie beheerders het in hun eigen logboeken staan, kunnen ze het uitzetten zonder ons te bellen, en hoeft er niets van eigenaar te wisselen als de samenwerking ooit stopt.

Een AI-systeem is voor het grootste deel gewone code. Op een of twee plekken in de route staat een modelaanroep: er gaat een stuk tekst uit, er komt een antwoord terug, de code doet er iets mee. Wat eruit gaat is het stuk dat die stap nodig heeft. Eén werkbon, niet de map. Eén mail, niet de postbus.

Wij trainen geen publieke modellen op jullie data. Wat een modelprovider zelf met verkeer via zijn API doet, staat in zijn eigen voorwaarden, en dat zoeken we per project uit: welke provider, welke regio, welke bewaartermijn. Die uitkomst staat in de verwerkersovereenkomst, met de partijen die wij inschakelen erbij, zodat iemand met verstand van zaken het kan nalezen.

Wat een model terugstuurt behandelen we als een voorstel, niet als een feit. Voordat het antwoord ergens landt, controleert de code of het de vorm heeft die is afgesproken: de velden die erin horen, een bedrag dat een bedrag is, een datum die bestaat. Klopt die vorm niet, dan stopt de route en komt het geval op de stapel die iemand nakijkt.

Een systeem krijgt bij ons een eigen identiteit, geen gedeeld beheerdersaccount en geen persoonlijk account van iemand die volgend jaar weggaat. Bij de grote cloudleveranciers heet dat een scoped IAM-rol, maar het idee is ouder dan de term: je schrijft op welke handelingen die ene route doet, en dat lijstje is precies de toegang die de identiteit krijgt.

In de praktijk leest dat als een korte lijst. Lezen uit deze ene map. Schrijven naar deze ene tabel. Versturen vanuit deze ene postbus. Verder niets, dus niet de rest van de schijf en niet alle mailboxen van het domein. Vraagt het systeem er later iets bij, dan is dat een aanpassing die iemand goedkeurt voordat de rol groter wordt.

De sleutels staan in de omgeving en nooit in de code, en ze zijn te vervangen zonder dat er iets stukgaat. En omdat het systeem zijn eigen naam draagt, staat er in jullie eigen logboeken bij elke handeling een naam, het systeem of een collega.

Een NDA en een verwerkersovereenkomst tekenen we standaard, ook bij een eerste project van twee weken. Daarin staat wie waarvoor verantwoordelijk is: jij bent verwerkingsverantwoordelijke, wij zijn verwerker, en de partijen die wij inschakelen staan er met naam bij.

Verder staat er per onderdeel welke gegevens erheen gaan, waarvoor ze daar zijn, in welke regio ze staan en hoe lang ze blijven. De modelprovider staat er met naam bij, met de regio en de bewaartermijn die we voor dat project hebben uitgezocht. Een volledige export kun je op elk moment opvragen, en ook die afspraak staat in dezelfde overeenkomst.