Agentic AI begint bij je data: lessen van Techorama 2026

In het kort

• De meeste AI-pilots lopen vast omdat ze te klein zijn: kleine schaal, kleine opbrengst, en niemand neemt de verantwoordelijkheid om ze naar productie te brengen.

• Developers hebben de gereedschapskist voor agent-ready data al. CQRS bijvoorbeeld leert je om wat een agent leest los te behandelen van wat hij schrijft.

• De moeilijkste taak van een agent is weten wat je data betekent. Een inventarisatie, classificatie en een semantic layer geven hem die context.

• Nu AI vragen op afroep beantwoordt, moeten conferenties meer bieden dan talks.

Waarom het model maar één onderdeel van het systeem is

De meeste gesprekken op onze stand kwamen uit bij AI. Wat me opviel: het gesprek gaat steeds vaker verder dan het model zelf. We praten veel over wat een large language model kan, maar het praktische werk zit vaak in de software eromheen: de data waar het bij kan, de tools die het kan gebruiken, de rechten die het heeft en de processen die het aansturen.

Daarom werkt AI ook zo goed in softwareontwikkeling. Softwaredata is relatief gestructureerd: code staat in repositories, heeft een consistente syntax en is georganiseerd op een manier waar tools mee overweg kunnen. In veel andere bedrijfscontexten is de data lang niet zo ver. Vaak merk ik dat we eerst de datakwaliteit, de processen eromheen of allebei moeten verbeteren voordat we iets zinnigs met AI kunnen doen.

Een enterprisesysteem heeft meer nodig dan een werkende demo. Validatie, gestructureerde output, foutafhandeling, rechten, auditlogging en securitygrenzen tellen allemaal mee. POC Prison van Luise Freese, een talk waar ik ontzettend van genoot, ging over een bekend probleem: een organisatie wil "iets met AI", mensen gaan experimenteren en dan gebeurt er eigenlijk niets.

Ik heb dit bij minstens drie verschillende klanten gezien. Ze proberen iets met AI op heel kleine schaal: agent-assisted software engineering op losse bestanden, RAG (Retrieval-Augmented Generation) op een kleine database en een fraudedetectie-agent voor tickets met een hoog risico. Omdat de schaal zo klein is, is de opbrengst ook relatief klein. En omdat de opbrengst klein is, neemt niemand de verantwoordelijkheid om ze echt naar productie te brengen. Iemand moet volwassenheid en betere processen introduceren voordat het werk verder kan. Het goede nieuws: organisaties ontdekken wat ervoor nodig is om AI in de praktijk te laten werken. AI-adoptie wordt volwassen.

Developers spreken de taal van data al

Ontwikkeling en data engineering lijken meer op elkaar dan mensen soms denken. Agentic AI maakt de basis van goed databeheer volgens mij alleen maar belangrijker. Daarom wilde ik agentic systemen verbinden met concepten die software- en data-engineers al kennen. Geen nieuwe, magische architectuur nodig.

Domain-Driven Design, bounded contexts, anti-corruption layers, CQRS, materialized views en polyglot persistence: developers kennen deze concepten. Het zijn gewoon andere namen voor ideeën die ertoe doen bij data-optimalisatie. Neem CQRS. Je moet het schrijven van data door agents (commands) los behandelen van het ophalen van data door agents (queries). Het zijn verschillende vraagstukken, en ze bepalen hoe je data opslaat en wanneer je datapijplijnen of zelfs duplicatie nodig hebt. Concepten die zo overlappen, maken het voor developers mogelijk om mee te praten over hoe data georganiseerd, weergegeven en ontsloten moet worden voor verschillende doelen.

Eén onderscheid helpt hierbij. Opslag is bedoeld om data te organiseren voor systemen. Ophalen draait om het organiseren van informatie, zodat intelligentie die kan gebruiken. Die doelen overlappen, maar ze zijn niet hetzelfde.

Opzoeken is iets anders dan actie ondernemen

In mijn talk gebruikte ik een fictief bedrijf, NICEDA Inc., kort voor "Nothing Is Certain Except Data and Access". Het customer success-team krijgt een agent die helpt klanten te begrijpen, risico's te herkennen en goedgekeurde acties uit te voeren. De agent heeft toegang nodig tot SharePoint, Cosmos DB, meerdere SQL-databases en een eigen CMS. In elk systeem hebben begrippen andere namen en andere eigenschappen, dus het is voor een agent lastig om te weten wat de data betekent.

De agent maakt vervolgens risicorapporten en tickets aan voor specifieke klantvertegenwoordigers. Wie zo'n agent ontwikkelt, moet weten in welk systeem die rapporten en tickets terechtkomen en welke bedrijfsregels gelden.

De informatie van een klant opzoeken, samenvatten en een risico signaleren is één soort werk. Een risicorapport aanmaken of wijzigen is een ander soort. De toegangspatronen, securityeisen en gevolgen verschillen. Dat onderscheid moeten we expliciet maken, in plaats van een agent brede toegang te geven en te hopen dat hij zich netjes gedraagt.

Daarom moet een agent ook niet zelf over zijn autorisatie beslissen. Het systeem bepaalt wat de agent mag zien en doen. Nu we steeds meer agentic systemen bouwen, worden goede identiteits- en autorisatiemechanismen essentieel. OAuth 2.1 had er, wat mij betreft, al veel eerder mogen zijn.

Vijf stappen om je data agent-ready te maken

Je hoeft niet te beginnen met alles opnieuw bouwen rondom AI. Begin met begrijpen welke data je al hebt en wat je een agent ermee wilt laten doen.

1. Breng je data in kaart. Weet wat er is en waar het staat, en bepaal welke use cases de agent moet ondersteunen.

2. Classificeer data zodra die het systeem binnenkomt. Classificatie en bruikbare metadata geven de agent context.

3. Scheid ophalen van actie. Maak onderscheid tussen queries en commands, elk met eigen toegangspatronen en securityeisen.

4. Automatiseer verwijderen, archiveren en opschonen. Ontwerp verwijderen vanaf het begin in het systeem, zodat het nooit een sluitpost wordt.

5. Ontsluit data via een semantic layer waar dat zinvol is. Die maakt bedrijfsbegrippen en hun onderlinge relaties bruikbaar voor een agent.

De andere praktijken uit mijn talk bouwen hierop voort: data op betekenis opdelen, waar mogelijk deterministisch testen en de feedbackloop sluiten, zodat het systeem verbetert op basis van wat er in de praktijk gebeurt.

Semantic chunking, voor wie het niet kent, deelt tekst op in kleinere stukken op basis van betekenis en context. Standaard wordt tekst opgeknipt in een vast aantal woorden of tekens. Elk semantisch stuk bevat samenhangende informatie, waardoor AI-systemen relevante content makkelijker begrijpen, ophalen en verwerken. Semantic chunking wordt veel gebruikt bij RAG om zoekresultaten nauwkeuriger en relevanter te maken.

Op Techorama liet Arnoud Boere zien hoe Achmea een semantic layer gebruikt om data bruikbaar te maken voor AI. Wat Achmea doet, ziet er veelbelovend uit. Het is precies het soort werk waar ik vanuit Betabit graag aan zou bijdragen.

Verantwoordelijkheid vraagt kennis

Natuurlijk besloot mijn demo ook mee te doen aan de show. Vlak voor mijn talk paste ik mijn demorepository aan, zodat de antwoorden van de agent als Markdown werden weergegeven. Terwijl ik dat deed, installeerde GitHub Copilot packages met kwetsbaarheden. De build behandelt waarschuwingen als fouten, dus die stopte. Ik werkte de packages bij, wat een update van Aspire in gang zette, en ineens stond ik op het laatste moment te rennen en te vliegen.

De veiligheidsmaatregelen deden hun werk: de build weigerde iets onveiligs op te leveren. Het was stressvol, maar omdat ik nog begreep wat er in mijn repo stond, werd het geen crisis. Sterker nog, ik was er helemaal door opgeladen voor mijn sessie. Verantwoordelijkheid nemen is extreem lastig zonder op zijn minst enige kennis. Agentic orkestratie kan intensiever zijn dan traditionele software-engineering. Je denkt niet per se minder na, omdat een agent een deel van het werk doet.

Hebben developerconferenties nog toekomst?

Die kennis opbouwen vraagt meer dan een snel antwoord van een AI. Dat brengt me bij een van mijn meer controversiële meningen: traditionele conferenties zoals Techorama zijn op de lange termijn misschien niet houdbaar. Er is online zoveel informatie beschikbaar en AI maakt het makkelijker dan ooit om antwoorden te krijgen die passen bij jouw specifieke situatie. Daar kan een talk niet altijd tegenop.

Wat waardevol blijft, is wat je niet kunt opzoeken. Workshops, waar je leert door te doen en feedback krijgt. En gesprekken tussen mensen. Die geven niet altijd direct antwoord op een vraag die je had, en juist daardoor brengen ze blinde vlekken en vooroordelen aan het licht.

Ik hoop dat Techorama blijft bestaan en groeit, want ik vind het geweldig en ga graag nog eens. Ik denk alleen dat conferenties zich steeds moeten blijven afvragen wat hen waardevol maakt. Het antwoord kan niet simpelweg zijn: "we hebben veel talks".

AI wordt weer een kwestie van engineering

Als ik Techorama in één gedachte moet samenvatten: AI gaat verder dan het model en wordt weer een kwestie van engineering, en onze engineeringpraktijken moeten bijblijven. De slotkeynote van Paul Smit, eigenlijk een stand-upvoorstelling over psychologie, had een passende boodschap: vertrouw je menselijk brein niet, vertrouw AI niet, en wantrouw ze allebei om andere redenen. We moeten er niet van uitgaan dat een van beide automatisch betrouwbaar is.

De kernvraag wordt dus: wat heeft dit systeem nodig om bruikbaar en veilig te zijn? Het model doet er natuurlijk toe, maar het is maar één onderdeel van het systeem. En dat systeem begint bij je data.

Wil je weten hoe agent-ready jouw data is? Laten we bespreken waar je organisatie staat en welke stappen je agents van het lab naar productie brengen.