Responsável Global da AWS pela Arquitetura de Soluções Partilha o Seu Modelo de Modernização Orientada por IA

Saurabh Shrivastava é Diretor Global de Arquitetura de Soluções e Engenharia Destacada na Amazon Web Services, onde se dedica à IA agêntica e à modernização empresarial.

Falámos com Saurabh para conhecer os novos modelos de engenharia que está a utilizar no seu trabalho na AWS. Eis o que partilhou.

Industrializar a IA de forma responsável

Sou um líder de transformação tecnológica e de IA com mais de 20 anos de experiência a ajudar empresas a transformar mudanças tecnológicas complexas em resultados empresariais escaláveis. O meu percurso passou pela engenharia, arquitetura empresarial, engenharia de campo alinhada com o produto, transformação para a cloud e, atualmente, pela IA agêntica e pelos modelos de fábrica de software na AWS.

No início da minha carreira, desenvolvi e liderei plataformas empresariais de grande escala em ambientes de telecomunicações, retalho, cadeia de abastecimento, tecnologia financeira e I&D. Isso proporcionou-me uma forte apreciação pelo pensamento sistémico, pela fiabilidade, pela complexidade da integração e pela realidade de operar tecnologia à escala empresarial.

Na AWS, o meu papel evoluiu, passando de ajudar os clientes a modernizar infraestruturas e aplicações para liderar a arquitetura global de soluções e iniciativas globais de engenharia destacada centradas na IA, na modernização e nas plataformas agênticas. Trabalhei com líderes empresariais, parceiros, equipas de produto e equipas de engenharia para passar da estratégia e da experimentação a plataformas controladas e prontas para produção.

A IA já não é apenas mais uma vaga tecnológica. Está a transformar a forma como as organizações desenvolvem software, como os colaboradores trabalham, como os clientes interagem e como as organizações tecnológicas têm de operar. O verdadeiro desafio de liderança não consiste apenas em selecionar modelos ou ferramentas. Consiste em criar o modelo operativo, a arquitetura, a governação, o talento e a disciplina de produto necessários para industrializar a IA de forma responsável.

Liderar a arquitetura de soluções da AWS

Enquanto Diretor Global de Arquitetura de Soluções e FDE, lidero a organização global da AWS responsável pela arquitetura de soluções e pela engenharia destacada, com foco em plataformas de IA agêntica, modernização empresarial e transformação para a cloud à escala da produção.

A organização opera à escala empresarial, trabalhando com grandes clientes globais, parceiros estratégicos, equipas de produto, equipas especializadas de engenharia e organizações regionais de campo. O âmbito da arquitetura é vasto: plataformas de IA/ML, fluxos de trabalho agênticos, bases de dados e analítica, modernização de aplicações, infraestrutura nativa da cloud, segurança, governação e soluções integradas com parceiros.

Lidero, capacito e influencio globalmente mais de 200 especialistas, engenheiros de parceiros e líderes tecnológicos de campo. O trabalho é altamente complexo porque não desenvolvemos demonstrações isoladas. Ajudamos as empresas a passar de ideias iniciais de IA e casos de negócio de modernização para plataformas repetíveis, seguras e prontas para produção, capazes de escalar entre unidades de negócio, mercados e ambientes de clientes.

O nosso modelo de implementação combina engenharia destacada, mecanismos de plataforma globais, implementação liderada por parceiros e ciclos de feedback entre produto e campo. A minha equipa desenvolve modelos reutilizáveis, arquiteturas de referência, demonstrações executivas, manuais técnicos, padrões de governação e modelos de soluções componíveis que aceleram a adoção, mantendo simultaneamente a qualidade, a segurança e a disciplina operacional.

Porque é essencial um modelo de engenharia destacada com a IA

Introduzi um modelo de engenharia destacada para a modernização orientada pela IA no ano passado.

Na era da cloud, tínhamos arquiteturas de referência reutilizáveis, modelos de soluções, padrões de implementação e pontos de controlo de governação. Estes elementos eram necessários, mas insuficientes no caso da IA. Os clientes continuavam a ter dificuldades em passar da POC para a produção porque o trabalho mais difícil ocorria no seu ambiente real: dados, parque aplicacional, complexidade do código, restrições de segurança e modelo operativo.

Por isso, introduzi um mecanismo FDE que integra engenheiros muito mais perto das cargas de trabalho reais do cliente. Em vez de prestar aconselhamento a partir do exterior, a equipa FDE trabalha com os dados, o código, a arquitetura e as equipas de implementação do cliente para identificar candidatos à modernização, desenvolver recursos utilizáveis e colocar a primeira carga de trabalho em produção.

Introduzi também um modelo simples 3-3-3: 3 dias para a descoberta, 3 semanas para a avaliação e 3 meses para colocar a primeira carga de trabalho em produção. Isto proporcionou aos executivos um percurso claro desde a ambição de IA até ao valor mensurável.

O impacto foi significativo. Os clientes conseguiram acelerar o seu percurso de modernização entre 2x e 4x, reduzir os custos até metade e ultrapassar as demonstrações para alcançar um ROI efetivo. Mais importante ainda, isto mudou a conversa ao nível executivo. A IA deixou de ser uma experiência secundária; tornou-se um mecanismo prático para modernizar cargas de trabalho reais, melhorar a produtividade da engenharia e criar valor empresarial mensurável.

Como modernizar mais rapidamente sem perder a confiança

Uso intensivamente a IA para acelerar a compreensão técnica, o reconhecimento de padrões e a capacidade de produção da engenharia, mas não delego a responsabilização à IA.

Nas empresas complexas, o negócio é frequentemente construído sobre décadas de código, dívida técnica, dependências não documentadas e regras de negócio incorporadas. Nesse ambiente, precisamos de abordagens determinísticas e probabilísticas. Não podemos depender exclusivamente da descoberta probabilística feita pela IA quando tentamos compreender sistemas críticos para a missão.

Para a descoberta de código, a extração de regras de negócio, a análise de dependências, o mapeamento de funcionalidades e a avaliação do estado atual, prefiro uma abordagem mais determinística. Precisamos de rastreabilidade, repetibilidade, evidências e confiança naquilo que o sistema faz. A IA pode ajudar ao resumir, agrupar e acelerar a análise, mas a base precisa de factos verificáveis provenientes do código, dos registos, dos fluxos de dados, do comportamento em execução e de evidências arquiteturais.

A IA torna-se mais poderosa no trabalho do estado futuro: gerar opções de modernização, propor novas arquiteturas, definir limites de serviços, desenvolver padrões de migração, escrever código, gerar testes e acelerar a implementação. Essa parte pode ser mais probabilística, porque a IA pode explorar opções e melhorar a velocidade de engenharia.

Mas, mesmo aí, a decisão final permanece humana. Os engenheiros e líderes responsáveis devem validar as escolhas arquiteturais, a postura de segurança, a prontidão para produção, o risco de conformidade, o impacto nos clientes e os compromissos de investimento.

Assim, o meu modelo é: descoberta determinística, conceção e implementação aceleradas pela IA e validação orientada por humanos. Esta combinação permite-nos modernizar mais rapidamente sem perder confiança, controlo ou responsabilização empresarial.

As desvantagens da IA nos fluxos de trabalho de engenharia

Saurabh partilha

O custo não é a única desvantagem (da IA). A IA também pode criar uma falsa confiança se as equipas a utilizarem sem governação.

O maior resultado positivo foi o facto de a IA ter encurtado significativamente o caminho da descoberta até à produção quando integrada num fluxo de trabalho de engenharia disciplinado.

A IA também acelerou a compreensão do código, a extração de regras de negócio, a análise de dependências, a geração de testes, a documentação e o planeamento da modernização. Reduziu o tempo de análise manual, ajudando as equipas de engenharia a concentrarem-se mais nas decisões arquiteturais, na validação e na prontidão para produção.

Mas a IA pode tornar-se muito dispendiosa muito rapidamente se as equipas não conceberem os sistemas tendo em conta a economia da inferência. Nas grandes empresas, com milhões de utilizadores, os custos dos tokens dos modelos de fronteira podem atingir milhões de dólares se cada interação depender de modelos fundacionais externos de terceiros sem otimização.

Uma das lições é que a arquitetura de IA tem de incluir uma arquitetura de custos. Para algumas cargas de trabalho, as empresas devem avaliar a inferência alojada localmente ou na nuvem, utilizando GPUs ou aceleradores, incluindo opções como o vLLM em infraestruturas de nuvem. Isto proporciona maior controlo sobre os custos, a latência, os limites dos dados e a estratégia de disponibilização dos modelos. Técnicas como o armazenamento em cache de KV, o agrupamento contínuo, a quantização e a otimização de kernels podem melhorar substancialmente a utilização das GPUs e reduzir o custo da inferência.

O custo não é a única desvantagem. A IA também pode criar uma falsa confiança se as equipas a utilizarem sem governação. Os riscos incluem uma compreensão incompleta do código, dependências alucinadas, uma cobertura de testes insuficiente, falhas de segurança e equipas que avançam demasiado depressa do protótipo para a produção.

Porque é que a IA tem dificuldades com a modernização de sistemas legados de ponta a ponta

A IA teve mais dificuldades quando as equipas lhe pediram para tomar decisões técnicas sem contexto suficiente sobre o sistema.

Um exemplo comum é a modernização de sistemas legados. A IA pode resumir código, gerar ideias para a migração e até produzir rapidamente código novo. Mas, nas grandes empresas, a verdadeira complexidade estende-se para além do código. Envolve décadas de regras de negócio, integrações não documentadas, processos em lote, dependências de dados, exceções operacionais, restrições de segurança e responsabilidades organizacionais. Se pedir à IA para modernizar esse ambiente tendo apenas uma visão parcial, poderá produzir respostas confiantes, mas incompletas.

A prontidão para produção é outra área em que a IA enfrenta dificuldades. A IA pode criar protótipos muito rapidamente, mas muitos protótipos não se transformam automaticamente em sistemas de produção seguros, observáveis, resilientes e eficientes em termos de custos. Por vezes, as equipas subestimam o trabalho necessário para os testes, a governação, a resposta a incidentes, a monitorização, a avaliação de modelos, a qualidade dos dados e a gestão do ciclo de vida.

Como os engenheiros podem melhorar os produtos controlando os custos e a fiabilidade da inferência

Eis um exemplo de uma grande plataforma de criação de conteúdos para meios de comunicação e marketing, onde a IA ajuda os utilizadores a passar da intenção a ativos digitais concluídos à escala empresarial.

O fluxo de trabalho começa quando um utilizador descreve aquilo que pretende criar: uma campanha de lançamento de produto, um conteúdo criativo para redes sociais, uma apresentação comercial, um excerto de vídeo ou um ativo de marketing localizado. A IA interpreta a intenção do utilizador, incluindo o público, o formato, o tom, as diretrizes da marca, os ativos necessários, as restrições do canal e os requisitos de conformidade.

A partir daí, a plataforma utiliza um fluxo de trabalho baseado em agentes. Um agente obtém modelos, logótipos, tipos de letra, cores e ativos de campanha aprovados pela marca. Outro gera textos e variações criativas. Outro propõe esquemas de disposição. Outro verifica a conformidade com a marca, a acessibilidade, as políticas e a segurança dos conteúdos. Uma camada final de orquestração reúne o resultado em ativos editáveis e encaminha-o através dos fluxos de aprovação ou publicação.

A esta escala, a engenharia enfrentou desafios não só relacionados com a qualidade dos modelos, mas também com a economia da inferência, a latência, a fiabilidade e a governação. A equipa otimizou um ambiente de inferência de muito grande escala, com suporte para cerca de 10 000 nós de computação e aproximadamente 80 000 GPUs. A arquitetura combinava capacidade de GPU de vários fornecedores de serviços de nuvem e terceiros aprovados, ligando esses ambientes através de uma camada de rede híbrida. Isto proporcionou à plataforma flexibilidade para posicionar as cargas de trabalho com base no custo, na latência, na disponibilidade e na localização dos dados.

A equipa implementou também uma estratégia mais disciplinada de disponibilização de modelos. Em vez de encaminhar todos os pedidos para o modelo de fronteira mais dispendioso, a plataforma distribuía os pedidos por modelos adequados à finalidade, incluindo modelos abertos como Kimi e Qwen, disponibilizados através de ambientes de execução otimizados como o vLLM e padrões ao estilo do Ollama. A equipa aplicou também técnicas de otimização da inferência, incluindo armazenamento em cache de KV, processamento contínuo em lotes, quantização, otimização da memória e afinação ao nível do núcleo, para melhorar a utilização das GPUs e reduzir os custos.

Os seres humanos mantiveram o controlo nos principais pontos de decisão. A IA gerava opções, recomendava esquemas de disposição, escrevia textos e acelerava a produção, mas o utilizador ou o responsável pela marca aprovava o ativo final. As equipas de engenharia eram responsáveis pelas salvaguardas: segurança, acesso aos dados, seleção de modelos, observabilidade, latência, controlos de custos, verificações de segurança e ciclos de feedback.

O resultado foi um fluxo de trabalho de IA que passou a fazer parte da experiência do produto, e não apenas uma ferramenta interna de produtividade. Reduziu o tempo entre a ideia e o ativo, melhorou a personalização, aumentou a reutilização de componentes de marca aprovados e criou um ciclo de feedback no qual as edições dos utilizadores e os dados de interação melhoravam as recomendações futuras. Ao mesmo tempo, a arquitetura proporcionou à empresa um controlo muito mais forte sobre os custos de inferência, a fiabilidade e a governação.

Por que motivo a implementação de IA exige uma mentalidade de produto

A implementação de ferramentas de IA tem menos que ver com a adoção de ferramentas e mais com a alteração do modelo operacional da engenharia.

Inicialmente, muitas organizações pensam que o desafio consiste em dar aos engenheiros acesso a copilotos, assistentes de programação, APIs de modelos ou plataformas internas de IA. Isso ajuda, mas não é suficiente. Sem padrões claros, as equipas utilizam a IA de forma inconsistente. Algumas usam-na apenas para gerar código. Outras usam-na para documentação. Algumas confiam demasiado nela. Outras evitam-na porque não têm a certeza quanto aos riscos de segurança, propriedade intelectual ou qualidade.

Se tivesse de começar de novo, definiria ainda mais cedo o fluxo de trabalho de engenharia com IA: onde a IA deve e não deve ser utilizada, que provas são necessárias, o que os seres humanos têm de rever e como os resultados são testados, protegidos e promovidos para produção.

Isto teria evitado alguns problemas. Em primeiro lugar, poderíamos ter reduzido a utilização inconsistente entre as equipas. Em segundo lugar, poderíamos ter evitado uma confiança mal colocada no código ou na análise gerados por IA que pareciam corretos, mas não tinham contexto suficiente. Em terceiro lugar, poderíamos ter controlado os custos mais cedo, implementando desde o início o encaminhamento de modelos, a orçamentação de tokens, a colocação em cache e a governação da inferência. Em quarto lugar, poderíamos ter criado melhores padrões reutilizáveis, em vez de deixar cada equipa inventar a sua própria abordagem.

A maior lição é que a implementação da IA exige uma mentalidade de produto e de plataforma. É necessário capacitação, mecanismos de proteção, observabilidade, controlos de custos, revisão de segurança, prompts e agentes reutilizáveis, padrões de avaliação e uma responsabilização humana clara. Caso contrário, a IA aumenta a atividade sem aumentar necessariamente a qualidade da engenharia ou o valor para o negócio.

Porque é que o SDLC tem de se tornar o AI-DLC

Partilhas de Saurabh

Os CTO devem estar a redesenhar ativamente o próprio ciclo de vida da entrega de software.

Os CTO devem estar a redesenhar ativamente o próprio ciclo de vida da entrega de software. Penso nisto como uma transição do SDLC tradicional para o AI-DLC, um ciclo de vida de entrega aumentado por IA para a era da IA agentiva.

No SDLC tradicional, seguimos frequentemente fases lineares: requisitos, conceção, desenvolvimento, implementação e suporte. Isto funcionava razoavelmente bem quando o principal objetivo era criar software determinístico através de transições estruturadas. Mas, com a IA, especialmente a IA agentiva, o ciclo de vida torna-se mais iterativo e compacto.

Divido o AI-DLC em três fases principais: início, construção e operação.

• Na fase de início, a IA ajuda na descoberta, na compreensão do código, na extração de regras de negócio, na análise de dependências, no esclarecimento de requisitos, na identificação de riscos e no planeamento do estado pretendido.
• Na fase de construção, a IA apoia as opções arquiteturais, a decomposição de serviços, a geração de código e testes, a documentação, as revisões de segurança, os padrões de infraestrutura e a execução da modernização.
• Na fase de operação, a IA apoia a observabilidade, a triagem de incidentes, os ciclos de feedback, a avaliação de modelos, a otimização de custos, a governação e a melhoria contínua.

O ponto importante é que o AI-DLC não é apenas o SDLC com um assistente de programação adicionado. É um modelo operacional de engenharia redesenhado. Integra agentes de IA, descoberta determinística, validação humana, pontos de controlo de segurança, prontidão para produção e governação de custos num único fluxo de trabalho.

Como as equipas de engenharia estão a mudar devido à IA

A IA fez com que as equipas de engenharia passassem de uma execução sequencial baseada em funções para equipas mais integradas e orientadas para os resultados.

No passado, organizávamo-nos em torno de funções distintas: arquitetos, engenheiros de aplicações, engenheiros de dados, DevOps, segurança, garantia de qualidade e operações. Essas funções continuam a ser importantes, mas a IA compacta o ciclo de vida e reduz o valor de longas transições. As equipas com melhor desempenho são mais multifuncionais e estão mais próximas do problema de negócio.

Para a modernização orientada por IA e a engenharia de produto, procuro agora equipas que combinem várias competências: bases sólidas de engenharia de software, engenharia de cloud e de plataformas, literacia em dados e IA, consciência de segurança, pensamento orientado para o produto e discernimento operacional. Também valorizo engenheiros que trabalham em ambientes ambíguos, raciocinam a partir de primeiros princípios e validam os resultados da IA em vez de os aceitarem cegamente.

O modelo de engenharia destacada é um bom exemplo. Em vez de manter a arquitetura, a engenharia de IA, o DevOps e a segurança em vias sequenciais separadas, aproximamos essas competências do cliente ou do ambiente empresarial. A equipa trabalha com código, dados, restrições e métricas de sucesso reais.

O recrutamento também mudou. Continuo a dar grande importância à profundidade técnica, mas procuro também pensadores sistémicos: pessoas que compreendam a arquitetura, utilizem a IA de forma responsável, comuniquem com as partes interessadas do negócio e assumam a responsabilidade pelos resultados em produção. Na era da IA, os melhores engenheiros não são apenas produtores de código. São definidores de problemas, validadores e criadores de sistemas repetíveis.

Como medir a eficácia da IA

Uma pergunta que gostaria que mais pessoas fizessem é: como devem os CTO medir se a IA está a criar valor empresarial duradouro?

Os CTO não devem medir a IA apenas pelo número de projetos-piloto ou copilotos implementados, nem pela precisão do modelo analisada isoladamente. Estes são sinais úteis, mas não comprovam uma transformação.

Os CTO devem medir a IA em quatro dimensões:

1. Produtividade de engenharia: a IA está a reduzir o tempo de ciclo, a melhorar a qualidade do código, a aumentar a cobertura de testes, a acelerar a modernização e a reduzir a dívida técnica?
2. Impacto empresarial: a IA está a melhorar a experiência do cliente, a produtividade dos colaboradores, a conversão de receitas, a eficiência de custos ou a velocidade de chegada ao mercado?
3. Maturidade em produção: os sistemas de IA são seguros, observáveis, fiáveis, regulados e têm os custos controlados? Têm uma responsabilização humana clara e critérios de aprovação para a entrada em produção?
4. Reutilização e escalabilidade: as equipas estão a criar serviços de IA, agentes, instruções, padrões, produtos de dados e capacidades de plataforma reutilizáveis, ou estão a criar demonstrações isoladas?

Esta questão é importante porque a IA pode criar uma grande quantidade de atividade visível sem criar valor duradouro. Os CTO têm de converter a atividade relacionada com IA em capacidade repetível. Isto significa ligar a estratégia, a arquitetura, o modelo operacional, a governação e a dimensão económica.

Porque devem os CTO separar a experimentação da industrialização

Eis o meu conselho.

Em primeiro lugar, não trate a IA como uma experiência paralela. Trate-a como uma nova camada operacional da empresa. A IA afetará a forma como o software é desenvolvido, como os colaboradores trabalham, como os clientes interagem e como as decisões são tomadas. A função do CTO é conduzir a organização de projetos-piloto dispersos para uma estratégia de plataforma de IA governada e escalável.

Em segundo lugar, separe a experimentação da industrialização. É perfeitamente aceitável experimentar rapidamente, mas a IA em produção precisa de arquitetura, segurança, governação de dados, avaliação, observabilidade, controlos de custos e responsabilização humana clara. Muitas empresas estão bloqueadas porque têm muitas demonstrações, mas não dispõem de um caminho repetível para a produção. Os CTO precisam de construir esse caminho.

Em terceiro lugar, concentre-se no valor empresarial, não na novidade do modelo. As organizações vencedoras não serão simplesmente as que utilizarem o modelo mais recente. Serão as que incorporarem a IA em fluxos de trabalho reais, modernizarem a sua base tecnológica, melhorarem a produtividade de engenharia e medirem resultados como o tempo de ciclo, a eficiência de custos, a experiência do cliente, o impacto nas receitas e a redução do risco.

E, em quarto lugar, o meu conselho prático é criar em conjunto uma plataforma de IA e um modelo de engenharia destacada. A plataforma proporciona reutilização, governação e escala. O modelo FDE leva a IA para cargas de trabalho reais de clientes e empresas, utilizando dados reais, código real e restrições reais. É assim que os CTO podem passar da ambição relacionada com a IA para um ROI concretizado.

Acompanhe o trabalho

Acompanhe o trabalho de Saurabh Shrivastava no LinkedIn e na sua página de autor na Amazon.

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