Anexo B. Medidas técnicas y organizativas (artículo 32 del Reglamento (UE) 2016/679)

Preámbulo

El presente Anexo describe las medidas técnicas y organizativas que CodeDesign S.r.l. (en adelante, el "Proveedor") adopta con arreglo al artículo 32 del Reglamento (UE) 2016/679 para garantizar un nivel de seguridad adecuado al riesgo en el tratamiento de datos personales realizado por cuenta del Cliente.

Las medidas se describen por función y por efecto. El Proveedor no indica detalles de implementación, denominaciones de sistemas internos, direcciones, componentes o parámetros de configuración cuya divulgación reduciría la eficacia de las propias medidas. Se pone información adicional a disposición del Cliente con las modalidades y los límites del artículo 4.8 del Anexo A.

El presente Anexo describe el estado de las medidas en la fecha de la versión. Puede ser actualizado por el Proveedor siempre que el nivel global de seguridad no se reduzca, con arreglo al artículo 12.5 de las Condiciones y a la sección 15 que sigue.

1. Organización de la seguridad

1.1 Funciones. El Proveedor ha atribuido de forma expresa las siguientes responsabilidades:

• a) Responsable de la seguridad de la información: evaluación de los riesgos de seguridad, verificación de la eficacia de las medidas, propuesta y verificación de las acciones correctivas.
• b) Persona de referencia para la protección de los datos personales: coordinación de la materia de protección de datos, calificación y gestión de las violaciones desde el punto de vista jurídico, llevanza del registro de violaciones, relaciones con la autoridad de control, atención del buzón privacy@codedesign.it.
• c) Responsable de la gestión de incidentes: asunción de los avisos, contención técnica, recogida y conservación de las evidencias, reconstrucción del alcance del suceso, coordinación de la recuperación.
• d) Dirección: decisión sobre las notificaciones a la autoridad de control y sobre las comunicaciones a los interesados cuando el Proveedor actúa como responsable del tratamiento, aprobación de los recursos para las acciones correctivas.

1.2 Delegado de protección de datos. El Proveedor no ha designado un delegado de protección de datos con arreglo al artículo 37 del Reglamento, al haber valorado que no concurren sus presupuestos. La valoración se revisa con una periodicidad al menos anual. El punto de contacto sigue siendo el buzón privacy@codedesign.it.

1.3 Sistema de gestión. El Proveedor ha iniciado la adopción de un sistema de gestión de la seguridad de la información conforme con la norma ISO/IEC 27001:2022 y el proceso de certificación correspondiente está en curso. En la fecha del presente Anexo la certificación no se ha obtenido. El Proveedor no declara estar certificado y comunicará a los Clientes su eventual obtención, actualizando el presente Anexo.

1.4 Revisión. Las medidas descritas en el presente Anexo se revisan con una periodicidad al menos anual, después de cada violación de la seguridad de los datos personales clasificada como de riesgo medio o alto y después de cada modificación relevante de la arquitectura del Servicio.

2. Control de los accesos y autenticación

2.1 Identidad centralizada. El acceso a la plataforma se realiza exclusivamente a través de un sistema centralizado de gestión de las identidades, distinto de la aplicación. Las credenciales de los usuarios no son conservadas por la aplicación.

2.2 Verificación de la dirección de correo electrónico. La política de autorización predeterminada de todas las interfaces aplicativas exige, además de la autenticación, que la dirección de correo electrónico del usuario figure como verificada. El acceso se deniega a falta de dicho requisito.

2.3 Autenticación de dos factores. Está disponible un segundo factor de autenticación mediante código de un solo uso enviado a la dirección de correo electrónico del usuario, configurable en el sistema de identidad.

2.4 Validación de las sesiones. Los tokens de acceso se validan en profundidad: verificación del destinatario, verificación del emisor frente a una lista explícita, verificación de la duración y de la caducidad, verificación de la firma con rechazo de los tokens no firmados, tolerancia limitada en los relojes. Los resultados negativos se registran con el motivo del rechazo, sin registrar nunca el token.

2.5 Claves de acceso aplicativas. Las claves de acceso entregadas al Cliente para el uso automatizado del Servicio se generan con entropía elevada, se conservan en reposo exclusivamente en forma de huella criptográfica y se muestran en claro una sola vez, en el momento de su creación. Una clave sin ámbitos declarados no permite la autenticación en ningún canal. Cada clave puede limitarse a Empleados digitales concretos. Las claves tienen estado y caducidad verificados en cada uso.

2.6 Separación de los privilegios de las claves. Una clave aplicativa no puede en ningún caso obtener privilegios de plataforma, de sistema o de organización, y está sujeta a una lista explícita de operaciones siempre denegadas, entre ellas la gestión de la suscripción, la modificación de los créditos y la gestión de las cuotas. Cuando una solicitud incorpora tanto la identidad de un usuario como una clave aplicativa, prevalece siempre el perfil de autorización del usuario.

2.7 Permisos granulares y comportamiento fail-closed. La autorización se basa en permisos atómicos resueltos por el sistema, no en el plan de suscripción. Cada interfaz declara de forma expresa el permiso exigido y deniega el acceso a falta de declaración o de permiso. Ningún perfil distinto del administrador de plataforma puede crear o modificar definiciones de rol, y por tanto no puede atribuirse privilegios superiores a los que posee.

2.8 Acceso por cuenta de un usuario. La función con la que el personal del Proveedor opera por cuenta de un Usuario del Cliente se admite únicamente a los perfiles expresamente habilitados, no puede activarse mediante la sola declaración del solicitante, exige privilegios superiores para operar sobre perfiles administrativos y queda anotada en el registro de auditoría, junto con los intentos denegados.

2.9 Autorizaciones a los servicios conectados. Las autorizaciones OAuth a los servicios conectados por el Cliente se obtienen con el flujo de código de autorización con extensión de clave de prueba (PKCE) y con parámetro de estado firmado y verificado con comparación en tiempo constante. La renovación de los tokens se realiza en flujo único con bloqueo distribuido.

2.10 Tokens de vida breve. Las sesiones de las funciones de transcripción en tiempo real y las sesiones de prueba de los agentes de voz usan tokens de duración limitada, de un solo uso para las sesiones de prueba, con firma verificada. En ausencia de la clave de firma ningún token se considera válido.

2.11 Custodia de los tokens en el lado del cliente. El portal del Cliente conserva el token de acceso exclusivamente en memoria, sin escribirlo en el almacenamiento local del navegador. La aplicación para dispositivos móviles conserva las credenciales en el almacén seguro del sistema operativo y aplica el cierre de sesión coordinado con supresión de las claves. Los portales secundarios no exponen ningún token al navegador, y mantienen la sesión en el lado del servidor de forma cifrada.

3. Separación de los datos entre Clientes

3.1 Perímetro. La unidad de separación es el entorno aplicativo de cada Cliente. Todo recurso, solicitud, credencial y registro se refiere a dicho entorno, y la pertenencia del usuario al entorno se verifica en cada solicitud.

3.2 Naturaleza de la medida. La separación se realiza mediante controles aplicativos explícitos en los servicios, integrados por una regla única de verificación del acceso aplicada como defensa en profundidad. El Proveedor declara con transparencia que se trata de controles aplicativos vigilados por pruebas automáticas contra regresiones y no de una separación estructural a nivel de almacén de datos.

3.3 Pruebas automáticas. La integración continua ejecuta, en cada modificación, pruebas que verifican: que cada interfaz declare el permiso exigido, con lista explícita y motivada únicamente de las excepciones admitidas; que no sea posible acceder a recursos pertenecientes a otros Clientes; que las limitaciones de los privilegios de las claves aplicativas se respeten. El fallo de dichas pruebas impide la integración de la modificación.

3.4 Borrado lógico. Las entidades principales del modelo de datos están sujetas a borrado lógico con filtro global, de modo que un registro borrado nunca sea devuelto por las consultas ordinarias.

3.5 Separación de los Empleados digitales. Cada Empleado digital del Cliente se ejecuta en un contenedor dedicado, con volúmenes de almacenamiento propios, con la base de conocimiento montada en solo lectura y con el espacio de trabajo separado. El almacén local con conversaciones, memoria y transcripciones reside en el volumen de cada contenedor.

3.6 Canal interno de los Empleados digitales. Las llamadas desde el contenedor a los servicios centrales se autentican con una credencial derivada, verificada con comparación en tiempo constante y vinculada a la identidad del Empleado digital, con control de coherencia contra el sistema de orquestación y con protección contra la suplantación de identidad entre Empleados digitales distintos.

3.7 Separación en la observabilidad. Toda consulta sobre registros y trazas técnicas debe contener la referencia al entorno del Cliente, a falta de la cual se rechaza, y la pertenencia del usuario a ese entorno se verifica. A los perfiles no administrativos se les eliminan de los resultados los campos técnicos que podrían contener fragmentos de contenido.

3.8 Revendedores. Los privilegios atribuidos a un revendedor operan únicamente sobre los recursos ligados al revendedor por una relación explícita registrada en el sistema. La condición de revendedor solo puede ser modificada por el administrador de plataforma y la modificación queda anotada en el registro de auditoría.

4. Cifrado

4.1 Cifrado de los datos en tránsito

• a) Todas las comunicaciones entre los clientes y la plataforma se realizan por canal cifrado con protocolo TLS, con redirección obligatoria del tráfico no cifrado fuera de los entornos de desarrollo.
• b) Los metadatos del sistema de identidad se recuperan exclusivamente por canal cifrado.
• c) Los enlaces temporales con los que se ponen a disposición los archivos se emiten en solo lectura, exclusivamente por canal cifrado, con una caducidad no superior a una hora.
• d) Las conexiones a los servidores de correo entrante y saliente configurados por el Cliente se realizan por canal cifrado, con negociación protegida.
• e) El correo consultado desde la aplicación para dispositivos móviles se transmite exclusivamente por canal cifrado con verificación del certificado del servidor, sin excepción alguna: un certificado no válido conlleva el rechazo de la conexión.
• f) La política de acceso desde orígenes distintos no permite la transmisión de credenciales de sesión, de modo que ninguna cookie pueda ser enviada desde un origen de terceros.

4.2 Cifrado aplicativo de los datos en reposo

• a) El Proveedor aplica un cifrado aplicativo con algoritmo AES de 256 bits en modo GCM, con envoltorio versionado, vector de inicialización aleatorio y etiqueta de autenticación. Una clave de longitud no conforme se rechaza para su uso y un descifrado fallido genera un error sin devolver nunca el dato.
• b) Están protegidos con dicho cifrado: las credenciales y las claves de acceso a los servicios configurados por el Cliente, las credenciales de los buzones de correo y de los flujos de trabajo, los secretos de firma de los canales y de los webhooks, las credenciales y los tokens de los conectores activados por el Cliente, las cadenas de conexión a los archivos documentales del Cliente, así como las transcripciones, las listas de participantes y los resultados de las reuniones procesadas por la aplicación para dispositivos móviles.
• c) Precisión de transparencia. El cifrado aplicativo de la letra b) no se extiende a los contenidos de las conversaciones de chat ni a los documentos cargados en las bibliotecas de conocimiento, que están protegidos por los controles de acceso descritos en las secciones 2 y 3 y por el cifrado en reposo del almacenamiento subyacente del apartado 4.3.

4.3 Cifrado en reposo de la infraestructura

El cifrado en reposo de los soportes de almacenamiento lo facilitan los proveedores de infraestructura conforme a sus condiciones de servicio. El Proveedor no declara dicha medida como verificada por él mismo y no la asume como compromiso contractual propio hasta la obtención de la certificación escrita del proveedor de infraestructura en la nube y del proveedor del servidor dedicado.

4.4 Copias de seguridad

Las copias de seguridad de los Empleados digitales se cifran en el origen, antes de su transmisión al almacenamiento remoto: sin la clave de cifrado las copias no son utilizables.

5. Gestión de los secretos

5.1 Almacén centralizado. Las credenciales y los secretos necesarios para la prestación del Servicio se conservan en un almacén dedicado, organizado por ámbitos separados, con el valor cifrado en el momento de la escritura con arreglo al apartado 4.2.

5.2 Clave principal. La clave principal de cifrado es única, no reside en el código fuente ni en los archivos de configuración versionados y se custodia en el almacén de claves del proveedor de infraestructura en la nube, desde el que se pone a disposición de la aplicación como ajuste protegido.

5.3 Resolución en el momento del uso. Los secretos se resuelven únicamente en el momento en que se necesitan y con comportamiento fail-closed: una referencia que no se resuelve genera un error y no produce nunca un valor vacío. Las configuraciones transmitidas a los Empleados digitales contienen exclusivamente referencias a los secretos, nunca los valores.

5.4 No recuperabilidad. Los valores de los secretos no son devueltos nunca por las interfaces de programación de la plataforma: la exclusión la impone por diseño el serializador de las respuestas y no depende de cada desarrollador. El almacén de secretos a disposición del Cliente es de solo escritura: los valores introducidos ya no pueden volver a leerse.

5.5 Registros. Los valores de los secretos se ocultan en los registros técnicos, incluso cuando se resuelven en el momento del uso, y no figuran en los registros de arranque de los Empleados digitales.

6. Registro y monitorización

6.1 Registro de auditoría de las operaciones administrativas. El Proveedor mantiene un registro de las operaciones administrativas que recoge para cada operación: fecha y hora, autor real, eventual sujeto que ha operado por cuenta de un usuario, entorno y organización afectados, categoría y tipo de acción, objeto afectado, detalles y dirección de procedencia. Están cubiertas, entre otras, las operaciones sobre roles y permisos, usuarios y pertenencias, créditos y cuotas, dominios y grupos, concesiones sobre los recursos y avisos de asistencia, así como los accesos por cuenta de un usuario.

6.2 Acceso al registro. La consulta del registro está protegida por un permiso dedicado. La vista referida a un Cliente concreto está siempre filtrada por el entorno de ese Cliente.

6.3 Conservación. Las entradas del registro de auditoría se conservan durante 24 meses y después se suprimen automáticamente.

6.4 Precisión de transparencia. El registro de auditoría cubre las operaciones administrativas y de configuración. El Proveedor no declara un registro inmutable ni un registro de los accesos a los contenidos de los Clientes.

6.5 Observabilidad. La plataforma produce trazas, métricas y registros técnicos con un sistema de observabilidad, enriquecidos con la referencia al entorno del Cliente. El acceso está sujeto a los controles del apartado 3.7.

6.6 Contenidos excluidos de los registros. Las reglas de escritura del código prohíben el registro de secretos, tokens y contenidos extensos de los usuarios, y están vigiladas por la revisión de las modificaciones.

6.7 Alarmas operativas. El Proveedor mantiene alarmas automáticas sobre los sucesos relevantes para la continuidad y para la seguridad, entre ellos el resultado negativo de las verificaciones periódicas de recuperación y el reinicio repetido de los servicios, con notificación a un buzón atendido.

6.8 Página de estado pública. El Proveedor publica una página de estado del Servicio, alimentada por sondas internas y hacia los proveedores anteriores en la cadena, con notificaciones por correo electrónico, canal de suscripción y avisos internos. Por decisión de seguridad la página no expone el nombre ni el número de los Empleados digitales de los Clientes.

7. Copias de seguridad y continuidad

7.1 Entorno de los Empleados digitales

7.1.1 Versiones. El almacenamiento de objetos que aloja las copias mantiene las versiones no actuales durante 30 días, como protección frente a las supresiones accidentales.

7.1.2 Verificación automática. Una verificación automática ejecutada cada 6 horas realiza una recuperación real de un Empleado digital por rotación a partir del almacenamiento remoto y compara las huellas criptográficas de los datos recuperados. El resultado negativo genera una alarma; con periodicidad regular se genera en todo caso una confirmación de funcionamiento de la propia verificación.

7.1.3 Prueba de recuperación. La última prueba de recuperación real, realizada con pérdida simulada de los volúmenes, se superó el 10 de julio de 2026, con un tiempo de recuperación medido de unos 15 minutos, identidad de los datos recuperados verificada por huella criptográfica y servicio reactivado al primer intento.

7.1.4 Perímetro. No entran en el perímetro de las copias de seguridad, por decisión documentada, las grabaciones de las reuniones obtenidas mediante participante automático, el código aplicativo y las cachés de los espacios de trabajo.

7.2 Entorno de la plataforma en la nube

Las copias de seguridad de la base de datos y del almacenamiento de archivos de la plataforma en la nube son las previstas por los servicios gestionados del proveedor de infraestructura. El Proveedor no declara, en la fecha del presente Anexo, objetivos de tiempo de recuperación y de pérdida máxima de datos para dicho entorno: los objetivos se declararán y se asumirán como compromiso cuando la configuración correspondiente esté verificada y documentada.

8. Conservación y supresión de los datos

8.1 Supresiones automáticas. El Proveedor ejecuta las siguientes supresiones o anonimizaciones automáticas:

8.2 Conversaciones de voz. La conservación de las conversaciones de voz es configurable por el Cliente para cada agente. Un proceso nocturno aplica un doble criterio, teniendo en cuenta tanto la caducidad comunicada por el proveedor de voz para cada conversación como el plazo configurado por el Cliente, y aplica el primero de los dos que venza. La supresión conlleva la eliminación efectiva del archivo de audio del almacenamiento y el borrado de la transcripción, del resumen, del análisis, del número de teléfono de quien llama y de la referencia al audio, con nuevo intento en caso de error. Queda una fila técnica residual sin datos personales, conservada con la sola finalidad de evitar duplicidades en la fase de importación y de demostrar que se realizó la declaración de naturaleza artificial.

8.3 Modalidad sin conservación. El Cliente puede activar una modalidad en la que la conversación de voz se registra sin contenido desde el momento mismo de su obtención.

8.4 Supresión por acción del Cliente. La supresión de un documento conlleva la eliminación del archivo del almacenamiento, la eliminación de sus índices de búsqueda y el borrado lógico del registro. La supresión de una biblioteca conlleva la supresión de los documentos que contiene. La supresión de un Usuario conlleva el borrado lógico en la plataforma y la supresión efectiva en el sistema de identidad, con anotación en el registro de auditoría.

8.5 Precisión de transparencia. Para las conversaciones de chat y para los documentos de las bibliotecas de conocimiento no se prevé un plazo automático de supresión: se conservan durante la vigencia del Contrato, pueden suprimirse por acción del Cliente con arreglo al apartado 8.4 y se suprimen al término del Contrato con arreglo al artículo 10 del Anexo A.

8.6 Supresión al término del Contrato. Se aplica íntegramente el artículo 10 del Anexo A, que regula la elección entre devolución y supresión, los plazos de 60 y 90 días y el bloqueo del acceso en el periodo intermedio.

9. Desarrollo seguro

9.1 Ramas protegidas y revisión. Las ramas principales del código aceptan modificaciones exclusivamente mediante solicitud de integración sometida a revisión. No se permite la escritura directa.

9.2 Verificaciones automáticas. En cada solicitud de integración la integración continua ejecuta la restauración de las dependencias, la compilación en configuración de publicación y la ejecución del conjunto de pruebas, con privilegios mínimos asignados al ejecutor. Un control dedicado impide la integración de modificaciones que carezcan de la documentación del impacto para el usuario.

9.3 Publicación sin credenciales estáticas. La publicación en producción se realiza mediante identidad federada ante el proveedor de infraestructura, sin credenciales estáticas almacenadas en el sistema de integración continua. La nueva versión se publica en un entorno de prueba y se promueve a producción únicamente tras su verificación, con posibilidad de retorno inmediato a la versión anterior.

9.4 Reglas de codificación vigiladas por herramientas automáticas. El Proveedor utiliza herramientas de análisis estático propias que prohíben la gestión genérica de las excepciones en los servicios, prohíben la supresión silenciosa de los errores e imponen la protección de las llamadas arriesgadas. La construcción manual de las respuestas de error se impide en fase de compilación.

9.5 Pruebas de seguridad contra regresiones. El conjunto comprende pruebas dedicadas sobre: cobertura del control de los permisos en cada interfaz, imposibilidad de acceder a recursos de otros Clientes, lista de las operaciones denegadas a las claves aplicativas, visualización única de las claves, limitación de las claves a Empleados digitales concretos, cifrado de los datos en reposo, conservación y supresión de las conversaciones de voz, verificación de las firmas de los webhooks, protección frente a las solicitudes a recursos de red internos, uso de la extensión de clave de prueba y del estado firmado en las autorizaciones, aislamiento de la ejecución de los scripts y funciones de seudonimización.

9.6 Ejecución aislada de los scripts. Los scripts definidos por el Cliente en las automatizaciones se ejecutan en un entorno aislado, sin acceso a recursos externos y limitado en profundidad de recursión, memoria, tiempo, número de instrucciones y duración de las expresiones de búsqueda.

9.7 Contrato de error. Las respuestas de error devueltas a los clientes no contienen trazas de ejecución ni detalles internos: se devuelven en formato normalizado con un identificador de correlación útil para la asistencia.

9.8 Precisión de transparencia. El Proveedor no declara, en la fecha del presente Anexo, la ejecución automática en integración continua de análisis de las vulnerabilidades de las dependencias, de escaneo de los secretos ni de análisis estático de seguridad del código de terceros.

10. Protección frente a abusos y usos indebidos

10.1 Limitación de la frecuencia de las solicitudes. Las interfaces aplicativas están protegidas por límites de frecuencia, con respuesta normalizada e indicación del tiempo de espera. Se prevén políticas distintas para el widget de chat, con límite instantáneo y presupuesto diario por Cliente, para el usuario autenticado y para el tráfico anónimo, así como reglas configurables por cada ruta y por cada Cliente.

10.2 Límites de procesamiento. Los trabajos en ejecución diferida están sujetos a un límite de concurrencia por Cliente, no superable. El consumo del Servicio está sujeto a cuota, con comportamiento fail-closed cuando se supera.

10.3 Validación del origen del widget. El widget de chat acepta solicitudes únicamente desde orígenes declarados y verificados. La ausencia del origen conlleva el rechazo.

10.4 Integridad de las comunicaciones entrantes. Todos los webhooks recibidos de los proveedores externos están sujetos a verificación de la firma, con comparación en tiempo constante. Para el canal de voz la verificación comprende el rechazo a falta del secreto y una protección frente a la reutilización de la misma solicitud basada en la referencia temporal.

10.5 Comunicaciones salientes. Los webhooks enviados a los sistemas del Cliente van firmados, de modo que el destinatario pueda verificar su autenticidad.

10.6 Protección frente a las solicitudes a recursos internos. Las direcciones que la plataforma contacta a petición del Cliente se someten a un control que rechaza la solicitud cuando aunque sea una sola dirección resuelta pertenece a espacios reservados, internos o de servicio de la infraestructura. El control se repite en cada nuevo intento de envío.

11. Herramientas de protección a disposición del Cliente

11.1 Región de residencia de los datos de voz. La selección de la región europea del proveedor de voz, con efecto sobre las llamadas y las transcripciones del propio entorno, está disponible para los Clientes del Plan Enterprise; para los demás planes se aplica la región global. Para las suscripciones de voz compartidas puestas a disposición por el Proveedor se aplica en todo caso la región global. Las funciones reservadas al Plan Enterprise están disponibles cuando así se prevea en la propuesta comercial aceptada por el Proveedor, con arreglo al artículo 2.3 de las Condiciones; los planes se describen en la lista de precios publicada en la dirección https://evolus.ai/es/precios.

11.2 Enrutamiento de las solicitudes a los modelos y limitación de los proveedores. Están disponibles para los Clientes del Plan Enterprise, cuando así se prevea en la propuesta comercial aceptada por el Proveedor con arreglo al artículo 2.3 de las Condiciones: la definición de la lista de los proveedores de inferencia admitidos para el propio entorno, que es aplicada por el sistema y prevalece sobre las preferencias establecidas a nivel de cada función; el enrutamiento europeo de las solicitudes a los modelos, mediante el endpoint de la Unión Europea del servicio de enrutamiento; el enrutamiento únicamente a los endpoints de conservación cero. Para los demás planes se aplican el enrutamiento global y los proveedores de inferencia de la lista publicada en la página de los subencargados, en la dirección https://evolus.ai/es/subencargados.

11.3 Conservación de las conversaciones de voz. Para todos los planes el Cliente puede configurar el plazo de conservación para cada agente de voz y puede activar la modalidad sin conservación, con arreglo a los apartados 8.2 y 8.3.

11.4 Seudonimización y ocultación. La plataforma pone a disposición funciones de seudonimización de los datos personales y de ocultación de los documentos. La ocultación de los documentos en formato PDF se realiza mediante rasterización, de modo que el texto ocultado ya no esté presente en el archivo producido. Un bloque de seudonimización puede utilizarse dentro de las automatizaciones definidas por el Cliente.

11.5 Protecciones no desactivables. Los Empleados digitales aplican protecciones que no pueden ser desactivadas por el Cliente ni eludidas mediante instrucciones, en materia de confirmación expresa del usuario antes de las acciones relevantes, verificación de la identidad del destinatario, verificación de la autenticidad del remitente y declaración de naturaleza artificial. El canal de voz aplica además un conjunto de reglas no desactivables para la protección de los datos personales de los empleados, de las comunicaciones internas, de los datos económicos y de las opiniones.

11.6 Declaración de naturaleza artificial. La declaración de naturaleza artificial la vuelve a aplicar el sistema sobre las comunicaciones salientes, no puede ser eliminada por el Cliente y su prueba se conserva. El Proveedor realiza una verificación periódica de conformidad sobre las comunicaciones generadas.

11.7 Aplicación para dispositivos móviles. El audio de los mensajes de voz no se conserva en los sistemas del Proveedor más allá del procesamiento, y queda únicamente la medición de la duración a efectos del consumo. El audio de las reuniones grabado en el dispositivo se ubica en un área excluida de las copias de seguridad del sistema. El acceso a la cámara está excluido de los permisos de la aplicación. Las solicitudes de permiso declaran expresamente al usuario que el contenido transita por los sistemas del Proveedor y por el proveedor de inteligencia artificial.

12. Proveedores y subencargados

12.1 Selección. El Proveedor selecciona a los subencargados sobre la base de las garantías ofrecidas en materia de protección de datos y de seguridad de la información, y celebra con cada uno un acuerdo de tratamiento de datos con obligaciones no menos exigentes que las asumidas frente al Cliente.

12.2 Lista pública. La lista de los subencargados está publicada en forma versionada en la dirección https://evolus.ai/es/subencargados, con indicación de la actividad realizada, del país de establecimiento y de la base jurídica de la transferencia, cuando sea aplicable.

12.3 Variaciones. Las incorporaciones y las sustituciones se comunican al Cliente con un preaviso de al menos 30 días, con derecho de oposición motivada, con arreglo al artículo 5 del Anexo A.

12.4 Transferencias. Las bases jurídicas de las transferencias a terceros países y las funciones de reducción de las transferencias reservadas al Plan Enterprise se rigen por el artículo 6 del Anexo A.

13. Gestión de los incidentes y de las violaciones de la seguridad de los datos personales

13.1 Procedimiento documentado. El Proveedor mantiene un procedimiento documentado de gestión de las violaciones de la seguridad de los datos personales, que define los canales de detección y de aviso, las funciones y las responsabilidades, las fases operativas con sus plazos, los criterios de valoración del riesgo para los interesados, los modelos de comunicación y las reglas de cierre, de análisis de las causas y de verificación de las acciones correctivas.

13.2 Aviso interno. Toda persona que opera para el Proveedor está obligada a avisar sin demora, y en todo caso en el plazo de una hora, de cualquier suceso sospechoso, a través de los canales dedicados y sin realizar análisis preliminares, con prohibición de alterar o destruir las evidencias.

13.3 Contención y conservación de las evidencias. El procedimiento prevé medidas tipificadas de contención, entre ellas la revocación de las sesiones y de las autorizaciones, el bloqueo de las cuentas, el aislamiento del contenedor afectado, la suspensión de la función concreta, la rotación de los secretos, la revocación de los enlaces temporales a los archivos y el bloqueo de las comunicaciones salientes, así como la congelación y la extracción de las evidencias con verificación de integridad.

13.4 Notificación al Cliente. El Proveedor notifica al Cliente toda violación que afecte a sus datos en el plazo de 48 horas desde que tenga conocimiento de ella, con independencia del nivel de riesgo, con el contenido previsto en el artículo 33, apartado 3, del Reglamento, y remite actualizaciones periódicas hasta el cierre del caso, con arreglo al artículo 9 del Anexo A.

13.5 Registro de violaciones. El Proveedor lleva un registro de las violaciones de la seguridad de los datos personales que documenta las circunstancias, los efectos, las medidas adoptadas, las decisiones sobre las notificaciones y sus motivaciones, incluidas las cuasi violaciones interceptadas antes de producir efectos.

13.6 Revisión y prueba. El procedimiento se revisa al menos anualmente y después de cada violación clasificada como de riesgo medio o alto, y se somete a una prueba de simulación con periodicidad anual.

14. Personal

14.1 Confidencialidad. Las personas autorizadas para el tratamiento de los datos de los Clientes han suscrito acuerdos de confidencialidad, cuya obligación permanece tras la extinción de la relación.

14.2 Autorización e instrucciones. La autorización para el tratamiento se atribuye únicamente a las personas que la necesitan para la prestación del Servicio, para la asistencia, para el mantenimiento y para la seguridad, con instrucciones escritas sobre las modalidades del tratamiento.

14.3 Acceso a los datos de los Clientes. El acceso del personal a los datos de los Clientes se realiza mediante las herramientas de la plataforma, está sujeto a los controles de la sección 2 y queda anotado con arreglo al apartado 2.8 y a la sección 6.

14.4 Formación. Un programa de formación del personal en materia de protección de los datos personales y de seguridad de la información está en curso de adopción en el marco del sistema de gestión del apartado 1.3. El Proveedor no declara, en la fecha del presente Anexo, formación ya impartida.

15. Revisión del presente Anexo

15.1 Actualización. El Proveedor puede actualizar el presente Anexo para reflejar la evolución técnica y organizativa de las medidas, siempre que el nivel global de seguridad no se reduzca, con arreglo al artículo 12.5 de las Condiciones.

15.2 Versionado. Cada versión se identifica mediante un código y una huella informática SHA-256 del texto. Las versiones anteriores permanecen accesibles al Cliente durante toda la vigencia del Contrato.

15.3 Comunicación. Las actualizaciones se comunican con las modalidades y los preavisos del artículo 13 de las Condiciones. Las actualizaciones que supongan una reducción de las garantías dan derecho al desistimiento sin penalizaciones con arreglo al artículo 13.2 de las Condiciones.

15.4 Revisión periódica. El Proveedor revisa las medidas con la periodicidad del apartado 1.4 y actualiza el presente Anexo en caso de variación sustancial.