Technische Dokumentation: Praktischer Leitfaden für SaaS-Teams

Technische Dokumentation für ein KI-System ist keine am Projektende erstellte Architekturübersicht. Sie ist das kontrollierte Nachweispaket, das Zweckbestimmung, Aufbau, Daten und Modelle, Leistung, Risiken, Kontrollen und Änderungen nach der Freigabe erklärt.

Für Anbieter von Hochrisiko-KI-Systemen verlangt Artikel 11 des EU AI Act, dass diese Dokumentation vor dem Inverkehrbringen oder der Inbetriebnahme erstellt, aktuell gehalten und so klar verfasst wird, dass zuständige Behörden und notifizierte Stellen die Konformität bewerten können. Anhang IV bestimmt den Mindestinhalt. SaaS-Teams sollten die Akte daher während der Entwicklung aus Produkt-, Engineering-, Daten-, Security-, Rechts- und Qualitätsnachweisen aufbauen und nicht erst während eines Audits rekonstruieren.

Die Pflicht gilt nicht automatisch für jede KI-Funktion. Entscheidend sind Klassifizierung und Rolle des Unternehmens. Beginnen Sie mit einer dokumentierten Klassifizierungs- und Rollenanalyse und gestalten Sie die Unterlagen proportional zu den tatsächlichen Pflichten und Risiken.

Warum dies praktisch wichtig ist

Eine gute technische Akte zeigt Release-Verantwortlichen, dass Tests zur Zweckbestimmung passen, und erlaubt Compliance-Teams, Aussagen in Kundenantworten auf kontrollierte Belege zurückzuführen. Engineering erkennt, ob Änderungen an Modell, Datenquelle, Schwellenwert oder Workflow eine Neubewertung auslösen. Behörden oder Konformitätsbewerter erhalten eine zusammenhängende Darstellung statt eines Ordners mit unerklärten Screenshots.

Die Dokumentation verbindet Unterlagen, die oft getrennt liegen: Produktanforderungen, Architekturdiagramme, Model Cards, Datenherkunft, Evaluierungsberichte, Risikoregister, Sicherheitstests, menschliche Aufsicht, Protokolle, Incident-Prozesse, Release-Freigaben und Marktbeobachtung. Ein zentraler Index darf auf diese kontrollierten Quellen verweisen; nicht jedes Artefakt muss dupliziert werden.

Das unterstützt auch die veränderten AI-Governance-Erwartungen an SaaS-Anbieter und wiederkehrende Käuferfragen.

Umfang vor dem Aufbau klären

Prüfen Sie zuerst, ob die Software ein KI-System und ein Hochrisiko-KI-System ist und welche Betreiberrolle vorliegt. Wer ein System unter eigenem Namen entwickelt und vermarktet, kann Anbieterpflichten haben. Wer nur ein fremdes System nutzt, ist möglicherweise Betreiber. Rebranding, wesentliche Änderungen oder eine geänderte Zweckbestimmung können die Rolle verändern.

Die Hochrisiko-Einstufung kann über Artikel 6 Absatz 1 und Anhang I für regulierte Produkte beziehungsweise Sicherheitskomponenten oder über einen in Anhang III aufgeführten Anwendungsfall nach Artikel 6 Absatz 2 entstehen. Die Kommission veröffentlichte im Mai 2026 Leitlinienentwürfe zur Klassifizierung. Sie sind nützlich, aber nicht als verbindliches Recht darzustellen.

Auch die Fristen sind wichtig: Verordnung (EU) 2026/1744 änderte den AI Act. Die Abschnitte 1, 2 und 3 von Kapitel III gelten für Hochrisiko-Systeme nach Anhang III ab 2. Dezember 2027 und für Systeme nach Anhang I ab 2. August 2028. Artikel 11 gehört dazu. Andere Gesetze, Verträge, Produktregeln oder Kundenzusagen können ähnliche Nachweise schon früher verlangen.

Verwechseln Sie diese Akte nicht mit den getrennten Dokumentationspflichten für Anbieter von General-Purpose-AI-Modellen nach Artikel 53 und Anhang XI. Nutzt ein SaaS-Anbieter ein fremdes Basismodell, sind Anbieterinformationen ein Input; die technische Akte muss dennoch das vollständige System, seine Integration, Zweckbestimmung, Kontrollen und geprüfte Leistung erklären.

Was Anhang IV erwartet

Behandeln Sie Anhang IV als Abdeckungsmatrix. Die Inhalte lassen sich praktisch gruppieren:

1. Identität und Zweckbestimmung: Anbieter, Name, Version, Nutzer, Zweck, Bereitstellungsform, Schnittstellen, Abhängigkeiten und Oberfläche.
2. Entwicklung: Methoden, Drittkomponenten, vortrainierte Elemente, Modellauswahl, Ziele, Annahmen und wesentliche Entscheidungen.
3. Architektur: Komponenten, Zusammenspiel, Rechenressourcen und Begründung wichtiger technischer Entscheidungen.
4. Daten: Herkunft, Auswahl, Kennzeichnung, Bereinigung, Governance, Einschränkungen sowie Trainings-, Validierungs-, Test- und gegebenenfalls Retrieval-Daten.
5. Fähigkeiten und Grenzen: Kennzahlen, Genauigkeit, Robustheit, Cybersecurity, vorhersehbare unerwünschte Ergebnisse und Bedingungen für Leistungseinbußen.
6. Tests: Protokolle, Daten, Kennzahlen, Grenzwerte, Datum, Version, Resultate, Fehler und Korrekturen.
7. Risiko und Aufsicht: Risikomanagement, Minderungen, Restrisiken, menschliche Aufsicht und Betreiberanweisungen.
8. Lebenszyklus: Versionierung, Logging, Change Management, Wartung, Incidents und Marktbeobachtung.
9. Konformität: Standards, technische Spezifikationen, EU-Konformitätserklärung und gegebenenfalls Unterlagen notifizierter Stellen.

Jede Aussage sollte auf Belege verweisen. „Das System ist robust“ genügt nicht. Ein Verweis auf einen konkreten Evaluierungsbericht, eine freigegebene Kennzahl, Testdaten, Release-Version und dokumentierte Restrisiken ist prüfbar.

Praktischer Workflow

1. Kontrollierten Index anlegen

Erstellen Sie ein Register mit einer Zeile je Anhang-IV-Element: Anforderung, Anwendbarkeitsentscheidung, Quellartefakt, Owner, Systemversion, Freigabestatus, letzter Review und nächster Auslöser. „Nicht anwendbar“ braucht Begründung und Freigabe. Zugriff, Versionierung und stabile Referenzen sind wichtiger als das verwendete Tool.

2. Nachweise dort verantworten, wo sie entstehen

Produkt verantwortet Zweck, Nutzer, Nutzungskontext und vorhersehbare Fehlanwendung. Engineering verantwortet Architektur, Versionen, Schnittstellen und Änderungen. Daten- oder ML-Teams verantworten Datenherkunft, Entwicklung, Evaluierungen und Leistungsgrenzen. Security verantwortet Bedrohungsanalyse, Zugriff, Resilienztests und Schwachstellen. Legal und Compliance verantworten Klassifizierung, Rollen, regulatorische Zuordnung und Dokumentensteuerung. Ein zentraler Owner koordiniert, ohne technische Fakten ungeprüft umzuschreiben.

3. Baseline vor Tests fixieren

Definieren Sie Zweck und Version, bevor Testergebnisse akzeptiert werden. Halten Sie Modellkennungen, relevante Prompts oder Systemanweisungen, Retrieval-Quellen, Feature Flags, Schwellenwerte, Abhängigkeiten und Umgebung fest. Bei probabilistischen Systemen gehören Datensatzversion, Methode, Akzeptanzgrenze, Datum und reproduzierbare Ergebnisse in die Akte.

4. Risiken, Kontrollen und Tests verbinden

Jedes wesentliche Risiko muss zu einer Minderung, einem Owner und einem Wirksamkeitsnachweis führen. Bei menschlicher Kontrolle ist zu dokumentieren, wer prüft, welche Informationen vorliegen, ob Outputs überstimmt werden können, wie eskaliert wird und wie die tatsächliche Durchführung belegt wird.

5. Dokumentation in Releases integrieren

Jedes wesentliche Release braucht einen Dokumentations-Impact-Check. Änderungen an Zweck, Modell, Daten, Schwellenwerten, Nutzergruppe, Geografie, Integration, Aufsicht oder Sicherheitskontrollen können neue Tests und aktualisierte Risiken, Anweisungen und Konformitätsbewertungen erfordern. Der Release-Eintrag hält fest, was geändert oder erneut bestätigt wurde.

Mindest-Checkliste

Vor einer formellen Prüfung sollten abrufbar sein:

• freigegebene Systembeschreibung, Zweckbestimmung, Rolle und Klassifizierungsbegründung
• aktuelle Architektur- und Datenflussdiagramme mit Komponenten- und Modellversionen
• Register relevanter Modelle, Bibliotheken, APIs und Abhängigkeiten
• Datenherkunft und Governance für Training, Validierung, Test und Retrieval
• Evaluierungspläne, Kennzahlen, Schwellenwerte, Resultate, Grenzen und Entscheidungen
• Risikoregister mit Kontrollen, Tests, Ownern und Restrisiko-Freigaben
• Design und Betriebsnachweise der menschlichen Aufsicht
• Security-, Robustheits-, Logging-, Incident- und Monitoring-Unterlagen
• Betreiberanweisungen und Produktgrenzen passend zum getesteten System
• Release-Historie, Change Assessments, Freigaben und Konformitätsunterlagen

Häufige Fehler

Ein leeres Compliance-Template erzeugt oft generische Aussagen ohne Engineering-Nachweis. Eine Model Card beschreibt nicht den vollständigen SaaS-Workflow. Lieferantendokumente sind Inputs, kein Ersatz für die eigene Integration und Zweckbestimmung. Grenzen zu verschweigen ist weniger belastbar als sie mit Kontrollen zu erklären. Kalenderbasierte Reviews reichen nicht; Releases, Incidents, neue Daten, Nutzungsänderungen und regulatorische Entwicklungen sind Auslöser. Schließlich müssen Kundenantworten, Produktseiten, Anweisungen, Risikodateien und technische Dokumentation dasselbe System beschreiben.

Beispiel: KI-gestütztes Bewerber-Screening

Bei einer SaaS-Funktion, die Bewerbungen für Recruiter ordnet, muss die Akte mehr als das Modell erfassen: Zweck, nicht unterstützte Nutzungen, Kundenworkflow, betroffene Personen, Eingabedaten, Rankinglogik, Versionen, Evaluierungsgruppen, Kennzahlen, Grenzwerte, menschliche Prüfung, Logging, Sicherheit und Monitoring.

Zeigt eine Evaluierung geringeren Recall für eine relevante Gruppe, bleiben Ergebnis, Bewertung, Minderung, Wiederholungstest und Restrisikoentscheidung erhalten. Nach einem Modell- oder Schwellenwertwechsel werden die verbundenen Evaluierungs-, Risiko-, Aufsichts- und Anweisungsunterlagen erneut geöffnet.

FAQ

Braucht jedes SaaS-Unternehmen eine technische Akte nach Anhang IV?

Nein. Artikel 11 und Anhang IV betreffen Hochrisiko-KI-Systeme, wobei die Kernpflicht den Anbieter trifft. Proportionale technische Nachweise sind dennoch für Governance, Lieferantenprüfung und Kundenassurance hilfreich.

Können bestehende Engineering-Unterlagen genutzt werden?

Ja. Nutzen Sie kontrollierte, aktuelle Quellen und einen Index, der die Abdeckung zeigt. Vermeiden Sie Kopien, die auseinanderlaufen können.

Wer sollte verantwortlich sein?

Ein benannter Dokumentations-Owner koordiniert die Akte. Die Nachweisverantwortung bleibt bei Produkt, Engineering, ML/Daten, Security, Legal und Compliance.

Wann muss aktualisiert werden?

Bei Änderungen an Zweck, Versionen, Daten, Integrationen, Nutzern, Leistung, Risiken, Kontrollen oder Monitoring sowie vor wesentlichen Releases und nach Incidents.

Gibt es das vereinfachte KMU-Formular der Kommission?

Artikel 11 sieht ein vereinfachtes Formular vor. Prüfen Sie vor der Nutzung stets die aktuellen offiziellen Kommissionsunterlagen. Bis ein anwendbares Formular verfügbar ist, sollten Teams eine vollständige Anhang-IV-Matrix mit proportionalen Nachweisen pflegen.

Quellen

• Verordnung (EU) 2024/1689, insbesondere Artikel 6, 9–17 und 43 sowie Anhang IV.
• Verordnung (EU) 2026/1744 mit den geänderten Anwendungsfristen.
• Leitlinienentwurf der Europäischen Kommission zur Klassifizierung von Hochrisiko-KI-Systemen, Mai 2026.
• Leitlinien der Europäischen Kommission für Anbieter von General-Purpose-AI-Modellen.