PrivateGraph: Ein Kontaktnetz für eine Person muss die automatische Erfassung zuerst streichen

Kernurteil: Das größte Verkaufsargument und die größte technische Hürde sind derselbe Satz – absolut privat, nur für eine Person. Das ist architektonisch unvereinbar mit plattformübergreifender intelligenter Erfassung. Sobald ein Server die Daten für Sie von den Plattformen holt, existiert ein zweiter Verarbeiter personenbezogener Daten, und „nur ich kann es sehen" ist sofort hinfällig. Die erste Entscheidung dieses Plans ist daher keine Technologiewahl, sondern ein Schnitt: Intelligente Erfassung wird neu definiert als aktiver Export des Nutzers plus lokale Zusammenführung, Vermittlung als reine Vorschläge ohne versendete Nachrichten.

Nachtrag vom 2026-11-05: Im Oktober 2026 verweigerten über 150 Apps dem Doubao-Phone-Assistenten schriftlich die stellvertretende Bedienung – der Grenzfall für die automatische plattformübergreifende Datenabfrage. Siehe Fallstudie in Kapitel 3.

Arbeitstitel: PrivateGraph. Arbeitstitel, kein offizieller Produktname. Projektstart 2026-11-05.

1. Das Problem ist nicht Vergessen – die Daten waren nie an einem Ort

Die Kontakte einer Person liegen meist in fünf getrennten Behältern: Visitenkarten und Tagungsverzeichnisse aus Papier, das Telefonbuch, Follower- und Abo-Listen der Content-Plattformen, Direktnachrichten und Kommentarspalten sozialer Plattformen sowie diverse Gruppenchats. Sie haben keine gemeinsame ID, keinen einheitlichen Zeitstempel und oft nicht einmal dieselbe Schreibweise eines Namens.

Ein konkretes Beispiel mit unseren eigenen öffentlichen Zahlen: Die ZouIC-Medienmatrix verzeichnet Follower auf 5 Plattformen – 3287 bei Toutiao, 317 bei iQIYI, 131 bei Weibo, 47 bei Zhihu und 117 beim Tencent-Omnia-Konto, zusammen 3899 Personen. Diese 3899 liegen in 5 getrennten Backends, von denen keines die anderen 4 sieht. Wie viele dieselbe Person unter verschiedenen Konten sind, wie viele im Bauteilehandel arbeiten, wie viele schon einmal nach einem Angebot gefragt haben – heute bleibt das dem Gedächtnis überlassen. Das ist kein Problem der Informationsmenge, sondern eines der Behälterisolation.

Noch praktischer ist die Vermittlung. Beispiel Bauteilebeschaffung: A schreibt in einer Gruppe, dass eine Charge verfügbar ist, B sucht in einer anderen Gruppe genau dieses Bauteil, beide kennen den Besitzer, doch der Besitzer verbindet die Erinnerungen aus beiden Gruppen nicht – und das Geschäft ist verloren. Unser Bauteile-Vermittlungsdienst ist im Kern genau diese manuell ausgeführte Arbeit. Was das Produkt verringern soll, ist dieser Verlust durch „ich kenne doch zwei Leute, mir fällt nur nicht ein, wen".

2. Drei unvermeidliche Widersprüche

Widerspruch eins: absolute Privatsphäre gegen plattformübergreifende Erfassung. Automatische Erfassung über Plattformen hinweg bedeutet dreierlei: Zugangsdaten halten, im Namen des Nutzers Anfragen an Plattformen stellen und die Antwortdaten speichern. Läuft das auf einem Server, fließen die Daten durch einen Dritten; selbst wenn der Anbieter zusagt, nichts zu speichern, bleibt er rechtlich Auftragsverarbeiter (Artikel 21 PIPL). Schwerwiegender: Simulierte Anmeldung oder Scraping verstoßen regelmäßig gegen die Nutzungsbedingungen und gefährden das Konto selbst. Fazit: Die Erfassung muss auf dem eigenen Gerät des Nutzers stattfinden und aktiv exportierte Dateien als Eingabe nutzen.

Widerspruch zwei: automatische Zusammenführung gegen nicht rückgängig zu machende Fehlzuordnung. Dieselbe Person erscheint auf der Visitenkarte als „Zhang Wei / Firma X / 138xxxx", in der WeChat-Notiz als „Wei-ge", auf Zhihu als „@xxx" und in der Gruppe als „Ingenieur Zhang". Ohne globale ID bleibt quellenübergreifende Zusammenführung eine Wahrscheinlichkeitsentscheidung. Verwechselt der Algorithmus zwei reale Personen, werden zwei völlig unterschiedliche Beziehungsnetze, Chatverläufe und Transaktionsnotizen dauerhaft verklebt – und das ist schwer zu entdecken. Für diese Fehlerklasse gibt es keinen Rückgängig-Knopf. Fazit: Präzision geht immer vor Trefferquote; das System erzeugt nur Zusammenführungskandidaten und übernimmt nie automatisch.

Widerspruch drei: Vermittlung gegen gesonderte Einwilligung. Vermittlung klingt nach „zwei Bekannte zusammenbringen", ist als Datenfluss aber die Weitergabe von A Informationen an B. Artikel 23 PIPL verlangt bei der Bereitstellung personenbezogener Daten an einen anderen Verarbeiter die Nennung von Name, Kontakt, Zweck, Verfahren und Datenkategorien des Empfängers sowie eine gesonderte Einwilligung; Artikel 25 untersagt die Veröffentlichung verarbeiteter Daten ohne gesonderte Einwilligung. Artikel 24 verlangt zudem Transparenz bei automatisierten Entscheidungen und gibt Betroffenen bei erheblicher Auswirkung das Recht auf Erläuterung und auf Widerspruch gegen rein automatisierte Entscheidungen. Fazit: Das System schiebt A niemals im Namen des Besitzers an B. Es zeigt nur dem Besitzer selbst „diese beiden könnten zusammenpassen"; die Vorstellung führt der Mensch aus und holt die Einwilligung ein.

3. Die Fallstudie: Ein Team mit Systemrechten hat Screenreading bis an die Grenze geführt

Die drei Widersprüche klingen nach Papiertheorie, doch zwischen Dezember 2025 und Oktober 2026 hat jemand dieses Kontrollexperiment mit echten Geräten, echtem Geld und echter Registrierung bereits durchgeführt. Für dieses Projekt ist das Ergebnis entscheidend: Das Schwierigste an der automatischen plattformübergreifenden Datenabfrage ist nicht das Modell und nicht OCR – sondern dass einem der Zugang nicht gehört und dessen Eigentümer bereits schriftlich Nein gesagt haben.

Die Zeitlinie zeigt das klarer als jede Architekturdiskussion:

An diesen Zahlen bleibt vor allem das Missverhältnis zwischen Können und Erlaubnis hängen. Über 80 % Aufgabenerfolg, Ketten mit hunderten Schritten, Injektionsrechte mit privatem Systemschlüssel, die Registrierung eines On-Device-Modells, ein öffentliches Protokoll mit Operationsprotokollen und System-Sicherheitsbaseline sowie das Gewicht eines Hardware- und eines Modellherstellers – kein einziges dieser Argumente fehlte, und zurück kamen 3 Standardschnittstellen und 155 Ablehnungserklärungen. SAEP hatte sogar vier ausgesprochen zurückhaltende Sicherheitsmechanismen vorgesehen: Apps können seitenweise erlauben oder untersagen, eine Policy-Entscheidung berücksichtigt Agent-Identität, System-Sicherheitsbaseline und Autorisierungsstatus, Einschränkungen werden von System-Gates statt durch Selbstdisziplin des Agenten durchgesetzt, und vollständige Protokolle erfassen, wer wann auf welcher Seite welche Operation angefragt hat, welche Regel griff und was daraus wurde. Technik, Compliance und Audit waren vollständig – die Ökosystem-Erlaubnis blieb aus. Ein persönliches Drittanbieter-Werkzeug besitzt keines dieser Argumente und hat keinen Grund anzunehmen, es könne es besser.

Auf die technischen Hürden von Projekt eins übersetzt, ergeben sich vier voneinander unabhängige Wände:

Ein weiterer Punkt wird leicht übersehen und bestimmt doch die Architekturgrenze: „Integration verweigern" heißt nicht „App unbenutzbar". Mehrere Medien stellten klar, dass die betroffenen Apps auf dem Doubao-Phone weiterhin heruntergeladen, installiert und manuell genutzt werden können; eingeschränkt ist nur das automatisierte Auslesen und simulierte Antippen durch den Assistenten. Der Weg, dass der Nutzer die App selbst öffnet und mit den plattformeigenen Export- und Teilen-Funktionen Daten herausholt, war also durchgehend offen und wurde von keiner Seite je verweigert.

„Aktiver Export plus lokale Zusammenführung" ist deshalb nicht die zweitbeste Kompromisslösung, sondern der einzige Weg, den das Kontrollexperiment als weiterhin offen belegt hat. Der Doubao-Fall hat die Frage, ob plattformübergreifende intelligente Erfassung machbar ist, von einer offenen Hypothese zu einer beantworteten Frage gemacht; die Architektur unten muss daher keine weiteren 12 Wochen in dieselbe Wand laufen.

Quellen: offizielle Mitteilungen des Doubao-Phone-Assistenten und SAEP-Integrationsdokumente, zusammengestellt aus Berichten von CNR (2026-10-16), China Economic Net (2026-10-15), The Paper, Nanfang+, 21st Century Business Herald und CCIDNET; geprüft am 2026-11-05. Die Ablehnungsliste wird jeden Mittwoch aktualisiert; die von Medien genannten 151 / 153 / 155 / 166 Apps gehen auf unterschiedliche Stichtage und Zählweisen zurück, maßgeblich ist die jeweils aktuelle offizielle Liste.

4. Produktdefinition und eine ausdrückliche Verzichtsliste

Definition in einem Satz: ein Werkzeug für eine einzelne Person, lokal zuerst, zur Verwaltung persönlicher Beziehungsdaten. Es importiert verstreute Kontaktfragmente auf ein selbst kontrolliertes Gerät, dedupliziert, führt zusammen, durchsucht und markiert Angebot-Nachfrage-Treffer – sämtlicher Klartext verlässt das Gerät nicht.

Die Verzichtsliste ist wichtiger als die Funktionsliste, denn sie entscheidet, ob das Produkt die Grenze überschreitet:

Dateneingänge: vCard-/CSV-Exporte des Telefonbuchs, lokale Visitenkarten-OCR, „persönliche Daten exportieren"-Dateien aus offiziellen Plattform-Backends, vom Nutzer manuell exportierte Chatverläufe als Text sowie handschriftliche Notizen des Besitzers. Sämtlich aktive, nachvollziehbare und widerrufbare Handlungen des Nutzers.

5. Compliance-Grenzen: Paragraf für Paragraf, nicht „nur für mich, also wohl egal"

Ein verbreiteter Irrtum lautet, private Nutzung sei nicht reguliert. Das chinesische PIPL kennt keine Ausnahme für häusliche Angelegenheiten im Sinne der DSGVO; es regelt die Verarbeitungshandlung selbst. Erfreulicherweise sind mehrere Vorschriften für dieses Projekt günstig, mehrere rote Linien müssen gemieden werden.

Rechtsgrundlage: Volltext des Gesetzes der VR China zum Schutz personenbezogener Daten (in Kraft seit 2021-11-01), Paragrafen geprüft am 2026-11-05. Dieses Dokument ist Produkt- und Engineering-Diskussion, keine Rechtsberatung; vor einem formellen Start sind eine Datenschutz-Folgenabschätzung (Artikel 55, 56) und eine fachliche Prüfung erforderlich.

6. Technische Architektur: fünf Ebenen, alle auf dem Gerät des Nutzers

Warum Ebene 4 auf „lokal" besteht: Namen, Firmen und Chat-Zusammenfassungen von 3899 Kontakten zum semantischen Abgleich an ein Cloud-Modell zu senden ist die naheliegendste Falle dieser Produktklasse – nominell „intelligente KI-Sortierung", tatsächlich die Übergabe des gesamten Beziehungsgraphen an einen Dritten. Ist externe Rechenleistung wirklich nötig, wird lokal eine reversible Pseudonymzuordnung gepflegt, die Entitäten vor dem Versand durch bedeutungslose Token wie ENT_0001 ersetzt und nach der Rückgabe lokal wiederherstellt; dabei bleibt klar: Das senkt das Abflussrisiko, ändert aber nicht die rechtliche Einordnung als personenbezogene Daten.

7. Verschlüsselung und Maskierung: drei Ebenen, und Maskieren ist kein Anonymisieren

Speicherebene: Vollverschlüsselung der Datenbank schützt bei Geräteverlust, Feldverschlüsselung verhindert, dass nach dem Öffnen der Datenbank alle Daten nackt vorliegen. Telefonnummern, E-Mails und Notizen erhalten jeweils eigene abgeleitete Schlüssel; das Aufdecken eines Datensatzes gibt keine anderen preis.

Anzeigeebene: standardmäßig maskiert (etwa 138****6621); jeder Klick auf „vollständig anzeigen" schreibt einen lokalen Audit-Eintrag mit Zeit und Feld. Vor Abflüssen über Screenshot und Zwischenablage wird gewarnt. Diese Ebene wirkt kleinlich, ist im Alltag aber das häufigste Leck – nicht ein Angreifer, der die Datenbank knackt, sondern der Besitzer, der einen Screenshot in eine Gruppe postet.

Rechenebene: Suche und Vermittlung laufen nur im entschlüsselten Speicher, auch Indexdateien sind verschlüsselt; temporäre Dateien und Absturzabbilder stehen auf der Aufräumliste. Nach außen gibt es nur den vom Nutzer ausdrücklich gewählten Einzel-Export, auf Wunsch mit automatischer Maskierung.

Eine häufig verwechselte Unterscheidung sei klargestellt: De-Identifizierung ist keine Anonymisierung. Artikel 4 nimmt anonymisierte Informationen aus, während über eine Pseudonymzuordnung wiederherstellbare Daten dem Gesetz unterliegen. In der Produktdokumentation aus „wir haben maskiert" ein „keine personenbezogenen Daten betroffen" zu machen, legt sich selbst eine Mine.

8. Vermittlung: der eigentliche Produktwert und der Ort mit dem größten Bedarf an Zurückhaltung

Es gibt zwei Arten der Vermittlung, mit völlig unterschiedlichem Risiko und Vorgehen.

Vermittlung unter Bekannten: Der Besitzer kennt beide Seiten. Das System externalisiert das Gedächtnis – tippt er „jemanden finden, der RK3588 in Serie fertigen kann", liefert die lokale Suche 3 Kandidaten, jeden mit Beweiskette: aus welcher Plattform, wann zuletzt gesprochen, worüber. Ein Blick genügt, um zu entscheiden, ob eine Vorstellung sinnvoll ist. Ein Mensch kann das auch, muss dafür aber Chatverläufe auf 5 Plattformen durchsuchen; genau in diesen 20 Minuten liegt der Produktwert.

Fremde Angebot-Nachfrage: Eine Seite ist dem Besitzer unbekannt, etwa ein Follower mit einer Einkaufsanfrage in einem Kommentar. Hier muss das System einen Schritt zurücktreten: Es erfasst nur den öffentlichen Kommentar als Hinweis (angemessener Umfang nach Artikel 27), ohne Anreicherung, Verknüpfung oder Vermutung weiterer Identitäten dieses Nutzers und ohne aktive Kontaktaufnahme. „Dem Besitzer helfen, einen Fremden zu finden" und „für den Besitzer einen Fremden kontaktieren" sind zweierlei; Letzteres macht aus einem Notizbuch einen nicht autorisierten Informationsmittler.

Noch ein Produktgrundsatz: Beziehungen nicht bewerten. Menschen nach „Wert" auf einer Skala von 1–5 Sternen zu sortieren lässt das Werkzeug umgekehrt das Sozialverhalten des Besitzers formen, und bei einem Datenleck ist nicht nur die Privatsphäre beschädigt, sondern die Beziehung selbst. Das System hält Fakten fest (wann, wo, worüber gesprochen), keine Bewertungen.

9. Wettbewerbsvergleich: Der Unterschied liegt nicht in Funktionen, sondern in der Datenhoheit

Vergleich nach öffentlicher Positionierung der Produkte, geprüft am 2026-11-05, ohne nicht veröffentlichte Funktionen und Geschäftszahlen.

Die Tabelle zeigt vor allem eines: Es fehlt am Markt nicht an Software, die sich Menschen merkt, sondern an einer, bei der die Daten danach vollständig einem selbst gehören und die quellenübergreifend zusammenführen kann. Der Burggraben ist nicht KI, sondern Datenhoheit und Zurückhaltung.

10. Geschäftsmodell: Vorweg klarstellen, dass dies kein VC-Projekt ist

Eine Person, unsichtbare Daten, kein Netzwerkeffekt, keine Datenmonetarisierung – treffen diese 4 zugleich zu, gibt es kein Daten-Flywheel und keine Skalierung über verbranntes Kapital. Eine SaaS-Wachstumsgeschichte zu erzwingen führt früher oder später zum Umzug in die Cloud, und dann geht das zentrale Versprechen verloren.

Die ehrliche Einordnung ist professionelle Werkzeug-Software: Desktop-Client zum Einmalkauf (Vorschlag 168–298 Yuan), optional Ende-zu-Ende-verschlüsselte Synchronisation als günstige Jahresgebühr (Vorschlag 68–98 Yuan/Jahr, nur Chiffre, der Server kann nicht entschlüsseln), keine Enterprise-Version. Entsprechend der Zahlungslogik vergleichbarer Lokal-zuerst-Werkzeuge: Nutzer zahlen für „beim Gerätewechsel keine Daten verlieren" und „weniger Zeit mit Sortieren", nicht für „mehr Funktionen".

Die Umsatzdecke ist niedrig, die Kostenstruktur aber auch: keine Servercluster, keine Inhalte-Moderation, kein Ticket-System, keine schweren Compliance-Audit-Assets. Geeignet für 1–2 Personen in langfristiger Pflege oder für einen offenen Kern plus kostenpflichtigen Desktop-Client. „Keine Finanzierung" in den Plan zu schreiben ist keine Schwäche, sondern die Garantie, dass das Produkt sich nicht verbiegt.

11. Ein 12-Wochen-MVP und die Kennzahlen, die zählen

Die zentralen Kennzahlen verzichten bewusst auf Wachstumsgrößen wie DAU oder Retention und betrachten nur 4: Importabdeckung (welcher Anteil der Kontaktfragmente liegt in der Datenbank), Bestätigungsquote der Zusammenführung (wie viele Kandidaten wurden manuell als dieselbe Person bestätigt), erfolgreiche Vorstellungen (wie oft der Besitzer tatsächlich vermittelt hat, von ihm selbst markiert) und Zwischenfälle mit falscher Zusammenführung (Ziel dauerhaft 0). Die vierte Kennzahl ist ein Vetokriterium; sie wiegt mehr als die ersten drei zusammen.

12. Risiken und drei harte Abbruchlinien

Fazit

Der eigentliche Wert dieser Idee liegt nicht darin, „Kontakte mit KI zu verwalten" – das ist der einfachste und am wenigsten wertvolle Teil. Der Wert liegt darin, über ein Jahrzehnt aufgebaute Beziehungsdaten, die in 5 getrennten Backends eingesperrt sind, wieder zu etwas zu machen, das der Besitzer durchsuchen, verstehen und verantworten kann. Am Beispiel dieser Seite: 3899 plattformübergreifende Follower sind heute nur eine verstreute Zahlenreihe; mit lokaler Zusammenführung und Beweisketten werden sie zu einem nutzbaren Graphen.

Und genau weil dieses Gut so sensibel ist, muss die Zurückhaltung in die Architektur geschrieben werden: Es meldet sich nicht für dich an, führt nicht für dich zusammen, stellt nicht für dich vor. Diese drei Verzichte definieren das Produkt besser als jeder Verschlüsselungsparameter. Bei einem Werkzeug für eine Person ist das Schwierige nicht, es zu bauen – sondern der Versuchung zu widerstehen, eine Plattform daraus zu machen.

Das Kontrollexperiment in Kapitel 3 hinterlässt noch einen Hinweis: Was selbst die Signatur mit privatem Systemschlüssel nicht erreichen konnte, wird man nicht mit einem schlaueren Algorithmus erreichen. Dieses Gut kommt nicht durch mehr Zugänge zu seinem Besitzer zurück, sondern dadurch, dass die Zugangsebene ganz entfällt.

Weiter: Projekt zwei · Ein-Klick-Anpassung und -Verteilung: aus „droht eine Sperre" eine berechenbare Größe machen.

Nachtrag 2026-11-08: Die Zugangsregeln von 2026 haben selbst Standardschnittstellen zur Prüffläche gemacht – Modellanbieter beziehen die Lieferkette fremder Skills in ihre Risikokontrolle ein, und die Richtlinie des Hosts entscheidet, ob ein MCP-Server aufgerufen werden darf. Die lokale Architektur mit vom Nutzer ausgelösten Importen ist damit robuster, aber auch schwerer zu einem externen Geschäft auszubauen: Projekt vier stuft sie per 5W1H zum Werkzeug für die Eigennutzung herab. Siehe die 5W1H-Neusortierung hinter den Zugangswällen.