B2Shift · Publicado a 3 de agosto de 2026 · Atualizado a 14 de agosto de 2026
A maioria dos incidentes com IA nas empresas não são falhas do modelo. São falhas de acesso: um sistema que conseguia alcançar mais dados do que a tarefa exigia, a agir sem ponto de controlo, sem deixar registo. Os controlos que evitam isso são prática de engenharia comum, aplicada de forma deliberada.
Comece pela minimização e por uma finalidade documentada
A automação atenta ao RGPD começa antes da primeira linha de código: escreva para que serve o fluxo, que dados pessoais precisa mesmo, e durante quanto tempo têm de ser conservados. Depois faça o sistema corresponder. Só devem estar acessíveis os campos e sistemas de que o fluxo realmente precisa — não o CRM inteiro porque era mais fácil conceder.
É também o controlo mais barato de implementar e o mais caro de acrescentar depois. Alargar o acesso mais tarde é uma alteração de configuração; restringi-lo ao fim de um ano a funcionar significa descobrir o que passou silenciosamente a depender dele.
Ponha uma barreira no que não se pode desfazer
Nem todos os passos precisam de aprovação, e tratá-los todos por igual ensina as pessoas a clicar sem ler. Separe as ações por reversibilidade. Ler, classificar, redigir e encaminhar podem normalmente correr sem supervisão. Enviar dinheiro, publicar preços, responder a reclamações, apagar registos e tudo o que chega a um cliente em seu nome merece uma aprovação humana ou, no mínimo, uma janela de espera em que alguém possa intervir.
O acesso por perfil pertence à mesma conversa. A automação deve agir com identidade e permissões próprias, e não a pedir emprestadas as credenciais de um administrador — o que é simultaneamente um problema de segurança e de auditoria, porque depois ninguém distingue a pessoa da máquina nos registos.
Torne cada decisão reconstruível
Cada ação deve deixar um registo de auditoria: o que a desencadeou, que contexto foi usado, o que o sistema decidiu, com que confiança, se uma pessoa aprovou, e o que mudou em consequência. Parece sobrecarga de conformidade até à primeira vez que um cliente contesta algo; nesse momento é a única coisa entre si e um palpite.
O tratamento da confiança pertence aqui também. Um fluxo deve ter um caminho explícito para os casos de baixa confiança: para uma pessoa identificada ou para uma fila, não em silêncio para o melhor palpite. O modo de falha desejável é «isto foi para uma pessoa», não «isto saiu errado e ninguém deu por ela durante três semanas».
Saiba onde corre o modelo e o que ele retém
Faça três perguntas a qualquer fornecedor: onde são processados os dados, são conservados, e são usados para treino? As respostas diferem substancialmente entre os produtos de consumo e os planos empresariais do mesmo fabricante, e entre instalações alojadas e privadas. Para dados regulados, a escolha da instalação — regiões da UE, alojamento privado ou modelos abertos geridos internamente — é uma decisão de conformidade, não uma preferência.
O parecer do Comité Europeu para a Proteção de Dados sobre modelos de IA é a referência a ler antes de fixar uma arquitetura; trata de quando as saídas dos modelos e os dados de treino acionam de facto obrigações de proteção de dados.
O que os controlos técnicos não conseguem fazer
Tudo o que ficou dito reduz o risco. Nada disso estabelece um fundamento legal para o tratamento, redige a sua política de privacidade, decide se é necessária uma avaliação de impacto, nem resolve as suas responsabilidades como responsável ou subcontratante. Isso depende do seu caso de uso concreto e das partes envolvidas, e exige uma revisão jurídica em vez de uma revisão de engenharia. Bons controlos tornam essa revisão simples; não a substituem.
Vamos falar do seu fluxo