Como o iFood chegou a 30% de EBITDA com IA?

O iFood chegou a 30% do EBITDA mensal gerado por IA porque tomou uma decisão de governança de dados em 2018, quatro anos antes do ChatGPT existir, e acumulou um data lake de 16 petabytes de dados limpos de delivery. Esse ativo é o que tornou economicamente viável treinar um modelo proprietário (o LCM) que opera 40 aplicações internas a cerca de 10% do custo por interação dos modelos de mercado, segundo press release oficial da empresa de março de 2026. A IA não foi a causa do resultado, foi a consequência de um ativo de dados que levou quatro anos para ficar pronto.

Quais são os números reais do caso iFood de IA?

Segundo a iFood Institucional, em press release oficial de março de 2026, 30% do EBITDA mensal da empresa é gerado por 190 modelos de IA que rodam 25 bilhões de predições por mês. O modelo proprietário deles, o LCM (Large Commerce Model), opera 40 aplicações internas com custo por interação de cerca de 10% do que custariam os modelos de mercado nas mesmas tarefas, uma redução de 90% sobre a linha de base de 2024, quando a empresa ainda dependia de OpenAI, Azure e Bedrock nessas operações.

A tabela abaixo consolida o antes e o depois, com as fontes públicas identificadas:

Os dados de tempo de resolução do Rosie e de ROI foram citados pela Itshow e pela Mobiletime a partir de executivos nomeados da empresa, com o intervalo de outubro de 2025 a maio de 2026 para a queda de 38 para 10 minutos. Os demais vêm da própria iFood Institucional.

Esse conjunto de números circula no LinkedIn com a narrativa de “empresa que apostou em IA e ganhou”. A leitura entrega admiração e não entrega método. O resultado de 30% de EBITDA não é produto da adoção de IA. É produto de uma decisão tomada em 2018, quando o ChatGPT não existia, o mercado de LLM não tinha nome e o iFood era conhecido por logística de entrega, não por tecnologia proprietária.

Por que a IA não é a causa do resultado do iFood?

A cadeia causal do caso tem quatro camadas, e vale desmontar de trás para frente, do resultado até a decisão-raiz.

Camada 4, a mais próxima do resultado. O LCM existe e opera 40 aplicações com custo dez vezes menor porque foi treinado com dados exclusivos do ecossistema de delivery do iFood, dados que nenhum modelo generalista de mercado tem. A consequência direta é o ROI de mais de 250 vezes em cenários selecionados e o agente Rosie caindo de 38 para 10 minutos de resolução média, com 70% dos chamados automatizados. O LCM só pôde ser construído porque existia um ativo de dados esperando por ele.

Camada 3, o ativo que viabilizou o LCM. O data lake de 16 petabytes, com dados estruturados e limpos acumulados desde 2018, é o que torna o treino do LCM economicamente viável. Cliques, buscas, cancelamentos, avaliações, histórico de pedidos de bilhões de interações reais de delivery, num contexto de domínio que nenhum modelo generalista carrega. Sem esse ativo, treinar um modelo especializado em comércio e delivery seria inviável técnica e economicamente. Qualquer concorrente que tente replicar o modelo proprietário hoje, sem esse histórico, volta para os modelos genéricos ao custo dez vezes maior, exatamente o problema que o iFood resolveu para si.

Camada 2, a decisão que construiu o ativo. O data lake existia porque, em 2018, a empresa fez uma decisão deliberada de governança de dados antes de qualquer agenda de IA generativa. Contratou time próprio de dados, adquiriu duas empresas de IA (Hekima e Maplink) e construiu cultura de decisão baseada em dados na operação diária. A plataforma de IA generativa interna existe há três anos, mas a escala só aconteceu quando os modelos deixaram de viver em 200 a 300 serviços isolados e passaram para uma infraestrutura centralizada, a Genplat, acessível a qualquer time interno. A Genplat é o segundo tijolo. O primeiro é o dado. Sem o dado, a Genplat é uma camada vazia.

Camada 1, o que tornou a decisão de 2018 irreversível. A liderança aceitou anos de investimento sem retorno imediato visível, e fez isso de um jeito mais específico do que “visão de longo prazo”: escreveu a expectativa de uso de IA na avaliação de desempenho dos 8,5 mil FoodLovers, em vez de deixar no slide da liderança. Segundo a iFood Institucional, mais de 90% dos FoodLovers usam a Genplat diariamente. Quando a métrica entra no critério de desempenho, ela para de ser aspiracional e vira operação.

O que é um ativo de dados, e por que ele é diferente de “ter dados”?

Ativo de dados é o registro de um processo que foi capturado com estrutura estável, no mesmo lugar, ao longo de tempo suficiente para responder perguntas que não foram feitas quando o registro começou. Ter dados é diferente: quase toda empresa tem dados, espalhados por e-mail, planilha, WhatsApp e cabeça de gente. Ativo é o que se consegue consultar, cruzar e treinar.

A distinção decide o resultado. Dado disperso serve para relatório retroativo. Ativo de dados serve para automação e para modelo. É por isso que o iFood conseguiu treinar algo proprietário e a maioria das empresas não consegue: não é uma diferença de talento em IA, é uma diferença de arquivo.

Na prática, um ativo de dados tem três características que dado solto não tem. Primeiro, destino único: o mesmo tipo de registro sempre vai para o mesmo lugar. Segundo, estrutura estável: os campos não mudam de nome e de significado a cada trimestre. Terceiro, continuidade temporal: existe série histórica, e não fotografias avulsas. O iFood levou de 2018 a 2022 para consolidar isso em escala. A parte boa é que as três características não dependem de porte. Dependem de decisão de quem manda no processo.

Qual é a peça do caso iFood que ninguém copia?

O data lake de 16 petabytes construído entre 2018 e 2022, antes da era LLM, com registros de cliques, buscas, cancelamentos e avaliações de bilhões de interações reais, é a peça que não se copia.

Não é a Genplat. Não são os 190 modelos. Não são os 14 mil agentes de IA internos nem os 10 mil microsserviços com IA integrada, todos citados pela iFood Institucional. Esses são consequências. O data lake é a causa.

O consenso do mercado trata IA como ferramenta de adoção: escolhe a plataforma, configura o agente, treina o time. O caso do iFood inverte a ordem, porque a IA aqui é consequência de uma infraestrutura de dados que levou quatro anos para ficar pronta. A maioria das empresas que tenta copiar quebra exatamente porque pula essa etapa: implanta o agente antes de organizar o dado, e a IA faz o que sempre faz quando o insumo é ruim, reproduz a desordem do processo com mais velocidade.

A barreira de entrada que o iFood construiu é temporal, não tecnológica. Ninguém compra quatro anos de histórico de domínio. Dá para começar hoje, e o relógio passa a contar a partir de hoje.

O que a Frons mediu ao aplicar essa lógica no próprio processo?

Na Frons, entre abril e julho de 2026, nós rodamos exatamente o diagnóstico que estamos recomendando aqui, no nosso processo de atendimento a alunos e candidatos de pós-graduação e MBA. A pergunta que guiou foi simples: quanto do nosso próprio registro operacional é ativo de dados e quanto é dado solto?

O resultado foi desconfortável. Mapeamos 11 processos que passam por três ou mais pessoas e encontramos 7 deles com o mesmo tipo de informação vivendo em mais de um lugar ao mesmo tempo, sem consolidação. Em 4 desses 7, o histórico dos últimos 30 dias não podia ser recuperado por alguém que não fosse o dono direto da tarefa. Ou seja: em pouco mais de um terço dos processos analisados, o conhecimento operacional estava na cabeça e na caixa de entrada de uma pessoa específica.

Também cronometramos, em julho de 2026, o tempo que um gestor da nossa operação levava para recuperar o histórico completo de interação de um candidato quando o registro estava fragmentado entre e-mail, WhatsApp e planilha. A média foi de 9 minutos por caso, contra menos de 2 minutos nos processos que já tinham destino único definido. Não é uma medição de laboratório, é o tempo real de gente ocupada procurando informação que a própria empresa já tinha.

Esses números são pequenos ao lado de 16 petabytes, e é justamente esse o ponto. A diferença entre a Frons e o iFood na escala é gigantesca. A diferença na natureza do problema é zero. Quem tem dado fragmentado não tem ativo, e quem não tem ativo vai contratar IA genérica para reproduzir a própria bagunça a preço de mercado.

O que deu errado no caminho do iFood, com números?

A fricção documentada do caso é o custo de escalar IA com modelos de mercado. Nas 40 aplicações onde o LCM foi implantado, o volume chegou a 150 bilhões de tokens mensais, segundo a iFood Institucional. Nessa escala, operar com modelos externos como OpenAI, Azure e Bedrock tornava o custo operacional inviável, porque o ganho de eficiência seria consumido pela conta de API.

A empresa precisou desenvolver modelo proprietário para viabilizar a própria operação, e isso exigiu investimento antecipado em treino e infraestrutura que só se pagou porque os dados já estavam organizados. Se o data lake não existisse, o LCM não seria desenvolvível com prazo e orçamento realistas, e o iFood estaria preso no dilema que a maioria enfrenta: IA que funciona em piloto e fica cara demais em produção.

Há um segundo ponto desfavorável que precisa ficar na mesa, e a newsletter que originou este artigo já registrou. O iFood processa entre 120 e 160 milhões de pedidos por mês e opera com 8,5 mil funcionários. Escalar 190 modelos nessa operação exigiu construir plataforma centralizada e modelo proprietário, investimento que empresa de menor porte não replica nos mesmos moldes. O método é transferível. O cheque de infraestrutura proprietária não é. Quem lê esse caso e conclui “preciso do meu LCM” entendeu o contrário do que o caso ensina.

Na nossa aplicação interna, o erro que cometemos foi de sequência. Entre abril e maio de 2026, testamos automação em 2 processos antes de consolidar o registro, e nos dois casos tivemos que refazer: a automação passou a produzir resposta a partir de histórico incompleto, o que gerou retrabalho de conferência manual e anulou o ganho de tempo. Voltamos, definimos destino único, e só então automatizamos. A lição custou cerca de seis semanas.

Como aplicar a lógica do iFood num processo de qualquer área?

A decisão transferível do iFood não é adotar IA. É a sequência: primeiro organiza o dado bruto do processo, depois avalia onde a IA resolve volume repetitivo com custo alto. Uma empresa de 20 pessoas inicia esse ciclo esta semana, antes de escolher qualquer ferramenta. Os cinco passos abaixo funcionam igual em RH, em fábrica e em loja.

Passo 1: escolhe um processo seu que mais acumula registro não estruturado e nomeia ele. Em qualquer área existe um processo que gera volume de texto sem destino: e-mails de suporte, notas de atendimento, histórico de ocorrências, ordens de serviço, formulários de entrada, registros de recebimento de mercadoria. Escolhe um, só um, e escreve o nome dele num documento. O artefato é uma linha de texto com o nome do processo e o dono. (O iFood começou por dados de clique e busca. RH pode começar por entrevistas de desligamento, fábrica por registros de parada de linha, loja por reclamação de cliente no balcão.)

Passo 2: lista onde esse dado está fragmentado hoje. Dado fragmentado é o equivalente prático a não ter data lake. Verifica: está no e-mail de três pessoas diferentes? Numa planilha que cada um copia para si? No WhatsApp de quem atende? Num caderno da portaria? Você lista os pontos onde o mesmo tipo de informação vive em mais de um lugar sem consolidação. O artefato é uma tabela de três colunas: fonte atual, responsável por ela, o que só existe ali.

Passo 3: define um destino único para esse registro a partir desta semana. Não é projeto de TI, é decisão operacional de quem manda no processo. Pode ser um CRM que já existe, uma planilha compartilhada com campos fixos, uma pasta de drive com nomenclatura padronizada, um formulário curto. O critério de aceite é objetivo: qualquer pessoa do time acha o histórico dos últimos 30 dias em menos de dois minutos. Você testa isso pedindo para alguém que não é o dono do processo procurar, e cronometra. (O iFood levou quatro anos para chegar a 16 petabytes. Você começa com 30 dias de histórico limpo.)

Passo 4: registra a linha de base de volume e tempo desse processo antes de automatizar nada. Sem linha de base não existe prova de ganho, existe opinião. Anota três coisas hoje: quantas interações por semana esse processo tem, quanto tempo médio uma pessoa gasta em cada uma, e quem gasta esse tempo. O artefato é um bloco de três linhas com data. Foi assim que descobrimos, na Frons, os 9 minutos por consulta de histórico fragmentado contra menos de 2 minutos no processo consolidado, e esse contraste é o que sustenta qualquer decisão de investimento depois.

Passo 5: agenda no calendário, hoje, uma hora daqui a 30 dias para revisar o dado acumulado. Organizar dado sem data de revisão é colecionar, não construir ativo. Na hora marcada, você abre o que foi acumulado e faz uma pergunta só: onde tem volume repetitivo aqui que uma ferramenta poderia assumir sem inventar informação? Só depois dessa revisão você escolhe ferramenta. A sequência importa mais que a ferramenta: dado limpo primeiro, automação depois.

Passo 6, opcional para quem já tem os cinco anteriores rodando: coloca a métrica no critério de desempenho de alguém. O iFood escreveu a expectativa de uso de IA na avaliação de desempenho dos 8,5 mil FoodLovers, e chegou a mais de 90% de uso diário da plataforma interna. Enquanto a expectativa vive só na apresentação da liderança, ela é aspiração. Quando entra no que é avaliado na conversa de desempenho, vira operação. Na próxima reunião de avaliação da sua área, você inclui uma linha sobre a alimentação correta do registro que definiu no Passo 3.

Qual é a pergunta certa a fazer sobre IA em 2026?

O iFood é citado como caso de IA. Na minha visão, é um caso de disciplina de dados com seis anos de vantagem sobre quem só agora está perguntando qual modelo contratar.

A pergunta “qual IA usar” tem prazo de validade de poucos meses, porque o mercado troca de modelo líder a cada temporada. A pergunta “qual dado eu tenho hoje que, se organizado, vira ativo daqui a dois anos” tem prazo de validade de anos, porque a resposta constrói algo que ninguém compra pronto. Quem responde essa segunda pergunta agora e age sobre ela está fazendo em 2026 o que o iFood fez em 2018, sem precisar do porte do iFood para começar.

Vale registrar o contraste com honestidade. O iFood tinha, em 2018, condições que a maioria não tem: caixa para adquirir duas empresas de IA, capacidade de montar time próprio de dados e liderança disposta a aceitar anos de investimento sem retorno visível. Nada disso é replicável por uma operação de 20 ou 200 pessoas. O que é replicável é a ordem das decisões, e a ordem é gratuita. Definir destino único para um tipo de registro não custa nada além de disciplina e de alguém disposto a cobrar.

O mercado não te deve nada, e menos ainda te deve um atalho de quatro anos. A constância aqui é do tipo mais chato que existe: um processo escolhido, um destino único, revisão em 30 dias, repetido por trimestres. É isso que separa a empresa que vai contratar IA genérica em 2028 ao custo de mercado da empresa que vai ter insumo próprio para automatizar o que ninguém mais consegue automatizar do mesmo jeito.

Perguntas frequentes

Quanto do EBITDA do iFood vem de inteligência artificial?

Segundo press release oficial da iFood Institucional de março de 2026, 30% do EBITDA mensal da empresa é gerado por 190 modelos de IA que rodam 25 bilhões de predições por mês. Esse resultado está ancorado num data lake de 16 petabytes construído a partir de 2018 e num modelo proprietário, o LCM, que opera 40 aplicações internas.

O que é o LCM do iFood e quanto ele economiza?

O LCM (Large Commerce Model) é o modelo de IA proprietário do iFood, treinado com dados exclusivos do ecossistema de delivery da empresa. Ele opera 40 aplicações internas com custo por interação de cerca de 10% do que custariam os modelos de mercado nas mesmas tarefas, uma redução de 90% sobre a linha de base de 2024, quando o iFood dependia de OpenAI, Azure e Bedrock nessas operações.

Por que a maioria das empresas falha ao copiar casos de IA como o do iFood?

Porque inverte a sequência: implanta o agente ou a ferramenta antes de organizar o dado que alimenta a automação. Quando o insumo está fragmentado entre e-mail, planilha e WhatsApp, a IA reproduz a desordem do processo com mais velocidade em vez de resolver. No iFood, o data lake de 16 petabytes levou de 2018 a 2022 para ficar pronto e é a condição de existência do resultado, não um detalhe de infraestrutura.

Uma empresa pequena consegue aplicar o método do iFood?

Sim, desde que aplique a sequência e não o investimento. O que é transferível é a ordem das decisões: escolher um processo que gera registro não estruturado, listar onde esse dado está fragmentado, definir um destino único a partir desta semana, registrar a linha de base de volume e tempo, e revisar em 30 dias antes de escolher ferramenta. Construir plataforma centralizada e modelo proprietário, como o iFood fez para 120 a 160 milhões de pedidos mensais, não é replicável por empresa de menor porte.

Como saber se o dado da minha empresa já é um ativo?

Ativo de dados é o registro de um processo capturado com destino único, estrutura estável e continuidade temporal, ao ponto de responder perguntas que não existiam quando a captura começou. Um teste rápido: peça a alguém que não é o dono do processo para achar o histórico dos últimos 30 dias e cronometre. Na Frons, em julho de 2026, medimos 9 minutos por consulta em processos com dado fragmentado contra menos de 2 minutos nos processos com destino único definido.

Como o iFood garantiu que o time realmente usasse a IA?

A empresa escreveu a expectativa de uso de IA na avaliação de desempenho dos 8,5 mil funcionários, em vez de deixar a diretriz apenas na comunicação da liderança. Segundo a iFood Institucional, mais de 90% dos funcionários usam a plataforma interna Genplat diariamente. Quando a métrica entra no critério de desempenho, ela deixa de ser aspiração e passa a ser operação.