Glossar

KI‑Agenten sind Systeme, die mit Sprachmodellen selbstständig mehrstufige Aufgaben ausführen: Sie planen, rufen Werkzeuge und Schnittstellen auf, schreiben Dateien oder lösen Transaktionen aus. Damit wächst die Angriffsfläche deutlich, denn manipulierte Eingaben können jetzt echte Handlungen auslösen.

Der Katalog behandelt Agenten‑Risiken als eigene Bedrohungsgruppe: von Werkzeug‑Missbrauch über Rechteausweitung bis zu Kaskadenfehlern zwischen Agenten. Zentrale Kontrollen sind eng begrenzte Berechtigungen, Freigabeschritte für kritische Aktionen und eine lückenlose Protokollierung.

Eine AIBOM ist die Stückliste eines KI‑Systems. Sie erweitert die klassische Software‑Stückliste (SBOM) um die Bestandteile, die bei KI hinzukommen: verwendete Modelle und ihre Version, Trainings- und Feinabstimmungsdaten, Einbettungs- und Vektorbestände, Prompt‑Vorlagen sowie die zur Laufzeit angebundenen Dienste.

Der Nutzen zeigt sich im Ernstfall. Wird eine Schwachstelle in einem Modell oder einem Datensatz bekannt, beantwortet die AIBOM die Frage, welche eigenen Systeme betroffen sind. Sie ist außerdem die Grundlage für Herkunftsnachweise gegenüber Kunden und Aufsicht.

Die EU‑KI‑Verordnung unterscheidet vor allem zwei Rollen. Anbieter entwickeln ein KI‑System oder lassen es entwickeln und bringen es unter eigenem Namen in Verkehr. Betreiber setzen ein System in eigener Verantwortung ein. An beiden Rollen hängen unterschiedliche Pflichten, von der Konformitätsbewertung bis zur Aufsicht im Betrieb.

In der Praxis ist die Zuordnung der häufigste Streitpunkt. Wer ein zugekauftes System wesentlich verändert, unter eigenem Namen anbietet oder seinen Zweck ändert, kann selbst zum Anbieter werden. Die Rolle sollte deshalb je System dokumentiert und begründet sein, nicht stillschweigend angenommen.

Der Autonomiegrad beschreibt, wie weit ein KI‑System eigene Entscheidungen trifft und in Abläufe eingreift: von reinen Vorschlägen über Handlungen mit Freigabe bis zu vollständig selbstständigen Aktionen. Er ist keine Eigenschaft des Modells, sondern eine Entscheidung beim Einsatz.

Für die Risikobewertung ist er einer der wichtigsten Hebel. Mit steigendem Autonomiegrad wächst der mögliche Schaden je Fehlentscheidung, während die Gelegenheit zum Eingreifen sinkt. Die EU‑KI‑Verordnung nennt Autonomiegrad und Werkzeugzugriff ausdrücklich als Faktoren systemischer Risiken.

Beim Data Poisoning manipulieren Angreifer Trainings-, Feinabstimmungs- oder Referenzdaten, damit ein Modell gezielt falsche, verzerrte oder schädliche Ausgaben liefert, oft erst ausgelöst durch bestimmte Eingaben. Betroffen sind auch nachgelagerte Datenquellen wie Vektor‑Datenbanken für Retrieval‑Verfahren.

Gegenmaßnahmen setzen an der Datenherkunft an: signierte und versionierte Datensätze, Herkunftsnachweise, Ausreißer‑Analysen vor dem Training und Regressionstests nach jedem Datenupdate. Die Bewertung gehört in die Lieferketten‑Betrachtung des KI‑Systems.

Die Schwellenwertanalyse ist die Vorprüfung zur Datenschutz‑Folgenabschätzung nach Art. 35 DSGVO: Sie klärt strukturiert, ob eine Verarbeitung voraussichtlich ein hohes Risiko für Betroffene birgt und damit eine vollständige DSFA erfordert. Kriterien sind unter anderem neue Technologien, umfangreiches Profiling und besondere Datenkategorien.

Bei generativer KI kommen eigene Fragen hinzu: Prompt‑Übermittlungen an Dritte, Zweckbindung von Trainings- und Kontextdaten sowie die Nachvollziehbarkeit automatisierter Ausgaben. Ein dokumentierter Prüfpfad macht die Entscheidung gegenüber Aufsichtsbehörden belastbar.

Die EU‑KI‑Verordnung ordnet KI‑Systeme nach Risiko: verbotene Praktiken (Art. 5), Hochrisiko‑Systeme (u. a. Anhang III, etwa Beschäftigung, Kreditwürdigkeit, Biometrie), Systeme mit Transparenzpflichten (Art. 50) und Systeme mit minimalem Risiko. Die Einstufung entscheidet über Pflichten von Risikomanagement bis Konformitätsbewertung.

Dokumentieren Sie die gewählte Risikoklasse und die Gründe für die Einstufung. Halten Sie auch offene Fragen und benötigte Nachweise fest. Ein strukturierter Fragenkatalog unterstützt Sie dabei, die Entscheidung nachvollziehbar zu begründen.

Bei der Feinabstimmung wird ein bestehendes Modell mit eigenen Beispielen weitertrainiert, um Stil, Fachsprache oder Aufgabenverhalten anzupassen. Das Wissen steckt danach in den Gewichten, anders als bei RAG, wo es erst zur Laufzeit beigestellt wird.

Datenschutzrechtlich ist das der heiklere Weg. Personenbezogene Daten in den Trainingsbeispielen lassen sich aus einem Modell nicht einfach wieder löschen, und Auskunfts- sowie Löschansprüche werden schwer erfüllbar. Zu klären sind Rechtsgrundlage, Zweckbindung und die Frage, ob RAG denselben Nutzen ohne dieses Risiko erreicht.

KI‑Modelle mit allgemeinem Verwendungszweck (GPAI) sind Basismodelle, die für viele Aufgaben eingesetzt werden können. Die EU‑KI‑Verordnung regelt sie in einem eigenen Kapitel: Anbieter müssen unter anderem technische Dokumentation, Informationen für nachgelagerte Anbieter und eine Zusammenfassung der Trainingsinhalte bereitstellen (Art. 53).

Besonders leistungsfähige Modelle können als GPAI mit systemischem Risiko eingestuft werden. Dann kommen Pflichten wie Modell‑Evaluierungen, Bewertung und Minderung systemischer Risiken sowie Cybersicherheits- und Infrastrukturschutz hinzu (Art. 55). Für Betreiber zählt vor allem, welche Modellkategorie im eigenen System steckt.

Sprachmodelle erzeugen Texte, die plausibel klingen, aber sachlich falsch sein können: erfundene Fakten, Quellen, Paragrafen oder Programmierschnittstellen. Diese Konfabulationen entstehen systembedingt, weil Modelle Wahrscheinlichkeiten fortschreiben und keine Wissensdatenbank abfragen.

Im Risikomanagement zählt weniger die einzelne Falschausgabe als der Prozess dahinter: fachliche Prüfung vor Verwendung, Kennzeichnung KI‑erzeugter Inhalte, Belegpflichten für kritische Aussagen und Messungen der Fehlerrate im eigenen Anwendungsfall.

Die drei Begriffe unterscheiden, wo der Mensch im Ablauf steht. Human in the Loop heißt: ohne menschliche Freigabe geschieht nichts. Human on the Loop heißt: das System handelt selbst, ein Mensch beobachtet und kann eingreifen oder abbrechen. Human out of the Loop heißt: das System handelt im laufenden Betrieb ohne Aufsicht.

Die Einstufung ist nachweisrelevant. Art. 14 der EU‑KI‑Verordnung verlangt für Hochrisiko‑Systeme eine wirksame menschliche Aufsicht, und wirksam ist sie nur, wenn die aufsichtführende Person die Ausgabe versteht, genug Zeit hat und das System tatsächlich anhalten kann. Eine Freigabeschaltfläche ohne Entscheidungsgrundlage erfüllt die Anforderung nicht.

Ein Jailbreak ist der gezielte Versuch, die Sicherheitsregeln eines Modells auszuhebeln, etwa durch Rollenspiele, hypothetische Rahmungen, schrittweises Herantasten oder kodierte Eingaben. Anders als bei Prompt Injection kommt die Eingabe hier von der nutzenden Person selbst.

Für Betreiber ist weniger die einzelne Umgehung entscheidend als die Frage, was danach möglich ist. Solange ein Jailbreak nur Text erzeugt, bleibt der Schaden begrenzt; sobald er Werkzeuge, Daten oder Transaktionen erreicht, wird daraus ein Betriebsrisiko. Regelmäßige Tests mit bekannten Mustern gehören in die Freigabe jeder Version.

KI‑Kompetenz umfasst Kenntnisse und Fähigkeiten, die Menschen benötigen, um KI‑Systeme sachkundig einzusetzen und ihre Ergebnisse einzuordnen. Dazu gehören ein Verständnis der Möglichkeiten und Grenzen sowie der Risiken für die betroffenen Personen.

Stimmen Sie Lernangebote auf Vorkenntnisse, Aufgaben und Einsatzkontext ab. Halten Sie Schulungen und praktische Übungen nachvollziehbar fest. Die rechtliche Einordnung zu Art. 4 und die verwendete Dokumentfassung finden Sie im Pflichtenkompass.

Leitplanken sind die technischen Begrenzungen um ein Modell herum: Filter auf Eingaben und Ausgaben, erlaubte und verbotene Themen, Prüfungen vor Werkzeugaufrufen, Budget- und Schrittgrenzen sowie feste Ausgabeformate. Sie wirken außerhalb des Modells und sind deshalb prüfbar und versionierbar.

Sie ersetzen keine Risikobewertung. Filter lassen sich umgehen, und zu strenge Regeln machen ein System unbrauchbar. Belastbar wird der Ansatz erst, wenn jede Leitplanke einer konkreten Bedrohung zugeordnet ist, ihre Wirkung gemessen wird und das verbleibende Restrisiko dokumentiert ist.

Das Model Context Protocol ist ein offener Standard, mit dem Sprachmodelle einheitlich auf Werkzeuge, Dateien und Datenquellen zugreifen. Statt für jede Anwendung eine eigene Schnittstelle zu bauen, meldet ein MCP‑Server seine Fähigkeiten an, und das Modell ruft sie über ein gemeinsames Protokoll auf.

Sicherheitsrelevant ist vor allem, was ein solcher Server freigibt. Jedes angebundene Werkzeug erweitert den Handlungsraum des Modells, und die Beschreibungen der Werkzeuge sind selbst Text, der manipuliert sein kann. Zu prüfen sind Herkunft und Integrität der Server, die Rechte je Werkzeug und ob Aufrufe protokolliert und bei kritischen Wirkungen freigegeben werden.

Model Theft umfasst den Diebstahl von Modellgewichten und die Extraktion über die Schnittstelle: Angreifer stellen systematisch Anfragen, um Verhalten, Trainingsdaten oder Systemanweisungen eines Modells zu rekonstruieren. Betroffen sind sowohl selbst trainierte Modelle als auch eingekaufte Modelle mit vertraglichen Schutzpflichten.

Typische Kontrollen sind Zugriffs- und Ratenbegrenzungen, Anomalie‑Erkennung auf Abfragemustern, Härtung der Modell‑Infrastruktur und vertragliche sowie technische Schutzmaßnahmen für Gewichte und Systemprompts.

Drift bezeichnet das Auseinanderlaufen von Modell und Wirklichkeit: Eingabedaten verschieben sich gegenüber den Trainingsdaten, Begriffe ändern ihre Bedeutung, Nutzungsmuster wandeln sich. Dadurch kann die Qualität der Ergebnisse abnehmen, auch wenn das System selbst unverändert bleibt.

Drift kann schleichend auftreten und lange unbemerkt bleiben. Regelmäßige Messungen helfen, Veränderungen früh zu erkennen. Halten Sie bei der Freigabe Vergleichswerte fest und legen Sie fest, ab welchen Abweichungen die zuständigen Personen eingreifen sollen. Bei zugekauften Modellen kommt hinzu, dass der Anbieter das Modell im Hintergrund austauschen kann.

Eine Modellkarte beschreibt ein Modell in strukturierter Form: vorgesehener Zweck, ungeeignete Einsatzfelder, Trainingsdaten und ihre Herkunft, Messwerte zur Leistung, bekannte Verzerrungen und Grenzen sowie Angaben zu Version und Pflege.

Für Betreiber ist sie der Einstieg in die eigene Bewertung, nicht deren Ersatz. Sie beschreibt, wofür das Modell vorgesehen ist. Ob es sich für Ihren Anwendungsfall eignet, müssen Sie gesondert prüfen. Fehlt eine Modellkarte, halten Sie dies bei der Prüfung des Anbieters und seiner Unterlagen fest.

In einem Multi‑Agenten‑System teilen sich mehrere spezialisierte Agenten eine Aufgabe: einer plant, einer recherchiert, einer schreibt, einer prüft. Sie tauschen Zwischenergebnisse aus und rufen sich gegenseitig auf, oft ohne dass ein Mensch die einzelnen Schritte sieht.

Das Risiko verschiebt sich von der einzelnen Ausgabe zur Kette. Ein Fehler oder eine manipulierte Anweisung pflanzt sich fort und wird von nachgelagerten Agenten als gesicherte Vorarbeit behandelt. Kontrollen setzen an den Übergängen an: Prüfpunkte zwischen den Agenten, begrenzte Rechte je Rolle und eine Protokollierung, die den ganzen Ablauf rekonstruierbar macht.

Nicht‑menschliche Identitäten sind technische Identitäten für Dienste, Anwendungen und Agenten. Ein Dienstkonto kann beispielsweise einem KI‑Agenten zugeordnet sein. Schlüssel, Zertifikate oder Token dienen dazu, diese Identität gegenüber anderen Systemen nachzuweisen.

Ein Agent benötigt Berechtigungen, um auf Daten und Werkzeuge zuzugreifen. Legen Sie fest, wer die technische Identität verwaltet, welche Zugriffe zulässig sind und wann die Berechtigungen enden. Dokumentieren Sie auch, wie sich Zugänge sperren lassen. Das erleichtert die Prüfung und die Reaktion auf Sicherheitsvorfälle.

Prompt Injection bezeichnet Angriffe, bei denen manipulierte Eingaben oder eingeschleuste Inhalte (etwa in Dokumenten, Webseiten oder E‑Mails) das Verhalten eines Sprachmodells umsteuern. Das Modell folgt dann Anweisungen des Angreifers statt den Vorgaben des Betreibers, zum Beispiel zum Ausleiten vertraulicher Daten oder zum Umgehen von Schutzregeln.

Wirksame Kontrollen kombinieren Eingabe- und Ausgabefilter, die strikte Trennung von Anweisungen und Daten, minimale Berechtigungen für angebundene Werkzeuge sowie Tests mit bekannten Angriffsmustern. Die Restrisiken bleiben dokumentationspflichtig, weil kein Filter vollständig schützt.

Bei Retrieval Augmented Generation sucht das System vor der Antwort passende Ausschnitte in einer eigenen Wissensbasis und gibt sie dem Modell als Kontext mit. So antwortet es auf Grundlage aktueller eigener Dokumente, ohne dass das Modell dafür neu trainiert werden muss.

Sicherheitsrelevant ist, dass die abgerufenen Inhalte im selben Kontextfenster landen wie die Anweisungen. Ein präpariertes Dokument in der Wissensbasis wirkt damit wie eine Anweisung an das Modell. Dazu kommen Berechtigungsfragen: Der Abruf muss die Zugriffsrechte der fragenden Person abbilden, sonst wird die Wissensbasis zum Datenleck.

Red Teaming ist der geplante Versuch, das eigene KI‑System zum Fehlverhalten zu bringen: Prompt‑Angriffe, Umgehungen, Datenabfluss über Ausgaben, Missbrauch angebundener Werkzeuge. Geprüft wird die gesamte Anwendung, nicht nur das Modell.

Damit daraus mehr wird als eine Sammlung von Anekdoten, braucht es Wiederholbarkeit: feste Angriffsmuster, dokumentierte Ergebnisse je Version und eine Zuordnung der Befunde zu Bedrohungen und Maßnahmen. Die EU‑KI‑Verordnung verlangt für Modelle mit systemischem Risiko ausdrücklich Evaluierungen einschließlich adversarialer Tests.

Das Restrisiko ist das Risiko, das nach Umsetzung aller beschlossenen Gegenmaßnahmen verbleibt. Es wird je Bedrohung aus Eintrittswahrscheinlichkeit und Schadenshöhe abgeleitet. Die zuständigen Personen entscheiden, ob sie das Risiko akzeptieren, weitere Maßnahmen veranlassen oder auf die betreffende Nutzung verzichten.

Eine belastbare Restrisiko‑Methodik dokumentiert je Entscheidung Begründung, Verantwortliche und Termin. So lässt sich später nachvollziehen, wie mit den einzelnen Risiken umgegangen wurde.

Schatten‑KI ist der Einsatz von KI‑Diensten außerhalb der geregelten Beschaffung: der schnell geöffnete Chatbot im Browser, die Erweiterung im Editor, der private Zugang für eine dienstliche Aufgabe. Der Antrieb ist selten böswillig, sondern meist der Wunsch, schneller fertig zu werden.

Das Problem ist die Unsichtbarkeit. Ohne Kenntnis der genutzten Dienste gibt es keine Auftragsverarbeitung, keine Zweckbindung und keinen Nachweis, wohin Eingaben geflossen sind. Wirksam ist meist ein niedrigschwelliges freigegebenes Angebot samt klarer Regel, nicht ein Verbot allein.

Der Systemprompt ist die vorangestellte Anweisung, die Rolle, Tonfall, erlaubte Themen und Grenzen eines Modells festlegt. Er ist für die nutzende Person meist unsichtbar, prägt aber jede Antwort und enthält oft Geschäftslogik.

Zwei Punkte sind bewertungsrelevant. Erstens ist er kein Geheimnis: Systemprompts lassen sich häufig erfragen oder erschließen, deshalb gehören Schlüssel und vertrauliche Regeln nicht hinein. Zweitens ist er eine Konfiguration mit Wirkung auf das Ergebnis und sollte versioniert, geprüft und freigegeben werden wie Programmcode.

TOMs sind die Schutzmaßnahmen, mit denen Verantwortliche die Sicherheit einer Verarbeitung gewährleisten (Art. 32 DSGVO): von Verschlüsselung, Zugriffskontrolle und Protokollierung bis zu Schulungen, Rollenkonzepten und Freigabeprozessen. Sie müssen dem Risiko der Verarbeitung angemessen sein.

Bei KI‑Systemen kommen KI‑spezifische Maßnahmen hinzu, etwa Filterketten gegen Prompt‑Angriffe, Kontrollen gegen Datenabfluss über Ausgaben und die Überwachung von Modell- und Datenänderungen. Eine Risikoanalyse ordnet jede Maßnahme einer konkreten Bedrohung zu und macht den Reifegrad messbar.

Beim Werkzeugaufruf entscheidet das Modell, eine Funktion aufzurufen: eine Suche, eine Datenbankabfrage, einen Versand, eine Buchung. Es liefert dabei die Parameter, ausgeführt wird der Aufruf von der umgebenden Anwendung.

Damit verlässt das System die reine Textwelt. Jede Ausgabe kann eine Handlung auslösen, und die Parameter stammen aus einem Text, der manipuliert sein kann. Zu prüfen sind die Rechte je Werkzeug, die Prüfung der Parameter vor der Ausführung, Freigaben für kritische Aufrufe und die Frage, welche Aufrufe sich rückgängig machen lassen.