Has elegido una región de la UE para tu proyecto desarrollado con Lovable y Supabase. El almacenamiento de archivos está en Fráncfort, el alojamiento en Estocolmo… todo parece estar correctamente ubicado dentro de Europa. Puedes sentirte tranquilo con tu estrategia de residencia de datos.
Hasta que alguien del departamento de compras te pregunta dónde se procesan los correos electrónicos transaccionales de tu aplicación.
La respuesta sincera, en la mayoría de los proyectos desarrollados con Lovable, es: «No lo sé».
Como entusiasta del vibe coding, llevo tiempo explorando herramientas como Lovable o Claude para crear interfaces sobre bases de datos y plataformas cuyo núcleo se basa en la residencia de datos en la Unión Europea. Sin embargo, prácticamente todos los proyectos que he desarrollado hasta ahora se han encontrado con el mismo problema: cómo enviar correos electrónicos.
Cuando hablo de «correo electrónico» en esta serie de artículos sobre Lovable, me refiero a mensajes como: códigos de un solo uso (OTP), confirmaciones de registro, confirmaciones de pedidos, informes periódicos, o cualquier otro correo transaccional necesario para que una aplicación pueda utilizarse a gran escala.
Qué significa realmente la residencia de datos en la UE para una aplicación creada con Lovable
La residencia de datos en la Unión Europea no es una única configuración. Es una propiedad que debe cumplirse en cada uno de los lugares donde tu aplicación procesa datos personales.
Eso incluye:
- la base de datos;
- el sistema de autenticación;
- el almacenamiento de archivos;
- el proveedor de correo electrónico;
- las herramientas de analítica;
- el sistema de seguimiento de errores.
Si cualquiera de estos componentes transfiere datos personales fuera de la Unión Europea sin una base jurídica adecuada, estarás realizando una transferencia internacional de datos regulada por el artículo 44 del RGPD.
En un proyecto típico desarrollado con Lovable existen cuatro puntos principales por los que los datos personales pueden abandonar la Unión Europea. Tres son fáciles de controlar. El cuarto suele pasar desapercibido.
Base de datos. Supabase ofrece regiones europeas, como Fráncfort, Londres o París. Si eliges una de ellas al crear el proyecto, tanto los datos de los usuarios como los datos de la aplicación permanecerán alojados en infraestructura europea.
Autenticación. Supabase Auth se ejecuta en la misma región del proyecto. Los tokens de sesión, los hashes de contraseñas y los flujos OAuth permanecen dentro de la Unión Europea.
Almacenamiento de archivos. Supabase Storage utiliza la misma configuración regional. Avatares, documentos y cualquier otro archivo permanecen almacenados en la región elegida.
Correo electrónico. Aquí es donde suelen aparecer los problemas. Supabase Auth genera los códigos OTP, los enlaces mágicos y los enlaces para restablecer contraseñas, pero delega su envío en un proveedor SMTP. El proveedor hacia el que Lovable dirige a los usuarios por defecto —y que aparece en la mayoría de sus plantillas— es Resend.
Resend es una excelente empresa con un excelente producto. Sin embargo, está constituida en Estados Unidos y opera principalmente sobre AWS US-East-1, en Virginia del Norte. Eso significa que cada correo electrónico transaccional enviado a un usuario francés, alemán o neerlandés pasa por infraestructura estadounidense y es procesado por una entidad establecida en Estados Unidos.
Descubre por qué es importante alojar los datos en la UE desde una perspectiva legal.
¿Por qué los desarrolladores suelen pasar por alto el correo electrónico?
Existe una explicación perfectamente comprensible. Cuando los fundadores evalúan la residencia de datos, normalmente piensan en dónde se almacenan los datos. ¿Dónde está la base de datos? ¿Dónde están los archivos? Estas preguntas tienen respuestas sencillas.
El correo electrónico es diferente. El email es datos en movimiento. Sale del sistema cada vez que se envía un mensaje y, por ello, no suele percibirse como un aspecto relacionado con la residencia de datos.
Sin embargo, desde el punto de vista del RGPD, sí lo es.
Un correo para restablecer una contraseña contiene:
- la dirección de correo electrónico del usuario (un dato personal);
- el código OTP;
- normalmente, también el nombre del usuario y alguna referencia a su cuenta.
Cuando ese mensaje se genera, se pone en cola, se transmite y queda registrado en la infraestructura del proveedor de correo, dicho proveedor actúa como encargado del tratamiento.
Y el lugar donde se realiza ese tratamiento entra plenamente dentro del ámbito de aplicación de las normas sobre transferencias internacionales de datos.
Si tu proveedor de correo está ubicado en Estados Unidos, dependerás del Marco de Privacidad de Datos UE-EE. UU. (EU-US Data Privacy Framework) o de las Cláusulas Contractuales Tipo (SCC) para legitimar la transferencia.
Actualmente ambos mecanismos son válidos desde el punto de vista jurídico.
Pero ambos han sido cuestionados por autoridades de protección de datos y organizaciones de defensa de la privacidad. Además, sus dos predecesores —Safe Harbor (2015) y Privacy Shield (2020)— fueron anulados por el Tribunal de Justicia de la Unión Europea.
Si estás desarrollando un producto serio, especialmente destinado a grandes empresas europeas, administraciones públicas, organizaciones sanitarias o entidades financieras, probablemente no quieras que toda tu estrategia de correo transaccional dependa de la estabilidad futura de esos mecanismos jurídicos.
La solución más sencilla es mantener el correo electrónico dentro de la Unión Europea desde el principio.
Dónde se alojan realmente los proveedores de correo más habituales
A continuación se muestra una referencia rápida para los proveedores que suelen utilizar los desarrolladores de Lovable.
La cuestión no es que los proveedores estadounidenses sean malos. No lo son. Ofrecen excelentes productos y APIs muy bien diseñadas.
Pero si ya has invertido tiempo en configurar Supabase dentro de la Unión Europea y en construir toda tu infraestructura sobre servicios europeos, enviar el correo electrónico transaccional a través de un proveedor estadounidense rompe esa estrategia de residencia de datos.
Qué debería significar realmente «correo electrónico alojado en la Unión Europea»
Algunos proveedores afirman disponer de opciones europeas, aunque determinados metadatos, copias de seguridad o incluso el soporte técnico sigan pasando por infraestructura estadounidense. La página comercial dice «Europa». La auditoría de cumplimiento cuenta otra historia.
Antes de elegir un proveedor conviene plantearse preguntas como:
- ¿Dónde se procesan y almacenan realmente los mensajes?
- ¿Dónde se almacenan los registros de rebotes, quejas y métricas de interacción?
- ¿Dónde se encuentran los subencargados del tratamiento?
- ¿Desde dónde accede el equipo de soporte a los datos?
- ¿Dónde se almacenan las copias de seguridad?
- ¿Cuál es la entidad jurídica con la que realmente firmas el contrato?
En el caso de Spotler SendPro, toda la infraestructura permanece dentro de la Unión Europea. El procesamiento principal, los registros, los subencargados, el soporte y la entidad contractual están ubicados en Europa. No existe una ruta alternativa hacia infraestructura estadounidense para los datos de los mensajes. Este tipo de detalles adquiere una enorme importancia cuando el responsable de protección de datos de un cliente empresarial revisa tu lista de proveedores.
Spotler SendPro es la API de correo electrónico elegida por numerosas organizaciones europeas que consideran la entregabilidad un aspecto crítico. Desde startups nacidas mediante vibe coding hasta multinacionales que envían millones de correos electrónicos al día, SendPro constituye la infraestructura sobre la que se apoya su comunicación por email.
Lee más sobre Spotler SendPro
Cómo integrar SendPro en un proyecto desarrollado con Lovable
Esta es la parte práctica —y algo más técnica—. Supabase Auth necesita un proveedor SMTP o basado en API para enviar códigos OTP, enlaces mágicos y mensajes de confirmación. Sustituir el proveedor predeterminado por SendPro requiere únicamente un prompt y cinco variables de entorno.
Un prompt que suele funcionar correctamente desde el primer intento es:
«Sustituye el envío de correo electrónico de este proyecto por Spotler SendPro utilizando OAuth2. Utiliza la documentación de la API disponible en: https://flowmailer.com/apidoc/sendpro-api.html«
Lovable genera entonces una implementación limpia que incluye:
- una caché de tokens en memoria con margen de seguridad respecto al tiempo de expiración;
- reintentos automáticos cuando se recibe un error 401;
- un mecanismo de degradación que registra mensajes en la consola cuando aún no se han configurado las credenciales, evitando que el entorno de desarrollo deje de funcionar.
Posteriormente deberás configurar las siguientes variables de entorno:
SENDPRO_CLIENT_ID: identificador de cliente obtenido en el panel de SendPro.SENDPRO_CLIENT_SECRET: secreto asociado al cliente OAuth.SENDPRO_ACCOUNT_ID: identificador de la cuenta.SENDPRO_FROM_EMAIL: dirección de correo verificada utilizada como remitente.SENDPRO_FROM_NAME: nombre que aparecerá como remitente.
Si utilizas los flujos estándar de Supabase para enviar correos de confirmación, recuperación de contraseña o enlaces mágicos, también deberás configurar el servidor SMTP de Supabase para que utilice el relay SMTP de SendPro. Así, tanto los correos enviados por Supabase como los enviados por la propia aplicación utilizarán la misma infraestructura europea.
Lista de comprobación de residencia de datos para aplicaciones desarrolladas con Lovable
Antes de presentar un proyecto desarrollado con Lovable a un cliente europeo exigente, revisa los siguientes aspectos:
- Confirma que Supabase utiliza una región europea.
- Verifica que las copias de seguridad de la base de datos permanecen dentro de esa región.
- Comprueba que el almacenamiento de archivos utiliza la misma región.
- Confirma que Supabase Auth se ejecuta dentro de la región del proyecto.
- Verifica dónde procesa realmente los datos tu proveedor de correo, incluidos sus subencargados y la entidad contractual.
- Si utilizas analítica, recuerda que PostHog dispone de instancia europea; Google Analytics, en la práctica, no.
- Si utilizas Sentry, asegúrate de haber seleccionado su región europea.
- Si tu aplicación utiliza APIs de OpenAI, Anthropic u otros proveedores similares, documenta esas transferencias hacia Estados Unidos y analiza los acuerdos de retención cero de datos cuando sea necesario.
- Documenta también la infraestructura de alojamiento (hosting) del frontend, ya que muchas redes de distribución de contenido operan desde Estados Unidos.
- Asegúrate de disponer de un acuerdo de tratamiento de datos (DPA) actualizado con todos los encargados del tratamiento, incluido SendPro.
El correo electrónico ocupa el quinto lugar de esta lista. Y, paradójicamente, suele ser el elemento que con más frecuencia pasa desapercibido, precisamente porque la recomendación predeterminada del asistente de IA puede ir en contra de toda tu estrategia de residencia de datos.
En resumen
Crear una aplicación desarrollada con Lovable que mantenga íntegramente la residencia de datos en la Unión Europea es perfectamente posible. Una combinación de Supabase en una región europea, Spotler SendPro, herramientas europeas de analítica y monitorización de errores permite conseguirlo. Pero solo si eliges cuidadosamente cada una de las capas de tu arquitectura. Y la capa del correo electrónico es, con diferencia, la que casi todo el mundo pasa por alto.
Si quieres profundizar en cómo encaja SendPro dentro de un proyecto desarrollado con Lovable, consulta la página de producto de Spotler SendPro, donde se explica su infraestructura europea, así como la documentación de la API, que incluye todos los detalles necesarios para la integración mediante OAuth2.
