Política de privacidad

Esta política explica qué datos personales trata Rekala, con qué finalidad, sobre qué base jurídica, quién más interviene y cómo ejercer tus derechos. Está escrita para describir lo que el software hace realmente, no lo que sería cómodo decir.

1. Quién es el responsable y cómo contactarnos

El servicio Rekala (la aplicación en app.rekala.io y el sitio web rekala.io) lo presta Rekala Labs SpA, sociedad por acciones constituida conforme a la ley chilena, con domicilio en Moneda 812, oficina 601, Santiago, Región Metropolitana, Chile, RUT 78.500.869-3. En adelante, «Rekala» o «nosotros».

Para cualquier asunto de protección de datos, incluido el ejercicio de derechos: privacy@rekala.io.

Delegado de protección de datos: no procede. Representante en la Unión Europea a efectos del artículo 27 del RGPD: no procede.

Puedes presentar una reclamación ante la autoridad de control competente: la Agencia de Protección de Datos Personales de Chile.

2. Dos relaciones distintas: cuándo somos responsables y cuándo encargados

Esta es la distinción más importante del documento, y determina a quién debes dirigirte.

(a) Rekala como responsable del tratamiento

Respecto de nuestros propios usuarios y de quienes visitan rekala.io, decidimos nosotros para qué y cómo se tratan los datos. Es el caso de tu cuenta, tu sesión, la facturación y los registros del servidor web.

(b) Rekala como encargado del tratamiento

Respecto de los datos de los prospectos que un cliente sube a su espacio de trabajo, el responsable es el cliente, no Rekala. El cliente decide a quién contactar, por qué y sobre qué base jurídica; nosotros almacenamos y procesamos esos datos únicamente siguiendo sus instrucciones documentadas, nunca por iniciativa propia, y nunca los compartimos entre espacios de trabajo.

Este reparto no es una declaración de intenciones: está cableado en el producto. Cada cliente acepta un Acuerdo de Encargo del Tratamiento (DPA) versionado, y cada declaración que hace —base jurídica de una importación, lanzamiento de una campaña, aceptación del DPA— queda registrada de forma inalterable junto con la versión exacta del texto que aceptó.

3. Si has recibido un correo enviado con Rekala

4. Datos que tratamos como responsable

De las personas que usan la aplicación:

• Cuenta: dirección de correo, nombre y apellidos, rol dentro del espacio de trabajo, si la cuenta está activa y la fecha de alta. La contraseña no se guarda: se guarda un hash bcrypt del que no puede recuperarse.
• Sesión: un identificador de sesión y su caducidad. El identificador tampoco se guarda en claro: en la base de datos solo vive su hash SHA-256.
• Perfil de remitente: nombre, cargo, empresa, firma, tono e idioma que quieres que use la redacción.
• Preferencias de interfaz (idioma de la interfaz, disposición de algunos paneles).
• Buzón conectado (solo si lo conectas): la dirección verificada del buzón y los tokens que autorizan el envío. Los tokens se guardan cifrados con AES-256-GCM.
• Registros de actividad: aceptaciones del DPA, declaraciones de base jurídica, cambios relevantes y suplantaciones de cuenta por parte de un administrador, con indicación de quién actuó.
• Comentarios que envíes por el formulario de opinión dentro de la aplicación.

De quienes visitan el sitio web rekala.io: El servidor web no mantiene registros de acceso; únicamente los errores operativos quedan en el diario del sistema, que rota automáticamente. El sitio no contiene JavaScript, ni analítica, ni cookies.

5. Datos que tratamos como encargado

Son los datos que un cliente introduce sobre las personas y empresas a las que quiere dirigirse. Los enumeramos con precisión porque es exactamente lo que un responsable necesita saber para cumplir con su propia obligación de información:

Sobre la persona de contacto

• Nombre y apellidos.
• Dirección de correo electrónico (es el único campo obligatorio).
• Empresa y cargo.
• Teléfono.
• Perfil de LinkedIn.
• País.
• Notas y etiquetas escritas por el cliente, y notas de investigación asociadas al contacto.
• Procedencia declarada del contacto y base jurídica que el cliente ha afirmado tener.

Sobre la relación con esa persona

• El texto íntegro de los correos generados (asunto y cuerpo de hasta tres correos por secuencia), sus versiones editadas y el momento en que se marcaron como enviados.
• El texto literal de las respuestas que el cliente pega en la aplicación cuando el prospecto contesta. Puede contener cualquier cosa que esa persona haya escrito, y se conserva tal cual.
• La conversación entre el cliente y el asistente sobre esos correos: instrucciones, correcciones y reglas.
• Eventos de envío y estado dentro de la campaña.
• Si la dirección está en la lista de supresión, y el motivo.

Sobre la empresa del prospecto

• Nombre, sector, tamaño, país, sitio web y notas.
• La información extraída automáticamente del sitio web público de esa empresa.

6. De dónde salen los datos de prospectos

De dos sitios, y solo de dos:

• Los aporta el cliente: importando un fichero CSV o dando de alta el contacto a mano. Al hacerlo debe declarar sobre qué base jurídica lo tiene, y esa declaración queda registrada.
• Investigación automatizada del sitio web de la empresa. Nuestro servidor hace una petición al sitio web público de la empresa del prospecto y extrae información de la empresa. Esta investigación es exclusivamente a nivel de empresa: nunca investigamos a personas.

Cuando esa lectura encuentra direcciones de correo publicadas en la página, actúan dos filtros por diseño, que no son configurables:

1. Solo buzones genéricos. Se aceptan direcciones del tipo info@, contacto@, kontakt@, ventas@ y similares. Una dirección de persona identificada —del tipo nombre.apellido@— se descarta siempre. Nunca recolectamos la dirección de un individuo.
2. Solo el mismo dominio. Únicamente se acepta una dirección del propio dominio de la página que se está leyendo, nunca la de un tercero que aparezca en ella: una agencia en el pie de página, un proveedor, un socio.

Tampoco se «deduce» una dirección que no estuviera literalmente escrita en la página.

7. Finalidades y bases jurídicas

Rekala no utiliza los datos de los prospectos de un cliente para ninguna finalidad propia, ni para mejorar el servicio de otros clientes. El aprendizaje del producto está aislado por espacio de trabajo: nada de lo que ocurre en el de un cliente influye en el de otro.

8. Qué se envía exactamente al modelo de IA — y qué no

Para redactar un correo, el contenido del prompt se envía a Anthropic PBC. Somos concretos sobre qué contiene, porque es la pregunta que hace todo administrador de sistemas y porque es comprobable.

No se envía

El bloque de contacto del prompt contiene únicamente el nombre, la empresa, el cargo y el país del prospecto. La dirección de correo del destinatario nunca se envía al modelo. Tampoco su teléfono ni su perfil de LinkedIn. La dirección solo se usa para entregar el mensaje, en el momento del envío, y ese envío no pasa por el modelo.

No es una afirmación de intenciones: los ocho prompts que el sistema ensambla están congelados byte a byte en una prueba automatizada que se ejecuta ante cualquier cambio, y no contienen ninguna dirección de correo, ningún teléfono ni ninguna referencia a LinkedIn.

Sí se envía

• La identidad del prospecto: nombre, empresa, cargo y país.
• Las notas de investigación que haya escrito el usuario.
• La información extraída del sitio web público de la empresa.
• El texto de las respuestas que el usuario haya pegado, cuando se redacta un seguimiento que debe responder a lo que el prospecto dijo.
• El material del vendedor: propuesta, argumentos, conocimiento de la empresa y los documentos subidos. Cuando un PDF no puede extraerse localmente, el fichero se envía codificado en base64 para que el modelo lo lea.

La consecuencia práctica es importante y conviene decirla: si un usuario escribe datos personales en las notas, o sube un documento que los contiene, esos datos llegarán al modelo. El control sobre eso está en manos de quien escribe.

Anthropic trata estos datos como sub-encargado, bajo contrato, únicamente para devolver la respuesta. Conforme a los términos comerciales de Anthropic, los datos enviados a través de su API no se utilizan para entrenar sus modelos.

9. Sub-encargados y transferencias internacionales

La lista es deliberadamente corta y es cerrada. Cada uno interviene solo en la parte del servicio que le corresponde, bajo contrato escrito con obligaciones de protección de datos equivalentes a las nuestras.

Sobre tu propio proveedor de correo

Cuando un usuario conecta su buzón de Gmail o de Microsoft, el mensaje se entrega a través de la API de ese proveedor con el permiso que el propio usuario concedió, y sale desde su cuenta. Ese proveedor ya es el proveedor de correo del cliente con independencia de Rekala. El permiso puede revocarse en cualquier momento desde la configuración de la cuenta de Google o de Microsoft, o desconectando el buzón dentro de Rekala.

Los sitios web de los prospectos

Durante la investigación, nuestro servidor realiza una petición HTTP al sitio web público de la empresa del prospecto. Ese sitio recibe, como en cualquier visita, la dirección IP de nuestro servidor —no la de ningún usuario ni la de ningún prospecto—. No es un sub-encargado, pero lo declaramos porque es un flujo de datos hacia un tercero.

Cambios en la lista

Antes de añadir o sustituir un sub-encargado que vaya a tratar datos de clientes, lo anunciamos con al menos 30 días de antelación, actualizando esta página y avisando dentro de la aplicación. Un cliente con una objeción razonable y fundada en protección de datos puede plantearla en ese plazo.

10. Conservación, copias de seguridad y borrado

Preferimos ser exactos, incluidas las limitaciones.

• Datos de prospectos: se conservan mientras el cliente los mantenga en su espacio de trabajo. Rekala no borra datos por el paso del tiempo. El producto señala para revisión los contactos con los que no ha habido intercambio en unos 36 meses, pero se limita a mostrarlos: la decisión de conservarlos o eliminarlos es siempre del cliente. No existe ningún borrado automático por plazo.
• Lista de supresión: se conserva de forma indefinida y por diseño. Una negativa a ser contactado no caduca. Cuando se borra un contacto a petición suya, se crea primero la entrada de supresión y después se anula la dirección en claro, de modo que solo queda un hash irreversible que sigue bloqueando cualquier recontacto.
• Registros de cumplimiento (aceptaciones del DPA, declaraciones de base jurídica): son de solo-añadir y se conservan como prueba, sin contenido de los correos.
• Cuenta de usuario: mientras la cuenta esté activa y durante 30 días después.
• Copias de seguridad: se hace una copia completa de la base de datos una vez al día y se conservan las siete más recientes; las anteriores se eliminan automáticamente. Un dato borrado del sistema en vivo puede, por tanto, seguir presente en una copia durante un máximo aproximado de siete días, hasta que esa copia rote.
• Limitación conocida: las filas de sesión caducadas no se purgan automáticamente. Una sesión caducada no sirve para acceder —se rechaza—, pero su registro permanece en la base de datos hasta que se cierra sesión o un administrador la revoca.

11. Seguridad

• Las contraseñas se guardan con bcrypt; nunca en claro y nunca recuperables.
• Los identificadores de sesión se guardan como hash SHA-256. Quien obtuviera una copia de la base de datos obtendría hashes, no credenciales reutilizables.
• Los tokens OAuth del buzón se cifran con AES-256-GCM. El sistema falla cerrado: si la clave falta o el dato está manipulado, el buzón se considera inutilizable en lugar de continuar sin cifrado.
• Los enlaces de previsualización y descarga de ficheros usan tokens de un solo uso, ligados al fichero y al espacio de trabajo, con una validez aproximada de dos minutos, para que la credencial de sesión no viaje nunca dentro de una URL.
• Aislamiento estricto por espacio de trabajo, incluido el aprendizaje del producto: ningún dato ni patrón cruza de un cliente a otro.
• Tres niveles de control de acceso: usuario autenticado, administrador del espacio de trabajo y administrador de plataforma. Las operaciones destructivas y la configuración sensible están reservadas a administradores.
• Cuando un administrador de plataforma actúa suplantando a otra cuenta, queda registrado quién lo hizo.
• Todas las consultas a la base de datos pasan por una guarda global que rechaza valores no escalares, para impedir que un dato de una petición se almacene con un tipo inesperado.
• Cabeceras de seguridad HTTP, lista blanca de orígenes permitidos, límites de frecuencia de peticiones y una protección contra peticiones a redes internas en las funciones que leen sitios web externos.

Ninguna medida elimina el riesgo por completo. Si detectas un problema de seguridad, escríbenos a security@rekala.io.

12. Tus derechos y cómo ejercerlos de verdad

Si el RGPD u otra norma equivalente te resulta aplicable, tienes derecho a acceder a tus datos, rectificarlos, suprimirlos, limitar u oponerte a su tratamiento, y a la portabilidad. También a retirar el consentimiento cuando el tratamiento se base en él, y a reclamar ante una autoridad de control.

Si eres usuario de Rekala

Escríbenos a privacy@rekala.io. Somos el responsable y respondemos directamente.

Si eres un prospecto

El responsable es el cliente de Rekala que te contactó, y es a él a quien corresponde decidir. Lo explicamos en el apartado 3. Nuestra obligación —que cumplimos— es asistirle para que pueda atenderte, y para eso el producto tiene herramientas reales:

• Exportación de acceso: un administrador del espacio de trabajo puede generar un volcado con todo lo que la plataforma guarda sobre un contacto: identidad, procedencia y base jurídica declarada, notas, todas las campañas en que figura, el texto completo de los correos, los eventos de envío, la conversación con el asistente sobre esos correos y su estado en la lista de supresión.
• Supresión: un administrador puede borrar el contacto. La operación crea primero la entrada de bloqueo permanente y a continuación elimina en cascada la ficha, sus pertenencias a campañas, los correos, las ediciones y la conversación asociada. La auditoría registra únicamente recuentos, nunca contenido.

Atenderemos o trasladaremos toda solicitud dentro del plazo legal aplicable, y sin coste, salvo que sea manifiestamente infundada o excesiva.

13. Decisiones automatizadas y elaboración de perfiles

Rekala no adopta decisiones basadas únicamente en tratamiento automatizado que produzcan efectos jurídicos sobre una persona o que le afecten significativamente de modo similar. El sistema redacta texto y clasifica material comercial; la decisión de a quién escribir, y de si un correo sale, es siempre de una persona, y el producto exige esa aprobación humana.

14. Sin cookies: almacenamiento local en tu navegador

La aplicación no usa cookies. La autenticación se hace con un token que se envía en la cabecera de cada petición y que el navegador guarda en localStorage. En ese mismo almacenamiento se guardan algunas preferencias de interfaz. Son datos que permanecen en tu dispositivo, no se envían automáticamente con cada petición como haría una cookie, y puedes borrarlos vaciando los datos del sitio en tu navegador —lo que cerrará tu sesión—.

El sitio web rekala.io no tiene JavaScript, ni analítica, ni cookies, y por eso no muestra ningún aviso de cookies: no hay ninguna que consentir.

15. Recursos externos en este sitio: ninguno

Al abrir cualquier página de rekala.io, tu navegador habla únicamente con rekala.io. No se carga nada desde un servidor de terceros: ni tipografías, ni imágenes, ni scripts, ni iconos. Las tipografías se sirven desde nuestro propio servidor junto con el resto del sitio.

Lo decimos porque hasta el 25 de agosto de 2026 no era así: las tipografías se cargaban desde fonts.googleapis.com y fonts.gstatic.com, de modo que Google recibía la dirección IP de cada visitante solo para entregar una fuente. Esa dependencia se ha eliminado.

16. Lo que no hacemos

Cada una de estas afirmaciones se ha comprobado sobre el código desplegado, buscando la función y confirmando que no existe:

• No vendemos ni cedemos datos personales a nadie, ni los intercambiamos con fines publicitarios.
• No insertamos píxeles de seguimiento en los correos.
• No medimos aperturas.
• No reescribimos los enlaces de los correos ni medimos clics.
• No añadimos copias ocultas (CCO) ni copias (CC) a ningún envío.
• No leemos la bandeja de entrada de Gmail. El único permiso que la aplicación pide a Google es gmail.send, junto con la identificación básica necesaria para saber desde qué dirección se envía. Con ese permiso es técnicamente imposible leer correo. Matiz honesto: la ruta alternativa de Microsoft, que está construida, sí solicita Mail.ReadWrite, porque el envío en hilo con Graph exige crear un borrador antes de enviarlo. Ese permiso se usa exclusivamente para eso.
• Nuestro uso de los datos de usuario de Google es limitado. El uso por parte de Rekala de la información recibida de las APIs de Google se ajusta a la Google API Services User Data Policy, incluidos sus requisitos de Limited Use.
• No usamos analítica de terceros ni en la aplicación ni en el sitio web.
• El sitio web no carga ningún recurso de terceros. Tu navegador solo habla con rekala.io.
• No investigamos a personas. La investigación automatizada es siempre a nivel de empresa.
• No recolectamos direcciones de personas de las páginas web: solo buzones genéricos del mismo dominio.
• No cruzamos datos entre clientes. Ni los datos ni el aprendizaje salen del espacio de trabajo en que se generaron.
• No enviamos nada por iniciativa propia. El envío automático está construido pero inerte: viene desactivado, requiere que el titular arme el transporte, que el cliente acepte el DPA y supere un envío de prueba, y aun así cada correo lo aprueba una persona.

17. Cambios en esta política

Si cambiamos esta política, actualizaremos la fecha y el identificador de versión que figuran al principio. Los cambios sustanciales que afecten a clientes se comunicarán además dentro de la aplicación. La versión vigente es siempre la publicada en esta dirección.