Bij een verzekeraar liggen twee spreadsheets naast elkaar. De ene heet informatieregister en is van de risicofunctie: de contractuele afspraken met ICT-derden, zoals DORA die vraagt. De andere heet AI-register en is van de FG. Microsoft staat in allebei. In de ene met contractdatum, ondersteunde functie en onderaannemers, in de andere met "Copilot, toegestaan, geen klantgegevens in prompts". Het land van vestiging staat in beide, en in één ervan verkeerd.
Zo ontstaan twee werkelijkheden uit één. De twee registers gaan over dezelfde leveranciers vanuit een andere vraag: het ene over wat er is afgesproken, het andere over wat er wordt gebruikt en besloten. De oplossing is niet één groot register, maar één plek per feit, een verwijzing tussen de lijsten, en een gemeenschappelijke bron voor wat er feitelijk wordt geopend. Wat een AI-register in het algemeen is en welke velden erin horen staat in AI-register: wat is het en wat leg je erin vast; waarom een AI-dienst onder DORA een ICT-dienst van een derde is, in AI en DORA.
Waar gaan de twee registers over?
Het informatieregister beantwoordt de vraag van de toezichthouder: van welke ICT-derden hangt deze onderneming af, welke functies ondersteunen ze, hoe kritiek zijn die functies, en wat is er contractueel geregeld als het misgaat. Het is een lijst van afhankelijkheden.
Het AI-register beantwoordt de vraag van de werkvloer en de FG: welke AI-tools gebruiken we, welke gegevens gaan erin, wat hebben we per tool besloten, onder welke voorwaarde, en wanneer kijken we daar opnieuw naar. Het is een lijst van besluiten.
| Veld | Informatieregister van ICT-derden | AI-register |
|---|---|---|
| Leverancier, land van vestiging | Ja | Ja |
| Contract, looptijd, onderaannemers | Ja, de kern | Alleen of er een is |
| Ondersteunde functie en of die kritiek of belangrijk is | Ja, de kern | Meestal niet |
| Welke gegevens erin gaan | Soms, op hoofdlijnen | Ja, per tool en per doel |
| Besluit met voorwaarde | Nee | Ja, de kern |
| Herbeoordeling en aanleiding | Contractueel moment | Datum plus gebeurtenis |
| Toegestaan alternatief | Nee | Ja |
| Tools zonder contract | Passen er niet in | Horen erin, op nog geen besluit |
De laatste rij is de belangrijkste. Een register van contractuele afspraken kan geen dienst bevatten waar geen afspraak mee is. Een AI-register kan dat wel, en moet dat ook, want juist die dienst is het minst beheerde risico.
Waar overlappen ze, en waar niet?
De overlap zit in de leveranciersfeiten: wie de leverancier is, waar hij gevestigd is, waar de verwerking plaatsvindt, welke onderaannemers hij gebruikt, en of er een contract en een verwerkersovereenkomst is. Die feiten veranderen wanneer de leverancier verandert, niet wanneer de organisatie iets besluit. Ze horen dus op één plek, en de andere lijst verwijst ernaar.
Wat niet overlapt is de reden van elke lijst. De kritikaliteit van een functie is een risico-oordeel over de onderneming; het besluit per tool is een beleidskeuze over gebruik. Dezelfde leverancier kan een kritieke dienst leveren (de polisadministratie) en een AI-functie waarover de organisatie apart besluit (de samenvatter in diezelfde applicatie). Dat zijn twee regels, elk in het register waar ze horen, met een verwijzing.
Hoe voorkom je dubbel werk?
Drie afspraken, en ze zijn saaier dan een nieuw systeem.
Eén eigenaar per veld. De risicofunctie is de bron voor contract, functie en kritikaliteit. De FG of de CISO is de bron voor gegevensgebruik, besluit en voorwaarde. De business is eigenaar per tool en beantwoordt de vragen bij een herbeoordeling. Wie welke rol draagt, en waarom "de FG doet het wel" niet werkt, staat in wie is verantwoordelijk voor het AI-register.
Eén route per nieuwe tool. Een AI-dienst die wordt opgemerkt komt in het AI-register op nog geen besluit. Wordt hij toegestaan, dan volgt inkoop en komt hij met contract in het informatieregister; het AI-register verwijst dan naar die regel. Wordt hij niet toegestaan, dan staan het besluit en het alternatief in het AI-register en komt hij nooit bij de derden. Zo hoeft niemand een tool twee keer in te voeren en is per tool te zien welke weg hij heeft afgelegd.
Eén ritme voor herbeoordeling. Een gewijzigd contract, een nieuwe AI-functie bij een bestaande leverancier, een incident of een nieuw gebruik zijn aanleidingen voor beide lijsten tegelijk. Welke aanleidingen dat zijn en hoe je er een ritme van maakt staat in hoe houd je een AI-register actueel.
Waar komt de bron vandaan?
Beide registers beschrijven wat de organisatie weet. De vraag die geen van beide beantwoordt is wat er buiten die kennis valt.
Een verzekeraar heeft in het informatieregister Microsoft staan, met Copilot als toegestane AI, en de leverancier van de schadesoftware, die sinds een update een samenvatfunctie heeft. Het AI-register telt vier regels. Als de organisatie voor het eerst kijkt welke AI-domeinen er vanuit de browser worden geopend, komen daar ChatGPT, Perplexity, een transcriptietool en een browserextensie die e-mails herschrijft bij. Over twee ervan is nog niets besloten en geen ervan heeft een contract. Niemand heeft iets fout gedaan. Het laat zien dat een register dat je bijwerkt beschrijft wat je kende, en dat een register dat gevoed wordt door waargenomen gebruik beschrijft wat er is.
Die waarneming vraagt geen gegevens over personen. Welk domein, hoe vaak, in welke periode, en of er een besluit over bestaat: dat is genoeg om te zien welke regel in beide lijsten ontbreekt. Hoe die stap van waarnemen naar een register dat klopt eruitziet, staat in van shadow AI naar een actueel AI-register.
BeeSensible koppelt een catalogus van 865 beoordeelde AI-tools aan het gebruik dat in de organisatie wordt waargenomen, alleen op domeinniveau en zonder gebruikers-id. Per tool staan leverancier, land, hostingregio, trainingsbeleid en de beschikbaarheid van een verwerkersovereenkomst al in de catalogus, en de organisatie legt zelf het besluit vast in de AI Tools-module. Het informatieregister blijft waar het is; wat BeeSensible toevoegt is de lijst van diensten die erin ontbreken.
