Tijdens een demonstratie afgelopen zomer verscheen er een onderzoeksteam in de gegenereerde tekst. Namen, titels, een geloofwaardige beschrijving van wie wat ging doen. Alleen: deze mensen hoorden niet bij het project. De echte namen stonden in een bestand dat niet goed was ingelezen.
De passage zag er verzorgd uit. Er stonden geen vreemde zinnen in die je aan het twijfelen brachten. Juist daarom is dit een nuttiger voorbeeld dan een overduidelijke AI-blunder. Het laat zien hoe een fout bij het aanleveren van informatie verderop als een overtuigend feit kan terugkomen.
Een bestand uploaden is nog geen bron lezen
Het betreffende bestandsformaat was als platte tekst ingelezen, terwijl die aanpak vooral opmaakcode opleverde. Voor de gebruiker stond het bestand tussen de bronnen. Voor het model was de inhoud niet bruikbaar.
Het model ging vervolgens op zoek naar andere informatie. Het vond een voorbeelddocument en nam daar details uit over. Een bron die bedoeld was om de vorm te laten zien, werd gebruikt als bewijs voor de inhoud.
Daar zitten twee verschillende problemen. Het systeem moet kunnen vaststellen of een bestand werkelijk bruikbare tekst oplevert. En het moet onderscheid houden tussen een voorbeeld van een goede aanvraag en feiten over het huidige project.
Een geslaagde upload zegt over geen van beide genoeg.
Je hoort een verzonnen feit niet aan de toon
We vragen mensen vaak om de output van AI goed te controleren. Dat blijft nodig. Alleen is het een dure laatste verdedigingslinie als het systeem eerder al met ontbrekende of verkeerde informatie is gaan schrijven.
Een taalmodel kan een ontbrekend gegeven invullen met iets plausibels. Het kan ook een overtuigend detail uit de verkeerde bron halen, zoals hier gebeurde. Zonder duidelijke grenzen levert het dan een antwoord waar eigenlijk een vraag had moeten staan.
Aan de stijl herken je dat niet betrouwbaar. Een verzonnen naam kan net zo zakelijk worden opgeschreven als een echte. Om het verschil vast te stellen, moet je terug naar het bronbestand.
Een vloeiende tekst is geen bewijs dat de bronnen goed zijn verwerkt. Wie alleen op leesbaarheid controleert, mist precies het soort fout dat hier ontstond.
Drie controles vóór en tijdens het schrijven
De eerste controle is eenvoudig te beschrijven: kijk vóór het schrijven of de aangeleverde bronnen leesbaar zijn. Niet alleen of het bestand bestaat, maar of er bruikbare inhoud uit komt. Maak een mislukte verwerking zichtbaar. Laat een leeg resultaat niet ongemerkt doorgaan als een gelezen document.
Daarna komt de inhoudelijke grens. Ontbreekt een naam, bedrag of afspraak, dan moet het systeem dat aangeven. Bijvoorbeeld: wie zijn de betrokken onderzoekers? Of: in welke bron staat dit bedrag? De adviseur kan dan gericht aanvullen, voordat een ontbrekend feit in een alinea verdwijnt.
De derde controle is herleidbaarheid. Leg per onderdeel vast welke bronnen voor de tekst zijn gebruikt. Daarmee kan de adviseur een bewering controleren zonder een heel dossier opnieuw door te nemen. Ook wordt zichtbaar wanneer een voorbeeld ten onrechte als feitelijke bron wordt behandeld.
Die controles ondersteunen elkaar. Een bestand kan technisch leesbaar zijn en toch de benodigde informatie missen.
Wat we daarvan hebben veranderd
Het concrete formaatprobleem is verholpen. Bij het inlezen van bestanden worden verwerkingsfouten en bestanden waar onverwacht geen tekst uit komt expliciet als fout behandeld. Het model krijgt ook te horen als een bron nog wordt verwerkt of is mislukt.
Dat is geen garantie dat het hele schrijfproces altijd stopt zodra één bron onvoldoende informatie bevat. Een technisch geslaagde verwerking kan nog steeds inhoud missen, en een model kan een verkeerde gevolgtrekking maken. We blijven daarom ook de stap van gelezen bron naar geschreven bewering toetsen.
Voor Twin is dit een les uit ons eigen systeem. Goede invoercontrole neemt de verantwoordelijkheid van de adviseur niet over. Ze zorgt er wel voor dat die adviseur eerder ziet waar zijn oordeel nodig is.
Inhoudelijk bijgewerkt op 15 september 2026.