Não compre IA. Compre resultados.

Neste preciso momento, algures, uma equipa de compras está a redigir um caderno de requisitos que nomeia um modelo de IA específico. Quando o contrato for assinado, esse modelo já terá sido substituído duas vezes. Quando o sistema entrar em produção, a versão indicada pode já estar marcada para descontinuação.

Não é um erro de nicho. É a forma predefinida como as organizações estão a comprar IA em 2026: às compras por marcas de modelos como outrora andavam à procura de licenças de bases de dados. E produz o resultado previsível — sistemas especificados em torno de um componente que sempre esteve destinado a ser trocado, comprados a quem pronunciou o nome da moda com mais convicção.

A nossa posição, enquanto empresa que constrói estes sistemas: deixe de comprar IA. Compre resultados, sob restrições, com evidência. O modelo é uma peça. O que está a comprar é uma máquina.

O caderno de encargos que nomeia um modelo já nasce obsoleto

Os modelos de fronteira renovam-se ao ritmo de meses. Os preços caem, as capacidades dão saltos, o vencedor do benchmark de ontem passa a opção de gama média hoje. Qualquer documento que fixe o nome de um modelo embutiu um plano de amortização nos seus próprios requisitos.

Mas o problema mais profundo não é a desatualização. É que a escolha do modelo nunca foi a decisão que determina se há valor. Já vimos modelos impressionantes embrulhados em sistemas descuidados falharem em produção, e modelos modestos embrulhados em sistemas disciplinados a fazer correr fluxos de trabalho inteiros sem darem nas vistas. A diferença nunca esteve no logótipo. Estava no sistema à volta dele: qualidade da recuperação de informação, guardrails, profundidade da integração, tratamento de falhas, avaliação. É essa a máquina que está realmente a comprar — aquilo a que chamamos sistemas agênticos.

Especificar o modelo é como fretar um voo ditando o fabricante dos motores, deixando o destino, o piloto e as verificações de segurança à imaginação do fornecedor.

O que especificar em vez disso: resultados e restrições

Um bom documento de contratação de sistemas agênticos cabe em poucas páginas e quase não contém palavras técnicas. Tem duas secções que fazem todo o trabalho.

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

O que o sistema tem de produzir: «primeiras versões de propostas a partir do nosso template e do arquivo de propostas anteriores, em menos de uma hora, factualmente consistentes com os documentos de origem».
O nível de qualidade e como é medido: testes de aceitação sobre casos históricos reais, não demonstrações do fornecedor sobre casos escolhidos a dedo.
O ponto de controlo humano: quem aprova o quê e o que o sistema pode fazer sem aprovação (normalmente: nada para o exterior).

Restrições — o que não se negoceia:

Fronteiras de dados. O que pode sair do seu ambiente, o que não pode, onde vivem os embeddings, quem pode auditar.
Tetos de custo. Custo por interação ou por resultado ao volume-alvo — e não apenas o preço da licença.
Comportamento de escalamento. O que acontece quando a confiança é baixa: silêncio, palpite ou passar a um humano? (Só uma destas respostas é aceitável.)
Observabilidade. Todas as ações registadas, todos os outputs rastreáveis até às suas fontes.
Saída. Os seus prompts, os seus fluxos de trabalho, os seus dados, as suas avaliações — portáveis no momento da rescisão. Se o fornecedor hesitar aqui, aprendeu cedo algo importante.

Especifique o destino e as proteções. Deixe quem constrói escolher o motor — e torne-o contratualmente responsável por trocá-lo quando existir um melhor.

Repare no que isto faz: converte a rotatividade dos modelos de risco seu em vantagem sua. Quando os modelos subjacentes melhorarem — e vão, de trimestre em trimestre —, um sistema comprado por resultados fica melhor ao abrigo do mesmo contrato.

Dez perguntas que separam quem constrói de quem revende

Use-as na conversa com o fornecedor. Não são rasteiras; quem constrói a sério gosta delas.

Mostre-me o seu sistema de avaliação. Como é que ambos vamos saber que o sistema continua a funcionar no próximo trimestre?
O que acontece, passo a passo, quando o modelo devolve disparates?
O que acontece quando o fornecedor do modelo descontinua a versão sobre a qual entregou o sistema?
Que partes do sistema são código determinístico e quais são juízo do modelo? Porquê essa divisão?
Como se comporta o sistema com dez vezes o volume da demonstração?
Para onde vão os nossos dados, exatamente — e o que fica retido depois de sairmos?
Que aspeto tem o fluxo de aprovação humana às 18h de uma sexta-feira?
Qual é o custo por resultado ao nosso volume, no pior cenário?
De que falha em produção se orgulha mais por ter resolvido? (Quem constrói tem histórias. Quem revende tem slides.)
O que é que se recusa a automatizar para nós, e porquê?

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 é todo o tema de O abismo entre a demo e a produção, e a razão pela qual a classe errada de fornecedores continua a ganhar concursos é o tema de Porque é que o seu integrador não consegue construir agentes.

Porque é mais difícil do que parece

A compra orientada a resultados exige do comprador algo incómodo: tem mesmo de definir o resultado. «Queremos IA no apoio ao cliente» é um desejo. «Sessenta por cento dos tickets de nível um resolvidos sem intervenção humana, medidos sobre os tickets reais do último trimestre, com escalamento em tudo o que envolva dinheiro ou irritação» é uma especificação. O fornecedor não pode fazer esta parte por si — e um fornecedor que se ofereça para a fazer está a vender-lhe os seus próprios trabalhos de casa, corrigidos com generosidade.

Exige também honestidade quanto às restrições. Se o departamento jurídico nunca vai autorizar dados de clientes num modelo de terceiros, isso pertence ao documento no primeiro dia, não ao quarto mês. Restrições descobertas tarde são a forma como os projetos de IA morrem em silêncio.

Há um bónus para os compradores europeus: os programas de inovação financiada já pensam assim. As candidaturas a apoios pedem resultados mensuráveis, marcos e verificação — por isso, um projeto de IA especificado por resultados está a meio caminho de ser financiável. Se vai escrever critérios de aceitação de qualquer maneira, mais vale deixar que o financiamento público pague parte da construção — os instrumentos portugueses e europeus cofinanciam habitualmente 45–75% dos custos elegíveis em projetos qualificados, o que transforma uma construção de 60k€ a 60% em ≈24k€ líquidos.

Como isto se traduz na prática

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

Como enquadramos os projetos. Todos os projetos da Gravitnomad começam com uma definição de resultado e testes de aceitação antes de se discutir arquitetura — porque preferimos perder um negócio na fase de especificação a ganhar um negócio vago. Os nossos próprios sistemas são construídos agnósticos ao modelo por princípio: o hub de publicação que transforma um briefing em artigo de blogue e em publicações de LinkedIn e Facebook corre sobre carris determinísticos, com chamadas ao modelo nos pontos de juízo, pelo que trocar o modelo por baixo é uma alteração de configuração e não uma reconstrução. O motor multi-tenant que renderiza este website trata a geração e a renderização como camadas separadas pela mesma razão. Carris primeiro, motores substituíveis — a filosofia que desenvolvemos em O determinismo é uma funcionalidade.

O arquétipo: uma PME a comprar um agente de apoio ao cliente. A versão orientada a resultados dessa compra especifica a taxa de desvio sobre tickets históricos, restrições de tom, gatilhos de escalamento, custo por ticket resolvido e um relatório mensal de avaliação — e nunca menciona o nome de um modelo. Respondem três fornecedores. Aquele que pede o arquivo de tickets para construir os testes de aceitação antes de orçamentar? Esse é quem constrói.

O piloto, estruturado como deve ser

«Vamos começar com um piloto» soa prudente, e a maioria dos pilotos está estruturada para não provar rigorosamente nada. Dados escolhidos pelo fornecedor, sem critérios de aceitação, sem volume, e no fim uma demonstração que toda a gente aplaude — seguida de um projeto de produção que se comporta como um estranho. O piloto era teatro; o aplauso foi o entregável.

Um piloto que vale a pena tem cinco propriedades. Dados históricos reais — o seu trimestre mais feio, não uma amostra higienizada. Testes de aceitação acordados antes de começar — notas mínimas definidas por si, sobre casos escolhidos por si. Um preço — pilotos gratuitos selecionam fornecedores que vendem esperança à custa do próprio balanço; um piloto pago seleciona quem constrói e conta ser medido. Uma janela fixa — seis a oito semanas; mais do que isso é um projeto com crachá de piloto. Artefactos portáveis — a suite de avaliação, as definições dos fluxos de trabalho e as conclusões são suas no final, qualquer que seja o fornecedor escolhido para a construção a sério.

Estruturado assim, até um piloto falhado é informação barata: fica a saber onde os seus dados são mais fracos do que julgava, que restrições apertam e o que a especificação de resultados devia ter dito. Estruturado da forma habitual, um piloto bem-sucedido é ruído caro. Compre informação, não aplausos.

A 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 ao volume real; escalamento e pontos de aprovação; observabilidade; condições de saída; responsabilidade pela troca de modelo. Se uma proposta não consegue responder à página, a proposta é marketing. E para calibrar enquanto lê os orçamentos: a automatização focada de um fluxo de trabalho, endurecida para produção, leva tipicamente 4–8 semanas e 18k€–45k€; um sistema agêntico com recuperação sobre o conhecimento da sua empresa, 6–12 semanas e 30k€–70k€; evolução contínua, 2k€–6k€ por mês. Um orçamento muito fora destes contornos não está necessariamente errado — mas deve-lhe uma explicação.

Teremos todo o gosto em pôr à prova uma especificação de resultados antes de a enviar seja a quem for — incluindo antes de a enviar para nós. Entre em contacto; traga o desejo e ajudamo-lo a transformá-lo numa especificação a que quem constrói possa ser responsabilizado.