Deine privaten Daten gehören dir. Wir können sie nicht lesen.

Das ist kein Marketing-Satz über interne Richtlinien. FlameP wird so gebaut, dass Betreiber, Administratoren, Support und Entwickler keinen normalen technischen Inhaltszugriff auf deine privaten Daten erhalten.

Wir wollen nicht sagen müssen: „Vertrau uns, wir schauen nicht hinein.“ Das Ziel ist stärker: Die Architektur soll uns diese Möglichkeit nicht geben.

Zero-Access bedeutet: FlameP als Betreiber besitzt keinen vorgesehenen technischen Mechanismus, mit dem Mitarbeiter oder Administratoren private Nutzerinhalte im Klartext lesen können.

Die Daten dürfen technisch verarbeitet werden, wenn du eine FlameP-Funktion ausführst. Diese Verarbeitung erfolgt aber innerhalb dafür autorisierter Runtime-Pfade und erzeugt keinen allgemeinen Betreiberzugriff.

Zero-Access bedeutet nicht, dass Software, Geräte, Kryptografie, Betriebssysteme oder externe Anbieter niemals Fehler oder Sicherheitslücken haben können.

Es bedeutet auch nicht, dass Daten niemals technisch entschlüsselt verarbeitet werden dürfen. Wenn eine von dir gewählte Funktion den Inhalt verarbeiten muss, kann dies innerhalb des autorisierten Ausführungskontexts erforderlich sein.

Für Konto, Sicherheit, Abrechnung und technischen Betrieb kann FlameP bestimmte nicht-inhaltliche Informationen verarbeiten, soweit sie für den jeweiligen Zweck erforderlich sind. Dazu können beispielsweise gehören:

• Kontostatus und technische Account-Referenzen,
• Entitlements, Tarif-/Produktstatus und Abrechnungsinformationen,
• technische Betriebs- und Sicherheitsereignisse ohne private Inhaltsprotokollierung,
• Verbrauchs-/Kosteninformationen, soweit sie für FlamePoints, Billing und Ledger erforderlich sind,
• vom Nutzer ausdrücklich öffentlich gemachte oder an FlameP übermittelte Informationen.

Welche personenbezogenen Metadaten konkret verarbeitet werden, beschreibt die Datenschutzerklärung.

Je nach FlameP-Produkt- und Infrastrukturstufe können private Daten lokal auf einem Nutzergerät, in einer persönlichen verschlüsselten Datenbank auf FlameP-Infrastruktur oder in einer dafür vorgesehenen persönlichen/dedizierten Runtime gespeichert werden.

Serverseitige Speicherung bedeutet nicht Betreiberzugriff. Entscheidend ist, ob FlameP den Inhalt entschlüsseln und lesen kann – nicht, wem die Festplatte physisch gehört.

Der konkrete Speicherpfad einer produktiven Funktion muss aus der tatsächlichen Runtime hervorgehen und darf nicht durch Marketingbegriffe ersetzt werden.

FlameP sieht für private persistente Nutzerdaten eine persönliche, verschlüsselte Datenhaltung vor. Nutzerinhalte werden nicht absichtlich in eine gemeinsame, für Betreiber lesbare Inhaltsdatenbank zusammengeführt.

Die persönliche Datenbank kann je nach Infrastrukturmodell in einem geteilten technischen Pool liegen, ohne ihre logische und kryptografische Trennung von anderen Nutzern zu verlieren.

Private FlameP-Daten werden in den dafür vorgesehenen Zero-Access-Pfaden verschlüsselt gespeichert. Übertragungen zwischen autorisierten Komponenten werden ebenfalls angemessen geschützt.

Verschlüsselung ist dabei kein alleiniger Beweis für Zero-Access. Entscheidend ist zusätzlich, wer die für eine Entschlüsselung erforderlichen Schlüssel kontrolliert und ob es einen alternativen Betreiberzugriff gibt.

FlameP behandelt Kryptografie deshalb als Teil einer Gesamtarchitektur aus Schlüsselkontrolle, Scope, Runtime-Isolation, minimalen Logs und kontrollierten Datenpfaden.

Für Zero-Access-Sicherheitsstufen liegt die entscheidende Schlüsselkontrolle beim Nutzer beziehungsweise in einem nutzerautorisierten Schlüsselpfad. FlameP darf keinen versteckten Betreiber-Generalschlüssel vorhalten, der den Zero-Access-Grundsatz aushebelt.

Eine Passphrase oder ein Schlüssel ist nicht dasselbe wie dein FlameP-Login. Account-Authentifizierung und Inhaltsentschlüsselung werden konzeptionell getrennt behandelt.

FlameP kann unterschiedliche Recovery-Stufen anbieten. Eine Recovery-Option muss transparent erklären, wer oder was eine Wiederherstellung ermöglichen kann und welche zusätzliche Vertrauensbeziehung dadurch entsteht.

Eine Komfort-Recovery darf nicht als identisch mit einer maximalen Zero-Recovery-Sicherheitsstufe dargestellt werden.

Bei einer maximalen Sicherheitsstufe ohne eingerichteten Recovery-Pfad gilt: Ist der notwendige Schlüssel verloren, kann FlameP die verschlüsselten Inhalte nicht für dich entschlüsseln.

Das ist kein Supportmangel, sondern die Konsequenz daraus, dass FlameP selbst keinen Generalschlüssel besitzt.

Backups sollen Verfügbarkeit und Wiederherstellbarkeit nach technischen Fehlern verbessern. Sie dürfen jedoch keinen zweiten ungeschützten Inhaltsbestand erzeugen.

Wenn verschlüsselte private Daten gesichert werden, muss ihre Zero-Access-Eigenschaft auch im Backup-Pfad erhalten bleiben. Backup-Operatoren oder Administratoren dürfen dadurch keinen zusätzlichen Klartextzugriff erhalten.

Konkrete Backup-Frequenzen, Retention und Recovery-Ziele werden aus dem produktiven Infrastruktur- und Recovery-Stand dokumentiert, nicht in diesem Text erfunden.

Wenn du eine Funktion startest, autorisierst du einen technischen Ausführungspfad. Dieser darf den für die Funktion erforderlichen Kontext verarbeiten und ein Ergebnis erzeugen.

Der Betreiber erhält dadurch nicht automatisch eine Oberfläche, API oder Datenbankabfrage, um denselben privaten Inhalt unabhängig von deiner Aktion einzusehen.

Wenn du eine Funktion nutzt, deren autorisierter Pfad einen externen Modellanbieter einbezieht, kann der für diese Anfrage erforderliche Kontext technisch an diesen Anbieter übermittelt werden.

Das ist kein Betreiberzugriff durch FlameP. Es ist aber eine Verarbeitung durch einen zusätzlichen Empfänger und muss deshalb transparent gemacht werden.

FlameP soll externe Übermittlung minimieren, private/precheck-basierte Wege nutzen, wo sie vorgesehen sind, und dir relevante Auswirkungen auf Privacy, Kosten und Modellwahl anzeigen.

Provider, Vertragsbedingungen, Speicherverhalten, Trainingsausschluss, Verarbeitungsort und Drittlandtransfer werden pro tatsächlich aktivem Provider geprüft und in der Datenschutzerklärung synchron gehalten.

FlameP benötigt technische Informationen, um Verfügbarkeit, Kosten, Sicherheit und Fehlerzustände zu verstehen. Diese Betriebsdiagnostik darf private Nutzerinhalte nicht zu einem alternativen lesbaren Datenbestand machen.

Inhaltsprotokolle privater Chats, Dokumente oder persönlicher Daten sind kein regulärer Zero-Access-Betriebsmechanismus.

Wenn zur Fehleranalyse nutzerseitig bewusst Beispielinhalte bereitgestellt werden, ist diese freiwillige Übermittlung vom normalen privaten Inhaltsbestand getrennt zu behandeln.

Ein Support-Mitarbeiter erhält nicht allein deshalb Zugriff auf private Inhalte, weil du ein Ticket eröffnest oder Hilfe brauchst.

Wenn du zur Fehleranalyse bewusst einen Screenshot, Export, Textausschnitt oder andere Informationen an den Support sendest, verarbeitet FlameP diese von dir ausdrücklich übermittelten Supportdaten für diesen Zweck. Sie sind von deinem sonstigen Zero-Access-Inhaltsbestand zu unterscheiden.

FlameP beachtet rechtlich wirksame Verpflichtungen. Soweit FlameP Kontometadaten, Abrechnungsdaten oder andere rechtmäßig zugängliche Informationen besitzt und zur Herausgabe verpflichtet ist, kann eine entsprechende gesetzliche Pflicht bestehen.

Zero-Access bedeutet zugleich: FlameP kann private Klartextinhalte nicht aufgrund einer Anfrage aus einem Betreiberzugriff herausgeben, wenn FlameP technisch keinen solchen Zugriff besitzt.

Die Architektur ist damit eine reale Grenze dessen, was FlameP selbst technisch bereitstellen kann. Gesetzliche Pflichten werden dadurch nicht ignoriert; vorhandene und nicht vorhandene Zugriffsmöglichkeiten werden aber nicht verwechselt.

Sichtbarkeit ist strikt optional. Eine World, ein Objekt, Beitrag, Outcome, eine Fähigkeit oder andere Information wird nicht automatisch sichtbar, nur weil sie im System existiert oder netzwerkrelevant sein könnte.

Öffentliche oder geteilte Sichtbarkeit entsteht nur über dafür vorgesehene Nutzerentscheidungen und Berechtigungen.

Die Zero-Access-Architektur unterstützt dieses Versprechen technisch: FlameP baut keinen Betreiberbestand privater Inhalte auf, aus dem solche Daten für andere Zwecke ausgesucht werden könnten.

Ein zukünftiges freiwilliges Contribution-, Research- oder Trainingsprogramm müsste eine eigene, klar erklärte Nutzerentscheidung sein. Es wäre nicht Teil der normalen privaten FlameP-Nutzung.

Nach Kündigung oder Widerruf bleibt dein FlameP-Konto bestehen. Die kostenpflichtigen Entitlements enden nach den dafür geltenden Regeln; der Zugang zu deinen eigenen Daten bleibt davon getrennt.

Deine eigenen Daten bleiben mindestens zwölf Monate kostenfrei zugänglich und exportierbar, soweit du nicht vorher ihre Löschung verlangst und keine zwingenden gesetzlichen Regelungen entgegenstehen.

Der reine Konto-/Datenzugang löst keine weitere reguläre Basisgebühr aus.

Eigene Daten sollen nicht in FlameP eingeschlossen werden. FlameP stellt die dafür vorgesehenen Exportwege bereit und berücksichtigt die gesetzlichen Rechte auf Datenzugang und Datenübertragbarkeit.

Ein Export soll in einem gängigen und maschinenlesbaren Format möglich sein, soweit dies für den jeweiligen Datentyp technisch und rechtlich einschlägig ist.

Du kannst die Löschung personenbezogener Daten verlangen, soweit die gesetzlichen Voraussetzungen vorliegen. Das zwölfmonatige Zugangsversprechen bedeutet nicht, dass FlameP Inhalte gegen deinen Willen zwölf Monate halten muss.

Gesetzliche Aufbewahrungspflichten oder Rechtsansprüche können für einzelne Datenarten eine längere, zweckgebundene Aufbewahrung erfordern. Solche Daten dürfen nicht deshalb wieder zu einem frei nutzbaren privaten Inhaltsbestand werden.

Auch Zero-Access-, Verschlüsselungs- und Runtime-Systeme können Fehler, Fehlkonfigurationen oder Sicherheitslücken enthalten. FlameP behauptet deshalb keine technische Unfehlbarkeit.

Wird FlameP ein Fehler bekannt, wird er untersucht und behoben. Sicherheits- und Datenschutzprobleme werden entsprechend ihrer möglichen Auswirkungen priorisiert.

Falls ein Vorfall gesetzliche Benachrichtigungs- oder Meldepflichten auslöst, werden diese nach den anwendbaren Regeln erfüllt.

Die DSGVO verlangt Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen. FlameP geht mit Zero-Access produktstrategisch darüber hinaus: Wir wollen private Inhalte nicht erst durch interne Prozesse vor Mitarbeitern schützen, sondern unnötigen Betreiberzugriff gar nicht als normalen Systempfad vorsehen.

Zu einer solchen Architektur gehören insbesondere Datenminimierung, Verschlüsselung, getrennte Schlüsselkontrolle, restriktive Scopes, isolierte Datenpfade und eine Diagnostik ohne private Inhaltslogs.

Zero-Access darf nicht allein durch dieses Dokument entstehen. Die produktive Aussage muss durch die reale Architektur und den aktiven Runtime-Pfad belegbar sein.

Dazu müssen unter anderem geprüft werden:

• Schlüssel- und Entschlüsselungspfade,
• Admin-/Support-Berechtigungen,
• Datenbank- und Backup-Zugriff,
• Logs, Traces und Error Reporting,
• Runtime-/Container-/Server-Zugriffswege,
• Export-, Recovery- und Account-Reset-Pfade,
• externe Provider- und Modellpfade,
• Incident- und Break-glass-Mechanismen.

Die Legal Experience darf nur den Zustand behaupten, den die produktive technische Evidence trägt.

Zentrale FlameP-Zusagen

Vor Productive Freeze technisch nachzuweisen