De lokale LLM-firewall als controlelaag

AI in maatwerksoftware: wat komt er écht bij kijken?

AI biedt veel kansen, maar stelt organisaties ook voor een ongemakkelijke vraag: welke informatie vertrouw je toe aan een extern AI-model?

Bij eenvoudige vragen is dat misschien geen groot probleem. Maar zodra AI wordt geïntegreerd in bedrijfssoftware, klantportalen, dossiers of interne werkprocessen, verandert de situatie.

Een prompt kan dan gevoelige klantinformatie bevatten. Of persoonsgegevens. Of contractafspraken, financiele gegevens, interne notities, broncode of projectdocumentatie.

In deel 5 van deze serie schreven we al dat privacy begint voordat een prompt wordt verstuurd. In dit artikel gaan we dieper in op een technisch concept dat we binnen ons R&D-traject NoardCode AI Gateway onderzoeken: de lokale LLM-firewall.

Een lokale LLM-firewall is een controlelaag tussen de applicatie en externe AI-modellen. Het idee is dat prompts en responses eerst lokaal worden gecontroleerd, opgeschoond of beoordeeld voordat informatie naar buiten gaat of terugkomt in de applicatie.

Binnen het projectplan wordt dit beschreven als onderzoek naar een lokaal draaiende LLM die als firewall fungeert, zodat vertrouwelijke informatie niet onnodig de deur uit gaat. Daarbij wordt ook gewerkt aan een geautomatiseerde anonimisatielaag, validatie, logging en mechanismen om consistentie, volledigheid en vertrouwelijkheid van data te waarborgen.

Waarom een AI-firewall?

Bij traditionele software kennen we firewalls vooral als beveiligingslaag voor netwerkverkeer. Ze bepalen welk verkeer wel of niet wordt doorgelaten.

Bij AI ontstaat een vergelijkbare behoefte, maar dan op inhoudelijk niveau.

Een gewone firewall ziet bijvoorbeeld dat er verkeer naar een externe dienst gaat. Maar hij begrijpt niet automatisch of de inhoud van een prompt persoonsgegevens, klantdata of bedrijfsgevoelige informatie bevat.

Een AI-firewall moet daarom niet alleen kijken naar de verbinding, maar naar de inhoud.

De centrale vraag is: mag deze informatie, in deze vorm, voor deze taak, naar dit AI-model?

Dat is een veel specifiekere vraag dan: mag deze applicatie verbinding maken met deze API?

Een prompt is geen gewone API-request

Een API-request naar een betaalprovider of boekhoudpakket heeft vaak een vaste structuur. Je weet welke velden worden meegestuurd en kunt vooraf controleren wat erin staat.

Bij AI-prompts ligt dat anders.

Een prompt kan dynamisch worden opgebouwd uit allerlei bronnen: een vraag van de gebruiker, tekst uit documenten, data uit een database, klantnotities, eerdere conversatiegeschiedenis, foutmeldingen, systeeminstructies, samenvattingen, opgehaalde RAG-context en gegenereerde tussenresultaten.

Daardoor kan gevoelige informatie ongemerkt onderdeel worden van een prompt.

Juist omdat AI-prompts flexibel zijn, is een controlelaag belangrijk. Niet alleen om gebruikers te corrigeren, maar om technisch af te dwingen wat wel en niet mag.

Wat doet een lokale LLM-firewall?

Een lokale LLM-firewall kan verschillende functies hebben. Het is geen enkelvoudige knop, maar een combinatie van controles en beslissingen rondom AI-verkeer.

Denk aan:

• herkennen van persoonsgegevens;
• detecteren van bedrijfsgevoelige informatie;
• anonimiseren of maskeren van data;
• blokkeren van prompts die niet naar buiten mogen;
• bepalen of een taak lokaal of extern verwerkt moet worden;
• controleren of de prompt voldoet aan beleid;
• valideren of de output geen ongewenste informatie bevat;
• logging vastleggen van keuzes en aanpassingen;
• signaleren van risico's of onzekerheden.

De firewall fungeert daarmee als poortwachter.

Niet elke AI-taak is hetzelfde. Een algemene tekstsuggestie kan misschien veilig extern worden verwerkt. Een samenvatting van een privacygevoelig klantdossier vraagt om meer controle. En sommige taken wil je misschien volledig lokaal houden.

Waarom lokaal?

Het woord lokaal is belangrijk.

Als de controlelaag zelf bij een externe AI-provider draait, heb je het privacyprobleem deels verplaatst. Je stuurt dan alsnog gevoelige informatie naar buiten om te vragen of die informatie gevoelig is.

Door de eerste controle lokaal uit te voeren, kun je gevoelige data beoordelen voordat die eventueel naar een extern model gaat.

Dat biedt voordelen: gevoelige informatie kan lokaal worden herkend, data kan worden geanonimiseerd voordat die extern verwerkt wordt, bepaalde prompts kunnen volledig lokaal blijven, beleid kan binnen de eigen infrastructuur worden afgedwongen, logging en audit trails blijven onder eigen controle en afhankelijkheid van externe partijen wordt kleiner.

Lokaal betekent niet dat alles altijd lokaal moet gebeuren. Het betekent vooral dat de organisatie een eigen controlepunt heeft voordat externe verwerking plaatsvindt.

Anonimisering als tussenstap

Een van de belangrijkste functies van een AI-firewall is anonimisering.

Stel dat een applicatie een AI-model wil vragen om een klantvraag samen te vatten. De originele tekst bevat namen, e-mailadressen, telefoonnummers en klantnummers.

Voor de inhoudelijke samenvatting zijn die gegevens vaak niet nodig.

De firewall kan dan bijvoorbeeld Jan de Vries vervangen door klant A, een e-mailadres maskeren, een klantnummer vervangen door een interne placeholder, adressen verwijderen, gevoelige velden uit de prompt halen en een mapping lokaal bewaren zodat de applicatie de output later weer correct kan koppelen.

Op die manier blijft de opdracht bruikbaar, maar wordt de hoeveelheid gevoelige informatie die extern verwerkt wordt kleiner.

Dat sluit aan bij dataminimalisatie: gebruik alleen de data die nodig is voor het doel.

Niet alles kan zomaar worden geanonimiseerd

Anonimisering klinkt eenvoudig, maar is technisch lastig.

Sommige informatie is direct herkenbaar als persoonsgegeven, zoals een e-mailadres of telefoonnummer. Andere informatie is contextafhankelijk.

Een functietitel, projectnaam of combinatie van details kan alsnog herleidbaar zijn tot een persoon of organisatie. Ook kan te veel anonimiseren ervoor zorgen dat het AI-model de taak niet goed meer kan uitvoeren.

Daarom moet een lokale LLM-firewall meer doen dan vaste patronen zoeken.

Hij moet context begrijpen: is deze naam relevant voor de taak, kan deze passage worden gemaskeerd zonder betekenisverlies, bevat deze tekst indirect herleidbare informatie, is dit bedrijfsgevoelig of publiek beschikbaar, of moet deze taak volledig lokaal blijven?

Dit is precies waarom een lokale LLM als controlelaag interessant is. Een taalmodel kan inhoudelijke patronen herkennen die met simpele regels lastig te vangen zijn.

Beleid afdwingen in plaats van alleen adviseren

Een lokale LLM-firewall moet niet alleen waarschuwingen geven. Hij moet beleid kunnen afdwingen.

Een organisatie kan bijvoorbeeld regels instellen zoals:

• persoonsgegevens mogen niet naar externe modellen;
• juridische documenten mogen alleen lokaal worden verwerkt;
• broncode mag niet worden meegestuurd;
• klantdata mag alleen geanonimiseerd extern worden gebruikt;
• medische of zorggerelateerde informatie moet altijd lokaal blijven;
• prompts met bepaalde classificaties vereisen menselijke goedkeuring;
• output uit externe modellen mag niet automatisch worden opgeslagen zonder validatie.

De firewall vertaalt deze regels naar technische beslissingen.

Dat maakt AI-gebruik minder afhankelijk van individuele gebruikerskeuzes. De software helpt om veilig gedrag standaard te maken.

Controle op de output

Een AI-firewall kijkt niet alleen naar wat eruit gaat, maar ook naar wat terugkomt.

Een AI-model kan gevoelige informatie herhalen, verkeerd combineren of conclusies trekken die niet zomaar opgeslagen of getoond mogen worden.

Daarom kan outputcontrole nodig zijn. Bijvoorbeeld: bevat het antwoord persoonsgegevens, bevat het antwoord informatie waar deze gebruiker geen toegang toe heeft, is de output te stellig geformuleerd, ontbreken bronverwijzingen, is de output geschikt voor automatische verwerking, moet een medewerker het antwoord eerst controleren of bevat de response inhoud die niet past binnen beleid?

Voor zakelijke software is dit belangrijk. AI-output wordt soms onderdeel van dossiers, e-mails, rapportages, workflows of besluiten. Dan wil je niet alleen controleren wat je aan AI vraagt, maar ook wat je met het antwoord doet.

Logging en reproduceerbaarheid

Een lokale LLM-firewall kan ook helpen om AI-verwerking beter controleerbaar te maken.

Zonder logging is achteraf vaak niet duidelijk welke prompt is verstuurd, welke data is verwijderd of gemaskeerd, welk model is gebruikt, welke beleidsregel is toegepast, waarom een prompt is geblokkeerd of aangepast, welke output is teruggekomen, of de output is gevalideerd en welke gebruiker de actie startte.

Met logging wordt AI-verwerking herleidbaar.

Dat is belangrijk voor debugging, compliance, security en vertrouwen. Zeker bij organisaties die werken met privacygevoelige of bedrijfskritische informatie.

Tegelijk moet logging zorgvuldig gebeuren. Je wilt niet dat gevoelige data die uit prompts is verwijderd alsnog volledig in logbestanden terechtkomt. Ook logdata moet dus worden geminimaliseerd en beveiligd.

De firewall als onderdeel van een bredere AI-architectuur

Een lokale LLM-firewall staat niet op zichzelf.

Binnen een serieuze AI-integratie raakt deze controlelaag aan meerdere onderdelen: authenticatie en autorisatie, dataclassificatie, RAG en contextselectie, promptopbouw, modelkeuze, lokale of externe verwerking, logging, monitoring, outputvalidatie, audit trails en gebruikersfeedback.

Dat betekent dat een AI-firewall niet als losse plugin moet worden gezien. Hij moet onderdeel zijn van de architectuur van de applicatie.

In een Laravel-omgeving kan zo'n laag bijvoorbeeld aansluiten op bestaande policies, rollen, permissies, queues, events, encryptie, logging en datamodellen.

Zo blijft AI-verwerking onderdeel van dezelfde beveiligingsprincipes als de rest van de applicatie.

Voorbeeld: een AI-taak met controlelaag

Stel dat een gebruiker in een klantportaal vraagt: vat dit dossier samen en benoem de belangrijkste openstaande punten.

Zonder controlelaag zou de applicatie mogelijk het hele dossier naar een extern AI-model sturen.

Met een lokale LLM-firewall kan het proces er anders uitzien:

1. De applicatie verzamelt alleen dossieronderdelen waar de gebruiker toegang toe heeft.
2. De firewall analyseert de inhoud op gevoelige informatie.
3. Persoonsgegevens en klantnummers worden gemaskeerd waar ze niet nodig zijn.
4. De firewall bepaalt of externe verwerking is toegestaan.
5. Alleen de noodzakelijke context wordt doorgestuurd.
6. De output wordt gecontroleerd op gevoelige of onjuiste informatie.
7. De applicatie toont het antwoord met passende waarschuwingen of bronverwijzingen.
8. De verwerking wordt gelogd zonder onnodige gevoelige data op te slaan.

Dit maakt het proces niet alleen veiliger, maar ook beter uitlegbaar.

Wat zijn de technische uitdagingen?

Het concept klinkt logisch, maar is technisch uitdagend.

Een lokale LLM-firewall moet snel genoeg zijn om de gebruikerservaring niet te verstoren. Hij moet nauwkeurig genoeg zijn om gevoelige informatie te herkennen. Hij moet niet te streng zijn, anders blokkeert hij bruikbare processen. Maar hij moet ook niet te soepel zijn, anders ontstaat schijnveiligheid.

Daarnaast spelen vragen zoals welk lokaal model geschikt is voor classificatie en anonimisering, hoeveel rekenkracht lokaal nodig is, hoe je false positives en false negatives voorkomt, hoe je meet of anonimisering voldoende is, hoe je regels combineert met AI-beoordeling, hoe je omgaat met meertalige data, hoe je output valideert, hoe je logs veilig houdt en hoe je dit integreert in bestaande software.

Dit zijn precies het soort vragen dat in een R&D-traject onderzocht moet worden.

Waarom dit relevant is voor organisaties

Voor organisaties die AI willen gebruiken, is de lokale LLM-firewall vooral relevant omdat hij helpt om grip te houden.

Niet elke medewerker hoeft zelf te beoordelen of een prompt veilig is. Niet elke AI-taak hoeft handmatig langs een securityspecialist. Niet elke gevoelige dataset hoeft volledig uitgesloten te worden van AI-toepassingen.

Met een goede controlelaag kun je AI op een verantwoordere manier inzetten.

Dat is interessant voor sectoren waar privacy, compliance en vertrouwen belangrijk zijn, zoals zorg, overheid, juridische dienstverlening, administratie en accountancy, onderwijs, HR, softwareontwikkeling en klantportalen of SaaS-platformen.

Juist daar kan AI veel waarde toevoegen, maar alleen als de dataroute goed beheersbaar is.

Wat onderzoeken we binnen de NoardCode AI Gateway?

Binnen de NoardCode AI Gateway onderzoeken we hoe een lokale LLM-firewall technisch kan functioneren als controlelaag tussen applicaties en AI-modellen.

Daarbij kijken we onder andere naar lokaal draaien van een LLM, classificatie van gevoelige informatie, automatische anonimisering, validatie van prompts, controle van responses, logging en audit trails, integratie met Laravel-applicaties, beleid voor lokale of externe verwerking, versleuteling en veilige opslag, en reproduceerbaarheid van AI-interacties.

De centrale vraag is: kunnen we een lokale controlelaag ontwikkelen die AI-verwerking veiliger maakt zonder de bruikbaarheid van AI weg te nemen?

Dat evenwicht is belangrijk. Te weinig controle is riskant. Te veel controle maakt AI onwerkbaar. De uitdaging zit in de juiste balans.

Wat leren we hiervan?

De belangrijkste les is dat veilige AI niet alleen draait om vertrouwen in een model of provider.

Veilige AI vraagt om een eigen controlepunt in de softwarearchitectuur.

Een lokale LLM-firewall kan helpen om prompts en responses inhoudelijk te beoordelen, gevoelige data te beschermen en beleid technisch af te dwingen.

Daarmee verschuift AI-integratie van we sturen data naar een model en hopen dat het goed gaat naar we bepalen bewust welke data, via welke route, onder welke voorwaarden wordt verwerkt.

Dat is een noodzakelijke stap als AI een structureel onderdeel wordt van bedrijfssoftware.

Tot slot

AI kan veel waarde toevoegen aan organisaties, maar alleen wanneer data zorgvuldig wordt behandeld.

De lokale LLM-firewall is een manier om meer grip te krijgen op die dataroute. Niet als vervanging van privacybeleid, security of goede softwarearchitectuur, maar als technische controlelaag die deze principes helpt afdwingen.

Binnen de NoardCode AI Gateway onderzoeken we hoe zo'n controlelaag kan bijdragen aan veilige, transparante en beheersbare AI-integratie.

In de volgende blog gaan we in op een ander belangrijk vraagstuk: waarom de toekomst van AI-integratie waarschijnlijk hybride is, lokaal waar het moet, cloud waar het kan.