IA de atendimento com rastreabilidade verificável, não uma demo bonita

Imagine um sábado às onze da noite. Um cliente escreve ao assistente da seguradora, do banco ou da loja: «O pagamento já foi aplicado? Aparece uma cobrança que não reconheço». O assistente responde com amabilidade, com boa redação e com total segurança: «O pagamento está em processamento, fique tranquilo». Ele não consultou o sistema de cobrança, porque não tem acesso. Respondeu com o que sabia do assunto em geral. Na segunda-feira, o cliente liga para o executivo de conta e repete tudo desde o início.

Essa cena não é uma falha do modelo de linguagem; ela ilustra um risco de desenho: um assistente pode responder com desenvoltura e, ainda assim, não ter o acesso, a permissão ou o contexto necessários para resolver um caso real. Uma demonstração, com o cenário limpo, raramente deixa ver esse risco.

Este artigo é para quem responde pelo atendimento ao cliente, pela operação, pela tecnologia ou pelo compliance em um banco, uma fintech, uma seguradora, uma rede de varejo ou uma empresa regulada. Ele defende uma ideia: um assistente de IA que atende a qualquer hora pode resolver, com controle, quando ao menos cinco capacidades existem antes de ligá-lo, e se a empresa puder mostrar a um auditor ou a um cliente o que ele fez, com qual dado e por quê.

Por que os assistentes ficam na demo

Uma demonstração funciona porque o cenário é limpo: um cliente de teste, três perguntas ensaiadas, nenhum sistema real no meio. O que acontece depois, em uma operação com décadas de sistemas acumulados, tem duas formas frequentes de fracassar.

A primeira: o assistente não toca os sistemas reais. Responde sobre políticas, horários e perguntas frequentes, mas não consegue consultar um saldo, o status de um sinistro, uma apólice ou um pedido. Quando o cliente pergunta pelo caso dele, o assistente só pode pedir desculpas ou transferi-lo. Vira um buscador de perguntas frequentes com boa dicção.

A segunda é mais perigosa: toca os sistemas, mas sem controle. Alguém entrega um usuário genérico com permissões amplas «para que funcione», ou conecta um acesso temporário que fica para sempre. O assistente agora consegue consultar e agir, mas ninguém sabe dizer com precisão a quais dados acessou, em nome de quem, nem quem autorizou essa ação. Em uma demonstração isso não aparece. Em uma reclamação perante a autoridade, aparece.

O dado de mercado aponta na mesma direção, com uma ressalva de método. Dado da Gartner: em uma pesquisa com 5.728 clientes realizada em dezembro de 2023, a Gartner informou que apenas 14 % dos problemas de atendimento e suporte foram resolvidos por completo no autoatendimento; entre os que os clientes descreveram como «muito simples», o número foi de 36 % [3]. É uma pesquisa com consumidores, não uma linha de base do México nem de um setor específico; deve ser lida como sinal. O número distingue responder de resolver; não demonstra, por si só, a causa de cada falha. Nos casos que exigem consultar informação atual ou iniciar um trâmite, o comitê deve verificar quais dados e ações estão autorizados para o assistente.

O que precisa um assistente que de fato resolve

Quando um assistente deixa de ser demonstração e passa a operar, precisa de cinco capacidades. Quatro são técnicas e uma é de processo.

1. Identidade: saber com quem fala e em nome de quem atua

Antes de mostrar um dado, o assistente deve saber que quem escreve é quem diz ser, e com qual nível de confiança. O nível de confiança não é determinado só pelo canal: deve ser definido conforme os sinais disponíveis e o risco da ação. Uma conversa iniciada no WhatsApp não equivale automaticamente a uma sessão autenticada com os controles definidos pela organização. A regra útil é que o assistente não eleve por conta própria o nível de confiança: se a consulta é sobre um saldo ou uma alteração de dados, ele pede uma verificação compatível com o risco e, se ela não for concluída, não avança. O mesmo vale ao contrário: o próprio assistente deve ter uma identidade própria nos sistemas, não a credencial compartilhada de uma pessoa.

2. Permissões: o mínimo, para o concreto

Um assistente de atendimento não precisa de acesso a todo o sistema; precisa consultar o status de uma operação do cliente já identificado e, talvez, iniciar um trâmite delimitado. Essa diferença, entre «pode ver tudo» e «pode fazer estas três coisas sobre este cliente», é a que separa um risco administrável de um que um comitê de riscos teria dificuldade em aceitar. Cada ação deve estar definida de antemão, com um alcance limitado e, quando possível, com a possibilidade de ser revertida.

3. Dados do cliente: só os necessários, e à vista do titular

Aqui entra a lei, e ela será vista mais adiante. A ideia de fundo é operacional: quanto mais dados pessoais passam pelo assistente, mais superfície há para proteger. Convém saber qual dado ele consulta, para qual finalidade, onde é processado, quais fornecedores intervêm e por quanto tempo a conversa é conservada.

4. Registro de atividades: poder reconstruir qualquer conversa

É a capacidade mais subestimada e a que mais pesa quando algo dá errado. Para cada interação, importa poder reconstruir: quem perguntou e como foi verificado, qual dado foi consultado, o que o assistente respondeu, qual ação executou, qual versão das instruções e do modelo estava ativa e quando ocorreu. Um registro que guarda apenas o texto da conversa não basta; o que serve registra também o que o assistente fez nos sistemas. E deve estar protegido contra alteração, porque um registro que alguém pode editar não é evidência.

5. Passagem para um humano: sair a tempo, com contexto

O assistente deve saber quando não deve continuar: uma reclamação formal, um cliente irritado, um caso fora do alcance dele, uma dúvida que não consegue verificar. E, ao passar o caso, a pessoa deve receber o contexto necessário e pertinente para resolver o caso (o que já foi verificado, o que foi consultado e o histórico que se justifique), para que o cliente não precise se repetir. Uma boa passagem para um humano não é um fracasso do assistente; faz parte do controle. Um assistente que nunca escala costuma ser um assistente que responde o que não sabe.

O que diz a nova lei de dados pessoais

A Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP, lei federal mexicana de proteção de dados pessoais em posse de particulares) que vigora hoje é uma lei nova: foi publicada no Diario Oficial de la Federación (DOF, o diário oficial do governo federal mexicano) em 20 de março de 2025, substituiu a de 2010 e o texto vigente inclui uma reforma de 14 de novembro de 2025. A autoridade que a aplica é agora a Secretaría Anticorrupción y Buen Gobierno (secretaria federal anticorrupção e bom governo) [1]. Cinco pontos do texto importam a quem opera um assistente de IA. Resumimo-los a seguir; a aplicação deles a um fluxo, um canal e um setor concretos deve ser validada com as áreas jurídica e de compliance.

• Aviso de privacidade em canais eletrônicos (art. 16). Quando os dados são obtidos por um meio eletrônico, o aviso deve ser dado na modalidade simplificada, com a informação básica e o site onde se consulta o aviso integral. Se dados pessoais forem coletados em um chat ou no WhatsApp, convém validar com a área jurídica como o aviso simplificado e o acesso ao integral são disponibilizados nesse fluxo, e incluí-los desde o primeiro contato [1].
• Finalidade (art. 11). O tratamento deve se limitar às finalidades do aviso; para uma finalidade distinta é necessário obter novamente o consentimento. Se a ideia é reutilizar conversas para treinar ou melhorar o assistente, convém verificar se o aviso da empresa o prevê [1].
• Medidas de segurança e confidencialidade (arts. 18 e 20). Exigem-se medidas administrativas, técnicas e físicas contra a perda, a alteração ou o acesso não autorizado, proporcionais ao risco e à sensibilidade dos dados, e controles para que quem intervém no tratamento guarde confidencialidade [1]. As permissões mínimas e o registro de atividades da seção anterior são a versão prática dessa exigência.
• Decisões automatizadas (art. 26, fração II). A pessoa titular pode se opor, por causa legítima, ao tratamento quando ele for automatizado, produzir efeitos jurídicos indesejados ou afetar de maneira significativa os interesses, direitos ou liberdades dela, e estiver destinado a avaliar, sem intervenção humana, determinados aspectos pessoais ou a analisar ou prever, entre outros, a situação econômica, a confiabilidade ou o comportamento; a lei exceta os casos em que o tratamento seja necessário para cumprir uma obrigação legal [1]. Se o fluxo puder produzir efeitos jurídicos indesejados ou afetar de maneira significativa uma pessoa por meio de tratamento automatizado, convém revisar o direito de oposição com a área jurídica. Convém também definir, como controle de risco, quais decisões exigem revisão humana.
• Direitos ARCO e prazos (art. 2, frs. VII e VIII; arts. 22 a 31 e 58). A pessoa titular pode pedir acesso, retificação, cancelamento ou oposição (ARCO). O responsável deve comunicar a determinação dele em no máximo vinte dias a partir do recebimento da solicitação, e a lei define «dias» como úteis; o prazo pode ser ampliado uma vez por um período igual se as circunstâncias o justificarem. Não atender a uma solicitação sem razão fundamentada é uma infração [1]. Convém que o chat identifique e encaminhe uma possível solicitação ARCO ao mecanismo previsto no aviso de privacidade, que a identidade e os requisitos sejam validados (art. 28) e que a data de recebimento seja guardada; e cancelar nem sempre é apagar de imediato, porque a lei prevê um período de bloqueio (art. 24).

Uma nota de prudência: a lei remete ao Regulamento dela para vários procedimentos, e no fechamento deste artigo a compilação da Câmara dos Deputados listava apenas o Regulamento publicado em 2011, expedido para a lei anterior [5]. Por isso, além desta lei, convém confirmar com a área jurídica o regulamento, as disposições secundárias e a regulação setorial vigentes na data da leitura; qualquer deles pode precisar as obrigações acima.

As reclamações: onde o registro de atividades vira defesa

Para as entidades financeiras que o artigo 3, fração IX, da lei enumera (instituições de crédito, sociedades financeiras de objeto múltiplo, sociedades financeiras populares e comunitárias, cooperativas de poupança e crédito, uniões de crédito e instituições de tecnologia financeira), convém verificar se o fluxo do assistente se enquadra no procedimento de esclarecimentos. A Ley para la Transparencia y Ordenamiento de los Servicios Financieros (LTOSF, lei mexicana de transparência e ordenamento dos serviços financeiros; art. 23) diz que, nas operações e serviços celebrados por contratos de adesão massivos e até os valores máximos fixados pela autoridade (a CONDUSEF), quando um cliente não concorda com um lançamento, pode apresentar uma solicitação de esclarecimento dentro de noventa dias corridos contados da data de corte ou, conforme o caso, da operação ou do serviço; que a entidade deve acusar o recebimento e que, uma vez recebida a solicitação, tem no máximo quarenta e cinco dias para entregar ao cliente um parecer com cópia da evidência considerada e um relatório detalhado que responda a todos os fatos apresentados [2]. A lista de entidades financeiras dessa lei não inclui as seguradoras: se a empresa é seguradora, o circuito de reclamações dela é fixado pela Ley de Protección y Defensa al Usuario de Servicios Financieros (o art. 50 Bis exige de cada instituição financeira, seguradoras incluídas, uma unidade especializada para consultas e reclamações, que deve recebê-las por qualquer meio que facilite o recebimento e responder por escrito em um prazo que não exceda trinta dias úteis) e pela regulação de seguros [4]. As nuances de cada tipo de reclamação e de cada autoridade constam da regulação setorial; convém que a área de compliance as confirme.

O que importa aqui para um assistente é uma consequência prática. Nem toda mensagem de chat é, por si só, uma solicitação formal de esclarecimento. Se o canal está habilitado para recebê-la, ou se o fluxo identifica e encaminha a solicitação, a conversa pode fazer parte do processo e conservar evidência útil. Se o assistente disse algo incorreto, ou se o cliente o disse e ninguém registrou, a instituição chega ao parecer sem evidência. Um registro completo e consultável converte essa conversa em insumo para responder; um registro que não existe a converte em lacuna.

Por isso a pergunta do comitê não é «quantos contatos o assistente absorve?». É: o que acontece quando um contato se converte em reclamação? As disposições da CONDUSEF sobre as unidades especializadas já exigem, em qualquer meio de recebimento, inclusive o eletrônico, acusar o recebimento, atribuir um número de protocolo e indicar o prazo de resposta, e manter os antecedentes à disposição da Comissão por dois anos [6]. Essas disposições exigem acusar o recebimento, atribuir número de protocolo e indicar o prazo de resposta, e conservar antecedentes e resoluções por dois anos. O restante é um objetivo interno de serviço, que convém fixar e testar em exercícios de controle: que seja registrado com número de protocolo, data e hora, que passe à pessoa certa sem perder o que foi conversado e que alguém possa recuperá-lo em minutos, não em dias. Isso pesa tanto quanto qualquer percentual de contenção.

Cenário (ilustrativo; não corresponde a nenhum cliente real. Os prazos de reclamação em seguros são fixados por outra regulação; o princípio, chegar ao processo com evidência, é o mesmo). Uma seguradora de porte médio habilita um assistente para informar o status de sinistros por WhatsApp. Um segurado pergunta pela reclamação dele e recebe «em análise, sem pendências». Duas semanas depois apresenta uma queixa: diz que lhe foi pedido um documento e que ninguém o comunicou. Se a seguradora consegue reconstruir qual status o assistente consultou, a que horas e com qual resposta, tem elementos para confrontar o caso e sustentar a resposta. Se só conserva um resumo genérico, o processo depende da memória do segurado e da do executivo de conta.

Cinco perguntas para o próximo comitê

1. Com qual identidade o nosso assistente atua em cada sistema? Se é uma conta compartilhada ou com permissões amplas, o primeiro achado já está feito.
2. Conseguimos reconstruir, em minutos, qualquer conversa? Com quem falou, qual dado consultou, qual ação fez, qual versão estava ativa. Teste com uma conversa escolhida ao acaso.
3. Onde residem os dados pessoais que passam pelo assistente e quais fornecedores intervêm? O nosso aviso de privacidade cobre essa finalidade? Cada fornecedor atua como operador ou como terceiro, e isso está documentado? Como detectaríamos e notificaríamos uma violação de segurança (art. 19)?
4. Quando uma conversa vira reclamação ou solicitação ARCO, quem a recebe, com qual número de protocolo e em quanto tempo? Como ela chega com todo o contexto?
5. Se o assistente der uma informação equivocada, quem responde, como se corrige e como fica documentado?

Quanto mais respostas forem «não sei», mais provável é que não falte um modelo melhor, mas conectar e governar o que já existe.

Antes de aprovar um caso de uso

Para comparar propostas, convém pedir evidência do caso específico que se quer habilitar: os dados e fornecedores envolvidos; as ações permitidas e as excluídas; uma amostra do registro de atividades e da passagem para uma pessoa; o responsável de negócio; e o critério de aceitação. Assim o comitê compara escopo, risco e evidência, não apenas uma demonstração.

Por onde começar esta semana

Não é preciso iniciar um projeto amplo. Escolha uma conversa de amostra cujo acesso esteja autorizado e controlado, de preferência com os dados minimizados, e peça à equipe que reconstrua, no papel, estes cinco elementos: como a pessoa foi verificada, qual sistema foi consultado e com qual permissão, o que o assistente respondeu, onde ficou registrado e quem teria sabido se tivesse sido uma reclamação. Documente as lacunas encontradas e priorize-as por risco: o que não puder ser reconstruído indica por onde começar.

Faça o mesmo exercício com uma conversa que o assistente tenha passado a uma pessoa: chegou todo o contexto?

O que a Hábil faz

A Hábil trabalha justamente onde um assistente deixa de ser demonstração: conectar a IA aos sistemas que já operam, com identidade, permissões delimitadas, registro do que ela faz e passagem a uma pessoa quando couber. A Hábil AI é a oferta para conectar capacidades de IA aos sistemas da organização; a Nova é o assistente virtual voltado ao atendimento. Quando o caso exigir processamento em infraestrutura sob o controle da organização, o alcance, os fornecedores e os controles devem ser definidos para esse caso. Para decidir quem entra em cada sistema, veja Controlar quem entra; para unir os canais e sistemas, Unificar a operação e os canais.

A primeira conversa de diagnóstico é sem custo: dela sai uma primeira leitura do mapa das integrações e dos pontos onde provavelmente se perdem dinheiro, tempo ou evidência. Escreva para nós pelo WhatsApp.