KI-Agenten rechtssicher betreiben: EU AI Act, DSGVO und die Nachweise, die zählen

Zwei Rechtsrahmen greifen beim Betrieb von KI-Agenten gleichzeitig, und sie stellen nicht dieselbe Frage. Der EU AI Act fragt: Wer bringt ein KI-System in Verkehr, und wie riskant ist der Einsatzzweck? Die DSGVO fragt: Wer entscheidet über Zwecke und Mittel der Datenverarbeitung, und wer verarbeitet nur weisungsgebunden? Beide Fragen haben in der Praxis fast immer dieselbe Antwort – Ihr Unternehmen trägt die operative Verantwortung, der Dienstleister liefert Infrastruktur und Nachweise –, aber die Begriffe sind nicht austauschbar. Wer sie durcheinanderwirft, unterschreibt am Ende den falschen Vertrag.

Ehrlich: Die meisten Mittelständler, mit denen wir über Agenten-Projekte sprechen, haben weder eine AI-Act-Rollenklärung noch ein aktuelles Verzeichnis von Verarbeitungstätigkeiten für ihre KI-Anwendungsfälle. Das ist kein Weltuntergang, solange man es vor dem Go-Live nachholt und nicht erst, wenn ein Auditor danach fragt.

Wer ist wer: Anbieter, Betreiber, Verantwortlicher, Auftragsverarbeiter

Der EU AI Act unterscheidet in erster Linie zwischen Anbieter und Betreiber. Anbieter ist, wer ein KI-System entwickelt oder unter eigenem Namen in Verkehr bringt – bei den meisten Agenten-Projekten also der Hersteller des zugrunde liegenden Sprachmodells oder einer GPAI-Komponente. Betreiber ist, wer das System in eigener Verantwortung einsetzt: in aller Regel Ihr Unternehmen, das den Agenten für einen konkreten Zweck – Support, Rechnungsprüfung, Codebase-Migration – produktiv nutzt.

Parallel dazu regelt die DSGVO die Rollen an den personenbezogenen Daten, die durch den Agenten fließen. Verantwortlicher ist, wer über Zwecke und Mittel der Verarbeitung entscheidet – meist wieder Ihr Unternehmen. Auftragsverarbeiter ist, wer nur nach Weisung verarbeitet, etwa der Betreiber der Agenten-Plattform. HostSpezial tritt in diesem Modell in aller Regel als Auftragsverarbeiter und technischer Betreiber der Infrastruktur auf, nicht als AI-Act-Anbieter des Modells selbst. Die vollständige Rollenzuordnung für den Plattformbetrieb finden Sie auf der Trust-Seite.

Merksatz: AI-Act-Anbieter/Betreiber beschreibt, wer das System technisch verantwortet. DSGVO-Verantwortlicher/Auftragsverarbeiter beschreibt, wer über die Daten entscheidet. In den meisten Agenten-Setups ist Ihr Unternehmen beides Mal die operativ verantwortliche Partei – der Dienstleister ist Auftragsverarbeiter und AI-Act-technischer Betreiber der Infrastruktur, nicht Anbieter des Modells.

Was das für Verträge bedeutet

Aus der Rollenverteilung folgt unmittelbar der Vertragsbedarf. Wenn Ihr Unternehmen Verantwortlicher ist und ein Dienstleister als Auftragsverarbeiter personenbezogene Daten für Sie verarbeitet – etwa Kundendaten in Support-Tickets, die ein Agent liest –, brauchen Sie einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO. Der AVV muss unter anderem Gegenstand und Dauer der Verarbeitung, Art und Zweck, die Kategorien betroffener Personen, die technischen und organisatorischen Maßnahmen und die Rechte und Pflichten beider Seiten regeln.

Zwei Punkte werden bei Agenten-Projekten häufig übersehen:

Unterauftragsverarbeiter offenlegen: Ein Agent, der eine externe Modell-API aufruft, macht den Modellanbieter zum Unterauftragsverarbeiter. Diese Kette muss im AVV vollständig und aktuell abgebildet sein – nicht nur bei Vertragsschluss, sondern auch bei späteren Wechseln.
Weisungsbindung technisch durchsetzen: Ein AVV auf Papier hilft wenig, wenn der Agent faktisch Entscheidungen trifft, die über die erteilte Weisung hinausgehen. Weisungsbindung muss sich in Scopes einer Agent Identity, Policy Engine und Freigabeschwellen widerspiegeln – nicht nur im Vertragstext.

In der Praxis heißt das: Bevor der erste Agent produktiv geht, sollten AVV, Sub-AV-Liste und die technische Umsetzung der Weisungsbindung im selben Projektplan stehen, nicht in getrennten Zuständigkeiten von Einkauf, Recht und IT.

Die Fristenlage nach dem Digital Omnibus

Der EU AI Act gilt stufenweise, und die Stufen haben sich seit der ursprünglichen Verordnung verschoben. Nach der Digital-Omnibus-Einigung vom Mai 2026 gilt aktuell folgender Stand:

Seit dem 2. Februar 2025: Verbote unzulässiger KI-Praktiken und die Pflicht zur KI-Kompetenz in Organisationen.
Seit dem 2. August 2025: Pflichten für Anbieter von General-Purpose-AI-Modellen (GPAI).
Verschoben auf den 2. Dezember 2027: Hochrisiko-Pflichten für Anhang-III-Anwendungsfälle (unter anderem Personalauswahl, Kreditwürdigkeitsprüfung, kritische Infrastruktur).
Verschoben auf den 2. August 2028: Hochrisiko-Pflichten für Anhang-I-Systeme, vorbehaltlich der finalen Verabschiedung des Digital Omnibus.

Wichtig: Ein früher kursierendes, rund zwei Jahre vor diesen Terminen liegendes Datum für die Hochrisiko-Pflichten ist mit dem Digital Omnibus überholt und sollte in keiner aktuellen Planung mehr auftauchen. Wer noch mit dem alten, früheren Stichtag rechnet, plant gegen eine Frist, die nicht mehr gilt.

Dazu kommt eine Bußgeld-Differenzierung: Verstöße gegen die Verbote unzulässiger Praktiken können mit bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes geahndet werden, andere Pflichtverletzungen – etwa im Hochrisiko- oder Transparenzbereich – mit geringeren, aber immer noch deutlichen Sätzen. Die Differenzierung ist ein Hinweis darauf, dass nicht jeder Verstoß gleich schwer wiegt, aber keiner davon folgenlos ist.

Risikoeinstufung in der Praxis: Ist Ihr Agent Hochrisiko?

Die meisten Agenten, die wir in Beratungsgesprächen sehen, sind keine Hochrisiko-Systeme im Sinne von Anhang III – ein interner Support-Bot, ein Rechnungsverarbeitungs-Agent oder ein Codebase-Migrations-Assistent fällt in aller Regel nicht darunter. Trotzdem sind sie nicht automatisch pflichtenfrei:

Transparenzpflichten gegenüber Personen, die mit einem KI-System interagieren, gelten unabhängig von der Risikoklasse.
Protokollpflichten ergeben sich in der Praxis schon aus DSGVO-Rechenschaftspflicht und ISO-27001-Betrieb, unabhängig davon, ob der AI Act sie im Einzelfall explizit fordert.
Die Einstufung selbst muss dokumentiert sein – auch das Ergebnis "kein Hochrisiko" braucht eine nachvollziehbare Begründung, sonst ist es beim nächsten Audit eine Behauptung statt eines Nachweises.

In der Praxis lohnt sich eine einfache Leitfrage: Trifft der Agent Entscheidungen, die für eine Person rechtliche Wirkung entfalten oder sie vergleichbar erheblich beeinträchtigen könnten – Kreditvergabe, Personalauswahl, Vertragskündigung? Wenn ja, ist eine vertiefte rechtliche Prüfung fällig, unabhängig vom aktuellen Fristenstand. Wenn nein, bleibt meist Transparenz- und Dokumentationspflicht übrig – die aber ernst genommen werden sollte, weil sie unabhängig vom Hochrisiko-Aufschub sofort gilt.

DSGVO im Agenten-Betrieb: Rechtsgrundlage, Zweckbindung, Art. 22

Jeder Agent, der personenbezogene Daten verarbeitet, braucht eine Rechtsgrundlage nach Art. 6 DSGVO – meist Vertragserfüllung oder berechtigtes Interesse, je nach Anwendungsfall. Die Zweckbindung ergibt sich aus dem, wofür der Agent tatsächlich gebaut wurde: Ein Support-Agent, der Tickets kategorisiert, darf dieselben Daten nicht ungefragt für ein Vertriebs-Scoring weiterverwenden. Das klingt banal, wird aber in der Praxis schnell verletzt, sobald ein Agenten-Graph um weitere Tools erweitert wird, ohne die Zweckbindung neu zu prüfen.

Der praktisch heikelste Punkt ist Art. 22 DSGVO: das grundsätzliche Verbot rein automatisierter Entscheidungen mit rechtlicher Wirkung oder vergleichbar erheblicher Beeinträchtigung für die betroffene Person, ohne dass ein Mensch beteiligt war. Ein Agent, der eine Rechnung mit 200 Euro Abweichung automatisch bucht, ist unkritisch. Ein Agent, der automatisch eine Kreditlinie kürzt oder eine Bewerbung ablehnt, ist es nicht.

Die sauberste Antwort auf Art. 22 ist eine Freigabeschwelle, nicht eine juristische Argumentation im Nachhinein: Alles, was rechtliche Wirkung entfalten könnte, geht an einen Menschen, bevor es ausgeführt wird. Das ist technisch günstiger zu bauen als jede Einzelfallabwägung, ob eine bestimmte Entscheidung "vergleichbar erheblich" ist – und es ist der Ansatz, den wir in Policy Engine und Sandboxing auch technisch umsetzen.

Löschkonzept für Traces und Prompts, TOMs

Prompts, Tool-Rückgaben und Traces sind personenbezogene Daten, sobald sie sich auf eine identifizierbare Person beziehen lassen – und das tun sie bei Support- oder HR-Agenten fast immer. Ein Löschkonzept sollte mindestens drei Fristen kennen:

Audit-relevante Ereignisse (wer hat wann was freigegeben): oft um die 365 Tage, weil sie für Rechenschaftspflicht und Streitfälle gebraucht werden.
Trace-Nutzlasten (vollständige Prompts, Tool-Antworten): meist kürzer, weil sie das eigentliche Datenschutzrisiko tragen.
Löschung auf Anforderung: Ein einzelner Lauf samt zugehöriger Spans und Nutzlasten muss löschbar sein, ohne die Abrechnungshistorie oder das Event-Log als Ganzes zu zerstören.

Die technischen und organisatorischen Maßnahmen (TOMs) sind der zweite Baustein: Verschlüsselung, Zugriffskontrolle, Mandantentrennung, Sanitisierung personenbezogener Felder direkt im Collector statt in der Anwendung. Letzteres ist ein Detail mit großer Wirkung – wenn die Schwärzung an der Disziplin einzelner Entwickler hängt, wird sie irgendwann vergessen. Wenn sie zentral im Collector passiert, gilt sie für jeden Agenten gleich.

ISO/IEC 42001 neben ISO/IEC 27001

ISO/IEC 27001 regelt Informationssicherheit allgemein – Zugriffskontrolle, Risikomanagement, Vorfallreaktion. ISO/IEC 42001 ist der jüngere, freiwillige Rahmen speziell für ein KI-Managementsystem: Er verlangt unter anderem eine dokumentierte KI-Risikobewertung je Anwendungsfall, definierte Rollen für KI-Governance und eine Eskalationskette für KI-spezifische Vorfälle wie Fehlverhalten eines Agenten.

HostSpezial ist nach ISO/IEC 27001:2022 vollumfänglich zertifiziert (Zertifikat Nr. 202787, ISOZERT-WEST). Für ISO/IEC 42001 liefern wir die betrieblichen Nachweise, die ein KI-Managementsystem verlangt, und arbeiten Ihrem Auditor zu – die Zertifizierung selbst nimmt eine akkreditierte Stelle vor, nicht wir. Wer beide Normen nebeneinander aufbaut, deckt Informationssicherheit und KI-Governance mit derselben Nachweislogik ab, statt zwei getrennte Dokumentationswelten zu pflegen.

Drei Agenten-Typen, drei Pflichtenkataloge

Nicht jeder Agent braucht denselben Aufwand. Entscheidend ist, wie weit seine Aktionsrechte reichen und ob er für Kunden sichtbar wird:

Merkmal	Interner Assistent (Auskunft)	Agent mit Aktionsrecht (intern)	Kundenseitig sichtbarer Agent
Typisches Beispiel	Wissens-Chat für Mitarbeiter	Ticket schließen, Rechnung buchen	Support-Chat mit Endkunden
Typische AI-Act-Einordnung	Meist minimales Risiko	Meist begrenztes Risiko, Einzelfallprüfung nötig	Begrenztes Risiko plus Transparenzpflicht
DSGVO-Rolle typischerweise	Verantwortlicher: Ihr Unternehmen	Verantwortlicher: Ihr Unternehmen	Verantwortlicher: Ihr Unternehmen, ggf. gemeinsam
Art. 22 relevant?	In der Regel nein	Ja, ab Rechtswirkung	Ja, plus Kundentransparenz
Freigabeschwelle nötig?	Selten zwingend	Ja, für kritische Aktionen	Ja, plus Eskalationspfad zum Menschen
Wichtigste Nachweise	Nutzungsrichtlinie, VVT-Eintrag	Audit-Log je Tool-Call, Policy-Dokument	Audit-Log, Transparenzhinweis, Eskalationsprotokoll

Was ein Auditor tatsächlich sehen will

Zwischen "wir haben Richtlinien" und "wir können sie belegen" liegt in jedem Audit der entscheidende Unterschied. Konkret verlangt wird üblicherweise:

Audit-Log je Tool-Call: Agenten-Identität, aufgerufenes Werkzeug, sanitisierte Parameter, Policy-Entscheidung mit Begründung, Zeitstempel, bei Freigaben die freigebende Person.
Versionierte Policies: nicht nur der aktuelle Stand, sondern nachvollziehbar, welche Regel zu welchem Zeitpunkt galt.
Betriebsreport: Laufzahlen, Fehlerraten, Eskalationen über einen definierten Zeitraum.
Verzeichnis der Verarbeitungstätigkeiten (VVT): je Agenten-Anwendungsfall mit Zweck, Rechtsgrundlage, Kategorien betroffener Personen.
Sub-AV-Liste: aktuell, nicht nur als Anlage zum Erstvertrag.

Diese Nachweise entstehen im laufenden Betrieb ohnehin, wenn Observability von Anfang an mitgedacht wird – Agenten-Identitäten, Modellversionen, Policy-Entscheidungen liegen dann als Trace vor, statt nachträglich rekonstruiert werden zu müssen. Details zur Architektur dahinter stehen auf der Architektur-Seite.

Praxisbeispiel: Checkliste vor Go-Live

Rechenbeispiel für den Aufwand, mit dem die meisten Mittelständler vor dem produktiven Start eines Agenten rechnen sollten – als grobe Annahme, nicht als verbindliches Angebot: Für einen internen Agenten mit Aktionsrecht (etwa 40 Tool-Calls pro Tag, keine Kundensicht) fallen typischerweise 15 bis 25 Stunden für Rollenklärung, VVT-Eintrag und Definition der Freigabeschwelle an. Für einen kundenseitig sichtbaren Agenten eher 40 bis 60 Stunden, weil TOM-Dokumentation, Transparenzhinweise und ein Eskalationspfad zum Menschen hinzukommen.

Die folgende Reihenfolge hat sich in der Praxis bewährt:

1. Rollen klärenAnbieter/Betreiber nach AI Act und Verantwortlicher/Auftragsverarbeiter nach DSGVO schriftlich fixieren.
2. AVV abschließenAuftragsverarbeitungsvertrag nach Art. 28 unterschrieben, Sub-Auftragsverarbeiter-Liste geprüft und akzeptiert.
3. Risiko einstufenRisikoeinstufung des Anwendungsfalls dokumentieren – auch das Ergebnis "kein Hochrisiko" braucht eine Begründung.
4. VVT nachführenRechtsgrundlage und Zweckbindung je Use Case im Verzeichnis der Verarbeitungstätigkeiten eintragen.
5. Freigabeschwelle definierenFür Aktionen mit Rechtswirkung oder vergleichbar erheblicher Beeinträchtigung.
6. Audit-Log prüfenPflichtfelder je Tool-Call: Identität, Werkzeug, Parameter, Policy-Entscheidung, Zeitstempel, Freigeber.
7. Löschkonzept hinterlegenFristen für Prompts und Traces festlegen, TOM-Dokumentation aktualisieren.
8. Transparenzhinweis vorbereitenFür kundenseitig sichtbare Agenten: erkennbarer KI-Hinweis plus Eskalationspfad zum Menschen.

Für Berufsgeheimnisträger und Unternehmen mit besonders strengen Datenresidenz-Anforderungen ist die vertragliche Klärung ohnehin nur die halbe Miete – die andere Hälfte ist die physische Datenhaltung. Wer Prompts, Tool-Rückgaben und Traces gar nicht erst außer Haus geben will, betreibt die Agenten-Plattform on-premise auf eigener Infrastruktur. Für den laufenden Betrieb über die reine Agenten-Ebene hinaus bündeln wir das im KI-Managed-Services-Angebot, für den kompletten Stack von Modell bis Anwendung im KI Full-Stack Providing. Welche Variante zu Ihrer Rollen- und Risikoeinstufung passt, klären wir am besten im persönlichen Gespräch – bevor der erste Agent produktiv geht.

Weiterführend

Trust: Zertifikate & EU AI Act Security: Identität & Policy Engine Observability & Audit-Trail Preise & Service-Klassen

Wann sich das nicht lohnt / Grenzen

Nicht jedes Agenten-Projekt braucht die volle Compliance-Maschinerie sofort. Für einen reinen Proof of Concept ohne Zugriff auf Produktivdaten und ohne echte Nutzerinteraktion ist ein schlankeres Vorgehen vertretbar – solange klar ist, dass vor dem Produktivbetrieb nachgerüstet wird. Wer dagegen von Anfang an mit personenbezogenen Daten oder Aktionsrechten testet, spart sich später doppelte Arbeit, wenn Rollen und VVT von Beginn an sauber stehen.

Grenzen dieses Artikels: Dies ist keine Rechtsberatung und ersetzt keine Einzelfallprüfung durch eine Kanzlei oder Ihren Datenschutzbeauftragten. Ob ein konkreter Anwendungsfall unter Anhang III oder Anhang I des AI Act fällt, ob eine bestimmte Entscheidung "vergleichbar erheblich" im Sinne von Art. 22 DSGVO ist, und wie die Fristenlage nach der finalen Verabschiedung des Digital Omnibus konkret ausfällt, hängt vom Einzelfall und vom endgültigen Rechtstext ab. HostSpezial liefert Nachweise und Betriebsdokumentation, keine juristische Bewertung.

Häufige Fragen

Ist HostSpezial Anbieter oder Betreiber im Sinne des EU AI Act?

Bei selbst entwickelten Agenten-Anwendungen ist in der Regel Ihr Unternehmen Betreiber im Sinne der Verordnung, HostSpezial ist technischer Auftragsverarbeiter und Betreiber der Infrastruktur. Anbieter ist meist derjenige, der das zugrunde liegende Modell oder System unter eigenem Namen in Verkehr bringt – bei genutzten Basis- oder GPAI-Modellen also der jeweilige Modellhersteller. Die genaue Zuordnung hängt vom Einzelfall ab und sollte vertraglich fixiert werden.

Wann gelten die Hochrisiko-Pflichten des EU AI Act für Agenten?

Nach der Digital-Omnibus-Einigung vom Mai 2026 gelten die Hochrisiko-Pflichten voraussichtlich ab dem 2. Dezember 2027 für Anhang-III-Anwendungen und ab dem 2. August 2028 für Anhang-I-Systeme, vorbehaltlich der finalen Verabschiedung. Ein früher kursierendes, deutlich früheres Datum für diese Pflichten ist damit überholt. Verbote unzulässiger Praktiken gelten bereits seit dem 2. Februar 2025, Pflichten für General-Purpose-AI-Modelle seit dem 2. August 2025.

Braucht jeder KI-Agent eine Freigabeschwelle nach Art. 22 DSGVO?

Nicht jeder, aber jeder Agent, der Entscheidungen mit Rechtswirkung oder vergleichbar erheblicher Beeinträchtigung treffen könnte – etwa Vertragskündigung, Kreditentscheidung oder Personalauswahl – braucht einen Menschen in der Freigabeschleife, sonst greift das grundsätzliche Verbot rein automatisierter Einzelfallentscheidungen aus Art. 22 DSGVO. Für rein informierende oder vorschlagende Agenten ist eine Freigabeschwelle nicht zwingend, aber in der Praxis trotzdem sinnvoll.

Was muss ein Auditor beim Audit-Log eines Agenten sehen?

Je Tool-Call: Agenten-Identität, aufgerufenes Werkzeug, sanitisierte Parameter, die Policy-Entscheidung samt Begründung, einen Zeitstempel und – bei Freigaben – die freigebende Person. Dazu versionierte Policy-Dokumente, einen Betriebsreport, das Verzeichnis der Verarbeitungstätigkeiten und die aktuelle Sub-Auftragsverarbeiter-Liste.

Ist ISO/IEC 42001 Pflicht für den Betrieb von KI-Agenten?

Nein, ISO/IEC 42001 ist ein freiwilliger Rahmen für ein KI-Managementsystem, keine gesetzliche Pflicht. Er ergänzt ISO/IEC 27001 um KI-spezifische Risikosteuerung und wird zunehmend als Nachweis akzeptiert, ersetzt aber keine AI-Act-Konformität und keine DSGVO-Pflichten.

Wie lange dürfen Prompts und Traces eines Agenten gespeichert werden?

Es gibt keine feste gesetzliche Frist, die für alle Fälle gilt – maßgeblich sind Zweckbindung und Speicherbegrenzung nach Art. 5 DSGVO. In der Praxis werden audit-relevante Ereignisse häufig um die 365 Tage vorgehalten, detaillierte Trace-Nutzlasten kürzer, mit klar dokumentierten Löschfristen je Umgebung.

Fällt ein interner Support-Assistent unter die Transparenzpflichten des AI Act?

Häufig ja in abgeschwächter Form: Wer mit einem KI-System interagiert, muss das grundsätzlich erkennen können, auch wenn der Anwendungsfall selbst kein Hochrisikosystem ist. Bei rein intern genutzten Assistenten ohne Kundenkontakt ist die praktische Ausprägung meist ein Hinweis im Tool selbst plus interne KI-Kompetenz-Schulung.

Was passiert bei einem Wechsel des Modell-API-Anbieters als Unterauftragsverarbeiter?

Ein neuer oder gewechselter Unterauftragsverarbeiter muss offengelegt und im AV-Vertrag nachgeführt werden; je nach Vereinbarung besteht ein Widerspruchsrecht des Verantwortlichen. Die Sub-AV-Liste sollte deshalb Teil der laufenden Vertragsdokumentation sein, nicht nur eine einmalige Anlage bei Vertragsschluss.

HostSpezial betreibt die Agentic-AI-Infrastruktur seit der Firmengründung 2010 mit heute 16 Jahren Erfahrung im deutschen Rechenzentrumsbetrieb – primär aus dem Rechenzentrum der SÜC Coburg, mit Disaster-Recovery-Standort bei der SWN Neustadt, vollständig DSGVO-konform betrieben. Die Betriebspauschalen für die Agenten-Plattform liegen je nach Service-Klasse bei 690, 1.490 oder ab 3.900 Euro pro Monat zzgl. USt., dazu nutzungsabhängige Komponenten – Details dazu auf der Preise-Seite. Wer die technische Systemkarte hinter diesen Zahlen sehen will, findet sie interaktiv unter /agentic-ai/#systemkarte.