Dürfen wir das überhaupt? Warum die Prozessanalyse deine Rechtsfrage und deine Tool-Frage gleichzeitig beantwortet

Kaum eine Frage bremst KI-Vorhaben in kleinen Betrieben so zuverlässig wie diese: „Dürfen wir das überhaupt?" Und fast immer folgt darauf dasselbe Muster: Die Rechtsfrage geht an den Datenschutzbeauftragten oder einen Anwalt, parallel sucht jemand nach Werkzeugen. Zwei Baustellen, zwei Zuständigkeiten, klingt vernünftig. In der Praxis blockieren sich beide gegenseitig – und das Projekt steht. Dabei gibt es einen Weg, der beide Fragen mit einem einzigen Arbeitsdokument beantwortet. Er beginnt nicht beim Tool und nicht beim Gesetz, sondern bei deinen Prozessen.

Zwei Baustellen, die sich gegenseitig blockieren

Laut Bitkom nennen 53% der deutschen Unternehmen rechtliche Hürden und 48% Datenschutzanforderungen als Hemmnis für den KI-Einsatz – fast gleichauf mit fehlendem Know-how (53%) [1]. Die übliche Reaktion darauf ist Arbeitsteilung: hier das Rechtliche, dort die Technik.

Das Problem: Die Rechtsfrage ist ohne konkreten Einsatzpunkt gar nicht beantwortbar. Auf „Dürfen wir KI nutzen?" gibt es keine seriöse Antwort, also kommt eine defensive Pauschalregel zurück, im Zweifel ein Verbot. Und die Werkzeugsuche ohne Klarheit über die Datenflüsse trifft Entscheidungen, die die spätere Rechtsprüfung wieder kassiert.

Das praktische Ergebnis dieser Blockade heißt Schatten-KI: Beschäftigte nutzen private KI-Konten an den offiziellen Regeln vorbei. Die MIT-Studie „The GenAI Divide" dokumentiert diese Schatten-Nutzung quer durch die Unternehmen [2], und in KMU nutzen Berichten zufolge bis zu 30% der Angestellten KI-Tools über private Accounts für berufliche Aufgaben. Ein Verbot verhindert die Nutzung also nicht, es verlagert sie in den Bereich, in dem niemand mehr prüft, welche Kundendaten in welchen Dienst fließen. Für den Datenschutz ist das der schlechteste erreichbare Zustand.

Ein Konzern löst diese Blockade mit Personal: Rechtsabteilung, Datenschutzbeauftragter, IT und Prozessmanagement stimmen sich ab, bis ein Rahmen steht. Ein Betrieb mit zwölf Beschäftigten hat diese Abteilungen nicht – dort laufen alle drei Rollen bei der Geschäftsführung zusammen. Er braucht deshalb ein Vorgehen, das die Fragen zusammenführt, statt sie auf Abteilungen zu verteilen, die es im Haus gar nicht gibt.

Beide Gesetze denken in Tätigkeiten, nicht in Tools

Der Ausweg steckt in einer Beobachtung, die im Projektalltag leicht untergeht: DSGVO und KI-Verordnung sind in derselben Einheit geschrieben, in der auch eine Prozessanalyse arbeitet – der einzelnen Tätigkeit.

Die DSGVO knüpft an die Verarbeitungstätigkeit an; das Verzeichnis nach Artikel 30 heißt wörtlich „Verzeichnis von Verarbeitungstätigkeiten". Die KI-Verordnung klassifiziert nach Zweck und Einsatzkontext eines Systems, nicht nach dem Produkt: Ein Werkzeug hat keine Risikoklasse, ein Einsatzzweck hat eine.

Ein Beispiel zeigt, wie wenig das Tool über das Risiko aussagt. Dasselbe Sprachmodell, das beim Formulieren einer Stellenanzeige ein Fall mit minimalen Pflichten ist, wird zum Hochrisiko-System, sobald es Bewerbungen vorsortiert – die KI-Verordnung stuft KI zur Auswahl und Bewertung von Bewerbern als Hochrisiko ein (Anhang III; die zugehörigen Pflichten gelten nach der Omnibus-Verordnung vom Juli 2026 ab Dezember 2027) [3]. Ein Werkzeug, zwei Tätigkeiten, zwei Risikoklassen. Eine Prüfung, die beim Tool ansetzt, kann diesen Unterschied nicht abbilden. Eine Prüfung, die bei der Tätigkeit ansetzt, stellt ihn automatisch fest.

Genau deshalb ist die Prozessanalyse mehr als Absicherung gegen ein gescheitertes KI-Projekt. Sie ist das Bindeglied: Dieselbe Tätigkeitsliste, die den Business Case rechnet, beantwortet auch die Rechtsfrage und grenzt die Werkzeugauswahl ein.

Die Ableitungskette: von der Tätigkeit zum zulässigen Werkzeug

In der Prozessaufnahme entsteht ohnehin eine Tabelle: je Tätigkeit die ein- und ausgehenden Informationen, das verwendete System, wer das Ergebnis prüft. Ergänzt um eine einzige Spalte – die Datenklasse – trägt diese Tabelle drei Antworten zugleich:

• Lohnt es sich? -> Zeiten x Häufigkeit x Stundensatz
• Dürfen wir es? -> Datenklasse je Tätigkeit -> Schutzmaßnahmen und KI-VO-Einordnung
• Womit machen wir es? -> Datenklasse + Systeme + Prüfschritt -> zulässige Werkzeugklasse

Die Kette dahinter hat vier Glieder und läuft immer in dieselbe Richtung: Tätigkeit -> Datenfluss -> Werkzeugklasse -> Werkzeug.

Für den Datenfluss reichen in der Praxis vier Datenklassen: öffentlich (Website-Texte, Preislisten), intern (Kalkulationen, Notizen ohne Personenbezug), personenbezogen (Namen, Kontakt- und Vertragsdaten) und besonders geschützt (Gesundheitsdaten nach Artikel 9 DSGVO, Berufsgeheimnisse nach § 203 StGB).

Dem stehen vier Werkzeugklassen gegenüber, als Treppe gedacht:

1. Consumer-Cloud: frei verfügbarer Dienst mit Standardkonto – genügt in der Regel nur für öffentliche Daten, denn die Nutzung deiner Eingaben für das Training ist oft nicht ausgeschlossen
2. Business-Cloud mit AVV (Auftragsverarbeitungsvertrag): Unternehmenskonto mit vertraglich ausgeschlossener Trainingsnutzung – für interne Daten
3. EU-Hosting mit AVV: zusätzlich Verarbeitung in der EU oder mit belastbarer Drittlandabsicherung – für personenbezogene Daten
4. Eigene Umgebung: die Daten verlassen die kontrollierte Umgebung nicht – für besonders geschützte Daten und Berufsgeheimnisträger

Diese Zuordnung ist eine bewusst konservative Faustregel für die Vorauswahl, keine fertige Rechtsprüfung – im Einzelfall kann nach Prüfung auch eine niedrigere Stufe zulässig sein. Aber sie verwandelt den Auftrag an deinen Datenschutzbeauftragten von „Prüfen Sie unseren KI-Einsatz" in eine Frage, die sich in einer Stunde beantworten lässt: Dürfen in dieser Tätigkeit diese Datenklassen in diese Werkzeugklasse? Wer die gängigen Anbieter nach genau diesen Dimensionen einordnet – AVV vorhanden, Trainingsnutzung ausgeschlossen, Verarbeitungsort –, stößt schnell auf eine wichtige Pointe: Derselbe Anbieter kann je nach Tarif von „ungeeignet" bis „unbedenklich" alles sein. Ein privates Consumer-Abo und der Business-Plan desselben Dienstes sind compliance-technisch zwei verschiedene Produkte.

Ein Hebel wird dabei oft übersehen: Pseudonymisierung senkt die benötigte Klasse. Wird der Kundenname vor der Eingabe durch einen Platzhalter ersetzt und erst beim menschlichen Prüfen wieder eingesetzt, verarbeitet das Werkzeug interne statt personenbezogener Daten – und Klasse 2 genügt. Diese Option existiert nur auf Tätigkeitsebene. Ein Tool-Vergleich kennt sie nicht.

Erst am Ende der Kette steht das konkrete Werkzeug: ausgewählt innerhalb der zulässigen Klasse, nach den unspektakulären Kriterien Anbindung, Bedienbarkeit und Preis.

Was das in der Praxis bedeutet: drei Fälle

Fall 1, der Angebotstext. Eingangsdaten sind die Kundenanfrage (personenbezogen), der Leistungskatalog (intern) und Altangebote (personenbezogen). Die Kette ergibt zwei gangbare Wege: ein EU-gehosteter Dienst mit AVV (Klasse 3) oder ein Business-Dienst der Klasse 2 mit pseudonymisierten Vorlagen. Aus der diffusen Frage „Dürfen wir Angebote mit KI schreiben?" sind zwei prüfbare Optionen geworden.

Fall 2, die Terminnachbereitung. Für eine Unternehmensberaterin sind Gesprächsnotizen personenbezogene Kundendaten: Klasse 3 genügt. Für eine Therapeutin enthalten dieselben Notizen Gesundheitsdaten – die Kette führt zu Klasse 4, also lokaler Verarbeitung, oder zum Verzicht auf diesen Einsatzpunkt. Dieselbe Tätigkeit, zwei Branchen, zwei Antworten.

Fall 3, die Grenze. Ein Betrieb will die Personalarbeit entlasten. „Stellenanzeige formulieren" läuft glatt durch die Kette: interne Daten, Klasse 2, minimale Pflichten. „Bewerbungen vorsortieren" stoppt am KI-VO-Check: Hochrisiko nach Anhang III, Pflichtenprogramm für einen Kleinbetrieb außer Verhältnis – die Tätigkeit wird zurückgestellt. Das Ergebnis ist kein Verbot von „KI im Personalbereich", sondern eine saubere Unterscheidung zweier Tätigkeiten desselben Bereichs, mit einer Begründung, die auch eine Aufsichtsbehörde nachvollziehen kann.

Die Compliance-Dokumente fallen nebenbei mit ab

Der vielleicht unterschätzteste Effekt: Die Pflichtdokumentation entsteht als Nebenprodukt. Aus der Tätigkeitsliste ergibt sich der Eintrag für das Verzeichnis der Verarbeitungstätigkeiten nach Artikel 30. Die Einordnung nach der KI-Verordnung liegt je Anwendungsfall schriftlich vor, einschließlich der Begründung, warum kein Hochrisiko-Fall vorliegt. Und die Schulung aus der Pilotphase zahlt auf die KI-Kompetenz nach Artikel 4 der KI-Verordnung ein, die seit Februar 2025 gilt – die Bundesnetzagentur beschreibt dafür ein pragmatisches Vorgehen in vier Schritten: Bedarf ermitteln, Maßnahmen gestalten, auffrischen, dokumentieren [4].

Was im werkzeuggetriebenen Projekt drei getrennte Pflichtenhefte wären, entsteht hier aus derselben Tabelle wie der Business Case.

Und damit dreht sich die Ausgangsfrage um. „Dürfen wir das überhaupt?" ist pauschal tatsächlich nicht beantwortbar – für die konkreten Tätigkeiten deines Betriebs dagegen schon, und zwar belastbar. Das größte Hemmnis der KI-Einführung ist damit zugleich ihr bester Einstieg: nicht mit einer Tool-Demo, sondern mit einem Blick auf die eigenen Prozesse. Die Nutzenrechnung entsteht auf demselben Weg gleich mit.

Quellen:

[1] Bitkom (2025): Presseinformation zur KI-Nutzung in der deutschen Wirtschaft, https://www.bitkom.org/Presse/Presseinformation/Durchbruch-Kuenstliche-Intelligenz

[2] MIT-Projekt NANDA (2025): The GenAI Divide – State of AI in Business, Berichterstattung u.a. bei Fortune, https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/

[3] Verordnung (EU) 2024/1689 (KI-Verordnung), Anhang III; Fristen geändert durch Verordnung (EU) 2026/1744 („Digital Omnibus on AI", in Kraft seit 27.07.2026): Hochrisikopflichten nach Anhang III gelten ab 02.12.2027

[4] Bundesnetzagentur (2025): Hinweispapier KI-Kompetenzen nach Artikel 4 KI-Verordnung, https://www.bundesnetzagentur.de/DE/Fachthemen/Digitales/KI/_functions/Hinweispapier.pdf