Wie man Deployer-Pflichten operationalisiert, ohne die Produktlieferung zu bremsen

Deployer-Pflichten nach dem EU AI Act werden beherrschbar, wenn SaaS-Teams sie als Liefer-Workflow behandeln und nicht als spaetes Rechtsmemo. Entscheidend ist, zu erkennen, wo das Unternehmen ein KI-System unter eigener Verantwortung nutzt, ob die Nutzung hochriskant ist, wie Anbieteranweisungen in Kontrollen uebersetzt werden, wer die menschliche Aufsicht uebernimmt, welche Logs und Monitoring-Nachweise benoetigt werden und wann die Nutzung gestoppt oder eskaliert werden muss.

Das muss Produktarbeit nicht blockieren. Der schnellere Weg ist ein Deployer-Review innerhalb bestehender Produkt-, Vendor-, Security- und Launch-Prozesse. Jeder relevante KI-Workflow sollte einen kurzen Datensatz haben: System, Zweck, Rollenbewertung, menschliche Aufsicht, Eingabedatenkontrollen, Monitoring, Log-Aufbewahrung, Incident-Route, Informationspflichten und Trigger fuer erneute Bewertung.

Artikel 26 der Verordnung (EU) 2024/1689 ist der zentrale Bezugspunkt fuer Betreiber hochriskanter KI-Systeme. Er verlangt unter anderem Nutzung gemaess Anbieteranweisungen, kompetente menschliche Aufsicht, relevante und hinreichend repraesentative Eingabedaten, soweit der Deployer sie kontrolliert, Monitoring, Aufbewahrung automatisch erzeugter Logs unter eigener Kontrolle und Handeln bei Risiken oder schweren Vorfaellen. Artikel 13 und 27 sind ebenfalls wichtig, weil Anbieterinformationen und Grundrechte-Folgenabschaetzungen die Arbeit vor dem Go-live praegen koennen.

Warum das praktisch zaehlt

Viele SaaS-Unternehmen haben KI-Governance bereits verteilt: Produkt genehmigt Features, Engineering integriert Anbieter, Legal prueft Anforderungen, Security sammelt Vendor-Nachweise und Sales beantwortet spaeter Kundenfragen. Deployer-Pflichten zeigen, wo diese Aktivitaeten nicht zusammenlaufen.

Ein Unternehmen kann Anbieter einer kundenseitigen KI-Funktion, Deployer eines internen Workflows und Kunde eines externen Providers sein. Diese Rollen muessen pro Workflow bewertet werden. Deployment-Entscheidungen bestimmen das Risiko: Welche Daten werden eingegeben, wer verlaesst sich auf Outputs, welche Ausnahmen sind erlaubt und wann darf ein Mensch uebersteuern?

Den Review in Delivery einbauen

Fuegen Sie Deployer-Fragen in KI-Inventar, Vendor Intake, Produktanforderungen, Datenschutzreview, Security Review und Launch-Readiness ein. Starten Sie den Review, wenn ein neues KI-System eingefuehrt wird, der Zweck sich aendert, ein internes Tool kundenwirksam wird, neue Eingabedaten hinzukommen, menschliche Pruefung reduziert wird, Anbieter oder Modell wechseln oder Incident-Signale auftreten.

Der Prozess braucht klare Owner: Wer oeffnet den Datensatz, wer liefert Workflow-Fakten, wer bewertet Rolle und Einstufung, wer bestaetigt technische Nachweise, wer genehmigt den Launch und wer verantwortet Reassessments. So wird der Review kein vages Legal-Checkspaet im Prozess.

Der Deployer-Datensatz

Ein guter Datensatz nennt System, Provider, internen Owner, Produktbereich, Prozess, Zweck, Nutzer, betroffene Personen, Datenkategorien, Laender und Launch-Status. Haengen Sie Anbieteranweisungen an und uebersetzen Sie sie in operative Schritte. Wenn Anweisungen geschulte Reviewende verlangen, muss der Datensatz Review-Schritt, Training, Eskalation und Nachweis zeigen.

Dokumentieren Sie danach Rolle und Klassifizierung: Deployer, Provider oder beides; hochriskant oder nicht; relevante AI-Act-Bestimmung; offene Unsicherheiten. Danach mappen Sie Pflichten auf Kontrollen: Oversight-Owner, freigegebene Anweisungen, Datenqualitaetspruefungen, Monitoring-Signale, Logs, Incident-Kriterien, Notices und Stop/Eskalationsroute.

Kontrolle ohne Scheintheater

"Human in the loop" reicht nicht, wenn die Person keine Zeit, kein Wissen oder keine Autoritaet hat. Dokumentieren Sie, wer Outputs prueft, worauf geachtet werden muss, welche Informationen noetig sind, was uebersteuert oder pausiert werden darf und welcher Nachweis entsteht.

Logs und Monitoring sollten vor dem Launch geklaert sein. Logs koennen in Vendor-Konsolen, Produkttelemetrie, Audit-Events, Security-Tools oder Support-Systemen liegen. Das Team muss wissen, was unter eigener Kontrolle steht, wie lange es aufbewahrt wird und wer es exportieren kann. Monitoring sollte Beschwerden, ungewoehnliche Outputs, Override-Raten, fehlgeschlagene Reviews, Datenqualitaetsausnahmen, Vendor-Aenderungen und Security Events erfassen.

Risiken, Incidents und Arbeitsplatznutzung

Wenn die Nutzung trotz Befolgung der Anweisungen ein Risiko darstellen kann, muss der Deployer moeglicherweise Provider oder Distributor informieren, Behoerden einbeziehen und die Nutzung aussetzen. Definieren Sie Trigger vor dem Launch: schaedliche Outputs, fehlende Logs, geaenderte Modelle, Nutzung ausserhalb des Zwecks, Beschwerden oder Sicherheitsereignisse.

Bei bestimmten hochriskanten Nutzungen kann eine Grundrechte-Folgenabschaetzung nach Artikel 27 erforderlich sein. Arbeitsplatznutzung braucht einen eigenen Launch-Check, weil Arbeitgeber-Deployer unter bestimmten Voraussetzungen Arbeitnehmervertretungen und betroffene Arbeitnehmer vor Inbetriebnahme informieren muessen.

FAQ

Was ist der praktische Zweck von Deployer-Pflichten?

Sie sollen zeigen, dass das Unternehmen Anbieteranweisungen befolgt, kompetente menschliche Aufsicht einsetzt, Eingabedaten kontrolliert, Nutzung ueberwacht, Logs haelt, Incidents behandelt und den Workflow neu bewertet, wenn sich Fakten aendern.

Wie vermeidet man langsame Produktlieferung?

Der Review gehoert in bestehende Produkt-, Vendor-, Security-, Privacy- und Launch-Prozesse. Trigger, Owner und Evidenzvorlagen verhindern, dass dieselben Fragen jedes Mal neu beantwortet werden.

Sources

• 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.