AutoSynthData: geração de dados de treinamento para agentes corporativos transforma falhas em um currículo

A ServiceNow CoreAI lançou o AutoSynthData em 2 de outubro, relatando ganhos a partir de quase 4.000 tarefas sintéticas em dois experimentos com agentes corporativos. AutoSynthData: geração de dados de treinamento para agentes corporativos parte das falhas do modelo e converte essas fragilidades em exemplos de treinamento executáveis e verificáveis. O conflito é claro: dados sintéticos podem escalar rapidamente, mas tarefas geradas também podem ensinar o comportamento errado.

Isso faz do AutoSynthData mais do que outro sistema que pede a um modelo para inventar prompts. Ele busca construir um ciclo fechado de treinamento em torno do agente-alvo, de seu ambiente operacional e de um modelo professor mais forte. Cada tarefa aceita inclui um estado inicial do sistema, uma solicitação do usuário, uma trajetória bem-sucedida e um verificador que avalia o estado final.

A ServiceNow afirma que a abordagem melhorou um modelo Gemma-alvo em dois domínios do EnterpriseOps Gym. Ainda assim, esses ganhos vêm de experimentos controlados dentro da mesma família de benchmarks que moldou o currículo. O resultado pressiona equipes que dependem de conjuntos de dados estáticos escritos por humanos, enquanto deixa sem resposta a transferência para contextos externos e a confiabilidade em produção.

AutoSynthData: geração de dados de treinamento para agentes corporativos começa com a falha

A mudança importante é que a ServiceNow está tratando falhas de agentes como instruções sobre quais dados de treinamento gerar em seguida.

Os pipelines tradicionais de dados sintéticos geralmente começam com tópicos, modelos ou exemplos iniciais. Eles expandem essas entradas em coleções maiores, filtram os resultados e usam as amostras restantes para treinamento. Esse processo pode criar volume sem comprovar que os novos dados abordam as fragilidades reais de um modelo.

O AutoSynthData inverte essa ordem. Primeiro, ele avalia um modelo-alvo em um ambiente operacional e estuda onde o modelo falha. Um modelo professor mais forte tenta as mesmas tarefas de diagnóstico, proporcionando uma comparação entre comportamentos malsucedidos e bem-sucedidos.

O sistema analisa a capacidade envolvida, as ferramentas necessárias, a estrutura do fluxo de trabalho e o estado final considerado bem-sucedido. Ele também identifica detalhes que podem mudar sem remover a capacidade subjacente. Essas observações se tornam o que a ServiceNow chama de cartões de especificação de capacidade sanitizados.

Esses cartões orientam a geração sem expor os prompts originais de avaliação, entidades, trajetórias ou detalhes do verificador. Essa separação busca reduzir o vazamento direto do benchmark. Ela também obriga o gerador a criar novas situações, em vez de apenas parafrasear perguntas de teste.

O formato da tarefa tem três partes conectadas. Uma especificação do sistema define políticas, ações disponíveis e o estado inicial do ambiente. Um prompt do usuário declara o resultado solicitado, enquanto um verificador decide se o agente alcançou um estado final aceitável.

Essa estrutura importa porque o trabalho corporativo raramente termina com uma resposta em texto. Um agente de serviços de TI pode precisar inspecionar um incidente, verificar uma permissão, atualizar um registro e preservar uma trilha de auditoria. Uma resposta fluente não comprova que alguma dessas ações ocorreu corretamente.

O lançamento do AutoSynthData descreve duas etapas de geração. A etapa target cria e valida exemplos centrais construídos em torno de lacunas de capacidade identificadas. A etapa multiply produz novas variantes a partir de amostras target aceitas.

Cada variante recebe sua própria solicitação, entidades, estado inicial, trajetória de referência e verificador. Uma amostra multiplicada não pode se tornar a semente de outra amostra multiplicada. Esse limite foi projetado para evitar que várias gerações de expansão sintética se afastem do núcleo validado.

O pipeline separa o controle central de geração da execução específica do ambiente. Um controlador gerencia cobertura, verificações de qualidade e a construção do conjunto de dados. Um adaptador executa ferramentas, gerencia o estado, reproduz soluções de referência, avalia agentes e aplica verificação determinística.

Essa separação dá à abordagem um caminho para além de um único benchmark. Em teoria, uma empresa poderia manter o controlador compartilhado enquanto escreve um adaptador para seus próprios sistemas. No entanto, cada novo adaptador precisaria de ferramentas precisas, transições de estado realistas e critérios de sucesso confiáveis.

A notícia, portanto, não é simplesmente que a ServiceNow gerou tarefas sintéticas. A empresa construiu um processo que escolhe tarefas de acordo com as fragilidades do modelo atual. Em seguida, ela desloca o alvo do treinamento à medida que essas fragilidades mudam.

Esse ciclo adaptativo desafia o desenvolvimento de conjuntos de dados estáticos. Uma coleção fixa se torna menos valiosa quando um modelo resolve a maior parte dela. Em vez disso, o AutoSynthData busca perto do limite atual de capacidade do modelo, onde os exemplos permanecem difíceis, mas ainda ensináveis.

A ideia também muda o que uma falha de avaliação representa. Em vez de se tornar apenas uma pontuação ou relatório de bug, a falha passa a ser matéria-prima para pós-treinamento. O mesmo ambiente pode diagnosticar fragilidades, gerar prática direcionada e testar o modelo atualizado.

Esse ciclo é a afirmação central por trás de AutoSynthData: geração de dados de treinamento para agentes corporativos. A ServiceNow ainda não demonstrou que ele funciona em ambientes corporativos não relacionados. Ainda assim, definiu uma alternativa concreta à expansão indiscriminada de dados sintéticos.

Conjuntos de dados estáticos para agentes agora enfrentam um alvo móvel

O AutoSynthData pressiona equipes que coletam dados amplos de treinamento sem medir se cada amostra ensina uma capacidade ausente.

Desenvolvedores de agentes corporativos enfrentam um difícil problema de dados. Registros de produção contêm padrões úteis de fluxo de trabalho, mas também podem incluir informações pessoais, dados empresariais confidenciais e resultados inconsistentes. Tarefas escritas por humanos evitam algumas preocupações de privacidade, mas criar exemplos variados e verificáveis em quantidade suficiente é caro.

Dados sintéticos oferecem escala, mas a escala por si só não seleciona a lição certa. Um modelo que já lida com solicitações de redefinição de senha ganha pouco com milhares de exemplos semelhantes. Ele precisa de tarefas que exponham problemas não resolvidos, como verificações de políticas, planejamento entre múltiplos sistemas e recusa segura.

O EnterpriseOps Gym fornece o ambiente controlado usado nos experimentos da ServiceNow. Seu artigo de benchmark descreve tarefas com estado nas quais um agente precisa raciocinar entre ferramentas e deixar o sistema subjacente na condição correta. Isso é diferente de benchmarks que avaliam apenas uma resposta textual final.

A ServiceNow descreve o EnterpriseOps Gym como cobrindo oito domínios empresariais. O ambiente associado inclui 512 ferramentas funcionais e 164 tabelas de banco de dados interconectadas. Esses recursos apoiam fluxos de trabalho em áreas como gestão de serviços de TI, atendimento ao cliente e recursos humanos.

Segundo a ServiceNow, o benchmark mais amplo contém 1.150 tarefas empresariais. Elas testam planejamento, conformidade com políticas e alterações de estado em sistemas conectados. O conjunto de dados lançado também dá a pesquisadores externos acesso aos materiais do benchmark.

Esses números explicam por que a geração direcionada importa. Um único fluxo de trabalho pode combinar várias ferramentas, registros, políticas e dependências. Pequenas mudanças no estado inicial podem alterar qual sequência é válida ou se a ação solicitada deve ocorrer.

A ServiceNow relatou anteriormente que fornecer planos de tarefas de especialistas elevou o desempenho de 15% a 35% em domínios empresariais difíceis. Essa descoberta sugere que o planejamento continua sendo uma limitação importante, mesmo quando um agente consegue chamar ferramentas individuais corretamente. O AutoSynthData busca converter essas lacunas de planejamento em oportunidades repetidas de treinamento.

A pressão recai primeiro sobre equipes de avaliação estática. Um conjunto de testes fixo pode identificar uma fragilidade, mas não cria automaticamente um currículo que a resolva. Pesquisadores ainda precisam traduzir falhas em exemplos diversos, soluções válidas e lógica de avaliação confiável.

A segunda pressão recai sobre provedores de modelos de uso geral. Médias fortes em benchmarks podem ocultar falhas causadas por políticas locais, estruturas de tabelas ou regras de fluxo de trabalho. As empresas precisam de evidências de que um modelo consegue operar em seus sistemas específicos, e não apenas responder a perguntas sobre eles.

A terceira pressão recai sobre empresas que constroem plataformas de agentes. Se o treinamento adaptativo se provar útil, a infraestrutura de avaliação passa a fazer parte do desenvolvimento do modelo, em vez de ser uma etapa final de qualidade. As plataformas precisarão de ambientes reproduzíveis, geração de tarefas, registros de execução e verificação baseada em estado.

Esse requisito favorece organizações com simuladores operacionais ou gêmeos digitais. A Salesforce seguiu uma direção relacionada com o CRMArena-Pro, que usa ambientes empresariais simulados para avaliar agentes em fluxos de trabalho de negócios. A sobreposição sinaliza um movimento mais amplo em direção a testes de agentes executáveis e ancorados no ambiente.

As abordagens não são idênticas. Um benchmark pode comparar modelos sem modificá-los, enquanto o AutoSynthData usa falhas de benchmark para gerar dados de pós-treinamento. Um mede a capacidade, e o outro tenta ampliá-la.

Essa distinção importa para compradores corporativos. Um ranking identifica o modelo mais forte em condições declaradas. Um currículo adaptativo pergunta se um modelo-alvo mais barato ou menor pode melhorar nas próprias tarefas recorrentes da organização.

Os resultados relatados pela ServiceNow tornam essa possibilidade concreta, mas não definitiva. O modelo-alvo ainda concluiu apenas uma minoria das tarefas de serviço de TI após o treinamento. Melhor que a linha de base não significa pronto para acesso não supervisionado em produção.

A qualidade do conhecimento também continua sendo uma limitação prática. Um agente não pode seguir uma política que está ausente, é contraditória ou inacessível. Equipes que criam uma base de conhecimento pesquisável ainda precisam de material-fonte claro antes que tarefas de treinamento geradas possam refletir o trabalho real.

Portanto, o AutoSynthData desloca o gargalo em vez de eliminá-lo. As equipes precisam de menos variações criadas manualmente, mas precisam de um ambiente confiável e de verificação precisa. Essa troca se torna decisiva quando um agente pode alterar registros de clientes, funcionários ou infraestrutura.

O mecanismo depende de tarefas executáveis e verificadores rigorosos

O AutoSynthData só funciona quando solicitações geradas, soluções de referência e verificadores concordam sobre o que significa sucesso.

O pipeline começa identificando tarefas que distinguem o modelo-alvo de um professor mais forte. Na configuração relatada, a ServiceNow favorece candidatos que o alvo resolve no máximo uma vez em três tentativas. O solucionador mais forte deve concluí-las pelo menos duas vezes em três tentativas.

Esse filtro busca uma faixa de dificuldade útil. Tarefas que derrotam ambos os modelos não oferecem uma demonstração confiável. Tarefas que ambos resolvem de forma consistente consomem capacidade de treinamento sem atingir uma fragilidade clara.

Quando um candidato entra no pipeline, o AutoSynthData executa sua trajetória de referência. Uma trajetória é a sequência de chamadas de ferramentas e ações usada para alcançar o estado solicitado. Em seguida, o verificador inspeciona o resultado em relação às condições de sucesso da tarefa.

Essa verificação positiva pergunta se a solução pretendida realmente funciona. Ela pode expor um estado inicial inválido, uma ferramenta indisponível, uma sequência de ações quebrada ou uma inconsistência entre a solicitação e o verificador. Um exemplo que parece plausível falha se não consegue sobreviver à execução.

O pipeline também realiza verificação negativa. Ele altera os resultados esperados e confirma que estados incorretos não sejam aprovados. Essa etapa é importante porque um verificador fraco pode recompensar um agente que ignora ações obrigatórias ou viola uma restrição importante.

Considere uma solicitação para encerrar um incidente de TI somente após confirmar a resolução com o funcionário afetado. Um verificador que checa apenas o status do incidente aceitaria um atalho inseguro. Um verificador mais robusto também exigiria o registro da confirmação e quaisquer observações obrigatórias.

O mesmo problema surge quando várias soluções são válidas. Um verificador deve reconhecer resultados aceitáveis sem exigir uma única sequência de referência exata. A ServiceNow enquadra isso como completude, ao lado da consistência com a solicitação e da rejeição correta de comportamentos incorretos.

Esses requisitos criam um equilíbrio difícil. Um verificador permissivo demais recompensa trabalho incompleto. Um verificador restritivo demais penaliza estratégias legítimas e treina o modelo para imitar uma sequência arbitrária.

Candidatos reprovados entram em um ciclo limitado de crítica e correção. Um crítico examina a construção da tarefa, o estado inicial, a solução e a lógica de verificação. O sistema aplica correções direcionadas, executa novamente as etapas de validação relevantes e aceita ou rejeita o candidato revisado.

Corrigir um candidato existente pode preservar trabalho útil. Isso também evita reiniciar a geração sempre que um componente contém um defeito corrigível. O limite de tentativas impede que o sistema gaste recursos ilimitados em uma família de tarefas de baixo retorno.

Em seguida, o AutoSynthData revisa a qualidade em todo o lote. Exemplos individualmente válidos ainda podem formar um conjunto de dados repetitivo. Um gerador pode produzir em excesso fluxos de trabalho conhecidos enquanto ignora combinações difíceis de políticas, ferramentas ou estados do sistema.

O controlador acompanha amostras aceitas e rejeitadas, padrões repetidos, cobertura de capacidades e descobertas recorrentes nas críticas. Ele reduz a geração em áreas super-representadas e redireciona esforços para lacunas. Isso cria feedback acima do nível de cada tarefa individual.

As etapas target e multiply sustentam essa estratégia. As amostras target estabelecem famílias de tarefas validadas em torno de lacunas específicas de capacidade. As amostras multiply variam redação, entidades, combinações de ferramentas e estados do ambiente sem expandir recursivamente variantes anteriores.

Esse desenho reduz um risco comum dos dados sintéticos. A geração recursiva pode ampliar pequenos erros à medida que cada nova amostra herda pressupostos de outra amostra gerada. Ancorar todas as variantes em exemplos target avaliados limita essa cadeia.

A abordagem também oferece às empresas uma trilha de auditoria mais defensável. Cada exemplo de treinamento pode ser associado ao seu estado inicial, à sequência de ações pretendida, ao verificador e ao resultado da validação. Isso é mais útil do que uma pasta contendo prompts sem contexto executável.

No entanto, verificações determinísticas não conseguem codificar todas as dimensões relevantes de qualidade. O estado final de um banco de dados pode parecer correto mesmo que um agente tenha exposto informações sensíveis durante o processo. Outra trajetória pode criar alterações desnecessárias antes de restaurar o estado esperado.

Logs de execução e verificações sensíveis a políticas continuam necessários. A própria ferramenta de avaliação de agentes da ServiceNow enfatiza conjuntos de dados, registros de execução e múltiplas dimensões de qualidade. O AutoSynthData estende essa filosofia à produção de dados de treinamento.

O mecanismo também depende do professor. Um modelo mais forte pode demonstrar comportamentos bem-sucedidos, mas suas ações ainda refletem as ferramentas disponíveis e as políticas codificadas. Um professor que opta por um atalho arriscado pode propagar esse comportamento para o ajuste fino supervisionado.

Isso cria uma questão de governança. As empresas precisam saber quem define o comportamento válido, quais políticas o ambiente implementa e como mudanças nos verificadores são revisadas. Caso contrário, a geração automatizada pode ampliar um erro de especificação que passou despercebido.

AutoSynthData: Generating Training Data for Enterprise Agents se destaca como um argumento em favor de dados executáveis. O gerador recebe atenção, mas o ambiente e o verificador sustentam grande parte da credibilidade do sistema. Sem eles, tarefas sintéticas continuam sendo histórias convincentes, e não exemplos de treinamento comprovados.

Os Ganhos Reportados São Relevantes, mas Ainda Limitados

A ServiceNow relata melhorias claras em benchmarks, mas os experimentos não estabelecem confiabilidade em produção nem transferência ampla.

O primeiro experimento usou Gemma-4-26B-A4B-it como modelo-alvo no domínio Hybrid do EnterpriseOps Gym. Qwen3.8-27B atuou como professor. O AutoSynthData gerou 2.000 exemplos sintéticos de treinamento em aproximadamente 18 horas.

A ServiceNow ajustou o Gemma com ajuste fino supervisionado, que treina um modelo para imitar exemplos bem-sucedidos. O melhor checkpoint reportado veio da quinta época. Uma época representa uma passagem completa pelo conjunto de dados de treinamento.

O Pass@1 médio melhorou 7,2 pontos percentuais, segundo a empresa. A ServiceNow caracteriza essa mudança como uma melhora relativa de 35%. O sucesso do verificador também aumentou de 63,01% para 68,55%.

A empresa afirma que o checkpoint resultante reduziu 59% da lacuna original de Pass@1 entre o Gemma e seu modelo de referência. Esses resultados indicam que exemplos sintéticos direcionados afetaram mais de uma métrica. Eles não revelam como o modelo se comportou fora do ambiente testado.

O segundo experimento concentrou-se em gestão de serviços de TI. Ele também usou Gemma-4-26B-A4B-it como alvo, enquanto DeepSeek-V4.1-Flash atuou como professor. O pipeline produziu 1.994 amostras aceitas ao longo de 66 horas.

O Pass@1 médio subiu de 18,77% para 27,18% na avaliação de ITSM. Trata-se de um aumento de 8,41 pontos percentuais. Ainda assim, o modelo treinado falha na maioria das primeiras tentativas segundo o método de pontuação do benchmark.

Essa lacuna restante é um contexto essencial. O experimento sustenta a afirmação de que o ajuste fino sintético direcionado pode melhorar um modelo. Não sustenta a afirmação de que o agente resultante está pronto para operar de forma independente em sistemas empresariais.

A ServiceNow afirma que o gerador Hybrid nunca recebeu os prompts de avaliação originais, entidades, trajetórias ou detalhes do verificador. Ele recebeu especificações de capacidades extraídas do comportamento de avaliação. Essa separação reduz uma forma evidente de contaminação do conjunto de testes.

No entanto, o currículo ainda derivou de falhas observadas no EnterpriseOps Gym. Portanto, treinamento e avaliação compartilharam um ambiente, uma estrutura de ferramentas e uma distribuição geral de tarefas. A melhora nesse ambiente não estabelece transferência para softwares não relacionados ou configurações empresariais privadas.

Os números reportados também vêm da equipe que projetou o sistema. Uma replicação independente fortaleceria o resultado. Pesquisadores precisariam de código suficiente, configurações de geração, amostras aceitas e detalhes de avaliação para reproduzir o pipeline.

A Artificial Analysis agora opera um ranking independente baseado no EnterpriseOps Gym. Sua avaliação também enfatiza trabalho com estado, múltiplas etapas e condições finais do banco de dados. Esse mecanismo externo cria uma possível via para testar checkpoints treinados de forma mais independente.

Uma avaliação entre ambientes seria ainda mais informativa. Um modelo treinado em uma configuração de ITSM poderia ser testado diante de políticas alteradas, ferramentas renomeadas, esquemas modificados e distribuições de registros desconhecidas. O desempenho sob essas mudanças mostraria se o modelo aprendeu uma capacidade ou memorizou um padrão do ambiente.

A segurança também precisa de medição separada. A ServiceNow descreveu anteriormente 30 tarefas de benchmark inviáveis que envolviam recursos indisponíveis, permissões ausentes ou violações de políticas. Segundo relatos, seu modelo mais forte testado reconheceu apenas cerca de metade delas como inviáveis.

O AutoSynthData poderia visar essas falhas, mas a versão atual não apresenta um resultado dedicado de abstenção segura. Melhorar a conclusão de tarefas pode criar novos riscos caso o modelo também se torne mais disposto a agir quando recusar é o correto.

A relação entre professor e alvo merece escrutínio. O experimento Hybrid usou modelos de tamanho relativamente próximo, enquanto a execução de ITSM usou um professor muito maior. A duração da geração diferiu substancialmente, em parte porque a ServiceNow afirma que a execução anterior de ITSM precedeu otimizações de throughput.

Essas diferenças tornam comparações diretas difíceis. Os dois domínios envolveram professores, tempos de processamento e provavelmente distribuições de capacidades distintos. As evidências mostram repetibilidade em dois cenários, não um estudo controlado de cada componente do sistema.

A ausência de um estudo de ablação também limita a interpretação. Os resultados públicos não isolam quanto da melhora veio do direcionamento por falhas, das demonstrações do professor, da filtragem pelo verificador, da multiplicação de tarefas ou do balanceamento em nível de lote. Cada componente parece plausível, mas suas contribuições individuais continuam pouco claras.

Custo e uso de recursos são outra questão em aberto, mesmo sem atribuir valores comerciais. Gerar milhares de tarefas exige chamadas repetidas ao modelo, execução no ambiente, tentativas do solucionador, crítica, correção e verificação. O conjunto de dados aceito representa apenas a saída, não toda a carga de trabalho tentada.

As empresas precisam comparar esse esforço com alternativas. Exemplos escritos por humanos podem ser mais lentos, mas mais fáceis de revisar. Mudanças em recuperação de informação e orquestração podem corrigir algumas falhas sem atualizar os pesos do modelo.

Um fluxo de trabalho também pode falhar porque seu conhecimento está incompleto, e não porque o modelo não tem capacidade de raciocínio. Uma melhor combinação de conhecimento pode abordar algumas lacunas de forma mais direta. O treinamento não deve se tornar a resposta padrão para toda execução malsucedida de um agente.

A leitura cautelosa ainda é encorajadora. O AutoSynthData produziu melhorias mensuráveis a partir de tarefas selecionadas em torno de fraquezas observadas. A afirmação mais forte, de que currículos sintéticos adaptativos se generalizam em agentes de produção mais seguros, continua não comprovada.

Três Sinais Determinarão se o AutoSynthData Importa Além do Benchmark

As próximas evidências devem demonstrar reprodutibilidade, transferência e comportamento mais seguro, e não apenas outra pontuação mais alta no ambiente original.

O primeiro sinal é uma versão reproduzível de forma independente. A ServiceNow publicou materiais do EnterpriseOps Gym, mas pesquisadores precisam da implementação do AutoSynthData e da receita experimental completa. Esse pacote deve incluir a construção de cartões de capacidade, configurações de geração, testes do verificador, critérios de rejeição e avaliação de checkpoints.

Equipes independentes devem ser capazes de regenerar conjuntos de dados comparáveis a partir das mesmas falhas diagnósticas. Melhorias semelhantes em múltiplas execuções reduziriam preocupações com amostragem favorável. A publicação de estatísticas sobre tarefas rejeitadas também revelaria quanta filtragem o conjunto de dados final exigiu.

A versão mais robusta desse sinal incluiria ablações. Pesquisadores poderiam remover a verificação negativa, o balanceamento de lotes, a multiplicação ou o direcionamento por falhas, um componente de cada vez. As diferenças de desempenho resultantes identificariam quais mecanismos produzem a melhora.

Se a replicação independente for bem-sucedida, ela fortalecerá a principal afirmação técnica da ServiceNow. Se os ganhos variarem drasticamente entre execuções, o resultado sugerirá que o pipeline continua sensível a geradores, professores ou escolhas de seleção.

O segundo sinal é a transferência entre ambientes. Um modelo treinado deve enfrentar fluxos de trabalho que preservem a capacidade subjacente enquanto alteram ferramentas, entidades, políticas e esquemas. Esse teste distinguiria aprendizado geral de familiaridade com a estrutura do EnterpriseOps Gym.

Um experimento útil poderia treinar em um ambiente de ITSM e avaliar em outro sem ajuste fino adicional. Outro poderia passar de um fluxo de trabalho de domínio único para uma tarefa entre domínios que exigisse dados de clientes, funcionários e ativos.

As empresas também devem observar adaptadores para além dos sistemas orientados ao ServiceNow. A arquitetura de controlador-adaptador do AutoSynthData sugere portabilidade, mas o design de software não garante compatibilidade prática. Cada novo ambiente precisa de ações executáveis e de verificação confiável.

Resultados bem-sucedidos em várias plataformas tornariam o método relevante para um mercado de agentes muito mais amplo. Uma transferência fraca restringiria seu papel a um pipeline eficiente de personalização para ambientes rigidamente especificados.

O terceiro sinal é se a conclusão de tarefas melhora sem enfraquecer a recusa e a conformidade com políticas. Um agente empresarial precisa saber quando não agir. Pontuações mais altas no Pass@1 são insuficientes se o treinamento incentivar uma execução confiante diante de permissões ausentes ou instruções contraditórias.

Avaliações futuras devem informar a detecção de tarefas inviáveis, alterações de estado não autorizadas, violações de políticas e chamadas desnecessárias de ferramentas. Também devem examinar ações intermediárias, e não apenas os estados finais do banco de dados. Um estado final restaurado pode ocultar uma sequência insegura.

A revisão humana continua importante para fluxos de trabalho de alto impacto. Os revisores devem examinar amostras que envolvam registros de funcionários, controles de acesso, direitos de clientes, incidentes de segurança e alterações irreversíveis. Verificadores automatizados podem apoiar esse processo, mas não devem definir políticas sem supervisão responsável.

Os próximos um a três meses devem, portanto, trazer três formas concretas de evidência: código de pipeline executável, testes entre ambientes e resultados específicos de segurança. Cada uma abordaria uma incerteza diferente na divulgação atual.

AutoSynthData: Generating Training Data for Enterprise Agents apresenta um mecanismo crível para transformar falhas de avaliação em prática direcionada. Os ganhos relatados mostram que a ideia merece atenção, especialmente para equipes com ambientes de fluxo de trabalho executáveis.

A decisão mais ampla agora cabe aos desenvolvedores de IA empresarial. Eles devem perguntar se as falhas de seus próprios agentes podem ser expressas como estados reproduzíveis, trajetórias válidas e resultados testáveis. Caso contrário, gerar mais tarefas apenas ampliará a ambiguidade.

Se essas bases existirem, um currículo adaptativo poderá tornar a avaliação muito mais útil. Ele pode mostrar o que falhou, gerar treinamento direcionado e medir se a mesma fraqueza persiste. A próxima prova deve mostrar que esse ciclo se mantém fora do ambiente que o criou.