# Technische und organisatorische Maßnahmen (TOMs)

Stand: 29.09.2026

Dieses Dokument beschreibt die technischen und organisatorischen Maßnahmen für Magedesk als Arbeitsgrundlage für die rechtliche Prüfung, insbesondere für Datenschutzdokumentation, AVV-Anlagen und sonstige DSGVO-Unterlagen. Es ersetzt keine rechtliche Prüfung.

## 1. Produkt- und Verarbeitungskontext

Magedesk ist ein SaaS-System zur zentralen Erfassung, Priorisierung und Bearbeitung eingehender Geschäftskommunikation. Das System verarbeitet derzeit insbesondere E-Mail-Postfächer und Google-Integrationen wie Gmail und Kalender; weitere Kanäle wie Social Media, Microsoft Teams oder ähnliche Kommunikationsquellen sind perspektivisch vorgesehen. Aus eingehenden Nachrichten werden priorisierte Aufgaben, Handlungsempfehlungen und Antwortentwürfe erstellt.

Die Software unterstützt Nutzer bei der Bearbeitung von Kommunikation, ersetzt diese aber nicht. Ausgehende Kommunikation und extern wirksame Aktionen erfolgen standardmäßig erst nach Freigabe durch einen berechtigten Nutzer ("Human Gate"). Interne Klassifizierung und Priorisierung erfolgen automatisch; eindeutig als Spam eingestufte Nachrichten können dabei automatisch archiviert werden.

Zusätzlich kann Magedesk bei als Unternehmenspostfach markierten E-Mail-Integrationen den Ordner für gesendete Nachrichten auswerten. Daraus werden wiederverwendbare Unternehmensregeln vorgeschlagen, die erst nach Entscheidung eines berechtigten Nutzers übernommen werden.

## 2. Verantwortlichkeiten und Rollen

Zu prüfen und durch den Anwalt zu konkretisieren:

- Anbieter/Betreiber: MageDesk, Karwendelweg 10, 86825 Bad Wörishofen

- Datenschutz Ansprechpartner: Marc Hennessen

- Rolle gegenüber Kunden: Auftragsverarbeiter im Sinne von Art. 28 DSGVO

- Rolle bei eigenen Nutzungs-, Vertrags- und Abrechnungsdaten: voraussichtlich Verantwortlicher

- Kundenrolle: Verantwortlicher für importierte Kommunikationsdaten, Nutzerkonten, Organisationsdaten und freigegebene Aktionen

## 3. Datenkategorien

Je nach Nutzung können insbesondere folgende Daten verarbeitet werden:

- Stammdaten von Kundenorganisationen, Nutzern und Teammitgliedern

- Login-, Session- und Berechtigungsdaten

- E-Mail- und Kommunikationsinhalte einschließlich Betreff, Absender, Empfänger, Zeitstempel, Textinhalt und Metadaten; eingehende Anhänge werden nur verarbeitet, wenn dies vom Nutzer im entsprechenden Postfach eingerichtet wurde

- von Nutzern hochgeladene Antwortanhänge; sie liegen in einem privaten Dateispeicher außerhalb des Webverzeichnisses und werden regulär zehn Tage nach dem Upload entfernt. Für bereits freigegebene, noch ausstehende Sendungen können abgelaufene Dateien bis zum Abschluss der Sendung vorübergehend erhalten bleiben

- Aufgaben, Priorisierungen, Status, Kommentare und Bearbeitungshistorie

- KI-generierte Zusammenfassungen, Antwortentwürfe, Empfehlungen und Begründungen

- aus gesendeten Unternehmensnachrichten abgeleitete Regelvorschläge einschließlich Begründung, Status, Entscheidungszeitpunkt und entscheidendem Nutzer

- Kalenderinformationen, sofern eine Kalenderintegration aktiviert ist, hier werden Titel, Beschreibung, Ort, Zeitangaben und Teilnehmeradressen sowie ggf. Wenn gewünscht Meetinglinks übergeben.

- Integrations- und OAuth-Daten, sofern externe Dienste verbunden werden

- Zahlungs-, Plan- und Abrechnungsdaten, sofern kostenpflichtige Pläne verwendet werden

- technische Protokolldaten, Sicherheitslogs, Fehlerlogs und Audit-relevante Ereignisse

Besondere Kategorien personenbezogener Daten im Sinne von Art. 9 DSGVO sind nicht Zweck der Anwendung. Sie können aber in Kommunikationsinhalten enthalten sein, wenn Kunden oder deren Kommunikationspartner solche Daten übermitteln.

## 4. Hosting und Infrastruktur

Der produktive Betrieb erfolgt derzeit auf einem Cloud-Server bei Hetzner. Die Anwendung ist containerisiert und verwendet getrennte Dienste für Frontend, Backend, Reverse Proxy, Datenbanken, Cache/Queue und Worker-Prozesse.

Aktueller technischer Kontext:

- Cloud-Hosting: Hetzner Cloud (Nürnberg)

- Cloud-Hosting: Hetzner Cloud StorageBox (Falkenstein)

- Einsatz einer Hetzner Cloud Firewall am Produktionsserver. Eingehend werden ausschließlich TCP-Verbindungen auf den Ports 80 (HTTP), 443 (HTTPS) und 22 (SSH) sowie ICMP für Netzwerkdiagnosen zugelassen. Sonstige eingehende Verbindungen über das öffentliche Netzwerk werden blockiert. Die SSH-Anmeldung erfolgt ausschließlich mittels SSH-Schlüsseln; die Passwortanmeldung ist deaktiviert.

- Reverse Proxy/TLS: Ein vorgeschalteter Caddy-Proxy terminiert öffentliches HTTPS; Nginx nimmt die interne HTTP-Weiterleitung entgegen und leitet je nach Pfad an Symfony/PHP-FPM oder das Frontend weiter

- Frontend: Next.js-Anwendung in separatem Repository/Container

- Backend: Symfony/PHP-Container mit Nginx/PHP-FPM

- Datenbanken: MariaDB und MongoDB

- Cache/Queue: Redis

- Automatisierung/Worker: separate Worker-Container für asynchrone Verarbeitung und OpenAI-Admin-Aufgaben

- Echtzeitaktualisierungen: Selbst gehosteter Mercure-Hub zur Übermittlung organisationsbezogener Status- und Änderungsereignisse an angemeldete Nutzer.

- Container Registry: GitHub Container Registry

- CI/CD: GitHub Actions

Der reguläre Webzugriff erfolgt über den vorgeschalteten Caddy-Proxy per HTTPS. Die Compose-Basiskonfiguration bindet Nginx zusätzlich an Host-Port 8080; dessen Erreichbarkeit von außen und Absicherung sind gesondert zu prüfen.

## 5. Zutrittskontrolle

Maßnahmen gegen unbefugten physischen Zugriff:

- Rechenzentrumsbetrieb durch den Hosting-Anbieter Hetzner

- physische Sicherheitsmaßnahmen des Rechenzentrums gemäß Anbieterangaben

- kein eigener physischer Serverbetrieb durch Magedesk

- administrative Zugriffe erfolgen remote über gesicherte Verbindungen

@todo Vom Anwalt bzw. Betreiber zu ergänzen:

- Verweis auf TOMs/ISO-Zertifizierungen des Hosting-Anbieters

- konkrete Hosting-Region und eingesetzte Rechenzentren

## 6. Zugangskontrolle

Maßnahmen gegen unbefugte Nutzung von Systemen:

- Der Anwendungszugriff erfolgt über passwortgeschützte Benutzerkonten.

- Das Frontend authentifiziert API-Anfragen mit einem JWT im Authorization-Header. Die API prüft diese Anfragen zustandslos. Ein rotierendes Refresh-Token ermöglicht die Erneuerung des JWT; serverseitig wird nur dessen Hash gespeichert, seine Gültigkeit beträgt 30 Tage. Das Frontend speichert JWT und Refresh-Token derzeit im localStorage des Browsers.

- Die Admin-API setzt zusätzlich die Rolle ROLE\_SUPER\_ADMIN, ein separates Admin-Passwort und einen TOTP-Code voraus. Nach der Entsperrung wird ein gesonderter, signierter Admin-Token verwendet, der zehn Minuten gültig ist und bei Bedienung der Adminoberfläche erneuert wird. Nach Ablauf ist eine erneute Admin-Authentifizierung erforderlich.

- Der ältere, serverseitig gerenderte Symfony-Adminbereich verwendet ein getrenntes Form-Login mit CSRF-Schutz. Für dessen Session-Cookies sind HttpOnly, Secure und SameSite=Lax konfiguriert; diese Cookie-Eigenschaften gelten nicht für die im Frontend gespeicherten API-Tokens.

- Ingest-Endpunkte werden zusätzlich über HMAC-Prüfungen abgesichert; Passwort-Reset-Prozesse verwenden zeitlich begrenzte Tokens.

- Administrative Server- und SSH-Zugriffe sind berechtigten technischen Administratoren vorbehalten.

- Produktive Geheimnisse werden nicht im Repository gespeichert, sondern über geschützte Konfiguration und Umgebungsvariablen bereitgestellt. Entwicklungs-, Test- und Produktionskonfiguration sind getrennt.

## 7. Zugriffskontrolle und Berechtigungskonzept

Maßnahmen zur Sicherstellung, dass Nutzer nur auf berechtigte Daten zugreifen:

- mandantenfähige Verarbeitung über Organisations-/Tenant-Zuordnung

- Nutzerzugriffe werden organisationsbezogen geprüft

- Rollen und Berechtigungen innerhalb einer Organisation, insbesondere Owner/Admin/Member, werden organisationsbezogen geprüft

- API-Endpunkte prüfen Authentifizierung und Autorisierung

- öffentliche IDs sollen als UUIDs verwendet werden

- administrative Funktionen sind vom normalen Nutzerbereich getrennt und im Adminbereich an ROLE\_SUPER\_ADMIN gebunden

- externe Integrationen werden organisations- bzw. nutzerbezogen gespeichert

## 8. Weitergabekontrolle und Transportverschlüsselung

Maßnahmen gegen unbefugte Kenntnisnahme bei Übertragung:

- Regulärer öffentlicher Webzugriff erfolgt über HTTPS/TLS am vorgeschalteten Caddy-Proxy; Anfragen an die Standard-HTTP-Adresse werden auf HTTPS umgeleitet

- Caddy terminiert TLS und leitet intern per HTTP an Nginx weiter; Nginx verteilt die Anfragen an die Containerdienste

- Kommunikation mit externen Diensten erfolgt über HTTPS, soweit vom Dienst unterstützt

- API-Zugriffe erfolgen über authentifizierte Requests

- Ingest-Webhooks werden über HMAC-Signaturen validiert

- Stripe-Webhooks werden über Stripe-Signaturheader und STRIPE\_WEBHOOK\_SECRET validiert

- Webhooks weiterer externer Anbieter sollen mit Signaturen oder vergleichbaren Prüfmechanismen validiert werden

- produktive Tokens und API-Schlüssel werden nicht im Klartext in Code-Repositories abgelegt; getrackte .env-Dateien dürfen nur Defaults, Platzhalter oder dedizierte Entwicklungs-/Testwerte enthalten

## 9. Eingabekontrolle und Nachvollziehbarkeit

Maßnahmen zur Nachvollziehbarkeit von Eingaben, Änderungen und Aktionen:

- Erstellung und Änderung zentraler Datensätze erfolgt über Backend-APIs

- Bearbeitungsstatus von Nachrichten/Aufgaben wird gespeichert

- ausgehende Aktionen erfolgen grundsätzlich erst nach Nutzerfreigabe

- AI-generierte Vorschläge werden als Vorschläge behandelt und nicht automatisch versendet

- Regelvorschläge aus gesendeten Unternehmensnachrichten werden mit Status gespeichert und erst nach Nutzerentscheidung übernommen oder verworfen

- wichtige Systemereignisse und Fehler werden protokolliert

- Zahlungs- und Planänderungen werden über definierte Backend-Services verarbeitet

## 10. Auftragskontrolle

Maßnahmen zur Verarbeitung nur entsprechend dokumentierter Weisungen:

- Kunden steuern Integrationen, Nutzerzugänge und Freigaben selbst

- das System führt ausgehende Kommunikation grundsätzlich nur nach Freigabe aus

- Datenverarbeitung erfolgt zweckgebunden zur Bereitstellung des Dienstes

- Einsatz von Unterauftragsverarbeitern wird dokumentiert

- Hetzner: Hosting/Server/Infrastruktur

- GitHub: Quellcode, CI/CD, Container Registry

- OpenAI: KI-Verarbeitung für Zusammenfassungen, Priorisierung, Antwortentwürfe, Regelvorschläge

- TypeSafe.ai: KI-Verarbeitung zur Einordnung als Spam sowie diverser anderer Kategorien

- Anthropic: KI-Verarbeitung für Zusammenfassungen, Priorisierung, Antwortentwürfe, Regelvorschläge

- Stripe: Zahlungsabwicklung, Abrechnung, Plan-/Payment-Daten

- Google: Gmail/Calendar OAuth und Datenzugriff, sofern vom Kunden verbunden

- Microsoft: Outlook OAuth und Datenzugriff, sofern vom Kunden verbunden

- IMAP/SMTP-Mailbox-Anbieter: soweit Kunden eigene Postfächer verbinden

- Resend: Systemmails

- Änderungen an wesentlichen Unterauftragsverarbeitern sollten Kunden gemäß AVV mitgeteilt werden

## 11. Verfügbarkeitskontrolle

Maßnahmen gegen zufällige Zerstörung oder Verlust:

- containerisierter Betrieb mit reproduzierbaren Images

- persistente Datenhaltung in Datenbankvolumes

- getrennte Dienste für Web, Worker, Datenbanken und Queue

- Healthchecks für MariaDB, MongoDB und Redis sind in der Compose-Konfiguration vorhanden

- Wiederanlauf zentraler Dienste und Worker erfolgt über Docker-Restart-Policies

- regelmäßiges Backup der produktiven Datenbanken

- Backup wird verschlüsselt in der Cloud gesichert

## 12. Trennungskontrolle

Maßnahmen zur getrennten Verarbeitung unterschiedlicher Zwecke und Mandanten:

- logische Mandantentrennung über Tenant-/Organisationskennungen

- Datenmodelle verwenden organisationsbezogene Zuordnungen

- öffentliche Identifikatoren werden als UUIDs verwendet

- produktive Konfiguration ist von Entwicklungs- und Testkonfiguration getrennt

- getrennte Umgebungsvariablen für verschiedene Umgebungen

- externe Integrationen werden je Organisation bzw. Nutzer zugeordnet

## 13. Pseudonymisierung, Verschlüsselung und Datenminimierung

Maßnahmen:

- Transportverschlüsselung über HTTPS/TLS

- Verwendung von UUIDs statt fortlaufender öffentlicher IDs

- Speicherung nur der für den Dienst erforderlichen Daten

- sensible Zugangsdaten und Tokens werden über Umgebungsvariablen, gesicherte Konfiguration oder anwendungsseitige Verschlüsselung bereitgestellt

- Organisations- und Tool-Zugangsdaten werden anwendungsseitig mit APP\_CREDENTIALS\_MASTER\_KEY, organisationsbezogener Schlüsselableitung und libsodium/XChaCha20-Poly1305 verschlüsselt

- interne Tool-Geheimnisse werden ebenfalls über eine aus dem Master-Key abgeleitete Anwendungsschlüsselung gespeichert

- AI-Verarbeitung soll nur mit für den jeweiligen Zweck erforderlichem Kontext erfolgen

Zu prüfen und ggf. umzusetzen:

- Verschlüsselung ruhender Daten auf Volume-/Datenbank-/Backup-Ebene

- produktive Bereitstellung und Rotation des APP\_CREDENTIALS\_MASTER\_KEY

- Lösch- und Anonymisierungskonzepte

- Reduktion von personenbezogenen Daten in Logs

- Maskierung von E-Mail-Inhalten in Fehlerberichten

## 14. KI-spezifische Schutzmaßnahmen

Magedesk verwendet KI-Funktionen zur Unterstützung der Nutzer, insbesondere zur Priorisierung, Zusammenfassung, Erstellung von Antwortentwürfen und Ableitung wiederverwendbarer Unternehmensregeln aus gesendeten Unternehmensnachrichten. Die KI soll keine eigenständigen rechtsgeschäftlichen oder kommunikativen Handlungen ohne Nutzerfreigabe ausführen.

Maßnahmen:

- Human-Gate-Prinzip: ausgehende Antworten und extern wirksame Aktionen standardmäßig nur nach Freigabe. Die Erstellung von Kalenderterminen wird ebebfalls nur nach Freigabe des Nutzers angestoßen.

- Interne Klassifizierung und Priorisierung erfolgen automatisch; eindeutig als Spam eingestufte Nachrichten können automatisch archiviert werden

- KI-Ausgaben werden als Vorschläge dargestellt

- Nutzer behalten Kontrolle über Versand, Snooze, Markierung als Aufgabe und sonstige Aktionen. Diese werden über eine API-Anbindung ausgelöst, nicht durch die KI.

- Priorisierungen sollen begründet bzw. transparent dargestellt werden

- Unternehmensregeln aus gesendeten Nachrichten werden nur als Vorschlag gespeichert; die Übernahme erfordert eine Nutzerentscheidung

- Prompts zur Regelableitung sollen Kundennamen, Personendaten, konkrete Termine, Einzelfallpreise und vertrauliche Details nicht in Regeln übernehmen

- System- und Prompt-Konfigurationen sind Teil der Anwendungskontrolle

- Kontext für KI-Anfragen soll zweckbezogen begrenzt werden

- KI-Aufrufe und Verbrauchsdaten werden technisch nachvollziehbar über Backend-Services verarbeitet

## 15. Löschung, Berichtigung und Export

Aktuelles Löschkonzept:

- Nutzerkonten können über die Account-API gelöscht werden. Die Löschung erfordert die Bestätigung der aktuellen Account-E-Mail-Adresse; bei aktivierter administrativer MFA ist zusätzlich ein gültiger TOTP-Code erforderlich.

- Bei Nutzerlöschung wird der Account technisch anonymisiert: Name, E-Mail-Adresse, Profilangaben, Reise-/Standortpräferenzen, Rollen, Passwort-Hash und administrative MFA-Daten werden entfernt oder durch technische Platzhalter ersetzt. Das Nutzerobjekt bleibt mit deletionRequestedAt und deletedAt als gelöschter Datensatz bestehen, damit referenzielle Integrität und technische Nachvollziehbarkeit erhalten bleiben.

- Zugehörige Refresh-Tokens, Teammitgliedschaften, Organisationsmitgliedschaften, vom Nutzer erstellte Einladungen und nutzerbezogene Integrations-Credential-Sets werden entfernt; Verweise wie used\_by oder approved\_by werden soweit möglich auf NULL gesetzt.

- Ist der gelöschte Nutzer der einzige Owner und einzige verbleibende Nutzer einer Organisation, wird die Organisation automatisch zur Löschung vorgemerkt.

- Organisationen können durch berechtigte Admins/Owner zur Löschung vorgemerkt werden. Für den expliziten Löschantrag muss der Organisationsname bestätigt werden; der ältere direkte DELETE-Endpunkt plant ebenfalls eine Löschung ein.

- Organisationslöschungen erfolgen zweistufig: Nach Ende des Vertrags wird ein Archiv mit allen Organisationsdaten erstellt und zum Download angeboten. Der Download ist durch die E-Mailadresse, die in gehashter Form hinterlegt ist und das letzte Organisationsadminpasswort geschützt. Sobald dieses Archiv erstellt ist wird die Organisation mit allen Daten final gelöscht. Die finale Löschung des Archivs ist nach 90 Tagen vorgesehen.

- Die Löschvormerkung wird auf operative Organisationsdaten übertragen, insbesondere importierte Inbox-Items/Aufgaben, Organisations-Credentials und Integrations-Credential-Sets. Diese Daten werden aus regulären Listen, Importläufen, Regelanalysen, Fokusübersichten und Tool-Abfragen ausgeschlossen.

- Eine vorgemerkte Organisationslöschung kann vor Ablauf der Frist durch berechtigte Nutzer storniert werden. Dabei werden die Löschmarker der Organisation und der markierten operativen Daten wieder entfernt.

- Nach Ablauf der Frist löscht der Konsolenjob app:organizations:finalize-deletions fällige Organisationen endgültig. Dabei werden insbesondere Aktionslogs, Inbox-Items, Organisations-Credentials, Integrations-Credential-Sets und die Organisation selbst entfernt.

- Vor der finalen Organisationslöschung werden abrechnungsrelevante Stripe-Rechnungsinformationen in eine separate Accounting-Retention-Tabelle übernommen, soweit sie abrufbar sind. Diese Aufbewahrung ist aktuell auf 10 Jahre ausgelegt und enthält Rechnungsschlüssel, Rechnungsnummer, Status, Beträge, Währung, Rechnungs-/Zahlungszeitpunkte, Rechnungsanschrift, Umsatzsteuer-ID und den ursprünglichen Organisationsbezug.

- Wenn der letzte Nutzer eine Organisation verlässt, wird die Organisation ebenfalls zur Löschung vorgemerkt. Verlässt ein alleiniger Owner eine Organisation mit weiteren Mitgliedern, muss ein Nachfolger bestimmt werden.

- Berichtigung von Account- und Organisationsstammdaten erfolgt über die jeweiligen Account- und Organisations-APIs.

Noch rechtlich/organisatorisch zu konkretisieren:

- dokumentierter Prozess für Betroffenenrechte und Kundenanfragen im Rahmen des AVV

- Datenexport personenbezogener Daten und mandantenbezogener Kommunikationsdaten

- gesonderte Löschfristen für technische Logs, Sicherheitslogs, Fehlerlogs, KI-Konversationen, Enrichment-/Decision-Traces, Kommunikationsspeicher und sonstige nicht direkt an die Organisationslöschung angebundene Sekundärdaten

- Löschung bzw. Ablehnung offener Regelvorschläge und Umgang mit bereits akzeptierten Unternehmensregeln außerhalb der Organisationslöschung

- Löschung oder Rotation einzelner Integrations-Tokens ohne komplette Organisationslöschung

- Umgang mit Daten in Backups nach Löschanforderungen, insbesondere Wiederherstellungsfälle und maximale Backup-Retention

## 16. Sicherheitsorganisation

Organisatorische Maßnahmen:

- Zugriff auf Produktionssysteme nur für berechtigte technische Personen

- Änderungen am Code erfolgen über Versionsverwaltung

- Deployments erfolgen über definierte Build- und Deployment-Prozesse

- Secrets dürfen nicht in Git-Repositories committed werden

- Sicherheitsrelevante Änderungen sollen geprüft und dokumentiert werden

- Abhängigkeiten werden über Paketmanager verwaltet

- Meldeprozess bei Datenschutzverletzungen nach Art. 33/34 DSGVO

- Datenschutzvorfälle werden intern unverzüglich an die verantwortliche Anlaufstelle gemeldet, bewertet und dokumentiert.

- Bei Vorfällen in der Rolle als Auftragsverarbeiter informiert Magedesk den betroffenen Kunden unverzüglich.

- Bei eigener Verantwortlichkeit wird geprüft, ob eine Meldung an die zuständige Aufsichtsbehörde nach Art. 33 DSGVO erforderlich ist; diese erfolgt möglichst binnen 72 Stunden nach Bekanntwerden.

- Bei voraussichtlich hohem Risiko für betroffene Personen wird zusätzlich eine Benachrichtigung nach Art. 34 DSGVO geprüft und umgesetzt.

- Maßnahmen zur Eindämmung, Ursachenanalyse und Nachbereitung werden dokumentiert.

## 17. Entwicklung, Testing und Deployment

Maßnahmen:

- Quellcodeverwaltung über Git

- Build von Container-Images über definierte Dockerfiles

- Trennung von Backend und Frontend

- produktive Konfiguration über separate Compose-Dateien und Umgebungsvariablen

- keine produktiven Geheimnisse in lokalen Entwicklungsdateien

- verpflichtende CI-Checks vor Deployment

- statische Codeanalyse und Linting

- Dependency-Scanning

- Container-Image-Scanning

- Zugriffsschutz für GitHub-Repositories und Container Registry

## 18. Logging und Monitoring

Maßnahmen:

- technische Logs für Container und Anwendung

- Fehlerlogs im Backend

- Protokollierung von Worker-Prozessen

- Protokollierung von Webhook-Verarbeitung und Integrationsfehlern, soweit erforderlich

- Protokollierung fehlgeschlagener Tool- und Sent-Mail-Regelanalysen erfolgt backendseitig

## 19. Datenschutz durch Technikgestaltung und Voreinstellungen

Maßnahmen:

- Human-Gate als datenschutz- und haftungsreduzierende Voreinstellung

- Nutzerfreigabe vor ausgehender Kommunikation

- rollen- und organisationsbezogene Zugriffskontrolle

- zweckgebundene Verarbeitung eingehender Nachrichten

- zentrale Sichtbarkeit von Status und Bearbeitung

- standardmäßig keine automatische Ersetzung menschlicher Entscheidung

- datenschutzfreundliche Default-Einstellungen für neue Organisationen

- minimale Datenfreigabe bei Integrationen

- granulare Aktivierung von Datenquellen

- Informationspflichten gegenüber Nutzern und Kommunikationspartnern