Contrato de encargo del tratamiento

Artículo 28 del Reglamento (UE) 2016/679 (RGPD)

Versión 1.5 · Redactado el 29/08/2026 · Vigente desde el 14/09/2026

Partes

EL RESPONSABLE DEL TRATAMIENTO (en adelante, «el Responsable»)

La empresa cliente que contrata el servicio Aportalia y gestiona un buzón de propuestas. Sus datos identificativos se recogen en el alta y se incorporan a este contrato:

EL ENCARGADO DEL TRATAMIENTO (en adelante, «el Encargado»)

Expositivo

1. El Responsable gestiona un buzón interno de propuestas de mejora dirigido a las personas que trabajan en su organización.
2. El Encargado presta el servicio técnico que soporta ese buzón: recogida de propuestas, transcripción de las enviadas por voz, anonimización de las enviadas de forma anónima, elaboración del informe periódico y conservación de los resultados.
3. En esa prestación el Encargado trata datos personales por cuenta del Responsable, lo que exige el contrato del artículo 28.3 del RGPD. Este documento lo es.

Cláusulas

1. Objeto y alcance

El Encargado tratará los datos personales descritos en el Anexo I únicamente para prestar el servicio Aportalia al Responsable, durante la vigencia de la relación de servicio y con la finalidad allí descrita.

El Encargado no tratará esos datos para finalidades propias. En particular, y sin que la enumeración sea limitativa: no los cederá a terceros salvo a los subencargados del Anexo II, no los usará para elaborar perfiles comerciales, y no los usará para entrenar modelos de inteligencia artificial propios ni de terceros.

2. Instrucciones del Responsable

El Encargado tratará los datos siguiendo únicamente instrucciones documentadas del Responsable, incluidas las relativas a transferencias internacionales. Se consideran instrucciones documentadas este contrato, la configuración que el Responsable establezca en su panel y cualquier indicación escrita posterior.

El Encargado informará al Responsable si, en su opinión, una instrucción infringe el RGPD o cualquier otra norma de protección de datos, y podrá suspender su ejecución hasta que el Responsable la confirme o la corrija.

3. Confidencialidad

El Encargado garantiza que las personas autorizadas para tratar los datos se han comprometido a respetar la confidencialidad, o están sujetas a una obligación de confidencialidad de naturaleza legal.

A fecha de este contrato, la única persona con acceso a los datos por parte del Encargado es su titular. Cualquier incorporación se comunicará al Responsable.

4. Seguridad del tratamiento (art. 32)

El Encargado aplicará las medidas técnicas y organizativas descritas en el Anexo III, apropiadas al riesgo. El Anexo III describe lo que está implantado a la fecha, no un catálogo aspiracional: las carencias conocidas figuran también allí, declaradas.

5. Subencargados

El Responsable autoriza de forma general al Encargado a recurrir a los subencargados relacionados en el Anexo II, con los que el Encargado tiene suscrito un contrato que le impone las mismas obligaciones de protección de datos que las de este documento.

El Encargado informará al Responsable de cualquier alta o sustitución de subencargado con una antelación mínima de treinta (30) días naturales, dándole la oportunidad de oponerse. Si el Responsable se opone motivadamente y el cambio es imprescindible para prestar el servicio, cualquiera de las partes podrá resolver el contrato sin penalización.

El Encargado sigue siendo plenamente responsable ante el Responsable del cumplimiento por parte de sus subencargados.

6. Derechos de los interesados

El Encargado asistirá al Responsable, mediante medidas técnicas y organizativas apropiadas, para atender las solicitudes de ejercicio de los derechos de acceso, rectificación, supresión, limitación, portabilidad y oposición.

Si un interesado dirige una solicitud directamente al Encargado, este la remitirá al Responsable sin dilación indebida y no responderá al fondo por su cuenta.

Límite estructural del que ambas partes quedan advertidas. El servicio permite enviar propuestas anónimas: el texto original se sustituye por una versión anonimizada y el original se elimina, sin que quede vínculo alguno con la identidad de quien la envió. Sobre una propuesta anónima ya procesada no es materialmente posible identificar al interesado ni, por tanto, atender un derecho de acceso o supresión referido a ella. Esto no es una limitación del esfuerzo del Encargado: es la propiedad que hace que el canal funcione, y opera a favor del interesado. El Responsable debe reflejarlo en su información a las personas trabajadoras.

7. Asistencia en materia de cumplimiento

El Encargado asistirá al Responsable, teniendo en cuenta la naturaleza del tratamiento y la información de la que disponga, en el cumplimiento de las obligaciones de los artículos 32 a 36 del RGPD: seguridad, notificación de brechas, evaluación de impacto y consulta previa.

8. Violaciones de la seguridad

El Encargado notificará al Responsable sin dilación indebida y, en todo caso, dentro de las 48 horas siguientes a tener conocimiento de una violación de la seguridad de los datos personales, por el canal de contacto que el Responsable haya designado.

La notificación incluirá, en la medida en que se conozca: naturaleza de la violación, categorías y número aproximado de interesados y de registros afectados, consecuencias probables y medidas adoptadas o propuestas. Si la información no está disponible de una vez, se facilitará de forma escalonada sin más dilación.

Corresponde al Responsable decidir sobre la notificación a la autoridad de control y a los interesados.

9. Destino de los datos al finalizar

A la terminación del contrato, y a elección del Responsable manifestada por escrito dentro de los treinta (30) días siguientes, el Encargado devolverá los datos en un formato estructurado y de uso común, o los suprimirá, incluidas las copias existentes.

Transcurrido ese plazo sin instrucción, el Encargado procederá a la supresión. Conservará únicamente aquello que le imponga una obligación legal, y solo durante el plazo de esa obligación.

10. Información y auditoría

El Encargado pondrá a disposición del Responsable la información necesaria para demostrar el cumplimiento de este contrato y permitirá y contribuirá a la realización de auditorías, incluidas inspecciones, por el Responsable o un auditor por él designado, con preaviso razonable y sin perturbar desproporcionadamente el servicio.

11. Transferencias internacionales

Los datos se alojan dentro de la Unión Europea. La base de datos y el almacenamiento residen en la región eu-west-1 (Irlanda) y el envío de correo se presta desde la Unión Europea.

Dos subencargados tratan datos fuera del Espacio Económico Europeo. En ambos casos la transferencia se ampara en las cláusulas contractuales tipo adoptadas por la Decisión de Ejecución (UE) 2021/914 de la Comisión, incorporadas al contrato estándar de cada proveedor:

Matiz que conviene no perder de vista. Que los datos residan en la Unión no convierte al proveedor en europeo: tanto Supabase como Brevo se contratan con entidades que pueden operar desde fuera del EEE para soporte. El DPA de cada uno —y las cláusulas tipo que incorpora— sigue siendo la cobertura de esos accesos. Queda como punto a confirmar con la revisión jurídica, no como afirmación de este documento.

12. Duración

Este contrato entra en vigor con la aceptación del Responsable y permanece vigente mientras dure la prestación del servicio, extendiéndose sus obligaciones de confidencialidad y de destino de los datos más allá de su terminación.

13. Responsabilidad

Cada parte responde de los daños que cause por incumplimiento de las obligaciones que el RGPD le impone específicamente, en los términos del artículo 82. Ninguna cláusula de este contrato excluye o limita la responsabilidad frente a los interesados ni frente a las autoridades de control.

14. Ley aplicable y jurisdicción

Este contrato se rige por el RGPD, por la Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales, y por el Derecho español. Las partes se someten a los juzgados y tribunales del domicilio del Responsable.

Anexo I — Descripción del tratamiento

Objeto: prestación del servicio Aportalia, un buzón de propuestas de mejora con respuesta razonada.

Naturaleza de las operaciones: recogida, registro, transcripción de voz a texto, anonimización de textos anónimos, análisis y elaboración de informe, conservación, comunicación al Responsable y supresión.

Finalidad: gestionar las propuestas del personal del Responsable, elaborar el informe periódico y hacer llegar a cada persona una respuesta razonada.

Duración: la de la relación de servicio.

Categorías de interesados: personas empleadas del Responsable y demás personas a las que el Responsable facilite el acceso a su buzón.

Categorías de datos personales:

No se tratan categorías especiales de datos del artículo 9 de forma deliberada. El servicio no las solicita. Puede ocurrir que una persona las introduzca por iniciativa propia en el texto libre de una propuesta; la anonimización de las anónimas reduce ese riesgo, pero no lo elimina en las identificadas. El Responsable debe tenerlo presente en su información al personal.

Plazo de conservación: el que fije el Responsable, por defecto 24 meses desde el cierre del ciclo. Superado el plazo se eliminan el nombre y el correo asociados y el texto se sustituye por un dato agregado.

Flujo del dato en una propuesta anónima

Es el recorrido que más importa de todo este anexo, porque de él depende la promesa que se le hace a la persona que escribe.

1. El texto llega al servidor y se guarda en una tabla de tránsito aislada (anonimas_pendientes), que el Responsable no puede leer en ningún momento: no hay política de acceso que se lo permita, ni pantalla, ni endpoint, ni informe que lo exponga.
2. Cada 15 minutos, un proceso que corre en la infraestructura del Encargado reescribe el texto en tono neutro con un modelo de lenguaje local. El texto original no sale de esa máquina.
3. El texto ya anonimizado se guarda en la tabla que el Responsable sí ve (propuestas) y la fila de tránsito se borra en la misma transacción.
4. Solo a partir de aquí, y solo con el texto ya anonimizado, interviene el análisis mensual que elabora el informe. El subencargado de inteligencia artificial (Anthropic) recibe únicamente texto ya anonimizado, nunca el original.

Si la anonimización no supera su verificación automática, la propuesta no se publica. Se reintenta hasta tres veces con estrategias distintas y, si tampoco entonces se consigue, el texto original se elimina de forma verificada: no se publica, no se conserva y nadie llega a leerlo. Solo queda un recuento sin contenido, para que el equipo pueda ver cuántas propuestas se descartaron por esta razón.

Esa eliminación ocurre dentro de la misma ventana de minutos que el resto del flujo. El texto original de una propuesta anónima o se convierte en una versión anonimizada, o se destruye; en ningún caso permanece ni llega a un tercero.

Estado a 29/08/2026. Los puntos 1, 3 y 4 son ciertos hoy. El punto 2 lo será cuando esté corriendo la anonimización local decidida el 29/08: hasta entonces el texto original pasa por Anthropic, por lo que este contrato no se puede ofrecer todavía. Ver docs/decisiones/2026-08-29-anonimizacion-local.md.

Anexo II — Subencargados autorizados

Inventario verificado el 29/08/2026 sobre la máquina y el entorno reales, no sobre lo que el código podría usar. Stripe se añade el 09/09/2026, verificado igual que los demás (ver más abajo).

Lo que NO es subencargado, y conviene que conste

• OpenAI — no interviene. La transcripción de los audios se hace con un modelo Whisper que corre en la máquina del Encargado. No sale audio ni texto hacia OpenAI. La clave de API existe en el código como posibilidad y está vacía. Si algún día se activara, sería un alta de subencargado sujeta al preaviso de treinta días de la cláusula 5, y su cobertura de transferencia serían las cláusulas tipo incorporadas a su Data Processing Addendum (https://openai.com/policies/data-processing-addendum/), con OpenAI Ireland Limited como entidad contratante en el EEE.
• Resend — retirado. Fue emisor de correo y ya no lo es (docs/decisiones/2026-08-28-resend-retirado.md). Su clave está vacía.

Stripe: qué ve exactamente, y qué no

Ninguna propuesta pasa por Stripe. Ni el texto, ni el audio, ni el informe, ni el tablón. La separación no es una promesa de configuración: es que el código que habla con Stripe (lib/facturacion/) no tiene acceso a esas tablas y el único dato de negocio que le envía es una cantidad —cuántas personas tienen acceso al buzón— que es un número, no una persona.

Lo que Stripe sí trata son los datos de facturación de quien gestiona el buzón: su nombre, su correo, el NIF y la dirección fiscal de la empresa, y el medio de pago. Los datos de la tarjeta los recoge y almacena Stripe directamente; Aportalia no los ve ni los guarda en ningún momento.

Y no antes de que haya tarjeta. Durante el ciclo de prueba gratuito no se comunica a Stripe absolutamente nada: quien prueba Aportalia y decide no continuar no llega a existir para Stripe. Es minimización por diseño, no por configuración (decisión del 09/09/2026).

Verificación (09/09/2026), con el mismo criterio que los demás:

• Entidad contratante en el EEE: Stripe Payments Europe, Limited (SPEL), Irlanda. Es la entidad con la que contrata una cuenta situada en España, según el acuerdo de servicios de Stripe.
• DPA: Stripe Data Processing Agreement, última actualización 18/11/2025 (https://stripe.com/legal/dpa). Incluye su anexo de transferencias, con las cláusulas contractuales tipo del EEE para los casos en que Stripe transfiera datos fuera del Espacio Económico Europeo.
• Ubicación declarada: Irlanda, dentro de la UE, igual que Supabase.

Por qué entra ahora y no cuando se decidió Stripe. La decisión del 29/08/2026 dejó escrito que Stripe entraría en este anexo «cuando el modo producción se active», con el argumento de que en modo test no hay datos reales de nadie. Se adelanta a la construcción por una razón práctica: el anexo tiene que estar bien el día que se cobre el primer euro, no el día después, y un documento que se actualiza en el mismo movimiento que el interruptor es un documento que alguien se deja sin actualizar.

Por qué esta tabla dice lo que dice, y por qué antes decía otra cosa

Hasta el 29/08/2026 el texto original de las propuestas anónimas pasaba por Anthropic. No a través de la aplicación —cuya clave de API está vacía— sino del proceso de anonimización, que se ejecutaba invocando un modelo remoto.

Se detectó precisamente al redactar este anexo, y llevó a una decisión: la anonimización pasa a ejecutarse con un modelo local, de modo que el texto original no salga de la máquina del Encargado y Anthropic quede reservado al informe mensual sobre texto ya anonimizado.

Queda escrito aquí porque un anexo de subencargados que no explica por qué es como es no permite comprobar si sigue siendo verdad dentro de seis meses.

Anexo III — Medidas técnicas y organizativas

Lo implantado a 29/08/2026. Las carencias van declaradas al final: un anexo de seguridad que solo cuenta lo bueno no sirve para lo que existe.

Control de acceso

• El acceso a la base de datos desde la aplicación usa una clave secreta que solo existe en el servidor; el navegador nunca la ve. Un guardián en tiempo de compilación (server-only) hace fallar la construcción si alguien importa ese cliente en código de cliente.
• Row Level Security activa sobre las tablas, con las tablas de tránsito sin ninguna política que las abra al Responsable ni al público.
• Cada empresa ve exclusivamente su propio buzón.

Minimización y retención

• La grabación de voz se elimina en la misma operación en que se transcribe.
• El texto original de una propuesta anónima se elimina en la misma transacción en que se guarda su versión anonimizada, cada 15 minutos.
• El texto original nunca se escribe en disco: viaja por una tubería entre procesos.
• Purga automática al cumplirse el plazo de retención.

Cifrado

• Todo el tráfico viaja por HTTPS.

• Cifrado en reposo, el que proporciona Supabase, y está documentado:

  • «All hard disks are encrypted-at-rest using the industry-standard AES-256 algorithm. Similarly, the regularly scheduled backups are also encrypted-at-rest using AES-256.»
  • «The encryption keys are protected by keys stored using FIPS 140-2 compliant HSMs.»
  • «All network communication is conducted over encrypted links protected by modern security standards (TLS 1.2, modern cipher suites).»
  • «All backups are encrypted-in-transit and at-rest.»

  Fuente: Schedule 1 (medidas técnicas y organizativas) del Data Processing Addendum de Supabase, versión 1 de 01/08/2026 — https://supabase.com/legal/customer-resources/data-processing-addendum. Confirmado también, en resumen, en su página de seguridad: «All customer data is encrypted at rest with AES-256 and in transit via TLS» (https://supabase.com/security). Verificado el 01/09/2026.

  Se cita el DPA y no el panel de control a propósito. Lo que se promete en este anexo tiene que poder sostenerse frente a un Responsable que pregunte, y una casilla del panel no es un compromiso: el Schedule 1 del DPA sí, porque es parte del contrato que Supabase tiene firmado con el Encargado. Un anexo de seguridad que se apoya en lo que alguien vio una vez en una pantalla no es verificable dentro de seis meses; una cláusula contractual con fecha y versión, sí.

Supervisión

• Vigilancia horaria automática del estado del servicio, con doble disparador independiente (GitHub Actions y la máquina del Encargado), que avisa por correo si el procesado deja de drenar la cola.
• La vigilancia distingue «no hay problema» de «no he podido comprobarlo» y grita en el segundo caso. Es la lección de un incidente propio, documentado en docs/decisiones/2026-08-27-vigilancia-no-pude-leer.md.

Carencias declaradas

Se declaran porque un Responsable diligente las preguntaría, y porque ocultarlas convertiría este anexo en una declaración falsa:

1. Parte del procesado corre en una máquina doméstica. La anonimización y la transcripción se ejecutan en un ordenador del titular, no en un centro de datos. Los datos en tránsito por ella lo están de forma efímera —minutos—, pero es una máquina doméstica y así consta. Esta es, además, la contrapartida de la decisión de anonimizar en local: el dato deja de salir a un tercero y a cambio depende de una máquina de casa.
2. No hay certificación de seguridad de terceros (ISO 27001, ENS ni equivalente).
3. No hay más de una persona con acceso. Esto es bueno para la confidencialidad y malo para la continuidad, y ambas cosas son ciertas.
4. Incidente abierto a la fecha. Desde el 27/08/2026 se observan fallos intermitentes de lectura contra la base de datos (PGRST303, capa de autenticación) que dejan a la vigilancia ciega durante intervalos cortos. No hay pérdida ni exposición de datos conocida; el efecto es de supervisión. Instrumentado y en seguimiento.

Control de versiones

Cada empresa que acepte este contrato queda vinculada a la versión concreta que aceptó, con sello de tiempo. Un cambio de versión que altere derechos u obligaciones exige nueva aceptación.