Wanneer technische documentatie van toepassing is en wat daarna te doen

Technische documentatie is een specifieke plicht uit de AI Act wanneer een onderneming aanbieder is van een AI-systeem met een hoog risico. Artikel 11 vereist dat het dossier vóór marktintroductie of ingebruikname wordt opgesteld, actueel blijft en duidelijk genoeg is voor autoriteiten en aangemelde instanties om conformiteit te beoordelen. Bijlage IV bepaalt de minimuminhoud.

Niet elk SaaS-bedrijf dat een AI-API gebruikt heeft dus een volledig dossier nodig. Het antwoord hangt af van systeemgrens, rol en hoogrisicoclassificatie. Ook zonder directe plicht kan proportionele documentatie productgovernance, leverancierscontrole, klantvragen, incidenten en latere herbeoordeling ondersteunen.

Bevestig systeem, rol en classificatie

Beschrijf het hele systeem: beoogd doel, gebruikers, betrokken personen, invoer, uitvoer, integraties, context en invloed van de uitkomst. Een extern model kan slechts één onderdeel van het SaaS-product zijn.

Bepaal daarna de rol. Wie een hoogrisicosysteem ontwikkelt en onder eigen naam aanbiedt, is doorgaans aanbieder; een klant kan gebruiksverantwoordelijke zijn. Rebranding, een ingrijpende wijziging of een nieuw doel kan verantwoordelijkheden verschuiven. Beoordeel vervolgens de twee hoofdroutes van artikel 6: gereguleerde producten in bijlage I en toepassingen in bijlage III. Zie de gids voor SaaS-aanbieders.

Wanneer artikel 11 geldt

Artikel 11 en bijlage IV zien op documentatie van hoogrisicosystemen en leggen de kernplicht bij de aanbieder. Na Verordening (EU) 2026/1744 gelden de regels voor systemen uit bijlage III vanaf 2 december 2027 en voor systemen in producten uit bijlage I vanaf 2 augustus 2028.

Wacht niet tot die data. Productrecht, privacy, contracten, beveiliging en klantonderzoek kunnen nu al vergelijkbaar bewijs vragen. Vroeg beginnen voorkomt reconstructie van versies, data, tests en beslissingen.

Is het systeem niet hoog risico of is het bedrijf alleen gebruiksverantwoordelijke, dan is een volledig dossier mogelijk niet vereist. Leg toch beslissing, feiten, reviewer en herbeoordelingstriggers vast. Een nieuw gevoelig doel, materiële model- of datawijziging, nieuwe markt of grotere invloed op personen moet de analyse heropenen.

Minimale dekking

Bijlage IV vraagt ten minste:

1. Identiteit, doel, versies, gebruikers en gebruiksvoorwaarden.
2. Ontwikkeling, architectuur, componenten en ontwerpbeslissingen.
3. Herkomst van data, validatie, tests en prestatiebeperkingen.
4. Risico's, controles, menselijk toezicht, logging en escalatie.
5. Robuustheid, cyberbeveiliging en voorzienbare ongewenste uitkomsten.
6. Wijzigingen, incidenten en monitoring na marktintroductie.
7. Normen, conformiteitsroute en goedkeuringen.
8. Traceerbaarheid van elke claim naar gecontroleerd bewijs.

Het dossier mag een index zijn die naar gecontroleerde bronnen verwijst. Stabiele links, rechten, versies en bewaring zijn belangrijker dan paginatal.

Praktische werkwijze

1. Keur de scope goed: leg identificatie, doel, grens, rol, classificatie en aannames vast.
2. Maak de bijlage-IV-index: noteer bron, eigenaar, versie, status, reviewer en updatetrigger.
3. Laat bewijs bij de echte eigenaar: product bezit het doel; engineering de architectuur; data of ML de evaluaties; security de maatregelen; compliance de mapping.
4. Sluit kritieke hiaten eerst: prioriteer classificatie, prestaties, risico's, toezicht en releasegoedkeuring.
5. Koppel wijzigingen: doel, modellen, data, drempels, gebruikers, integraties of controles moeten updates en zo nodig nieuwe tests activeren.
6. Test vindbaarheid: een onafhankelijke reviewer moet een prestatieclaim, controle, toezichtspad en release naar bewijs kunnen volgen.

De checklist voor technische documentatie geeft een gedetailleerde structuur. Klantantwoorden moeten ook overeenkomen met AI-controles die inkopers vragen.

Veelgemaakte fouten

• Met een sjabloon beginnen voordat scope en bewijs vaststaan.
• Alleen het model in plaats van het hele systeem documenteren.
• Leveranciersdocumentatie als bewijs voor de eigen configuratie zien.
• Een laagrisicoconclusie nooit opnieuw beoordelen.
• Een auditdossier los van releases en wijzigingen beheren.

Voorbeeld: AI-ondersteunde sollicitantselectie

Bij een functie die sollicitaties rangschikt, moet het team doel, aanbieder, systeemgrens en analyse van bijlage III bepalen. Is het bedrijf aanbieder van een hoogrisicosysteem, dan omvat het dossier productieversies, data, klantworkflow, groepsevaluaties, metrieken, beperkingen, menselijke beoordeling, logging, beveiliging en monitoring. Een gewijzigd model of drempel moet de gekoppelde registraties heropenen.

FAQ

Wanneer geldt dit voor SaaS-teams?

Artikel 11 geldt voor aanbieders van hoogrisicosystemen. Bevestig grens, rol en classificatie voordat u een volledig dossier als wettelijke plicht behandelt.

Wat moet eerst worden vastgelegd?

Doel, grens, rol, classificatie, productieversie, architectuur, risico's, evaluaties, controles, instructies en eigenaars.

Mogen engineeringdocumenten worden hergebruikt?

Ja. Verwijs naar actuele, gecontroleerde bronnen en toon in de index welke eis en versie ze dekken.

Bronnen

• Verordening (EU) 2024/1689, artikelen 6 en 11 en bijlagen I, III en IV.
• Verordening (EU) 2026/1744 over documentatie en toepassingsdata.
• Europese Commissie, “AI Act”, actuele implementatietijdlijn.