Der EU AI Act für Cloud-Operations-Teams

Die Risikopyramide in einer Minute

Der AI Act reguliert nach Risikoklassen. Verbotene Praktiken (Artikel 5) - Social Scoring, manipulative Systeme und Ähnliches - sind schlicht untersagt. Hochrisiko-Systeme (Anhang III) umfassen KI in Beschäftigungsentscheidungen, Kreditwürdigkeitsprüfung, Steuerung kritischer Infrastruktur und weiteren gelisteten Bereichen. Sie tragen die schweren Pflichten. Systeme mit begrenztem Risiko haben Transparenzpflichten (Artikel 50). Alles andere, also die große Mehrheit interner Tools, ist minimales Risiko ohne spezifische Pflichten jenseits der horizontalen.

Die Klassifizierungsfrage für ein Ops-Team ist die ehrliche Nutzung, nicht die Marketing-Kategorie: Ein LLM, das Incident-Zusammenfassungen zur Prüfung durch einen Engineer entwirft, ist etwas anderes als ein System, das automatisch Entscheidungen über Menschen trifft.

Anbieter oder Betreiber: Was sind Sie?

Die meisten Operations-Teams sind Betreiber (Deployer): Sie nutzen KI-Systeme in eigener Verantwortung, haben sie aber nicht für den Markt entwickelt. Betreiberpflichten sind leichter als Anbieterpflichten, aber real: Systeme gemäß Gebrauchsanweisung nutzen, menschliche Aufsicht sicherstellen, wo gefordert, und bei Hochrisiko-Systemen die automatisch erzeugten Logs aufbewahren (Artikel 26).

Die Grenze kann sich verschieben. Wer ein System wesentlich verändert oder ein eigenes KI-Produkt unter eigenem Namen in Verkehr bringt, kann Anbieterpflichten erwerben. Interne Agent-Workflows auf einer Foundation-Model-API lassen Sie in der Regel Betreiber des Modells bleiben, aber dokumentieren Sie die Designentscheidung, solange sie frisch ist.

Was von Ops-Teams jetzt konkret fällig ist

Drei horizontale Pflichten gelten bereits und sind früh billig zu erfüllen - und teuer unter Termindruck nachzurüsten.

• ✓KI-Kompetenz (Artikel 4): Wer KI-Systeme bedient, braucht rollengerechte Schulung. Eine kurze, rollenspezifische Enablement-Session mit Teilnahmenachweis erfüllt den Zweck besser als jedes Policy-PDF, das niemand liest.
• ✓Inventar: Was nicht gelistet ist, lässt sich nicht klassifizieren. Führen Sie ein Register der KI-Systeme und Use Cases im Betrieb - je mit Risikoklasse und einer Zeile ehrlicher Begründung.
• ✓Transparenz (Artikel 50): Nutzer eines Chatbots müssen erkennen können, dass sie mit KI interagieren; KI-generierte Inhalte sind in bestimmten Kontexten zu kennzeichnen. Für internes Tooling genügt dafür meist ein Label.

Wo Cloud-Governance und KI-Governance zusammenlaufen

Wer bereits eine gesteuerte Cloud-Umgebung betreibt, besitzt die Maschinerie, die der AI Act voraussetzt: Zugriffskontrolle entscheidet, wer welchen Modell-Endpoint aufrufen darf; Logging erfasst, was Agents getan haben; Lieferantenmanagement behandelt den Modellanbieter wie jeden anderen Auftragsverarbeiter; Datenresidenz entscheidet, welche Workloads Endpoints welcher Region nutzen dürfen. KI-Governance als Erweiterung des bestehenden Kontrollsets zu behandeln ist der billigste und zugleich verteidigbarste Weg.

Für Agent-Workflows im Besonderen: Beschränken Sie die Tools eines Agents, wie Sie eine IAM-Rolle beschränken - Least Privilege, auditiert, widerrufbar. Das Muster, das jeder Prüfung standhält, ist ein Agent, dessen jede Aktion zuordenbar und umkehrbar ist.

Eine vernünftige Vorbereitungssequenz für 2026

Bis zum Hochrisiko-Meilenstein im August 2026: Inventar und Klassifizierung abschließen, die Kompetenz-Session durchführen, nutzerzugewandte KI kennzeichnen sowie alles, was plausibel unter Anhang III fallen könnte, mit Rechtsberatung gegenprüfen, bevor Compliance-Maschinerie darum gebaut wird. Die meisten Teams stellen fest, dass ihre gesamte Ops-KI minimales oder begrenztes Risiko trägt, womit der AI Act von einer Bedrohung zu einem einseitigen Governance-Anhang wird.

FAQ