AI-trends Gepubliceerd 2026-06-15 · 7 min leestijd

EU AI Act in 2026: wat verandert on-prem-uitrol aan compliance

De verplichtingen van de Act voor deployers van hoog-risico AI worden gefaseerd ingevoerd in 2026. On-prem-uitrol ontwijkt de regelgeving niet, maar verandert wel welke verplichtingen praktisch haalbaar zijn, en welke door cloud-SaaS in het geheel niet vervuld kunnen worden.

De EU AI Act is in augustus 2024 in werking getreden, met bepalingen die gefaseerd worden ingevoerd over een venster van twee tot drie jaar ^[1]^[2]. De meeste enterprise-compliance-gesprekken hebben zich tot dusver gericht op de vraag of een workflow überhaupt binnen de categorie "hoog-risico" valt. Halverwege 2026 verschuift het gesprek naar een praktischer vraag: aangenomen dat de workflow wel binnen het toepassingsgebied valt, welke uitrolarchitecturen stellen u daadwerkelijk in staat de deployer-verplichtingen te vervullen, en welke doen dat stilletjes niet?

Die tweede vraag is waar on-premises-uitrol ophoudt een stilistische voorkeur te zijn en een structurele match wordt.

Wat de Act vraagt van deployers van hoog-risico AI

De Act maakt onderscheid tussen de provider van een AI-systeem en de deployer ervan ^[1]. Een bank die een LLM-API van een derde partij gebruikt om leningaanvragen te scoren is de deployer, niet de provider. Deployers van hoog-risico systemen dragen verplichtingen waaronder: het waarborgen van menselijk toezicht, het monitoren van de werking van het systeem, het bijhouden van logs gedurende een passende periode, het opschorten van het gebruik wanneer het systeem een risico vormt voor fundamentele rechten, en het op verzoek aantonen van deze capaciteiten.

Verscheidene van deze verplichtingen zijn eenvoudig wanneer de deployer de runtime controleert. De verplichting om "logs gedurende een passende periode bij te houden" is mechanisch eenvoudig als de inferentie plaatsvindt op een server die de deployer in eigendom heeft en de logs in de SIEM van de deployer terechtkomen. De verplichting tot "opschorting van het gebruik" is eveneens triviaal als de deployer het model kan uitschakelen op de eigen infrastructuur.

Dezelfde verplichtingen worden moeilijker wanneer de inferentie draait op een cloud-LLM-API die de deployer niet exploiteert. De logs die de deployer kan produceren zijn beperkt tot wat de provider blootstelt. Opschorting van gebruik vereist medewerking van de provider. Gelijktijdig aantonen welke gegevens door het systeem zijn gestroomd vereist vertrouwen in de pipeline van de provider.

Waar cloud-LLM-API's zich in de regelgeving bevinden

Niets van dit alles maakt cloud-LLM-API's non-compliant. Artikel voor artikel kunnen providers en deployers van cloud-gehoste AI voldoen aan de verplichtingen van de Act. De frictie is operationeel, niet juridisch: de deployer moet compliance over een leveranciersgrens heen samenstellen, auditen en aantonen, vaak voor workflows die duizenden inferenties per dag uitvoeren.

De longitudinale AI Index van Stanford HAI heeft de bijbehorende verschuiving in enterprise-uitgaven gevolgd ^[3]: de steilste groei over 2023–2025 zat niet in algemene generatieve AI, maar in de ondersteunende tooling — observability, governance, prompt-logging, contentclassificatie, jailbreak-detectie. Het grootste deel van die uitgaven bestaat om de kloof te overbruggen tussen wat cloud-LLM-API's van nature blootstellen en wat een deployer in een regulatoire context moet aantonen.

Die kloof is het structurele voordeel van inferentie draaien op hardware die de deployer in eigendom heeft. Elke vraag van het type "is dit gebeurd?" valt terug op een vraag die de deployer kan beantwoorden uit de eigen logs.

Wat on-prem u niet gratis oplevert

Drie deployer-verplichtingen uit de AI Act worden niet automatisch vervuld door een on-prem-uitrol, en het is de moeite waard die expliciet te benoemen:

Menselijk toezicht. De Act vereist betekenisvol toezicht op hoog-risico AI, waarbij mensen outputs kunnen interpreteren en kunnen ingrijpen. Het lokaal draaien van het model plaatst geen mens in de lus; het ontwerp van de workflow doet dat.
Monitoring op drift en onveilig gedrag. De deployer moet het systeem doorlopend monitoren. On-prem-uitrol maakt het leidingwerk triviaal (de gegevens zijn lokaal), maar het beleid ("hoe ziet drift eruit voor deze workflow?") moet nog steeds gedefinieerd worden.
Doorgegeven provider-verplichtingen. Wanneer de on-prem-uitrol is gebouwd op een model van een derde partij (bijvoorbeeld een open-weight model onder een niet-commerciële licentie, of een leveranciersmodel dat als binary wordt geleverd), moet de deployer nog steeds de vereiste disclosures van de provider zichtbaar maken.

Het structurele voordeel van on-prem ligt op de assen van gegevensverwerking en aantoonbaarheid, niet op de as van beleid. Beleid moet worden opgeschreven en gehandhaafd, ongeacht waar de GPU zich bevindt.

Hoe dit zich verhoudt tot de VS, het VK en andere jurisdicties

De EU AI Act is het meest voorschrijvende van de grote kaders. Het Amerikaanse NIST AI RMF ^[4] kiest een vrijwillige, kader-gebaseerde benadering, en de OECD AI Policy Observatory ^[5] volgt hoe nationale overheden buiten de EU convergeren op grotendeels vergelijkbare principes (risicogebaseerd toezicht, transparantieverplichtingen, regels voor gegevensverwerking).

Voor een multinationale deployer is het praktische effect dat de strengste jurisdictie de architectuur bepaalt. Als een workflow moet voldoen aan de EU AI Act voor Europese gebruikers, dan zal dezelfde workflow niet falen op verplichtingen in de VS, het VK, Japan of Singapore wanneer deze is ontworpen tegen de Europese lat. Het ontwerpen van de uitrol tegen de strengste lat — inclusief het vermogen van de deployer om per verzoek gegevensverwerking aan te tonen — is wat on-prem in 2026 tot de structureel eenvoudigste default maakt in enterprise-AI.

Hoe een on-prem AI-uitrol eruit ziet die klaar is voor compliance in 2026

De vorm waarin wij leveren — en de vorm waar de compliance-reviewers met wie wij werken om vragen — is:

Inferentie lokaal bij de klant. Hetzij op het apparaat van de gebruiker, hetzij op een door de klant geëxploiteerde server. Geen prompts verlaten de perimeter.
Inhoudvrije auditlogs. Elke administratieve actie wordt gelogd met tijdstempel + actor; geen prompts en geen responses verschijnen in de auditregel. De auditregel is het bewijs; de inhoud blijft bij de deployer onder diens eigen bewaarbeleid.
Identiteit via de IdP van de klant. OIDC tegen Microsoft Entra ID of Google Workspace, waarbij de bestaande toegangscontroles van de deployer onveranderd gelden.
Geen tenant aan leverancierszijde. De leverancier (wij) exploiteert de runtime niet, ziet de gegevens niet, en vormt geen single point of failure voor de compliance-positie van de deployer.

Die laatste eigenschap is degene die cloud-LLM-API's structureel niet kunnen repliceren — en dat is waarom on-prem-uitrol in 2026 het dominante patroon is in de gereguleerde-enterprise-hoek van de markt.

Achtergrond over hoe wij hier vanaf het begin omheen hebben gebouwd staat in Waarom wij AI leveren als installeerbare binaries, niet als cloud-SaaS. De capaciteiten die het audit-, identiteits- en beleidsoppervlak implementeren bevinden zich in AI Admin Console.

Referenties

European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu. Geraadpleegd op 2026-06-15.
European Commission. "AI Act enters into force." digital-strategy.ec.europa.eu. Geraadpleegd op 2026-06-15.
Stanford HAI. "AI Index Report." aiindex.stanford.edu. Geraadpleegd op 2026-06-15.
NIST. "AI Risk Management Framework (AI RMF 1.0)." nist.gov/itl/ai-risk-management-framework. Geraadpleegd op 2026-06-15.
OECD AI Policy Observatory. "National AI policies." oecd.ai. Geraadpleegd op 2026-06-15.

Loop deployer-verplichtingen door tegen een echte workload.

Een gratis pilot van één week loopt het compliance-team van de klant door deployer-verplichtingen tegen een reëel stuk werk, op lokale inferentie, met de IdP en het audittrail van de klant.

Start een gratis pilot van één week