Um agente de IA que opera navegador costuma falhar em campos com máscara porque escreve o valor inteiro de uma vez. O JavaScript que aplica a máscara (telefone, CPF, CNPJ, CEP, data, valor) espera eventos de teclado, um caractere por vez. Quando recebe “11987654321” de uma vez, ele pode rejeitar, truncar ou reformatar o texto de forma errada.
A correção prática é simples: validar o formato antes de enviar, entender o que o campo aceita, e reler o valor depois de preencher. Sem isso, o agente confirma sucesso enquanto o campo ficou vazio ou pela metade.
Resumo rápido
- Máscara é JavaScript que reage a cada tecla; texto colado de uma vez burla esse fluxo.
- Digitar caractere a caractere e colar o valor completo produzem resultados diferentes no campo.
- Validar o formato antes de enviar evita retrabalho e cadastros quebrados.
- Reler o campo depois de preencher é a única prova de que o valor entrou certo.
- Campos de dígitos puros e campos com pontuação exigem tratamentos distintos.
- CPF e CNPJ têm dígitos verificadores: formato válido não garante número real.
- Dados cadastrais sensíveis pedem uma checagem humana antes de salvar.
Por que a máscara quebra o preenchimento automático
Uma máscara de entrada é um trecho de JavaScript que observa o campo e reformata o conteúdo conforme o usuário digita. Cada tecla dispara eventos como keydown, input e, ao sair do campo, blur. A máscara lê o valor, remove o que não é número, recoloca parênteses, pontos e hífens, e devolve o texto formatado ao campo.
Quando um agente insere o valor inteiro de uma só vez, o evento chega uma única vez, com o texto completo. Muitas máscaras não preveem esse caso. O resultado costuma cair em três padrões: rejeição (o campo volta vazio), truncamento (só os primeiros caracteres ficam) e embaralhamento (a máscara insere pontuação em posições erradas porque conta caracteres que ela mesma adicionou).
Há ainda o campo que reformata no blur. Nesse tipo, o valor parece correto enquanto o cursor está no campo, mas muda no instante em que o foco sai. O agente lê o valor antes do blur, considera tudo certo, e o formulário envia outra coisa.
Digitar caractere a caractere versus colar o valor completo
A diferença entre os dois métodos explica a maioria das falhas. Digitar tecla a tecla reproduz o comportamento humano: cada input dispara a máscara, que ajusta o texto progressivamente. É mais lento, porém previsível.
Colar o valor completo é rápido, mas pula o fluxo incremental. Alguns frameworks escutam apenas os eventos de teclado e ignoram a inserção direta no valor do campo. Nesse caso, o conteúdo aparece na tela e some no momento do envio, porque a máscara nunca processou os caracteres.
A escolha depende do campo. Se a máscara reage a eventos de teclado, digitar tecla a tecla é mais seguro. Se o campo aceita o valor completo e formata depois, colar pode servir, desde que o agente confirme a leitura após o blur.
Validar o formato antes de enviar
Validar o formato antes de qualquer envio economiza retrabalho. O custo de checar o padrão é baixo; o custo de descobrir depois que o CRM salvou um telefone sem DDD é alto, porque envolve corrigir registros, reenviar mensagens e ligar para clientes.
A validação deve comparar o valor com o padrão esperado usando expressões regulares. Telefone brasileiro com DDD tem 11 dígitos; CPF tem 11 dígitos; CNPJ tem 14; CEP tem 8. Se o número de dígitos não bate, o agente para e não envia. Melhor interromper do que salvar errado.
Como conferir o valor depois de preencher
A releitura do campo é a verificação mais importante e a mais esquecida. Depois de preencher, o agente deve ler o valor atual, tirar a máscara (comparar só os dígitos) e confirmar que bate com o que pretendia inserir. Se a leitura divergir, o passo falhou.
A releitura precisa acontecer após o blur, quando o campo já reformatou. Ler durante a digitação mostra um estado intermediário e engana o agente. O roteiro correto é: preencher, sair do campo, ler o valor final, limpar a pontuação e comparar com o número de origem.
Campos de dígitos puros versus campos com pontuação
Alguns formulários aceitam só dígitos no envio e aplicam a máscara na exibição. Outros exigem a pontuação e rejeitam o valor sem ela. Confundir os dois é fonte constante de erro.
O agente precisa descobrir qual é o caso antes de preencher. A dica costuma estar no atributo do campo, no texto de ajuda ou no comportamento da máscara. Quando o formulário valida no servidor, o erro aparece só no envio, o que atrasa a descoberta. Testar com um valor de exemplo e reler o resultado é mais confiável do que supor.
Tipos de campo, formato esperado e erro típico
A tabela abaixo reúne os campos mais comuns e o erro que aparece com mais frequência quando o preenchimento é feito de uma vez.
| Campo | Formato esperado | Erro típico do agente |
|---|---|---|
| Telefone | (XX) XXXXX-XXXX (11 dígitos) | Trunca o DDD ou grava sem pontuação e o envio por WhatsApp falha |
| CPF | 000.000.000-00 (11 dígitos) | Perde os dois últimos dígitos e ainda passa se a checagem for fraca |
| CNPJ | 00.000.000/0000-00 (14 dígitos) | Máscara insere barra no lugar errado e a validação do servidor rejeita |
| CEP | 00000-000 (8 dígitos) | Campo autocompleta o endereço cedo e o agente sobrescreve depois |
| Data | DD/MM/AAAA | Formata como MM/DD/AAAA ou inverte dia e mês |
| Valor monetário | R$ 1.234,56 (vírgula decimal) | Usa ponto como decimal e o valor entra multiplicado por cem |
| Percentual | 12,5 ou 12.5% | Símbolo fora de lugar ou valor gravado como texto sem conversão |
Repare que dois campos podem aceitar o mesmo número de dígitos (telefone e CPF, sete pontos e telefone com DDD) e ainda assim exigir tratamentos distintos. Por isso a validação precisa checar o tipo de campo, não apenas a quantidade de caracteres.
Cuidados com CPF e CNPJ: dígitos verificadores
CPF e CNPJ carregam dígitos verificadores: os últimos dois (CPF) e dois (CNPJ) são calculados a partir dos demais. Um agente que só confere o formato, 11 ou 14 dígitos com a pontuação certa, aceita números que passam no padrão mas não existem.
Validar os dígitos verificadores é uma checagem de consistência, não de existência. Ela reduz a chance de salvar um número inventado ou transcrito errado, mas não substitui a confirmação do titular. Para cadastro de clientes, a validação matemática é o mínimo antes de qualquer integração com emissão de boleto ou nota.
O risco de o agente confirmar sucesso sobre um campo vazio
Esse é o erro mais perigoso porque é silencioso. Se o agente não relê o campo, ele não tem como saber que a máscara rejeitou o valor. Ele registra “sucesso”, o fluxo continua, e o problema só aparece depois, quando o documento não sai ou a mensagem não chega.
Confirmar sucesso exige evidência: ler o campo, comparar com o valor original e, quando o sistema oferecer, conferir a resposta do servidor. Um alerta na tela não prova que o dado foi gravado. A tela pode mostrar o valor antigo por cache, ou o formulário pode ter recarregado sem salvar.
A checagem humana para dados cadastrais sensíveis
Dados cadastrais alimentam cobrança, atendimento e obrigações fiscais. Um erro neles contamina vários processos ao mesmo tempo. Por isso, mesmo com agente automatizado, uma revisão humana antes de salvar é prudente em duas situações: cadastros novos e alterações de dados de contato.
A revisão não precisa ser do formulário inteiro. Basta conferir os campos críticos em uma tela de resumo, com o valor original e o valor lido lado a lado. É a diferença entre automatizar a digitação e delegar a responsabilidade pelo dado errado.
Exemplo: escritório contábil em Campinas (SP)
Um escritório em Campinas usa um agente para cadastrar clientes em um CRM. O agente preenchia telefone e CPF colando o valor completo, sem digitar tecla a tecla. Os registros começaram a acumular números truncados e CPFs sem os últimos dígitos, porque a máscara do CRM rejeitava parte da entrada sem avisar.
Os sintomas apareceram no dia a dia. O envio de boleto falhava porque o CNPJ gravado estava com a pontuação errada e a validação do emissor recusava. O atendimento por WhatsApp não encontrava o número porque faltava o DDD. A equipe só percebeu ao cruzar os erros com as reclamações de clientes.
A correção seguiu três passos: validar o formato e os dígitos verificadores antes de qualquer envio, preencher caractere a caractere nos campos com máscara que escutavam teclado, e reler cada campo após o blur comparando só os dígitos. Cadastros novos passaram a exigir uma conferência humana em uma tela de resumo antes de salvar. O efeito foi menos retrabalho, sem números de resultado a apresentar neste texto.
Erros comuns
- Inserir o valor completo em campos cuja máscara só reage a eventos de teclado.
- Ler o campo antes do
blur, quando a formatação final ainda não aconteceu. - Confiar no alerta de sucesso da tela sem verificar o valor gravado.
- Validar só o número de dígitos e ignorar os dígitos verificadores de CPF e CNPJ.
- Assumir que todo campo de telefone aceita a mesma máscara, inclusive com nono dígito.
- Deixar o agente salvar dados cadastrais sem nenhuma conferência humana.
Perguntas frequentes
Por que colar o telefone completo faz a máscara rejeitar o valor?
Porque a máscara escuta eventos de teclado, um por caractere. A inserção direta no valor do campo não gera esses eventos, então a máscara nunca processa o texto e o conteúdo pode sumir no envio.
Digitar tecla a tecla sempre resolve o problema?
Resolve o caso mais comum, mas não todos. Alguns campos reformatam no blur e mudam o valor depois do preenchimento. Por isso a releitura do campo continua necessária em qualquer cenário.
Como saber se o campo aceita só dígitos ou exige pontuação?
Teste com um valor de exemplo, saia do campo e leia o resultado. O comportamento da máscara e a resposta do servidor mostram o formato aceito. Supor é o caminho mais caro.
Validar o CPF pelo dígito verificador garante que ele existe?
Não. A validação confere a consistência matemática e pega erros de transcrição e números inventados, mas não confirma que aquele CPF pertence a alguém na base da Receita Federal.
Um alerta de sucesso na tela é prova de que o dado foi salvo?
Não. A tela pode mostrar valor em cache ou o formulário pode ter recarregado sem gravar. A prova é reler o campo e, quando houver, conferir a confirmação do servidor.
Quando vale pedir revisão humana?
Em cadastros novos e em alterações de dados de contato, que costumam alimentar cobrança e atendimento. Uma tela de resumo com valor original e valor lido já reduz a maioria dos erros.
Fontes e leitura recomendada
- Documentação da Anthropic para Claude: guias de uso de ferramentas por agentes.
- Documentação de plataforma da OpenAI: conceitos de function calling e structured outputs.
- Google AI for Developers: documentação de modelos Gemini e uso de ferramentas.
- MDN: evento blur: quando o campo perde o foco e dispara a formatação final.
- MDN: elemento input tipo tel: comportamento esperado de campos de telefone.
- WAI: WCAG 2.2, critério On Input: como a mudança automática de conteúdo deve se comportar.
Para aprofundar o assunto, veja o que são agentes autônomos de IA, o guia de function calling e structured outputs e como testar um agente de IA antes de colocá-lo em produção.
