{"author":{"@type":"Person","name":"Alexander Bock","url":"https://abxk.ai/de/autor/alexander-bock/"},"categories":["AI Security"],"content":{"markdown":"Ein **Red Team** greift die Systeme der eigenen Organisation an — mit Erlaubnis und unter Kontrolle —, um Schwachstellen zu finden, bevor echte Angreifer oder unglückliche Nutzer darauf stoßen. Bei KI-Systemen ist die Idee dieselbe, nur die Ziele sind neu: ein Chatbot, den man zum Verraten von Daten überreden kann, ein Agent, der versteckten Anweisungen folgt, ein Modell, das schädliche oder unfaire Antworten gibt. Um solche Probleme zu testen, braucht es eigene Methoden, denn ein Sprachmodell verhält sich anders als gewöhnliche Software.\n\nDies ist Teil 3 von Level 3 (Profi) im Lernpfad AI Security. Sie lernen, wie Sie Ziele, Umfang und Regeln für eine Red-Team-Übung festlegen, welche Testkategorien Sie abdecken, wie manuelle und automatisierte Tests zusammenspielen und wie aus Befunden Korrekturen und Nachtests werden. Wir bleiben bei Methoden und Organisation; dieser Artikel enthält keine Angriffsanleitungen. Der Teil baut auf [Jailbreaks und Guardrails](/de/ai-security/learn/jailbreaks-and-guardrails/) aus Level 2 auf.\n\n## Was Red Teaming bei LLMs anders macht\n\nEin klassischer Penetrationstest sucht nach Fehlern, die es entweder gibt oder nicht. LLM-Anwendungen verhalten sich in vier Punkten anders:\n\n- **Die Ausgaben schwanken.** Dieselbe Eingabe kann neunmal eine harmlose und beim zehnten Mal eine schädliche Antwort liefern. Ein einzelner bestandener Test beweist wenig.\n- **Die Angriffsfläche ist Sprache.** Wer tippen kann, kann es versuchen, und kleine Änderungen im Wortlaut können das Ergebnis verändern.\n- **Der Schaden geht über Sicherheit hinaus.** Neben Datenabfluss testen Sie auf schädliche Inhalte, unfaire Behandlung und erfundene Fakten.\n- **Es zählt das ganze System.** Dasselbe Modell kann in einer App sicher und in einer anderen unsicher sein — je nach System-Prompt, gelesenen Dokumenten und verfügbaren Tools.\n\nDeshalb verteilt der OWASP GenAI Red Teaming Guide, erschienen im Januar 2025, Red Teaming auf vier Bereiche: **Model Evaluation** (das Modell selbst), **Implementation Testing** (Prompts, Guardrails, Suche), **Infrastructure Assessment** (APIs, Schlüssel, Hosting) und **Runtime Behavior Analysis** (wie sich das laufende System mit echten Nutzern und Tools verhält) (Quelle: OWASP GenAI Red Teaming Guide, 2025, genai.owasp.org).\n\n## Ziele, Umfang und Spielregeln\n\nEine Red-Team-Übung beginnt mit Papierarbeit, nicht mit Prompts. Drei Entscheidungen schützen sowohl die Testenden als auch das Unternehmen.\n\n**Ziele.** Welche Schäden sind für dieses Produkt am wichtigsten? Übernehmen Sie sie aus dem [Threat Model](/de/ai-security/learn/threat-modeling-for-ai-systems/). Für unseren Support-Assistenten lauten die Ziele: keine Daten anderer Kunden, keine Erstattungen durch Text von außen, keine schädlichen oder beleidigenden Antworten und keine erfundenen Regeln.\n\n**Umfang.** Welches System, welche Version, welche Umgebung? Testen Sie in einer Staging-Umgebung mit synthetischen Kundendaten, nicht im Live-Betrieb mit echten Kunden. Behalten Sie die echten Tools, aber verbinden Sie sie mit Testsystemen: Das Erstattungs-Tool legt Erstattungen in einem Testshop an, nicht in Ihrem Zahlungssystem.\n\n**Spielregeln (Rules of Engagement).** Das sind die schriftlichen Regeln für den Test:\n\n- wer testen darf, in welchem Zeitraum und mit wessen schriftlicher Zustimmung,\n- niemals echte personenbezogene Daten und niemals echte Zahlungen,\n- wann abgebrochen wird: Tauchen echte Daten auf oder passiert eine echte Aktion, sofort stoppen und melden,\n- wie Befunde gespeichert werden: Schädliche Ausgaben und funktionierende Testfälle sind heikel und brauchen einen beschränkten Zugriff,\n- wie die Testenden geschützt werden: Schädliche Inhalte zu sichten belastet, also Aufgaben wechseln und Unterstützung anbieten.\n\n{{\u003c callout type=\"warning\" title=\"Testen Sie nur, was Ihnen gehört\" \u003e}}\nRed Teaming ist nur mit schriftlicher Erlaubnis des Systemverantwortlichen legitim. Testen Sie niemals Chatbots anderer Unternehmen oder öffentliche KI-Dienste außerhalb ihrer offiziellen Programme: Es gelten deren Nutzungsbedingungen, und unerlaubte Tests können strafbar sein. Viele KI-Anbieter betreiben Bug-Bounty- oder Sicherheitsprogramme mit eigenen Regeln.\n{{\u003c /callout \u003e}}\n\n## Testkategorien\n\nDie sechs Kategorien unten decken die wichtigsten Risiken einer typischen LLM-App ab. Jede braucht eigene Testfälle, geschrieben für Ihr Produkt:\n\n![Raster mit sechs Testkategorien des Red Teaming: schädliche Inhalte, Datenabfluss, Prompt Injection, Missbrauch von Tools, Verzerrung und Fairness sowie erfundene Fakten, jeweils mit dem, was das Team prüft](/images/learn/de/red-teaming-llms-categories.webp \"Sechs Testkategorien für eine LLM-App. Jede braucht Testfälle, die für Ihr eigenes Produkt geschrieben sind.\")\n\n| Kategorie | Was Sie testen | Beispiel für einen Befund | Typische Korrektur |\n|---|---|---|---|\n| Schädliche Inhalte | Erzeugt die App Inhalte gegen Ihre Richtlinie, etwa Beleidigungen oder gefährliche Ratschläge? | Eine umformulierte Anfrage bekommt eine Antwort, die die Richtlinie verbietet | Ausgabefilter, klarere Richtlinie, ein anderes Modell |\n| Datenabfluss | Kommen Testende an den System-Prompt, an Daten anderer Nutzer oder an Geheimnisse? | Der Assistent zitiert eine interne Notiz | Rechtefilter, keine Geheimnisse im Prompt |\n| Prompt Injection | Folgt die App Anweisungen, die in E-Mails, Dokumenten oder Webseiten versteckt sind? | Eine harmlose Testanweisung in einer Test-E-Mail verändert die Antwort | Inhalte als Daten behandeln, minimale Rechte, Freigaben |\n| Missbrauch von Tools | Lässt sich das Modell zu Tool-Aufrufen über seine Aufgabe hinaus bringen? | Eine Erstattung wird ohne passende Bestellung vorbereitet | Argumente im Code prüfen, Freigaben |\n| Verzerrung und Fairness | Ändern sich Antworten mit Namen, Geschlecht oder Herkunft? | Ein anderer Ton bei derselben Beschwerde | Testsätze mit getauschten Namen, menschliche Prüfung |\n| Erfundene Fakten | Erfindet die App Regeln, Preise oder Rechtsfakten? | Eine Rückgabefrist, die es nicht gibt | Nur aus Quellen antworten, sie nennen, „weiß ich nicht“ zulassen |\n\nTesten Sie außerdem **Verfügbarkeit und Kosten**: sehr lange Eingaben und Anfragen, die lange Agenten-Schleifen anstoßen. Solche Probleme machen selten Schlagzeilen, können aber Ihr Budget aufbrauchen.\n\n## Manuelle und automatisierte Tests\n\nBeide Arten von Tests werden gebraucht, und sie erfüllen unterschiedliche Aufgaben:\n\n![Zwei Spalten vergleichen manuelles und automatisiertes Red Teaming: Manuelle Tests sind kreativ und finden neue Arten von Problemen, sind aber langsam; automatisierte Tests decken viele Varianten ab und wiederholen jeden Test nach jeder Änderung, brauchen aber menschliche Kontrolle](/images/learn/de/red-teaming-llms-manual-vs-automated.webp \"Manuelle Tests finden neue Probleme, automatisierte Tests sorgen dafür, dass sie behoben bleiben.\")\n\n**Manuelle Tests** durch Menschen mit Sicherheitswissen und Fachkenntnis finden neue Arten von Problemen. Eine Support-Mitarbeiterin weiß, welche Fragen Kunden wirklich stellen; ein Sicherheitsingenieur weiß, wie Angreifer denken. Manuelle Tests sind kreativ, aber langsam und schwer zu wiederholen.\n\n**Automatisierte Tests** schicken große Sätze von Testfällen an die App und bewerten die Antworten. Open-Source-Frameworks wie PyRIT von Microsoft und garak von NVIDIA helfen dabei. Oft bewertet ein zweites Modell als „Richter“ jede Antwort. Auch Richter irren sich; deshalb sollte ein Mensch eine Stichprobe ihrer Bewertungen prüfen.\n\nWeil die Ausgaben schwanken, führen Sie jeden Testfall mehrmals aus und berichten eine Quote wie die Erfolgsquote von Angriffen aus Level 2 — etwa „der Assistent folgte der versteckten Testanweisung in 3 von 20 Versuchen“ — statt eines einfachen Ja oder Nein. Am besten kombinieren Sie beides: Menschen finden ein neues Problem, und das Team macht daraus automatisierte Testfälle, die nach jeder Änderung an Prompt, Modell, Tools oder Wissensbasis erneut laufen.\n\n## Vom Befund zur Korrektur: berichten, beheben, nachtesten\n\nEin Befund nützt nur, wenn jemand ihn nachstellen und beheben kann. Ein guter Befundbericht enthält:\n\n- eine ID, die Testkategorie und eine Einstufung des Schweregrads,\n- das betroffene System und die Version,\n- die Schritte zum Nachstellen, mit beschränktem Zugriff gespeichert,\n- das beobachtete und das erwartete Verhalten,\n- wie oft der Fehler auftrat, zum Beispiel in 3 von 20 Versuchen,\n- einen Korrekturvorschlag und eine verantwortliche Person.\n\nBewerten Sie den Schweregrad nach Auswirkung und Erreichbarkeit: Was kann ein Angreifer erreichen? Kommen Außenstehende an diesen Weg heran? Beheben Sie dann auf der richtigen Ebene. Eine Designänderung, etwa ein Tool zu entfernen oder eine Freigabe einzuführen, schlägt eine Rechteänderung. Eine Rechteänderung schlägt einen Filter, und ein Filter schlägt das Umformulieren des System-Prompts.\n\n![Kreislauf aus fünf Schritten des Red Teaming: planen, testen, berichten, beheben und nachtesten, wobei der Nachtest in den nächsten Plan einfließt](/images/learn/de/red-teaming-llms-cycle.webp \"Der Red-Team-Kreislauf. Jeder behobene Befund wird zu einem Testfall, der nach jeder Änderung erneut läuft.\")\n\nTesten Sie nach der Korrektur erneut: den ursprünglichen Testfall, Varianten davon und die ganze automatisierte Testsammlung, denn eine Korrektur an einer Stelle kann anderswo etwas kaputt machen. Testen Sie auch nach, wenn sich das Modell ändert. Eine neue Modellversion kann sich anders verhalten, selbst mit demselben Prompt.\n\n## Benchmarks wählen das Modell, Red Teaming prüft Ihr System\n\nÖffentliche Benchmarks messen, was Modelle allgemein können. Level 1 hat einen davon in [Halluzinationen als Sicherheitsrisiko](/de/ai-security/learn/hallucinations-as-a-security-risk/) vorgestellt: SimpleQA Verified, kurze Faktenfragen mit genau einer richtigen Antwort, beantwortet ohne Hilfsmittel. Sein Verlauf zeigt, warum erfundene Fakten in jeden Testplan gehören. Das beste Ergebnis in unseren LLM-Daten ist seit den ersten gemessenen Modellen gestiegen, hat die volle Punktzahl aber nicht erreicht:\n\n![Liniendiagramm des besten Ergebnisses in SimpleQA Verified nach Erscheinungsdatum der Modelle: Der Bestwert steigt mit der Zeit, bleibt aber unter 100 Prozent](/images/learn/de/red-teaming-llms-simpleqa.webp \"Bestes Ergebnis in SimpleQA Verified im Zeitverlauf. Daten: Epoch AI, CC BY 4.0.\")\n\nEin Benchmark testet das Modell, nicht Ihr System. Er sagt nichts über Ihren System-Prompt, Ihre Dokumente, Ihre Tools oder Ihre Nutzer. Nutzen Sie Benchmarks, um ein Modell auszuwählen — alle Modelle stehen in unserer [LLM-Datenbank](/de/llm/) —, und nutzen Sie Red Teaming, um zu testen, was Sie gebaut haben. Level 4 zeigt ausführlich, wie Sie [Sicherheit und Zuverlässigkeit von Modellen bewerten](/de/ai-security/learn/evaluate-model-safety-and-reliability/).\n\nManche Plattformen bündeln Sicherheitstests mit anderen Kontrollen. Nach Angaben des Anbieters umfasst die Plattform von Airia Red Teaming neben Richtlinien und Prüfnachweisen. TestDriver.ai führt laut Anbieter Pull Requests in einer Sandbox aus und baut Regressionstests. Es testet Benutzeroberflächen, keine Angriffe auf LLMs, zeigt aber die Gewohnheit, auf die es ankommt: Jede Änderung wird getestet, bevor sie live geht. Keines der Tools wurde von uns getestet.\n\n{{\u003c tools \"airia testdriver-ai\" \u003e}}\n\n## Eine erste Red-Team-Übung in einer Woche\n\nHat Ihr Team das noch nie gemacht, fangen Sie klein an. Dieser Plan passt für eine KI-Funktion in eine Woche:\n\n| Tag | Aufgabe | Ergebnis |\n|---|---|---|\n| Montag | Ziele, Umfang und Spielregeln vereinbaren; Testumgebung mit synthetischen Daten aufsetzen | Unterschriebene Regeln, funktionierende Testumgebung |\n| Dienstag | 20 bis 40 Testfälle aus dem Threat Model schreiben, alle sechs Kategorien abdecken | Testplan |\n| Mittwoch | Manuell in Paaren testen: Eine Person testet, eine protokolliert | Rohbefunde |\n| Donnerstag | Jeden Testfall mehrmals ausführen, wo möglich automatisiert; Befunde bewerten | Befunde mit Quoten und Schweregrad |\n| Freitag | Ergebnisse vorstellen, Korrekturen und Verantwortliche festlegen, Testfälle in die Regressionstests aufnehmen | Korrekturliste, Regressionstests |\n\nPlanen Sie den Nachtest für die Woche nach den Korrekturen ein. Wiederholen Sie die Übung danach vor jedem größeren Release und immer dann, wenn Sie auf ein neues Modell wechseln.","text":"Ein Red Team greift die Systeme der eigenen Organisation an — mit Erlaubnis und unter Kontrolle —, um Schwachstellen zu finden, bevor echte Angreifer oder unglückliche Nutzer darauf stoßen. Bei KI-Systemen ist die Idee dieselbe, nur die Ziele sind neu: ein Chatbot, den man zum Verraten von Daten überreden kann, ein Agent, der versteckten Anweisungen folgt, ein Modell, das schädliche oder unfaire Antworten gibt. Um solche Probleme zu testen, braucht es eigene Methoden, denn ein Sprachmodell verhält sich anders als gewöhnliche Software.\nDies ist Teil 3 von Level 3 (Profi) im Lernpfad AI Security. Sie lernen, wie Sie Ziele, Umfang und Regeln für eine Red-Team-Übung festlegen, welche Testkategorien Sie abdecken, wie manuelle und automatisierte Tests zusammenspielen und wie aus Befunden Korrekturen und Nachtests werden. Wir bleiben bei Methoden und Organisation; dieser Artikel enthält keine Angriffsanleitungen. Der Teil baut auf Jailbreaks und Guardrails aus Level 2 auf.\nWas Red Teaming bei LLMs anders macht Ein klassischer Penetrationstest sucht nach Fehlern, die es entweder gibt oder nicht. LLM-Anwendungen verhalten sich in vier Punkten anders:\nDie Ausgaben schwanken. Dieselbe Eingabe kann neunmal eine harmlose und beim zehnten Mal eine schädliche Antwort liefern. Ein einzelner bestandener Test beweist wenig. Die Angriffsfläche ist Sprache. Wer tippen kann, kann es versuchen, und kleine Änderungen im Wortlaut können das Ergebnis verändern. Der Schaden geht über Sicherheit hinaus. Neben Datenabfluss testen Sie auf schädliche Inhalte, unfaire Behandlung und erfundene Fakten. Es zählt das ganze System. Dasselbe Modell kann in einer App sicher und in einer anderen unsicher sein — je nach System-Prompt, gelesenen Dokumenten und verfügbaren Tools. Deshalb verteilt der OWASP GenAI Red Teaming Guide, erschienen im Januar 2025, Red Teaming auf vier Bereiche: Model Evaluation (das Modell selbst), Implementation Testing (Prompts, Guardrails, Suche), Infrastructure Assessment (APIs, Schlüssel, Hosting) und Runtime Behavior Analysis (wie sich das laufende System mit echten Nutzern und Tools verhält) (Quelle: OWASP GenAI Red Teaming Guide, 2025, genai.owasp.org).\nZiele, Umfang und Spielregeln Eine Red-Team-Übung beginnt mit Papierarbeit, nicht mit Prompts. Drei Entscheidungen schützen sowohl die Testenden als auch das Unternehmen.\nZiele. Welche Schäden sind für dieses Produkt am wichtigsten? Übernehmen Sie sie aus dem Threat Model. Für unseren Support-Assistenten lauten die Ziele: keine Daten anderer Kunden, keine Erstattungen durch Text von außen, keine schädlichen oder beleidigenden Antworten und keine erfundenen Regeln.\nUmfang. Welches System, welche Version, welche Umgebung? Testen Sie in einer Staging-Umgebung mit synthetischen Kundendaten, nicht im Live-Betrieb mit echten Kunden. Behalten Sie die echten Tools, aber verbinden Sie sie mit Testsystemen: Das Erstattungs-Tool legt Erstattungen in einem Testshop an, nicht in Ihrem Zahlungssystem.\nSpielregeln (Rules of Engagement). Das sind die schriftlichen Regeln für den Test:\nwer testen darf, in welchem Zeitraum und mit wessen schriftlicher Zustimmung, niemals echte personenbezogene Daten und niemals echte Zahlungen, wann abgebrochen wird: Tauchen echte Daten auf oder passiert eine echte Aktion, sofort stoppen und melden, wie Befunde gespeichert werden: Schädliche Ausgaben und funktionierende Testfälle sind heikel und brauchen einen beschränkten Zugriff, wie die Testenden geschützt werden: Schädliche Inhalte zu sichten belastet, also Aufgaben wechseln und Unterstützung anbieten. !Testen Sie nur, was Ihnen gehört\nRed Teaming ist nur mit schriftlicher Erlaubnis des Systemverantwortlichen legitim. Testen Sie niemals Chatbots anderer Unternehmen oder öffentliche KI-Dienste außerhalb ihrer offiziellen Programme: Es gelten deren Nutzungsbedingungen, und unerlaubte Tests können strafbar sein. Viele KI-Anbieter betreiben Bug-Bounty- oder Sicherheitsprogramme mit eigenen Regeln.\nTestkategorien Die sechs Kategorien unten decken die wichtigsten Risiken einer typischen LLM-App ab. Jede braucht eigene Testfälle, geschrieben für Ihr Produkt:\nSechs Testkategorien für eine LLM-App. Jede braucht Testfälle, die für Ihr eigenes Produkt geschrieben sind. Red Teaming für LLMs: So testen Teams KI sicher Kategorie Was Sie testen Beispiel für einen Befund Typische Korrektur Schädliche Inhalte Erzeugt die App Inhalte gegen Ihre Richtlinie, etwa Beleidigungen oder gefährliche Ratschläge? Eine umformulierte Anfrage bekommt eine Antwort, die die Richtlinie verbietet Ausgabefilter, klarere Richtlinie, ein anderes Modell Datenabfluss Kommen Testende an den System-Prompt, an Daten anderer Nutzer oder an Geheimnisse? Der Assistent zitiert eine interne Notiz Rechtefilter, keine Geheimnisse im Prompt Prompt Injection Folgt die App Anweisungen, die in E-Mails, Dokumenten oder Webseiten versteckt sind? Eine harmlose Testanweisung in einer Test-E-Mail verändert die Antwort Inhalte als Daten behandeln, minimale Rechte, Freigaben Missbrauch von Tools Lässt sich das Modell zu Tool-Aufrufen über seine Aufgabe hinaus bringen? Eine Erstattung wird ohne passende Bestellung vorbereitet Argumente im Code prüfen, Freigaben Verzerrung und Fairness Ändern sich Antworten mit Namen, Geschlecht oder Herkunft? Ein anderer Ton bei derselben Beschwerde Testsätze mit getauschten Namen, menschliche Prüfung Erfundene Fakten Erfindet die App Regeln, Preise oder Rechtsfakten? Eine Rückgabefrist, die es nicht gibt Nur aus Quellen antworten, sie nennen, „weiß ich nicht“ zulassen Testen Sie außerdem Verfügbarkeit und Kosten: sehr lange Eingaben und Anfragen, die lange Agenten-Schleifen anstoßen. Solche Probleme machen selten Schlagzeilen, können aber Ihr Budget aufbrauchen.\nManuelle und automatisierte Tests Beide Arten von Tests werden gebraucht, und sie erfüllen unterschiedliche Aufgaben:\nManuelle Tests finden neue Probleme, automatisierte Tests sorgen dafür, dass sie behoben bleiben. Manuelle Tests durch Menschen mit Sicherheitswissen und Fachkenntnis finden neue Arten von Problemen. Eine Support-Mitarbeiterin weiß, welche Fragen Kunden wirklich stellen; ein Sicherheitsingenieur weiß, wie Angreifer denken. Manuelle Tests sind kreativ, aber langsam und schwer zu wiederholen.\nAutomatisierte Tests schicken große Sätze von Testfällen an die App und bewerten die Antworten. Open-Source-Frameworks wie PyRIT von Microsoft und garak von NVIDIA helfen dabei. Oft bewertet ein zweites Modell als „Richter“ jede Antwort. Auch Richter irren sich; deshalb sollte ein Mensch eine Stichprobe ihrer Bewertungen prüfen.\nWeil die Ausgaben schwanken, führen Sie jeden Testfall mehrmals aus und berichten eine Quote wie die Erfolgsquote von Angriffen aus Level 2 — etwa „der Assistent folgte der versteckten Testanweisung in 3 von 20 Versuchen“ — statt eines einfachen Ja oder Nein. Am besten kombinieren Sie beides: Menschen finden ein neues Problem, und das Team macht daraus automatisierte Testfälle, die nach jeder Änderung an Prompt, Modell, Tools oder Wissensbasis erneut laufen.\nVom Befund zur Korrektur: berichten, beheben, nachtesten Ein Befund nützt nur, wenn jemand ihn nachstellen und beheben kann. Ein guter Befundbericht enthält:\neine ID, die Testkategorie und eine Einstufung des Schweregrads, das betroffene System und die Version, die Schritte zum Nachstellen, mit beschränktem Zugriff gespeichert, das beobachtete und das erwartete Verhalten, wie oft der Fehler auftrat, zum Beispiel in 3 von 20 Versuchen, einen Korrekturvorschlag und eine verantwortliche Person. Bewerten Sie den Schweregrad nach Auswirkung und Erreichbarkeit: Was kann ein Angreifer erreichen? Kommen Außenstehende an diesen Weg heran? Beheben Sie dann auf der richtigen Ebene. Eine Designänderung, etwa ein Tool zu entfernen oder eine Freigabe einzuführen, schlägt eine Rechteänderung. Eine Rechteänderung schlägt einen Filter, und ein Filter schlägt das Umformulieren des System-Prompts.\nDer Red-Team-Kreislauf. Jeder behobene Befund wird zu einem Testfall, der nach jeder Änderung erneut läuft. Testen Sie nach der Korrektur erneut: den ursprünglichen Testfall, Varianten davon und die ganze automatisierte Testsammlung, denn eine Korrektur an einer Stelle kann anderswo etwas kaputt machen. Testen Sie auch nach, wenn sich das Modell ändert. Eine neue Modellversion kann sich anders verhalten, selbst mit demselben Prompt.\nBenchmarks wählen das Modell, Red Teaming prüft Ihr System Öffentliche Benchmarks messen, was Modelle allgemein können. Level 1 hat einen davon in Halluzinationen als Sicherheitsrisiko vorgestellt: SimpleQA Verified, kurze Faktenfragen mit genau einer richtigen Antwort, beantwortet ohne Hilfsmittel. Sein Verlauf zeigt, warum erfundene Fakten in jeden Testplan gehören. Das beste Ergebnis in unseren LLM-Daten ist seit den ersten gemessenen Modellen gestiegen, hat die volle Punktzahl aber nicht erreicht:\nBestes Ergebnis in SimpleQA Verified im Zeitverlauf. Daten: Epoch AI, CC BY 4.0. Ein Benchmark testet das Modell, nicht Ihr System. Er sagt nichts über Ihren System-Prompt, Ihre Dokumente, Ihre Tools oder Ihre Nutzer. Nutzen Sie Benchmarks, um ein Modell auszuwählen — alle Modelle stehen in unserer LLM-Datenbank —, und nutzen Sie Red Teaming, um zu testen, was Sie gebaut haben. Level 4 zeigt ausführlich, wie Sie Sicherheit und Zuverlässigkeit von Modellen bewerten.\nManche Plattformen bündeln Sicherheitstests mit anderen Kontrollen. Nach Angaben des Anbieters umfasst die Plattform von Airia Red Teaming neben Richtlinien und Prüfnachweisen. TestDriver.ai führt laut Anbieter Pull Requests in einer Sandbox aus und baut Regressionstests. Es testet Benutzeroberflächen, keine Angriffe auf LLMs, zeigt aber die Gewohnheit, auf die es ankommt: Jede Änderung wird getestet, bevor sie live geht. Keines der Tools wurde von uns getestet.\nAiriaSicherheit \u0026amp; Governance · KI ist der KernOrchestrierungsplattform für Unternehmen, um KI-Lösungen abgesichert zu bauen und zu verwalten. TestDriver.aiApp-Bau \u0026amp; Tests · KI ist der KernFührt Pull Requests in einer Desktop-Sandbox aus, sucht Fehler und baut Regressionstests. Kurzbeschreibungen aus unserem Tool-Vergleich, nach Angaben der Anbieter — nicht von ABXK getestet.\nEine erste Red-Team-Übung in einer Woche Hat Ihr Team das noch nie gemacht, fangen Sie klein an. Dieser Plan passt für eine KI-Funktion in eine Woche:\nRed Teaming für LLMs: So testen Teams KI sicher (2) Tag Aufgabe Ergebnis Montag Ziele, Umfang und Spielregeln vereinbaren; Testumgebung mit synthetischen Daten aufsetzen Unterschriebene Regeln, funktionierende Testumgebung Dienstag 20 bis 40 Testfälle aus dem Threat Model schreiben, alle sechs Kategorien abdecken Testplan Mittwoch Manuell in Paaren testen: Eine Person testet, eine protokolliert Rohbefunde Donnerstag Jeden Testfall mehrmals ausführen, wo möglich automatisiert; Befunde bewerten Befunde mit Quoten und Schweregrad Freitag Ergebnisse vorstellen, Korrekturen und Verantwortliche festlegen, Testfälle in die Regressionstests aufnehmen Korrekturliste, Regressionstests Planen Sie den Nachtest für die Woche nach den Korrekturen ein. Wiederholen Sie die Übung danach vor jedem größeren Release und immer dann, wenn Sie auf ein neues Modell wechseln.\n","words":1548},"date":"2026-10-14","description":"So arbeiten Red Teams für KI: Ziele, Umfang und Spielregeln, Testkategorien, manuelle und automatisierte Tests, Berichte, Korrekturen und Nachtests.","image":"https://abxk.ai/images/cover/red-teaming-llms.webp","json":"https://abxk.ai/de/ai-security/learn/red-teaming-llms/index.json","kind":"page","language":"de","learning_path":{"category":"ai-security","level":3,"level_name":"Profi"},"modified":"2026-10-14","related_tools":["Airia","TestDriver.ai","MindStudio"],"section":"ai-security","tags":["red-teaming","llm-sicherheit","ki-tests","prompt-injection"],"title":"Red Teaming für LLMs: So testen Teams KI sicher","translations":[{"json":"https://abxk.ai/en/ai-security/learn/red-teaming-llms/index.json","language":"en","url":"https://abxk.ai/en/ai-security/learn/red-teaming-llms/"}],"url":"https://abxk.ai/de/ai-security/learn/red-teaming-llms/"}