Acuerdo de Encargado del Tratamiento (DPA)

El presente Acuerdo de Encargado de Tratamiento ("DPA") forma parte integrante de los Términos de Servicio (/es/terms/) y regula las obligaciones de AIGiner S.L. ("Encargado") cuando trata datos personales por cuenta del Cliente ("Responsable") en virtud del artículo 28 del Reglamento (UE) 2016/679 (RGPD). En caso de conflicto entre los Términos y este DPA respecto del tratamiento de datos personales, prevalecerá este DPA.

Estructura del documento: el DPA cuenta con tres anexos. El Anexo I describe la naturaleza del tratamiento (operaciones, datos, interesados); el Anexo II recoge la relación de subencargados (con enlace a la lista pública); el Anexo III detalla las medidas técnicas y organizativas aplicadas conforme al art. 32 RGPD.

1. Partes y aceptación

Responsable: el Cliente que contrata el Servicio.

Encargado: AIGiner S.L., CIF B93819753, Gran Via de Carles III, 98, 08028 Barcelona, España.

Contacto de protección de datos: dpo@aiginer.com. AIGiner no ha designado un Delegado de Protección de Datos conforme al art. 37 RGPD porque su tratamiento no se encuentra en los supuestos que lo exigen; esa dirección es el buzón por el que se canalizan las solicitudes formales del Responsable y las notificaciones de este DPA.

Este DPA se entiende aceptado por el Responsable mediante la contratación del Servicio. Para clientes que requieran firma específica (planes Max, Concerto Local, sectores regulados) se firmará versión PDF equivalente con valor probatorio.

2. Objeto y duración

El Encargado tratará datos personales por cuenta del Responsable exclusivamente con la finalidad de prestar el Servicio descrito en los Términos. La duración del tratamiento coincide con la vigencia del contrato más el periodo de devolución de datos (30 días) y los plazos legales mínimos de conservación cuando apliquen.

3. Anexo I, Detalle del tratamiento

4. Obligaciones del Encargado (art. 28 RGPD)

El Encargado se obliga a:

• Tratar los datos únicamente siguiendo instrucciones documentadas del Responsable, incluidas las indicadas en los Términos, en este DPA y las que el Responsable comunique posteriormente por canales formales, incluidas las transferencias a terceros países, solo con los subencargados y garantías del apartado 5.
• Garantizar que las personas autorizadas a tratar los datos se han comprometido a respetar la confidencialidad o están sujetas a obligación legal de confidencialidad equivalente.
• Aplicar las medidas técnicas y organizativas del Anexo III.
• Respetar las condiciones de subcontratación del apartado 5 (Anexo II).
• Asistir al Responsable, en la medida de lo posible y mediante medidas técnicas y organizativas apropiadas, en el cumplimiento de su obligación de responder a las solicitudes de ejercicio de derechos de los interesados.
• Asistir al Responsable a garantizar el cumplimiento de las obligaciones de los artículos 32 a 36 del RGPD (seguridad, brechas, evaluaciones de impacto, consultas previas).
• A elección del Responsable, suprimir o devolver todos los datos personales una vez finalice la prestación, y suprimir las copias existentes salvo que la legislación aplicable obligue a conservarlas.
• Poner a disposición del Responsable toda la información necesaria para demostrar el cumplimiento de las obligaciones del art. 28, así como permitir y contribuir a auditorías conforme al apartado 7.
• Notificar sin demora al Responsable cuando, en su opinión, una instrucción infrinja el RGPD u otra normativa de protección de datos.

5. Anexo II, Subcontratación

El Responsable autoriza con carácter general la subcontratación de los subencargados publicados en /es/subprocessors/. La lista pública se considera incorporada a este DPA por referencia y se actualiza conforme avance el producto. El cuadro siguiente es un resumen; en caso de discrepancia prevalece la lista pública, que es la que se mantiene al día.

5.1 Lista resumen actual

Telegram (Telegram FZ-LLC): avisos operativos internos al equipo de AIGiner, sin datos personales del Responsable ni de los Usuarios. No es subencargado.

5.2 Compromisos del Encargado respecto a los subencargados

• Notificar cualquier cambio (alta o sustitución) con un preaviso mínimo de 30 días por email a la cuenta administradora del Responsable y mediante actualización pública en la página de subencargados.
• Conceder al Responsable el derecho de oposición razonada en ese plazo. Si la oposición no puede resolverse, el Responsable podrá resolver el contrato sin penalización con efectos al final del ciclo en curso.
• Imponer a cada subencargado, mediante contrato escrito, las mismas obligaciones de protección de datos asumidas en este DPA, en particular las garantías suficientes de aplicación de medidas técnicas y organizativas apropiadas.
• Ser plenamente responsable ante el Responsable del cumplimiento por los subencargados.

6. Anexo III, Medidas de seguridad (art. 32 RGPD)

Estas son las medidas técnicas y organizativas que aplicamos, proporcionales al riesgo del tratamiento. Están descritas por lo que hacen hoy, no por lo que está previsto.

6.1 Cifrado de secretos y credenciales

• Los secretos y credenciales que el servicio guarda por cuenta del Responsable (por ejemplo, los tokens de acceso de las integraciones) se cifran en la aplicación con AES-256-GCM; cada credencial lleva su propia clave, envuelta por una clave maestra, y va atada a la empresa: copiada a otra, no se descifra.
• La clave maestra vive fuera del código y de la base de datos, en la configuración protegida del servidor. Se puede rotar sin descifrar los datos y sin parar el servicio: durante el cambio, la aplicación lee con la clave antigua y con la nueva.

6.2 Cifrado en tránsito

• TLS 1.2 como mínimo (con preferencia por TLS 1.3) y conjuntos de cifrado modernos.
• HSTS habilitado durante dos años, con preload y subdominios incluidos.
• El agente de servidor solo se comunica con la API y con el servicio de actualizaciones si el certificado lo emite una de las autoridades raíz fijadas en el agente (las de Cloudflare); se comprueba la firma de cada eslabón de la cadena y, si no casa, no envía nada. La fijación no se puede apagar en producción.

6.3 Autenticación e identidades

• Contraseñas almacenadas con función de derivación con sal (bcrypt), nunca en claro.
• Segundo factor TOTP disponible para todas las cuentas, con códigos de recuperación. El Responsable puede exigirlo a toda su empresa desde la configuración de la cuenta; en ese caso se bloquea el acceso de quien no lo tenga configurado. Quien tiene el segundo factor activado lo necesita (o entra con passkey) en toda la aplicación: en cada petición, en el canal en tiempo real, en la configuración de conectores y en la aprobación de acciones. Si la empresa lo exige a todo el equipo, se exige a todos sus miembros, también cuando entran desde otra empresa. Quien no lo tiene activado y cuya empresa no lo exige entra con contraseña.
• Tras cinco fallos, cada intento desde esa dirección se retrasa hasta 5 s, contra la fuerza bruta y la enumeración de usuarios; cinco códigos de 2FA erróneos bloquean ese factor diez minutos.
• Principio de mínimo privilegio en los accesos internos, con revocación al cesar el vínculo.

6.4 Separación entre clientes

• Cada consulta filtra por tu empresa, comprobada contra la base de datos y no contra lo que declare la petición.
• En trece áreas (consumo de modelos, facturación, aprobaciones, memoria —lectura—, ejecuciones, flujos, integraciones, recursos humanos, proyectos, soporte, facturación fiscal, plantillas de documentos y clientes, el CRM) las políticas de fila de Postgres hacen además de segunda barrera: la consulta baja de privilegios antes de ejecutarse y queda restringida a las filas de la organización del solicitante aunque la aplicación tuviera un fallo lógico. En el resto, el aislamiento lo da el filtro por empresa. Extender las políticas está pendiente.
• Concerto Local: base de datos Postgres independiente, desplegada en la infraestructura del Cliente, sin recursos compartidos con ningún otro.

6.5 Robustez frente a la manipulación de los modelos

• Batería de pruebas adversariales con cobertura del OWASP LLM Top 10 y casos propios del producto: instrucciones inyectadas directamente, inyección a través de documentos, exfiltración de datos, revelación de información sensible y otros.
• Umbral que bloquea la publicación: si menos del 95 % de los ataques queda neutralizado, la versión no sale.
• Filtro de salida diseñado para eliminar las referencias al modelo real, a las instrucciones del sistema, a la ficha de identidad del agente o a la configuración interna.
• Refuerzo en las instrucciones del sistema para tratar el contenido externo como material a procesar, nunca como órdenes a ejecutar.

6.6 Endurecimiento de la aplicación web

• HSTS, prohibición de incrustar el sitio en marcos ajenos y bloqueo de la interpretación de tipos de contenido distintos del declarado.
• Política de seguridad de contenido con origen propio por defecto y lista explícita de excepciones. El bloqueo de los scripts en línea está pendiente por una limitación del proveedor de red, que inyecta en el borde un script con testigo aleatorio que no admite huella.
• Permisos del navegador restringidos: geolocalización y cámara desactivadas; el micrófono solo se habilita en la aplicación y a petición del usuario.
• Cookies de sesión con las marcas Secure, HttpOnly y SameSite.

6.7 Registros, auditoría y trazabilidad

• Registro de ejecuciones de agente, con identificador, agente, alias del modelo, huella del prompt, tokens consumidos, latencia, modo de ahorro y resultado.
• Registro de auditoría separado para los eventos administrativos (cambios en la ficha de identidad de un agente, accesos a producción, cambios de configuración), en el que la base de datos solo permite añadir líneas (modificar, borrar o vaciar el registro se rechaza, también para la propia aplicación), encadenado con SHA-256 y verificable desde la aplicación, que detecta la alteración de un registro intermedio. Además, cada hora se guarda una copia firmada de la última línea de la cadena de cada empresa en un almacenamiento con bloqueo de borrado de 30 días, fuera de la base de datos, y cada día se comprueba que la base coincide con esas copias, de modo que una reescritura del registro por quien tenga privilegios máximos sobre la base se detectaría.
• Aprobaciones humanas registradas con la identidad de quien aprueba y la marca de tiempo.
• Borrado automático por antigüedad: está encendido. El propietario de cada empresa elige en Ajustes el plazo de conservación de las conversaciones y las ejecuciones (30, 60, 90, 180 o 365 días; 90 por defecto) y cada noche se borra lo que lo supera. Los registros técnicos se borran a los 90 días. No se borran nunca por antigüedad el registro de auditoría, la facturación (6 años, art. 30 del Código de Comercio), la memoria (la borra el Cliente) ni la configuración; todo ello se suprime a la finalización del contrato, según el apartado 11 de este DPA (Devolución y eliminación de datos al final). Las copias de seguridad conservan los datos hasta que caducan (35 días).

6.8 Copias de seguridad y continuidad

• Cuatro copias diarias de la base de datos, cifradas (AES-256, GPG) y fuera del servidor, conservadas 35 días con bloqueo de borrado de 30 días.
• Una restauración real de prueba cada semana.
• Los ficheros adjuntos aún no tienen copia propia.
• Vigilancia diaria de que la copia se ha hecho y de que ha salido del servidor, con aviso si falla cualquiera de las dos cosas.

6.9 Gestión de claves

• La clave maestra vive fuera del código y de la base de datos, en la configuración protegida del servidor.
• La clave maestra se puede rotar sin descifrar los datos y sin parar el servicio: durante el cambio, la aplicación lee con la clave antigua y con la nueva.
• Copias de seguridad: se cifran con AES-256 antes de salir del servidor. La clave de cifrado se conserva en el propio servidor, porque el cifrado nocturno y los simulacros automáticos de restauración la necesitan; por eso la custodia de estas claves no está separada de la infraestructura productiva. Se guarda además una copia de la clave fuera del servidor, en el almacén cifrado de secretos de la empresa.
• El acceso a las claves está restringido a los operadores autorizados de AIGiner.

6.10 Personas y proceso

• Quienes acceden a producción están obligados a confidencialidad por contrato o, como administradores, por el art. 228.b LSC.
• Dos personas de AIGiner administran la plataforma y tienen acceso técnico a la base de datos, incluida la memoria de los Usuarios; solo acceden para soporte, incidencias u obligación legal, sujetas a confidencialidad.
• Revocación de credenciales al terminar el vínculo laboral o contractual.
• Procedimiento documentado de gestión de brechas, con la plantilla de notificación del apartado 10.

6.11 Agentes con acceso a equipos y servidores

• Exclusiones de acceso: AIGiner ha configurado los agentes de escritorio para que no accedan a almacenes de contraseñas ni llaveros del sistema (Credential Manager y DPAPI de Windows, Llavero de macOS, gnome-keyring, KWallet), a las cookies ni a las credenciales guardadas del navegador, ni a claves privadas SSH o GPG. Los agentes de servidor no leen /etc/shadow, claves privadas ni secretos de Docker.
• Cambios en servidores con aprobación: ningún cambio en un servidor (reiniciar, instalar, editar) se ejecuta sin la aprobación de un administrador del Responsable en Shara. Se ejecuta con el comando exacto aprobado, con privilegios de administrador del sistema (root) mediante systemd-run, y queda auditado en el registro de auditoría del apartado 6.7.
• Recuperación y confirmaciones: lo que el agente de escritorio borra con sus propias herramientas va a la Papelera del sistema; eso no alcanza a lo que borre un programa o script que el agente ejecute. Escribir accesos directos del sistema (.lnk, .url, .scf, desktop.ini) y leer el portapapeles requieren la confirmación del Usuario.
• Registro de actividad: cada acción de un agente (qué, cuándo y con qué resultado) queda anotada en un registro visible para el Responsable en la aplicación.
• Ámbito personal: el escritorio sobre el que actúa un agente es siempre el de la persona que habla con él.
• Alcance de estas medidas: son controles del software de AIGiner. No sustituyen los permisos del sistema operativo ni las políticas de seguridad del Responsable (cuentas con el mínimo privilegio, copias de seguridad, custodia separada de secretos), que el Responsable mantiene bajo su responsabilidad.

7. Auditorías

Antes de enumerar las vías, un dato que el Responsable necesita para elegir la suya: AIGiner S.L. no dispone de certificación ISO/IEC 27001, ISO/IEC 27701 ni de informes SOC 2 Tipo I o II, y no se encuentra en proceso de certificación a la fecha de este documento. Si algún día los obtiene, se anunciarán en esta página y podrán aportarse como evidencia. Mientras tanto, el derecho de auditoría se ejerce por las dos vías restantes.

• Mediante cuestionarios de seguridad razonables, que respondemos con la evidencia técnica correspondiente.
• Mediante auditoría remota o in situ, una vez al año, previo preaviso de 30 días, durante horario laboral, con coste a cargo del Responsable y firma de acuerdo de confidencialidad. Tras una brecha confirmada, la frecuencia no está limitada y el coste se reparte entre las partes en función de su cuota de responsabilidad. La frecuencia podrá incrementarse también si una autoridad de protección de datos lo requiere.
• Mediante la entrega de informes o certificaciones independientes cuando lleguen a existir, sin que su ausencia limite las dos vías anteriores.

8. Dónde se trata cada cosa

El contenido del Cliente que procesan los agentes se trata dentro de la Unión Europea: la base de datos y los servidores de aplicación (Contabo, Lauterbourg, Francia), la autenticación (Supabase, Irlanda · eu-west-1) y la inferencia y transcripción de voz (TensorX Ltd., en centros de datos en la UE: Irlanda y Finlandia). No existe transferencia internacional de los prompts, de las respuestas del modelo ni de las grabaciones de voz. La relación con TensorX se rige por un contrato de encargo (art. 28 RGPD); TensorX no almacena ni registra el contenido de las peticiones ni lo usa para entrenar.

Una salvedad, que es la del operador de IA: cuando AIGiner administra sus sistemas con Claude Code (Anthropic), las salidas de los servidores y de los almacenes de secretos que el operador consulta viajan a Anthropic y pueden contener, de forma incidental, datos del Cliente. La configuración del entrenamiento con esos datos en la cuenta de AIGiner está pendiente de confirmar.

Tres tratamientos accesorios sí implican tratamiento fuera de la UE, y el Responsable debe conocerlos: el correo transaccional del servicio, que se envía a través de Resend desde Estados Unidos y que incluye el nombre y la dirección del destinatario y el contenido del aviso; los metadatos de tráfico que trata Cloudflare en su red global, que además actúa como proxy TLS y ve el contenido en tránsito; y los datos de pago en Stripe, en Irlanda y Estados Unidos. Los tres se amparan en las Cláusulas Contractuales Tipo de la Comisión Europea (Decisión 2021/914) y en el DPA o las condiciones de cada proveedor.

8.1 Concerto Local

Cuando el Responsable contrata Concerto Local, el Servicio se despliega en su infraestructura: la base de datos y el modelo Concerto se ejecutan en sus propios servidores y AIGiner no accede a ese contenido en el curso normal de la prestación. El tratamiento como Encargado se limita, en ese caso, a los datos de cuenta y licencia y a las tareas que el Responsable delegue expresamente a la cuota de orquestación en la nube, que es una opción que él activa y desactiva.

El soporte que requiera acceso a la instalación del Responsable se presta únicamente a petición suya, con el alcance que él autorice y dejando registro del acceso.

9. Asistencia al Responsable (arts. 32-36 RGPD)

El Encargado prestará al Responsable la asistencia razonablemente necesaria para cumplir sus obligaciones, en particular:

• Art. 32 (Seguridad): aplicación y demostración de las medidas del Anexo III; respuesta a cuestionarios; revisión conjunta tras cambios materiales.
• Art. 33 (Notificación a la autoridad): comunicación al Responsable sin demora indebida y, en todo caso, dentro de las 48 horas siguientes a la detección, para que disponga de margen sobre el plazo que el Reglamento le concede frente a la autoridad. Plantilla de información mínima en el apartado 10.
• Art. 34 (Notificación al interesado): provisión de la información necesaria para que el Responsable evalúe la obligación y, si decide notificar, redacte la comunicación.
• Art. 35 (Evaluación de impacto): información sobre la naturaleza del tratamiento, medidas y riesgos a petición del Responsable, en plazo razonable, incluida la relativa al despliegue de agentes con acceso a equipos y servidores.
• Art. 36 (Consulta previa): asistencia documental cuando el Responsable deba consultar a la autoridad de control.

Las solicitudes formales del Responsable dirigidas a dpo@aiginer.com se atienden sin dilación indebida, para que el Responsable pueda contestar en plazo.

10. Notificación de brechas (art. 33 RGPD)

En caso de brecha de seguridad que afecte a datos del Responsable, el Encargado lo notificará sin demora indebida y, a más tardar, en 48 horas desde su detección. La comunicación inicial incluirá, como mínimo, la siguiente plantilla:

Si no fuera posible facilitar toda la información en el plazo inicial, se hará de forma escalonada documentando las razones.

11. Devolución y eliminación de datos al final

• El Responsable dispone de 30 días naturales tras la terminación para exportar los datos en formato estructurado (un .zip con un fichero NDJSON por tabla y un manifest.json, desde Ajustes; en CSV, a petición).
• A petición motivada, el plazo puede ampliarse 30 días adicionales.
• Transcurrido el plazo, el Encargado eliminará todos los datos del Responsable de su entorno productivo y, por la rotación natural de las copias de seguridad, de éstas en un máximo de 60 días adicionales (las copias se conservan 35 días), salvo obligación legal de conservación.
• Antes de suprimir, el Encargado cancela la suscripción y los cobros pendientes. Tras la exportación, suprime los datos de la empresa y entrega al Responsable un certificado de supresión firmado.
• Solo se conserva lo que la ley obliga a guardar: la facturación, durante 6 años (art. 30 del Código de Comercio). Las copias de seguridad conservan los datos hasta que caducan, a los 35 días.

12. Régimen de incumplimiento

El incumplimiento por el Encargado de sus obligaciones no exime al Responsable de las suyas propias. Cada parte responde frente a las autoridades de control de las infracciones que le sean imputables, sin que las sanciones administrativas puedan trasladarse contractualmente. Respecto de las indemnizaciones a interesados, se aplica el artículo 82 del RGPD, incluida la acción de regreso de su apartado 5 en función de la cuota de responsabilidad de cada parte en el daño causado.

13. Disposiciones finales

Para cualquier cuestión sobre este DPA, escribe a dpo@aiginer.com.

• Este DPA se rige por la ley española y las normas imperativas del RGPD.
• La nulidad parcial de alguna cláusula no afecta a la validez del resto.
• El idioma prevalente del DPA es el español; las versiones en otros idiomas son meras traducciones de cortesía.