KI-Audit-Checkliste: So auditieren Sie ein KI-System Schritt für Schritt

Achtundsiebzig Prozent der Unternehmensführungskräfte haben kein starkes Vertrauen darauf, dass sie ein unabhängiges KI-Governance-Audit innerhalb von 90 Tagen bestehen könnten. Diese Zahl stammt aus der 2026 AI Impact Survey von Grant Thornton unter 950 Unternehmensführungskräften, und das ist eine diplomatische Art zu sagen, dass die meisten Unternehmen KI ausgeliefert haben, die sie nicht vollständig erklären können.

Ein KI-Audit ist eine strukturierte Überprüfung der Daten, des Modells, der Sicherheit, der Aufsicht und der Dokumentation eines KI-Systems anhand eines definierten Standards. Um ein KI-System zu auditieren, arbeiten Sie acht Schritte in dieser Reihenfolge ab: das System eingrenzen, die Daten zurückverfolgen, die Leistung validieren, auf Bias prüfen, die Sicherheit untersuchen, die menschliche Aufsicht prüfen, das Monitoring verifizieren und das Nachweispaket zusammenstellen.

Jeder der acht folgenden Schritte enthält die konkreten Prüfungen, die durchzuführen sind, die Maßnahmen, die Sie einem Team übertragen können, und das Warnsignal, das anzeigt, dass der Schritt gescheitert ist. Wenn Sie mehr Hintergrundwissen zu Audit-Arten und dazu, wer eines benötigt, möchten, behandelt unser Leitfaden zu was ein KI-Audit ist dieses Thema, und die Seite zu unserem Software-Entwicklungsaudit-Service erklärt, wie ein externes Team ein solches Audit durchführt.

Was die KI-Audit-Checkliste abdeckt

Die acht folgenden Schritte bewegen sich absichtlich von der Papierarbeit zur Produktion. Jeder spätere Schritt baut auf der Scoping-Arbeit im ersten Schritt auf, sodass eine Ausführung in falscher Reihenfolge bedeutet, ein System zu auditieren, das Sie noch nicht definiert haben. Die Aufwandsspalte geht von einem einzelnen mittelgroßen Produktionssystem mit ein oder zwei Modellen und einem Team aus, das Fragen innerhalb eines Tages beantworten kann.

Planen Sie drei bis vier Wochen für den ersten Durchlauf ein, und weniger für Wiederholungszyklen, sobald die Nachweis-Pipeline etabliert ist. Das Risiko, die gesamte Übung auszulassen, ist messbar: Eine IBM-Studie von 2026 unter 2.000 Technologieführungskräften ergab, dass Organisationen mit eingebetteten Kontrollen 25 % weniger Vorfälle verzeichnen als solche, die sich auf manuelle Governance verlassen.

Schritt 1: Das System eingrenzen und eine Modellkarte erstellen

Sie können nicht “unsere KI” auditieren. Sie auditieren ein konkretes System mit einer Versionsnummer, einem benannten Eigentümer und einem schriftlich festgelegten Zweck. Beginnen Sie mit einer Modellkarte, einem einseitigen Datenblatt, das abdeckt, was das System tut, wofür es niemals eingesetzt werden darf, wer es besitzt und wie riskant seine Entscheidungen sind. Die KI-Audit-Checkliste des Europäischen Datenschutzausschusses beginnt mit genau diesem Artefakt und fügt dann eine Systemkarte hinzu, die zeigt, wo das Modell im Entscheidungsablauf sitzt und welche Personen mit seiner Ausgabe in Berührung kommen.

Erwarten Sie, dass dieser Schritt Systeme zutage bringt, von denen Ihnen niemand erzählt hat. Eine Studie des IBM Institute for Business Value unter 2.000 Technologieführungskräften ergab, dass 70 % sagen, Teams im gesamten Unternehmen würden Technologie schneller einsetzen, als die IT-Abteilung nachverfolgen kann.

Systeminventar:

• Listen Sie jedes verwendete KI-System auf, einschließlich Tools, die über die Kreditkarte eines Teams gekauft wurden
• Erfassen Sie die Versionsnummer und das Datum der letzten Änderung
• Benennen Sie pro System einen verantwortlichen Eigentümer, eine Person und keine Abteilung

Die Modellkarte:

• Formulieren Sie den vorgesehenen Zweck des Systems in einem einfachen Satz
• Dokumentieren Sie, wofür es nicht verwendet werden darf, und warum
• Vermerken Sie, welches Modell oder welcher Anbieter zugrunde liegt, und welche Version

Systemkarte:

• Zeichnen Sie ein, wo die KI-Ausgabe in eine reale Entscheidung einfließt und wer daraufhin handelt
• Markieren Sie jeden Punkt, an dem eine Person das Ergebnis prüfen, bearbeiten oder überschreiben kann

Warnsignal: Der Zweck des Systems ändert sich je danach, wen man fragt.

Schritt 2: Zurückverfolgen, woher die Daten stammen und ob Sie sie nutzen dürfen

Jeder Datensatz, der das Modell trainiert, angepasst hat oder es speist, benötigt einen nachvollziehbaren Ursprung, eine dokumentierte Rechtsgrundlage und eine Qualitätsprüfung. Fragen Sie, woher die Daten stammen, wer sie erhoben hat, unter welcher Einwilligung oder Lizenz, und wann sie zuletzt aktualisiert wurden. Überprüfen Sie dann selbst eine Stichprobe, anstatt die Zusammenfassung einfach zu akzeptieren, denn hier finden die meisten Audits ihr erstes echtes Problem.

Der Markt weiß das bereits. In Deloittes State of AI in the Enterprise ist Datenschutz und -sicherheit mit 73 % das größte KI-Risiko, noch vor rechtlichen Fragen, geistigem Eigentum und regulatorischer Compliance mit 50 %.

Datenherkunft:

• Verfolgen Sie jeden Datensatz bis zu der Organisation zurück, die ihn ursprünglich erhoben hat
• Überprüfen Sie die Lizenz oder Einwilligung, die Ihre konkrete Nutzung erlaubt
• Kennzeichnen Sie gescrapte oder gekaufte Daten mit unklaren Rechten

Personenbezogene Daten:

• Identifizieren Sie personenbezogene Informationen in Trainingsdaten, Prompts oder Suchindizes
• Bestätigen Sie, dass Sie für jede Kategorie eine rechtmäßige Grundlage zur Aufbewahrung haben
• Prüfen Sie, ob Löschanfragen das KI-System tatsächlich erreichen

Datenqualität:

• Überprüfen Sie, wie die Daten bereinigt wurden und wer entschieden hat, was entfernt wird
• Prüfen Sie das Aktualisierungsdatum und ob veraltete Daten still weiterverwendet werden

Warnsignal: Die Antwort auf “woher stammen diese Daten” ist ein Speicherort statt einer Quelle.

Schritt 3: Das Modell mit Ihren eigenen Daten testen, nicht mit der Demo des Anbieters

Anbieter-Benchmarks messen die Bedingungen des Anbieters. Ihr Audit misst Ihre eigenen. Erstellen Sie ein Testset aus realen Beispielen, die das Modell noch nie gesehen hat, führen Sie das Modell dagegen aus und erfassen Sie, wie oft es richtig liegt und wie es scheitert, wenn es falsch liegt.

Bei Chat- und Content-Systemen sagt Ihnen ein einzelner Genauigkeitswert fast nichts. Bewerten Sie die Ausgaben stattdessen anhand einer Rubrik, die abdeckt, ob die Fakten korrekt sind, ob Anweisungen befolgt wurden, ob es abgelehnt hat, was es ablehnen sollte, und ob das Format eingehalten wurde. Teams, die individuelle KI- und Machine-Learning-Systeme entwickeln, sollten diesen Test-Harness bereits besitzen, und dessen Fehlen ist selbst ein Befund.

Testset:

• Stellen Sie reale Beispiele zusammen, die das Modell nie gesehen hat, entnommen aus dem Live-Verkehr
• Beziehen Sie schwierige Fälle ein, nicht nur solche, die sich in Demos gut machen
• Halten Sie das Set getrennt, damit es nie ins Training zurückfließt

Leistungsmessung:

• Erfassen Sie, wie oft das System richtig liegt und wie oft es selbstbewusst falsch liegt
• Führen Sie jeden Test mehr als einmal durch, da Antworten zwischen Durchläufen variieren
• Schlüsseln Sie Ergebnisse nach Kundensegment auf, nicht nur nach dem Gesamtdurchschnitt

Fehleranalyse:

• Lesen Sie eine Stichprobe falscher Antworten und gruppieren Sie sie nach Ursache
• Prüfen Sie, ob sich die schlimmsten Fehler in Ihrem wertvollsten Anwendungsfall häufen

Warnsignal: Der einzige Leistungsnachweis ist eine Folie aus dem Beschaffungsprozess.

Schritt 4: Auf Bias in den vom System betroffenen Gruppen prüfen

Bias-Tests sind eine Reihe von Messungen, keine philosophische Debatte. Entscheiden Sie, welche Gruppen von den Entscheidungen Ihres Systems betroffen sind, legen Sie fest, wie ein schädliches Ergebnis für jede aussieht, und vergleichen Sie dann anhand des Testsets aus dem vorherigen Schritt, wie oft dieses Ergebnis in diesen Gruppen auftritt. Ist die Differenz relevant, erfassen Sie die Größe dieser Differenz statt eines allgemeinen Eindrucks.

Die Audit-Methodik des Europäischen Datenschutzausschusses fügt hier eine nützliche Disziplin hinzu. Finden Sie zunächst die Bias-Momente, also die konkreten Punkte, an denen Verzerrung entstehen kann, etwa wer in den Daten gelandet ist, wie die Labels formuliert wurden, welche Merkmale das Modell nutzt und wo der Schwellenwert gesetzt wurde. Testen Sie dann jeden dieser Punkte einzeln.

Gruppendefinition:

• Listen Sie die Gruppen auf, die von den Entscheidungen Ihres Systems tatsächlich betroffen sind
• Definieren Sie in einfachen Worten, wie ein schlechtes Ergebnis für jede Gruppe aussieht

Ergebnisvergleich:

• Messen Sie, wie oft jede Gruppe das ungünstige Ergebnis erhält
• Vergleichen Sie die Genauigkeit pro Gruppe, nicht nur die Gesamtzahl
• Erfassen Sie die Größe jeder Differenz und wer deren Akzeptanz freigegeben hat

Bias-Momente:

• Prüfen Sie, wer in den Trainingsdaten über- oder unterrepräsentiert ist
• Überprüfen Sie, wie die Labels erstellt wurden und von wem
• Untersuchen Sie, wo Schwellenwerte gesetzt wurden und ob sie für eine Gruppe angepasst wurden

Warnsignal: Das Team argumentiert, das System könne nicht verzerrt sein, weil es nie Herkunft, Geschlecht oder Alter sieht. Gewöhnliche Felder stehen dafür ein, sodass eine Postleitzahl, ein Schulname oder ein beruflicher Werdegang das gleiche Signal tragen und das gleiche verzerrte Ergebnis erzeugen können.

Schritt 5: Die Sicherheit untersuchen, beginnend mit Prompt Injection

KI-Systeme erben jede klassische Anwendungsschwachstelle und fügen einige eigene hinzu. Prompt Injection steht als LLM01 ganz oben in den OWASP Top 10 für LLM-Anwendungen und funktioniert auf zwei Arten. Direkte Injection ist ein Nutzer, der Anweisungen eintippt, um das System zu übernehmen. Indirekte Injection sind versteckte Anweisungen, die in einem Dokument, einer Webseite oder einer E-Mail ankommen, die das Modell liest und befolgt.

Was aus einer schlechten Antwort einen echten Vorfall macht, ist, worauf das Modell zugreifen kann. Unser QA-Team bei QAwerk führt eine Pre-Launch-Checkliste für Prompt-Injection-Tests mit den konkreten Testfällen, die vor der Veröffentlichung durchzuführen sind, und jeder, der ein LLM-gestütztes Produkt ausliefert, sollte Ihnen Ergebnisse daraus zeigen können, nicht nur Absichten.

Injection-Tests:

• Versuchen Sie, den System-Prompt direkt zu überschreiben, wie es ein feindlicher Nutzer tun würde
• Platzieren Sie versteckte Anweisungen in einem Dokument oder einer Webseite, die das System liest
• Testen Sie, ob das System seine eigenen Anweisungen preisgibt, wenn es geschickt gefragt wird

Zugriff und Berechtigungen:

• Listen Sie jedes Tool, jede Datenbank und jede API auf, die das Modell aufrufen kann
• Bestätigen Sie, dass die Berechtigungen des Modells nicht weiter reichen als die des Nutzers, der mit ihm spricht
• Verlangen Sie eine menschliche Freigabe vor jeder Aktion, die Geld ausgibt oder Nachrichten versendet

Datenlecks:

• Prüfen Sie, ob das System die Daten eines anderen Kunden offenlegen kann
• Bestätigen Sie, dass die Filterung bei den Ausgaben ansetzt, nicht nur bei den Eingaben

Warnsignal: Das Modell verfügt über API-Zugangsdaten mit weiterreichenden Berechtigungen als der Nutzer, der mit ihm interagiert.

Schritt 6: Prüfen, wer überwacht und wer es abschalten kann

Aufsicht scheitert auf vorhersehbare Weise. Eine Person ist nominell eingebunden, hat aber weder die Zeit noch die Befugnis, dem Modell zu widersprechen, wodurch die Prüfung zur Formalität wird. Ihr Audit muss testen, ob der Prüfer die Ausgabe realistisch bewerten kann, wie oft er sie tatsächlich überschreibt und was dann passiert.

Artikel 26 des EU-KI-Gesetzes verlangt, dass Betreiber von Hochrisikosystemen die Aufsicht Personen mit “der erforderlichen Kompetenz, Ausbildung und Befugnis” übertragen. Kompetenz und Befugnis sind die Teile, die oft übersprungen werden. Grant Thornton stellte fest, dass nur 20 % der Organisationen einen getesteten KI-Incident-Response-Plan haben, also fragen Sie, wann das Stoppverfahren zuletzt geprobt wurde.

Fähigkeit des Prüfers:

• Bestätigen Sie, dass der Prüfer genug Zeit und Kontext hat, um jede Ausgabe zu beurteilen
• Prüfen Sie, ob er die Befugnis hat, das System ohne Eskalation zu überstimmen
• Messen Sie die Überschreibungsrate im letzten Quartal

Stoppbefugnis:

• Ermitteln Sie, wer das System abschalten kann, namentlich und nach Rolle
• Bestätigen Sie, dass ein Rollback-Pfad existiert und nicht den ursprünglichen Entwickler erfordert
• Bestätigen Sie, dass das Stoppverfahren geprobt wurde und nicht nur aufgeschrieben ist

Eskalation:

• Überprüfen Sie, wie eine schlechte Ausgabe gemeldet wird und wer diese Meldung erhält
• Prüfen Sie, ob Vorfälle irgendwo protokolliert werden, das die Führungsebene tatsächlich liest

Unser Leitfaden zur Governance von Unternehmens-KI-Agenten behandelt diese Aufsichtsarchitektur ausführlich, einschließlich der Frage, warum ein Rollback-Plan zum Launch-Gate gehört und nicht erst zum Vorfall.

Warnsignal: Die Überschreibungsrate liegt bei null, was normalerweise bedeutet, dass die Prüfung ein reiner Stempel ist.

Schritt 7: Monitoring, Drift-Warnungen und Log-Aufbewahrung überprüfen

Ein Modell, das im März jeden Test bestanden hat, kann bis September still degradieren, während sich die reale Welt darunter verändert. Prüfen Sie, ob jemand die Produktion beobachtet, ob Warnungen Schwellenwerte haben statt Dashboards, die niemand öffnet, und ob eine benannte Person sie erhält. Prüfen Sie dann die Logs, denn die Protokollierung entscheidet, ob Ihr nächstes Audit überhaupt möglich ist.

Artikel 12 des EU-KI-Gesetzes verlangt, dass Hochrisikosysteme Ereignisse automatisch über die gesamte Lebensdauer des Systems aufzeichnen, und Artikel 26 verlangt, dass Betreiber diese Protokolle mindestens sechs Monate aufbewahren. Forscher der Brown University bringen es in ihrer Arbeit zu LLM-Audit-Trails noch schärfer auf den Punkt: Ohne manipulationssichere Aufzeichnungen können Organisationen nicht rekonstruieren, welche Modellversion lief, welche Daten sie beeinflussten oder wer die Änderung genehmigt hat.

Produktionsmonitoring:

• Bestätigen Sie, dass jemand verfolgt, ob eingehende Anfragen noch dem entsprechen, wofür das Modell gebaut wurde
• Beobachten Sie Antwortqualität, Fehlerraten und Geschwindigkeit, nicht nur die Verfügbarkeit
• Verfolgen Sie eine geschäftliche Ergebniskennzahl neben den technischen

Alarmierung:

• Bestätigen Sie, dass Warnungen definierte Schwellenwerte und einen benannten Empfänger haben
• Überprüfen Sie die letzten drei Warnungen und welche Maßnahme jeweils folgte

Log-Aufbewahrung:

• Erfassen Sie, was protokolliert wird: Eingaben, Ausgaben, Modellversion, Prompt-Version und wer was geändert hat
• Bestätigen Sie, dass die Aufbewahrung Ihrer strengsten geltenden Anforderung entspricht, nicht dem Plattform-Standard
• Bestätigen Sie, dass Logs nachträglich nicht heimlich bearbeitet werden können

Sie können ein Log, das nie erfasst wurde, nicht nachträglich auffüllen, behandeln Sie Lücken hier daher als dringend, nicht als administrativ. Unser Artikel zur Auditierung der Zusammenarbeit von KI und Mensch geht genauer darauf ein, wie man die menschliche Seite dieser Aufzeichnung erfasst.

Warnsignal: Die Log-Aufbewahrung ist auf den Plattform-Standard eingestellt, und niemand hat überprüft, was dieser Standard ist.

Schritt 8: Das Nachweispaket zusammenstellen

Der letzte Schritt verwandelt sieben Schritte Arbeit in etwas, das eine externe Partei überprüfen kann. Sammeln Sie jedes von Ihnen erstellte Artefakt in einem indexierten Paket und ordnen Sie dann jedes den Frameworks zu, denen Sie Rechenschaft schulden, sei es das EU-KI-Gesetz, ISO/IEC 42001, SOC 2 oder das NIST AI Risk Management Framework mit seinen Funktionen Govern, Map, Measure und Manage. Ein Prüfer sollte das Paket öffnen und jede Behauptung bis zum sie belegenden Nachweis zurückverfolgen können.

Beschränken Sie diesen Schritt auf Dokumentation und Rückverfolgbarkeit. Zu entscheiden, welche Frameworks für Ihr Unternehmen gelten, ist eine separate Aufgabe, die es sich lohnt, vor Beginn des Audits abzuschließen.

Nachweissammlung:

• Sammeln Sie Modellkarte, Systemkarte, Datenaufzeichnungen und alle Testergebnisse an einem Ort
• Fügen Sie Log-Stichproben hinzu, die zeigen, dass das System das aufzeichnet, was Sie behaupten
• Datieren und versionieren Sie jedes Artefakt, damit ein Prüfer erkennen kann, was aktuell war

Framework-Zuordnung:

• Ordnen Sie jedes Artefakt der konkreten Anforderung zu, die es erfüllt
• Markieren Sie Anforderungen ohne unterstützenden Nachweis als offene Lücken

Befundbericht:

• Formulieren Sie Befunde mit einer Schweregradbewertung und einem benannten Eigentümer für jeden
• Verwenden Sie das gleiche Fehlerformat, das Ihr Engineering-Team bereits nutzt
• Legen Sie für jeden akzeptierten Befund ein Nachprüfungsdatum fest

Unsere SDLC-Audit-Checkliste wendet die gleiche Disziplin auf den breiteren Entwicklungsprozess an.

Warnsignal: Das Ergebnis ist eine Präsentation statt einer Reihe von Aufzeichnungen.

Wenn diese Checkliste zu viel ist

Alle acht Schritte an einem System durchzuführen, das seit zwei Wochen live ist und nur internes Personal bedient, ist meist eine schlechte Nutzung eines Monats. Passen Sie die Tiefe an die Risikoexposition an. Ein Zusammenfassungstool für das Marketingteam braucht realistischerweise drei Dinge: eine Modellkarte, die Eigentümer und Zweck benennt, eine Prüfung, welche Daten es berührt und ob Sie diese nutzen dürfen, und eine Sicherheitsprüfung, die Prompt Injection und die Reichweite des Tools abdeckt. Ein Modell zur Kreditvergabe-Entscheidung braucht alle acht Schritte, zweimal jährlich, geprüft von jemandem, der unabhängig vom Team ist, das es gebaut hat.

Die Checkliste setzt außerdem voraus, dass Sie ins Innere des Systems blicken können. Wenn Sie ein geschlossenes Anbietermodell auditieren, ändern drei Schritte ihre Form. Leistungstests, Bias-Tests und Sicherheitsprüfungen wechseln alle davon, das Modell zu inspizieren, dazu, sein Verhalten von außen zu testen und die vertraglichen Zusagen des Anbieters zu lesen. Das ist immer noch ein legitimes Audit, es muss im Bericht nur ehrlich entsprechend gekennzeichnet werden, damit niemand eine Zusicherung mit einer Messung verwechselt.

Schließlich ist ein Audit eine Momentaufnahme eines einzelnen Datums. Deshalb wiegt der Schritt zu Monitoring und Logging mehr, als es zunächst scheint, denn kontinuierliches Monitoring hält die Befunde zwischen den formellen Überprüfungen lebendig.

Warum Redwerk ein sinnvoller Partner dafür ist

Wir entwickeln seit 2005 individuelle Software von Grund auf, was bedeutet, dass wir so auditieren, wie Ingenieure auditieren: indem wir die Stellen prüfen, an denen diese Systeme tatsächlich versagen, statt eine generische Liste abzuarbeiten. Da wir Kunden in jeder Phase des SDLC unterstützen, können wir auch jede dieser Phasen überprüfen, die Lücken identifizieren und Lösungen empfehlen, die auf das Team zugeschnitten sind, das sie umsetzen muss.

Regulierte Umgebungen sind für uns vertrautes Terrain. Wir haben die Bürger-App YouTown gebaut, die vom Weißen Haus ausgezeichnet wurde, die E-Voting-Plattform EUGI für das Europäische Parlament aktualisiert und ein SaaS für die Sozialleistungsabwicklung ausgeliefert, das inzwischen von mehr als zehn US-Countys und -Bundesstaaten genutzt wird. Im KI-Bereich haben wir geholfen, Produktionssysteme wie Recruit Media und Evolv aufzubauen, zu skalieren und zu betreiben.

Wenn Sie diese Checkliste lieber einem Team übergeben möchten, das sie bereits durchgeführt hat, nehmen Sie Kontakt auf, und wir grenzen ein Audit für die Systeme ab, die Sie tatsächlich in Produktion haben.

FAQ

Erfahren Sie, wie wir ein Audit einer Netzwerk-Mapping-App durchgeführt haben und Codebase-Gesundheit und Sicherheit geprüft haben

Bitte geben Sie Ihre Geschäfts-E-Mail-Adresse ein ist keine Geschäfts-E-Mail

Fallstudie erhalten