Avalie um ERP de IA pedindo a cada fornecedor para completar um resultado real, de ponta a ponta, sem ninguém no ecrã. Escolha o resultado você mesmo, faça-o abranger pelo menos três módulos, traga o agente que a sua equipa já utiliza e declare o pedido uma vez. Depois, abra os registos, faça login como um utilizador restrito e repita, e leia o registo. Pontue o que viu num cartão fixo. Um produto que precisa de uma pessoa para clicar em parte do resultado é um assistente; um produto que o completa e mostra o seu trabalho no registo, dentro das suas permissões, é um sistema agente.
A razão pela qual isto funciona é que tudo o que um slide pode afirmar, o teste pode verificar ou falsificar em uma hora, no seu ambiente, com os seus dados. Também tem a propriedade útil de ser o mesmo teste para cada fornecedor, o que torna as pontuações comparáveis.
O único teste que sobrevive a uma demonstração
Uma demonstração é uma performance. O apresentador escolheu os dados, ensaiou o pedido e sabe de quais funcionalidades se deve afastar. Nada disso é desonesto, e nada disso lhe diz o que o produto faz quando são os seus dados e o seu pedido. Se você quer saber como avaliar um ERP de IA, a resposta curta é retirar o pedido ao apresentador.
Escolha um resultado que seja importante para o seu negócio e que um júnior competente possa fazer numa tarde: faturar um cliente e cobrar-lhe, reservar stock contra uma ordem de compra e corresponder à fatura do fornecedor, ou transformar um orçamento aceite num trabalho, um cronograma e um pedido de depósito. Traga o agente que a sua equipa já utiliza, conectado de fora do produto do fornecedor através do Model Context Protocol, o padrão aberto que os clientes principais utilizam. Declare o pedido numa mensagem e retire as mãos do teclado. O que acontecer a seguir é a avaliação.
Três coisas podem acontecer. O resultado completa e os registos estão corretos. O sistema faz parte disso e entrega o resto a uma pessoa, geralmente numa fronteira de módulo ou num Guardar. Ou o próprio agente do fornecedor completa, mas nada de fora pode conectar. Cada um desses é um produto diferente, e cada um pontua de forma diferente no cartão abaixo.
Escolhendo o resultado
O resultado faz a maior parte do trabalho, por isso escolha-o antes de falar com qualquer fornecedor e use o mesmo para todos eles. Deve cumprir quatro condições.
- Ele atravessa módulos. Pelo menos três: um pedido que permanece dentro de um ecrã testa o copiloto, não o agente. Faturação mais contactos mais email mais uma tarefa agendada é uma boa forma. Recepção de stock mais ordem de compra mais correspondência de fatura de fornecedor é outra.
- Tem uma escrita nele. Ler e resumir é a parte fácil. A avaliação é sobre se o sistema permitirá que um agente mude registos, e se verifica quem está a perguntar antes de o fazer.
- Tem uma exceção óbvia. Planta um: um cliente com dois registos quase idênticos, ou uma quantidade de entrega que não corresponde à ordem. Você quer ver se o agente pergunta, adivinha ou corrige silenciosamente.
- Tem um acompanhamento no futuro. Um lembrete, um acompanhamento, uma verificação agendada. Isso testa se o agente pode deixar algo para mais tarde e se o sistema o executará quando a data chegar.
Escreva o pedido em linguagem simples antes do dia, exatamente como um responsável de operações o escreveria, e não deixe o fornecedor editá-lo. Um fornecedor que pede para reformular o pedido está a dizer-lhe onde estão os limites.
Gerindo o dia
A sequência abaixo leva cerca de uma hora por fornecedor e não precisa de ninguém técnico. Insista em fazê-lo num espaço de trabalho de teste que você controla, com dados que você carregou, com o seu próprio agente conectado. Se alguma dessas três for recusada, essa recusa é um resultado e vai para o cartão.
- Conecte o seu próprio agenteAdicione o servidor MCP do fornecedor ao Claude, ChatGPT em modo de desenvolvedor, ou a qualquer cliente que a sua equipa utilize, e faça o login. Note se é um login OAuth ou um token que tem de colar, e se o fornecedor poderia fazê-lo de todo.
- Liste as ferramentasPergunte ao agente o que é permitido fazer. Leia a lista quanto à extensão e cobertura dos módulos no seu resultado. Depois, faça login como utilizador restrito e pergunte novamente; a lista deve encolher.
- Declare o resultado uma vezDigite o pedido preparado como utilizador com permissões totais e pare. Responda apenas a perguntas genuínas do agente, como qual dos dois clientes correspondentes quis dizer. Conte os retornos.
- Verifique os registosAbra todos os registos que o pedido deveria ter tocado. Confirme a fatura, o e-mail, o movimento de stock, a tarefa. Depois, execute o mesmo pedido como utilizador restrito e veja onde é recusado.
- Leia o registo e o medidorEncontre a entrada do registo: quem perguntou, qual agente, quais ferramentas, entradas, resultados, recusas. Descubra qual foi o custo da execução e se um limite poderia tê-la impedido.
- Pontuação do diaPreencha o cartão antes de sair da sala. A memória é generosa com bons apresentadores.
O painel de resultados
Classifique cada linha de 0, 1 ou 2. Zero significa que não o viu; um significa que o viu com uma ressalva; dois significa que o viu claramente, no seu ambiente, com a evidência à sua frente. Dez linhas, portanto o máximo é vinte. Não pese as linhas antes de ter realizado o teste em pelo menos dois produtos; pesar antecipadamente é como o marketing volta a entrar.
| Linha | Como é um 2 | Razão comum para um 1 ou 0 |
|---|---|---|
| Resultado concluído | Todos os registos corretos, sem pessoa no ecrã | Devolução numa fronteira de módulo ou um Guardar |
| O seu agente está conectado | O seu próprio cliente MCP, início de sessão OAuth, sem token para colar | Apenas assistente do fornecedor, ou uma chave de API colada |
| A lista de ferramentas é real | Longo, digitado, cobre os seus módulos, legível por máquina | Uma dúzia de funcionalidades, ou uma lista apenas num slide |
| Permissões por chamada | Utilizador restrito recusado na chamada; o resto completa | Recusa apenas no carregamento do ecrã, ou uma aprovação que passa |
| Exceção tratada | A ambiguidade plantada produziu uma pergunta, não um palpite | Correção silenciosa, ou um registo errado escolhido |
| Ação futura agendada | O acompanhamento existe e será realizado na data | Uma nota num resumo, nada no sistema |
| Registo está completo | Quem perguntou, agente, ferramentas, entradas, resultados, recusas | Registos alterados, mas sem sequência de chamadas; um utilizador de integração genérico |
| O gasto é limitado | Um limite por integração que o agente não pode ultrapassar; custo por ação | Total mensal apenas, ou sem limite |
| Custo do próprio agente | Nada é cobrado quando o seu agente faz o raciocínio | IA cobrada independentemente de quem raciocina |
| Extensível por outros | Uma aplicação de terceiros instala-se e aparece na lista de ferramentas | Apenas roteiro ou trabalho personalizado |
Dez linhas, dois pontos cada. Avalie cada fornecedor com base no mesmo resultado, no mesmo dia se possível, e compare os totais apenas depois de cada linha ter um número.
Lendo o resultado
Os totais importam menos do que o padrão nas primeiras quatro linhas, porque essas quatro decidem que tipo de produto está a ser analisado. Um produto que pontua zero no resultado e zero na conexão com o seu agente é um assistente dentro de um ecrã, e o resto da sua pontuação descreve controlos que não precisa. Pode ainda ser a compra certa se o que a sua equipa deseja é um ecrã mais rápido, mas deve comprá-lo como tal.
Um produto que completa o resultado mas pontua zero na conexão com o seu agente é agente com uma porta fechada. Funciona, nos termos do fornecedor, com o agente do fornecedor, ao preço do fornecedor para raciocínio. A questão a colocar a si mesmo é o que acontece em dois anos quando o agente da sua equipa for aquele que eles querem usar, e se o fornecedor disse algo sobre abrir a porta.
Um produto que pontua dois em todos os quatro é nativo-agente, e as seis linhas restantes são onde a verdadeira comparação acontece: quão bem lida com a exceção que você plantou, quão completo é o registo, se os gastos podem ser limitados, o que cobra quando o seu agente raciocina, e se terceiros podem estendê-lo. Dois produtos nativos-agente podem diferir muito nessas seis, e são as linhas que preveem como será viver com o produto.
Uma leitura mais. Se um fornecedor recusar o teste, ou oferecer uma versão gravada, ou pedir para substituir o seu pedido pelo deles, pontue as linhas que não conseguiu observar como zero e diga porquê nas notas. Recusar é informação. Um produto que pode fazer isto quererá mostrar-lhe.
O que lhe mostraríamos
Sois é um produto contra o qual pode realizar esta avaliação, e como o construímos, podemos dizer o que veria. Um espaço de trabalho é um servidor MCP; você adiciona o seu endereço ao Claude, ChatGPT ou outro cliente e faz login uma vez através do OAuth, sem token para colar. A lista de ferramentas é filtrada pelo seu papel antes do agente a ver e verificada novamente quando cada ferramenta é executada; o acesso falha fechado. Os gastos podem ser limitados por integração, cada ação é registada, e quando o seu próprio agente faz o raciocínio, a plataforma não realiza IA em seu nome e não cobra nada por isso. As aplicações do mercado aparecem na lista de ferramentas uma vez instaladas. Aqui está o resultado da faturação do fluxo acima, à medida que é executado.
- Leitura do trabalho faturável do projeto e do registo do cliente
- Fatura criada a partir das linhas faturáveis
- Enviada para o contacto do cliente por email
- Cobrança agendada para a data de vencimento
Quatro ferramentas em contabilidade, contactos, caixa de entrada e tarefas, com o registo a mostrar cada chamada. Execute-o como um utilizador que não pode emitir faturas e a primeira escrita é recusada, com a razão.
Depois, pontue-o no mesmo cartão que todos os outros. O objetivo de um teste fixo é que não se importa quem construiu o produto, e uma avaliação que você pode defender é aquela que tratou todos os fornecedores, incluindo este, da mesma forma.
Perguntas que as pessoas fazem
Quanto tempo leva esta avaliação por fornecedor?
Cerca de uma hora uma vez que o resultado está escrito e um espaço de trabalho de teste com os seus dados existe. Carregar dados realistas e plantar a exceção é a preparação; o teste em si é um pedido, dois logins e uma leitura do registo.
E se o fornecedor não puder permitir que o meu próprio agente se conecte?
Marque essa linha como zero e execute o teste com o agente deles para que ainda veja o resultado, permissões, registo e linhas de custo. Depois, decida se uma porta fechada é aceitável para a sua equipa e pergunte ao fornecedor se e quando ela abre.
Devo ponderar as linhas do cartão de pontuação?
Não antes de ter executado o teste em pelo menos dois produtos. Classifique todas as dez linhas primeiro, depois decida quais linhas são mais importantes para a sua operação. Ponderar antecipadamente é como uma apresentação forte volta a entrar numa decisão que o teste deveria ter mantido fora.
- especificação do Protocolo de Contexto do Modelo: ferramentas listas de ferramentas, listagem dependente de autorização e a recomendação de que um humano permaneça no circuito com a capacidade de negar chamadas de ferramentas
- Anthropic: como começar com conectores personalizados usando MCP remoto adição de um servidor remoto, autenticação OAuth e aprovação por ferramenta no Claude
- OpenAI: modo de desenvolvedor do ChatGPT suporte total ao cliente MCP no ChatGPT; ações de escrita requerem confirmação por padrão
- Documentação Sois: o servidor MCP do espaço de trabalho o que o teste observa numa implementação: OAuth, ferramentas filtradas por função, execução fail-closed, limites orçamentais
Este artigo é revisto quando os produtos que descreve mudam. Próxima revisão agendada: 4 de dezembro de 2026.