Teknisk dokumentation: praktisk guide för SaaS-team

Teknisk dokumentation för ett AI-system är inte en arkitekturöversikt som skrivs när projektet är klart. Det är det kontrollerade bevispaket som förklarar systemets avsedda ändamål, hur det byggdes, vilka data och modeller det använder, hur det presterar, identifierade risker, tillhörande kontroller och hur ändringar efter lansering hanteras.

För leverantörer av AI-system med hög risk kräver artikel 11 i AI Act att dokumentationen upprättas innan systemet släpps ut på marknaden eller tas i bruk, hålls aktuell och är tillräckligt tydlig för att myndigheter och anmälda organ ska kunna bedöma överensstämmelsen. Bilaga IV anger minimiinnehållet. Ett SaaS-team bör därför samla bevis från produkt, engineering, data, säkerhet, juridik och kvalitet under utvecklingen, inte återskapa dem under en revision.

Kravet gäller inte automatiskt varje AI-funktion. Omfattningen beror på klassificering och företagets roll. Dokumentera båda först och gör dokumentationen proportionerlig mot de faktiska skyldigheterna och riskerna.

Varför detta är viktigt i praktiken

Bra dokumentation visar att testerna motsvarar det avsedda ändamålet, kopplar kundsvar till kontrollerade bevis och hjälper teamet avgöra om en ändring av modell, data, tröskel eller workflow kräver ny bedömning. Bedömaren får en sammanhängande redogörelse i stället för skärmbilder utan sammanhang.

Den kopplar samman produktkrav, arkitekturdiagram, model cards, datalinjer, utvärderingar, riskregister, säkerhetstester, mänsklig tillsyn, loggar, incidentprocesser, releasegodkännanden och övervakning efter utsläppandet. Ett centralt index kan peka till dessa källor utan att duplicera dem.

Arbetet stöder också förändrade krav på AI governance för SaaS-leverantörer.

Bekräfta omfattningen

Fastställ om programvaran är ett AI-system, om den har hög risk och vilken roll företaget har. Den som utvecklar och marknadsför under eget namn kan vara leverantör. Den som använder någon annans system kan vara tillhandahållare, men rebranding, en väsentlig ändring eller ett nytt avsett ändamål kan ändra analysen.

Hög risk kan följa av artikel 6.1 och bilaga I för reglerade produkter eller säkerhetskomponenter, eller av ett användningsfall i bilaga III enligt artikel 6.2. Kommissionens utkast till klassificeringsriktlinjer från maj 2026 är användbart men inte rättsligt bindande.

Förordning (EU) 2026/1744 ändrade också tidsplanen: avsnitten 1, 2 och 3 i kapitel III, inklusive artikel 11, gäller från 2 december 2027 för system i bilaga III och från 2 augusti 2028 för system i bilaga I. Andra lagar, avtal eller kundåtaganden kan kräva liknande bevis tidigare.

Blanda inte ihop detta med de separata dokumentationskraven för leverantörer av AI-modeller för allmänna ändamål enligt artikel 53 och bilaga XI. Information från modellleverantören är ett underlag; SaaS-leverantören måste dokumentera hela systemet, integrationen, ändamålet, kontrollerna och den utvärderade prestandan.

Vad bilaga IV förväntar sig

Använd bilagan som täckningsmatris:

1. Identitet och ändamål: leverantör, namn, version, användare, syfte, leveransform, gränssnitt, beroenden och UI.
2. Utveckling: metoder, tredjeparts- eller förtränade komponenter, modellval, mål, antaganden och viktiga beslut.
3. Arkitektur: komponenter, interaktioner, beräkningsresurser och motivering av val.
4. Data: ursprung, urval, märkning, rensning, governance, begränsningar och tränings-, validerings-, test- eller retrievaldata.
5. Förmågor och begränsningar: mätvärden, noggrannhet, robusthet, cybersäkerhet, förutsebara oönskade resultat och försämring.
6. Tester: protokoll, data, trösklar, datum, versioner, resultat, fel och korrigeringar.
7. Risk och tillsyn: riskhantering, åtgärder, kvarstående risk, mänsklig tillsyn och instruktioner.
8. Livscykel: versioner, loggning, change management, underhåll, incidenter och post-market monitoring.
9. Överensstämmelse: standarder, specifikationer, EU-försäkran och dokument från anmält organ när det krävs.

Varje påstående ska leda till konkret bevis. En hänvisning till rapport, godkänt mätvärde, dataset, version och kvarstående begränsning kan granskas; ”systemet är robust” kan inte det.

Operativt workflow

1. Skapa ett kontrollerat index

Ha en rad per bilaga-IV-element med krav, tillämplighet, källartefakt, ägare, version, godkännande, senaste granskning och nästa trigger. ”Ej tillämpligt” kräver motivering och godkännande. Åtkomstkontroll, historik och stabila referenser är centrala.

2. Lägg bevisägarskapet där beviset skapas

Produkt ansvarar för ändamål, användare, kontext och förutsebar felanvändning. Engineering ansvarar för arkitektur, beroenden, versioner och ändringar. Data eller ML ansvarar för ursprung, utveckling, utvärderingar och begränsningar. Säkerhet ansvarar för hot, åtkomst, resiliens och sårbarheter. Juridik och compliance ansvarar för klassificering, roller, regelmappning och dokumentstyrning. En central ägare samordnar utan att skriva om overifierade tekniska fakta.

3. Lås baseline före tester

Definiera ändamål och version innan resultat accepteras. Registrera modeller, relevanta prompts, retrievalkällor, feature flags, trösklar, beroenden och miljö. För probabilistiska system ska datasetversion, metod, acceptanströskel, datum, reproducerbara resultat och begränsningar bevaras.

4. Koppla risker, kontroller och tester

Varje väsentlig risk ska leda till en åtgärd, ägare och effektivitetsbevis. Om kontrollen är mänsklig, beskriv vem som granskar, vilken information de får, om output kan åsidosättas, hur undantag eskaleras och hur genomförandet bevisas.

5. Integrera dokumentationen i releases

Varje väsentlig release behöver en dokumentationskontroll. Ändringar av ändamål, modell, data, tröskel, användare, land, integration, tillsyn eller säkerhet kan kräva nya tester och uppdaterade risker, instruktioner och bedömningar.

Minsta bevischecklista

Teamet ska kunna hämta: godkänd beskrivning, roll och klassificering; aktuella arkitektur- och dataflödesdiagram med versioner; register över modeller, bibliotek, API:er och beroenden; dataursprung och governance; utvärderingsplaner, mätvärden, trösklar, resultat och begränsningar; risker kopplade till kontroller och godkännanden; bevis på mänsklig tillsyn; säkerhets-, robusthets-, logg-, incident- och monitoreringsunderlag; instruktioner som stämmer med det testade systemet; releasehistorik och överensstämmelsedokument.

Vanliga misstag

En tom compliance-mall ger ofta generella påståenden utan bevis. Ett model card beskriver inte hela SaaS-workflowet. Leverantörsdokument är underlag, inte en ersättning för analys av integrationen. Att dölja begränsningar är mindre försvarbart än att beskriva dem med kontroller. Kalendergranskning räcker inte: releases, incidenter, nya data, användningar och regeländringar är triggers. Kundformulär, produktsidor, instruktioner, riskfiler och teknisk dokumentation måste beskriva samma system.

Exempel: AI-stödd kandidatgranskning

För en funktion som rangordnar ansökningar omfattar dokumentationen ändamål, användningar som inte stöds, kundworkflow, berörda personer, data, rankinglogik, versioner, utvärderade grupper, mätvärden, trösklar, mänsklig granskning, loggning, säkerhet och monitorering.

Om en utvärdering visar lägre recall för en relevant grupp, bevara resultat, analys, åtgärd, omtest och beslut om kvarstående risk. En senare modell- eller tröskeländring ska återöppna de sammanlänkade delarna.

FAQ

Behöver varje SaaS-företag ett bilaga-IV-dokument?

Nej. Artikel 11 och bilaga IV gäller högrisksystem och leverantörens huvudskyldighet. Ett proportionerligt underlag är ändå värdefullt för governance och kundgranskningar.

Kan engineeringdokument återanvändas?

Ja, om de är kontrollerade och aktuella och ett index visar täckningen. Undvik kopior som glider isär.

Vem bör vara ansvarig?

En utsedd ägare samordnar; produkt, engineering, ML/data, säkerhet, juridik och compliance behåller ägarskapet över sina bevis.

När ska dokumentationen uppdateras?

När ändamål, versioner, data, integrationer, användare, prestanda, risker, kontroller eller monitorering ändras, före väsentliga releases och efter incidenter.

Finns kommissionens förenklade SME-formulär?

Artikel 11 föreskriver ett förenklat formulär. Kontrollera alltid aktuella officiella resurser innan en mall används. Behåll tills dess en komplett bilaga-IV-matris med proportionerliga bevis.

Källor

• Förordning (EU) 2024/1689, särskilt artiklarna 6, 9–17 och 43 samt bilaga IV.
• Förordning (EU) 2026/1744 med ändrade tillämpningsdatum.
• Kommissionens utkast till riktlinjer om högriskklassificering, maj 2026.
• Kommissionens riktlinjer för leverantörer av AI-modeller för allmänna ändamål.