Depois que a IA devora tudo, o que ainda é inatrainável?

Título original: The Untrainable
Autor original: Sarah Guo, Conviction
Tradução: Peggy, BlockBeats

Nota do editor: Quando as capacidades de IA continuam a evoluir, uma nova visão pessimista surge no mundo dos investimentos: se os modelos ficarem cada vez mais fortes, todas as empresas de aplicação acabarão sendo engolidas por modelos e poder computacional de empresas como Anthropic, OpenAI e Nvidia, deixando no mercado apenas os modelos de ponta, o poder de computação e algumas infraestruturas básicas. Mas Sarah Guo acredita que essa visão só está parcialmente correta. Aquelas "thin wrapper" (camadas superficiais, ou seja, aplicações que apenas envolvem modelos simples) realmente serão absorvidas; tarefas que podem ser medidas por benchmarks, treinadas com dados públicos e validadas a baixo custo também se tornarão commodities.

A verdadeira questão é: após a IA engolir tudo que pode ser treinado, o que ainda é impossível de treinar?

A resposta está naquelas coisas que existem dentro de organizações reais, que não podem ser facilmente copiadas de fora: dados privados de empresas, fluxos de trabalho complexos, confiança dos usuários, permissões de sistema, julgamentos setoriais, responsabilidades de conformidade e experiências acumuladas ao longo do tempo. Os modelos podem ficar mais inteligentes, mas não podem automaticamente acessar os sistemas de produção de bancos; podem gerar respostas médicas, mas não conquistam a confiança dos médicos ou os processos decisórios hospitalares; podem escrever textos jurídicos, mas não assumem responsabilidade como advogados experientes, nem definem do zero o que constitui um trabalho jurídico de qualidade.

Portanto, as verdadeiras empresas de IA com vantagem competitiva no futuro não serão simplesmente mais inteligentes que modelos gerais, mas sim aquelas que mergulharem profundamente em um setor específico, realizando a difícil, porém crucial, tarefa de "tradução": transformar a realidade privada, as ferramentas, os processos e os critérios de julgamento do cliente em sistemas que possam agir por meio de modelos, e ao longo do tempo, definir o que constitui um "bom resultado". Quanto mais forte for a IA, mais ela desvalorizará tarefas mensuráveis e replicáveis; ao mesmo tempo, destacará aquilo que carrega história, relações, permissões e julgamento profissional — as "coisas não treináveis". Essa é a verdadeira riqueza que pode permanecer após a absorção dos modelos.

A seguir, o texto original:

Em meados de 2026, a versão de investidores do "delírio de IA" é uma sensação de desespero de que nada mais vale a pena ser investido: parece que devemos colocar todo o dinheiro na Anthropic e Nvidia, e depois voltar para casa dormir. Mas eu nunca tive essa sensação. Desde várias versões menores, tenho certeza de que os modelos já são mais inteligentes do que eu; se eu comprasse Anthropic e Nvidia pelo preço de mercado, ficaria feliz; meus amigos mais inteligentes também acreditam que a autoaperfeiçoamento dos modelos vai avançar rapidamente — mas eu ainda não sinto esse desespero.

Esse desespero não é tolo. Sua lógica é a seguinte: se os modelos continuarem a ficar mais fortes em todas as áreas, todas as empresas baseadas neles serão apenas camadas superficiais esperando serem absorvidas; o valor que restará será apenas poder computacional e os pesos dos modelos de ponta.

Tomemos como exemplo o software, que é o caso mais dependente dessa sensação de desespero. Quando Devin lançou sua primeira versão em 2024, ela só resolvia cerca de 13% das tarefas em benchmarks padrão de software, sendo então subestimada pelo mercado. Um ano e meio depois, o agente mais avançado já atingia mais de 80% de pontuação e começava a lidar com tarefas reais dentro do Goldman Sachs e do Exército dos EUA. Quase todos chegaram à mesma conclusão errada: os modelos estão engolindo a engenharia de software.

Mas, após os modelos absorverem a parte mais fácil de medir na engenharia de software, estamos redescobrindo uma verdade que muitas equipes já sabiam: que a engenharia sempre resistiu à mensuração, e que as partes mais fáceis de medir nem sempre são as mais importantes.

Mert Demirer, do MIT, e seus colaboradores finalmente quantificaram isso: entre mais de 100 mil desenvolvedores, a última geração de agentes de codificação aumentou a produção de código em cerca de 180%, mas a quantidade de código realmente entregue e colocado em produção aumentou apenas cerca de 30%. Escrever código ficou mais barato, mas as etapas restantes ainda dependem de humanos, e essas etapas são cruciais. Claro, o impacto líquido geral ainda é impressionante.

Benchmarks são algo que você pode medir; e qualquer coisa que possa ser medida pode ser usada para treinar. Assim, o agente de codificação foi o primeiro a amadurecer: compiladores são validadores gratuitos, assim como suítes de testes. Quando as respostas podem ser verificadas quase sem custo, você pode continuamente aprimorá-las até que elas se tornem perfeitas.

Mas, passar em testes não garante que uma mudança em um código de dez anos de idade seja correta. Talvez esse módulo exista por três razões que ninguém escreveu na documentação; a linha de produção pode depender de um cron job que ninguém quer admitir que escreveu.

Essa correção não pode ser lida em rankings, nem mesmo diretamente de qualquer coisa. Você só saberá se ela é eficaz ao deixar o sistema rodar por tempo suficiente no mundo real. E modelos mais inteligentes não aceleram esse processo. Ninguém confia totalmente em um sistema gigante como o Google só porque passou nos testes unitários e deu o check verde. A confiança vem do fato de que ele suportou anos de carga real.

Essa correção não é apenas privada, mas também uma barreira de proteção que se forma lentamente — uma barreira que o capital não consegue comprimir de uma vez. Mesmo os otimistas reconhecem que esse relógio não pode ser pulado. Noam Brown, pioneiro em modelos de raciocínio da OpenAI, escreveu recentemente: avaliar o desempenho de um agente ao longo de um ano provavelmente só é possível deixando-o realmente rodar por esse período.

Como Gabe Pereyra diz, a verdadeira automação não é apenas modelos mais fortes. É a mudança conjunta de produto, modelos, fluxos de trabalho e organização da empresa, sendo que três desses elementos avançam na velocidade da organização.

O que realmente motiva as pessoas, e que nenhum benchmark consegue medir, é a parte: convencer um sócio cético a mudar sua forma de lidar com as coisas, manter uma equipe unida durante uma reconstrução. É por isso que, ao contratar um CEO, valorizamos sua habilidade de lidar com pessoas tanto quanto sua capacidade analítica. Modelos mais inteligentes não mudam esse peso.

O feedback aqui é vago, o horizonte é de anos, e a confiança pertence a uma pessoa específica. Todas as empresas que conheço já fazem seus engenheiros usarem modelos de ponta, mas nenhuma delas mudou sua organização na velocidade do avanço dos modelos. Adotar ferramentas leva um trimestre, e que trimestre mágico de aumento de tokens! Mas uma reconstrução verdadeira leva anos.

O trabalho que pode ser claramente visto está desaparecendo. O trabalho de valor real, estruturalmente, é aquilo que não pode ser lido: tudo que pode estar em rankings pode ser treinado; portanto, tudo que pode ser medido está se tornando uma commodity. Esse processo leva tempo e nunca é totalmente concluído, mas seu rumo é irreversível.

Como diz meu amigo Matt MacInnis, da Rippling, em termos monetários: um token que serve apenas para responder a uma questão geral vale quase nada, pois qualquer modelo pode responder; mas um token que faz inferências com base nos dados internos da sua empresa vale muito mais, porque realiza aquilo que você realmente deseja, e não apenas gera uma resposta plausível.

O trabalho legível será engolido de duas formas.

De baixo para cima, as tarefas se saturam: assim que uma tarefa pode ser verificada a baixo custo, o comprador não se importa mais qual modelo a executou, só quanto custa. Então, ela passará a ser feita pelo modelo open source ou pelo modelo de destilação mais barato da semana. Desde que a margem de lucro seja suficiente, ela sempre será feita.

De cima para baixo, os laboratórios tentam fazer seus modelos engolirem suas próprias estruturas de suporte. Roteamento entre recuperação, chamadas baratas e caras, uso de ferramentas, estratégias de raciocínio — todos os dispositivos que antes ficavam fora do modelo estão sendo integrados ao peso do modelo, até que a "casca" se torne o próprio modelo. Essa é a fronteira de absorção.

A pressão por lucro também atua de outra forma: um agente geral precisa estar preparado para tudo, o que é caro; uma aplicação focada pode otimizar seu fluxo de trabalho até consumir apenas uma pequena fração de tokens. E, ao contrário de laboratórios que vendem tokens, as empresas podem reter a margem intermediária.

Assim, podemos fazer duas perguntas a qualquer trabalho: sua correção é privada e cara, uma verdade que só existe dentro de uma empresa? Ela está isolada em um sistema inacessível a terceiros? Juntando essas perguntas com o grau de saturação da tarefa, surge uma matriz 2×2.

Trabalhos saturados e com respostas públicas são de commodities, dominados por tokens. Trabalhos de ponta, mas com respostas públicas, como benchmarks de codificação, são áreas de laboratório, pois, quando a avaliação é gratuita, possuir o sistema não vale nada.

A verdadeira recompensa está no último canto, o "não treinável": trabalhos de ponta, cuja correção só existe em ambientes privados. Você pode perceber isso na nuvem de inferência voltada para os pioneiros da IA: a maioria dos tokens é gerada por modelos customizados, não por modelos de código aberto generalistas.

A parede que leva a esse último canto tem altura variável. Um repositório de código de um desenvolvedor é portátil e padronizado, então não é difícil acessá-lo. Mas o sistema de produção de um banco, por exemplo, não é portátil nem padronizado. Você não consegue ganhar acesso root só porque foi mais inteligente em um teste de SWE-Bench Verificado.

Capacidade pode engolir muita coisa, mas modelos melhores não transformarão padrões privados em padrões públicos. Eles não possuem licença, não assinam por responsabilidade, nem detêm os documentos da empresa; quando erram, não podem ser processados. O gargalo não é inteligência, mas permissões e responsabilidades. Você pode imaginar um modelo muito mais inteligente que qualquer pessoa, mas ele ainda precisa ser autorizado a entrar, e alguém precisa assinar por suas ações.

Essa porta tem uma fechadura e um ferrolho.

A fechadura é o ambiente: só após obter confiança dentro de um sistema, passar por uma revisão de segurança, integrar-se e assinar contratos de responsabilidade pelos resultados, você pode verificar se a IA realmente fez algo útil.

O ferrolho é o usuário. Hoje, a maioria dos médicos nos EUA abre o OpenEvidence todos os dias — algo que nenhum poder computacional pode comprar. Um laboratório pode treinar amanhã um modelo médico perfeito, mas ainda assim não consegue integrá-lo ao fluxo de trabalho dos médicos ou aos processos de decisão da UCSF. A confiança é construída lentamente, por relações e pelo consentimento do usuário, não por descida de gradiente que apague esses fatores.

Essa também é a tarefa das empresas de aplicação. Uma aplicação que ocupa um espaço no "não treinável" depende de trabalhos que, embora pouco glamourosos, são essenciais: organizar a realidade privada de uma empresa, permitindo que o modelo aja com base nela; fornecer ferramentas de ação ao modelo; e mudar, junto com o cliente, a operação de sua força de trabalho.

Uma empresa capaz de fazer essa "tradução" é difícil de copiar, e esse processo nunca termina. A integração e a manutenção continuam enquanto a relação com o cliente durar. Quem ganha essa batalha são as equipes que colocam engenheiros especializados no domínio e ferramentas ao lado do cliente.

Por exemplo, em um grande escritório de advocacia tradicional, quase mil transações de fusões e aquisições por ano. Você não pode fazer com que centenas de assistentes jurídicos baixem os documentos de clientes e entreguem a um agente genérico para leitura. Por razões de confidencialidade, isso nem é permitido, e há dezenas de outros problemas. Mesmo que fosse possível, o que se aprenderia seriam apenas fragmentos: um assistente corrigindo uma coisa de cada vez, sem ninguém conseguir entender como uma transação inteira se move.

O sinal realmente importante está no nível da transação. Cada transação tem sua forma: para fusões, NDA, lista de cláusulas, due diligence, contrato de compra, documentos anexos, lista de entregas; para litígios de propriedade intelectual, são petições, revelações de provas, tecnologia existente, mais petições. Cada área de negócio tem sua estrutura, e advogados e ferramentas não podem ser trocados livremente.

E o verdadeiro problema que essa firma precisa resolver está em um nível mais alto: como gerenciar várias áreas ao mesmo tempo, como um sócio principal que coordena centenas de casos simultaneamente, introduzindo novos clientes e treinando assistentes. Transformar uma empresa assim não é uma tarefa que se resolve com um único teste de avaliação. É preciso um gestor que trate tudo como um "jogo de beisebol de dados": objetivos intermediários muito vagos, feedback incompleto, ciclos longos, e um ambiente que nunca fica parado.

Infelizmente, o valor não legível também é difícil de vender, pelo mesmo motivo de sua dificuldade de se tornar uma commodity: uma empresa não consegue avaliar externamente se a IA pode realmente transformar sua operação como os benchmarks indicam. Assim, as empresas mais fortes param de tentar provar isso externamente e passam a entrar primeiro na organização do cliente, e a precificar os resultados.

A Sierra só cobra quando seu agente resolve o problema do cliente; se o problema é transferido para humanos, ela não cobra. Assim, o preço vira um mecanismo de avaliação. E isso funciona porque a Sierra detém o direito de definir o que é "resolvido". Devin, da Cognition, fez algo semelhante no software, lançando uma "garantia de desempenho". Só quando você é confiavelmente inserido no sistema, pode oferecer essa garantia pelos resultados.

Mesmo na camada de serviços de tokens — aquela que todos chamam de commodity pura — seu desempenho não é exatamente de commodity. As melhores empresas nativas de IA concentram seus serviços em uma ou duas fornecedoras, como Baseten ou Fireworks. Porque, embora o custo por token se torne uma commodity ao longo do tempo, a confiabilidade sob carga real e o acesso estável a poder computacional escasso não se tornam commodities. Onde oferecer o serviço de inferência e quais modelos usar são escolhas distintas. A única parte que realmente se assemelha a uma commodity na inferência é o preço.

Um argumento comum é: os laboratórios são seus fornecedores, por que eles não usam seus próprios produtos de primeira linha para vender abaixo do custo e acabar com você? Ou simplesmente revogam seu acesso à API e tomam o mercado para si? Essa é a versão mais realista dessa sensação de desespero. Mas só funciona se o nível de modelos for uma competição de um só jogador.

Obviamente, isso não é verdade. O nível de modelos é mais parecido com uma corrida de morte de três e meio jogadores, com alguns competidores internacionais com progresso cerca de seis meses atrás, e uma aliança de desenvolvimento cinco vezes maior do que no ano passado. Os clientes querem competição entre fornecedores, e os laboratórios querem participação de mercado, mais do que acabar com qualquer aplicação específica.

Você pode ver isso no mercado de competição direta entre laboratórios. Em cenários de chat com consumidores, os melhores modelos nunca conquistaram todo o mercado de forma simples. ChatGPT manteve sua liderança por anos de competição real; sua fatia de mercado perdida foi para o Gemini, por causa da distribuição do Android e de buscas, não por modelos melhores. A Anthropic é considerada atualmente a melhor em previsão de mercado e no clima da internet, mas quase não atua em chats com consumidores, focando sua atuação em ambientes empresariais e codificação.

Se um modelo melhor não consegue tirar usuários de concorrentes nas aplicações mais centrais, também não vai facilmente conquistar sistemas de prontuário hospitalar ou sistemas de responsabilidade de um banco por integração. Hoje, a preferência do público por produtos não se baseia apenas na capacidade de codificação. Se os modelos de ponta ainda estão congestionados, a camada de aplicação acima deles mantém seu valor.

Se uma tarefa não pode ser avaliada externamente, alguém dentro da organização precisa decidir o que é uma boa resposta. Essa decisão é o próprio jogo. Quando muitas dessas decisões são escritas, elas se tornam benchmarks. Harvey lançou benchmarks na área jurídica, e Sierra criou benchmarks para agentes de voz. Você só tem o direito de definir o que significa "bom" em um campo porque já está usando esse campo. E essas empresas conquistaram esse direito por meio de uma luta difícil de adoção real.

A avaliação que realmente determina o fluxo de dinheiro é privada, e se forma de forma incremental em cada empresa: ela decide o que considera um bom trabalho nesse tipo de tarefa. E isso ainda não está completo, pois a profundidade do direito é muito maior do que qualquer teste público. A OpenEvidence está consolidando o que é uma resposta clínica segura.

Tudo isso, na verdade, não é uma "medição" no sentido clássico, mas uma questão de julgamento do que é verdadeiro e do que é bom. Esses julgamentos são escritos até se tornarem padrões que todos precisam aceitar. Por mais inteligentes que os laboratórios de modelos básicos fiquem, eles não podem criar esses padrões do nada, pois esse status só existe dentro do domínio.

Essa autoridade costuma residir onde ela já existe. Advogados experientes escrevem benchmarks jurídicos. Quem define o que é segurança clínica são os médicos. O que significa "resolvido" é decidido por uma empresa que já possui relacionamento com o cliente.

A fronteira de absorção continuará a subir, pois aprenderemos a medir mais tarefas, e o que for mensurável será engolido. O terreno do "não treinável" vai se estreitando sob os pés de quem está por cima, então não há como parar em um ponto defensável. É preciso avançar continuamente em direção ao que ainda não pode ser avaliado, reavaliando riscos e reassegurando-se constantemente.

Em tarefas específicas, com seus dados privados e sistemas de avaliação próprios, você pode treinar até o limite de ponta e superar modelos gerais em cenários críticos; esse modelo dedicado se tornará uma parte da barreira de proteção. Por outro lado, se você competir apenas com base na capacidade de modelos gerais, será uma guerra de capital, e você perderá para quem tiver mais poder computacional. Essa é a armadilha mais comum para empresas com acesso superficial e tarefas altamente legíveis.

Quando uma empresa decide treinar um modelo além do estado da arte em uma vasta gama de tarefas gerais para sobreviver, o resultado geralmente depende do tamanho do data center. O desfecho final costuma ser a venda para um jogador com poder computacional suficiente, não a criação de um campeão independente.

Tudo isso é uma estratégia defensiva. O mais difícil é atacar: primeiro, decidir o que construir. Essa é a questão que tenho buscado há um ano, e acho que só encontrei três vezes. Modelos não ajudam nisso. Para onde você aponta, eles vão; mas eles não dizem o que vale a pena apontar. Não há benchmarks para isso, então não há como treiná-los.

Por isso, gigantes não tomam tudo: eles defendem seu território, enquanto a próxima inovação vem de alguém que descobriu uma nova aplicação antes dos outros. Talvez, a intenção seja um insumo mais escasso que o poder computacional.

Essa sensação de desespero está parcialmente certa. As camadas superficiais estão sendo absorvidas, e muitas coisas que parecem empresas hoje são apenas camadas superficiais. Mas a avaliação do que sobra após a absorção está errada. Os mecanismos são claros, mas o destino não.

Minha aposta é nesse caminho: a inteligência continuará a ficar mais barata, e o valor continuará a se mover para lugares que poucos modelos podem alcançar. As coisas não treináveis carregam valor histórico.

Portanto, entrar em um desses domínios, fazer as traduções que não parecem glamourosas, e começar a definir o que é "bom" lá dentro. Porque alguém sempre fará isso. As pontuações de benchmarks mais citadas deste ano são, na verdade, um mapa de domínio que logo perderá valor, e um aviso: um aviso de que alguns perderão o direito de definir o que é "bom".

[Link do original]

Clique para conhecer as vagas na BlockBeats

Participe do grupo oficial da BlockBeats no Telegram:
https://t.me/theblockbeats

Grupo de discussão no Telegram:
https://t.me/BlockBeats_App

Conta oficial no Twitter:
https://twitter.com/BlockBeatsAsia