Decision-grade blueprints · Deel 1 van 4
Een beeld dat klopt
Elk AI-project begint met één zin en vier verschillende producten in vier hoofden. Een accuraat beeld maakt er één product van, nog voor er gebouwd wordt.

Dit is één van vier artikels over decision-grade blueprints: beelden van AI-producten die goed genoeg zijn om er beslissingen op te nemen, nog voor er gebouwd wordt.
Vier mensen rond een tafel. De directeur zegt: “We willen AI gebruiken om sneller de juiste kandidaten te vinden.” Iedereen knikt.
De recruiter ziet een tool die haar avonden teruggeeft. De IT-verantwoordelijke ziet een model dat cv's leest. De jurist ziet een dossier dat ze liever niet opent. De directeur ziet een lijn in het jaarverslag. Vier mensen, vier producten, één zin.
Zo begint bijna elk AI-project dat ik de voorbije jaren heb zien vertrekken. Wat er nog niet is: een gedeeld beeld van wat er gebouwd wordt. Het woord “AI” werkt dan als een spiegel. Iedereen vindt er zijn eigen verwachting in terug, tot de eerste oplevering die spiegel breekt.
Vervang die spiegel door een beeld, een beeld dat klopt, en de vier producten worden er één.
Drie soorten beelden
Er zijn ruwweg drie manieren om een product te tonen voor het bestaat.
Het wireframe. Grijze vlakken, lijnen, placeholders. Het is eerlijk, want het belooft niets. Maar het vraagt verbeelding, en ieder vult de gaten op zijn eigen manier in. Een goedgekeurd wireframe betekent dus vaak twaalf verschillende producten: één per persoon aan tafel, en nog een paar voor wie later aanschoof.
De ambitieuze demo. Die is de laatste jaren spectaculair goedkoop geworden. Met de juiste tools staat er op een namiddag een klikbaar scherm dat eruitziet als een afgewerkt product: “AI-match 94%”, een schakelaar die afwijzingen automatisch verstuurt, een dashboard dat gloeit. Soms is de demo sneller klaar dan het gesprek over wat ze eigenlijk moet voorstellen. Ze overtuigt, en dat is precies het probleem: ze toont wat iemand graag zou willen, niet wat de data, het model en de wet toelaten.
Onderaan die demo staat Marek. Lasser, acht jaar ervaring, cv in het Pools. 61 procent, automatisch afgewezen. Niemand aan tafel heeft hem ooit gezien, en dankzij de demo blijft dat zo.
Het accurate beeld. Het ziet er even af uit als de demo, maar het is gebouwd op wat werkelijk kan. Het toont waarop het systeem steunt, waar die onderbouwing zwak wordt, en waarom. Het laat zien waar een mens moet bevestigen.
De casus in deze reeks is fictief: een illustratief ontwerp, geen gevalideerd systeem. De mensen, het bedrijf en de data bestaan niet.



Wat accuraat betekent
Accuraat is geen synoniem voor gedetailleerd. Een beeld is accuraat als elke bewering erop houdbaar is. Concreet betekent dat zes dingen.
- Het is bouwbaar. Elk getal, elke status en elke suggestie komt uit data die er is of realistisch kan komen, en uit een model dat dat aankan.
- Het is eerlijk over twijfel. Waar het systeem op zwakke grond staat, zegt het dat, in woorden die een gebruiker begrijpt, met de reden erbij.
- Het toont de mens. Wie bevestigt, wie mag overschrijven, wat er bewaard wordt. Een wervingsproduct zonder zichtbare mens is zelden een product dat je zou moeten willen.
- Het is uitvoerbaar. Elke menselijke actie die het systeem veronderstelt, heeft in de organisatie een eigenaar en een proces. Een scherm dat een praktijkproef voorstelt terwijl niemand die kan organiseren, is niet accuraat, hoe goed het er ook uitziet.
- Het respecteert de regels. De wet bepaalt mee wat er op een scherm mag staan, en wat er net niet mag staan.
- Het zegt wat het niet is. Wat later komt, krijgt het label “later”. Wat illustratief is, heet illustratief.
Onder elk scherm ligt zo een tweede laag: welke gegevens, uit welke bron, wat het model levert en wat de mens doet. Die laag maakt van een beeld een bouwplan.


Waarom het een vak is
Achter één rustige melding als “scan half leesbaar, norm niet vermeld” zitten honderd kleine oordelen. Kan dit model een functietitel in het Pools betrouwbaar herkennen? Mag dit gegeven hier wel getoond worden? Welke status leest een consulent om vier uur 's middags verkeerd? Wat gebeurt er als twee bronnen elkaar tegenspreken? Wie is aansprakelijk als het systeem “in orde” zegt en het is niet zo? En wat gebeurt er met wat níet op het scherm staat?
De laatste vraag verdient de meeste aandacht: een fout op het scherm wordt gecorrigeerd, maar een gegeven dat het scherm nooit haalt, mist niemand.
Elk van die vragen hoort bij een ander vakgebied: data-architectuur, wetgeving, de psychologie van interpretatie, procesontwerp, visuele helderheid. Een accuraat beeld is de plek waar ze elkaar moeten ontmoeten, op één scherm, in één beslissing. Daarom is het geen marketing. Het is een technische discipline. En het resultaat moet er bovendien nog goed uitzien.
Elk van hen, de klant inbegrepen, kan zijn deel aanwijsbaar bevestigen of bijsturen: de jurist het gegeven dat er staat, de developer de bron erachter, de klant zijn verwachting. Niemand bevestigt daarmee een garantie, wel de aannemelijkheid, en bij elke bevestiging staat een naam. Wat daarna nog verrast, valt op, omdat er een gedeelde referentie is.
De blueprint als gedeelde bron
Eén scherm, vijf lenzen
Elke discipline kijkt naar hetzelfde beeld en stelt er haar eigen vraag bij. Waar de vragen samenvallen, vallen de beslissingen.






Lenzen
- M1Kan de extractie elke bevinding naar de juiste zin in het cv laten verwijzen?
- M2Wat doet het model met een half leesbare scan: onvolledig melden of gokken?
- D1Origineel en vertaling naast elkaar bewaren: welke opslag, en hoe lang?
- D2Wat schrijft de logregel weg, en wie mag hem lezen?
- G1Hoeveel klikken kost dit bij twintig dossiers op een middag?
- G2Durf ik af te wijken van het voorstel, en kost dat moeite?
- L1Volstaat deze mail als duidelijke en betekenisvolle uitleg?
- L2Kan Victor het voorstel echt begrijpen en overschrijven?
- B1Wie organiseert de praktijkproef, en wat kost ze per kandidaat?
- B2Krijgt ChainConstruct sneller een sterkere kandidaat dan nu?
Twee plekken, drie lenzen tegelijk. De praktijkproef (model, gebruiker, business) en de beslissing (gebruiker, wet, business). Daar moet het kloppen voor er gebouwd wordt.
- M1Kan de extractie elke bevinding naar de juiste zin in het cv laten verwijzen?
- M2Wat doet het model met een half leesbare scan: onvolledig melden of gokken?
- D1Origineel en vertaling naast elkaar bewaren: welke opslag, en hoe lang?
- D2Wat schrijft de logregel weg, en wie mag hem lezen?
- G1Hoeveel klikken kost dit bij twintig dossiers op een middag?
- G2Durf ik af te wijken van het voorstel, en kost dat moeite?
- L1Volstaat deze mail als duidelijke en betekenisvolle uitleg?
- L2Kan Victor het voorstel echt begrijpen en overschrijven?
- B1Wie organiseert de praktijkproef, en wat kost ze per kandidaat?
- B2Krijgt ChainConstruct sneller een sterkere kandidaat dan nu?
Een beeld dat nee durft te zeggen
In het voorbeeld van deze reeks vraagt de klant ook om de “werkattitude” van kandidaten te voorspellen uit hun cv. Teken het als percentage of als sterren voor inzet, en het valt uit elkaar: er is geen data die het draagt. Een cv beschrijft wat iemand deed, niet hoe hij werkt; zo'n model zou vooral schrijfstijl meten. Hoe leg je een kandidaat uit dat hij een lage “attitude” kreeg? En hoe verdedig je dat tegenover een toezichthouder, in een domein dat de AI Act als hoog risico bestempelt?
Het scherm blijft leeg, en dát is het resultaat. Om tot die leegte te komen, moest je weten welke data er is, wat het model kan, wat de wet vraagt en wat de klant eigenlijk wil weten. Dat is werk van dagen. Ik heb dezelfde ontdekking in andere projecten pas na maanden bouwen zien vallen. Dan kost ze geen dagen meer, maar budget, vertrouwen en soms het project zelf.

En een beeld dat kansen ziet
Wie AI-ontwerp herleidt tot risicobeheer, mist de helft. Privacy, discriminatie en aansprakelijkheid zijn terechte zorgen, maar ze vertellen niet wat AI kan dat een klassiek systeem niet kan.
Terug naar Marek. Een filter op trefwoorden vindt “lasser” niet in zijn cv, want daar staat “spawacz”. Zijn diploma laat zich niet zomaar naast een Belgisch diploma leggen. Hij valt weg voor iemand hem gezien heeft. Een goed ontworpen systeem herkent zijn ervaring, zegt eerlijk dat het diploma niet automatisch te vergelijken is, en stelt een praktijkproef voor in plaats van een afwijzing.
Dat is een ontwerpkeuze. Voor Marek is het misschien een job. Voor een metaalbedrijf dat al maanden geen lasser vindt, misschien eindelijk die lasser.

Waarom het zelden het startpunt is
In de meeste projecten komt zo'n beeld niet eerst. Het komt erna, als het product al half gebouwd is en iemand vraagt of het scherm “nog even mooi” kan. Vooraf lijkt het tijdverlies: er wordt nog geen code geschreven, de demo toonde toch al hoe het eruit zou zien, en het budget staat klaar voor de bouw.
Maar het beeld beslist meer dan het lijkt. Hoeveel rijen telt de tabel op het scherm van de recruiter? Wat blijft er zichtbaar in het zijpaneel, en wat zie je pas als je scrolt? Wie dat pas na de bouw ontdekt, herwerkt niet een tekening, maar een product. En bij een product dat mee beslist over mensen komt daar nog iets bij: de duurste keuzes liggen in wat er niet op het scherm staat. Welke gegevens het gebruikt, wie bevestigt, wat het weigert te doen. Die keuzes vallen hoe dan ook. De vraag is alleen wanneer.
Een terechter bezwaar, en een dat ik vaak hoor: te pixel-perfect, te veel tijd in gestoken. Er zit iets in: wie iets ziet dat af lijkt, gaat ervan uit dat het bijna gebouwd is.
Het antwoord is niet minder afwerking, maar precies zoveel als de beslissing vraagt, met eerlijke labels. Voor een keuze over architectuur volstaan soms vakken en pijlen. Wie wil weten of een consulent een voorstel te snel goedkeurt, heeft een scherm nodig dat aanvoelt als het echte product.
In een accuraat beeld staat daarom bij elke fase of ze geoffreerd is of niet. Wat illustratief is, draagt dat woord. En bij elke oplevering hoort een lijst met wat ik buiten de opdracht opmerkte.
Een klant die voelt hoe een product werkt, ziet ook sneller waar het wringt.
Een blueprint is daarbij geen watervalspecificatie. Hij legt vast wat vroeg beslisbaar is, zet de rest als open vraag met een eigenaar, en groeit mee met wat de bouw leert.
Previsualisatie voor AI-producten
In de filmwereld bestaat een discipline die previsualisatie heet. Voor er een dure draaidag begint, wordt een complexe scène eerst in beeld gebracht: camerastandpunten, timing, wat er in het kader staat. Niemand verwart die previsualisatie met de film. Maar niemand draait zo'n scène zonder.
AI-producten verdienen dezelfde discipline. Ik noem het voorlopig een decision-grade blueprint: een beeld dat goed genoeg is om er een beslissing op te nemen, en eerlijk genoeg om er een offerte op te bouwen. Het vervangt de engineers, de jurist of de architect niet. Het geeft hen één product om het over eens te worden, voor hun losse keuzes optellen tot een product dat niemand zo bedoelde.
In het volgende artikel open ik het dossier van Marek en ontleed ik één scherm: tien beslissingen die je niet ziet als je er alleen naar kijkt, maar die het product maken of breken.
