Nachweisführung in der Softwareentwicklung: wenn der Kunde fragt, wie Sie freigeben
Die Frage taucht inzwischen in fast jedem größeren Lieferantenfragebogen auf: Wie stellen Sie sicher, dass ausgelieferte Software geprüft wurde, und wie weisen Sie das nach? Wer sie mit Screenshots beantwortet, hat eine Antwort für diese Runde. Wer sie mit einem Export beantwortet, hat sie ein für alle Mal.
Der Druck zur Nachweisführung kommt meist nicht aus der Regulierung, sondern von Großkunden, interner Revision und Versicherern. Ein tragfähiger Beleg beantwortet drei Fragen an derselben Änderung: Was wurde geändert, was wurde geprüft und mit welchem Ergebnis, wer hat entschieden — unveränderbar und exportierbar. Er muss im Prozess anfallen; nachträgliche Rekonstruktion ist teuer und angreifbar. Ein separates Nachweissystem weicht binnen eines Jahres vom tatsächlichen Ablauf ab.
Woher der Druck tatsächlich kommt
Nicht in erster Linie aus der Regulierung. Für die meisten Häuser, die KI zur Entwicklung der eigenen Software einsetzen, greifen die Hochrisiko-Pflichten des AI Act nicht. Der reale Druck entsteht dreifach: Großkunden sichern ihre Lieferkette ab, interne Revisionen haben das Thema entdeckt, und Versicherer fragen nach Freigabeprozessen. Alle drei akzeptieren keine Beschreibung, sondern wollen Belege.
Was ein Beleg leisten muss
Er muss drei Fragen beantworten: Was wurde geändert, was wurde geprüft und mit welchem Ergebnis, wer hat entschieden. Diese drei Angaben müssen an derselben Änderung hängen, unveränderbar sein und sich über einen Zeitraum exportieren lassen. Alles andere — hübsche Berichte, Kennzahlen, Reifegradmodelle — ist Zugabe.
Warum er im Prozess entstehen muss
Weil nachträgliche Rekonstruktion teuer und angreifbar ist. Wer zwei Wochen vor dem Audit Screenshots sammelt, produziert einen Aufwand, der sich jedes Jahr wiederholt, und ein Ergebnis, das genau so lange trägt, bis jemand nach der Vollständigkeit fragt. Fällt der Beleg dagegen bei jeder Änderung an, ist die Vorbereitung ein Export.
Der praktische Aufbau
Vier Bestandteile, alle in Systemen, die ohnehin da sind: die Änderung selbst mit Herkunftsvermerk in der Versionsverwaltung; die Ergebnisse der automatischen Prüfungen als Anhang am Build; die Freigabeentscheidung mit Person und Zeitpunkt; und die Zuordnung zur Risikoklasse. Zusammengehalten wird das über die Kennung der Änderung — mehr Werkzeug braucht es nicht.
Der Fehler, den fast alle machen
Ein eigenes Nachweissystem zu bauen. Es entsteht ein zweiter Datenbestand, der gepflegt werden muss und der spätestens nach einem Jahr vom tatsächlichen Ablauf abweicht. Ein Nachweis, der neben dem Prozess geführt wird, dokumentiert nicht die Wirklichkeit, sondern die Absicht.
Häufige Fragen
Betrifft der EU AI Act die eigene Softwareentwicklung?
In der Regel nicht mit Hochrisiko-Pflichten, wenn KI nur zur Entwicklung eigener Software eingesetzt wird. Wer KI-Funktionen in Produkte einbaut, die unter die entsprechenden Kategorien fallen, steht anders da. Für die Nachweisführung ist der Auslöser meist ohnehin ein anderer: der Kunde.
Wie lange müssen Nachweise aufbewahrt werden?
Das ergibt sich aus Branche und Vertrag, nicht aus der Softwareentwicklung. Üblich sind Zeiträume zwischen fünf und zehn Jahren. Praktisch entscheidend ist, dass die Aufbewahrung automatisch geschieht und nicht davon abhängt, dass ein System nicht abgelöst wird.
Reicht die Historie der Versionsverwaltung als Nachweis?
Als Grundlage ja, als Nachweis allein nicht. Es fehlen die Prüfergebnisse und die Freigabeentscheidung. Beide lassen sich mit vertretbarem Aufwand an dieselbe Änderungskennung hängen — dann trägt die Kombination.
Was, wenn Prüfungen umgangen wurden?
Dann muss genau das im Nachweis stehen: Ausnahme, Grund, Person, Zeitpunkt. Ein Nachweis, der keine Ausnahmen kennt, ist unglaubwürdig. Ein Nachweis, der sie dokumentiert und auswertbar macht, ist stärker als einer ohne.
Rechnen Sie Ihre Review-Lücke aus.
Vierzehn Fragen, fünf Minuten. Ihre Zahlen, kein Login.
AI Engineering Review ansehen →
