Veelgemaakte fouten in technische documentatie

De meeste fouten gaan niet over opmaak, maar over scope, bewijs, eigenaarschap en wijzigingsbeheer. Een dossier kan volledig ogen en toch niet controleerbaar zijn. Artikel 11 van de AI Act verplicht aanbieders van AI-systemen met een hoog risico de documentatie vóór marktintroductie of ingebruikname op te stellen en actueel te houden. Bijlage IV noemt de minimale inhoud. Verordening (EU) 2026/1744 vereenvoudigt voor sommige kleinere organisaties de presentatie, niet de noodzaak om claims te onderbouwen.

Niet elk SaaS-bedrijf is aanbieder van een hoog-risicosysteem. Bevestig eerst de systeemgrens, rol en classificatie.

1. Het model documenteren in plaats van het systeem

Een modelkaart of leveranciersblad beschrijft geen prompts, datastromen, interfaces, menselijke controle, logging en vervolgacties. Teken de systeemgrens en registreer componenten, actoren, invoer, uitvoer en beheersmaatregelen. Scheid leveranciersinformatie van intern geverifieerde feiten. De AI-Act-gids voor SaaS-aanbieders ondersteunt de rol- en scopeanalyse.

2. Beginnen met een verhalend sjabloon

Grote sjablonen leveren aannemelijke tekst over testen en toezicht voordat bewijs bestaat. Begin met een dekkingsindex: vereiste, bronartefact, systeemversie, eigenaar, reviewer, status en updatetrigger. Schrijf de toelichting pas vanuit gecontroleerde bronnen.

3. Beleid verwarren met bewijs

Beleid beschrijft wat hoort te gebeuren; bewijs toont wat voor een specifieke versie gebeurde. Goedgekeurde eisen, architectuurbesluiten, datasetregistraties, evaluaties, dreigingsmodellen, releasegoedkeuringen en monitoringsreviews zijn bruikbaar. Leg per bewijs claim, bron, datum, versie en verantwoordelijke vast.

4. Versietraceerbaarheid verliezen

Overschreven diagrammen, tests zonder model- of datasetversie en veranderende dashboards breken de keten. Geef het systeem een stabiele identifier en koppel elk artefact aan release, model, configuratie en datum. Een reviewer moet vanuit productie eisen, architectuur, tests, risico's, controles, instructies en goedkeuring kunnen terugvinden.

5. Het hele dossier bij compliance leggen

Compliance coördineert de norm en bevraagt zwakke claims, maar hoort technische feiten niet uit tweede hand te schrijven. Product bezit het doel; engineering de architectuur en wijzigingen; data of ML de evaluaties; security de controles; releasemanagement wat is uitgerold. Eén documentatieverantwoordelijke beheert de dekking zonder al het bewijs zelf te maken.

6. Documentatie als eenmalige lanceringstaak behandelen

Modellen, data, leveranciers en risico's veranderen. Voeg een impactcheck toe bij wijzigingen in doel, grens, model, belangrijke data, prestaties, menselijk toezicht, beveiliging, instructies of monitoring. Periodieke review is een vangnet; gebeurtenisgestuurd beheer is de hoofdcontrole. Een goede structuur laat audits sneller verlopen.

7. Activiteit meten in plaats van kwaliteit

Het aantal gesloten documenten of tickets bewijst niets. Meet volledigheid bij eerste review, belangrijke hiaten, verlopen uitzonderingen, kapotte links, versieverschillen en bijwerktijd. Moet de reviewer de auteur interviewen om een conclusie te reproduceren, dan staat het bewijs niet op zichzelf.

8. Leveranciersclaims zonder toetsing accepteren

Certificaten en modelkaarten kunnen een andere versie, taal, populatie of omgeving betreffen. Registreer het exacte document, beoordeel het verschil met uw toepassing en test relevant gedrag. Ontbrekende informatie is een risico of bewijshiaat, geen reden om aannames te doen.

9. Hiaten achter vage uitzonderingen verbergen

“Later afronden” is geen beheerste beslissing. Noteer hiaat, reden, tijdelijke maatregel, risico-eigenaar, goedkeuring, herstelactie en vervaldatum. Een duidelijk compliance-eigenaarsmodel voorkomt permanente uitzonderingen.

Gerichte review

1. Bevestig systeemgrens, rol, classificatie, doel en actuele versie.
2. Bouw de bijlage-IV-index en koppel gecontroleerde bronnen.
3. Bemonster één claim over architectuur, prestaties, risico, toezicht en wijziging.
4. Controleer consistente identifiers en reproduceerbare uitkomsten.
5. Geef elk hiaat een eigenaar, materialiteit, actie en datum.
6. Integreer triggers in product-, leveranciers-, security- en releaseprocessen.

FAQ

Wat is het praktische doel?

Traceerbaar uitleggen wat het systeem is, hoe het is ontwikkeld en beoordeeld, welke risico's en controles gelden en waarom aan de eisen zou zijn voldaan.

Wanneer geldt dit voor SaaS-teams?

Artikel 11 geldt voor aanbieders van AI-systemen met een hoog risico. Bevestig grens, rol en classificatie voordat u bijlage IV als directe verplichting behandelt.

Wat moet eerst worden hersteld?

Doel, versie, architectuur, evaluatie, materiële risico's, menselijk toezicht, instructies en releasegoedkeuring. Los tegenstrijdigheden en belangrijke onbewezen claims vóór presentatieproblemen op.

Bronnen

• Verordening (EU) 2024/1689, met name artikel 11 en bijlage IV.
• Verordening (EU) 2026/1744, inclusief vereenvoudigingen voor technische documentatie.