Wann Deployer-Pflichten gelten und was als Naechstes zu tun ist

Deployer-Pflichten gelten, wenn ein Unternehmen ein Hochrisiko-KI-System unter eigener Verantwortung nutzt. Fuer SaaS-Teams geht es nicht nur darum, wer das System gebaut hat. Entscheidend ist, wer den Einsatz, die Konfiguration, die Ueberwachung, die menschliche Kontrolle und die Nachweise im konkreten Workflow steuert.

Der naechste Schritt ist ein operativer Prozess: KI-System identifizieren, Hochrisiko-Status pruefen, Rolle als Deployer bewerten, Owner benennen, Anbieteranweisungen einhalten, menschliche Aufsicht festlegen, Betrieb ueberwachen, relevante Logs sichern und Eskalation fuer Risiken oder Vorfaelle dokumentieren.

Diese Arbeit passt zu AI governance expectations for SaaS vendors, internal AI-tool review, compliance owner models und dem Risiko statischer Compliance-Dokumente.

Wann das Thema auftaucht

Deployer-Pflichten werden relevant, wenn ein Team ein Hochrisiko-KI-System in Produkt-, Kunden-, HR-, Finanz-, Bildungs-, Gesundheits-, Public-Sector- oder anderen folgenreichen Prozessen nutzt. Ein Unternehmen kann fuer ein Feature Anbieter sein und fuer ein anderes Deployer. Die Rolle folgt dem konkreten Einsatz, nicht dem bevorzugten Label.

Typische Trigger sind KI-Systeme fuer Bewerberranking, Worker Management, Kredit- oder Versicherungsbewertung, Bildungsentscheidungen, biometrische Funktionen, kritische Infrastruktur, wesentliche Dienstleistungen oder kundenseitig konfigurierbare Entscheidungsworkflows.

Wann es moeglicherweise nicht gilt

Nicht jeder KI-gestuetzte SaaS-Workflow loest Artikel-26-Pflichten aus. Ein Drafting Assistant, Support-Zusammenfasser, Code-Helfer oder internes Knowledge-Search-Tool kann ausserhalb eines Hochrisiko-Kontexts liegen.

Trotzdem braucht der Workflow oft Privacy Review, Security Review, Vendor Assessment, Transparenzpruefung, Vertragsgrenzen oder AI Inventory. Wichtig ist Routing: normale KI-Nutzung sollte leicht dokumentiert werden, plausible Hochrisiko-Nutzung braucht tieferes Review.

Was Deployer steuern muessen

Artikel 26 verlangt vor allem operative Kontrolle. Deployer muessen geeignete technische und organisatorische Massnahmen treffen, damit das System gemaess den Nutzungsanweisungen eingesetzt wird. Die menschliche Aufsicht muss Personen mit Kompetenz, Training, Befugnis und Unterstuetzung zugewiesen werden.

Wenn der Deployer Inputdaten kontrolliert, muessen diese fuer den vorgesehenen Zweck relevant und ausreichend repraesentativ sein. Der Betrieb muss anhand der Anweisungen ueberwacht werden. Bei Risiken oder schweren Vorfaellen braucht es Benachrichtigung, Eskalation und gegebenenfalls Aussetzung der Nutzung.

Logs sind ebenfalls wichtig. Soweit sie unter Kontrolle des Deployers stehen, muessen sie fuer einen angemessenen Zeitraum und mindestens sechs Monate aufbewahrt werden, sofern kein anderes Recht etwas anderes verlangt. Bei Hochrisiko-KI am Arbeitsplatz muessen Arbeitnehmervertretungen und betroffene Arbeitnehmer vor Nutzung informiert werden.

Was zuerst zu tun ist

Bauen Sie ein kurzes Deployment Intake ein. Erfassen Sie System, Anbieter, Owner, Zweck, Nutzerreise, betroffene Personen, Geografie, Datenkategorien, Output, menschliche Nutzung, Hochrisiko-Hinweise, Rolle und Ablageort der Anbieteranweisungen.

Danach routen Sie in drei Bahnen: normale KI-Nutzung, unklare oder sensible Nutzung, wahrscheinliches Hochrisiko-Deployment. Fuer die dritte Bahn braucht es einen Decision Record mit Owner, Rollenbewertung, Anbieteranweisungen, Human Oversight, Inputdaten, Monitoring, Log Retention, Incident Escalation, Arbeitnehmerinformation und Reassessment Trigger.

Haeufige Fehler

Der erste Fehler ist die Annahme, Deployer-Pflichten betreffen nur Kunden. SaaS-Anbieter nutzen KI intern, konfigurieren Workflows fuer Kunden oder betreiben AI in Managed Services.

Der zweite Fehler ist blinde Abhaengigkeit von Vendor-Dokumentation. Anbieteranweisungen sind wichtig, ersetzen aber nicht die konkrete Einsatzentscheidung, Aufsicht, Inputdatenkontrolle, Monitoring und Eskalation.

Der dritte Fehler ist menschliche Aufsicht ohne echte Befugnis. Reviewer brauchen Training, Zugriff, Zeit, Eskalationsrecht und eine klare Stop-Regel.

FAQ

Wozu dienen Deployer-Pflichten praktisch?

Sie sorgen dafuer, dass ein Hochrisiko-KI-System nach der Bereitstellung verantwortungsvoll betrieben wird: mit Ownern, Aufsicht, Monitoring, Logs und Eskalation.

Wann gelten sie fuer SaaS-Teams?

Wenn ein SaaS-Team ein Hochrisiko-KI-System unter eigener Verantwortung nutzt, konfiguriert oder betreibt, etwa intern, fuer Kunden oder in sensiblen Entscheidungsworkflows.

Was sollte zuerst dokumentiert werden?

Starten Sie mit System, Zweck, Owner, Rollenbewertung, Hochrisiko-Screening, Anbieteranweisungen, Human Oversight, Inputdaten, Monitoring, Logs und Incident Escalation.