Van chatvenster naar agents in het proces
De eerste golf AI in bedrijfssoftware was een chatvenster naast de applicatie. Klanten verwachten nu dat de software zelf werk afhandelt: een agent haalt gegevens op, neemt een beslissing binnen vastgestelde regels en voert de actie uit in het systeem.
Dat legt de lat voor je architectuur hoger dan een losse AI-feature. Een agent kan alleen handelen via de interfaces die je hem geeft, op data die klopt, met rechten die je kunt beperken en controleren. Een monolithische applicatie zonder heldere API’s biedt dat niet. Daar zit volgens SUE de grootste rem op agentic AI in bestaande software: niet het model, maar de applicatie eromheen.
1. Van monoliet naar modulair
We delen een monoliet op in bouwstenen met duidelijke grenzen, die via REST- of gRPC-API’s met elkaar praten. Elke bouwsteen kun je los vernieuwen, schalen en testen. Voor een agent zijn die API’s de handvatten: hij roept een afgebakende functie aan in plaats van zelf in een database te zoeken.
Dat hoeft geen big bang te zijn. We halen eerst de onderdelen eruit die het vaakst veranderen of het meest opleveren voor AI, terwijl de rest blijft draaien. Bij CarWise koppelden we zo de gebruikersinterface los van de bedrijfslogica, als basis voor een schaalbaar SaaS-platform.
2. Klantdata strikt gescheiden, met één bron van waarheid
Een SaaS-applicatie bedient meerdere klanten (tenants) op hetzelfde platform. Zodra een agent namens een gebruiker handelt, moet vaststaan dat hij alleen bij de data van die klant kan. We richten de datastructuur daarom zo in dat tenants strikt gescheiden blijven, in de database en in elke API.
Daarnaast heeft een agent één betrouwbare bron van waarheid nodig: een System of Record. Staan dezelfde klantgegevens op drie plekken met drie verschillende waarden, dan beslist een agent op verkeerde informatie.
3. Guardrails rond elke AI-actie
B2B-klanten willen weten wat een agent met hun data doet, en achteraf kunnen nagaan wat hij heeft gedaan. Met Retrieval-Augmented Generation (RAG) koppelen we de domeinkennis uit je eigen applicatie aan het model, zodat antwoorden en acties uitgaan van je eigen data. Guardrails bepalen wat een agent mag: welke acties, op welke data, tot welke grens, en wanneer een mens eerst moet goedkeuren.
Elke actie wordt gelogd, zodat je kunt uitleggen wat er gebeurde. Transparantie en logging zijn ook eisen uit de EU AI Act. Guardrails horen daarom in de architectuur, niet in een laag die je er later omheen zet.
4. Een verdienmodel op basis van gebruik
Neemt een agent werk over dat eerst handmatig gebeurde, dan heeft een klant op termijn minder gebruikersaccounts nodig. Een licentiemodel per gebruiker krimpt dan mee. Softwarebedrijven stappen daarom over op prijsmodellen op basis van gebruik of uitkomst: per afgehandelde aanvraag, per verwerkt document of per transactie.
Dat kan alleen als je software meet wat er gebeurt. Metering en telemetry horen daarom in de architectuur: welke klant welke functie gebruikt, hoe vaak en tegen welke kosten. Die data heb je ook nodig om de kosten van AI-modellen en cloud per klant te bewaken, zodat een nieuwe AI-module je marge niet opeet.
Waar begin je?
Bij de code die je al hebt. Met Re:App analyseert SUE bestaande software met AI: architectuur, afhankelijkheden en bedrijfslogica, ook als documentatie ontbreekt. Bij Deltares ging het om 6 miljoen regels code met 40 jaar geschiedenis. Uit die analyse volgt welke onderdelen eerst modulair moeten en welke kunnen blijven zoals ze zijn.
Draait je applicatie nog als desktopsoftware op de pc’s van gebruikers, dan is de overstap naar een webapplicatie vaak de eerste stap. Voor het platform eronder gebruiken we Multistax, zodat ontwikkelaars nieuwe functies zelf live zetten en de cloud- en AI-kosten zichtbaar blijven.
Hoe SUE dit aanpakt, lees je op de pagina Applicatie Modernisatie en in onze aanpak met AI. Voor softwarebedrijven staat meer op Applicatie Modernisatie voor ISV’s.
