Wat de AI Act vraagt van wie AI op eigen documenten inzet

De deadlines voor hoogrisicosystemen schuiven op. Toch stellen kopers en auditors nu al dezelfde vier vragen aan uw documentsysteem.

Veel bedrijven die wij spreken hebben een werkend systeem dat facturen uitleest, inkomende post sorteert of antwoorden zoekt in interne procedures. Sinds het politieke akkoord van 7 mei 2026 over de digitale omnibus weten ze dat de EU de AI Act wil vereenvoudigen en de deadlines voor hoogrisicosystemen opschuift. De reflex is dan om te wachten tot alles vastligt. Wij denken dat dat de duurdere keuze is.

Wat volgt is hoe wij de regels lezen bij het bouwen van documentsystemen. Het is geen juridisch advies. Voor uw concrete situatie hebt u een jurist nodig die de tekst en uw toepassing naast elkaar legt.

Aanbieder of gebruiker

De AI Act maakt een onderscheid tussen wie een model ontwikkelt en op de markt brengt, de aanbieder, en wie een model inzet binnen de eigen werking, de gebruiksverantwoordelijke. De regels voor modellen voor algemene doeleinden zijn intussen van toepassing, maar die verplichtingen liggen grotendeels bij de makers van die modellen: documentatie, informatie over trainingsdata, afspraken rond auteursrecht.

Gebruikt u een bestaand taalmodel via een API om leveringsbonnen uit te lezen, dan bent u doorgaans gebruiker en geen aanbieder. Die positie is niet vrijblijvend. Wie een model ingrijpend aanpast of een systeem onder eigen naam aan derden verkoopt, kan zelf in de rol van aanbieder terechtkomen. Die vraag stelt u beter vroeg, en niet pas wanneer het product al bij klanten draait.

Waarom de meeste documentsystemen geen hoog risico zijn

Of een systeem hoog risico is, hangt af van waarvoor het gebruikt wordt, niet van de techniek erachter. Gegevens halen uit inkooporders, contracten op type classificeren of zoeken in een interne kennisbank met RAG: zulke toepassingen staan niet op de lijst. Het meeste werk dat wij bouwen valt daarbuiten.

Dezelfde techniek kan wel over de grens schuiven, en vaak zonder dat iemand de code aanraakt. Een classificatiesysteem voor inkomende post krijgt er een categorie sollicitaties bij en bepaalt zo mee wie een gesprek krijgt. Of een extractiepijplijn voor loonfiches gaat een kredietbeslissing voeden. Ook een zoeksysteem kan helpen beslissen wie toegang krijgt tot een uitkering of een verzekering. Werving, kredietwaardigheid en toegang tot essentiële diensten zijn precies de domeinen waar de Act strenger wordt. Wij hebben geleerd om bij elk project niet alleen te vragen wat het systeem doet, maar ook waar de output daarna naartoe gaat.

Vier dingen die u hoe dan ook nodig hebt

Ook buiten de hoogrisicocategorieën krijgen we steeds dezelfde vragen, van inkoopafdelingen, interne audit en functionarissen voor gegevensbescherming. Ze willen weten wat het systeem mag lezen, wat het bijhoudt, wie de output goedkeurt en hoe een beslissing terug te volgen is. Daaruit volgen vier dingen die wij standaard inbouwen:

• afgebakende toegang tot data, per gebruiker en per bron

• logging van invoer, modelversie, prompt en output

• menselijke goedkeuring op output met gevolgen

• herleidbaarheid van elk antwoord naar het brondocument

Afgebakende toegang betekent dat een zoeksysteem over HR-dossiers niet dezelfde index deelt met de algemene kennisbank, en dat de rechten van de gebruiker ook gelden voor wat het model te zien krijgt. Bij logging maakten wij in het begin de fout om alleen fouten bij te houden. Wanneer iemand maanden later vraagt waarom een document zo geclassificeerd werd, hebt u net de gewone gevallen nodig, met de modelversie die toen draaide.

Menselijke goedkeuring hoeft niet overal. Een voorgestelde tag op een interne nota mag automatisch door, een bedrag dat naar de boekhouding gaat of een dossier dat afgewezen wordt niet. Herleidbaarheid betekent dat elk geëxtraheerd veld en elk antwoord verwijst naar de pagina en de passage waar het vandaan komt. Zonder die verwijzing kan niemand de output controleren, en dan wordt goedkeuring een formaliteit.

Waarom wachten meer kost

Deze vier zaken achteraf toevoegen is duurder dan ze meteen voorzien. Logs die u nooit bijhield, kunt u niet terughalen, en een pijplijn die geen bronverwijzingen bewaart, moet vaak opnieuw verwerkt worden. Een systeem dat deze antwoorden al klaar heeft, raakt intern sneller door een aankoopdossier of een auditgesprek. Als de regels later toch strenger worden, of uw toepassing verschuift naar een gevoelig domein, staat het fundament er al.