Toda aplicação que usa um modelo externo tem um momento em que o dado do cliente sai da sua infraestrutura. É um momento invisível no código, uma chamada de função como qualquer outra, e é o ponto em que a responsabilidade jurídica muda de configuração.
Vale acompanhar o trajeto inteiro, porque a maior parte das dúvidas se resolve sabendo por onde o dado passa.
O caminho que o dado faz
Uma pergunta digitada por um cliente percorre, tipicamente, cinco etapas:
- Chega à sua aplicação e normalmente é registrada em algum log.
- É enriquecida com contexto, que pode incluir o cadastro da pessoa, o histórico dela ou trechos de documentos.
- É enviada ao provedor do modelo, atravessando a internet e chegando a um servidor que não é seu, frequentemente em outro país.
- É processada e permanece nos registros do provedor pelo tempo que a política dele determinar.
- Volta, e a resposta costuma ser gravada junto com a pergunta no seu banco.
Repare que a etapa dois é onde a maioria dos vazamentos acidentais nasce. O cliente perguntou algo banal, e a aplicação anexou o cadastro completo dele ao prompt por conveniência de implementação.
As três perguntas que definem a exposição
O provedor treina com o que você manda?
Essa é a pergunta mais importante e a que tem a resposta mais variável. Serviços costumam ter políticas diferentes para uso pessoal e uso empresarial via API, e frequentemente diferentes entre planos.
A resposta precisa vir do contrato, não da suposição. E precisa ser verificada de novo quando o contrato mudar, o que acontece mais do que se imagina.
Por quanto tempo o dado fica lá?
Mesmo sem treinamento, provedores retêm requisições por um período, geralmente para monitorar abuso. Esse prazo importa, porque durante ele o dado existe num sistema que você não controla.
Em que país o processamento acontece?
Dado que atravessa fronteira fica sujeito a mais de uma jurisdição. A LGPD trata transferência internacional de forma específica, e isso vira um item de contrato, não um detalhe técnico.
O que a LGPD pede na prática
Sem entrar em análise jurídica, que é trabalho de advogado, há quatro pontos operacionais que caem no colo de quem constrói:
- Finalidade declarada. O uso de IA no tratamento do dado precisa estar dentro do que foi comunicado à pessoa. Se a política de privacidade não menciona, ela está desatualizada.
- Minimização. Só deve ser enviado o necessário para a finalidade. Mandar o cadastro inteiro quando bastava o primeiro nome é exatamente o que esse princípio proíbe.
- Transparência sobre terceiros. O provedor do modelo é um agente no tratamento, e isso precisa aparecer para o titular.
- Direito de exclusão. Se a pessoa pedir que os dados sejam apagados, isso inclui o histórico de conversas guardado na sua aplicação.
Três medidas técnicas que resolvem muito
Mandar menos
É a medida mais eficaz e a mais barata. Antes de montar o prompt, pergunte se cada campo é necessário para a resposta. Na maioria das aplicações, a resposta é não para a maior parte deles.
Mascarar antes de enviar
Quando um identificador precisa aparecer para o modelo entender o contexto, substitua por um marcador. O modelo trabalha com a estrutura e você recompõe o valor real na volta. Documento, telefone e e-mail quase nunca precisam ir em claro.
Definir prazo do seu lado
Histórico de conversa não precisa ser eterno. Definir por quanto tempo guardar e apagar automaticamente depois reduz a superfície de risco e ainda atende ao princípio de retenção limitada.
Quando nada disso basta
Existem casos em que a natureza do dado torna o envio a terceiros inviável, independentemente de contrato. Dado de saúde, informação sob sigilo profissional, segredo industrial, dado sob cláusula contratual de não divulgação.
Nesses casos, a única arquitetura que resolve é rodar o modelo em infraestrutura própria, para que o dado não saia. Modelos abertos ficaram bons o suficiente para tornar isso viável em boa parte das aplicações, e frequentemente essa é a razão que justifica o esforço, mais do que qualquer cálculo de economia.
A pergunta que vale fazer hoje
Se alguém perguntasse agora quais dados de clientes já foram enviados para fora da sua infraestrutura no último mês, você saberia responder?
Se a resposta for não, esse é o primeiro trabalho, antes de qualquer política ou contrato. Mapear o que sai é o pré-requisito de tudo o mais.
Para cenários em que o dado não pode sair do país, a StayCloud opera em data center nacional, o que simplifica bastante a conversa sobre jurisdição.
