Deployer-Pflichten: Praxisleitfaden fuer SaaS-Teams

Deployer-Pflichten nach dem EU AI Act betreffen Organisationen, die ein KI-System unter eigener Verantwortung einsetzen. Fuer SaaS-Teams geht es nicht nur um die Frage, ob das System selbst gebaut oder von einem Anbieter bezogen wurde. Entscheidend ist, wer den Einsatz kontrolliert, ob ein Hochrisiko-KI-System betroffen ist, welche Anweisungen des Providers gelten, welche menschliche Aufsicht erforderlich ist und welche Nachweise fuer Logs, Monitoring und Eskalation vorhanden sind.

Artikel 26 verlangt fuer Hochrisiko-KI-Systeme insbesondere Nutzung gemaess den Anweisungen, menschliche Aufsicht durch kompetente Personen, geeignete Eingangsdaten, Monitoring, Aufbewahrung automatisch erzeugter Logs soweit sie unter Kontrolle des Deployers stehen, sowie Meldung und Aussetzung bei Risiken oder schwerwiegenden Vorfaellen. In bestimmten Faellen kommen Arbeitsplatzinformationen, Registrierungspflichten, Unterstuetzung fuer DPIAs oder eine Grundrechte-Folgenabschaetzung hinzu.

Wann das relevant wird

Ein SaaS-Unternehmen kann Provider fuer ein Kundenfeature und zugleich Deployer fuer interne oder operative KI-Nutzung sein. Typische Beispiele sind KI in Support-Triage, HR-Prozessen, Risiko-Scoring, Fraud-Pruefung, Finanzworkflows oder Kundenentscheidungen. Die Rollenpruefung sollte deshalb pro Workflow erfolgen, nicht einmal fuer das ganze Unternehmen.

Auch wenn ein Use Case nicht hochriskant ist, koennen Transparenz, Datenschutz, Security, Vendor Risk und Kundendokumentation relevant bleiben. Die Pruefung sollte sauber trennen, ob es um Deployer-Pflichten, Provider-Pflichten oder andere Governance-Kontrollen geht.

Deployer-Datensatz aufbauen

Erstellen Sie fuer jeden relevanten KI-Workflow einen Deployer-Datensatz. Er sollte System, Anbieter, Prozess, Zweck, Nutzergruppe, betroffene Personen, Datenkategorien, Geografie, Launch-Status, Provider-Anweisungen und interne Dokumentation enthalten.

Danach folgen Rolle und Klassifizierung: Warum ist das Team Deployer? Ist der Use Case hochriskant? Welche AI-Act-Spur ist betroffen? Welche offenen Fragen blockieren den Launch? Jede Pflicht sollte in einen operativen Kontrollpunkt uebersetzt werden: Wer folgt den Anweisungen, wer prueft Ergebnisse, welche Eingangsdaten sind erlaubt, wo liegen Logs, wer ueberwacht den Betrieb und wann wird der Anbieter informiert?

Praktische Checkliste

• KI-System, Anbieter, Workflow, Zweck, Nutzergruppe und betroffene Personen benennen.
• Rolle als Deployer, Provider oder beides dokumentieren.
• Hochrisiko-Einstufung und andere AI-Act-Spuren pruefen.
• Provider-Anweisungen in SOPs, Tickets, Akzeptanzkriterien und Training uebersetzen.
• Menschliche Aufsicht mit Kompetenz, Training, Autoritaet und Eskalationsweg zuweisen.
• Eingangsdaten kontrollieren, soweit das Team diese steuert.
• Logs, Speicherfrist, Zugriff und Exportweg klaeren.
• Monitoring fuer Fehler, Beschwerden, Vendor-Aenderungen, Drift und Missbrauch definieren.
• Vorfallroute, Aussetzung, Providerkontakt und Behoerdeneskalation vorbereiten.
• Nachweise mit Owner, Datum, Entscheidung und naechstem Review speichern.

Haeufige Fehler

Der erste Fehler ist, Deployer-Pflichten nur als Kundenthema zu sehen. Interne KI-Nutzung kann genauso relevant sein. Der zweite Fehler ist, Provider-Anweisungen als PDF im Procurement-Ordner liegen zu lassen, statt sie in operative Schritte zu uebersetzen. Der dritte Fehler ist menschliche Aufsicht ohne echte Autoritaet. Eine Person, die nicht widersprechen, pausieren oder eskalieren kann, ist kein belastbarer Kontrollpunkt.

FAQ

Was ist der praktische Zweck?

Der Zweck ist, nachweisen zu koennen, dass das Team Anweisungen befolgt, kompetente Aufsicht einsetzt, Eingangsdaten kontrolliert, Logs aufbewahrt, Nutzung ueberwacht, Vorfaelle behandelt und den Workflow bei Aenderungen neu bewertet.

Wer sollte verantwortlich sein?

Product oder Operations besitzen die Workflow-Fakten, Engineering Integration und Logs, Security Vendor- und Monitoring-Nachweise, Legal und Compliance die Auslegung und Nachweisstandards. Ein benannter Business Owner entscheidet ueber Launch-Blocker.

Quellen

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 26: Obligations of deployers of high-risk AI systems.
• European Commission AI Act Service Desk, Article 27: Fundamental rights impact assessment for high-risk AI systems.
• European Commission AI Act Service Desk, Article 13: Transparency and provision of information to deployers.