Lovable detalha regras de segurança para o setor financeiro: logs de auditoria de 13 semanas e EU inference

A Lovable, serviço para montar aplicativos de trabalho a partir de prompts, lançou um guia para diretores de marketing do setor financeiro. A ideia é simples: hoje é possível montar o protótipo de uma campanha em poucas horas, mas a aprovação por compliance e segurança leva semanas. O documento descreve onde passa a fronteira de responsabilidade entre a plataforma e o cliente, quais dados não podem ser carregados na Lovable e como verificar o aplicativo antes da publicação. É um texto de fornecedor, mas traz detalhes concretos suficientes para servir de base a um checklist interno.

Plataforma e aplicativo: dois níveis de proteção

A Lovable divide a segurança em duas camadas. A camada da plataforma inclui criptografia, isolamento de workspaces, identidade corporativa, logs de auditoria, além de detecção, prevenção e remoção de dados pessoais (PII). É essa camada que o time de segurança precisa para avaliar a Lovable como fornecedora. A camada do aplicativo reúne as verificações automáticas sobre o que o próprio usuário construiu: permissões inseguras no banco de dados, chaves vazadas, dependências vulneráveis e falhas no código.

Antes de montar o aplicativo, a empresa sugere responder a cinco perguntas: quais dados estão envolvidos (públicos, internos, pessoais, investimentos confidenciais), quem é o público, o que o aplicativo faz (exibe informações, altera registros, envia mensagens, dá recomendações), qual é o custo de um erro e quem é o dono do aplicativo e pode desativá-lo. São de baixo risco um planejador interno de campanhas com dados sintéticos e o protótipo de uma página de evento. São de alto risco um portal para investidores, o marketing personalizado de fundos, a integração com CRM e ferramentas com avaliações não publicadas. O guia destaca separadamente que "interno" não é sinônimo de "seguro" quando há informações relevantes não públicas (MNPI) no sistema.

A restrição principal está na seção 3.8 do acordo de processamento de dados (DPA) para Business e Enterprise. Ela proíbe o envio de dados sensíveis: números de contas financeiras, identificadores governamentais, dados biométricos e informações médicas protegidas. Nem o controle de acesso nem o EU inference anulam essa proibição.

Conectores, dados e geografia do processamento

A parte mais delicada são os conectores. Há quatro tipos, e a escolha define quem enxerga os dados:

• Chat connector: contexto pessoal na fase de construção (por exemplo, um briefing do Google Drive); não vai para o aplicativo publicado, mas os colegas podem ver os dados em um projeto compartilhado.
• App + chat connector: uma única conta compartilhada para construir e operar o aplicativo; os usuários veem os dados dentro das permissões dessa conta.
• App user connector: cada pessoa trabalha com a própria conta; por exemplo, o gerente vê apenas as suas contas.
• Custom connectors e MCP: o comportamento depende do tipo de conexão escolhido.

Há ainda um alerta: se o aplicativo copia registros para o próprio banco de dados, as permissões do sistema de origem não acompanham essas cópias. O acesso aos dados salvos precisa ser descrito e testado de novo. Segundo o documento, as permissões devem ser aplicadas no backend ou no banco de dados, e não escondendo botões e páginas.

Sobre o treinamento de modelos: o conteúdo de clientes Business e Enterprise (prompts, arquivos, código, resultados) fica fora do treinamento por padrão. No Free e no Pro, os dados podem ser usados até que o usuário recuse. O EU inference está disponível no Enterprise e direciona as requisições aos modelos para pontos de presença europeus; se não houver um adequado, a requisição falha em vez de ser enviada a outra região. As ressalvas são importantes: os limites variam entre provedores, parte dos recursos fica indisponível, algumas ferramentas de agentes ainda processam dados nos EUA, e a configuração não altera o local de armazenamento dos dados do aplicativo. A região do backend do Lovable Cloud é escolhida separadamente.

Logs, planos e checklist antes da publicação

Os logs de auditoria do Enterprise registram alterações em membros, papéis, configurações, conexões e publicações: quem fez, quando, o quê e em qual recurso. Eles são mantidos por 13 semanas, cerca de 90 dias; depois disso, é preciso exportá-los. Ações dentro do próprio aplicativo, como o download de um documento por um investidor ou a aprovação de um envio em massa, não entram nesses logs. Esses eventos precisam ser previstos pelo desenvolvedor.

Sobre os planos: o Pro oferece domínios personalizados e design systems; o Business acrescenta SSO, acesso baseado em papéis, templates de design e a ausência de treinamento com os dados por padrão; o Enterprise inclui logs de auditoria, SCIM e varreduras de segurança programadas. O consumo de créditos deve ser previsto tanto para a construção quanto para a operação: backend, IA e parte dos conectores também gastam créditos.

A ordem prática de ações para a equipe é a seguinte. Primeiro, classifique o projeto pelas cinco perguntas e confira os dados com o DPA. Construa com dados sintéticos.

Para um aplicativo de cinco pessoas, escolha a audiência personalizada no Business e no Enterprise, ou Invite only no Free e no Pro. Teste os dois extremos: um estranho não consegue abrir o dashboard, e o convidado vê apenas os próprios registros. Para ações com consequências, adicione uma etapa de confirmação.

Mantenha os segredos somente no armazenamento Secrets, e não no frontend. Corrija as vulnerabilidades encontradas pelo scanner, teste com contas diferentes e designe um responsável que possa desativar o aplicativo. A plataforma fornece as ferramentas, mas a responsabilidade por dados e permissões continua com você.