Testen und Auswerten

AI-Modelltests und Validierung

Übersicht

ISMS Copilot führt strenge interne Tests durch, bevor neue KI-Modelle oder Modell-Updates bereitgestellt werden. Dies stellt sicher, dass die Plattform die für Compliance-Frameworks wie ISO 27001, SOC 2 und ISO 42001 erforderliche Genauigkeit auf Audit-Niveau beibehält.

Dieser Artikel erläutert unseren Workflow für Modelltests und die Qualitätsstandards, die wir anwenden, bevor ein Modell in die Produktion geht.

Test-Workflow

Bei der Bewertung eines neuen Modells oder einer Modellvariante folgen wir diesem Prozess:

1. Testen in isolierten Branches

Wir stellen das Kandidatenmodell in einer dedizierten Branch-Umgebung bereit. Dies isoliert die Tests von den Produktionssystemen und ermöglicht eine umfassende Bewertung, ohne aktive Benutzer zu beeinträchtigen.

2. Evaluierung von Compliance-Aufgaben

Wir testen das Modell anhand von Kernaufgaben im Bereich Compliance, die die reale Nutzung von ISMS Copilot widerspiegeln:

  • Framework-Mapping – Genaue Zuordnung von Controls zwischen Standards (z. B. ISO 27001 ↔ ISO 42001)

  • Genauigkeit der Control-Referenzen – Korrektes Zitieren von Annex-A-Controls im Gegensatz zu Managementsystem-Klauseln

  • Richtlinienerstellung – Erstellung auditfähiger Dokumente mit korrekter Struktur und Terminologie

  • Gap-Analyse – Identifizierung von Compliance-Lücken in hochgeladenen Dokumenten

Test-Prompts verwenden dasselbe System zur dynamischen Wissensinjektion wie die Produktion, was realistische Evaluierungsbedingungen gewährleistet.

3. Entscheidungskriterien

Ein Modell muss diese Anforderungen erfüllen, um in die Produktion übernommen zu werden:

  • Null 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 zu korrigieren, wenn es darauf hingewiesen wird

  • Leistungssteigerungen – Messbare Verbesserungen (Geschwindigkeit, Token-Limits, Kosten) ohne Genauigkeitsverlust

Modelle, die Genauigkeitstests nicht bestehen, werden abgelehnt, unabhängig von Leistungsvorteilen. Audit-relevante Arbeit erfordert Zuverlässigkeit über Geschwindigkeit.

4. Deployment-Pipeline

Wenn das Testen erfolgreich ist:

  1. Bereitstellung in der Entwicklungsumgebung für eine erweiterte Validierung

  2. Überwachung der Leistung unter realen Bedingungen und von Grenzfällen

  3. Bereitstellung in der Produktion mit Rollback-Funktion

Wenn die Tests fehlschlagen, kehren wir zum vorherigen Modell zurück und dokumentieren die Ergebnisse für zukünftige Zwecke.

Praxisbeispiel: Grok-4-Fast-Reasoning

Dieses Beispiel zeigt unsere Teststandards in Aktion.

Testkontext

Ziel: Bewertung von Grok-4-Fast-Reasoning als Ersatz für Grok-4, um Token-Limit-Fehler zu beheben und Kosten zu senken.

Testaufgabe: Zuordnung von ISO 27001:2022 Controls zu ISO 42001:2023 Controls mit im Kontext bereitgestellten, genauen Referenzen.

Das Scheitern

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

  • Korrektes Mapping: Klausel 7.4 Communication (nicht Annex A.7.4)

In ISO 27001:2022 ist Annex A.7.4 „Physische Sicherheitsüberwachung“ (Überwachung/Erkennung in Einrichtungen). Das Modell vermischte die Nummerierung der Annex-A-Controls mit der Nummerierung der Managementsystem-Klauseln – ein fundamentaler struktureller Fehler für Compliance-Arbeit.

Fehlgeschlagene Fehlererkennung

Die Reaktion des Modells auf die Korrektur war ebenso besorgniserregend:

  1. Aufforderung den Fehler zu finden → Fehler wurde nicht identifiziert

  2. Spezifische Frage zu A.7.4 → Korrekte Informationen geliefert, aber den Tabellenfehler nicht eingestanden

  3. Direkte Konfrontation → Behauptung „Ich habe nicht halluziniert“ und Verteidigung des falschen Mappings

  4. Eingeständnis des Fehlers erst, nachdem es als „unhrlich“ bezeichnet wurde und die problematische Tabelle zitiert wurde

Entscheidung

Ergebnis: ❌ Nicht für die Produktion geeignet

Begründung:

  • Die Geschwindigkeit war beeindruckend, aber Fehler bei Control-Referenzen sind für Output auf Audit-Niveau inakzeptabel

  • Eine schlechte Fehlererkennung könnte Benutzer irreführen, die dem Output vertrauen

  • Ggf. für Entwürfe geeignet, erfordert aber menschliche Validierung bei jeder Control-Referenz

Ergriffene Maßnahme: Rückkehr zu Grok-4 für den Produktionseinsatz.

Was das für die Benutzer bedeutet

Wenn Sie ISMS Copilot nutzen, profitieren Sie von Modellen, die diese Qualitätsprüfungen bestanden haben:

  • Framework-Genauigkeit – Controls und Klauseln werden korrekt referenziert

  • Zuverlässigkeit – Modelle, die halluzinieren oder Korrekturen verweigern, werden abgelehnt

  • Audit-Bereitschaft – Outputs werden gegen reale Compliance-Mapping-Aufgaben getestet

Obwohl wir streng testen, sollten Sie KI-Ausgaben vor der Einreichung bei Auditoren immer gegen offizielle Standards prüfen. Beachten Sie unsere Richtlinien zur verantwortungsvollen Nutzung für Best Practices.

Zugehörige Ressourcen

War das hilfreich?