OpenAI consome fortemente a camada de aplicação? a16z: as oportunidades estão além do "Caminho de Tijolos Amarelos", os empreendedores ainda têm chances atrás dele

a16z sócio aponta que a camada de aplicações de IA não é um campo único, startups devem evitar ferramentas horizontais de grandes modelos que atacam diretamente, e focar em setores verticais aprofundados. Este artigo é baseado em uma postagem no Twitter.
（Contexto anterior: Google lidera investimento na plataforma de roteamento de IA OpenRouter, avaliada em 1,3 bilhões de dólares, crescimento de 240% em um ano）
（Complemento de contexto: Sam Altman conversa com fundador da a16z: OpenAI aposta agressivamente em infraestrutura, Sora é uma ferramenta estratégica importante）

Índice deste artigo

Alternar

• Ansiedade se espalha: grandes modelos dominam a camada de aplicação?
• Armadilha do caminho de tijolos amarelos: ferramentas horizontais estão condenadas
• Oportunidade no País de Oz: barreira de proteção de fluxos de trabalho verticais
• Vantagem de custo: roteamento de modelos e pós-treinamento
• Plano de controle: valor de conformidade e governança

Essa é a questão que Joe Schmidt, sócio da a16z, tenta responder neste artigo. Ele usa a metáfora do "caminho de tijolos amarelos" de "O Mágico de Oz" para dividir as oportunidades de aplicação de IA em duas categorias: uma, o caminho principal que os laboratórios de grandes modelos estão trilhando, como geração de código, escrita, geração de imagens, agentes gerais e assistentes de escritório horizontais; outra, "outros lugares em Oz", ou seja, cenários verticais que aprofundam processos industriais, dependem de fluxos de trabalho complexos, dados sedimentados, conformidade, governança e integração de sistemas.

Na visão dele, a verdadeira oportunidade para startups está na segunda.

De vendas a seguros, Joe Schmidt reforça repetidamente uma lógica: o que as empresas realmente querem pagar não é uma janela de chat mais inteligente, mas um sistema responsável pelos resultados de negócio. Ele precisa entender o caos dos dados do cliente, lidar com múltiplas aprovações e casos limites, assumir responsabilidades de conformidade e auditoria, além de realizar migração, roteamento e otimização de custos na atualização contínua do modelo.

Essa é a principal conclusão do artigo sobre o software empresarial de próxima geração: os modelos de base ficarão cada vez mais poderosos e substituíveis; mas o que realmente não pode ser substituído são os dados, processos, capacidades de governança e memória operacional sedimentados em setores específicos e fluxos de trabalho concretos. As oportunidades de empresas de IA não estão em disputar o "caminho de tijolos amarelos" com as empresas de modelos, mas em explorar lugares mais complexos, mais sujos, mais lentos, porém mais próximos do valor real de negócio.

Recentemente, tenho ouvido repetidamente de fundadores e potenciais funcionários a mesma dúvida: ainda há o que fazer na camada de aplicação de IA? Ou será que OpenAI e Anthropic acabarão por eliminar tudo?

Por trás dessa dúvida há uma ansiedade típica de IA. Alguns já concluíram: se não quisermos ficar presos à camada de base, o único lugar de valor a longo prazo é dentro de laboratórios de modelos ou em startups de robótica, tecnologia dura ou fronteiras similares — ou seja, fazer coisas que "não podem ser feitas em laboratórios". Porque, se toda categoria de software for engolida, seja pelo Codex ou Claude, ou se um futuro modelo tornar tudo desnecessário, a melhor estratégia parece ser: correr rápido!

Reconheço que também sou quase um extremista de IA, e acho que eles têm razão em parte. Os laboratórios de grandes modelos realmente estão entrando em áreas extensas da camada de aplicação. Mas "camada de aplicação" não é uma oportunidade homogênea. O critério chave é: você está trilhando o "caminho de tijolos amarelos" ou está em outros lugares em Oz.

Nota: "Caminho de tijolos amarelos" é a via principal que leva ao centro de Oz, na Cidade Esmeralda, em "O Mágico de Oz".

O chamado "caminho de tijolos amarelos" é a metáfora que usamos para descrever a rota que os laboratórios de modelos estão trilhando, com grande investimento. Geração de código, escrita, criação de imagens são problemas naturalmente adequados a laboratórios, porque melhoram à medida que a capacidade original do modelo evolui: cada dólar investido em pré-treinamento e pós-treinamento melhora diretamente a qualidade do produto.

Por outro lado, em outros lugares em Oz, há problemas mais complexos, geralmente mais verticais. Não se trata apenas de oferecer uma ferramenta horizontal para um usuário empresarial, que resolva tudo com integração a ferramentas padrão e habilidades de computação. O valor aqui vem mais das estruturas ao redor do modelo: scaffolds que tornam as saídas confiáveis, conformes, capazes de realmente integrar-se ao fluxo de negócio. A capacidade do modelo de base é importante, mas não é tudo.

Estamos vendo isso acontecer em tempo real. OpenAI e Anthropic estão admitindo que não podem resolver todos os problemas com um colaborador de IA universal. Anunciaram investimentos massivos em projetos de implantação direta, construindo soluções completas de configuração e personalização de modelos para empresas. Se achassem que a próxima versão do modelo resolveria tudo, não investiriam bilhões nesses projetos.

Ansiedade se espalha: grandes modelos dominam a camada de aplicação?

Então, se você quer ganhar dinheiro com aplicações de IA, não trilhe o caminho de tijolos amarelos, mas construa em outros lugares em Oz. Aqui estão algumas experiências que nós e alguns fundadores do nosso portfólio aprenderam na prática.

Se você quer fundar uma empresa, o caminho de tijolos amarelos é o mais visível, mas também o mais perigoso. Pegue um modelo de alto desempenho, conecte a alguns conectores prontos, como Google Drive, Slack, Salesforce, Notion, GitHub, e construa uma camada de orquestração inteligente. Parece magia.

O problema é que isso é exatamente o que os laboratórios de modelos estão fazendo com Cowork e Codex. Claramente, eles têm modelos, o que lhes dá maior margem de lucro, controle mais forte e poder de precificação sobre todos os participantes downstream. Mas talvez mais importante, eles controlam as arquiteturas que decidem quais problemas o produto deve resolver. Até agora, eles têm adotado deliberadamente o padrão "modelo + chamada de ferramenta", que é exatamente o que esses trabalhos horizontais de baixa etapa na rota de tijolos amarelos precisam. Mesmo que uma startup consiga superar Codex ou Claude Code, os laboratórios de modelos ainda têm uma enorme capacidade de distribuição e o maior halo de marca na área de IA.

Se você é uma startup de aplicação de IA, usando a mesma abordagem: conectando-se aos mesmos conectores, sem subinteligências ou configurações próprias, sem canais de distribuição, provavelmente está trilhando um caminho para o vazio.

Para startups, a situação não é toda sombria. Fora do caminho de tijolos amarelos, ainda há oportunidades enormes. Startups podem atender clientes nesses lugares e resolver problemas complexos.

Essas empresas estão construindo experiências de inteligência: modelos integrados a ferramentas complexas, automações e redes de integração — ou seja, software. Isso faz com que a maioria dessas startups seja naturalmente verticalizada. Podem focar em fluxos de trabalho com múltiplas etapas, múltiplos participantes, projetar subinteligências específicas para diferentes papéis e cenários verticais, lidando com problemas difíceis de alcançar para plataformas horizontais como Anthropic e OpenAI: coletando contexto de múltiplos sistemas, roteando tarefas para múltiplos aprovadores em diferentes fases.

Esses trabalhos geralmente envolvem um ou mais sistemas legados, muitas vezes exigindo resultados determinísticos, pois ambiguidade é inaceitável, e às vezes vinculam-se a resultados comerciais críticos. Os laboratórios de modelos sabem o quanto esses problemas são valiosos: por isso, estão formando suas próprias equipes de configuração terceirizada, e um grupo de empresas de serviços de RLHF (Reinforcement Learning com Feedback Humano) está surgindo.

Uma objeção a esse ponto de vista é: até agora, apostar em modelos ou laboratórios que não evoluem continuamente é uma péssima estratégia. Eles provavelmente continuarão evoluindo e acabarão por engolir o mercado dessas aplicações.

Claro que os laboratórios vão continuar evoluindo. Mas, na minha opinião, empresas em outros lugares em Oz podem, a longo prazo, adotar algumas estratégias defensivas.

Muito do que você internaliza na sua operação não está nos conjuntos de dados de treinamento: práticas não documentadas, padrões não registrados, conhecimento tribal que vive na cabeça dos profissionais. Tudo isso não está na internet pública. Nenhum poder de treinamento, por maior que seja, consegue substituir o trabalho de realmente inserir esse conhecimento na rotina de trabalho.

Aqui, entram dois círculos viciosos: um, o ciclo de aprendizado cruzado entre clientes, onde quanto mais variantes de um problema você encontrar, mais seu modelo se beneficia; outro, o ciclo interno do cliente, que é entender as razões por trás de decisões específicas, as exceções não explicadas, as regras internas da empresa, que só aparecem na interação real com o sistema.

Armadilha do caminho de tijolos amarelos: ferramentas horizontais estão condenadas

Mesmo que os dados do cliente não possam ser usados entre clientes, uma empresa de aplicação pode usar o reconhecimento de padrões de problemas diferentes para orientar o design de futuros problemas. Se uma empresa já fez mil vezes uma tarefa, como modificar uma linha de regra de conformidade legal, ela tem uma compreensão que um novato não consegue copiar só com um novo modelo.

Teoricamente, um modelo horizontal também pode criar uma infraestrutura de aprendizado semelhante. Mas não o faz por falta de foco, e mais ainda por questões de experiência do usuário. Capturar esse conhecimento depende totalmente de como você fornece a interface de fluxo de trabalho ao usuário. Os players verticais podem projetar essas interfaces em torno de informações realmente necessárias para o fluxo de trabalho específico, algo que ferramentas horizontais não conseguem fazer. Conjuntos de avaliação, rotulagem de saídas, sistemas de classificação de casos limites podem formar um ciclo de dados verticalizado, apoiando ajustes finos. Se um novo participante não tiver uma infraestrutura de produção equivalente, será difícil gerar esse ciclo. Sua viabilidade depende de direitos de dados, volume de uso na produção e estrutura contratual com clientes, mas o reconhecimento de padrões continuará acumulando.

Os laboratórios de modelos já fazem roteamento interno: chamam modelos diferentes para diferentes tipos de requisições, usando integração de modelos na base. Mas eles não conseguem fazer roteamento entre fornecedores, nem avaliar modelos concorrentes para tarefas específicas, ou usar modelos open source ajustados para tarefas estreitas.

Empresas em Oz podem escolher o modelo mais adequado para cada sub-tarefa, no mercado de modelos, e não apenas usar o modelo de um laboratório. Elas também assumem trabalhos que ninguém quer fazer: reavaliar modelos toda vez que um novo é lançado, recalibrar prompts para casos limites de clientes, colocar em produção sem quebrar o ambiente. Os laboratórios de modelos não fazem isso por você. Eles vendem o novo modelo e dizem para você migrar. Empresas em Oz absorvem esse custo de migração. O cliente recebe a melhor capacidade de inteligência do mercado, com continuidade a cada atualização.

Enviar cada consulta para Opus 4.7 é o caminho mais rápido para tornar a margem de lucro negativa. As melhores empresas em Oz fazem roteamento entre diferentes níveis de modelos: tarefas mais difíceis vão para modelos de ponta, a maior parte para modelos intermediários, e tarefas já comprovadas para modelos menores ou ajustados.

Algumas dessas empresas já fazem seu próprio pós-treinamento, otimizando modelos para as tarefas específicas que o cliente realmente valoriza, oferecendo a um custo muito menor do que chamadas à API de ponta. Os laboratórios de modelos praticam preços de "piso": o menor nível de inteligência que se pode comprar por X dólares. Empresas em Oz vendem o oposto: o nível de inteligência necessário para uma tarefa específica, ao menor custo por dólar. Isso só é possível quando você sabe exatamente o nível de inteligência que cada sub-tarefa precisa. Como os laboratórios de modelos não podem entender cada tarefa de cada setor, isso acaba se traduzindo em preços mais baixos e mais controlados para resultados.

Tornar-se o plano de controle de um cliente em um setor vertical de IA gera valor significativo. Esse plano de controle é o ponto onde se concentram permissões, auditorias, o que a inteligência pode fazer e o que realmente foi feito.

Esse plano de controle é construído sobre limites específicos de uso, que variam por setor e função. Como essas empresas têm ferramentas, fluxos de trabalho e dados com contato direto com a inteligência, podem oferecer resultados com maior certeza do que ferramentas horizontais. Também assumem a complexidade regulatória: regras federais de litígio civil nos EUA, regras de prática jurídica, HIPAA na saúde, regras da SEC e FINRA no financeiro, regulamentações estaduais de seguros, etc. Se uma ferramenta horizontal não se transformar em uma centena de setores verticais, não conseguirá fazer isso de forma convincente. O CIO precisa de um parceiro que possa assumir a responsabilidade de conformidade contratual.

Tudo isso, no final, se resume a uma coisa: foco.

Esse foco pode ser uma indústria vertical, como seguros, jurídico, contábil; ou uma função aprofundada, como vendas, atendimento ao cliente, finanças. Em qualquer caso, exige uma equipe que esteja há muito tempo no mesmo tipo de cliente, entendendo seu fluxo, casos limites e requisitos regulatórios. Os laboratórios de modelos não foram criados para isso. Precisam atender a todos, cobrir tudo, o que explica por que construíram o caminho de tijolos amarelos inicialmente. Essa troca de foco também dificulta sua entrada em outros lugares em Oz: você pode estar em todos os lugares, ou fazer uma coisa muito bem feita, mas não as duas ao mesmo tempo.

Na prática, como entender isso? Aqui estão algumas recomendações práticas do CEO Prabhav Jain.

Oportunidades em Oz: barreira de proteção de fluxos de trabalho verticais

Construir uma empresa capaz de resistir ao impacto dos laboratórios de modelos é seguir uma estratégia: partir de resultados concretos que realmente importam para o cliente. Para nós, esse resultado é gerar mais leads e pipeline de vendas.

A partir daí, a questão fica muito específica: quais atividades queremos controlar do começo ao fim, que realmente impulsionam o crescimento do pipeline? Que tarefas podem ser feitas por inteligência, e quais não? Quais requerem insights profundos de domínio, e quais não? Os laboratórios de modelos também oferecem fluxos de trabalho, mas quando uma etapa tem muitas entradas, caos de dados, estados difíceis de explicar ou restrições do mundo real, só um melhor modelo não resolve. Nesse momento, o trabalho volta à engenharia de software tradicional, onde os laboratórios não têm vantagem frente a uma aplicação focada.

Por exemplo, algumas tarefas que lidamos incluem: identificar potenciais clientes com sinais customizados, completar informações de leads, pesquisa aprofundada de contas, extrair contexto do CRM, criar textos para diferentes canais, avaliar a qualificação de leads com inteligência, e sistemas de entrega de emails. Algumas são tarefas de IA, outras não. Essas tarefas não se resolvem com uma única prompt, requerem engenharia avançada.

A grande insight em Oz é: em qualquer fluxo de trabalho real, aproximadamente metade das tarefas não envolve IA, e essa metade não traz vantagem de laboratório. Fora do modelo, elas envolvem escrever software determinístico, que não é melhor do que você. A outra metade, que envolve IA, também exige que você foque no resultado desejado, ajustando, treinando e restringindo o modelo.

O conhecimento de domínio geralmente não está nos dados de treinamento genéricos. Essas capacidades precisam ser construídas de baixo para cima, a partir do setor ou função específica, e alimentadas no momento certo do fluxo de trabalho. Quando nosso IA avalia uma ligação de entrada, ela precisa entender: para um setor ou perfil de usuário específico, o que é uma boa conversa de vendas? Essa é a tarefa de uma aplicação, e essa capacidade se beneficia de efeito composto.

Mais importante, essas capacidades ficam desatualizadas à medida que a empresa evolui. Portanto, evoluir continuamente o fluxo de trabalho e o contexto se torna uma vantagem competitiva. Por exemplo, quando começamos a fazer campanhas de email em escala, "emails escritos por IA" estavam começando a aparecer. Hoje, as pessoas têm um senso aguçado para distinguir emails de IA de humanos, e essa percepção muda a cada poucos meses. Nosso IA precisa se ajustar às dinâmicas do mercado, e a barreira de proteção se constrói aqui. Apesar dessa dinâmica, nossa taxa de resposta aumentou 4 vezes nos últimos meses, gerando bilhões de dólares em pipeline de vendas.

Problemas complexos são onde o valor de negócio realmente se revela. Caso contrário, você acaba só com uma camada superficial de embalagem.

Ao decompor problemas de negócio suficientemente complexos, logo aparece o caos. Um exemplo simples do GTM: se uma empresa já é sua cliente, você não deveria mais contatar um contato específico dentro dela. Mas isso não é simples.

Talvez seu CRM tenha o domínio da empresa. E aí? Como lidar com empresas com dezenas de subsidiárias? E se o CRM tiver o domínio da matriz? E se um campo desatualizado no Salesforce fizer você enviar um email frio ao CFO de um cliente existente? Os dados do mundo real são caóticos. Humanos têm dificuldades, modelos também não passam por essa barreira mágica. Para criar ordem nesse caos, é preciso projetar IA específica para o problema, não apenas apontar uma IA genérica para o CRM. Na verdade, com os dados que temos, nossa qualidade e atualidade de dados já superam a do cliente, então, por padrão, usamos nossos próprios dados como âncora.

A importância dos limites de uso foi subestimada. Mesmo dentro de um mesmo produto, cada caso de uso precisa de seus próprios limites. Para nós, um lead regulado, por exemplo, exige garantias diferentes de um cliente SaaS de médio porte. Essas garantias se propagam para como a IA escreve, quem ela pode contatar, quais dados ela acessa, o que ela diz na ligação, e como cada decisão é registrada.

Um sistema "one-size-fits-all" colapsaria diante dessas diferenças. Os limites precisam ser construídos por caso de uso, configurados por cliente, e continuamente auditados. Essa responsabilidade recai sobre a aplicação. Por isso, precisamos de engenheiros de implantação e estrategistas de deployment, que ajustem tudo às necessidades de cada cliente.

Vantagem de custo: roteamento de modelos e pós-treinamento

Por exemplo, trabalhamos com uma instituição Fortune 1000, usando IA de voz para chamadas autorizadas a seus clientes SMB. Nas primeiras tentativas, a taxa de atendimento foi baixa. Precisamos iterar rapidamente, aprendendo a fazer com que esse público interagisse nos primeiros 10 segundos da chamada. Os comportamentos de SMBs são bem diferentes de grandes compradores B2B ou consumidores. Hoje, geramos mais oportunidades de venda por dia para eles do que toda a equipe de vendas do segmento em um mês.

Vendas é só um exemplo. Seguros é outro, ilustrando a mesma ideia sob outro ângulo. Aqui está a visão do CEO da FurtherAI, Aman Gour, sobre "sair do caminho de tijolos amarelos".

Quando começamos a implantar IA na operação real de seguros, uma hipótese recorrente era: o modelo é a inteligência, o fluxo de trabalho é só uma estrutura ao redor do modelo.

Mas, quanto mais trabalhamos com seguradoras, mais acreditamos que o oposto é verdadeiro.

Na indústria de seguros, muita inteligência já está no fluxo de trabalho. Duas seguradoras podem fazer uma submissão passar por um caminho semelhante: submissão, auditoria, cotação, aceitação. O caminho em si é fácil. O que diferencia as seguradoras é tudo que está dentro dele: quais riscos precisam de escalonamento, quais sinais de perda são críticos, qual regra de subscrição prevalece em caso de conflito, quando é preciso assinatura humana, quais dados externos consultar, e como registrar a decisão final.

Essas lógicas não estão em um motor de regras limpo. Estão dispersas em procedimentos operacionais, auditorias gerenciais, filosofias de subscrição, preferências específicas de cada seguradora, e anos de experiência operacional. Muitas delas não estão escritas em um formato que um modelo possa ler diretamente.

Por isso, não acreditamos em IA que raciocina do zero toda vez, nem em fluxos rígidos que colapsam na complexidade real. Pelo contrário, construímos fluxos de trabalho de IA. Fluxos que trazem repetibilidade, auditabilidade e controle de custos; IA que lida com variabilidade e recupera o fluxo quando ele é interrompido; humanos que permanecem nas decisões de julgamento e responsabilidade.

No começo, esse sistema automatiza tarefas humanas. Mas, com o tempo, cada melhoria vira um sinal, cada exceção uma retroalimentação, cada correção humana uma atualização do manual. No fim, o fluxo de trabalho deixa de ser só um script, e vira a memória operacional da seguradora.

Essa é a parte que os laboratórios de modelos têm dificuldade de alcançar. Eles continuam lançando modelos melhores e IA mais geral, e devem fazer isso. Mas não ficarão anos em um fluxo de trabalho de uma seguradora, aprendendo por que uma conta foi escalada, por que uma rejeição foi feita, ou por que um underwriter mudou uma regra, e estava certo.

Essa compreensão só vem de executar o mesmo fluxo milhares de vezes em produção. A primeira versão do fluxo não é uma barreira. A vantagem competitiva está na rotina de uso que se constrói ao longo do tempo.

Para nós, essa é a essência de "sair do caminho de tijolos amarelos".

Plano de controle: valor de conformidade e governança

Quantas etapas essa tarefa exige? Quão complexas são as ferramentas necessárias?

Compare com uma busca horizontal de IA no Google Drive: uma operação simples, com alta tolerância a erros. O usuário lê o resumo, se errar, pergunta de novo.

Agora, uma tarefa de revisão de limites legais baseada em precedentes de um escritório de advocacia nos últimos três anos: pode envolver dezenas de etapas, múltiplas ferramentas, saída que precisa passar por revisão de sócio, e até ser usada em tribunal. Ambas parecem "uma IA fazendo", mas só a segunda requer um sistema de software profundo, construído por uma equipe focada por anos.

Você está construindo um sistema para o cliente executar o trabalho, ou apenas adicionando uma camada inteligente ao sistema que ele já tem?

Um sistema tem fluxo de trabalho ponta a ponta: captura de dados, governança, registro de tarefas. Quando o cliente descreve como o trabalho realmente acontece, aponta para esse sistema. A ferramenta é só uma camada de inteligência adicional ao fluxo existente.

Produtos de ferramenta também geram receita real, mas os laboratórios de modelos tendem a levar isso embora, porque o cliente não depende de você como camada de orquestração. Produtos de sistema, com alto valor de contrato, indicam que o sistema substitui trabalho humano real, e por isso, podem cobrar por isso. Mas isso não é garantido. Você deve se perguntar: se um laboratório de modelos lançar um produto que pareça competir com você, o cliente ainda precisará da sua ferramenta? Se sim, você está construindo um sistema. Se não, você é uma ferramenta — mesmo com alto ACV.

O desempenho de um laboratório de modelos é avaliado por benchmarks; o desempenho de empresas em Oz, por resultados no balanço do cliente.

Os clientes não se importam com a pontuação do seu modelo no SWE-Bench ou no MMLU. Eles querem saber se sua IA fechou negócios, ajustou contratos, aprovou a apólice correta. Se o foco for o resultado de fluxo de trabalho, não a pontuação de capacidade geral, você está em Oz. Se o cliente paga por capacidade geral, está comprando o que Claude ou Codex podem oferecer.

As melhores empresas de IA funcionam como fundos de hedge: ganham com alpha, que é avaliado na linha de resultado do cliente, não em pontuações de benchmark.

Veremos grandes vencedores tanto na rota de tijolos amarelos quanto fora dela. Modelos continuarão vencendo, pois têm modelos e capacidade de distribuição de ferramentas horizontais.

Empresas em Oz também podem vencer, desde que tenham o sistema de trabalho: interface de execução real, fluxo de dados, captura de informações. Essas empresas têm coleta de dados, sistemas de fluxo de trabalho e governança. À medida que fluxos complexos de setores verticais amadurecem, eles se tornam experiências centrais que os clientes não podem abandonar. Com o lançamento de novas gerações de modelos por players existentes e novos, essas empresas se tornam a camada que integra esses modelos e os entrega ao cliente. Os modelos de base são substituíveis, mas o sistema de trabalho não.

A próxima geração de software empresarial será construída fora da rota de tijolos amarelos.