Lovable detalla sus reglas de seguridad para el sector financiero: logs de auditoría de 13 semanas y EU inference

Lovable, un servicio para construir aplicaciones de trabajo mediante prompts, ha publicado una guía para directores de marketing del sector financiero. La idea es sencilla: un prototipo de campaña ya puede montarse en cuestión de horas, pero la aprobación de cumplimiento normativo y de seguridad lleva semanas. El documento describe dónde termina la responsabilidad de la plataforma y dónde empieza la del cliente, qué datos no se pueden cargar en Lovable y cómo revisar la aplicación antes de publicarla. Es un texto de proveedor, pero contiene suficiente concreción como para usarlo de base en una lista de verificación interna.

Plataforma y aplicación: dos niveles de protección

Lovable divide la seguridad en dos capas. La capa de plataforma incluye cifrado, aislamiento de los espacios de trabajo, identidad corporativa, logs de auditoría, y también detección, prevención y depuración de datos personales (PII). Es la que necesita el equipo de seguridad para evaluar a Lovable como proveedor. La capa de aplicación son las comprobaciones automáticas de lo que ha construido el propio usuario: permisos inseguros en la base de datos, claves filtradas, dependencias vulnerables y agujeros en el código.

Antes de construir, la compañía propone responder a cinco preguntas: qué datos se manejan (públicos, internos, personales, inversiones confidenciales), quién es la audiencia, qué hace la aplicación (muestra información, modifica registros, envía correos, da recomendaciones), cuál es el coste de un error y quién es el propietario de la aplicación y puede desactivarla. Un riesgo bajo sería un planificador interno de campañas con datos sintéticos o un prototipo de página de un evento. Un riesgo alto sería un portal para inversores, marketing personalizado de fondos, una integración con CRM o herramientas con valoraciones no publicadas. La guía subraya por separado que «interno» no equivale a «seguro» si dentro hay información material no pública (MNPI).

La restricción clave es la sección 3.8 del acuerdo de tratamiento de datos (DPA) para Business y Enterprise. Prohíbe transferir datos sensibles: números de cuentas financieras, identificadores gubernamentales, datos biométricos e información médica protegida. Ni el control de acceso ni EU inference anulan esta prohibición.

Conectores, datos y geografía del procesamiento

La parte más delicada son los conectores. Hay cuatro tipos, y de la elección depende quién verá los datos:

• Chat connector: contexto personal durante la construcción (por ejemplo, un brief de Google Drive). No llega a la aplicación publicada, pero los colegas pueden ver los datos de un proyecto compartido.
• App + chat connector: una única cuenta compartida para construir y para el funcionamiento de la aplicación; los usuarios ven los datos dentro de los permisos de esa cuenta.
• App user connector: cada persona trabaja con su propia cuenta; por ejemplo, un gestor ve solo sus cuentas.
• Custom connectors y MCP: el comportamiento depende del tipo de conexión elegido.

Hay una advertencia aparte: si la aplicación copia registros a su propia base de datos, los permisos del sistema de origen no los acompañan. El acceso a las copias guardadas hay que describirlo y probarlo de nuevo. Según el documento, los permisos deben aplicarse en el backend o en la base de datos, no ocultando botones y páginas.

Sobre el entrenamiento de modelos: el contenido de los clientes de Business y Enterprise (prompts, archivos, código, resultados) queda excluido del entrenamiento por defecto. En Free y Pro, los datos pueden usarse mientras el usuario no lo rechace. EU inference está disponible en Enterprise y dirige las solicitudes a modelos en puntos de acceso europeos; si no hay uno adecuado, la solicitud termina con un error en lugar de enviarse a otra región.

Las salvedades son importantes: los límites de los proveedores difieren, una parte de las funciones no está disponible, algunas herramientas de agentes siguen procesando datos en EE. UU. y el ajuste no cambia el lugar de almacenamiento de los datos de la aplicación.

La región del backend de Lovable Cloud se elige por separado.

Logs, tarifas y lista de verificación antes de publicar

Los logs de auditoría de Enterprise registran los cambios en participantes, roles, ajustes, conexiones y publicaciones: quién, cuándo, qué y sobre qué recurso. Se conservan 13 semanas, aproximadamente 90 días; después hace falta exportarlos. Las acciones dentro de la propia aplicación, como la descarga de un documento por un inversor o la aprobación de un envío, no aparecen en estos logs; esos eventos tiene que preverlos el desarrollador.

En cuanto a las tarifas: Pro ofrece dominios personalizados y sistemas de diseño; Business añade SSO, acceso por roles, plantillas de diseño y ausencia de entrenamiento con los datos por defecto; Enterprise suma logs de auditoría, SCIM y escaneos de seguridad programados. El gasto de créditos conviene presupuestarlo tanto para la construcción como para la operación: el backend, la IA y parte de los conectores también los consumen.

El orden práctico de actuación para un equipo es el siguiente. Primero, clasifique el proyecto con las cinco preguntas y compruebe los datos con el DPA. Construya con datos sintéticos.

Para una aplicación de cinco personas, elija audiencia personalizada en Business y Enterprise, o Invite only en Free y Pro. Compruebe ambos extremos: un ajeno no abre el dashboard y un invitado ve solo sus propios registros. Para las acciones con consecuencias, añada un paso de confirmación.

Guarde los secretos solo en el almacén Secrets, no en el frontend. Corrija las vulnerabilidades que detecte el escáner, pruebe con distintas cuentas y designe a un propietario que pueda desactivar la aplicación. La plataforma ofrece herramientas, pero la responsabilidad sobre los datos y los permisos sigue siendo suya.