Een AI-audittrail bouwen die een toezichthouder accepteert
De lastige vraag is hoe het systeem op een bepaalde dag was ingesteld. Zo beantwoord je die, van een log van elke wijziging tot geëxporteerd bewijs.
Meer informatie over audittrailsZorg · 4 min leestijd
AI-projecten in de zorg lopen zelden vast op het model. Ze lopen vast in de privacyreview, op vier technische vragen die elk een instelling kunnen worden waar je naar kunt wijzen.
De meeste AI-projecten in de zorg die vastlopen, doen dat niet omdat het model niet goed genoeg was. Ze lopen vast in de privacy- en juridische review, waar de vragen technische vragen zijn en het project er geen technische antwoorden op heeft. Dit is een doorloop van de vier vragen die bijna elke keer terugkomen, en van hoe elk een instelling wordt waar iemand naar kan wijzen, die te testen en te verdedigen is, in plaats van een toezegging in een vergadering.
Let op de reikwijdte: dit is technische richtlijn over controles, geen juridisch advies en geen uitspraak over wat een regelgeving vereist. NeuralSeek beschikt over SOC 1- en SOC 2 Type II-rapporten en is HIPAA-conform. Je juridisch adviseur, privacykantoor en interne audit bepalen wat voor jouw organisatie geldt.
De gangbare aanname is dat de regelgeving verbiedt om klinische data ook maar in de buurt van een taalmodel te brengen, waardoor het project wacht op een juridisch antwoord dat nooit helemaal komt. In de praktijk vraagt de review zelden in het abstracte om toestemming. Ze vraagt vier concrete dingen: wat het model bereikt, welke registratie er daarna is, wat het systeem überhaupt kan zien en hoe je dat allemaal kunt aantonen.
Elk daarvan is in configuratie te beantwoorden, en een project dat met de antwoorden al geconfigureerd binnenkomt, krijgt een heel andere review dan een project dat met een demo en een belofte komt.
Het sterkst mogelijke antwoord op deze vraag is ‘niets ervan’, en dat is vaker haalbaar dan teams verwachten. Als beschermde informatie wordt verwijderd voordat de prompt wordt samengesteld, is de vraag wat de modelaanbieder ermee doet niet meer interessant.
De sterkste opzetten maken in twee rondes redacties, om de redenen uit het artikel over het detecteren van persoonsgegevens. Een snelle deterministische ronde verwijdert de gestructureerde identificatoren (dossiernummers, datums, contactgegevens) met verwaarloosbare vertraging. Een contextuele ronde vangt daarna wat patronen niet kunnen: een naam in een klinische notitie in vrije tekst, een locatie die op een dozijn manieren is beschreven, een omschrijving die een persoon identificeert zonder hem te noemen.
De derde beslissing is wat er bij een treffer gebeurt, en die is de moeite waard om per workflow bewust in te stellen: de waarde maskeren, vervangen door een stabiel token zodat de omliggende zin nog klopt, verwijderen of het verzoek weigeren. Eén keer ingesteld, consistent toegepast en zichtbaar in de configuratie in plaats van in iemands code.
Je kunt geen verantwoording afleggen over toegang die je niet hebt vastgelegd, en een review gaat uit van niets over wat je systeem deed. Twee aanvullende registraties doen het meeste werk: een duurzame, manipulatiebestendige log voor de hele organisatie van elke interactie, en een registratie van de prompts zelf, zodat een vraag die maanden later opkomt kan worden gereconstrueerd met de context waarmee het systeem werkelijk werkte.
De praktische test is of het opleveren van die registratie een export is of een project. Als een reviewer vraagt wat een bepaalde assistent op een bepaalde dag tegen een bepaald persoon zei en het antwoord een week kost om samen te stellen, bestaat de controle eigenlijk nog niet.
Redactie en logging doen weinig als een zoekopdracht materiaal kan bereiken dat het nooit had mogen bereiken. Dit is een toegangsvraag, niet alleen een inlogvraag: een assistent voor één afdeling hoort structureel niet in staat te zijn de dossiers van een andere afdeling op te halen, niet alleen ontmoedigd om dat te doen.
Dat wordt afgedwongen in de ophaallaag, door te beperken welke documenten elke klant of bedrijfseenheid mag bevragen, voordat enige rangschikking plaatsvindt. Daarnaast moeten inloggegevens en verbindingsgeheimen volledig buiten prompts en antwoorden blijven. Anders wordt het bewijsdossier dat je voor een reviewer maakt een plek waar een sleutel kan weglekken.
De laatste vraag bepaalt hoe lang de review duurt. Een configuratie die klopt maar niet is gedocumenteerd, wordt behandeld als een bewering. De organisaties die de review snel doorstaan, zijn de organisaties die elke controle naast de eis kunnen leggen waarvoor ze er is, in een structuur die de reviewer al kent.
Die koppeling is het verschil tussen een securityvragenlijst die een maandenlange zoektocht naar bewijs wordt en een die uit een document wordt beantwoord. Het is bovendien de registratie die personeelswisselingen overleeft.
Wanneer NeuralSeek in jouw omgeving draait, ligt de reikwijdte van compliance bij jou en hoeft de data die omgeving nooit te verlaten. De controles hierboven leveren wij, en jij configureert en beheert ze.
NeuralSeek wordt geaudit voor SOC 1 en SOC 2 Type II en is HIPAA-conform.
Lees verder
Praktische lectuur over het bouwen, besturen en draaien van AI-agents.
Voor instellingen en parameters, zie de productdocumentatie (in het Engels).
De lastige vraag is hoe het systeem op een bepaalde dag was ingesteld. Zo beantwoord je die, van een log van elke wijziging tot geëxporteerd bewijs.
Meer informatie over audittrailsWaarom het model dit niet alleen kan oplossen, hoe een aanval verstopt in een document eruitziet en hoe je die indamt.
Meer informatie over prompt injectionMeld je online aan en begin met een proefperiode van twee weken, of bespreek met een NeuralSeek-expert hoe je het in je eigen cloud draait.