Construiu-o com o Lovable — Quem é Responsável Quando Há uma Fuga de Dados?

Um gestor de produto precisa de um painel interno. Em vez de abrir um ticket e esperar um trimestre pela equipa de engenharia, abre o Lovable, descreve o que pretende em linguagem simples, liga-o ao Google Workspace da empresa e lança uma aplicação funcional nessa mesma tarde. Ela lê a Drive, extrai algumas folhas de cálculo e envia um resumo semanal por email. Funciona. Todos ficam satisfeitos.

Ninguém coloca a questão que importa seis meses depois, quando um revisor de segurança ou um regulador o faz: quem é responsável pela forma como essa aplicação trata os dados com que contacta?

A resposta não é a plataforma que gerou o código. É a empresa que a implementou. Este artigo explica por que razão "construímo-lo com IA" não é uma defesa válida, o que corre especificamente mal com aplicações construídas por IA, e como obter visibilidade antes que a pergunta seja feita com indignação.

O que significa realmente "aplicação construída por IA"

Uma nova categoria de ferramentas — Lovable, Base44, Bolt.new, Cursor e uma lista crescente de outras — permite às pessoas construir e implementar aplicações web reais a partir de indicações em linguagem natural. São frequentemente designadas plataformas de "vibe coding". O atrativo é óbvio: alguém sem formação em programação pode produzir algo que antes exigia uma equipa, e fazê-lo em horas.

Estas aplicações não são brinquedos. São implementadas junto de utilizadores reais e ligam-se rotineiramente a sistemas empresariais reais — Google Workspace, Salesforce, bases de dados internas — através de autorizações OAuth comuns. Do ponto de vista dos dados, uma aplicação construída numa tarde com um prompt e uma aplicação construída ao longo de meses por uma equipa de engenharia são idênticas: ambas detêm um token de acesso e ambas podem ler tudo o que esse token permite.

Essa simetria está no cerne do problema. A velocidade que torna os construtores de IA atrativos é a mesma velocidade que permite a uma aplicação alcançar dados sensíveis sem que ninguém reveja o que ela faz com esses dados.

Construir com IA não é o mesmo que estar seguro

Vale a pena ser preciso e justo aqui: uma aplicação construída com o Lovable ou o Base44 não é inerentemente insegura. Estas plataformas podem produzir aplicações perfeitamente razoáveis, e muitas fazem-no. O risco não é a IA escrever mau código. O risco é a governação, e manifesta-se de três formas previsíveis.

Quem a implementa raramente lê o código. Toda a proposta de valor do vibe coding assenta em não ser necessário fazê-lo. Por isso, a pessoa que lançou a aplicação frequentemente não consegue dizer como esta armazena dados, se regista campos sensíveis, para onde envia informação ou durante quanto tempo retém seja o que for. A parte responsável tem a menor visibilidade sobre aquilo pelo qual é responsável.

O acesso é amplo e invisível. Os construtores de IA solicitam os âmbitos (scopes) que fazem a demonstração funcionar, e "fazer funcionar" significa muitas vezes acesso de leitura amplo. Um painel interno que apenas precisava de ler uma pasta pode acabar por deter acesso de leitura a toda a Drive. Como a autorização ocorreu através de um ecrã de consentimento OAuth normal, nunca apareceu no radar de segurança de ninguém — é, por definição, shadow IT.

Não existe uma política documentada de tratamento de dados. Peça a política de retenção de um sistema em produção construído manualmente e normalmente obterá uma resposta. Peça a política de retenção de uma aplicação que um colega gerou na terça-feira passada e não há nada registado. Ao abrigo da legislação de proteção de dados, "não sabemos durante quanto tempo mantém os dados" não é uma resposta neutra — é uma constatação de incumprimento.

Por que razão é a empresa — e não a plataforma — a responsável

Eis a parte que surpreende as pessoas. Quando uma aplicação construída por IA trata mal os dados, a responsabilidade legal e regulatória recai sobre a organização que a implementou, não sobre a plataforma de IA que a gerou.

Esta é a mesma mudança de responsabilização que atualmente reformula o direito da IA em geral. Ao abrigo do Regulamento Geral sobre a Proteção de Dados da UE, a entidade que determina as finalidades e os meios do tratamento de dados pessoais é o responsável pelo tratamento, e é este quem assume as obrigações — fundamento jurídico, minimização de dados, limitação da conservação e o dever de o demonstrar tudo. Quando a sua empresa implementa uma aplicação que trata dados de clientes, a sua empresa é o responsável pelo tratamento. A plataforma construtora é, quando muito, uma ferramenta que utilizou.

O panorama jurídico mais amplo de 2026 aponta na mesma direção. Os tribunais começaram a tratar a empresa que utiliza um sistema de IA como responsável pelo seu comportamento — o processo *Mobley v. Workday*, nos Estados Unidos, prosseguiu com base numa teoria de mandato (agency) e obteve posteriormente a certificação condicional de uma ação coletiva a nível nacional. Na Alemanha, o OLG Hamm abordou a responsabilidade pelo que um sistema de IA comunica aos clientes e sinalizou que uma cláusula genérica de "sem garantia" não protege, por si só, a empresa que o implementa. O AI Act da UE acrescenta obrigações específicas para os implementadores, com penalizações significativas para usos de alto risco. Abordamos essa mudança em profundidade na nossa visão geral sobre quem é responsável quando um agente de IA sofre uma fuga de dados.

O fio condutor comum: implementar uma aplicação construída por IA é uma decisão que a sua organização tomou, e a lei trata as decisões como portadoras de responsabilidade. O facto de uma IA ter escrito o código em nada altera quem escolheu ligá-la aos dados da empresa.

O ponto cego, em concreto

Juntando as peças, surge um modo de falha específico e comum:

• Um colaborador sem formação técnica constrói uma aplicação com um construtor de IA.
• A aplicação liga-se ao Google Workspace através de OAuth e recebe âmbitos amplos.
• Alcança dados pessoais de clientes ou de colaboradores — contactos, conteúdo de emails, ficheiros.
• Ninguém reviu o tratamento de dados, e não existe política de retenção registada.
• A segurança não tem qualquer entrada de inventário para a aplicação, porque esta nunca passou por uma revisão.

Cada passo é, individualmente, razoável. Em conjunto, produzem uma aplicação que trata dados pessoais, pela qual a sua empresa é legalmente responsável, e cuja existência a sua equipa de segurança desconhece. É essa a lacuna que um auditor sonda e que uma violação de dados explora.

Como fechar a lacuna

A solução não é proibir os construtores de IA — essa corrida já está perdida, e o ganho de produtividade é real. A solução é visibilidade e evidência: saber quais as aplicações construídas por IA que estão ligadas, saber a que cada uma pode aceder e ser capaz de demonstrar que foram governadas.

É exatamente isso que a 8200.dev faz. Descobre as aplicações OAuth ligadas ao seu Google Workspace e sinaliza as que têm origem em construtores de IA — Lovable, Base44, Bolt.new, Cursor e semelhantes — a partir das assinaturas de nome de aplicação e de anfitrião de redirecionamento, e a partir do padrão revelador de uma aplicação não verificada, criada recentemente, que já detém âmbitos amplos. Para cada uma, vê a plataforma construtora, os âmbitos exatos concedidos, quem os autorizou e uma pontuação de risco, apresentados numa vista dedicada de AI-Built Apps junto com o restante dos seus agentes de IA e aplicações OAuth.

Quando uma aplicação construída por IA pode aceder a PII de clientes, ou detém acesso amplo sem política de retenção documentada, gera-se uma constatação específica — de modo a que a lacuna se transforme numa tarefa com um responsável, em vez de uma surpresa numa auditoria. E cada aplicação construída por IA pode ser registada no AI Agent Registry, de forma a que mesmo as que nenhum conector alcança apareçam num inventário completo único. Pode ver aqui o conjunto completo de funcionalidades.

O objetivo não é abrandar as suas equipas. É garantir que, quando a pergunta chegar — de um regulador, de um auditor ou de uma revisão de segurança de um cliente — consiga responder-lhe. Não "construímo-lo com IA, por isso é problema da plataforma", o que não constitui defesa, mas sim "aqui está a aplicação, aqui está exatamente a que pode aceder, e aqui está a evidência de que a revimos." Para uma análise mais aprofundada do que os revisores exigem atualmente, veja o que os auditores exigem para a governação de IA em 2026.

Construir com IA é rápido. Ser responsável pelo que construiu não é opcional. As duas coisas conciliam-se através de uma única: saber a que os seus aplicativos construídos por IA podem realmente aceder.

Comece por ver o que já está ligado ao seu Workspace. Pode mapear as suas aplicações construídas por IA, pontuar o seu acesso e gerar a sua primeira evidência no plano gratuito — veja os planos e comece gratuitamente.

*Este artigo constitui informação geral, não aconselhamento jurídico. Consulte um advogado qualificado para orientação específica para a sua organização.*