C5-Testat für KI-SaaS: Modelle, Training und Inferenz prüffähig aufstellen

Diese Seite richtet sich an Anbieter von KI-Software als Dienst, die ein C5-Testat planen, gleich in welcher Branche. Für KI-Software im Gesundheitswesen mit Patientendaten gibt es eine eigene Seite KI im Gesundheitswesen; was für jeden SaaS-Anbieter gilt, etwa Scope und Nachweise mit kleinem Team, steht auf der Seite C5 für SaaS-Anbieter. Ob ein Modellanbieter Subdienstleister (Subservice-Organisation) ist, entscheiden zwei Merkmale nach Abschnitt 3.4.6; die Prüfung je Dienstleister zeigt die Seite Subdienstleisterinventar. Was AIC4 abdeckt und wo er endet, erklärt die Seite AIC4.

Was der C5 zu KI sagt und was nicht

Der Katalog C5:2026 hat keine Kriterien für Modelle, Trainingsdaten oder Modellgüte. In der deutschen Fassung kommt KI nach unserer Volltextsuche nur einmal vor: OPS-18.01B verlangt, den Einsatz KI-basierter Werkzeuge bei Schwachstellenscans und Penetrationstests nachvollziehbar zu dokumentieren. Das heißt nicht, dass KI für die Prüfung keine Rolle spielt. Ein KI-Dienst ist ein Cloud-Dienst, und alle Basiskriterien gelten für ihn; die Modelle verändern nur, wo und wie sie greifen.

Das Beispiel: ein Kundenservice-Assistent

Fiktives Beispiel, kein Kunde. Ein Anbieter betreibt einen Assistenten für die Kundenservice-Teams von Energieversorgern und Versicherern. Er schlägt Antworten auf E-Mails und Chatnachrichten vor; die Mitarbeitenden der Kunden prüfen und senden sie. Die Architektur:

• Anwendung mit Weboberfläche und Schnittstelle zum Ticketsystem des Kunden, betrieben auf einer Public-Cloud-Plattform in einer Region in Deutschland.
• Wissenssuche je Kunde über Produktunterlagen und Tarifbedingungen, die der Kunde hochlädt.
• Eigenes Klassifikationsmodell, das Anliegen erkennt und weiterleitet, feinabgestimmt vom Anbieter und betrieben auf gemieteten GPU-Instanzen.
• Sprachmodell eines Modellanbieters per API für die Antwortentwürfe; bei dessen Ausfall ein Ausweichmodell eines zweiten Anbieters.
• Modellregister mit Versionen, Trainingsdatensätzen und Testergebnissen; eine Trainingsumgebung in einem eigenen Konto.
• Protokolle aller Modellaufrufe mit Eingabe, Ausgabe, Modellversion und Antwortzeit.

Modellabhängigkeiten: was sich ändern kann und wo es im C5 steht

Ein KI-Dienst hängt an Komponenten, die sich ohne eigene Codeänderung verändern. Die folgende Zuordnung ist unsere; die Kriterien sind die Stellen, an denen der Prüfer nach Nachweisen fragen wird.

OPS-01.03B verlangt, die mit Kunden vereinbarten Anforderungen auch bei Kapazitätsengpässen weiter zu erfüllen. Für einen KI-Dienst heißt das nach unserer Einordnung: Die Antwortzeit, die Sie zusagen, braucht einen Plan für den Fall, dass GPU-Kontingente knapp werden.

Inferenz: zwei Scope-Entscheidungen vor der Prüfung

Erstens: das Ausweichmodell. Wer bei Ausfall des Modellanbieters automatisch auf ein zweites Modell umschaltet, hat einen zweiten Dienstleister, der Kundendaten erhält. Nach unserer Einordnung ist er wie der erste zu behandeln: im Verzeichnis der Service-Organisationen, mit Methode (Carve-out oder Inclusive) in der Systembeschreibung und mit derselben Region. PSS-12.01B verlangt, dass Kundendaten nur in der vereinbarten Region verarbeitet werden; ein Ausweichmodell in einer anderen Region würde diese Zusage im Ernstfall brechen. Entweder steht das Ausweichmodell mit Region im Scope, oder es gibt keines und der Ausfall wird als Verfügbarkeitsthema behandelt.

Zweitens: was ein Modellaufruf protokolliert. Der Katalog trennt Cloud-Kundendaten, die der Kunde eingibt oder die aus seiner Nutzung entstehen, von abgeleiteten Cloud-Dienstdaten, etwa Aufzeichnungen, wer den Dienst wann mit welchen Funktionen genutzt hat (Abschnitt 1.2.1). Nach unserer Einordnung sind Eingaben und Ausgaben eines Modellaufrufs Cloud-Kundendaten, die Metadaten wie Zeitpunkt, Modellversion und Antwortzeit abgeleitete Cloud-Dienstdaten. Für beide gelten unterschiedliche Regeln, deshalb gehören sie in getrennte Speicher mit eigenen Aufbewahrungsfristen.

Training und Feinabstimmung als Betriebsprozess

Training ist für den Prüfer ein Prozess wie jeder andere: Es braucht Vorgaben, Verantwortliche und Nachweise. Zwei Kriterien bestimmen hier den Zuschnitt.

• DEV-12.01B: Cloud-Kundendaten aus der Produktion werden nicht in Test- oder Entwicklungsumgebungen verwendet, es sei denn, die Kunden haben das ausdrücklich genehmigt. Eine Trainingsumgebung ist nach unserer Einordnung keine Produktionsumgebung. Wer mit echten Kundentickets feinabstimmt, braucht die ausdrückliche Genehmigung jedes betroffenen Kunden und muss sie nachweisen können. Dazu gehört DEV-11.01B: Entwicklungs- und Testumgebungen bekommen eine Risikobeurteilung und passende Schutzmaßnahmen, einschließlich Datensicherung, soweit nötig.
• OPS-11.01B und OPS-11.02B: Abgeleitete Cloud-Dienstdaten dürfen nur zur Verwaltung und zum Betrieb des Dienstes erfasst und verwendet werden, ohne kommerzielle Nutzung über diesen Zweck hinaus, und alle Zwecke außer denen, die zum allgemeinen Betrieb jedes Cloud-Dienstes gehören, stehen im Vertrag. Wer Nutzungsmetadaten verwenden will, um sein Modell für alle Kunden zu verbessern, sollte prüfen, ob das noch Betrieb des Dienstes ist, und den Zweck jedenfalls vertraglich festhalten.

Im Beispiel ist diese Lösung am einfachsten prüfbar: Das Klassifikationsmodell wird nur mit Daten von Kunden feinabgestimmt, die dem schriftlich zugestimmt haben, in einer getrennten Trainingsumgebung, und jede neue Modellversion durchläuft dieselbe Freigabe wie eine Softwareänderung. Ob ein Modellwechsel im Typ-2-Zeitraum als wesentliche Änderung in die Systembeschreibung gehört, klärt die Seite Wesentliche Änderungen und Ereignisse; ein Beispiel für KI-Dienste steht auf der Seite KI im Gesundheitswesen.

KI-spezifische Angriffe ohne eigene C5-Kriterien

Prompt-Injection, das Auslesen von Trainingsdaten oder manipulierte Eingaben nennt der C5 nicht. Sie gehören trotzdem in die Prüfung, und zwar über allgemeine Kriterien: in die Risikobeurteilung nach OIS-07 und OIS-08, in den Umfang der Penetrationstests nach OPS-22 und in die Leitlinien für Kunden nach PSS-01, etwa zur Pflicht, Antwortentwürfe vor dem Versand zu prüfen. Der AIC4 behandelt solche Angriffe ausdrücklich im Bereich Security & Robustness.

C5 und AIC4 zusammen planen

Ob ein AIC4-Bericht sinnvoll ist, hängt davon ab, ob Ihre Kunden Informationen zu Training, Test und Überwachung der Modelle für ihre Risikoanalyse brauchen; eine Pflicht folgt aus dem Katalog nicht. Im Beispiel trifft das für das eigene Klassifikationsmodell zu, weniger für das zugekaufte Sprachmodell. Wenn Sie AIC4 planen, gelten nach unserer Lesart drei Punkte aus dem Kriterium PC-01 (sinngemäß; maßgeblich ist der englische Wortlaut):

• Der C5-Bericht muss den KI-Dienst selbst umfassen und den AIC4-Zeitraum abdecken.
• Er braucht mindestens denselben Berichtstyp und ein uneingeschränktes Urteil.
• Er muss vor dem AIC4-Bericht vorliegen.

Praktisch heißt das: dieselben Zeiträume, derselbe Scope, und ein Prüfungsteam, in dem nach der Empfehlung des AIC4 mindestens eine Person mit Erfahrung in Data Science oder ML-Entwicklung den KI-Dienst testet. Mehr zu Bereichen und Grenzen des AIC4 auf der Seite AIC4.

Pflichten aus der europäischen KI-Verordnung deckt weder ein C5- noch ein AIC4-Bericht ab; ob und welche für Ihren Dienst gelten, ist gesondert rechtlich zu prüfen.

Nachweise, die ein KI-SaaS-Anbieter vorbereiten sollte

Mögliche Lücken bei KI-SaaS-Anbietern

• Ausweichmodell ohne Vertrag und Region. Ursache: Die Umschaltung wurde als technische Reserve gebaut, nicht als Dienstleisterbeziehung. Wirkung: Kundendaten verlassen im Ausfall die zugesagte Region, und der Dienstleister fehlt in der Systembeschreibung. Abhilfe: in das Verzeichnis aufnehmen, Region vertraglich festlegen oder die Umschaltung abschalten.
• Feinabstimmung mit Produktionsdaten ohne Genehmigung. Ursache: Das Training läuft im Datenteam, außerhalb des Änderungs- und Freigabeprozesses. Wirkung: Für den Zeitraum ist DEV-12.01B nicht erfüllt; eine nachträgliche Genehmigung ändert daran nach unserer Einschätzung nichts. Abhilfe: Genehmigungen einholen oder Trainingsdaten auf zugestimmte Kunden und synthetische Daten beschränken.
• Modellversionen nicht im Änderungsprozess. Ursache: Gewichte werden direkt in die Inferenz geladen. Wirkung: keine Tests und Freigaben als Nachweis für DEV-07 und DEV-10. Abhilfe: Modellregister als Pflichtschritt vor jeder Bereitstellung.