Haeufige Fehler bei Deployer-Pflichten, die SaaS-Teams immer noch machen

Der haeufigste Fehler besteht darin, Deployer-Pflichten aus dem EU AI Act als einmalige rechtliche Einordnung zu behandeln. Fuer SaaS-Teams ist die eigentliche Arbeit operativ: Wann nutzt das Unternehmen ein AI-System unter eigener Verantwortung? Ist die Nutzung hochriskant? Welche Anweisungen des Providers gelten? Wer fuehrt menschliche Aufsicht aus? Welche Logs werden kontrolliert? Wie wird eskaliert?

Artikel 26 verlangt fuer Deployer von Hochrisiko-AI-Systemen unter anderem Nutzung gemaess Anweisungen, kompetente menschliche Aufsicht, Kontrolle relevanter Eingabedaten, Monitoring, Aufbewahrung kontrollierter automatisch erzeugter Logs und Reaktion auf Risiken oder schwerwiegende Vorfaelle. Artikel 27 kann fuer bestimmte Deployer und Use Cases eine Fundamental Rights Impact Assessment ausloesen. Artikel 13 ist wichtig, weil Provider-Anweisungen die Grundlage fuer die korrekte Nutzung bilden.

Fehler 1: Nur an Kunden denken

Viele SaaS-Unternehmen betrachten Deployer-Pflichten nur bei Kundennutzung. Interne Nutzung kann aber genauso relevant sein: Support-Triage, HR-Screening, Risiko-Scoring, Fraud, Security-Untersuchungen oder operative Priorisierung. Nicht jeder Einsatz ist hochriskant, aber die Rollenfrage gehoert in jeden AI-Workflow.

Fehler 2: Provider-Dokumente als Kontrolle behandeln

Ein PDF des Providers ist keine operative Kontrolle. Die Anweisungen muessen in SOPs, Tickets, Trainings, Monitoring, Review-Kriterien und Evidenz uebersetzt werden. Wenn der Provider menschliche Pruefung verlangt, muss der Deployer zeigen koennen, wer prueft, nach welchen Kriterien, mit welcher Befugnis und wo die Evidenz liegt.

Fehler 3: Menschliche Aufsicht ohne Befugnis

"Human in the loop" reicht nicht, wenn die Person keine Kompetenz, Zeit, Autoritaet oder Eskalationsmoeglichkeit hat. Die Aufsicht sollte als Kontrolle beschrieben werden: Rolle, Training, Review-Kriterien, Override-Befugnis, Eskalation, Evidenz und Backup.

Fehler 4: Eingabedaten und Logs zu spaet klaeren

Wenn der Deployer Eingabedaten kontrolliert, muessen sie fuer den Zweck relevant und ausreichend repraesentativ sein. Teams sollten erlaubte Datenquellen, verbotene Felder, Qualitaetschecks und Aenderungsfreigaben vor dem Launch festlegen.

Logs duerfen ebenfalls nicht erst im Incident gesucht werden. Der Record sollte zeigen, welche Logs existieren, wer sie kontrolliert, wie lange sie aufbewahrt werden, wie Export funktioniert und wer Zugriff hat.

Fehler 5: Alles in einen AI-Review werfen

Deployer-Pflichten, Provider-Pflichten, Transparenz, Datenschutz, Security, Vendor Risk und Kundenkommunikation sind verbundene, aber unterschiedliche Spuren. Der Deployer-Record sollte Rolle, Klassifikation, Anweisungen, Aufsicht, Eingabedaten, Monitoring, Logs, Incident Route, Hinweise und Reassessment beantworten.

Fehler 6: Eskalation erst im Ernstfall definieren

Wenn eine Nutzung trotz Anweisungen ein relevantes Risiko erzeugen kann, muss der Deployer handeln, informieren und gegebenenfalls suspendieren. Das sollte nicht im Krisenmoment erfunden werden. Definieren Sie Trigger wie schaedliche Outputs, fehlende Logs, Provider-Aenderungen, Beschwerden, Zweckabweichungen oder fehlgeschlagene Overrides.

Was als Naechstes zu tun ist

Beginnen Sie mit einem live genutzten oder launchnahen Workflow. Erstellen Sie einen Deployer-Record mit System, Zweck, Provider-Anweisungen, Rollenentscheidung, Hochrisiko-Screening, Aufsicht, Eingabedaten, Logs, Monitoring, Incident Route, Impact-Assessment-Screening, Evidenzort und Reassessment-Triggern.

Deployer-Pflichten werden handhabbar, wenn sie in Owner, Trigger und Evidenz uebersetzt werden. Sie werden teuer, wenn sie bis zur Kundenfrage, zum Audit oder zum Incident nur eine rechtliche Notiz bleiben.

FAQ

Was sollten Teams ueber Deployer-Pflichten verstehen?

Sie sollten verstehen, wann Pflichten greifen koennen, welche operativen Aenderungen noetig sind und welche Evidenz Anweisungen, Aufsicht, Logs, Monitoring und Eskalation belegt.

Warum sind Deployer-Pflichten praktisch wichtig?

Weil der Deployer die Live-Nutzung kontrolliert. Gute Provider-Dokumentation beweist nicht automatisch, dass das SaaS-Team korrekt gehandelt hat.

Was ist der groesste Fehler?

Der groesste Fehler ist, Deployer-Pflichten als einmalige rechtliche Interpretation statt als wiederholbaren Workflow zu behandeln.

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.