Eigene Web-Anwendung DSGVO-konform betreiben:
die Pflichten des Betriebs als Verantwortlicher

Mit der ersten fremden Person in der Datenbank wird der Betrieb zum Verantwortlichen

Die DSGVO nennt denjenigen Verantwortlichen, der festlegt, wozu Daten mit Personenbezug verarbeitet werden und auf welchem Weg. Personenbezug hat jede Angabe, hinter der eine konkrete Person steht oder ermittelbar ist. In einer Web-Anwendung sind das die Namen und Kontaktwege der Nutzer, ihre Kundennummern, die Adresse des Rechners, von dem sie zugreifen, und die Vorgänge, die sie in der Anwendung auslösen. Wer eine Anwendung in Auftrag gibt und festlegt, was sie mit diesen Angaben tut, ist ihr Verantwortlicher, auch wenn eine Agentur sie baut und ein Rechenzentrum sie betreibt.

Die Grenze liegt bei der ersten fremden Person. Eine Anwendung, die der Inhaber allein für sich nutzt und in der ausschließlich seine eigenen Angaben liegen, fällt nicht unter die DSGVO. Sobald ein Kunde, ein Bewerber, ein Mitarbeiter oder ein Interessent eingetragen wird, gilt sie vollständig. Für eine Anwendung, die Kunden bedienen soll, tritt dieser Fall mit dem ersten Nutzer ein.

Auf der anderen Seite steht der Auftragsverarbeiter. So heißt ein Dienstleister, der die Daten für den Betrieb bearbeitet, dabei an dessen Anweisungen gebunden ist und keinen eigenen Zweck damit verfolgt. Das Rechenzentrum, der Anbieter der Datenbank, der Versanddienst für Benachrichtigungen und der Anbieter eines Sprachmodells arbeiten in dieser Rolle. Die Verantwortung bleibt beim Betrieb; der Dienstleister haftet für seinen Teil, nimmt dem Betrieb aber keine Pflicht ab.

Ein Betrieb, der die Anwendung für seine Kunden betreibt, wird zugleich Auftragsverarbeiter

Beide Rollen treten nebeneinander auf, sobald Kunden eigene Daten Dritter in die Anwendung einbringen. Trägt eine Hausverwaltung im Portal des Sanitärbetriebs die Namen und Telefonnummern ihrer Mieter ein, damit Wartungstermine abgestimmt werden können, verarbeitet der Betrieb diese Angaben im Auftrag der Hausverwaltung. Für die Daten der Hausverwaltung selbst bleibt er Verantwortlicher; für die Daten der Mieter ist er Auftragsverarbeiter und muss seinem Kunden dafür einen eigenen Vertrag anbieten. Welches Dokument daraus folgt, behandelt der Abschnitt zu den Dokumenten weiter unten.

Für jeden Dienstleister, der die Daten sieht, liegt ein Vertrag zur Auftragsverarbeitung vor

Ein Vertrag zur Auftragsverarbeitung, in der Praxis AVV genannt, bindet einen Dienstleister, der für den Betrieb Daten mit Personenbezug bearbeitet, an die Vorgaben des Artikels 28 DSGVO. Darin steht, was der Dienstleister mit den Daten tun darf und wofür, wie er sie absichert, dass er ausschließlich auf Anweisung des Betriebs handelt, dass er weitere Dienstleister nur mit Zustimmung einsetzt, dass er Prüfungen zulässt und dass er die Daten nach Vertragsende löscht oder zurückgibt. Die Form ist schriftlich oder elektronisch; die meisten Anbieter hinterlegen den Vertrag zur Annahme im Kundenkonto.

Zur Dienstleisterkette einer Web-Anwendung gehören in der Regel:

• das Rechenzentrum oder der Hosting-Anbieter, auf dessen Servern die Anwendung läuft,
• der Anbieter von Datenbank, Anmeldung und Dateiablage, wenn diese Bausteine als Dienst bezogen werden,
• der Versanddienst für E-Mails und Benachrichtigungen aus der Anwendung,
• ein Dienst für Fehlerberichte oder Nutzungsstatistik, sofern er Nutzerkennungen erhält,
• der Anbieter des Sprachmodells, sobald Eingaben mit Personenbezug an ihn gehen,
• Entwicklungswerkzeuge, die während der Arbeit Zugriff auf Daten mit Personenbezug haben.

Der Tarif entscheidet, ob ein solcher Vertrag überhaupt zu bekommen ist. Verbraucher-Tarife und kostenfreie Zugänge vieler Dienste sehen keinen Vertrag zur Auftragsverarbeitung vor und lassen Einstellungen wie den Ausschluss der eigenen Eingaben vom Training eines Modells nicht zu. Geschäfts- und Unternehmenstarife enthalten beides in der Regel. Ein Werkzeug, das Daten der Anwendung sieht, läuft deshalb über ein geschäftliches Konto des Betriebs.

Den Vertrag vor der Annahme zu lesen ist Teil der Pflicht. Geprüft werden die Zwecke, zu denen der Dienstleister die Daten verwenden darf, die Speicherorte, die Speicherdauer, die Liste der weiteren Dienstleister und die Frage, was mit den Daten geschieht, wenn der Vertrag endet. Stimmt eine dieser Angaben nicht mit der eigenen Verarbeitung überein, scheidet der Dienst für diese Anwendung aus.

Auch die Dienstleister des Dienstleisters werden geprüft

Setzt der Auftragsverarbeiter für seine Leistung selbst Dritte ein, heißen diese Unterauftragsverarbeiter: das Rechenzentrum, in dem ein Datenbank-Dienst seine Server stehen hat, oder der Versanddienst, über den er Systemmails verschickt. Die DSGVO erlaubt den Einsatz nur mit vorheriger Genehmigung des Betriebs, in der Praxis als allgemeine Genehmigung im Vertrag mit der Pflicht, über Änderungen zu informieren, und verlangt, dass der Dienstleister seine eigenen Pflichten an die Unterauftragsverarbeiter weitergibt. Die Liste der Unterauftragsverarbeiter veröffentlichen die meisten Anbieter. Verlangt ist die Kenntnis der ersten Ebene: welche Unterauftragsverarbeiter der eigene Dienstleister einsetzt, wo sie sitzen und wofür sie Daten erhalten.

Ein Anbieter außerhalb der EU braucht eine zusätzliche Grundlage für die Übermittlung

Für Anbieter mit Sitz in der Europäischen Union oder im Europäischen Wirtschaftsraum gilt die DSGVO unmittelbar; der Vertrag zur Auftragsverarbeitung genügt. Ein Anbieter außerhalb dieses Raums sitzt in einem Drittland, und die Übermittlung von Daten mit Personenbezug dorthin ist nur erlaubt, wenn eine der Übermittlungsgrundlagen vorliegt, die die DSGVO in ihrem fünften Kapitel vorsieht. Zwei davon kommen für eine Web-Anwendung in Betracht: Entweder hat die EU-Kommission dem Land per Beschluss ein angemessenes Schutzniveau bescheinigt, oder der Betrieb schließt mit dem Anbieter die von der Kommission vorgegebenen Standardvertragsklauseln und prüft, ob das Recht des Ziellands diese Zusage im Ernstfall hält.

Für die Vereinigten Staaten hat die Kommission einen solchen Beschluss im Juli 2023 gefasst, allerdings mit einer Bedingung: Er gilt nur für Unternehmen, die sich unter dem vereinbarten Datenschutzrahmen selbst zertifiziert haben und in der öffentlichen Liste des zuständigen US-Ministeriums geführt werden. Steht der Anbieter auf dieser Liste, ist die Übermittlung an ihn zulässig. Die Zertifizierung des Anbieters erledigt damit genau einen Punkt, die Übermittlungsgrundlage. Vertrag zur Auftragsverarbeitung, Prüfung der Zwecke, Datenminimierung und die eigene Datenschutzinformation bleiben Aufgabe des Betriebs.

Umgekehrt macht ein Sitz innerhalb der EU die Anwendung nicht von selbst zulässig. Er erspart dem Betrieb den Nachweis der Übermittlungsgrundlage; alle übrigen Pflichten dieses Beitrags gelten unverändert. Die Wahl des Anbieters folgt deshalb der Verarbeitung: Je sensibler die Daten, desto kürzer die Kette und desto näher der Speicherort.

Selbst betrieben heißt nur dann ohne Dienstleister, wenn kein Dritter Zugriff hat

Ein Sprachmodell, das auf einem Rechner im eigenen Betriebsnetz läuft und von außen nicht erreichbar ist, braucht keinen Vertrag mit dem Anbieter des Modells, weil dieser keine Daten erhält. Läuft dasselbe Modell auf einem gemieteten Server in einem Rechenzentrum, ist das Rechenzentrum Auftragsverarbeiter, und der Vertrag wird mit ihm geschlossen; der Modellanbieter bleibt außen vor. Für Gesundheitsdaten und andere sensible Angaben ist diese Anordnung ein Gewinn an Kontrolle. Sie verschiebt zugleich Pflichten auf den Betrieb: Zugriffsschutz, Verschlüsselung, Updates, Datensicherung und Wiederherstellung liegen dann vollständig bei ihm. Wie sich die Steuerung einer KI-Automation im Betrieb halten lässt und welche Grenzen dabei festzulegen sind, beschreibt unser Beitrag zum lokalen Harness einer KI-Automation.

Während der Entwicklung bleiben echte Kundendaten außerhalb der Werkzeuge

Entwicklungswerkzeuge mit KI-Unterstützung senden Code, Kommentare und oft auch Datenbankinhalte als Kontext an den Anbieter des Modells. Solange darin keine Angaben zu Personen vorkommen, berührt das den Datenschutz nicht. Ein Vertrag zur Auftragsverarbeitung und der Ausschluss der Eingaben vom Training sind trotzdem die Voraussetzung, weil sich im Projektverlauf nicht ausschließen lässt, dass Personenbezug entsteht: in einem Beispieldatensatz, in einer Fehlermeldung mit Nutzerkennung, in einem Protokollauszug.

Für Tests und Vorführungen dienen erfundene Datensätze oder pseudonymisierte Auszüge. Pseudonymisierung ersetzt die Angaben, die eine Person erkennbar machen, durch Platzhalter, sodass der Datensatz ohne eine getrennt verwahrte Zuordnung keiner Person mehr zugeordnet werden kann. Ein Export der echten Kundendatenbank hat in einer Entwicklungsumgebung nichts zu suchen, auch nicht für einen Nachmittag.

Gelangen echte Daten doch in ein Werkzeug, läuft eine Frist von 72 Stunden

Dann liegt eine Datenpanne im Sinne der DSGVO vor: Angaben sind bei einer Stelle gelandet, die sie nicht bekommen durfte. Der Betrieb stellt zuerst fest, welche Daten in welchem Umfang und zu welchen Personen betroffen sind, beendet den Abfluss, beantragt beim Anbieter die Löschung und prüft, ob die Eingaben vom Training ausgeschlossen waren. Danach schätzt er ein, was den betroffenen Personen daraus entstehen kann. Lässt sich ein Risiko nicht ausschließen, geht innerhalb von 72 Stunden ab Kenntnis eine Meldung an die Aufsichtsbehörde. Wiegt das Risiko voraussichtlich schwer, erfahren auch die Betroffenen davon, und zwar mit der Beschreibung des Vorfalls, seiner Folgen und der Gegenmaßnahmen. Unabhängig von einer Meldung hält der Betrieb jeden Vorfall intern schriftlich fest.

Die Anwendung erhebt nur die Angaben, die ihr Zweck verlangt

Datenminimierung heißt: Die Anwendung fragt nur ab, was sie für den jeweiligen Vorgang tatsächlich braucht. Die DSGVO macht das in Artikel 5 zum Grundsatz jeder Verarbeitung. Technisch lässt sich fast jede Angabe abfragen; erlaubt ist, was der konkrete Zweck braucht. Artikel 25 DSGVO verlangt dazu zweierlei vom Entwurf: Der Schutz der Daten ist von Anfang an Teil der Konstruktion, und die Anwendung startet in ihrer sparsamsten Einstellung, bis der Nutzer selbst etwas anderes wählt.

Für eine Terminbuchung heißt das: Name, ein Kontaktweg für die Bestätigung, der gewünschte Zeitraum und das Anliegen sind erforderlich. Geburtsdatum, Anschrift ohne Versand, Firmengröße oder eine Angabe, die man für einen späteren Zweck vorhalten will, sind es nicht und werden nicht abgefragt. Pflichtfelder werden auf das Erforderliche begrenzt, Freitextfelder bekommen eine Zweckangabe, und jedes Feld erhält eine Löschfrist, nach der die Angabe ohne weiteren Anlass verschwindet.

Zur Gestaltung gehört auch, wer im Betrieb welche Angaben sieht. Ein Rollen- und Rechtekonzept legt fest, welche Benutzergruppe welche Daten lesen, ändern und exportieren darf, und die Anwendung protokolliert Zugriffe auf sensible Datensätze. Übertragung und Ablage sind verschlüsselt, Kennwörter werden nur in einer Form gespeichert, aus der sich das Kennwort nicht zurückrechnen lässt, und Datensicherungen unterliegen derselben Löschfrist wie die Datenbank.

Die Rechte der Nutzer sind Funktionen der Anwendung

Jede Person, deren Daten in der Anwendung liegen, kann vom Betrieb verlangen, dass er offenlegt, was er über sie gespeichert hat und wofür, und dass er ihr eine Kopie davon aushändigt. Sie kann falsche Angaben berichtigen lassen, die Löschung verlangen, sobald der Zweck weggefallen ist, die Verarbeitung einschränken lassen, die selbst eingegebenen Daten in einem gängigen, maschinell lesbaren Format mitnehmen und bestimmten Verarbeitungen widersprechen. Die DSGVO regelt das in den Artikeln 15 bis 21. Für die Antwort hat der Betrieb einen Monat ab Eingang; nur bei komplexen Anfragen darf er diese Frist um bis zu zwei Monate ausdehnen und muss das dem Antragsteller begründen.

Wer diese Rechte beim Entwurf einplant, beantwortet Anfragen in Minuten. Die Anwendung bekommt eine Exportfunktion, die alle Daten eines Nutzers als Datei in einem offenen Format zusammenstellt, etwa als CSV- oder JSON-Datei, eine Berichtigung im Benutzerkonto und eine Löschroutine, die den Nutzer an allen Ablageorten entfernt: in der Datenbank, in der Dateiablage, in Protokollen, beim Versanddienst, beim Anbieter des Sprachmodells und, mit Frist, in den Datensicherungen. Eine Vorlage für die Auskunft nennt Zwecke, Empfänger, Speicherdauer und Herkunft der Daten, sodass nur noch der Datensatz eingesetzt werden muss.

Das Argument, der Nutzer habe die Daten freiwillig eingegeben, ändert an diesen Rechten nichts. Die Angaben gehören weiterhin zu seiner Person, und der Betrieb bleibt Verantwortlicher für sie. Welche Ablageorte bei einer Löschung leicht übersehen werden und wie sich Fristen je Datenart festlegen lassen, zeigt unser Beitrag zu Bewerbungen über die Website am Beispiel der Bewerbungsunterlagen.

Eine KI-Funktion fügt jeder Pflichtengruppe einen eigenen Punkt hinzu

Eine KI-Funktion ist ein Teil der Anwendung, der Eingaben an ein Sprachmodell übergibt und dessen Antwort weiterverwendet: ein Chatbot, der Kundenfragen beantwortet, eine Vorsortierung eingehender Nachrichten oder eine Zusammenfassung von Vorgängen. Läuft das Modell bei einem Anbieter, tritt ein weiterer Auftragsverarbeiter in die Kette ein, und alle drei Pflichtengruppen erhalten einen Zusatz.

Beim Vertrag: Der Anbieter des Modells erhält Eingaben mit Personenbezug und braucht deshalb einen Vertrag zur Auftragsverarbeitung mit Ausschluss der Eingaben vom Training. Dazu gehört die Frage, wie lange der Anbieter Eingaben und Antworten aufbewahrt und zu welchem Zweck, etwa zur Missbrauchsprüfung, und ob sich diese Aufbewahrung im Geschäftstarif abschalten oder verkürzen lässt.

Bei der Gestaltung: Ein Chatbot, der Kundenfragen beantwortet, fällt unter die Kennzeichnungsregel der KI-Verordnung, die seit dem 2. August 2026 anzuwenden ist. Der Nutzer darf nicht im Unklaren bleiben, ob er gerade mit einem Mitarbeiter oder mit einem Programm schreibt; der Betrieb macht das vor dem ersten Austausch deutlich, es sei denn, es ist aus dem Zusammenhang für jeden erkennbar. Ein Hinweis am Chatfenster erfüllt das. Dazu kommt ein Hinweis vor der Eingabe, welche Angaben in das Feld gehören und welche nicht, und eine Rückfalllösung, über die der Nutzer einen Mitarbeiter erreicht. Was von der KI-Verordnung seit August 2026 tatsächlich greift und welche Teile aufgeschoben sind, hat unser Beitrag zum Stichtag der KI-Verordnung aufgeschlüsselt.

Bei den Dokumenten: Die Datenschutzinformation der Anwendung nennt die KI-Funktion, den Anbieter des Modells, dessen Sitz und die Speicherdauer der Eingaben. Und weil die Aufsichtsbehörden den Einsatz von KI zur Steuerung der Kommunikation mit Betroffenen zu den Verarbeitungen mit hohem Risiko zählen, kommt der Betrieb um eine Datenschutz-Folgenabschätzung vor dem Start meist nicht herum; der Abschnitt zu den Dokumenten erklärt sie. Welche Architektur eines Chatbots mit welchem Speicherort vereinbar ist, behandelt unser Beitrag zum DSGVO-konformen KI-Chatbot.

Aufgedrängte Daten verlangen eine Regel vor der ersten Eingabe

Aufgedrängte Daten sind Angaben, die ein Nutzer von sich aus mitteilt, ohne dass die Anwendung danach gefragt hat. Ein Kunde schreibt in den Chat eines Fensterbauers, dass er nach einer Schulteroperation die alten Fenster nicht mehr öffnen kann und deshalb eine leichtgängige Mechanik sucht. Mit diesem Satz liegt eine Gesundheitsangabe vor, und Gesundheitsangaben zählt die DSGVO zu den besonders geschützten Datenarten, die ein Betrieb ohne eine der wenigen zugelassenen Ausnahmen, etwa eine ausdrückliche Einwilligung, gar nicht verarbeiten darf. Da sich die Eingabe nicht verhindern lässt, wird der Umgang damit vorab geregelt: Die Datenschutzinformation nennt den Fall, Gesprächsverläufe werden nach kurzer Frist gelöscht und weder ausgewertet noch zum Training verwendet, die Angabe wird nicht in das Kundenkonto übernommen, und die Mitarbeiter, die Gespräche nachlesen, kennen diese Regel.

Sieben Dokumente beschreiben und belegen die Verarbeitung

Zwei dieser Dokumente sind öffentlich und richten sich an die Nutzer, fünf sind intern und werden Kunden, Aufsichtsbehörden oder Gerichten vorgelegt, wenn diese sie verlangen. Ohne die internen Dokumente ist eine Verarbeitung nicht belegbar, und ein fehlendes Verzeichnis oder eine fehlende Folgenabschätzung ist für sich ein Verstoß, unabhängig davon, ob die Verarbeitung selbst in Ordnung war.

1. Datenschutzinformation der Anwendung. Sie erfüllt die Informationspflicht aus Artikel 13 DSGVO gegenüber den Nutzern, bevor diese etwas eingeben. Darin stehen der Betrieb als Verantwortlicher mit Kontaktweg, die einzelnen Verarbeitungen mit ihrem Zweck und ihrer Rechtsgrundlage, die Dienstleister, die Daten erhalten, ein etwaiger Empfänger außerhalb der EU, die Speicherfristen, die Rechte der Nutzer und die Aufsichtsbehörde, an die sie sich wenden können. Sie ist ein eigenes Dokument der Anwendung; die Datenschutzerklärung der Website beschreibt den Besuch der Website und deckt die Anwendung nicht ab.
2. Nutzungsbedingungen oder Allgemeine Geschäftsbedingungen. Sie regeln das Vertragsverhältnis zum Nutzer unabhängig vom Datenschutz: Leistungsumfang, Verfügbarkeit, Pflichten des Nutzers, Haftung, Vergütung, Laufzeit und Kündigung. Wer die Anwendung kostenpflichtig anbietet, braucht sie vor dem ersten Vertragsschluss.
3. Verträge zur Auftragsverarbeitung mit jedem Dienstleister. Sie liegen abgeschlossen vor, bevor der erste echte Datensatz die Anwendung erreicht, und werden zusammen mit der Liste der Unterauftragsverarbeiter und den vereinbarten Schutzmaßnahmen abgelegt.
4. Ein eigener Vertrag zur Auftragsverarbeitung für Kunden. Er wird nötig, sobald der Betrieb Daten im Auftrag seiner Kunden verarbeitet, etwa die Mieterdaten der Hausverwaltung im Portal. Der Betrieb stellt ihn seinen Kunden von sich aus bereit; er ist ein anderes Dokument als die Verträge, die der Betrieb selbst mit seinen Dienstleistern schließt.
5. Verzeichnis der Verarbeitungstätigkeiten. Artikel 30 DSGVO verlangt eine interne Aufstellung, in der jede Verarbeitung mit Zweck, Datenarten, betroffenen Personengruppen, Empfängern, Auslandsübermittlungen, Fristen und Schutzmaßnahmen steht. Die Erleichterung für Betriebe unter 250 Beschäftigten hilft hier nicht, weil sie nur für gelegentliche Verarbeitungen gilt und eine Anwendung im Dauerbetrieb nicht gelegentlich verarbeitet.
6. Beschreibung der Schutzmaßnahmen. Artikel 32 DSGVO verlangt Sicherheitsvorkehrungen, die zum Risiko passen, und diese Beschreibung hält sie fest: wie Übertragung und Ablage verschlüsselt sind, wer über welche Rolle Zugriff erhält, was protokolliert wird, wie Datensicherung und Wiederherstellung ablaufen, wie die Software aktuell gehalten wird und was bei einer Datenpanne geschieht. In der Praxis heißt dieses Dokument TOM-Beschreibung, nach den technischen und organisatorischen Maßnahmen, die es aufführt. Es ist zugleich Anlage zu jedem Vertrag, in dem der Betrieb als Auftragsverarbeiter auftritt.
7. Datenschutz-Folgenabschätzung. Artikel 35 DSGVO schreibt sie für Verarbeitungen vor, bei denen für die betroffenen Personen ein hohes Risiko zu erwarten ist, und sie muss abgeschlossen sein, bevor die Verarbeitung beginnt. Wann sie greift und was sie enthält, erklärt der folgende Abschnitt.

Die Folgenabschätzung zwingt zur Risikobewertung aus Sicht der Nutzer

In der Folgenabschätzung legt der Betrieb schriftlich dar, was die Anwendung mit den Daten tut, warum das in diesem Umfang nötig ist, welche Nachteile den Nutzern daraus entstehen können und mit welchen Vorkehrungen er diese Nachteile klein hält. Bewertet wird aus der Perspektive der Nutzer. Als Fälle mit hohem Risiko nennt die DSGVO unter anderem Gesundheitsdaten und andere besonders geschützte Datenarten in größerem Umfang sowie die systematische Bewertung persönlicher Merkmale; die deutschen Aufsichtsbehörden ergänzen das um eine gemeinsame Liste, auf der der Einsatz künstlicher Intelligenz zur Steuerung der Kommunikation mit Betroffenen oder zur Bewertung ihrer persönlichen Merkmale steht. Ein Chatbot, der Kundengespräche führt, fällt darunter. Typische Maßnahmen, die aus der Prüfung folgen, sind ein engeres Rechtekonzept, kürzere Löschfristen, der Verzicht auf einzelne Felder, die Pseudonymisierung vor der Übergabe an das Modell und die Wahl eines Speicherorts innerhalb der EU. Ist ein Datenschutzbeauftragter bestellt, wird er an der Prüfung beteiligt.

Rechtstexte aus einem Sprachmodell ersetzen keine juristische Prüfung

Wer die Anwendung mit KI-Unterstützung baut, kann im selben Werkzeug einen Entwurf der Datenschutzinformation, des Vertrags zur Auftragsverarbeitung und der Folgenabschätzung erzeugen. Das Ergebnis klingt nach Rechtstext und hält einer Prüfung oft nicht stand.

Der Grund liegt in der Arbeitsweise eines Sprachmodells. Es erzeugt die Formulierung, die in seinen Trainingsdaten am häufigsten vorkommt. Sein Maßstab ist damit die am häufigsten kopierte Klausel aus öffentlich verfügbaren Datenschutzerklärungen; den aktuellen Stand von Gesetz und Rechtsprechung kennt es nur, soweit er in diesen Texten steht. Dazu kommen erfundene Artikelnummern, veraltete Fristen und Klauseln, die zur Verarbeitung des Betriebs nicht passen. Die Haftung für ein unbrauchbares Dokument liegt beim Betrieb, der es verwendet.

Brauchbar ist das Werkzeug als Prüfhilfe: um einen vorhandenen Entwurf auf Lücken abzuklopfen, Fachbegriffe zu erklären oder eine Felderliste in eine erste Gliederung zu bringen. Die Dokumente selbst erstellt oder prüft, wer dafür ausgebildet ist: der Datenschutzbeauftragte des Betriebs oder eine Kanzlei. Wir liefern dafür die technischen Angaben, die diese Prüfung braucht: die Felderliste mit Zwecken und Fristen, die Dienstleisterkette mit Sitz und Vertragsstand und die Beschreibung der Schutzmaßnahmen.

Wir bauen die Pflichten in vier Schritten in die Anwendung ein

In einem Anwendungsprojekt mit ProXWorks laufen die Datenschutzpflichten parallel zur technischen Arbeit mit, in vier Schritten, die jeweils ein prüfbares Ergebnis liefern.

1. Wir erstellen mit Ihnen die Verarbeitungsübersicht. Für jede Angabe, die die Anwendung erheben soll, halten wir fest, von wem sie stammt, wozu sie dient, auf welcher Grundlage sie verarbeitet wird, wie lange sie bleibt und wer sie sehen darf. Angaben ohne Zweck fallen hier heraus. Ergebnis: eine Felderliste, aus der Verzeichnis und Datenschutzinformation entstehen.
2. Wir legen die Dienstleisterkette fest. Hosting, Datenbank, Versand und, falls vorgesehen, der Anbieter des Sprachmodells werden nach Sitz, Tarif, Vertragsangebot und Unterauftragsverarbeitern ausgewählt; Werkzeuge der Entwicklung laufen über geschäftliche Konten mit Trainingsausschluss. Ergebnis: ein Vertragsordner, der vor dem ersten echten Datensatz vollständig ist.
3. Wir bauen Rechte und Schutz als Funktionen ein. Minimale Pflichtfelder, Rollen und Protokolle, Verschlüsselung, Export- und Löschroutine über alle Ablageorte, die Kennzeichnung der KI-Funktion und der Hinweis vor der Eingabe gehören zum ersten Entwurf. Ergebnis: eine Anfrage auf Auskunft oder Löschung ist aus der Anwendung heraus erledigt.
4. Wir übergeben die Unterlagen zur Prüfung und begleiten den Start. Die Beschreibung der Schutzmaßnahmen, die Felderliste und, wo nötig, der Entwurf der Folgenabschätzung gehen an Ihren Datenschutzbeauftragten oder Ihre Kanzlei; nach deren Freigabe wird die Datenschutzinformation veröffentlicht und die Anwendung freigeschaltet. Ergebnis: eine Anwendung, deren Verarbeitung vom ersten Tag an belegt ist.

Fünf Fehler holen die Datenschutzfrage nach dem Start zurück

Die fünf Fehler unten treten bei Anwendungen, die ohne Datenschutzkonzept gestartet sind, regelmäßig auf. Jeder ist im Entwurf mit geringem Aufwand zu vermeiden und nach dem Start nur mit erheblichem zu beheben.

Die Fehler 1 bis 3 betreffen Pflichten, die vor dem Start erledigt sein müssen; die Fehler 4 und 5 fallen im laufenden Betrieb auf.