Der Stand der Dinge
Viele KI-Plattformen versprechen "DSGVO-Konformität". In den meisten Fällen heißt das: Die Server stehen in der EU, irgendwo gibt es eine Datenschutzerklärung, und im Footer prangt ein Logo, das Vertrauen erzeugen soll. Aus regulatorischer Sicht ist das nicht ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO. Das ist eine Marketing-Aussage.
Wenn euer Unternehmen einem KI-Anbieter personenbezogene Daten anvertraut — Mitarbeiter:innendaten, Lead-Informationen, Support-Tickets mit Klarnamen —, dann seid ihr Verantwortliche im Sinne der Verordnung und müsst sicherstellen, dass der Anbieter Auftragsverarbeiter ist und die in Art. 28 aufgelisteten Pflichten erfüllt. Punkt.
Wir haben ORCONIC vom ersten Tag so gebaut, dass die DSGVO operationalisiert ist und nicht nur dokumentiert. Hier zeigen wir, wie.
DPA als Klickstrecke, nicht als E-Mail-PDF
Der erste Berührungspunkt mit dem Datenschutz ist bei uns kein PDF-Anhang in der zweiten Onboarding-Mail. Stattdessen läuft jeder neue Workspace durch eine DPA-Klickstrecke:
- Anzeige des vollständigen Auftragsverarbeitungsvertrags mit Versionsnummer.
- Eingabe von Unternehmensdaten plus benannter Datenschutz-Verantwortliche.
- Auswahl der zulässigen Sub-Prozessoren mit Information zu Datenkategorien und Drittlandbezug.
- Explizite Annahme über eine Checkbox plus Bestätigung.
Das Ergebnis: ein signiertes PDF in unserem Vault plus ein DB-Eintrag in dpa_signatures, der den Zeitstempel, die IP, die Version, den Hash-Wert des Dokuments und den Hash-Wert der Signatur enthält. Anwaltskanzlei-tauglich.
CREATE TABLE dpa_signatures (
id uuid PRIMARY KEY,
workspace_id uuid NOT NULL REFERENCES workspaces(id),
signed_by uuid NOT NULL REFERENCES users(id),
signed_at timestamptz NOT NULL DEFAULT now(),
dpa_version text NOT NULL,
document_hash text NOT NULL,
signature_hash text NOT NULL,
ip_address inet NOT NULL,
user_agent text NOT NULL
);Wer den Vertrag aufkündigen will, klickt im Dashboard auf "Vertrag widerrufen" — der Vorgang löst einen geordneten Datenexport plus die im DPA vereinbarte Datenlöschung aus. Mehr dazu gleich.
Datenexport: 47 Tabellen, ein Klick
Art. 20 DSGVO gibt jeder betroffenen Person das Recht auf Datenübertragbarkeit. Was im Gesetz wie ein Klick aussieht, ist in der Realität ein verteiltes Join-Problem über Dutzende Tabellen. Wir haben dafür gdpr.export gebaut — eine Funktion, die für eine gegebene subject_id alle relevanten Datensätze in einer strukturierten ZIP mit JSON pro Tabelle und einer MANIFEST.md ausgibt.
Was im Manifest steht:
- Welche Tabellen abgefragt wurden, mit Zeilenanzahl.
- Welche Spalten als personenbezogen klassifiziert sind.
- Welche Sub-Prozessoren historisch mit diesen Daten gearbeitet haben.
- Der SHA-256-Hash des Exports.
Der Export wird in unserem Audit-Log mit IP, Auslöser und Hash protokolliert. Das macht den Vorgang revisionssicher: niemand kann später behaupten, der Export sei unvollständig oder verfälscht gewesen, ohne den Hash zu brechen.
Datenlöschung: keine Tombstones, sondern echte DELETE
gdpr.delete ist die schwerere Schwester von gdpr.export. Hier reicht es nicht, ein Flag zu setzen — die Spuren müssen aus der Produktionsdatenbank verschwinden. Wir haben dafür einen Topological-Sort-Walker gebaut, der alle 47 Tabellen in der korrekten Foreign-Key-Reihenfolge durchläuft.
Beispielsweise: bevor wir einen Workspace löschen, müssen alle Workflow-Runs, alle Audit-Einträge, alle Tool-Invocations, alle OAuth-Tokens, alle Webhook-Subscriptions und alle Memory-Vektoren gelöscht sein. Wir kennen die Reihenfolge nicht intuitiv — wir bauen sie aus der Drizzle-Schema-Definition.
const order = topoSort(schema.relations);
for (const table of order) {
await db.delete(table).where(eq(table.workspaceId, id));
}Was nicht gelöscht wird: die Audit-Hash-Kette (siehe nächster Abschnitt). Sie ist gesetzlich erforderliche Tamper-Evidence und wird mit Pseudonymen statt Klarnamen geführt.
Tamper-Evidence: SHA-256 als Beweis
Jeder auditrelevante Vorgang in ORCONIC wird in audit_log geschrieben. Was diese Tabelle besonders macht: jeder neue Eintrag enthält den Hash des vorherigen Eintrags. Das macht aus dem Audit-Log eine Hash-Kette mit Tamper-Evidence.
const previousHash = await getLatestHash(workspaceId);
const payload = JSON.stringify({ action, subject, timestamp, actor, previousHash });
const entryHash = sha256(payload);
await db.insert(audit_log).values({ ...payload, entryHash });Wer einen historischen Eintrag manipulieren will, müsste alle nachfolgenden Hashes neu berechnen. Wer das nicht kann, fliegt sofort auf, sobald ein Auditor stichprobenartig zwei Einträge prüft und die Hash-Kette validiert.
Wir veröffentlichen wöchentlich den Hash des jeweils letzten Eintrags pro Workspace per E-Mail an die Datenschutz-Verantwortlichen. Das macht aus der Hash-Kette eine externe Tamper-Evidence — der Wochenstand ist außerhalb unseres Systems vorhanden und kann nicht rückwirkend manipuliert werden.
Sub-Prozessoren als Vertragsangelegenheit
Wir nutzen OpenAI, Anthropic, AWS, Supabase, Stripe und ein paar weitere Anbieter. Jeder von ihnen ist als Sub-Prozessor im DPA aufgeführt. Wenn wir einen Sub-Prozessor wechseln oder hinzufügen, informieren wir alle Workspaces 30 Tage vorher per E-Mail und im Dashboard. Niemand wird mit einer stillen Änderung überrascht.
Im Dashboard zeigt das Trust Center unter /dashboard/trust für jeden Sub-Prozessor:
- Datenkategorien
- Verarbeitungszweck
- Sitzland und EU-Standardvertragsklauseln
- Letztes Audit-Datum
- Verfügbarkeit als API-Endpoint für JSON-Export
Was bleibt zu tun
Wir sind nicht fertig. Auf der Roadmap für H2/2026:
- Zero-Trust-Mandantentrennung auf DB-Ebene mit Row-Level-Security für 100 % der relevanten Tabellen — aktuell sind wir bei 94 %.
- Bring Your Own Key (BYOK) für AES-256-Datenverschlüsselung at rest, mit kundengehosteten KMS-Schlüsseln.
- EU AI Act-Compliance, sobald die delegierten Rechtsakte für High-Risk-Anwendungen veröffentlicht sind.
Compliance ist kein Endzustand, sondern ein Modus, in dem man baut. Wer das verinnerlicht, baut Software, die auch noch in fünf Jahren rechtssicher funktioniert.