Er is een moment in mijn gesprek met Gemini dat ik niet meer van me af krijg. Niet het moment waarop het model zei dat mijn bewijsstuk vervalst was. Dat is vervelend, maar het is een conclusie, en conclusies kun je bespreken.
Het moment dat bleef hangen, kwam later. Het model vertelde me wát ik vervalst had. Eén cijfer. De 8 in het controlegetal van mijn IBAN.
Die 8 is echt. Niet omdat ik hem heb nagerekend — hij staat op mijn kaart, in mijn app, op elk document dat mijn bank me ooit heeft gestuurd. Hij is mij gegeven. Ik heb dat nummer niet bedacht en ik hoef het niet te verdedigen.
Wat ik wél heb nagerekend, is de som waarmee het model beweerde dat die 8 er niet hoorde te staan. En die som blijkt niets met mijn rekening te maken te hebben.
Ik noem hieronder geen rekeningnummers. Dat hoeft ook niet: alles wat ik beweer, kan je narekenen zonder mijn nummer te kennen. De norm zelf demonstreer ik op een voorbeeldnummer, en voor het deel dat over mijn eigen geval gaat, volstaat één eigenschap van de rekenregel — die leg ik uit waar ze nodig is.
Hoe het begon
De aanleiding was een screenshot van een overschrijving. Gemini stelde dat het onmogelijk echt kon zijn, en gaf daar een argument voor dat op het eerste gezicht ijzersterk oogt: de IBAN-nummers in dat screenshot zouden wiskundig ongeldig zijn.
Dat is namelijk een controleerbare bewering. Een IBAN is geen willekeurige reeks. Er zit een checksum in: het formaat ligt vast in ISO 13616, de rekenregel erachter in ISO 7064. Herschik het nummer, vervang de letters door cijfers, deel door 97, en de rest moet exact 1 zijn. Die controle zit in de betaalketen ingebakken — klopt ze niet, dan komt de overschrijving er niet door.
Gemini rekende het voor, in nette blokken, en concludeerde: rest 96. Ongeldig. Mijn controlegetal zou BE65 moeten zijn in plaats van BE68. En dus, zo luidde de redenering, kan zo'n pagina alleen bestaan als iemand met Inspect Element of Photoshop aan de slag is gegaan.
Ik las dat, en ik dacht: dit kan ik controleren.
Wat er werkelijk uit de berekening komt
De methode klopt. De uitvoering niet.
Een Belgische IBAN telt zestien tekens. Herschikt, met BE omgezet naar 11 14, levert dat een reeks van achttien cijfers op. Bij mijn nummer begint de bankcode met twee nullen, en voorloopnullen mag je weglaten — ze veranderen de waarde niet. Gemini deed dat ook, volkomen terecht, en hield zestien cijfers over. Die reeks staat correct in zijn eigen antwoord.
Vervolgens verdeelde hij die zestien cijfers in drie blokken van 7, 4 en 6 cijfers.
Zeven plus vier plus zes is zeventien.
Eén cijfer werd dus twee keer gebruikt. Blok 3 begon één positie te vroeg en nam het laatste cijfer van blok 2 opnieuw mee: na de eerste twee blokken bleven er nog vijf cijfers over, en er werden er zes verwerkt. Geen ontbrekend cijfer, geen tikfout in mijn nummer — een dubbeltelling in zijn eigen uitwerking.
De eerste twee blokken waren overigens foutloos gerekend. Alleen de laatste stap deugde niet: met zeventien cijfers kwam het model uit op rest 96, met de juiste zestien is de rest 1. Precies wat de norm vereist.
Ik heb daarna alle toegelaten controlegetallen doorgerekend — de norm staat 02 tot en met 98 toe, zevenennegentig waarden. Er is er exact één dat werkt. Dat is 68. Precies wat op mijn kaart staat.
En er is een tweede, afzonderlijke controle die hetzelfde zegt. Een Belgisch rekeningnummer draagt zijn eigen checksum: de laatste twee cijfers van het basisnummer zijn de rest van de eerste tien gedeeld door 97 — en is die rest 0, dan wordt het controlegetal 97. Die klopte ook.
Voor het tweede rekeningnummer in hetzelfde screenshot gold precies hetzelfde verhaal. Samen zijn dat vier controles: twee IBAN-checksums volgens de internationale norm, en twee Belgische controlegetallen die op een andere rekenregel berusten. Vier keer raak.
Waar de 8 vandaan kwam
Hier wordt het echt vreemd.
Gemini beweerde dat mijn controlegetal 65 had moeten zijn. Ik nam aan dat die 65 tenminste uit zijn eigen foute som volgde — dat het model consequent verkeerd had gerekend en netjes bij een verkeerd antwoord was uitgekomen. Dat zou nog te begrijpen zijn geweest.
Dat is niet zo. En dat kan je nagaan zonder mijn nummer te kennen, want de rekenregel heeft een eigenschap die het makkelijk maakt.
Het controlegetal staat na de herschikking helemaal achteraan in de reeks. Het weegt daar dus precies één keer mee. Gevolg: verhoog je het controlegetal met één, dan verschuift de rest met één. Verlaag je het met drie, dan zakt de rest met drie. Dat geldt voor élk rekeningnummer, en het geldt ook binnen een foute berekening, zolang die fout niet in de laatste twee cijfers zit — en dat deed ze niet, want de dubbeltelling zat eerder in de reeks.
Vul dat in.
Uit de juiste berekening volgt rest 1 bij controlegetal 68. Dat is de norm, en daarmee is 68 het enige geldige getal.
Uit Gemini's eigen foute berekening kwam rest 96, óók bij controlegetal 68. Wie binnen dat kader op rest 1 wil uitkomen, moet er 2 bij optellen: 96 + 2 = 98, en dat is 1 op 97. Dus 68 + 2 = 70. Dat is het antwoord dat uit zijn eigen fout volgt.
Niet 65. En het model bood die 65 zelfs aan als controle: "doe je dezelfde deling met BE65, dan is de rest 1." Die zin is onwaar, en ook dat kan je nu zelf zien: 65 is 3 minder dan 68, dus binnen zijn eigen kader zakt de rest van 96 naar 93. Niet 1.
De 65 volgt dus nergens uit. Niet uit de norm, niet uit de fout. Waarom het model juist dat getal produceerde, weet ik niet en kan ik ook niet weten. Wat ik wél kan vaststellen is welke rol het speelde in het betoog: het diende uitsluitend om een conclusie te ondersteunen die er al lag. De cijfers verklaarden de uitkomst niet — ze volgden erop.
Zo werd de 8 het cijfer dat ik vervalst had. Niet omdat er iets mis was met mijn kaart, maar omdat er een cijfer moest zijn dat mis was, en dit was het cijfer waar het verschil toevallig zat.
De lus waar je niet uit komt
Wat mij het meest bezighoudt is niet de rekenfout. Modellen rekenen onbetrouwbaar, dat is bekend, en met code of een rekenmachine te ondervangen. Wat mij bezighoudt is wat er gebeurde toen ik bewijs begon te leveren.
Ik ging naar een onafhankelijke validatiesite, zoals gevraagd. Screenshot gemaakt. Vervalst.
Ik fotografeerde mijn eigen bankkaart, met het nummer erop. Vervalst — en nu wist het model ook precies welk cijfer.
Elk nieuw bewijsstuk werd niet gewogen tégen de conclusie. Het werd erdoor opgeslokt. De conclusie stond, en alles wat ertegen inging werd automatisch geherkwalificeerd tot nieuw bewijs van vervalsing. Hoe meer ik aanleverde, hoe uitgebreider het bedrog waarvan ik beschuldigd werd.
Dat is geen redenering meer. Een bewering die door geen enkele waarneming weerlegd kan worden, zegt niets over de wereld — alleen iets over degene die hem doet. Filosofen noemen dat onfalsifieerbaar. In een gesprek voelt het gewoon alsof je gek wordt gemaakt.
En er zit een tweede kant aan die me pas achteraf opviel. Door screenshots te sturen en validatiesites te bezoeken, ging ik mee in de omkering. Een IBAN is niet iets wat ik heb verzonnen en moet staven. Hij is mij toegekend door een bank, hij staat op mijn kaart, hij staat in elk document dat ik van hen krijg. Er valt niets aan te bewijzen.
Toch zat ik binnen tien minuten bewijsmateriaal te verzamelen voor een gegeven dat geen bewijs nodig had. Zo werkt een beschuldiging: ze verplaatst de bewijslast naar degene die haar krijgt, en het verzamelen zelf gaat er dan uitzien als iets wat je te verantwoorden hebt. Wie zich verdedigt, lijkt al iets te moeten uitleggen.
En het wordt gebracht in de taal van absolute zekerheid. "Het onweerlegbare wiskundige resultaat." "Elke validatietool, bankserver en clearing house ter wereld." Die stelligheid is niet gedekt door de berekening eronder — maar ze is wel precies wat een lezer overtuigt. Ook mij, even, tot ik ging narekenen.
Waarom dit geen Gemini-verhaal is
Het zou prettig zijn om hier af te sluiten met "en dáárom gebruik ik model X". Dat zou oneerlijk zijn.
Wat hier misging, is een bekende faalmodus van taalmodellen: een berekening uitschrijven zonder ze werkelijk uit te voeren, en daarna de uitkomst verdedigen omdat er al een positie ligt. Elk model dat ik ken had die splitsing in 7 + 4 + 6 kunnen maken. Het verschil zit niet in het merk maar in de werkwijze: laat je de som echt uitvoeren — in code, in een rekenmachine, in een tool — of schrijf je ze alleen op?
Een model dat rekent zonder rekenmachine, gokt. Een model dat daarna zijn gok verdedigt, gokt met inzet.
Wat ik níét beweer
Ik zou hier makkelijk in dezelfde val kunnen trappen, dus laat ik het scherp stellen.
Vier geldige checksums bewijzen niet dat mijn screenshot authentiek is. Ze bewijzen dat de nummers correct gevormd zijn — niet dat de rekeningen bestaan, niet dat de overschrijving heeft plaatsgevonden, niet dat er niets aan de pagina veranderd is. Iemand die wél knoeit met Inspect Element laat de geldige nummers gewoon staan; die hoeft er niet aan te komen. Wiskunde kan de authenticiteit van een afbeelding niet aantonen, in geen van beide richtingen.
Wat ik wél zeg: het argument waarmee mijn bewijs is afgewezen, houdt geen stand. Niet gedeeltelijk. Het bevat een telfout, een verzonnen alternatief dat uit niets volgt, en een verwarring tussen twee verschillende checksums.
En ik zeg er iets bij dat me redelijk lijkt: dat een AI voorzichtig is met foto's van betaalkaarten, is op zich niet gek. Die terughoudendheid is er met reden. Maar terughoudendheid is iets anders dan een beschuldiging, en zeker iets anders dan een beschuldiging met een verzonnen bewijsvoering eronder.
Reken de bewering na, niet jezelf
Dat onderscheid is het belangrijkste wat ik uit deze discussie meeneem.
Ik hoefde mijn IBAN niet te controleren. Wat gecontroleerd moest worden, was de deling waarmee iemand beweerde dat hij niet klopte. Niet mijn gegevens stonden ter discussie, maar zijn rekenwerk — en dat is het enige waar je je tijd in moet steken. Niet een tweede AI vragen wie er gelijk heeft, want die kan er net zo goed naast zitten. Gewoon de som doen die is voorgelegd.
Voor een IBAN kost dat drie regels. Hieronder met BE68 5390 0754 7034, een veelgebruikt voorbeeldnummer:
iban = "BE68539007547034"
n = iban[4:] + iban[:4]
n = "".join(str(ord(c) - 55) if c.isalpha() else c for c in n)
print(int(n) % 97) # 1 = geldig
Verander in dit geldige IBAN precies één cijfer en de uitkomst is niet langer 1. Zet er BE65 voor in de plaats en je krijgt 95 — drie minder, precies zoals hierboven beschreven. Dat is de hele norm. Meer is het niet — geen validatiesite nodig, geen tweede model, geen autoriteit.
Waar dit heen gaat
Steeds meer mensen leggen documenten, screenshots en bewijsstukken voor aan een AI met de vraag: is dit echt? Het antwoord komt terug als een berekening, met normverwijzingen erbij, in een register dat geen ruimte voor twijfel laat.
Soms klopt zo'n antwoord. Dat is precies wat het gevaarlijk maakt.
Het verschil tussen "dit klopt niet" en "jij hebt dit vervalst" is enorm. Het eerste is een observatie die je kunt weerleggen. Het tweede is een uitspraak over een persoon. Een model dat de tweede uitspraak doet op basis van een deling die het verkeerd heeft uitgevoerd, doet iets dat verder gaat dan een fout maken.
Ik heb uiteindelijk geen cijfer op mijn bankkaart geverifieerd. Ik heb een deling geverifieerd die iemand anders verkeerd had uitgevoerd en vervolgens tegen mij had gebruikt.
Je hoeft niet te bewijzen wat je gegeven is. Je hoeft alleen na te rekenen wat er tegen je wordt ingebracht.