Risico's van AI bij het extraheren van eisen: hallucinaties en aannames

Het risico van ongecontroleerde eisenextractie

Wanneer een systeemspecificatie uit honderden pagina’s bestaat, is handmatige eisenextractie geen realistische optie meer. Teams grijpen dan naar generieke AI-tools zoals Copilot, ChatGPT of Claude om brondocumenten om te zetten in gestructureerde requirements. De snelheid is indrukwekkend: binnen enkele minuten produceren deze tools lijsten met honderden vermeende eisen. Maar snelheid zonder controle creëert een verborgen aansprakelijkheid. Wat er niet staat, wordt namelijk net zo moeiteloos gegenereerd als wat er wél staat.

Het onzichtbare risico: hallucinaties en impliciete aannames

Een empirische studie van Huang et al. (ACM, 2025) concludeert dat large language models hallucinaties produceren in repository-level software engineering-contexten. De onderzoekers tonen aan dat AI niet alleen oppervlakkige fouten maakt, maar diepgewortelde, plausibel klinkende afwijkingen genereert binnen complexe ontwikkelscenario’s. Een survey uit 2025 in arXiv (arXiv:2510.06265v1) stelt daarbij dat de indrukwekkende vloeiendheid van LLM’s vaak ten koste gaat van correctheid: het model produceert valse of gefabriceerde informatie.

In de context van eisenextractie betekent dit dat een model impliciete aannames kan vermommen als expliciete verplichtingen. Een brondocument drukt een wens uit, maar de AI herformuleert die als een harde eis. Of erger nog: het voegt constraints toe die in geen enkele paragraaf terug te vinden zijn. De output ziet er gestructureerd uit, maar die structuur is vaak een reconstructie van wat het model dénkt (interpretatie) dat er had moeten staan.

De schaalval: van twintig naar vijfhonderd eisen

Het probleem is niet alleen dát er fouten optreden, maar dat ze onzichtbaar worden bij schaling. Bij twintig eisen controleer je nog regel voor regel. Bij vijfhonderd eisen schakelt het brein onvermijdelijk over op patroonherkenning. De vloeiende stijl van de AI imiteert betrouwbaarheid: een verzonnen functionaliteit of een niet-bestaande interfacespecificatie glipt dan ongemerkt de requirementsdatabase in, simpelweg omdat de zinnen grammaticaal correct en technisch geloofwaardig klinken.

Hallucinatie is geen incident, maar een structureel kenmerk. Frontiers in AI (september 2025) beschrijft het fenomeen inmiddels als een zelfstandig onderzoeksobject dat wetenschappers proberen te begrijpen, te evalueren en te mitigeren. Zolang die mitigatie ontbreekt, schaalt niet alleen je output mee, maar ook je risico.

Waarom generieke tools het probleem verergeren

Generieke AI-tools werken als een black box. Ze bieden geen paragraafnummers, geen bronvermelding en geen classificatie van wat ze hebben gevonden. Je krijgt een lijst, maar geen traceerbaarheid.

De parallel met codegeneratie is direct. CACM (augustus 2025) documenteerde hoe LLM’s niet-bestaande software packages en API’s genereren en die presenteren alsof het bestaande componenten zijn. Voor eisenextractie vertaalt dit zich naar niet-bestaande regelgevende verplichtingen, verzonnen technische constraints of geïmproviseerde interfacedefinities. Zonder een mechanisme dat elke extractie koppelt aan een concreet stuk brontekst, is het onderscheid tussen feit en fictie eenvoudigweg niet te maken.

Wat er op het spel staat: downstream en compliance

Een gehallucineerde eis blijft niet netjes in het extractiespreadsheet. Hij stroomt door naar systeemarchitectuur, testprotocollen en validatiegates. Heeft een vermeende regelgevende verplichting nooit in het brondocument gestaan, maar heeft je AI die wél geëxtraheerd, dan ontwerp en bouw je tegen een fictie. De downstream-kosten van zo’n fout in een systems engineering-traject zijn exponentieel hoger dan de tijdwinst die de generieke tool ooit opleverde.

Voor compliance en certificering is dit ronduit desastreus. Auditors eisen traceerbaarheid van eis naar bron. Een black-box-extractie zonder paragraafverwijzing of context levert een antwoord, maar geen bewijs.

De oplossing: regels stellen aan de agent én Human-in-the-Loop

Het probleem is niet de AI zelf, maar het ontbreken van regels en verificatielussen. Basewise DRE (Document Requirements Extractor) is speciaal ontwikkeld voor systems engineering-workflows en behandelt eisenextractie als een gestuurd proces in plaats van een open vraag. DRE werkt in twee modi:

• Fully automatic mode met een two-pass-structuur: eerst een structurele scan van het document, gevolgd door parallelle extractie. Zo interpreteert het model niet vrijelijk, maar volgt het een gedefinieerd schema.
• Human-in-the-Loop mode: binnen een live PDF-viewer selecteer je tekstsegmenten en kies je per segment voor verbatim extractie of een INCOSE-structured rewrite.

Elke extractie krijgt een unieke ID, een source reference (document en paragraaf), surrounding context en een classificatielabel: requirement, assumption, obligation, of expliciet “geen requirement”. De output is een gestructureerde tabel die direct te importeren is in requirements management-tools. Basewise DRE is daarmee bewust gepositioneerd als de stap vóór klassieke requirements management-tools, niet als vervanging ervan. Het doel is traceerbare, gevalideerde input, zodat downstream-tools werken met feiten die aantoonbaar aan een bron zijn gekoppeld.

Afsluiting: een praktische stelregel

Gebruik generieke AI als denkpartner, niet als eisenextractor. Kun je niet naar een specifieke paragraaf en een classificatielabel wijzen, dan is het nog geen requirement. De stelregel is eenvoudig: controleer de bron voordat de eis de keten in gaat. Bij twintig eisen doe je dat uit gewoonte. Bij vijfhonderd eisen heb je een tool nodig die die controle afdwingt.