Dieser Artikel ordnet die Rechtslage für die Praxis ein und ersetzt keine Rechtsberatung. Er beschreibt, welche Punkte in ein Angebot und in einen Vertrag gehören, damit eine KI-Anwendung im Unternehmen freigegeben werden kann. Die Quellen stehen am Ende.
Ein Angebot für eine KI-Anwendung muss 2026 fünf Dinge schriftlich regeln: einen Auftragsverarbeitungsvertrag mit allen Unterauftragsverarbeitern, den Ausschluss von Training auf Ihren Daten, drei getrennte Hosting-Antworten (Anwendung, Modell, Logs), Rolle und Risikoklasse nach EU AI Act sowie das Code-Eigentum. Fehlt einer dieser Punkte, scheitert die Freigabe durch IT und Datenschutz, nicht die Technik.
Zwei Zahlen erklären, warum KI-Projekte im Mittelstand häufiger an der Freigabe scheitern als an der Technik. 69 Prozent der Unternehmen nennen Datenschutz als Hemmnis beim KI-Einsatz, 53 Prozent nennen rechtliche Unsicherheit. Das sind keine Technologieprobleme. Das sind Vertragsprobleme.
Seit dem 2. August 2026 ist die Frage konkreter geworden, allerdings anders als lange angekündigt: Die Transparenzpflichten nach Artikel 50 gelten seitdem, die Pflichten für Hochrisiko-Systeme nach Anhang III wurden durch die Verordnung (EU) 2026/1744 kurz vor der Frist auf den 2. Dezember 2027 verschoben. Den aktuellen Stand aller Fristen fasst EU AI Act: Was seit August 2026 für Unternehmen wirklich gilt zusammen. Wer jetzt eine KI-Anwendung beauftragt, sollte wissen, was das für den eigenen Fall bedeutet, und vor allem, was es nicht bedeutet.
Der häufigste Fehler: DSGVO und EU AI Act werden vermischt
Es sind zwei getrennte Regelwerke mit unterschiedlichen Anknüpfungspunkten.
Die DSGVO greift, sobald personenbezogene Daten verarbeitet werden. Sie fragt nicht danach, ob KI im Spiel ist. Ein Wissensassistent über Vertragsunterlagen fällt darunter, weil in Verträgen Namen stehen, nicht weil er ein Sprachmodell verwendet.
Der EU AI Act greift, sobald ein KI-System in Verkehr gebracht oder betrieben wird. Er fragt nicht danach, ob personenbezogene Daten verarbeitet werden. Eine Anwendung, die ausschließlich anonymisierte Maschinendaten auswertet, fällt darunter, obwohl die DSGVO sie nicht berührt.
Die meisten internen Anwendungen berühren beide Regelwerke, aber an verschiedenen Stellen und mit verschiedenen Konsequenzen. Ein Angebot, das nur pauschal "DSGVO-konform" verspricht, hat die Frage nicht beantwortet.
Was die DSGVO konkret verlangt
Wenn ein Dienstleister eine Anwendung baut und betreibt, die personenbezogene Daten des Auftraggebers verarbeitet, ist er in aller Regel Auftragsverarbeiter nach Artikel 28. Daraus folgt eine kurze Liste von Dingen, die vorliegen müssen, bevor die erste echte Datei in das System geht.
Auftragsverarbeitungsvertrag (AVV). Kein optionales Anhangsdokument, sondern die Rechtsgrundlage der Zusammenarbeit. Er muss Gegenstand, Dauer, Art und Zweck der Verarbeitung benennen, die Kategorien betroffener Personen, und die Weisungsbindung des Auftragnehmers.
Unterauftragsverarbeiter. Jeder Dienst in der Kette gehört benannt: das Hosting, der Modellanbieter, das Monitoring, der Mailversand. Bei KI-Anwendungen ist der Modellanbieter der Punkt, an dem die meisten Angebote schweigen. Wird ein Modell über eine API eines Anbieters außerhalb der EU aufgerufen, gehört das in die Liste, samt Rechtsgrundlage für den Drittlandtransfer.
Kein Training auf Unternehmensdaten. Diese Zusage muss ausdrücklich im Vertrag stehen, nicht in einer Marketingaussage. Bei den großen Modellanbietern ist die Nutzung von API-Daten für das Training vertraglich ausgeschlossen, aber es ist der Auftragsverarbeiter, der das gegenüber dem Auftraggeber zusichern muss.
Löschkonzept. Was passiert mit Prompts, Ausgaben, Logdateien und Vektorindizes am Ende der Aufbewahrungsfrist und am Ende des Vertrags. Bei RAG-Anwendungen wird der Vektorindex regelmäßig vergessen, obwohl er eine Kopie der Ausgangsdokumente enthält.
Technische und organisatorische Maßnahmen. Verschlüsselung, Zugriffskonzept, Protokollierung, Mandantentrennung. Bei einer Anwendung mit Rollen gehört das Rechtekonzept ohnehin in die Spezifikation, hier wird es zusätzlich zur Compliance-Anforderung.
Hosting ist eine Freigabefrage, keine Preisfrage
Ein Befund aus der Bitkom-Erhebung zur digitalen Souveränität 2025: 93 Prozent der befragten Unternehmen bevorzugen KI-Lösungen aus Deutschland, 37 Prozent würden für eine ausschließlich deutsche Datenverarbeitung mehr bezahlen, und 80 Prozent wünschen sich ausdrücklich deutsche oder europäische Alternativen.
Für die Projektplanung heißt das etwas Praktisches. EU-Hosting ist in vielen Häusern die Bedingung dafür, dass die Anwendung überhaupt in Betrieb gehen darf. Wer es aus dem Angebot herausverhandelt, um ein paar hundert Euro monatlich zu sparen, verhandelt unter Umständen die Freigabe weg.
Zu klären sind drei Punkte, und sie sind nicht dasselbe:
Wo läuft die Anwendung selbst, also Datenbank, Dateien und Vektorindex?
Wo läuft das Modell, das die Anfragen beantwortet?
Wohin gehen Logs, Fehlerberichte und Monitoring-Daten?
Es kommt häufig vor, dass Punkt eins in Frankfurt liegt und Punkt zwei in einer US-Region, weil das beim Einrichten der Standardwert war. Für die Freigabe ist die Frage einzeln je Punkt zu beantworten.
EU AI Act: erst die Rolle, dann die Risikoklasse
Der Act ordnet Pflichten nach Rolle zu. Für ein beauftragtes Projekt sind zwei relevant.
Der Anbieter entwickelt ein KI-System und bringt es unter eigenem Namen in Verkehr. Der Betreiber setzt ein KI-System unter eigener Verantwortung ein. Bei einer intern genutzten Auftragsentwicklung ist das beauftragende Unternehmen typischerweise Betreiber, und die Betreiberpflichten sind deutlich leichter als die Anbieterpflichten.
Ein Detail, das in Angeboten fast nie steht und trotzdem wichtig ist: Wer ein Hochrisiko-System unter eigenem Namen oder eigener Marke in Verkehr bringt oder es wesentlich verändert, kann selbst zum Anbieter werden, mit den entsprechend schwereren Pflichten. Wenn die Anwendung also nicht nur intern läuft, sondern später Kunden angeboten werden soll, ist die Rollenfrage vor Projektbeginn zu klären und nicht danach.
Zur Risikoklasse: Für die überwiegende Zahl der intern eingesetzten Anwendungen ist die Einordnung unspektakulär. Wissensassistenten auf eigenen Dokumenten, Dokumentenautomatisierung und Ticket-Triage liegen typischerweise im Bereich mit minimalem oder begrenztem Risiko. Anders liegt es bei den Anwendungsfällen aus Anhang III, unter anderem Personalauswahl und Beschäftigtenmanagement, Kreditwürdigkeitsprüfung, Zugang zu Bildung und grundlegenden Diensten. Deren Pflichten greifen nach der Verschiebung durch die Verordnung (EU) 2026/1744 erst ab dem 2. Dezember 2027; die Einordnung selbst gehört trotzdem an den Projektanfang, denn sie entscheidet über den Zuschnitt.
Dazu kommen die Transparenzpflichten aus Artikel 50, die seit dem 2. August 2026 gelten. Sie treffen auch harmlose Anwendungen: Wer mit einem System interagiert, muss erkennen können, dass er mit einem KI-System interagiert. Für einen Kundenservice-Assistenten ist das eine Anforderung an die Oberfläche, und sie gehört in die Spezifikation, nicht in eine spätere Korrekturschleife.
Die Einordnung gehört in die Discovery
Der teure Fehler ist nicht die falsche Einordnung. Der teure Fehler ist die späte Einordnung.
Wird zu Projektbeginn festgestellt, dass ein Anwendungsfall unter Anhang III fällt, lässt sich der Zuschnitt ändern, solange noch nichts gebaut ist. Ein Beispiel: Ein Assistent, der Bewerbungen vorsortiert, fällt unter Anhang III. Ein Assistent, der eingehende Bewerbungen lediglich formal auf Vollständigkeit prüft und keine Bewertung der Person vornimmt, ist ein anderer Anwendungsfall mit anderen Pflichten. Diese Unterscheidung in Woche eins zu treffen kostet ein Gespräch. Sie in Woche zehn zu treffen kostet das Projekt.
Deshalb gehört eine schriftliche Einordnung in die erste Projektphase, mit drei Ergebnissen: Rolle des Auftraggebers, Risikoklasse des Systems, und die daraus folgenden Pflichten in Stichpunkten. Wie dieser Nachweis zusammen mit Repository und Merge-Historie aussieht, zeigt Audit-Trail für eine KI-Anwendung.
Prüfliste für ein Angebot
Liegt ein AVV bei, oder wird er nur erwähnt?
Sind alle Unterauftragsverarbeiter benannt, einschließlich des Modellanbieters?
Steht im Vertrag ausdrücklich, dass Unternehmensdaten nicht für das Training von Modellen verwendet werden?
Wo läuft die Anwendung, wo läuft das Modell, wohin gehen die Logs? Drei getrennte Antworten.
Gibt es ein Löschkonzept, und schließt es Vektorindizes und Logdateien ein?
Ist die Rolle nach EU AI Act benannt, Anbieter oder Betreiber?
Ist die Risikoklasse eingeordnet, und ist die Einordnung Teil der ersten Projektphase?
Ist die Transparenzpflicht nach Artikel 50 in der Oberfläche berücksichtigt, soweit Menschen direkt mit dem System interagieren?
Wem gehört der Quellcode nach Abnahme?
Die letzte Frage sieht aus, als gehöre sie nicht in diese Liste. Sie gehört hinein, weil die Antwort darauf bestimmt, ob das Unternehmen die Anwendung später an eine geänderte Rechtslage anpassen kann, ohne erneut zu verhandeln.
Wie wir das handhaben
re-entry ist eine KI-App-Fabrik in Deutschland. AVV und EU-Hosting sind Teil jedes Angebots, nicht ein Aufpreis. Die Einordnung nach EU AI Act, also Rolle und Risikoklasse, ist Bestandteil der ersten Projektphase und liegt schriftlich vor, bevor gebaut wird. Das Repository liegt ab dem ersten Tag in der GitHub-Organisation des Auftraggebers, womit die letzte Frage der Prüfliste vor Projektbeginn beantwortet ist.
Der Pilot-Build liegt bei 14.900 Euro für drei Wochen, der Produktions-Build bei 49.000 Euro für sechs Wochen, jeweils zuzüglich Umsatzsteuer.
Quellen
Verordnung (EU) 2024/1689 (EU AI Act), Artikel 25, Artikel 50, Anhang III
Verordnung (EU) 2026/1744 (Digital Omnibus): verschobene Hochrisiko-Fristen
artificialintelligenceact.eu: Risikoklassen
Verordnung (EU) 2016/679 (DSGVO), Artikel 28
Bitkom, Digitale Souveränität 2025
Bitkom, KI-Studie 2025 und 2026
KfW Fokus Nr. 533, Februar 2026: KfW-Mittelstandspanel zur KI-Nutzung