AI bouwen is eenvoudig. AI goed bouwen is dat niet.
Iedere CTO die een proof-of-concept naar productie heeft gebracht, weet hoe groot het verschil is tussen succes in een testomgeving en succes in de echte wereld. Een model kan perfect draaien op schone data, maar pas wanneer echte klanten, echte variatie en echte randgevallen langskomen, zie je waar de oplossing barsten vertoont.
In onze eerste aflevering van de Blinqx Tech TalQX-podcast sprak ik met Martijn (Product Owner AI) en Rasyan (AI Engineer) precies over die spanning: de belofte van AI versus de verantwoordelijkheid om het veilig, uitlegbaar en schaalbaar te maken. In deze blog kijk ik terug op dat gesprek. En wat het ons leert over hoe je AI in B2B SaaS “zonder brokken” bouwt.
De meeste problemen ontstaan niet in de techniek
Ik opende de aflevering met een simpele vraag aan Martijn: Komen AI-problemen vaker door techniek of door mensen?
Hij hoefde niet te twijfelen: door mensen.
De techniek is vandaag volwassen genoeg. Wat meestal ontbreekt, is structuur. Wie is verantwoordelijk voor het gedrag van het model? Hoe wordt een prompt beheerd? Welke afspraken voorkomen dat iemand het systeem per ongeluk onveilig maakt?
Het echte risico zit bijna nooit in de architectuur, maar in snelheid zonder governance. Dat zie ik ook breder in de markt: teams willen vooruit, maar bouwen ondertussen gaten waar ze later zelf in vallen.
AI werkt pas echt zodra klanten fouten maken
Rasyan kreeg vervolgens de vraag of je beter lang moet testen, of juist vroeg live moet gaan. Hij ging vol voor ‘vroeg live gaan’:
“Als klanten beginnen te klagen, dát is het moment dat je product echt begint.”
Niet omdat fouten wenselijk zijn, maar omdat de wereld in productie onvergelijkbaar is met je testomgeving. Die is schoon, logisch en voorspelbaar. In productie krijg je te maken met variatie, afwijkende formuleringen, onvolledige dossiers en patronen die je nooit volledig kunt simuleren.
Rasyan verwoordde het treffend: “Je bent in je testomgeving op 5%. De rest leer je pas in productie.”
Succesvolle AI-producten ontstaan dan ook niet door één grote release, maar door continue observatie, analyse en bijsturing. Het echte werk begint zodra je gebruikers feedback geven, thumbs-down klikken of foutief gedrag signaleren. Daar moet je op voorbereid zijn, met monitoring, fallbacks, traceability en processen die verbetering net zo normaal maken als releasen.
Waarom wij één centrale AI-infrastructuur kozen
Omdat AI zich gedraagt als een levend systeem, kun je het niet in losse eilandjes organiseren. Daarom bouwden we Qore/AI: het centrale fundament onder alle AI-ontwikkeling binnen Blinqx. Martijn omschreef het in de podcast als een stroomnetwerk.
“Steek je de stekker erin, dan kun je AI gebruiken.”
Met één gedeelde AI-backbone hoeven teams niet telkens opnieuw prompts, beveiliging, logging of evaluatieprocessen uit te vinden. Dat zit al ingebakken. Daardoor kunnen ze zich richten op hun domein, hun product en hun klant. Zonder dat ieder team zijn eigen risico’s creëert.
Het effect is merkbaar: innovaties ontstaan sneller én zijn veel eenvoudiger door te trekken naar andere producten. Wat werkt in Legal, werkt vaak ook in Finance of HR. Een bouwblok voor verzekeringen past met minimale aanpassing in accountancy of juridische workflows. Qore/AI tilt zo niet één product op, maar het hele portfolio.
Transparantie is de basis voor vertrouwen
In sectoren als verzekeringen, accountancy en legal is de vraag naar AI nooit: werkt het?
De vraag is: waarom werkt het zo? Klanten willen weten waarom een systeem een bepaald antwoord geeft, wat er met hun data gebeurt en hoe het omgaat met uitzonderingen. Martijn zei het zelf: “Je moet als product owner kunnen verklaren waarom AI zo reageert.”
Dat gaat niet om het uitleggen van interne modelmechanismen, maar om begrijpelijkheid: welke stappen het systeem neemt, wanneer het twijfelt, wanneer het overschakelt op andere logica, en wanneer een mens moet valideren. Zonder die duidelijkheid krijgt AI geen plek in compliance-gedreven omgevingen. Transparantie is geen nice-to-have. Het is een randvoorwaarde.
Experimenteren moet, maar wel binnen veilige grenzen
Binnen Blinqx stimuleren we teams om zelf te experimenteren. Met centraal beschikbare tools bouwen R&D teams in elke sector kleine AI experimenten die direct aansluiten op de uitdagingen van de gebruiker. Dat levert ideeën op die wij centraal niet kunnen bedenken.
Maar experiment en productie zijn twee verschillende werelden. Daarom hebben we een duidelijk overgangsmoment: zodra een experiment waardevol blijkt, kijken we of we het kunnen overbrengen naar Qore/AI. Daar wordt het robuust, testbaar en veilig gemaakt. En schaalbaar voor uitrol naar andere sectoren.
Dat is de balans die werkt: vrijheid om snel te leren, gecombineerd met bescherming zodra het serieus wordt.
Begin klein, maar bouw voor groots succes
Aan het einde van de aflevering kwamen we uit op de vraag waar organisaties moeten beginnen. De antwoorden van Martijn en Rasyan lagen opvallend dicht bij elkaar:
Begin klein. Maar doe het goed.
Niet met “AI in ons hele platform”, maar met één taak. Eén concreet probleem. En zorg dat je vanaf dag één meet, uitlegbaarheid inbouwt en model-agnostisch werkt. Je pipeline van vandaag is niet de pipeline van over twee jaar. En dat moet je accepteren in je ontwerp.
Het is veel eenvoudiger om iets goeds op te bouwen dan iets onveiligs achteraf te repareren. De rode draad van de aflevering is helder: AI faalt zelden door techniek. Wel door een ondoordachte organisatie.
Veelgestelde vragen
Omdat teams de complexiteit onderschatten en geen duidelijk framework hebben om op terug te vallen. Een model werkt prima op gestructureerde testdata, maar valt door de mand zodra echte variatie, ruis en randgevallen binnenkomen. Zonder monitoring, fallback-mechanismen en eigenaarschap wordt dat pas zichtbaar wanneer het naar productie gaat.
Je kunt productiegedrag niet simuleren. Je kunt daarentegen wel veilig vroeg live gaan, mits de basis klopt: logging, metrics, guardrails, evaluatiepaden en het vermogen om snel bij te sturen. Zonder die infrastructuur werkt “lang testen” vooral als uitstel van onvermijdelijke problemen.
Omdat AI zich gedraagt als een systeem, niet als een feature. Als ieder productteam eigen prompts, validatieregels en beveiliging bouwt, krijg je versnippering, inconsistent gedrag en compliance-risico’s. Een gedeeld fundament zoals Qore/AI zorgt voor herhaalbaarheid, traceability en schaal.
Begin klein met één concrete taak waar je de volledige lifecycle kunt oefenen: monitoring, evaluatie, transparantie, fallback en updates. Als dat werkt, ga dan pas groter werken. De manier waarop je begint, bepaalt of je later makkelijk kunt opschalen.
