Como escolher um parceiro de IA

A resposta curta

Quase toda avaliação testa o quão bem o fornecedor se apresenta. O que você precisa saber de verdade é se ele já levou algo parecido com o seu problema para produção e ficou lá enquanto aquilo quebrava.

As perguntas abaixo são desenhadas para incomodar quem não passou por isso. Não são perguntas técnicas, e esse é o ponto. Você não precisa avaliar a arquitetura deles. Precisa avaliar se a coisa vai estar no ar, com seu time como dono, e ainda funcionando daqui a um ano.

Os três tipos de fornecedor que você vai encontrar

A consultoria. Forte em enquadramento, discovery e gestão de stakeholder. Entrega estratégia, roadmap e recomendação. Frequentemente não constrói, ou constrói por um braço de entrega que você não conheceu.

A software house. Constrói o que você especificar, com competência e por contrato. A lacuna é que especificar um sistema de IA corretamente exige saber qual decisão vale automatizar, e essa é justamente a parte que você esperava comprar.

O fornecedor de produto. Vende uma plataforma. Rápido de começar, e a pergunta de encaixe é se o seu problema tem de fato o formato que o produto deles assume. Muitas vezes tem, e aí comprar é a decisão certa.

Nenhum deles está errado. Eles ficam errados quando você precisa de um e contrata outro, que é o que a maioria dos projetos ruins de IA de fato é.

Pergunte sobre produção, não sobre o pitch

Pergunte o que eles têm rodando em produção agora, com usuário real, que não tenham construído para si mesmos. Pergunte há quanto tempo está no ar. Pergunte o que quebrou no primeiro mês, porque tudo quebra no primeiro mês, e fornecedor que diz que nada quebrou ou é novo ou não está falando a verdade.

Depois pergunte o que eles fazem quando o fornecedor do modelo publica uma atualização que muda comportamento. Essa é diagnóstica. Um time que operou um sistema durante isso tem uma resposta específica e levemente cansada. Um time que não operou vai falar de como abordaria.

A pergunta de portfólio que revela tudo

Peça um case em que o resultado foi pior que o esperado, e o que eles fizeram. A resposta separa quem entregou de quem vendeu.

O que você quer ouvir é uma falha específica, um diagnóstico real e uma mudança que fizeram. O que você não quer é uma transição suave para um case de sucesso, ou uma resposta sugerindo que isso nunca aconteceu. Todo mundo que constrói IA em produção já foi surpreendido. Alegar o contrário é sinal mais negativo do que a falha teria sido.

Quem faz o trabalho de verdade

Peça para conhecer os engenheiros que vão estar no seu projeto. Não o líder da prática, não o arquiteto de soluções que escreveu a proposta: as pessoas que escrevem o código.

O padrão a observar é time sênior no processo de venda e um time diferente, mais barato, na entrega. É comum, raramente é declarado, e é o maior previsor isolado de um projeto decepcionante.

Uma pergunta de acompanhamento que funciona bem: quais dessas pessoas ainda vão estar no projeto no mês quatro.

Código e propriedade

O código deve ser seu, nos seus repositórios, desde o primeiro commit. Não entregue no fim, não guardado no ambiente deles, não licenciado de volta para você.

Pergunte especificamente o que acontece se você encerrar no mês três. Se a resposta honesta é que você fica com um sistema funcionando que seu time consegue operar, ótimo. Se é que você fica com um artefato que ninguém internamente entende, isso é dependência, não entrega.

E pergunte o que eles usam de proprietário. Usar ferramenta própria tudo bem. Construir a sua lógica central de decisão dentro de algo que só eles mantêm, não.

Como eles lidam com estar errados

Pergunte como eles vão saber que o sistema está funcionando, e espere resposta específica sobre avaliação em vez de uma frase sobre monitoramento. Se ninguém consegue descrever como corretude é medida, ninguém está medindo. O formato de uma resposta real está em evals de LLM e observabilidade.

Pergunte o que acontece quando o sistema dá uma resposta errada para um cliente. Quem descobre, em quanto tempo, e o que impede de repetir. Um parceiro que já passou por isso descreve um processo. Um que não passou descreve uma intenção. A engenharia por trás desse processo é o que chamamos de guardrails.

A estrutura de preço é um sinal

Cobrança por hora premia lentidão e coloca você e o fornecedor em lados opostos de toda estimativa. Preço por caso de uso coloca vocês do mesmo lado, porque eles só terminam quando está no ar.

Cuidado com qualquer coisa cobrada por assento para um sistema que toma decisão em vez de servir usuário, e com proposta em que o maior número é o discovery. Discovery que não termina com preço de produção e um plano é exploração paga. A abertura completa está em quanto custa um agente de IA.

Um scorecard de uma página

Pontue cada fornecedor de um a cinco em: tem algo comparável no ar hoje, você conheceu os engenheiros de fato, o código é seu desde o dia um, eles conseguem descrever como corretude é medida, responderam à pergunta da falha de forma específica, o preço é por resultado e não por hora, e existe uma data em que algo estará no ar diante de um usuário real.

Qualquer nota abaixo de quatro no primeiro, no terceiro ou no sétimo merece uma parada. Esses três preveem o desfecho mais que qualquer coisa na proposta. É também assim que estruturamos nossos próprios trabalhos, e por isso nosso preço é público em vez de descoberto em negociação. Veja como construímos IA em produção, ponta a ponta.