Durante três décadas, proteger os dados pessoais significava controlar onde os dados eram armazenados e quem podia aceder à base de dados. As ferramentas de IA desmantelaram esse modelo em cerca de dezoito meses.
Isto não é uma crítica à IA. É a descrição de uma mudança estrutural — e compreendê-la é a diferença entre uma proteção de dados que funciona de facto e uma proteção que fica bem numa auditoria de conformidade mas falha na prática no momento em que um profissional do conhecimento abre uma janela de conversa.
O modelo antigo — e porque funcionava
A proteção clássica de dados pessoais foi concebida para dados estruturados: registos de CRM, sistemas de processos clínicos, bases de Recursos Humanos, livros-razão financeiros. A ameaça era o acesso não autorizado — um atacante ou um colaborador não habilitado a chegar a dados a que não devia chegar.
A resposta era igualmente estruturada:
- Tokenização e cifragem ao nível do campo nas bases de dados: substituir números de segurança social e números de conta por tokens opacos em repouso. Só os serviços autorizados podem resolver o token de volta ao original.
- Controlos de acesso baseados em funções: limitar que colaboradores podem consultar que tabelas. Auditar cada leitura.
- DLP de rede (prevenção de perda de dados): analisar o tráfego de saída em busca de padrões estruturados de dados pessoais — formato de número de segurança social, números de cartão de crédito, padrões de IBAN — e bloquear a exfiltração antes de ela sair do perímetro da empresa.
- Mascaramento de dados em ambientes que não são de produção: testar com dados de aparência realista mas gerados sinteticamente, que não contêm nenhuma identidade real.
Isto funcionava porque os dados viviam em localizações delimitadas e conhecidas. Era possível enumerar os sistemas que continham dados pessoais, cercar as camadas de armazenamento e de rede com controlos, e esses controlos aguentavam-se face ao modelo de ameaça para que foram construídos.
O que as ferramentas de IA mudaram
A superfície de ameaça deslocou-se — não porque as ferramentas de IA sejam inseguras, mas porque introduziram um caminho novo e sem atrito do armazenamento controlado para o processamento externo.
Considere o fluxo de trabalho: um profissional do conhecimento abre o SharePoint, transfere um contrato em PDF, abre o ChatGPT e cola o conteúdo. Estava autorizado a aceder ao documento — nenhum controlo de acesso foi violado. Não exfiltrou dados no sentido técnico — usou um dispositivo aprovado na rede da empresa. Mas o documento, com cada nome, cada morada e cada valor financeiro lá dentro, acabou de transitar para uma infraestrutura cloud comercial sobre a qual a organização não tem visibilidade, que nenhum contrato regula, e da qual não existe nenhum registo de auditoria.
O ferramental de antigamente não tem nenhuma alça sobre isto:
- O DLP de rede deteta padrões estruturados em carregamentos de ficheiros e fluxos de saída, mas a maioria das interações com a IA acontece como pedidos HTTPS POST a uma interface web — o proxy vê o domínio de destino, não o conteúdo do corpo da mensagem.
- A tokenização em base de dados protege os dados pessoais em repouso. Quando o utilizador já transferiu um PDF e o está a ler, os dados já foram extraídos do cofre de tokens, reconstituídos e apresentados. O sistema de tokens fez exatamente o que devia fazer — apenas não foi concebido para o passo seguinte.
- Os controlos de acesso ficaram satisfeitos no instante em que o utilizador autorizado abriu o ficheiro. O que acontece a jusante desse acesso fica fora do seu âmbito, por conceção.
O modelo antigo partia do princípio de que controlar o acesso aos dados significava controlar o que se fazia com eles. As ferramentas de IA romperam essa premissa de forma limpa. Acesso autorizado mais uma janela de conversa equivale a dados a saírem da organização — discretamente, legalmente (do ponto de vista do controlo de acesso), e em volume.
Porque é que a filtragem do lado da cloud não chega
Uma resposta a esta lacuna é encaminhar todo o tráfego de IA por um proxy empresarial que interceta os pedidos, procura dados pessoais, oculta-os e reencaminha a versão higienizada. Esta abordagem existe e é melhor do que nada. Mas tem limites estruturais:
- Exige inspeção SSL do tráfego HTTPS — tecnicamente invasiva, dispendiosa de operar, e cada vez mais contestada pelos modelos de segurança dos navegadores e pela resistência dos colaboradores em nome da sua privacidade.
- Exige configuração por cada ferramenta de IA. À medida que a proliferação das ferramentas de IA acelera, a superfície a configurar cresce mais depressa do que qualquer equipa de segurança consegue acompanhar. Uma nova ferramenta de IA torna-se uma lacuna no instante em que um utilizador a descobre.
- Apanha padrões estruturados de dados pessoais (formato de número de segurança social, IBAN) mas tropeça em nomes em texto livre, moradas e identificadores dependentes do contexto — que constituem a maioria dos dados pessoais nos documentos profissionais.
- Não consegue apanhar o copiar-colar a partir de aplicações fora do âmbito do proxy — dispositivos móveis, máquinas pessoais, fluxos «offline e depois colar».
A filtragem do lado da cloud trata a IA como um canal a vigiar em vez de um comportamento a reestruturar. A ação de fundo — um utilizador que extrai conteúdo sensível de um sistema controlado e o entrega a um serviço externo — continua a acontecer. A filtragem acrescenta um lomba a meio do caminho. Não ataca a raiz.
A comparação em termos claros
Dimensão DLP clássico Anonimização do lado do clienteA fronteira certa: antes da IA, no dispositivo
A intervenção tem de acontecer antes de os dados saírem do dispositivo do utilizador — nem no perímetro da rede, nem dentro da infraestrutura do fornecedor de IA depois do facto consumado.
Isto exige um modelo mental diferente. Em vez de perguntar «como supervisionamos o que os utilizadores enviam para as ferramentas de IA?», a pergunta passa a ser: «como damos aos utilizadores uma versão dos seus documentos que seja, por conceção, segura de enviar a qualquer ferramenta de IA?»
A ideia-chave é que a IA não precisa das identidades para fazer o seu trabalho. Precisa da estrutura, da língua e do contexto. «Alice Martin, nascida a 14 de março de 1987, residente na Rua das Acácias 14, Lyon, referência de cliente A-2091» não diz nada de adicional a um grande modelo de linguagem sobre a cláusula contratual que lhe pedem para analisar. Retire a identidade, mantenha a cláusula. O resultado da IA é igualmente útil — e os dados originais nunca saíram do dispositivo.
Como o promptShield concretiza isto
O promptShield corre inteiramente offline no dispositivo do utilizador — sem inferência na cloud, sem nenhuma chamada de rede durante a anonimização. O pipeline de deteção aplica três camadas a cada documento:
- Regex — padrões estruturados de alta precisão: IBAN, número de segurança social, e-mail, telefone, número de passaporte e outros formatos de identificadores de documentos em 7 línguas europeias. Disparam primeiro, com alta precisão, e não exigem o carregamento de um modelo.
- Deteção de entidades — modelos spaCy e de transformador a correr localmente, que detetam nomes, moradas, organizações e datas em contexto. A mesma entidade que se repete ao longo das páginas é ligada, de modo que anonimizar na página 1 a suprime automaticamente na página 4.
- Passagem opcional por LLM — para os casos ambíguos, um modelo GGUF a correr localmente resolve as deteções no limiar sem enviar dados para lado nenhum.
Cada entidade detetada é substituída por um token tipado e estável: [PERSON_1], [ADDRESS_2], [IBAN_1]. A correspondência entre o token e o valor original é guardada numa base de dados SQLite local — o registo de tokens — que nunca sai do dispositivo.
O utilizador cola o documento anonimizado em qualquer ferramenta de IA. A IA produz a sua análise a partir dos tokens. Quando o utilizador quer aplicar o resultado da IA de volta ao documento original, o promptShield restaura os valores reais. O fluxo de trabalho analítico mantém-se inalterado. A exposição é eliminada por conceção.
O que muda, e o que não muda
A anonimização do lado do cliente colmata uma lacuna específica: o caminho sem atrito de um documento controlado para um serviço de IA externo. Não substitui os controlos de acesso, não substitui a auditoria por registos, e não dispensa a necessidade de formar os colaboradores para um uso apropriado da IA.
O que muda, isso sim, é o modelo de risco especificamente para o caso de uso da IA. Assim que anonimiza antes de colar, a pergunta «o que acontece se um colaborador usar o ChatGPT num documento de cliente?» tem uma resposta diferente. A IA recebe conteúdo estruturado — lógica das cláusulas, rácios financeiros, arquitetura do contrato — sem nenhum identificador associado. Não há nada para expor.
O perímetro antigo era o repositório de documentos. O novo perímetro tem de ser o próprio documento — especificamente, o momento em que ele transita de um sistema delimitado para texto livre nas mãos de um utilizador.
Essa fronteira é a que o DLP clássico nunca foi concebido para aguentar. É a que importa agora.
