Resposta direta: escolha o parceiro pela capacidade de provar uma transação corporativa completa e controlada, não pela qualidade isolada de uma resposta do modelo. Exija evidências em sete dimensões: resultado e fronteira, contratos de dados, identidade e autorização, orquestração e APIs, confiabilidade e fallback, observabilidade e economia, e propriedade e transferência. Antes do rollout, execute um teste com dados representativos, uma integração indisponível, uma permissão negada e uma mudança de contrato. A empresa deve mostrar como impede ações indevidas, registra cada decisão e mantém o processo operável quando IA ou legado falham.
A maioria dos projetos corporativos de IA não termina no modelo. Para gerar valor, a solução precisa consultar fontes, interpretar contexto, pedir aprovação, gravar em sistemas, acionar pessoas e lidar com exceções. É nessa cadeia que surgem atrasos, custos e riscos. Um parceiro forte trata o legado como parte do produto: conhece seus contratos, limitações, donos e modos de falha, e propõe uma evolução incremental que não esconde dependências.
Integration Delivery Proof-7
Pontue cada dimensão de 0 a 4: ausente, descrita, demonstrada, validada em ambiente representativo ou operada em contexto comparável. O máximo é 28. Identidade, autorização, rastreabilidade e reversão devem ser gates eliminatórios; não podem ser compensados por uma boa média. Solicite o mesmo pacote de evidências a cada finalista.
1. Resultado e fronteira do sistema
Comece pela decisão ou tarefa que deve terminar melhor: resolver uma solicitação, atualizar CRM, reconciliar documento, recomendar ação ou executar etapa operacional. Exija baseline, volume, exceções, donos e resultado econômico. O desenho precisa indicar onde a IA recomenda, onde uma regra decide, onde uma pessoa aprova e onde um sistema registra. Sem fronteira explícita, o escopo cresce enquanto responsabilidade e aceite permanecem vagos.
2. Contratos de dados e contexto
Peça inventário de fontes, proprietários, finalidade, qualidade, atualização, campos sensíveis e regras de retenção. Cada integração precisa de contrato de esquema, validação, versionamento e tratamento para dados ausentes, atrasados ou conflitantes. O parceiro deve explicar como impede que conteúdo não autorizado entre no contexto e como reconcilia a resposta com o sistema de registro. Dados “disponíveis” não são necessariamente dados confiáveis ou permitidos.
3. Identidade, autorização e aprovação
A solução deve agir com a identidade correta e o menor privilégio necessário. Avalie autenticação, autorização por objeto e função, segregação de funções, credenciais de máquina, consentimento e aprovação humana. O OWASP API Security Top 10 destaca falhas de autorização e autenticação entre os principais riscos de APIs. Peça testes negativos: o que ocorre quando um usuário tenta acessar outro cliente, executar função superior ou induzir o agente a usar uma ferramenta proibida?
4. Orquestração, APIs e compatibilidade
Exija um diagrama ponta a ponta com modelos, gateways, filas, APIs, conectores, regras, sistemas de registro e canais. Verifique limites de taxa, idempotência, timeouts, retries, duplicidade, versionamento e compensação de transações. O parceiro deve manter inventário de APIs e avaliar serviços consumidos, pois o OWASP também aponta consumo inseguro e inventário inadequado. Prefira adaptadores substituíveis a acoplamento direto com um único modelo ou fornecedor.
5. Confiabilidade, fallback e reversão
Defina comportamento para modelo indisponível, latência alta, resposta inválida, API fora do ar, escrita parcial e conflito de dados. Exija circuit breaker, fila, modo somente leitura, rota manual, reconciliação e rollback quando aplicável. Um processo que “funciona” apenas no caminho feliz é uma demonstração. O teste de aceite deve incluir interrupções e provar que nenhuma ação crítica fica invisível ou sem responsável.
6. Observabilidade, avaliação e economia
Logs soltos não bastam. Peça correlação entre intenção, contexto, chamada de modelo, ferramenta, sistema, aprovação e resultado, com proteção de dados sensíveis. OpenTelemetry organiza observabilidade por traces, métricas e logs; a proposta deve mostrar quais sinais revelam qualidade, latência, erro, custo e impacto. Combine avaliação da resposta com métricas do processo e custo total por resultado, incluindo revisão humana, suporte e reprocessamento.
7. Propriedade, operação e transferência
Separe código, conectores, prompts, avaliações, dados, modelos, licenças e serviços gerenciados. Exija repositório, documentação, infraestrutura como código, runbooks, acesso a telemetria, backlog, treinamento, suporte, SLAs e plano de saída. O NIST SP 800-218A reforça práticas ao longo do ciclo de desenvolvimento; isso exige versões, testes e responsabilidades que sobrevivem à equipe inicial. O comprador precisa conseguir operar, auditar e trocar componentes.
Teste de ruptura para os finalistas
Use o mesmo cenário com todos: o CRM altera um campo obrigatório; a API começa a responder com atraso; uma credencial perde permissão; e o modelo tenta repetir uma gravação. Peça desenho, sequência de eventos, controles, telemetria, mensagem ao usuário, reconciliação e responsável. A qualidade da resposta mostra se a empresa entende integração distribuída ou apenas sabe conectar um modelo a uma API em uma demo.
Piloto vertical antes da expansão
Selecione uma jornada de ponta a ponta com valor e risco controláveis. Inclua casos comuns, exceções, dados reais governados, uma escrita em sistema e um fallback humano. Congele critérios para qualidade, autorização, latência, disponibilidade, custo e reconciliação. O Perfil de IA Generativa do NIST recomenda medir e gerenciar capacidades, limites e impactos; o piloto deve transformar isso em evidência para decidir parar, redesenhar ou escalar.
Como comparar propostas
Normalize premissas: volume, integrações, ambientes, dados, modelos, disponibilidade, suporte e responsabilidades. Compare custo de descoberta, construção, licenças, consumo, observabilidade, segurança, manutenção e mudança. Desconfie de preço fechado sem inventário técnico e de cronograma que ignora acessos e donos do legado. Vincule pagamentos a entregáveis e gates: contrato de dados, integração validada, teste negativo, recuperação, documentação e aceite operacional.
Sinais eliminatórios
Desclassifique quem solicita credenciais amplas; não testa autorização; não registra chamadas de ferramentas; trata retries como detalhe; não explica dados enviados a terceiros; depende de um ambiente manual impossível de reproduzir; ou não oferece exportação e transição. Também é alerta prometer substituir o legado antes de mapear regras e exceções que ele incorpora.
Próximo passo
Use este framework com o guia de automação em https://makinai.co/insights/pt/como-escolher-empresa-automacao-processos-ia, a avaliação de agentes em https://makinai.co/insights/pt/como-avaliar-empresa-agentes-ia-checklist-producao e o guia de contrato e SOW em https://makinai.co/insights/pt/o-que-incluir-contrato-sow-servicos-ia. Para integrar agentes, automações e sistemas com uma entrega orientada a resultado, visite https://makinai.co/services/pt/desenvolvimento-agentes-ia-automacao.