TGV · Master-Konzept · First-Trias · 11 Sektionen + §3a · Stand 2026-09-19

Sicherheit & Datenschutz First

„Wie geheim und geschützt sind meine Daten?" — die Frage hat zwei Antworten, die TGV bewusst trennt: WER sieht es (Governance: Rollen × Vertraulichkeits-Stufe, §2–§4) und WIE ist es gesichert (Schutz-Mechanik: RLS-Realität, Guards, EU-Stack, §5–§6 + §11). Diese Seite führt die Tower-erarbeiteten Konzepte zusammen — entschieden wird in den SSOT-Dokumenten (unten verlinkt). Wie TGV VIELE Kunden trägt (Hierarchie · Topologie · M1–M6 · Onboarding · White-Label) steht im Schwester-Konzept 🏢 Multi-Mandant.

§1Die Schutz-Grenzen — Landkarte (Defense-in-Depth)

Ein Zugriff muss ALLE Schichten von außen nach innen passieren — jede Schicht ist an einer anderen Ebene strukturell verriegelt. Der interaktive Graph (SYSTEM#01-Baustein, gleiche Karten-Sprache wie der Architektur-Graph) hat zwei Modi: 🛡️ Schutz-Grenzen (Defense-in-Depth) und 🇪🇺 EU-Stack (Datenfluss mit ehrlicher EU/US-Färbung, §11) — jeder Knoten öffnet per Klick sein Detail-Panel mit Regel-Text + SSOT-Verweis:

§2Die Rollen (Ebene ① — Wer) — bewusst wenige

§2aBetreiberzugriff und Verwalterrolle — DEV Override · Support · Break Glass · Audit (konsolidierter JC-Entscheid 04.10.2026)

Quelle: 01_ITERATIONS/CONTROL_TOWER_HANDOFF/JC_ENTSCHEID_TGV_DATENSCHUTZ_DATENHOHEIT_2026-10-04.md (JC, konsolidiert aus Workshop 03.10. und Klärungsrunde) · Kurzform JE-186 bis JE-199 · Register #3550. Arbeitsprinzip: Recht → Produktregel → technische Umsetzung. Dieser Abschnitt trennt strikt IST (gemessen 04.10.2026, live) und SOLL (JC-Entscheid, Paket in Klammern). ⛔ Die Live-Policies und 08_OPS/chat_engine/scope_gate.py bleiben die technische Wahrheit über den IST-Stand.

§3Die 4 Vertraulichkeits-Stufen (Ebene ② — „wer AUSSER dir sieht es")

v1.1-Kern (relational): Die Stufe sagt, wer außer dir es sieht — NIE, ob du es nutzen darfst. Dir gehören deine Daten; deine KI nutzt sie alle, auch „streng" (Owner-Bypass). Die Stufe steuert nur, was bei ANDEREN ankommt.

Einstufung bei Upload/Intake — die vier Regeln (JC 19.07., Register #34)

§3aVertraulichkeit in der Praxis — JCs Entscheide vom 18./19.09.2026

Dieser Abschnitt zeigt den Kanon, er ersetzt ihn nicht: Quelle bleibt KONZEPT_VERTRAULICHKEIT_GEHEIMHALTUNG.md (§2, §2a, §2c, §4). Jede Zeile trägt ihren Stand: live · gebaut, Deploy offen · offen / JC · Lücke.

① Entität zuerst, dann die Stufen — am Beispiel „Marie"

Die Entität ist die Basis-Privatsphäre (wer nicht in der C3 ist, sieht keinen C3-Beleg); die Stufe verschärft nur innerhalb. „öffentlich" heißt weltöffentlich. Beispiel von JC (19.09., über TOWER#57): JC ist Verwalter der C3, Marie Mitarbeiterin der C3, dazu die Buchhalterin der C3.

② „Ausdrücklich Benannte": Kreise und Einzelfreigabe (E3, JC 19.09.)

Die Flächen und KAI-Befehle dafür baut die Bahn RECHTE-UX#01; VERTRAULICH#01 liefert Endpunkte und Funktionen. Die SQL fährt JC, der Gegenbeweis läuft mit echten Konten.

③ Zwei Mützen: dieselbe Police, zwei Belege (Register #2121)

Zahlt die Firma eine Vorsorge für eine Person, brauchen beide den Beleg. Am echten Fall: dieselbe Datei kam zweimal per Mail.

④ Erst erschließen, dann einstufen — Stufe UND Entität aus dem Dokument

JC: „Die Wahrheit zur Einstufung liegt im Dokument selbst, nicht in der Mail, mit der es versendet wurde." Absender und Empfänger sind höchstens ein Hinweis.

Stand: Erschließen vor dem Einstufen #2798 (RAG#01) · Anwenden auf dem Hauptweg orch_apply.apply #2800. Der n8n-Knoten lief zuletzt am 23.08. — die Naht dort (#2795) ist geschlossen.

⑤ Keine Stufe = streng — überall gleich

Ein Beleg ohne Stufe sieht nur der Eigentümer. Vorher lasen vier Stellen „keine Stufe" verschieden (Liste offen, KAI streng, Datenbank offen).

⑥ Gleiche Stufen für alle — Auslegung lernt je Mandant (Register #2123)

Die Stufen (fünf, davon Projekt als BALD-Stufe) gelten für jeden Mandanten gleich. Welche Fälle wohin gehören, ist je Mandant verschieden und wächst über den KVP: Zuordnungen, Korrekturen und Klärkarten werden Lernereignisse, aus denen ORCH je Mandant Hinweise präzisiert — oder aufhebt. Feste Regeln (auch „privat + Personenname") sind Startwerte für ORCH, nie Wenn-Dann-Pflicht.

⑧ Wer hochlädt, ist Eigentümer — und darf bis intern öffnen (Register #2139 · #2140, JC 19.09.)

Die Person, die ein Dokument hochlädt, sieht es immer — auch ohne Stufe und bei streng. Die Stufen-Klärkarte geht zuerst an sie, an den Verwalter erst, wenn sie weiterreicht oder nach N Tagen. Sie darf verschärfen und ihr eigenes Dokument bis intern öffnen, mit Pflicht-Grund und Protokoll — nie auf öffentlich.

Mails haben keinen Hochlader. Der Mail-Eingang läuft ohne Sitzung eines Menschen; ORCH stuft Mail und Anhänge aus dem Inhalt ein (④), die Klärkarte geht an die Verwalter.

Einführung, SQL fährt JC in dieser Reihenfolge: ① Spalte hochgeladen_von + Lesen (#2139) → ② Trigger-Regel mit Hochlader-Zweig (#2140, bricht ohne ① selbst ab) → ③ Hochlader der Altbelege nachtragen (vertraulich01_hochlader_nachtragen.py --apply). Danach Gegenbeweis mit zwei Mitarbeiter-Konten. Kanon: KONZEPT_VERTRAULICHKEIT_GEHEIMHALTUNG.md §4.

⑨ Wo eine Freigabe hängt: an den Ordnern der Projektgliederung, nicht am Speicherpfad (RECHTE-UX#01 mit TOWER#57 · ✅ JC-Entscheid 19.09., JE-175)

JCs Frage (19.09.): Kommt der Nutzer mit einem „Unterprojekt“ klar? Üblich ist die Ordnerstruktur mit Freigabe für Kreise. Er hat recht, und die Ordner gibt es als Konzept schon: die nummerierte Projektgliederung des Dokumentalisten. Vorlage: Projektordner und Rechte (löst Frage 6 der Rechte-Vorlage neu).

⑩ Welche Dokumentarten sieht der Buchhalter-Kreis? (Register #2150 · offen, JC 19.09. geparkt)

Die Vorlage, über die noch entschieden wird:

Lage. Der Kreis sieht heute alles seiner Entität bis vertraulich; ② sagt denselben Ist-Zustand. Ursprünglich war „Belege und Verträge“ versprochen — die Wand filtert nach keiner Dokumentart — und zwar an zwei Stellen: im Kreis-Zweig selbst, und im allgemeinen Mitglieder-Zweig, der jedem Mitglied des Mandanten alles bis intern zeigt und die Rolle nicht unterscheidet. Ein Filter nur im Kreis würde über den zweiten Zweig umgangen. Gemessen 19.09.: es gibt heute kein Buchhalter-Konto — noch kein Abfluss, aber das Versprechen hat keine Wirkung. Angebote und Protokolle haben heute keine eigene Dokumentart (vorhanden sind 9 Werte, gemessen); sie stehen unter Sonstiges — oder unter einer falschen Art (s. Grenze unten).

⑦ Stand je Punkt

§4Die Rechte-Matrix — Rolle × Status → Konsequenz

Lesart: was darf diese Rolle mit einem Doc dieses Status, innerhalb der berechtigten Entität? (Governance §3, gekürzt — SSOT hat die volle Matrix inkl. RAG-Abruf-Zeilen.)

Owner-Bypass (der Eigentümer nutzt ALLE seine Docs aller Stufen — auch in der KI) und fail-closed (Status NULL = wie 🔴 streng für Andere) sind die zwei Anker der Matrix. Wie Änderungen ablaufen (Gates, Audit, Löschen) → §7 Lebenszyklus.

§4bDie Navigations-Matrix — Rolle × Screen (wer sieht welches Menü)

§4 sagt, was eine Rolle mit einem Daten-Stück darf. Diese Matrix beantwortet die andere Frage (JC 10.08.): welche Menüpunkte / Screens eine Rolle überhaupt zu sehen bekommt. Kern-Satz: Ein Externer eines Projekts sieht NICHT das ganze TGV-Menü — er sieht seinen Projekt-Arbeitsraum, sonst nichts. Zwei Achsen, die zusammenspielen: die Sicht-Klasse (dieser §) entscheidet, welche Screens erscheinen; §4 entscheidet, welche Datenzeilen darin sichtbar sind.

Fünf Sicht-Klassen — Screens werden NICHT einzeln aufgezählt (eine Liste veraltet beim nächsten SCREEN-COMPOSER-Screen), sondern in wenige Klassen einsortiert. Jeder Screen deklariert seine Klasse (Vertrag); die Shell zeigt ihn nur, wenn die Rolle die Klasse trägt.

Die gezeigten Menüpunkte = Vereinigung der Klassen, die die Mitgliedschaften des Aufrufers tragen. Ein Nutzer mit nur einer Projekt-Rolle (kein Mandant-Recht) bekommt allein T1 — der Rest des Menüs entsteht gar nicht. Default-Deny: trägt die Rolle die Klasse nicht, wird der Eintrag NICHT gerendert (nicht nur ausgegraut).

§5Geschützte Tabellen — die RLS-Realität (Umsetzungswahrheit)

Nicht „RLS ist an" als Behauptung, sondern je Kern-Tabelle der Code-verifizierte Stand (Migrationen in 05_SCHEMA/). Grundnetz seit Mig 037: RLS wird auf JEDER public-Tabelle erzwungen (dynamischer Loop) — seither wird das grobe Netz Tabelle für Tabelle durch schärfere Policies ersetzt:

§5aDie DREI Sichtbarkeits-Achsen — gemessen, nicht behauptet

SICHERHEIT#05 hat am 05.09.2026 alle pg_policies der laufenden DB gelesen (nicht die 05_SCHEMA/*.sql-Dateien) und jede Tabelle einer Achse zugeordnet. Anlass: das Konzept nannte für documents zwei Wege (Mandant ODER Projekt-Gast) — die Frage war, ob eine dritte Achse fehlt. Antwort: die dritte Achse ist konzipiert, aber live auf NULL Tabellen.

Regale, über die diese Liste gilt (R-193): ① pg_policies + pg_class.relrowsecurity der laufenden Supabase-DB, gelesen über 08_OPS/db_query.py · ② 05_SCHEMA/*.sql (271 Dateien) · ③ public.tgv_migrations. NICHT gelesen: Views und deren security_invoker-Flag · Trigger und Funktionen ausserhalb der genannten RLS-Helfer · n8n-Workflows · Endpoint-Guards der App-Schicht (die als service_role laufen und RLS per Design umgehen, s. §6). Eine Aussage über diese vier Regale ist hier NICHT enthalten.

Grundnetz bestätigt: 141 von 141 public-Tabellen haben RLS aktiv, keine einzige mit RLS aus; eine Tabelle hat RLS an und null Policies (= vollständig zu, fail-closed).

Die Naht — wo zwei richtige Regeln eine Menge erzeugen, die keiner hat

§6Sicherheits-Mechanismen — WIE jede Grenze strukturell gebunden ist

Analog zur Seitenbau-Lehre („Kanon strukturell binden, nie ans Gedächtnis"): jeder Mechanismus nennt die Ebene, an der er verriegelt ist — Schema, RLS, Guard am Wirkort oder Modul-Vertrag. Das ist die Antwort auf „WIE ist es gesichert?":

Lesewege × Decke × Wache — jeder Weg, auf dem ein Inhalt den Dienst verlässt (Register #2179, Stand 19.09.2026)

Die EINE Liste für alle Bahnen (VERTRAULICH#01 pflegt sie; die rag_chunks-Wege hat RAG#01 gegen master nachgeschlagen, Bauplan #2094 P3). Ein Weg ohne Wache ist ein Befund, keine Zeile zum Weglassen. „CI ㊵“ = Schritt ㊵ in .github/workflows/konformitaets-guards.yml, „skipped“ gilt dort als rot.

§7Lebenszyklus (Ebene ③) — ändern, vergessen, löschen

Status ändern mit Leitplanken: Hochstufen jederzeit („im Zweifel strenger") · Runterstufen nur Admin/Eigentümer mit Bestätigungs-Dialog + Audit · der KI-Dokumentalist schlägt vor, entscheidet NIE · jede Änderung zeigt sofort die Konsequenz („wer verliert/gewinnt Zugriff"). Vor Runterstufen/Löschen steht die Awareness-Session als menschliches Gate (§8).

§7 löscht ein Dokument. Wenn eine Person verlangt, dass ihre Daten gelöscht werden, gilt §7a: Sie steht an vielen Orten, und jeder Ort hat eine eigene Regel.

§7aPersonen löschen (DSGVO Art. 17) — Kontakte, Betroffene, User (Register #2145, 19.09.2026)

⛔ Offene Vorfrage (JC-Ball, Register #2241): „Löschen" heißt heute zweierlei — endgültig (02.09.) oder umkehrbar markiert (05.09.), und beide Formen sind schon benutzt worden. Welche davon Hausform wird, entscheidet JC in der Vorlage „Löschen — welche Form?" (Anlass: die Test-Uploads, JE-182). Bis dahin gilt für Personen weiter die Stufenfolge aus §7.

Ziel (JC 19.09.): Kontakte und User können ihre Daten löschen lassen. Das gilt in jedem Mandanten und auch in einer gesamten Kontakt-Datenbank; die Mandanten bleiben dabei getrennt. Schon entschieden, hier nur angewandt: das Regime je Kontakt-Klasse (GATE_A_KONTAKTE.md §6 · §9.2(c)), die Felder rechtsgrundlage + loesch_regime je Zeile (Mig 251:61-62), die Lösch-Stufen ①②③ (§7), das Lösch-Audit „dass · was · wann · wer · Rechtsgrund, nie der Inhalt“ (KONZEPT_VERTRAULICHKEIT §5), der Fristen-Kanon (08_OPS/aufbewahrung_kanon.yaml, JC 03.09.) und „Vorschau → apply nur mit freigegeben_von“ (mail_versand.senden).

① Was wir müssen — die Pflichten (Quellen abgerufen am 19.09.2026)

Quellen: DSGVO · § 257 HGB · § 147 AO · § 35 BDSG · L123-22 · L102 B LPF · CNIL Referenzrahmen · EDPB-Bericht Löschrecht 2025 · SDM-Baustein 60. ⛔ Keine Rechtsberatung: Die Fristen testiert der Steuerberater (C3) bzw. der expert-comptable (C4), wie im Kanon vermerkt (testiert_von ist leer).

② Wer entscheidet — Verantwortlicher je Zeile

③ Der Ablauf — fünf Schritte, einer davon ist menschlich

⛔ Das „Wie“ ist EIN Wert, kein Code-Zweig: Ob ein Fundstück markiert oder endgültig gelöscht wird, liest die Vorschau an genau einer Stelle aus der Konfig-Fläche (tunable_params.dsgvo01_hausform). Bis JC die Vorfrage beantwortet (Vorlage #2241 „Löschen — welche Form?", liegt JC vor; der Link folgt mit ihrem Merge) steht dort offen, und jedes Fundstück sagt: was geschehen soll, steht fest — wie, noch nicht. Damit wird JCs Antwort eine Zeile in der Konfig und kein Umbau.

④ Wo die Person steht — Datenart × Entscheid (Aufbau nach DIN 66398 / SDM-Baustein 60)

⑤ Mandanten-Wand — dieselbe Person in mehreren Mandanten

Ein Mensch, der bei C3 und bei C4 bekannt ist, steht dort in zwei getrennten Zeilen (contacts.mandant_id NOT NULL, 251:52). Es gibt keine gemeinsame Sammlung. Jeder Mandant löscht nur seine Zeilen. Die Suche der Vorschau läuft nur über die Mandanten, in denen der Aufrufer eine Rolle hat (my_mandant_ids aus user_mandant_roles), Default-Deny. Die Ergebnisse stehen je Mandant getrennt und werden je Mandant entschieden, denn die Fristen sind verschieden (DE ≠ FR). Betrifft eine Anfrage mehrere Mandanten, leitet der Betreiber sie an jeden Verantwortlichen weiter; er löscht nicht über die Wand hinweg. Gegenbeweis (Pflicht vor Merge): Ein Viewer auf c3 sucht eine E-Mail, die nur in c4 steht, und bekommt 0 Treffer und keinen Hinweis, dass es sie woanders gibt.

⑥ Sperrliste — damit eine gelöschte Person nicht zurückkommt

Ohne Sperrliste legt der nächste Signatur-Vorschlag oder Import die Person wieder an (Modelle: HubSpot sperrt die Adresse nach der DSGVO-Löschung, Brevo und Mailchimp ebenso). contact_suppressions hält je Mandant nur einen HMAC des Kanal-Werts mit einem eigenen Schlüssel je Mandant, keinen Klartext und keinen Namen (CNIL „liste repoussoir“). Getrennte Schlüssel bedeuten: Dieselbe Adresse hat in c3 und c4 verschiedene Werte, die Sperrliste kann also kein mandantenübergreifender Personen-Index werden. Wirkt in contact-propose (Signatur und Import laufen beide dort durch) und vor jedem Werbe-Versand. Wirkt nicht auf Korrespondenz (Rechnung, Vertrag). ⛔ Eine Sperre hat zwei mögliche Wirkungen, und sie zu vermischen wäre teuer: werbung heißt „die Person will keine Werbung" (Art. 21 (3)) — Rechnungen gehen weiter raus. zustellung heißt „der Versand-Anbieter nimmt die Adresse nicht mehr an" — dann kommt auch die Rechnung nicht an, sie sieht bei uns nur so aus. Brevo führt eine solche Liste und wendet sie auch auf Transaktionsmails an (MAIL#02 §V10e ② · §X5b, über KONTAKTE#01 21.09.); sie wird als grund='anbieter_sperre' gespiegelt und trägt zwingend wirkung='zustellung'. ⭐ Sonst beantwortet eine Zeile zwei Fragen — „darf ich werben?" ist eine Rechtsfrage, „kommt es an?" eine Tatsache, und eine unzustellbare Rechnung fällt niemandem auf, bis jemand mahnt. Solange der Kontakt existiert, ist contact_consents die Wahrheit. Die Sperrliste ist das, was die Löschung überlebt. Deshalb schreibt eine Abmeldung oder Beschwerde in einem Schritt beides: eine neue Consent-Zeile widerrufen (MAIL#02 §J5 V1) und den Sperreintrag. Bei der Löschung verschwindet die Consent-Zeile, der Sperreintrag bleibt. Die Sperrliste des Versand-Anbieters wird hier gespiegelt (MAIL_VERSAND_CONCEPT §V10e ②). Ein Hard-Bounce ist kein Sperrgrund: Er setzt den Kanal auf veraltet (§J5 V3) und hält dort jeden Versand auf. Gesperrt wird nur Werbung (Mail-Klasse 4, §J2); Korrespondenz, Buchhalter-Versand und Systempost prüfen die Sperrliste nicht.

⑦ KAI: „Lösche alle Daten von Person X“

KAI ruft person-loeschen als Vorschau auf und zeigt die Fundstücke je Mandant als EINE Tabelle (K-33) mit Entscheid und Frist je Zeile. Darunter steht ein Knopf „Löschung freigeben“, der dem Menschen gehört. KAI sagt nie „gelöscht“, bevor apply gelaufen ist, und nie „es gibt nichts“, ohne die geprüften Orte zu nennen (R-193). Gesperrte Stücke erscheinen mit Grund und Datum: „Rechnung 2024 bleibt gesperrt bis 31.12.2032, § 147 AO“.

⑧ Bauplan in Paketen

⑨ Workshop DSGVO/AVV — nach dem Funktions-Gate (JC 19.09.)

§7bEinwilligung beim Zugang — ein Bildschirm für alle Neuen (Register #2153, JC 19.09.2026)

JCs Ziel (sinngemäß): Wer neu in TGV kommt oder Dokumente erhält, hakt beim ersten Zugang alles auf einmal ab: Datenschutz, Nutzungsbedingungen, Widerruf und die Einwilligung, vom Mandanten Werbung zu erhalten. Das soll konform, transparent, extrem einfach und zeitsparend sein, damit TGV und die Mandanten ihr Geschäft entwickeln können. JCs Wunsch dabei: „niemanden reinlassen, der nicht eingewilligt hat, Werbung zu erhalten“.

① Die ehrliche Antwort: Den Zugang an die Werbe-Einwilligung zu binden, ist nicht erlaubt

Was stattdessen geht und JCs Ziel am nächsten kommt: EIN Bildschirm und EIN Klick auf „Weiter“. Pflicht ist nur, was für den Zugang wirklich nötig ist. Die Werbung wird so angeboten, dass möglichst viele freiwillig Ja sagen. Wo das Recht ein Opt-out erlaubt, wird es genutzt.

② Die Maske: was Pflicht ist, was freiwillig, was nur ein Link

Ist eine Bestätigungsmail (Double-Opt-in) nötig? Das Double-Opt-in beweist, dass der Inhaber der Adresse selbst eingewilligt hat (BGH I ZR 164/09, DSK Ziff. 3.3). Bei TGV kommt jeder über einen Magic-Link an genau diese Adresse herein (core_shell.html doMagicLink, shouldCreateUser:false). Das Kästchen wird also in einer Sitzung angehakt, die den Besitz der Adresse schon bewiesen hat. ⇒ Empfehlung: keine zweite Mail — mit einer Grenze (MAIL#02): Das gilt nur, wenn die Einwilligung (a) für genau die Login-Adresse erteilt wird und (b) diese Adresse bestätigt ist, also email_confirmed_at gesetzt ist oder die Sitzung per Magic-Link/Code zustande kam. AUTH #2110 baut auch eine Passwort-Anmeldung, und wer so angemeldet ist, hat den Besitz des Postfachs in dieser Sitzung nicht gezeigt. Für eine andere Adresse und für unbestätigte Adressen gilt das Double-Opt-in. Der Login ist sonst die Bestätigung, protokolliert mit Sitzung, Anmeldeart und Zeitpunkt. ⛔ Das ist eine Wertung und kein Urteil; ein Anwalt prüft beide Fälle vor dem Bau.

③ Wo die Maske erscheint — EIN Tor für alle Wege

Gemessen am 19.09. (Zeilen gemessen an origin/master 19.09. abends):

• Login: Magic-Link core_shell.html:23602 (doMagicLink), nach dem Login onAuth :23620. Heute gibt es keinen ersten Schritt, kein Kästchen und keinen Rechtstext; die Zeile „jederzeit löschbar“ ist eine Behauptung ohne Link.
• Einladung: invite-user app.py:7010 → GoTrue /auth/v1/invite :7033. Die Mail verschickt Supabase Auth mit seiner Vorlage „Invite user“, ohne TGV-Text.
• Dokumente: Links sind signiert, laufen nach 10 Minuten ab und werden nur mit Konto vergeben (file-url app.py:5793). Auch die Einzelfreigabe verlangt ein Konto (freigabe :5527). Öffentliche Links gibt es nicht.

⇒ Jeder Weg führt über den Login. Das Tor sitzt deshalb an EINER Stelle: in onAuth, vor H.onSession. Fehlt die Zustimmung zur aktuellen Fassung der Nutzungsbedingungen, erscheint die Maske. Sonst gibt es keinen Zugang, auch nicht zu einem geteilten Dokument. Ändert sich die Fassung, erscheint die Maske noch einmal, nur mit den Änderungen. Die Maske zeigt Werbe-Kästchen nur für die Mandanten, in denen die Person eine Rolle hat (my_mandant_ids). Die Namen anderer Mandanten sieht sie nie.

④ Das Vertragswerk — wer mit wem, welches Papier

Vorbild im Haus für Kästchen mit Zeitstempel-Protokoll und Rechtstext-Gerüst: 00_LEITDOKUMENT/KONZEPT_WEBSITE_FACTORY.md:14,19 (drei Pflicht-Kästchen, Skill website-legal mit Jurist-Gate). ⛔ Die Texte selbst schreibt ein Anwalt (DE + FR); TGV baut nur die Form.

⑤ Bildschirm-Vorschau (Empfehlung A · rechts Variante B für einen FR-Mandanten)

legal_name ist ein Platzhalter: Das Tor gilt je Mandant, der Name kommt aus entity_signatures.legal_name. Beispiel C3: „CONVIS Consult & Marketing GmbH“, C4: „CONVIS Consult & Marketing SARL“. Ein Kürzel steht nie in einer Einwilligung, denn dort muss der Verantwortliche mit seinem Rechtsnamen genannt sein (EDPB Rn. 65). Die Form ist dieselbe wie auf der Login-Karte (#loginView), in derselben Sprache wie der Login-Schalter DE/FR/EN. Auf dem Handy liegen die Kästchen untereinander, die Trefferfläche ist die ganze Zeile. Den Knopf „Weiter“ gibt es EINMAL. Er ist aktiv, sobald das Pflicht-Kästchen gesetzt ist; die freiwilligen Kästchen ändern daran nichts.

⑥ Bauplan (nach JC-Wort und Rechtstexten)

⑦ Entscheidungsvorlage an JC

Quellen (abgerufen am 19.09.2026): EDPB 05/2020 · DSK OH Werbung · CNIL Prospection · § 7 UWG · § 305 BGB · § 310 BGB · OLG Frankfurt 6 U 6/19 · Google Absender-Regeln (One-Click). Weitere Rechtslage zum Anschreiben von Kontakten: Datenfluss §7b. ⛔ Keine Rechtsberatung.

§7cDatenhoheit — Export und Löschung aus demselben Inventar · Data Governance Contract · Paketplan (konsolidierter JC-Entscheid 04.10.2026)

Produktversprechen (JE-196): Der Mandant muss TGV verlassen können und seine Daten vollständig, verständlich und weiterverwendbar zurückerhalten. Geschäftsdaten und im Auftrag erzeugte Ergebnisse gehören zum Datenbestand des Mandanten; Betroffenenrechte bleiben unberührt; Kivisai erzeugt keine künstliche Datenbindung. Quelle: JC_ENTSCHEID_TGV_DATENSCHUTZ_DATENHOHEIT_2026-10-04.md §19–§22, §27–§30.

§8Haftung & Betriebsmodi — Verwaltet vs. Souverän

Der Haftungs-Hebel der Vermarktung (AVV/Auftragsverarbeitung): zwei Betriebsmodi, die Awareness-Session ist das menschliche Gate vor Runterstufen/Löschen. Struktur, Fahrplan (M1–M6) und Onboarding → 🏢 Multi-Mandant.

AVV + Lösch-Garantie (§7) sind Verkaufsargument UND Haftungs-Pflicht — beide hängen an diesem Modell. Grundpfeiler: Default-Deny · fail-closed · vollständiges Audit · „im Zweifel strenger". Sub-Processor-Transparenz (wer verarbeitet was, wo) lebt in der Security-Baseline (TGV_CORE_V1_SECURITY_PRIVACY_BASELINE.md).

§9Wie es FIRST entsteht & dauerhaft bleibt — die Sicherheits-Lernschleife

„First" heißt: die Grenze entsteht mit dem Schema, nicht nachträglich. Analog zur Seitenbau-Lernschleife hat Sicherheit ihre eigene Kette — jede Stufe bindet strukturell (Anti-Amnesie), nichts hängt am Gedächtnis:

§10⚠️ Ehrliche Lücken-Landkarte (Stadium-ehrlich)

„Dauerhaft gesichert" ist nur ehrlich mit den offenen Punkten sichtbar — jede Lücke hat eine Owner-Lane. (Früher stand hier auch das rag_chunks-Retrieval-Gate — seit 13.07. gebaut + Gate-bewiesen, §6.)

§11Der EU-souveräne Stack — von der DB bis Mistral

Die Garantie an Mandanten (Ziel-Satz): „Ihre Daten gehen NICHT an US-Firmen und werden nicht zum Training genutzt." Das ist Wettbewerbsvorteil, kein Detail — und darf erst versprochen werden, wenn jede Zeile hier grün ist. Grafisch: §1-Graph, Modus 🇪🇺 EU-Stack (Datenfluss mit EU/US-Färbung). Ehrlicher Stand je Komponente: