Protótipos rápidos de IA, problemas lentos de compliance: quando apps internas viram risco RGPD

Cadeado e pasta sobre superfície neutra, governance de dados e acessos

A história do The Guardian sobre “rogue AI agents” é útil por uma razão muito simples: comprime num só artigo um erro que já está a entrar em empresas normais [1].

Não falo de laboratórios estranhos, nem de cenários de ficção. Falo de equipas a montar apps internas com IA e a ligá-las a CRM, email, propostas, contratos, tickets, drives partilhados e ferramentas operacionais. O padrão é sempre parecido. A ideia começa pequena, o protótipo resulta, alguém pede “já agora liga isto ao resto”, e de repente a empresa tem software a tocar em dados reais sem ter tratado da parte chata. Há um nome para isto: vibe coding. Descreves o que queres, o modelo escreve, corre na primeira tentativa. O problema é que “corre” significa “faz a coisa”: não diz nada sobre que dados toca, que acessos pede, ou o que acontece quando se liga a algo real.

É essa parte chata que interessa. A notícia chama-se “rogue agents”. A dor real chama-se permissões largas, contas partilhadas, conectores mal pensados, logs mal geridos e dados pessoais metidos no circuito porque dava jeito.

Vejo muita conversa sobre IA feita como se o problema estivesse lá longe, nos modelos, nos labs, nos nomes grandes. Para uma PME, o problema costuma estar bem mais perto. Está na app interna feita à pressa por alguém que queria poupar 20 minutos por dia e acabou por criar um sistema com acesso a informação de clientes, colaboradores ou candidatos.

Onde isto começa a descambar

Uma empresa não precisa de construir um “agente autónomo” para se meter num problema sério. Basta fazer 3 ou 4 escolhas preguiçosas seguidas.

A primeira é óbvia. Alguém cola dados pessoais numa ferramenta porque é mais rápido do que estruturar o processo. CVs, notas de entrevistas, emails de clientes, tickets com nomes e contactos, notas comerciais, resumos de reuniões. Nada rebenta na hora. O risco entra na mesma.

A segunda é dar à app mais acesso do que ela precisa. Uma pasta vira o drive inteiro. Um pipeline vira o CRM todo. Um assistente que devia sugerir texto passa a poder exportar, escrever ou enviar. Nos testes da Irregular, que deram origem à peça do Guardian, os agentes encontravam caminhos porque os caminhos estavam lá, abertos [2].

A terceira é misturar instruções e conteúdo sem grande disciplina. Quando a app lê documentos, páginas wiki, emails, tickets ou qualquer conteúdo recuperado por pesquisa, a fronteira entre dados e instruções fica muito mais frágil. O OWASP já trata prompt injection como um dos riscos práticos centrais em sistemas com LLMs [5]. Isto deixou de ser curiosidade académica.

A quarta é espalhar conectores por todo o lado e fingir que isso continua a ser um protótipo inocente. SharePoint, Google Drive, Slack, Microsoft 365, CRM, ERP, ticketing, APIs internas, servidores MCP, automações de terceiros. Cada ligação abre mais uma porta. Também abre mais uma pergunta que alguém devia ter feito antes: que dados podem sair por aqui, quem aprovou isto, e quem revoga o acesso quando a experiência acaba.

A quinta é usar uma conta técnica partilhada e seguir em frente como se a auditabilidade fosse detalhe. Quando há um incidente, a conversa degrada-se depressa. Quem correu a app? Que dados viu? Que output gerou? Houve revisão humana? Se ninguém consegue responder sem adivinhar, já estamos a trabalhar para trás.

O RGPD entra mais cedo do que muita gente imagina

É aqui que vejo empresas a tropeçar. A ferramenta ainda cheira a protótipo, mas o enquadramento já mudou.

Assim que uma app interna de IA toca em emails, CRM, documentos, tickets, CVs, notas de RH, outputs identificáveis ou logs com dados pessoais, o tema já está dentro do RGPD [3][7]. A tecnologia pode parecer nova. As perguntas são antigas.

Que dados estão a entrar?

Para que finalidade?

Quem tem acesso?

Quanto tempo fica tudo guardado?

Que fornecedor está no circuito?

Há contrato, visibilidade administrativa e controlo suficiente sobre retenção e uso posterior?

A tentação aqui é tratar tudo como detalhe técnico. Costuma sair caro. O EDPB voltou a sublinhar, no seu parecer sobre IA, que estas análises continuam a ser feitas caso a caso, e que chamar “anónimo” a um sistema mal anonimizado não resolve nada [3]. Também convém lembrar outra coisa simples: utilidade não é base legal.

A CNIL bate no mesmo ponto de forma mais operacional. Recolher muito dado porque a ferramenta aguenta é uma escolha com consequências. Guardar prompts e outputs para sempre porque armazenamento é barato também [7]. Quando uma empresa monta uma app interna com memória, logs, integrações e dados reais, cada decisão de conveniência vai ficar à vista mais tarde.

Os dados de colaboradores merecem ainda mais cuidado. Sempre que a app toca em avaliações, notas internas, métricas ou processos de RH, a conversa fica mais sensível. Já vi demasiada gente tentar resolver isto com “consentimento”. É uma solução preguiçosa e fraca.

E a NIS2?

A NIS2 entra na conversa, mas não da forma preguiçosa que já se vê por aí.

Nem toda a empresa que monta uma app interna com IA passa magicamente a estar no âmbito da NIS2. Essa leitura é curta. Ao mesmo tempo, muitas empresas vão sentir pressão real por via contratual, por exigência de clientes, por cadeias de fornecimento mais apertadas e por controlos mínimos que deixam de ser opcionais.

Na prática, a NIS2 puxa a conversa para temas que estas apps também tocam depressa: gestão de incidentes, continuidade, supply chain, MFA, controlo de acessos, evidência, capacidade de resposta [8]. Para algumas organizações, isso será obrigação direta. Para muitas outras, será disciplina imposta pelo mercado.

Foi essa a ideia central no meu artigo recente sobre a NIS2 em Portugal. O tema raramente fica confinado ao jurídico. Acaba por cair na operação. E é aí que dói.

O que eu faria antes de ligar uma app destas a produção

Eu gosto de protótipos rápidos. Uso-os. Servem para perceber depressa se há utilidade real. O erro aparece quando o protótipo ganha conectores, memória e permissões, e ninguém pára para lhe chamar sistema.

Antes de ligar isto a produção, eu queria 5 coisas resolvidas.

Primeiro, um caso de uso com fronteiras. A app vai resumir, pesquisar, sugerir, aprovar, enviar, ou fazer o quê exatamente?

Segundo, classes de dados definidas. O que pode entrar e o que fica de fora?

Terceiro, identidade própria. Conta de serviço dedicada, permissões mínimas, separação entre leitura e escrita, revogação simples.

Quarto, revisão humana nos pontos onde o custo de errar dispara: envio externo, exportações, links públicos, alterações de permissões, aprovações financeiras, ações operacionais sensíveis.

Quinto, logs úteis e retenção limitada. O suficiente para investigar. Não uma lixeira eterna de prompts, outputs e dados pessoais.

Nada disto é glamoroso. Também não devia ser. A maior parte do trabalho sério em IA interna hoje tem esta textura: disciplina operacional, não demos.

O problema lento aparece depois da demo

É isso que a peça do Guardian ajuda a lembrar. O estrago raramente começa com um grande momento de falha. Começa com uma sequência de pequenas concessões que parecem razoáveis na altura.

“Dá acesso a esta pasta também.”

“Liga ao email para ficar mais útil.”

“Usa esta conta técnica, depois arrumamos.”

“Guarda tudo para já, logo vemos.”

“É só interno.”

Já vi esta história demasiadas vezes, em formatos diferentes, para a tratar como detalhe. Quando a app toca em sistemas vivos e em dados reais, deixou de ser experiência de fim de semana.

Se a sua empresa já está a testar assistentes internos, copilots ou automações com IA ligadas a CRM, email, documentos ou outras ferramentas operacionais, vale a pena fazer primeiro uma revisão curta de governance e implementação. Que dados entram, que acessos existem, que ferramentas fazem sentido, o que fica em sandbox, e que controlos precisam de existir antes do rollout.