O agente entrou no ERP, mas a implementação nunca termina

TL;DR

• Um agente conectado ao ERP não encerra a implementação quando ainda não está claro o que ele pode inferir e o que deve obedecer como regra fixa.
• Sem critérios explícitos, cada exceção comercial reabre testes, integrações e aprovações.
• O problema central não é apenas a capacidade da IA, mas a governança das decisões que ela influencia ou executa.
• Antes de ampliar a automação, o CTO precisa separar inferência, regra, alçada, evidência e responsabilidade.

Por que o go-live continua preso mesmo depois que o agente já funciona?

O agente foi integrado. O ERP responde. Os principais fluxos foram demonstrados. Ainda assim, o go-live não avança com segurança.

Para o CTO, essa é uma das formas mais difíceis de atraso: a tecnologia parece pronta, mas a organização continua descobrindo condições que não estavam explícitas. Uma nova exceção de preço exige outro teste. Uma condição comercial fora do padrão volta para aprovação. Uma divergência de crédito reabre a discussão sobre alçada. Uma resposta gerada pelo agente precisa ser confrontada com aquilo que o negócio considera vinculante.

O projeto permanece “quase pronto”.

A tese apresentada no material sobre o Prism expõe a origem dessa paralisia: sem critérios explícitos sobre o que a IA pode inferir e o que deve seguir uma regra comercial fixa, cada exceção reabre testes, integrações e aprovações. O agente se torna uma frente de homologação contínua, não o fim da implementação.

Isso muda o diagnóstico. O gargalo não está necessariamente na integração técnica. Ele pode estar na ausência de um modelo de decisão capaz de delimitar o papel da IA dentro da operação comercial B2B.

A integração responde se o agente consegue agir. A governança responde se ele deve agir

Uma integração bem-sucedida demonstra que sistemas conseguem trocar dados e acionar processos. Ela não resolve, por si só, questões como:

• Quais decisões podem ser inferidas a partir do contexto?
• Quais condições devem ser aplicadas sem interpretação?
• Quando uma exceção exige intervenção humana?
• Quem aprova uma decisão fora do padrão?
• Qual evidência precisa ser preservada para explicar o resultado?
• Uma mudança de política exige ajuste de regra, de integração ou do comportamento do agente?

Sem essas respostas, a homologação tenta compensar a falta de governança. O time adiciona cenários, cria novas verificações e repete aprovações. Cada teste resolve um caso, mas não necessariamente define um princípio reutilizável.

O resultado é uma implementação que acumula exceções sem estabilizar a lógica decisória.

O problema aparece nas fronteiras, não no fluxo ideal

Fluxos ideais costumam ser mais fáceis de demonstrar: dados disponíveis, condição válida, política clara e resposta esperada. O risco aparece quando a realidade comercial combina variáveis que não foram classificadas previamente.

Em uma negociação B2B, uma condição pode depender de contexto, mas também pode estar limitada por uma política fixa. Se essa fronteira não estiver documentada, a equipe técnica precisa redescobri-la durante a homologação.

Nesse cenário, a pergunta “o agente acertou?” é insuficiente. O CTO precisa fazer perguntas mais precisas:

• O agente aplicou uma regra ou produziu uma inferência?
• A fonte usada para decidir era válida para aquele contexto?
• A decisão estava dentro da alçada prevista?
• A exceção deveria bloquear, escalar ou apenas registrar?
• O comportamento pode ser reproduzido e explicado?
• Quem é responsável por alterar esse critério no futuro?

A diferença é relevante porque uma inferência pode admitir avaliação contextual. Uma regra comercial fixa exige aderência. Misturar as duas categorias faz com que o mesmo teste tente validar, ao mesmo tempo, interpretação e conformidade.

Homologação contínua não é o mesmo que evolução contínua

Sistemas e políticas mudam. Portanto, algum grau de validação contínua é inevitável. O problema surge quando a organização não consegue distinguir evolução planejada de reabertura permanente da implementação.

Há uma diferença entre:

• validar uma nova capacidade;
• alterar uma política comercial;
• corrigir uma integração;
• recalibrar uma inferência;
• incluir uma nova alçada;
• tratar uma exceção ainda não governada.

Quando tudo entra na mesma fila, o CTO perde visibilidade sobre a natureza do trabalho. A operação chama de erro aquilo que pode ser uma regra ausente. O time técnico trata como ajuste aquilo que talvez seja uma decisão de negócio. A homologação cresce porque se torna o lugar onde conflitos de responsabilidade são resolvidos.

A IA amplia essa tensão. O agente consegue interpretar contexto e propor ações, mas essa capacidade não elimina a necessidade de declarar onde termina a interpretação e começa a obrigação comercial.

O Custo da Inação

Manter essa fronteira indefinida não apenas adia o go-live. Também preserva um modelo operacional no qual cada exceção consome novamente atenção técnica e executiva.

O custo aparece em diferentes frentes:

• testes reabertos por condições que não foram classificadas;
• integrações revistas sem clareza sobre a origem do problema;
• aprovações repetidas para exceções semelhantes;
• dependência de pessoas específicas para interpretar políticas;
• dificuldade para explicar por que o agente tomou ou sugeriu uma decisão;
• expansão da automação limitada pela insegurança operacional.

O efeito mais profundo é a perda de previsibilidade. O CTO não consegue afirmar se a implementação está perto do fim porque o escopo real não é apenas funcional. Ele inclui decisões comerciais que continuam implícitas.

A empresa pode ter um agente tecnicamente operacional e, ainda assim, não possuir uma operação governável.

Princípios para impedir que cada exceção reabra o projeto

• Classificar antes de automatizar: separar decisões inferenciais, regras fixas, exceções e ações que exigem aprovação.
• Definir alçadas de forma explícita: registrar quem pode aprovar, bloquear ou alterar cada tipo de condição.
• Homologar princípios, não apenas exemplos: um cenário aprovado deve estar associado ao critério que poderá ser reutilizado.
• Preservar evidências: manter o contexto, a regra aplicada, a inferência realizada e a decisão final.
• Separar mudança técnica de mudança comercial: nem toda divergência deve retornar para integração ou desenvolvimento.
• Tratar exceções como sinal de governança: quando casos semelhantes reaparecem, o problema pode estar no desenho decisório.
• Ampliar autonomia progressivamente: o agente deve ganhar espaço à medida que regras, limites e escalonamentos se tornam verificáveis.
• Manter responsabilidade humana identificável: automação não deve tornar difusa a propriedade sobre políticas e resultados.

FAQ

O agente precisa seguir regras fixas em todas as decisões?

Não. O ponto é distinguir onde a inferência agrega valor e onde uma política comercial exige execução determinada. Essa separação deve ser explícita e homologável.

Mais testes resolvem o problema?

Testes são necessários, mas não substituem critérios de decisão. Sem critérios, novos testes tendem a cobrir exceções isoladas e a aumentar o ciclo de homologação.

Quando uma exceção deve voltar para o time técnico?

Quando houver falha de integração, execução ou comportamento técnico. Se a origem for uma política ausente, uma alçada indefinida ou um conflito comercial, a decisão precisa voltar ao responsável de negócio.

Como saber se a implementação está realmente pronta?

Quando os fluxos relevantes, inclusive seus limites, possuem regras, alçadas, evidências e caminhos de exceção definidos. O funcionamento do agente é uma parte desse estado, não sua totalidade.

Quem já vive isso

Paulo Renan S., em avaliação publicada no portal Software Advice, descreve uma capacidade relevante para ambientes que precisam evoluir sem perder controle:

“Entregando evolução consistente, escalável e com correções de rota ágeis.”

Ver o depoimento no Software Advice

Um caso que ilustra

O case LI-966729, do acervo fornecido, mostra a mesma questão em outro contexto: a baixa penetração digital no agro decorre menos da ausência de canais e mais da falta de governança na negociação.

Segundo o resumo do case, estruturar cotação, preço contextual, crédito e barter em um fluxo integrado reduz o custo de transação e libera o RTV para atuar como consultor técnico.

A conexão com a IA agêntica está na arquitetura da decisão. Integrar um canal ou adicionar um agente não basta quando preço, crédito, contexto e exceções continuam distribuídos em critérios implícitos. A automação passa a ser sustentável quando a negociação possui regras, alçadas e caminhos verificáveis.

Link público do case não informado no material fornecido.

Sobre esta publicação

“O Custo da Venda” analisa como decisões, exceções e coordenação operacional afetam a eficiência comercial B2B.

Na etapa final dessa análise, o custo de transação oferece uma medida útil: quantas validações, interações, aprovações e correções são necessárias para concluir uma negociação com controle?

A CWS atua como uma B2B Commerce Platform for Governed Negotiation, organizando a negociação comercial para que regras, contexto, alçadas e exceções sejam tratados de forma governada. Nessa arquitetura, a IA pode ampliar a capacidade operacional sem assumir decisões para as quais a empresa ainda não definiu critérios.

O objetivo não é eliminar a homologação. É evitar que ela continue sendo o lugar onde a organização descobre, indefinidamente, como deveria decidir.

Fontes

• Tese “O agente entrou no ERP. O go-live ficou preso na homologação”, material-base fornecido para este artigo, sem link público informado.
• Software Advice, avaliação de Paulo Renan S. sobre a CWS Platform: https://www.softwareadvice.com/product/546664-CWS-Platform/
• Case LI-966729, acervo fornecido sobre governança da negociação no agro, sem link público informado.