DCODER

Tag: lgpd

  • LGPD e agentes de IA no atendimento: o que garantir antes de ligar o bot

    A empresa que contrata o atendimento continua sendo a controladora dos dados. O fornecedor da automação é operador. Antes de ligar o bot, é preciso ter aviso de privacidade atualizado, contrato com termo de processamento, controle sobre onde os dados ficam e um caminho claro para exclusão a pedido do titular.

    Quando o atendimento passa a ser feito por um agente conversacional, nada muda na estrutura de responsabilidade da LGPD. E é justamente por isso que muita gente erra. A tentação é achar que “é a IA que está atendendo”. Perante a lei, é a sua empresa.

    Quem é o quê nessa relação

    A empresa que atende os clientes decide por que e como os dados são tratados, então ela é a controladora. Quem construiu e mantém a automação trata os dados em nome dela, então é a operadora. O fornecedor do modelo de linguagem entra como suboperador, e isso precisa estar declarado em algum lugar.

    A consequência prática aparece rápido. Se um cliente pedir exclusão dos dados ou reclamar do tratamento, quem responde é a empresa contratante. Ela precisa ter como cumprir o pedido, o que significa ter acesso e controle sobre a base, sem depender da boa vontade de um fornecedor.

    A base legal costuma ser mais simples do que parece

    Quando o cliente inicia a conversa pedindo um atendimento, o tratamento dos dados necessários para responder se apoia na execução de contrato ou em procedimentos preliminares a ele. Você não precisa pedir consentimento formal para responder a quem perguntou o preço de um serviço.

    O cuidado está nos usos adicionais. Usar aquele contato para disparo de marketing depois, enriquecer cadastro, ou treinar modelo com o conteúdo das conversas. Esses usos têm base legal própria e alguns exigem consentimento específico. É aqui que se cria problema, não no atendimento em si.

    Dado sensível pede atenção redobrada

    Clínica é o caso mais evidente. Uma mensagem como “preciso remarcar minha sessão de fisioterapia” contém dado de saúde, que tem proteção reforçada. Isso não impede a automação, mas exige alguns cuidados:

    • Coletar o mínimo necessário. O agente não precisa perguntar diagnóstico para marcar horário.
    • Restringir quem enxerga a conversa dentro da empresa, com contas individuais e registro de acesso.
    • Definir por quanto tempo o histórico fica guardado e apagar quando o prazo vence, automaticamente.

    O que precisa estar no contrato com o fornecedor

    Peça e confira:

    1. Termo de processamento de dados, deixando explícito que a contratante é controladora e o fornecedor é operador, com a finalidade descrita.
    2. Lista de suboperadores. Qual provedor de modelo de linguagem, qual hospedagem, qual provedor de mensageria.
    3. Onde os dados ficam e o que acontece com eles no encerramento do contrato, incluindo exportação e prazo de eliminação.
    4. Compromisso de não usar os dados para treinar modelos. Os provedores corporativos oferecem essa garantia nos planos de API. Confirme que ela está sendo usada.
    5. Procedimento de incidente. Quem avisa quem, em quanto tempo, e quem comunica a autoridade e os titulares se for o caso.

    O aviso ao cliente é simples e obrigatório

    São duas coisas. A pessoa precisa saber que está falando com um sistema automatizado e precisa ter um caminho para falar com um humano. Uma linha na primeira mensagem resolve o primeiro ponto. Um “atendente” que realmente funcione resolve o segundo.

    Além disso, o aviso de privacidade da empresa precisa mencionar o atendimento automatizado por WhatsApp, quais dados são tratados e por quanto tempo. É atualização de meia página, e é o que costuma estar faltando.

    Checagem antes de ligar

    • Aviso de privacidade atualizado e acessível.
    • Contrato com termo de processamento assinado.
    • Acesso ao painel com conta individual por pessoa, sem senha compartilhada.
    • Prazo de retenção definido e rotina de exclusão funcionando.
    • Caminho testado para atender pedido de exclusão de um titular.
    • Backup com restauração testada, porque perder dados de clientes também é incidente.
    • Transbordo para humano funcionando e visível.

    Automatizar bem melhora a conformidade

    Vale dizer o outro lado dessa história. O cenário anterior, com conversas no celular pessoal de cada funcionário, sem registro, sem controle de acesso, sem prazo de retenção e saindo da empresa junto com quem pede demissão, é bem pior do ponto de vista de proteção de dados.

    Um atendimento centralizado, com contas individuais, registro de acesso, retenção definida e exclusão automatizada, é mais fácil de auditar e de defender. Automação feita direito é ganho de conformidade, não risco novo.

    A DCODER implanta atendimento com IA com contrato formal, termo de processamento de dados e infraestrutura sob controle do cliente. Fale com o estúdio em dcoder.io.

  • Política de uso de IA em uma página: o que precisa estar escrito

    Uma política de uso de IA que funciona cabe em uma página e responde a quatro perguntas: o que pode ser colado numa ferramenta de IA, o que nunca pode, quem responde pelo resultado, e o que fazer quando sai errado. Documento maior que isso não é lido, e política não lida não protege ninguém.

    A maior parte das empresas está no pior dos mundos: a equipe já usa IA todos os dias, e não existe nada escrito. Não é caso de proibir — proibição empurra o uso para o celular pessoal, onde ninguém vê. É caso de escrever a regra que já deveria existir.

    Por que uma página, e não vinte

    Política longa é escrita para o auditor e ignorada pela equipe. O objetivo aqui é outro: que alguém no segundo dia de casa leia em três minutos e saiba o que fazer. Se precisar de mais de uma página, o que sobra vira anexo.

    As quatro seções

    1. O que pode entrar

    Liste o que é liberado, por nome. Ambiguidade gera consulta ao gestor, e consulta ao gestor gera atalho.

    • Texto público da empresa: material de marketing, conteúdo do site, descrição de produto.
    • Documento interno sem dado pessoal e sem número financeiro: procedimento, manual, roteiro de treinamento.
    • Código de projeto próprio, quando o contrato com o cliente permite.
    • Rascunho, resumo de reunião e tradução que a pessoa vai revisar antes de usar.

    2. O que nunca entra

    Esta é a seção que a empresa precisa acertar, e é curta de propósito:

    • Dado pessoal de cliente — nome com CPF, endereço, telefone, e-mail, histórico de compra.
    • Dado sensível — saúde, biometria, dado de criança, origem racial, convicção religiosa ou política.
    • Credencial — senha, chave de API, token, certificado, string de conexão.
    • Informação sob acordo de confidencialidade, incluindo código e documento de cliente.
    • Número financeiro não divulgado — faturamento, margem, folha, proposta em negociação.

    E uma frase que evita metade das dúvidas: na dúvida sobre um dado, ele não entra.

    3. Quem responde pelo resultado

    Este é o ponto que mais falta nas políticas que circulam por aí. A regra é uma linha, e não admite exceção:

    Quem envia responde pelo que sai. O modelo não assina, não responde a processo e não é citado em auditoria. Se um texto gerado por IA vai para um cliente, quem apertou o botão respondeu por ele.

    Do que decorre uma lista curta do que exige revisão humana antes de sair:

    • Qualquer texto enviado a cliente, fornecedor ou órgão público.
    • Qualquer número que embase uma decisão.
    • Qualquer código que vá para produção.
    • Qualquer conteúdo publicado com o nome da empresa.

    4. O que fazer quando erra

    Modelos erram, e erram com confiança. A política precisa dizer o que acontece depois, sem transformar o episódio em caça às bruxas — senão o próximo erro é escondido.

    • Quem percebeu avisa o responsável pela área no mesmo dia.
    • O erro é anotado em um registro simples: o que aconteceu, o que causou, o que mudou.
    • Se saiu dado que não podia sair, o caso vira incidente e segue o procedimento de segurança que já existe.
    • A política é revista quando o mesmo tipo de erro aparece duas vezes.

    Três linhas que vale acrescentar

    Ferramentas autorizadas. Nomeie as que a empresa contratou e diga que outras precisam de aprovação. Sem lista, cada um usa a que achou primeiro.

    Conta corporativa, não pessoal. Contas de trabalho costumam ter configuração diferente de retenção e de uso do conteúdo para treino. É a diferença mais barata que existe entre risco alto e risco baixo.

    Avisar quando o cliente fala com um sistema. Se a empresa atende por agente automatizado, a pessoa precisa saber disso e ter um caminho para falar com um humano. Além de boa prática, virou obrigação legal em vários mercados.

    O que não colocar

    Não coloque lista de modelos permitidos por versão — envelhece em semanas. Não coloque promessa de percentual de produtividade. Não copie política de outra empresa sem adaptar: a lista do que nunca entra depende do que a sua empresa trata.

    Como colocar no ar

    1. Escreva a versão 1 em uma hora, com o que você já sabe. Ela não precisa ser boa, precisa existir.
    2. Mostre para duas pessoas que usam IA todo dia e pergunte o que a política proíbe que elas já fazem. A resposta é o mapa do problema real.
    3. Publique num lugar único, com data e responsável no rodapé.
    4. Marque a revisão daqui a seis meses no calendário. Sem data marcada, não acontece.

    Uma política de uma página, escrita e conhecida, protege mais do que um manual de trinta que ninguém abriu.

    A DCODER organiza o uso de IA dentro de empresas: inventário, regra escrita, fonte única e medição de uso. Converse com o estúdio em dcoder.io.