De verborgen risico's van zelfbouw AI.

Waarom dit artikel bestaat.

In 2024-2026 is AI toegankelijk geworden voor iedereen. Een medewerker met een ChatGPT-abonnement bouwt in een middag een prompt-template voor klantenservice. Een IT-er knutselt een workflow in Make of n8n die klant-e-mails automatisch beantwoordt met een LLM. Een marketing-afdeling zet een interne chatbot op voor kennisvragen. Allemaal werken ze. Allemaal zijn ze gratis of goedkoop. Allemaal voelen ze als vooruitgang.

Tot ze niet meer werken. Of erger: tot ze werken op een manier die kostbaar is. Een hallucinatie die een klant verkeerde informatie geeft. Een prompt die een datalek veroorzaakt. Een AI Act-classificatie die niet is gedocumenteerd en bij audit wordt opgemerkt. Een model-update bij de leverancier die jouw gebouwde systeem ineens anders laat presteren. Een interne bouwer die vertrekt waarna niemand weet hoe het systeem werkt.

Deze risico's zijn niet theoretisch, ze zijn frequent. En ze zijn vermijdbaar. Dit artikel legt ze op tafel, kwantificeert ze waar mogelijk en laat zien hoe een gezonde mix van intern experimenteren en professionele uitvoering het verschil maakt. We zijn niet tegen zelfbouw. We zijn tegen zelfbouw die de grenzen van het verantwoorde oversteekt zonder dat iemand in de organisatie door heeft dat dat is gebeurd.

De ijsberg van AI-complexiteit.

Wat een demo laat zien is 10% van wat AI in productie moet kunnen. De andere 90% zit onder water: beveiliging, compliance, monitoring, onderhoud, documentatie, versiebeheer, foutafhandeling, integratie, schaal, kennisoverdracht. Dat onderdrukte deel bepaalt of een AI-systeem over drie jaar nog steeds betrouwbaar werkt of een tijdbom is geworden.

Waar breekt zelfbouw?

DIY-AI werkt prima in de eerste fase: experimenten, proof-of-concepts, interne tools. De curve breekt op voorspelbare momenten, drie inflectie-punten waar zelfbouw structureel tekortschiet.

Inflectie 1: Klant-facing output.

Zodra AI-output klanten raakt, verandert alles. Een verkeerd antwoord is niet langer intern opgelost met een correctie; het raakt reputatie, contract of aansprakelijkheid. Monitoring, review-processen, fallback-mechanismen en incident-handling worden plots essentieel. Zelfbouw-systemen hebben dit zelden ingericht omdat het in de experimentele fase niet nodig was. De dag dat AI op de klant wordt gericht, moet dit klaar zijn. Anders krijg je de dag daarop het eerste incident.

Inflectie 2: Persoonsgegevens of gereguleerde data.

Een tweede breekpunt is wanneer persoonsgegevens of andere gereguleerde data door AI gaan. AVG (Verordening 2016/679) vereist rechtsgrond, informatieplicht, DPIA, verwerkersovereenkomst. AI Act (Verordening 2024/1689) voegt classificatie, documentatie, logs, training, betrokkene-informatie toe. Sectorale wetgeving (DORA voor finance, MDR voor medisch, NIS2 voor kritieke sectoren) voegt eigen eisen toe. Deze juridische laag is niet iets wat een DIY-bouwer kan improviseren; het vereist specifieke kennis, formele documentatie en doorlopende naleving. Wie dit negeert krijgt niet een technisch probleem maar een juridisch probleem dat veel duurder is.

Inflectie 3: Schaal en strategische afhankelijkheid.

De derde breek ligt bij strategische afhankelijkheid: wanneer een AI-systeem bedrijfsprocessen draagt die mission-critical zijn. Downtime is niet meer een ongemak maar een bedrijfsonderbreking. Fouten zijn niet meer een incident maar een crisis. Onderhoud is niet meer een hobby van een collega maar een SLA. Dit vereist professionele engineering-rigor: tests, staging-omgevingen, incident-procedures, monitoring, documentatie, backup en recovery. Organisaties die hier niet op voorbereid zijn, staan stil bij eerste grote storing. Zelfbouw zonder deze lagen is OK voor experimenten maar niet voor kritische processen.

De gemeenschappelijke deler.

Alle drie inflectie-punten hebben een gemeenschappelijke deler: het moment waarop AI geen hulpmiddel meer is maar infrastructuur. Hulpmiddelen mag elke medewerker zelf bouwen; dat is waardevolle autonomie. Infrastructuur vraagt om governance, professionaliteit en standaarden. De meeste MKB-organisaties maken deze overgang impliciet en te laat. Dit artikel wil die overgang expliciet maken.

Vier scenario's waarin zelfbouw verantwoord is.

Dit artikel is geen pleidooi tegen zelfbouw. Het is een pleidooi tegen zelfbouw op verkeerde plekken. In vier specifieke scenario's is DIY-AI prima.

Scenario 1: Experimenten zonder persoonsgegevens of klant-impact.

Een product-manager die met ChatGPT brainstormt voor feature-ideeen. Een marketeer die AI gebruikt voor content-inspiratie. Een developer die AI vraagt om code-suggesties op eigen project. Allemaal geen probleem: geen persoonsgegevens, geen klant-facing output, geen compliance-verplichtingen. De eigen verantwoordelijkheid en beoordelingsvermogen zijn voldoende waarborg. AI als ideation-partner is gezond gebruik.

Scenario 2: Strikt interne productiviteits-tools met gecontroleerde data.

Een HR-dashboard dat publieke vacature-informatie samenvat. Een sales-tool die openbare bedrijfsinformatie verrijkt (met expliciete bronvermelding en zonder geautomatiseerde besluitvorming). Een intern Q&A-systeem dat alleen documentatie benadert die vrij beschikbaar is. Deze tools hebben lage risico-profielen en kunnen veilig door DIY-bouwers ontwikkeld worden, mits governance-basisprincipes worden nageleefd: documenteer wat het doet, train gebruikers op beperkingen, periodiek review.

Scenario 3: Low-code automation workflows met AI-componenten.

Platforms zoals n8n, Make of Zapier laten toe dat niet-technische medewerkers workflows bouwen met AI-knooppunten. Voor niet-kritische automation (interne notificaties, kleine content-verwerkingen, administratie-ondersteuning) is dit een uitstekend model. Het platform biedt meestal monitoring, logs en versiebeheer. Houd grenzen aan: geen persoonsgegevens richting externe AI zonder VWO, geen klant-facing output zonder menselijke review, geen compliance-gevoelige processen.

Scenario 4: Proof-of-concept voorafgaand aan professionele bouw.

Wanneer je een AI-idee wilt testen voordat je in een professioneel traject investeert, is een DIY-POC vaak de slimste aanpak. Snel, goedkoop, leerrijk. Belangrijk: duidelijk afbakenen dat het een POC is, stakeholder-expectation-management dat dit niet productie-klaar is, en een helder pad van POC naar productieve implementatie (met professionele begeleiding) zodra de case bewezen is. POC's die stilletjes doorgroeien tot kritische infrastructuur zijn een veelvoorkomende val.

De gemeenschappelijke regel.

In alle vier scenario's is het risico-profiel laag: geen persoonsgegevens, geen klant-facing output, geen compliance-verplichtingen, geen mission-critical afhankelijkheid. Zodra een van deze grenzen wordt overschreden, moet de aanpak opschalen. Professionele architectuur, compliance-inrichting, monitoring, documentatie. De transitie van 'mag DIY' naar 'vraagt professioneel' moet expliciet zijn, niet per ongeluk gebeuren.

Wat zelfbouw echt kost over 3-5 jaar.

De aantrekkelijkheid van DIY is de afwezigheid van factuur. Er is geen externe leverancier die elk kwartaal een betaling vraagt. Maar de totale kosten van eigendom over de levensduur van een AI-systeem zijn bij DIY vaak 2 tot 3 keer hoger dan bij professionele bouw. Die kosten zijn verspreid over jaren en onzichtbaar per maand, wat ze moeilijk te rapporteren en bespreken maakt.

Kostencategorie 1: opportuniteit.

De medewerker die AI bouwt doet tijdens die periode ander werk niet. Reken op 20 tot 40 procent productiviteitsverlies van die persoon over bouwperiode van typisch drie tot twaalf maanden. Bij senior medewerker met jaarsalaris van 100.000 euro bruto plus 30 procent werkgeverslasten: 130.000 euro per jaar fulltime-cost. Twintig procent verlies over zes maanden is 13.000 euro verloren productiviteit. Dertig procent over negen maanden is 29.250 euro. Dit verschijnt nergens in een financieel overzicht als 'AI-kosten' maar het is wel degelijk verlies.

Kostencategorie 2: onderhoud en technical debt.

DIY-systemen bouwen technical debt snel op. Zonder documentatie, versiebeheer, tests en review-proces neemt elke wijziging meer tijd dan de vorige. Na een jaar is een kleine aanpassing vaak 3-5x zo arbeidsintensief als in het begin. Reken op onderhoud van 25 tot 40 procent van oorspronkelijke bouwtijd per jaar. Systeem dat 400 uur bouwen kostte eist 100-160 uur onderhoud per jaar. Plus wijzigingen voor veranderende business-vraag, modelupdates, compliance-aanpassingen. Over drie jaar komt cumulatief onderhoud vaak uit op meer dan oorspronkelijke bouw.

Kostencategorie 3: incident- en compliance-kosten.

DIY-systemen hebben significant hogere kans op incidenten. AVG-datalek, verkeerde output aan klant, audit-falen, security-breach. Gemiddelde incident-kosten voor MKB zijn 25.000 tot 150.000 euro direct: onderzoek, herstel, communicatie, eventuele juridische kosten. Indirecte kosten: reputatie, klantverlies, deal-annuleringen. Een AVG-boete kan tot 20 miljoen of 4 procent wereldomzet, een AI Act-boete tot 35 miljoen of 7 procent (voor Art 5-overtredingen) of 15 miljoen of 3 procent (Art 26/50). Kans is laag per incident maar bij DIY over meerdere jaren en systemen wordt cumulatieve kans substantieel.

Kostencategorie 4: kansen-kosten door uitblijvende opschaling.

DIY-systemen die niet professioneel ingericht zijn, kunnen vaak niet meeschalen met de business. Wanneer een use-case zou moeten groeien naar meer gebruikers, andere afdelingen of klantgebruik, moet er meestal herbouwd worden. Die herbouw vertraagt schaalvergroting met maanden en leidt tot kansenverlies. Professioneel gebouwd systeem kan vaak gewoon meeschalen met aanpassingen in configuratie en capaciteit.

Herken je deze rode vlaggen in eigen AI-projecten?

Deze zelftest helpt je huidige zelfgebouwde AI-systemen op risico toetsen. Vink mentaal aan voor elk zelfgebouwd AI-systeem in jouw organisatie. Scoor hieronder.

Van DIY-val naar gecontroleerde aanpak in vier stappen.

Transitie van ongestructureerde zelfbouw naar volwassen AI-inzet hoeft niet dramatisch te zijn. Vier stappen, typisch doorlopen in drie tot zes maanden met externe begeleiding.

Stap 1: Inventarisatie.

Maak een volledige lijst van alle zelfgebouwde AI-oplossingen in de organisatie. Medewerkers-interviews, IT-scan, SaaS-audit. Registreer per item: doel, eigenaar, gebruikte systemen en data, huidige status, vermoedelijke gebruikers. Dit is vaak confronterend; organisaties ontdekken meestal 30 tot 70 procent meer AI-gebruik dan directie dacht.

Stap 2: Risico-classificatie.

Per systeem risico-klasse bepalen: Artikel 5 verboden (stop direct), high-risk Annex I/III (professionele inrichting vereist), transparantie-eis Artikel 50, of minimal-risk. Onderbouwing schriftelijk vastleggen conform Artikel 6 lid 4 AI Act. Dit sluit aan bij onze risicoclassificatie-pagina.

Stap 3: Besluit per systeem.

Drie opties per systeem. Eerste: doorgaan met kleine aanpassingen (voor minimal-risk systemen met lage gebruikers-impact). Tweede: professioneel laten herbouwen (voor high-risk of mission-critical systemen met substantiele risico's). Derde: uitfaseren (voor systemen die te risicovol zijn om door te laten lopen of die weinig waarde toevoegen). Prioriteit op basis van risico-klasse en gebruiks-impact.

Stap 4: Governance en capability.

Inricht om toekomstige zelfbouw niet opnieuw in de val te laten lopen. AI-beleid met duidelijke kader: welke typen AI mag intern (experimenten, low-risk workflows), welke vragen professionele inrichting (klant-facing, persoonsgegevens, compliance-gevoelig). Training voor medewerkers zodat ze de grenzen kennen. Governance-proces voor nieuwe AI-initiatieven: iemand toetst voordat het ad-hoc gestart wordt.

Het belang van begeleiding bij transitie.

Deze transitie is goed zelf uit te voeren mits met externe begeleiding. Externe partij brengt onafhankelijk oordeel (interne bouwers zijn soms defensief over eigen werk), compliance-expertise, professionele inrichtings-ervaring. Interne team brengt context, kennis van organisatie, uitvoerings-capaciteit. Typisch traject drie tot zes maanden voor MKB; zonder begeleiding vaak 12 tot 24 maanden of onvolledig.