Construir ou contratar IA: como decidir com controle

A decisão entre construir ou contratar IA começa pelo desenho de controle, dependência e aprendizagem. A pergunta melhor é: quais partes da capacidade de inteligência artificial precisam ficar sob controle da empresa, quais podem depender de terceiros e quais aprendizados a equipe precisa acumular para evoluir o produto?

Quando a decisão vira apenas compra de ferramenta, a liderança pode acelerar uma entrega e, ao mesmo tempo, perder clareza sobre diferenciação, qualidade, risco e dependência.

Quando a pergunta não é ferramenta, mas controle

A situação costuma começar de forma simples. Alguém encontra uma solução pronta, uma API ou um assistente configurável. A demonstração parece boa. A equipe imagina encaixar aquilo no produto. A liderança pergunta se faz sentido desenvolver IA internamente ou comprar IA de um fornecedor.

Por trás da escolha aparecem decisões sobre controle, aprendizagem, risco operacional e dependência.

Você não está decidindo apenas se vai usar tecnologia externa. Muitas capacidades de IA em produto combinam componentes externos, dados internos, regras de produto, experiência de usuário, avaliação de qualidade e operação contínua. Mesmo quando a empresa decide desenvolver IA internamente, é comum usar modelos de base, infraestrutura de nuvem, bibliotecas e serviços de terceiros. Mesmo quando decide contratar, ainda precisa definir o comportamento esperado, testar limites e assumir responsabilidade pela experiência entregue ao cliente.

Por isso, construir ou contratar IA é uma decisão de desenho organizacional. Ela define onde a empresa quer aprender, onde aceita depender e onde não pode perder capacidade de julgamento.

Esse cuidado é coerente com a forma como o relatório DORA 2025 apresenta a IA: como uma amplificadora das forças e fraquezas existentes na organização, com o sistema organizacional influenciando o retorno obtido. A fonte não prova que IA gera produtividade automaticamente, nem que uma opção de arquitetura seja superior. Mas reforça um ponto prático: tecnologia aplicada sobre um processo frágil tende a expor a fragilidade.

Se a sua empresa ainda está organizando a direção estratégica, vale conectar esta decisão ao quadro maior de estratégia de inteligência artificial conectada ao negócio. A escolha entre construir, contratar ou combinar só melhora quando existe clareza sobre o problema que a IA deve resolver.

Separar a capacidade de IA em partes decidíveis

A decisão build or buy, expressão usada para comparar construir internamente ou comprar uma capacidade pronta, fica pobre quando trata IA como um bloco único. Uma capacidade de IA no produto pode ser separada em partes menores e mais decidíveis.

Em vez de perguntar “vamos construir ou contratar?”, a liderança pode mapear:

A interface com o usuário: onde a IA aparece, como a pessoa interage e que grau de controle ela mantém.
O modelo: o componente que gera, classifica, recomenda ou interpreta informações.
Os dados de contexto: informações do produto, do cliente, do histórico de uso ou do domínio que orientam a resposta.
As regras de negócio: critérios que limitam, priorizam ou impedem determinadas ações.
A avaliação de qualidade: testes, revisão humana, métricas e critérios para saber se a resposta é aceitável.
O monitoramento: acompanhamento de erros, exceções, uso indevido, degradação e impacto na operação.
A governança de IA: responsabilidades, decisões autorizadas, limites de uso e revisão de riscos.

Essa separação muda a conversa. Talvez faça sentido contratar o modelo, usar infraestrutura externa e construir internamente a camada de contexto, avaliação e governança. Talvez uma função periférica possa ser quase totalmente contratada. Talvez uma capacidade central exija mais controle de produto, mesmo que ainda use componentes de terceiros.

O erro mais caro não é contratar. É contratar sem saber qual parte da inteligência virou dependência.

O que precisa ficar perto da proposta de valor

Quanto mais a capacidade de IA altera a promessa central do produto, mais perto ela precisa ficar da liderança de produto, da tecnologia e do conhecimento de domínio da empresa.

Isso não significa treinar um modelo próprio em todos os casos. Modelos de terceiros podem integrar produtos maduros. A questão é outra: a empresa consegue especificar o comportamento esperado, avaliar se a resposta é boa, corrigir desvios e aprender com o uso?

Um critério concreto ajuda: se a resposta da IA muda a decisão do cliente, afeta confiança ou incorpora conhecimento específico do domínio, a empresa deve preservar capacidade interna para definir, avaliar e evoluir esse comportamento.

Imagine um software de gestão para oficinas industriais que quer sugerir prioridades de manutenção a partir de descrições de falhas, histórico de peças e agenda de equipes. Se a IA apenas resume chamados, talvez a empresa possa contratar uma parte relevante da solução. Mas se a IA passa a sugerir qual máquina deve receber atenção primeiro, ela influencia operação, confiança e percepção de valor. A empresa pode usar um modelo externo, mas não deveria terceirizar completamente a lógica de prioridade, a avaliação de respostas e o aprendizado sobre exceções do domínio.

Esse raciocínio conversa com a ideia de maturidade. Uma empresa não é mais madura porque desenvolve tudo sozinha. Ela é mais madura quando sabe onde precisa de controle, onde aceita componentes externos e como aprende com a operação. Esse ponto se conecta ao diagnóstico de maturidade em IA, especialmente quando a liderança confunde adoção de ferramenta com capacidade organizacional.

O que pode ser contratado sem perder aprendizagem

Contratar pode ser a melhor escolha quando a parte contratada é comum, bem definida e pouco diferenciadora para o produto. Infraestrutura, modelos de base, transcrição, classificação genérica, busca semântica, automações administrativas e componentes padronizados podem liberar energia para o que exige domínio da empresa, se integração, custo e operação fizerem sentido.

O cuidado está em não confundir contratação de componente com terceirização do julgamento.

Mesmo quando compra uma capacidade pronta, a empresa precisa manter internamente algumas perguntas:

Que problema do cliente essa capacidade resolve?
Que erro é aceitável, revisável ou inaceitável?
Que dados podem ser usados e com quais limites?
Quem responde por uma falha em produção?
Como a equipe vai registrar exceções, feedbacks e ajustes necessários?
Em que situação a funcionalidade deve ser interrompida, reduzida ou redesenhada?

A atualização da METR sobre limites da medição de produtividade é útil como alerta contra conclusões apressadas. A organização considera os novos dados um sinal pouco confiável do efeito atual da IA sobre produtividade e aponta dificuldades de medição, incluindo seleção de participantes e tarefas e medição de tempo com agentes concorrentes. Isso não autoriza generalizar que IA melhora ou piora produtividade em qualquer empresa. Mas recomenda prudência: decisões de construir ou contratar não deveriam se apoiar apenas em expectativa abstrata de ganho.

Contratar sem medir valor aumenta o risco de terceirizar apenas a expectativa de ganho.

Como medir dependência antes de assinar a arquitetura

Dependência tecnológica não é apenas depender de um fornecedor. É perder opções relevantes quando o produto, os dados, a operação e o suporte passam a girar em torno de uma escolha difícil de substituir.

Antes de consolidar a arquitetura, a liderança pode avaliar dependências em cinco frentes:

Portabilidade de dados: os dados usados, enriquecidos ou gerados pela capacidade de IA podem ser exportados em formato reaproveitável? A empresa entende o que é dado original, dado derivado, avaliação humana e histórico de interação?
Substituição de fornecedor: trocar o componente exigiria mudar apenas uma integração ou redesenhar experiência do usuário, operação, suporte e regras de negócio?
Explicabilidade mínima para suporte: a equipe consegue entender por que uma resposta foi apresentada, ao menos o suficiente para investigar, orientar o usuário e corrigir o fluxo?
Teste de alternativas: existe um conjunto de casos reais ou simulados para comparar respostas entre abordagens diferentes, sem depender apenas de demonstrações pontuais?
Impacto de indisponibilidade: se a capacidade falhar, o produto degrada com segurança, oferece caminho manual ou simplesmente interrompe uma operação relevante?

A intenção não é buscar neutralidade total. Em software, alguma dependência sempre existe. O ponto é saber se a dependência é aceitável, visível e reversível o bastante para o papel daquela capacidade no produto.

Se a iniciativa faz parte de um plano mais amplo, essa análise deve aparecer no roadmap de IA, não apenas em uma decisão técnica isolada. Dependência que nasce invisível no piloto costuma virar restrição quando a funcionalidade ganha uso.

Exemplo fictício: assistente de triagem em um software vertical

Considere um exemplo fictício. Uma empresa de software atende operações de manutenção predial. Seu produto recebe solicitações como “ar-condicionado fazendo ruído”, “lâmpadas do corredor apagadas” ou “porta de acesso travando”. A empresa quer criar um assistente de triagem para classificar solicitações, pedir informações faltantes e sugerir encaminhamento para a equipe responsável.

Três caminhos aparecem.

No primeiro, a empresa contrata um assistente pronto. O ganho hipotético é acelerar a entrega inicial e reduzir esforço técnico no começo. O risco é tratar como genérica uma triagem que depende de categorias próprias, linguagem dos usuários, prioridades operacionais e histórico de manutenção de cada cliente. Essa opção pode fazer sentido se a IA atuar em uma camada lateral, com baixo impacto na experiência central e revisão humana clara.

No segundo, a empresa tenta construir tudo internamente. O ganho hipotético é maior controle sobre comportamento, dados e evolução. O risco é gastar energia em partes que não diferenciam o produto, como infraestrutura comum ou funcionalidades já bem resolvidas por componentes externos. Essa opção pode fazer sentido se a triagem for o núcleo da proposta de valor e se a empresa tiver capacidade real de operar, testar e manter a solução.

No terceiro, a empresa contrata um modelo ou serviço de IA e constrói internamente a camada de domínio, avaliação e governança. O modelo ajuda a interpretar texto e gerar classificações. A empresa mantém regras de prioridade, categorias do produto, exemplos de qualidade, trilhas de revisão, monitoramento de exceções e critérios para atualização. O ganho hipotético é combinar velocidade com aprendizagem interna. O risco é exigir disciplina de produto e operação, não apenas integração técnica.

Não há resposta universal. Se a triagem apenas organiza uma fila simples, contratar mais pode ser suficiente. Se a triagem influencia a confiança do cliente e a eficiência percebida do produto, a empresa deve manter mais controle sobre regras, avaliação e aprendizagem. Se a empresa não consegue testar uma resposta ruim nem revisar exceções, talvez a melhor decisão seja adiar a escala da funcionalidade, mesmo usando tecnologia pronta.

A Microsoft descreve sua plataforma de experimentação ExP como uma forma de incorporar experimentação ao ciclo de desenvolvimento, validar hipóteses, medir impacto e iterar produtos. A fonte não sustenta que feedback retreina automaticamente um modelo. O aprendizado útil aqui é de gestão de produto: hipóteses precisam ser testadas e revistas ao longo do ciclo, especialmente quando a IA muda a experiência do usuário.

Matriz de decisão para construir ou contratar IA

Use esta matriz em uma conversa executiva antes de fechar a arquitetura da capacidade de IA.

A capacidade de IA altera diretamente a promessa central feita ao cliente? Se sim, não trate como simples compra. Preserve capacidade interna para definir comportamento, avaliar qualidade e decidir evolução.
O desempenho depende de conhecimento específico do domínio da empresa ou do cliente? Se sim, considere construir ou manter internamente a camada de contexto, regras, avaliação e curadoria, mesmo que o modelo seja contratado.
A empresa conseguiria explicar, testar e corrigir uma resposta ruim em produção? Se não, a decisão ainda não está pronta. Antes de escalar, defina mecanismos de avaliação, revisão humana e responsabilidade operacional.
A troca de fornecedor exigiria redesenhar produto, dados, suporte e operação? Se sim, a dependência é estratégica. Avalie arquitetura modular e preservação de dados em formatos reaproveitáveis, sem transformar isso em promessa de neutralidade total.
A equipe aprende algo relevante a cada ciclo de uso da capacidade de IA? Se não, contratar pode acelerar entrega, mas não necessariamente aumenta competência interna. Defina quais aprendizados serão registrados: erros, exceções, feedback do usuário, limites do modelo e decisões de ajuste.
Existe uma função comum, pouco diferenciadora e já bem resolvida por terceiros? Se sim, contratar pode liberar energia para o que diferencia o produto, desde que a empresa mantenha controle sobre integração, dados sensíveis, experiência do usuário e avaliação de impacto.
A iniciativa depende de experimentação contínua para provar valor? Se sim, a decisão deve incluir como hipóteses serão testadas, medidas e revisadas ao longo do ciclo de desenvolvimento.

A matriz deve terminar com uma posição explícita para cada parte da capacidade de IA: construir perto do núcleo, contratar componente padronizado, combinar modelo externo com camada própria de domínio ou adiar até existir capacidade de avaliar qualidade e risco.

Antes da próxima demonstração sedutora, a pergunta útil é mais simples e mais difícil: se esta IA errar, aprender ou virar dependência, quem na empresa terá condição real de decidir o que fazer?

Se quiser discutir essa decisão no contexto da sua empresa, converse com a dooop.

Leituras para continuar

Fontes

Para continuar esta leitura

Como alinhar uma expansão de IA à capacidade de operação

PRÓXIMA DECISÃO

Conversar sobre a aplicação na empresa

Conversa sobre o contexto da empresa de software

Conteúdo de dooop. O cadastro permite relacionar esta pauta à jornada do leitor e acompanhar o interesse pelo tema.