Toda montadora centenária carrega um dilema estrutural. Como integrar inovação de ponta a sistemas legados que sustentam décadas de produção em escala, sem colocar em risco a operação que já funciona? A resposta mais comum é tratar inovação como iniciativa isolada: um laboratório, um piloto, um projeto de vitrine, mantendo a operação principal intocada. Isso até funciona como demonstração de intenção, mas raramente muda a forma como a empresa efetivamente decide e produz.
Foi esse o pano de fundo do episódio #359 do podcast. O programa trouxe a experiência do Grupo Renault para discutir um tema urgente para a indústria. Inteligência artificial, veículos definidos por software e metaverso industrial deixaram de ser iniciativas isoladas. Eles passaram a fazer parte da operação da companhia. A conversa reuniu a liderança de tecnologia e digital da montadora na América Latina. E o recorte é revelador: uma arquitetura orientada por IA pensada para apoiar decisões em toda a cadeia produtiva, não apenas em um departamento específico.
O problema de tratar IA como iniciativa isolada
Quando uma empresa trata inteligência artificial como projeto pontual, um chatbot aqui, um modelo preditivo ali, o ganho fica limitado. Ele não sai do escopo estreito de cada iniciativa. O sintoma mais comum desse modelo fragmentado é a dificuldade de escalar. Um projeto de IA que funciona bem em uma fábrica, por exemplo, não se replica automaticamente em outra. Isso acontece porque ele foi construído sobre uma base de dados e uma arquitetura específicas daquele contexto, sem padrão comum entre plantas.
Além disso, esse padrão fragmentado tem custo alto em uma indústria como a automotiva. Nela, decisões de produção, cadeia de suprimentos e experiência do produto final estão profundamente interligadas. Se cada área constrói sua própria solução de IA sobre sua própria base de dados, a empresa acumula um mosaico de iniciativas que não conversam entre si. Como resultado, cada nova integração exige esforço de tradução manual entre sistemas. Esses sistemas deveriam, desde o início, ter sido pensados como parte de uma arquitetura única.
De sistemas legados a arquitetura orientada por dados
A alternativa discutida no episódio é tratar a arquitetura tecnológica como camada única que atravessa toda a cadeia produtiva, da fábrica ao ponto de venda. Essa camada é capaz de integrar sistemas legados sem descartá-los de uma vez. Na prática, isso significa que decisões de produção, logística e desenvolvimento de produto passam a se apoiar em uma base de dados comum. Essa base substitui bases paralelas, que exigem reconciliação manual toda vez que uma área precisa de informação de outra.
Vale reforçar que esse tipo de arquitetura não elimina os sistemas legados de uma hora para outra. Isso seria inviável em uma operação do porte de uma montadora global. Em vez disso, ela cria uma camada de integração. Essa camada permite que novos projetos de IA se conectem a dados já existentes, sem recriar a mesma base de informação a cada nova iniciativa. É essa camada de integração, mais do que qualquer modelo específico de IA, que sustenta a escala.
O papel do edge computing na cadeia produtiva
Um elemento central dessa arquitetura é o processamento de dados na borda. Ele acontece próximo de onde a informação é gerada, dentro da própria fábrica ou do próprio veículo. Assim, a empresa reduz a dependência exclusiva de processamento centralizado. Consequentemente, isso reduz a latência em decisões que precisam de resposta quase instantânea, como ajustes em linha de produção ou funcionalidades embarcadas em veículos definidos por software. Também diminui a dependência de conectividade constante com data centers distantes.
Por isso, combinar edge computing com uma arquitetura de dados unificada traz um benefício direto. Decisões locais, em uma linha de produção específica, por exemplo, passam a se beneficiar de padrões e aprendizados construídos em toda a rede da companhia. Dessa forma, cada unidade deixa de precisar reinventar sua própria solução isolada.
Veículos definidos por software: o produto também é a plataforma
Um dos conceitos mais discutidos no episódio foi o de veículo definido por software. Trata-se da ideia de que boa parte do valor e da diferenciação de um carro moderno não está mais apenas na engenharia mecânica. Está também na camada de software que roda sobre ele, atualizável remotamente e capaz de evoluir depois que o veículo já saiu da fábrica. Ou seja, isso muda fundamentalmente o ciclo de vida do produto. Um carro deixa de ser um artefato fechado no momento da venda. Ele passa a ser uma plataforma que continua recebendo funcionalidades novas ao longo do tempo.
Essa mudança tem implicações organizacionais profundas. Times que antes trabalhavam em ciclos de desenvolvimento de anos, alinhados ao lançamento de um novo modelo, agora precisam operar também em ciclos de software muito mais curtos. Isso exige atualizações frequentes e capacidade de resposta rápida a problemas identificados em campo. Por isso, integrar essas duas velocidades, a da engenharia física e a do software, é um dos desafios centrais. Ele vale para qualquer montadora que leva a sério a transformação digital.
Metaverso industrial como ferramenta, não como modismo
O metaverso industrial apareceu na conversa não como conceito especulativo, mas como ferramenta aplicada. Trata-se de simulações digitais de linhas de produção. Elas permitem testar mudanças de processo antes de implementá-las fisicamente, reduzindo risco e custo de erro em ambientes de manufatura de alta complexidade. Afinal, testar em ambiente simulado antes de mexer na fábrica real é o que diferencia uso maduro de tecnologia de experimentação isolada sem retorno claro.
O que muda quando tecnologia vira vantagem competitiva, não suporte
Em empresas industriais tradicionais, a área de tecnologia historicamente ocupou um papel de suporte: manter sistemas funcionando, garantir que a operação não pare. A experiência discutida no episódio aponta para um papel diferente. Nele, a tecnologia se torna fonte direta de vantagem competitiva, na mesma régua de decisão estratégica que engenharia de produto ou eficiência de manufatura.
Por consequência, essa mudança de papel exige que a liderança de tecnologia participe de decisões que antes eram exclusivamente de negócio ou de engenharia. Ao mesmo tempo, a liderança de negócio precisa desenvolver entendimento suficiente sobre arquitetura de dados e IA para avaliar criticamente onde investir. Sem esse entendimento compartilhado, decisões de tecnologia continuam sendo vistas como custo a ser controlado, em vez de investimento a ser priorizado estrategicamente.
Riscos de acelerar demais essa transição
Nem toda empresa tem maturidade organizacional para sustentar uma arquitetura orientada por IA em toda a cadeia produtiva de uma vez. Um risco comum é tentar implementar uma camada de dados unificada cedo demais. Isso acontece quando a empresa não resolve antes problemas básicos de qualidade e consistência de dados nos sistemas de origem. Isso produz uma arquitetura tecnicamente sofisticada, mas alimentada por informação pouco confiável. Na prática, a empresa acaba reproduzindo em escala maior os mesmos problemas que existiam antes, de forma fragmentada.
Outro risco é subestimar o tempo necessário para integrar sistemas legados de forma segura. Afinal, empresas industriais operam sistemas críticos que não podem parar. Por isso, qualquer migração de arquitetura precisa ser feita em etapas, com validação cuidadosa em cada uma. Mesmo que isso signifique um cronograma mais longo do que o inicialmente planejado, vale o custo.
Como medir se a arquitetura está gerando resultado, e não só sofisticação técnica
Um erro recorrente em projetos de arquitetura de dados de grande escala é medir sucesso pela sofisticação da solução implementada. O critério certo, no entanto, é o resultado de negócio que ela gera. Uma plataforma tecnicamente elegante, que integra dezenas de sistemas legados, pode ainda assim falhar em entregar valor. Isso acontece se ninguém consegue apontar, com clareza, qual decisão de produção ou de produto ficou melhor por causa dela.
Por outro lado, os sinais mais confiáveis de que uma arquitetura orientada por IA está funcionando aparecem em outro lugar. Aparecem na velocidade com que uma nova unidade fabril consegue reaproveitar um modelo já validado em outra planta, sem reconstruir a base de dados do zero. Aparecem também na redução do tempo entre identificar um problema em campo, em um veículo já vendido, e disponibilizar uma correção via atualização de software. E aparecem na capacidade de qualquer gestor de operação explicar, em termos simples, que decisão específica um modelo de IA está apoiando, e por quê.
A dimensão humana da transição
Nenhuma arquitetura tecnológica se sustenta sozinha. As pessoas que operam a fábrica e tomam decisões de produção precisam entender, ao menos em linhas gerais, como os dados estão sendo usados. Por isso, empresas que investem pesado em infraestrutura de IA, mas não em capacitação de times operacionais, correm um risco específico. Elas tendem a criar uma camada de especialistas que entende a tecnologia e uma camada operacional que apenas segue recomendações sem questionar. Isso é frágil quando o modelo erra, e erros acontecem.
Por isso, construir esse entendimento distribuído exige tempo e investimento contínuo em capacitação, não apenas um treinamento pontual no lançamento de uma nova ferramenta. Certamente, é esse investimento, mais do que qualquer escolha específica de tecnologia, que faz a diferença no longo prazo. Ele determina se a transformação se sustenta ao longo dos anos ou se esvai assim que a atenção executiva se volta para a próxima prioridade.
O que líderes de outras indústrias podem levar dessa experiência
Para quem lidera tecnologia ou operações em empresas industriais de outros setores, a experiência do Grupo Renault sugere um roteiro prático. Primeiro, mapear onde a base de dados hoje está fragmentada entre áreas, antes de investir em modelos de IA mais sofisticados. Em seguida, avaliar onde processamento na borda pode reduzir latência em decisões críticas de operação. Por fim, tratar atualização contínua de produto, quando aplicável ao setor, como mudança de modelo de negócio, não apenas como funcionalidade técnica adicional.
Nenhum desses passos exige abandonar sistemas legados de uma vez. Exige, sim, tratar arquitetura de dados como decisão estratégica de longo prazo. Do contrário, ela continua sendo vista como escolha técnica que pode ser adiada. Aí, a pressão competitiva torna a mudança inevitável, e mais cara do que teria sido se planejada com antecedência.
Quer receber uma curadoria mensal com os melhores insights ágeis? Assine a Newsletter Agilistas, onde você tem acesso a tendências e reflexões do mundo ágil. Inscreva-se grátis no formulário no fim dessa página com seu melhor e-mail.
