Anlage B. Technische und organisatorische Maßnahmen (Art. 32 der Verordnung (EU) 2016/679)
Version 1.0, veröffentlicht am 21. September 2026, gültig ab 21. Oktober 2026.
SHA-256-Prüfsumme: ec8fed8a111b88dbb42eb1a4665cade05571e7040c5c8abcd4e747b72efa73c1
Kanonischen Text herunterladen (.md)Dies ist eine unverbindliche Übersetzung. Bei Abweichungen ist die italienische Fassung maßgeblich (Art. 14.6 der Bedingungen).
| Eintrag | Inhalt |
|---|---|
| Titel | Anlage B, Technische und organisatorische Maßnahmen |
| Version | 1.0 |
| Text der vorliegenden Anlage | https://evolus.ai/de/sicherheitsmassnahmen |
| Anlage zu | Allgemeine Nutzungsbedingungen für Evolus und Employee AI („Bedingungen“), Version 2.0, veröffentlicht unter der Adresse https://evolus.ai/de/nutzungsbedingungen, und Anlage A, Version 1.0, veröffentlicht unter der Adresse https://evolus.ai/de/auftragsverarbeitung |
| Erstellt von | CodeDesign S.r.l., Via Nino Pesce 38, 18018 Taggia (IM), USt-IdNr. IT01739830089 |
| Kontaktstelle | privacy@codedesign.it |
Vorbemerkung
Die vorliegende Anlage beschreibt die technischen und organisatorischen Maßnahmen, die CodeDesign S.r.l. (nachfolgend der „Anbieter“) im Sinne von Art. 32 der Verordnung (EU) 2016/679 trifft, um bei der im Auftrag des Kunden durchgeführten Verarbeitung personenbezogener Daten ein dem Risiko angemessenes Schutzniveau zu gewährleisten.
Die Maßnahmen sind nach Funktion und nach Wirkung beschrieben. Der Anbieter gibt keine Umsetzungsdetails, Bezeichnungen interner Systeme, Adressen, Komponenten oder Konfigurationsparameter an, deren Offenlegung die Wirksamkeit der Maßnahmen selbst verringern würde. Weitere Informationen werden dem Kunden nach den Modalitäten und in den Grenzen des Art. 4.8 der Anlage A zur Verfügung gestellt.
Die vorliegende Anlage beschreibt den Stand der Maßnahmen zum Tag der Fassung. Sie kann vom Anbieter aktualisiert werden, sofern das Gesamtniveau der Sicherheit nicht verringert wird, nach Art. 12.5 der Bedingungen und nach dem nachstehenden Abschnitt 15.
1. Organisation der Sicherheit
1.1 Rollen. Der Anbieter hat die folgenden Verantwortlichkeiten förmlich zugewiesen:
- a) Verantwortlicher für die Informationssicherheit: Bewertung der Sicherheitsrisiken, Prüfung der Wirksamkeit der Maßnahmen, Vorschlag und Prüfung der Korrekturmaßnahmen.
- b) Ansprechperson für den Schutz personenbezogener Daten: Koordinierung des Bereichs des Datenschutzes, rechtliche Einordnung und Behandlung der Verletzungen, Führung des Verzeichnisses der Verletzungen, Kontakte zur Aufsichtsbehörde, Betreuung des Postfachs privacy@codedesign.it.
- c) Verantwortlicher für die Behandlung von Vorfällen: Übernahme der Meldungen, technische Eindämmung, Erhebung und Aufbewahrung der Nachweise, Rekonstruktion der Tragweite des Ereignisses, Koordinierung der Wiederherstellung.
- d) Geschäftsleitung: Entscheidung über die Meldungen an die Aufsichtsbehörde und über die Benachrichtigungen der betroffenen Personen, wenn der Anbieter als Verantwortlicher handelt, Freigabe der Ressourcen für die Korrekturmaßnahmen.
1.2 Datenschutzbeauftragter. Der Anbieter hat keinen Datenschutzbeauftragten im Sinne von Art. 37 der Verordnung benannt, nachdem geprüft wurde, dass dessen Voraussetzungen nicht vorliegen. Die Prüfung wird mindestens jährlich erneut vorgenommen. Kontaktstelle bleibt das Postfach privacy@codedesign.it.
1.3 Managementsystem. Der Anbieter hat mit der Einführung eines Informationssicherheits-Managementsystems nach der Norm ISO/IEC 27001:2022 begonnen, und der entsprechende Zertifizierungsprozess läuft. Zum Tag der vorliegenden Anlage ist die Zertifizierung nicht erlangt worden. Der Anbieter erklärt nicht, zertifiziert zu sein, und wird den Kunden die etwaige Erlangung mitteilen und dabei die vorliegende Anlage aktualisieren.
1.4 Überprüfung. Die in der vorliegenden Anlage beschriebenen Maßnahmen werden mindestens jährlich überprüft, nach jeder als mittleres oder hohes Risiko eingestuften Verletzung des Schutzes personenbezogener Daten und nach jeder wesentlichen Änderung der Architektur des Dienstes.
2. Zugangskontrolle und Authentifizierung
2.1 Zentralisierte Identität. Der Zugang zur Plattform erfolgt ausschließlich über ein zentralisiertes, von der Anwendung getrenntes System zur Verwaltung der Identitäten. Die Zugangsdaten der Nutzer werden von der Anwendung nicht aufbewahrt.
2.2 Verifizierung der E-Mail-Adresse. Die voreingestellte Autorisierungsrichtlinie aller Anwendungsschnittstellen verlangt zusätzlich zur Authentifizierung, dass die E-Mail-Adresse des Nutzers verifiziert ist. Fehlt diese Voraussetzung, wird der Zugang verweigert.
2.3 Zwei-Faktor-Authentifizierung. Es steht ein zweiter Authentifizierungsfaktor über einen an die E-Mail-Adresse des Nutzers gesendeten Einmalcode zur Verfügung, der im Identitätssystem konfigurierbar ist.
2.4 Validierung der Sitzungen. Die Zugangstoken werden eingehend validiert: Prüfung des Empfängers, Prüfung des Ausstellers anhand eines ausdrücklichen Verzeichnisses, Prüfung der Gültigkeitsdauer und des Ablaufs, Prüfung der Signatur mit Zurückweisung nicht signierter Token, begrenzte Toleranz bei den Uhren. Negative Ergebnisse werden mit dem Grund der Zurückweisung protokolliert, ohne jemals das Token zu protokollieren.
2.5 Anwendungs-Zugriffsschlüssel. Die dem Kunden für die automatisierte Nutzung des Dienstes ausgestellten Zugriffsschlüssel werden mit hoher Entropie erzeugt, im Ruhezustand ausschließlich in Form eines kryptografischen Hashwerts aufbewahrt und nur ein einziges Mal, im Zeitpunkt der Erstellung, im Klartext angezeigt. Ein Schlüssel ohne erklärte Berechtigungsbereiche ermöglicht auf keinem Kanal eine Authentifizierung. Jeder Schlüssel kann auf bestimmte digitale Mitarbeiter beschränkt werden. Status und Ablauf der Schlüssel werden bei jeder Verwendung geprüft.
2.6 Trennung der Privilegien der Schlüssel. Ein Anwendungsschlüssel kann in keinem Fall Privilegien der Plattform, des Systems oder der Organisation erlangen und unterliegt einem ausdrücklichen Verzeichnis stets verweigerter Vorgänge, darunter die Verwaltung des Abonnements, die Änderung der Credits und die Verwaltung der Kontingente. Trägt eine Anfrage sowohl die Identität eines Nutzers als auch einen Anwendungsschlüssel, so geht stets das Autorisierungsprofil des Nutzers vor.
2.7 Granulare Berechtigungen und Fail-closed-Verhalten. Die Autorisierung beruht auf atomaren Berechtigungen, die das System auflöst, nicht auf dem Abonnementtarif. Jede Schnittstelle erklärt ausdrücklich die erforderliche Berechtigung und verweigert den Zugang, wenn die Erklärung oder die Berechtigung fehlt. Kein anderes Profil als der Plattformadministrator kann Rollendefinitionen erstellen oder ändern und sich daher keine höheren Privilegien zuweisen, als es besitzt.
2.8 Zugriff im Auftrag eines Nutzers. Die Funktion, mit der das Personal des Anbieters im Auftrag eines Nutzers des Kunden handelt, ist nur den ausdrücklich dafür freigeschalteten Profilen gestattet, kann nicht allein durch die Erklärung des Anfordernden aktiviert werden, erfordert höhere Privilegien, um auf administrativen Profilen zu handeln, und wird zusammen mit den verweigerten Versuchen im Auditprotokoll aufgezeichnet.
2.9 Autorisierungen gegenüber den angebundenen Diensten. Die OAuth-Autorisierungen gegenüber den vom Kunden angebundenen Diensten werden mit dem Authorization-Code-Flow mit Proof Key for Code Exchange (PKCE) und mit signiertem, durch zeitkonstanten Vergleich geprüftem State-Parameter erlangt. Die Erneuerung der Token erfolgt in einem einzigen Ablauf mit verteilter Sperre.
2.10 Kurzlebige Token. Die Sitzungen der Echtzeit-Transkriptionsfunktionen und die Testsitzungen der Sprachagenten verwenden Token mit begrenzter Gültigkeitsdauer, bei den Testsitzungen zur einmaligen Verwendung, mit geprüfter Signatur. Fehlt der Signaturschlüssel, gilt kein Token als gültig.
2.11 Verwahrung der Token aufseiten des Clients. Das Portal des Kunden hält das Zugangstoken ausschließlich im Arbeitsspeicher, ohne es in den lokalen Speicher des Browsers zu schreiben. Die Anwendung für mobile Geräte bewahrt die Zugangsdaten im sicheren Speicher des Betriebssystems auf und wendet die koordinierte Abmeldung mit Löschung der Schlüssel an. Die sekundären Portale legen dem Browser kein Token offen und halten die Sitzung serverseitig in verschlüsselter Form.
3. Trennung der Daten zwischen Kunden
3.1 Perimeter. Die Trennungseinheit ist die Anwendungsumgebung des einzelnen Kunden. Jede Ressource, jede Anfrage, jede Zugangsberechtigung und jedes Protokoll ist dieser Umgebung zugeordnet, und die Zugehörigkeit des Nutzers zu der Umgebung wird bei jeder Anfrage geprüft.
3.2 Art der Maßnahme. Die Trennung wird durch ausdrückliche Anwendungskontrollen in den Diensten verwirklicht, ergänzt durch eine einheitliche Regel zur Zugriffsprüfung, die als gestaffelte Verteidigung angewandt wird. Der Anbieter erklärt transparent, dass es sich um Anwendungskontrollen handelt, die durch automatische Regressionstests abgesichert sind, und nicht um eine strukturelle Trennung auf der Ebene des Datenspeichers.
3.3 Automatische Tests. Die kontinuierliche Integration führt bei jeder Änderung Tests aus, die prüfen: dass jede Schnittstelle die erforderliche Berechtigung erklärt, mit einem ausdrücklichen und begründeten Verzeichnis allein der zugelassenen Ausnahmen; dass auf Ressourcen anderer Kunden nicht zugegriffen werden kann; dass die Beschränkungen der Privilegien der Anwendungsschlüssel eingehalten werden. Das Fehlschlagen dieser Tests verhindert die Integration der Änderung.
3.4 Logische Löschung. Die Hauptentitäten des Datenmodells unterliegen einer logischen Löschung mit globalem Filter, sodass ein gelöschter Datensatz von den gewöhnlichen Abfragen nie zurückgegeben wird.
3.5 Trennung der digitalen Mitarbeiter. Jeder digitale Mitarbeiter des Kunden wird in einem eigenen Container ausgeführt, mit eigenen Speichervolumen, mit schreibgeschützt eingebundener Wissensbasis und mit getrenntem Arbeitsbereich. Der lokale Speicher mit Konversationen, Gedächtnis und Transkriptionen liegt im Volumen des einzelnen Containers.
3.6 Interner Kanal der digitalen Mitarbeiter. Die Aufrufe vom Container zu den zentralen Diensten werden mit einer abgeleiteten Zugangsberechtigung authentifiziert, die durch zeitkonstanten Vergleich geprüft und an die Identität des digitalen Mitarbeiters gebunden ist, mit Kohärenzprüfung gegen das Orchestrierungssystem und mit Schutz gegen den Identitätstausch zwischen verschiedenen digitalen Mitarbeitern.
3.7 Trennung in der Observability. Jede Abfrage technischer Protokolle und Traces muss den Verweis auf die Umgebung des Kunden enthalten, ohne den sie zurückgewiesen wird, und die Zugehörigkeit des Nutzers zu dieser Umgebung wird geprüft. Bei nicht administrativen Profilen werden die technischen Felder, die Inhaltsfragmente enthalten könnten, aus den Ergebnissen entfernt.
3.8 Wiederverkäufer. Die einem Wiederverkäufer zugewiesenen Privilegien wirken nur auf die Ressourcen, die mit dem Wiederverkäufer durch eine ausdrückliche, im System erfasste Beziehung verbunden sind. Die Eigenschaft als Wiederverkäufer kann allein vom Plattformadministrator geändert werden, und die Änderung wird im Auditprotokoll aufgezeichnet.
4. Verschlüsselung
4.1 Verschlüsselung der Daten während der Übertragung
- a) Alle Kommunikationsvorgänge zwischen den Clients und der Plattform erfolgen über einen mit dem Protokoll TLS verschlüsselten Kanal, mit verpflichtender Umleitung des unverschlüsselten Verkehrs außerhalb der Entwicklungsumgebungen.
- b) Die Metadaten des Identitätssystems werden ausschließlich über einen verschlüsselten Kanal abgerufen.
- c) Die temporären Links, über die die Dateien bereitgestellt werden, werden schreibgeschützt und ausschließlich über einen verschlüsselten Kanal ausgestellt, mit einer Gültigkeit von höchstens einer Stunde.
- d) Die Verbindungen zu den vom Kunden konfigurierten Eingangs- und Ausgangs-Mailservern erfolgen über einen verschlüsselten Kanal, mit geschützter Aushandlung.
- e) Die von der Anwendung für mobile Geräte abgerufene Mail wird ausschließlich über einen verschlüsselten Kanal mit Prüfung des Serverzertifikats übertragen, ohne jede Abweichung: ein ungültiges Zertifikat führt zur Zurückweisung der Verbindung.
- f) Die Richtlinie für den Zugriff aus anderen Ursprüngen lässt die Übertragung von Sitzungsdaten nicht zu, sodass kein Cookie von einem fremden Ursprung gesendet werden kann.
4.2 Anwendungsseitige Verschlüsselung der ruhenden Daten
- a) Der Anbieter wendet eine anwendungsseitige Verschlüsselung mit dem Algorithmus AES mit 256 Bit im Modus GCM an, mit versioniertem Umschlag, zufälligem Initialisierungsvektor und Authentifizierungs-Tag. Ein Schlüssel nicht konformer Länge wird zur Verwendung zurückgewiesen, und eine fehlgeschlagene Entschlüsselung erzeugt einen Fehler, ohne jemals das Datum zurückzugeben.
- b) Mit dieser Verschlüsselung geschützt sind: die Zugangsdaten und die Zugriffsschlüssel zu den vom Kunden konfigurierten Diensten, die Zugangsdaten der Postfächer und der Arbeitsabläufe, die Signaturgeheimnisse der Kanäle und der Webhooks, die Zugangsdaten und die Token der vom Kunden aktivierten Konnektoren, die Verbindungszeichenfolgen zu den Dokumentenspeichern des Kunden sowie die Transkriptionen, die Teilnehmerlisten und die Ergebnisse der von der Anwendung für mobile Geräte verarbeiteten Besprechungen.
- c) Transparenzhinweis. Die anwendungsseitige Verschlüsselung nach Buchstabe b) erstreckt sich weder auf die Inhalte der Chat-Konversationen noch auf die in die Wissensbibliotheken hochgeladenen Dokumente, die durch die in den Abschnitten 2 und 3 beschriebenen Zugriffskontrollen und durch die Verschlüsselung der ruhenden Daten des zugrunde liegenden Speichers nach Absatz 4.3 geschützt sind.
4.3 Verschlüsselung der ruhenden Daten der Infrastruktur
Die Verschlüsselung der ruhenden Daten der Speichermedien wird von den Infrastrukturanbietern nach deren Dienstbedingungen bereitgestellt. Der Anbieter erklärt diese Maßnahme nicht als selbst geprüft und übernimmt sie nicht als eigene vertragliche Verpflichtung, bis die schriftliche Bestätigung des Cloud-Infrastrukturanbieters und des Anbieters des dedizierten Servers vorliegt.
4.4 Sicherungskopien
Die Sicherungskopien der digitalen Mitarbeiter werden an der Quelle verschlüsselt, vor der Übertragung an den entfernten Speicher: ohne den Verschlüsselungsschlüssel sind die Kopien nicht verwendbar.
5. Verwaltung der Geheimnisse
5.1 Zentralisierter Speicher. Die für die Erbringung des Dienstes erforderlichen Zugangsdaten und Geheimnisse werden in einem eigenen Speicher aufbewahrt, der nach getrennten Bereichen gegliedert ist, wobei der Wert im Zeitpunkt des Schreibens nach Absatz 4.2 verschlüsselt wird.
5.2 Hauptschlüssel. Der Hauptschlüssel der Verschlüsselung ist einzigartig, liegt weder im Quellcode noch in den versionierten Konfigurationsdateien und wird im Schlüsseltresor des Cloud-Infrastrukturanbieters verwahrt, von dem aus er der Anwendung als geschützte Einstellung bereitgestellt wird.
5.3 Auflösung im Zeitpunkt der Verwendung. Die Geheimnisse werden nur in dem Zeitpunkt aufgelöst, in dem sie benötigt werden, und mit Fail-closed-Verhalten: ein Verweis, der sich nicht auflöst, erzeugt einen Fehler und liefert nie einen leeren Wert. Die an die digitalen Mitarbeiter übermittelten Konfigurationen enthalten ausschließlich Verweise auf die Geheimnisse, nie die Werte.
5.4 Keine Rückgabe. Die Werte der Geheimnisse werden von den Programmierschnittstellen der Plattform nie zurückgegeben: der Ausschluss wird vom Serialisierer der Antworten von vornherein erzwungen und hängt nicht vom einzelnen Entwickler ab. Der dem Kunden zur Verfügung stehende Speicher der Geheimnisse ist nur beschreibbar: die eingegebenen Werte sind nicht mehr lesbar.
5.5 Protokolle. Die Werte der Geheimnisse werden in den technischen Protokollen unkenntlich gemacht, auch wenn sie im Zeitpunkt der Verwendung aufgelöst werden, und erscheinen nicht in den Startprotokollen der digitalen Mitarbeiter.
6. Protokollierung und Überwachung
6.1 Auditprotokoll der administrativen Vorgänge. Der Anbieter führt ein Protokoll der administrativen Vorgänge, das für jeden Vorgang Folgendes wiedergibt: Datum und Uhrzeit, tatsächlicher Urheber, etwaige Person, die im Auftrag eines Nutzers gehandelt hat, betroffene Umgebung und Organisation, Kategorie und Art der Aktion, betroffenes Objekt, Einzelheiten und Herkunftsadresse. Erfasst sind unter anderem die Vorgänge zu Rollen und Berechtigungen, Nutzern und Zugehörigkeiten, Credits und Kontingenten, Domains und Gruppen, Berechtigungen für die Ressourcen und Supportmeldungen sowie die Zugriffe im Auftrag eines Nutzers.
6.2 Zugriff auf das Protokoll. Die Einsicht in das Protokoll ist durch eine eigene Berechtigung geschützt. Die auf einen einzelnen Kunden bezogene Ansicht ist stets auf die Umgebung dieses Kunden gefiltert.
6.3 Aufbewahrung. Die Einträge des Auditprotokolls werden für 24 Monate aufbewahrt und anschließend automatisch gelöscht.
6.4 Transparenzhinweis. Das Auditprotokoll erfasst die administrativen Vorgänge und die Konfigurationsvorgänge. Der Anbieter erklärt weder ein unveränderliches Protokoll noch ein Protokoll der Zugriffe auf die Inhalte der Kunden.
6.5 Observability. Die Plattform erzeugt mit einem Observability-System Traces, Metriken und technische Protokolle, die mit dem Verweis auf die Umgebung des Kunden angereichert werden. Der Zugriff unterliegt den Kontrollen des Absatzes 3.7.
6.6 Von den Protokollen ausgeschlossene Inhalte. Die Regeln für das Schreiben des Codes verbieten die Protokollierung von Geheimnissen, Token und umfangreichen Inhalten der Nutzer und werden durch die Überprüfung der Änderungen abgesichert.
6.7 Betriebsalarme. Der Anbieter unterhält automatische Alarme zu den für die Kontinuität und für die Sicherheit maßgeblichen Ereignissen, darunter das negative Ergebnis der periodischen Wiederherstellungsprüfungen und der wiederholte Neustart der Dienste, mit Benachrichtigung an ein betreutes Postfach.
6.8 Öffentliche Statusseite. Der Anbieter veröffentlicht eine Statusseite des Dienstes, die von internen Sonden und von Sonden zu den vorgelagerten Anbietern gespeist wird, mit Benachrichtigungen per E-Mail, Abonnementkanal und internen Hinweisen. Aus Sicherheitsgründen legt die Seite weder den Namen noch die Anzahl der digitalen Mitarbeiter der Kunden offen.
7. Sicherungskopien und Kontinuität
7.1 Umgebung der digitalen Mitarbeiter
| Gegenstand | Häufigkeit | Aufbewahrung | Ablage |
|---|---|---|---|
| Lokaler Speicher jedes digitalen Mitarbeiters | Stündlich | 6 aktuelle Kopien | Lokales Medium des Produktionsservers |
| Arbeitsbereiche und Wissensbasen | Stündlich | 24 stündliche, 7 tägliche, 4 wöchentliche, 1 monatliche Kopie | Objektspeicher in der Europäischen Union, getrennt vom Produktionsserver, an der Quelle verschlüsselt |
| Speicher der Orchestrierung und der Verwaltung | Täglich | 3 lokale und 14 entfernte Kopien | Objektspeicher in der Europäischen Union |
| Abbild der Maschine | Täglich | 7 Snapshots | Dienst des Infrastrukturanbieters |
7.1.1 Versionen. Der Objektspeicher, der die Kopien beherbergt, hält die nicht aktuellen Versionen 30 Tage lang vor, zum Schutz vor versehentlichen Löschungen.
7.1.2 Automatische Prüfung. Eine alle 6 Stunden ausgeführte automatische Prüfung nimmt eine echte Wiederherstellung eines digitalen Mitarbeiters im Rotationsverfahren aus dem entfernten Speicher vor und vergleicht die kryptografischen Hashwerte der wiederhergestellten Daten. Ein negatives Ergebnis löst einen Alarm aus; in regelmäßigen Abständen wird gleichwohl eine Bestätigung der Funktionsfähigkeit der Prüfung selbst erzeugt.
7.1.3 Wiederherstellungstest. Der letzte echte Wiederherstellungstest, mit simuliertem Verlust der Volumen durchgeführt, wurde am 10. Juli 2026 bestanden, mit einer gemessenen Wiederherstellungszeit von etwa 15 Minuten, per kryptografischem Hashwert geprüfter Identität der wiederhergestellten Daten und beim ersten Versuch wieder aktiviertem Dienst.
7.1.4 Perimeter. Nicht in den Perimeter der Sicherungskopien fallen, aufgrund einer dokumentierten Entscheidung, die über den automatischen Teilnehmer erfassten Aufzeichnungen der Besprechungen, der Anwendungscode und die Caches der Arbeitsbereiche.
7.2 Umgebung der Cloud-Plattform
Die Sicherungskopien der Datenbank und des Dateispeichers der Cloud-Plattform sind diejenigen, die die verwalteten Dienste des Infrastrukturanbieters vorsehen. Der Anbieter erklärt zum Tag der vorliegenden Anlage für diese Umgebung keine Ziele für die Wiederherstellungszeit und für den höchstzulässigen Datenverlust: die Ziele werden erklärt und als Verpflichtung übernommen, sobald die entsprechende Konfiguration geprüft und dokumentiert ist.
8. Aufbewahrung und Löschung der Daten
8.1 Automatische Löschungen. Der Anbieter führt die folgenden automatischen Löschungen oder Anonymisierungen durch:
| Datenkategorie | Frist | Wirkung |
|---|---|---|
| Von den unterstützten Verarbeitungen erzeugte temporäre Dateien | 24 Stunden | Löschung der Dateien |
| Temporäre Arbeitsbereiche der Agenten | 24 Stunden ab dem letzten Schreibvorgang | Löschung |
| Ergebnisse und Audiodaten der von der Anwendung für mobile Geräte verarbeiteten Besprechungen | 7 Tage, verkürzt auf 6 Stunden ab der ersten Einsichtnahme | Löschung des Datensatzes und der Audiodaten |
| Von der Anwendung für mobile Geräte erstellte periodische Zusammenfassungen | 7 Tage, verkürzt auf 6 Stunden ab der ersten Einsichtnahme | Löschung; Entfernung der personenbezogenen Daten aus den nicht eingesehenen Verarbeitungen |
| Einzelheiten des Verbrauchs des Dienstes | 13 Monate | Anonymisierung: Entfernung der Kennung und des Namens des Endnutzers sowie des Verweises auf die Konversation |
| Auditprotokoll der administrativen Vorgänge | 24 Monate | Löschung |
| Benachrichtigungen im Portal | 90 Tage | Löschung |
| Nicht genutzte persönliche Autorisierungen für die Konnektoren | 90 Tage der Inaktivität | Ablauf der Autorisierung |
| Über den automatischen Teilnehmer erfasste Aufzeichnungen der Besprechungen | 30 Tage | Löschung beim Dienst |
| Technische Ausführungs-Traces der digitalen Mitarbeiter | 7 Tage, mit einer Obergrenze von 30 | Löschung, mit Ausnahme der noch offenen Tätigkeiten |
8.2 Sprachkonversationen. Die Aufbewahrung der Sprachkonversationen ist vom Kunden für jeden Agenten konfigurierbar. Ein nächtlicher Verarbeitungslauf wendet ein doppeltes Kriterium an, indem er sowohl die vom Sprachanbieter für die einzelne Konversation mitgeteilte Frist als auch die vom Kunden eingestellte Frist berücksichtigt, und wendet die zuerst ablaufende der beiden an. Die Löschung führt zur tatsächlichen Entfernung der Audiodatei aus dem Speicher und zur Leerung der Transkription, der Zusammenfassung, der Analyse, der Telefonnummer des Anrufers und des Verweises auf die Audiodatei, mit erneutem Versuch im Fehlerfall. Es verbleibt eine technische Restzeile ohne personenbezogene Daten, die allein zu dem Zweck aufbewahrt wird, Dubletten beim Import zu vermeiden und die erfolgte Kennzeichnung als künstliche Intelligenz nachzuweisen.
8.3 Modus ohne Aufbewahrung. Der Kunde kann einen Modus aktivieren, in dem die Sprachkonversation bereits im Zeitpunkt der Erfassung ohne Inhalt aufgezeichnet wird.
8.4 Löschung auf Handlung des Kunden. Die Löschung eines Dokuments führt zur Entfernung der Datei aus dem Speicher, zur Entfernung der entsprechenden Suchindizes und zur logischen Löschung des Datensatzes. Die Löschung einer Bibliothek führt zur Löschung der darin enthaltenen Dokumente. Die Löschung eines Nutzers führt zur logischen Löschung in der Plattform und zur tatsächlichen Löschung im Identitätssystem, mit Aufzeichnung im Auditprotokoll.
8.5 Transparenzhinweis. Für die Chat-Konversationen und für die Dokumente der Wissensbibliotheken ist keine automatische Löschfrist vorgesehen: sie werden für die Dauer des Vertrags aufbewahrt, sind auf Handlung des Kunden nach Absatz 8.4 löschbar und werden bei Vertragsende nach Art. 10 der Anlage A gelöscht.
8.6 Löschung bei Vertragsende. Es gilt vollumfänglich Art. 10 der Anlage A, der die Wahl zwischen Rückgabe und Löschung, die Fristen von 60 und 90 Tagen und die Sperrung des Zugangs im Zwischenzeitraum regelt.
9. Sichere Entwicklung
9.1 Geschützte Branches und Überprüfung. Die Hauptbranches des Codes nehmen Änderungen ausschließlich über eine Integrationsanfrage an, die einer Überprüfung unterzogen wird. Das unmittelbare Schreiben ist nicht zulässig.
9.2 Automatische Prüfungen. Bei jeder Integrationsanfrage führt die kontinuierliche Integration die Wiederherstellung der Abhängigkeiten, die Kompilierung in der Freigabekonfiguration und die Ausführung der Testsuite durch, mit minimalen Privilegien für den Ausführenden. Eine eigene Prüfung verhindert die Integration von Änderungen ohne Dokumentation der Auswirkungen für den Nutzer.
9.3 Freigabe ohne statische Zugangsdaten. Die Freigabe in die Produktion erfolgt über eine föderierte Identität gegenüber dem Infrastrukturanbieter, ohne im System der kontinuierlichen Integration gespeicherte statische Zugangsdaten. Die neue Version wird in einer Testumgebung veröffentlicht und erst nach der Prüfung in die Produktion überführt, mit der Möglichkeit der sofortigen Rückkehr zur vorherigen Version.
9.4 Durch automatische Werkzeuge abgesicherte Codierungsregeln. Der Anbieter verwendet eigene Werkzeuge zur statischen Analyse, die die generische Ausnahmebehandlung in den Diensten untersagen, die stillschweigende Unterdrückung von Fehlern untersagen und die Absicherung riskanter Aufrufe vorschreiben. Die manuelle Erstellung der Fehlerantworten wird bereits bei der Kompilierung verhindert.
9.5 Sicherheitstests gegen Regressionen. Die Suite umfasst eigene Tests zu: Abdeckung der Berechtigungsprüfung auf jeder Schnittstelle, Unmöglichkeit des Zugriffs auf Ressourcen anderer Kunden, Verzeichnis der den Anwendungsschlüsseln verweigerten Vorgänge, einmalige Anzeige der Schlüssel, Beschränkung der Schlüssel auf einzelne digitale Mitarbeiter, Verschlüsselung der ruhenden Daten, Aufbewahrung und Löschung der Sprachkonversationen, Prüfung der Signaturen der Webhooks, Schutz gegen Anfragen an interne Netzwerkressourcen, Verwendung von Proof Key for Code Exchange und des signierten State-Parameters bei den Autorisierungen, Isolierung der Skriptausführung und Funktionen der Pseudonymisierung.
9.6 Isolierte Ausführung der Skripte. Die vom Kunden in den Automatisierungen definierten Skripte werden in einer isolierten Umgebung ohne Zugriff auf externe Ressourcen ausgeführt und sind nach Rekursionstiefe, Speicher, Zeit, Anzahl der Anweisungen und Laufzeit der Suchausdrücke begrenzt.
9.7 Fehlervertrag. Die an die Clients zurückgegebenen Fehlerantworten enthalten weder Stack-Traces noch interne Einzelheiten: sie werden in normalisiertem Format mit einer für den Support nützlichen Korrelationskennung zurückgegeben.
9.8 Transparenzhinweis. Der Anbieter erklärt zum Tag der vorliegenden Anlage nicht die automatische Ausführung einer Schwachstellenanalyse der Abhängigkeiten, eines Secret-Scannings oder einer statischen Sicherheitsanalyse des Codes durch Dritte in der kontinuierlichen Integration.
10. Schutz vor Missbrauch und vor unsachgemäßer Nutzung
10.1 Begrenzung der Anfragehäufigkeit. Die Anwendungsschnittstellen sind durch Häufigkeitsgrenzen geschützt, mit normalisierter Antwort und Angabe der Wartezeit. Vorgesehen sind gesonderte Richtlinien für das Chat-Widget, mit Sofortlimit und Tagesbudget je Kunde, für den authentifizierten Nutzer und für den anonymen Verkehr, sowie konfigurierbare Regeln je einzelnem Pfad und je einzelnem Kunden.
10.2 Verarbeitungsgrenzen. Die zeitversetzt ausgeführten Aufträge unterliegen einer Nebenläufigkeitsgrenze je Kunde, die nicht überschritten werden kann. Der Verbrauch des Dienstes unterliegt einem Kontingent, mit Fail-closed-Verhalten bei dessen Überschreitung.
10.3 Validierung des Ursprungs des Widgets. Das Chat-Widget nimmt Anfragen nur von erklärten und geprüften Ursprüngen an. Fehlt der Ursprung, erfolgt die Zurückweisung.
10.4 Integrität der eingehenden Kommunikation. Alle von den externen Anbietern empfangenen Webhooks unterliegen einer Signaturprüfung mit zeitkonstantem Vergleich. Für den Sprachkanal umfasst die Prüfung die Zurückweisung bei fehlendem Geheimnis und einen auf dem Zeitstempel beruhenden Schutz gegen die Wiederverwendung derselben Anfrage.
10.5 Ausgehende Kommunikation. Die an die Systeme des Kunden gesendeten Webhooks werden signiert, sodass der Empfänger ihre Echtheit prüfen kann.
10.6 Schutz gegen Anfragen an interne Ressourcen. Die Adressen, die die Plattform auf Verlangen des Kunden kontaktiert, unterliegen einer Kontrolle, die die Anfrage zurückweist, wenn auch nur eine einzige aufgelöste Adresse zu reservierten, internen oder Dienstadressräumen der Infrastruktur gehört. Die Kontrolle wird bei jedem neuen Sendeversuch wiederholt.
11. Schutzinstrumente, die dem Kunden zur Verfügung stehen
11.1 Region der Datenresidenz der Sprachdaten. Die Auswahl der europäischen Region des Sprachanbieters, mit Wirkung auf die Anrufe und die Transkriptionen der eigenen Umgebung, steht den Kunden des Enterprise-Tarifs zur Verfügung; für die übrigen Tarife gilt die globale Region. Für die vom Anbieter bereitgestellten gemeinsam genutzten Sprachabonnements gilt in jedem Fall die globale Region. Die dem Enterprise-Tarif vorbehaltenen Funktionen stehen zur Verfügung, soweit sie im vom Anbieter angenommenen kommerziellen Angebot vorgesehen sind, nach Art. 2.3 der Bedingungen; die Tarife sind in der unter der Adresse https://evolus.ai/de/preise veröffentlichten Preisliste beschrieben.
11.2 Weiterleitung der Anfragen an die Modelle und Beschränkung der Anbieter. Den Kunden des Enterprise-Tarifs stehen zur Verfügung, soweit im vom Anbieter angenommenen kommerziellen Angebot nach Art. 2.3 der Bedingungen vorgesehen: die Festlegung des Verzeichnisses der für die eigene Umgebung zugelassenen Inferenzanbieter, die vom System angewandt wird und den auf der Ebene der einzelnen Funktion eingestellten Präferenzen vorgeht; die europäische Weiterleitung der Anfragen an die Modelle über den Endpunkt des Weiterleitungsdienstes in der Europäischen Union; die Weiterleitung ausschließlich an Endpunkte ohne Inhaltsspeicherung. Für die übrigen Tarife gelten die globale Weiterleitung und die Inferenzanbieter des auf der Seite der Unterauftragsverarbeiter unter der Adresse https://evolus.ai/de/unterauftragsverarbeiter veröffentlichten Verzeichnisses.
11.3 Aufbewahrung der Sprachkonversationen. Für alle Tarife kann der Kunde die Aufbewahrungsfrist für jeden Sprachagenten konfigurieren und den Modus ohne Aufbewahrung nach den Absätzen 8.2 und 8.3 aktivieren.
11.4 Pseudonymisierung und Schwärzung. Die Plattform stellt Funktionen zur Pseudonymisierung personenbezogener Daten und zur Schwärzung von Dokumenten bereit. Die Schwärzung der Dokumente im PDF-Format wird durch Rasterung verwirklicht, sodass der geschwärzte Text in der erzeugten Datei nicht mehr vorhanden ist. Ein Pseudonymisierungsbaustein kann innerhalb der vom Kunden definierten Automatisierungen verwendet werden.
11.5 Nicht deaktivierbare Schutzvorkehrungen. Die digitalen Mitarbeiter wenden Schutzvorkehrungen an, die der Kunde weder deaktivieren noch durch Anweisungen umgehen kann, und zwar hinsichtlich der ausdrücklichen Bestätigung des Nutzers vor maßgeblichen Handlungen, der Überprüfung der Identität des Empfängers, der Überprüfung der Echtheit des Absenders und der Kennzeichnung als künstliche Intelligenz. Der Sprachkanal wendet ferner eine Reihe nicht deaktivierbarer Regeln zum Schutz der personenbezogenen Daten der Mitarbeiter, der internen Kommunikation, der wirtschaftlichen Daten und der Meinungen an.
11.6 Kennzeichnung als künstliche Intelligenz. Die Kennzeichnung als künstliche Intelligenz wird vom System auf die ausgehende Kommunikation erneut angewandt, kann vom Kunden nicht entfernt werden, und der entsprechende Nachweis wird aufbewahrt. Der Anbieter führt eine periodische Konformitätsprüfung der erzeugten Kommunikation durch.
11.7 Anwendung für mobile Geräte. Die Audiodaten der Sprachnachrichten werden über die Verarbeitung hinaus nicht auf den Systemen des Anbieters aufbewahrt; es verbleibt allein die Messung der Dauer für Zwecke des Verbrauchs. Die auf dem Gerät aufgezeichneten Audiodaten der Besprechungen werden in einem Bereich abgelegt, der von den Sicherungskopien des Systems ausgenommen ist. Der Zugriff auf die Kamera ist von den Berechtigungen der Anwendung ausgeschlossen. Die Berechtigungsanfragen erklären dem Nutzer ausdrücklich, dass der Inhalt über die Systeme des Anbieters und über den Anbieter der künstlichen Intelligenz läuft.
12. Anbieter und Unterauftragsverarbeiter
12.1 Auswahl. Der Anbieter wählt die Unterauftragsverarbeiter auf der Grundlage der gebotenen Garantien im Bereich des Datenschutzes und der Informationssicherheit aus und schließt mit jedem eine Auftragsverarbeitungsvereinbarung mit Pflichten, die nicht weniger streng sind als die gegenüber dem Kunden übernommenen.
12.2 Öffentliches Verzeichnis. Das Verzeichnis der Unterauftragsverarbeiter ist in versionierter Form unter der Adresse https://evolus.ai/de/unterauftragsverarbeiter veröffentlicht, mit Angabe der ausgeübten Tätigkeit, des Landes der Niederlassung und der Rechtsgrundlage der Übermittlung, soweit anwendbar.
12.3 Änderungen. Die Hinzufügungen und die Ersetzungen werden dem Kunden mit einer Vorankündigung von mindestens 30 Tagen mitgeteilt, mit dem Recht auf begründeten Einspruch, nach Art. 5 der Anlage A.
12.4 Übermittlungen. Die Rechtsgrundlagen der Übermittlungen in Drittländer und die dem Enterprise-Tarif vorbehaltenen Funktionen zur Verringerung der Übermittlungen sind in Art. 6 der Anlage A geregelt.
13. Behandlung von Vorfällen und von Verletzungen des Schutzes personenbezogener Daten
13.1 Dokumentiertes Verfahren. Der Anbieter unterhält ein dokumentiertes Verfahren zur Behandlung von Verletzungen des Schutzes personenbezogener Daten, das die Kanäle der Feststellung und der Meldung, die Rollen und die Verantwortlichkeiten, die operativen Phasen mit den entsprechenden Fristen, die Kriterien zur Bewertung des Risikos für die betroffenen Personen, die Kommunikationsvorlagen und die Regeln zum Abschluss, zur Ursachenanalyse und zur Überprüfung der Korrekturmaßnahmen festlegt.
13.2 Interne Meldung. Jede Person, die für den Anbieter tätig ist, ist verpflichtet, jedes verdächtige Ereignis unverzüglich, in jedem Fall innerhalb einer Stunde, über die dafür vorgesehenen Kanäle und ohne vorherige Analysen zu melden, wobei es untersagt ist, die Nachweise zu verändern oder zu vernichten.
13.3 Eindämmung und Aufbewahrung der Nachweise. Das Verfahren sieht typisierte Eindämmungsmaßnahmen vor, darunter den Widerruf der Sitzungen und der Autorisierungen, die Sperrung der Konten, die Isolierung des betroffenen Containers, die Aussetzung der einzelnen Funktion, den Wechsel der Geheimnisse, den Widerruf der temporären Links zu den Dateien und die Sperrung der ausgehenden Kommunikation sowie das Einfrieren und die Extraktion der Nachweise mit Integritätsprüfung.
13.4 Meldung an den Kunden. Der Anbieter meldet dem Kunden jede Verletzung, die seine Daten betrifft, innerhalb von 48 Stunden ab dem Zeitpunkt, in dem er davon Kenntnis erlangt, unabhängig vom Risikoniveau, mit dem in Art. 33 Abs. 3 der Verordnung vorgesehenen Inhalt, und übermittelt bis zum Abschluss des Falls regelmäßige Aktualisierungen, nach Art. 9 der Anlage A.
13.5 Verzeichnis der Verletzungen. Der Anbieter führt ein Verzeichnis der Verletzungen des Schutzes personenbezogener Daten, das die Umstände, die Auswirkungen, die getroffenen Maßnahmen, die Entscheidungen über die Meldungen und die entsprechenden Gründe dokumentiert, einschließlich der Beinahe-Verletzungen, die vor dem Eintritt von Auswirkungen abgefangen wurden.
13.6 Überprüfung und Übung. Das Verfahren wird mindestens jährlich und nach jeder als mittleres oder hohes Risiko eingestuften Verletzung überprüft und wird jährlich einer Simulationsübung unterzogen.
14. Personal
14.1 Vertraulichkeit. Die zur Verarbeitung der Daten der Kunden befugten Personen haben Vertraulichkeitsvereinbarungen unterzeichnet, deren Pflicht über die Beendigung des Beschäftigungsverhältnisses hinaus fortbesteht.
14.2 Befugnis und Weisungen. Die Befugnis zur Verarbeitung wird allein den Personen erteilt, die sie für die Erbringung des Dienstes, für den Support, für die Wartung und für die Sicherheit benötigen, mit schriftlichen Weisungen zu den Modalitäten der Verarbeitung.
14.3 Zugriff auf die Daten der Kunden. Der Zugriff des Personals auf die Daten der Kunden erfolgt über die Werkzeuge der Plattform, unterliegt den Kontrollen des Abschnitts 2 und wird nach Absatz 2.8 und Abschnitt 6 aufgezeichnet.
14.4 Schulung. Ein Programm zur Schulung des Personals im Bereich des Schutzes personenbezogener Daten und der Informationssicherheit wird im Rahmen des Managementsystems nach Absatz 1.3 eingeführt. Der Anbieter erklärt zum Tag der vorliegenden Anlage keine bereits durchgeführte Schulung.
15. Überarbeitung der vorliegenden Anlage
15.1 Aktualisierung. Der Anbieter kann die vorliegende Anlage aktualisieren, um die technische und organisatorische Entwicklung der Maßnahmen abzubilden, sofern das Gesamtniveau der Sicherheit nicht verringert wird, im Sinne von Art. 12.5 der Bedingungen.
15.2 Versionierung. Jede Fassung wird durch einen Code und durch einen SHA-256-Hashwert des Textes identifiziert. Die früheren Fassungen bleiben dem Kunden für die gesamte Laufzeit des Vertrags zugänglich.
15.3 Mitteilung. Die Aktualisierungen werden nach den Modalitäten und Ankündigungsfristen des Art. 13 der Bedingungen mitgeteilt. Aktualisierungen, die eine Verringerung der Garantien mit sich bringen, begründen ein Rücktrittsrecht ohne Vertragsstrafen nach Art. 13.2 der Bedingungen.
15.4 Periodische Überprüfung. Der Anbieter überprüft die Maßnahmen in dem Rhythmus des Absatzes 1.4 und aktualisiert die vorliegende Anlage im Fall einer wesentlichen Änderung.
Anlage B, Version 1.0. CodeDesign S.r.l., Via Nino Pesce 38, 18018 Taggia (IM), USt-IdNr. IT01739830089. Kontakt für den Datenschutz: privacy@codedesign.it.