docs/data-protection.de.md
Rama main · réplica de lectura del repositorio original.
---
source_sha: "bf339c9ea7e0"
---
# Datenschutz { #data-protection }
Wo personenbezogene Daten in einem Deployment liegen, was es verlässt und unter
welcher Konfiguration, welche Kontrollen im Code existieren und einen Test
hinter sich haben und welche noch offene Issues sind. Geschrieben für den, der
eine Datenschutzprüfung eines Deployments beantwortet — einen
Datenschutzbeauftragten, einen Sicherheitsverantwortlichen, einen Betreiber —
und ehrlich gehalten über den Unterschied zwischen dem, was die Software kann,
und dem, was ein Deployment tatsächlich entschieden hat.
!!! warning "Eine Seite ist keine Compliance"
Nichts hier ist ein Nachweis, dass ein Deployment die DSGVO einhält. Die
Codebasis lässt sich innerhalb einer konformen Umgebung betreiben; ob eine
solche es *ist*, hängt von den konfigurierten Providern ab, von der
entschiedenen Aufbewahrung, den unterzeichneten Verträgen und dem Betreiber,
der sie führt. Jede dieser Bedingungen ist unten als etwas benannt, das zu
beschaffen und zu prüfen ist, nie als etwas Angenommenes.
Das Capability-Inventar enthält auch den pro Konversation auswählbaren lokalen Coding-Agent, selbst wenn der veröffentlichte Spec keinen solchen Binding enthält oder eine Sandbox nutzt. Diese Zeile beschreibt einen möglichen Weg, keinen Nachweis seiner Nutzung.
Personendatenexporte enthalten Dateinamen und Patches der Coding-Aufgaben aus den exportierten Unterhaltungen; deren JSON zählt zur vorab geprüften Größenbegrenzung. Das Ende einer Organisationsmitgliedschaft entfernt die persönlichen Coding-Verbindungen in derselben Transaktion. Ein erneuter Beitritt erfordert eine neue Verbindung und Zustimmung; die bisherige Freigabe lebt nicht wieder auf.
Personendatenexporte enthalten auch private Aufgabentafeln, Datensatzwerte, erhaltene Änderungshistorien und Spaltenschemata sowie dauerhafte Zustimmungen zu Routineaktionen. Diese JSON-Daten zählen zum Größenlimit der Exportvorprüfung. Gemeinsame Projekt-, Gruppen- und Organisationstabellen werden nicht allein deshalb exportiert, weil die Person darin eine Aufgabe erstellt hat.
## Was standardmäßig das System verlässt { #nothing-leaves-by-default }
Ein frisches Deployment hält alles in seinem eigenen PostgreSQL und auf seiner
eigenen Platte oder dem Objektspeicher, mit dem es konfiguriert ist. Es sendet
keine Prompts, Konversationen oder Dokumente irgendwohin. Jeder Sprung nach außen
ist eine Zeile oder eine Einstellung, die jemand danach hinzufügt: ein
Model-Profil, das einen Provider benennt, eine Collection, die einen Parser oder
einen entfernten Embedding-Provider wählt (der dann die Dokument-Chunks erhält),
eine Suchmethode auf einem Spec, ein Logfire-Token, ein MCP-Server,
ein Kanal-Bot. Entfernen Sie die Zeile, und der Sprung ist weg.
Ein Bericht ist standardmäßig aktiv und enthält keine Inhalte: Die
[Deployment-Diagnose](#deployment-diagnostics) sendet Installationszustand, grobe
Nutzungszähler, Zähler fehlgeschlagener Runs, Jobs und Ingestionen nach
geschlossenen Kategorien und ein pseudonymes Aktivitätssignal an einen Kollektor.
Ein Deployment, das **gar keinen Kontakt nach außen** will, setzt
`DIAGNOSTICS_ENABLED=false`.
Ein Deployment, das **keine dritte Partei in der Kette** will, konfiguriert sich
entsprechend, und die Software macht mit:
| Thema | Die lokale Antwort |
| --- | --- |
| Das Chat-Model | Ein `ollama`- oder `litellm`-Profil — schlüssellos, auf einen Endpunkt gerichtet, den Sie selbst betreiben. Jeder der 28 Provider mit `base_url` nimmt auch ein Gateway von Ihnen |
| Dokumenten-Parsing | `pymupdf`, der Standard, läuft im Worker. LiteParse-OCR läuft ebenfalls im Worker oder an einem OCR-Server, den Sie als lokalen Dienst registrieren. LlamaParse ist eine Wahl je Collection und braucht einen Vault-Schlüssel; ohne einen wird nichts außer Haus geparst |
| Embeddings | Ein Ollama, das Sie betreiben, unter Knowledge → Integrations als lokaler Dienst registriert und je Collection als Provider `ollama` gewählt. Schlüssellos, und der einzige Provider, den eine app-scoped Collection nutzen darf |
| Traces | Lassen Sie `LOGFIRE_TOKEN` ungesetzt und binden Sie kein `observability`-Token an einen Spec oder ein Environment. Runs halten die Trace-Id weiterhin lokal fest |
| Suche, Browsing, Memory, Tools | Binden Sie kein `search`-Secret, keine Capability `web_fetch` oder `browser_use`, keine MCP-Verbindung. Der Webbrowser kann bleiben, wenn jede Seite, die er öffnen darf, auf `allowed_domains` steht und seine Schritte an ein Modell gehen, das Sie selbst betreiben |
| E-Mail | Ihr eigenes SMTP-Relay |
| Sprache, Bilder und Video | Für Spracherkennung gar kein Provider: Diktat auf `off` oder `browser` lassen und Kanal-Bots ausschalten, denn ein selbst gehosteter Spracherkennungsserver lässt sich noch nicht benennen (ein geplanter Folgeschritt). Für Sprachausgabe und Video keine Capability `text_to_speech` oder `video_generation`. Für Bilder ein Profil bei einem Provider, den Sie betreiben, oder gar kein solches Profil |
Embeddings eingeschlossen: Der Katalog nennt OpenRouter und OpenAI, die eine
Collection mit einem Vault-Schlüssel erreicht, und `ollama`, das eine Collection
an einem lokalen Dienst erreicht — einer Zeile, die einen Server benennt, den die
Organisation oder das Deployment betreibt. Eine Collection auf `ollama` schickt
ihre Chunks und Anfragen an keinen anderen Host und zahlt niemandem etwas. Ein
Deployment, das Dokumente auf eigener Hardware halten muss, legt dort jede
Collection an.
## Wer wofür verantwortlich ist { #who-is-responsible-for-what }
| Partei | Rolle | Was das hier bedeutet |
| --- | --- | --- |
| Die Organisation, die es betreibt (eine Stadt, ein Unternehmen) | **Verantwortlicher** | Entscheidet über Zwecke, Aufbewahrung, welche Provider ein Agent erreichen darf, und unterzeichnet die Verträge mit ihnen |
| Vstorm als Autor der Software | **Keines von beiden**, bei einem selbst gehosteten Deployment | Der Code läuft auf Ihrer Infrastruktur. Vstorm sieht Ihre Prompts, Konversationen und Dokumente nie. Solange der Standard-Kollektor verwendet wird, den Vstorm betreibt, erhält er die [Deployment-Diagnose](#deployment-diagnostics); mit `DIAGNOSTICS_ENABLED=false` oder einem eigenen Kollektor erhält er keine |
| Vstorm, wenn es das Deployment für Sie betreibt | **Auftragsverarbeiter** | Ein Auftragsverarbeitungsvertrag ist ein Vertrag zwischen uns, keine Einstellung. Er muss vor dem ersten veröffentlichten Agent existieren |
| Ein Model-, Embedding-, Parsing-, Such- oder Observability-Provider | **Unterauftragsverarbeiter**, per Konfiguration gewählt | Die Plattform hält fest, _welchen_ Provider und _welchen_ Endpunkt jeder Agent nutzt. Deren Standort, Aufbewahrung und Trainingsbedingungen sind ihre und werden je Deployment geprüft |
Die Plattform trainiert und finetunt nichts. Sie sendet Prompts, Dokumente und
Tool-Ergebnisse an die Provider, die ein Deployment konfiguriert, und speichert,
was zurückkommt. Ob ein Provider API-Verkehr zum Training verwendet, ist eine
Eigenschaft seines Kontos und seiner Bedingungen, und die Checkliste am Ende
verlangt die Erklärung, statt sie anzunehmen.
## Wo personenbezogene Daten liegen { #where-personal-data-lives }
Alles unten liegt im eigenen PostgreSQL des Deployments, auf seiner eigenen
Platte oder in einem Dienst, den das Deployment gewählt hat. Jede Tabelle, die
einer Organisation gehört, trägt eine `organization_id`; eine Kindzeile — eine
Nachricht, ein Anhang, eine Bewertung — ist über die Conversation oder den
Benutzer gescoped, an dem sie hängt, und der Lesezugriff geht über die Prüfung
des Elternteils.
### Die Datenbank { #the-database }
Die Gesamtgrenze wird im Savepoint der Änderung unter einer Organisationssperre vor dem Commit geprüft. Eine Überschreitung rollt den Datensatz und alle Kopien zurück, auch eine Importzeile; übrige Zeilen werden als abgelehnt gemeldet. Quittungswiederholungen, unveränderte Schreibvorgänge, Lesen und Löschen bleiben nach einer Absenkung möglich. Die Aufbewahrungsbereinigung gibt entfernte Bytes frei. Gespeicherte PostgreSQL-JSONB-Nutzdaten je Organisation über Datensätze, Historie, Quittungen und Outbox; Tabellen- und Index-Overhead zählt separat.
| Speicher | Hält | Personenbezogene Daten darin | Zweck |
| --- | --- | --- | --- |
| `users`, `sessions`, `organization_members` | Konten und Anmeldungen | E-Mail, Name, Avatar, gehashtes Passwort oder die Google-Konto-Id, Refresh-Token-Hash, IP-Adresse und User-Agent je Session; was die Person Agents über sich gesagt hat - Sprache der Konsole, Zeitzone, Rolle, woran sie arbeitet, Arbeitszeiten - und die ersten Nachrichten, die für ihren leeren Chat geschrieben wurden | Authentifizierung und Autorisierung; was jeder Agent über die Person erfährt |
| `browser_sign_ins` | Gespeicherte Anmeldungen einer Person bei Websites, für den Webbrowser | Die Website, die Organisation, wann sie zuletzt genutzt wurde, und die Sitzung selbst (Cookies und der `localStorage` der Website), über den Vault im eigenen Bereich der Person versiegelt | Ein späterer Durchlauf in ihrem Namen beginnt bereits angemeldet. Der Export personenbezogener Daten nennt die Websites, nie die Sitzung |
| `coding_accounts` | Persönliche Claude-Code/Codex-Verbindungen | Organisation, Eigentümer, Kontobezeichnung, Zustimmungsrevision und im Benutzerbereich versiegelter API-Schlüssel oder ChatGPT-Tokenpaar | Metadatenexport nur für Eigentümer; eigener Container pro Aufgabe; Trennen entfernt die Plattformfreigabe, nicht die Anbieterfreigabe |
| `conversations`, `messages`, `tool_calls` | Jeder Chat auf jeder Oberfläche | Der Text, den Menschen geschrieben haben, die Antworten und das Reasoning des Models, Tool-Argumente und -Ergebnisse, eine fortlaufende Zusammenfassung langer Threads | Die Kernfunktion des Produkts; die Historie, zu der ein Mensch zurückkehrt |
| `coding_task_changes` | Eine Aufgabe des Coding-Agenten bei `edit` in einer Unterhaltung | Die Dateien, die die Aufgabe geändert hat, und ihr Patch, bis 256 KiB: der Code, wie er war und wie er wurde | Der Diff der Aufgabe, in ihrem Panel gezeigt; mit dem Zugriff der Unterhaltung gelesen |
| `voice_calls` | Jede Verbindung eines [Sprachanrufs](voice.md) | Die Benutzer-ID des Anrufers (keine bei einem Besucher), der Agent, der Run, die Conversation und das Embed, zu denen er gehörte, Provider und Modell, die Anruf-ID des Providers, die ID des Vault-Schlüssels, mit dem er gehalten wurde, der Worker, der ihn hält, sein Heartbeat, die Zeiten von Beginn, Ende und Auflegen, seine Kosten, Sekunden und die Zahl der Guardrail-Treffer. **Kein Audio und kein Transkript** - die Worte des Anrufs sind gewöhnliche Zeilen in `messages`, jede mit einer `turn_id` markiert und, wenn der Anrufer dazwischengesprochen hat, mit `interrupted` | Einen Anruf auflegen, dessen Prozess gestorben ist, und die monatlichen Anrufminuten der Organisation zählen |
| `chat_files` | Anhänge an einer Nachricht | Dateiname, Typ, Größe, der extrahierte Text (`parsed_content`) und der Pfad der Bytes auf der Platte | Antworten über eine Datei |
| `generated_media` | Eine Zeile je Bild, Sprachclip oder Video, das ein Agent erzeugt hat | Die Organisation, die Conversation, in der es entstand, sofern der Run eine hatte, Dateiname, Speicherpfad und Größe - **nicht der Inhalt**, der eine Datei unter `MEDIA_DIR` ist | Die erzeugten Medien jeder Organisation gegen ihr Kontingent zählen und sie mit ihrer Conversation oder nach ihrer Aufbewahrungsfrist löschen |
| `context_files` | Dauerhaftes Wissen, das ein Builder für Agents geschrieben hat | Was der Autor dort hineingeschrieben hat — und es erreicht den Prompt wörtlich. Siehe [Kontextdateien](context.md) | Anweisungen und Fakten, die ein Agent immer kennen soll |
| `virtual_table_records`, `virtual_table_record_history`, `virtual_table_receipts`, `virtual_table_outbox` | Die Zeilen einer [Virtual Table](virtual-tables.md) und die Spur jeder Änderung daran | Was die Organisation in ihre Zellen geschrieben hat, darunter möglicherweise personenbezogene Daten. Die aktuellen Werte (Records); der ganze Datensatz bei Create und Delete, bei einem Update nur die geänderten Zellen (History); der ganze Datensatz, wie ihn ein Schreibzugriff mit Schlüssel zurückgab (Receipts); die ids und die external id jedes erstellten Datensatzes (Outbox, keine Werte). Ein Löschen des Datensatzes entfernt nur die aktuelle Zeile: History und Receipts behalten die Werte, bis der tägliche Aufbewahrungs-Sweep sie entfernt: Receipts nach 24 Stunden, zugestellte Outbox-Zeilen nach 3 Tagen und die History nach 365 Tagen, alles Einstellungen des Deployments. Das Löschen eines Kontos entfernt seine Receipts und löscht es als Akteur in der History; das Löschen der Organisation entfernt alle vier | Typisierte Datensätze für Agents und Workflows, sichere Wiederholungen eines Schreibzugriffs und die Übergabe eines erstellten Datensatzes |
| `virtual_table_triggers`, `virtual_table_trigger_revisions`, `table_trigger_admissions` | Die [Trigger](virtual-tables.md#triggers) einer Tabelle, jede Konfiguration, die sie hatten, und was jeder über einen angelegten Datensatz entschieden hat | Das Mitglied, als das ein Trigger läuft; seine Filterwerte und Zuordnungsschlüssel, die personenbezogene Daten enthalten können, wenn ein Builder welche eingetragen hat (ein Filter auf eine E-Mail-Adresse). Eine Entscheidung enthält einen Status, einen groben Grund und den gestarteten Run, nie die Werte des Datensatzes. Keine Aufbewahrungsklasse räumt sie auf: Sie gehen mit ihrer Tabelle und ihrem Trigger, und das Löschen eines Kontos entfernt es als Mitglied, danach startet der Trigger nichts mehr | Einen Workflow ausführen, wenn ein Datensatz hinzukommt |
| `artifacts`, `artifact_versions` und ihre Dateien | Seiten, die Agents veröffentlicht haben — Berichte, Dashboards | Was auch immer die Seite zeigt, die der Run aus dem gebaut hat, was er lesen konnte — oder, bei einer an Tabellendaten gebundenen Seite, ihre Seitenabfragen (Tabelle, Filter, Sortierung, Limit und Spalten, jeweils zu IDs aufgelöst), während die Datensätze selbst beim Ansehen mit dem Zugriff des Besitzers der Seite gelesen und nie in der Seite gespeichert werden; je Version, wer sie veröffentlicht hat, und die Einwilligung des Besitzers, ihre Daten zu teilen (ein Fingerabdruck der Abfragen, die Mitgliedschaft des Besitzers und wann), und die Einwilligung der Seite für öffentliche Daten (wer sie bestätigt hat, die Mitgliedschaft des Besitzers, wann); die Zeile der Organisation hält den Schalter `public_live_data`; der Besitzer, der Run, der jede Version geschrieben hat, und, wenn einer aktiv ist, der Schlüssel des öffentlichen Links, seine Einstellungen (ein Passwort als bcrypt-Hash) und wie oft er geöffnet wurde — eine Zahl und ein Zeitpunkt, nichts über die Besucher. Siehe [Apps](artifacts.md) | Ein Ergebnis unter einem stabilen Link teilen |
| `datasets`, `dataset_cases` | Testfälle für Evals | Fragen und Antworten, die aus Conversations kopiert wurden, als jemand „Zum Dataset hinzufügen“ wählte, der Kommentar zu einer negativ bewerteten Antwort als Notiz des Falls, und was eine importierte Datei enthielt. Zugangsdaten werden geschwärzt, bevor ein Fall gespeichert wird. Jeder Fall hält außerdem fest, wessen Worte er enthält - wer gefragt hat, wer jeden früheren Zug geschrieben hat, wessen Kommentar seine Notiz ist -, was nie angezeigt oder exportiert wird und die Conversation überdauert. Das Löschen der Person, die gefragt hat, anonymisiert den Fall in jeder Version, die ihn enthält; das Löschen jeder anderen Person, deren Zug oder Kommentar er behalten hat, ersetzt diesen Zug und die Antwort des Agents darauf und leert diese Notiz. Siehe [Datasets](datasets.md#personal-data) | Prüfen, ob ein Agent besser geworden ist |
| `spec_proposal_hunks`, `skill_proposals`, `context_proposals`, `authoring_requests` | Die vom Authoring-Assistenten vorgeschlagenen Änderungen und seine Berichte | Zitate, je bis zu 600 Zeichen, aus den Runs, die er gelesen hat: was Menschen gefragt haben, was der Agent geantwortet hat, und die Kommentare zu einer Bewertung. Das Löschen einer Person entfernt die Zitate ihrer Runs und die Zitate ihrer Kommentare zu Runs anderer Personen. Siehe [Authoring-Assistent](authoring.md#every-quote-is-checked) | Zeigen, warum der Assistent eine Änderung vorgeschlagen hat |
| `knowledge_searches`, `knowledge_gap_topics`, `knowledge_gap_members` | Jede Wissenssuche, die ein Agent in einem Run gemacht hat, und die zu Themen gruppierten Fehltreffer | Die Anfrage, die der Agent aus der Frage einer Person formuliert hat, die durchsuchten Wissensdatenbanken und wie nah die nächste Passage war. Eine Suche, Treffer oder Fehltreffer, wird so lange aufbewahrt wie ihr Run, also erreicht sie die Klasse der Runs in der [Aufbewahrung](governance.md#retention). Ein Thema kopiert keine Frage: Es hält einen Vektordurchschnitt seiner Fragen und liest alles andere aus den Suchen. Sein einziger Text ist der Entwurf, den ein Modell oder ein Mensch dafür geschrieben hat; er wird auf personenbezogene Daten und auf aus den Fragen wiederholte Nummern geprüft, bevor er der Wissensdatenbank hinzugefügt werden kann, und das Thema hält fest, wer ihn mit welchem Dokument hinzugefügt hat. Ein aus einem Thema hinzugefügtes Dokument bleibt in der Wissensdatenbank, wenn eine Person gelöscht wird, deren Frage es geprägt hat, weil ein Mensch bestätigt hat, was es sagt. Siehe [Wissenslücken](knowledge-gaps.md#personal-data) | Zeigen, welche Fragen die Wissensbasis nicht beantworten konnte |
| `knowledge_gap_classifications` | Jede Antwort, die ein Modell auf Wissenslücken gelesen hat, mit ihrem Urteil | Welche Antwort, für welche Wissensbasis, das Urteil, die Begründung des Klassifizierers in einem Satz und sein Run. Sie geht mit der Conversation der Antwort; die Begründung wird gelöscht, wenn die fragende Person gelöscht wird, es sei denn, der Run der Antwort ist nicht mehr da. Eine aus einer Antwort als Lücke gelesene Frage ist eine Zeile von `knowledge_searches` mit der Frage der Person. Siehe [Wissenslücken](knowledge-gaps.md#answers-and-comments) | Nicht zweimal dafür zahlen, dieselbe Antwort zu lesen |
| `case_scores` | Was die Bewertung über die Antwort eines Runs auf einen Fall ergeben hat | Eine Kopie der bewerteten Antwort, bis zu 8.000 Zeichen; die Begründungen des Bewerters und die Zitate, die er in der Antwort nicht finden konnte; die Prüfentscheidung und die Notiz einer Person und wer sie abgegeben hat. Die Entscheidungen, die eine Person abgegeben hat, und die aus ihren Runs aufbewahrten Antworten sind in ihrem Export enthalten (`GET /me/data/export`); das Löschen der Person entfernt diese Antworten, mit den Begründungen und Zitaten, die sie wiederholen können. Die Antwort an einen Besucher auf einer Oberfläche, die die Person veröffentlicht hat, gehört nicht ihr und wird weder an sie exportiert noch mit ihr gelöscht. Zugangsdaten werden geschwärzt, bevor ein Score gespeichert wird, und die Antwort sieht nur, wer den Agent sehen darf, der sie gab. Siehe [Datasets](datasets.md#personal-data) | Entscheiden, ob die Antwort eines Agents bestanden hat |
| `eval_runs`, `eval_run_arms`, `eval_run_cases` | Was ein Agent auf jeden Fall eines Eval-Runs geantwortet hat | Die Antwort und die Argumente jedes Aufrufs, den er gemacht hat - also das, was der Fall gefragt hat, und bei einem aus einer Aufzeichnung beantworteten Fall das, was die Conversation zurückgegeben hat, aus der er stammt; der Spec eines Drafts, den ein Run eingefroren hat. Gelöscht mit seinem Run, und ein Run mit seinem Agent oder Dataset. Das Löschen der Person, von der ein Fall stammt oder deren Zug er enthielt, entfernt die dafür aufgezeichneten Antworten und Aufrufe, kürzt die Manifeste der Runs des Agents und des Bewerters auf das, was der Spec festgelegt hat, und entfernt die Argumente der Aufrufe, die diese Runs zurückgehalten haben; die Runs selbst bleiben. Siehe [Eval-Runs](evals.md#what-a-run-keeps) | Versionen eines Agents vergleichen |
| `case_generations`, `case_proposals` | Entwürfe des Fallgenerators, die auf eine Entscheidung warten | Umformulierungen von Fragen, die Menschen einem Agent gestellt haben, Abschnitte seiner Dokumente und die Verweise darauf. Zugangsdaten werden geschwärzt, bevor ein Entwurf gespeichert wird. Eine Entscheidung löscht den Entwurf. Siehe [Datasets](datasets.md#generating-cases) | Testfälle vorschlagen, die ein Mensch annimmt oder verwirft |
| `artifacts`, `artifact_versions` und ihre Dateien | Seiten, die Agents veröffentlicht haben — Berichte, Dashboards | Was auch immer die Seite zeigt, die der Run aus dem gebaut hat, was er lesen konnte; der Besitzer, der Run, der jede Version geschrieben hat, und, wenn einer aktiv ist, der Schlüssel des öffentlichen Links, seine Einstellungen (ein Passwort als bcrypt-Hash) und wie oft er geöffnet wurde — eine Zahl und ein Zeitpunkt, nichts über die Besucher. Siehe [Apps](artifacts.md) | Ein Ergebnis unter einem stabilen Link teilen |
| `agent_memory_files` | Notizen, die ein Agent über eine Person oder einen Gruppenchat geschrieben hat | Was der Agent für merkenswert hielt, geschlüsselt auf `person:<user_id>` oder einen Chatraum | Kontinuität zwischen Conversations |
| `rag_documents`, `knowledge_bases` und eine Vektortabelle je Collection | Hochgeladene und synchronisierte Dokumente, ihre Chunks und Embeddings | Der Dokumenttext und seine Vektoren, der ursprüngliche Pfad der Datei in der Quelle | Retrieval |
| `agent_runs`, `tool_approvals`, `run_manifests` | Was jeder Run gekostet und getan hat | Der System-Prompt und die letzte an das Model übergebene Anfrage, Tool-Argumente, die auf Freigabe warten, die entscheidende Person und ihre Notiz. Neben den Argumenten hält `tool_approvals.context` die Namen, für die die IDs eines geparkten Aufrufs stehen - den Namen einer Ansicht und einer Tabelle, nie den Inhalt eines Datensatzes -, aufgelöst als die Person des Runs, als der Aufruf geparkt wurde. Er bleibt bei der Freigabe-Zeile, auch nachdem die Ansicht oder Tabelle umbenannt wurde oder verschwunden ist, und wird von jedem gelesen, der über Freigaben entscheiden darf, unabhängig von seinem eigenen Zugriff auf diese Tabelle | Budgets, Freigaben, Run-Historie |
| `routine_deliveries` | Dauerhafte [Übergaben fortgesetzter Routinen](governance.md#resumed-routine-answers) | Fertiger Antworttext, besitzende Person, Organisation, Quelllauf und Routine, Ziel und Zustellstatus. Im begrenzten persönlichen Datenexport enthalten; mit Person oder Quelllauf gelöscht und damit der Laufaufbewahrung unterworfen | Konsolenzustellung ohne erneuten Modellaufruf oder doppelte Nachricht wiederholen |
| `routine_device_waits` | Wartende lokale Routine-Aktivierungen | IDs von Person, Organisation, Routine und Gerät, Aufgaben-Fingerabdruck, unverbrauchter Ereigniskontext, Status und begrenzter Fehlerzähler. Begrenzter Export der besitzenden Person; Kontext nach Start oder Stornierung sofort gelöscht; abgeschlossene Zeilen folgen der Laufaufbewahrung; Löschung von Person, Organisation oder Routine kaskadiert | Auf genau den bestätigten Computer warten, ohne Modellaufrufe oder gestartete Arbeit zu wiederholen |
| `workflow_runs`, `node_runs`, `node_attempts`, `workflow_events`, `dispatch_outbox`, `resource_refs` | Jeder Run eines Workflows, die Versuche jedes Knotens und der Ereignisstrom des Runs | Das Konto, in dessen Namen der Run handelt, und bei einem Run, der aus der [Aktion einer Seite](artifacts.md#actions) gestartet wurde, die Seite und ihre Versionsnummer; das Ergebnis jedes Versuchs, das enthält, was der Knoten aus den ihm übergebenen Daten erzeugt hat; Code und Meldung eines Fehlers; die Datei- und Tabellenverweise, die ein Graph gebunden hat. Workflow-Historie und Dateien folgen `run_retention_days`. Die Bereinigung behält Quellen aktiver Wiederholungen, noch benötigte aufgerufene Läufe und Dateierzeuger mit Verweisen aus behaltenen Läufen. Explizites Löschen eines Workflows kann seine Historie weiterhin entfernen. | Einen Workflow über Neustarts hinweg zu Ende führen und seine Historie zeigen |
| `workflow_approvals` | Die Anfragen, die die [`human.approval`](reference/workflow-nodes.md#human-approval)-Schritte eines Workflows gestellt haben | Titel und Details des Schritts, der daran gebundene Vorschlag und der freigegebene Endtext (Inhalt, im Klartext), die IDs der benannten Freigebenden, die entscheidende Person und ihre Notiz sowie wie stark die Person den Vorschlag geändert hat (`edit_ratio`, eine Zahl zwischen 0 und 1, nie Text). Wird mit dem Run gelöscht | Einer Person ermöglichen, freizugeben, abzulehnen oder zu ändern, was ein Workflow gleich tun wird |
| `workflow_files` | Die Dateien, die die Schritte eines Workflow-Runs gespeichert haben - Downloads, geschriebene Dateien, gerenderte Seiten, umgewandelte Bilder, die Ausgabe eines Skripts und die Anhänge einer Gmail- oder Outlook-Nachricht, die den Run gestartet hat | Was die Datei enthält, was personenbezogene Daten sein können, und ihr Name. Die Bytes liegen unter `MEDIA_DIR` oder im Objektspeicher. Workflow-Historie und Dateien folgen `run_retention_days`. Die Bereinigung behält Quellen aktiver Wiederholungen, noch benötigte aufgerufene Läufe und Dateierzeuger mit Verweisen aus behaltenen Läufen. Explizites Löschen eines Workflows kann seine Historie weiterhin entfernen. | Dateien von einem Schritt an den nächsten weitergeben und sie aus dem Run herunterladen |
| `workflow_exposures`, `workflow_webhook_deliveries` | Die Webhooks und Zeitpläne eines Workflows und jede Webhook-Zustellung, die er zugelassen hat | Das Mitglied, als das jeder läuft, die Eingabe eines Zeitplans, das im Tresor versiegelte Signing Secret eines Webhooks und die ID jeder Zustellung neben dem Run, den sie gestartet hat. Sie verschwinden mit ihrem Workflow und ihrer Organisation, und das Mitglied wird beim Löschen des Kontos entfernt | Einen Workflow von außerhalb der Konsole genau einmal pro Zustellung ausführen |
| `agent_triggers` | Geplante und ereignisgesteuerte Runs | Der Prompt sowie Konfiguration und Filter der Ereignisquelle | Einen Agent ohne Menschen laufen lassen |
| `app_admin_audit_logs` | Wer Zugriff geändert oder Geld ausgegeben hat — die Spur der Organisation und die des Deployment-Administrators teilen sich eine Tabelle | Akteur, Impersonator, IP-Adresse, die Aktion und eine `details`-Map. Die Map benennt meist Felder, aber manche Einträge halten Werte: die E-Mail des impersonierten Kontos, die E-Mail eines vom Administrator gelöschten Kontos, eine Veröffentlichungsnotiz | Rechenschaft. Siehe [Governance](governance.md#audit) |
| `notifications`, `notification_deliveries` | Jede an jemanden adressierte Benachrichtigung und ihre E-Mail-Zustellung. Eine Zeile wird auch dann geschrieben, wenn der Empfänger für dieses Ereignis jeden Kanal abgeschaltet hat - sie ist es, die verhindert, dass dasselbe Vorkommnis zweimal geschrieben wird - und wird dann einfach nie gezeigt oder gesendet; nur die Zustellungszeile ist bedingt | Der Empfänger, eine vorgerenderte Zusammenfassung (nie ein roher Kommentar oder Secret-Wert) und die typisierten Variablen, aus denen eine E-Mail neu rendert; eine Zustellungszeile fügt ihren Kanal, Status, die Versuche und einen bereinigten Fehlgrund hinzu — nie den Fehlertext des Providers. Eine Freigabe, die ein nicht verknüpftes Chat-Konto angefragt hat, behält diesen Anzeigenamen oder das Handle in der Zusammenfassung und den Variablen, bis der Aufbewahrungs-Sweep der Benachrichtigungen die Zeile entfernt - das Löschen der Identität erreicht sie nicht | Warnungen, die eine Person einmal liest, unbeaufsichtigt. Siehe [Governance](governance.md#alerts) |
| `notification_preferences`, `announcements` | Kanal-Umschalter je Ereignis, und die eigenen Ankündigungen eines App-Administrators | Eine Benutzer-Id je Umschalter; der Absender einer Ankündigung, ihr Text sowie die Organisationen und die Rolle, an die sie adressiert war — nie die aufgelöste Empfängerliste, die aus `notifications` nur rekonstruierbar ist, solange diese Zeile nicht durch [den Retention-Sweep für Benachrichtigungen](governance.md#alerts) verfällt — danach hält der Audit-Eintrag dahinter nur noch eine Zahl, nie die Empfänger | Opt-out, und der eigene Nachweis des Verfassers |
| `notification_routes` | Dein ausdrücklich gewählter privater Plattformchat in einer Organisation | IDs für Person, Organisation, private Sitzung und Autorisierungsgeneration; keine Zugangsdaten oder Nachrichtentexte | Chatbenachrichtigungen nach Zustimmung. Ersetzen widerruft wartende Routen. Im persönlichen Export enthalten; Löschen von Person, Sitzung oder Organisation entfernt den Eintrag |
| `embed_visitors`, `channel_identities`, `channel_sessions` | Fremde auf einer gehosteten Seite und Menschen auf Slack, Teams, Telegram oder Mattermost | Ein zufälliger Besucherschlüssel; eine Plattform-Benutzer-Id, ein Benutzername und ein Anzeigename; die Chat-Id | Den richtigen Thread fortsetzen. Bei einer nicht verknüpften fragenden Person werden Anzeigename oder Handle außerdem in der Freigabe-Queue, ihrem CSV-Export und der Freigabe-E-Mail angezeigt, den Personen, die entscheiden |
| `message_ratings` | Daumen und Kommentare zu Antworten | Der Bewertende und sein Kommentar | Qualitätsprüfung |
| `suggestions` | Was die [Arbeit aus eigener Initiative](governance.md#proactive-work) einer Person vorgeschlagen hat, und ob sie es angenommen hat | Die Person, ein Titel und eine Zeile Detail aus ihren letzten Anfragen, der Routine-Prompt oder das Profil, das er setzen würde, und ein Schlüssel, der verhindert, dass ein verworfener Vorschlag wiederkommt | Vorschläge, über die die Person entscheidet |
| `watches` | Was eine Person die [Arbeit aus eigener Initiative](governance.md#proactive-work) in ihren eigenen Verbindungen beobachten lässt | Die Person, welche ihrer Verbindungen, wonach gesucht und was ausgelassen wird in ihren eigenen Worten, wie oft und wann zuletzt nachgesehen wurde | Beobachtungen, die die Person einrichtet |
| `ml_service_calls` | Jeder Aufruf der [ML-Dienste](ml-services.md) und jede Transkription: Diktat, eine Sprachnachricht in einem Kanal, die API, das Diktat eines Besuchers auf einer gehosteten Seite oder in einem Widget | Die Organisation, wer gefragt hat, welcher Dienst, Byte- und Einheitenzahlen, die Dauer und wie es endete; bei einer Transkription außerdem Provider und Modell, die ID des Vault-Schlüssels, mit dem sie gesendet wurde, woher sie kam, der Agent und der Kanal-Bot, für die sie war, und die Länge der Aufnahme. Die Zeile einer Sprachnachricht in einem Kanal nennt die Person, mit der das Konto des Absenders verknüpft ist, und bei einem nicht verknüpften Absender niemanden. Die Zeile eines Besuchers nennt niemanden - weder den Besucher, der kein Konto hat, noch den, der die Seite veröffentlicht hat. Das Löschen der Person, des Agents, des Bots oder des Schlüssels entfernt die Verknüpfung und behält die Zeile - **nichts von dem, was eingereicht wurde, und nichts von dem, was zurückkam** | Nutzungsberichte und der Blick eines Betreibers auf eine Integration, die scheitert |
| `agent_workspaces`, `sandbox_operations` | Dateien, an denen ein Agent gearbeitet hat, und das Log dessen, was er ausgeführt hat | Beim `state`-Backend die Dateien selbst, als JSON; bei einem Container die Session-Id und jedes Kommando, Ziel und Ergebnis-Resümee | Die Sandbox. Siehe [Die Sandbox](sandbox.md#what-was-done-in-one-and-where-that-record-lives) |
| `organization_secrets`, `model_profiles`, `mcp_connections`, `channel_bots` | Zugangsdaten und wohin sie zeigen | Nur versiegelter Chiffretext, mit einem Hinweis; Provider, Model und `base_url` im Klartext | Provider erreichen. Siehe [Secrets](secrets.md) |
Das Löschen einer Conversation entfernt auch ihre gespeicherten Coding-Änderungssätze (`coding_task_changes`).
`workflow_node_spend` bewahrt direkte Entscheidungs- und Embedding-Gebühren nach dem Löschen der Historie: Organisation, Versuch-UUID, Kosten, Teilkostenmarkierung und Zeitstempel. Keine Prompts, Ergebnisse, Dateien oder Mitgliedsidentität. Agentengebühren bleiben in `agent_runs` und zählen nicht doppelt. Nie aufgezeichnete historische Kosten lassen sich nicht rekonstruieren.
Den Text eines aus einer Unterhaltung kopierten Falls sehen nur Leser mit `runs:view` oder Zugriff auf die Quellunterhaltung. Andere sehen Metadaten und einen Platzhalter, sowohl in aktuellen und historischen Versionen als auch in CSV/JSONL-Exporten. Eine fehlende Quelle gibt den Text nicht frei. Verborgener Text kann nicht bearbeitet und durch Metadatenänderungen nicht offengelegt werden. Evals führen weiterhin die vollständige gespeicherte Revision aus.
Antworten, Prüfungsnotizen und Bewertungsbelege benötigen `runs:view` und Zugriff auf den antwortenden Agenten. Fehlt eines davon, bleiben Ergebnis und Status sichtbar, aber Antworttext, Begründungen, Regeln und Zitate werden entfernt. Vor dem Kopieren einer fremden privaten Unterhaltung nennt der Dialog deren Eigentümer und warnt, dass Dataset-Leser mit Leserecht für Runs den Text sehen werden.
`messages.search_vector` ist ein Volltextindex über denselben Inhalt, und
`conversations.summary_messages` ist eine vom Model geschriebene Verdichtung
davon. Beides sind Kopien des Chats und gehen mit ihm.
### Erzeugte Medien { #generated-media }
Ein Bild, ein Sprachclip oder ein Video, das ein Agent erzeugt, ist eine Datei
unter `generated_<org>/` und eine `generated_media`-Zeile, die sie benennt. Die
Zeile hält die Organisation fest, die Conversation, sofern der Run eine hatte, und
die Größe - so ist die Summe der Organisation durch `GENERATED_MEDIA_QUOTA_MB`
(5120) begrenzt, geprüft vor jedem bezahlten Erzeugungsaufruf. Jede Datei zählt,
auch eine ohne Conversation: aus einer Vorschau oder einem Testlauf, aus einem
`/btw`-Einschub in einem Kanal, aus einem API-Run, der keine Conversation nennt,
oder eine Datei, deren Conversation über einen Weg gelöscht wurde, der sie
zurückließ.
Die Datei wird mit ihrer
Conversation gelöscht, mit dem Konto, dem diese Conversation gehörte, vom
täglichen Job `sweep-generated-media`, sobald sie älter als
`GENERATED_MEDIA_RETENTION_DAYS` (90) ist, auch wenn ihre Conversation noch
existiert, und per Präfix mit ihrer Organisation. 0 schaltet jede der beiden
Grenzen ab. Eine Datei ohne Conversation kann kein Mitglied löschen, um Platz zu
schaffen, daher löscht derselbe Job sie nach 7 Tagen, unabhängig von
`GENERATED_MEDIA_RETENTION_DAYS`, auch bei 0. Ein Link darauf - in einer
Kanalantwort oder einer API-Antwort - funktioniert dann nicht mehr.
Das Löschen einer Conversation, eines Kontos oder einer Organisation entfernt die
Zeilen in seiner eigenen Transaktion und reiht das Lösen der Bytes in derselben
Transaktion als Hintergrundjob ein - die Bytes gehen also nur, wenn die Zeilen
gehen, und ein Neustart nach dem Commit verliert das Lösen nicht. Dieser Job
wiederholt ein Präfix, das der Speicher nicht ganz entfernt - das einer
Organisation -, und eine einzelne Datei einer gelöschten Conversation oder eines
gelöschten Kontos, die der Speicher verweigert, weil nichts anderes diese Bytes
je wiederfinden könnte. Eine Datei, die der Speicher auch beim letzten Versuch
des Jobs verweigert, bleibt ohne Zeile unter `generated_<org>/`, bis ihre
Organisation geht, und der Bericht unten zählt sie.
Der Sweep löscht zuerst die Datei und ihre Zeile erst, wenn die Datei weg ist; eine Datei,
die der Speicher verweigert, behält ihre Zeile, und der nächste Sweep versucht es
erneut.
Dateien, die erzeugt wurden, bevor es die Tabelle gab, haben keine Zeile. Sie
werden weiter ausgeliefert, zählen aber nicht gegen das Kontingent, und der Sweep
sieht sie nicht: Sie gehen mit ihrer Organisation oder von Hand, und der
Datenschutzbericht zählt sie zu den Dateien ohne Zeile.
### Außerhalb der Datenbank { #outside-the-database }
| Speicher | Hält | Gelöscht, wenn |
| --- | --- | --- |
| `MEDIA_DIR` auf dem API-Host (Volume `media_data`) | Chat-Anhänge unter `<user_id>/`, Avatare, Embed-Logos, die von Agenten erzeugten Bilder, Sprachclips und Videos unter `generated_<org>/` und eine temporäre Kopie jedes Dokuments unter `_rag_tmp`, solange es geparst wird | Ein Dokument über das Produkt gelöscht wird. Seine Parse-Kopie unter `_rag_tmp` geht, wenn sein Ingest-Job endet - indexiert, abgelehnt, sein Dokument gelöscht oder beim letzten Versuch fehlgeschlagen - und wenn das Dokument gelöscht wird; der stündliche Job `sweep-rag-scratch` entfernt eine Kopie, deren Dokument fehlt oder nicht mehr verarbeitet wird, und räumt so die Kopien weg, die frühere Versionen nie entfernt haben. Die Bytes eines Chat-Anhangs werden nach dem Commit gelöst, der seine Conversation oder seinen Besitzer löscht. Eine erzeugte Datei geht mit der Conversation, in der sie entstand, nach `GENERATED_MEDIA_RETENTION_DAYS` (90) unabhängig davon, was aus der Conversation wurde - nach 7 Tagen, wenn sie keine Conversation hat -, und mit ihrer Organisation; siehe [Erzeugte Medien](#generated-media). Siehe [Was das Löschen erreicht](#what-deletion-reaches) |
| `SANDBOXD_WORKSPACE_ROOT` auf dem Sandbox-Host | Die Dateien jedes containergestützten Workspace | Die Conversation gelöscht wird oder `SANDBOXD_WORKSPACE_TTL` sie wegräumt; ungesetzt bleiben sie unbegrenzt. Siehe [Wie lange etwas überlebt](sandbox.md#how-long-anything-survives) |
| Redis | Rate-Limit-Buckets, geschlüsselt auf den Aufrufer — bei einer öffentlichen Oberfläche ist das die **IP-Adresse im Klartext**, im Schlüssel, für die TTL des Fensters; Dedup-Schlüssel für Trigger und Kanäle; OAuth-Austauschzustand; vorgemerkte Einladungen; die Live-Ansicht eines Browsens — sein letzter Screenshot, seine Schritte und was die Person, die den Browser hält, geklickt und getippt hat, bis das Browsen es liest; die wiederholbaren Browse-Schritte einer Person — Adressen und Beschriftungen dessen, was ihre abgeschlossenen Browses gedrückt haben, nie das Getippte | Beim Ablauf: eine Live-Ansicht eine Stunde nach dem letzten Frame des Browsens, wiederholbare Schritte zwei Wochen nach der letzten Erledigung der Aufgabe, alles andere binnen Minuten |
| `background_jobs` in PostgreSQL | Der Payload jedes Hintergrund-Jobs, sein letzter Fehler und die Antwort eines asynchronen API-Runs | Der Aufbewahrungs-Sweep entfernt einen beendeten Job nach `BACKGROUND_JOB_RETENTION_DAYS` (14). Payloads sind Ids und Pfade, mit zwei Ausnahmen: der **`event_context` eines ereignisgesteuerten Auslösens** — Absender, Betreff und Text einer Gmail- oder Outlook-Nachricht samt Nachrichten- und Thread-Id, eines GitHub-Issues, eines Webhook-Payloads — sowie **Prompt und Antwort eines asynchronen API-Runs** bleiben bis dahin im Job. Die Logs des Workers laufen durch denselben Redaktionsfilter wie die der API |
| Logfire, wenn konfiguriert | Traces jedes Runs | Die Aufbewahrung des Providers. Heute trägt ein Trace den vollen Prompt, die Ausgabe und die Tool-Argumente — siehe [Traces](#traces) |
| Ihr SMTP-Relay | Einladungen, Magic Links, Freigabeanfragen, Budget-Warnungen, Nutzungsberichte, und die eigene Mail des [Benachrichtigungs-Postfachs](governance.md#alerts) - ein Run, der unbeaufsichtigt fertig wird oder scheitert, die Ingestion eines Dokuments, die abschließt oder scheitert, ein Sicherheitsereignis oder eine Konfigurationsänderung, die eigene Ankündigung eines Admins - und Betreff und Text eines [`email.send`](reference/workflow-nodes.md#email-send)-Schritts eines Workflows, an die Adressen, die er bekommt | Was das Relay aufbewahrt. Eine Freigabe-Mail nennt den Agent, das Tool und einen Link, nicht die Argumente des Tools; bei einem Aufruf, den ein nicht verknüpftes Chat-Konto angefragt hat, nennt sie auch dessen Anzeigenamen oder Handle und den Bot |
| Backups | Ein `pg_dump` ist die ganze Datenbank; das Media-Volume sind die Dateien | Ihr Backup-Ablauf. Eine Löschung erreicht ein bereits gezogenes Backup nie — siehe [Backups](deploy.md#backups) |
## Was das Deployment verlässt { #what-leaves-the-deployment }
Nichts geht hinaus, solange nicht eine Zeile oder eine Einstellung ein Ziel
benennt, mit einer Ausnahme: Die [Deployment-Diagnose](#deployment-diagnostics) ist
standardmäßig aktiv. Dies ist die vollständige Liste der Ziele, mit der Konfiguration, die
über jedes entscheidet.
| Ziel | Was gesendet wird | Entschieden durch | Standort und Bedingungen |
| --- | --- | --- | --- |
| Der Diagnose-Kollektor | Installationszustand, grobe Nutzungszähler, Zähler fehlgeschlagener Runs, Jobs und Ingestionen nach geschlossenen Kategorien und ein pseudonymes Aktivitätssignal, das jeder Browser oder jede App sendet; keine Prompts, Konversationen, Dateinamen, Kontonamen, E-Mail-Adressen oder Provider-Schlüssel | `DIAGNOSTICS_ENABLED` (Standard `true`) und `DIAGNOSTICS_COLLECTOR_URL` | Standardmäßig `https://analytics-agenticos.testapp.ovh`; [was gesendet wird](configuration.md#diagnostics) |
| Das Chat-Model | Die bisherige Conversation, eingefügte oder beschriebene Anhänge, abgerufene Chunks, Tool-Ergebnisse; einmal pro Nacht, für die [Arbeit aus eigener Initiative](governance.md#proactive-work), die letzten Anfragen einer Person (nur die Prompts, die den Eingabe-Guardrail des Agents passiert haben; ein von ihm geschwärzter Prompt wird ungeschwärzt gelesen, [#2655](https://github.com/vstorm-co/agenticos/issues/2655)), ihr Profil und was ihr Agent über sie notiert hat | Ein [Model-Profil](models.md#a-model-profile): `provider`, `model`, `base_url` und ein versiegelter Schlüssel. Siebenundzwanzig Provider; `ollama` und `litellm` sind schlüssellos und werden an einem Endpunkt erreicht, den Sie betreiben, und `openai`, `anthropic`, `google`, `huggingface` und andere akzeptieren eine `base_url`, ein EU-Endpunkt oder ein Gateway ist also ein Feld und keine Abzweigung. Ein `openai`- oder `azure`-Profil auf der Responses-API sendet `store: false`, der Provider behält also keine gespeicherte, abrufbare Antwort, sofern das Profil nicht `openai_store` setzt; die Aufbewahrung von OpenAI zur Missbrauchsüberwachung gilt weiterhin, sofern das Konto keine Zero Data Retention hat | Die des Providers. Je Profil prüfen |
| Das Model des Fallgenerators | Die Anweisungen, Skill-Auszüge und Tool-Beschreibungen des getesteten Agents; Abschnitte der Dokumente seiner Wissensbasis; die Fragen, die Menschen ihm gestellt haben, mit dem Kommentar zu einer negativ bewerteten Antwort. Zugangsdaten werden vor dem Senden aus Abschnitten und Fragen geschwärzt | Das im Dataset konfigurierte Generierungsmodell, nur nach einem Start durch eine Person mit `datasets:edit`. Gesprächsquellen benötigen zusätzlich `runs:view`. | Die des Providers. Je Profil prüfen |
| Das Embedding-Model | Jeder Chunk jedes Dokuments einer Collection, jede Retrieval-Anfrage und noch einmal die Anfragen, die nichts gefunden haben, wenn [Wissenslücken](knowledge-gaps.md#topics) sie gruppieren | Je Collection, und nur dort: `embedding_provider` (`openrouter`, `openai` oder `ollama`, aus dem Katalog) und, für die ersten beiden, der Vault-Schlüssel `embedding_secret_id`, der zahlt. Einen deploymentweiten Embedding-Schlüssel gibt es nicht; eine schlüsselpflichtige Collection ohne einen verweigert Indexierung und Suche. `ollama` ist schlüssellos und wird an dem lokalen Dienst erreicht, den die Collection benennt (`embedding_endpoint_id`), einem Host, den Sie betreiben | Die des Providers oder Ihr eigener Host. [Eine dauerhafte Wahl](choosing-models.md#embeddings-are-a-separate-permanent-choice) |
| LlamaCloud | Das ganze Dokument | Eine Collection, deren `pdf_parser` `llamaparse` ist; sie muss einen Vault-Schlüssel benennen (`llamaparse_secret_id`), einen Deployment-Schlüssel gibt es nicht. Der Standard `pymupdf` parst im Worker | Die von LlamaCloud, falls genutzt |
| Ein OCR-Server | Gerenderte Seiten eines Dokuments | Eine Collection, deren `pdf_parser` `liteparse` ist **und** deren `ocr_endpoint_id` einen lokalen Dienst benennt; ohne einen läuft OCR im Worker | Ihr eigener Host — ein lokaler Dienst liegt konstruktionsbedingt im Netz des Deployments |
| Ein Bildbeschreibungs-Model | Bilder in Dokumenten | Das `image_description_model` einer Collection | Die dieses Model-Providers |
| Web-Recherche | Die Suchanfrage, die der Agent formuliert hat | `web_research.method` auf dem Spec: `duckduckgo` (kein Schlüssel), `tavily`, `brave` oder `exa` (je ein `search`-Secret), oder `native`, wobei der Provider des Chat-Models sucht | Die des Suchanbieters oder des Model-Providers |
| Web-Fetch und der Webbrowser | Die URL; beim Browser, was er auf den geöffneten Seiten eintippt | Die Capability auf dem Spec; der Browser braucht zusätzlich einen CDP-Endpunkt auf `BROWSER_CDP_ALLOWED_HOSTS`, standardmäßig leer | Die abgerufene Seite; der Browser-Host und die Seiten, die er öffnet |
| Proxy oder gehosteter Browser eines Agents | Alles, was der Browser lädt und sendet, wie es sonst der Browser im Deployment täte - Seiten, Formularinhalte, Cookies, Anmeldungen - samt der eigenen Aufzeichnung des Proxys oder Dienstes | `browser_use.connection` in der Spec (#2130); standardmäßig `built_in` | Der Proxy oder der gehostete Browser-Dienst (Browserbase, Steel oder ein anderer), unter dem eigenen Vertrag der Organisation |
| Die Schritte des Webbrowsers | Jeder Schritt eines Durchlaufs geht an das eigene Modell des Agenten: die URL der Seite, ihr Titel, die Beschriftungen der sichtbaren Elemente und bis zu 4.000 Zeichen ihres sichtbaren Texts, mit `vision` auch ein Screenshot — was der Inhalt eines internen Systems sein kann. Was ein Feld enthält, wird nicht wiederholt: Die Elementtabelle sagt nur, dass ein Feld gefüllt ist | Die Capability `browser_use` auf dem Spec | Der Modellanbieter des Agenten, wie beim Gespräch |
| Computer-Bedienung | Jeder Screenshot des Desktops geht an das eigene Modell des Agenten und kann alles zeigen, was darauf geöffnet ist; keiner wird mit dem Run gespeichert. Die Aktionen, auch der Text, den das Modell tippt, gehen an den Desktop | Die Capability `computer_use` auf dem Spec, mit einer Sandbox-Verbindung für einen Desktop in der Sandbox; ein Daemon-Desktop braucht seinen Host auf `COMPUTER_DAEMON_ALLOWED_HOSTS`, standardmäßig leer, und das Token der Organisation dafür im Vault | Der Modellanbieter des Agenten; die Sandbox-Verbindung des Agenten oder der `computerd`-Host, den der Betreiber betreibt |
| Lokale Coding-Agents | Die Aufgabe und der Code, den Claude Code oder Codex auf dem Rechner der Person liest | `coding_agent.runs_on: this_computer`, vollständiger Ordnerzugriff und native Startbestätigung. Modell, Endpoint und Anmeldung bestimmt der lokale Agent; das Deployment wählt sie nicht | Direkt von diesem Rechner zum Anbieter oder Gateway des lokalen Agents. Der Datenschutzbericht unterscheidet diesen Weg von der Ausführung in der Sandbox |
| Die Sandbox, ausgehend | **Alles im Workspace, an jeden beliebigen Host** — die Runtime `workbench` hat ein Netz, eine Shell und `curl` | Die Capability `sandbox` und eine Runtime mit `needs_network`; die Kommandofreigabe steuert, was läuft, nicht wohin es sich verbindet | Wohin das Kommando ging. Egress-Kontrolle ist die Firewall des Sandbox-Hosts, keine Einstellung hier |
| Ein MCP-Server | Tool-Argumente und -Ergebnisse, eines Agents oder eines [`mcp.call`](reference/workflow-nodes.md#mcp-call)-Schritts eines Workflows | `mcp_connections.url`, je Organisation oder je Person | Die des Serverbetreibers |
| Google Workspace und Microsoft 365 über einen Server, den Sie selbst betreiben | Was der `mcp.call`-Schritt eines Agents oder Workflows anfragt: Suchbegriffe, Nachrichten- und Thread-IDs, Antworttext, Termindetails. Ihr eigener Server leitet es an die APIs von Google oder Microsoft weiter und hält auch die Tokens des angemeldeten Kontos | Eine Organisations- oder persönliche Connection, angelegt aus dem Katalogeintrag `google-workspace` oder `ms-365` | Ihr Server, dann Google oder Microsoft |
| Microsoft Work IQ | Was ein Tool-Aufruf anfragt, und die Antwort, im gehosteten Dienst von Microsoft; abgerechnet in Copilot Credits | Eine Connection aus dem Katalogeintrag `work-iq` | Microsofts |
| Ein Host im eigenen Netzwerk | Alles, was ein Workflow-HTTP-Schritt, ein Konnektor, ein A2A-Aufruf oder eine MCP-Connection dorthin sendet | `OUTBOUND_PRIVATE_ALLOWLIST`, standardmäßig leer; `MCP_ALLOWED_HOSTS` nur für MCP | Der Host, den Sie listen. Jedes Konto jeder Organisation erreicht jeden seiner Ports |
| Das Modell des Wissenslücken-Entwerfers | Die neuesten Fragen einer Wissenslücke (bis zu 20): was jede Person gefragt hat, was die Suche zurückgab, welche Antwort sie bekam und die Kommentare der Leser, wobei E-Mail-Adressen, Telefon-, Karten- und Kontonummern sowie bestellnummerähnliche Nummern vorher entfernt werden - Namen nicht; dazu die Kontextdateien der Agents des Themas, die die entwerfende Person lesen darf | Nur auf ausdrücklichen Auftrag einer Person mit Wissensbasiszugriff, einem lauffähigen Modell und Budget. | Der Anbieter dieses Modells |
| Das Modell des Wissenslücken-Klassifizierers | Die letzten Antworten einer Wissensbasis (bis zu 100 je Prüfung) oder die schlechten Antworten einer Verbesserungssitzung: was jede Person gefragt hat, welche Antwort sie bekam und die Kommentare zu negativen Bewertungen, dazu die Anweisungen und die Kontextdateien des antwortenden Agents, die die prüfende Person lesen darf | Nur auf ausdrücklichen Auftrag einer Person mit Wissensbasiszugriff, einem lauffähigen Modell und Budget. | Der Anbieter dieses Modells |
| Die Dienste eines virtuellen Terminals | Die Befehle, die der Agent auf jedem eingebundenen Ordner ausführt, und was er dort schreibt; was er liest, geht an das Modell des Agents zurück | Die Ordner der Capability `mirage` im Spec: ein Dienst, seine Optionen und ein Vault-Secret oder ein [verbundenes Konto](secrets.md#connected-accounts). Ein eingetippter Host muss in `MIRAGE_ALLOWED_HOSTS` stehen | Die jedes eingebundenen Dienstes - Google, GitHub, Notion, Ihre eigene Datenbank oder Ihr Server |
| Logfire | Spans für jede Anfrage und jeden Run | `LOGFIRE_TOKEN` deploymentweit; ein `observability`-Token auf einem Spec oder `logfire_token_secret_id` auf einem Environment lenkt diese Runs in ein anderes Projekt. `LOGFIRE_BASE_URL` wählt das US- oder EU-Deployment. Überall ungesetzt wird nichts gesendet | Die von Pydantic, US oder EU |
| Speech-to-Text, Bildgenerierung | Eine Sprachnachricht aus einem Kanal, eine in `/chat` diktierte Aufnahme oder die Aufnahme eines anonymen Besuchers auf einer gehosteten Seite oder in einem Widget; der Prompt | Der Provider, auf den sich eine Aufnahme auflöst - das eigene Paar des Bots, die Überschreibung des Agents oder die Voreinstellung der Organisation, die ein Bot erbt, sofern er nicht ausgeschaltet ist -, gesendet mit dem neben diesem Paar benannten Vault-Schlüssel - einem API-Schlüssel für `groq`, `mistral` oder `openai`, auf Organisations- und Bot-Ebene organisationsweit sichtbar; beim Diktieren in `/chat` zusätzlich die Engine der Organisation auf `server`, und bei einer Seite oder einem Widget deren eigenes `dictation: server`. Ein Profil für `google` oder `openai` für Bilder. Das Audio eines Diktats wird hier nicht gespeichert. Mit `browser` auf einer Seite oder in einem Widget schickt der Browser des Besuchers das Audio an seinen Anbieter, und nichts davon geht durch dieses Deployment | Die des Providers, oder für Bilder Ihr eigener Host; bei `browser` die des Browser-Anbieters |
| Ein Realtime-Sprach-Provider | Während eines [Sprachanrufs](voice.md): das Audio des Anrufers, die Anweisungen und Tool-Definitionen des Agents, Tool-Ergebnisse und die früheren Züge der Unterhaltung als Text, wenn ein Anruf beginnt oder sich neu verbindet | Der Abschnitt „Sprachgespräche“ (Voice conversations) auf der Karte Stimme des Agents: `provider`, `model` (oder ein Azure-Deployment) und der Vault-Schlüssel `secret_id`, veröffentlicht; ohne den Abschnitt nimmt der Agent keine Anrufe an. Über WebRTC (OpenAI) fließt das Audio direkt zwischen Browser und Provider; über das Relay (Azure, Gemini, xAI) geht es durch dieses Deployment, ohne gespeichert zu werden. Hier wird kein Audio behalten, und die Sitzung behält nur Transkripte | Die des Providers |
| Sprachausgabe | Der zu sprechende Text und eine etwaige Anweisung, wie er gesprochen wird | Der `provider` der Capability `text_to_speech`: `openai`, `elevenlabs` oder `google`, mit dem Schlüssel des Bindings | Die des Providers |
| Videoerzeugung | Der Prompt und ein etwaiges Startbild | Der `provider` der Capability `video_generation`: `google`, `byteplus`, `xai` oder `alibaba`, mit dem Schlüssel des Bindings. `google` speichert die Interaktion (`store: true`), weil Gemini einen Clip nur aus einer gespeicherten per Adresse liefert; die anderen drei werden nicht darum gebeten | Die des Providers |
| Slack, Teams, Telegram, Mattermost | Die Antworten des Agents; die E-Mail-Adresse eines neuen Mitglieds, um es für eine [Begrüßung](channels.md#a-welcome-for-a-new-member) in Slack, Mattermost oder Teams zu finden | Eine `channel_bots`-Zeile mit ihrem Token im Vault | Der Messaging-Anbieter hält den Chat ohnehin schon |
| Google-Anmeldung | Nichts ausgehend; Google liefert E-Mail, Name, Bild und Konto-Id zurück | `GOOGLE_CLIENT_ID` | Die von Google |
| Ihr SMTP-Relay | Die oben genannte Post und der Text eines [`email.send`](reference/workflow-nodes.md#email-send)-Schritts, an die Adressen, die sein Autor gewählt hat | `SMTP_HOST`, `SMTP_TLS` | Ihre, dann die jedes Empfängers |
Sync-Konnektoren laufen andersherum: Eine Google-Drive- oder S3-Quelle zieht
Dokumente **herein**, authentifiziert durch ein `connector`-Secret, und von da an
sind die Dokumente die Kopie des Deployments und folgen den Regeln oben. Wer
lesen kann, was eine Quelle aufgenommen hat, ist
[eine Entscheidung der Quellzeile](file-processing.md#who-ends-up-able-to-read-what-a-source-ingested).
## Tabellendaten auf einer Seite { #table-data-on-a-page }
Eine veröffentlichte [Seite](artifacts.md#live-data) kann Datensätze aus einer
Tabelle zeigen, und diese Datensätze können personenbezogene Daten sein. Das ist
**ein Fluss innerhalb des Deployments, vom Besitzer der Seite zu allen, die die
Seite öffnen können** - kein Ziel außerhalb davon -, aber er umgeht die eigene
Zugriffskontrolle der Tabelle und ist deshalb hier aufgeführt.
- **Was fließt.** Nur die Spalten, die eine Seitenabfrage nennt, und die Zeilen,
die ihre Filter auswählen, bis zu 1.000 pro Binding. Ein Filter darf eine Spalte
nutzen, die die Seite nicht zeigt, und der Besitzer erfährt, welche. Formeln,
Lookups, Rollups und Link-Labels tragen auch Daten aus verknüpften Tabellen, und
die Einwilligung nennt diese Tabellen.
- **Auf wessen Befugnis.** Der des Besitzers der Seite. Jedem Betrachter werden
dieselben Datensätze ausgeliefert, gleich welchen eigenen Zugriff er auf die
Tabelle hat. Die Daten verlassen die Tabelle erst, wenn der Besitzer sie
bestätigt hat, nachdem er die Abfragen in Worten gelesen hat und wer die Seite
jetzt und später öffnen kann (die Rollen, die jede Seite öffnen, die
Sichtbarkeit, Personen und Gruppen). Die Daten werden bei jedem Laden erneut
gelesen und nie in der Seite gespeichert. Lesevorgänge für Mitglieder werden nicht
gecacht; die für eine öffentliche Seite schon, wie unten beschrieben.
- **Was darüber gespeichert wird.** Je Seitenversion: wer sie veröffentlicht hat,
ein Fingerabdruck ihrer Abfragen, ob der Besitzer eingewilligt hat, wann und mit
welcher Mitgliedschaft. Freigabeanfragen halten den Anfragenden, die Art, eine
optionale Notiz, die Entscheidung und wer sie getroffen hat. Der Audit-Trail
erfasst Einwilligung, Zurückziehen, automatische Einwilligung, `edit_data`-Grants,
Besitzerwechsel und Anfragen, mit dem Text, den eine Person bestätigt hat.
- **Was nie protokolliert wird.** Datensatzwerte, Filterwerte und die
Inhaltsadresse einer Seite, die mit ihren Daten ausgeliefert wird. Die
Audit-Einträge und Benachrichtigungen nennen die Seite und die Personen, nie
eine Zeile.
- **Was sie nicht erreicht.** Die Einwilligung eines gelöschten Mitglieds verfällt mit
seiner Mitgliedschaft, und eine Seite, deren Besitzer gegangen ist, liefert
keine Daten aus, bis ein anderer Besitzer sie bestätigt.
### An Personen ohne Konto { #table-data-on-a-public-page }
Das ist der eine Ablauf hier, der **den Kreis der Personen mit einem Konto verlässt**.
Der [öffentliche Link einer Seite und ihre Embeds](artifacts.md#live-data-on-a-public-link)
können dieselben Datensätze für jeden, der die Adresse öffnet, und für jede Website,
die sie einbettet, ohne Anmeldung in die Seite schreiben. Zwei Entscheidungen öffnen
ihn, und ein Deployment, das den Ablauf nicht will, lässt die erste aus.
- **Standardmäßig aus, für die ganze Organisation.** `public_live_data` ist ein
Schalter, den nur ein Owner oder Admin ändert, als er selbst. Ist er aus, zeigt keine
Seite Daten auf einem Link oder in einem Embed, was auch immer ihr Besitzer bestätigt
hat.
- **Dann pro Seite.** Der Besitzer der Seite oder ein Owner oder Admin für ihn bestätigt
sie nach einem Bildschirm, der die Tabellen und Spalten nennt und sagt, wer sie lesen
kann - jeder mit dem Link, sein Passwort und sein Ablauf, jede einbettende Website.
Die Einwilligung ist an die Seitenabfragen und an dieses Publikum gebunden. Eine
Website hinzuzufügen, das Passwort zu entfernen, den Link auszuschalten, die Seite zu
archivieren, ein neuer Besitzer und eine zurückgezogene Einwilligung der Mitglieder
löschen sie.
- **Was gespeichert wird.** Auf der Seite: der Fingerabdruck der Abfragen, für die sie
gegeben wurde, wer sie bestätigt hat, die Mitgliedschaft des Besitzers und wann. Die
Zeile der Organisation hält den Schalter. Der Audit-Trail erfasst
`organization.public_live_data_changed`, `artifact.public_data_consented`,
`artifact.public_data_withdrawn` und `artifact.public_data_voided` mit Tabellen- und
Spaltennamen, den einbettenden Websites, ob ein Passwort gesetzt ist, und dem Grund -
nie eine Zeile, ein Wert oder ein Besucher.
- **Der Cache.** Die Datensätze eines Bindings werden 30 Sekunden lang im Speicher des
API-Prozesses gehalten, damit eine stark besuchte Seite ihre Tabelle nicht einmal pro
Besucher liest. Sie werden **nie in Redis**, die Datenbank oder eine Datei geschrieben,
der Speicher ist in Bytes begrenzt (`ARTIFACT_PUBLIC_DATA_CACHE_BYTES`) und mit dem
Prozess verschwunden. Jede Zugriffsbedingung läuft, bevor der Cache gelesen wird,
sodass das Ausschalten des Schalters oder das Rotieren des Links den Ablauf beim
nächsten Laden beendet; was ein Besucher bereits geladen hat, bleibt in seinem Browser.
- **Was nie protokolliert wird.** Datensatzwerte, Filterwerte, der Schlüssel des Links
und die Inhaltsadresse einer Seite, die mit ihren Daten geladen wurde, bleiben aus
Logs, Traces und Audit-Einträgen heraus. Kein Besucher wird erfasst: Der Link zählt
Öffnungen, keine Personen. Nur der Schlüssel des Rate-Limits hält die IP des
Besuchers, in Redis, für Minuten.
- **Niemand erfährt, warum.** Ein Besucher, dessen Laden an einer Bedingung scheitert,
sieht die Seite ohne ihre Daten und ohne Grund, sodass die Seite nicht sagt, was eine
Tabelle enthält oder warum es verborgen ist.
- **Was eine Website sieht, die die Seite einbettet.** Die einbettende Website rahmt die
Seite; die Seite läuft in einem opaken Origin ohne Netzwerk, sodass die Website die
Datensätze nicht aus dem Frame lesen kann, aber wer die Website öffnet, liest sie.
Datensätze, die jedem mit einem Link gezeigt werden, kann jeder kopieren, der sie sieht.
Binden Sie eine öffentliche Seite nur an Spalten, die öffentlich sein sollen.
Ein Deployment, das die Zeilen einer Tabelle vor einigen seiner Mitglieder
schützen muss, sollte keine Seite an sie binden, die diese Mitglieder öffnen
können; die Bestätigung nennt, wer sie sind.
## Kontrollen, und wo jede nachgewiesen ist { #controls-and-where-each-is-proved }
Jede Zeile benennt den Mechanismus im Code und den Test oder die Seite, die ihn
festnagelt, oder das Issue, das es tun wird. Eine Zeile, deren letzte Spalte ein
Issue ist, ist eine Lücke und steht als solche da.
| Kontrolle | Mechanismus | Nachgewiesen durch |
| --- | --- | --- |
| Mandantentrennung | `organization_id` auf jeder Tabelle, die einer Organisation gehört, bei jeder Anfrage aus `X-Organization-Id` auf eine Mitgliedschaft aufgelöst; Kindzeilen nur über die Prüfung ihres Elternteils erreichbar | `tests/integration/test_conversation_tenant_isolation.py` und Geschwister; [Berechtigungen](permissions.md) |
| Zugriff auf eine Zeile | Drei Schichten: Deployment-Administrator, Rolle in der Organisation, Grant je Ressource über `resolve_access`. Ein Bedienelement, das der Aufrufer nicht nutzen darf, wird nicht gerendert | Ablehnungstests in `tests/api/`; [Berechtigungen](permissions.md#how-the-layers-combine) |
| Den Chat einer anderen Person lesen | Besitzer, eine ausdrückliche Freigabe oder der App-Administrator des Deployments — nie eine Rolle in der Organisation. Der Chat eines Projekts wird nur über das Projekt gelesen: von allen, die das Projekt sehen dürfen, die Person, die ihn begonnen hat, eingeschlossen, und von niemandem mehr, der es nicht mehr darf. Conversations haben ihre eigene Prüfung, `ConversationService._may_read`, statt der Grant-Formel | `admin_conversations.py` verlangt `is_app_admin`; `tests/integration/test_conversation_tenant_isolation.py` |
| Zugangsdaten im Ruhezustand | Envelope-Verschlüsselung je Organisation, versionierte Masterschlüssel, Rotation mit Trockenlauf | [Secrets](secrets.md#what-never-happens), vier durch Tests festgenagelte Garantien |
| Inhalte im Ruhezustand | **Von der Anwendung nicht verschlüsselt.** Die Postgres-Daten, `media_data` und das Workspace-Wurzelverzeichnis der Sandbox verlassen sich auf die Platten- oder Volume-Verschlüsselung, die Sie bereitstellen. Ausnahme sind hochgeladene und Chat-Dateien bei `FILE_STORAGE_BACKEND=s3` und `FILE_STORAGE_S3_ENCRYPTION` auf `sse-s3` (der Voreinstellung) oder `sse-kms` unter einem Schlüssel, den Sie halten: Jeder Schreibvorgang bittet den Store dann, sie zu verschlüsseln. Der dritte Modus, `none`, sendet keinen Verschlüsselungs-Header und existiert für einen S3-kompatiblen Store ohne KMS | Sache des Betreibers. [Konfiguration](configuration.md#uploaded-files-at-rest); `agenticos cmd doctor` nennt das Backend, auf dem ein laufendes Deployment steht |
| Auf dem Transportweg, eingehend | HTTPS an Ihrem Proxy; `Strict-Transport-Security`, wenn `ENVIRONMENT=production`; Session-Cookies `httpOnly`, und `secure` aus dem Schema der Anfrage bei Anmeldung und Refresh. Die Route für den Passwortwechsel setzt `secure` nur in einem Produktions-Build | [Deploy](deploy.md#choose-a-reverse-proxy); `frontend/src/app/api/auth/login/route.ts` |
| Auf dem Transportweg, zu den Speichern | `POSTGRES_SSLMODE` und `REDIS_SSL`; `agenticos cmd doctor` meldet, ob die hergestellte Verbindung verschlüsselt war | [Verschlüsselte Verbindungen](configuration.md#encrypted-connections-tls); `tests/integration/test_store_tls.py` |
| Auf dem Transportweg, zu den Providern | HTTPS zu jedem katalogisierten Endpunkt. Eine eigene `base_url` wird ohne Host oder mit Zugangsdaten darin abgelehnt, aber **`http://` wird akzeptiert**, für ein Ollama oder ein Gateway im Netz des Deployments selbst; ein Klartext-HTTP-Profil, das aus diesem Netz hinauszeigt, sendet Prompts und Schlüssel im Klartext. Punkt 4 der Checkliste listet jedes solche Profil | `refused_field("base_url", ...)` im Model-Profile-Service; das Schema ist Sache des Betreibers |
| Secrets in Antworten, Logs, Audit, Exporten | Kein Endpunkt gibt einen Klartext zurück; `SecretStr` überall; Specs referenzieren Secrets per Id | [Secrets](secrets.md#what-never-happens) |
| Personenbezogene Daten in Logs | `app/core/logging.py` redigiert E-Mail-Adressen, JWTs, API-Schlüssel, Bearer-Token, Discord-Interaktions-Token, vollständige Abfragen signierter Discord-Anhangs-URLs, `password=`-Paare und das geheime Segment einer Adresse - den Link-Schlüssel oder das Inhalts-Token eines Artifacts, das Token einer geteilten Unterhaltung, eines Workflow-Formulars, eines Webhook-Tests, einer Kanalverknüpfung oder einer Einladung oder das Fortsetzungs-Token eines Workflow-Laufs - sowie den Wert eines Query-Parameters, der als Zugangsdatum dient - `visitor` und `token` am Socket des Agent-Widgets, `code`, `state` und `invitation_handle` einer Anmeldung und das `token` eines per E-Mail verschickten Links - aus jedem Log-Record, in API wie Worker, das Access-Log von uvicorn und seine WebSocket-Zeilen eingeschlossen. Dieselben Segmente und Werte werden in Logfire-Spans und den Endpunkt-Argumenten, die sie mitführen, redigiert, bevor ein Span kopiert oder ausgegeben wird. Die mitgelieferten Konfigurationen für Traefik und Nginx lassen den Pfad, den Query-String und den `Referer` im Access-Log des Proxys weg Ein Discord-Aufruf, der sich mit einem Interaktions-Token in seiner URL ausweist, wird nicht getraced | `tests/test_logging.py`, `tests/test_logfire_redaction.py`; der Worker installiert es in `app/worker/__main__.py`, jeder Kindprozess der Ingestion in `app/worker/child.py` (#440); [Deploy](deploy.md#choose-a-reverse-proxy) |
| Personenbezogene Daten, die das Model erreichen | Die Capability `guardrails` redigiert IBANs, Kartennummern, US-Sozialversicherungsnummern, Telefonnummern und E-Mail-Adressen aus Prompts, Antworten, Tool-Ergebnissen und Tool-Argumenten, sofern konfiguriert | [Capabilities](reference/capabilities.md); ihre Tests unter `tests/` |
| Personenbezogene Daten in einer Fehlerspalte | `rag_documents.error_message` und Verwandte halten Stufe und Klasse fest, nie den Text des Kunden | `app/services/rag/failures.py` (#423) |
| Rechenschaft | Audit-Einträge teilen die handelnde Transaktion und scheitern geschlossen; Impersonation nennt beide Personen; Massenexporte werden festgehalten | [Governance](governance.md#audit) |
| Audit-Export | `GET /audit/export`, CSV oder JSONL über ein Fenster, auf `audit:read` gegated und in der Spur selbst festgehalten | [Governance](governance.md#audit) (#1422) |
| Manipulationsnachweis der Spur | Jeder Eintrag gehört zu einer Hash-Kette je Organisation, und jede Kette trägt einen Checkpoint auf ihrem höchsten Stand, damit ein umgeschriebener Eintrag, ein gekapptes Ende und eine gelöschte Kette allesamt erkennbar sind. `agenticos cmd audit-verify` läuft sie ab und endet bei einem Bruch mit einem Exit-Code ungleich null | [Governance](governance.md#audit) (#1622, #1648). Erkennung, keine Verhinderung: wer die Zugangsdaten der Datenbank selbst hat, schmiedet eine Kette neu oder entfernt den Trigger, der den Checkpoint schützt |
| Traces | `observability.content` je Agent: `full` zeichnet alles auf, `none` nur Zeit, Tokens, Kosten und Tool-Namen, und ein Spezialist dieses Agents erbt den Modus | [Umgebungen](environments.md) (#1413); ein `redacted`-Dazwischen wurde verworfen, [#1616](https://github.com/vstorm-co/agenticos/issues/1616) |
| Aufbewahrung nach Zeitplan | Je Organisation und je Klasse — Gespräche und ihre Dateien, Runs und Manifeste, Workspaces, das Gedächtnis von Agenten, hochgeladene Dokumente und Audit — innerhalb einer deploymentweiten Vorgabe, Obergrenze und Audit-Untergrenze. Ein täglicher Sweep löscht hart und hält Zähler fest, nie Inhalte. Receipts, zugestellte Outbox-Zeilen und die History der Virtual Tables werden im selben Lauf bereinigt, mit Fristen für das ganze Deployment statt je Organisation. Backups und alles bereits an einen externen Collector Geschickte liegen außerhalb. `notifications` gehört nicht zu diesen Klassen: Es wird stattdessen nach einem eigenen festen Zeitplan geräumt — eine _gelesene_ Zeile nach 90 Tagen, jede Zeile nach einem Jahr in jedem Fall. `announcements` selbst sind ausgenommen, sodass das Gesendete über die Audit-Spur beantwortbar bleibt, nachdem seine Zustellungen gealtert sind Generierte Medien haben ebenfalls ihre eigene Frist `GENERATED_MEDIA_RETENTION_DAYS`. | [Aufbewahrung](governance.md#retention); `test_retention.py`, `tests/integration/test_retention_sweep.py`; der Notification-Sweep ist `tests/integration/test_notification_retention.py` (#1598, Decision 8); `test_generated_media.py`, `tests/integration/test_generated_media.py` |
| Löschung einer Person | Die Kontolöschung bereinigt, was sie blockieren würde, löst die Anhang-Bytes nach dem Commit und räumt weg, was keine Kaskade erreicht - die Notizen, die Agents über die Person geschrieben haben, ihre Plattform-Identitäten, ihre Workspaces. Die Löschung des Gedächtnisses ist ebenfalls ein eigener Aufruf | [Was eine Löschung erreicht](#what-deletion-reaches) für das bewusst Aufbewahrte; `test_personal_data.py` |
| Zugang zu den eigenen Daten | Eine Person liest unter Einstellungen → Gedächtnis alles, was jeder Agent hier über sie aufgeschrieben hat, und kann eine Notiz stilllegen, wiederherstellen oder löschen. Den Speicher _einer anderen Person_ zu lesen steht allein der Deployment-Administratorin zu - keiner Organisationsrolle - und wird mit Akteurin, Tenant, Person und Begründung auditiert, nie mit Inhalt | [Lesen und löschen](reference/capabilities.md#reading-it-and-erasing-it); `test_memory_self_service.py`. Alles andere, was über sie gehalten wird, kommt aus `GET /me/data/export` zurück, begrenzt und auditiert (#1421) |
| Unternehmensidentität | Google-Anmeldung, Passwörter, generisches OIDC gegen den Provider, den Sie ohnehin betreiben - allein per Discovery aus `OIDC_ISSUER` konfiguriert - und Ihr eigenes Verzeichnis über LDAP oder Kerberos. Adresse, Anzeigename und stabile Kennung aus dem Verzeichnis werden am Konto gehalten; seine Gruppen werden bei jeder Anmeldung gelesen und nicht gespeichert, nur die Mitgliedschaften, die die Zuordnungen der Organisationen daraus machen. Kein SAML, kein SCIM | [Verzeichnisanmeldung und Gruppen](directory.md); `OIDC_ISSUER`, `LDAP_URL` |
| Die Kontrollmatrix, die eine Sicherheitsprüfung liest | [Sicherheit](security.md#controls-matrix) ordnet jeder Kontrolle ihren Mechanismus und den Test zu, der ihn hält, im Rahmen von HIPAA §164.312 und SOC 2 CC6–CC8; diese Seite und [Einführen](rollout.md#what-your-security-review-will-ask) sind der Rest | [Sicherheit](security.md) (#1412) |
| Öffentliche Oberflächen | Der Besucherschlüssel einer gehosteten Seite ist zufällig, nie aus der Person abgeleitet; Einlass und Uploads sind je Adresse ratenbegrenzt, die Adresse liegt für die Dauer des Fensters in einem Redis-Schlüssel und sonst nirgends | [Kanäle](channels.md#a-hosted-page) |
| Rechtliche Hinweise | Die eigenen AGB- und Datenschutz-URLs des Deployments ersetzen die eingebauten Seiten | [Das Deployment](deployment.md#identity) |
### Traces { #traces }
`instrument_pydantic_ai()` läuft mit dem Standard der Bibliothek, ein Span hält
also die Nachricht des Benutzers, die Antwort des Models und jedes Tool-Argument
und -Ergebnis. Mit ungesetztem `LOGFIRE_TOKEN`, ohne `observability`-Token auf
irgendeinem Spec und ohne `logfire_token_secret_id` auf irgendeinem Environment
wird nichts gesendet, und die Trace-Id wird trotzdem lokal festgehalten. Ein
Deployment, das Traces ohne den Inhalt braucht, setzt `observability.content` des
Agents auf `none`: aufgezeichnet werden Zeit, Tokens, Kosten und Tool-Namen, und
kein Nachrichtentext verlässt die Maschine — und ein Spezialist dieses Agenten
erbt den Modus, ob sein Autor ihn inline geschrieben oder das Model des Runs ihn
erfunden hat.
Einen dritten Modus dazwischen gibt es nicht. Ein durch einen PII-Filter
bereinigter Export ist eine Zusicherung, die niemand prüfen kann — ein
Identifikator, den der Filter übersieht, ist bereits draußen, und der Betreiber
glaubt das Gegenteil —, die Wahl steht also bewusst zwischen dem ganzen Inhalt
und keinem ([#1616](https://github.com/vstorm-co/agenticos/issues/1616)).
### Was das Löschen erreicht { #what-deletion-reaches }
Löschen ist das, was das Produkt heute tut, wenn jemand darum bittet; geplante
Aufbewahrung ist [#1420](https://github.com/vstorm-co/agenticos/issues/1420).
| Aktion | Entfernt | Lässt zurück |
| --- | --- | --- |
| `DELETE /conversations/{id}` (der Besitzer) | Die Conversation, ihre Nachrichten, Tool-Aufrufe, Bewertungen, Freigaben, `chat_files`-Zeilen und die darin gemachten Wissenssuchen per Kaskade - darunter das Transkript eines Sprachanrufs, da seine Züge Nachrichten sind; die Anhang-Bytes unter `MEDIA_DIR`, vor dem Löschen eingesammelt und nach dessen Commit gelöst; die aus diesem Thread ausgelagerten Medienobjekte per Präfix; ein Container-Workspace über `purge_for_conversation`; die daraus generierten Dataset-Entwürfe, die noch auf eine Entscheidung warten In diesen Gesprächen erzeugte Bilder, Sprache und Videos werden mit ihren Zeilen gelöscht; ein in derselben Transaktion eingereihter Job entfernt ihre Dateien. | Run-Zeilen und Manifeste, die die Conversation benannten, behalten ihre Prompt-Kopie; eine `voice_calls`-Zeile behält ihre Zeiten und Kosten, mit geleerter Verknüpfung zur Conversation. Daraus kopierte Dataset-Fälle behalten ihren Text, jede Verbindung zur Conversation, ihrem Run und ihren Nachrichten wird gelöscht - der Text kann weiterhin personenbezogene Daten enthalten, die jemand geschrieben hat, und verschwindet, wenn diese Person gelöscht wird. Bereits aus diesen Fällen erzeugte Eval-Ergebnisse behalten die aufgezeichneten Antworten und Aufrufe. Daraus abgezweigte Conversations behalten ihre kopierten Nachrichten und Tool-Aufrufe, mit geleerter Verknüpfung, und erzeugte Bilder laden darin nicht mehr; die Aufbewahrungsfrist einer Abzweigung läuft ab ihrer Erstellung |
| `DELETE /projects/{id}` (`projects:edit`) | Den Container des Projekts und jede Datei darin; die Chats, deren Starter sein Konto gelöscht hat und die nur noch das Projekt erreichte, mit allem, was das Löschen einer Conversation entfernt; die aus diesen Chats generierten Dataset-Entwürfe, die noch auf eine Entscheidung warten | Seine übrigen Chats, als gewöhnliche Chats außerhalb eines Projekts behalten. Dataset-Fälle, die aus einem entfernten Chat kopiert wurden, behalten ihren Text, ohne jede Verbindung zum Chat, seinem Run und seinen Nachrichten |
| `DELETE /memory/person/{user_id}` (die Person oder `members:manage`) | Jede `agent_memory_files`-Zeile, die auf die Person geschlüsselt ist, über alle Agents der Organisation hinweg, jeden festgehaltenen Claim im Bereich der Person und die daraus weitergegebenen Kopien | Notizen, die auf einen Gruppenchat geschlüsselt sind, in dem die Person gesprochen hat |
| `DELETE /users/{id}` | Das Konto, seine Sessions, seine persönliche Organisation und persönliche Collections samt Vektortabellen und Dateien per ausdrücklichem Teardown; Conversations außerhalb eines Projekts und Chat-Dateien per Kaskade; deren Bytes, nach dem Commit gelöst; und was keine Kaskade erreicht - die Notizen, die Agents über die Person geschrieben haben (`owner_key` ist ein String, kein Fremdschlüssel), ihre Plattform-Identitäten, ihre nutzergebundenen Workspaces, die Wissenssuchen jedes Runs, den sie gestartet hat, auch in einem Projekt-Chat, die Kopie einer Antwort, die ein Eval-Score aus einem ihrer Runs aufbewahrt hat, die aus ihren eingegebenen Fragen, ihren Gesprächen oder Runs generierten Dataset-Entwürfe, die noch auf eine Entscheidung warten; der Text der Dataset-Fälle, deren Frage sie gestellt hat, in jeder Version, auch nachdem die Conversation gelöscht ist, mit den Antworten und Aufrufen, die Eval-Runs für diese Fälle aufgezeichnet haben, den Nachrichten in den Manifesten der Runs des Agents und des Bewerters, die sie beantwortet haben, und den Argumenten der Aufrufe, die diese Runs zurückgehalten haben; ihre Züge im früheren Verlauf der Fälle anderer Personen, mit den Antworten des Agents darauf; ihre als Notiz eines Falls aufbewahrten Kommentare; die Zitate des Authoring-Assistenten von ihr; und die Entwürfe der Wissenslücken-Themen, die ihre Suchen enthalten In diesen Gesprächen erzeugte Bilder, Sprache und Videos werden mit ihren Zeilen gelöscht; ein in derselben Transaktion eingereihter Job entfernt ihre Dateien. | Audit-Einträge, die die Actor-Id und bei manchen Aktionen die E-Mail nennen - bewusst aufbewahrt, denn ein Eintrag ohne seinen Actor ist schlimmer als einer, der ein gelöschtes Konto nennt. Nachrichten in Conversations, die jemand anderem gehören, und die Projekt-Chats, die die Person begonnen hat - für das Team behalten, ohne Urheber; ihre Nachrichten darin erscheinen als die eines ehemaligen Mitglieds. Dataset-Fälle, die aus ihren Conversations oder Runs kopiert wurden - mit der Markierung **Nach Löschung anonymisiert** und ohne jede Verbindung zu ihr behalten, damit ihr Kurator sie umschreiben oder entfernen kann; bis dahin lässt ein Eval-Run sie aus. Ein Fall, der geschrieben wurde, bevor Fälle festhielten, wer gefragt hat, und dessen Conversation schon davor gelöscht wurde, behält seinen Text. Ein Fall aus dem Run einer anderen Person, den sie nur bewertet hat, behält Frage und Antwort Erzeugte Medien ohne Gespräch sind keiner Person zugeordnet und verfallen nach sieben Tagen. |
| Ein Dokument oder eine Collection löschen | Die Zeilen, die Vektortabelle (oder nur die Chunks der Collection, solange eine andere Collection oder Chunks, die keiner Collection gehören, die Tabelle halten) und die gespeicherte Datei, über einen dauerhaften Flow nach dem Commit; die Parse-Kopie unter `_rag_tmp`, wenn das Dokument gelöscht wird oder sein Ingest-Job das nächste Mal läuft, sonst durch den stündlichen Sweep, sobald die Kopie eine Stunde alt ist - binnen etwa zwei Stunden nach dem Upload. Eine Kopie bleibt, solange ihr Dokument noch verarbeitet wird | Nichts, sobald der Flow gelaufen ist, außer Alt-Chunks ohne vermerkte Collection, die bis zum Löschen der Tabelle bleiben können, solange eine andere Collection oder Inhalt eines Operators sie hält; die Zählstände in `sync_logs` bleiben |
| Eine Organisation löschen | Alles, was auf sie gescoped ist, mit demselben aufgeschobenen Abbau - ihre erzeugten Medien per Präfix, einschließlich der Dateien, die geschrieben wurden, bevor sie erfasst wurden | Persönliche Collections, die die Id lediglich mitführten |
Kanalnachrichten speichern nur den Text des Absenders. Autorenbezeichnungen werden unmittelbar vor der Modellanfrage aus Kanalidentitäten aufgelöst, außerhalb der Systemanweisungen. Konsole, Kopieren, Anheften und Kurzbefehle erhalten den reinen Text. Gespeicherte Verläufe und pausierte Runs behalten opake Identitätsreferenzen; Manifeste lassen die eingefügten Kanalreferenzteile aus. Die Kontolöschung entfernt dessen Kanalidentitäten, sodass spätere Anfragen die Plattformbezeichnungen der Person nicht mehr auflösen können. Geteilte Nachrichtentexte bleiben erhalten.
Keines davon erreicht ein Backup. Eine Wiederherstellung bringt zurück, was
gelöscht wurde, der Backup-Ablauf gehört also zur Aufbewahrungsrichtlinie und
wird mit ihr zusammen niedergeschrieben.
## Was ein Deployment entscheiden und beschaffen muss { #what-a-deployment-has-to-decide-and-obtain }
Die Software kann nichts davon liefern. Jedes ist ein Nachweis, den die Prüfung
verlangen wird, und etwas anderes als die technische Fähigkeit, die ihn möglich
macht.
- **Ein Auftragsverarbeitungsvertrag mit jedem konfigurierten
Unterauftragsverarbeiter** — jedem Provider, den eine Zeile in
`model_profiles` oder `organization_secrets` benennt, dem Embedding-Provider,
LlamaCloud, falls eine Collection es nutzt, dem Suchanbieter, den die `method`
eines Agents benennt, Logfire, dem SMTP-Relay und Google, falls
die Anmeldung aktiviert ist.
- **Eine Erklärung zum Datenstandort je Provider**, abgeglichen mit der
`base_url`, die jedes Profil tatsächlich nutzt. Ein Provider mit EU-Endpunkt
ist nur dann in der EU, wenn das Profil es sagt.
- **Ein Trainingsausschluss je Provider**: die Kontoeinstellung oder
Vertragsklausel, unter der API-Daten nicht zum Training verwendet werden. Die
eigene Position der Plattform ist ein Satz — sie trainiert nichts — und der
Rest ist deren Sache.
- **Ein Auftragsverarbeitungsvertrag mit Vstorm**, nur wenn Vstorm das
Deployment betreibt.
- **Ein Aufbewahrungsplan** für Conversations, Dateien, Memory, Dokumente, Runs
und Audit, und daneben der Backup-Ablauf. Bis
[#1420](https://github.com/vstorm-co/agenticos/issues/1420) einen erzwingt,
ist Aufbewahrung manuelles Löschen.
- **Platten- oder Volume-Verschlüsselung** auf dem Datenbank-Host, dem
Media-Volume und dem Sandbox-Host, da die Anwendung Inhalte nicht selbst
verschlüsselt — und eine Egress-Regel auf dem Sandbox-Host, wenn Agents
Kommandos ausführen dürfen.
- **Die Rechtsseiten**, auf die das Deployment verlinkt, und wer eine Auskunfts-
oder Löschanfrage beantwortet. Die Mechanismen stehen hier - `GET
/me/data/export` und die Kontolöschung - aber wer die Anfrage entgegennimmt und
in welcher Frist, ist Sache des Verantwortlichen.
## Ein Deployment prüfen { #verifying-one-deployment }
Wiederholbare Prüfungen, vom Host aus, gegen das laufende Deployment. Jede gibt
Fakten aus, die die Prüfung anhängen kann; keine gibt ein Zugangsdatum oder die
Daten einer Person aus. Führe sie aus `backend/` aus, oder über
`docker compose exec api`.
```bash
# 1. Läuft es überhaupt, und sind die Verbindungen zu den Speichern
# verschlüsselt? `postgres` meldet den TLS-Zustand der Verbindung, die der
# Doctor selbst aufgebaut hat.
uv run agenticos cmd doctor
# 2. Jedes versiegelte Zugangsdatum öffnet sich weiterhin unter den
# konfigurierten Master Keys.
uv run agenticos cmd vault-rotate --dry-run
# 3. Die Hash-Ketten der Audit-Spur und ihre Checkpoints, neu berechnet. Endet
# mit einem Exit-Code ungleich null, wenn eine Kette verändert wurde.
uv run agenticos cmd audit-verify
# 4. Alles, was dieses Deployment tatsächlich konfiguriert hat: die
# Einstellungen, die entscheiden, was hinausgeht, jeden Provider und
# Endpunkt, den ein Agent erreichen kann, die gehaltenen Zugangsdaten nach
# Zweck, die Collections und wer sie einbettet, die Server im eigenen Netz,
# die MCP-Server, Trigger-Portale, Sync-Quellen und Channel-Bots, die
# Capabilities, die eine eigene Adresse erreichen, wohin Runs getraced werden
# und wie viel Inhalt ein Span trägt, wie viel jedes Speichers eine
# Aufbewahrungsfrist erfassen würde, und die Dateien unter `MEDIA_DIR`, auf
# die keine Zeile mehr zeigt.
uv run agenticos cmd data-protection-report --older-than 365
```
Punkt 4 ist der, den man anhängt. Er gibt Konfiguration und Zählungen aus und
niemals Inhalt: keinen Nachrichtentext, kein Dokument, keinen Secret-Wert und
keinen Hinweis darauf, und eine Einstellung, die ein Zugangsdatum hält, wird als
gesetzt oder ungesetzt gemeldet statt ausgegeben. `--older-than` ist die
betrachtete Aufbewahrungsfrist in Tagen, und die letzte Spalte seiner
Aufbewahrungstabelle ist das, was diese Frist bereits entfernt hätte.
Sein letzter Abschnitt zählt die Bytes, die keine Zeile mehr benennt. Das Löschen
einer Konversation oder eines Kontos löst deren Anhänge jetzt nach dem Commit, so
dass dieser Weg nichts mehr hinzufügt; was er noch findet, stammt aus der Zeit vor
diesen Löschungen oder aus einem Lösen, das ein Best-Effort-Sweep nicht zu Ende
gebracht hat.
Das Parse-Arbeitsverzeichnis ist ausgenommen - es hat von
vornherein keine Zeile; der stündliche Job `sweep-rag-scratch` entfernt eine
Kopie, deren Dokument fehlt oder nicht mehr verarbeitet wird.
Erzeugte Medien werden gezählt, seit `generated_media`
jede Datei festhält, daher ist, was unter einem Verzeichnis `generated_<org>`
erscheint, meist eine Datei, die vor dieser Tabelle erzeugt wurde und nur mit
ihrer Organisation geht. Es kann auch eine Datei sein, deren Lösen nach dem
Löschen ihrer Zeile fehlschlug, oder eine, die noch gespeichert wird, bevor ihre
Zeile geschrieben ist. Alles andere, was dort gezählt wird, sind Bytes, die das
Produkt nicht mehr findet und nicht löschen kann. Er meldet ein Verzeichnis und eine Zahl statt eines Dateinamens, denn ein
gespeicherter Pfad behält den Namen, unter dem die Datei hochgeladen wurde.
Zwei Abschnitte werden aus dem gelesen, was läuft, und nicht aus einer Tabelle.
**Capability-Ziele** listet die an einen Agenten gebundenen Capabilities auf, die
eine eigene Adresse erreichen - `web_research` sucht ohne jedes Zugangsdatum über
DuckDuckGo und damit ohne Zeile irgendwo sonst im Bericht - und **Tracing** wird
aus jeder lauffähigen Version gelesen: der Standardversion und der, die jede
benannte [Umgebung](environments.md) anheftet, denn ein Run über diese Umgebung
nutzt die Observability jener Version und nicht die der Standardversion.
Was kein Befehl erzeugen kann, ist die andere Hälfte dieser Seite: die
Vereinbarungen, Standorte und Trainingsausschlüsse des vorherigen Abschnitts.
Hänge sie neben die Ausgabe.
## Offene Bedingungen für eine erste Einführung { #open-conditions-for-a-first-rollout }
Festgehalten für das Deployment, für das diese Seite geschrieben wurde, und wahr
für jedes Deployment, bis jede von ihnen geschlossen ist.
**Im Code, und bleibend:**
- Traces tragen vollen Inhalt, sofern ein Agent `observability.content` nicht auf
`none` setzt. Ein gefiltertes Dazwischen gibt es nicht und wird es nicht geben:
ein teilweise bereinigter Export ist eine Zusage, die niemand prüfen kann
([#1616](https://github.com/vstorm-co/agenticos/issues/1616)).
- **Inhalte im Ruhezustand gehören dem Betreiber.** Nachrichtentexte, Dokumente
und ihre Vektoren sowie Sandbox-Workspaces sind gewöhnliche Spalten und
Dateien; der Vault versiegelt Zugangsdaten, nicht Inhalte. Hochgeladene Dateien
können in einen S3-kompatiblen Store gehen, der sie serverseitig verschlüsselt,
aber Datenbank und Medien-Volume schützt die Platten- oder
Volume-Verschlüsselung - oder gar nichts.
**Geschlossen, und oben statt hier beantwortet:** der Manipulationsnachweis der
Audit-Spur (#1622, #1648), der Trace-Inhaltsmodus je Agent und sein Erben durch Spezialisten (#1413, #1699), das Tracing in dem Prozess, der einen
gefeuerten Agent ausführt (#1700), die
Kontrollmatrix für HIPAA und SOC 2 unter
[Sicherheit](security.md#controls-matrix) (#1412), Löschung und Export der Daten
einer Person (#1421), das S3-Backend mit serverseitiger Verschlüsselung (#1423)
und generisches OIDC-Sign-in (#1419). Traces haben kein gefiltertes
Dazwischen und bekommen keines
([#1616](https://github.com/vstorm-co/agenticos/issues/1616)); für ein
Deployment, das keinen Inhalt exportieren darf, ist `none` die Antwort.
**Im Deployment, von seinem Betreiber entschieden:** die Vereinbarungen,
Standorte, Trainingsausschlüsse, der Aufbewahrungsplan, die Backup-Frist, die
Plattenverschlüsselung, der Sandbox-Ausgangsverkehr und die Rechtsseiten des
vorherigen Abschnitts. Jedes davon ist der Nachweis, den
`data-protection-report` bewusst nicht erzeugt.
Eine Prüfung, die jede Zeile oben entweder geschlossen oder schriftlich
akzeptiert vorfindet, hat, was diese Seite ihr geben kann. Der Rest gehört dem
Deployment.
## Bereitstellungsdiagnose { #deployment-diagnostics }
Der Kollektor erhält Installationszustand, Nutzungsbereiche, gruppierte
Fehlerzähler (eine Komponente, ein geschlossener Fehlercode und eine Anzahl, nie
Ausnahmetext) und pseudonyme Vordergrundaktivität, die jeder angemeldete Browser
oder jede App direkt an ihn sendet. Berichte sind standardmäßig aktiviert, auch
nach Upgrades mit alter `.env`, und der Standard-Kollektor ist eine entfernte
Adresse, `https://analytics-agenticos.testapp.ovh`. Die
[Diagnosekonfiguration](configuration.md#diagnostics) beschreibt Felder,
Aufbewahrung, wie Sie ihn auf einen eigenen Kollektor richten und wie Sie ihn mit
`DIAGNOSTICS_ENABLED=false` abschalten.
## Daten der iMessage-Bridge { #imessage-bridge-data }
Der optionale iMessage-Kanal überträgt Nachrichtentext und ausdrücklich angehängte Dateien über den konfigurierten BlueBubbles-Mac der Organisation und Apple Nachrichten. Auf dem Mac und im Apple-Konto können weitere Kopien verbleiben. AgenticOS speichert verknüpfte Adressen, Kanalunterhaltungen, Durchläufe und Uploads gemäß den bestehenden Aufbewahrungs- und Löschregeln für Kanäle; eine Löschung hier entfernt keine Kopien auf dem Mac oder in Nachrichten. Private Benachrichtigungen benötigen ein ausdrücklich gewähltes Ziel; Gruppen übernehmen keinen privaten Profilspeicher.
Serverpasswort und separates Callback-Geheimnis liegen verschlüsselt im Tresor. Der HTTP-Client verbirgt das Passwort in sichtbaren Anfrageadressen; die Bridge erhält dennoch ihren erforderlichen Authentifizierungsparameter. Ihr Betreiber muss daher eigene Protokolle und Netzwerk schützen.