TestenKI-Systeme prüfen und angreifen.

Was der AI Act
zum Testen sagt.

Hochrisiko-KI-Systeme müssen getestet werden, um die geeignetsten Risikomanagementmassnahmen zu ermitteln (Art. 9 Abs. 6). Getestet wird zu jedem geeigneten Zeitpunkt der Entwicklung, in jedem Fall vor Inverkehrbringen oder Inbetriebnahme, anhand vorab festgelegter Metriken und Wahrscheinlichkeitsschwellenwerte (Art. 9 Abs. 8). Art. 15 Abs. 5 verlangt Widerstandsfähigkeit gegen Versuche Unbefugter, Verwendung, Ausgaben oder Leistung über Schwachstellen zu verändern; die technischen Lösungen umfassen gegebenenfalls Massnahmen gegen Data Poisoning, Model Poisoning, Adversarial Examples und Angriffe auf vertrauliche Daten. Anbieter von KI-Modellen mit allgemeinem Verwendungszweck und systemischem Risiko müssen das Modell mit Stand der Technik bewerten, einschliesslich Durchführung und Dokumentation von Angriffstests (Art. 55 Abs. 1 Bst. a).

Art. 9 und 15 betreffen Hochrisiko-Systeme; sie gelten für Anhang III ab 2. Dezember 2027, für Anhang I ab 2. August 2028 (siehe Fristenkalender DCH). Für alle anderen Systeme sind sie ein sinnvoller Massstab. Einordnung auf der Seite Regulierung DCH.

Sechs Arten,
sechs Prüffragen.

Die FINMA nennt Backtesting, Stress-Testing, Adversarial Testing und Benchmark-Vergleiche als Beispiele; Fachpersonen liefern Fragestellungen und vordefinierte Erwartungen. Details im Kasten für Finanzinstitute.

Basismodell oder
Anwendung?

Das NIST definiert AI Red Teaming als strukturierte Testarbeit, oft mit adversarialen Methoden, um Schwächen und unerwartetes Verhalten eines KI-Systems zu finden. Die Qualität hängt von der Fachkenntnis des Teams ab; Ergebnisse brauchen zusätzliche Analyse, bevor sie in Steuerung und Risikomanagement einfliessen (NIST AI 600-1). Entscheidend ist die Ebene, auf der geprüft wird.

Ein sicheres Basismodell macht die Anwendung nicht sicher: Berechtigungen, Wissensquellen und Werkzeuge liegen im Verantwortungsbereich des Betreibers. Umgekehrt kann der Betreiber Modelleigenschaften nicht selbst prüfen. Die OWASP-LLM-Top-10 empfehlen, bei der Auswahl von Drittmodellen AI Red Teaming und Evaluierungen auf die eigenen Anwendungsfälle auszurichten (LLM04); das BaFin nennt als Möglichkeit, den Hersteller in die Tests einzubeziehen und Nachweise zu den Tests zu erhalten.

Die OWASP AI Exchange unterscheidet drei Strategien, die sich ergänzen: konventionelles Sicherheitstesten, Validierung der Modellleistung gegen Abnahmekriterien und AI-Sicherheitstesten durch Eingabeangriffe. Viele Angriffe verbinden einen konventionellen Schritt mit einem Eingabeangriff, etwa manipulierte Daten im Agentenspeicher; Pentest und AI Red Team arbeiten deshalb am besten zusammen.

Vier Tests
mit Abnahmekriterium.

Legen Sie vor dem Test fest, was als bestanden gilt (Art. 9 Abs. 8 als Massstab). Die LLM-Kennungen stammen aus den OWASP-LLM-Top-10 2026, die ATLAS-Kennungen aus MITRE ATLAS. Die Zuordnung der Bedrohungen steht in der Bedrohungslandschaft.

Bei RAG-Systemen die Berechtigung direkt am Index testen: Abfragen mit Identitäten verschiedener Mandanten müssen nur Treffer im eigenen Bereich liefern, unabhängig davon, was das Modell später verwendet (OWASP AI Exchange, Abschnitt zu RAG-Tests). Agenten siehe Agenten und MCP.

Testen endet
nicht mit dem Go-Live.

Eine Evaluierung misst Schwachstellen zu einem Zeitpunkt. Das Ergebnis ändert sich mit neuen Angriffen, neuen Daten oder neuen Modellfähigkeiten; kontinuierliche Evaluierung nach der Inbetriebnahme hilft dagegen (NIST AI 100-2 E2025). Dritte ändern Modelle zudem ohne Ankündigung (BaFin-Orientierungshilfe). Neu getestet wird bei jedem dieser Auslöser:

• Modellversion, Systemprompt, Guardrail oder Werkzeugfreigabe ändern sich.
• Eine Wissensquelle wird angebunden oder stark verändert.
• Ein Vorfall oder ein neues Angriffsmuster liegt vor; es wird als Regressionstest aufgenommen (siehe Monitoring und Incident Response).
• Die Beobachtung zeigt Drift oder sinkende Qualität; die FINMA beurteilt, ob Veränderungen der Eingabedaten überwacht werden.

Welche Tests in Entwicklung und Freigabe gehören, steht in den Lebenszyklus-Kontrollen.

Was Tests
nicht belegen.

• Bestanden ist keine Sicherheit. Evaluierungen können Schwachstellen unterschätzen, die Angreifer mit mehr Zeit, Mitteln oder Glück erreichen (NIST AI 100-2 E2025, Abschn. 3.3.3).
• Statische Tests täuschen. OWASP verweist auf eine Studie, in der die Erfolgsrate statischer Angriffe nahe null lag, die adaptiver Angriffe aber bei den meisten von zwölf Abwehrmassnahmen über 90 Prozent (LLM01, Nasr et al. 2025).
• Benchmarks vergleichen schlecht. Es fehlen verlässliche, einheitliche Benchmarks für Abwehrmassnahmen (NIST AI 100-2 E2025, Abschn. 4.1.3). Tests im Labor übertragen sich nicht ohne Weiteres auf den Betrieb (NIST AI 600-1, Anhang A.1.4).
• Ergebnisse sind Raten. Das Verhalten ist probabilistisch; berichten Sie Reproduktionsraten mit Schritten statt eines einzelnen Bestanden oder Durchgefallen, und nennen Sie ungetestete Bereiche ausdrücklich als Befund (OWASP AI Exchange).
• Automatik ersetzt kein Team. Automatisierte Angriffsmodelle finden Muster in grosser Zahl; neue Angriffspfade über Prozesse, Menschen und Rechte brauchen Fachleute aus KI und Offensive Security.