Darf ich personenbezogene Daten in eine KI eingeben?

Die Rechtsgrundlage ist das kleinere Problem · Stand: 7. August 2026

Der häufigste KI-Einsatz in deutschen Unternehmen sieht ungefähr so aus: Eine Kundenmail kommt rein, jemand markiert den Text, kopiert ihn in ein KI-Tool im Browser, fragt nach einem Antwortvorschlag, kopiert das Ergebnis zurück, liest kurz drüber und schickt ab. Kein Projekt, keine Freigabe, kein Ticket. Bei vierzig Mails am Tag spart das spürbar Zeit, und genau deshalb passiert es, meist bevor jemand gefragt hat, ob es in Ordnung ist.

Die eingebaute Variante gibt es inzwischen auch. Outlook bietet den Entwurf über Microsoft 365 Copilot an, Gmail über Gemini. Beides hängt allerdings an einer Lizenz, im Fall von Copilot an einer kostenpflichtigen Zusatzlizenz pro Arbeitsplatz, weshalb in vielen kleineren Betrieben weiter kopiert und eingefügt wird. Datenschutzrechtlich ist das die ungünstigere Variante, weil beim Kopieren in ein privates Konto weder ein Vertrag noch eine Konfiguration dazwischensteht.

Fragt dann doch jemand nach, kommt in jedem Ratgeber dieselbe Antwort: Es braucht eine Rechtsgrundlage, einen Vertrag zur Auftragsverarbeitung und eine Grundlage für den Drittstaatentransfer. Das stimmt alles. Und es beantwortet zusammengenommen nur eine einzige Frage, nämlich ob man anfangen darf. Die Frage, die acht Monate später auf dem Tisch liegt, ist eine andere: Ein Kunde verlangt Auskunft über alles, was zu ihm gespeichert ist, und anschließend die Löschung. Um diese zweite Frage geht es hier.

Der Punkt, an dem die übliche Prüfung aufhört

Unstrittig ist der Anfang. Sobald eine Kundennachricht in ein KI-System fließt, werden personenbezogene Daten verarbeitet. Verarbeitung ist nach Art. 4 Nr. 2 DSGVO jeder Vorgang im Zusammenhang mit solchen Daten, ausdrücklich auch das Auslesen, das Abfragen und die Verwendung. Ob das Modell mit den Eingaben trainiert wird, spielt dafür keine Rolle. Das ist der verbreitetste Irrtum zum Thema: Solange kein Training stattfinde, sei die Sache datenschutzrechtlich unkritisch. Sie ist es nicht.

Daraus folgt die bekannte Prüfkette. Es braucht eine Rechtsgrundlage nach Art. 6 DSGVO, in der Praxis meist die Vertragserfüllung oder das berechtigte Interesse mit der dazugehörigen Abwägung, einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO, sofern es überhaupt einen Auftragsverarbeiter gibt, eine Transfergrundlage nach Art. 44 ff. DSGVO bei Anbietern außerhalb des Europäischen Wirtschaftsraums, einen Eintrag im Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DSGVO sowie die Information der Betroffenen. Die läuft über Art. 13 DSGVO, soweit die Daten beim Kunden selbst erhoben wurden, und über Art. 14 DSGVO für alle anderen, die im Verlauf mitverarbeitet werden. Je nach Risiko kommt eine Datenschutz-Folgenabschätzung nach Art. 35 DSGVO dazu.

Diese Punkte sind Pflicht, und wer sie überspringt, hat ein Problem. Sie haben allerdings eine gemeinsame Eigenschaft: Sie regeln den Eintritt. Keiner von ihnen sagt etwas darüber, ob sich der Vorgang wieder rückgängig machen lässt.

Wie ernst das ist, muss man mir nicht glauben. Die Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder, also die versammelte deutsche Aufsicht, schreibt in ihrer Orientierungshilfe zu KI-Systemen mit RAG-Methode vom Oktober 2025 wörtlich:

„Insgesamt ist festzustellen, dass die Umsetzung von Betroffenenrechten in KI-Modellen, insbesondere LLM, weitgehend ungelöst ist.“

Das ist keine Blogger-Zuspitzung, sondern die Aufsicht über sich selbst. Und es verschiebt die eigentliche Prüffrage. Sie lautet nicht, ob KI und Datenschutz zusammengehen, sondern wo die personenbezogenen Daten am Ende liegen und ob sie von dort wieder verschwinden können.

Was beim Kopieren tatsächlich das Haus verlässt

Beim E-Mail-Fall lohnt sich ein genauer Blick, weil beide Varianten mehr mitnehmen, als der Anlass hergibt. Wer eine Mail kopiert, kopiert in aller Regel nicht nur den eigenen Absatz, sondern den zitierten Verlauf darunter, samt Signaturen, Telefonnummern und den Adressen aller, die je in Kopie standen. Bei der eingebauten Variante ist es ähnlich, nur automatisch: Der Assistent bekommt den Thread mitgeliefert, damit die Antwort zum Kontext passt, und greift bei manchen Produkten auf weitere Vorgänge zu. In beiden Fällen werden Daten von Menschen verarbeitet, die mit dem aktuellen Anliegen nichts zu tun haben.

Dazu kommt die Eigenart von Freitext. E-Mails identifizieren Menschen auch dann, wenn kein Name darin steht. Der Satz „Der Geschäftsführer unseres größten Kunden aus dem Münsterland hat sich über die Rechnung vom 14. März beschwert“ enthält keinen einzigen Namen und bezeichnet trotzdem genau eine Person. Fachlich heißt das Herausgreifen, und es ist der Grund, warum das bloße Schwärzen von Namen als Schutzmaßnahme wenig taugt.

Ebenso wenig taugt die Annahme, im Freitext stünde nichts Sensibles. Genau dort steht das Sensibelste. „Seit meiner Operation komme ich nicht mehr in den Account.“ „Meine Tochter hat aus Versehen bestellt.“ Gesundheitsangaben und Familienverhältnisse, also Daten, die unter Art. 9 DSGVO fallen können, landen im Postfach, ohne dass sie jemand als solche gemeint hätte.

Für die spätere Löschfrage ist entscheidend, wo diese Daten anschließend liegen. Bei einem KI-gestützten Postfach sind das mindestens vier Orte: die Eingabe beim Anbieter, der Kontext der laufenden Sitzung, ein etwaiger Suchindex über die eigenen Dokumente und, falls damit nachtrainiert wurde, das Modell selbst. Die wenigsten Unternehmen können diese vier Orte auf Nachfrage benennen. Wer sie nicht benennen kann, kann Art. 15 DSGVO nicht bedienen, denn Auskunft setzt voraus, dass man den eigenen Datenbestand kennt.

Ein zweiter verbreiteter Kurzschluss gehört an dieselbe Stelle: Der Schalter, mit dem sich das Training abschalten lässt, regelt genau eine Sache, nämlich das Training. Er regelt nicht, wie lange der Anbieter Eingaben protokolliert, ob Mitarbeiter zur Missbrauchskontrolle mitlesen und ob sich einzelne Datensätze gezielt entfernen lassen.

Und noch etwas hängt an der Einstiegsszene, das leicht untergeht: Wer eine Kundenmail in ein Browser-Tool kopiert, tut das häufig in einem privaten Konto. Die DSK empfiehlt in ihrer Orientierungshilfe Künstliche Intelligenz und Datenschutz ausdrücklich, dass Arbeitgeber betriebliche Geräte und Accounts bereitstellen, damit Beschäftigte nicht mit privaten Zugängen arbeiten müssen, weil auf diesem Weg Profile über die Beschäftigten selbst entstehen können. Aus demselben Papier stammt der Hinweis, den Datenschutzbeauftragten stets einzubinden und eine Beteiligung von Betriebs- oder Personalrat zu prüfen. Bei einem Assistenten, der dauerhaft im Postfach mitliest, ist diese Prüfung keine Formalie.

Warum Löschen und Berichtigen an der Technik scheitern

Das Recht auf Berichtigung nach Art. 16 DSGVO trifft auf ein grundsätzliches Hindernis. Ein Sprachmodell lässt sich nicht berichtigen. Erzeugt es über eine Person eine falsche Aussage, bleibt nur, den Output zu filtern oder per Anweisung zu unterdrücken. Das behandelt das Symptom, nicht die Ursache.

Beim Recht auf Löschung nach Art. 17 DSGVO trennt sich, was geht und was nicht. Löschbar sind Protokolle, Suchindizes und Trainingsdatensätze. Aus den Modellgewichten dagegen lässt sich ein einzelner Datensatz nach heutigem Stand nicht gezielt entfernen, ohne das Modell neu zu trainieren. Der technische Grund heißt Memorisierung: Sprachmodelle behalten Teile ihrer Trainingsdaten. Die Arbeit von Nolte, Finck und Meding vom März 2025 arbeitet das für die Fachwelt heraus und leitet daraus ab, dass Sprachmodelle über den gesamten Entwicklungszyklus hinweg als personenbezogene Daten zu behandeln seien. Die DSK formuliert zurückhaltender und nennt die Umsetzung der Betroffenenrechte auf Modellebene schlicht ungelöst.

Häufig übersehen wird das Widerspruchsrecht nach Art. 21 DSGVO, obwohl es die direkte Folge der beliebtesten Rechtsgrundlagenwahl ist. Wer den KI-Einsatz auf das berechtigte Interesse stützt, muss einzelne Personen aus der Verarbeitung herausnehmen können. Nach Art. 21 Abs. 1 DSGVO darf der Verantwortliche nach einem Widerspruch nicht weiterverarbeiten, es sei denn, er kann zwingende schutzwürdige Gründe nachweisen. Der Europäische Gerichtshof hat mit Urteil vom 07.12.2023 in den verbundenen Rechtssachen C-26/22 und C-64/22 entschieden, dass die betroffene Person in diesem Fall die unverzügliche Löschung nach Art. 17 Abs. 1 lit. c DSGVO verlangen kann. Widerspruch und Löschung hängen damit zusammen, und beides muss technisch abbildbar sein. Ein Vertrag zur Auftragsverarbeitung ersetzt das nicht: Er ist eine Voraussetzung, keine Erlaubnis, und über die Betroffenenrechte sagt er nichts.

Und dann ist da noch ein Grundsatz, der gar kein Betroffenenrecht ist und deshalb noch seltener geprüft wird. Nach Art. 5 Abs. 1 lit. d DSGVO müssen personenbezogene Daten sachlich richtig sein. Ein System, das plausibel klingende Falschaussagen über echte Menschen erzeugt, verletzt diesen Grundsatz strukturell, unabhängig davon, wie sauber die Rechtsgrundlage dokumentiert ist.

An dieser Stelle gehört Ehrlichkeit dazu. Ob in einem Sprachmodell überhaupt personenbezogene Daten stecken, ist unter den Aufsichtsbehörden umstritten. Der Hamburgische Beauftragte für Datenschutz und Informationsfreiheit vertritt in seinem Diskussionspapier vom Juli 2024 die These, im Modell seien keine gespeichert, weshalb sich Ansprüche nur auf Eingabe und Ausgabe richten könnten, bezeichnet sich aber ausdrücklich als Debattenimpuls. Der Europäische Datenschutzausschuss hält in seiner Stellungnahme 28/2024 mit personenbezogenen Daten trainierte Modelle dagegen nicht in allen Fällen für anonym, mit hoher Nachweislast für den, der Anonymität behauptet.

Für die Praxis fällt dieser Streit in beide Richtungen gleich aus, und das ist die eigentliche Pointe. Trifft die Hamburger Position zu, richten sich alle Ansprüche auf Eingabe, Ausgabe und die eigenen Datenbestände. Trifft die strengere Position zu, kommt das Modell hinzu, an dem sich ohnehin nichts ändern lässt. In beiden Fällen ist die einzige Ebene, auf der Handlungsfähigkeit besteht, die eigene.

Die Unterscheidung, die den Ausschlag gibt

Daraus ergibt sich die Unterscheidung, auf die es beim ganzen Thema ankommt. Jeder KI-Einsatz zerfällt in zwei Schichten. In der kontrollierbaren Schicht liegen die Eingabe, die Ausgabe, die eigenen Referenzdokumente, der Suchindex und, falls pseudonymisiert wird, die Zuordnungstabelle. All das steht in eigenen Systemen und lässt sich durchsuchen, korrigieren, exportieren und löschen. In der unkontrollierbaren Schicht liegen die Modellgewichte, die Trainingspipeline des Anbieters und dessen Protokolle. Was dort landet, kommt nicht zurück.

Dass diese Trennung trägt, sagt dieselbe DSK-Orientierungshilfe, die die Betroffenenrechte für weitgehend ungelöst erklärt. Im selben Abschnitt heißt es weiter:

„Unabhängig von der Frage, ob das verwendete LLM personenbezogen oder anonym ist, stehen Betroffenen insbesondere in Bezug auf den Eingabeprompt und die Ausgabe, die Referenzdokumente und die Vektordatenbank die Rechte aus Art. 15 ff. DSGVO zu […] Transparenz, Auskunft, Berichtigung und Löschung [können] für diese in der Regel umgesetzt werden.“

Damit hat die Aufsicht die Linie selbst gezogen. Auf Modellebene sind die Betroffenenrechte ungelöst, auf der eigenen Ebene sind sie in der Regel umsetzbar. Wie viel Aufwand das kostet, hängt vom Anwendungsfall ab, und deshalb hat die pauschale Frage „Darf man KI mit personenbezogenen Daten nutzen?“ auch keine pauschale Antwort. Der Bayerische Landesbeauftragte für den Datenschutz geht in seiner Reihe AI in a nutshell denselben Weg und bewertet einzelne Anwendungsfälle statt der Technik im Ganzen. Fünf davon begegnen mir am häufigsten:

Bemerkenswert ist die Spreizung. Dasselbe Werkzeug ist für eine Produktbeschreibung völlig unproblematisch und bei der Vorauswahl von Bewerbern nur unter engen Voraussetzungen zulässig. Bewertet wird deshalb der Anwendungsfall, nicht das Werkzeug.

• Texte formulieren und übersetzen ohne Personenbezug
  Marketingtext, Anleitung, Produktbeschreibung. Kein Personenbezug, keine besondere Prüfung. Es braucht nur eine interne Regel, die klarstellt, dass hier nichts Personenbezogenes hineingehört.
• Suche über eigene Dokumente
  Handbuch, Richtlinien, technische Dokumentation. Geringer Personenbezug, und der Index liegt im eigenen Haus, ist also löschbar. Der Musterfall für die kontrollierbare Schicht.
• E-Mails beantworten und zusammenfassen
  Größter Zeitgewinn, schwierigste Datenlage, weil Freitext, Verlauf und unbeteiligte Dritte zusammenkommen. Machbar, aber nur in einer bestimmten Ausbaustufe.
• Bewerbungen vorsortieren
  Zwei scharfe Normen zugleich: das Verbot der automatisierten Einzelentscheidung nach Art. 22 Abs. 1 DSGVO und die besonderen Datenkategorien nach Art. 9 DSGVO, die aus Lebensläufen regelmäßig ableitbar sind. Art. 22 Abs. 2 DSGVO lässt Ausnahmen zu, verlangt dann aber angemessene Schutzmaßnahmen. Ohne echte menschliche Entscheidung und ohne Folgenabschätzung halte ich den Einsatz für nicht vertretbar.
• Kunden bewerten oder Wahrscheinlichkeiten berechnen
  Der Europäische Gerichtshof hat am 07.12.2023 (C-634/21) entschieden, dass schon die Erstellung eines Wahrscheinlichkeitswerts eine automatisierte Entscheidung nach Art. 22 DSGVO sein kann, wenn ein Dritter ihn maßgeblich heranzieht. Verboten ist das nicht in jedem Fall, aber es fällt in den Anwendungsbereich von Art. 22 DSGVO und braucht dann eine der Ausnahmen aus Absatz 2 samt Schutzmaßnahmen. Ohne diese Prüfung nicht starten.

Drei Ausbaustufen für das Postfach

Für den E-Mail-Fall ist die Frage „erlaubt oder nicht“ zu grob. Sinnvoller ist es, in Ausbaustufen zu denken. Jede Stufe bringt für sich einen Nutzen, und die höchste ist selten die richtige.

Die dritte Stufe verdient einen genaueren Blick, weil sie auf den ersten Blick nach der perfekten Lösung aussieht. Rechtlich ist sie tragfähiger, als viele annehmen. Der Europäische Gerichtshof hat am 04.09.2025 in der Rechtssache C-413/23 P in der Großen Kammer entschieden, dass sich der Personenbezug pseudonymisierter Daten aus der Perspektive der jeweils verarbeitenden Stelle bestimmt. Ein vertragliches Verbot der Re-Identifizierung könne zusammen mit Maßnahmen, die dem Empfänger den Schlüssel vorenthalten, ausreichen, um die Daten in dessen Händen als anonym einzuordnen. Der Sachverhalt ähnelt dem Aufbau verblüffend: Eine Behörde hatte pseudonymisierte Stellungnahmen an einen externen Gutachter gegeben, ohne den Schlüssel mitzuliefern.

Abgeschlossen ist die Frage nicht. Die EDSA-Leitlinien 02/2026 zur Anonymisierung ziehen diese Linie zwar nach und halten Anonymität für perspektivenabhängig, sind aber eine Konsultationsfassung mit Frist bis zum 30. Oktober 2026. Die älteren Leitlinien 01/2025 zur Pseudonymisierung formulieren strenger. Die Entwicklungslinie zeigt in eine Richtung, ein Freibrief ist sie nicht.

Wichtiger als der Rechtsstreit ist ohnehin ein anderer Effekt: Der Aufbau holt die Betroffenenrechte zurück. Zuordnungstabelle, Protokoll und Ausgabe liegen alle im eigenen Haus, es entsteht kein unlöschbarer Rest in einem fremden Modell. Das ist genau die Schicht, für die die DSK sagt, dass Auskunft, Berichtigung und Löschung in der Regel umsetzbar sind.

Vier Dinge kippen die Konstruktion, wenn sie nicht beherrscht werden. Das Herausgreifen durch Kontext, weil Namen zu ersetzen nichts nützt, solange die Beschreibung drumherum eine Person eindeutig bezeichnet. Die unvollständige Erkennung, weil ein Modell nie alle Personenbezüge findet und nicht meldet, was es übersehen hat, was eine zweite regelbasierte Prüfschicht für E-Mail-Adressen, Telefonnummern und Kundennummern nötig macht. Fehler beim Zurücksetzen, weil das externe Modell Platzhalter gern umformuliert und aus einem Platzhalter dann „der Kunde“ wird, was zu einer Falschzuordnung führt. Bleibt die im Entwurf und wird sie bei der Freigabe bemerkt, ist es ein Qualitätsproblem. Geht die Nachricht so hinaus, ist es eine unbefugte Offenlegung im Sinne von Art. 4 Nr. 12 DSGVO und damit ein Fall für die Meldepflicht nach Art. 33 DSGVO. Und die Zuordnungstabelle selbst, die als zusätzliche Information im Sinne von Art. 4 Nr. 5 DSGVO das empfindlichste Objekt im ganzen Aufbau ist und eine eigene Zugriffsbeschränkung, eine eigene Löschfrist und einen eigenen Platz im Sicherheitskonzept nach Art. 32 DSGVO braucht.

Eine verbreitete Erwartung trägt außerdem nicht: Pseudonymisierung löst das Richtigkeitsproblem nicht. Sie verhindert nur, dass das externe Modell eine Falschaussage über eine ihm bekannte Person trifft. Nach der Rücksetzung hängt eine erfundene Aussage wieder an einem echten Menschen. Erfindet das Modell den Satz „Sie haben bereits dreimal storniert“, steht anschließend eine Falschbehauptung über einen realen Kunden im Entwurf. Was das löst, ist ausschließlich die menschliche Prüfung vor dem Absenden. Sie ist damit keine Bequemlichkeit, sondern die tragende Maßnahme für Art. 5 Abs. 1 lit. d DSGVO, und eine Freigabe, die aus Zeitdruck zum Durchklicken wird, ist keine.

Zum Schluss die unbequeme Alternative. Oft ist die dritte Stufe der kompliziertere Weg. Die DSK weist in derselben Orientierungshilfe darauf hin, dass sich Sprachmodelle vielfach auf eigener Hardware betreiben lassen, wodurch tendenziell weniger personenbezogene Daten aus dem Modell extrahierbar sind. Ein Modell im eigenen Haus oder bei einem Anbieter im Europäischen Wirtschaftsraum hat kein Transferproblem, keine Zuordnungstabelle und keine Rücksetzungsfehler. Es ist inhaltlich schwächer. Gegen diese Messlatte muss sich der aufwendigere Weg rechtfertigen.

• Stufe 1: Vorschlag ohne Nachrichteninhalt
  Die KI schlägt anhand der Kategorie eine passende Textvorlage vor und sieht den Inhalt nie. Kein Personenbezug beim Modell, sofort umsetzbar, und der Zeitgewinn ist größer als erwartet.
• Stufe 2: Verarbeitung im geschlossenen System
  Ein Modell auf eigener Hardware oder bei einem Anbieter im Europäischen Wirtschaftsraum verarbeitet den vollständigen Inhalt. Der Personenbezug bleibt in der eigenen Umgebung, Löschung und Auskunft bleiben vollziehbar. Höherer Aufwand, rechtlich am saubersten.
• Stufe 3: Pseudonymisierung vor einem externen Modell
  Ein lokales Modell ersetzt die Personenbezüge durch Platzhalter, ein starkes externes Modell formuliert, anschließend wird lokal zurückgesetzt und ein Mensch prüft. Inhaltlich am stärksten, technisch am anspruchsvollsten.

Die drei Bedingungen

Damit lässt sich die Ausgangsfrage beantworten. Personenbezogene Daten dürfen mit KI verarbeitet werden, wenn drei Bedingungen zusammen erfüllt sind. Fehlt eine davon, lautet die Antwort nein, unabhängig davon, wie gut die Dokumentation aussieht.

Die erste Bedingung steht in jedem Ratgeber. Die dritte ist organisatorisch und meist schnell geregelt. Die zweite ist die, an der die verbreitete Praxis scheitert, und sie muss vor der Einführung geprüft werden, nicht danach. Ist eine Information erst einmal in der unkontrollierbaren Schicht, hilft kein Vertrag und keine Interessenabwägung mehr.

Wer das für den eigenen Betrieb einschätzen will, kommt mit sechs Prüfpunkten weit:

Der aufschlussreichste dieser Punkte ist der dritte, und er ist auch der einzige, der sich nicht am Schreibtisch beantworten lässt. Wenn dabei herauskommt, dass die Löschung nicht vollständig funktioniert, ist das kein Grund, ein Projekt zu beerdigen. Es ist der Grund, die Architektur zu ändern, solange das noch billig ist. Nach der Einführung wird es teuer, und spätestens beim ersten ernst gemeinten Löschverlangen wird es sichtbar.

• 1. Zulässigkeit
  Rechtsgrundlage, Zweck, Information der Betroffenen, Vertrag zur Auftragsverarbeitung, Transfergrundlage und gegebenenfalls Datenschutz-Folgenabschätzung.
• 2. Umkehrbarkeit
  Jede personenbezogene Information liegt in einer Schicht, die sich durchsuchen, korrigieren und löschen lässt. Nichts davon gelangt in Modellgewichte oder in die Trainingspipeline eines Anbieters. Diese Bedingung entscheidet über Auskunft, Berichtigung, Löschung und Widerspruch.
• 3. Ergebniskontrolle
  Keine KI-Ausgabe über eine identifizierte Person verlässt das Haus ungeprüft, und keine Entscheidung über einen Menschen fällt allein die Maschine. Das bedient den Richtigkeitsgrundsatz und Art. 22 DSGVO in einem Zug.
• Prüfpunkt 1
  Ist der Anwendungsfall einzeln bewertet, oder wurde pauschal ein Werkzeug freigegeben?
• Prüfpunkt 2
  Sind alle Orte benannt, an denen personenbezogene Daten liegen: Eingabe, Ausgabe, Index, Protokolle, Zuordnungstabelle?
• Prüfpunkt 3
  Wurde die Löschung einer einzelnen Person an einem Testfall tatsächlich durchgeführt, nicht nur angenommen?
• Prüfpunkt 4
  Ist ein Widerspruch nach Art. 21 DSGVO technisch abbildbar, falls die Verarbeitung auf dem berechtigten Interesse beruht?
• Prüfpunkt 5
  Sind Aufbewahrungsfristen für Eingaben und Protokolle gesetzt und beim Anbieter geprüft?
• Prüfpunkt 6
  Ist die menschliche Freigabe verbindlich geregelt, mit echter Möglichkeit zur Ablehnung?

Dieser Beitrag dient der allgemeinen Information und stellt keine Rechtsberatung im Einzelfall dar. Trotz sorgfältiger Recherche übernehme ich keine Gewähr für Aktualität, Richtigkeit und Vollständigkeit. Für die verbindliche Beurteilung eines konkreten Falls ist anwaltliche Beratung erforderlich.