# AI Act in de praktijk: wat bedrijven in 2026 moeten doen [Naar de inhoud](#lm-inhoud)Netwerk/NL[EN](/en/)[Hubhub.llmnet.nlModellen vergelijken op taak, taal, kosten en licentie.](https://hub.llmnet.nl/)[Communitycommunity.llmnet.nlPrompttechnieken, patronen en systeemprompts.](https://community.llmnet.nl/)[APIapi.llmnet.nlLLM's robuust in software: rate limits, routing, structured output.](https://api.llmnet.nl/)[Consultancyconsultancy.llmnet.nlAI invoeren in een organisatie, van pilot tot productie.](https://consultancy.llmnet.nl/)[Nieuwsnieuws.llmnet.nlOntwikkelingen in AI, geduid voor Nederland.](https://nieuws.llmnet.nl/)[Benchmarkbenchmark.llmnet.nlZelf meten wat AI-kwaliteit is, voor jouw taken.](https://benchmark.llmnet.nl/)[Vacaturesvacatures.llmnet.nlAI-rollen, salarissen en carrièrepaden in Nederland.](https://vacatures.llmnet.nl/)[Lerenleren.llmnet.nlAI-concepten in gewoon Nederlands, van beginner tot bouwer.](https://leren.llmnet.nl/)[Gidsgids.llmnet.nlAI privé draaien op eigen Mac, pc, NAS of thuisserver.](https://gids.llmnet.nl/)[Directorydirectory.llmnet.nlHet AI-ecosysteem in kaart: tools, modellen, bedrijven.](https://directory.llmnet.nl/)[Radarradar.llmnet.nlSignalen uit X, onderzoek en communities voor indie developers.](https://radar.llmnet.nl/)[llmnet.nl — hoofdsite](https://llmnet.nl/)[](https://x.com/intent/post?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fai-act-in-de-praktijk-wat-bedrijven-in-2026-concreet-moeten-doen&text=AI%20Act%20in%20de%20praktijk%3A%20wat%20bedrijven%20in%202026%20moeten%20doen)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fai-act-in-de-praktijk-wat-bedrijven-in-2026-concreet-moeten-doen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fai-act-in-de-praktijk-wat-bedrijven-in-2026-concreet-moeten-doen&title=AI%20Act%20in%20de%20praktijk%3A%20wat%20bedrijven%20in%202026%20moeten%20doen)[](#)[](https://x.com/intent/post?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fai-act-in-de-praktijk-wat-bedrijven-in-2026-concreet-moeten-doen&text=AI%20Act%20in%20de%20praktijk%3A%20wat%20bedrijven%20in%202026%20moeten%20doen)[](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fai-act-in-de-praktijk-wat-bedrijven-in-2026-concreet-moeten-doen)[](https://www.reddit.com/submit?url=https%3A%2F%2Fnieuws.llmnet.nl%2Fai-act-in-de-praktijk-wat-bedrijven-in-2026-concreet-moeten-doen&title=AI%20Act%20in%20de%20praktijk%3A%20wat%20bedrijven%20in%202026%20moeten%20doen)[](#) # AI Act in de praktijk: wat bedrijven in 2026 concreet moeten doen Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) De inwerkingtreding van de Europese AI-verordening (EU AI Act) is geen abstract juridisch vergezicht meer, maar een directe operationele realiteit voor iedere organisatie die software ontwikkelt, integreert of afneemt. Waar het publieke debat zich lange tijd concentreerde op ethische principes en theoretische risicocategorieën, dwingt het wettelijke handhavingskader in 2026 tot harde technische en organisatorische keuzes. Organisaties die kunstmatige intelligentie toepassen binnen HR-processen, kredietbeoordeling, klantenservice of geautomatiseerde documentverwerking kunnen niet langer volstaan met informele experimenten. In het overzicht over de [AI Act-tijdlijn en de inwerkingtreding in 2026](https://nieuws.llmnet.nl/ai-act-tijdlijn-wat-er-in-2026-daadwerkelijk-in-werking-is-getreden) staat een chronologisch overzicht van alle formele termijnen en publicatiedata; in dit artikel verschuift het perspectief naar de directe implementatiepraktijk binnen organisaties. We behandelen hoe een realistisch intern compliance-programma wordt ingericht, waar de technische knelpunten zitten bij logging en datakwaliteit, en hoe bedrijven hun rol als deployer of provider zuiver afbakenen zonder te verdrinken in bureaucratische overhead. ## 1. Bepaal de rolverdeling: Provider versus Deployer De eerste en meest cruciale stap bij elke compliance-audit onder de AI Act is het vaststellen van de exacte juridische rol van de organisatie per individueel systeem. De verordening maakt een scherp onderscheid tussen de provider (aanbieder) die een AI-systeem ontwikkelt of onder eigen handelsnaam op de markt brengt, en de deployer (gebruiker) die een bestaand systeem inzet binnen de eigen professionele activiteiten. De verplichtingen voor providers zijn aanzienlijk zwaarder en omvatten onder meer conformiteitsbeoordelingen, technische dossiers en CE-markeringen. Veel Nederlandse bedrijven verkeren in de veronderstelling dat zij louter deployer zijn omdat zij gebruikmaken van externe API's van grote technologieleveranciers. Dat is een gevaarlijke misvatting. Zodra een organisatie een bestaand basismodel fine-tunt met specifieke bedrijfsdata, de functionaliteit wezenlijk wijzigt, of het model integreert in een nieuw product onder het eigen merk, kan de organisatie juridisch promoveren tot provider. Dit staat bekend als de 'substantiele wijziging' (substantial modification). De zware provider-verplichtingen verschuiven daarmee integraal naar de partij die de aanpassing heeft doorgevoerd. Wie zuiver als deployer opereert, is niet vrijgesteld van verplichtingen. Deployers moeten toezien op correct gebruik volgens de instructies van de leverancier, zorgen voor menselijk toezicht door gekwalificeerd personeel, invoergegevens controleren op relevantie en representativiteit, en operationele logs bewaren zolang die onder hun controle vallen. Wie zijn rolverdeling niet formeel per use-case vastlegt in een register, loopt direct vast bij een eventuele controle door toezichthoudende instanties. ## 2. Risicoclassificatie van interne en externe systemen De AI Act hanteert een risicogebaseerde benadering met vier niveaus: onaanvaardbaar risico (verboden praktijken), hoog risico, specifiek transparantierisico, en minimaal risico. In 2026 zijn de verbodsbepalingen reeds van kracht. Dat betekent dat systemen voor sociale scoring, manipulatieve subliminale beïnvloeding of realtime biometrische identificatie in openbare ruimtes categorisch verboden zijn, op enkele strikt gedefinieerde wetshandhavingsuitzonderingen na. De grootste praktische uitdaging bevindt zich in de categorie hoog risico (High-Risk AI Systems). Bijlage III van de verordening wijst specifieke domeinen aan die direct van toepassing zijn op het Nederlandse bedrijfsleven: - Personeelsbeheer en HR: Software voor geautomatiseerde cv-screening, het rangschikken van sollicitanten, prestatiebeoordeling of geautomatiseerde besluitvorming over promoties en ontslag. - Financiële dienstverlening en kredietwaardigheid: Algoritmen die de kredietscore van natuurlijke personen vaststellen of risico-inschattingen maken voor levens- en zorgverzekeringen. - Toegang tot essentiële diensten: Beoordeling van toelating tot onderwijsinstellingen of systemen die bepalen of iemand in aanmerking komt voor overheidsuitkeringen en subsidies. - Kritieke infrastructuur: AI-componenten die worden ingezet in de beveiliging of aansturing van energie-, water- en transportnetwerken. Voor systemen die onder deze noemer vallen, geldt dat organisaties vóór ingebruikname moeten kunnen aantonen dat het systeem voldoet aan de eisen rond risicobeheersystemen, datagovernance, technische documentatie, logging, transparantie, menselijk toezicht en robuustheid. Om te begrijpen hoe dit Nederlandse toezichtslandschap is verdeeld tussen de Autoriteit Persoonsgegevens en sectorale toezichthouders, biedt het dossier over [AI-toezicht in Nederland en de rol van toezichthouders](https://nieuws.llmnet.nl/ai-toezicht-nederland) een gedetailleerd overzicht van bevoegdheden en inspectiekaders. Risicocategorie | Voorbeelden in de praktijk | Kernverplichtingen in 2026 | Verboden (Onaanvaardbaar) | Social scoring, cognitieve gedragsmanipulatie, emotiedetectie op de werkvloer | Directe uitfasering en staken van alle operationele processen | Hoog risico (High-Risk) | CV-ranking, kredietbeoordeling, triage in klantacceptatie, kritieke infra | Conformiteitsbeoordeling, risicomanagement, datagovernance, logging, menselijk toezicht | Transparantierisico | Klantenservice-chatbots, deepfakes, AI-gegenereerde marketingcontent | Actieve informatieplicht: gebruikers expliciet informeren over interactie met AI | Minimaal risico | Spamfilters, code-autocompletion voor interne tooling, vertaaldiensten | Geen dwingende wettelijke eisen; vrijwillige gedragscodes aanbevolen | ## 3. Transparantie-eisen en de AI-geletterdheid van medewerkers Naast de zware verplichtingen voor hoog-risicosystemen legt artikel 50 van de AI Act directe transparantieverplichtingen op aan een veel bredere groep toepassingen. Een organisatie die een chatbot of AI-assistent inzet voor klantcontact, moet eindgebruikers op duidelijke en ondubbelzinnige wijze informeren dat zij communiceren met een kunstmatig intelligent systeem, tenzij dit uit de context overduidelijk blijkt. Daarnaast moet synthetisch gegenereerde audio-, video- of tekstcontent die betrekking heeft op zaken van algemeen belang herkenbaar worden gemarkeerd als zijnde kunstmatig gegenereerd. Een vaak over het hoofd gezien artikel met directe werking is artikel 4 van de verordening: de verplichting tot AI-geletterdheid (AI literacy). Bedrijven en instellingen zijn wettelijk verplicht ervoor te zorgen dat hun personeel en andere personen die namens hen met AI-systemen werken, over voldoende kennis en vaardigheden beschikken. Deze verplichting is evenredig aan de context, de doelgroep en de potentiële risico's van de ingezette technologie. In de praktijk betekent dit dat een generiek beleidsdocument niet volstaat. Medewerkers die AI-tools gebruiken voor hun dagelijkse werkzaamheden moeten getraind zijn in het herkennen van hallucinaties, het beoordelen van vooringenomenheid (bias), en het respecteren van privacy- en auteursrechtelijke grenzen. Organisaties moeten aantoonbaar kunnen maken dat zij gerichte trainingen aanbieden en dat medewerkers begrijpen wanneer een AI-uitvoer kritisch getoetst moet worden door een menselijke expert. ## 4. Datagovernance en bias-mitigatie bij modelselectie Voor hoog-risicosystemen stelt artikel 10 van de AI Act extreem strenge eisen aan de datasets die worden gebruikt voor training, validatie en testen. Deze datasets moeten worden onderworpen aan passende datagovernance- en beheerspraktijken. Dit omvat onder meer het vooraf onderzoeken van mogelijke vooroordelen (biases) die kunnen leiden tot discriminatie of oneerlijke uitkomsten, en het nemen van passende maatregelen om deze vooroordelen te corrigeren. Bedrijven die kant-en-klare taalmodellen of visuele modellen afnemen via cloudproviders lopen hier tegen een praktisch dilemma aan: de onderliggende trainingsdata van grote commerciële modellen is zelden volledig openbaar. Als deployer kan een organisatie niet direct in de trainingsdata van de leverancier snijden. De verantwoordelijkheid van de deployer verschuift daarom naar het zorgvuldig auditen van de invoerdata en het systematisch evalueren van de uitvoerdata. Een robuust datagovernance-proces vereist dat organisaties de volgende punten structureel borgen: - Representativiteit: Toetsen of de data die aan het model wordt gevoed representatief is voor de specifieke doelgroep waarop het systeem wordt toegepast. - Foutdetectie en data-hygiëne: Controleren op ontbrekende waarden, foutieve annotaties en statistische anomalieën vóórdat gegevens in geautomatiseerde besluitvormingsketens worden opgenomen. - Bias-audits: Periodiek testen van modeluitkomsten op subgroepverschillen aan de hand van gestandaardiseerde metrieken zoals disparate impact ratio of equalized odds. Om deze normen concreet in te bedden in kwaliteitsmanagementsystemen sluiten steeds meer organisaties aan bij internationale kaders; in het artikel over [AI-standaarden en ISO-normering zoals ISO/IEC 42001](https://nieuws.llmnet.nl/ai-standaarden-en-iso-normering) wordt uitgelegd hoe deze certificeringen als operationeel bewijsmiddel dienen tijdens inspecties. ## 5. Logging, traceerbaarheid en technische monitoring Hoog-risico AI-systemen moeten technisch zo zijn ontworpen dat zij automatisch logs bijhouden gedurende hun gehele levenscyclus. Deze logging-functionaliteit is geen optionele debug-functionaliteit, maar een wettelijke vereiste om de traceerbaarheid van de werking van het systeem te garanderen. Doel hiervan is dat incidenten, substantiële afwijkingen of discriminatoire patronen achteraf gereconstrueerd en geanalyseerd kunnen worden door toezichthouders. De logging moet minimaal de operationele periodes registreren, de inputdata waarmee het systeem is aangeroepen, de referentie naar de gebruikte modelversie en systeemparameters, en de gegenereerde outputs inclusief betrouwbaarheidsscores. Voor deployers geldt specifiek dat zij deze logs moeten bewaren voor een periode die passend is bij het beoogde doel van het systeem, met een minimale termijn van zes maanden, tenzij andere sectorale wetgeving langere bewaartermijnen voorschrijft. { "timestamp": "2026-08-15T14:22:01.412Z", "system_id": "hr-recruitment-ranker-v2", "model_version": "mistral-large-2407-instruct", "deployment_mode": "high_risk_annex_iii_4a", "input_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855", "parameters": { "temperature": 0.0, "top_p": 1.0, "seed": 42 }, "metrics": { "latency_ms": 320, "confidence_score": 0.88, "human_override_triggered": false }, "compliance_status": "verified_input_sanitized" } Een cruciaal aandachtspunt bij logging is de wisselwerking met de Algemene Verordening Gegevensbescherming (AVG). Het loggen van volledige prompts en modeluitvoeringen kan ertoe leiden dat persoonsgegevens of bijzondere persoonsgegevens onbedoeld langdurig worden opgeslagen in logbestanden. Organisaties moeten pseudonimisatie, hashing of geautomatiseerde PII-maskering (Personally Identifiable Information) toepassen op de inputstromen vóórdat deze worden weggeschreven naar audittrails. ## 6. Menselijk toezicht en het 'Human-in-the-loop'-principe Het vereiste van menselijk toezicht (Human Oversight, artikel 14) dwingt organisaties ertoe om de verhouding tussen mens en machine formeel te herzien. De wet eist dat natuurlijke personen aan wie het toezicht is opgedragen, de capaciteiten en beperkingen van het hoog-risicosysteem volledig begrijpen. Zij moeten in staat zijn om de neiging tot 'automatiseringstrouwheid' (automation bias) — het blindelings vertrouwen op geautomatiseerde uitkomsten — actief te weerstaan. Er zijn drie dominante vormen van menselijk toezicht in productieomgevingen: - Human-in-the-loop (HITL): Elke individuele beslissing vereist een actieve goedkeuring door een menselijke operator voordat de actie effect sorteert. Dit is de norm bij beslissingen met aanzienlijke juridische of financiële gevolgen. - Human-on-the-loop (HOTL): Het systeem handelt autonoom binnen vooraf gedefinieerde parameters, maar een menselijke toezichthouder monitort het proces in realtime en heeft te allen tijde de mogelijkheid om in te grijpen of het proces te stoppen. - Human-in-command (HIC): De mens houdt toezicht op het gehele operationele kader, definieert wanneer het systeem mag worden ingezet en kan het systeem op elk moment buiten werking stellen (de spreekwoordelijke 'noodknop'). De opkomst van zelfstandig handelende multi-agent systemen zet dit toezichtsmodel zwaar onder druk. In het achtergrondartikel over [Agentic AI en autonome besluitvormingsloops](https://nieuws.llmnet.nl/agentic-ai) wordt dieper ingegaan op de technische mechanismen waarmee autonome softwareketens opereren en waarom juist daar het risico op ongecontroleerde cascading errors toeneemt. Wanneer agents zelfstandig API-calls uitvoeren en databases manipuleren, vereist de AI Act dat er harde deterministische grenzen worden ingebouwd die voorkomen dat een model zelfstandig buiten zijn toegestane mandaat treedt. ## 7. Leveranciersbeheer, API-gateways en contractuele afspraken Omdat het merendeel van de bedrijven AI-capaciteit inkoopt via externe cloudproviders en API-leveranciers, is leveranciersmanagement een centrale pijler van AI-compliance geworden. Een organisatie kan haar wettelijke verantwoordelijkheden als deployer niet contractueel afwentelen op een leverancier. Als een ingekocht AI-systeem bias vertoont of faalt in productie, blijft de deployer aansprakelijk tegenover de toezichthouder en de betrokken burgers of werknemers. Om grip te houden op modelwijzigingen, downtime en compliance-parameters maken moderne software-architecturen steeds vaker gebruik van tussenlagen. In de technische gids over de [kracht en werking van een LLM API-aggregator](https://api.llmnet.nl/aggregator-uitleg) leest men hoe een centrale gateway helpt bij het dynamisch routeren van aanvragen, het afdwingen van logging en het voorkomen van vendor lock-in. Door een gateway tussen de bedrijfsapplicaties en de AI-aanbieders te plaatsen, kunnen organisaties centraal datamasking toepassen, responstijden monitoren en direct overschakelen naar een ander model wanneer een leverancier zijn voorwaarden of modelgewichten wijzigt. Contractueel moeten bedrijven hun SLA's en inkoopovereenkomsten met AI-leveranciers herzien op de volgende punten: - Gedetailleerde modelkaarten en systeeminformatie: De leverancier moet gedocumenteerde informatie verstrekken over de capaciteiten, beperkingen, bedoelde gebruiksscenario's en bekende foutmarges van het model. - Wijzigingsbeheer (Change Management): Verplichting voor de leverancier om updates van modelgewichten of systeem-prompts vooraf aan te kondigen, zodat de afnemer regressietests kan uitvoeren. - Data-gebruiksrechten: Expliciete garanties dat ingevoerde bedrijfsprompts en klantdata niet worden hergebruikt voor het hertrainen of verfijnen van publieke basismodellen van de leverancier. ## 8. Stappenplan voor de interne compliance-audit in 2026 Om te voorkomen dat compliance een ad-hoc reactie wordt op externe incidenten, moeten organisaties een gestructureerde aanpak hanteren. Het onderstaande stappenplan schetst de noodzakelijke stappen om binnen de organisatie een beheersbaar en controleerbaar AI-governancekader op te zetten: - Inventarisatie en Shadow-AI detectie: Breng alle AI-systemen, API-koppelingen, SaaS-tools met ingebouwde AI en experimentele projecten binnen de organisatie in kaart. Blokkeer niet-geautoriseerde tools die bedrijfsdata lekken. - Risico- en rolkwalificatie: Classificeer elk geïnventariseerd systeem volgens de categorieën van de AI Act (minimaal, transparantie, hoog, verboden) en stel per use-case vast of de organisatie optreedt als deployer dan wel als provider. - Gap-analyse op hoog-risicosystemen: Toets bestaande hoog-risicosystemen aan de eisen rond logging, datakwaliteit, menselijk toezicht en technische documentatie. Stel concrete herstelplannen op voor geconstateerde tekortkomingen. - Inrichten van het AI-register: Leg een intern register aan waarin doel, eigenaar, risicoclassificatie, gebruikte databronnen en toezichtsmaatregelen per model eenduidig zijn vastgelegd. - Uitrol van AI-geletterdheidsprogramma's: Train medewerkers en toezichthouders op basis van hun specifieke takenpakket en leg de deelnamebewijzen vast ter onderbouwing van artikel 4. - Continue monitoring en incidentrespons: Richt processen in om drift in modelgedrag te detecteren en definieer een escalatieprocedure voor het melden van ernstige incidenten aan de bevoegde toezichthouder. ## 9. Valkuilen en veelgemaakte denkfouten In de praktijk trappen organisaties regelmatig in dezelfde valkuilen bij de implementatie van de AI Act. De meest voorkomende denkfout is de aanname dat compliance uitsluitend een juridische aangelegenheid is die kan worden opgelost met een set disclaimers en een privacy policy. De AI Act is fundamenteel een technisch-operationele verordening; wie geen inzicht heeft in modelparameters, API-logs, dataconversies en deterministische vangrails, kan de vereiste documentatie simpelweg niet leveren. Een tweede valkuil is het blind vertrouwen op marketingclaims van softwareleveranciers die claimen dat hun product '100% AI Act compliant' is. Compliance is contextafhankelijk: een HR-tool kan technisch vlekkeloos zijn gebouwd, maar als de deployer de tool inzet zonder adequaat menselijk toezicht of met niet-representatieve invoerdata, overtreedt de deployer direct de wet. Certificering van de leverancier ontslaat de gebruiker nooit van zijn eigen zorgplicht. Tot slot leidt overmatige bureaucratie vaak tot schijnveiligheid. Documenten die eenmaal worden opgesteld en vervolgens in een la verdwijnen, beschermen niet tegen modeldrift, hallucinaties of operationele fouten. Succesvolle compliance vraagt om een pragmatische integratie van wettelijke kaders in de bestaande softwareontwikkelingscyclus (CI/CD) en IT-beheerprocessen van de organisatie.