Wat moet er op een AI-systeemkaart staan?
Teken één taak van begin tot eind: medewerker, toepassing, gegevensbron, model, antwoord en eventuele actie. Schrijf bij iedere stap wie eigenaar is, welke gegevens worden verwerkt en welke rechten nodig zijn. Een schema met productlogo's is onvoldoende; het moet laten zien welke informatie de grens tussen systemen overgaat. Deze kaart helpt besluiten of een connector, documentassistent of eigen API verstandig is voordat je iets installeert.
Begin met één concrete vraag, bijvoorbeeld: 'Kan de servicedesk een antwoord vinden in de actuele handleiding?' Als de handleidingen verspreid staan, wijs dan eerst de geldige bron aan. NIST's AI RMF begint met het in kaart brengen van context, doelen en betrokkenen. Dat voorkomt dat de technische koppeling een onduidelijk bedrijfsproces vastzet.
Welke gegevens moet je per systeem noteren?
Maak per bron een regel met naam, eigenaar, locatie, inhoudstype, actuele versie en bewaartermijn. Noteer of de bron persoonsgegevens of vertrouwelijke informatie bevat en wie die vandaag mag lezen. Voeg toe hoe een fout in het bronbestand wordt hersteld. Een archiefmap en een actuele beleidsmap kunnen er technisch hetzelfde uitzien, maar leveren een ander antwoord op. Een model kan dat onderscheid alleen gebruiken als de toepassing het correct aanbiedt.
De Europese Commissie beschrijft AVG-beginselen zoals doelbinding, minimale verwerking en bewaarbeperking. De systeemkaart is een hulpmiddel om die vragen te stellen, geen vervanging voor een verwerkingsregister of juridische beoordeling. Leg ook vast welke gegevens na de AI-vraag in logs, chats of zoekindexen achterblijven.
Wie kan na koppeling welke informatie zien?
Schrijf bij elke pijl in de kaart of de verbinding leest, schrijft of uitvoert. Een documentzoekfunctie heeft meestal alleen lezen nodig. Een koppeling met e-mail of CRM kan ook berichten verzenden of records wijzigen. Begin met de kleinste rechten en controleer wie ze kan intrekken. Een gebruiker die de bron niet mag openen, hoort die informatie ook niet via een AI-samenvatting te krijgen.
Denk apart aan de zoekindex. Bij Azure AI Search beschrijft Microsoft meerdere methoden voor documentrechten, waarbij rechten ook tijdens zoeken moeten worden gehandhaafd. Dat illustreert een algemeen ontwerppunt: rechten in de oorspronkelijke map worden niet vanzelf meegenomen naar een nieuwe index. Test dit met twee gebruikersrollen en een afgeschermd fictief document.
Welke vragen stel je aan een connector of leverancier?
Noteer welke dienst de invoer ontvangt, welke regio en contractafspraken relevant zijn, wie toegang tot logs heeft en wat er gebeurt na verwijderen van een bron. Vraag of de connector kopieën opslaat, alleen tijdens een vraag ophaalt of een aparte index bouwt. Maak de route naar de modelaanbieder expliciet. Dezelfde taak kan via een zakelijke werkruimte, persoonlijke app of eigen API een andere gegevensstroom hebben.
Teken ook de foutpaden: bron niet bereikbaar, rechten geweigerd, document verouderd, modelantwoord zonder bron of hoge kosten. Wie merkt zo'n fout op en hoe valt het proces terug op de bestaande werkwijze? Een systeemkaart wordt pas bruikbaar als een medewerker en een beheerder er allebei de werkelijke route in herkennen. Laat hen de kaart samen nalopen voordat je bouwt.
Wanneer is de kaart goed genoeg?
De kaart is klaar voor een kleine proef wanneer iedere bron een eigenaar heeft, de benodigde rechten bekend zijn, de toegestane gegevens zijn afgebakend en een medewerker de uitkomst controleert. Zet open vragen zichtbaar op de kaart; vul geen aanname in als iemand de bewaartermijn of toestemming niet weet. Een onbekend recht is een reden om te wachten met koppelen, niet om tijdelijk een beheeraccount te gebruiken.
Kies daarna of je documenten wilt doorzoeken, een bestaande connector wilt gebruiken of een eigen API nodig hebt. De gids over AI met eigen documenten en de koppelgids bouwen op deze kaart voort. Herzie haar na nieuwe bronnen, rollen of productinstellingen.
Bronnen en controle
- Auteur
- Jesse Dekkers, Redactioneel verantwoordelijke, Palisade. Verantwoordelijk voor de inhoud en actualisering van deze Palisade Kennisgids.
- Inhoudelijke controle
- Jesse Dekkers op 25 oktober 2026
- Werkwijze
- Systeemkaart op basis van primaire risicobeheer-, privacy- en zoekdocumentatie, gecontroleerd op 25 oktober 2026. Geen specifieke architectuur of juridische naleving beoordeeld.
- NIST — AI RMF Core (gecontroleerd 25 oktober 2026)
- Europese Commissie — GDPR principles (gecontroleerd 25 oktober 2026)
- Microsoft — Document-level access control (gecontroleerd 25 oktober 2026)