Lovable lanza su paquete corporativo: despliegue en AWS y Azure del cliente, inferencia en la UE y políticas de publicación

Lovable, servicio para construir aplicaciones conversando con una IA, ha lanzado un conjunto de funciones pensado para grandes empresas. Lo principal: las aplicaciones y sus datos ya pueden ejecutarse en la cuenta cloud del propio cliente, en AWS o en Azure. Ambas opciones siguen en vista previa cerrada. Deutsche Telekom ha sido la primera en llegar a producción: en octubre puso en marcha sus aplicaciones de Lovable en su propia cuenta de AWS. El resto de las novedades responden a las preguntas habituales de los equipos de seguridad: dónde se ejecuta el código, adónde van las consultas a los modelos y quién puede publicar qué.

La lógica de la versión se apoya en el modelo federado que Lovable observa en sus clientes. Un equipo central de TI o de IA fija las reglas una sola vez, y los departamentos construyen aplicaciones dentro de ellas. La compañía lo llama crecimiento gestionado, en lugar de crecimiento en la sombra.

Los datos se quedan dentro del perímetro del cliente

Deploy on AWS y Deploy on Azure trasladan a la cuenta del cliente los entornos de vista previa (sandboxes), las aplicaciones publicadas, la base de datos, el almacenamiento de archivos y los logs. Todo funciona en una red dedicada. Las aplicaciones acceden a sistemas internos, como el almacén de datos, mediante VPC o VNet peering, y esos sistemas no se exponen a internet público. Lovable se encarga de la instalación y las actualizaciones. Según la compañía, un ejemplo típico es una aplicación de RR. HH. que lee datos del sistema de personal: mientras no esté dentro de la red, no pasará a producción.

Por separado llega Bring your own key. Incluso con el despliegue en la nube propia, el historial de chats y proyectos permanece en Lovable. El administrador conecta su propia clave de cifrado y, si la revoca, Lovable no podrá leer el historial. La función está en vista previa cerrada y por ahora solo funciona con AWS KMS en los espacios de trabajo que usan Deploy on AWS. Azure Key Vault llegará junto con Deploy on Azure.

Para las empresas europeas se ha añadido la inferencia en la UE. Por defecto, las consultas van a los endpoints estándar de los proveedores de modelos, que pueden procesarlas en EE. UU. Con la opción activada, las consultas se quedan en endpoints europeos, tanto durante el desarrollo como en las funciones de IA de las aplicaciones publicadas. Si ningún endpoint europeo puede atender una consulta, esta termina con un error en lugar de enviarse a otra región.

Gestión: Organizations, políticas y Action center

La consola Organizations permite configurar SSO y SCIM a la vez para todos los espacios de trabajo, asignar los grupos del proveedor de identidad a los espacios, bloquear el cambio de ajustes y la creación de espacios no aprobados, y consultar los logs de auditoría de toda la organización. Las aplicaciones internas se pueden publicar para toda la empresa: solo podrán abrirlas los miembros de los espacios de la organización.

Las políticas de los espacios de trabajo bloquean una acción o exigen la aprobación de un administrador o del propietario. Las primeras políticas se refieren a la publicación:

• prohibir la publicación si quedan hallazgos sin resolver con datos personales (sustituye al ajuste Block publishing with PII);
• exigir aprobación para las publicaciones de colaboradores externos;
• prohibir la publicación pública;
• exigir aprobación para las aplicaciones con conectores;
• bloquear la publicación desde direcciones ajenas a los dominios verificados.

Cuando se solicita una aprobación, todos los administradores reciben una notificación en Lovable y por correo. Solo hace falta una nueva aprobación si cambia lo que verifica la política, por ejemplo los conectores o la audiencia. Mientras la solicitud está pendiente, el desarrollo y la vista previa continúan. En las políticas sobre conectores y colaboradores externos, el cuadro de diálogo muestra con qué frecuencia se habrían activado en los últimos 30 días.

Action center reúne las solicitudes de aprobación y las señales de alerta: proyectos sin propietario, un aumento brusco del gasto de créditos, aplicaciones públicas con vulnerabilidades críticas y aplicaciones que llevan meses sin editarse. Está disponible en Business y Enterprise; las solicitudes de aprobación requieren Enterprise.

API y exportación de logs

Lovable API, disponible en Business y Enterprise, permite leer ajustes, miembros y grupos, analítica y resultados de los escaneos de seguridad, además de publicar, despublicar, actualizar y eliminar proyectos. En Enterprise están disponibles las etiquetas de PII y el inventario de seguridad de los proyectos. Los datos sobre créditos y límites se añadirán más adelante. Las claves las crean propietarios y administradores, y también hay clientes OAuth.

Los logs de auditoría se envían a Splunk, Azure Log Analytics, Amazon S3, Google Cloud Storage o Azure Blob Storage cada hora o cada tres horas, y solo con los registros nuevos. Lovable conserva los logs durante 13 semanas, y la exportación genera una copia propia durante el tiempo que se necesite. El acceso a las nubes se realiza con credenciales de corta duración, sin claves de larga duración.

Qué viene después

La hoja de ruta incluye ajustes que se apliquen a la vez a todos los espacios de una organización, paridad de funciones en AWS y Azure con el alojamiento de Lovable, y Deploy on Google Cloud. Las políticas, Action center, la API y la exportación de logs ya funcionan. Para Organizations y las vistas previas cerradas hay que dirigirse al account manager o a [email protected]. Los equipos cuyos prototipos chocan con los requisitos de seguridad deberían comprobar de antemano tres cosas: si necesitan desplegar en su propia nube, si el regulador exige procesar las consultas a los modelos en la UE y qué políticas de publicación activar primero.