KI-Modell-Tests & Validierung
ISMS Copilot führt vor der Bereitstellung neuer KI-Modelle oder Modell-Updates strenge interne Tests durch. Dies stellt sicher, dass die Plattform eine prüfungsgerechte Genauigkeit für Compliance-Frameworks wie ISO 27001, SOC 2 und ISO 42001 beibehält…
Übersicht
ISMS Copilot führt vor der Bereitstellung neuer KI-Modelle oder Modell-Updates strenge interne Tests durch. Dies stellt sicher, dass die Plattform eine prüfungsgerechte Genauigkeit für Compliance-Frameworks wie ISO 27001, SOC 2 und ISO 42001 beibehält.
In diesem Artikel wird unser Modell-Testworkflow sowie die Qualitätsstandards erläutert, die wir anwenden, bevor ein Modell in die Produktion geht.
Testworkflow
Bei der Evaluierung eines neuen Modells oder einer Modellvariante folgen wir diesem Prozess:
1. Isolierte Branch-Tests
Wir setzen das Kandidatenmodell in einer dedizierten Branch-Umgebung ein. Dies isoliert die Tests von den Produktionssystemen und ermöglicht eine umfassende Evaluierung, ohne aktive Nutzer zu beeinträchtigen.
2. Compliance-Aufgaben-Evaluierung
Wir testen das Modell anhand zentraler Compliance-Aufgaben, die den realen Einsatz von ISMS Copilot repräsentieren:
- Framework-Mapping – Präzises Zuordnen von Controls zwischen Standards (z. B. ISO 27001 ↔ ISO 42001)
- Genauigkeit der Control-Referenzen – Korrektes Zitieren von Annex-A-Controls im Vergleich zu Management-System-Klauseln
- Richtlinienerstellung – Erstellung prüfungsreifer Dokumente mit korrekter Struktur und Terminologie
- Gap-Analyse – Identifizierung von Compliance-Lücken in hochgeladenen Dokumenten
Die Test-Prompts nutzen dasselbe dynamische Wissens-Injektionssystem, das auch in der Produktion eingesetzt wird, um realistische Evaluierungsbedingungen zu gewährleisten.
3. Entscheidungskriterien
Ein Modell muss folgende Anforderungen erfüllen, um in die Produktion übernommen zu werden:
- Keine Control-Halluzinationen – Keine erfundenen oder falsch identifizierten Framework-Controls
- Strukturelle Genauigkeit – Korrekte Unterscheidung zwischen Annex-A-Controls und Klauseln
- Fehlererkennung – Fähigkeit, Fehler zu erkennen und bei Nachfrage zu korrigieren
- Leistungsverbesserungen – Messbare Fortschritte (Geschwindigkeit, Token-Limits, Kosten) ohne Genauigkeitsverlust
Modelle, die die Genauigkeitstests nicht bestehen, werden unabhängig von Leistungsvorteilen abgelehnt. Bei prüfungsrelevanten Aufgaben hat Zuverlässigkeit Vorrang vor Geschwindigkeit.
4. Bereitstellungspipeline
Bei erfolgreichen Tests:
- Bereitstellung in der Entwicklungsumgebung für erweiterte Validierung
- Überwachung der Leistung in der Praxis und von Edge-Cases
- Bereitstellung in der Produktion mit Rollback-Möglichkeit
Falls die Tests fehlschlagen, kehren wir zum vorherigen Modell zurück und dokumentieren die Ergebnisse für zukünftige Referenzen.
Praxisbeispiel: Grok-4-Fast-Reasoning
Dieses Beispiel zeigt unsere Teststandards in der Praxis.
Testkontext
Ziel: Evaluierung von Grok-4-Fast-Reasoning als Ersatz für Grok-4, um Token-Limit-Fehler zu beheben und Kosten zu senken.
Testaufgabe: Mapping von ISO 27001:2022-Controls zu ISO 42001:2023-Controls mit genauen Control-Referenzen im Kontext.
Der Fehler
Das Modell produzierte diesen Mapping-Fehler:
- ISO 42001 Control: A.8.5 Information for interested parties
- Grok-4-Fast-Reasoning zugeordnet zu: A.7.4 Communication
- Korrekte Zuordnung: Clause 7.4 Communication (nicht Annex A.7.4)
In ISO 27001:2022 ist Annex A.7.4 "Physical security monitoring" (Überwachung/Erkennung in Einrichtungen). Das Modell verwechselte die Nummerierung von Annex-A-Controls mit der Nummerierung von Management-System-Klauseln – ein grundlegender struktureller Fehler für Compliance-Arbeiten.
Fehlererkennung fehlgeschlagen
Die Reaktion des Modells auf Korrekturen war gleichermaßen besorgniserregend:
- Aufforderung, den Fehler zu erkennen → Fehler wurde nicht identifiziert
- Spezifische Frage zu A.7.4 → Korrekte Informationen wurden geliefert, aber der Tabellenfehler nicht anerkannt
- Direkte Konfrontation → Modell behauptete "I did not hallucinate" und verteidigte die falsche Zuordnung
- Fehler erst nach Vorwurf der "Unehrlichkeit" mit zitierter problematischer Tabelle eingestanden
Entscheidung
Ergebnis: ❌ Nicht für die Produktion geeignet
Begründung:
- Die Geschwindigkeit war beeindruckend, aber Control-Referenzfehler sind für prüfungsrelevante Ausgaben inakzeptabel
- Schlechte Fehlererkennung könnte Nutzer in die Irre führen, die den Ausgaben vertrauen
- Kann für Entwürfe funktionieren, erfordert aber menschliche Validierung jeder Control-Referenz
Durchgeführte Maßnahme: Rückkehr zu Grok-4 für die Produktionsbereitstellung.
Was dies für Nutzer bedeutet
Wenn Sie ISMS Copilot nutzen, profitieren Sie von Modellen, die diese Qualitätskontrollen durchlaufen haben:
- Framework-Genauigkeit – Controls und Klauseln werden korrekt referenziert
- Zuverlässigkeit – Modelle, die halluzinieren oder Korrekturen verweigern, werden abgelehnt
- Prüfungsbereitschaft – Ausgaben werden anhand realer Compliance-Mapping-Aufgaben getestet
Auch wenn wir gründlich testen, sollten Sie KI-Ausgaben stets anhand offizieller Standards überprüfen, bevor Sie sie an Prüfer weitergeben. Weitere Best Practices finden Sie in unseren Richtlinien zur verantwortungsvollen Nutzung.
Verwandte Ressourcen
- Verständnis und Vermeidung von KI-Halluzinationen – Wie wir erfundene Controls minimieren
- Übersicht zu KI-Sicherheit & verantwortungsvoller Nutzung – Unsere Sicherheitsvorkehrungen und Überwachungspraktiken
- Technische Übersicht des KI-Systems – Architektur und Details zur dynamischen Wissens-Injektion
- ISMS Copilot vs. Grok – Modellvergleiche und Fähigkeiten