Erros de fuso horário e prazo em agentes de IA: as checagens de data

Um agente de IA calcula mal um prazo quando trata a data como um texto simples, assume um único relógio para todos os clientes ou conta dias úteis sem o calendário de feriados correto. Os erros são silenciosos: o agente soa confiante, a data parece plausível, e o problema só aparece quando o cliente perde um corte ou recebe um lembrete em um dia em que o escritório está fechado. A solução não está apenas em um prompt mais inteligente. Ela exige tratamento explícito de fuso horário, dados de feriados versionados e um conjunto curto de checagens que rodem antes de qualquer data chegar ao cliente.

Principais pontos

• Guarde cada prazo com o seu fuso horário ou deslocamento em relação ao UTC, e mantenha a regra local do cliente separada do relógio do servidor.
• Converta expressões relativas, como 'na próxima terça' ou 'em dez dias', em uma data absoluta com fuso declarado antes de enviar qualquer coisa.
• Trate feriados como dados regionais, versionados e com um responsável definido, e não como conhecimento geral que o modelo já possui.
• Coloque a validação de datas na ferramenta que registra o compromisso, e não apenas no prompt.
• Teste os casos de borda de propósito: viradas de meia-noite, dias de mudança de horário, feriados regionais e cortes no fim do dia.

Por que agentes erram prazos mesmo quando parecem seguros

Um modelo de linguagem produz datas a partir de padrões de texto e do contexto que o ambiente de execução fornece. Se o ambiente não informar a data, a hora e o fuso atuais, o agente adivinha, e a adivinhação costuma coincidir com o fuso onde a equipe trabalha, com o fuso da máquina que executa a ferramenta ou com o fuso que predominou nos textos de treinamento. Quando alguém pede um prazo de 'fim do dia de sexta', o agente ainda precisa responder qual sexta, fim do dia para quem e medido em qual relógio.

A falha raramente é dramática. Um lembrete chega com várias horas de antecedência para um cliente de outra região, ou uma janela de pagamento se fecha à meia-noite no fuso errado. Como o texto é fluente, quem revisa rapidamente a mensagem pode não notar que a data está errada em um dia, e por isso o erro chega ao cliente antes que alguém da empresa o veja.

Cinco pontos onde os erros de data começam

A maioria dos erros de data vem de um pequeno número de padrões. Cada um parece correto isoladamente e passa por uma leitura casual.

• Carimbos de data e hora sem fuso: data e hora sem zona, que o sistema interpreta como o fuso do servidor.
• Campos somente com data: um dia do calendário gravado como meia-noite UTC, que aparece como o dia anterior para clientes em um deslocamento negativo.
• Expressões relativas: 'semana que vem', 'até sexta' ou 'em dez dias' resolvidas a partir de uma data atual errada.
• Mudanças de horário: uma hora local que não existe no dia em que os relógios avançam, ou que ocorre duas vezes no dia em que eles voltam.
• Contagem de dias úteis: uma contagem que pula fins de semana, mas não os feriados que importam para quem precisa agir.

Ao revisar o tratamento de datas de um agente, verifique cada um desses cinco padrões separadamente. Uma resposta final correta ainda pode esconder um passo intermediário errado, e é justamente o passo intermediário que quebra quando o calendário ou o cliente muda.

Feriados são calendários, não conhecimento comum

Um feriado que fecha um órgão público em um país pode deixar uma empresa privada funcionando no país vizinho. Feriados públicos variam por país, por região e às vezes por cidade, e os fechamentos internos da empresa acrescentam outra camada. Portugal e Brasil, por exemplo, não compartilham a mesma lista de feriados, então um prazo calculado como 'o próximo dia útil' para uma equipe em um país pode estar errado para um cliente no outro.

Por isso, o calendário de feriados deve ser um conjunto de dados versionado, com um responsável nomeado, uma chave de região e uma data da última revisão. O agente consulta esses dados por meio de uma ferramenta e não lembra feriados de memória, porque a memória é inconsistente entre regiões e entre anos. Quando o calendário mudar, a alteração deve ser registrada da mesma forma que uma mudança de prompt ou de ferramenta, para que um revisor posterior consiga ver qual regra gerou determinada data.

Guia de decisão para guardar e exibir prazos

Antes de construir qualquer lógica de data, defina que tipo de prazo você está tratando. A regra certa de armazenamento e exibição depende dessa resposta.

• Se o prazo for um instante, como um corte, o início de uma reserva ou uma janela de pagamento, guarde-o em UTC junto com o fuso que o cliente aceitou e mostre a hora local com o nome do fuso.
• Se o prazo for um dia do calendário, como uma data de vencimento ou o dia de renovação, guarde apenas a data com o fuso em que ela foi definida, e nunca a converta em carimbo de data e hora sem esse fuso.
• Se a entrada for relativa, resolva-a imediatamente para uma data absoluta usando a hora atual do ambiente de execução e o fuso do cliente, e peça confirmação quando o risco for alto.
• Se a data resolvida cair em feriado ou fechamento para quem precisa agir, mova-a apenas sob uma regra de negócio escrita e registre qual regra foi aplicada.
• Se o fuso do cliente for desconhecido, não o deduza pela redação da mensagem. Pergunte, ou encaminhe o caso para uma pessoa.

A última regra é a mais importante na prática. Um fuso adivinhado é um fato inventado, e ele vai parecer razoável até o momento em que causar a perda de uma janela.

Cenário ilustrativo: um aviso de renovação que chega um dia antes

O cenário a seguir é ilustrativo e não descreve um cliente real. Uma empresa de serviços usa um agente que envia avisos de renovação. O servidor do agente opera em um fuso. Para um cliente que está várias horas atrás desse fuso, o agente resolve 'próxima segunda' com base na data do servidor, que naquele horário já está um dia à frente da data do cliente. O vencimento é então gravado como meia-noite UTC, e a tela do cliente mostra o dia anterior, de modo que o aviso afirma que a janela de renovação fechou antes de abrir.

O erro teria sido pego por três checagens: recalcular o prazo a partir do fuso do cliente, comparar esse resultado com o rascunho do agente e incluir uma confirmação de uma linha no fuso do cliente antes do envio. A correção não foi um prompt mais longo. Foi uma ferramenta que se recusa a registrar um vencimento sem fuso e uma etapa de comparação que interrompe o envio quando as duas datas não coincidem.

Checagens de data antes que um compromisso chegue ao cliente

Essas checagens pertencem à ferramenta que registra ou envia o compromisso. Um prompt pode pedir ao agente que tenha cuidado, mas a ferramenta pode se recusar a seguir em frente.

• Confirme que a hora atual veio do ambiente de execução, e não da memória do modelo.
• Confirme que o fuso do cliente existe no cadastro da conta e não foi inferido apenas a partir da mensagem.
• Recalcule o prazo a partir da regra declarada e compare o resultado com o rascunho do agente. Qualquer divergência interrompe o envio.
• Verifique se o prazo está no futuro e cai em dia útil para quem precisa agir, usando o calendário regional.
• Verifique se a data ou a hora cai dentro de uma janela de mudança de horário para o fuso relevante.
• Mostre ao cliente a data, a hora e o fuso absolutos em uma linha simples antes de qualquer compromisso vinculante.
• Registre a regra, as entradas e o resultado no registro de ações para que um revisor consiga reproduzir a data depois.

Rode as mesmas checagens em toda chamada de ferramenta relacionada a datas, incluindo lembretes, renovações, confirmações de reserva e escalonamentos internos que carreguem um prazo. Prazos internos causam o mesmo dano quando um colega age com base em uma data errada.

Como testar a lógica de datas antes que clientes a vejam, e como a Be Human gerencia isso

Monte um pequeno conjunto de casos de teste antes que o agente escreva em canais de clientes. Inclua prazos nas viradas de meia-noite, uma data que caia em dia de mudança de horário, um cliente em cada fuso que você atende, um feriado que vale em uma região mas não em outra, e uma expressão relativa enviada na véspera de um feriado. Execute esses casos primeiro em modo sombra, para que o agente proponha datas que uma pessoa possa comparar com o resultado esperado, e mantenha esses casos no conjunto de regressão para que uma atualização do modelo ou uma mudança no calendário não os quebre silenciosamente. O conjunto de testes de referência e os testes de chamadas de ferramentas são os lugares habituais para guardar esses casos, e o modo sombra mostra como observar as propostas antes de conceder permissão de escrita.

Em um trabalho gerenciado, a Be Human define as regras de data como parte do contexto operacional do agente: qual fuso é a referência para cada tipo de prazo, onde fica o calendário de feriados e quem é responsável por ele, e quais chamadas de ferramenta precisam passar pelas checagens de data antes de serem executadas. O monitoramento revisa as falhas relacionadas a datas como parte da operação de rotina, as avaliações recorrentes incluem os casos de data, e as mudanças nos dados de feriados ou nas regras de fuso passam pelo mesmo registro de mudanças e pela mesma revisão de permissões das demais alterações de comportamento, para que o dono veja o que mudou e quando entrou em vigor.

Se você não tem certeza de qual prazo um agente deve tratar primeiro, o diagnóstico gratuito de IA da Be Human pode ajudar a encontrar a primeira tarefa que vale a pena entregar a um agente.

Perguntas frequentes

Por que meu agente de IA dá um prazo errado quando a data parece correta? A data pode estar correta para o servidor, mas errada para o fuso do cliente, e a redação raramente revela essa diferença. Verifique se o prazo é um instante ou um dia do calendário e confirme que o fuso está guardado junto com ele. Recalcule o prazo no fuso do cliente antes do envio da mensagem.

O modelo deve conhecer os feriados públicos, ou uma ferramenta deve fornecê-los? Uma ferramenta deve fornecê-los. A memória do modelo sobre feriados varia por região e por ano, e um feriado errado pode deslocar um prazo sem nenhum sinal visível. Um calendário versionado, com responsável e data de revisão, dá uma fonte que você pode auditar.

Quanto o agente deve pedir confirmação ao cliente? Para prazos vinculantes, como janelas de pagamento, renovações e cortes de reserva, uma confirmação de uma linha com a data, a hora e o fuso absolutos é um padrão razoável. Para lembretes de baixo risco, a etapa de confirmação pode muitas vezes ser dispensada. Quando o fuso do cliente é desconhecido, o agente deve perguntar antes de se comprometer com qualquer coisa.

Essas checagens deixam as respostas do agente mais lentas? As checagens são pequenas chamadas de ferramenta e acrescentam tempo principalmente às ações que carregam prazo, e não a cada mensagem. Essa troca costuma valer a pena, porque uma data errada, rápida, custa mais para corrigir do que um caminho um pouco mais longo para os poucos compromissos que têm prazo.

Orientação editorial Be Human. Exemplos são ilustrativos, salvo atribuição explícita. Fontes oferecem contexto; a implementação depende do seu processo.