SecurityTechInsider AI-veiligheid & governance
EN/ NL
Governance

Bewijsgerichte hallucinatiedetectie bij AWS en Collibra

Hallucinatiedetectie wordt in 2026 bewijsgericht en runtime-gebonden. AWS, Collibra en TrustScale tonen vier methodefamilies, maar onafhankelijke evaluatie

29 september 2026 3 min
Illustratie bij dit artikel: Bewijsgerichte hallucinatiedetectie bij AWS en Collibra.
Runtime-verificatie van hallucinaties vereist dat u zelf de beleidsregels, bronnen en validatieprocessen definieert en onderhoudt. Beeld: SecurityTechInsider — originele redactionele illustratie

U moet hallucinatiedetectie inrichten als gelaagde verificatie met expliciete beleidsregels, runtime-controles en onafhankelijke validatie — niet als enkel product.

De aanleiding is een analyse van 29 september 2026 van bewijsgerichte hallucinatiedetectie bij runtime-verificatie, die stelt dat geautomatiseerde detectie in 2026 verschuift van algemene modelbeoordeling naar verificatie van individuele claims tegen externe bronnen en formeel beleid. AWS kondigde op 23 juni 2026 geautomatiseerde verfijningsworkflows aan voor Automated Reasoning-checks in Amazon Bedrock Guardrails, die generatieve antwoorden wiskundig toetsen aan door klanten gedefinieerd beleid. In onze inschatting is dit de belangrijkste verandering: de vraag verschuift van 'klinkt dit aannemelijk' naar 'tegen welke regel of bron is dit getoetst, en met welk bewijs'. Dat maakt detectie bruikbaarder, maar verlegt de last naar de kwaliteit van het beleid en de bronnen zelf.

Wat controleert hallucinatiedetectie eigenlijk?

Hallucinatiedetectie is geen enkel meetpunt. Het kan meerdere, verschillende dingen toetsen: trouw aan een brondocument, overeenstemming met de werkelijkheid buiten dat document, of naleving van organisatorisch beleid. Deze drie vallen niet samen. Een antwoord kan trouw zijn aan een fout brondocument, of feitelijk juist maar in strijd met beleid. Wie een detector inzet, moet daarom weten welke van deze drie het systeem daadwerkelijk controleert. De AWS-aankondiging richt zich op beleidsnaleving via formele logica; dat is iets anders dan controle tegenover de bredere werkelijkheid.

Welke methodefamilies bestaan en waar falen zij?

De bestaande methoden laten zich ordenen in vier families, die fundamenteel verschillen in wat zij aannemelijk maken en waar zij falen:

  • Formele logica en beleidsregels — antwoorden worden wiskundig getoetst aan expliciet gedefinieerde regels, maar kunnen alleen beleidsnaleving controleren, niet feitelijke juistheid.
  • Bronverificatie en retrieval-augmented generation — antwoorden worden getoetst aan opgehaalde documenten, maar falen als de bron zelf onjuist is.
  • Semantische inconsistentie — systemen detecteren tegenstrijdigheden binnen antwoorden, maar missen hallucinaties die intern consistent zijn.
  • Statistische afwijking van trainingsgegevens — modellen signaleren ongebruikelijke patronen, maar kunnen legitieme nieuwe informatie als hallucinatie markeren.

Elke familie heeft een structurele afhankelijkheid die de detectie kan ondermijnen. Dat is geen detail, maar de kern van de beperking.

Wat zeggen de leverancierscijfers over nauwkeurigheid?

De gepubliceerde nauwkeurigheidscijfers zijn leveranciersclaims. TrustScale noemt getallen over nauwkeurigheid en snelheid; die vormen geen onafhankelijke validatie. Ook de surveycijfers in het bericht van Collibra zijn door de leverancier gepresenteerd. In onze inschatting is de belangrijkste openstaande vraag daarom hoe deze systemen presteren in onafhankelijke, domeinspecifieke tests. Zolang die ontbreken, blijft een hoge score op een leverancierstest een zwak fundament voor bedrijfskritische inzet.

Welke stappen moet u zelf nemen?

De praktische boodschap voor professionals met vertrouwelijke informatie is een gelaagde workflow, niet één product. U moet de volgende stappen kunnen aantonen:

  1. Definieer expliciet welke claims u wilt controleren — bepaal of u beleidsnaleving, brontrouw of feitelijke juistheid controleert, en welke daarvan voor uw use case kritisch is.
  2. Stel bronnen en beleidsregels samen voordat u detectie inzet — hallucinatiedetectie kan alleen tegen bronnen en regels controleren die u zelf hebt vastgesteld en gevalideerd.
  3. Voer onafhankelijke, domeinspecifieke tests uit — test de detector op uw eigen gegevens en use cases voordat u hem in productie neemt.
  4. Bouw menselijke controle in voor kritische beslissingen — detectie geeft signalen; het vervangt geen review door iemand die het domein kent.
  5. Monitor en log alle detectie-uitkomsten — zorg dat u kunt aantonen welke antwoorden zijn gecontroleerd, welke regel of bron is gebruikt, en wat de detector heeft geconstateerd.

Deze aanpak sluit aan bij de manier waarop toezichthouders naar validatie kijken. Wie agents inzet, betrekt daarbij ook het runtime begrenzen van agentacties — precies het terrein waar Agent Contracts op mikken.

Wat kunnen tools doen en wat niet?

De productontwikkelingen bij AWS, Collibra en TrustScale maken hallucinatiedetectie concreet runtime- en bewijsgericht. Dat is winst. Maar de afwezigheid van onafhankelijke, domeinspecifieke evaluatie blijft een structureel risico. Organisaties moeten hun eigen validatie- en monitoringprocessen inrichten náást de aangeboden tools, niet in plaats daarvan. Tools kunnen claims ontleden en tegen regels toetsen; zij kunnen niet bepalen of uw regels juist zijn, of of uw bronnen betrouwbaar zijn. Die oordelen blijven uw eigen professionele verantwoordelijkheid.

Bronnen: Dit artikel is gebaseerd op berichtgeving en richtlijnen van AWS, Collibra en TrustScale.

Marit Halversen

Geschreven door

Marit Halversen

Schrijft over AI-governance en regelgeving, met de nadruk op hoe verplichtingen neerslaan in architectuur in plaats van in papierwerk.