We gaven onze database een chatvenster. Sindsdien heb ik geen developer meer om een rapport gevraagd.

Het duurste onderdeel van productanalytics was nooit de tooling. Het was een developer storen, elke keer dat ik een getal nodig had.

Op een dinsdag in augustus typte ik een vraag in een nieuw chatvenster in ons interne admin-dashboard: hoeveel gebruikers die de studiomodus probeerden, hebben uiteindelijk een item opgeslagen? De agent bedacht wat hij moest queryen, keek hoe onze data in elkaar zit en draaide zijn read-only queries. Twintig seconden later had ik het antwoord als grafiek, plus een paar voorgestelde vervolgvragen. Voor dat rapport werd geen enkele developer gestoord.

Wat er veranderde in onze dagelijkse workflow

Ik ben productmanager bij LI Solutions. We runnen Shop Minis, vier AI-shopping-apps in Shopify's Shop app, en dat chatvenster gaf ons een data-analist die dag en nacht paraat staat.

Voordat we hem bouwden, betekende elk getal een developer vragen: zo'n twintig minuten contextwisseling aan zijn kant, een uur tot een dag wachten aan de mijne. Die frictie leerde me om geen kleine vragen meer te stellen. Ik vroeg alleen om data als ik een groot voorstel te verdedigen had.

Nu stel ik misschien tien keer zoveel vragen als in het voorjaar. Sommige lopen dood en zijn tegen lunchtijd vergeten. Een paar werden echte roadmap-items die ik in een kwartaalrapport nooit had gevonden. De maandelijkse modelrekening voor dat alles is lunchgeld.

Veiligheid was de eerste zorg toen we een agent aan een productiedatabase koppelden. De agent kan fysiek niets veranderen: zijn toegang is read-only en elke query wordt gecontroleerd voordat hij draait. Het ergste wat een slechte query kan doen is een fout of traag antwoord teruggeven. Een fout antwoord kan ik opvangen. Een verwijderde tabel niet.

De agent onze businessregels geven

Generieke text-to-SQL-tools adverteren met 85%+ nauwkeurigheid op benchmarks en zakken naar 10-20% op echte bedrijfsdata. Ze falen omdat de businesscontext ontbreekt: ze weten niet wat er in jouw product toe doet of hoe jij succes definieert.

Wij gaven onze agent die context wel. Hij kent het volledige datamodel, de eventfunnel in canonieke volgorde en de businessregels. Opslaan als favoriet is de echte conversie, en save rates wegen zwaarder dan ruwe aantallen. Die kennis leeft bij de code, dus als developers aanpassen wat de apps registreren, schuift het beeld van de agent mee met de werkelijkheid, eigenaardigheden en randgevallen inbegrepen.

De ML-laag draait vandaag op dezelfde rails. Een getraind model scoort elke generatie op de kans dat hij eindigt in een save en laat zien welke factoren die kans omhoog of omlaag duwen. Daarnaast draaien de projecties: geschat dagelijks gebruik en AI-kosten per app, weken vooruit, zodat capaciteits- en budgetplanning begint bij een voorspellingscurve in plaats van een gok.

De voorspellingen landen in hetzelfde chatgesprek. Ik vraag welke modus volgens het model meer saves oplevert, en het antwoord komt onderbouwd met zijn cijfers in plaats van een onderbuikgevoel. En de ML-kant blijft strikt additief. Valt hij ooit uit, dan merken de apps die onze gebruikers aanraken er niets van.

De modellen op onze eigen hardware draaien

Het belangrijkste aan deze architectuur is waar hij leeft. De ML-modellen kunnen volledig op je eigen hardware draaien, en lokale LLM's zijn inmiddels capabel genoeg voor analysewerk. De hele analist, agent en modellen samen, kan dus binnen je eigen infrastructuur zitten, en gevoelige data verlaat die nooit.

Voor ons is dit praktijk, geen theorie. We bouwen healthcareproducten onder strenge NDA's waar gebruikspatronen naar een externe API sturen simpelweg geen optie is. De modellen lokaal draaien is hoe die projecten überhaupt analytics krijgen. Dezelfde logica geldt voor fintech en elk product onder serieuze dataregels.

Lokale modellen hebben ook minder dramatische voordelen. Je weet wat je hardware per maand kost, dus een prijswijziging van een leverancier kan het analyticsbudget niet opblazen. Een externe storing kan je dashboard niet offline halen. En verschijnt er een beter open model, dan upgrade je op je eigen tempo. De analytics-infrastructuur is van jou.

Een eigen analist hebben veranderde hoe ik met mijn eigen nieuwsgierigheid omga. Ik kijk niet meer eerst hoe druk het engineeringteam oogt voordat ik een vraag stel. Ik verken een vermoeden meteen en laat het los als de data nee zegt.

Heb je een productdatabase en een intern dashboard, dan is dit een feature van één tot twee weken. Geef de agent read-only toegang. Schrijf je stilzwijgende kennis op waar hij die kan zien, en bewaar die naast de code. Iemand moet wel een paar dagen besteden aan je businessregels in woorden vertalen. In ons geval was ik dat.