Contrato de encargo del tratamiento de datos

Última actualización: 5 de octubre de 2026

Versión v2026-10-05

Partes

• El Responsable: la tienda que contrata Parlo, identificada en el alta. Acepta este contrato quien tenga poder para obligarla, al aceptar los Términos del servicio.
• El Encargado: The Wise Brands LLC, sociedad de responsabilidad limitada de Estados Unidos, con domicilio postal en 11820 Miramar Pkwy, Unit 204, Miramar, FL 33025 (Estados Unidos), EIN 98-1896488, contacto info@parlodesk.com, que presta el servicio Parlo.

Este contrato forma parte de los Términos del servicio de Parlo. Regula el tratamiento de datos personales que el Encargado hace por cuenta del Responsable, conforme al artículo 28 del Reglamento (UE) 2016/679 (RGPD) y, en lo que aplique, a la Ley Orgánica 3/2018. En lo que toca a datos personales, este contrato manda sobre los Términos y sobre cualquier otro acuerdo entre las partes.

1. Objeto

El Encargado trata los datos personales descritos en el Anexo I solo para prestar al Responsable el servicio Parlo: leer el buzón de atención al cliente que el Responsable conecte, entender cada correo, cruzarlo con el pedido de su tienda de Shopify, consultar al transportista el estado del envío y preparar borradores de respuesta que una persona del Responsable revisa y envía desde su propio buzón. Si el Responsable elige un modo automático, el Encargado también envía desde ese buzón, sin revisión de una persona, las respuestas que permitan el modo elegido y las comprobaciones del servicio (Anexo II). Si el Responsable abre el portal de sus clientes, el Encargado atiende las consultas que esos clientes hacen en él sobre su pedido y, si el Responsable lo enciende, cambia en su tienda de Shopify, a petición del cliente y después de enviarle desde el buzón del Responsable un código de verificación al correo del pedido, la dirección de envío de un pedido que no ha salido (Anexo II).

2. Duración

Este contrato empieza el día en que el Responsable lo acepta, antes de cualquier tratamiento, y cubre también la prueba previa al alta si el Responsable la autoriza (cláusula 3.2). Dura mientras el Encargado trate datos por cuenta del Responsable y, después, el tiempo necesario para cumplir la cláusula 10 (fin del servicio). Si tras la prueba previa el Responsable no se suscribe, el Encargado borra los datos de la prueba en cuanto termina y se lo confirma por escrito.

3. Instrucciones del Responsable

3.1. El Encargado trata los datos solo siguiendo instrucciones documentadas del Responsable, incluidas las que afectan a transferencias a terceros países. Son instrucciones del Responsable: este contrato, los Términos, y la configuración que el Responsable hace en Parlo (buzón conectado, ajustes, modo de respuesta y situaciones que pueden salir solas, temas que pasan siempre a una persona, funciones que activa o desactiva y propuestas que aprueba). Los cambios del modo de respuesta quedan registrados con quién los hizo y cuándo, y ese registro no se puede cambiar ni borrar mientras exista la tienda. El Encargado solo puede cambiar el modo por su cuenta para volver a «Borrador», si un correo del Responsable rebota de forma permanente o alguien lo marca como spam, al darse de baja la tienda, o al restaurar una copia de seguridad de la base de datos, que deja todas las tiendas en «Borrador», y lo registra con el motivo.

3.2. Las funciones opcionales que tratan más datos solo se usan si el Responsable las activa o lo autoriza por escrito:

• «Aprender de cómo contestas», que viene apagada.
• El análisis del historial del buzón, que se pide expresamente para 3, 6 o 12 meses, o, con autorización escrita, desde una exportación del buzón que entrega el Responsable.
• La prueba previa al alta con correos anteriores del buzón, que solo se hace con autorización escrita previa y con este contrato ya aceptado.
• La tarjeta del equipo de la analítica, que enseña a quien lleva la tienda los datos de trabajo de cada persona de su equipo (Anexo I).
• Los avisos y el informe semanal a un canal de Slack del Responsable, sin datos de sus clientes.
• Los modos «Automático por temas» y «Automático», que envían respuestas sin revisión de una persona (cláusula 1 y Anexo II).
• La valoración de las respuestas por el cliente, que se añade al pie de las respuestas.
• El portal donde los clientes del Responsable miran su pedido y piden un cambio de dirección o una devolución, y el enlace a ese portal al pie de las respuestas (Anexo I y Anexo II).
• Dentro del portal, cada una por separado: el cambio de la dirección de envío en Shopify, con o sin el visto bueno previo del Responsable, y la petición de reembolso de un pedido enviado, que solo llega al Responsable. Encenderlas es la instrucción del Responsable; la del cliente, pedirlo desde el portal: sin las dos, no se escribe nada. Desde el portal no se puede cancelar un pedido.

3.3. Si el Encargado cree que una instrucción infringe el RGPD u otra norma de protección de datos, se lo dirá de inmediato al Responsable.

3.4. Si el Derecho de la Unión o de un Estado miembro al que esté sujeto el Encargado le obliga a tratar los datos de otra forma, se lo dirá antes al Responsable, salvo que ese Derecho lo prohíba por razones importantes de interés público.

4. Uso de los datos solo para el Responsable

4.1. El Encargado no usa los datos para fines propios ni para prestar servicio a otros clientes. En particular, no los usa para entrenar ni ajustar modelos de inteligencia artificial, y lo que el servicio aprende de un Responsable solo se usa para ese Responsable.

4.2. El Encargado no vende ni comunica los datos a terceros, salvo a los encargados ulteriores de la cláusula 7 o cuando le obligue el Derecho de la Unión o de un Estado miembro al que esté sujeto.

5. Confidencialidad

El Encargado garantiza que las personas autorizadas a tratar los datos se han comprometido a respetar su confidencialidad o están sujetas a una obligación legal de confidencialidad. Solo acceden a los datos las personas que lo necesitan para prestar el servicio, darle soporte o mantenerlo.

6. Seguridad

6.1. El Encargado aplica las medidas técnicas y organizativas del Anexo II, apropiadas al riesgo según el artículo 32 del RGPD.

6.2. El Encargado puede mejorar esas medidas. No puede rebajar el nivel de protección sin avisar antes al Responsable.

7. Encargados ulteriores

7.1. El Responsable da su autorización general para que el Encargado recurra a los encargados ulteriores del Anexo III, que es la lista vigente en la fecha en que el Responsable acepta este contrato. Los cambios posteriores siguen la cláusula 7.2. La página de encargados del tratamiento de Parlo es informativa.

7.2. Antes de añadir o sustituir un encargado ulterior, el Encargado avisará al Responsable por correo con al menos 30 días de antelación, diciendo quién es, qué hará, qué datos recibirá, dónde y con qué garantía. El Responsable puede oponerse por motivos razonables de protección de datos dentro de ese plazo. Si las partes no encuentran una solución, el Responsable puede terminar el servicio sin penalización y con devolución de la parte pagada y no disfrutada.

7.3. El Encargado ha suscrito con cada encargado ulterior un contrato que le impone las mismas obligaciones de protección de datos que este contrato, en los términos del artículo 28.4 del RGPD, y sigue siendo plenamente responsable ante el Responsable de lo que ellos hagan.

8. Transferencias internacionales

8.1. Los datos se guardan en un servidor en Alemania y el modelo de inteligencia artificial se usa en la multirregión de la Unión Europea de Google, que mantiene el procesamiento dentro de la UE. El Encargado es una empresa de Estados Unidos y el servicio se administra en remoto; algunos encargados ulteriores son empresas de Estados Unidos, y Cloudflare puede tratar el tráfico en cualquier punto de su red mundial. El encargado ulterior que consulta el estado de los envíos (17TRACK) contrata a través de su empresa de Singapur (VASTAR SINGAPORE TECHNOLOGY PTE. LTD) y, según su propia política de privacidad, guarda los datos en Estados Unidos y los trata en China; Singapur y China no tienen decisión de adecuación, y la de Estados Unidos solo cubre a las empresas adheridas al Marco de Privacidad de Datos. Recibe solo los datos que indica el Anexo II; con el número de seguimiento obtiene del transportista los movimientos del envío, que pueden incluir la dirección de entrega, y los conserva hasta que el Encargado le pide que los borre. Las partes entienden que eso supone transferencias de datos fuera del Espacio Económico Europeo.

8.2. Para esas transferencias, el Encargado se apoya en las cláusulas contractuales tipo de la Comisión Europea que recogen los contratos de tratamiento de cada encargado ulterior y, cuando el encargado ulterior está adherido, en el Marco de Privacidad de Datos UE-EE. UU. La transferencia a 17TRACK se apoya en las cláusulas contractuales tipo de la Comisión Europea que recoge su contrato de tratamiento y en la evaluación de la transferencia del Encargado. El Responsable puede pedir una copia de esas garantías en info@parlodesk.com.

8.3. El Encargado no transfiere datos a terceros países distintos de los indicados en el Anexo III sin seguir el procedimiento de la cláusula 7.

8.4. Peticiones de autoridades públicas. Si una autoridad pública, de cualquier país, pide al Encargado acceso a los datos del Responsable, el Encargado: (a) se lo dirá al Responsable de inmediato, salvo que la ley se lo prohíba, y en ese caso intentará que se levante la prohibición; (b) comprobará si la petición es legal e impugnará la que, tras un examen cuidadoso, considere ilegal; (c) entregará solo el mínimo que se le exija; y (d) dejará constancia de la petición y de su respuesta, y se la facilitará al Responsable cuando pueda. 8.5. Cláusulas contractuales tipo entre el Responsable y el Encargado. Para la transferencia de los datos del Responsable al propio Encargado, empresa de Estados Unidos que administra el servicio en remoto, las partes celebran, al aceptar este contrato, las cláusulas contractuales tipo de la Comisión Europea aprobadas por la Decisión de Ejecución (UE) 2021/914, módulo dos (transferencia de responsable a encargado), que se incorporan a este contrato por referencia, con el Responsable como exportador de datos y el Encargado como importador. Para esas cláusulas: la descripción de la transferencia es la del Anexo I; las medidas técnicas y organizativas, las del Anexo II; los encargados ulteriores, los del Anexo III, con la autorización general y el aviso previo de 30 días de la cláusula 7 de este contrato (opción 2 de su cláusula 9); no se incluyen la cláusula opcional de adhesión (su cláusula 7) ni la opción de su cláusula 11; la autoridad de control competente es la que fija su cláusula 13 (si el Responsable está establecido en la Unión, la de su Estado miembro); se rigen por el Derecho español (su cláusula 17) y las controversias que deriven de ellas se someten a los tribunales de España (su cláusula 18). Si algo de este contrato contradice esas cláusulas, mandan las cláusulas.

9. Asistencia al Responsable

9.1. Derechos de las personas. Parlo no tiene relación directa con los clientes del Responsable. Si una persona se dirige al Encargado para ejercer sus derechos, el Encargado se lo pasará al Responsable en un plazo de 5 días hábiles y no contestará por su cuenta salvo que el Responsable se lo pida. El Encargado ayudará al Responsable, con los medios técnicos disponibles y en un plazo razonable, a localizar, rectificar, exportar o borrar los datos de esa persona.

9.2. Brechas de seguridad. El Encargado avisará al Responsable de cualquier violación de la seguridad que afecte a sus datos sin dilación indebida y, en todo caso, en un plazo máximo de 48 horas desde que tenga conocimiento, con la información disponible en ese momento: qué ha pasado, qué datos y cuántas personas pueden estar afectados, las consecuencias probables y las medidas tomadas o propuestas. Completará la información a medida que la tenga, y ayudará al Responsable, si lo necesita, a comunicar la brecha a la autoridad de control y a las personas afectadas.

9.3. Evaluaciones de impacto y consultas. El Encargado facilitará al Responsable la información que necesite para su evaluación de impacto y, si hace falta, para la consulta previa a la autoridad de control.

9.4. Información para los clientes del Responsable. El Encargado facilita en sus páginas públicas la descripción del servicio, de los datos que trata, del uso de inteligencia artificial y de sus encargados ulteriores, y en el Anexo IV un texto que el Responsable puede usar en su política de privacidad. Informar a esos clientes corresponde al Responsable.

10. Fin del servicio

10.1. Al terminar el servicio, a elección del Responsable, el Encargado devolverá los datos personales o los suprimirá, y borrará las copias que tenga, salvo que el Derecho de la Unión o de un Estado miembro le obligue a conservarlas. Si el Responsable no elige, se suprimen. Al terminar, el Encargado deja de leer el buzón y la tienda del Responsable y borra sus credenciales de acceso: lo hace el sistema en el acto al dar de baja la tienda. Cuando el servicio termina porque acaba la suscripción, el Encargado da la baja a mano.

10.2. Plazo: al dar de baja la tienda, el corte es en el acto; la supresión, en un máximo de 30 días desde que el Responsable la pide por escrito, y hoy se hace a mano.

10.3. Las copias de seguridad no se modifican una a una: caducan solas. Las copias de la base de datos que hace el Encargado van cifradas y se borran en un máximo de 30 días desde que se hacen; las imágenes diarias de la máquina que guarda el proveedor del servidor, a los 7 días.

10.4. El Encargado podrá conservar, debidamente bloqueados, los datos necesarios mientras puedan derivarse responsabilidades de su relación con el Responsable.

11. Información y auditorías

11.1. El Encargado pondrá a disposición del Responsable la información necesaria para demostrar que cumple este contrato y el artículo 28 del RGPD.

11.2. El Responsable puede auditar ese cumplimiento, por sí mismo o mediante un auditor sujeto a confidencialidad: primero mediante cuestionario y documentación; si no basta, una auditoría al año como máximo, con 30 días de preaviso, en horario laboral, a cargo del Responsable, salvo que la pida una autoridad o que tras una brecha haya indicios de incumplimiento.

12. Obligaciones del Responsable

El Responsable:

• Tiene una base legal para los tratamientos que encarga y ha informado a sus clientes de que usa un proveedor como Parlo, que emplea inteligencia artificial.
• Solo conecta buzones y tiendas sobre los que tiene derecho.
• Da instrucciones conformes con la ley y supervisa el tratamiento, incluida la decisión de qué temas sensibles pasan siempre a una persona.
• Mantiene la revisión humana de las respuestas en el modo «Borrador» y, si elige un modo automático, vigila lo que sale solo y lo para o vuelve a «Borrador» cuando haga falta. Decide qué modo y qué situaciones salen solas, y responde de esa decisión ante sus clientes.
• Informa a sus clientes de que algunas respuestas se envían sin revisión de una persona, si elige un modo automático.
• Informa a las personas de su equipo antes de encender la tarjeta del equipo de la analítica.

13. Responsabilidad

Cada parte responde de sus incumplimientos de este contrato y de la normativa de protección de datos.

14. Ley aplicable y tribunales

Este contrato se rige por la ley española y por el RGPD. Cualquier controversia sobre él se somete a los juzgados y tribunales de España. Esto vale aunque los Términos elijan otra ley y otros tribunales para el resto de la relación.

15. Cambios

Los cambios de este contrato se notifican al Responsable por correo y requieren su aceptación. Publicarlos en la web no basta.

Anexo I. Descripción del tratamiento

Categorías de interesados

• Clientes y posibles clientes del Responsable que escriben a su buzón de atención al cliente, usan su portal o valoran una respuesta.
• Cualquier otra persona que escriba a ese buzón: proveedores, transportistas, plataformas, remitentes de boletines o de correo personal si el buzón lo mezcla. Parlo guarda también esos correos descartados.
• Las personas del equipo del Responsable cuyas respuestas, firmas o nombres aparecen en los correos y, si el Responsable enciende la tarjeta del equipo de la analítica, cuyos datos de trabajo se le enseñan.

Categorías de datos

• De los correos: dirección, nombre, asunto, texto, fecha y datos que enlazan la conversación. Los números de tarjeta que el sistema detecta se tapan al guardar el correo.
• De los pedidos de Shopify de los últimos 60 días, cuando el pedido se identifica con certeza: número, fecha, importe total, estado del pago y del envío, nombre, apellidos y correo, dirección de envío, productos (nombre, variante, cantidad, referencia, imagen, precio), envíos y seguimiento, y la valoración de riesgo de fraude que calcula Shopify. No se leen teléfono ni tarjeta.
• Datos que deduce el servicio de cada correo: intención, idioma, señales de conflicto (enfado, amenaza legal, disputa de pago, salud, daño físico), nivel de riesgo de contracargo con sus motivos y motivo por el que pasa a una persona.
• Borradores, versiones corregidas por el equipo y respuestas enviadas, y la diferencia entre ellas.
• Lista de direcciones a las que no se debe escribir (rebotes, quejas, peticiones).
• Para no contestar dos veces: cabeceras de los correos de la carpeta de Enviados y una huella (resumen irreversible) de la dirección del destinatario; si el Responsable activa «aprender de cómo contestas», también dónde está la respuesta en su carpeta de Enviados.
• Si el Responsable activa «aprender de cómo contestas»: el texto de las respuestas de su equipo, recortado y con tarjetas tapadas.
• Para calcular los plazos reales de entrega: de los pedidos entregados de 60 días, solo el país y las fechas, y solo se guarda el resultado agregado por país.
• Del estado del envío consultado al transportista a través de 17TRACK: número de seguimiento, código del transportista, el pedido al que corresponde y su país de entrega, estado, fecha de cada movimiento, cuándo consultó 17TRACK al transportista y país de destino. El estado y las fechas pasan también a la ficha del envío del pedido. No se guardan lugares, direcciones ni la descripción libre del transportista. Con los transportistas que nombra el Anexo II, también se trata el código postal de la dirección de envío del pedido: se toma del pedido al dar de alta el envío y se manda a 17TRACK; no se guarda aparte. Para SEUR, el código postal y las cuatro últimas cifras del teléfono de remitente del Responsable, que este pone en sus ajustes y se guardan en ellos.
• Si la respuesta salió sola o la aprobó una persona, y el texto con la firma con la que salió.
• Para contar el cupo del plan: por mes, el número de pedido o una huella irreversible de la dirección del cliente.
• Si el Responsable enciende la tarjeta del equipo: por cada persona de su equipo, su correo, cuántas respuestas aprobó y editó en el periodo y la mediana de minutos hasta aprobar.
• Constancia de las cancelaciones y cambios de dirección que el equipo marca como hechos en Shopify (qué pedido, qué acción, quién y cuándo).
• El número de pedido que nombra cada correo.
• Si el Responsable enciende la valoración: el voto del cliente (sí o no), su comentario si lo escribe y la fecha, ligados a la respuesta. La página donde vota no guarda su dirección IP.
• Del portal: el número de pedido y el correo que escribe el cliente, una huella de la dirección IP de su conexión y dos huellas (seudónimos, no anonimato: de la tienda con el número y de la tienda con el correo) para los límites; si el pedido se encontró, su identificador en Shopify, con la fecha de la consulta; lo que se le enseña (número, día de compra, estado y, de cada paquete, transportista, número y enlace de seguimiento y día del último movimiento y, si puede cambiar la dirección, el país de entrega) y el idioma del pedido; y, si pide algo por escrito, el tipo de petición, el pedido y su texto, que entra como un correo más del cliente.
• Si el cliente cambia la dirección de envío desde el portal: la dirección nueva que escribe (nombre y apellidos si los cambia, calle, piso, código postal, ciudad y teléfono si lo da o el Responsable lo pide) y la que tenía el pedido en Shopify justo antes (con su teléfono y su empresa, si los tenía); el número y el identificador del pedido, cuándo lo pidió, quién del Responsable lo aprobó o no, lo que contestó Shopify y el correo que lo enseña en la bandeja. Si pide un reembolso: su motivo, con lo mismo. Del código de verificación: una huella mientras vale, cuántas veces se ha escrito, cuándo se pidió y se mandó y en qué idioma.

Categorías especiales. El servicio no busca datos de salud ni de otras categorías especiales, pero un cliente puede escribirlos en su correo. Los correos con temas legales pasan siempre a una persona sin borrador. Cuando el servicio detecta salud, daños o una disputa de pago, el correo pasa a una persona sin borrador salvo que el Responsable lo cambie en sus ajustes. Esos casos no se usan para aprender y nunca salen solos, en ningún modo. El texto del correo se conserva como el resto.

Naturaleza del tratamiento. Lectura del buzón (Microsoft 365, por Microsoft Graph, y Gmail, en pruebas, por IMAP y SMTP con una contraseña de aplicación que crea el Responsable), incluida la carpeta de Enviados; consulta de pedidos en Shopify con la aplicación que crea el propio Responsable; consulta del estado de los envíos a los transportistas a través de 17TRACK, con el número de seguimiento y, con algunos transportistas, el código postal de entrega del pedido o, con SEUR, los datos de remitente del Responsable (Anexo II); clasificación, redacción y, a petición de quien revisa, traducción al castellano con un modelo de inteligencia artificial (Gemini en Vertex AI); almacenamiento, presentación en la aplicación y envío desde el buzón del Responsable cuando una persona lo aprueba o, en el modo automático que elija el Responsable, cuando lo permiten las comprobaciones del servicio; consulta del estado de un pedido en Shopify a petición del propio cliente desde el portal del Responsable, con comprobación contra robots de Cloudflare; y, si el Responsable lo enciende, envío desde el buzón del Responsable del código de verificación al correo del pedido y escritura en Shopify de la dirección de envío que pide el cliente.

Qué recibe el modelo de inteligencia artificial.

• Para clasificar: asunto y texto del correo, con las tarjetas tapadas. Nombres, correos y teléfonos que escriba el cliente no se tapan.
• Para redactar: una lista cerrada de datos del pedido (número, nombre de pila, días desde la compra, plazo, productos y cantidades, número de envíos, si ya había comprado antes, transportista, seguimiento y último movimiento) más el texto del correo y los ajustes del Responsable. No recibe apellidos, dirección, correo del pedido, importes ni la valoración de riesgo.
• Para los borradores que siguen una regla aprobada por el Responsable: el texto del correo, las reglas aprobadas para ese tipo de consulta y, solo si el pedido se identifica con certeza, la misma lista cerrada. Sin esa certeza no recibe nada del pedido, y si el borrador afirma algo de él se descarta.
• Para el asistente de quien lleva la tienda: lo que esa persona escribe, con correos, teléfonos y números largos tapados, y un resumen de los ajustes, sin datos de compradores. La conversación no se guarda.
• Para traducir al castellano un correo que no está en castellano, cuando lo pide quien revisa: el texto del correo guardado (con las tarjetas tapadas) y el borrador. La traducción solo se enseña en pantalla; no se guarda ni se envía.
• El modelo no redacta la firma de lo que sale solo: la pone el código.
• Para aprender y para analizar el historial (si el Responsable lo activa): textos con nombres, correos, teléfonos, direcciones, enlaces, documentos de identidad y números de pedido y de seguimiento tapados. Puede pasar un nombre suelto sin nada alrededor que lo identifique.

Finalidad. Ayudar al Responsable a atender a sus clientes: clasificar los correos, encontrar el pedido, preparar borradores y proponer mejoras que el Responsable aprueba.

Conservación. Mientras dure el servicio, con estas excepciones:

• Dirección de envío: se borra sola 60 días después de la última vez que se leyó el pedido (tarea horaria).
• Texto de respuestas para aprender: al analizarlo, como mucho a los 30 días, y al momento si se apaga la función.
• Rastro de Enviados sin enlazar: pasados 14 días, en la siguiente lectura de Enviados del buzón del Responsable.
• Copia temporal del correo mientras se procesa (lleva el correo tal cual, con la tarjeta sin tapar si la había): una hora después de terminar, o 14 días si falla todas las veces.
• Historial del buzón: se lee y no se guarda ningún correo, solo cifras y propuestas sin datos personales.
• Registros técnicos del servidor, que incluyen el asunto de cada correo procesado: se sobrescriben solos por volumen.
• Voto y comentario del cliente: con la respuesta a la que van ligados.
• Consultas del portal: el número y el correo escritos, al contestar si no son de un pedido y a los 30 minutos si lo son; la huella de la dirección IP, a la hora; la fila con sus huellas y, si el pedido se encontró, su identificador en Shopify, al día. Lo borra una tarea de cada minuto, también con el portal cerrado. Lo que pide el cliente por escrito se conserva como un correo más.
• Código de verificación del portal: su huella, al usarse, agotarse o caducar (a los 10 minutos); el resto de su registro, al día. Cambios de dirección y peticiones de reembolso del portal: la dirección nueva, la de antes y el motivo, a los 90 días; el registro de qué se pidió, cuándo y qué pasó, mientras dure el servicio; el correo que los enseña en la bandeja, como el resto de los correos.
• Avisos de errores en Sentry, que de forma ocasional pueden llevar algún dato del Responsable: hasta 90 días. Su copia en Discord, sin datos de los clientes del Responsable, también se borra como mucho a los 90 días.
• Consulta a 17TRACK (número dado de alta, pedido al que corresponde y respuesta): 150 días desde que se empieza a seguir el envío. Si 17TRACK no confirma su borrado, el Encargado la borra igualmente de su sistema como mucho a los 157 días. El estado y las fechas que pasan a la ficha del envío del pedido se conservan como el resto del pedido.
• En 17TRACK: cuando el Encargado sabe que un envío se ha entregado, le pide que deje de seguirlo a las 24 horas, y a los 150 días del alta le pide que lo borre. Si no contesta, según su documentación borra lo parado a los 90 días; lo que nunca se entrega puede quedar allí más tiempo.

Al terminar, la cláusula 10.

Lugar del tratamiento. Servidor en Núremberg (Alemania), con imágenes diarias de la máquina en el mismo proveedor; modelo de IA (también la traducción para quien revisa) en la multirregión de la Unión Europea de Google; consulta del estado de los envíos en 17TRACK (empresa de Singapur, que guarda los datos en Estados Unidos y los trata en China); avisos del portal al Responsable, por Resend (envía desde Irlanda y guarda en Estados Unidos); administración remota del servicio por el Encargado; copias de seguridad cifradas en el servidor y en el ordenador de la persona que administra el servicio por cuenta del Encargado, en la Unión Europea; la prueba previa al alta y la carga del historial desde una exportación del buzón, si se autorizan, en ese mismo ordenador, y sus datos se borran al terminar. Encargados ulteriores: Anexo III.

Anexo II. Medidas de seguridad

Solo se listan medidas que existen hoy.

Separación entre clientes

• Cada tabla con datos de un Responsable tiene seguridad por filas forzada en la base de datos (la propia base impide leer filas de otra tienda), y hay pruebas automáticas que intentan cruzar datos entre tiendas.
• La tienda de cada petición se decide en el servidor a partir de la sesión, no de lo que diga el navegador.
• Ninguna petición al modelo de IA lleva ejemplos, reglas ni correos de otro Responsable.

Credenciales y acceso

• Las credenciales de Shopify y del buzón (y, si el Responsable conecta Slack, la dirección de su canal) se guardan cifradas en la base de datos; la clave de cifrado está fuera de la base. La parte de la aplicación que se ve en pantalla puede guardarlas pero no leerlas; solo las lee el proceso que trabaja los correos.
• Contraseñas guardadas con scrypt (una función que las transforma de forma irreversible y costosa de atacar); misma respuesta y mismo tiempo ante un usuario que no existe y una contraseña mal escrita; límite de intentos por correo y por conexión.
• Códigos de invitación y de contraseña nueva aleatorios, de un solo uso y con caducidad (7 días y 24 horas); solo se guarda su huella.
• Sesiones firmadas, con una clave distinta de la que cifra las credenciales, y caducidad de 30 días.
• Dos papeles en cada tienda: quien la lleva y quien solo contesta, que no ve ajustes, buzón, suscripción ni equipo.
• Conexiones a la base de datos con papeles distintos para cada parte del sistema.
• Registro de quién consulta la dirección de envío de un pedido y cuándo, que no se puede modificar.
• Solo quien lleva la tienda puede pasar a un modo automático o cambiar las situaciones que salen solas, y «Automático» exige su confirmación expresa. El servicio, por su cuenta, solo puede volver a «Borrador»: lo hace si un correo del Responsable rebota de forma permanente o alguien lo marca como spam, al darse de baja la tienda, y al restaurar una copia de seguridad, que deja todas las tiendas en «Borrador» y el proceso de envío parado hasta revisarlo. Cada cambio, también estos, queda en un registro que escribe la propia base de datos y que nadie puede cambiar ni borrar; los que hace el servicio llevan el motivo en lugar de la persona.

Red y servidor

• A la aplicación solo se llega a través de un túnel cifrado; la base de datos y el proceso de correos están configurados para escuchar solo dentro del servidor.
• Cabeceras de seguridad en todas las respuestas (HSTS, que obliga a usar conexión cifrada; prohibición de enmarcar la página; nosniff, que impide al navegador reinterpretar archivos; política de referencia restringida).
• Acceso de administración al servidor solo con llave, solo para un usuario y solo a través de una red privada; cortafuegos fuera de la máquina que no deja entrar ninguna conexión de administración desde internet; bloqueo de intentos repetidos; actualizaciones de seguridad automáticas.

Minimización

• El sistema detecta los números de tarjeta y los tapa antes de guardar el correo y antes de enviarlo al modelo, salvo en la copia temporal del correo mientras se procesa, que se borra a la hora de terminar.
• El modelo de IA recibe una lista cerrada de datos del pedido (Anexo I).
• La dirección de envío se borra sola a los 60 días de la última lectura del pedido.
• El texto de las respuestas para aprender se borra al analizarlo, como mucho a los 30 días, y al momento si se apaga la función.
• Los avisos de errores salen con una lista cerrada de campos, con correos, teléfonos, direcciones IP y lo que va entre comillas tapados, y el sistema está construido para que no salga el contenido de los correos.
• Los registros técnicos no guardan lo que se envía al modelo ni lo que contesta.
• A Slack solo salen cuentas, el nombre de la tienda, enlaces a la aplicación y, en el informe semanal, los nombres de los productos y transportistas del Responsable con más consultas; nunca el texto de un correo ni datos de clientes, salvo el número del pedido en los avisos del portal.
• A 17TRACK solo sale el número de seguimiento, el código del transportista cuando se sabe, un identificador interno aleatorio que no dice nada del comprador y, con el transportista PostNL, el país de destino. Solo con GLS España, Paack, Envialia, Ontime, TIPSA, Mondial Relay e InPost España, una lista cerrada, sale también el código postal de la dirección de entrega del pedido; y con SEUR, el código postal y las cuatro últimas cifras del teléfono de remitente del Responsable, nunca los del comprador (sin ellos, los envíos de SEUR no se siguen en 17TRACK). Nunca el nombre, la calle, el correo ni el teléfono del comprador, ni el pedido; los envíos de los transportistas que piden otros datos del comprador no se siguen en 17TRACK. El código postal no se guarda con la consulta ni va a los registros técnicos ni a los avisos de errores. De lo que devuelve se guardan el estado, las fechas de los movimientos y el país de destino; nunca los lugares, la dirección ni el texto libre del transportista.
• A Slack y al correo de Parlo (Resend), los avisos del cupo, del primer cobro y de la pausa llevan solo datos de la tienda (nombre, plan, conversaciones, fechas, lo que se cobra y si falta una tarjeta); a Slack, sin el importe. Nunca un dato de un cliente.

Portal del comprador

• La página pública no puede leer las credenciales del Responsable: apunta la consulta en la base y la contesta el proceso que trabaja los correos. A Shopify solo se le hace una consulta fija, sin dirección, importes, cliente ni artículos, y el pedido solo se da por bueno si el número y el correo coinciden en el código.
• Lo que se enseña pasa por dos listas cerradas (en el código y en la base). Un pedido que no existe y uno con otro correo dan la misma respuesta, y ninguna búsqueda contesta antes de 2 segundos, para que el tiempo no delate si un correo ha comprado.
• Comprobación contra robots en cada búsqueda (sin ella el portal no se abre) y límites contados en la base antes de saber nada del pedido: 20 búsquedas por conexión y hora; 10 por correo y hora y 30 al día en cada tienda; 5 por pedido y hora; 300 por tienda y hora; 3.000 en total; y 3 peticiones por pedido y 100 por tienda al día.
• La dirección pública del portal (app.parlodesk.com/p/...) lleva un componente aleatorio de 40 bits por Responsable: sin él, la página es la de una dirección que no existe.
• Lo que el cliente pide por escrito y la petición de reembolso no cambian nada en Shopify: entran en la bandeja, sin respuesta preparada, para que las revise una persona.
• El cambio de dirección en Shopify solo lo escribe el proceso que trabaja los correos, nunca la página pública. Por su conexión con Shopify solo salen dos documentos fijos (leer ese pedido y cambiar su dirección de envío), atados al pedido de la acción; cancelar, reembolsar o cualquier otro cambio se rechazan sin salir. Justo antes de escribir se vuelve a comprobar que la acción sigue encendida y, en Shopify, que el pedido no está cancelado, no tiene envíos y no se está preparando ni lo ha aceptado un almacén o un servicio de envíos, que el país es el mismo y, en España, que el código postal es de la misma provincia.
• Antes de apuntar un cambio de dirección, verificación de que quien lo pide controla el correo del pedido: código de un solo uso de 6 cifras, 10 minutos, 5 intentos, conservado solo como huella y borrado al usarse, agotarse o caducar; enviado desde el buzón del Responsable; como mucho 3 códigos por pedido a la hora y 5 al día, y 30 por Responsable a la hora y 100 al día. Si el buzón del Responsable no puede enviarlo, el cambio no se ofrece.
• Como mucho 3 acciones por pedido y 100 por Responsable al día; una por consulta y una en curso por pedido. Lo que se queda a medias no se repite: se vuelve a leer el pedido y, si no consta hecho, pasa a una persona.
• Los avisos al Responsable de cada acción llevan el número del pedido y, si es la dirección, de cuál a cuál, o el motivo del reembolso; nunca el correo ni el teléfono del cliente. A Slack, sin la dirección ni el motivo.
• La página no lleva scripts propios, no pone cookies, no se guarda en caché, no envía la dirección de origen y no se indexa.

Revisión humana y envío automático

• Cuando una persona del Responsable aprueba una respuesta, el envío espera 10 segundos para poder deshacerlo y, antes de enviar, se comprueba si alguien ya contestó desde el buzón.
• El modo de fábrica es «Borrador» y el Responsable elige otro. En todos los modos, cada correo pasa las mismas comprobaciones automáticas, y lo que no las pasa queda como borrador.
• Nunca sale solo, y el Responsable no lo puede cambiar: lo que no es una consulta de seguimiento del pedido (reembolsos, devoluciones, cancelaciones, cambios y quejas); lo que pide dinero o trae una reclamación legal, una disputa de pago, un problema de salud o un daño; lo que ofrece algo o promete gestiones; las situaciones de seguimiento que no se gradúan (hoy pueden salir solas 2 de 21: en camino dentro de plazo y entregado sin discusión); la respuesta a quien ya escribió otro correo en las últimas 72 horas; y lo escrito en un idioma que el servicio no sabe revisar o que no está habilitado para salir solo. Tampoco lo que supera el riesgo de contracargo que fija el Responsable.
• Lo que sale solo lleva la firma «The [nombre de la tienda] AI Customer Care Agent», que pone el código y no el modelo; si no se puede poner, la respuesta vuelve a borrador. Espera unos minutos antes de salir, y en ese tiempo cualquier persona del Responsable lo puede parar. Justo antes de enviarlo se vuelven a comprobar los ajustes de ese momento y si alguien ya contestó desde el buzón. Si por el buzón del Responsable no puede salir la marca para máquinas del punto siguiente (hoy, Microsoft 365), lo que iba a salir solo vuelve a borrador.
• Cuando el buzón del Responsable lo permite, toda respuesta cuyo texto redacta el servicio lleva las cabeceras X-Parlo-AI: generated y X-Parlo-Review: human o none, según la haya aprobado una persona o no. Lo que sale solo las lleva siempre.

Fin del servicio

• Al dar de baja una tienda se corta en el acto: se deja de leer su buzón, lo aprobado que no ha empezado a salir no sale y se borran todas sus credenciales. Una tienda cortada no puede volver a conectar su buzón ni guardar credenciales mientras la baja siga en curso, y el correo que llegue no se procesa.

Copias y continuidad

• Copias diarias de la base de datos, cifradas (AES-256, con la clave derivada mediante PBKDF2), que se comprueban al hacerlas y caducan como máximo a los 30 días.
• Vigilancia automática del servicio cada 5 minutos, con reinicio y aviso si falla.

Anexo III. Encargados ulteriores

Lista vigente a la fecha en que el Responsable acepta este contrato. Los cambios posteriores siguen la cláusula 7.2; la página de encargados del tratamiento de Parlo es informativa.

Microsoft, Google (si se conecta un buzón de Gmail) y Shopify no son encargados ulteriores del Encargado: son proveedores del propio Responsable, a los que Parlo accede con el permiso que el Responsable da. Tampoco lo es Slack: si el Responsable conecta su canal, es un destino que elige él, y solo recibe cuentas, el nombre de la tienda, enlaces y, en el informe semanal, los nombres de sus productos y transportistas con más consultas, sin datos de sus clientes salvo el número del pedido en los avisos del portal. El código de verificación del portal sale del buzón del Responsable, por su propio proveedor de correo, como sus respuestas. Tampoco lo es Discord: recibe los avisos de errores que manda Sentry ya filtrados (el nombre del error, la tienda y la página), sin datos de los clientes del Responsable, y se borran como mucho a los 90 días.

Con los demás correos de Parlo a las personas que llevan cada tienda (los avisos del cupo, del primer cobro y de la pausa, el enlace del alta, la copia en PDF de los Términos y el informe semanal), Resend no recibe datos de los clientes del Responsable: ahí trata datos de los que el Encargado es responsable. Figura en esta lista solo por los avisos del portal.

Anexo IV. Texto sugerido para la política de privacidad del Responsable

El Responsable puede adaptar este texto:

Para atender los correos que nos envías usamos Parlo, un servicio de The Wise Brands LLC que actúa como encargado del tratamiento. Parlo lee los correos que llegan a nuestro buzón de atención al cliente, busca tu pedido en nuestra tienda y usa un modelo de inteligencia artificial (Gemini, de Google, en la Unión Europea) para preparar un borrador de respuesta. Para saber por dónde va tu envío, consulta al transportista a través de 17TRACK, un proveedor de Singapur que guarda los datos en Estados Unidos y los trata en China, y que recibe el número de seguimiento, el transportista y, en algunos casos, el país de destino o el código postal de la dirección de entrega. Con el número, 17TRACK obtiene del transportista los movimientos del envío, que pueden incluir la dirección de entrega, y los conserva hasta que se le pide que los borre. Una persona de nuestro equipo revisa cada respuesta antes de enviarla. Al final de algunas respuestas puede haber un enlace para valorar si te hemos ayudado (guardamos tu voto y tu comentario). En nuestro portal de pedidos, que gestiona Parlo, puedes ver el estado de tu pedido con su número y tu correo y pedirnos un cambio de dirección o una devolución. Para frenar abusos pasa una comprobación contra robots de Cloudflare, que ve tu dirección IP y tu navegador. Si no pides nada, el número y el correo no se guardan más de media hora; lo que pidas por escrito nos llega como un correo y lo revisa una persona de nuestro equipo. Si lo tenemos encendido, también puedes cambiar ahí la dirección de envío de un pedido que todavía no ha salido, después de escribir un código que te mandamos al correo del pedido, y pedirnos el reembolso de un pedido ya enviado, que decidimos nosotros. Los datos se guardan en un servidor en Alemania. The Wise Brands LLC y algunos de sus proveedores son empresas de Estados Unidos, y 17TRACK es de Singapur y guarda y trata los datos en Estados Unidos y en China, lo que supone transferencias fuera del Espacio Económico Europeo con las garantías que se indican en la política de privacidad de Parlo (parlodesk.com/privacidad). La lista de sus proveedores está en parlodesk.com/encargados.

Si el Responsable elige un modo automático, sustituye la frase «Una persona de nuestro equipo revisa cada respuesta antes de enviarla» por esta:

Algunas respuestas sobre dónde está tu pedido se envían sin que las revise una persona; van firmadas «The [nombre de la tienda] AI Customer Care Agent». Las demás las revisa una persona de nuestro equipo antes de enviarlas.

Si el Responsable no abre el portal o no enciende la valoración, quita las frases que hablan de ellos; si no enciende el cambio de dirección ni el reembolso en el portal, quita la frase que empieza por «Si lo tenemos encendido».

Data processing agreement

Last updated: October 5, 2026

Version v2026-10-05

Parties

• The Controller: the store that contracts Parlo, identified at sign-up. This agreement is accepted, when accepting the Terms of service, by whoever has the authority to bind the store.
• The Processor: The Wise Brands LLC, a United States limited liability company, with postal address at 11820 Miramar Pkwy, Unit 204, Miramar, FL 33025 (United States), EIN 98-1896488, contact info@parlodesk.com, which provides the Parlo service.

This agreement is part of Parlo's Terms of service. It governs the processing of personal data that the Processor carries out on behalf of the Controller, in accordance with Article 28 of Regulation (EU) 2016/679 (GDPR) and, where applicable, Spanish Organic Law 3/2018. Regarding personal data, this agreement prevails over the Terms and over any other agreement between the parties.

This agreement is entered into in Spanish, and the Spanish version prevails; this English version is provided for convenience.

1. Purpose

The Processor processes the personal data described in Annex I only to provide the Controller with the Parlo service: reading the customer support mailbox the Controller connects, understanding each email, matching it with the order in its Shopify store, checking the shipment status with the carrier and preparing draft replies that a person of the Controller reviews and sends from their own mailbox. If the Controller chooses an automatic mode, the Processor also sends from that mailbox, without review by a person, the replies allowed by the chosen mode and by the service's checks (Annex II). If the Controller opens its customers' portal, the Processor handles the searches those customers make in it about their order and, if the Controller turns it on, changes in its Shopify store, at the customer's request and after sending from the Controller's mailbox a verification code to the order's email address, the shipping address of an order that has not shipped (Annex II).

2. Term

This agreement starts on the day the Controller accepts it, before any processing, and also covers the pre-sign-up test if the Controller authorizes it (clause 3.2). It lasts while the Processor processes data on behalf of the Controller and, afterwards, for the time needed to comply with clause 10 (end of the service). If after the pre-sign-up test the Controller does not subscribe, the Processor deletes the test data as soon as it ends and confirms it in writing.

3. Controller's instructions

3.1. The Processor processes the data only on documented instructions from the Controller, including those regarding transfers to third countries. The Controller's instructions are: this agreement, the Terms, and the configuration the Controller sets in Parlo (connected mailbox, settings, reply mode and situations that can go out on their own, topics that always go to a person, features it turns on or off and proposals it approves). Changes to the reply mode are recorded with who made them and when, and that record cannot be changed or deleted while the store exists. The Processor can only change the mode on its own to go back to "Draft", if an email from the Controller bounces permanently or someone marks it as spam, when the store leaves, or when restoring a backup of the database, which leaves all stores in "Draft", and it records this with the reason.

3.2. The optional features that process more data are only used if the Controller turns them on or authorizes it in writing:

• "Learn from how you reply", which comes switched off.
• The analysis of the mailbox history, which is requested expressly for 3, 6 or 12 months, or, with written authorization, from a mailbox export delivered by the Controller.
• The pre-sign-up test with earlier emails from the mailbox, which is only done with prior written authorization and with this agreement already accepted.
• The analytics team card, which shows the person who runs the store the work data of each person on their team (Annex I).
• Notices and the weekly report to a Slack channel of the Controller, without data about its customers.
• The "Automatic by topic" and "Automatic" modes, which send replies without review by a person (clause 1 and Annex II).
• The customer's rating of the replies, which is added at the foot of the replies.
• The portal where the Controller's customers look up their order and ask for an address change or a return, and the link to that portal at the foot of the replies (Annex I and Annex II).
• Within the portal, each one separately: changing the shipping address in Shopify, with or without the Controller's prior approval, and the refund request for a shipped order, which only reaches the Controller. Turning them on is the Controller's instruction; the customer's, asking for it from the portal: without both, nothing is written. An order cannot be canceled from the portal.

3.3. If the Processor believes an instruction infringes the GDPR or another data protection rule, it will tell the Controller immediately.

3.4. If Union or Member State law to which the Processor is subject requires it to process the data differently, it will tell the Controller beforehand, unless that law prohibits it on important grounds of public interest.

4. Use of the data only for the Controller

4.1. The Processor does not use the data for its own purposes or to provide services to other customers. In particular, it does not use them to train or fine-tune artificial intelligence models, and what the service learns from a Controller is only used for that Controller.

4.2. The Processor does not sell or disclose the data to third parties, except to the sub-processors of clause 7 or when required by Union or Member State law to which it is subject.

5. Confidentiality

The Processor guarantees that the persons authorized to process the data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. Only the people who need it to provide, support or maintain the service access the data.

6. Security

6.1. The Processor applies the technical and organizational measures of Annex II, appropriate to the risk under Article 32 of the GDPR.

6.2. The Processor may improve those measures. It may not lower the level of protection without notifying the Controller beforehand.

7. Sub-processors

7.1. The Controller gives its general authorization for the Processor to engage the sub-processors of Annex III, which is the list in force on the date the Controller accepts this agreement. Later changes follow clause 7.2. Parlo's subprocessors page is informative.

7.2. Before adding or replacing a sub-processor, the Processor will notify the Controller by email at least 30 days in advance, saying who it is, what it will do, what data it will receive, where and with what safeguard. The Controller may object on reasonable data protection grounds within that period. If the parties do not find a solution, the Controller may terminate the service without penalty and with a refund of the amount paid and not used.

7.3. The Processor has entered into a contract with each sub-processor that imposes on it the same data protection obligations as this agreement, under Article 28.4 of the GDPR, and remains fully liable to the Controller for what they do.

8. International transfers

8.1. The data are stored on a server in Germany and the artificial intelligence model is used in Google's European Union multi-region, which keeps processing within the EU. The Processor is a United States company and the service is administered remotely; some sub-processors are United States companies, and Cloudflare may process traffic at any point of its global network. The sub-processor that checks shipment status (17TRACK) contracts through its Singapore company (VASTAR SINGAPORE TECHNOLOGY PTE. LTD) and, according to its own privacy policy, stores the data in the United States and processes it in China; Singapore and China have no adequacy decision, and the one for the United States only covers companies certified under the Data Privacy Framework. It receives only the data indicated in Annex II; with the tracking number it obtains from the carrier the shipment's events, which may include the delivery address, and keeps them until the Processor asks it to delete them. The parties understand that this involves transfers of data outside the European Economic Area.

8.2. For those transfers, the Processor relies on the European Commission's standard contractual clauses included in each sub-processor's data processing agreement and, where the sub-processor has joined it, on the EU-U.S. Data Privacy Framework. The transfer to 17TRACK relies on the European Commission's standard contractual clauses included in its data processing agreement and on the Processor's transfer assessment. The Controller can ask for a copy of those safeguards at info@parlodesk.com.

8.3. The Processor does not transfer data to third countries other than those indicated in Annex III without following the procedure of clause 7.

8.4. Requests from public authorities. If a public authority, from any country, asks the Processor for access to the Controller's data, the Processor will: (a) tell the Controller immediately, unless the law prohibits it, and in that case try to have the prohibition lifted; (b) check whether the request is lawful and challenge any request that, after careful assessment, it considers unlawful; (c) hand over only the minimum required; and (d) keep a record of the request and its answer, and provide it to the Controller when it can. 8.5. Standard contractual clauses between the Controller and the Processor. For the transfer of the Controller's data to the Processor itself, a United States company that administers the service remotely, the parties enter into, when accepting this agreement, the European Commission's standard contractual clauses approved by Implementing Decision (EU) 2021/914, module two (transfer controller to processor), which are incorporated into this agreement by reference, with the Controller as data exporter and the Processor as data importer. For those clauses: the description of the transfer is that of Annex I; the technical and organizational measures, those of Annex II; the sub-processors, those of Annex III, with the general authorization and the 30 days' prior notice of clause 7 of this agreement (option 2 of their clause 9); the optional docking clause (their clause 7) and the option of their clause 11 are not included; the competent supervisory authority is the one set by their clause 13 (if the Controller is established in the Union, that of its Member State); they are governed by Spanish law (their clause 17) and disputes arising from them are submitted to the courts of Spain (their clause 18). If anything in this agreement contradicts those clauses, the clauses prevail.

9. Assistance to the Controller

9.1. Data subjects' rights. Parlo has no direct relationship with the Controller's customers. If a person contacts the Processor to exercise their rights, the Processor will pass it on to the Controller within 5 business days and will not answer on its own unless the Controller asks it to. The Processor will help the Controller, with the technical means available and within a reasonable time, to locate, rectify, export or delete that person's data.

9.2. Security breaches. The Processor will notify the Controller of any breach of security affecting its data without undue delay and, in any case, within 48 hours at most from becoming aware of it, with the information available at that moment: what happened, what data and how many people may be affected, the likely consequences and the measures taken or proposed. It will complete the information as it gets it, and will help the Controller, if needed, to notify the breach to the supervisory authority and to the people affected.

9.3. Impact assessments and consultations. The Processor will provide the Controller with the information it needs for its impact assessment and, if necessary, for the prior consultation with the supervisory authority.

9.4. Information for the Controller's customers. The Processor provides on its public pages the description of the service, of the data it processes, of the use of artificial intelligence and of its sub-processors, and in Annex IV a text the Controller can use in its privacy policy. Informing those customers is the Controller's responsibility.

10. End of the service

10.1. When the service ends, at the Controller's choice, the Processor will return the personal data or delete them, and will delete the copies it holds, unless Union or Member State law requires it to keep them. If the Controller does not choose, they are deleted. When it ends, the Processor stops reading the Controller's mailbox and store and deletes its access credentials: the system does this immediately when the store leaves. When the service ends because the subscription ends, the Processor carries out the departure manually.

10.2. Timing: when the store leaves, the cut-off is immediate; deletion, within 30 days at most from the Controller's written request, and today it is done manually.

10.3. Backups are not modified one by one: they expire on their own. The database backups the Processor makes are encrypted and deleted within 30 days at most from when they are made; the daily machine images kept by the server provider, after 7 days.

10.4. The Processor may keep, duly blocked, the data needed while liabilities may arise from its relationship with the Controller.

11. Information and audits

11.1. The Processor will make available to the Controller the information needed to demonstrate that it complies with this agreement and with Article 28 of the GDPR.

11.2. The Controller may audit that compliance, itself or through an auditor bound by confidentiality: first through a questionnaire and documentation; if that is not enough, one audit a year at most, with 30 days' notice, during business hours, at the Controller's expense, unless an authority requests it or there are signs of non-compliance after a breach.

12. Controller's obligations

The Controller:

• Has a legal basis for the processing it entrusts and has informed its customers that it uses a provider such as Parlo, which uses artificial intelligence.
• Only connects mailboxes and stores it has the right to.
• Gives instructions that comply with the law and supervises the processing, including the decision about which sensitive topics always go to a person.
• Keeps human review of replies in "Draft" mode and, if it chooses an automatic mode, monitors what goes out on its own and stops it or goes back to "Draft" when needed. It decides which mode and which situations go out on their own, and is answerable for that decision to its customers.
• Informs its customers that some replies are sent without review by a person, if it chooses an automatic mode.
• Informs the people on its team before turning on the analytics team card.

13. Liability

Each party is liable for its breaches of this agreement and of data protection law.

14. Governing law and courts

This agreement is governed by Spanish law and by the GDPR. Any dispute about it is submitted to the courts of Spain. This applies even if the Terms choose another law and other courts for the rest of the relationship.

15. Changes

Changes to this agreement are notified to the Controller by email and require its acceptance. Publishing them on the website is not enough.

Annex I. Description of the processing

Categories of data subjects

• Customers and prospective customers of the Controller who write to its customer support mailbox, use its portal or rate a reply.
• Anyone else who writes to that mailbox: suppliers, carriers, platforms, senders of newsletters or of personal email if the mailbox mixes them. Parlo also keeps those discarded emails.
• The people on the Controller's team whose replies, signatures or names appear in the emails and, if the Controller turns on the analytics team card, whose work data are shown to it.

Categories of data

• From emails: address, name, subject, text, date and data that link the conversation. Card numbers the system detects are masked when the email is stored.
• From Shopify orders of the last 60 days, when the order is identified with certainty: number, date, total amount, payment and fulfillment status, first name, surname and email address, shipping address, products (name, variant, quantity, SKU, image, price), shipments and tracking, and the fraud risk assessment calculated by Shopify. Phone and card are not read.
• Data the service infers from each email: intent, language, conflict signals (anger, legal threat, payment dispute, health, physical harm), chargeback risk level with its reasons and the reason why it goes to a person.
• Drafts, versions corrected by the team and replies sent, and the difference between them.
• List of addresses that must not be written to (bounces, complaints, requests).
• To avoid replying twice: headers of the emails in the Sent folder and a hash (irreversible digest) of the recipient's address; if the Controller turns on "learn from how you reply", also where the reply is in its Sent folder.
• If the Controller turns on "learn from how you reply": the text of its team's replies, trimmed and with cards masked.
• To calculate actual delivery times: from orders delivered within 60 days, only the country and the dates, and only the result aggregated by country is stored.
• From the shipment status checked with the carrier through 17TRACK: tracking number, carrier code, the order it belongs to and its delivery country, status, date of each event, when 17TRACK checked with the carrier and destination country. The status and dates also go to the order's shipment record. Places, addresses and the carrier's free-text description are not stored. With the carriers named in Annex II, the postal code of the order's shipping address is also processed: it is taken from the order when the shipment is registered and sent to 17TRACK; it is not stored separately. For SEUR, the postal code and the last four digits of the Controller's sender phone number, which the Controller enters in its settings and which are stored there.
• Whether the reply went out on its own or was approved by a person, and the text with the signature it went out with.
• To count the plan's quota: per month, the order number or an irreversible hash of the customer's address.
• If the Controller turns on the team card: for each person on its team, their email address, how many replies they approved and edited in the period and the median minutes until approval.
• A record of the cancellations and address changes the team marks as done in Shopify (which order, which action, who and when).
• The order number each email mentions.
• If the Controller turns on the rating: the customer's vote (yes or no), their comment if they write one and the date, linked to the reply. The page where they vote does not store their IP address.
• From the portal: the order number and the email address the customer types, a fingerprint of their connection's IP address and two fingerprints (pseudonyms, not anonymity: of the store with the number and of the store with the email address) for the limits; if the order was found, its identifier in Shopify, with the date of the search; what is shown to them (number, purchase date, status and, for each package, carrier, tracking number and link and day of the last event and, if they can change the address, the delivery country) and the order's language; and, if they ask for something in writing, the type of request, the order and its text, which comes in as one more email from the customer.
• If the customer changes the shipping address from the portal: the new address they type (first name and surname if they change them, street, floor, postal code, city and phone if they give it or the Controller asks for it) and the one the order had in Shopify right before (with its phone and company, if it had them); the order's number and identifier, when they asked for it, who at the Controller approved it or not, what Shopify answered and the email that shows it in the inbox. If they request a refund: its reason, with the same. Of the verification code: a fingerprint while it is valid, how many times it has been typed, when it was requested and sent and in which language.

Special categories. The service does not look for health data or other special categories, but a customer may write them in their email. Emails with legal topics always go to a person without a draft. When the service detects health, harm or a payment dispute, the email goes to a person without a draft unless the Controller changes this in its settings. Those cases are not used for learning and never go out on their own, in any mode. The text of the email is kept like the rest.

Nature of the processing. Reading the mailbox (Microsoft 365, through Microsoft Graph, and Gmail, in testing, through IMAP and SMTP with an app password created by the Controller), including the Sent folder; looking up orders in Shopify with the application the Controller itself creates; checking shipment status with carriers through 17TRACK, with the tracking number and, with some carriers, the order's delivery postal code or, with SEUR, the Controller's sender data (Annex II); classification, drafting and, at the reviewer's request, translation into Spanish with an artificial intelligence model (Gemini on Vertex AI); storage, display in the application and sending from the Controller's mailbox when a person approves it or, in the automatic mode the Controller chooses, when the service's checks allow it; looking up an order's status in Shopify at the request of the customer themselves from the Controller's portal, with a bot check by Cloudflare; and, if the Controller turns it on, sending from the Controller's mailbox the verification code to the order's email address and writing in Shopify the shipping address the customer asks for.

What the artificial intelligence model receives.

• To classify: subject and text of the email, with cards masked. Names, email addresses and phone numbers the customer writes are not masked.
• To draft: a closed list of order data (number, first name, days since purchase, delivery time, products and quantities, number of shipments, whether they had bought before, carrier, tracking and last event) plus the text of the email and the Controller's settings. It does not receive surnames, address, the order's email address, amounts or the risk assessment.
• For drafts that follow a rule approved by the Controller: the text of the email, the rules approved for that type of query and, only if the order is identified with certainty, the same closed list. Without that certainty it receives nothing about the order, and if the draft states anything about it, it is discarded.
• For the assistant of the person who runs the store: what that person writes, with email addresses, phone numbers and long numbers masked, and a summary of the settings, without buyer data. The conversation is not stored.
• To translate into Spanish an email that is not in Spanish, when the reviewer asks for it: the text of the stored email (with cards masked) and the draft. The translation is only shown on screen; it is not stored or sent.
• The model does not write the signature of what goes out on its own: the code adds it.
• For learning and for analyzing history (if the Controller turns it on): texts with names, email addresses, phone numbers, addresses, links, identity documents and order and tracking numbers masked. A lone name with nothing around it that identifies the person may get through.

Purpose. Helping the Controller serve its customers: classifying emails, finding the order, preparing drafts and proposing improvements the Controller approves.

Retention. For as long as the service lasts, with these exceptions:

• Shipping address: deleted automatically 60 days after the order was last read (hourly task).
• Text of replies for learning: when it is analyzed, at most after 30 days, and immediately if the feature is turned off.
• Unlinked Sent trail: after 14 days, at the next reading of the Controller's mailbox Sent folder.
• Temporary copy of the email while it is processed (it carries the email as is, with the card unmasked if there was one): one hour after finishing, or 14 days if every attempt fails.
• Mailbox history: it is read and no email is stored, only figures and proposals without personal data.
• Technical server logs, which include the subject of each processed email: overwritten automatically by volume.
• Customer's vote and comment: with the reply they are linked to.
• Portal searches: the number and email address typed, when answering if they are not from an order and after 30 minutes if they are; the fingerprint of the IP address, after an hour; the row with its fingerprints and, if the order was found, its identifier in Shopify, after a day. An every-minute task deletes them, also with the portal closed. What the customer asks for in writing is kept as one more email.
• Portal verification code: its fingerprint, when it is used, exhausted or expired (after 10 minutes); the rest of its record, after a day. Address changes and refund requests from the portal: the new address, the previous one and the reason, after 90 days; the record of what was asked for, when and what happened, for as long as the service lasts; the email that shows them in the inbox, like the rest of the emails.
• Error notices in Sentry, which may occasionally carry some of the Controller's data: up to 90 days. Their copy in Discord, with no data about the Controller's customers, is also deleted after 90 days at most.
• Query to 17TRACK (registered number, the order it belongs to and the response): 150 days from when tracking of the shipment starts. If 17TRACK does not confirm its deletion, the Processor deletes it from its own system anyway at most after 157 days. The status and dates that go to the order's shipment record are kept like the rest of the order.
• At 17TRACK: when the Processor knows a shipment has been delivered, it asks 17TRACK to stop tracking it after 24 hours, and 150 days after registration it asks 17TRACK to delete it. If it does not answer, according to its documentation it deletes stopped shipments after 90 days; what is never delivered may stay there longer.

At the end, clause 10.

Place of processing. Server in Nuremberg (Germany), with daily images of the machine at the same provider; AI model (also the translation for the reviewer) in Google's European Union multi-region; shipment status checks at 17TRACK (a Singapore company that stores the data in the United States and processes it in China); portal notices to the Controller, through Resend (sends from Ireland and stores in the United States); remote administration of the service by the Processor; encrypted backups on the server and on the computer of the person who administers the service on the Processor's behalf, in the European Union; the pre-sign-up test and the loading of history from a mailbox export, if authorized, on that same computer, and their data are deleted when finished. Sub-processors: Annex III.

Annex II. Security measures

Only measures that exist today are listed.

Separation between customers

• Every table with a Controller's data has row-level security enforced in the database (the database itself prevents reading another store's rows), and there are automated tests that try to cross data between stores.
• The store of each request is decided on the server from the session, not from what the browser says.
• No request to the AI model carries examples, rules or emails from another Controller.

Credentials and access

• The Shopify and mailbox credentials (and, if the Controller connects Slack, its channel address) are stored encrypted in the database; the encryption key is outside the database. The on-screen part of the application can store them but not read them; only the process that works the emails reads them.
• Passwords stored with scrypt (a function that transforms them irreversibly and is costly to attack); same answer and same time for a user that does not exist and a mistyped password; attempt limits per email address and per connection.
• Invitation and new-password codes that are random, single-use and expiring (7 days and 24 hours); only their hash is stored.
• Signed sessions, with a key different from the one that encrypts the credentials, expiring after 30 days.
• Two roles in each store: the person who runs it and the person who only replies, who does not see settings, mailbox, subscription or team.
• Database connections with different roles for each part of the system.
• Record of who views an order's shipping address and when, which cannot be modified.
• Only the person who runs the store can switch to an automatic mode or change the situations that go out on their own, and "Automatic" requires their express confirmation. The service, on its own, can only go back to "Draft": it does so if an email from the Controller bounces permanently or someone marks it as spam, when the store leaves, and when restoring a backup, which leaves all stores in "Draft" and the sending process stopped until it is reviewed. Every change, these included, goes into a record written by the database itself that nobody can change or delete; those made by the service carry the reason instead of the person.

Network and server

• The application can only be reached through an encrypted tunnel; the database and the email process are configured to listen only inside the server.
• Security headers on every response (HSTS, which forces an encrypted connection; a ban on framing the page; nosniff, which stops the browser reinterpreting files; a restricted referrer policy).
• Administrative access to the server only with a key, only for one user and only through a private network; a firewall outside the machine that lets in no administrative connection from the internet; blocking of repeated attempts; automatic security updates.

Minimization

• The system detects card numbers and masks them before storing the email and before sending it to the model, except in the temporary copy of the email while it is processed, which is deleted an hour after finishing.
• The AI model receives a closed list of order data (Annex I).
• The shipping address is deleted automatically 60 days after the order was last read.
• The text of replies for learning is deleted when analyzed, at most after 30 days, and immediately if the feature is turned off.
• Error notices go out with a closed list of fields, with email addresses, phone numbers, IP addresses and anything in quotes masked, and the system is built so that the content of emails does not go out.
• Technical logs do not store what is sent to the model or what it answers.
• Only counts, the store name, links to the application and, in the weekly report, the names of the Controller's products and carriers with the most queries go to Slack; never the text of an email or customer data, except the order number in the portal notices.
• Only the tracking number, the carrier code when known, a random internal identifier that says nothing about the buyer and, with the carrier PostNL, the destination country go to 17TRACK. Only with GLS Spain, Paack, Envialia, Ontime, TIPSA, Mondial Relay and InPost Spain, a closed list, the postal code of the order's delivery address also goes; and with SEUR, the postal code and the last four digits of the Controller's sender phone number, never the buyer's (without them, SEUR shipments are not tracked in 17TRACK). Never the buyer's name, street, email address or phone, or the order; shipments of carriers that ask for other buyer data are not tracked in 17TRACK. The postal code is not stored with the query and does not go to the technical logs or the error alerts. From what it returns, the status, the event dates and the destination country are stored; never the places, the address or the carrier's free text.
• To Slack and to Parlo's email (Resend), the quota, first charge and pause notices carry only store data (name, plan, conversations, dates, what is charged and whether a card is missing); to Slack, without the amount. Never data about a customer.

Shopper portal

• The public page cannot read the Controller's credentials: it records the search in the database and the process that works the emails answers it. Only one fixed query is made to Shopify, without address, amounts, customer or items, and the order is only accepted if the number and the email address match in the code.
• What is shown goes through two closed lists (in the code and in the database). An order that does not exist and one with another email address give the same answer, and no search answers before 2 seconds, so that timing does not reveal whether an email address has bought.
• A bot check on every search (without it the portal does not open) and limits counted in the database before knowing anything about the order: 20 searches per connection per hour; 10 per email address per hour and 30 per day at each store; 5 per order per hour; 300 per store per hour; 3,000 in total; and 3 requests per order and 100 per store per day.
• The portal's public address (app.parlodesk.com/p/...) carries a random component of 40 bits per Controller: without it, the page is that of an address that does not exist.
• What the customer asks for in writing and the refund request change nothing in Shopify: they go to the inbox, without a prepared reply, for a person to review them.
• Only the process that works the emails writes the address change in Shopify, never the public page. Only two fixed documents go out through its connection with Shopify (reading that order and changing its shipping address), tied to the action's order; canceling, refunding or any other change is rejected without going out. Right before writing, it checks again that the action is still turned on and, in Shopify, that the order is not canceled, has no shipments and is not being prepared or accepted by a warehouse or a fulfillment service, that the country is the same and, in Spain, that the postal code is from the same province.
• Before recording an address change, verification that whoever asks for it controls the order's email address: single-use code of 6 digits, 10 minutes, 5 attempts, kept only as a fingerprint and deleted when used, exhausted or expired; sent from the Controller's mailbox; at most 3 codes per order per hour and 5 per day, and 30 per Controller per hour and 100 per day. If the Controller's mailbox cannot send it, the change is not offered.
• At most 3 actions per order and 100 per Controller per day; one per search and one in progress per order. What is left halfway is not repeated: the order is read again and, if it is not shown as done, it goes to a person.
• The notices to the Controller of each action carry the order number and, if it is the address, from which to which, or the reason for the refund; never the customer's email address or phone. To Slack, without the address or the reason.
• The page carries no scripts of its own, sets no cookies, is not cached, does not send the referring address and is not indexed.

Human review and automatic sending

• When a person of the Controller approves a reply, sending waits 10 seconds so it can be undone and, before sending, it checks whether someone has already replied from the mailbox.
• The default mode is "Draft" and the Controller chooses another. In every mode, each email goes through the same automated checks, and what fails them stays as a draft.
• Never goes out on its own, and the Controller cannot change this: anything that is not an order tracking query (refunds, returns, cancellations, exchanges and complaints); anything that asks for money or brings a legal claim, a payment dispute, a health problem or harm; anything that offers something or promises actions; the tracking situations that do not graduate (today 2 of 21 can go out on their own: on its way within the expected time and delivered without dispute); the reply to someone who already wrote another email in the last 72 hours; and anything written in a language the service cannot review or that is not enabled to go out on its own. Nor anything above the chargeback risk the Controller sets.
• What goes out on its own carries the signature "The [store name] AI Customer Care Agent", added by the code and not by the model; if it cannot be added, the reply goes back to draft. It waits a few minutes before going out, and during that time any person of the Controller can stop it. Right before sending, the settings at that moment and whether someone already replied from the mailbox are checked again. If the machine-readable mark of the next point cannot go out through the Controller's mailbox (today, Microsoft 365), what was going to go out on its own goes back to draft.
• When the Controller's mailbox allows it, every reply whose text the service writes carries the headers X-Parlo-AI: generated and X-Parlo-Review: human or none, depending on whether a person approved it or not. What goes out on its own always carries them.

End of the service

• When a store leaves, it is cut off immediately: its mailbox is no longer read, what was approved and has not started going out does not go out, and all its credentials are deleted. A store that has been cut off cannot reconnect its mailbox or store credentials while the departure is in progress, and incoming email is not processed.

Backups and continuity

• Daily database backups, encrypted (AES-256, with the key derived through PBKDF2), checked when made and expiring after 30 days at most.
• Automated monitoring of the service every 5 minutes, with restart and alert if it fails.

Annex III. Sub-processors

List in force on the date the Controller accepts this agreement. Later changes follow clause 7.2; Parlo's subprocessors page is informative.

Microsoft, Google (if a Gmail mailbox is connected) and Shopify are not sub-processors of the Processor: they are providers of the Controller itself, which Parlo accesses with the permission the Controller gives. Nor is Slack: if the Controller connects its channel, it is a destination it chooses, and it only receives counts, the store name, links and, in the weekly report, the names of its products and carriers with the most queries, without data about its customers except the order number in the portal notices. The portal's verification code goes out from the Controller's mailbox, through its own email provider, like its replies. Nor is Discord: it receives the error alerts Sentry sends already filtered (error name, store and page), with no data about the Controller's customers, and they are deleted after 90 days at most.

With Parlo's other emails to the people who run each store (the quota, first charge and pause notices, the sign-up link, the PDF copy of the Terms and the weekly report), Resend does not receive data about the Controller's customers: there it processes data for which the Processor is the controller. It is on this list only because of the portal notices.

Annex IV. Suggested text for the Controller's privacy policy

The Controller may adapt this text:

To handle the emails you send us we use Parlo, a service of The Wise Brands LLC that acts as a data processor. Parlo reads the emails that reach our customer support mailbox, looks up your order in our store and uses an artificial intelligence model (Gemini, by Google, in the European Union) to prepare a draft reply. To find out where your shipment is, it checks with the carrier through 17TRACK, a Singapore provider that stores the data in the United States and processes it in China, and that receives the tracking number, the carrier and, in some cases, the destination country or the postal code of the delivery address. With the number, 17TRACK obtains from the carrier the shipment's events, which may include the delivery address, and keeps them until it is asked to delete them. A person on our team reviews each reply before sending it. At the end of some replies there may be a link to rate whether we helped you (we keep your vote and your comment). In our orders portal, run by Parlo, you can see your order's status with its number and your email address and ask us for an address change or a return. To curb abuse it goes through a bot check by Cloudflare, which sees your IP address and your browser. If you do not ask for anything, the number and the email address are not kept for more than half an hour; what you ask for in writing reaches us as an email and a person on our team reviews it. If we have it turned on, you can also change there the shipping address of an order that has not shipped yet, after typing a code we send to the order's email address, and ask us for a refund of an order already shipped, which we decide. The data are stored on a server in Germany. The Wise Brands LLC and some of its providers are United States companies, and 17TRACK is a Singapore company that stores and processes the data in the United States and in China, which involves transfers outside the European Economic Area with the safeguards indicated in Parlo's privacy policy (parlodesk.com/privacidad). The list of its providers is at parlodesk.com/encargados.

If the Controller chooses an automatic mode, it replaces the sentence "A person on our team reviews each reply before sending it" with this one:

Some replies about where your order is are sent without being reviewed by a person; they are signed "The [store name] AI Customer Care Agent". The others are reviewed by a person on our team before being sent.

If the Controller does not open the portal or does not turn on the rating, it removes the sentences about them; if it does not turn on the address change or the refund in the portal, it removes the sentence that begins "If we have it turned on".