Existe uma versão da história da IA que a indústria de tecnologia conta muito bem. Modelo novo. Benchmark novo. Uma capacidade que não existia seis meses atrás. O ritmo de mudança é real. O progresso está documentado.
A versão menos contada acontece no mês 8 de uma implementação de IA. É quando uma empresa do middle market descobre que os dados de que precisa estão espalhados por quatro sistemas. Dois deles não têm API. E um ainda roda em um servidor dentro de um armário no escritório de Chicago.
Já resolvemos esse problema em empresas de pagamentos, consultorias financeiras, operadoras de rede elétrica, negócios de serviços em campo, indústrias e plataformas de logística. Foram doze anos e projetos em quatro continentes. A tecnologia muda. O problema de infraestrutura por baixo dela não.
A seguir está o que aprendemos na prática. São os fatores que separam uma implementação de IA que chega à produção daquelas que geram demos impressionantes e pouco mais do que isso. Cada lição aqui nasceu de uma sala como aquela em Chicago.
Onde vimos isso na prática
Nosso trabalho abrange pagamentos, serviços financeiros, energia, operações industriais, IoT e logística. Os setores são diferentes. Os problemas de dados são notavelmente parecidos. Abaixo está uma amostra representativa dos projetos que sustentam as lições deste artigo.
| Cliente | O que construímos | Por que foi mais difícil do que parecia |
| MoneyGram Pagamentos / Fintech | Infraestrutura de pagamentos internacionais e experiência digital do cliente em um ambiente regulado e multimoeda. | As exigências de compliance sobre dados de pagamento mudam conforme a jurisdição. A camada de integração precisou ser construída para mais de 200 ambientes regulatórios ao mesmo tempo. |
| AES Corporation Energia / Utilities | Plataforma de inteligência de rede elétrica para uma empresa de energia da Fortune 500. Infraestrutura de usina virtual e sistemas de dados operacionais em tempo real. | Requisitos de confiabilidade do setor elétrico não deixam margem para falhas no pipeline de dados. A infraestrutura precisou nascer com 99,99% de uptime, e não ser adaptada depois. |
| Knapsack IA / Fintech | Plataforma de IA criada especificamente para ambientes de compliance financeiro rigoroso. Auditabilidade, explicabilidade e rastreabilidade regulatória embutidas na arquitetura. | Os frameworks padrão de implantação de IA pressupõem flexibilidade. O compliance financeiro exige determinismo. Cada saída do modelo precisava de uma justificativa auditável. |
| Camio IA / Industrial | Sistema de videomonitoramento e detecção de eventos com IA, processando mais de 4 milhões de eventos por dia em ambientes comerciais e industriais. | A inferência de IA em tempo real nessa escala exige decisões de arquitetura de edge já na primeira semana. Adaptar edge computing depois equivale a reconstruir o sistema. |
| Birdnest Operações em campo / Industrial | Plataforma de operações em campo para empresas de água e saneamento. Roteirização de técnicos, gestão de ordens de serviço e relatórios de compliance. | As operações em campo do saneamento têm exigências de relatório regulatório que afetam cada fluxo de trabalho. A camada de compliance precisou ser desenhada dentro do modelo de dados, e não adicionada depois. |
| Bemis Manufatura | Entrega de software ponta a ponta para um cliente de manufatura do middle market. Engajamento completo, da descoberta até a implantação em produção. | Os dados de manufatura vivem na interseção entre sistemas de OT (tecnologia operacional) e de TI que nunca foram feitos para conversar. O desafio de integração era o projeto em si, não um obstáculo a ele. |
Esses não são projetos movidos a hype de IA. São sistemas operacionais que rodam em produção, processam transações reais, atendem clientes reais e trazem consequências reais quando falham. É desse contexto que vêm as lições.
Seis lições que a maioria das empresas ainda erra
1 – A falha quase nunca está no modelo. Está nos dados por baixo dele
Em 77% das implantações corporativas de IA estudadas pelo Digital Economy Lab de Stanford, os maiores desafios foram qualidade de dados, redesenho de processos e gestão de mudança. Não a escolha do modelo. Vemos isso se repetir o tempo todo.
O modelo escolhido no início do projeto raramente determina se ele vai dar certo. O estado dos dados que alimentam esse modelo quase sempre determina.
Uma empresa com dados confiáveis, centralizados e consultáveis, mesmo com um modelo mediano, supera uma empresa com dados fragmentados em silos e acesso ao melhor modelo do mundo. Sempre. Por isso, o diagnóstico precisa começar pelos dados, e não pela avaliação de modelos.
2 – Compliance é uma decisão de arquitetura tomada no começo
Essa é a lição que os setores regulados ensinam da forma mais dura. Serviços financeiros, energia, saúde, jurídico: em todos eles existem exigências de compliance que afetam o modelo de dados, a camada de API, a trilha de auditoria e a interface do usuário.
Quando o time trata compliance como etapa final de revisão, e não como restrição de projeto, o resultado é um sistema que precisa ser refeito em boa parte. A revisão de conformidade acaba revelando o que já deveria estar claro desde o primeiro dia. Por isso, incorporamos compliance à arquitetura já no primeiro sprint. Custa mais no início e muito menos no total.
3 – Sistemas legados não são o problema. Sistemas legados não mapeados são
Toda empresa do middle market com quem trabalhamos nos últimos doze anos tem sistemas legados. As que dão certo com IA não são as que substituíram tudo antes de começar. Quase nenhuma empresa consegue bancar isso. São as que mapearam o próprio cenário de legado com honestidade antes de construir qualquer coisa nova.
Quais sistemas guardam quais dados. Quais têm API e quais não têm. Quais podem ser integrados e quais precisam ser substituídos. Quais dados já são confiáveis e quais exigem transformação antes do uso.
Esse mapa não existe na maioria das empresas do middle market quando chegamos. Construí-lo é a primeira entrega real de qualquer projeto sério de IA.
4 – Fluxos de trabalho precisam ser mapeados antes de serem automatizados
A causa mais comum de fracasso em projetos de automação com IA é automatizar o que as pessoas dizem que fazem, em vez do que elas realmente fazem. São coisas diferentes. O fluxo de trabalho declarado é aquele que está na documentação de processos.
O fluxo de trabalho real envolve a planilha que alguém montou há três anos, que todo mundo usa e ninguém comenta. Envolve também a corrente de e-mails que substitui um sistema nunca construído. E os cinco passos manuais entre o lançamento no ERP e o aviso ao cliente.
A automação com IA construída sobre o fluxo declarado quebra assim que encontra a realidade. Por isso, mapeamos o fluxo real antes de escrever uma linha de lógica de automação. Isso inclui as exceções, os contornos e as decisões que dependem de julgamento humano.
5 – As decisões de infraestrutura da primeira semana definem o teto de tudo o que vem depois
Na implementação de IA, as decisões iniciais de arquitetura se acumulam nos dois sentidos. Uma boa arquitetura de dados torna cada nova funcionalidade mais fácil de construir.
Uma arquitetura mal escolhida cria um atrito que se acumula a cada sprint. Os times que pulam a fase de design de infraestrutura para chegar logo à parte interessante da IA passam do sexto ao décimo oitavo mês pagando uma dívida técnica totalmente previsível.
Aprendemos a ser lentos na arquitetura e rápidos em todo o resto. O tempo investido na primeira semana volta multiplicado até o sexto mês.
6 – O intervalo entre a demo e a produção é onde a maioria das iniciativas de IA morre
Uma demo é uma prova de conceito feita com dados de amostra limpos, ambiente controlado e nenhum caso extremo. Produção é um sistema que roda com dados reais, usuários reais, volume real e falhas que ninguém previu.
A distância entre essas duas realidades é onde a maioria das iniciativas de IA fracassa. Não porque o conceito estava errado, mas porque o caminho do conceito até a produção nunca foi projetado. Vimos isso em pagamentos, energia e manufatura.
Construir para a produção desde o primeiro sprint, em vez de adaptar uma demo depois, é a disciplina que separa as implementações que realmente entram no ar daquelas que ficam pelo caminho.
O que isso significa para a implementação de IA no middle market em 2026
O mercado de IA em 2026 produz um volume enorme de conselhos que soam seguros sobre como implementar IA. A maior parte aponta a direção certa, mas é incompleta na prática. Diz o que fazer. Raramente diz o que é verdade sobre a sua infraestrutura, os seus dados e a complexidade dos seus fluxos de trabalho antes de você tentar fazer.
“As empresas que capturam valor com IA não são as que têm o melhor modelo. São as que fizeram o trabalho de base antes de colocar a IA em produção.”
As seis lições acima não são exclusivas dos setores em que atuamos. Elas valem para qualquer empresa do middle market, em qualquer setor regulado ou intensivo em dados, que tente implementar IA de forma relevante. Os setores mudam. O padrão por baixo deles, não.
O que muda de um setor para outro é o ambiente específico de compliance, o cenário de sistemas legados e a complexidade dos fluxos de trabalho. O que não muda é a sequência: diagnostique antes de construir, mapeie antes de automatizar, projete a arquitetura antes de implantar.
| O que se transfere entre setores |
| Fintech → Manufatura — O desenho de arquitetura sensível a compliance, a disciplina no modelo de dados e as exigências de trilha de auditoria são estruturalmente idênticos. A regulação é outra; o padrão de projeto é o mesmo. |
| Energia → Operações industriais — Requisitos de infraestrutura de alta confiabilidade, arquitetura de edge computing e desafios de integração com tecnologia operacional se traduzem diretamente entre operações de rede elétrica e sistemas de manufatura industrial. |
| Pagamentos → Logística — A reconciliação de dados entre múltiplas partes, os requisitos de processamento em tempo real e a lógica de tratamento de exceções criada para redes de pagamento se aplicam diretamente à gestão de eventos da cadeia de suprimentos. |
| Serviços em campo → Manufatura — Gestão de ordens de serviço, roteirização de técnicos, relatórios de compliance e integração de dados de sensores IoT são paralelos estruturais, seja o campo o saneamento básico ou a manutenção de equipamentos industriais. |
Uma nota honesta sobre onde estamos
Não afirmamos ter tudo isso perfeitamente resolvido. O cenário de IA avança mais rápido do que a capacidade interna de qualquer empresa consegue acompanhar, inclusive a nossa. O que podemos afirmar são doze anos de entrega em ambientes de risco real, com dados genuinamente bagunçados, nos quais entregar algo que não funcionasse nunca foi uma opção aceitável.
Metade do nosso time de engenharia tem experiência prática em integração de LLM. Temos arquitetos de IA em nível staff. Temos sistemas em produção em serviços financeiros, energia e operações em campo. Mantemos parcerias de plataforma de dados com Snowflake, Databricks e DBT Labs. Sabemos como precisa ser a infraestrutura por baixo da Inteligência Artificial porque a construímos repetidamente em ambientes que não podiam errar.
A lição mais fundamental é esta: as empresas que têm sucesso com IA não são as que se moveram primeiro. São as que diagnosticaram com honestidade antes de construir, mapearam com cuidado antes de automatizar e escolheram parceiros de implementação que já estiveram na sala quando o problema de infraestrutura era real. Não apenas quando a demo parecia impecável.
A melhor estratégia de IA começa com uma resposta honesta a esta pergunta: o que é realmente verdade sobre nossos dados, nossos sistemas e nossos fluxos de trabalho neste momento?
Se você ainda não tem essa resposta, a estratégia de IA pode esperar. O diagnóstico, não.
