AI schreef het werk: zo leg je vast wie wat heeft gedaan

De vraag die steeds vaker op tafel ligt

Je laat een offerte voorbereiden door AI. Een collega laat een e-mail aan een klant opstellen. Iemand van de administratie laat een rekenblad opschonen. Het werk is sneller klaar en meestal is het ook goed.

Tot er iets niet klopt. Dan komt de vraag: wie heeft dit eigenlijk gemaakt? En wie heeft er naar gekeken voordat het de deur uit ging?

Bij de meeste bedrijven is daar geen antwoord op. Het werk ligt er, het is af en niemand weet meer welk deel uit een AI-venster kwam. Dat is geen klein ongemak. Het is precies de informatie die je nodig hebt op het moment dat een klant een fout terugkaatst.

Wat de bedenker van Linux deze week opschreef

Op 12 oktober verscheen er een nieuwe tak in de code-opslag van Linus Torvalds, de man die Linux is begonnen en er nog dagelijks aan werkt. De tak heet noref-filemap-read-with-llm en bevat acht wijzigingen aan de manier waarop Linux bestanden uit zijn geheugencache leest.

Technisch gaat het hierover: als meerdere programma's tegelijk hetzelfde bestand lezen, zaten ze elkaar in de weg bij een gedeelde teller die bijhoudt hoeveel lezers er zijn. Torvalds haalt die teller uit de leesroute weg en stelt het vrijgeven van geheugen kort uit, zodat lezen veilig blijft zonder dat iedereen op dezelfde plek moet wachten.

Het interessante zit in de begeleidende tekst. Torvalds schrijft daar dat de code, de testprogramma's, de controle erachter en de eerste versie van die tekst zelf zijn gemaakt met een AI-assistent, Claude Code, onder zijn leiding. En hij zet er een tweede zin bij: de metingen heeft hij op zijn eigen machine gedaan.

Waarom juist die tweede zin telt

Veel mensen lezen het eerste deel en denken: zie je wel, AI schrijft nu kernelcode. Het tweede deel is belangrijker voor jouw bedrijf.

Torvalds splitst zijn verantwoording in twee stukken. Wat de AI deed, benoemt hij. Wat hij zelf deed, benoemt hij ook. Dat is het deel waar hij zijn naam aan verbindt: de richting bepalen, zelf meten of de winst echt bestaat en beslissen of de keerzijde acceptabel is.

Die keerzijde staat er gewoon bij. Op zijn eigen laptop daalde het aantal rekenstappen per leesactie van ongeveer 2.950 naar ongeveer 725 bij acht gelijktijdige lezers. De botsingen tussen die lezers gingen van 30.538 naar 101. Maar één geval werd juist duurder: een enkele lezer die een nog niet ingeladen stuk geheugen aanraakt, ging van ongeveer 4.150 naar 6.550 rekenstappen. Hij noemt dat, weegt het af en vindt het de ruil waard.

En dan het laatste punt: de wijziging is niet opgenomen in Linux. Hij staat in een losse tak, buiten de officiële versie, langs dezelfde beoordeling als elke andere bijdrage.

Drie dingen die je zelf opschrijft

Je hoeft geen kernelontwikkelaar te zijn om dit over te nemen. Het patroon is simpel genoeg voor een bedrijf van vier mensen.

1. Welk deel kwam uit AI. Benoem het concrete stuk: de eerste versie van de tekst, de berekening, de samenvatting van het telefoongesprek. Het hele document aanmerken zegt te weinig. Eén regel onderaan of in een opmerkingenveld is genoeg.
2. Welke persoon heeft het nagekeken en waarop. "Jan heeft de bedragen tegen de offerte gelegd" zegt iets. "Gecheckt" zegt niets.
3. Wat je zelf hebt vastgesteld. Als er een getal of een belofte in staat, moet iemand het ergens aan hebben getoetst. Schrijf op waaraan.

Dat is het. Drie regels bij werk dat de deur uit gaat of in een dossier belandt.

Waarom dit in een klein bedrijf eerder knelt

Bij een groot bedrijf vangt een goedkeuringsproces dit op. In een klein bedrijf is de persoon die het werk maakt vaak ook de persoon die het verstuurt. Dan verdwijnt het onderscheid tussen opstellen en nakijken.

Dat gaat lang goed. Het gaat mis op het moment dat je het achteraf moet uitleggen: aan een klant die een verkeerd bedrag heeft gekregen, aan je accountant, of aan een verzekeraar die wil weten hoe een advies tot stand kwam. Dan is "dat heeft de AI gedaan" het slechtste antwoord dat er is, omdat het niemand aanwijst.

Met een vastgelegde verdeling heb je een ander gesprek. Je kunt laten zien waar de fout zat: in de opdracht, in het nakijken of in iets wat niemand kon weten. Alle drie zijn te repareren. Een onbekende herkomst niet.

Hoe je dit invoert zonder nieuwe tool

Je hebt hier geen software voor nodig en dat is het punt.

• Spreek af bij welke soorten werk de regel geldt. Begin smal: alles met een bedrag erin plus alles dat een klant leest.
• Zet een vast veld of een vaste slotregel in de sjablonen die je al gebruikt. In een offerte-sjabloon, onderaan een adviesdocument, in het opmerkingenveld van je dossier.
• Laat de persoon die nakijkt zijn eigen naam intypen. Een automatisch ingevulde naam is geen controle.
• Kijk na een maand terug op vijf stukken en vraag of je uit de aantekening nog begrijpt wat er is gebeurd. Zo niet, dan is de aantekening te vaag.

Een automatisering die zelf werk aflevert, verdient dezelfde behandeling. Loopt er een workflow die e-mails of documenten opstelt, laat die dan in de uitvoer zetten welke stap het heeft gedaan. Hoe je dat in een workflow inbouwt, lees je in onze uitleg over n8n voor ondernemers.

Waar de grens ligt

Dit lost niet op dat AI dingen verzint. Het zorgt er alleen voor dat je weet waar je moet kijken als dat gebeurt. En het zorgt ervoor dat er een mens aanwijsbaar tussen het werk en de klant staat.

Het vervangt ook geen vakkennis. Torvalds kon dit doen omdat hij zelf kan beoordelen of kernelcode deugt en omdat hij zelf heeft gemeten. Wie een AI iets laat maken waar hij zelf niets van weet, houdt een gok over. Over waar die grens bij software precies ligt, schreven we eerder in wat je van AI-softwareontwikkeling mag verwachten.

Begin bij het soort werk dat bij jou het vaakst de deur uit gaat. Zet er deze week één regel onder. Je merkt het verschil pas als er iets misgaat. Dan merk je het meteen.

Benieuwd hoe je dit vastlegt bij de automatiseringen die bij jou al draaien? We kijken het graag samen met je door.