Líder tecnológico com mais de 30 anos de experiência explica como passar de silos de IA para um modelo operacional com governação

Prem Kumar A S tem mais de 30 anos de experiência na liderança de projetos de TI e de infraestrutura na nuvem. Atualmente, exerce funções como VCTO na The Preminent.

Reunimo-nos com Prem para compreender como as organizações podem passar de núcleos isolados de IA para um modelo operacional com governação. Foi isto que nos contou.

Mais de 30 anos de experiência

Tenho mais de 30 anos de experiência na liderança de projetos de TI e de infraestrutura na nuvem em todo o mundo. Atualmente, trabalho como VCTO, prestando aconselhamento a conselhos de administração e a diretores executivos em matéria de tecnologia, risco cibernético, resiliência, confiança e governação na era da IA. O meu foco consiste em ajudar as equipas de liderança a tomar decisões mais claras, sólidas e preparadas para o futuro.

Paralelamente, apresento o PREMINENT KONCLAVE do Power of Knowing Forum — uma série semanal de podcasts de referência que abrange tecnologia, cibersegurança, crescimento e estratégia, com mais de 370 conversas com líderes e um ecossistema de especialistas em crescimento.

Como passar de núcleos isolados de IA para um modelo operacional com governação

Passámos da experimentação com ferramentas para um modelo operacional com governação — especificamente através da introdução de uma camada de governação de IA e de análise da implementação antes de qualquer solução com IA poder entrar em produção.

Antes disso, a IA estava a ser explorada em núcleos isolados — assistentes, projetos-piloto de automação, casos de utilização de análise de dados e alguma experimentação no domínio da segurança. O problema não era a intenção; era a fragmentação. Diferentes equipas podiam avaliar ou até implementar capacidades com IA sem um enquadramento comum para a classificação de dados e o risco de exposição, os limites de utilização dos modelos, as aprovações de ferramentas de IA de terceiros, a análise humana e a responsabilização, ou a medição dos resultados empresariais.

Em termos simples, a IA estava a começar a entrar no ambiente mais rapidamente do que a governação conseguia acompanhar. Isto cria três riscos para qualquer organização séria:

1. Exposição da segurança e da privacidade: dados empresariais ou de clientes sensíveis a entrar em fluxos de trabalho de IA não geridos
2. Inconsistência operacional: equipas a utilizar diferentes ferramentas, instruções e processos sem normas repetíveis
3. Risco ao nível do conselho de administração sem visibilidade: a utilização de IA está a crescer, mas a liderança não sabe onde se encontram os riscos reais ou o retorno do investimento

Por isso, introduzimos um modelo prático de controlo da IA associado à forma como a tecnologia é criada, implementada e governada — não como um documento teórico de políticas, mas como uma disciplina operacional. Isto incluiu cinco mudanças concretas:

1. Os casos de utilização de IA tiveram de ser classificados antes da adoção. Cada caso de utilização de IA proposto foi categorizado como produtividade de baixo risco, apoio à decisão interna, interação com clientes ou sensível/regulamentado/de alto risco. Isto alterou imediatamente a conversa de “Podemos utilizar IA?” para “Que nível de governação exige este caso de utilização de IA?”
2. A implementação de IA passou a ter um ponto de controlo obrigatório. Antes de uma ferramenta, automação ou fluxo de trabalho com IA poder passar para produção, tinha de ser submetido a uma revisão que abrangesse a sensibilidade dos dados, os controlos de identidade e acesso, o risco associado ao fornecedor/modelo, o tratamento dos pedidos e resultados, os pontos de aprovação humana, os mecanismos de contingência/reversão e os requisitos de registo para auditoria. Isto tornou a implementação de IA parte da governação tecnológica, e não apenas uma encenação de inovação.
3. Separámos a experimentação da produção. Foi criado um modelo de ambiente controlado para a experimentação com IA. As equipas podiam testar ideias rapidamente — mas a utilização em produção exigia conjuntos de dados aprovados, ferramentas/modelos aprovados, responsáveis definidos, resultados empresariais mensuráveis e aprovação do risco sempre que necessário. Esta foi uma mudança cultural importante, porque protegeu a inovação sem permitir que a experimentação se transformasse silenciosamente numa dependência empresarial.
4. Introduzimos regras de “humano no circuito” para fluxos de trabalho sensíveis. Exigimos validação humana antes da ação final em qualquer caso de utilização de IA que tivesse impacto nos clientes, na conformidade, nas decisões financeiras, nas operações de segurança ou nas comunicações empresariais críticas. Isto evitou o erro clássico de tratar os resultados gerados por IA como automaticamente fiáveis apenas por serem rápidos.
5. Começámos a medir a IA pelo valor operacional, e não pelo entusiasmo. Cada iniciativa de IA tinha de responder às seguintes perguntas: Que esforço manual está a ser reduzido? Que tempos de execução melhoram? Que riscos são reduzidos? Como melhora a qualidade das decisões? Que ganhos de custos, produtividade ou resiliência são esperados? Isto transferiu a IA de uma conversa sobre tendências tecnológicas para uma conversa sobre o modelo operacional da empresa.

Isto deu-nos um melhor controlo sem travar o ritmo. A governação deixou de ser vista como um obstáculo. Ao criar um caminho claro — experimentar aqui, governar aqui, implementar aqui — as equipas avançaram mais depressa, com menos confusão e menos riscos ocultos.

Também reduziu o risco da IA sombra. Passámos a ter uma visibilidade muito melhor sobre as ferramentas utilizadas, as equipas que as utilizavam, os dados que lhes eram transmitidos e os casos de utilização que tinham um verdadeiro valor empresarial. Isto é fundamental, porque a adoção não gerida de IA está rapidamente a tornar-se a nova TI sombra.

Como implementar IA sem criar caos

Eis algumas sugestões para quem está a começar — se quiser evitar o caos:

1. Comece por fluxos de trabalho de grande volume e baixo risco. Não comece por decisões fundamentais de arquitetura ou alterações autónomas críticas para a produção. Comece pela documentação, criação de testes, triagem do apoio interno, sumarização de registos, elaboração de manuais operacionais ou geração de notas de versão.
2. Estabeleça salvaguardas antes de aumentar a escala. Cada implementação de engenharia de IA deve definir as ferramentas aprovadas, a política de utilização de pedidos/dados, as regras de revisão de código, os requisitos de análise de segurança, os limites da aprovação humana e o registo/auditabilidade.
3. Meça antes e depois. Acompanhe o tempo de execução, a frequência de implementação, os defeitos que chegam à produção, o MTTR, a taxa de reversão, o tempo dedicado a tarefas repetitivas e o retorno dos engenheiros sobre satisfação/produtividade.
4. Mantenha os humanos responsáveis. A IA deve apoiar os engenheiros, não substituir a responsabilidade da engenharia. O modelo pode sugerir. A equipa tem, ainda assim, de decidir, validar, proteger e assumir a responsabilidade pelo resultado.

Os melhores casos de utilização técnica da IA

Quando é implementada corretamente, a IA nos fluxos de trabalho técnicos pode melhorar significativamente a velocidade, a visibilidade, a produtividade e a qualidade das decisões. Quando é implementada de forma inadequada, pode amplificar defeitos, aumentar o risco operacional e criar uma falsa sensação de confiança à escala.

Eis os casos de utilização e os benefícios que tenho observado:

Maior capacidade de produção de engenharia quando a IA é utilizada no trabalho certo: Os ganhos mais significativos surgem normalmente em tarefas de complexidade baixa a média, como a geração de código padronizado, a criação de casos de teste, a elaboração de documentação e manuais operacionais, a sumarização de registos e a triagem de incidentes, a criação de modelos de infraestrutura como código, a classificação de pedidos e as sugestões de resolução de problemas de primeiro nível. Os resultados quantitativos que tenho observado incluem:

• Redução de 20–40% no tempo de ciclo para tarefas de engenharia repetíveis
• Melhoria de 15–30% na produtividade dos programadores para trabalho bem delimitado
• Triagem de incidentes 25–50% mais rápida quando a IA resume registos, alertas e prováveis causas-raiz
• Redução de 30–60% no esforço de documentação para SOP, procedimentos operacionais e artigos de conhecimento

Maior eficiência em DevOps e nas plataformas: A IA é especialmente eficaz nas operações de DevOps/SRE/infraestruturas quando utilizada como copiloto para análise, e não como decisora autónoma. Por exemplo, a correlação de registos entre ferramentas torna-se mais rápida, os alertas ruidosos são agrupados e resumidos, as notas de implementação e os passos de reversão são gerados automaticamente, os padrões de capacidade são assinalados mais cedo e as verificações operacionais repetitivas são automatizadas. As melhorias quantitativas incluem frequentemente:

• Melhoria de 20–35% no MTTR em ambientes com muitos incidentes
• 10–25% menos escalamentos para engenheiros seniores no caso de padrões de problemas conhecidos
• Melhoria de 15–20% na taxa de sucesso das alterações quando a IA é utilizada para impor listas de verificação de implementação, notas de versão e validação de dependências
• Redução do trabalho rotineiro para as equipas de suporte e operações L1/L2, libertando os engenheiros seniores para tarefas de arquitetura e resiliência

Prem Kumar Partilha

Quando implementada corretamente, a IA nos fluxos de trabalho técnicos pode melhorar significativamente a velocidade, a visibilidade, a produtividade e a qualidade das decisões. Quando implementada de forma inadequada, pode amplificar defeitos, aumentar o risco operacional e criar uma falsa sensação de confiança em grande escala.

Melhoria da engenharia de testes e da cobertura de qualidade: Um dos casos de utilização mais práticos é a realização de testes assistida por IA. Isto inclui gerar casos de teste a partir de requisitos ou histórias de utilizador, identificar cenários de casos-limite, criar padrões de dados de teste e ajudar as equipas a melhorar mais rapidamente a cobertura de regressão. Os resultados positivos podem incluir:

• Criação de casos de teste 20–35% mais rápida
• Maior cobertura de testes no mesmo período da iteração
• Ciclos de preparação de regressão mais curtos
• Melhor deteção de defeitos numa fase mais precoce do ciclo de vida, se as instruções e a validação forem sólidos

Gestão do conhecimento e integração de novos colaboradores mais fortes: A IA é subvalorizada numa área crítica: a captura do conhecimento tácito. Em muitas equipas de engenharia, grande parte do conhecimento operacional reside na mente de algumas pessoas. A IA ajuda a convertê-lo em procedimentos operacionais pesquisáveis, manuais de resolução de problemas, resumos de arquitetura, guias de integração e sínteses de RCA. Os benefícios típicos incluem:

• Integração mais rápida de novos engenheiros
• Menor dependência de algumas pessoas “heroicas”
• Melhor transferência de conhecimento entre equipas
• Menos tempo gasto a pesquisar pedidos antigos e conversas no Slack/Teams

Para PME em crescimento e organizações de engenharia de média dimensão, este pode ser um dos casos de utilização com maior retorno do investimento, porque melhora a escalabilidade do conhecimento de engenharia, e não apenas a produção de código.

As desvantagens da IA

Naturalmente, os resultados não são todos positivos:

• As taxas de defeitos podem aumentar se a IA for colocada em produção demasiado depressa. O maior erro que vemos é tratar o código gerado por IA como “produtividade dos programadores” sem reforçar a revisão, os testes e a validação de segurança.
• O risco de segurança e conformidade aumenta sem mecanismos de proteção. Esta é uma preocupação importante em ambientes regulamentados ou sensíveis.

• As equipas podem tornar-se mais rápidas, mas menos ponderadas. Uma desvantagem subtil é a delegação cognitiva. A IA deve reduzir o esforço mecânico, não reduzir o pensamento de engenharia.
• O tempo de ciclo melhora, mas a qualidade da entrega não. Esta é uma das armadilhas executivas mais comuns: as equipas celebram uma produção de código mais rápida, mas ignoram se o resultado empresarial melhorou. O sucesso da IA não pode ser medido apenas por “a rapidez com que os programadores escrevem código”. Deve ser medido através da frequência de implementação, da taxa de falhas das alterações, da taxa de defeitos que escapam, do MTTR, das conclusões de segurança, do custo por versão e das horas de engenharia poupadas em comparação com o retrabalho criado.

O que a IA nunca deve tocar

Estas são as áreas em que a IA deve apoiar o pensamento, mas nunca substituir o decisor humano responsável.

• Aceitação do risco. Nenhuma IA deve decidir se aceita um risco de segurança, se adia uma correção, se opera com uma lacuna de controlo conhecida ou se prossegue com uma versão que apresenta problemas por resolver. Essa decisão cabe ao líder responsável, porque tem consequências financeiras, jurídicas e reputacionais.
• Liderança em situações de crise. Durante uma grande interrupção, um incidente cibernético, uma violação de dados ou uma escalada regulamentar, a IA pode ajudar com dados e opções. No entanto, os humanos devem assumir a responsabilidade pelas mensagens dirigidas às partes interessadas, pelo contacto com os reguladores, pelas decisões relativas à confiança dos clientes, pela comunicação da liderança e pela orientação da sala de crise.
• Ética, privacidade e compromissos empresariais. A IA não pode ser a autoridade final para decidir se a utilização de dados é eticamente aceitável, se uma decisão é justa para clientes ou colaboradores, se um controlo de vigilância ou monitorização é proporcional ou se a conveniência empresarial deve sobrepor-se aos princípios de confiança. Estas são decisões de liderança.

Porque é que a arquitetura já não diz apenas respeito à escala e ao desempenho

A IA obrigou-me a repensar a ideia de que a arquitetura é algo que se concebe uma vez e se otimiza ao longo do tempo. Esse modelo funcionava quando os sistemas mudavam de forma incremental. Deixa de funcionar quando os agentes de IA, os assistentes de programação, as camadas de automação e os pipelines de dados começam a influenciar dinamicamente o comportamento em produção.

Prem Kumar partilha

A arquitetura já não diz apenas respeito à escala e ao desempenho. Diz agora respeito à adaptabilidade, à rastreabilidade, à resiliência e à governação.

Atualmente, a arquitetura deve ser tratada como um sistema de controlo vivo, e não como um projeto fixo. Isto significa que:

• Os sistemas devem ser concebidos para uma adaptação contínua.
• A observabilidade deve ir além da infraestrutura e abranger o comportamento da IA e a qualidade das decisões.
• A segurança deve passar da defesa do perímetro para a confiança, o controlo e a resiliência integrados.

Por outras palavras, a arquitetura já não diz apenas respeito à escala e ao desempenho. Diz agora respeito à adaptabilidade, à rastreabilidade, à resiliência e à governação.

Conselhos para CTOs

O meu conselho para os CTOs é simples: não encarem a IA apenas como uma corrida tecnológica — encarem-na como um momento de liderança empresarial. Atualmente, demasiadas organizações estão a apostar em projetos-piloto, ferramentas e casos de utilização de IA sem fazerem primeiro as perguntas mais importantes: Que problema empresarial estamos a resolver? Que risco estamos a introduzir? Que capacidade estamos a desenvolver a longo prazo?

Os CTOs devem liderar a mudança impulsionada pela IA em cinco frentes:

1. Comece pelo valor empresarial, não pelo entusiasmo em torno da IA. Se a IA não estiver associada ao crescimento das receitas, à produtividade, à experiência do cliente, à redução dos riscos ou à rapidez de execução, transforma-se em experimentação sem impacto.
2. Construa a IA sobre bases sólidas. A IA não consegue compensar uma infraestrutura fraca, dados fragmentados, uma governação deficiente ou responsabilidades pouco claras. Os CTOs devem primeiro garantir que a organização dispõe da disciplina de dados adequada, preparação para a nuvem, salvaguardas de cibersegurança e uma arquitetura de integração apropriada. Sem isso, a IA aumenta a confusão mais rapidamente do que aumenta o valor.
3. Trate a cibersegurança, a privacidade e a governação como princípios de conceção. Este não é o momento de acrescentar a segurança mais tarde. A IA introduz novos riscos — fuga de dados, utilização indevida dos modelos, enviesamento, alucinações, lacunas de conformidade e utilização não autorizada de IA pelas equipas. Os melhores CTOs integrarão a governação da IA, os controlos de acesso, a proteção de dados, a responsabilização dos modelos e a supervisão humana no modelo operacional desde o primeiro dia.
4. Redefina o papel do líder tecnológico. Nesta era, o CTO já não é apenas o guardião dos sistemas. O CTO tem de se tornar um intérprete entre a ambição empresarial e a realidade técnica — ajudando o conselho de administração e a equipa executiva a compreender o que a IA pode realmente fazer, onde pode falhar e como adotá-la de forma responsável. Isto envolve tanto educação, definição de prioridades e construção de confiança como arquitetura.
5. Concentre-se primeiro no aumento das capacidades, antes da automatização. A estratégia de IA mais sólida não é «Como substituímos as pessoas?». É «Como tornamos as nossas pessoas mais rápidas, perspicazes e eficazes?». A IA deve começar por aumentar as capacidades das equipas — melhorando a tomada de decisões, reduzindo o trabalho repetitivo, acelerando a análise e libertando talento para contributos de maior valor. É aí que se constrói a confiança, melhora a adoção e a transformação se torna sustentável.

Acompanhe

Pode acompanhar o trabalho de Prem no LinkedIn. E pode também ouvir o seu podcast, PREMINENT KONCLAVE.

Seguir-se-ão mais entrevistas com especialistas no The CTO Club!