Dit kan niet verzonden worden zonder bewijs
Rasmus Kjær Damgaard, Oprichter ·
Dit artikel is met AI‑ondersteuning gemaakt en door een persoon nagelezen. Rasmus Kjær Damgaard draagt de eindredactionele verantwoordelijkheid voor de inhoud.
TL;DR: Marketingclaims drijven af van de realiteit, en niemand merkt het tot een auditor of toezichthouder dat wel doet. Op deze site kan een zin alleen een feitelijke bewering doen over waar data wordt verwerkt, wie er toegang toe kan afdwingen, of het een grens overgaat, of dat een model dat erop getraind is niet gepubliceerd kan worden – tenzij een machinegecontroleerde voorwaarde dat ondersteunt. Dit artikel legt het mechanisme uit, laat drie beweringen zien die het systeem momenteel weigert te publiceren, noemt er één die het daadwerkelijk heeft opgespoord, en beschrijft wat het niet kan bewijzen.
Het probleem is afwijking, en die afwijking is een juridisch risico
Een bewering op de website van een leverancier wordt één keer geschreven en daarna met rust gelaten. Maar de feiten eronder veranderen: er komt een onderverwerker bij, een regio wijzigt, een certificering verloopt. De zin blijft staan. Maandenlang beweert de pagina iets wat de eigen administratie van het bedrijf al tegenspreekt, en het gat blijft onzichtbaar omdat de twee op verschillende plekken staan, bewerkt door verschillende mensen.
Voor een Europese verkoper is dit niet alleen een geloofwaardigheidsprobleem. Volgens de Richtlijn oneerlijke handelspraktijken (2005/29/EG), Artikel 12, mag een autoriteit een handelaar verplichten een feitelijke bewering te bewijzen en kan onvoldoende bewijs worden gezien als bewijs dat de bewering onjuist is. De bewijslast ligt bij jullie, en er is geen rechtszaak voor nodig om dat te activeren. De EU AI Act voegt een eigen transparantieverplichting toe: Artikel 50(1) eist dat een persoon wordt geïnformeerd wanneer hij met een AI-systeem communiceert. Een beweringenpagina die overdrijft wat een bedrijf kan onderbouwen, is precies waar beide regels op mikken.
Het mechanisme: bewering, voorwaarde, register, poort
Het ontwerp is eenvoudig. Een register koppelt elke klantgerichte bewering aan een voorwaarde, en die voorwaarde wordt geëvalueerd aan de hand van feiten die de copywriter niet kan aanpassen: het onderverwerkersregister en de trust-snapshot, beide gegenereerd uit de broncode. Voorwaarden zijn gespecificeerd per laag, want een uitspraak als "gehost in de EU" bestaat uit meerdere beweringen tegelijk: opslag, het requestpad en telemetrie kunnen elk een ander antwoord hebben, en als je die door elkaar haalt, wordt een ware uitspraak over het ene onderdeel een valse over het andere.
De poort, bun run check:claims, dwingt vervolgens vier dingen af in één keer. Een bewering waarvan de voorwaarde onwaar is, mag niet in de content verschijnen, in welke taal dan ook. Elke tekst die een belofte doet over verblijfplaats, jurisdictie, gegevensoverdracht of training moet worden gedeclareerd, zodat de volgende absolute niet stiekem kan worden toegevoegd. Geen enkele dergelijke bewering mag buiten de vertaalbare berichtencatalogus bestaan, waar hij aan alle andere controles ontsnapt. En een bewering die in het Engels is gecorrigeerd, mag niet actief blijven in de andere 22 talen: de pipeline vertaalt alleen opnieuw wanneer iemand hem draait, dus een aanpassing die alleen in het Engels wordt doorgevoerd, laat de oude bewering in alle andere talen staan. Die laatste controle is de pariteitspoort, en dat is degene die de meeste systemen over het hoofd zien.
Het laatste onderdeel schrapt het schrijfproces volledig voor de risicovolste onderdelen. In plaats van handmatig een verblijfplaatszin in een meta-omschrijving of manifest te schrijven en te hopen dat een reviewer het oppikt, gebruiken die onderdelen een token dat wordt omgezet in een fragment dat uit het register komt. Dat fragment wordt alleen weergegeven zolang de voorwaarde geldig is. Een zin die het register niet kan onderbouwen, heeft geen fragment om in te voegen – en kan dus niet getypt worden. Detectie pakt één formulering per keer aan; generatie sluit de hele categorie af.
Wat het weigert
De beste manier om een poort te vertrouwen, is door hem nee te zien zeggen. Drie beweringen zijn vandaag gedeclareerd die het register momenteel niet laat publiceren, en de poort meldt bij elke run dat ze geblokkeerd zijn:
- Een bewering dat onze voorwaarden, die modelaanbieders verbieden om klantcontent te gebruiken voor training, contractueel doorwerken in elke laag. Dat is onze intentie, maar het register heeft daar nog geen bewijs voor, dus blijft het ongepubliceerd.
- Een bewering dat het platform al volledig voldoet aan de EU AI Act. Het corpus registreert een status per verplichting, en niet alle zijn vervuld, dus de allesomvattende versie wordt geweigerd.
- Een bewering over de jurisdictie van de modelsupplychain, waarvoor een voorwaarde over de bedrijfsincorporatie nodig is in plaats van over waar een request wordt verwerkt, en die nog niet geldig is.
Dit zijn geen vergissingen. Het zijn beweringen die we graag zouden maken, maar niet doen, omdat de discipline belangrijker is dan de zin.
Het heeft ook een actieve fout opgespoord. Op 2026-07-27 landde de poort (commit 3b7a4bffd), en binnen een dag dwong hij een correctie af die het reviewproces had gemist: de hero-tekst op de landingspagina beweerde datadata-residency zonder enige onderbouwing in het register (commit a8d94d4a3), en de pariteitscontrole eiste vervolgens dat de gecorrigeerde formulering in alle 22 andere talen werd doorgevoerd, niet alleen in het Engels. De beweringen die wel door de controle kwamen, zijn de specifieke, controleerbare: generatie draait in Frankrijk, embeddings in Berlijn, documenten in Ierland en Neurenberg, elk getoond op de trustpagina met de bijbehorende overdrachtsbasis.
Wat het niet kan bewijzen, duidelijk uitgelegd
Een poort die zichzelf overschat, is precies wat hij moet voorkomen. Dus hier is de grens. Hij bewijst dat elke gepubliceerde bewering overeenkomt met het register. Hij bewijst niet dat het register de wereld correct beschrijft, hoewel een aparte poort het register aan de code toetst. Hij kan niet verifiëren of een benchmarkcijfer klopt of dat een genoemde artikelnummer het juiste is; dat zijn oordeelskwesties die een reguliere expressie niet kan bereiken. Wat hij wegneemt, is het specifieke, terugkerende probleem waarbij een bewering die bij lancering waar was, stilletjes onwaar wordt en niemand het bestand in de gaten houdt. De bewering in eerste instantie goed krijgen, blijft een taak voor mensen.
Hoe jullie hetzelfde kunnen doen
Het patroon is overdraagbaar, en geen van de onderdelen is bijzonder. Houd een machineleesbaar register bij van de feiten waarop jullie beweringen berusten, gegenereerd uit de broncode in plaats van handmatig onderhouden. Geef elke bewering een voorwaarde die het register kan weerleggen, zo nauwkeurig gespecificeerd dat de waarheid van het ene subsysteem niet kan doorgaan voor die van een ander. Voer een pre-commitpoort uit die elke bewering in elke taal die jullie aanbieden evalueert, en laat een onware voorwaarde de build falen. Gebruik vervolgens, voor de onderdelen waar een onjuiste absolute de meeste schade aanricht, gegenereerde beweringstekst uit het register in plaats van die handmatig in te typen.
Het resultaat is geen luidere copy. Het is copy die een kritische lezer kan controleren – en voor een Europese koper die een securityleverancier evalueert, is dat de enige soort die converteert.
Veelgestelde vragen
Wat controleert de claims-gate eigenlijk?
Het leest elke gedeclareerde claim over de verwerkingsketen, evalueert de predicaat tegen het sub-processorregister en het trust-snapshot, en laat de build mislukken als een claim waarvan de predicaat onwaar is, verschijnt in de tekst in een van de 23 talen. Het draait als een pre-commit hook en opnieuw in CI.
Waarom het register controleren in plaats van gewoon de tekst te beoordelen?
Een menselijke beoordeling bewijst de staat op de dag dat deze wordt uitgevoerd en niets daarna. Het register wordt gegenereerd vanuit de bron en is in beide richtingen geborgd, dus het koppelen van de zin aan het register betekent dat de zin niet langer kan bestaan dan het feit waarop deze rust. Wanneer een leverancier verandert, faalt de claim die ervan afhankelijk was bij de volgende commit.
Bewijst de gate dat jullie claims waar zijn?
Nee, en dat staat er ook. Het bewijst dat elke gepubliceerde claim overeenkomt met het register; het kan niet verifiëren dat een benchmarkgetal echt is of dat een geciteerd artikelnummer het juiste is. Dat blijft een menselijk oordeel. De gate elimineert de faalmodus waarbij een bij de lancering ware claim stilzwijgend onwaar wordt, niet de noodzaak om de claim in eerste instantie goed te krijgen.
Kunnen we dit patroon hergebruiken?
Ja. De onderdelen zijn een machineleesbaar register van feiten als de enige bron van waarheid, een predicaat per claim die het register kan weerleggen, een pre-commit gate die elke taalversie evalueert, en het genereren van de claimstrings vanuit het register in plaats van ze met de hand te typen. Elk onderdeel is klein; de discipline zit in het aan elkaar koppelen ervan.