Een AI-laag op je Laravel-app: het verschil
tussen een chatbot en een assistent

Een chatbot in een corporate webapplicatie voelt vaak als een sticker op een kluis: hij plakt erop, maar hij hoort er niet bij. Hij weet niets van je schema, kent je permissies niet, en als hij een record schrijft via een eigen SQL-laag heb je net je hele validatie omzeild. Een AI-assistent die je wél in je Laravel-app durft te zetten ziet er anders uit. Dit artikel legt uit waar dat verschil zit.

De aanleiding: formulieren die nooit zijn afgeslankt

Veel maatwerk-applicaties zijn de afgelopen vijf tot tien jaar gegroeid. Wat ooit één formulier was, is nu vier tabbladen met twaalf velden, drie afhankelijke dropdowns en een verplichte bijlage waarvan niemand meer precies weet waarom hij verplicht is. Een nieuwe medewerker traint twee weken op het klikpad voordat een werkbon, dossier of factuurregel vlot wordt ingevoerd. Mobiel is het helemaal niet werkbaar.

Tegelijkertijd weten gebruikers wél precies wat er moet gebeuren. Als je het ze in normale taal vraagt, leveren ze het in één zin: "Klant Jansen, ketel vervangen, drie uur, gebruikt CV-blok artikel 4421, factuur naar hoofdkantoor." Daarin zit alle informatie die het systeem nodig heeft, alleen verspreid over wat eigenlijk drie tabellen zijn: een werkbon, een tijdregistratie en een factuurregel.

De vraag is niet meer "kan AI dit invullen?" — dat kan al een tijdje. De vraag is: hoe doe je dat zónder je business rules te omzeilen?

Wat een chatbot níet doet

Een generieke chatbot — bijvoorbeeld een widget die je inbedt en aansluit op een LLM — kent jouw model niet. Hij weet niet dat een werkbon een tenant_id nodig heeft die uit de ingelogde gebruiker komt. Hij weet niet dat artikel 4421 alleen geldig is bij CV-installatiebonnen en niet bij onderhoud. Hij weet niet dat een factuurregel pas mag worden aangemaakt nadat de werkbon de status "voltooid" heeft.

Drie typische ontwerpkeuzes die in de praktijk pijn doen:

• Eigen SQL- of database-laag. De chatbot praat direct met je database, langs je Eloquent-models en FormRequests heen. Een ongeldige record wordt gewoon weggeschreven; jouw applicatie ziet pas later dat het mis is.
• Geen diff vóór schrijven. De gebruiker typt een zin, de chatbot zegt "klaar". Als hij het verkeerd interpreteerde, ontdek je dat de volgende ochtend in je administratie.
• Geen aansluiting op je policy-laag. Wat een gebruiker via de UI niet mag (bv. records van een andere tenant zien), kan de chatbot meestal wél, omdat hij een eigen service-account gebruikt.

De gemene deler is dat de chatbot náást je applicatie zit, niet erop. En de "data" die hij gebruikt is op zijn best een prompt-engineerde context-blob met wat schemavelden — geen levende verbinding met jouw model.

Wat een AI-assistent dan wel is

Een assistent in deze betekenis is een chat-laag met tools die 1-op-1 mappen op je bestaande Filament Resources. Geen losse SQL-laag, geen omzeil-pad. De LLM (Claude, GPT, of een lokaal model via Ollama) krijgt een lijst tools, beschrijft via die tools wat hij wil doen, en de tools voeren dat uit met dezelfde validatie die jouw frontend ook gebruikt.

Concreet ziet dat er zo uit:

1. Resources worden tools. Een Filament Resource heeft al een create, update, delete en bijbehorende FormRequests. Wij wikkelen die in tool-definities die de LLM begrijpt: een naam, een schema (uit de FormRequest), en de aanroep-logica.
2. Lezen vóór schrijven. Eerst leesoperaties: findCustomer, findArticle, listTimeEntries. Daarmee bouwt de assistent context op die voor jou en hem hetzelfde betekent.
3. Diff vóór commit. De assistent stelt voor wat hij wil schrijven, in een gestructureerd diff-blok. De gebruiker ziet exact wat er in welke tabel landt en in welke velden. Akkoord, aanpassen of annuleren — pas dan gaat het door de echte FormRequest en Eloquent-laag.
4. Policies blijven leidend. Tools roepen $user->can(...) aan voordat ze iets doen. Wat een gebruiker in de UI niet mag, kan de assistent ook niet. Geen aparte AI-bypass-rol.
5. Audit-trail per actie. Elke tool-call wordt gelogd: gebruiker, prompt, tool-naam, argumenten, resultaat. Compliance-afdelingen kunnen exact reconstrueren wat de assistent heeft gedaan en op verzoek van wie.

Waarom Laravel en Filament hier zo goed bij passen

Een groot deel van het werk dat normaal in een AI-assistent gaat zitten — schema-mapping, validatie, autorisatie, audit — heb je in een Laravel-applicatie met Filament al staan. FormRequests zijn al je validatie, Policies zijn al je autorisatie, en als je spatie/laravel-permission draait is je rol-model ook al aanwezig.

Wij doen niets meer dan die laag exposen aan een LLM via tool-definities. Geen herimplementatie, geen tweede source of truth, geen aparte schema-beschrijving die los van je code uit elkaar gaat lopen. Als jij morgen een veld toevoegt aan je InvoiceResource, weet de assistent het overmorgen ook.

Dat is het verschil tussen een AI-laag die meegroeit met je applicatie en eentje die elke release weer een aparte sync-stap nodig heeft.

Provider-agnostisch: niet aan één LLM hangen

Wij beginnen meestal met Anthropic Claude voor tool-use omdat die in de praktijk het meest betrouwbaar is in tool-call patronen. Maar de implementatie is provider-agnostisch opgezet — de tool-definities zijn intern, de LLM is een driver. Concreet betekent dat je per omgeving kunt kiezen:

• Anthropic Claude API — standaard voor productie, beste prijs/prestatieverhouding voor tool-use met complexe schema's.
• OpenAI / Azure OpenAI — als je organisatie al een Azure-tenant heeft of GPT-4-class output wil, draait dezelfde code daar prima op.
• Ollama (lokaal of on-prem) — voor scenarios waar geen enkele prompt of database-inhoud je netwerk mag verlaten. Een eigen GPU-server of een Ollama-deployment in je DMZ. Werkt naast je Laravel-app, niet erbuiten.

Voor de gemiddelde scale-up is dat vaak géén keuze die je vooraf hoeft te maken. Begin bij Claude voor pilot, switch naar Ollama als compliance daar later om vraagt — de applicatie-code verandert niet mee.

MCP-server inbegrepen: dezelfde tools, andere oppervlakken

Een onderbelichte bonus: dezelfde tool-definities werken ook via het Model Context Protocol. Dat betekent dat je power-users binnen je organisatie de tools óók kunnen aanroepen vanuit Claude Desktop of Claude in de browser, zonder dat ze in je applicatie hoeven in te loggen. Eén implementatie, twee oppervlakken: een ingebedde chat in de Laravel-app voor de meeste gebruikers, en een MCP-koppeling voor analytisch werk dat over meerdere tabellen heen vraagt.

Wanneer het past — en wanneer niet

Een AI-assistent op deze manier ingebouwd is geen sluitstuk-feature. Hij rendeert wanneer:

• Je applicatie meerdere modellen heeft die in samenhang worden bijgewerkt (orders + invoices, cases + time + invoice-lines, contracts + orders).
• Een nieuwe medewerker meer dan één werkdag moet trainen op het klikpad.
• Je gebruikers regelmatig vanaf mobiel werken en het formulier daar gewoon te groot is.
• Je analytische vragen krijgt die nu rapporten of exports vereisen die niemand bouwt.

Hij rendeert niet wanneer:

• Je applicatie maar één formulier heeft van vier velden. Een chatlaag voegt dan complexiteit toe waar simpel UX-onderhoud meer effect heeft.
• Je gebruikers de huidige UI prima vinden en de support-load laag is. Onder die voorwaarde is een AI-laag een oplossing zonder probleem.
• Je policies en validatie nog niet op orde zijn. Wij bouwen de assistent op je business rules; als die niet bestaan, is de assistent net zo vrijblijvend.

Dat laatste punt is in de praktijk de belangrijkste sortering. Een Laravel-applicatie die al netjes met FormRequests, Policies en Eloquent-events draait kan binnen vier weken een werkende read-only AI-laag hebben. Een applicatie waar al die discipline ontbreekt heeft eerst een andere klus voordat een AI-laag verantwoord is.

Hoe wij dit aanpakken

Onze aanpak is gefaseerd. Geen big-bang, want het vertrouwen in een schrijvende AI-laag bouw je op in iteraties:

1. Discovery. We brengen je Filament Resources, Policies en flows in kaart. Welke acties kosten het meest tijd? Waar zit de meeste support-druk?
2. Tools. Resources worden tool-definities. Eerst alleen lezen — vragen stellen aan je data zonder rapport-builder. Per tool een duidelijk contract.
3. Pilot. Eén schrijfflow live, met een pilotgroep. Logging aan, feedback ophalen, scherper afstellen. Diff vóór akkoord is hier niet onderhandelbaar.
4. Rollout. Stap voor stap: meer tools, meer gebruikers, meer surfaces. MCP-server ernaast voor power-users.

Een read-only versie kan binnen vier weken werken voor een afgebakend deel van je systeem. Schrijfflows komen daarna gefaseerd erbij.

Verder lezen of een gesprek

Voor wie de propositie compacter wil zien, met de vier kernfeatures naast elkaar en concrete praktijkgevallen: de dienstpagina AI-assistent voor je Laravel-app heeft de volledige opzet inclusief use-cases voor servicebedrijven, adviesbureaus en B2B-portalen.

Heb je een Laravel-app draaien waar dit op zou kunnen werken — of waar het juist niet bij past en je dat wilt valideren? Plan een gesprek. Eén vraag, één eerlijk antwoord, niet langer dan een halfuur.