Checkliste Deployer-Pflichten fuer Gruender und Compliance-Leads

Deployer-Pflichten nach dem EU AI Act sollten geprueft werden, bevor ein Team ein Hochrisiko-KI-System in Betrieb nimmt, dessen Einsatz aendert, es in einen neuen Kunden- oder Mitarbeiterprozess bringt oder sich bei einer folgenreichen Entscheidung auf seinen Output stuetzt. Die praktische Checkliste ist klar: Rolle bestaetigen, Provider-Anweisungen befolgen, kompetente menschliche Aufsicht zuweisen, Eingabedaten kontrollieren, Live-Nutzung ueberwachen, Logs aufbewahren, Hinweise und Impact-Assessment-Trigger verwalten und festlegen, wann Nutzung ausgesetzt oder eskaliert wird.

Fuer SaaS-Teams ist das ein Betriebsablauf, kein einzelnes Legal-Memo. Deployer-Pflichten verbinden Produktkonfiguration, Implementierung, Vendor Management, Support, Training, Security Logging, Privacy Review und Incident Response. Ein Gruender oder Compliance Lead sollte in einem Datensatz sehen koennen, welches System genutzt wird, warum das Unternehmen Deployer ist, welche Anweisungen gelten, wer beaufsichtigt, welche Nachweise existieren und was eine Neubewertung ausloest.

Nutzen Sie die Checkliste zusammen mit AI-Governance-Erwartungen an SaaS-Anbieter. Die weiteren verwandten Themen zur schnellen AI-Regulierung, statischen Compliance-Dokumenten und Fundraising-Due-Diligence sind derzeit im deutschen Blog noch nicht lokalisiert.

1. System und Use Case bestaetigen

Benennen Sie das konkrete KI-System und den Workflow. Schreiben Sie Provider, Produktname, Version oder Konfiguration, Zweck, Business Owner, Nutzer, betroffene Personen, Eingabedaten, Output, Entscheidungspunkt und Einsatzbereich auf. Wird das System fuer Kunden, Mitarbeitende, Bewerber, Auftragnehmer oder interne Ablaufe genutzt?

Halten Sie fest, ob das System hochriskant, transparenzpflichtig, minimal riskant oder noch in Klassifizierung ist. Ist die Klassifizierung offen, darf die Checkliste nicht als erledigt gelten. Sie sollte den Owner, offene Fragen, angeforderte Provider-Unterlagen und Entscheidungsdatum zeigen.

2. Rolle als Deployer pruefen

Deployer-Status entsteht, wenn eine Organisation ein KI-System unter eigener Verantwortung nutzt, ausser bei persoenlicher nicht-beruflicher Nutzung. SaaS-Unternehmen koennen Deployer sein, wenn sie Drittanbieter-KI in Support, Recruiting, Trust and Safety, Fraud Review, Customer Scoring, Content Moderation oder internen Betriebsablaeufen einsetzen.

Dokumentieren Sie die Fakten: Wer hat das System ausgewaehlt? Wer definiert den operativen Einsatz? Wer kontrolliert Zugriff, Schwellen, Prompts, Regeln oder Eskalationen? Wer schult Nutzer? Wer entscheidet, ob der KI-Output akzeptiert, ueberprueft, ueberstimmt oder ignoriert wird?

3. Provider-Anweisungen sichern

Artikel 26 verlangt geeignete technische und organisatorische Massnahmen, damit Hochrisiko-KI-Systeme gemaess den Anweisungen genutzt werden. Das Team braucht aktuelle Anweisungen, Release Notes, Grenzen, erlaubte und nicht erlaubte Use Cases, Monitoring-Erwartungen, Human-Oversight-Vorgaben und Eskalationswege.

Speichern Sie die Anweisungen auffindbar. Notieren Sie Version und Pruefdatum. Wenn Implementierung, Support oder Customer Success eigene Anleitungen erhalten, muessen diese mit den offiziellen Anweisungen abgeglichen werden. Lokale Abkuerzungen, Sonderprompts oder undocumented thresholds koennen Rolle, Risiko oder Vertragslage veraendern.

4. Menschliche Aufsicht zuweisen

Menschliche Aufsicht ist nicht erledigt, wenn in einer Policy ein Team genannt wird. Artikel 26 verlangt natuerliche Personen mit notwendiger Kompetenz, Training, Autoritaet und Unterstuetzung. Der Datensatz sollte Namen oder Rollen, Training, Entscheidungsrechte und Interventionspunkte enthalten.

Fragen Sie pro Workflow: Versteht der Reviewer den Output? Sieht er genug Kontext, um ihn anzufechten? Kann er ueberstimmen, pausieren, eskalieren oder ablehnen? Ist er vor Druck geschuetzt, Empfehlungen nur abzunicken? Kennt er die Grenzen des genehmigten Einsatzes?

5. Eingabedaten kontrollieren

Soweit der Deployer Eingabedaten kontrolliert, muessen diese im Blick auf den Zweck relevant und ausreichend repraesentativ sein. Das betrifft Kundendaten, Mitarbeiterdaten, Tickets, Dokumente, Prompts, Labels, CRM-Felder, Transaktionen oder Konfigurationen.

Dokumentieren Sie Mindestqualitaet, ausgeschlossene Daten, Umgang mit veralteten Daten, Bias- oder Repraesentativitaetsfragen und Remediation Owner. Wenn nicht nachweisbar ist, dass Inputs zum genehmigten Einsatz passen, sollte der Launch bedingt bleiben.

6. Betrieb ueberwachen und eskalieren

Deployers muessen den Betrieb anhand der Anweisungen ueberwachen. Definieren Sie, was beobachtet wird, wie oft Review stattfindet, wer prueft und was bei veraenderten Ergebnissen passiert.

Monitoring kann Support-Eskalationen, Beschwerden, Override-Raten, Sampling, Incident Tickets, Drift-Signale, Vendor Notices, Missbrauch oder wiederholte manuelle Korrekturen umfassen. Wenn die Nutzung ein Risiko darstellen kann, sollten Provider oder Distributor und relevante Marktueberwachungsbehoerden informiert und die Nutzung ausgesetzt werden. Bei schwerwiegenden Vorfaellen muss der Eskalationsweg Provider, Importeur oder Distributor, Behoerde, Legal, Security, Privacy und Kundenkommunikation abdecken.

7. Logs unter eigener Kontrolle behalten

Automatisch erzeugte Logs, die unter Kontrolle des Deployers stehen, muessen fuer einen dem Zweck angemessenen Zeitraum und mindestens sechs Monate aufbewahrt werden, sofern kein anderes Recht etwas anderes verlangt. Erfassen Sie vorhandene Logs, Kontrollbereich, Retention, Access Owner, Security-Beschraenkungen, Privacy Review, Exportweg und Incident-Retrieval.

Logs sollten beantworten koennen: welches System wurde genutzt, von wem, fuer welchen Workflow, mit welcher Eingabe oder Konfiguration, welcher Output entstand, ob ein Mensch pruefte und welche Handlung folgte.

8. Hinweise und Impact Assessments verwalten

Vor Einsatz eines Hochrisiko-KI-Systems am Arbeitsplatz muessen Arbeitgeber-Deployers Arbeitnehmervertretungen und betroffene Arbeitnehmer informieren, wo dies anwendbar ist. Je nach System und Artikel 50 koennen auch Hinweise gegenueber Personen erforderlich sein, die KI-Interaktionen oder KI-unterstuetzten Entscheidungen unterliegen.

Artikel 27 kann fuer bestimmte Deployers von Hochrisiko-KI-Systemen eine Grundrechte-Folgenabschaetzung ausloesen. Artikel 26 verweist ausserdem darauf, Provider-Informationen fuer Datenschutz-Folgenabschaetzungen nach DSGVO zu nutzen, wenn anwendbar. Dokumentieren Sie Entscheidung, Faktenbasis, Owner und Reassessment-Trigger.

9. Evidence Pack und Reassessment

Ordnen Sie Nachweise um Entscheidungen: Rollenpruefung, Klassifizierung, Provider-Anweisungen, genehmigter Use Case, Aufsicht, Training, Input-Kontrollen, Monitoring, Log-Retention, Hinweise, Impact-Assessment-Entscheidung, Vendor-Kontakte, Incident-Route und Reassessment-Trigger.

Oeffnen Sie die Checkliste erneut, wenn Provider-Anweisungen, Systemversion, Workflow, Kundensegment, Eingabedaten, Automatisierung, Human Review, Beschwerden, Logs, Vorfaelle oder offizielle Leitlinien sich aendern.

FAQ

Was ist der praktische Zweck von Deployer-Pflichten?

Das Team soll zeigen koennen, dass es Provider-Anweisungen befolgt, kompetente Aufsicht zuweist, Nutzung ueberwacht, relevante Inputs kontrolliert, Logs haelt, Hinweise verwaltet und Risiken eskaliert.

Wann gelten Deployer-Pflichten fuer SaaS-Teams?

Sie koennen gelten, wenn ein SaaS-Team ein KI-System unter eigener Verantwortung in einem Geschaeftsprozess nutzt, besonders bei Hochrisiko-Systemen oder Entscheidungen zu Kunden, Mitarbeitenden, Bewerbern, Fraud, Sicherheit oder Betrieb.

Was sollte zuerst dokumentiert werden?

Beginnen Sie mit einem Datensatz pro KI-Workflow: Rolle, Klassifizierung, Anweisungen, genehmigte Nutzung, Aufsicht, Monitoring, Logs, Hinweise, Impact-Assessment-Entscheidung, Incident-Route und Reassessment-Trigger.

Quellen

• Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence.
• European Commission AI Act Service Desk, Article 26.
• European Commission AI Act Service Desk, Article 27.
• European Commission AI Act Service Desk, Article 50.
• European Commission AI Act Service Desk, Article 4.