Bewijzen of hopen: wat evaluatie- en guardrail-tooling werkelijk kan vaststellen

Veldnotities agentplatform, zes van acht. Elk governancegesprek komt uiteindelijk bij “hoe weten we dat het werkt”. Deze notitie sorteert de tools die beweren dat te beantwoorden in drie vragen die ze werkelijk beantwoorden, en één die ze niet beantwoorden.

De vraag

Wanneer een gemeente vraagt of een agent veilig te gebruiken is op zaken van inwoners, wijst het engineeringteam meestal naar drie dingen: een evaluatiesuite, een guardrails-laag en een observability-dashboard. Alle drie zijn nuttig. Ze worden ook routinematig met elkaar verward, en die verwarring heeft een vorm: een meting wordt behandeld als een control, en een control wordt behandeld als bewijs.

De vraag voor deze notitie is dus smal. Wat stelt elke klasse tools vast, en wat suggereert ze alleen?

Drie vragen, drie tools

“Gedroeg het zich correct op gevallen die wij kozen?” Dat is evaluatie. De tool die ik hier het hoogst waardeer is Inspect AI, oorspronkelijk van het UK AI Security Institute en nu onderhouden door een non-profit. Het combineert datasets, solvers, tools en scorers; draait de tool calls van elk sample in een eigen sandbox, standaard zonder netwerk; en schrijft een compact, geversioneerd logbestand met een eigen viewer dat kan leven in opslag die jij beheert. Drie ideeën eruit gingen rechtstreeks mijn platform in: de sandbox per sample, het geketende goedkeuringsbeleid waarin een tool call die geen enkele approver claimt wordt geweigerd en elke beslissing in het transcript belandt, en het eval-log als auditartefact.

Wat evaluatie vaststelt: gedrag op de verdeling die je testte, op het moment dat je testte, met de modelsnapshot die je vastpinde. Wat het niet vaststelt: gedrag op het volgende geval, of nadat de provider het model heeft bijgewerkt. Daarom gaat in mijn ontwerp niets live zonder de evaluatieset te doorstaan, en daarom verloopt een kwalificatie.

“Bleef het binnen de grenzen op dit verzoek?” Dat is een guardrail. NeMo Guardrails is het duidelijkste voorbeeld: input-, dialog-, retrieval-, execution- en output-rails, geschreven in een kleine flow-taal, tussen de applicatie en het model. Vooral execution rails, die tool- en actieaanroepen bewaken, komen het dichtst in de buurt van de beleidspoort uit notitie een.

Wat een guardrail vaststelt: dat een specifieke check draaide op een specifiek verzoek en een specifiek oordeel teruggaf. Wat het niet vaststelt: dat de check correct was, of dat hij niet omzeild kon worden. Veel rails zijn zelf modelaanroepen. Een model dat een model beoordeelt, is een nuttige second opinion; het is geen control in de zin die een security engineer bedoelt, omdat de faalwijze dezelfde is als die van het ding dat het bewaakt. Ik gebruik rails als defence in depth en nooit als handhavingspunt. Handhaving is deterministisch en leeft in de governor.

“Wat gebeurde er, in productie, en wat kostte het?” Dat is observability. Langfuse is degene die de meeste teams die ik tegenkom al draaien: tracing van prompts, completions, tool calls en retrieval, met evaluatie, promptversioning en kostenmetrieken erbovenop, zelf te hosten. Dezelfde rol wordt vervuld door Phoenix, Opik en de OpenTelemetry-native stacks.

Wat observability vaststelt: wat het systeem deed, zoals het systeem het zag. Wat het niet vaststelt: of het dat mocht, en of er met het record is geknoeid. Een trace is geen bewijs. Het is de grondstof voor bewijs totdat iets wat je zelf bezit het heeft ondertekend en geketend.

Dijkstra zei dat testen de aanwezigheid van fouten aantoont, nooit de afwezigheid. Hij zei het in 1969 over programma’s. Het is nog steeds het hele evaluatieverhaal, alleen kan het programma nu ook tegenspreken.

De vraag die geen van alle beantwoordt

“Is dit veilig te gebruiken op de zaak van een inwoner?” is geen toolingvraag. Het is een besluit, genomen door een persoon met een naam, op basis van de drie metingen hierboven plus de juridische en organisatorische feiten eromheen: de dataklassen, het doorgiftebesluit, het toezichtontwerp, de bezwaarmogelijkheid.

Daarom heeft mijn platform een kwalificatierecord en geen testscore. Het record pint het evaluatiecontract vast, de uitkomst ervan, de modelroute, de beleidsversie en de goedkeurder, met een vervaldatum. De tools voeden het. Ze vervangen het niet. Een groene evaluatie sluit op zichzelf niets af; een mens sluit het af, en het record zegt wie.

Wat ik leerde van het lezen van de code

Twee bevindingen temperden mijn enthousiasme voor de evaluatietooling, en beide gaan over standaardinstellingen.

De sandbox-isolatie in de evaluatieharness is het sterkst wanneer hij zijn eigen containerconfiguratie genereert. Lever je een eigen configuratie aan, dan verdwijnt de standaard “geen netwerk”. De goedkeuringsketen staat uit tenzij je hem configureert. En er is geen scorepoort: de harness rapporteert, hij stopt geen pipeline. Elk daarvan is redelijk voor een onderzoekstool. Elk is een valkuil voor een team dat de featurelijst leest en aanneemt dat de governance aanstaat. De les is algemener: in evaluatie- en guardrail-tooling is het veilige gedrag meestal beschikbaar en zelden de standaard.

De tweede bevinding gaat over bewijs. Het evaluatielog is uitstekend als artefact, maar het is niet ondertekend, en metadatabewerkingen dragen de auteursnaam die de bewerker opgeeft. Het is dus auditeerbaar in de zin van leesbaar, niet in de zin van tamper-evident. Voor de gemeentelijke use case behandel ik het log als input en hash ik het bij toelating de bewijsketen in, wat het gat dicht zonder de tool te veranderen.

Wat ik nog niet kan bewijzen

Prototypeniveau, met één specifieke kanttekening. Ik heb evaluatiesuites voor het platform, waaronder een modelkwalificatie voor één frontier-model, en ze bewaken wijzigingen in mijn pipeline. Wat ik nog niet heb, is het ding dat deze notitie meer dan een betoog zou maken: een productiehistorie die lang genoeg is om te laten zien dat een verlopende kwalificatie, en het opnieuw draaien van de evaluatie, een regressie heeft gevangen die anders een zaak had bereikt. Op dat bewijs wacht ik.

Wat je hiermee doet

Teken drie kolommen op het whiteboard: bewijzen, beheersen, observeren. Zet elke tool in je stack in precies één kolom. Zoek dan de rij die “veilig te gebruiken” zegt. Staat die in een van de kolommen, haal hem er dan uit. Die hoort bij een persoon, met een datum naast zijn naam.

Volgende notitie: build versus buy, en het bewijsregister dat ik bouwde zodat de beslissing mijn eigen enthousiasme kon overleven.

Een evaluatie die vorig kwartaal slaagde op een model dat de leverancier inmiddels heeft vervangen, rust niet. Hij smacht niet naar de fjorden. Hij heeft opgehouden te bestaan.

Verwijzingen

De knipogen en citaten in dit stuk, met hun herkomst:

• Edsger Dijkstra, “Notes on Structured Programming” (1969): testing shows the presence of bugs, never their absence.
• Monty Python’s Flying Circus (BBC, 1969), the Dead Parrot sketch: “pining for the fjords”, “it has ceased to be”.