Além do discurso: por que a IA aplicada exige mais colaboração do que você imagina

Há alguns anos, participei de uma reunião onde um cientista de dados apresentava um modelo de recomendação com acurácia de 95% em testes offline. O time de negócios, animado, queria colocar aquilo no ar em duas semanas. O time de engenharia, porém, se deparou com um sistema legado escrito em COBOL, sem APIs modernas e com um pipeline de dados que exigia aprovação manual de três áreas diferentes. O projeto morreu na fase de proof of concept, não por falta de capacidade técnica, mas por ausência de um mecanismo real de colaboração entre os envolvidos. Esse episódio, infelizmente comum, ecoa o que vejo repetidamente em eventos como a Rio Innovation Week: a distância entre o discurso da multidisciplinaridade e a prática nos projetos de IA aplicada.

A edição deste ano do evento reforça a ideia de que os grandes desafios contemporâneos exigem colaboração entre diferentes áreas do conhecimento. Inteligência artificial, mudanças climáticas, novas lideranças, ciência e criatividade deixaram de ser assuntos de nicho. Mas, como engenheiro que já atuou em dezenas de iniciativas de automação e transformação digital, afirmo com convicção: a retórica da colaboração é o ponto de partida, não a linha de chegada. O verdadeiro desafio está em traduzir esse conceito em processos, ferramentas e cultura organizacional — e é aí que a maioria das empresas tropeça.

O abismo entre o POC e a produção

Dados recentes indicam que entre 70% e 85% dos projetos de machine learning nunca chegam à produção. A causa raiz raramente é o algoritmo — é a falta de integração organizacional. O cientista de dados treina o modelo em um Jupyter notebook, usando dados limpos e estáticos, enquanto o engenheiro de software precisa lidar com dados sujos, latência de rede, restrições de segurança e prazos de entrega. Sem um vocabulário comum e um processo de handoff bem definido, o modelo vira um artefato de museu. Na prática, isso exige que o engenheiro de software entenda métricas de drift, o cientista de dados conheça padrões de deploy (como blue-green ou canary), e ambos compartilhem a responsabilidade pelo monitoramento contínuo.

Em uma implementação real que acompanhei, a equipe demorou três meses para alinhar os requisitos de infraestrutura. O time de dados queria GPUs para treinar modelos com deep learning; o time de infraestrutura operava com instâncias spot na AWS e tinha limites de custo mensais. A solução veio de um engenheiro de software que propôs treinar modelos menores, com técnicas de compressão (quantização e poda), e usar inferência em CPU otimizada. Não foi uma decisão técnica pura, foi uma negociação entre performance, custo e prazo. Esse tipo de trade-off é invisível em palestras, mas define o sucesso ou fracasso de um projeto de IA.

O engenheiro de IA como arquiteto de integração

Na minha trajetória com automação de processos, percebi que o profissional mais valorizado não é aquele que domina a última arquitetura de transformers, mas quem consegue conectar mundos. Um engenheiro de software que atua com IA precisa ser um arquiteto de integração: precisa entender de orquestração de containers (Kubernetes), pipelines de dados (Apache Kafka, Airflow), governança (linhagem de dados, versionamento de modelos) e, principalmente, comunicação com stakeholders de negócio. Sem essa visão sistêmica, o modelo vira um peso morto.

Em um projeto de automação de atendimento ao cliente, o time de negócios queria um chatbot que resolvesse 80% dos chamados. O time de NLU treinou um modelo com alta precisão, mas o sistema legado de CRM só aceitava integração via arquivos CSV enviados por FTP. O engenheiro de software precisou construir um adaptador que convertesse respostas em lotes e agendasse envios noturnos — uma solução nada elegante, mas funcional. A lição é clara: a IA aplicada não existe no vácuo; ela precisa se encaixar em arquiteturas existentes, com todas as suas limitações. Ignorar isso é condenar o projeto ao fracasso.

Dados: o calcanhar de Aquiles que ninguém quer assumir

Outro ponto crítico que a conversa sobre colaboração frequentemente ignora é a responsabilidade pelos dados. Em muitas empresas, os dados estão espalhados em silos: um time tem os dados de vendas, outro tem os dados de comportamento do usuário, e um terceiro gerencia os dados de logística. Para treinar um modelo preditivo de demanda, por exemplo, é necessário juntar essas fontes, o que exige não apenas engenharia de dados, mas também alinhamento jurídico (LGPD), compliance interno e um vocabulário comum de métricas. Sem uma governança de dados madura, o projeto trava.

Em um caso recente, uma empresa gastou seis meses tentando unificar dados de clientes de três sistemas diferentes. A cada reunião, um time dizia que o campo "cliente" significava CPF, outro dizia que era o ID do sistema, e o terceiro usava e-mail. O cientista de dados não tinha autonomia para resolver isso; era necessário um grupo de trabalho multidisciplinar com representantes de TI, negócios e jurídico. A IA aplicada depende de dados de qualidade, e a qualidade de dados é um problema organizacional, não técnico. Engenheiros de software que entendem disso e sabem propor estratégias de data contracts e data mesh se tornam indispensáveis.

Implicações para carreira e operação

Para o profissional de engenharia de software, o cenário acima significa que a carreira em IA não se limitará a treinar modelos. Haverá demanda crescente por engenheiros que saibam projetar arquiteturas de ML em produção (MLOps), implementar pipelines de CI/CD para machine learning, lidar com monitoramento de drift e garantir a reprodutibilidade dos experimentos. Além disso, habilidades de comunicação e entendimento de negócio serão diferenciais competitivos. O engenheiro que consegue traduzir uma métrica de negócio (como "reduzir churn") em um problema de classificação, e depois comunicar os resultados para executivos, terá um valor imenso.

Na operação, a colaboração multidisciplinar exige novas ferramentas e processos. Times de engenharia precisam adotar práticas de feature stores, model registries e experiment tracking (como MLflow ou DVC). Reuniões de alinhamento entre squads de dados e de produto devem ser frequentes e com métricas compartilhadas. Uma dica prática que aprendi: crie um "contrato de serviço" entre o time de dados e o time de engenharia, definindo SLAs para latência de inferência, disponibilidade do endpoint e frequência de retreinamento. Isso evita surpresas e coloca ambos os lados na mesma página.

Riscos e limitações da abordagem colaborativa

É tentador acreditar que a colaboração resolve todos os problemas, mas ela também traz riscos. Reuniões intermináveis, conflitos de prioridade e a dificuldade de alinhar expectativas entre áreas com culturas diferentes (agilidade vs. robustez, inovação vs. conformidade) podem gerar paralisia. Sem uma liderança técnica que saiba decidir trade-offs, o time pode gastar mais tempo discutindo do que implementando. Em projetos de IA, o "design by committee" é um perigo real — modelos precisam de decisões técnicas rápidas, baseadas em dados, não em consenso forçado.

Outro risco é a diluição de responsabilidades. Quando todo mundo é responsável pelo modelo, ninguém é. É essencial definir papéis claros: quem é o dono do pipeline de dados, quem é o dono do modelo em produção, quem monitora o drift. O engenheiro de software deve ser o guardião da arquitetura e da estabilidade, enquanto o cientista de dados cuida da performance do modelo. A colaboração não significa ausência de fronteiras; significa fronteiras bem desenhadas com canais de comunicação abertos.

Perspectiva pessoal e recomendação

A Rio Innovation Week acerta ao colocar a colaboração multidisciplinar como tema central, mas precisamos ir além do discurso. A verdadeira transformação acontece quando as empresas investem em estruturas organizacionais que permitam essa integração — squads multidisciplinares com métricas compartilhadas, job rotation entre áreas de dados e engenharia, e incentivos que recompensem o sucesso do produto, não apenas a entrega técnica. Para o engenheiro de software, é um convite para expandir horizontes: aprender sobre machine learning, governança de dados e até mesmo design thinking. O profissional do futuro não será aquele que sabe mais de uma tecnologia, mas aquele que consegue conectar pessoas, processos e sistemas.

Em suma, a IA aplicada exige mais do que algoritmos avançados: exige uma engenharia de integração que nasce da colaboração genuína entre áreas. Os eventos e palestras são importantes para inspirar, mas a prática — com seus trade-offs, frustrações e vitórias — é o que realmente forma profissionais capazes de transformar discurso em valor. Que essa edição do Rio Innovation Week sirva não apenas como inspiração, mas como um chamado para repensarmos como estruturamos nossos times, nossos pipelines e nossas carreiras.