Data-analyse in gewone taal
Vraag je dashboard in gewone zinnen wat je wil weten
Stel je voor: je opent een chatvenster en typt "welke klanten hebben in maart minder besteld dan gemiddeld?" Vijf seconden later zie je een lijst met namen, bedragen en percentages. Geen SQL, geen dashboard, geen Excel-export. In 2026 is dit geen sci-fi meer. Maar tussen "kan het" en "moet je het altijd doen" zit een wereld van nuance. Deze les gaat over die nuance.
De belofte: je database ondervragen in Nederlands
Het idee heet "natural language querying" en het bestaat al jaren, maar pas sinds grote modellen als GPT-5 en Claude 4.7 is het écht bruikbaar. Je geeft de AI je database-schema, stelt een vraag in gewone taal, en hij schrijft de SQL die nodig is — of voert hem zelfs direct uit.
Voor een solo-SaaS-bouwer is dat goud. Je hebt vaak geen tijd voor "even een BI-dashboard bouwen". Je wilt snel antwoord op één losse vraag: "hoeveel maandabonnementen hebben we vorige week?" of "welke klanten logden nooit in?" In Metabase of Power BI is dat een query die je moet schrijven. In een AI-chat is dat typen en wachten.
Drie manieren om dit aan te pakken
De snelste: upload en chat. Je exporteert een CSV uit je database — bijvoorbeeld alle orders van de laatste drie maanden — en sleept hem in Claude of ChatGPT. Je typt je vraag. Het model leest de kolommen, rekent, en geeft antwoord. Voor eenmalige analyses is dit veruit het makkelijkst. Geen koppeling, geen opzet, klaar binnen twee minuten.
De structurele: SQL-generator. Je plakt je database-schema in een prompt ("hier zijn mijn tabellen met velden"), stelt een vraag, en vraagt om de SQL. Je kopieert die query, draait hem zelf in phpMyAdmin of je eigen tool, en ziet het resultaat. Voordeel: je ziet precies wat er gebeurt, en de data verlaat je server niet.
De chic-versie: chat-met-je-dashboard. Tools als Vanna, Julius AI en MotherDuck's AI-mode koppelen zich direct aan je database. Je stelt vragen, zij voeren uit, laten grafieken zien. Voor Postgres, MySQL en SQLite werkt dit in 2026 erg goed. Je moet wel credentials delen — niet altijd gewenst.
Een LLM die "mee-rekent" is geen rekenmachine. Hij is een taalmodel dat gokken welke cijfers waarschijnlijk lijken. Als je Claude een CSV van tienduizend rijen geeft en vraagt "wat was de totale omzet van klant X?" — dan kan hij het juiste antwoord geven, maar hij kan óók een plausibel-klinkend bedrag verzinnen. Het verschil zie je niet. Vraag daarom altijd: "laat de Python- of SQL-code zien die je gebruikt hebt". Zo weet je of hij gerekend heeft, of gehallucineerd.
Wanneer je SQL zelf moet schrijven
AI is krachtig, maar hij is niet je vervanger voor basiskennis. Drie situaties waar je beter zelf typt:
Als getallen écht moeten kloppen. Financiële rapporten, btw-aangifte, commissie-afrekeningen. Hier is één fout er één te veel. Laat de AI eventueel helpen met de structuur, maar verifieer handmatig op een kleine subset. Vertrouw geen bedrag dat je niet hebt gecontroleerd.
Als performance telt. Een AI-gegenereerde query werkt prima op 10.000 rijen en kan je database op 10 miljoen rijen platleggen. AI's kiezen zelden optimaal. Als je query vaker gaat draaien, laat iemand met SQL-ervaring (of jij, na nadenken) hem reviewen op indexen en joins.
Als het gaat om schrijfacties. Selecteren (SELECT) is relatief veilig. Maar zodra een AI een UPDATE of DELETE voorstelt op productie, stop. Altijd. Test op een kopie, of schrijf hem zelf. Een gehallucineerde WHERE-clause kan in één commando alles weggooien.
Een workflow die werkt
Wat zich bewezen heeft voor solo-ondernemers:
Maak één keer een "schema-prompt" voor je AI. Een stuk tekst met al je tabellen, belangrijkste velden, en een korte uitleg wat wat betekent. ("orders.status: 'draft', 'paid', 'cancelled' — 'cancelled' telt niet mee in omzet.") Sla die op. Start elke analyse-sessie met dit schema als context.
Stel dan je vraag in normale taal. Vraag expliciet om de SQL, niet alleen het antwoord. Kijk de query door — vaak zie je in één oogopslag of de joins kloppen.
Draai hem op read-only-credentials. Op de meeste MySQL- en Postgres-servers kun je binnen vijf minuten een gebruiker aanmaken die alleen SELECT mag. Gebruik die. Geen risico op ongeluk schade.
Verifieer op een subset. Draai de query met LIMIT 10, kijk of de rijen kloppen, tel handmatig twee of drie. Pas daarna op de volledige tabel.
Een vuistregel die je kunt lenen van oude BI-mensen: als je een rapport zou aanhouden voor een klant, kan je dan uitleggen hoe je aan elk getal gekomen bent? Zo niet, dan publiceer je het niet. AI-gegenereerde cijfers moeten diezelfde test doorstaan. Begrijp de query voor je het resultaat vertrouwt.
Waar AI echt schittert
Het is niet dat je SQL verleert. AI schittert in het verkennen van data, niet in het harde rapporteren.
"Welke vijf klanten zijn relatief het meest gegroeid afgelopen kwartaal?" Typ die zin, krijg antwoord. Normaal ging dat via een omslachtig rapport bouwen, grafiek maken, sorteren. Nu niet.
"Zie jij iets vreemds in deze data?" is misschien wel de krachtigste vraag. Upload een CSV, vraag hem te kijken naar uitschieters. AI's zijn goed in patronen herkennen die jij over het hoofd ziet. "Drie klanten hebben op exact dezelfde dag opgezegd — mogelijk iets met je dienst die dag?" Dat soort vragen had je zelf niet geformuleerd.
Voor klant-facing dashboards werkt het als tweede laag. Je eigen admin laat een grafiek zien. Je klant heeft een vraag. In plaats van een e-mail: een chat-knop onder de grafiek. "Vraag iets over deze data." De AI kent de context van die specifieke grafiek, beantwoordt de vraag, en jij hoeft niet tussen te komen.
Valkuilen die je moet kennen
Drie dingen zie je gegarandeerd fout gaan als je onbezonnen begint:
Hallucinatie van tabelnamen. Vraag de AI iets over "klanten die meer dan €500 besteden", maar je tabel heet "customers" en het veld "totaal_bedrag". Zonder context gokt de AI namen die plausibel lijken maar niet bestaan. Oplossing: altijd eerst het schema meegeven.
Datumgrenzen. "Afgelopen maand" betekent voor jou misschien "de kalendermaand februari". AI interpreteert dat soms als "30 dagen terug vanaf vandaag". Expliciet zijn. Altijd.
Nullen en lege waardes. AI's vergeten vaak dat NULL in SQL anders werkt dan 0 of lege string. Een query "klanten zonder factuur" mist makkelijk een halve groep. Test op randgevallen voor je conclusies trekt.
Drie dingen om mee te nemen
- Bewaar één schema-prompt, herbruik hem. De eerste keer een schema beschrijven duurt twintig minuten. Daarna plak je hem in elke chat en bespaar je uren.
- Vraag altijd om de SQL, niet alleen het antwoord. Als je het getal niet kunt herleiden, weet je niet of het klopt. Een LLM is geen rekenmachine; hij is een taalmodel dat soms gokt.
- Gebruik read-only-credentials. Verken vrij, maar laat de AI nooit in één commando schrijven of verwijderen op productie. Dat is geen wantrouwen — dat is gezond verstand.
In de volgende les zet je AI aan het werk in wat misschien wel jouw kerntaak is: zelf code schrijven. Claude Code, Copilot, agents in je terminal — wat doen ze in 2026, en wat laten ze toch nog steeds aan jou over?
Tot dan. Rare getallen? Eerst twijfelen, dan geloven.