Diretor Técnico Global de Campo insta os líderes a concentrarem-se na infraestrutura de dados antes da IA

Kai Waehner é CTO Global de Campo na Confluent e prestou aconselhamento a grandes empresas como a BMW e a Siemens. O seu foco centra-se na infraestrutura de dados, na estratégia de integração e na adoção de IA.

Falámos com Kai para compreender por que razão tantas iniciativas de IA empresarial falham. Foi isto que nos disse.

Uma vantagem no reconhecimento de padrões

Chamo-me Kai Waehner. Passei os últimos nove anos como CTO Global de Campo na Confluent, trabalhando com centenas de empresas na América do Norte, na Europa e na região Ásia-Pacífico. Prestei aconselhamento a empresas como a BMW, a Volkswagen, a Lufthansa, a Siemens, a DISH Networks e a Globe Telecom. Trabalho com executivos em áreas como estratégia tecnológica, execução de estratégias de entrada no mercado, avaliação de fornecedores, arquitetura empresarial e criação de conteúdos.

A função de CTO de Campo é diferente de dirigir uma única organização de engenharia. Trabalho simultaneamente em dezenas de ambientes de clientes, prestando aconselhamento a arquitetos e líderes da direção sobre infraestrutura de dados, estratégia de integração e adoção de IA. Essa amplitude proporciona-me uma vantagem no reconhecimento de padrões que é difícil de obter a partir do interior de uma única empresa.

A minha experiência abrange toda a história da integração de dados empresariais: ETL, ESB, iPaaS e gestão de API, seguidos de nove anos centrados na transmissão de dados, com Apache Kafka e Flink como base para arquiteturas orientadas por eventos e, cada vez mais, na orquestração de processos e na IA em todo o espectro, desde a aprendizagem automática preditiva até à IA generativa e agêntica. Faço regularmente apresentações a analistas da Gartner e da Forrester e publico a minha própria investigação, abrangendo cenários de fornecedores, padrões de arquitetura e estudos de caso reais do setor. Publiquei também um livro sobre transmissão de dados.

A conversa sobre transformação da IA que tenho com líderes tecnológicos não se centra principalmente nos modelos. Centra-se na infraestrutura que lhes está subjacente. Os sistemas de IA agêntica que executam ações autónomas nos fluxos de trabalho empresariais precisam de três elementos para funcionar de forma fiável:

• Dados em tempo real para atuarem com base na realidade atual
• Inteligência de processos para definir o que lhes é permitido fazer
• Confiança incorporada na arquitetura, não apenas no modelo

O meu pensamento centra-se nessa convergência.

Porque têm as camadas da arquitetura de convergir para o sucesso da IA

Em todos os setores, vejo consistentemente as empresas investirem fortemente em três camadas separadas: uma espinha dorsal de integração de dados, uma camada de automatização de processos e, cada vez mais, uma iniciativa de IA. O problema é que estas três camadas quase nunca são concebidas para funcionarem em conjunto. A integração de dados move dados, mas não estabelece ligação às decisões empresariais. A automatização de processos impõe fluxos de trabalho, mas funciona com contexto desatualizado. Os agentes de IA geram recomendações ou executam ações, mas não têm limites controlados em torno daquilo que podem fazer. Cada camada funciona de forma isolada. Falta a arquitetura convergente.

Os modelos de implementação que observo variam significativamente. Algumas organizações executam infraestruturas nativas da nuvem totalmente geridas na AWS, Azure ou GCP, e as maiores empresas globais incluem frequentemente implementações na China continental na Alibaba Cloud, mantidas deliberadamente separadas por razões legais, regulamentares e de privacidade dos dados. Outras operam arquiteturas híbridas com centros de dados locais ligados à nuvem, devido a requisitos de soberania dos dados ou a sistemas antigos que não conseguem migrar rapidamente. Os setores regulamentados, como os serviços financeiros e os cuidados de saúde, têm quase sempre requisitos de várias regiões ou de várias nuvens, não por escolha, mas por imposição de conformidade. Os clientes do setor industrial têm frequentemente implementações na periferia, onde processam os dados junto da linha de produção antes de os agregarem centralmente.

Em todos estes ambientes, a arquitetura orientada por eventos tornou-se uma infraestrutura crítica para a missão. O Apache Kafka consolidou-se como o padrão de facto para o agente de eventos que permite um verdadeiro desacoplamento entre sistemas, processamento em tempo real a qualquer escala e integração híbrida e multinuvem. O PayPal processa diariamente mais de um bilião de mensagens Kafka. A New Relic ingere milhares de milhões de pontos de dados por minuto. Não se trata de implementações experimentais. São a espinha dorsal operacional da atividade.

Muitas empresas já dispõem das três peças de que necessitam para uma IA agêntica fiável. Falta-lhes o compromisso arquitetural para as fazer convergir.

Porque a preparação dos dados precede a preparação para a IA

Pensamentos de Kai

A preparação para a IA é a preparação dos dados.

Eis o que descobri: a IA não é a parte difícil. A infraestrutura de dados que lhe está subjacente é.

A maioria das iniciativas de IA empresarial que vi serem bem-sucedidas ou falharem nos últimos nove anos dependeu menos do modelo escolhido e mais de a organização dispor ou não de uma base fiável, controlada e em tempo real para alimentar esse modelo com dados atuais, exatos e de confiança.

Um modelo bem alinhado que receba dados desatualizados ou inconsistentes produzirá resultados pouco fiáveis. Um sistema de IA agentiva sem uma camada de processos que defina o que pode fazer acabará por executar uma ação que ninguém consegue explicar ou reverter. Estes não são problemas do modelo. São problemas de infraestrutura e arquitetura. E são totalmente previsíveis antes de escrever uma única linha de código de IA.

A implicação prática é que a preparação para a IA é a preparação dos dados. Antes de selecionar um modelo, antes de escolher um fornecedor de IA, antes de lançar um projeto-piloto, um CTO deve conseguir responder honestamente a três perguntas.

1. A organização tem acesso fiável a dados em tempo real provenientes dos seus sistemas operacionais?
2. Existem processos governados que definam o que um sistema de IA pode e não pode fazer de forma autónoma?
3. Existe uma estrutura de confiança ao nível da arquitetura, e não apenas dentro do modelo, capaz de impor esses limites em produção?

Se a resposta a qualquer uma destas três perguntas for não, a jornada de IA deve começar aí, e não pelo modelo.

Porque é que a IA tem de ser incorporada nos processos empresariais existentes

A mudança mais significativa que promovi foi passar de construir IA como uma iniciativa separada para a incorporar nos processos empresariais existentes. Esta é uma área que recebe muito pouco investimento e tem consequências significativas. Na verdade, diria que a maioria dos CTOs deveria passar de conceber novos sistemas de IA para conceber a forma como a IA participa nos fluxos de trabalho existentes, os limites impostos pela camada de processos e a forma como a governação e a auditabilidade são integradas — antes de implementar um único modelo.

Antes de fazer esta mudança, o padrão era quase sempre o mesmo. Um projeto de IA começava desligado dos sistemas operacionais. O modelo tinha um bom desempenho no laboratório. Em produção, não tinha acesso fiável a dados atuais, um limite definido para as suas ações nem integração nos fluxos de trabalho de aprovação dos quais a empresa dependia. Uma demonstração impressionante. Uma implementação falhada.

A mudança que agora defendo sistematicamente assenta em dois pontos.

• Em primeiro lugar, tratar a arquitetura existente orientada para eventos como a base da adoção da IA, e não como um alvo a substituir. Os sistemas permanecem. Os processos empresariais permanecem. A IA participa em fluxos de trabalho já em execução, consumindo eventos em tempo real e atuando dentro dos limites definidos pela camada de processos.
• Em segundo lugar, transferir as salvaguardas da IA do modelo para a camada de orquestração de processos. Um modelo bem alinhado não é suficiente. Uma IA fiável em produção significa que a camada de fluxo de trabalho impõe etapas de aprovação, vias de escalamento e registos de auditoria para cada ação autónoma executada pelo agente.

A Alpian, o primeiro banco privado digital totalmente licenciado da Suíça, é um exemplo forte de como fazer isto corretamente desde o primeiro dia. A Alpian construiu toda a sua plataforma com base numa arquitetura orientada para eventos, com o Apache Kafka como sistema nervoso central que liga microsserviços, produtos de dados de domínio e agentes de IA. Quando introduziu IA agentiva e RAG nos fluxos de trabalho de interação com os clientes, a arquitetura já estava preparada. Os eventos do Kafka forneceram aos agentes contexto em tempo real. A camada de processos impôs os controlos de conformidade. A empresa integrou encriptação ao nível dos campos e governação de esquemas desde o início.

O resultado foi uma instituição financeira regulamentada a executar agentes de IA autónomos em fluxos de trabalho governados e auditáveis — exatamente o padrão que a maioria das empresas tradicionais está agora a tentar adaptar.

As organizações que fazem isto corretamente tratam a adoção da IA como uma disciplina arquitetónica, e não como um sprint de projeto.

Porque é que a preparação dos dados determina o sucesso da implementação da IA

Após nove anos na Confluent, em centenas de ambientes empresariais, os resultados de IA que observei são profundamente desiguais. A diferença entre resultados bons e maus resulta quase sempre de uma única coisa: o facto de a infraestrutura de dados estar, ou não, preparada antes da introdução da IA.

No lado positivo, os números de implementações bem arquitetadas são convincentes. A BMW evita mais de 500 minutos de paragem não planeada da produção por ano numa única fábrica. O Alpian gere um banco digital totalmente regulamentado, com IA autónoma integrada em fluxos de trabalho de clientes controlados e auditáveis. O padrão qualitativo entre implementações bem-sucedidas é consistente: menor tempo de chegada ao mercado, redução dos custos operacionais em fluxos de trabalho repetitivos de elevado volume e uma experiência do cliente significativamente melhor quando a IA acede a contexto em tempo real, em vez de dados antigos processados em lote.

No lado negativo, o padrão de insucesso é igualmente consistente. Os projetos de IA sem uma base de dados controlada produzem quase sempre o mesmo resultado: demonstrações impressionantes, implementações em produção falhadas. O modelo funciona no laboratório. Em produção, recebe dados desatualizados ou inconsistentes, produz alucinações em casos-limite, executa ações sem qualquer registo de auditoria e corrói, em vez de criar, a confiança das empresas na IA. Uma investigação do MIT estima que cerca de 95% dos projetos-piloto de IA nas empresas não conseguem produzir um impacto empresarial mensurável. Este número corresponde às minhas observações no terreno.

O modo de insucesso mais recente que tenho observado é a adição demasiado tardia da governação. As organizações implementam IA autónoma e descobrem depois, geralmente na sequência de um incidente, que nenhuma camada de processos definiu o que o agente podia fazer, que não existia um percurso de escalada para resultados incertos do modelo e que não havia um registo de auditoria para reconstituir os acontecimentos. Isto não é um problema de IA. É um problema de arquitetura. E é totalmente evitável.

Por que motivo a IA informa as decisões, mas os humanos asseguram a responsabilização

Vejo consistentemente um padrão: a IA informa e acelera. Toma decisões autónomas dentro de limites definidos. Mas os humanos assumem a responsabilidade pelas decisões mais importantes.

No lado informado pela IA, a síntese de investigação, a criação de conteúdos, a geração de código para problemas bem delimitados, os testes automatizados e a análise de segurança acrescentam um valor claro. No meu próprio trabalho, as ferramentas de IA comprimem em dias a síntese de relatórios de analistas, conversas com clientes e documentação técnica. O resultado continua a exigir o julgamento de especialistas para ser validado, mas o ponto de partida está muito mais avançado.

No lado das decisões autónomas, os agentes de IA devem decidir de forma independente quando o risco é limitado e o processo é devidamente controlado. A deteção de fraude nos serviços financeiros é o exemplo mais claro. Abaixo de um limiar de risco definido, um agente de IA bloqueia automaticamente uma transação sem intervenção humana. À medida que o valor da transação aumenta e a exposição regulamentar cresce, a camada de orquestração do processo encaminha o caso para um analista humano antes de tomar qualquer medida. O limite não é fixo. É definido pela empresa, codificado pelo fluxo de trabalho e aplicado pela camada de processos, não pelo próprio modelo.

No lado explicitamente humano, estabeleço o limite nas decisões com consequências arquitetónicas importantes, risco empresarial estratégico ou responsabilidade regulamentar significativa. Escolher um padrão de arquitetura fundamental, selecionar um fornecedor tecnológico estratégico, conceber o modelo de governação para um sistema de IA autónoma: estas continuam a ser decisões humanas. Avançar mais depressa não elimina as consequências de tomar decisões erradas.

Por que motivo a IA fica aquém do esperado em três áreas principais

A IA não produziu o impacto técnico ou de engenharia que os clientes inicialmente esperavam em três áreas.

A primeira é a integração de dados empresariais. A IA prometeu simplificar drasticamente a ligação entre sistemas heterogéneos: mapeamento de esquemas, aplicação da qualidade dos dados, lógica de transformação e governação em ambientes híbridos complexos. Na prática, a IA ajuda nestas tarefas, mas não as resolve. Um modelo não consegue raciocinar para ultrapassar a dívida arquitetónica subjacente, os sistemas antigos com modelos de dados não documentados, a semântica inconsistente entre unidades de negócio, a ausência de metadados e a responsabilidade fragmentada. Os engenheiros continuam a ter de realizar o trabalho difícil.

A segunda é a IA autónoma em fluxos de trabalho empresariais complexos e compostos por várias etapas. As demonstrações são convincentes. Em produção, os agentes falham de forma imprevisível quando encontram casos-limite que os dados de treino não abrangiam, quando a janela de contexto não contém estado atual suficiente ou quando a camada de processos não deteta e trata adequadamente os erros dos agentes. A diferença entre aquilo que um agente consegue fazer num ambiente controlado e aquilo que podemos confiar-lhe autonomamente num fluxo de trabalho de produção regulamentado continua a ser significativa.

A terceira é a tomada de decisões arquitetónicas. As ferramentas de IA aceleraram significativamente a programação de rotina, a escrita de testes e a documentação. Mas não melhoram de forma fiável as decisões sobre a arquitetura fundamental. Os modelos refletem padrões do passado. A arquitetura empresarial exige discernimento sobre restrições futuras, trajetórias regulamentares e apostas tecnológicas que os modelos não conseguem avaliar bem. As equipas que dependem excessivamente da IA para tomar decisões arquitetónicas tendem a produzir sistemas localmente coerentes, mas globalmente frágeis.

O aspeto comum às três áreas é o seguinte: a IA produz resultados quando o problema está bem delimitado, os dados são limpos e atuais e existe a intervenção de uma pessoa com conhecimentos especializados do domínio. Fica aquém do esperado sempre que o problema exige discernimento contextual, mudança organizacional ou pensamento arquitetónico que ultrapasse a correspondência de padrões com base em dados históricos.

Como a IA enfrenta dificuldades com a segurança e a escalabilidade no código

A dificuldade mais consistente que observo surge na fronteira entre o código gerado por IA e o discernimento de engenharia de nível de produção.

As ferramentas de geração de código por IA são genuinamente úteis para tarefas repetitivas e bem delimitadas: código padrão, casos de teste, documentação e transformações simples. Os problemas surgem quando as equipas estendem essa confiança a decisões arquiteturais, código sensível do ponto de vista da segurança ou componentes críticos para a escalabilidade sem uma revisão humana rigorosa.

No que diz respeito à segurança, o código gerado por IA introduz frequentemente vulnerabilidades subtis que passam pelos sistemas de análise automatizada, mas falham em condições adversariais. A injeção de prompts é o exemplo atual mais claro nos sistemas de IA agêntica. Um agente que gera ou executa código com base nos dados introduzidos pelo utilizador sem uma validação adequada dos dados de entrada e sem isolamento numa área protegida cria superfícies de ataque fáceis de ignorar e difíceis de detetar posteriormente. Já observei este padrão surgir em implementações iniciais de IA agêntica, nas quais as equipas se concentraram nas capacidades e na velocidade e trataram a revisão de segurança como uma etapa posterior.

No que diz respeito à escalabilidade, as ferramentas de IA tendem a gerar soluções que funcionam corretamente em pequena escala, mas que contêm pressupostos ocultos sobre o volume de dados, a simultaneidade ou a latência, que só se revelam sob a carga de produção. Um consumidor Kafka gerado que funciona perfeitamente nos testes pode falhar de forma imprevisível a dez mil eventos por segundo se o código gerado não tiver em conta o reequilíbrio das partições, a gestão dos offsets ou o tratamento da contrapressão. O modelo não conhece o seu ambiente de produção. Conhece padrões presentes nos dados de treino.

A resposta prática não é deixar de utilizar IA para gerar código. É tratar o código gerado por IA da mesma forma que trataria o código de um engenheiro competente, mas júnior, que nunca viu o seu sistema de produção. Reveja-o. Teste-o em condições realistas. E nunca o deixe aproximar-se de caminhos críticos para a segurança ou para a escalabilidade sem a aprovação de um engenheiro sénior.

O que os líderes tecnológicos devem fazer a seguir

Pensamentos de Kai

Invista na sua base de dados antes da sua ambição de IA…trate a governação da IA como um problema de arquitetura, não como um problema de políticas…pense simultaneamente nas duas direções.

Eis três conselhos, pela ordem da sua importância:

Primeiro, invista na sua base de dados antes da sua ambição de IA. As organizações que obtêm resultados mensuráveis com IA não são as que avançaram mais rapidamente para um novo modelo. Tinham dados limpos, em tempo real e governados a fluir pelos seus sistemas antes de a conversa sobre IA ter começado. Se os seus dados estiverem isolados, desatualizados ou sem governação, resolva isso primeiro. Nenhum modelo compensa dados de má qualidade à escala.

Segundo, trate a governação da IA como um problema de arquitetura, não como um problema de políticas. Redigir orientações sobre a utilização responsável da IA é necessário, mas não suficiente. É a camada de processos que governa efetivamente o comportamento dos agentes em produção: os controlos dos fluxos de trabalho, os limiares de aprovação, os percursos de escalamento e os registos de auditoria que impõem limites, independentemente do que o modelo recomenda. Integre-os na arquitetura desde o início. Adaptar a governação após a implementação é dispendioso, pouco fiável e geralmente acontece depois de algo ter corrido mal.

Terceiro, pense simultaneamente nas duas direções. A pressão de baixo para cima para lançar rapidamente casos de utilização de IA é real e legítima. Também o é a necessidade, de cima para baixo, de uma arquitetura estratégica que evite criar soluções pontuais fragmentadas que passará anos a desemaranhar. Os CTO que observo a gerir bem esta situação conseguem manter ambas as perspetivas ao mesmo tempo: avançar rapidamente em casos de utilização específicos, mantendo simultaneamente uma orientação arquitetural clara que preserve a capacidade de composição e de governação desses casos ao longo do tempo.

As organizações que olharão para este período como uma vantagem competitiva não são as que adotaram a IA mais cedo. Construíram a infraestrutura para tornar a IA fiável e, depois, avançaram rapidamente com base nessa fundação.

Acompanhe

Pode acompanhar o trabalho de Kai Waehner no seu site, no blogue e no LinkedIn.

Em breve, haverá mais entrevistas com especialistas no The CTO Club!