De EU AI-verordening trad in augustus 2024 in werking, met bepalingen die gefaseerd worden ingevoerd over een periode van twee tot drie jaar [1][2]. Tot nu toe hebben de meeste gesprekken over naleving binnen ondernemingen zich gericht op de vraag of een workflow überhaupt onder de categorie 'hoog risico' valt. Tegen midden 2026 verschuift het gesprek naar een meer praktische vraag: gezien het feit dat de workflow is Binnen de reikwijdte, welke implementatiearchitecturen laten u daadwerkelijk toe om te voldoen aan de verplichtingen van de implementator, en welke doen dat stilzwijgend niet?

Die tweede vraag is waar on-premises implementatie ophoudt een stijlkeuze te zijn en begint een structurele match te worden.

Wat de wet van aanbieders van hoogrisico-AI vraagt

De wet maakt onderscheid tussen de aanbieder van een AI-systeem en de inzetter ervan [1]. Een bank die een API van een derde partij voor een LLM gebruikt om leningaanvragen te beoordelen, is de implementator, niet de aanbieder. Implementatoren van hoogrisicosystemen hebben verplichtingen, waaronder: het waarborgen van menselijke controle, het monitoren van de werking van het systeem, het bijhouden van logboeken voor een passende periode, het opschorten van het gebruik als het systeem een risico vormt voor fundamentele rechten, en het op verzoek aantonen van deze mogelijkheden.

Verschillende van die verplichtingen zijn eenvoudig wanneer de implementator de runtime beheert. De verplichting om "logs voor een passende periode te bewaren" is mechanisch eenvoudig als de inferentie plaatsvindt op een server die de implementator bezit en de logs in de SIEM van de implementator terechtkomen. De verplichting tot "gebruik opschorten" is op vergelijkbare wijze triviaal als de implementator het model op hun eigen infrastructuur kan uitschakelen.

Dezelfde verplichtingen worden moeilijker wanneer de inferentie plaatsvindt via een cloud LLM API die de implementator niet beheert. De logs die de implementator kan produceren zijn beperkt tot wat de aanbieder blootgeeft. Het opschorten van het gebruik vereist medewerking van de aanbieder. Tegelijkertijd aantonen welke gegevens door het systeem zijn gegaan vereist vertrouwen in de pijplijn van de aanbieder.

Waar cloud LLM-API's binnen de regelgeving vallen

Niets hiervan maakt cloud LLM API's niet-conform. Artikel per artikel kunnen aanbieders en inzetters van cloud-gehoste AI voldoen aan de verplichtingen van de wet. De wrijving is operationeel, niet juridisch: de inzetter moet compliance samenstellen, auditen en aantonen over een leveranciersgrens heen, vaak voor workflows die duizenden inferenties per dag uitvoeren.

De longitudinale AI Index van Stanford HAI heeft de overeenkomstige verschuiving in bedrijfsuitgaven gevolgd [3]: de sterkste groei tussen 2023–2025 was niet in generatieve AI voor algemene doeleinden, maar in de ondersteunende tooling — observability, governance, prompt-logging, content-classificatie, jailbreak-detectie. Het merendeel van die uitgaven bestaat om de kloof te overbruggen tussen wat cloud LLM API's van nature blootstellen en wat een inzetter moet aantonen in een regelgevende context.

Die kloof is het structurele voordeel van het uitvoeren van inferentie op hardware die de inzetter bezit. Elke vraag 'is dit gebeurd?' valt terug op een vraag die de inzetter kan beantwoorden vanuit zijn eigen logs.

Wat on-prem niet gratis voor je regelt

Drie inzetterverplichtingen uit de AI Act worden niet automatisch vervuld door een on-prem deployment, en het is de moeite waard ze expliciet te benoemen:

  • Menselijke supervisie. De wet vereist zinvolle supervisie van hoog-risico AI, waarbij mensen outputs kunnen interpreteren en ingrijpen. Het lokaal draaien van het model plaatst geen mens in de lus; dat doet het ontwerp van de workflow.
  • Monitoring op drift en onveilig gedrag. De inzetter moet het systeem continu monitoren. On-prem deployment maakt de technische infrastructuur triviaal (de data is lokaal), maar het beleid ('hoe ziet drift eruit voor deze workflow?') moet nog steeds worden gedefinieerd.
  • Verplichtingen van de aanbieder doorgegeven. Wanneer de on-prem deployment is gebouwd op een model van een derde partij (bijv. een open-weight model onder een niet-commerciële licentie, of een vendormodel geleverd als binary), moet de inzetter nog steeds de vereiste openbaarmakingen van de aanbieder zichtbaar maken.

Het structurele voordeel van on-prem ligt op het vlak van datahandling en aantoonbaarheid, niet op beleid. Beleid moet worden geschreven en gehandhaafd ongeacht waar de GPU zich bevindt.

Hoe dit zich verhoudt tot VS, VK en andere jurisdicties

De EU AI Act is het meest voorschrijvend van de grote kaders. De Amerikaanse NIST AI RMF [4] hanteert een vrijwillige, kadergebaseerde aanpak, en het OECD AI Policy Observatory [5] volgt hoe nationale overheden buiten de EU convergeren naar min of meer gelijke principes (risicogebaseerde supervisie, transparantieverplichtingen, regels voor datahandling).

Voor een multinationale inzetter is het praktische effect dat de strengste jurisdictie de architectuur bepaalt. Als een workflow moet voldoen aan de EU AI Act voor Europese gebruikers, zal dezelfde workflow niet falen voor Amerikaanse, Britse, Japanse of Singaporese verplichtingen als deze is ontworpen tegen de EU-norm. Het ontwerpen van de deployment tegen de strengste norm — inclusief het vermogen van de inzetter om per verzoek datahandling aan te tonen — is wat on-prem in 2026 de structureel eenvoudigere standaard maakt voor enterprise AI.

Hoe een on-prem AI deployment eruitziet die klaar is voor compliance in 2026

De vorm waarin wij leveren — en de vorm die compliance beoordelaars waarmee wij samenwerken vragen — is:

  • Inferentie lokaal bij de klant. Ofwel op het apparaat van de gebruiker, of op een door de klant beheerde server. Er verlaten geen prompts het perimeter.
  • Inhoudsvrije auditlogs. Elke administratieve handeling wordt gelogd met tijdstempel + actor; geen prompts en geen reacties verschijnen in de auditregel. De auditregel is het bewijs; de inhoud is voor de deployer om te bewaren volgens hun eigen bewaarbeleid.
  • Identiteit via de IdP van de klant. OIDC tegen Microsoft Entra ID of Google Workspace, waarbij de bestaande toegangscontroles van de deployer ongewijzigd blijven.
  • Geen door de leverancier beheerde inferentie-tenant. Software Tailor beheert de modelruntime niet en ontvangt geen prompts, reacties of klantdocumenten via dit pad. Organisatie-identiteit, licenties, beleid, serverstatus, geaggregeerd gebruik, audit- en ondersteuningsgegevens kunnen nog steeds een leverancierscontrolplane gebruiken en moeten als een aparte afhankelijkheid worden beoordeeld.

Die laatste inferentie-eigenschap is iets wat cloud LLM-API's structureel niet kunnen repliceren. Het maakt een on-premises product niet automatisch compliant en neemt de noodzaak niet weg om de controlplane, ondersteuningsroutes, modelleveringsketen en klantverantwoordelijkheden te beoordelen.

Achtergrond over hoe wij dit vanaf het begin hebben opgebouwd is te vinden in Waarom wij AI leveren als installeerbare binaries, niet als cloud SaaS. De mogelijkheden die de audit-, identiteit- en beleidslaag implementeren bevinden zich in AI Admin Console.

Referenties

  1. Europese Commissie. "AI Act — Regelgevend kader voor AI." https://digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Geraadpleegd op 2026-06-15.
  2. Europese Commissie. "AI Act treedt in werking." https://digital-strategy.ec.europa.eu/. Geraadpleegd op 15-06-2026.
  3. Stanford HAI. "AI Index Report." https://aiindex.stanford.edu/. Geraadpleegd op 15-06-2026.
  4. NIST. "AI Risk Management Framework (AI RMF 1.0)." https://www.nist.gov/itl/ai-risk-management-framework. Geraadpleegd op 15-06-2026.
  5. OECD AI Policy Observatory. "Nationale AI-beleidslijnen." https://oecd.ai/. Geraadpleegd op 15-06-2026.