Einführung
Aktualisierung: 08.08.2026 – Rechtslage, Anbieterlandschaft, Digital Omnibus on AI und Leitlinien zu Artikel 50 des EU AI Act geprüft
Generative KI ist in vielen Unternehmen längst Teil des Arbeitsalltags. Beschäftigte lassen Texte überarbeiten, fassen Dokumente zusammen, analysieren Daten, erzeugen Programmcode oder beantworten Kundenanfragen. Dafür kommen ChatGPT, Claude, Microsoft Copilot, Gemini und weitere KI-Dienste oder in Fachanwendungen integrierte Assistenten zum Einsatz. Häufig beginnt die Nutzung mit einem persönlichen Account, bevor das Unternehmen Anwendungsfälle, Verträge und Zuständigkeiten festgelegt hat.
Die entscheidende Frage lautet deshalb nicht, ob ein bestimmter Produktname abstrakt „erlaubt“ ist. Maßgeblich ist, welcher Dienst in welchem Tarif mit welchen aktivierten Funktionen für welchen Zweck und mit welchen Daten eingesetzt wird und wie das Unternehmen die Ergebnisse kontrolliert. Erst aus diesem Zusammenspiel lassen sich die Anforderungen an Datenschutz, Vertraulichkeit, Verträge, Beschäftigtenregeln und den EU AI Act ableiten. Das gilt für klassische Chatoberflächen ebenso wie für Large Language Models – kurz LLMs –, multimodale Assistenten, Programmierschnittstellen, Konnektoren und unternehmenseigene Integrationen.
Weitere Informationen: Beratung / Schulung zum Einsatz von KI im Unternehmen

Letzte Bearbeitung des Beitrages: 08.08.2026
Bewertung des Beitrags:
Kurzantwort: Generative KI ist weder pauschal DSGVO-konform noch generell unzulässig
Ein KI-Dienst ist nicht allein aufgrund seines Produktnamens datenschutzkonform. Umgekehrt verbietet die Datenschutz-Grundverordnung den betrieblichen Einsatz generativer KI nicht generell.
Vor einer Freigabe sollten Unternehmen sechs Punkte klären:
- Anwendungszweck: Welche konkrete Aufgabe soll das System übernehmen oder unterstützen?
- Datenklasse: Welche personenbezogenen, vertraulichen oder geschützten Inhalte gelangen in das System?
- Dienst und Tarif: Wird ein persönlicher Chatdienst, ein verwalteter Business-Arbeitsbereich, eine API oder ein eigenes System eingesetzt?
- Anbieterbeziehung: Welche Rollen, Unterauftragnehmer, Speicherfristen, Trainingsnutzungen und Drittlandübermittlungen bestehen?
- Betriebliche Regeln: Wer darf das Tool wofür nutzen und wann ist eine Freigabe erforderlich?
- Kontrolle des Ergebnisses: Wer prüft Richtigkeit, Rechte Dritter und Eignung für die vorgesehene Nutzung?
Ein Business- oder Enterprise-Tarif kann durch zentrale Administration, angepasste Datenverwendung und zusätzliche Vertragsunterlagen bessere Voraussetzungen schaffen. Er ersetzt aber weder die Rechtsgrundlage für die eingegebenen Daten noch die Prüfung des konkreten Anwendungsfalls.

Welcher technische Einsatz liegt tatsächlich vor?
Unter dem betrieblichen Einsatz generativer KI werden sehr unterschiedliche technische und vertragliche Konstellationen zusammengefasst. Für die rechtliche Einordnung ist diese Unterscheidung zentral.
| Einsatzform | Typische Merkmale | Zentrale Prüffragen |
|---|---|---|
| Persönlicher Cloud-Chatdienst | individuelles Konto, persönliche Einstellungen, kaum zentrale Kontrolle | Ist die betriebliche Nutzung gestattet? Welche Daten werden gespeichert oder für Modellverbesserungen verwendet? Kann das Unternehmen Zugriffe, Löschung und Ausscheiden von Beschäftigten steuern? |
| Verwalteter Business-Arbeitsbereich | Organisationsvertrag, zentrale Nutzerverwaltung, geschäftliche Datenschutz- und Sicherheitsfunktionen | Passen Vertrag, Auftragsverarbeitung, Unterauftragnehmer, Speicherfristen und Administration zum Anwendungsfall? Welche Funktionen können Daten an weitere Dienste übertragen? |
| API oder integrierter Assistent | Einbindung in eigene Software, Fachanwendung oder automatisierten Ablauf | Welche Systemkomponente erhält welche Daten? Wo entstehen Protokolle und Zwischenspeicher? Wer bestimmt Zwecke, Oberfläche und Ausgabe? |
| RAG-System mit interner Wissensbasis | Referenzdokumente werden gesucht und dem Modell bei der Anfrage als Kontext bereitgestellt | Wer darf auf welche Dokumente und Textabschnitte zugreifen? Sind Daten aktuell, erforderlich und löschbar? Welche externen Modelle, Embeddings oder Datenbanken sind beteiligt? |
| Eigenes oder selbst betriebenes Modell | größere technische Kontrolle, eigene Infrastruktur oder Open-Weight-Modell | Wer trägt Verantwortung für Entwicklung, Sicherheit, Trainingsdaten, Modellpflege und Betroffenenrechte? Entstehen Anbieterpflichten nach dem AI Act? |
RAG steht für „Retrieval-Augmented Generation“. Dabei wird ein Sprachmodell mit einer gesonderten Wissensbasis verbunden. Das kann Quellenbezug, Aktualisierung und Zugriffskontrolle verbessern. Es ändert aber weder nachträglich die Trainingsdaten des Grundmodells noch beseitigt es die datenschutzrechtliche Prüfung. Die Datenschutzkonferenz erläutert diese Unterschiede in ihrer Orientierungshilfe zu RAG-Systemen.
Vor dem Tool kommt der Anwendungsfall
Eine allgemeine Freigabe „für Büroarbeiten“ ist meist zu unbestimmt. Die rechtlichen Anforderungen unterscheiden sich erheblich danach, ob ein System lediglich einen öffentlichen Produkttext sprachlich glättet, vertrauliche Kundenunterlagen auswertet oder Bewerber vorsortiert.
| Betrieblicher Anwendungsfall | Typischer Prüfbedarf |
|---|---|
| Sprachliche Überarbeitung bereits veröffentlichter Produktinformationen | Freigegebener Dienst, Qualitätskontrolle, Prüfung werblicher Aussagen und Rechte am Output |
| Entwurf einer Kundenantwort nach Entfernung identifizierender Angaben | Wirksame Anonymisierung oder Datenminimierung, Vertraulichkeit, menschliche Prüfung vor Versand |
| Zusammenfassung eines Kundenvertrags mit Namen, Konditionen und Geschäftsdetails | Rechtsgrundlage, Auftragsverarbeitung, Geheimhaltung, Anbieterfunktionen, Speicher- und Löschkonzept |
| Coding-Assistent mit Zugriff auf internes Repository | Rechte am Quellcode, Geschäftsgeheimnisse, Zugriffsrechte, Protokollierung, Sicherheits- und Lizenzprüfung des Outputs |
| Interne Wissenssuche über Personal-, Support- oder Projektdokumente | Berechtigungskonzept, Zweckbindung, Datenqualität, RAG-Architektur, Löschung und Betroffenenrechte |
| Bewertung von Bewerbern oder Beschäftigten | Datenschutz, AGG, Mitbestimmung, automatisierte Entscheidungen und mögliche Hochrisiko-Einstufung nach dem AI Act |
| Kunden-Chatbot auf der Webseite oder im Produkt | Rollenverteilung, Datenschutzhinweise, Interaktionshinweis, Wissensbasis, Eskalation an Menschen und vertragliche Leistungszusagen |
Diese Beispiele sind keine pauschalen Freigaben. Sie zeigen, welche Tatsachen eine belastbare Einordnung benötigt.
Personenbezogene Daten: Welche Verarbeitung findet statt?
Sobald Prompts, hochgeladene Dateien, Nutzungsprotokolle oder Ausgaben Informationen über identifizierte oder identifizierbare Personen enthalten, gilt die Datenschutz-Grundverordnung. Dabei sind nicht nur Kundendaten relevant. Auch Namen in Verträgen, E-Mail-Inhalte, Beschäftigtendaten, Supporttickets, Benutzerkennungen und vom Modell erzeugte Aussagen über Personen können personenbezogene Daten sein.
Zweck und Rechtsgrundlage festlegen
Das Unternehmen muss bestimmen, wofür es die Daten durch das KI-System verarbeiten lässt. Eine Rechtsgrundlage, die das Speichern eines Vertrags in der eigenen Ablage trägt, erlaubt nicht automatisch dessen Übermittlung an einen externen KI-Anbieter oder dessen Nutzung für einen neuen Analysezweck.
Je nach Anwendungsfall kommen insbesondere Vertragserfüllung, eine gesetzliche Pflicht oder berechtigte Interessen in Betracht. Ein berechtigtes Interesse ist kein pauschaler Auffangtatbestand. Erforderlich sind ein legitimes Ziel, die Erforderlichkeit der Verarbeitung und eine Abwägung mit den Rechten der betroffenen Personen. Bei Beschäftigtendaten sowie besonderen Datenkategorien – etwa Gesundheitsdaten – gelten zusätzliche Anforderungen.
Der Europäische Datenschutzausschuss betont für KI-Modelle eine einzelfallbezogene Prüfung. Ob ein Modell als anonym angesehen werden kann, hängt unter anderem davon ab, wie wahrscheinlich eine Identifizierung oder Extraktion personenbezogener Trainingsdaten ist. Auch die Nutzung berechtigter Interessen ist anhand eines dreistufigen Tests zu beurteilen.
Rollen des Unternehmens und des Anbieters prüfen
Nutzt ein Unternehmen einen externen Dienst nach seinen Zwecken und Weisungen, kann der Anbieter personenbezogene Daten als Auftragsverarbeiter verarbeiten. Dann wird regelmäßig ein Vertrag nach Artikel 28 DSGVO benötigt. Die Bezeichnung im Vertrag entscheidet die Rollenfrage jedoch nicht allein. Nutzt ein Anbieter bestimmte Daten für eigene Zwecke oder bestimmt er wesentliche Mittel selbst, können insoweit andere oder zusätzliche Verantwortlichkeiten bestehen.
Deshalb sollten nicht nur ein Auftragsverarbeitungsvertrag, sondern auch Leistungsbeschreibung, Datenschutzhinweise, Sicherheitsdokumentation und tatsächliche Produkteinstellungen zusammen geprüft werden. Unterauftragnehmer, optionale Erweiterungen, verbundene Apps und Supportfunktionen können eigene Datenflüsse auslösen.
Datenübermittlungen und Speicherorte nachvollziehen
Werden personenbezogene Daten außerhalb des Europäischen Wirtschaftsraums verarbeitet oder zugänglich gemacht, sind zusätzlich die Anforderungen der Artikel 44 ff. DSGVO zu beachten. Entscheidend sind nicht nur der zugesagte Speicherort, sondern auch mögliche Fernzugriffe, Unterauftragnehmer, Supportleistungen und weitere Empfänger.
Eine bloße Aussage „EU-Hosting“ beantwortet diese Fragen nicht vollständig. Umgekehrt macht ein Drittlandbezug den Einsatz nicht automatisch unzulässig. Er verlangt eine tragfähige Übermittlungsgrundlage und – abhängig von Land, Daten und Zugriffsszenario – ergänzende Prüfung und Schutzmaßnahmen.
Daten minimieren und Funktionen begrenzen
Bevor Dokumente hochgeladen werden, sollte geprüft werden, ob Namen, Kontaktdaten, Fallnummern oder andere Identifikatoren überhaupt benötigt werden. Pseudonymisierung kann Risiken senken, hält die Daten aber grundsätzlich im Anwendungsbereich der DSGVO. Erst eine wirksame Anonymisierung führt aus diesem Anwendungsbereich heraus.
Auch Produktfunktionen gehören zur Datenminimierung. Speicherverlauf, Memory, Feedback, gemeinsam nutzbare Links, Konnektoren, Webzugriff und externe Aktionen können den Kreis der verarbeiteten Daten und Empfänger verändern. Nicht benötigte Funktionen sollten technisch begrenzt werden, soweit der gewählte Dienst dies ermöglicht.
Informationspflichten und Betroffenenrechte umsetzen
Je nach Datenquelle und Einsatz müssen betroffene Personen über die Verarbeitung informiert werden. Außerdem muss das Unternehmen Auskunft, Berichtigung, Löschung, Einschränkung und Widerspruch tatsächlich bearbeiten können. Das betrifft nicht nur die ursprünglichen Dokumente, sondern gegebenenfalls auch Protokolle, Vektordatenbanken und erzeugte personenbezogene Ausgaben.
Gerade bei RAG-Systemen können getrennte Referenzdokumente und Berechtigungskonzepte die Aktualisierung und Löschung erleichtern. Das Sprachmodell selbst bleibt jedoch technisch schwerer durchschaubar. Die Datenquelle sollte deshalb nicht nur vorhanden, sondern aktuell, überprüfbar und sauber vom Modellzugriff abgegrenzt sein.
Datenschutz-Folgenabschätzung nicht schematisch behandeln
Eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO ist erforderlich, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Nicht jeder Einsatz eines Textassistenten löst diese Pflicht aus. Bei systematischer Bewertung von Menschen, umfangreicher Verarbeitung sensibler Daten, neuen Überwachungs- oder Profilingverfahren und folgenreichen automatisierten Entscheidungen kann sie jedoch naheliegen.
Das Ergebnis sollte dokumentiert werden – ebenso die Gründe, wenn eine Folgenabschätzung nach einer Vorprüfung nicht erforderlich erscheint. Die Orientierungshilfen der Datenschutzkonferenz zu KI und Datenschutz sowie zu technischen und organisatorischen Maßnahmen für KI-Systeme bieten hierfür einen aufsichtsbehördlichen Rahmen.
Artikel 22 DSGVO ist gesondert zu prüfen, wenn ein System eine Entscheidung mit rechtlicher oder ähnlich erheblicher Wirkung ausschließlich automatisiert trifft. Nicht jede KI-Unterstützung erfüllt diesen Tatbestand. Eine zwischengeschaltete Person genügt aber nicht allein deshalb als menschliche Kontrolle, weil sie das Ergebnis formal bestätigen kann. Sie muss die Empfehlung nachvollziehen, eigenständig bewerten und tatsächlich ändern oder verwerfen können. Zu beachten sind insbesondere das Urteil des Europäischen Gerichtshofs im Verfahren SCHUFA, C-634/21 zu Artikel 22 sowie die Entscheidung Dun & Bradstreet Austria, C-203/22 zu aussagekräftigen Informationen über die Logik einer automatisierten Entscheidung.
Warum Dienst, Tarif und aktivierte Funktionen entscheidend sind
Auch innerhalb eines einzelnen Produktnamens können sich persönliche Konten, verwaltete Unternehmensbereiche, Programmierschnittstellen und integrierte Funktionen erheblich unterscheiden. ChatGPT, Claude, Microsoft Copilot und Gemini sind deshalb keine jeweils einheitlichen rechtlichen Kategorien. Zu prüfen ist die konkrete Leistung, die das Unternehmen tatsächlich bezieht und technisch freigibt.
Einen Ausgangspunkt bieten die aktuellen Anbieterinformationen zur geschäftlichen Datenverarbeitung, etwa von OpenAI für seine Business-Angebote und die API, von Anthropic für Claude for Work und die API, von Microsoft zum Schutz von Unternehmensdaten in Microsoft 365 Copilot und von Google zum Einsatz generativer KI in Google Workspace. Diese Angaben beziehen sich jeweils auf bestimmte Produkte, Tarife, Funktionen und Voraussetzungen. Sie müssen deshalb zusammen mit den im Zeitpunkt der Nutzung geltenden Verträgen, Datenschutzunterlagen und Systemeinstellungen geprüft werden.
Eine Anbieterinformation ist ein relevanter Prüfschritt, aber kein datenschutzrechtliches Gesamtergebnis. „Kein Training“ bedeutet nicht notwendig „keine Speicherung“, „keine Sicherheitsprüfung“ oder „keine Unterauftragnehmer“. Ebenso wenig ersetzt eine einzelne Einstellung einen Organisationsvertrag, ein Berechtigungskonzept oder die Prüfung der Rechtsgrundlage für die eingegebenen Daten. Maßgeblich bleiben der konkrete Tarif, die aktivierten Komponenten und der tatsächliche Datenfluss – nicht der Markenname.

Geschäftsgeheimnisse und vertrauliche Informationen schützen
Nicht jede vertrauliche Information ist personenbezogen. Quellcode, Kalkulationen, Produktpläne, Kundenvorgaben, Vertragskonditionen und interne Strategien können unabhängig von der DSGVO schutzbedürftig sein.
Nach § 2 Geschäftsgeheimnisgesetz setzt der gesetzliche Schutz eines Geschäftsgeheimnisses unter anderem voraus, dass die Information Gegenstand angemessener Geheimhaltungsmaßnahmen ist. Welche Maßnahmen angemessen sind, hängt von Wert, Sensibilität, Unternehmensgröße, Zugriffsmöglichkeiten und konkretem Risiko ab.
Für den KI-Einsatz können dazu gehören:
- eine nachvollziehbare Klassifizierung vertraulicher Informationen,
- die Beschränkung auf freigegebene Dienste und verwaltete Konten,
- vertragliche Vertraulichkeits- und Nutzungsregelungen mit dem Anbieter,
- Rollen- und Berechtigungskonzepte,
- Beschränkung von Konnektoren, Freigabelinks und Datenexporten,
- Protokollierung sicherheitsrelevanter Vorgänge,
- klare Regeln für Kundenunterlagen, Quellcode und Zugangsdaten,
- Schulung und dokumentierte Reaktion auf Fehlübermittlungen.
Ein Auftragsverarbeitungsvertrag schützt nur personenbezogene Daten innerhalb seines Anwendungsbereichs. Für Geschäftsgeheimnisse, reine Unternehmensdaten und vertraglich vertrauliche Informationen müssen Leistungs- und Geheimhaltungsregeln gesondert passen. Bestehende NDAs oder Kundenverträge können die Weitergabe an Unterauftragnehmer oder externe KI-Dienste zusätzlich begrenzen.
Was der EU AI Act für den betrieblichen Einsatz generativer KI bedeutet
Ein Unternehmen, das einen fremden KI-Dienst unter eigener Verantwortung nutzt, ist nach dem EU AI Act regelmäßig Betreiber – in der deutschen Fassung der Verordnung „Betreiber“, im englischen Text „deployer“. Beschäftigte, die das System unter Weisung und Kontrolle des Unternehmens bedienen, werden dadurch nicht jeweils selbst zu Betreibern. Wer ein System unter eigenem Namen anbietet, seine Zweckbestimmung ändert oder es wesentlich verändert, kann dagegen in eine Anbieterrolle gelangen. Die Rolle ist für jeden Einsatz gesondert zu bestimmen.
KI-Kompetenz muss zum Einsatz passen
Anbieter und Betreiber müssen seit dem 2. Februar 2025 Maßnahmen ergreifen, um die Entwicklung von KI-Kompetenz bei Beschäftigten und anderen Personen zu unterstützen, die in ihrem Auftrag mit KI-Systemen umgehen. Die im Juli 2026 geänderte Fassung von Artikel 4 verlangt nicht, bei jeder Person ein bestimmtes Kompetenzniveau zu garantieren. Sie verlangt aber weiterhin angemessene Maßnahmen unter Berücksichtigung von Vorwissen, Erfahrung, Einsatzkontext und betroffenen Personengruppen. Das folgt aus der Änderungsverordnung (EU) 2026/1744. Eine allgemeine Schulung genügt deshalb nicht automatisch für sämtliche Anwendungen: Wer öffentliche Texte glättet, benötigt andere Kenntnisse als Beschäftigte, die einen Kunden-Chatbot betreuen, personenbezogene Daten auswerten oder KI in Personalprozessen einsetzen. Richtlinie, Schulung und technische Freigaben sollten zusammenpassen.
Transparenz und besondere Risikofälle gesondert einordnen
Die Transparenzpflichten des Artikels 50 gelten seit dem 2. August 2026. Daraus folgt keine allgemeine Pflicht, jeden intern erstellten Entwurf oder jeden KI-unterstützten Geschäftstext zu kennzeichnen. Relevant sind insbesondere die Information natürlicher Personen bei direkter Interaktion mit bestimmten KI-Systemen, die Offenlegung von Deepfakes sowie unter näheren Voraussetzungen KI-generierte oder manipulierte Texte, die veröffentlicht werden, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren. Für solche Texte sieht die Verordnung eine Ausnahme vor, wenn eine inhaltlich substanzielle menschliche Überprüfung oder redaktionelle Kontrolle stattfindet und eine natürliche oder juristische Person die redaktionelle Verantwortung trägt. Die Leitlinien der Europäischen Kommission zu Artikel 50 ordnen Anwendungsbereich und Ausnahmen näher ein.
Für Anbieter generativer Systeme bestehen daneben technische Markierungspflichten. Systeme, die bereits vor dem 2. August 2026 in Verkehr gebracht wurden, erhalten hierfür nach der Änderung von 2026 eine Übergangsfrist bis zum 2. Dezember 2026. Ob ein Unternehmen selbst Adressat einer Kennzeichnungs- oder Informationspflicht ist, hängt von seiner Rolle und dem konkreten Output ab.
Ein allgemeiner KI-Assistent wird nicht allein aufgrund seiner technischen Leistungsfähigkeit zum Hochrisiko-System. Systeme für Einstellung, Auswahl, Aufgabenzuweisung, Leistungsbewertung oder Beendigung von Arbeitsverhältnissen können dagegen unter die Hochrisiko-Fälle des Anhangs III fallen. Die besonderen Hochrisiko-Regeln für diese Fälle gelten nach der im Juli 2026 beschlossenen Verschiebung grundsätzlich ab dem 2. Dezember 2027; DSGVO, AGG und Betriebsverfassungsrecht sind bereits heute zu beachten. Gleiches gilt für bereits anwendbare Verbote, etwa die grundsätzlich untersagte Emotionserkennung am Arbeitsplatz außerhalb enger medizinischer oder sicherheitsbezogener Ausnahmen.
Für den Vollzug in Deutschland gilt seit dem 29. Juli 2026 das KI-Marktüberwachungs- und Innovationsförderungsgesetz. Die Bundesnetzagentur übernimmt danach die zentrale Koordinierung und grundsätzlich Aufgaben der Marktüberwachung; zuständige Fach- und Sektorbehörden bleiben daneben eingebunden. Die vollständige Rollen-, Fristen-, Risiko- und Sanktionssystematik erläutert der Hauptbeitrag zum EU AI Act für Unternehmen.
Beschäftigte, Shadow AI und Betriebsrat
Wenn ein Unternehmen kein nutzbares Verfahren vorgibt, weichen Beschäftigte häufig auf persönliche Konten aus. Ein bloßes Verbot verhindert diese „Shadow AI“ nicht zuverlässig. Sinnvoller ist eine Kombination aus freigegebenen Werkzeugen, verständlichen Datenregeln, konkreten Beispielen, technischen Beschränkungen und erreichbaren Eskalationswegen.
Besteht ein Betriebsrat, sollte er frühzeitig einbezogen werden. Nach § 90 BetrVG ist er über die Planung von Arbeitsverfahren und Arbeitsabläufen einschließlich des Einsatzes künstlicher Intelligenz rechtzeitig zu unterrichten und zu beraten. Ein Mitbestimmungsrecht nach § 87 Absatz 1 Nummer 6 BetrVG kann bestehen, wenn eine technische Einrichtung dazu bestimmt ist, Verhalten oder Leistung von Beschäftigten zu überwachen. Für Auswahlrichtlinien mit KI enthält § 95 Absatz 2a BetrVG eine ausdrückliche Regelung.
Ob eine konkrete Funktion diese Rechte auslöst, hängt von ihrer Ausgestaltung ab. Nutzungsstatistiken, Inhaltszugriffe, Leistungsanalysen und administrative Einsichtsmöglichkeiten sollten deshalb vor dem Rollout geklärt werden – nicht erst, wenn das System bereits Daten erzeugt.
Warum menschliche Kontrolle mehr als Gegenlesen bedeutet
LLMs erzeugen sprachlich plausible Ergebnisse, ohne deren Wahrheit oder rechtliche Tragfähigkeit zu gewährleisten. Auch ein mit internen Dokumenten verbundenes RAG-System kann veraltete Quellen auswählen, Zusammenhänge unvollständig erfassen oder zusätzliche Inhalte des Grundmodells einfließen lassen.
Die Kontrolltiefe sollte sich nach Bedeutung und Außenwirkung richten:
- Ein interner Ideenvorschlag verlangt eine andere Prüfung als eine veröffentlichte Tatsachenbehauptung.
- Eine Formulierungshilfe ist anders zu behandeln als eine Entscheidung über Kunden, Beschäftigte oder Vertragspflichten.
- Generierter Programmcode benötigt neben einer Funktionsprüfung regelmäßig Sicherheits-, Herkunfts- und Lizenzkontrollen.
- Wer einem Kunden eine bestimmte Qualität, Vertraulichkeit oder Exklusivität schuldet, muss diese Zusage auch bei KI-Unterstützung erfüllen können.
„Human in the loop“ ist nur belastbar, wenn die prüfende Person fachlich geeignet ist, die maßgeblichen Informationen erhält, ausreichend Zeit hat und das Ergebnis tatsächlich ändern oder verwerfen kann. Eine rein formale Bestätigung reduziert das Risiko nicht verlässlich.
Urheberrechtliche Fragen zu fremdem Input, Schutzfähigkeit, Übernahmen und kommerzieller Verwertung behandelt der Beitrag KI und Urheberrecht für Unternehmen.
Was in Verträgen mit KI-Anbietern geprüft werden sollte
Ein Anbietercheck sollte nicht bei der Frage enden, ob Daten zum Modelltraining verwendet werden. Für Unternehmen sind insbesondere folgende Punkte relevant:
- genaue Bezeichnung von Dienst, Tarif und einbezogenen Funktionen,
- erlaubte betriebliche Nutzungszwecke und ausgeschlossene Anwendungsfälle,
- Rollen nach Datenschutzrecht und Inhalt des Auftragsverarbeitungsvertrags,
- Speicherfristen, Löschung, Export und Rückgabe von Unternehmensdaten,
- Modelltraining, Feedback, Missbrauchskontrolle und sonstige eigene Nutzungszwecke,
- Unterauftragnehmer, Datenstandorte und Drittlandzugriffe,
- Mandantentrennung, Verschlüsselung, Berechtigungen und Protokollierung,
- Umgang mit Sicherheitsvorfällen und Unterstützung bei Betroffenenanfragen,
- Rechte an Eingaben und Ausgaben sowie Umgang mit Ansprüchen Dritter,
- Verfügbarkeit, Leistungsänderungen und Wechsel des zugrunde liegenden Modells,
- Haftungsgrenzen, Freistellungen und Ausschlüsse,
- Kündigung, Anbieterwechsel und Entfernung angebundener Datenquellen.
Bei Konnektoren und KI-Agenten muss zusätzlich geklärt werden, ob das System nur Informationen liest oder selbst Aktionen auslösen darf. Der Zugriff auf E-Mail, Cloudspeicher, CRM, Quellcode oder Kalender kann aus einer einzelnen Chatfunktion einen weitreichenden Geschäftsprozess machen.
Solche Verbindungen erhöhen auch das Risiko indirekter Prompt-Injection: Manipulierte Inhalte in Webseiten, E-Mails oder Dokumenten können versuchen, Systemanweisungen zu überschreiben, Daten offenzulegen oder Aktionen auszulösen. Schreibrechte und Zugang zu sensiblen Daten sollten deshalb nach dem Least-Privilege-Prinzip begrenzt, kritische Aktionen gesondert bestätigt und Ein- sowie Ausgaben angemessen überwacht werden. Das Bundesamt für Sicherheit in der Informationstechnik weist auf diese Angriffsform und mögliche Schutzmaßnahmen hin.
Allgemeine Hinweise zu Leistungsbeschreibung, Auftragsverarbeitung, Haftung und Exit finden sich im Beitrag zur Vertragsgestaltung mit IT-Dienstleistern.
Neun Bausteine einer betrieblichen KI-Richtlinie
Eine KI-Richtlinie sollte die tatsächlichen Systeme und Arbeitsabläufe des Unternehmens abbilden. Eine allgemeine Musterregel, die weder Tarife noch Datenklassen oder Verantwortliche kennt, schafft häufig nur scheinbare Klarheit.
- Geltungsbereich: Welche Beschäftigten, Gesellschaften, Endgeräte und Arten von KI-Systemen sind erfasst?
- Freigegebene Dienste: Welche Produkte, Tarife, Konten und Funktionen dürfen genutzt werden?
- Zulässige Zwecke: Für welche Aufgaben ist der Einsatz freigegeben, eingeschränkt oder untersagt?
- Datenregeln: Welche öffentlichen, internen, vertraulichen und personenbezogenen Daten dürfen eingegeben werden?
- Kunden- und Drittmaterial: Welche Vertrags-, Urheber- und Geheimhaltungspflichten sind vor einem Upload zu prüfen?
- Outputkontrolle: Wer prüft Tatsachen, Qualität, Rechte, Diskriminierungsrisiken und Sicherheit?
- Freigabe und Eskalation: Welche Ergebnisse benötigen eine fachliche, rechtliche oder sicherheitsbezogene Prüfung?
- Dokumentation und Vorfälle: Was wird nachvollziehbar festgehalten und wie werden Fehlübermittlungen oder problematische Outputs gemeldet?
- Schulung und Aktualisierung: Welche rollenbezogenen Kenntnisse werden vermittelt und wer prüft Änderungen an Diensten, Verträgen und Einsatzfällen?
Die Richtlinie sollte mit Datenschutzkonzept, Informationssicherheit, Vertragsmanagement und bestehenden Freigabeprozessen verbunden werden. Sie ist kein Ersatz für technische Einstellungen. Umgekehrt verhindern Administrationsfunktionen allein nicht, dass ein zulässiger Dienst für einen unzulässigen Zweck verwendet wird.
Häufige Fragen zum Einsatz generativer KI im Unternehmen
Gelten für ChatGPT, Claude, Microsoft Copilot und Gemini dieselben rechtlichen Anforderungen?
Für alle Dienste gelten grundsätzlich dieselben einschlägigen Rechtsgebiete, insbesondere Datenschutz-, Vertrags-, Geschäftsgeheimnis-, Urheber- und Arbeitsrecht sowie der EU AI Act. Daraus folgt aber nicht für jeden Dienst dasselbe Ergebnis. Entscheidend sind das konkrete Produkt und der Tarif, aktivierte Funktionen und Konnektoren, die verarbeiteten Daten, der betriebliche Zweck sowie die jeweils geltenden Anbieterunterlagen.
Reicht ein Business- oder Enterprise-Tarif für die betriebliche Freigabe aus?
Nein. Ein solcher Tarif kann zentrale Nutzerverwaltung, vertragliche Zusagen und geeignetere Datenkontrollen bieten. Das Unternehmen muss trotzdem für jeden freigegebenen Anwendungsfall unter anderem Rechtsgrundlage, Geheimhaltung, Rechte an den Eingaben, Drittlandbezüge, Speicherfristen und erforderliche Ergebniskontrollen prüfen. Die Freigabe sollte deshalb Dienst, Tarif, Funktionen, Datenklassen und zulässige Zwecke benennen.
Werden keine Daten mehr verarbeitet, wenn Modelltraining ausgeschlossen ist?
Doch. Auch ohne Verwendung für das Modelltraining können Ein- und Ausgaben gespeichert, sicherheitsbezogen kontrolliert, protokolliert oder im Supportfall verarbeitet werden. Unterauftragnehmer, Konnektoren und angebundene Funktionen können weitere Datenflüsse auslösen. Die Aussage zum Training ist daher nur ein Teil der Anbieterprüfung.
Reicht es für eine Anonymisierung aus, Namen und Kontaktdaten zu entfernen?
Nicht zwingend. Eine Person kann auch aus der Kombination von Funktion, Vorgang, Ort, Zeitraum oder Vertragsdetails identifizierbar sein. Werden Zuordnungsmerkmale lediglich ersetzt oder getrennt aufbewahrt, liegt regelmäßig eine Pseudonymisierung und keine Anonymisierung vor. Ob Daten tatsächlich anonym sind, muss anhand des gesamten Kontextes und der realistischen Identifizierungsmöglichkeiten beurteilt werden.
Verhindert ein RAG-System unrichtige oder erfundene Antworten?
Nein. Eine angebundene Wissensbasis kann Quellenbezug und Aktualität verbessern, beseitigt aber Auswahlfehler, unvollständige oder veraltete Dokumente und Einflüsse des Grundmodells nicht. Zusätzlich müssen Zugriffsrechte, Löschung, Aktualisierung und die Übermittlung gefundener Textabschnitte an weitere Systemkomponenten kontrolliert werden. Fachlich relevante Ausgaben benötigen deshalb weiterhin eine angemessene Prüfung.
Muss jeder mit generativer KI erstellte oder überarbeitete Text gekennzeichnet werden?
Nein. Artikel 50 des EU AI Act enthält bestimmte Informations- und Offenlegungspflichten, aber keine allgemeine Kennzeichnungspflicht für sämtliche internen Entwürfe oder geschäftlichen Texte. Ob ein Hinweis erforderlich ist, hängt insbesondere von Rolle, Einsatzform, Adressaten und Inhalt ab. Vertragliche Transparenzpflichten oder Vorgaben einer Plattform können unabhängig davon hinzukommen.
Beseitigt eine menschliche Freigabe die rechtlichen Risiken des KI-Einsatzes?
Nein. Eine Freigabe wirkt nur, wenn die prüfende Person fachlich geeignet ist, die entscheidenden Informationen kennt, ausreichend Zeit erhält und das Ergebnis tatsächlich ändern oder verwerfen kann. Umfang und Dokumentation der Kontrolle müssen zur möglichen Wirkung des Outputs passen. Eine bloß formale Bestätigung macht eine fehlerhafte oder rechtsverletzende Ausgabe nicht belastbar.
Was Unternehmen vor der Einführung dokumentieren sollten
Ein verhältnismäßiger Einführungsprozess kann in dieser Reihenfolge aufgebaut werden:
- Anwendungsfälle und wirtschaftlichen Zweck beschreiben.
- Eingaben, Ausgaben, Nutzer und betroffene Personen erfassen.
- Datenklassen und Geheimhaltungsanforderungen zuordnen.
- Dienst, Tarif, Funktionen und technische Datenflüsse dokumentieren.
- Anbieterrollen, Verträge, Unterauftragnehmer und Transfers prüfen.
- Rechtsgrundlagen, Informationspflichten und eine mögliche Datenschutz-Folgenabschätzung bewerten.
- AI-Act-Rolle, Transparenzpflichten und besondere Risikofälle einordnen.
- Betriebsrat und weitere interne Stellen rechtzeitig beteiligen.
- Freigaben, menschliche Kontrolle und Eskalationsfälle festlegen.
- Richtlinie, Schulung und technische Administration umsetzen.
- Änderungen an Modellen, Funktionen, Verträgen und Anwendungsfällen fortlaufend überwachen.
Dieser Prüfpfad schafft die Tatsachengrundlage. Ob bestimmte Kundenunterlagen, Beschäftigtendaten oder Fachprozesse in einem konkreten Dienst verarbeitet werden können, hängt von den jeweiligen Daten, Verträgen, Systemeinstellungen und Schutzmaßnahmen ab.
Wann eine individuelle Prüfung sinnvoll ist
Eine gesonderte rechtliche und vertragliche Einordnung ist insbesondere sinnvoll, wenn:
- personenbezogene Kunden- oder Beschäftigtendaten verarbeitet werden,
- besondere Datenkategorien, Berufsgeheimnisse oder zentrale Geschäftsgeheimnisse betroffen sind,
- ein KI-Dienst an CRM, E-Mail, Cloudspeicher, Quellcode oder interne Wissensbestände angebunden wird,
- ein RAG-System, Fine-Tuning oder eine eigene KI-Anwendung aufgebaut wird,
- Ausgaben Entscheidungen über Personen vorbereiten oder beeinflussen,
- ein Kunden-Chatbot oder eine generative Funktion im eigenen Produkt angeboten wird,
- der Betriebsrat zu beteiligen ist,
- gegenüber Kunden bestimmte Rechte, Vertraulichkeit oder Qualität zugesagt werden,
- Anbieterbedingungen, Datenübermittlungen oder Haftung unklar bleiben.
Für eine erste Prüfung sind regelmäßig eine Liste der geplanten Anwendungsfälle, die eingesetzten Produkte und Tarife, eine Skizze der Datenflüsse, Anbieter- und Datenschutzunterlagen, die betroffenen Datenklassen sowie die vorgesehenen Kontroll- und Freigabeschritte erforderlich. Ich ordne auf dieser Grundlage Rollen und Pflichten ein und prüfe, wie Anbieterbedingungen, interne KI-Richtlinie und tatsächlicher Einsatz zusammengeführt werden können.
Unterlagen und eine kurze Beschreibung des vorgesehenen Einsatzes können über die Kontaktseite übermittelt werden. Hinweise zu allgemeinen Datenschutzprozessen finden sich außerdem im Bereich Datenschutzrecht für Unternehmen; rollenbezogene Formate sind auf der Seite zu KI- und Datenschutzschulungen beschrieben.
Amtliche Quellen und weiterführende Hinweise
- Datenschutz-Grundverordnung
- Datenschutzkonferenz: Orientierungshilfe „Künstliche Intelligenz und Datenschutz“
- Datenschutzkonferenz: Technische und organisatorische Maßnahmen bei KI-Systemen
- Datenschutzkonferenz: Datenschutzrechtliche Besonderheiten von RAG-Systemen
- Europäischer Datenschutzausschuss: Opinion 28/2024 zu KI-Modellen
- Verordnung (EU) 2024/1689 – EU AI Act
- Verordnung (EU) 2026/1744 – Digital Omnibus on AI
- Europäische Kommission: Fragen und Antworten zur KI-Kompetenz
- Europäische Kommission: Leitlinien zu den Transparenzpflichten nach Artikel 50
- Bundesregierung: KI-Marktüberwachungs- und Innovationsförderungsgesetz
- Geschäftsgeheimnisgesetz
- Betriebsverfassungsgesetz
- BSI: Indirekte Prompt-Injection bei integrierten Sprachmodellen
Kurzantwort: Generative KI ist weder pauschal DSGVO-konform noch generell unzulässig
Ein KI-Dienst ist nicht allein aufgrund seines Produktnamens datenschutzkonform. Umgekehrt verbietet die Datenschutz-Grundverordnung den betrieblichen Einsatz generativer KI nicht generell.
Vor einer Freigabe sollten Unternehmen sechs Punkte klären:
- Anwendungszweck: Welche konkrete Aufgabe soll das System übernehmen oder unterstützen?
- Datenklasse: Welche personenbezogenen, vertraulichen oder geschützten Inhalte gelangen in das System?
- Dienst und Tarif: Wird ein persönlicher Chatdienst, ein verwalteter Business-Arbeitsbereich, eine API oder ein eigenes System eingesetzt?
- Anbieterbeziehung: Welche Rollen, Unterauftragnehmer, Speicherfristen, Trainingsnutzungen und Drittlandübermittlungen bestehen?
- Betriebliche Regeln: Wer darf das Tool wofür nutzen und wann ist eine Freigabe erforderlich?
- Kontrolle des Ergebnisses: Wer prüft Richtigkeit, Rechte Dritter und Eignung für die vorgesehene Nutzung?
Ein Business- oder Enterprise-Tarif kann durch zentrale Administration, angepasste Datenverwendung und zusätzliche Vertragsunterlagen bessere Voraussetzungen schaffen. Er ersetzt aber weder die Rechtsgrundlage für die eingegebenen Daten noch die Prüfung des konkreten Anwendungsfalls.

Welcher technische Einsatz liegt tatsächlich vor?
Unter dem betrieblichen Einsatz generativer KI werden sehr unterschiedliche technische und vertragliche Konstellationen zusammengefasst. Für die rechtliche Einordnung ist diese Unterscheidung zentral.
Einsatzform: Persönlicher Cloud-Chatdienst
Typische Merkmale: individuelles Konto, persönliche Einstellungen, kaum zentrale Kontrolle
Zentrale Prüffragen: Ist die betriebliche Nutzung gestattet? Welche Daten werden gespeichert oder für Modellverbesserungen verwendet? Kann das Unternehmen Zugriffe, Löschung und Ausscheiden von Beschäftigten steuern?
Einsatzform: Verwalteter Business-Arbeitsbereich
Typische Merkmale: Organisationsvertrag, zentrale Nutzerverwaltung, geschäftliche Datenschutz- und Sicherheitsfunktionen
Zentrale Prüffragen: Passen Vertrag, Auftragsverarbeitung, Unterauftragnehmer, Speicherfristen und Administration zum Anwendungsfall? Welche Funktionen können Daten an weitere Dienste übertragen?
Einsatzform: API oder integrierter Assistent
Typische Merkmale: Einbindung in eigene Software, Fachanwendung oder automatisierten Ablauf
Zentrale Prüffragen: Welche Systemkomponente erhält welche Daten? Wo entstehen Protokolle und Zwischenspeicher? Wer bestimmt Zwecke, Oberfläche und Ausgabe?
Einsatzform: RAG-System mit interner Wissensbasis
Typische Merkmale: Referenzdokumente werden gesucht und dem Modell bei der Anfrage als Kontext bereitgestellt
Zentrale Prüffragen: Wer darf auf welche Dokumente und Textabschnitte zugreifen? Sind Daten aktuell, erforderlich und löschbar? Welche externen Modelle, Embeddings oder Datenbanken sind beteiligt?
Einsatzform: Eigenes oder selbst betriebenes Modell
Typische Merkmale: größere technische Kontrolle, eigene Infrastruktur oder Open-Weight-Modell
Zentrale Prüffragen: Wer trägt Verantwortung für Entwicklung, Sicherheit, Trainingsdaten, Modellpflege und Betroffenenrechte? Entstehen Anbieterpflichten nach dem AI Act?
RAG steht für „Retrieval-Augmented Generation“. Dabei wird ein Sprachmodell mit einer gesonderten Wissensbasis verbunden. Das kann Quellenbezug, Aktualisierung und Zugriffskontrolle verbessern. Es ändert aber weder nachträglich die Trainingsdaten des Grundmodells noch beseitigt es die datenschutzrechtliche Prüfung. Die Datenschutzkonferenz erläutert diese Unterschiede in ihrer Orientierungshilfe zu RAG-Systemen.
Vor dem Tool kommt der Anwendungsfall
Eine allgemeine Freigabe „für Büroarbeiten“ ist meist zu unbestimmt. Die rechtlichen Anforderungen unterscheiden sich erheblich danach, ob ein System lediglich einen öffentlichen Produkttext sprachlich glättet, vertrauliche Kundenunterlagen auswertet oder Bewerber vorsortiert.
Betrieblicher Anwendungsfall: Sprachliche Überarbeitung bereits veröffentlichter Produktinformationen
Typischer Prüfbedarf: Freigegebener Dienst, Qualitätskontrolle, Prüfung werblicher Aussagen und Rechte am Output
Betrieblicher Anwendungsfall: Entwurf einer Kundenantwort nach Entfernung identifizierender Angaben
Typischer Prüfbedarf: Wirksame Anonymisierung oder Datenminimierung, Vertraulichkeit, menschliche Prüfung vor Versand
Betrieblicher Anwendungsfall: Zusammenfassung eines Kundenvertrags mit Namen, Konditionen und Geschäftsdetails
Typischer Prüfbedarf: Rechtsgrundlage, Auftragsverarbeitung, Geheimhaltung, Anbieterfunktionen, Speicher- und Löschkonzept
Betrieblicher Anwendungsfall: Coding-Assistent mit Zugriff auf internes Repository
Typischer Prüfbedarf: Rechte am Quellcode, Geschäftsgeheimnisse, Zugriffsrechte, Protokollierung, Sicherheits- und Lizenzprüfung des Outputs
Betrieblicher Anwendungsfall: Interne Wissenssuche über Personal-, Support- oder Projektdokumente
Typischer Prüfbedarf: Berechtigungskonzept, Zweckbindung, Datenqualität, RAG-Architektur, Löschung und Betroffenenrechte
Betrieblicher Anwendungsfall: Bewertung von Bewerbern oder Beschäftigten
Typischer Prüfbedarf: Datenschutz, AGG, Mitbestimmung, automatisierte Entscheidungen und mögliche Hochrisiko-Einstufung nach dem AI Act
Betrieblicher Anwendungsfall: Kunden-Chatbot auf der Webseite oder im Produkt
Typischer Prüfbedarf: Rollenverteilung, Datenschutzhinweise, Interaktionshinweis, Wissensbasis, Eskalation an Menschen und vertragliche Leistungszusagen
Diese Beispiele sind keine pauschalen Freigaben. Sie zeigen, welche Tatsachen eine belastbare Einordnung benötigt.
Personenbezogene Daten: Welche Verarbeitung findet statt?
Sobald Prompts, hochgeladene Dateien, Nutzungsprotokolle oder Ausgaben Informationen über identifizierte oder identifizierbare Personen enthalten, gilt die Datenschutz-Grundverordnung. Dabei sind nicht nur Kundendaten relevant. Auch Namen in Verträgen, E-Mail-Inhalte, Beschäftigtendaten, Supporttickets, Benutzerkennungen und vom Modell erzeugte Aussagen über Personen können personenbezogene Daten sein.
Zweck und Rechtsgrundlage festlegen
Das Unternehmen muss bestimmen, wofür es die Daten durch das KI-System verarbeiten lässt. Eine Rechtsgrundlage, die das Speichern eines Vertrags in der eigenen Ablage trägt, erlaubt nicht automatisch dessen Übermittlung an einen externen KI-Anbieter oder dessen Nutzung für einen neuen Analysezweck.
Je nach Anwendungsfall kommen insbesondere Vertragserfüllung, eine gesetzliche Pflicht oder berechtigte Interessen in Betracht. Ein berechtigtes Interesse ist kein pauschaler Auffangtatbestand. Erforderlich sind ein legitimes Ziel, die Erforderlichkeit der Verarbeitung und eine Abwägung mit den Rechten der betroffenen Personen. Bei Beschäftigtendaten sowie besonderen Datenkategorien – etwa Gesundheitsdaten – gelten zusätzliche Anforderungen.
Der Europäische Datenschutzausschuss betont für KI-Modelle eine einzelfallbezogene Prüfung. Ob ein Modell als anonym angesehen werden kann, hängt unter anderem davon ab, wie wahrscheinlich eine Identifizierung oder Extraktion personenbezogener Trainingsdaten ist. Auch die Nutzung berechtigter Interessen ist anhand eines dreistufigen Tests zu beurteilen.
Rollen des Unternehmens und des Anbieters prüfen
Nutzt ein Unternehmen einen externen Dienst nach seinen Zwecken und Weisungen, kann der Anbieter personenbezogene Daten als Auftragsverarbeiter verarbeiten. Dann wird regelmäßig ein Vertrag nach Artikel 28 DSGVO benötigt. Die Bezeichnung im Vertrag entscheidet die Rollenfrage jedoch nicht allein. Nutzt ein Anbieter bestimmte Daten für eigene Zwecke oder bestimmt er wesentliche Mittel selbst, können insoweit andere oder zusätzliche Verantwortlichkeiten bestehen.
Deshalb sollten nicht nur ein Auftragsverarbeitungsvertrag, sondern auch Leistungsbeschreibung, Datenschutzhinweise, Sicherheitsdokumentation und tatsächliche Produkteinstellungen zusammen geprüft werden. Unterauftragnehmer, optionale Erweiterungen, verbundene Apps und Supportfunktionen können eigene Datenflüsse auslösen.
Datenübermittlungen und Speicherorte nachvollziehen
Werden personenbezogene Daten außerhalb des Europäischen Wirtschaftsraums verarbeitet oder zugänglich gemacht, sind zusätzlich die Anforderungen der Artikel 44 ff. DSGVO zu beachten. Entscheidend sind nicht nur der zugesagte Speicherort, sondern auch mögliche Fernzugriffe, Unterauftragnehmer, Supportleistungen und weitere Empfänger.
Eine bloße Aussage „EU-Hosting“ beantwortet diese Fragen nicht vollständig. Umgekehrt macht ein Drittlandbezug den Einsatz nicht automatisch unzulässig. Er verlangt eine tragfähige Übermittlungsgrundlage und – abhängig von Land, Daten und Zugriffsszenario – ergänzende Prüfung und Schutzmaßnahmen.
Daten minimieren und Funktionen begrenzen
Bevor Dokumente hochgeladen werden, sollte geprüft werden, ob Namen, Kontaktdaten, Fallnummern oder andere Identifikatoren überhaupt benötigt werden. Pseudonymisierung kann Risiken senken, hält die Daten aber grundsätzlich im Anwendungsbereich der DSGVO. Erst eine wirksame Anonymisierung führt aus diesem Anwendungsbereich heraus.
Auch Produktfunktionen gehören zur Datenminimierung. Speicherverlauf, Memory, Feedback, gemeinsam nutzbare Links, Konnektoren, Webzugriff und externe Aktionen können den Kreis der verarbeiteten Daten und Empfänger verändern. Nicht benötigte Funktionen sollten technisch begrenzt werden, soweit der gewählte Dienst dies ermöglicht.
Informationspflichten und Betroffenenrechte umsetzen
Je nach Datenquelle und Einsatz müssen betroffene Personen über die Verarbeitung informiert werden. Außerdem muss das Unternehmen Auskunft, Berichtigung, Löschung, Einschränkung und Widerspruch tatsächlich bearbeiten können. Das betrifft nicht nur die ursprünglichen Dokumente, sondern gegebenenfalls auch Protokolle, Vektordatenbanken und erzeugte personenbezogene Ausgaben.
Gerade bei RAG-Systemen können getrennte Referenzdokumente und Berechtigungskonzepte die Aktualisierung und Löschung erleichtern. Das Sprachmodell selbst bleibt jedoch technisch schwerer durchschaubar. Die Datenquelle sollte deshalb nicht nur vorhanden, sondern aktuell, überprüfbar und sauber vom Modellzugriff abgegrenzt sein.
Datenschutz-Folgenabschätzung nicht schematisch behandeln
Eine Datenschutz-Folgenabschätzung nach Artikel 35 DSGVO ist erforderlich, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Nicht jeder Einsatz eines Textassistenten löst diese Pflicht aus. Bei systematischer Bewertung von Menschen, umfangreicher Verarbeitung sensibler Daten, neuen Überwachungs- oder Profilingverfahren und folgenreichen automatisierten Entscheidungen kann sie jedoch naheliegen.
Das Ergebnis sollte dokumentiert werden – ebenso die Gründe, wenn eine Folgenabschätzung nach einer Vorprüfung nicht erforderlich erscheint. Die Orientierungshilfen der Datenschutzkonferenz zu KI und Datenschutz sowie zu technischen und organisatorischen Maßnahmen für KI-Systeme bieten hierfür einen aufsichtsbehördlichen Rahmen.
Artikel 22 DSGVO ist gesondert zu prüfen, wenn ein System eine Entscheidung mit rechtlicher oder ähnlich erheblicher Wirkung ausschließlich automatisiert trifft. Nicht jede KI-Unterstützung erfüllt diesen Tatbestand. Eine zwischengeschaltete Person genügt aber nicht allein deshalb als menschliche Kontrolle, weil sie das Ergebnis formal bestätigen kann. Sie muss die Empfehlung nachvollziehen, eigenständig bewerten und tatsächlich ändern oder verwerfen können. Zu beachten sind insbesondere das Urteil des Europäischen Gerichtshofs im Verfahren SCHUFA, C-634/21 zu Artikel 22 sowie die Entscheidung Dun & Bradstreet Austria, C-203/22 zu aussagekräftigen Informationen über die Logik einer automatisierten Entscheidung.
Warum Dienst, Tarif und aktivierte Funktionen entscheidend sind
Auch innerhalb eines einzelnen Produktnamens können sich persönliche Konten, verwaltete Unternehmensbereiche, Programmierschnittstellen und integrierte Funktionen erheblich unterscheiden. ChatGPT, Claude, Microsoft Copilot und Gemini sind deshalb keine jeweils einheitlichen rechtlichen Kategorien. Zu prüfen ist die konkrete Leistung, die das Unternehmen tatsächlich bezieht und technisch freigibt.
Einen Ausgangspunkt bieten die aktuellen Anbieterinformationen zur geschäftlichen Datenverarbeitung, etwa von OpenAI für seine Business-Angebote und die API, von Anthropic für Claude for Work und die API, von Microsoft zum Schutz von Unternehmensdaten in Microsoft 365 Copilot und von Google zum Einsatz generativer KI in Google Workspace. Diese Angaben beziehen sich jeweils auf bestimmte Produkte, Tarife, Funktionen und Voraussetzungen. Sie müssen deshalb zusammen mit den im Zeitpunkt der Nutzung geltenden Verträgen, Datenschutzunterlagen und Systemeinstellungen geprüft werden.
Eine Anbieterinformation ist ein relevanter Prüfschritt, aber kein datenschutzrechtliches Gesamtergebnis. „Kein Training“ bedeutet nicht notwendig „keine Speicherung“, „keine Sicherheitsprüfung“ oder „keine Unterauftragnehmer“. Ebenso wenig ersetzt eine einzelne Einstellung einen Organisationsvertrag, ein Berechtigungskonzept oder die Prüfung der Rechtsgrundlage für die eingegebenen Daten. Maßgeblich bleiben der konkrete Tarif, die aktivierten Komponenten und der tatsächliche Datenfluss – nicht der Markenname.

Geschäftsgeheimnisse und vertrauliche Informationen schützen
Nicht jede vertrauliche Information ist personenbezogen. Quellcode, Kalkulationen, Produktpläne, Kundenvorgaben, Vertragskonditionen und interne Strategien können unabhängig von der DSGVO schutzbedürftig sein.
Nach § 2 Geschäftsgeheimnisgesetz setzt der gesetzliche Schutz eines Geschäftsgeheimnisses unter anderem voraus, dass die Information Gegenstand angemessener Geheimhaltungsmaßnahmen ist. Welche Maßnahmen angemessen sind, hängt von Wert, Sensibilität, Unternehmensgröße, Zugriffsmöglichkeiten und konkretem Risiko ab.
Für den KI-Einsatz können dazu gehören:
- eine nachvollziehbare Klassifizierung vertraulicher Informationen,
- die Beschränkung auf freigegebene Dienste und verwaltete Konten,
- vertragliche Vertraulichkeits- und Nutzungsregelungen mit dem Anbieter,
- Rollen- und Berechtigungskonzepte,
- Beschränkung von Konnektoren, Freigabelinks und Datenexporten,
- Protokollierung sicherheitsrelevanter Vorgänge,
- klare Regeln für Kundenunterlagen, Quellcode und Zugangsdaten,
- Schulung und dokumentierte Reaktion auf Fehlübermittlungen.
Ein Auftragsverarbeitungsvertrag schützt nur personenbezogene Daten innerhalb seines Anwendungsbereichs. Für Geschäftsgeheimnisse, reine Unternehmensdaten und vertraglich vertrauliche Informationen müssen Leistungs- und Geheimhaltungsregeln gesondert passen. Bestehende NDAs oder Kundenverträge können die Weitergabe an Unterauftragnehmer oder externe KI-Dienste zusätzlich begrenzen.
Was der EU AI Act für den betrieblichen Einsatz generativer KI bedeutet
Ein Unternehmen, das einen fremden KI-Dienst unter eigener Verantwortung nutzt, ist nach dem EU AI Act regelmäßig Betreiber – in der deutschen Fassung der Verordnung „Betreiber“, im englischen Text „deployer“. Beschäftigte, die das System unter Weisung und Kontrolle des Unternehmens bedienen, werden dadurch nicht jeweils selbst zu Betreibern. Wer ein System unter eigenem Namen anbietet, seine Zweckbestimmung ändert oder es wesentlich verändert, kann dagegen in eine Anbieterrolle gelangen. Die Rolle ist für jeden Einsatz gesondert zu bestimmen.
KI-Kompetenz muss zum Einsatz passen
Anbieter und Betreiber müssen seit dem 2. Februar 2025 Maßnahmen ergreifen, um die Entwicklung von KI-Kompetenz bei Beschäftigten und anderen Personen zu unterstützen, die in ihrem Auftrag mit KI-Systemen umgehen. Die im Juli 2026 geänderte Fassung von Artikel 4 verlangt nicht, bei jeder Person ein bestimmtes Kompetenzniveau zu garantieren. Sie verlangt aber weiterhin angemessene Maßnahmen unter Berücksichtigung von Vorwissen, Erfahrung, Einsatzkontext und betroffenen Personengruppen. Das folgt aus der Änderungsverordnung (EU) 2026/1744. Eine allgemeine Schulung genügt deshalb nicht automatisch für sämtliche Anwendungen: Wer öffentliche Texte glättet, benötigt andere Kenntnisse als Beschäftigte, die einen Kunden-Chatbot betreuen, personenbezogene Daten auswerten oder KI in Personalprozessen einsetzen. Richtlinie, Schulung und technische Freigaben sollten zusammenpassen.
Transparenz und besondere Risikofälle gesondert einordnen
Die Transparenzpflichten des Artikels 50 gelten seit dem 2. August 2026. Daraus folgt keine allgemeine Pflicht, jeden intern erstellten Entwurf oder jeden KI-unterstützten Geschäftstext zu kennzeichnen. Relevant sind insbesondere die Information natürlicher Personen bei direkter Interaktion mit bestimmten KI-Systemen, die Offenlegung von Deepfakes sowie unter näheren Voraussetzungen KI-generierte oder manipulierte Texte, die veröffentlicht werden, um die Öffentlichkeit über Angelegenheiten von öffentlichem Interesse zu informieren. Für solche Texte sieht die Verordnung eine Ausnahme vor, wenn eine inhaltlich substanzielle menschliche Überprüfung oder redaktionelle Kontrolle stattfindet und eine natürliche oder juristische Person die redaktionelle Verantwortung trägt. Die Leitlinien der Europäischen Kommission zu Artikel 50 ordnen Anwendungsbereich und Ausnahmen näher ein.
Für Anbieter generativer Systeme bestehen daneben technische Markierungspflichten. Systeme, die bereits vor dem 2. August 2026 in Verkehr gebracht wurden, erhalten hierfür nach der Änderung von 2026 eine Übergangsfrist bis zum 2. Dezember 2026. Ob ein Unternehmen selbst Adressat einer Kennzeichnungs- oder Informationspflicht ist, hängt von seiner Rolle und dem konkreten Output ab.
Ein allgemeiner KI-Assistent wird nicht allein aufgrund seiner technischen Leistungsfähigkeit zum Hochrisiko-System. Systeme für Einstellung, Auswahl, Aufgabenzuweisung, Leistungsbewertung oder Beendigung von Arbeitsverhältnissen können dagegen unter die Hochrisiko-Fälle des Anhangs III fallen. Die besonderen Hochrisiko-Regeln für diese Fälle gelten nach der im Juli 2026 beschlossenen Verschiebung grundsätzlich ab dem 2. Dezember 2027; DSGVO, AGG und Betriebsverfassungsrecht sind bereits heute zu beachten. Gleiches gilt für bereits anwendbare Verbote, etwa die grundsätzlich untersagte Emotionserkennung am Arbeitsplatz außerhalb enger medizinischer oder sicherheitsbezogener Ausnahmen.
Für den Vollzug in Deutschland gilt seit dem 29. Juli 2026 das KI-Marktüberwachungs- und Innovationsförderungsgesetz. Die Bundesnetzagentur übernimmt danach die zentrale Koordinierung und grundsätzlich Aufgaben der Marktüberwachung; zuständige Fach- und Sektorbehörden bleiben daneben eingebunden. Die vollständige Rollen-, Fristen-, Risiko- und Sanktionssystematik erläutert der Hauptbeitrag zum EU AI Act für Unternehmen.
Beschäftigte, Shadow AI und Betriebsrat
Wenn ein Unternehmen kein nutzbares Verfahren vorgibt, weichen Beschäftigte häufig auf persönliche Konten aus. Ein bloßes Verbot verhindert diese „Shadow AI“ nicht zuverlässig. Sinnvoller ist eine Kombination aus freigegebenen Werkzeugen, verständlichen Datenregeln, konkreten Beispielen, technischen Beschränkungen und erreichbaren Eskalationswegen.
Besteht ein Betriebsrat, sollte er frühzeitig einbezogen werden. Nach § 90 BetrVG ist er über die Planung von Arbeitsverfahren und Arbeitsabläufen einschließlich des Einsatzes künstlicher Intelligenz rechtzeitig zu unterrichten und zu beraten. Ein Mitbestimmungsrecht nach § 87 Absatz 1 Nummer 6 BetrVG kann bestehen, wenn eine technische Einrichtung dazu bestimmt ist, Verhalten oder Leistung von Beschäftigten zu überwachen. Für Auswahlrichtlinien mit KI enthält § 95 Absatz 2a BetrVG eine ausdrückliche Regelung.
Ob eine konkrete Funktion diese Rechte auslöst, hängt von ihrer Ausgestaltung ab. Nutzungsstatistiken, Inhaltszugriffe, Leistungsanalysen und administrative Einsichtsmöglichkeiten sollten deshalb vor dem Rollout geklärt werden – nicht erst, wenn das System bereits Daten erzeugt.
Warum menschliche Kontrolle mehr als Gegenlesen bedeutet
LLMs erzeugen sprachlich plausible Ergebnisse, ohne deren Wahrheit oder rechtliche Tragfähigkeit zu gewährleisten. Auch ein mit internen Dokumenten verbundenes RAG-System kann veraltete Quellen auswählen, Zusammenhänge unvollständig erfassen oder zusätzliche Inhalte des Grundmodells einfließen lassen.
Die Kontrolltiefe sollte sich nach Bedeutung und Außenwirkung richten:
- Ein interner Ideenvorschlag verlangt eine andere Prüfung als eine veröffentlichte Tatsachenbehauptung.
- Eine Formulierungshilfe ist anders zu behandeln als eine Entscheidung über Kunden, Beschäftigte oder Vertragspflichten.
- Generierter Programmcode benötigt neben einer Funktionsprüfung regelmäßig Sicherheits-, Herkunfts- und Lizenzkontrollen.
- Wer einem Kunden eine bestimmte Qualität, Vertraulichkeit oder Exklusivität schuldet, muss diese Zusage auch bei KI-Unterstützung erfüllen können.
„Human in the loop“ ist nur belastbar, wenn die prüfende Person fachlich geeignet ist, die maßgeblichen Informationen erhält, ausreichend Zeit hat und das Ergebnis tatsächlich ändern oder verwerfen kann. Eine rein formale Bestätigung reduziert das Risiko nicht verlässlich.
Urheberrechtliche Fragen zu fremdem Input, Schutzfähigkeit, Übernahmen und kommerzieller Verwertung behandelt der Beitrag KI und Urheberrecht für Unternehmen.
Was in Verträgen mit KI-Anbietern geprüft werden sollte
Ein Anbietercheck sollte nicht bei der Frage enden, ob Daten zum Modelltraining verwendet werden. Für Unternehmen sind insbesondere folgende Punkte relevant:
- genaue Bezeichnung von Dienst, Tarif und einbezogenen Funktionen,
- erlaubte betriebliche Nutzungszwecke und ausgeschlossene Anwendungsfälle,
- Rollen nach Datenschutzrecht und Inhalt des Auftragsverarbeitungsvertrags,
- Speicherfristen, Löschung, Export und Rückgabe von Unternehmensdaten,
- Modelltraining, Feedback, Missbrauchskontrolle und sonstige eigene Nutzungszwecke,
- Unterauftragnehmer, Datenstandorte und Drittlandzugriffe,
- Mandantentrennung, Verschlüsselung, Berechtigungen und Protokollierung,
- Umgang mit Sicherheitsvorfällen und Unterstützung bei Betroffenenanfragen,
- Rechte an Eingaben und Ausgaben sowie Umgang mit Ansprüchen Dritter,
- Verfügbarkeit, Leistungsänderungen und Wechsel des zugrunde liegenden Modells,
- Haftungsgrenzen, Freistellungen und Ausschlüsse,
- Kündigung, Anbieterwechsel und Entfernung angebundener Datenquellen.
Bei Konnektoren und KI-Agenten muss zusätzlich geklärt werden, ob das System nur Informationen liest oder selbst Aktionen auslösen darf. Der Zugriff auf E-Mail, Cloudspeicher, CRM, Quellcode oder Kalender kann aus einer einzelnen Chatfunktion einen weitreichenden Geschäftsprozess machen.
Solche Verbindungen erhöhen auch das Risiko indirekter Prompt-Injection: Manipulierte Inhalte in Webseiten, E-Mails oder Dokumenten können versuchen, Systemanweisungen zu überschreiben, Daten offenzulegen oder Aktionen auszulösen. Schreibrechte und Zugang zu sensiblen Daten sollten deshalb nach dem Least-Privilege-Prinzip begrenzt, kritische Aktionen gesondert bestätigt und Ein- sowie Ausgaben angemessen überwacht werden. Das Bundesamt für Sicherheit in der Informationstechnik weist auf diese Angriffsform und mögliche Schutzmaßnahmen hin.
Allgemeine Hinweise zu Leistungsbeschreibung, Auftragsverarbeitung, Haftung und Exit finden sich im Beitrag zur Vertragsgestaltung mit IT-Dienstleistern.
Neun Bausteine einer betrieblichen KI-Richtlinie
Eine KI-Richtlinie sollte die tatsächlichen Systeme und Arbeitsabläufe des Unternehmens abbilden. Eine allgemeine Musterregel, die weder Tarife noch Datenklassen oder Verantwortliche kennt, schafft häufig nur scheinbare Klarheit.
- Geltungsbereich: Welche Beschäftigten, Gesellschaften, Endgeräte und Arten von KI-Systemen sind erfasst?
- Freigegebene Dienste: Welche Produkte, Tarife, Konten und Funktionen dürfen genutzt werden?
- Zulässige Zwecke: Für welche Aufgaben ist der Einsatz freigegeben, eingeschränkt oder untersagt?
- Datenregeln: Welche öffentlichen, internen, vertraulichen und personenbezogenen Daten dürfen eingegeben werden?
- Kunden- und Drittmaterial: Welche Vertrags-, Urheber- und Geheimhaltungspflichten sind vor einem Upload zu prüfen?
- Outputkontrolle: Wer prüft Tatsachen, Qualität, Rechte, Diskriminierungsrisiken und Sicherheit?
- Freigabe und Eskalation: Welche Ergebnisse benötigen eine fachliche, rechtliche oder sicherheitsbezogene Prüfung?
- Dokumentation und Vorfälle: Was wird nachvollziehbar festgehalten und wie werden Fehlübermittlungen oder problematische Outputs gemeldet?
- Schulung und Aktualisierung: Welche rollenbezogenen Kenntnisse werden vermittelt und wer prüft Änderungen an Diensten, Verträgen und Einsatzfällen?
Die Richtlinie sollte mit Datenschutzkonzept, Informationssicherheit, Vertragsmanagement und bestehenden Freigabeprozessen verbunden werden. Sie ist kein Ersatz für technische Einstellungen. Umgekehrt verhindern Administrationsfunktionen allein nicht, dass ein zulässiger Dienst für einen unzulässigen Zweck verwendet wird.
Häufige Fragen zum Einsatz generativer KI im Unternehmen
Gelten für ChatGPT, Claude, Microsoft Copilot und Gemini dieselben rechtlichen Anforderungen?
Für alle Dienste gelten grundsätzlich dieselben einschlägigen Rechtsgebiete, insbesondere Datenschutz-, Vertrags-, Geschäftsgeheimnis-, Urheber- und Arbeitsrecht sowie der EU AI Act. Daraus folgt aber nicht für jeden Dienst dasselbe Ergebnis. Entscheidend sind das konkrete Produkt und der Tarif, aktivierte Funktionen und Konnektoren, die verarbeiteten Daten, der betriebliche Zweck sowie die jeweils geltenden Anbieterunterlagen.
Reicht ein Business- oder Enterprise-Tarif für die betriebliche Freigabe aus?
Nein. Ein solcher Tarif kann zentrale Nutzerverwaltung, vertragliche Zusagen und geeignetere Datenkontrollen bieten. Das Unternehmen muss trotzdem für jeden freigegebenen Anwendungsfall unter anderem Rechtsgrundlage, Geheimhaltung, Rechte an den Eingaben, Drittlandbezüge, Speicherfristen und erforderliche Ergebniskontrollen prüfen. Die Freigabe sollte deshalb Dienst, Tarif, Funktionen, Datenklassen und zulässige Zwecke benennen.
Werden keine Daten mehr verarbeitet, wenn Modelltraining ausgeschlossen ist?
Doch. Auch ohne Verwendung für das Modelltraining können Ein- und Ausgaben gespeichert, sicherheitsbezogen kontrolliert, protokolliert oder im Supportfall verarbeitet werden. Unterauftragnehmer, Konnektoren und angebundene Funktionen können weitere Datenflüsse auslösen. Die Aussage zum Training ist daher nur ein Teil der Anbieterprüfung.
Reicht es für eine Anonymisierung aus, Namen und Kontaktdaten zu entfernen?
Nicht zwingend. Eine Person kann auch aus der Kombination von Funktion, Vorgang, Ort, Zeitraum oder Vertragsdetails identifizierbar sein. Werden Zuordnungsmerkmale lediglich ersetzt oder getrennt aufbewahrt, liegt regelmäßig eine Pseudonymisierung und keine Anonymisierung vor. Ob Daten tatsächlich anonym sind, muss anhand des gesamten Kontextes und der realistischen Identifizierungsmöglichkeiten beurteilt werden.
Verhindert ein RAG-System unrichtige oder erfundene Antworten?
Nein. Eine angebundene Wissensbasis kann Quellenbezug und Aktualität verbessern, beseitigt aber Auswahlfehler, unvollständige oder veraltete Dokumente und Einflüsse des Grundmodells nicht. Zusätzlich müssen Zugriffsrechte, Löschung, Aktualisierung und die Übermittlung gefundener Textabschnitte an weitere Systemkomponenten kontrolliert werden. Fachlich relevante Ausgaben benötigen deshalb weiterhin eine angemessene Prüfung.
Muss jeder mit generativer KI erstellte oder überarbeitete Text gekennzeichnet werden?
Nein. Artikel 50 des EU AI Act enthält bestimmte Informations- und Offenlegungspflichten, aber keine allgemeine Kennzeichnungspflicht für sämtliche internen Entwürfe oder geschäftlichen Texte. Ob ein Hinweis erforderlich ist, hängt insbesondere von Rolle, Einsatzform, Adressaten und Inhalt ab. Vertragliche Transparenzpflichten oder Vorgaben einer Plattform können unabhängig davon hinzukommen.
Beseitigt eine menschliche Freigabe die rechtlichen Risiken des KI-Einsatzes?
Nein. Eine Freigabe wirkt nur, wenn die prüfende Person fachlich geeignet ist, die entscheidenden Informationen kennt, ausreichend Zeit erhält und das Ergebnis tatsächlich ändern oder verwerfen kann. Umfang und Dokumentation der Kontrolle müssen zur möglichen Wirkung des Outputs passen. Eine bloß formale Bestätigung macht eine fehlerhafte oder rechtsverletzende Ausgabe nicht belastbar.
Was Unternehmen vor der Einführung dokumentieren sollten
Ein verhältnismäßiger Einführungsprozess kann in dieser Reihenfolge aufgebaut werden:
- Anwendungsfälle und wirtschaftlichen Zweck beschreiben.
- Eingaben, Ausgaben, Nutzer und betroffene Personen erfassen.
- Datenklassen und Geheimhaltungsanforderungen zuordnen.
- Dienst, Tarif, Funktionen und technische Datenflüsse dokumentieren.
- Anbieterrollen, Verträge, Unterauftragnehmer und Transfers prüfen.
- Rechtsgrundlagen, Informationspflichten und eine mögliche Datenschutz-Folgenabschätzung bewerten.
- AI-Act-Rolle, Transparenzpflichten und besondere Risikofälle einordnen.
- Betriebsrat und weitere interne Stellen rechtzeitig beteiligen.
- Freigaben, menschliche Kontrolle und Eskalationsfälle festlegen.
- Richtlinie, Schulung und technische Administration umsetzen.
- Änderungen an Modellen, Funktionen, Verträgen und Anwendungsfällen fortlaufend überwachen.
Dieser Prüfpfad schafft die Tatsachengrundlage. Ob bestimmte Kundenunterlagen, Beschäftigtendaten oder Fachprozesse in einem konkreten Dienst verarbeitet werden können, hängt von den jeweiligen Daten, Verträgen, Systemeinstellungen und Schutzmaßnahmen ab.
Wann eine individuelle Prüfung sinnvoll ist
Eine gesonderte rechtliche und vertragliche Einordnung ist insbesondere sinnvoll, wenn:
- personenbezogene Kunden- oder Beschäftigtendaten verarbeitet werden,
- besondere Datenkategorien, Berufsgeheimnisse oder zentrale Geschäftsgeheimnisse betroffen sind,
- ein KI-Dienst an CRM, E-Mail, Cloudspeicher, Quellcode oder interne Wissensbestände angebunden wird,
- ein RAG-System, Fine-Tuning oder eine eigene KI-Anwendung aufgebaut wird,
- Ausgaben Entscheidungen über Personen vorbereiten oder beeinflussen,
- ein Kunden-Chatbot oder eine generative Funktion im eigenen Produkt angeboten wird,
- der Betriebsrat zu beteiligen ist,
- gegenüber Kunden bestimmte Rechte, Vertraulichkeit oder Qualität zugesagt werden,
- Anbieterbedingungen, Datenübermittlungen oder Haftung unklar bleiben.
Für eine erste Prüfung sind regelmäßig eine Liste der geplanten Anwendungsfälle, die eingesetzten Produkte und Tarife, eine Skizze der Datenflüsse, Anbieter- und Datenschutzunterlagen, die betroffenen Datenklassen sowie die vorgesehenen Kontroll- und Freigabeschritte erforderlich. Ich ordne auf dieser Grundlage Rollen und Pflichten ein und prüfe, wie Anbieterbedingungen, interne KI-Richtlinie und tatsächlicher Einsatz zusammengeführt werden können.
Unterlagen und eine kurze Beschreibung des vorgesehenen Einsatzes können über die Kontaktseite übermittelt werden. Hinweise zu allgemeinen Datenschutzprozessen finden sich außerdem im Bereich Datenschutzrecht für Unternehmen; rollenbezogene Formate sind auf der Seite zu KI- und Datenschutzschulungen beschrieben.
Amtliche Quellen und weiterführende Hinweise
- Datenschutz-Grundverordnung
- Datenschutzkonferenz: Orientierungshilfe „Künstliche Intelligenz und Datenschutz“
- Datenschutzkonferenz: Technische und organisatorische Maßnahmen bei KI-Systemen
- Datenschutzkonferenz: Datenschutzrechtliche Besonderheiten von RAG-Systemen
- Europäischer Datenschutzausschuss: Opinion 28/2024 zu KI-Modellen
- Verordnung (EU) 2024/1689 – EU AI Act
- Verordnung (EU) 2026/1744 – Digital Omnibus on AI
- Europäische Kommission: Fragen und Antworten zur KI-Kompetenz
- Europäische Kommission: Leitlinien zu den Transparenzpflichten nach Artikel 50
- Bundesregierung: KI-Marktüberwachungs- und Innovationsförderungsgesetz
- Geschäftsgeheimnisgesetz
- Betriebsverfassungsgesetz
- BSI: Indirekte Prompt-Injection bei integrierten Sprachmodellen
Kontaktmöglichkeiten
Hier finden Sie professionelle Hilfe bei allen Fragen rund um das Thema: Vertragsrecht und Urheberrecht
Kontaktmöglichkeiten
Hier finden Sie professionelle Hilfe bei allen Fragen rund um das Thema: IT-Recht und Urheberrecht
