Datenschutzerklärung

Datenschutzerklaerung

ENTWURF — nicht rechtsgeprueft. Dieser Text wurde von einem Sprachmodell verfasst und ersetzt keine Rechtsberatung. Vor jeder Veroeffentlichung muss er von einer Anwaeltin oder einem Anwalt geprueft werden. Stand: 2026-08-09.

Fassung 1 vom 2026-08-31. Sie sagt, welche Fassung dieser Erklaerung gilt — nicht, dass sie geprueft waere. Die Angabe ist noetig, weil bei der Anmeldung festgehalten wird, welcher Fassung zugestimmt wurde (§952.5); ein Beleg ohne Fassung belegt nur den Zeitpunkt. Der Wortlaut dieser Zeile steht zugleich in src/zustimmung.mjs, und ein Riegel haelt beide gegeneinander.

0. Wozu dieser Text da ist — und was an ihm der wichtigste Teil ist

Diggi ist eine Orchestrierungsmaschine. Der Kern des Produkts ist, dass Ihre Eingaben nicht von einem Modell beantwortet werden, sondern von vielen — und diese Modelle betreiben Dritte. Damit ist die entscheidende Auskunft dieser Erklaerung nicht, was wir mit Ihren Daten machen, sondern wohin sie gehen. Das steht in Abschnitt 5, und dort ist bewusst eine leere Tabelle: welche Anbieter tatsaechlich eingesetzt werden, entscheidet die Einrichtung der Anlage und nicht dieser Text. Wer die Tabelle nicht ausfuellt, hat keine Datenschutzerklaerung, sondern eine Ueberschrift.

1. Verantwortlicher

Name:      Lukas Hauenstein
Anschrift: Dr.-Roß-Str. 2A, 95503 Hummeltal, Deutschland
E-Mail:    [email protected]

Verantwortlicher im Sinne von Art. 4 Nr. 7 DSGVO.

Zur fehlenden Telefonnummer. Die Zeile „Telefon" ist am 2026-08-18 gestrichen worden. Grund: Lucky hat entschieden, dass es keine Nummer gibt, die veroeffentlicht werden soll. Im Impressum steht an derselben Stelle stattdessen ein offener Punkt, weil dort Artikel 246a § 1 Abs. 1 Satz 1 Nr. 3 EGBGB fuer Verbrauchervertraege im Raum steht (Impressum, offene Frage O-2). Faellt diese Klaerung so aus, dass eine Nummer veroeffentlicht werden muss, gehoert sie auch hier wieder hinein.

Datenschutzbeauftragter: nicht benannt. Ob eine Benennung nach Art. 37 DSGVO in Verbindung mit § 38 BDSG noetig ist, ist hier nicht geprueft — siehe offene Frage O-1.

1.1 Zwei Betriebsarten, und nur bei einer sind wir Verantwortlicher

Diggi kennt drei Betriebsarten (eigen, test, gehostet, siehe src/konto.mjs). Fuer den Datenschutz zerfallen sie in zwei Faelle, und der Unterschied ist keine Formulierung:

Im Eigenbetrieb verarbeitet der Betreiber Ihre Inhalte nicht; Ihr Rechner spricht direkt mit den Anbietern, deren Schluessel Sie eingetragen haben. Diese Erklaerung beschreibt dann nur, was die Software tut — nicht, was wir tun. Die Verantwortung gegenueber den Modellanbietern liegt in diesem Fall bei Ihnen.

Alles Weitere in dieser Erklaerung gilt fuer den gehosteten Betrieb und die Testkonten, soweit nicht ausdruecklich etwas anderes dabeisteht.

2. Betrieb der Webseite

2.1 Server-Logdateien

Erhobene Felder:        <OFFEN 2026-08-18: was der Webserver tatsaechlich
                        protokolliert - Lucky 2026-08-18: "recherchiere" bzw.
                        "branchenueblich"; zu recherchieren und zu belegen. Zu
                        messen ist der Webserver im Betrieb, nicht der Code>
Speicherdauer:          <OFFEN 2026-08-18: Speicherdauer der Logs in Tagen -
                        Lucky 2026-08-18: "recherchiere" bzw. "branchenueblich";
                        zu recherchieren und zu belegen>
Hoster:                 <OFFEN 2026-08-18: Name, Anschrift, Sitzland - Lucky:
                        "machen wir spaeter wenn Gewerbe steht">
Auftragsverarbeitung:   <OFFEN 2026-08-18: Vertrag nach Art. 28 DSGVO
                        geschlossen ja/nein - Lucky: "machen wir spaeter wenn
                        Gewerbe steht">

Rechtsgrundlage voraussichtlich Art. 6 Abs. 1 Buchst. f DSGVO (berechtigtes Interesse an einem sicheren Betrieb). Ohne die tatsaechliche Konfiguration ist das eine Vermutung und keine Auskunft — deshalb steht sie als Luecke.

2.2 Speicherung auf Ihrem Geraet

Diggi legt Einstellungen im Browser ab (etwa Farbwelt und Sprache). Solche Zugriffe auf Ihr Endgeraet regelt § 25 TDDDG: sie brauchen eine Einwilligung, ausser sie sind unbedingt erforderlich, damit ein ausdruecklich gewuenschter Dienst zur Verfuegung gestellt werden kann (§ 25 Abs. 2 Nr. 2 TDDDG).

Gemessen am 2026-08-31 in ui/index.html, ui/landing.html und src/auth.mjs — nicht geschaetzt, sondern an den 30 Schreibstellen und den beiden Cookie-Zeilen abgezaehlt.

Bis zum 2026-08-31 nannte diese Zeile 28 Schreibstellen und als Messorte nur ui/index.html und src/auth.mjs. ui/landing.html fehlte — also ausgerechnet die Seite, die jeder Besucher zuerst sieht und die den allerersten Eintrag ueberhaupt anlegt, vor jeder Anmeldung. Der Fehler war nicht die Zahl, sondern der Messort (plan/ERSTTAG.md, Befund E-3).

Zwei Cookies, beide technisch notwendig:

Der uebrige Speicher liegt in localStorage und verlaesst Ihren Browser nie — er wird nicht an den Server gesendet und ist fuer uns nicht lesbar. Es sind ausschliesslich Bedienvorlieben:

Einwilligungsbanner noetig: nein. Nach § 25 Abs. 2 Nr. 2 TDDDG ist keine Einwilligung noetig, wenn die Speicherung unbedingt erforderlich ist, damit ein vom Nutzer ausdruecklich gewuenschter Dienst funktioniert. Beides trifft hier zu: die Cookies halten die Anmeldung, der uebrige Speicher haelt Ihre eigenen Einstellungen. Es gibt keine Reichweitenmessung, keine Analyse und kein Werkzeug eines Dritten — nachgesehen am 2026-08-30: Diggi laedt keinerlei fremdes Skript zur Zaehlung von Besuchern.

Solange ausschliesslich unbedingt erforderliche Eintraege gesetzt werden, ist nach dem Wortlaut des § 25 Abs. 2 Nr. 2 TDDDG kein Einwilligungsbanner noetig. Ob das fuer jeden einzelnen Eintrag zutrifft, muss anhand der Liste geprueft werden — siehe offene Frage O-2.

3. Konto und Anmeldung

Bei der Registrierung legen Sie eine E-Mail-Adresse und ein selbstgewaehltes Passwort fest (src/anmeldung.mjs, src/passwort.mjs). Zusaetzlich koennen Sie sich mit einem Einmalcode per E-Mail anmelden; der Code lebt zehn Minuten, gilt einmal und wird nach drei Fehlversuchen ungueltig.

Ihr Passwort wird nicht gespeichert - nur eine Ableitung davon. Diggi rechnet es mit scrypt und einem je Konto zufaelligen Salz in einen Pruefwert um (src/passwort.mjs); aus diesem Wert laesst sich das Passwort nicht zurueckrechnen. scrypt ist absichtlich langsam und speicherhungrig, damit massenhaftes Durchprobieren teuer bleibt.

Korrigiert am 2026-08-30. Hier stand bis dahin „ein Passwort wird nicht gespeichert". Das war vor §938 richtig; seither vergibt jeder Nutzer eines, und der Pruefwert dazu ist eine Verarbeitung, die in dieser Tabelle stehen muss. Eine Datenschutzerklaerung, die eine Verarbeitung nicht nennt, ist an dieser Stelle falsch und nicht bloss unvollstaendig.

Was hinter „bis zu 30 Tage" steht - gemessen am 2026-08-30, nicht angenommen.

Die Frist ist eine Obergrenze, keine Zusage. Gemessen an Diggis Quelltext: es gibt keinen eingebauten Sicherungslauf. Kein Befehl legt Kopien an, kein Zeitgeber raeumt sie weg; die beiden Treffer fuer „snapshot" im Code sind Zustandsabzuege des Budgets und keine Datensicherung. Wird ein Konto geloescht, verschwindet sein Zustandsverzeichnis sofort und vollstaendig.

Ungemessen bleibt (§118.2), ob die darunterliegende Anlage bei Google Cloud Momentaufnahmen fuehrt. Das ist eine Einstellung im Cloud-Konto des Betreibers, kein Teil dieser Software - und sie von hier aus zu behaupten waere dasselbe wie sie zu bestreiten: eine Angabe ohne Messung.

Deshalb steht hier eine Obergrenze und keine Dauer. Sie nennt, was laengstens passiert, nicht was passiert. Sobald ein Sicherungslauf gebaut ist, gehoert an diese Stelle seine gemessene Aufbewahrungsdauer - und dieser Absatz weg.

Der Satz stand hier bis zum 2026-08-30 anders: er beschrieb Sicherungen als vorhanden. Ich hatte ihn geschrieben, ohne nachzusehen, ob es sie gibt.

Der Versand des Codes laeuft ueber den in Abschnitt 5 zu benennenden Mailversender.

4. Welche Inhalte Diggi verarbeitet

Diese Liste folgt dem Code, nicht einer Vorlage. Jede Zeile hat eine Datei, in der sie steht.

Rechtsgrundlage fuer all das ist im gehosteten Betrieb die Erfuellung des Nutzungsvertrags, Art. 6 Abs. 1 Buchst. b DSGVO.

Speicherdauer: <OFFEN 2026-08-18: Speicherdauer je Inhaltsbereich — Lucky: "recherchiere" bzw. "branchenueblich"; zu recherchieren, zu belegen und dann zu entscheiden. Eine geschaetzte Frist waere hier eine Zusage>. Dass Chats, Gedaechtnis und Medien anhaengend und dauerhaft geschrieben werden, ist eine Bauentscheidung (nichts geht verloren, auch abgebrochene Antworten nicht). Wie lange sie aufgehoben werden, ist dagegen eine Entscheidung des Betreibers — und muss getroffen werden, bevor der Dienst oeffnet.

4.1 Besondere Kategorien und fremde Daten

Sie koennen Diggi Texte, Dateien und Mails geben, die Gesundheitsdaten, Gewerkschaftszugehoerigkeit oder aehnliche Angaben nach Art. 9 DSGVO enthalten, und Sie koennen ihm Daten anderer Menschen geben. Beides geht dann an die in Abschnitt 5 genannten Drittanbieter. Wir pruefen den Inhalt Ihrer Eingaben nicht und koennen es technisch nicht. Was Sie hineingeben, verantworten Sie — und wenn es Daten Dritter sind, brauchen Sie dafuer eine eigene Grundlage.

Entschieden am 2026-08-30: ausgeschlossen. Diggi ist nicht dafuer gebaut, besondere Kategorien personenbezogener Daten im Sinne von Art. 9 DSGVO zu verarbeiten - also Angaben ueber Gesundheit, Herkunft, religioese oder weltanschauliche Ueberzeugungen, Gewerkschaftszugehoerigkeit, Sexualleben oder biometrische Daten. Es gibt keine gesonderte Einwilligung dafuer, und es wird auch keine eingeholt.

Was das heisst und was es nicht heisst. Es heisst: geben Sie solche Daten hier bitte nicht ein. Es heisst nicht, dass technisch etwas sie aufhaelt - wer im Chat ueber seine Krankheit schreibt, hat es getan, und der Text daneben haelt niemanden davon ab. Deshalb steht diese Zeile hier zusammen mit dem Hinweis aus Abschnitt 5: was Sie eingeben, geht an den Modellanbieter, den Sie gewaehlt haben. Das gilt fuer jede Eingabe, und fuer diese besonders.

Sollte spaeter ein Modul hinzukommen, das solche Daten ausdruecklich verarbeiten soll, braucht es eine eigene, ausdrueckliche und jederzeit widerrufliche Einwilligung - und dieser Absatz muss vorher geaendert werden, nicht danach.

4.2 Das Nutzungszaehlwerk zaehlt Funktionen, nicht Inhalte

src/nutzung.mjs schreibt je Ereignis eine Zeile mit welcher Funktion, wann, von welchem Konto — und ob sie durchging oder an einem fehlenden Anspruch scheiterte. Kein Prompt, kein Dateiname, kein Projekttitel. Der Zweck ist, ein Preismodell auf gemessene Gleichzeitigkeit stuetzen zu koennen statt auf Schaetzungen.

Rechtsgrundlage voraussichtlich Art. 6 Abs. 1 Buchst. f DSGVO. Der Zaehler enthaelt trotzdem personenbezogene Daten, weil die Zeile das Konto nennt.

Dieser Zaehler hat eine Folge ausserhalb des Datenschutzrechts. Weil er einen Zweck verfolgt, der ueber die Leistungserbringung hinausgeht — die Vorbereitung eines Preismodells —, koennte er dazu fuehren, dass die kostenlosen Testkonten als Verbrauchervertraege nach § 312 Abs. 1a und § 327 Abs. 3 BGB gelten, mit Widerrufsrecht und Maengelrechten. Die Frage ist am 2026-08-09 anhand des Gesetzeswortlauts ausgearbeitet worden; das Ergebnis steht in recht/GRATISKONTEN.md und lautet unklar. Wer erwaegt, den Zaehler fuer Testkonten abzuschalten, entscheidet damit zugleich eine verbraucherrechtliche Frage — siehe dort G-3.

4.3 Was Diggi ausdruecklich nicht tut

• Kein Zusammenfassen beim Speichern. Gedaechtnis und Chatverlauf werden woertlich abgelegt; es laeuft kein Modell darueber, das verdichtet. Das ist der Grund, warum aus einer vorsichtigen Bemerkung keine Behauptung wird.
• Kein Zwischenspeicher fuer das Postfach (Abschnitt 6).
• Kein Rueckauslesen von Zugangsdaten (Abschnitt 7).

5. Drittanbieter von KI-Modellen — der Kern dieser Erklaerung

Was passiert. Wenn Sie etwas eingeben, geht es an ein oder mehrere Modelle von Drittanbietern. Im Teamlauf und im Wettstreit geht dieselbe Eingabe an mehrere Anbieter gleichzeitig. Welche das sind, haengt davon ab, welche Zugaenge in der Anlage eingerichtet sind und welcher Pool die Anfrage bekommt.

Diggi kann technisch unter anderem folgende Anbieter ansprechen — die Liste ergibt sich aus den Adaptern in config.example.json und ist eine Liste des Moeglichen, keine Aussage darueber, was tatsaechlich laeuft: OpenAI-kompatible Endpunkte, Anthropic, Google (Gemini und Vertex AI), Mistral, Cohere, OpenRouter, Hugging Face, Cloudflare Workers AI, Groq, Cerebras, NVIDIA, SambaNova, Scaleway, DeepInfra, Fireworks, Baseten, Alibaba, Z.ai, OVH, Pollinations sowie lokal betriebene Modelle.

Die folgende Tabelle ist auszufuellen — Zeile fuer Zeile, fuer jeden Anbieter, der in der veroeffentlichten Anlage wirklich eingerichtet ist. Anbieter, die nicht eingerichtet sind, gehoeren nicht hinein.

## ⚠ SPERRVERMERK — dieser Text darf ohne die ausgefuellte Tabelle NICHT veroeffentlicht werden

Entscheidung des Betreibers vom 2026-08-09: Die Tabelle bleibt vorerst leer und wird vor dem Livegang ausgefuellt — dann steht fest, welche Anbieter tatsaechlich eingerichtet sind.

Was diese Entscheidung nicht bedeutet. Sie verschiebt den Zeitpunkt, sie senkt nicht die Anforderung. Bis die Tabelle ausgefuellt ist, ist dieser Text kein veroeffentlichungsfaehiger Entwurf, sondern ein Geruest.

Der Grund, in einem Satz: Eine Datenschutzerklaerung ohne benannte Empfaenger ist keine. Der Kern dieser Erklaerung ist nicht, was wir mit Ihren Daten machen, sondern wohin sie gehen — steht so in Abschnitt 0. Wer die Tabelle leer laesst und den Text trotzdem online stellt, veroeffentlicht eine Ueberschrift und nennt sie Datenschutzerklaerung. Das ist schlechter als gar nichts zu veroeffentlichen, weil es Vollstaendigkeit vortaeuscht.

Wer sie ausfuellt, fuellt sie ganz. Zu jeder Zeile gehoeren die fuenf Spalten und die drei Punkte darunter (Rolle nach Art. 28 DSGVO, Drittlandgrundlage nach Kapitel V DSGVO, Training). Eine halb ausgefuellte Zeile ist keine erfuellte Anforderung.

Pruefung vor dem Livegang: Enthaelt die Tabelle noch ein einziges <AUSFUELLEN>, geht der Text nicht online. Der Eintrag steht als L-16 in „Was noch fehlt" mit dem Zeitpunkt „vor Livegang".

### ENTWURF von Diggi — aus den Adaptern gebaut, nicht aus der Live-Anlage, keine Rechtsberatung

Was diese Tabelle ist. Ein von Diggi (Sprachmodell) erstellter Entwurf, abgeleitet aus dem Adapter-Katalog in config.example.json — also aus dem, was die Software ansprechen kann, nicht aus dem, was in der veroeffentlichten Anlage wirklich eingerichtet ist. Die echte Live-Konfiguration steht in config.local.json und wurde hier nicht eingesehen. Der Entwurf ersetzt keine Rechtsberatung; er ist eine Vorarbeit, die Lucky prueft, kuerzt und bestaetigt.

Herkunftskennung je Angabe (§118.2). „belegt" = mit verlinkter Quelle; „ungeprueft — Lucky nachschlagen" = nicht gefunden oder nicht verifiziert, nicht geraten. Angaben zu Sitz, AVV, SCC und Training veralten schnell und sind je Tarif verschieden — jede Zeile ist vor Livegang am Anbieter selbst nachzupruefen.

Die Spalte „Rechtsgrundlage" ist Diggis Vorschlag, kein Befund. Vorgeschlagen ist durchgaengig Art. 6 Abs. 1 Buchst. b DSGVO (Erfuellung des Nutzungsvertrags im gehosteten Betrieb, wie in Abschnitt 4). Das muss Lucky je Anbieter bestaetigen oder korrigieren. Offen bleibt dabei O-4: ob der Wettstreit (dieselbe Eingabe gleichzeitig an mehrere Anbieter) eine gemeinsame Verantwortung nach Art. 26 DSGVO begruendet — dann traegt die Grundlage anders.

Was Lucky an dieser Tabelle noch tun muss. 1. Streichen, was in der Live-Anlage nicht eingerichtet ist — die mit „(Katalog)" markierten Zeilen stehen hier nur als Moeglichkeit. 2. Je verbleibende Zeile die Rechtsgrundlage bestaetigen. 3. Je Zeile die Rolle nach Art. 28 (Auftragsverarbeiter?) endgueltig klaeren und den AVV/SCC am Anbieter pruefen, wo hier „ungeprueft" steht. 4. Je Zeile die Training-Frage klaeren (siehe Kurzstand unter der Tabelle). 5. Den Sperrvermerk erst aufheben, wenn kein ungeprueft und kein <AUSFUELLEN> mehr in Abschnitt 5 steht.

Legende: * = in den Beispiel-Pools von config.example.json aktiv; (Katalog) = im Adapter-Katalog vorhanden, aber in den Beispiel-Pools nicht belegt — nur relevant, wenn in der Anlage eingerichtet.

Kurzstand Training (soweit recherchiert, je Tarif verschieden — vor Livegang am Anbieter bestaetigen): Mistral, fal.ai und Z.ai geben an, ueber die API nicht mit Kundendaten zu trainieren; Anthropic trainiert unter den Commercial Terms nicht; bei Google trennt sich der Weg — Vertex AI trainiert nicht, das kostenlose AI-Studio kann es. Fuer alle uebrigen Anbieter ist die Training-Frage hier ungeprueft und je Anbieter zu klaeren.

Zu jeder Zeile sind ausserdem drei Dinge zu klaeren und in der letzten Spalte festzuhalten:

• Rolle des Anbieters. Auftragsverarbeiter nach Art. 28 DSGVO — dann braucht es einen Vertrag — oder eigener Verantwortlicher. Das ist keine freie Wahl, sondern haengt von den Bedingungen des Anbieters ab.
• Uebermittlung in ein Drittland. Sitzt der Anbieter oder sein Verarbeitungsort ausserhalb des EWR, braucht es eine Grundlage nach Kapitel V DSGVO: ein Angemessenheitsbeschluss nach Art. 45 DSGVO, Standardvertragsklauseln nach Art. 46 DSGVO oder eine Ausnahme nach Art. 49 DSGVO.
• Training. Ob der Anbieter Ihre Eingaben zum Training eigener Modelle verwendet, steht in seinen Bedingungen. Es ist die Frage, die Nutzer am haeufigsten stellen, und sie kann nur je Anbieter beantwortet werden.

Was diese Zeilen sind — und was sie nicht sind. Fruehere Fassungen liessen diese Tabelle bewusst leer, weil erfundene Angaben schlimmer sind als offene. Die Tabelle oben ist jetzt ein recherchierter Entwurf von Diggi aus dem Adapter-Katalog: jede Angabe traegt ihre Herkunft („belegt" mit Quelle, „ungeprueft" ohne). Sie ersetzt die Anforderung nicht, sie bereitet sie vor. Was weiter gilt: Angaben zu Sitz, Speicherung und Training veralten schnell und sind je Tarif verschieden — deshalb bleibt jede Zeile bis zur Pruefung durch Lucky und die Rechtsberatung vorlaeufig, und der Sperrvermerk bleibt bestehen, bis kein ungeprueft und kein <AUSFUELLEN> mehr in diesem Abschnitt steht.

5.1 Weitere Dienste im Datenweg

Cloud Data Processing Addendum. Es wird nicht gesondert unterschrieben, sondern ist nach seinem eigenen Wortlaut in die Vereinbarung einbezogen: „This Cloud Data Processing Addendum … is incorporated into the Agreement(s) … between Google and Customer", wirksam ab dem Tag, an dem der Kunde es angenommen hat oder die Parteien sich darauf geeinigt haben (abgerufen am 2026-08-30) |

Zum Zahlungsdienstleister: In src/zahlung.mjs ist Stripe als Anbieter vorgesehen und begruendet, aber die Zahlung ist nicht gebaut. Solange kein Bezahlvorgang laeuft, gehoert diese Zeile nicht als laufende Verarbeitung in eine veroeffentlichte Erklaerung, sondern erst dann, wenn sie stimmt.

Zu den MCP-Connectoren: Sie sind standardmaessig aus. Ein Connector startet einen Prozess und schickt Eingaben an einen fremden Dienst; das schaltet niemand fuer Sie ein. Wird einer eingeschaltet, gehoert er in diese Tabelle.

6. Mail-Anschluss (IMAP und SMTP)

Wenn Sie ein Postfach anbinden, gilt Folgendes:

• Es wird nichts gespiegelt. Diggi holt bei jedem Blick frisch vom Server und legt keinen lokalen Zweitbestand an (src/postfach.mjs). Ein geloeschtes Konto behaelt damit keine Nachrichten, die es nicht mehr geben soll.
• Der Zugang gehoert Ihnen. Verbunden wird mit einem App-Passwort, nicht mit Ihrem Kontopasswort. Es liegt wie jedes andere Geheimnis in config.local.json mit Dateirechten 0600 und wird nie zurueckgelesen; nach aussen geht nur die Angabe, ob ein Passwort hinterlegt ist.
• Was ein Modell zu sehen bekommt. Sobald Sie ein Modell auf eine Nachricht ansetzen — zusammenfassen, beantworten, einsortieren —, geht deren Inhalt an den betreffenden Drittanbieter aus Abschnitt 5. Das betrifft auch die Daten Ihrer Korrespondenzpartner, die dem nie zugestimmt haben.

Gemessen am 2026-08-30, nicht zugesagt: src/imap.mjs enthaelt keinen einzigen schreibenden Aufruf, src/postfach.mjs schreibt ausschliesslich die Zugangsdaten in config.local.json. Daraus folgt:

• Kopfzeilen bleiben nur fuer die Dauer der Anfrage im Arbeitsspeicher. Es gibt keinen Zwischenspeicher — Diggi holt bei jedem Blick frisch. Ein gespiegeltes Postfach waere ein zweiter Datenbestand, der auseinanderlaeuft und der bei einem geloeschten Konto Nachrichten behielte, die es nicht mehr geben soll.
• Anhaenge werden nicht abgelegt. Weder auf der Platte noch in einer Datenbank.

Was ein Modell zu sehen bekommt, verlaesst die Anlage trotzdem — das steht oben und aendert sich dadurch nicht.

7. Zugangsschluessel

Alle Schluessel und Passwoerter liegen ausschliesslich in config.local.json, mit Dateirechten 0600, und sind seit dem ersten Commit von der Versionsverwaltung ausgeschlossen (src/credentials.mjs). Ein Schluesselwert verlaesst dieses Modul nicht: Statusanzeigen sagen, ob und woher ein Schluessel kommt, niemals welcher.

Im gehosteten Betrieb sind es die Schluessel des Betreibers, im Eigenbetrieb Ihre eigenen.

8. Spracheingabe und Vorlesen im Browser

Der Mikrofonknopf benutzt die Spracherkennung Ihres Browsers (SpeechRecognition). Das ist keine Funktion von Diggi, sondern eine des Browsers — und damit gilt fuer sie die Datenschutzerklaerung des Browserherstellers.

Chrome schickt Mikrofondaten standardmaessig an Google. Neuere Fassungen koennen die Erkennung auf dem Geraet ausfuehren; Diggi versucht deshalb zuerst die Verarbeitung auf dem Geraet (processLocally, gemessen am 2026-08-07). Geht das nicht, werden Sie gefragt, statt stillschweigend nach draussen geschickt zu werden. Firefox hat die Schnittstelle nicht; dort erscheint der Knopf gar nicht.

Dasselbe gilt fuer das Vorlesen ueber speechSynthesis: welche Stimmen es gibt und wo sie erzeugt werden, entscheidet der Browser.

Der Wortlaut, abgeschrieben am 2026-08-30 aus ui/index.html und ui/sprachen/de.js — nicht sinngemaess wiedergegeben. Eine Einwilligung, deren Wortlaut in der Erklaerung anders steht als auf dem Bildschirm, ist keine:

Dein Mikrofon verlässt den Rechner

Dieser Browser kann die Spracherkennung nicht auf dem Gerät ausführen. Was du sprichst, geht zur Erkennung an den Anbieter des Browsers.

Der Weg über ein Hör-Modell aus deinen eigenen Zugängen bleibt davon unberührt — der läuft über Diggi.

[ Lieber nicht ] [ Für diese Sitzung erlauben ]

Die Antwort wird nirgends gespeichert — gemessen: an dieser Stelle steht kein einziger Zugriff auf localStorage oder sessionStorage. Sie gilt fuer diesen einen Vorgang, und beim naechsten Mal wird wieder gefragt. Das ist umstaendlicher als ein Haken „nicht mehr fragen" und dafuer das Einzige, was zu einer Einwilligung passt, die jederzeit widerruflich sein muss (Art. 7 Abs. 3 DSGVO): was nicht gespeichert ist, muss auch nicht widerrufen werden.

Die Vorbelegung steht auf Lieber nicht (autofocus), nicht auf Erlauben.

Wird stattdessen der serverseitige Weg ueber ein Hoer-Modell benutzt, geht die Aufnahme an den betreffenden Anbieter aus Abschnitt 5.

9. Ihre Rechte

Sie haben nach der DSGVO folgende Rechte:

Zustaendige Aufsichtsbehoerde:  <OFFEN 2026-08-18: Name, Anschrift, Webseite -
                                Lucky: "recherchiere" bzw. "branchenueblich";
                                zu recherchieren und zu belegen. Haengt am Sitz,
                                und der haengt am Gewerbe>
Kontakt fuer Betroffenenrechte: [email protected]

Ein Hinweis, der zur Ehrlichkeit gehoert: Ein Loeschverlangen erreicht die Daten, die bei uns liegen. Was bereits an einen Drittanbieter uebermittelt wurde, unterliegt dessen eigenen Fristen — wir koennen dort nur weiterleiten, nicht loeschen. Wie das im Einzelfall laeuft, haengt am jeweiligen Vertrag aus Abschnitt 5.

10. Automatisierte Entscheidungen und Hinweis nach der KI-Verordnung

Eine automatisierte Entscheidung im Einzelfall mit rechtlicher Wirkung oder aehnlich erheblicher Beeintraechtigung im Sinne von Art. 22 DSGVO findet nach derzeitigem Stand nicht statt: Diggi erzeugt Vorschlaege und Texte, es entscheidet nichts ueber Sie. Bestaetigt am 2026-08-30 fuer den Startumfang: keines der ausgelieferten Module bewertet Menschen. Kommt ein solches Modul hinzu, gehoert dieser Absatz geaendert, bevor es freigeschaltet wird.

Nach Art. 50 Abs. 1 der Verordnung (EU) 2024/1689 (KI-Verordnung) muessen Personen informiert werden, dass sie mit einem KI-System interagieren. Nach Art. 50 Abs. 4 muessen Betreiber offenlegen, wenn Bild-, Ton- oder Videoinhalte kuenstlich erzeugt oder manipuliert wurden. Die Verordnung gilt nach Art. 113 ab dem 2. August 2026.

11. Aenderungen dieser Erklaerung

Diese Erklaerung wird angepasst, wenn sich die Verarbeitung aendert — insbesondere, wenn ein Anbieter in Abschnitt 5 dazukommt oder wegfaellt. Es gilt die jeweils veroeffentlichte Fassung; das Datum steht im Kasten ganz oben.

Quellen

Nicht aus einer Rechtsquelle, sondern aus dem Code dieses Projekts belegt: src/postfach.mjs, src/imap.mjs, src/credentials.mjs, src/memory.mjs, src/ledger.mjs, src/nutzung.mjs, src/chats.mjs, src/media.mjs, src/anhaenge.mjs, src/agenda.mjs, src/zeiterfassung.mjs, src/buchhaltung.mjs, src/websuche.mjs, src/konto.mjs, src/anmeldung.mjs, src/zahlung.mjs, src/mcp.mjs, config.example.json, ui/index.html.

Was noch fehlt

Stand 2026-08-18 — was von dieser Liste erledigt ist.

Luecken, die der Betreiber ausfuellen muss — die urspruengliche Liste (24):

Offene Fragen an die Rechtsberatung (8):

• O-1 Ist ein Datenschutzbeauftragter zu benennen? § 38 BDSG knuepft an die Zahl der staendig mit automatisierter Verarbeitung beschaeftigten Personen an; die Schwelle wurde hier nicht nachgelesen. Zu pruefen ist ausserdem, ob die Verarbeitung eine Datenschutz-Folgenabschaetzung nach Art. 35 DSGVO ausloest — bei einem Dienst, der beliebige Nutzerinhalte an eine wechselnde Zahl von Drittanbietern weitergibt, ist das keine fernliegende Frage.
• O-2 Sind die im Browser gesetzten Eintraege „unbedingt erforderlich" im Sinne von § 25 Abs. 2 Nr. 2 TDDDG? Das laesst sich nur an der konkreten Liste entscheiden.
• O-3 Wie ist mit Daten nach Art. 9 DSGVO umzugehen, die Nutzer von sich aus eingeben? Ausschluss in den Nutzungsbedingungen, Einwilligung, oder technische Massnahme — alle drei haben Folgen fuer den Bau.
• O-4 Ist der Betreiber gegenueber den Modellanbietern Verantwortlicher oder gemeinsam Verantwortlicher nach Art. 26 DSGVO? Der Wettstreit schickt dieselbe Eingabe an mehrere Anbieter gleichzeitig; das ist kein gewoehnlicher Auftragsverarbeitungsfall.
• O-5 Welche Grundlage traegt die Uebermittlung an Anbieter ohne Angemessenheitsbeschluss — Standardvertragsklauseln, oder greift eine Ausnahme nach Art. 49 DSGVO? Bei einer wechselnden Anbieterliste ist das je Zeile zu beantworten.
• O-6 Wer ist Verantwortlicher fuer die Daten in einem angebundenen Postfach, wenn Diggi im gehosteten Betrieb laeuft und Nachrichten Dritter durch ein Modell laufen?
• O-7 Reicht der Hinweis auf die browsereigene Spracherkennung, oder ist eine Einwilligung noetig, bevor der Knopf ueberhaupt erscheint?
• O-8 Loest Diggi als Betreiber eines KI-Systems ueber Art. 50 der KI-Verordnung hinaus weitere Pflichten aus? Die Einstufung des Systems (Hochrisiko oder nicht) wurde hier nicht geprueft.