Technische documentatie: praktische gids voor SaaS-teams

Technische documentatie voor een AI-systeem is geen architectuuroverzicht dat aan het einde van een project wordt geschreven. Het is het gecontroleerde bewijsdossier dat uitlegt wat het systeem moet doen, hoe het is gebouwd, welke data en modellen het gebruikt, hoe het presteert, welke risico's zijn vastgesteld, welke maatregelen die beperken en hoe wijzigingen na de release worden beheerd.

Voor aanbieders van AI-systemen met een hoog risico vereist artikel 11 van de AI Act dat het dossier vóór het in de handel brengen of in gebruik nemen wordt opgesteld, actueel blijft en duidelijk genoeg is voor autoriteiten en aangemelde instanties om conformiteit te beoordelen. Bijlage IV bepaalt de minimale inhoud. Een SaaS-team moet daarom bewijs uit product, engineering, data, security, legal en kwaliteit tijdens de ontwikkeling verzamelen, niet tijdens een audit reconstrueren.

De verplichting geldt niet automatisch voor elke AI-functie. De scope hangt af van classificatie en bedrijfsrol. Documenteer die eerst en maak het dossier evenredig aan de werkelijke verplichtingen en risico's.

Waarom dit praktisch telt

Een goed dossier toont dat tests passen bij het beoogde doel, koppelt klantantwoorden aan gecontroleerd bewijs en helpt bepalen of een wijziging van model, data, drempel of workflow een herbeoordeling vereist. De beoordelaar krijgt een samenhangend verhaal in plaats van contextloze screenshots.

Het verbindt producteisen, architectuurdiagrammen, model cards, datalijnen, evaluaties, risicoregisters, securitytests, menselijk toezicht, logs, incidentprocessen, releasegoedkeuringen en post-market monitoring. Een centrale index kan naar deze bronnen verwijzen zonder alles te dupliceren.

Dit ondersteunt ook de veranderende AI-governanceverwachtingen voor SaaS-leveranciers.

Bevestig de scope

Bepaal of de software een AI-systeem en een systeem met hoog risico is, en welke rol de onderneming vervult. Wie onder eigen naam ontwikkelt en verkoopt kan aanbieder zijn. Wie een systeem van een ander gebruikt kan gebruiksverantwoordelijke zijn, maar rebranding, een substantiële wijziging of een nieuw doel kan de analyse veranderen.

Hoog risico kan volgen uit artikel 6(1) en bijlage I voor gereguleerde producten of veiligheidscomponenten, of uit een use case in bijlage III onder artikel 6(2). De ontwerp-richtsnoeren die de Commissie in mei 2026 publiceerde zijn nuttig, maar niet juridisch bindend.

Verordening (EU) 2026/1744 wijzigde ook de planning: afdelingen 1, 2 en 3 van hoofdstuk III, waaronder artikel 11, gelden vanaf 2 december 2027 voor systemen uit bijlage III en vanaf 2 augustus 2028 voor systemen uit bijlage I. Andere wetten, contracten of klantafspraken kunnen vergelijkbaar bewijs eerder vereisen.

Verwar dit dossier niet met de afzonderlijke documentatieplichten voor aanbieders van AI-modellen voor algemene doeleinden onder artikel 53 en bijlage XI. Informatie van de modelaanbieder is input; de SaaS-aanbieder moet het complete systeem, de integratie, het doel, de maatregelen en geëvalueerde prestaties documenteren.

Wat bijlage IV verwacht

Gebruik de bijlage als dekkingsmatrix:

1. Identiteit en doel: aanbieder, naam, versie, gebruikers, doel, leveringsvorm, interfaces, afhankelijkheden en UI.
2. Ontwikkeling: methoden, externe of vooraf getrainde componenten, modelkeuze, doelen, aannames en kernbesluiten.
3. Architectuur: componenten, interacties, rekenmiddelen en onderbouwing van keuzes.
4. Data: herkomst, selectie, labeling, opschoning, governance, beperkingen en training-, validatie-, test- of retrievaldata.
5. Mogelijkheden en grenzen: metrics, nauwkeurigheid, robuustheid, cybersecurity, voorzienbare ongewenste uitkomsten en degradatie.
6. Tests: protocollen, data, drempels, datums, versies, resultaten, fouten en correcties.
7. Risico en toezicht: risicobeheer, maatregelen, restrisico, menselijk toezicht en instructies.
8. Levenscyclus: versies, logging, change management, onderhoud, incidenten en post-market monitoring.
9. Conformiteit: normen, specificaties, EU-conformiteitsverklaring en zo nodig stukken van de aangemelde instantie.

Elke claim moet naar concreet bewijs leiden. Een verwijzing naar rapport, goedgekeurde metric, dataset, versie en resterende beperking is controleerbaar; “het systeem is robuust” niet.

Operationele workflow

1. Maak een gecontroleerde index

Gebruik één rij per bijlage-IV-element met eis, toepasselijkheid, bron, eigenaar, versie, goedkeuring, laatste review en volgende trigger. “Niet van toepassing” vereist motivering en goedkeuring. Toegangsbeheer, historie en stabiele verwijzingen zijn essentieel.

2. Leg bewijs vast bij de maker

Product beheert doel, gebruikers, context en voorzienbaar misbruik. Engineering beheert architectuur, afhankelijkheden, versies en wijzigingen. Data of ML beheert lineage, ontwikkeling, evaluaties en grenzen. Security beheert dreigingen, toegang, veerkracht en kwetsbaarheden. Legal en compliance beheren classificatie, rollen, wettelijke mapping en documentgovernance. Eén eigenaar coördineert zonder onverifieerde technische feiten te herschrijven.

3. Bevries de baseline vóór tests

Definieer doel en versie vóór resultaten worden geaccepteerd. Leg modellen, relevante prompts, retrievalbronnen, feature flags, drempels, afhankelijkheden en omgeving vast. Bewaar voor probabilistische systemen datasetversie, methode, acceptatiedrempel, datum, reproduceerbare resultaten en beperkingen.

4. Koppel risico's, maatregelen en tests

Elk materieel risico leidt naar een maatregel, eigenaar en effectiviteitsbewijs. Bij menselijke controle beschrijf je wie beoordeelt, met welke informatie, of outputs kunnen worden genegeerd, hoe escalatie werkt en hoe uitvoering wordt aangetoond.

5. Integreer het dossier in releases

Elke materiële release krijgt een documentatie-impactcheck. Wijzigingen in doel, model, data, drempel, gebruikers, landen, integraties, toezicht of security kunnen nieuwe tests en updates van risico's, instructies en conformiteitsanalyse vereisen.

Minimale checklist

Het team moet kunnen ophalen: goedgekeurde beschrijving, rol en classificatie; actuele architectuur- en dataflowdiagrammen met versies; register van modellen, libraries, API's en afhankelijkheden; dataherkomst en governance; evaluatieplannen, metrics, drempels, resultaten en beperkingen; risico's gekoppeld aan maatregelen en acceptaties; bewijs van menselijk toezicht; security-, robuustheids-, logging-, incident- en monitoringgegevens; instructies die bij het geteste systeem passen; releasehistorie en conformiteitsstukken.

Veelgemaakte fouten

Een leeg compliance-template levert vaak algemeenheden zonder bewijs. Een model card beschrijft niet de complete SaaS-workflow. Leveranciersdocumenten zijn input, geen vervanging voor de analyse van de integratie. Beperkingen verbergen is minder verdedigbaar dan ze met maatregelen uitleggen. Alleen kalenderreviews zijn onvoldoende: releases, incidenten, nieuwe data, gebruik en regelgeving zijn triggers. Klantvragenlijsten, productpagina's, instructies, risicodossiers en technische documentatie moeten hetzelfde systeem beschrijven.

Voorbeeld: AI-ondersteunde kandidaatselectie

Voor een functie die sollicitaties rangschikt, bevat het dossier doel, niet-ondersteund gebruik, klantworkflow, betrokken personen, data, rankinglogica, versies, geëvalueerde groepen, metrics, drempels, menselijke review, logging, security en monitoring.

Als een evaluatie lagere recall toont voor een relevante groep, bewaar dan resultaat, analyse, maatregel, hertest en restrisicobesluit. Een latere model- of drempelwijziging moet de verbonden onderdelen heropenen.

FAQ

Heeft elk SaaS-bedrijf een bijlage-IV-dossier nodig?

Nee. Artikel 11 en bijlage IV gaan over systemen met hoog risico en de kernplicht van de aanbieder. Een evenredig dossier blijft nuttig voor governance en klantbeoordelingen.

Kunnen engineeringdocumenten worden hergebruikt?

Ja, als ze gecontroleerd en actueel zijn en een index de dekking toont. Voorkom uiteenlopende kopieën.

Wie is verantwoordelijk?

Een benoemde eigenaar coördineert; product, engineering, ML/data, security, legal en compliance blijven eigenaar van hun bewijs.

Wanneer moet het worden bijgewerkt?

Bij wijzigingen in doel, versies, data, integraties, gebruikers, prestaties, risico's, maatregelen of monitoring, vóór materiële releases en na incidenten.

Is het vereenvoudigde mkb-formulier beschikbaar?

Artikel 11 voorziet in een vereenvoudigd formulier. Controleer altijd actuele officiële bronnen voordat je een template gebruikt. Houd tot die tijd een volledige bijlage-IV-matrix met evenredig bewijs bij.

Bronnen

• Verordening (EU) 2024/1689, met name artikelen 6, 9–17 en 43, en bijlage IV.
• Verordening (EU) 2026/1744 met de gewijzigde toepassingsdata.
• Ontwerp-richtsnoeren van de Commissie voor hoogrisicoclassificatie, mei 2026.
• Richtsnoeren van de Commissie voor aanbieders van AI-modellen voor algemene doeleinden.