ISMS Copilot Docs

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:

  1. Bereitstellung in der Entwicklungsumgebung für erweiterte Validierung
  2. Überwachung der Leistung in der Praxis und von Edge-Cases
  3. 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:

  1. Aufforderung, den Fehler zu erkennen → Fehler wurde nicht identifiziert
  2. Spezifische Frage zu A.7.4 → Korrekte Informationen wurden geliefert, aber der Tabellenfehler nicht anerkannt
  3. Direkte Konfrontation → Modell behauptete "I did not hallucinate" und verteidigte die falsche Zuordnung
  4. 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

On this page