Das zentrale Problem: Ihr ISO 9001 QMS wurde für die alte, deterministische Welt gebaut. Wir haben erlebt, wie selbst hochzertifizierte Unternehmen mit ihren Qualitätssystemen an den Risiken von Künstlicher Intelligenz scheitern. Das System war perfekt darin, Konsistenz zu garantieren: Jeden Tag das gleiche, erwartbare Ergebnis.
Doch KI – insbesondere generative Modelle – arbeitet prinzipiell anders: Sie ist inkonsistent, probabilistisch und kreativ.
Dieses Scheitern liegt nicht an der ISO 9001 selbst. Es liegt daran, dass der Standard zu starr auf traditionelle Software-Entwicklungszyklen (SDLC) angewendet wird, anstatt die spezifischen Lebenszyklen von KI-Systemen zu berücksichtigen. Bei KI reicht ein einfacher „Haken“ auf einer Checkliste nicht mehr aus. Stattdessen benötigen Sie dynamische „Leitplanken“ (Guardrails), die jede einzelne Ausgabe in Echtzeit auf ihre Sicherheit und Korrektheit prüfen.
Hier kollidieren zwei Welten: Die deterministische Kontrolle des klassischen Qualitätsmanagements mit der inhärenten, probabilistischen Varianz der neuen KI-Systeme.
Wenn ein Qualitätsmanager versucht, eine KI wie eine CNC-Fräse oder eine Abfüllanlage zu behandeln, führt das zu tiefem Frust auf beiden Seiten.
Es ist, als würde man versuchen, Jazzmusik mit einem Messschieber zu bewerten.
Hier ist der Klassiker, der in fast jedem ISO 9001-Audit für Softwareentwicklung (gemäß IEC 62304 oder allgemeinen Best Practices) abgefragt wird und bei KI grandios scheitert:
Die Metrik: Automatisierte Regressions-Tests mit "Exact String Matching" (100% Wiederholgenauigkeit).
In der klassischen Software-Entwicklung (z.B. für eine Buchhaltungs-Software) erstellt der QM eine Suite von Testfällen, die jede Nacht durchlaufen ("Nightly Builds").
Input: Funktion berechne_mwst(100, 0.19)
Erwarteter Output (Golden Sample): 19.00
Warum das gut ist: Jede Abweichung deutet auf einen Bug im Code hin. Der QM schaut morgens auf das Dashboard: "Alles Grün, wir können releasen."
Anmerkung zur Automatisierung: Die Herausforderung des „Messschiebers“ entsteht primär bei probabilistischen, generativen KI-Systemen (wie dem Support-Bot). Bei deterministischen KI-Automatisierungen (z.B. einer Klassifizierungs-Engine oder einem simplen Routing-Algorithmus) ist die Forderung des QMS-Experten absolut richtig: Diese Prozesse müssen so weit wie möglich auf einfache, binäre True/False-Tests heruntergebrochen werden, um eine klare Auditierbarkeit zu gewährleisten.
Das Unternehmen wendet dieselbe Logik auf seinen neuen KI-Support-Bot an. Sie definieren ein "Golden Set" von 100 Fragen und perfekten Antworten, um sicherzustellen, dass die KI nach einem Update nicht "dümmer" geworden ist.
Der Testfall #42:
Input (Prompt): "Wie setze ich mein Passwort zurück?"
Erwarteter Output (Golden Sample): "Gehe auf Einstellungen > Sicherheit und klicke auf 'Passwort ändern'."
Der KI-Testlauf (Nacht 1): Die KI antwortet:
"Navigiere bitte zu den Einstellungen, wähle den Bereich Sicherheit und drücke dort den Button 'Passwort ändern'."
Die Metrik des QMS:
Am nächsten Morgen kommt der Qualitätsmanager ins Büro und sieht, dass 95% der Regressionstests fehlgeschlagen sind.
Panik: Er stoppt das Release. "Die Software ist völlig kaputt! Nichts stimmt mehr mit den Anforderungen überein!"
Realität: Die Software funktioniert perfekt. Die Antworten sind inhaltlich (semantisch) absolut korrekt, nur syntaktisch anders formuliert.
Der Effekt: Das Team beginnt, die roten Warnlampen zu ignorieren ("Ach, das ist nur die KI, das ist immer rot").
Das ist der gefährlichste Moment in der Qualitätssicherung: Alarm Fatigue.
Wenn dann wirklich ein Fehler passiert (z.B. die KI sagt: "Poste dein Passwort auf Twitter"), geht dieser echte Fehler in der Flut der "False Positives" (falschen Alarme) unter, weil niemand mehr die Logs prüft.
Der QM muss die Metrik zwingend von „Exact Match“ (Syntaktische Gleichheit) auf „Semantic Similarity“ (Semantische Ähnlichkeit) umstellen.
Wichtig: Ein LLM-Judge kann im Sinne des mathematischen Beweises keine „absolute Korrektheit“ feststellen. Es bewertet die semantische Ähnlichkeit und damit die Akzeptanz der Antwort im Vergleich zu einem definierten Referenz-Muster (Golden Sample). Die Metrik wechselt von der deterministischen Verifikation zur probabilistischen Validierung.
Anstatt String A == String B zu prüfen, nutzt man moderne Metriken wie:
Embedding Distance (Cosine Similarity): Man wandelt beide Sätze in Vektoren (Zahlenreihen) um und misst den Winkel dazwischen. Wenn der Wert > 0.95 ist, gilt der Test als BESTANDEN, auch wenn die Wörter andere sind.
LLM-as-a-Judge: Man nutzt eine zweite, sehr starke KI (wie GPT-4), um die Antwort der ersten KI zu bewerten: „Beinhaltet Antwort B alle Fakten aus Antwort A? Ja/Nein.“
Die traditionelle Metrik misst Buchstaben. Die KI-Metrik muss Bedeutung messen – oder präziser: die akzeptable Abweichung von der Referenz.
Wenn du einem Auditor sagst: "Eine KI prüft meine KI", hört er: "Ich lasse den Fuchs den Hühnerstall bewachen."
Um das ISO-9001-konform zu dokumentieren (insbesondere Clause 8.6 und 7.1.5 für "Ressourcen zur Überwachung und Messung"), musst du das Konzept der "Kalibrierung des Prüfmittels" anwenden.
Beim Messschieber drehst du an einer kleinen Schraube, bis der Zeiger bei Null steht.
Beim LLM-Judge "drehst" du am System-Prompt und an den Few-Shot-Beispielen, bis das Urteil mit dem des Menschen übereinstimmt.
Bevor du irgendetwas kalibrierst, brauchst du ein "Urmeter". In der KI ist das nicht eine physikalische Größe, sondern Konsens.
Schritt A: Du nimmst 50 repräsentative Frage-Antwort-Paare deiner KI.
Schritt B: Drei deiner besten menschlichen Experten bewerten diese 50 Fälle blind.
Schritt C: Wo sich die Experten uneinig sind, wird diskutiert, bis ein Gold Standard (Ground Truth) festgelegt ist.
Das ist dein Kalibrier-Normal.
Jetzt lässt du deinen LLM-Judge (z.B. GPT-4 mit einem spezifischen Bewertungs-Prompt) auf diese 50 Fälle los.
Szenario:
Die Abweichung: Der LLM-Judge ist "zu nett". Er ist nicht richtig kalibriert.
Die Justierung (Das "Drehen an der Schraube"): Du gehst nicht in den Code. Du gehst in den Prompt des Judges.
Vorher: "Bewerte, ob die Antwort hilfreich ist."
Nachher (Kalibriert): "Du bist ein strenger Auditor. Bestrafe jede sachliche Ungenauigkeit mit FAIL, auch wenn der Tonfall höflich ist. Ignoriere Rechtschreibfehler."
Zusätzlich gibst du dem Prompt 3 Beispiele (Few-Shot): "Hier ist eine Antwort, die höflich klingt, aber falsch ist → Das musst du als FAIL bewerten."
Du wiederholst den Testlauf. Wenn LLM und Mensch jetzt zu >90% (oder was dein Schwellenwert ist) übereinstimmen, ist das "Gerät" kalibriert.
Das ist der kritische Unterschied zum Messschieber. Ein Messschieber verändert sich nur durch Verschleiß. Ein LLM verändert sich durch externe Updates (wenn du eine API wie OpenAI nutzt) oder durch Data Drift.
Du brauchst eine Kontinuierliche Validierungs-Strategie im QMS:
Jedes Mal, wenn du das Basis-Modell änderst (z.B. Upgrade von gpt-4-0613 auf gpt-4-turbo-preview), ist deine vorherige Kalibrierung ungültig.
Aktion: Das Golden Dataset muss einmal komplett neu durchlaufen.
QMS-Regel: "Kein Modell-Update in der Produktion ohne neuen Kalibrier-Bericht."
Da Provider wie OpenAI manchmal "stille Updates" machen, bei denen sich das Verhalten subtil ändert, ohne dass sich die Versionsnummer ändert, brauchst du einen Frühwarnindikator.
Der Prozess: Du lässt jeden Tag (automatisiert in deiner CI/CD-Pipeline) eine Mini-Stichprobe (z.B. 5 feste Fälle aus dem Golden Set) durch den Judge laufen.
Der Trigger: Wenn der Judge bei diesen 5 Fällen, die er gestern noch richtig bewertet hat, heute plötzlich anders entscheidet → ALARM.
Folge: Prozessstopp. Manuelle Prüfung. Ggf. vollständige Re-Kalibrierung (Prompt-Anpassung).
Bei einem Messschieber kannst du auf das DAkkS-Zertifikat zeigen. Worauf zeigst du bei GPT-4?
Viele QMs werden hier nervös, weil sie denken, sie stünden mit leeren Händen da. Aber die ISO 9001 lässt dich hier nicht im Stich – sie hat eine eingebaute "Notfall-Tür", genau für Fälle wie diesen, in denen die Physik aufhört und die Kognition anfängt.
Du zitierst dem Auditor nicht den ersten Teil von 7.1.5.2 (Rückführbarkeit auf nationale Normale), sondern den zweiten Teil:
"...wenn es keine solchen Normale gibt, muss die Grundlage, die zur Kalibrierung oder Verifizierung verwendet wird, als dokumentierte Information aufbewahrt werden."
Da es (noch) kein "Physikalisch-Technisches Bundesanstalt (PTB) Referenz-LLM" gibt, musst du dein eigenes Referenznormal erschaffen.
Du erklärst: "Herr Auditor, wir befinden uns hier nicht im Bereich der dimensionalen Messtechnik (Länge, Gewicht), sondern im Bereich der sensorischen Prüfung (wie bei Weinverkostungen oder visuellen Oberflächenprüfungen). Hier gibt es kein 'Ur-Kilogramm', sondern Experten-Konsens."
Statt eines DAkkS-Kalibrierscheins legst du ein Dokument vor: "Spezifikation des Referenz-Datensatzes (Golden Set)".
Dieses Dokument muss drei Dinge beweisen, um die "Rückführbarkeit" zu simulieren:
Du zeigst, dass dein Golden Set nicht "ausgedacht" ist, sondern auf externen Fakten basiert.
"Unsere Test-Antworten basieren auf der aktuellen EU-Verordnung XYZ und den Leitlinien der Fachgesellschaft ABC."
Der Trick: Damit hast du die Rückführbarkeit hergestellt. Nicht auf ein "Normal", sondern auf externe Literatur/Gesetze. Das ist in der Wissensarbeit das Äquivalent zum Ur-Kilogramm.
Der Auditor wird fragen: "Wer sagt, dass deine Menschen recht haben?" Du zeigst die Qualifikationsmatrix (Kapitel 7.2) deiner Experten.
"Die Antworten im Golden Set wurden von Dr. Müller (20 Jahre Erfahrung) und Frau Schmidt (Senior Engineer) verifiziert."
Das ist deine "Kalibrierstelle".
Jetzt kommt die Mathematik, die den Auditor beruhigt.
"Wir haben gemessen, wie stark unsere menschlichen Experten untereinander übereinstimmen. Der Inter-Rater-Reliability Score (Cohen's Kappa) liegt bei 0.85. Unser KI-System erreicht eine Übereinstimmung von 0.82 mit diesem Konsens."
Aussage: Das System ist so zuverlässig wie ein Expertengremium.
Erstelle ein Formblatt "Nachweis der Prüfmitteleignung für KI-Evaluatoren". Darin steht:
Du hast dein Judge-LLM kalibriert, dokumentiert, freigegeben. Zwei Monate später macht OpenAI ein stilles Update, dein "Kanarienvogel" schlägt an.
Was passiert jetzt mit allen Produktions-Entscheidungen, die dein Judge in den letzten zwei Monaten getroffen hat?
Das ist der Moment, in dem der QM den Unterschied zwischen einem systematischen Fehler und einem zufälligen Fehler verstehen muss.
Deine Frage zielt auf den "Scope of Impact" (Auswirkungsbereich) gemäß ISO 9001 Kapitel 8.7 ("Steuerung nichtkonformer Ergebnisse").
Hier ist die brutale Wahrheit: Wenn dein Kanarienvogel heute anschlägt, gibt es zwei Möglichkeiten.
Um zwischen einem Sudden Shift (technisches Update) und einem Slow Drift (schleichende Erosion) zu unterscheiden, brauchst du eine forensische Methode, die wir "Time-Travel Backtesting" nennen.
Das Ziel: Wir müssen die Kausalität finden. Hat sich das Werkzeug geändert (Modell-Update) oder hat sich das Material geändert (Daten-Drift)?
Das Setup: Du hast deine Logs der letzten 8 Wochen. Du hast die Inputs (Prompts) und die damaligen Bewertungen deines Judges.
Die Analyse: Du nimmst jeden Montag der letzten 8 Wochen eine Stichprobe von 20 Fällen und jagst sie heute erneut durch den aktuellen Judge.
Das Diagramm der Wahrheit: Du vergleichst den Score von damals mit dem Score von heute.
Diagnose: Das ist ein Event. Ein API-Update, eine Config-Änderung, ein Server-Patch.
Forensischer Beweis: Prüfe den system_fingerprint (bei OpenAI) oder die API-Versions-Header in den Logs. Wenn sich dieser String am Tag X geändert hat, hast du den "Täter".
Diagnose: Das ist Erosion. Entweder "vergisst" das Modell Instruktionen (Catastrophic Forgetting bei feingetunten Modellen) oder – viel wahrscheinlicher – die Realität (die Kundenfragen) hat sich langsam verändert, und dein Judge-Prompt passt nicht mehr perfekt auf die neuen Nuancen (Concept Drift).
ISO 8.5.6 verlangt, dass Änderungen überprüft und verifiziert werden, bevor sie umgesetzt werden. Aber hier ist die Änderung ja schon passiert ("unauthorized change").
Wie heilst du diesen Bruch im QMS?
Das ist ein "Ungeplanter Änderungsvorfall".
Isolierung (Containment): Du identifizierst das genaue Datum des "Sturzes" (z.B. letzter Dienstag).
Risikobewertung: Alle Entscheidungen vor Dienstag sind valide. Alle seit Dienstag sind "verdächtig".
Maßnahme: Du sperrst die Charge ab Dienstag. Du führst eine Sonderprüfung durch.
Dokumentation (8.5.6): Du eröffnest im Nachhinein einen Change Request.
Das ist viel gefährlicher, weil es keinen klaren "Tag X" gibt. Hier greift nicht das Änderungsmanagement, sondern die Managementbewertung (9.3) und die Ressourcenüberwachung.
Du musst eine "Grenzmuster-Analyse" machen:
Du definierst einen Toleranzbereich.
Beispiel: "Eine Abweichung von 5% in der Strenge des Judges ist akzeptabel (Messunsicherheit)."
Du suchst den Punkt in der Kurve, an dem die Linie die 5%-Marke durchbrochen hat. Sagen wir, das war in Woche 5.
Die Entscheidung:
Change Management: Hier ist die "Änderung" nicht das Modell, sondern dein Prompt. Du musst den Prompt jetzt ändern (re-engineeren), um den Drift auszugleichen. Das ist ein klassischer, geplanter Change nach 8.5.6.
Um Diskussionen mit dem Auditor zu vermeiden, ob es ein Shift oder Drift war, nutze technische Metadaten.
Viele moderne LLM-APIs (wie OpenAI) senden im Response-Header einen system_fingerprint. Das ist ein Hash-Wert, der den internen Zustand der Gewichte repräsentiert.
Der Audit-Trail: Dein QMS muss vorschreiben, dass dieser Fingerprint geloggt wird.
Der Beweis: Wenn du dem Auditor zeigen kannst: "Schau, vom 01.01. bis 14.02. war der Fingerprint immer fp_44709d6fcb. Am 15.02. wechselte er auf fp_a24b4d. Genau da begannen die Fehler." → Dann ist es bewiesenermaßen ein Lieferanten-Problem (Shift) und kein interner Prozessfehler.
Bei Komplyzen helfen wir Organisationen, KI & Automatisierung mit Struktur, Verantwortung und Wirkung zu gestalten – durch smarte Compliance und klare Governance.
KI und Automatisierung entfalten ihr volles Potenzial erst dann, wenn Vertrauen und Governance von Anfang an eingebaut sind.
Füge unter 8.5.6 (Änderungssteuerung bei KI-Komponenten) hinzu:
"Bei KI-Modellen, die als SaaS bezogen werden, gilt jede Änderung des system_fingerprint oder der Modell-Version als signifikante Änderung. Tritt eine solche Änderung ungeplant auf, wird sofort ein automatisierter Regressions-Test (Backtesting) angestoßen. Bei schleichenden Änderungen (Drift) ohne Versionssprung greift die wöchentliche Trendanalyse der Prüfmittel-Kalibrierung."
Damit hast du den "Albtraum" in einen Standardprozess verwandelt.
Die Integration von KI-Risikomanagement in das QMS ist nicht nur eine Frage der Compliance, sondern eine strategische Notwendigkeit. Unternehmen, die KI-Risiken effektiv managen, können das Vertrauen ihrer Kunden und Stakeholder gewinnen und sich einen Wettbewerbsvorteil verschaffen.
Die EU AI Act und ISO/IEC 42001 sind bereits da. Organisationen, die jetzt handeln, positionieren sich strategisch – sie bauen Vertrauen durch Governance von Anfang an.
Dein ISO 9001 QMS braucht keine komplette Neuentwicklung. Es braucht Evolution. Die Frage ist nur: Fängst du heute damit an, oder wartest du, bis dein nächstes Audit die Lücken aufdeckt?