Medir para escalar: o problema que bloqueia a IA empresarial
Há dois anos, a maioria dos executivos que conheço debatia sobre qual modelo de linguagem escolher. Hoje, os que já tomaram essa decisão — e mesmo assim não conseguem justificar uma segunda rodada de investimento — começam a entender que o problema nunca foi o modelo. Foi a mensuração.
O setor empresarial vem adotando inteligência artificial em ritmo acelerado há vários anos. Segundo a McKinsey, 88% das organizações já incorporaram IA em pelo menos uma função de negócio. Mas apenas um terço delas começou a escalar essa tecnologia com consistência. Essa lacuna — entre testar e escalar — não é tecnológica. É organizacional, e tem origem em uma conversa que a maioria das equipes diretivas evitou ter com precisão: o que significa, em termos operacionais e financeiros, que isso funcione.
Na Sustainabl, observamos há algum tempo como as empresas constroem seus casos de investimento em IA. O que vemos com maior frequência não é incompetência técnica. É uma confusão de camadas: mede-se o que o fornecedor entrega — pontuações em testes padronizados, precisão em laboratório, rankings comparativos — e esquece-se de medir o único dado que o conselho de administração precisa ver: o que mudou no negócio.
A armadilha do benchmark e o que ela revela sobre a liderança
Quando uma equipe diretiva avalia modelos de IA comparando pontuações de referência, está repetindo um erro que o mundo tecnológico já cometeu com os servidores nos anos noventa: comprar especificações em vez de resultados. O problema não é que os benchmarks sejam inúteis. É que eles respondem a uma pergunta diferente.
Os benchmarks medem o quão bem um modelo resolve tarefas padronizadas, em condições controladas, com dados que não têm nada a ver com os fluxos reais da sua empresa, sua base de conhecimento proprietária nem seus casos-limite específicos. O que ocorre em produção — com os dados que você tem, os processos que já existem e os usuários que interagem diariamente — pode diferir dessas métricas em 15 a 25 pontos percentuais. Essa lacuna não é um detalhe técnico. É a distância entre uma promessa de fornecedor e um resultado de negócio.
O que me interessa aqui não é a engenharia do modelo. Me interessa o que essa confusão revela sobre como as organizações operam quando enfrentam tecnologia nova. Existe um padrão recorrente: diante da incerteza, a liderança tende a delegar o critério de sucesso ao domínio técnico. Adota-se a linguagem dos engenheiros — precisão, recall, pontuação F1 — sem traduzi-la para a linguagem do negócio. E isso não acontece porque a liderança seja incompetente. Acontece porque ninguém quis ter a conversa desconfortável de definir o que significa fracassar com esse investimento.
Essa conversa tem um custo. Quando um projeto de IA chega aos 90 dias sem conseguir mostrar movimento em nenhum indicador operacional, o debate se torna político antes de se tornar analítico. Cada área defende sua interpretação, ninguém quer ser o responsável pelo resultado e o projeto se sustenta por inércia ou é cancelado por frustração. Ambos os desfechos são evitáveis se a equipe diretiva estabelecer desde o início — antes de escolher o modelo, antes de selecionar o fornecedor — quais indicadores de negócio vão se mover e em quanto.
O que um diretor financeiro precisa ouvir
Há um teste que aplico mentalmente quando analiso propostas de investimento em IA: imaginar o diretor financeiro lendo o caso de negócio doze meses após o desdobramento. Se o documento só consegue mostrar que o modelo obteve 93% em um benchmark de raciocínio, o projeto está em risco. Não porque esse número seja irrelevante, mas porque não responde a nenhuma das perguntas que um diretor financeiro faz quando autoriza um segundo ano de orçamento.
As perguntas reais são: quanto baixou o tempo de resolução por caso, quanto melhorou a taxa de resolução no primeiro contato, quanto custou cada interação assistida por IA frente a uma completamente manual, quanto tempo levaram os novos agentes para atingir um nível operacional aceitável. Essas métricas não são entregues pelo modelo. São entregues pela arquitetura completa do sistema: a qualidade do dado, o design da recuperação de informação, a latência de integração, os mecanismos de controle. O modelo é uma variável dentro desse sistema. Frequentemente, não é a variável mais determinante.
O que se mede em produção, contra os dados próprios da empresa e com os casos-limite reais do negócio, é o que define se a solução entrega valor. Um modelo mais modesto, melhor calibrado à base de conhecimento específica e aos padrões linguísticos do cliente, pode superar consistentemente um mais sofisticado que nunca foi ajustado para aquele contexto. Já vi isso acontecer em centrais de atendimento do setor de serviços públicos: o modelo "vencedor" do benchmark acabou sendo substituído por um mais simples que se desempenhava melhor nas consultas reais dos clientes.
A implicação é direta: o modelo deve ser tratado como um componente intercambiável, e não como a identidade do projeto. As organizações que projetam suas arquiteturas com essa lógica — separando a camada do modelo da camada da aplicação — podem substituir um modelo sem desmontar toda a solução. As que não o fazem ficam presas em uma dependência técnica que encarece qualquer melhoria futura.
Um framework de três camadas que sobrevive aos ciclos orçamentários
Depois de observar múltiplos desdobramentos em setores industriais e de serviços, a estrutura de mensuração que demonstra maior durabilidade não é a mais sofisticada. É a mais legível para toda a cadeia de comando, desde a equipe técnica até o conselho de administração.
A primeira camada mede precisão em produção: qual percentual dos resultados gerados pelo sistema está correto sem correção humana, medido contra os dados reais da empresa e seus casos extremos. Não o accuracy que o fornecedor reporta. O que emerge das interações reais com usuários e especialistas internos.
A segunda camada mede eficiência operacional: se o tempo de gestão diminuiu, se as taxas de resolução melhoraram, se os escalonamentos reduziram. Essas são as métricas que justificam a continuidade. Um desdobramento que não consegue mostrar movimento em pelo menos um desses indicadores nos primeiros noventa dias tem um problema em algum ponto da pilha técnica, e esperar mais tempo para descobri-lo apenas aumenta o custo de corrigi-lo.
A terceira camada mede impacto financeiro: o custo por interação assistida frente à interação completamente manual, o período de recuperação do investimento, a economia atribuível. Essa é a camada que converte o projeto em um ativo dentro do balanço de decisões diretivas. Sem ela, a conversa sobre IA permanece no domínio dos entusiastas da tecnologia, e não no daqueles que alocam capital.
O que faz esse framework funcionar não é sua complexidade. É que ele obriga a organização a ter a conversa de definição antes de desdobrar. Definir três a cinco indicadores de negócio específicos para cada caso de uso, antes de selecionar modelo ou fornecedor, não é um exercício metodológico. É o sinal de que a liderança entende a que está se comprometendo e com qual critério avaliará se foi cumprido.
Quem mede bem, escala. Quem não mede, itera sem direção
O contexto regulatório adiciona urgência a essa conversa. A regulamentação europeia de inteligência artificial, em vigor desde agosto de 2024 com aplicabilidade ampla a partir de agosto de 2026, exige que as organizações não apenas implantem sistemas de IA, mas que consigam demonstrar que esses sistemas operam dentro de parâmetros definidos, auditáveis e não discriminatórios. Isso não é possível sem uma infraestrutura de mensuração ativa. As empresas que já possuem painéis de acompanhamento de indicadores operacionais estão, sem que tenham planejado isso, melhor posicionadas para cumprir as exigências de governança que virão.
Mas a regulação é o argumento mínimo. O argumento de fundo é de maturidade organizacional.
As empresas que conseguem escalar IA não são necessariamente as que escolheram o melhor modelo. São as que construíram a disciplina de medir, ajustar e comunicar resultados com precisão suficiente para sustentar o apoio interno ao longo do tempo. Essa disciplina exige que alguém na equipe diretiva assuma o desconforto de dizer: "Ainda não sabemos se isso funciona porque não definimos a tempo o que significaria funcionar."
Há organizações onde essa conversa nunca aconteceu porque nenhum executivo quis ser o que colocasse em dúvida o entusiasmo da equipe, ou porque o piloto chegou com ruído político demais para que alguém se atrevesse a propor critérios claros de fracasso. O resultado é o que vemos com frequência: projetos que se sustentam em iterações sem direção, com equipes técnicas otimizando métricas que ninguém no comitê diretivo consegue interpretar, e líderes que aprovam orçamentos adicionais com medo de reconhecer que o primeiro investimento não entregou o que prometia.
A IA não resolve esse problema. Ela o amplifica. Um sistema que gera centenas de milhares de interações por semana amplifica tanto o valor quanto o erro. Se você não sabe o que está medindo, tampouco saberá o que está multiplicando.
O modelo sempre vai melhorar. Os fornecedores lançarão versões mais capazes em ciclos cada vez mais curtos. O que não muda por si só é a capacidade de uma organização para estabelecer critérios claros antes de agir, medir com honestidade o que ocorre e ajustar sem precisar reconstruir o projeto do zero. Isso não é entregue por nenhum modelo. É construído pela liderança, ou não é construído por ninguém.
