Garbage in garbage out: wat het is en hoe je het voorkomt

Je MKB-organisatie heeft waarschijnlijk meerdere systemen die dagelijks gegevens uitwisselen: een webshop, CRM, boekhouding, planning en misschien een AI-toepassing. Op papier werkt elke applicatie correct. Toch verschillen klantstatussen per afdeling, ontbreken identificerende gegevens en verschijnen in rapportages cijfers die niemand herkent.

Dat lijkt eerst op een slecht model of een vervuilde dataset. Vaak zit de echte oorzaak ergens anders. Systemen hanteren verschillende definities, koppelingen zetten waarden verkeerd om en niemand heeft formeel eigenaarschap over de kwaliteitsregels. Dat is de praktische betekenis van garbage in, garbage out: betrouwbare verwerking kan onbetrouwbare invoer niet vanzelf herstellen.

Een organisatie kan een AI-project starten om klachten automatisch te classificeren. De eerste resultaten vallen tegen. Het team controleert het model, verandert de instructies en zoekt naar een betere trainingsset. Pas later blijkt dat klachten uit de webshop, het CRM en het callcentersysteem verschillende categorieën gebruiken. Sommige records missen een klant-ID, terwijl statussen als “open”, “in behandeling” en “opgelost” per systeem iets anders betekenen.

De dataset is dan niet noodzakelijk waardeloos. Het probleem zit in de gegevensketen. Een koppeling kan technisch succesvol zijn terwijl de betekenis van een veld onderweg verandert. Een API kan een geldige waarde afleveren die voor de ontvangende applicatie toch onbruikbaar is. Zonder eigenaar voor definities en controles verspreidt een lokale afwijking zich naar rapportages, workflows en modellen.

Maak bij een incident eerst onderscheid tussen drie lagen:

• Technisch: een veld wordt afgekapt, een datum wordt verkeerd geïnterpreteerd of een import slaat lege waarden over.
• Organisatorisch: medewerkers voeren gegevens verschillend in of een proces laat ruimte voor meerdere werkwijzen.
• Governance: niemand bepaalt wat “actieve klant”, “omzet” of “afgeronde klacht” precies betekent.

Die indeling voorkomt dat je uitsluitend naar de database kijkt. De Nederlandse overheid stelt in het Algoritmekader voor datakwaliteit dat de kwaliteit van inputdata bepalend is voor de uitkomsten van een algoritme. Daarbij horen onder meer juistheid, compleetheid, validiteit, consistentie, actualiteit, plausibiliteit en traceerbaarheid.

Automatisering maakt processen sneller, maar ook minder vergevingsgezind. Een medewerker kan een vreemde waarde herkennen, een geautomatiseerde flow voert haar vaak gewoon door. Een ontbrekend kenmerk kan een voorspelling beïnvloeden, terwijl een onduidelijke definitie ervoor zorgt dat twee afdelingen verschillende cijfers rapporteren.

De urgentie groeit bovendien doordat AI snel onderdeel wordt van bedrijfsprocessen. In 2025 gebruikte 33% van de Nederlandse bedrijven één of meer AI-technologieën, tegenover 23% in 2024, volgens het CBS-overzicht over digitalisering en kenniseconomie. Naarmate meer organisaties AI inzetten, wordt datakwaliteit geen apart IT-project meer, maar een voorwaarde voor betrouwbare dagelijkse operatie.

Een kassa rekent een verkeerd bedrag probleemloos mee. Voer je bij een bestaand artikelnummer een foutieve prijs in, dan klopt de berekening technisch, maar niet het resultaat. Dat is de kern van garbage in, garbage out, vaak afgekort tot GIGO: een systeem kan geen betrouwbare uitvoer leveren wanneer de invoer onjuist, onvolledig, verouderd of tegenstrijdig is.

Software controleert meestal wel of een waarde het juiste formaat heeft. Een klant-ID kan bijvoorbeeld uit cijfers bestaan en toch naar de verkeerde persoon verwijzen. De toepassing mist zonder aanvullende regels de context om te bepalen of de invoer overeenkomt met de werkelijkheid.

GIGO komt uit de informatica, maar hetzelfde principe geldt voor rapportages, AI-modellen en integraties. Een automatische correctie kan fouten herstellen, maar alleen als die correctie bewust is ontworpen, getest en gecontroleerd. Anders verplaatst het probleem zich naar een later proces.

Fouten kunnen ontstaan voordat een analist of model de gegevens gebruikt. Het CBS onderscheidt onder meer inleesfouten, dekkingsfouten, meetfouten en verwerkingsfouten. Een bestand kan dus al tijdens het importeren veranderen of informatie kunnen missen, zoals beschreven in de kwaliteitsrichtlijnen van het CBS.

De tabel laat zien waarom de bottleneck in MKB-projecten vaak tussen systemen ligt. Een veld kan technisch geldig zijn, terwijl de definitie, herkomst of koppeling niet klopt. Daardoor ontstaat GIGO niet alleen door slechte brondata, maar ook door onduidelijke afspraken over betekenis en eigenaarschap.

GIGO betekent niet dat iedere afwijking eerst moet verdwijnen. Ook hoogwaardige databronnen bevatten fouten. Het CBS beschrijft dat register- en enquêtegegevens niet perfect zijn en gebruikt editing en modelmatige correctie om fouten op te sporen, te verbeteren of achteraf te schatten.

De werkbare vraag luidt daarom: kennen we de foutmarges, controleren we kritieke waarden en weten we wat een afwijking betekent? Voor een MKB-team begint dat bij gegevens die direct invloed hebben op geldstromen, klanten, compliance of besluiten. Leg per kritieke dataset vast welke controles gelden, wie afwijkingen beoordeelt en wanneer een record niet mag doorstromen.

De meeste GIGO-problemen ontstaan niet doordat één database volledig vervuild is. Ze ontstaan doordat systemen dezelfde gegevens anders opslaan, benoemen of interpreteren. Een legacy-systeem kan bijvoorbeeld een datum zonder tijdzone doorgeven. Intern lijkt die datum consistent, maar bij het koppelen van bestellingen, betalingen en klantcontacten kan de volgorde van gebeurtenissen verkeerd worden weergegeven.

Dat soort fouten blijft lang verborgen omdat iedere applicatie afzonderlijk logisch lijkt te werken. De bron levert een waarde, de API accepteert haar en de ontvangende applicatie slaat haar op. Pas wanneer iemand een rapportage combineert of een workflow een beslissing laat nemen, wordt zichtbaar dat de systemen niet hetzelfde bedoelden.

Stel dat marketing een klant “actief” noemt zodra een offerte is verstuurd. Sales gebruikt dezelfde status pas wanneer een contract is ondertekend. De API geeft in beide gevallen een technisch geldige waarde door. Toch ontstaat een fout zodra management de waarde gebruikt voor omzetvoorspelling of capaciteitsplanning.

Let daarom bij elke koppeling op meer dan de naam en het datatype. Leg ook vast:

• Definitie: wat betekent het veld in het bedrijfsproces?
• Bron: welk systeem bepaalt de waarde?
• Eigenaar: wie mag de regel wijzigen?
• Transformatie: wordt de waarde omgerekend, afgekapt of samengevoegd?
• Validatie: wanneer wordt gecontroleerd of de waarde klopt?
• Logging: hoe zie je welke wijziging de afwijking veroorzaakte?

Bij een migratie kunnen ook identifiers veranderen. Zonder stabiele mapping wordt één klant een nieuwe klant, of worden meerdere klanten aan hetzelfde record gekoppeld. Eenheden leveren een vergelijkbaar risico op. Een gewicht, bedrag of levertijd kan technisch geldig blijven terwijl de ontvangende applicatie een andere eenheid verwacht.

Een bruikbare analyse loopt van bron tot beslissing. Breng eerst de gegevensstroom in kaart, inclusief handmatige invoer, exports, middleware, API's en rapportagelagen. Zoek daarna naar het eerste punt waarop een waarde onduidelijk, incompleet of anders geïnterpreteerd wordt.

Praktische regel: behandel iedere koppeling als een contract tussen systemen. Beschrijf niet alleen welke velden worden uitgewisseld, maar ook welke betekenis, toegestane waarden en foutafhandeling daarbij horen.

Bekijk voor een concreet beeld van zo'n aanpak hoe MG Software systeemintegraties bouwt voor klanten.

Een technische walkthrough kan helpen om de stroom begrijpelijk te maken. Gebruik de video hieronder als aanvulling op je eigen systeemtekening.

Een fout in een spreadsheet blijft misschien beperkt tot één rapportage. Een fout in een geautomatiseerde keten kan verder reizen. Een CRM dat dubbele contacten niet herkent, bouwt bijvoorbeeld gefragmenteerde klantprofielen op. Een marketingflow ziet dan geen compleet beeld van eerdere gesprekken, terwijl een accountmanager juist meerdere dossiers voor dezelfde klant kan aantreffen.

Rapportages krijgen daardoor een schijn van precisie. Een dashboard kan cijfers exact tonen zonder dat de onderliggende definities kloppen. Als de ene afdeling omzet meet op factuurdatum en de andere op betaaldatum, levert een optelsom geen neutraal bedrijfsbeeld op. Het getal is berekend, maar de vraag erachter is niet eenduidig.

Een AI-model leert of gebruikt patronen in de gegevens die het ontvangt. Ontbrekende velden, historische voorkeuren of ongelijke vertegenwoordiging van groepen kunnen daardoor zichtbaar worden in de uitkomst. Het model “begrijpt” niet vanzelf dat een ontbrekende waarde een administratieve fout was, of dat een bepaalde subgroep in de bron nauwelijks voorkomt.

Het Nederlandse Algoritmekader koppelt inputkwaliteit rechtstreeks aan de uitkomst van algoritmen. Het noemt naast technische kenmerken ook de noodzaak om vooraf functionele eisen vast te leggen en representativiteit van doelgroepen en subgroepen te controleren. Voor een MKB-team betekent dat: test niet alleen of een model technisch antwoord geeft, maar controleer ook of de gebruikte gegevens geschikt zijn voor het beoogde besluit.

Een RPA-flow die facturen verwerkt, volgt ingestelde regels. Als een leverancier-ID ontbreekt of een bedrag op de verkeerde manier wordt aangeleverd, kan de flow de fout doorzetten naar de administratie. Een medewerker ontdekt de afwijking misschien tijdens controle, maar die controle is minder effectief wanneer niemand weet welke waarden verdacht zijn.

Leg daarom vast welke situaties een proces mag automatiseren en wanneer menselijke beoordeling nodig blijft. Denk aan ontbrekende verplichte velden, afwijkende statussen en records die niet aan een referentielijst kunnen worden gekoppeld. Voor AI-toepassingen is ook een duidelijke grens nodig tussen assistentie en zelfstandig handelen.

Meer achtergrond over onbetrouwbare AI-uitvoer en controles vind je in de kennisbank over AI-hallucinatie. De kern blijft eenvoudig: een vloeiende tekst, een strak dashboard of een succesvolle workflow is geen bewijs dat de invoer betrouwbaar was.

De Nederlandse overheid laat zien dat brondata directe operationele gevolgen kan hebben. Bij een steekproef van 30 gemeenten op de Basisregistratie Personen vond de Rijksdienst voor Identiteitsgegevens in 22 gemeenten afwijkingen op meer dan 15% van de gecontroleerde persoonslijsten, zoals beschreven door iBestuur over de controle van gemeenten.

De oorzaken waren niet beperkt tot één verkeerd ingevoerd persoonsgegeven. Genoemd werden onder meer het ontbreken van een tijdig continuïteitsplan, kennisverlies door het vertrek van ervaren medewerkers, openstaande vacatures en onvoldoende opleidingstijd door personeelstekort. Daarmee wordt zichtbaar dat GIGO niet alleen een dataprobleem is. Mensen, processen en verantwoordelijkheden bepalen mede of fouten worden ontdekt en hersteld.

Denk aan een registratie die door meerdere gemeentelijke of landelijke systemen wordt gebruikt. Een fout in de bron kan een koppeling laten mislukken, een controlemechanisme op het verkeerde veld laten werken of herstelwerk veroorzaken bij een andere organisatie. De ontvangende applicatie maakt de fout niet noodzakelijk zelf. Zij gebruikt simpelweg gegevens waarvan de kwaliteit niet voldoende is vastgesteld.

Voor MKB-organisaties werkt dit hetzelfde, ook al zijn de systemen kleiner. Een adresveld kan in het ene systeem een vrije tekst zijn en in het andere een combinatie van straat, huisnummer en postcode. Een veld met “woonplaats” kan bovendien een plaatsnaam bevatten, terwijl een ander systeem een interne regiocode verwacht. Beide waarden zien er geldig uit, maar ze zijn niet uitwisselbaar zonder duidelijke mapping.

De belangrijkste les is dat een kwaliteitsregel altijd een eigenaar nodig heeft. Iemand moet kunnen bepalen welke definitie geldt, welke afwijking acceptabel is en wie een fout corrigeert. Zonder die afspraak blijft iedere afdeling haar eigen lokale oplossing gebruiken.

De overheid heeft daarvoor het Meldpunt Fouten in Overheidsregistraties ingericht. Burgers, bedrijven en organisaties nemen eerst contact op met de verantwoordelijke organisatie. Als correctie daar niet lukt, helpt het meldpunt bij het vinden van de juiste route. Dat proces onderstreept een bredere regel: data moet niet alleen gebruikt, maar ook herstelbaar georganiseerd worden.

Een MKB-team ziet datakwaliteit pas echt verbeteren wanneer controles aansluiten op de gegevensstromen die bedrijfsprocessen sturen. Begin daarom bij klantidentificatie, bedragen, statussen, adressen en gegevens die een automatische beslissing beïnvloeden. Breng per stroom eerst de bron, koppeling, definitie en verantwoordelijke in beeld. Daar zit in Nederlandse maatwerkprojecten vaak de bottleneck, niet in één losse dataset.

Bronvalidatie voorkomt dat onbruikbare waarden het kernsysteem bereiken. Controleer bij iedere ingang het formaat, verplichte velden, toegestane waarden en relaties met referentiedata. Een postcode kan syntactisch geldig zijn en toch niet passen bij het opgegeven land. Een klant-ID kan correct zijn opgebouwd, maar ontbreken in het bronsysteem.

Controleer op meerdere momenten. Een importcontrole vangt fouten aan de poort af, een transformatiecontrole bewaakt wijzigingen onderweg en een controle na het laden bevestigt dat records niet zijn weggevallen. Gebruik voor correcties een vast proces: leg vast welke waarde geldt, wie mag herstellen en hoe de wijziging wordt geregistreerd.

Een bruikbare set kwaliteitsdimensies:

• Juistheid: komt de waarde overeen met de werkelijkheid?
• Compleetheid: zijn noodzakelijke velden aanwezig?
• Validiteit: voldoet de waarde aan afgesproken regels?
• Consistentie: gebruiken systemen dezelfde betekenis en codering?
• Actualiteit: is de waarde recent genoeg voor het proces?
• Traceerbaarheid: kun je de herkomst en wijzigingen reconstrueren?

Een dashboard toont meer dan afgekeurde records. Meet ook trends en patronen. Krijgt een koppeling plotseling meer lege klant-ID's? Neemt het aantal onbekende statussen toe? Verschijnt een bronbestand met een andere kolomstructuur? Zulke signalen wijzen vaak op een gewijzigde mapping of definitie.

Stel per kwaliteitsregel een drempelwaarde en eigenaar vast. Leg vast wie een melding onderzoekt, wie een bronleverancier aanspreekt en wanneer een workflow tijdelijk stopt. Logging moet minimaal bron, verwerking, wijziging en foutmelding kunnen reconstrueren. Zonder die informatie begint ieder incident opnieuw bij giswerk.

Ook een klein team kan datagovernance toepassen. Wijs een datasteward aan voor definities en metingen, een technisch eigenaar voor koppelingen en een proceseigenaar voor de zakelijke betekenis. Die rollen mogen bij dezelfde persoon liggen, zolang duidelijk blijft wie welke beslissing neemt.

Neem edge cases op in softwaretests. Test ontbrekende waarden, dubbele identifiers, onverwachte tekens, gewijzigde statussen en een vertraagde API. Documenteer datacontracten en wijzigingsprocedures, zodat een API-aanpassing niet ongemerkt een rapportage breekt.

Een praktische toelichting op data-engineering laat zien hoe controles aansluiten op pipelines, transformaties en onderhoud. Organisaties kunnen deze maatregelen zelf bouwen of laten implementeren binnen maatwerksoftware, migratie of integratie.

Datakwaliteit is geen eenmalige schoonmaakactie. Je kunt een database opschonen en de volgende dag opnieuw duplicaten creëren wanneer een koppeling, invoerformulier of importproces dezelfde fout blijft produceren. Richt je daarom op de bron van de afwijking én op de manier waarop je controleert of de oplossing blijft werken.

Start met een beperkte datascan van de drie bronnen die het belangrijkst zijn voor je klantproces, financiële rapportage of automatisering. Breng per bron in kaart welke velden worden gebruikt, wie eigenaar is, hoe gegevens binnenkomen en welke systemen ze verder verwerken.

Kies vervolgens een kleine set kritieke kwaliteitsregels. Denk aan een unieke klant-ID, een verplichte status, een geldige koppeling tussen factuur en klant, of een datum die in alle systemen dezelfde betekenis heeft. Maak per regel zichtbaar hoeveel records eraan voldoen en wat er gebeurt wanneer een record wordt afgekeurd.

Wijs een datasteward aan en plan vaste kwaliteitsreviews in het teamoverleg. Gebruik de PDCA-cyclus:

1. Plan: bepaal de belangrijkste datarisico's en kwaliteitsregels.
2. Do: bouw controles in formulieren, API's en verwerkingsstappen.
3. Check: volg afwijkingen via logging en dashboards.
4. Act: herstel de oorzaak, pas regels aan en documenteer de wijziging.

Integreer controles waar mogelijk in de CI/CD-pipeline. Nieuwe code moet niet alleen functioneel werken, maar ook aantonen dat datadefinities, mappings en foutafhandeling intact blijven. Plan bij legacy-modernisering een gefaseerde migratie met een audit, duidelijke mapping en een mogelijkheid om tijdelijk parallel te controleren.

Maak voor de komende 90 dagen een overzicht met concrete mijlpalen. Eerst inventariseer je bronnen en definities. Daarna pak je één kritieke koppeling aan, richt je logging in en bespreek je de eerste afwijkingen met de betrokken proceseigenaren. In de laatste fase leg je de werkwijze vast voor nieuwe leveranciers, releases en datastromen.

Bespreek ook datakwaliteit-SLA's met leveranciers. Spreek af welke velden verplicht zijn, hoe wijzigingen worden aangekondigd, welke foutmeldingen beschikbaar zijn en wie incidenten opvolgt. Zo voorkom je dat het team iedere afwijking ad hoc moet oplossen.

Een bruikbare kwaliteitsaanpak maakt afwijkingen zichtbaar voordat een klant, medewerker of bestuurder de gevolgen ervan merkt.

De evaluatie van het Meldpunt Fouten in Overheidsregistraties laat zien waarom herstelbaarheid belangrijk is. In 2023 was bij ongeveer 40% van de meldingen daadwerkelijk sprake van een fout in een overheidsregistratie. Voor jouw organisatie betekent dat: richt niet alleen preventie in, maar ook een duidelijke route om fouten te melden, te onderzoeken en duurzaam te corrigeren.

MG Software bouwt maatwerkapplicaties, API-koppelingen, datamigraties en AI-integraties met aandacht voor validatie, logging en onderhoud van de volledige gegevensketen. Bespreek jouw datakwaliteits- of integratievraag met MG Software en zet de eerste stap naar betrouwbare automatisering zonder verborgen GIGO-risico's.