Não Compre IA. Compre Resultados.

Neste exato momento, em algum lugar, um time de compras está escrevendo um documento de requisitos que cita um modelo de IA específico. Quando o contrato for assinado, esse modelo já terá sido substituído duas vezes. Quando o sistema entrar no ar, a versão citada pode já estar marcada para descontinuação.

Não é um erro de nicho. É o jeito padrão como as organizações estão comprando IA em 2026: escolhendo marcas de modelo como um dia escolheram licenças de banco de dados. E o resultado é o previsível — sistemas especificados em torno de um componente que sempre seria trocado, comprados de quem falou o nome da moda com mais confiança.

Nossa posição, como empresa que constrói esses sistemas: pare de comprar IA. Compre resultados, sob restrições, com evidências. O modelo é uma peça. Você está comprando uma máquina.

O RFP que cita um modelo já nasce obsoleto

Os modelos de fronteira se renovam num ritmo de meses. Preços caem, capacidades saltam, o vencedor do benchmark de ontem vira a opção mediana de hoje. Qualquer documento que fixa o nome de um modelo embutiu um cronograma de depreciação nos próprios requisitos.

Mas o problema mais profundo não é ficar desatualizado. É que a escolha do modelo nunca foi a decisão que determina se você extrai valor. Já vimos modelos impressionantes embrulhados em sistemas descuidados falharem em produção, e modelos modestos embrulhados em sistemas disciplinados tocarem workflows inteiros sem alarde. A diferença nunca esteve no logo. Estava no sistema em volta: qualidade da recuperação, guardrails, profundidade de integração, tratamento de falhas, avaliação. É essa a máquina que você está comprando de verdade — o que chamamos de sistemas agênticos.

Especificar o modelo é como fretar um voo ditando o fabricante do motor e deixando o destino, o piloto e as checagens de segurança por conta da imaginação do fornecedor.

O que especificar no lugar: resultados e restrições

Um bom documento de contratação de sistemas agênticos cabe em poucas páginas e quase não tem palavra técnica. São duas seções que fazem todo o trabalho.

Resultados — observáveis, testáveis, com dono:

O que o sistema precisa produzir: "primeiras versões de propostas a partir do nosso template e do arquivo de propostas antigas, em menos de uma hora, factualmente consistentes com os documentos-fonte."
A régua de qualidade e como ela é medida: testes de aceitação sobre casos históricos reais, não demos do fornecedor com casos escolhidos a dedo.
O portão humano: quem aprova o quê, e o que o sistema pode fazer sem aprovação (normalmente: nada externo).

Restrições — os inegociáveis:

Fronteiras de dados. O que pode sair do seu ambiente, o que não pode, onde ficam os embeddings, quem pode auditar.
Tetos de custo. Custo por interação ou por resultado no volume-alvo — não só o preço da licença.
Comportamento de escalonamento. O que acontece quando a confiança é baixa: silêncio, chute ou passar para um humano? (Só uma dessas respostas é aceitável.)
Observabilidade. Toda ação registrada, toda saída rastreável até as fontes.
Saída. Seus prompts, seus workflows, seus dados, seus evals — portáveis no encerramento. Se o fornecedor hesitar aqui, você aprendeu algo importante bem cedo.

Especifique o destino e os guardrails. Deixe quem constrói escolher o motor — e torne essa pessoa contratualmente responsável por trocá-lo quando existir um melhor.

Repare no que isso faz: converte a rotatividade de modelos de risco seu em vantagem sua. Quando os modelos por baixo melhorarem — e vão melhorar, a cada trimestre —, um sistema comprado por resultado fica melhor sob o mesmo contrato.

Dez perguntas que separam quem constrói de quem revende

Use na conversa com o fornecedor. Não são pegadinhas; quem constrói de verdade gosta delas.

Me mostre seu harness de avaliação. Como nós dois vamos saber que o sistema continua funcionando no próximo trimestre?
O que acontece, passo a passo, quando o modelo devolve besteira?
O que acontece quando o provedor descontinua a versão do modelo em que vocês fizeram o deploy?
Quais partes do sistema são código determinístico e quais são julgamento do modelo? Por que essa divisão?
Como o sistema se comporta com dez vezes o volume da demo?
Para onde vão nossos dados, exatamente — e o que fica retido depois que a gente sair?
Como é o fluxo de aprovação humana às 18h de uma sexta-feira?
Qual é o custo por resultado no nosso volume, no pior cenário?
Qual falha em produção você tem mais orgulho de ter resolvido? (Quem constrói tem histórias. Quem revende tem slides.)
O que vocês vão se recusar a automatizar para a gente, e por quê?

O padrão por trás das dez: evidência de produção acima de carisma de demonstração. A distância entre as duas coisas é o assunto inteiro de O Abismo entre a Demo e a Produção, e por que a classe errada de fornecedor continua ganhando contratos é o assunto de Por Que Seu Integrador Não Consegue Construir Agentes.

Por que isso é mais difícil do que parece

Comprar por resultado exige algo desconfortável de quem compra: você tem que efetivamente definir o resultado. "Queremos IA no atendimento" é um desejo. "Sessenta por cento dos tickets de nível um resolvidos sem toque humano, medido sobre os tickets reais do último trimestre, com escalonamento em qualquer coisa que envolva dinheiro ou irritação" é uma especificação. O fornecedor não pode fazer essa parte por você — e o fornecedor que se oferece está te vendendo sua própria lição de casa, corrigida com generosidade.

Também exige honestidade sobre restrições. Se o jurídico nunca vai permitir dados de clientes num modelo de terceiros, isso entra no documento no primeiro dia, não no quarto mês. Restrições descobertas tarde são o jeito como projetos de IA morrem em silêncio.

Tem um bônus para quem compra na Europa: os programas de inovação financiada já pensam assim. Os pedidos de financiamento exigem resultados mensuráveis, marcos e verificação — ou seja, um projeto de IA especificado por resultado já está na metade do caminho de ser financiável. Se você vai escrever critérios de aceitação de qualquer jeito, é melhor deixar o financiamento público pagar parte da construção — instrumentos portugueses e da UE costumam cofinanciar de 45% a 75% dos custos elegíveis em projetos qualificados, o que transforma uma construção de €60 mil a 60% em ≈€24 mil líquidos.

Como isso funciona na prática

Regra da casa, como sempre: nada de clientes inventados, nada de métricas fictícias. Nossa própria operação e um arquétipo.

Como escopamos os projetos. Todo projeto da Gravitnomad começa com uma definição de resultado e testes de aceitação antes de qualquer discussão de arquitetura — porque preferimos perder um negócio na fase de especificação a ganhar um negócio vago. Nossos próprios sistemas são model-agnostic por princípio: o hub de publicação que transforma um único brief em post de blog, LinkedIn e Facebook roda sobre trilhos determinísticos, com chamadas ao modelo nos pontos de julgamento — trocar o modelo por baixo é mudança de configuração, não reconstrução. O motor multi-tenant que renderiza este site trata geração e renderização como camadas separadas pelo mesmo motivo. Trilhos primeiro, motores intercambiáveis — a filosofia que destrinchamos em Determinismo É uma Feature.

O arquétipo: uma PME comprando um agente de suporte. A versão orientada a resultado dessa compra especifica taxa de contenção sobre tickets históricos, restrições de tom, gatilhos de escalonamento, custo por ticket resolvido e um relatório mensal de avaliação — e nunca cita o nome de um modelo. Três fornecedores respondem. Aquele que pede seu arquivo de tickets para montar os testes de aceitação antes de orçar? Esse constrói.

O piloto, estruturado direito

"Vamos começar com um piloto" soa prudente, e a maioria dos pilotos é estruturada para não provar absolutamente nada. Dados escolhidos pelo fornecedor, nenhum critério de aceitação, nenhum volume e, no fim, uma demo que todo mundo aplaude — seguida de um projeto de produção que se comporta como um estranho. O piloto era teatro; o aplauso era a entrega.

Um piloto que vale a pena rodar tem cinco propriedades. Dados históricos reais — seu trimestre mais feio, não uma amostra higienizada. Testes de aceitação acordados antes de começar — nota de corte definida por você, sobre casos que você escolheu. Um preço — piloto gratuito seleciona fornecedor vendendo esperança com o próprio caixa; piloto pago seleciona quem constrói e espera ser medido. Uma janela fixa — de seis a oito semanas; mais que isso é um projeto com crachá de piloto. Artefatos portáveis — a suíte de avaliação, as definições de workflow e as conclusões são suas no fim, independente de qual fornecedor você escolher para a construção de verdade.

Estruturado assim, até um piloto que fracassa é informação barata: você descobre onde seus dados são mais frágeis do que imaginava, quais restrições apertam e o que a especificação de resultado deveria ter dito. Estruturado do jeito de sempre, um piloto bem-sucedido é ruído caro. Compre informação, não aplauso.

O checklist

Antes da sua próxima compra de IA, uma página: o resultado em números; os testes de aceitação e quem os executa; fronteiras de dados; custo por resultado em volume; portões de escalonamento e aprovação; observabilidade; condições de saída; responsabilidade pela troca de modelo. Se uma proposta não responde a essa página, a proposta é marketing. E, para calibrar enquanto você lê os orçamentos: uma automação focada de um workflow, endurecida para produção, costuma levar de 4 a 8 semanas e custar €18 mil–€45 mil; um sistema agêntico com recuperação sobre o conhecimento da sua empresa, de 6 a 12 semanas e €30 mil–€70 mil; evolução contínua, €2 mil–€6 mil por mês. Um orçamento muito fora desses formatos não está necessariamente errado — mas deve a você uma explicação.

Temos prazer em estressar uma especificação de resultado antes de você mandar para qualquer fornecedor — inclusive antes de mandar para a gente. Entre em contato; traga o desejo, e a gente ajuda você a transformá-lo numa especificação pela qual quem constrói possa ser cobrado.