Vanaf 2 december 2027 gelden de verplichtingen voor implementatoren onder de EU AI-verordening voor hoog-risico AI-systemen die worden gebruikt in biometrie, kritieke infrastructuur, onderwijs, werkgelegenheid, migratie, asiel en grenscontrole [1]. Compliance-teams in 2026 wachten niet tot december 2027 om zich te positioneren. Ze schrijven nu al leveranciersvragenlijsten, en enterprise AI-inkoop loopt vast op die vragenlijsten in een tempo dat weinig te maken heeft met de technologie die wordt ingekocht. De oplossing is geen betere demo. Het is een herkadering van waar het in het inkoopgesprek werkelijk om gaat.

Hoe 'vastlopen' er in 2026 eigenlijk uitziet

Het technische proof-of-concept slaagt. Het model levert bruikbare output op de eigen werklast van de klant. De technische beoordelaar schrijft een positieve notitie en overhandigt het dossier aan inkoop. Daarna blijft het dossier liggen. Drie weken later komt het compliance-team van de klant terug met een memo: "We kunnen onze verplichtingen als implementator niet aantonen voor deze workflow als de inferentie plaatsvindt op een endpoint dat wij niet beheersen."

De enterprise-enquête van a16z identificeerde de vorm van dit patroon terwijl het zich ontwikkelde: dealcycli die "vroeger meer dan een jaar duurden om te sluiten, nu in 2 of 3 maanden worden afgerond" voor producten die aan de nieuwe eisen voldoen [4]. De implicatie werkt ook de andere kant op. Inkoop voor producten die niet aan de nieuwe eisen voldoen, duurt nog steeds een jaar. Sterke technische pilots veranderen daar niets aan.

Wat inkoop eigenlijk moet aantonen

De EU AI-verordening maakt onderscheid tussen de aanbieder van een AI-systeem en de implementator ervan [1]. Een bank die een derdepartij LLM API gebruikt om leningaanvragen te scoren, is de implementator. Verplichtingen voor implementatoren omvatten menselijke supervisie, monitoring, incidentrapportage en het op verzoek aantonen van deze mogelijkheden. Deze verplichtingen gelden voor de bank, niet voor de LLM-leverancier — en het inkoopteam van de bank is het front waar leverancierskeuze bepaalt of de verplichtingen praktisch te voldoen zijn.

Deze richting is niet alleen EU-specifiek. NIST publiceerde op 7 april 2026 een conceptnota voor een AI RMF-profiel over Vertrouwbare AI in Kritieke Infrastructuur [2], de eerste federale afbakening van AI RMF-implementatorverplichtingen voor operators van kritieke infrastructuur in de Verenigde Staten. Het OECD AI Policy Observatory onderhoudt een levend archief "van meer dan 80 jurisdicties en organisaties" [3]. Convergentie tussen jurisdicties over verplichtingen aan de kant van de implementator is de trend, geen uitzondering.

Inkoopteams in gereguleerde sectoren lezen deze signalen en positioneren zich vooraf. Ze kunnen niet wachten tot 2 december 2027 om te ontdekken of een leveranciersarchitectuur hen in staat stelt hun verplichtingen na te komen.

Waarom 'wij zijn SOC 2' het verkeerde antwoord is

Het antwoord met vendor-controles dat historisch gezien de inkoopgesprekken binnen ondernemingen oploste — SOC 2 Type II, ISO 27001, GDPR-conforme DPA — richt zich op vendor-zijde controles. Deze zijn noodzakelijk. Ze zijn niet voldoende voor de deployer-verplichtingen die nu opkomen.

Deployer-verplichtingen vereisen dat de deployer op verzoek kan aantonen welke data door het AI-systeem is verwerkt. Dat is een vraag over de eigen logs van de deployer, niet die van de vendor. Een SOC-2-schoon vendor die prompt en respons in een beheerde cloud bewaart, kan deze kloof niet dichten, omdat de kloof aan de kant van de deployer ligt: de deployer kan geen log produceren van iets wat hij niet ziet.

Dit is de structurele mismatch die het inkoopgesprek blokkeert. Het compliance-team schrijft een memo over de deployer-verplichtingen. De vendor reageert met vendor-zijde certificeringen. De twee partijen passeren elkaar.

De kaderstelling die de blokkade oplost

Drie eigenschappen van de deployment-architectuur, vooraf genoemd in de vendor-vragenlijst, doorbreken de blokkade:

  1. Inference lokaal bij de deployer. Ofwel op het apparaat van de gebruiker of op een server die de deployer beheert. Prompts en responsen verlaten nooit de perimeter van de deployer.
  2. Inhoudsvrije auditlogs die eigendom zijn van de deployer. Elke administratieve actie wordt gelogd met tijdstempel en actor, in de SIEM van de deployer. Geen prompts of responsen verschijnen in de auditregel. De regel is het bewijs; de inhoud is voor de deployer om te bewaren volgens het eigen retentiebeleid.
  3. Identiteit via de IdP van de deployer. OIDC tegen Microsoft Entra ID of Google Workspace. De bestaande toegangscontroles en SSO-beleid van de deployer blijven ongewijzigd van toepassing.

Dit zijn geen vendor-eigenschappen om te certificeren. Het zijn deployment-architectuureigenschappen die gespecificeerd moeten worden. Zodra de vendor-vragenlijst hiertegen is opgesteld, schrijft het compliance-memo zichzelf: elke deployer-verplichting heeft een corresponderende architectuureigenschap waar de deployer naar kan verwijzen.

Hoe dit eruitziet in de vorm die wij leveren

Software Tailor's AI Suite wordt geleverd als desktop-installers die communiceren met een lokaal inference-proces. AI Admin Console is het beheersoppervlak dat het IT-team van de deployer gebruikt om beleid af te dwingen, licenties te beheren en audit te tonen. Zes Fortune Global 500-klanten uit de farmacie, financiën, overheid, juridische sector, defensie en energie hebben sinds 2007 tegen deze vorm geïmplementeerd (voormalige klanten), en elk van die trajecten doorliep een versie van bovenstaande kaderstelling voordat het contract werd getekend.

De snelste manier om dit concreet te maken is het doorlopen van een echte workload. Een gratis pilot van 1 week plaatst het model op de hardware van de klant, de auditregel in de SIEM van de klant, en identiteit via de IdP van de klant — genoeg voor het compliance-team om het memo te schrijven tegen de verplichtingen waarmee ze daadwerkelijk geconfronteerd worden.

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-03.
  2. NIST. "AI Risk Management Framework." https://www.nist.gov/itl/ai-risk-management-framework. Geraadpleegd op 2026-06-03. Het conceptdocument Kritieke Infrastructuur werd uitgebracht op 7 april 2026.
  3. OECD AI Policy Observatory. "Policy Navigator dashboards." https://oecd.ai/en/dashboards. Geraadpleegd op 2026-06-03.
  4. Andreessen Horowitz. "State of Generative AI in the Enterprise." https://a16z.com/generative-ai-enterprise-2024/. Gepubliceerd op 21 maart 2024. Geraadpleegd op 2026-06-03.