Häufige Fehler bei der technischen Dokumentation

Die häufigsten Fehler sind keine Formatierungsprobleme, sondern Schwächen bei Umfang, Nachweisen, Verantwortung und Änderungskontrolle. Eine Akte kann vollständig wirken und dennoch nicht überprüfbar sein. Artikel 11 des EU AI Act verlangt von Anbietern von Hochrisiko-KI-Systemen, die technische Dokumentation vor dem Inverkehrbringen oder der Inbetriebnahme zu erstellen und aktuell zu halten. Anhang IV nennt die Mindestinhalte. Die Verordnung (EU) 2026/1744 vereinfacht die Darstellung für bestimmte kleinere Unternehmen, nicht aber die Pflicht, Aussagen zu belegen.

Nicht jedes SaaS-Unternehmen ist Anbieter eines Hochrisiko-KI-Systems. Systemgrenze, Rolle und Einstufung müssen zuerst geklärt werden.

1. Nur das Modell statt des Systems dokumentieren

Eine Modellkarte oder ein Lieferantendatenblatt beschreibt nicht das SaaS-System mit Prompts, Datenflüssen, Schnittstellen, menschlicher Aufsicht, Protokollierung und nachgelagerten Entscheidungen. Zeichnen Sie die Systemgrenze und erfassen Sie Komponenten, Akteure, Ein- und Ausgaben sowie Kontrollen. Trennen Sie Lieferantenaussagen von selbst geprüften Fakten. Der EU-AI-Act-Leitfaden für SaaS-Anbieter unterstützt die Rollen- und Umfangsanalyse.

2. Mit einer Erzählvorlage beginnen

Große Vorlagen erzeugen plausible Texte über robuste Tests oder angemessene Aufsicht, bevor Nachweise vorhanden sind. Beginnen Sie mit einem Abdeckungsindex: Anforderung, Quellartefakt, Systemversion, Eigentümer, Prüfer, Status und Aktualisierungsauslöser. Schreiben Sie Erläuterungen erst, wenn kontrollierte Quellen existieren.

3. Richtlinien mit Nachweisen verwechseln

Eine Richtlinie beschreibt, was geschehen soll. Nachweise zeigen, was bei einer bestimmten Version geschah. Geeignet sind freigegebene Anforderungen, Architekturentscheidungen, Datensatzaufzeichnungen, Testergebnisse, Bedrohungsmodelle, Release-Freigaben und Überwachungsprotokolle. Jeder Nachweis braucht Aussagezweck, Quelle, Datum, Version und Verantwortlichen.

4. Versionsrückverfolgbarkeit verlieren

Überschriebene Diagramme, Tests ohne Modell- oder Datensatzversion und veränderliche Dashboards machen selbst richtige Angaben unbrauchbar. Vergeben Sie eine stabile Systemkennung und verbinden Sie Artefakte mit Release, Modell, Konfiguration und Datum. Ein Prüfer muss von der Produktionsversion zu Anforderungen, Architektur, Tests, Risiken, Kontrollen, Anweisungen und Freigabe gelangen können.

5. Die gesamte Akte Compliance zuweisen

Compliance kann Standards koordinieren und schwache Aussagen hinterfragen, aber technische Fakten nicht aus zweiter Hand zuverlässig verfassen. Produkt verantwortet Zweck und Nutzung, Engineering Architektur und Änderungen, Daten- oder ML-Teams Bewertungen, Security Schutzmaßnahmen und Release Management die ausgelieferte Version. Ein zentraler Dokumentationsverantwortlicher steuert die Abdeckung, ohne alle Nachweise selbst zu schreiben.

6. Dokumentation als einmalige Launch-Aufgabe behandeln

Modelle, Daten, Anbieter, Funktionen und Risiken ändern sich. Ergänzen Sie bei wesentlichen Änderungen eine Dokumentationsauswirkungsprüfung. Zweck, Systemgrenze, Modell, wichtige Daten, Leistung, menschliche Aufsicht, Sicherheit, Anweisungen oder Monitoring sind typische Auslöser. Regelmäßige Prüfungen bleiben ein Rückhalt; die Hauptkontrolle ist ereignisbasiert. Eine gute Struktur lässt zudem Compliance-Prüfungen schneller ablaufen.

7. Aktivität statt Nachweisqualität messen

Die Zahl geschlossener Tickets sagt nicht, ob Aussagen belegt sind. Messen Sie Vollständigkeit beim ersten Durchlauf, wesentliche offene Lücken, überfällige Ausnahmen, defekte Links, Versionsabweichungen und Aktualisierungszeit. Kann ein unabhängiger Prüfer eine Schlussfolgerung nicht ohne Interview nachvollziehen, ist der Nachweis nicht selbsterklärend.

8. Lieferantenaussagen ungeprüft übernehmen

Zertifikate und Modellkarten können nützlich sein, decken aber möglicherweise eine andere Version, Sprache, Population oder Umgebung ab. Erfassen Sie das genaue Lieferantendokument, prüfen Sie die Abweichung zum eigenen Einsatz und testen Sie das relevante Verhalten. Fehlende Informationen sind ein Risiko oder eine Nachweislücke, kein Anlass für Annahmen.

9. Lücken hinter vagen Ausnahmen verbergen

„Später erledigen“ ist keine kontrollierte Entscheidung. Halten Sie Lücke, Grund, Zwischenkontrolle, Risikoverantwortlichen, Freigabe, Maßnahme und Ablaufdatum fest. Nicht jeder Fehler stoppt ein Release, aber fehlende Bewertung oder unklare Aufsicht ist anders zu behandeln als eine kleine redaktionelle Lücke. Ein klares Compliance-Verantwortungsmodell verhindert Dauerprovisorien.

Fokussierter Prüfablauf

1. Systemgrenze, Rolle, Einstufung, Zweck und aktuelle Version bestätigen.
2. Anhang-IV-Index erstellen und kontrollierte Quellen verknüpfen.
3. Je eine Architektur-, Leistungs-, Risiko-, Aufsichts- und Änderungsbehauptung prüfen.
4. Gleiche System- und Versionskennungen sowie reproduzierbare Ergebnisse bestätigen.
5. Lücken nach Verantwortlichem, Wesentlichkeit, Maßnahme und Frist steuern.
6. Ereignisbasierte Auslöser in Produkt-, Anbieter-, Sicherheits- und Release-Prozesse integrieren.

FAQ

Wozu dient technische Dokumentation praktisch?

Sie erklärt rückverfolgbar, was das System ist, wie es entwickelt und bewertet wurde, welche Risiken und Kontrollen gelten und warum die Anforderungen als erfüllt angesehen werden.

Wann gilt sie für SaaS-Teams?

Artikel 11 gilt für Anbieter von Hochrisiko-KI-Systemen. Rolle, Systemgrenze und Einstufung sind vor der Anwendung von Anhang IV zu prüfen.

Was sollte zuerst korrigiert werden?

Zweck, Version, Architektur, Bewertung, wesentliche Risiken, menschliche Aufsicht, Anweisungen und Release-Freigabe. Widersprüche und unbelegte wesentliche Aussagen haben Vorrang vor der Darstellung.

Quellen

• Verordnung (EU) 2024/1689, insbesondere Artikel 11 und Anhang IV.
• Verordnung (EU) 2026/1744, einschließlich der Vereinfachungen der technischen Dokumentation.