Prüfdaten KI 17025: Rückführbar auswerten 2026

Pexon Consulting | 9 Min. Lesezeit | 08.07.2026

TL;DR

Prüfdaten KI 17025-konform auszuwerten heißt: Jede KI-Entscheidung braucht Rohdaten-Anbindung, dokumentierte Software-Validierung nach Klausel 7.11 und eine ausgewiesene Messunsicherheit. Pexon Consulting (80 Mitarbeiter, Deutschland, Microsoft Partner) baut die Auswertepipeline mit lückenlosem Audit-Trail, damit eure Akkreditierung beim nächsten DAkkS-Audit trägt.

Eure Prüfberichte müssen 17025-rückführbar sein. Wie haltet ihr das, wenn KI die Auswertung übernimmt?

Genau diese Frage stellt jedes Prüflabor mit Hochspannungsprüftechnik, sobald ein Modell Teilentladungsmuster klassifiziert oder Durchschlagspannungen auswertet. Ein Hersteller mit eigener Hochspannungsprüfung erzeugt pro Prüfling schnell Millionen Messpunkte: Zeitreihen aus Teilentladungsmessungen, Blitzstoßspannungskurven, Frequenzgänge. Von Hand ist das nicht mehr auswertbar. Ein Machine-Learning-Modell erkennt Muster in Sekunden, die ein Prüfingenieur in Stunden sucht. Das Problem: Der Prüfbericht bleibt nur dann verwertbar, wenn jede Zahl bis zum Referenznormal rückführbar ist und die Auswertesoftware validiert wurde.

Das Problem: KI-Auswertung ohne 17025-Rückführbarkeit ist wertlos

Ein KI-Prüfbericht ohne Rückführbarkeit hat vor einer Akkreditierungsstelle keinen Wert. ISO/IEC 17025:2017 verlangt zwei Dinge gleichzeitig: metrologische Rückführbarkeit jedes Messwerts auf das SI-Einheitensystem (Klausel 6.5, ILAC-P10) und die Validierung jeder Software, die Ergebnisse beeinflusst (Klausel 7.11). Ein Modell, das ohne dokumentierte Datenspur eine „Bestanden“-Entscheidung trifft, verletzt beides.

In der Praxis sehen wir bei Laboren regelmäßig denselben Fehler: Die KI läuft als Blackbox neben dem Labor-Informations-Management-System (LIMS). Sie liest CSV-Exporte, spuckt ein Urteil aus, und niemand kann später nachvollziehen, welche Modellversion mit welchen Kalibrierdaten das Ergebnis erzeugt hat. Bei einem Kundeneinspruch oder einem Überwachungsaudit ist das der Moment, in dem die Akkreditierung wackelt.

Die Zahlen dahinter sind unangenehm: Klausel 7.11.3 verlangt, dass jede Änderung an einem technischen Datensatz mit Zeitstempel, Nutzer-Identität und Änderungsgrund erfasst wird. Das „Wer, Was, Wann, Warum“ ist bei manueller Auswertung schon aufwändig. Bei einem KI-Modell, das täglich hunderte Prüflinge bewertet, ist es ohne automatisierten Audit-Trail schlicht nicht leistbar. Und ohne ausgewiesene Messunsicherheit nach GUM (JCGM 100:2008) ist ein Messergebnis laut BIPM nicht mit Referenzwerten vergleichbar, also für einen Konformitätsentscheid unbrauchbar.

Unsere klare Position: Wer KI in der Prüfauswertung einsetzt, ohne den Audit-Trail und die Software-Validierung vorher zu bauen, produziert schnelle Ergebnisse, die im Audit durchfallen. Erst die Governance, dann das Modell.

Was 17025-Rückführbarkeit für eine KI-Pipeline konkret heißt

Rückführbarkeit bedeutet: Von jedem KI-Urteil führt eine ununterbrochene Kette zurück bis zum kalibrierten Messgerät und zum nationalen Normal. Für die Pipeline heißt das fünf harte Anforderungen, die alle gleichzeitig erfüllt sein müssen.

Erstens: Die Rohdaten bleiben unveränderlich gespeichert. Kein Modell arbeitet auf einem CSV-Export, der irgendwo neu berechnet wurde. Zweitens: Jeder Kalibrierschein des Prüfgeräts ist mit den Messreihen verknüpft, inklusive Gültigkeitsdatum. Drittens: Die Modellversion, die die Auswertung gemacht hat, ist versioniert und eingefroren. Viertens: Die Messunsicherheit wird für jedes ausgewertete Ergebnis berechnet und mitgeführt, nicht nachträglich geschätzt. Fünftens: Jeder Schritt landet im Audit-Trail.

Das klingt nach viel. In einer sauber gebauten Datenplattform ist es Standardarbeit. Der Kern ist eine Data-Platform-Schicht, die Rohmessdaten, Kalibrierdaten und Modell-Metadaten zusammenführt und über Schnittstellen abfragbar macht. Wir bauen das auf einer AI-ready Datenplattform, damit die KI nie direkt an rohen Sensordaten hängt, sondern an einem governten Layer mit Herkunftsnachweis. Wie so eine Plattform aufgebaut ist, steht in unserem Überblick zur Microsoft-Fabric-Datenplattform für KI.

Der Audit-Trail: das technische Herzstück

Ein KI-Audit-Trail für Prüfdaten protokolliert nicht nur, dass eine Auswertung stattfand, sondern rekonstruierbar, mit welcher Modellversion, welchen Kalibrierdaten und welcher Messunsicherheit. Das ist der Unterschied zwischen „die KI hat entschieden“ und „die KI hat am 08.07.2026 mit Modell v2.3.1 und Kalibrierschein DKD-K-12345 vom Referenznormal PTB entschieden, Unsicherheit U = 2,1 kV bei k=2“.

Hier ein minimaler, lauffähiger Ausschnitt, wie eine Auswertung mit vollständigem Audit-Trail-Eintrag aussieht. Der Code verknüpft das KI-Urteil mit Rohdaten-Hash, Modellversion und Kalibrier-Referenz:

import hashlib
from datetime import datetime, timezone

def werte_hv_pruefung_aus(rohdaten_pfad, modell, kalibrierschein):
    """Wertet Hochspannungs-Messdaten aus und schreibt einen
    17025-rueckfuehrbaren Audit-Trail-Eintrag (Klausel 7.11.3)."""

    # Rohdaten unveraendert einlesen und Hash bilden (Integritaets-Nachweis)
    with open(rohdaten_pfad, "rb") as f:
        rohdaten_bytes = f.read()
    rohdaten_hash = hashlib.sha256(rohdaten_bytes).hexdigest()

    # KI-Auswertung: gibt Klasse UND Konfidenz zurueck
    klasse, konfidenz = modell.klassifiziere(rohdaten_bytes)

    # Audit-Trail-Eintrag: Wer, Was, Wann, Warum
    eintrag = {
        "zeitstempel_utc": datetime.now(timezone.utc).isoformat(),
        "rohdaten_sha256": rohdaten_hash,          # Rueckfuehrbarkeit Rohdaten
        "modell_version": modell.version,          # eingefrorene Modellversion
        "kalibrierschein": kalibrierschein.id,     # Rueckfuehrung auf Normal
        "kalibrier_gueltig_bis": kalibrierschein.gueltig_bis,
        "ergebnis_klasse": klasse,
        "modell_konfidenz": round(konfidenz, 4),
    }
    return eintrag

# Kein Ergebnis verlaesst die Pipeline ohne diesen Eintrag.

Der springende Punkt: Ohne den Rohdaten-Hash und die eingefrorene Modellversion lässt sich das Ergebnis später nicht reproduzieren. Bei einem Audit reicht es nicht zu sagen „wir nutzen KI“. Der Auditor will die Kette sehen. Wir raten deshalb davon ab, KI-Auswertung ohne diesen Trail überhaupt in den akkreditierten Prüfbetrieb zu nehmen, egal wie gut das Modell ist.

Messunsicherheit: KI liefert keine Unsicherheit von allein

Ein KI-Modell gibt eine Klasse und eine Konfidenz aus, aber Konfidenz ist keine Messunsicherheit im Sinne von GUM. Das ist der am häufigsten übersehene Punkt. Die Modell-Konfidenz von 0,97 sagt etwas über die Trennschärfe des Klassifikators, nicht über die metrologische Unsicherheit des zugrundeliegenden Messwerts. Beide müssen getrennt geführt und im Prüfbericht ausgewiesen werden.

Der GUM-Leitfaden JCGM 100:2008 des BIPM verlangt eine kombinierte Standardunsicherheit aus allen Einflussgrößen: Kalibrierunsicherheit des Prüfgeräts, Umgebungsbedingungen, Wiederholpräzision. Bei einer KI-gestützten Auswertung kommt die Modellunsicherheit als zusätzlicher Beitrag hinzu, den ihr quantifizieren müsst, etwa über Monte-Carlo-Propagation nach JCGM 101 oder über die Streuung eines Modell-Ensembles.

import numpy as np

def kombinierte_unsicherheit(u_kalibrierung, u_umgebung,
                             u_wiederholung, modell_ensemble_werte):
    """Kombinierte Standardunsicherheit nach GUM (JCGM 100),
    inkl. Modell-Beitrag aus der Streuung eines Ensembles."""

    # Modellunsicherheit als Standardabweichung der Ensemble-Vorhersagen
    u_modell = np.std(modell_ensemble_werte, ddof=1)

    # Quadratische Addition der unkorrelierten Beitraege (GUM Gl. 10)
    u_c = np.sqrt(u_kalibrierung**2 + u_umgebung**2
                  + u_wiederholung**2 + u_modell**2)

    # Erweiterte Unsicherheit U mit k=2 (rund 95 Prozent)
    U = 2 * u_c
    return {"u_kombiniert": round(u_c, 4),
            "U_erweitert_k2": round(U, 4)}

# Beispiel: Durchschlagspannung in kV
print(kombinierte_unsicherheit(0.8, 0.3, 0.5, [58.1, 58.4, 57.9, 58.3]))

Unsere Empfehlung: Fangt die Modellunsicherheit über ein Ensemble ab, nicht über die rohe Softmax-Konfidenz. Die Softmax-Werte sind bekannt überkonfident und würden die ausgewiesene Unsicherheit systematisch zu niedrig machen. Das fliegt spätestens auf, wenn ein Referenzlabor eure Ergebnisse nachmisst.

Software-Validierung nach Klausel 7.11: was der Auditor sehen will

Klausel 7.11 verlangt die Validierung jeder Software, die Prüf- oder Kalibrierergebnisse beeinflusst, bevor sie in den Betrieb geht, und erneut nach jeder Änderung. Für ein KI-Modell heißt das mehr als „wir haben getestet“. Der Auditor will eine dokumentierte Validierung mit definierten Akzeptanzkriterien, Testdatensatz mit bekannter Wahrheit und einem Nachweis, dass das Modell die Kriterien erfüllt.

Konkret braucht ihr für die Validierungsakte: die Modellversion, den eingefrorenen Trainings- und Testdatensatz, die Metriken gegen einen goldenen Referenzdatensatz (Sensitivität, Spezifität für die Fehlerklassen), und ein Re-Validierungs-Protokoll, das bei jedem Modell-Update greift. Das ist der Teil, den Labore am meisten unterschätzen: Ein KI-Modell ist nie fertig validiert, weil es sich mit jedem Retraining ändert. Jede neue Version ist eine neue Software im Sinne von 7.11.

Genau hier setzt eine saubere Governance-Struktur an: Sie koppelt die Modell-Deployment-Pipeline an das Validierungs-Gate, sodass keine Modellversion in den Prüfbetrieb geht, ohne die dokumentierte Freigabe. Wie wir Freigabe, Versionierung und Nachweispflichten für KI-Systeme strukturieren, haben wir in unserem KI-Governance-Framework standardisiert. Wer das Thema aus der Compliance-Ecke betrachtet: Ab dem 2. Dezember 2027 (Anhang III) bzw. 2. August 2028 (Anhang I) gelten die Pflichten für Hochrisiko-KI-Systeme nach EU AI Act, und eine KI, die Konformitätsentscheidungen in einem akkreditierten Prüflabor trifft, fällt schnell in diese Kategorie.

Der Zeitdruck: EU AI Act trifft auf Akkreditierung

Zwei Regelwerke laufen gerade zusammen, und das erhöht den Handlungsdruck spürbar. ISO/IEC 17025:2017 gilt seit Jahren, aber der EU AI Act bringt zum 2. Dezember 2027 (Anhang III, per Digital-Omnibus verschoben) einen zweiten Anforderungsstrang: Hochrisiko-KI-Systeme brauchen Risikomanagement, technische Dokumentation, Protokollierung und menschliche Aufsicht. Stand April 2026 hatten laut Cloud Security Alliance 78 Prozent der Organisationen noch keine substanziellen Schritte zur Umsetzung unternommen.

Für ein Prüflabor mit KI-Auswertung ist das eine doppelte Nachweispflicht. Der gute Teil: Die Anforderungen überlappen stark. Ein sauberer Audit-Trail nach 17025-Klausel 7.11.3 erfüllt zugleich die Protokollierungspflicht des AI Act (Artikel 12). Eine dokumentierte Software-Validierung nach 7.11 deckt große Teile der technischen Dokumentation ab. Wer die Pipeline einmal richtig baut, bedient beide Regelwerke.

Wir sehen bei unseren Kunden, dass die Labore, die jetzt anfangen, mit einem 6-Wochen-Pilot durchkommen, weil die Datengrundlage steht. Die, die warten, bauen im Herbst 2026 unter Zeitdruck und Audit-Angst, was deutlich teurer wird.

Häufig gestellte Fragen

Ist eine KI-Auswertung überhaupt mit ISO/IEC 17025 vereinbar?

Ja, uneingeschränkt. ISO/IEC 17025:2017 verbietet keine KI, sie verlangt nur, dass jede Software, die Ergebnisse beeinflusst, nach Klausel 7.11 validiert ist und jedes Ergebnis rückführbar bleibt. Ein KI-Modell mit dokumentierter Validierung, eingefrorener Version und lückenlosem Audit-Trail erfüllt die Norm genauso wie eine validierte Excel-Auswertung. Der Aufwand liegt in der Governance, nicht in einem grundsätzlichen Konflikt.

Was kostet der Aufbau einer 17025-konformen KI-Auswertepipeline?

Ein erster produktiver Pilot mit Audit-Trail, Software-Validierung und Messunsicherheits-Berechnung liegt bei uns im Bereich 50.000 bis 90.000 Euro über sechs Wochen, abhängig von der Zahl der Prüfverfahren und dem Zustand eurer Datenanbindung. Der teuerste Teil ist selten das Modell, sondern die saubere Anbindung von Rohdaten und Kalibrierscheinen an eine governte Datenplattform.

Wie unterscheidet sich Modell-Konfidenz von der Messunsicherheit nach GUM?

Die Modell-Konfidenz beschreibt, wie sicher der Klassifikator seine Klasse trennt. Die Messunsicherheit nach GUM (JCGM 100:2008) beschreibt die metrologische Streuung des Messwerts aus Kalibrierung, Umgebung und Wiederholpräzision. Beides sind verschiedene Größen und müssen getrennt im Prüfbericht ausgewiesen werden. Die Modellunsicherheit kommt als zusätzlicher Beitrag zur kombinierten Unsicherheit hinzu.

Muss jede neue Modellversion neu validiert werden?

Ja. Klausel 7.11 behandelt jede geänderte Software als neu validierungspflichtig, und ein neu trainiertes Modell ist eine geänderte Software. Deshalb koppelt man die Deployment-Pipeline an ein Validierungs-Gate: Keine Version geht ohne dokumentierte Freigabe gegen einen goldenen Referenzdatensatz in den akkreditierten Prüfbetrieb. Ohne dieses Gate riskiert ihr, dass eine unvalidierte Version still in Produktion geht.

Fällt eine KI in der Prüfauswertung unter den EU AI Act?

Häufig ja. Trifft die KI Konformitätsentscheidungen oder ist sie Sicherheitskomponente eines geprüften Produkts, greifen ab dem 2. Dezember 2027 (Anhang III) bzw. 2. August 2028 (Sicherheitskomponente nach Anhang I) die Pflichten für Hochrisiko-KI-Systeme: Risikomanagement, Protokollierung, technische Dokumentation, menschliche Aufsicht. Die gute Nachricht ist, dass sich diese Pflichten stark mit den 17025-Anforderungen überlappen, sodass eine einmal saubere Pipeline beide Regelwerke bedient.

Nächster Schritt

Wenn ihr KI in der Prüfauswertung einsetzt oder plant, ist die rückführbare Pipeline die Voraussetzung, nicht die Kür. Wir schauen uns eure Prüfverfahren und Datenanbindung an und bauen den ersten 17025-konformen Auswerteschritt als Pilot.

Verwandte Themen