De dag dat onze private AI een medewerker een salaris toonde dat hij nooit had mogen zien

Het memo dat niet werkt

Ergens in uw bedrijf heeft op dit moment iemand een klantcontract in een chatbot geplakt om het te laten samenvatten. Ze hebben het niet gevraagd. Ze zijn niet kwaadwillig. Ze hadden een deadline en een tool die werkte, en die tool stuurde dat contract toevallig naar een server die eigendom is van een bedrijf op een ander continent.

Ik weet dit omdat elke CISO met wie ik heb gewerkt hetzelfde dashboard heeft, en het vertelt hetzelfde verhaal. Een van hen opende Netskope tijdens een vergadering en liet me 317 verschillende generatieve-AI-apps zien die actief in gebruik waren binnen zijn organisatie. Hij had er een handvol goedgekeurd. De rest waren zijn medewerkers die hun eigen problemen oplosten, één plakactie tegelijk.

Die kloof — tussen de AI die u heeft goedgekeurd en de AI die uw mensen daadwerkelijk gebruiken — is het probleem dat ik het laatste deel van mijn carrière heb gewijd aan het oplossen door Veriprajna te bouwen. Wij doen aan private LLM-implementatie: we plaatsen een capabel groot taalmodel binnen uw eigen infrastructuur, onder uw eigen controles, zodat het werk dat uw medewerkers al met AI doen niet langer aan de zijkant van het gebouw naar buiten lekt. Soevereine AI is geen filosofische verkooppraat over nationale technologische onafhankelijkheid. Het is het praktische antwoord op een vraag die elke beveiligingsleider nu al niet weet te beantwoorden: waar gaan onze gegevens naartoe, en kunnen we dat bewijzen?

Het instinct, wanneer u dat dashboard voor het eerst ziet, is om een memo te sturen. Verbied de tools. Ik heb die gedachtegang vroeg eens uitgeprobeerd, en ik wil u precies vertellen waarom die uiteenvalt — want het falen ervan is de hele reden waarom dit bedrijf bestaat.

AI verbieden verwijdert het niet uit uw bedrijf. Het ontneemt u alleen het zicht erop.

De cijfers maken het punt beter dan ik dat kan. Het rapport 'Cost of a Data Breach 2025' van IBM stelde vast dat een op de vijf organisaties al een datalek heeft geleden dat verband houdt met schaduw-AI — niet-goedgekeurde tools die zonder medeweten van IT worden gebruikt. Die datalekken kostten gemiddeld $670.000 meer dan traditionele incidenten, en het kostte 247 dagen om ze te detecteren, tegenover 241 voor al het andere. Een aparte enquête stelde het botweg: 43% van de werknemers geeft toe gevoelige werkinformatie te delen met AI-tools die hun werkgever nooit heeft goedgekeurd. Een verbod verandert dat gedrag niet. Het garandeert alleen dat u de laatste bent die het te weten komt wanneer het misgaat.

Waarom lost een private chatbot schaduw-AI niet op?

Dus als u het niet kunt verbieden, bouwt u het veilige alternatief. Zet een interne chatbot op, koppel hem aan een goed model, en zeg tegen iedereen dat ze die in plaats daarvan moeten gebruiken. Dit is waar ik mijn duurste fout maakte, en het is de moeite waard om erbij stil te staan, omdat bijna iedereen die maakt.

De eerste interne implementatie waar ik dicht bij betrokken was, zag er geweldig uit in de demo. Strakke interface, snelle antwoorden, een model dat de documenten van het bedrijf kende. We waren er trots op. Toen, tijdens de pilot, stelde iemand in een junior functie een vraag over een beloningsplan — en het gaf antwoord. Volledig. Nauwkeurig. Met details uit een document dat die persoon absoluut niet had mogen lezen.

Er was niets gehackt. Het retrievalsysteem deed precies wat we het hadden gebouwd om te doen: de meest relevante documenten vinden en aan het model doorgeven. We hadden het alleen nooit geleerd dat relevantie en toestemming verschillende dingen zijn. De chatbot was een trouwe bibliothecaris die de loper had gekregen voor elke afgesloten ruimte in het gebouw.

Die middag herkaderde het hele probleem voor mij. Het model was nooit het moeilijke deel. Het moeilijke deel is toestemming.

Dit is wat niemand u vertelt in de leveranciersdemo's: de meeste ondernemingen dragen jarenlang opgebouwde toegangslogica met zich mee, verborgen in Active Directory — geneste beveiligingsgroepen, overgeërfde permissies, distributielijsten, organisatie-eenheden die door mensen die jaren geleden vertrokken op elkaar zijn gestapeld. Wanneer u een retrievalsysteem bouwt, is de naïeve zet om elk tekstfragment te taggen met een platte lijst van wie het mag zien. Dat stort in op het moment dat u te maken krijgt met groepsnesting uit de praktijk. Een document erft toegang van een groep, die erft van een andere groep, waaraan jaren geleden een externe medewerker voor één enkel project werd toegevoegd.

Dit goed doen is het eigenlijke werk. We hebben een synchronisatielaag gebouwd die zich bevindt tussen de identity provider — Active Directory, Okta, Azure AD — en de vectordatabase waar de documenten staan. Die lost groepslidmaatschap recursief op, maakt die overervingsketens plat, en ververst de toegangsmetadata in een strak tempo. Voor de meeste implementaties synchroniseren we elke 60 tot 90 seconden. Maar het scenario waar u 's nachts van wakker ligt, is het ontslag: iemand wordt om 9 uur 's ochtends het pand uit begeleid, en het systeem mag om 9:05 niet nog steeds antwoorden met diens toegang. Intrekkingen wachten dus niet op de volgende synchronisatie — een Okta- of Azure AD-webhook activeert een onmiddellijke purge op het moment dat het account wordt uitgeschakeld.

Relevantie en toestemming zijn niet hetzelfde, en een retrievalsysteem dat ze verwart, geeft het juiste antwoord aan precies de verkeerde persoon. Geen enkel groot RAG-platform lost dit kant-en-klaar op — ik heb ernaar gezocht.

Dat is geen marketingbravoure — het is wat ik aantrof toen ik keek. TrueFoundry, Databricks, de cloud-native zoekproducten hebben allemaal gedeeltelijke antwoorden: alleen-lezen permissiecontroles, periodieke synchronisaties. Geen van hen neemt het volledige beeld over van groepsbeleid en attribuutgebaseerde regels — tijdgebonden toegang, "alleen vanaf een beheerd apparaat," classificatieniveaus — waarop een gereguleerde onderneming daadwerkelijk draait. Dus bouwen we die policy engine als maatwerk, want er is geen kortere weg naartoe. Als u de volledige architectuur wilt van hoe deze permissiehandhaving van begin tot eind werkt, dan staat die uiteengezet op onze soevereine AI en private LLM-implementatie-pagina.

Maakt een datacenter in Frankfurt uw AI Europees?

Er is een tweede valkuil, en die is subtieler omdat hij op compliance lijkt. Veel ondernemingen grijpen naar een managed optie — Azure OpenAI, AWS Bedrock — en voelen zich veilig. De data blijft in hun cloud-tenant. Er zijn VPC-endpoints, private networking, een stapel certificeringen. Voor tal van bedrijven is dat echt het juiste antwoord, en ik zeg dat een klant recht in het gezicht wanneer dat zo is.

Maar onder het technische feit ligt een juridisch feit dat ik mensen voortdurend zie missen. Uw AI hosten in een datacenter in Frankfurt maakt hem niet Europees. Microsoft en Amazon zijn bedrijven met hun hoofdkantoor in de VS, en dat maakt hen onderworpen aan de Amerikaanse CLOUD Act, die Amerikaanse rechtshandhaving in staat stelt een Amerikaans bedrijf te dwingen gegevens af te staan die het waar ook ter wereld opslaat. Artikel 48 van de AVG stelt dat een buitenlands gerechtelijk bevel hier alleen geldig is met een internationale overeenkomst. Die twee wetten wijzen in tegengestelde richtingen, en uw gegevens bevinden zich in het gat ertussen.

Dit hield in maart 2026 op theoretisch te zijn. De Oostenrijkse gegevensbeschermingsautoriteit beboette een Weense fintech 450.000 EUR voor het uitvoeren van kredietscoring via een in de VS gevestigde AI-API — met de uitspraak dat dit een onrechtmatige gegevensoverdracht onder de AVG was. Het bedrijf had, zoals bijna iedereen doet, aangenomen dat hosting in een Europese regio genoeg was. Dat was het niet. Ik houd die uitspraak als bladwijzer bewaard, want het is de helderste illustratie die ik heb gevonden van een risico waarvan de meeste besturen niet weten dat ze het dragen.

Het spiegelbeeldige geval is een Amerikaanse ziekenhuisketen: daar telt de CLOUD Act nauwelijks mee, maar de business-associate-vereisten van HIPAA en — zodra u federale contracten aanraakt — het NIST AI Risk Management Framework en FedRAMP High worden dan de grens die u trekt. De jurisdictievraag behoudt dezelfde vorm; alleen het wetsartikel aan de muur verandert.

Voor een Amerikaans financieel bedrijf zonder Europese klanten doet niets hiervan ertoe en is Azure OpenAI vaak precies goed. Voor een Europese bank die de gegevens van haar eigen klanten verwerkt, keert de rekensom om — en de enige configuratie die de blootstelling aan de CLOUD Act volledig wegneemt, is een zelfgehoste implementatie op open-weight-modellen die draait op infrastructuur waarvan de beheerder niet onder de Amerikaanse jurisdictie valt. Dat is de eigenlijke functie van de Europese soevereine-cloudaanbieders — OVHcloud, Scaleway, de nieuwe Blackwell-capaciteit die in Europa online komt. Geen patriottisme. Jurisdictie.

En de deadline is reëel. De transparantieverplichtingen van artikel 50 van de EU AI Act worden afdwingbaar op 2 augustus 2026. Stapel de boetes van de AI Act boven op die van de AVG en het gecombineerde plafond bereikt 55 miljoen EUR, oftewel 11% van de wereldwijde jaaromzet. Dat is geen boete die u opvangt. Dat is een getal dat carrières beëindigt.

"Gebruik gewoon de API" — Het gesprek dat ik elke maand voer

De tegenwerping die ik het vaakst hoor is financieel, en die is terecht: zelf hosten klinkt duur. Waarom GPU's kopen en een team aannemen wanneer een API slechts een creditcardbetaling verderop ligt?

Omdat de rekensom omslaat, en het punt waar dat gebeurt is specifieker dan mensen verwachten. Voor een zelfgehost model met 70 miljard parameters kost inferentie ongeveer $0.013 per duizend tokens. Hetzelfde werk via een gehoste API zoals GPT-4o mini kost $0.15 tot $0.60 per duizend. Dat is geen afrondingsverschil. Maar het maakt alleen uit boven een bepaald volume, want zelfgehoste GPU's kosten geld of u ze nu gebruikt of ze stilstaan.

Het break-evenpunt ligt rond twee miljoen tokens per dag. Onder die grens winnen API's — u betaalt niet voor stilstaande hardware, en ik zeg een klant zonder aarzelen dat hij bij API's moet blijven. Erboven bespaart zelf hosten 60 tot 85% op inferentie. Eén fintech die ik ken verlaagde zijn maandelijkse AI-rekening van $47.000 naar $8.000 door over te stappen op hybride zelf hosten.

Maar — en dit is het deel dat de prijskaartjes van GPU's verhullen — de hardware is zelden de grootste kostenpost. Tegen de huidige prijzen huurt u een H100 voor $2.50 tot $3.50 per uur, en een enkele die een open-weight-model zoals Llama 3.3 70B draait, bedient 30 tot 50 gelijktijdige gebruikers met een latentie van onder de twee seconden. Het dure deel zijn de mensen. U hebt MLOps-engineers nodig — minimaal twee voor betrouwbaarheid in productie — voor $200.000 tot $350.000 per stuk, plus monitoring, evaluatiepijplijnen, een rollbackstrategie. Voor een team dat nieuw is in het draaien van modellen, komt de totale eigendomskosten in het eerste jaar rond de 3.2x de kale API-kosten uit. Voor een volwassen team met bestaande tooling daalt dat naar ongeveer 1.8x.

Die fintech die zijn rekening zo drastisch verlaagde? Het werkte omdat ze al een Kubernetes-team hadden en 18 maanden aan operationeel littekenweefsel. Dezelfde stap zou een team dat het al doende leert failliet hebben gemaakt.

De GPU is het goedkoopste deel van zelf hosten. De twee engineers die hem draaiende houden zijn de kostenpost die bepaalt of de rekensom daadwerkelijk klopt — en wie sneller "moeten we zelf hosten?" beantwoordt dan met "dat hangt af van uw volume en uw team," verkoopt u iets.

Het goede nieuws onder dit alles is dat de open-weight-modellen goed genoeg zijn geworden om de vraag überhaupt de moeite waard te maken. Llama 3.3 70B haalt 86% op de MMLU-benchmark en draait zelfgehost ongeveer 25 keer goedkoper dan de gelijkwaardige API. DeepSeek-V3 scoort 88.5% — en verslaat daarmee op die maatstaf een toonaangevend propriëtair model. Voor de grote meerderheid van bedrijfstaken is het model dat u binnen uw eigen muren kunt draaien niet langer het compromis dat het twee jaar geleden was.

Wat er gebeurt wanneer de AI niet langer alleen praat

Eén ontwikkeling maakt dit alles van verstandig tot urgent. De AI in uw bedrijf houdt binnenkort op een chatbot te zijn en wordt een agent — software die niet alleen vragen beantwoordt maar acties onderneemt, met permanente toegang tot uw systemen.

Gartner verwacht dat tegen eind 2026 40% van de bedrijfsapplicaties AI-agents zal inbedden, tegenover minder dan 5% een jaar eerder. Maar slechts ongeveer 5% van de ondernemingen heeft agents daadwerkelijk van pilot naar productie gebracht, en het beveiligingsbeeld is werkelijk alarmerend: 92% van de beveiligingsleiders zegt geen volledig zicht te hebben op de AI-identiteiten die al in hun omgeving actief zijn. Een agent die uw CRM kan lezen, tickets kan aanmaken en geld kan verplaatsen, is een heel ander risico dan een chatbot die een PDF kan samenvatten.

Alles wat ik heb beschreven — de permissiehandhaving, de jurisdictiecontrole, de runtime-guardrails die prompt injection onderscheppen — houdt op een nice-to-have te zijn op het moment dat uw AI kan handelen. Een chatbot die het verkeerde document ophaalt is een blamage. Een agent met permanente toegang en geen permissiegrens is een incident dat op een datum wacht.

Dit is de herkadering die ik u zou willen meegeven. De guardrail-laag doet er hier ook toe — en het is goed om te weten dat kant-en-klare opties zoals NVIDIA's NeMo Guardrails echte latentie toevoegen, 100 tot 300 milliseconden per aanroep, en dat is waarom we de policy-logica afstemmen op het specifieke compliancepatroon in plaats van er een generiek filter op te schroeven. Maar het diepere punt is architectonisch. U kunt geen agent plaatsen op infrastructuur die u niet beheert en die dan bestuurd noemen.

Het deel waartegen mensen zich altijd verzetten

Mensen vragen me of ze echt moeten kiezen — of ze enkele cloud-API's kunnen behouden en zichzelf toch soeverein kunnen noemen. Ja: de meeste implementaties die ik zou aanbevelen zijn hybride, gevoelige workloads op private infrastructuur en die met een laag risico op managed API's, met een duidelijke beleidsgrens die bepaalt wat waar hoort. Soevereiniteit was nooit een alles-of-niets-belofte; het gaat erom de grens op de juiste plek te trekken en te kunnen bewijzen waar die ligt.

De andere vraag is timing — is het niet te vroeg? De Oostenrijkse boete is al gevallen. De deadline van artikel 50 staat in de agenda. Uw medewerkers plakken op dit moment, terwijl u dit leest, gegevens in honderden tools die u niet heeft goedgekeurd. De kosten van vroeg handelen zijn een project. De kosten van te laat handelen worden afgemeten aan een plafond van elf procent van de omzet.

Ik ben Veriprajna begonnen omdat ik zag hoe een trouwe kleine chatbot een junior medewerker een salaris toonde dat hij nooit had mogen zien, en ik besefte dat de hele branche modellen verkocht terwijl het eigenlijke probleem controle was. Het model is het gemakkelijke deel. Dat is het altijd geweest.

Uw mensen wachten niet op toestemming om AI te gebruiken. De enige openstaande vraag is of de AI die zij gebruiken verantwoording aan u aflegt.

Als u wilt zien hoe we die controle ontwerpen voor een specifiek risicoprofiel — waar de grens tussen privaat en managed zou moeten liggen, hoe de permissielaag wordt gebouwd, hoe de werkelijke totale kosten er voor uw team uitzien — dan is dat wat we, eerlijk en leveranciersonafhankelijk, uiteenzetten op de Veriprajna soevereine-AI-pagina. Breng uw dashboard mee. Ik weet al ongeveer wat erop staat.