Diretor de Tecnologia afirma que a IA precisa de um novo modelo de governação

Tyrone Grandison ocupou vários cargos de nível executivo ao longo da sua carreira de 35 anos na área da tecnologia e é atualmente CTO da Cornerstone Assurance Corporation. É também o autor de A Revolução da IA e Uma Cultura que Perdura.

Falámos com Tyrone para saber como a IA está a transformar a governação nas organizações tecnológicas. Eis o que nos disse.

35 anos na área da tecnologia

Lidero uma organização tecnológica enxuta que apoia uma empresa em crescimento nos setores dos seguros e dos serviços financeiros, chamada Cornerstone Assurance Corporation. O que torna esta função particularmente interessante é o facto de estarmos a construir uma arquitetura tecnológica moderna, enquanto operamos num setor com requisitos regulamentares significativos, dados financeiros sensíveis, integrações complexas com seguradoras e uma tolerância muito reduzida para erros.

Comecei a minha carreira como cientista informático, muito antes de a IA se tornar o tema de todas as conversas nas salas de administração e das palestras principais das conferências. Ao longo dos anos, o meu trabalho levou-me da construção de tecnologia à liderança de organizações perante o impacto da tecnologia sobre elas. Exerci funções de Diretor de Inteligência Artificial, Diretor de Tecnologia, Diretor de Informação e Diretor-adjunto de Dados. Trabalhei em áreas como a administração pública, o meio académico, empresas emergentes, consultoria, organizações sem fins lucrativos e grandes empresas.

Após 35 anos na área da tecnologia, tive o privilégio de assistir à introdução de várias coisas apresentadas como “a tecnologia que vai mudar tudo”. E algumas delas mudaram mesmo.

Cada grande mudança obriga os líderes a tomar decisões antes de disporem de informação perfeita. Põe à prova os modelos de negócio, os modelos operacionais, a cultura, o talento, a governação e, por vezes, a nossa compreensão do que os nossos próprios empregos devem ser. A IA está a fazer tudo isso ao mesmo tempo.

Mas o que torna este momento particularmente fascinante para mim é o facto de termos ultrapassado a fase em que a IA se limitava a ajudar-nos a analisar informação. Temos agora sistemas capazes de gerar, raciocinar, planear, criar, escrever código, utilizar ferramentas e, cada vez mais, agir. Isso transforma fundamentalmente a conversa sobre liderança.

A pergunta costumava ser: “O que pode a IA fazer?”

Creio que esta está rapidamente a tornar-se a pergunta menos interessante. Talvez até a pergunta errada.

As perguntas muito mais importantes são: O que devemos permitir que faça? Onde continua o julgamento humano a ser essencial? Como devemos redesenhar as organizações quando a informação útil se torna abundante? E como podemos aproveitar o extraordinário potencial desta tecnologia sem criar riscos que não compreendemos ou sistemas que não conseguimos governar?

É aí que se centra atualmente o meu trabalho. Trabalho com executivos e organizações para os ajudar a separar o sinal da considerável quantidade de ruído que rodeia a IA, compreender o que está realmente a mudar e transformar essa compreensão em estratégia, governação, produtos e resultados empresariais mensuráveis.

Como a IA transforma os ciclos de vida do desenvolvimento de software

Uma das maiores mudanças que implementei na Cornerstone Assurance Corporation foi redesenhar o nosso ciclo de vida do desenvolvimento de software partindo do princípio de que a IA irá escrever uma percentagem significativa do nosso código.

Antes dessa mudança, seguíamos um fluxo de trabalho de engenharia relativamente tradicional. Um programador recebia um requisito, concebia a solução, escrevia o código, criava testes, submetia um pedido de integração e outro engenheiro fazia a revisão. Utilizávamos automatização, naturalmente, mas os seres humanos continuavam a realizar a maior parte do trabalho cognitivo, desde o requisito até à implementação.

A IA alterou completamente a economia desse modelo.

Assim, introduzimos um processo de desenvolvimento assistido por IA que utiliza o GitHub Copilot para a geração e refatorização de código, o ChatGPT e o Claude para a exploração arquitetural orientada por IA, a decomposição de requisitos, a depuração e a geração de casos de teste, com as nossas ferramentas habituais de CI/CD e de segurança a fornecerem os controlos determinísticos em torno do trabalho gerado pela IA.

Porque é que o código gerado por IA exige um novo modelo de governação

Mas a mudança importante não foi: “Muito bem, agora todos têm o Copilot.” Alterámos o modelo de governação.

Etapas de aprovação

Agora tratamos o código gerado por IA quase como código submetido por um engenheiro júnior muito rápido, que nunca dorme, leu uma quantidade absurda de documentação e, ocasionalmente, diz algo completamente errado com uma confiança tremenda.

Isso significa que a IA pode gerar código, testes unitários, contratos de API, documentação, consultas à base de dados, definições de infraestrutura e correções propostas, mas não pode aprovar o seu próprio trabalho nem ter um percurso não controlado até à produção.

Introduzimos pontos de aprovação humana explícitos para alterações sensíveis do ponto de vista da segurança, autenticação e autorização, tratamento de dados de clientes e financeiros, integrações externas e infraestrutura de produção.

Testes automatizados

Também expandimos os testes automatizados e a revisão de código porque o estrangulamento mudou de lugar. Quando a IA aumenta drasticamente a rapidez com que se pode produzir código, o problema deixa de ser a geração de código. O problema passa a ser provar que o código merece ser executado.

Um exemplo simples é a criação de testes. Anteriormente, um engenheiro podia implementar uma funcionalidade e depois escrever os testes unitários óbvios. Agora também podemos pedir à IA para gerar casos de teste adversariais. O que acontece com uma entrada malformada? O que acontece quando uma API devolve uma resposta inesperada? O que acontece num limite de permissões? O que acontece quando um registo de cliente contém dados incompletos?

Isso dá ao engenheiro humano uma função diferente. Em vez de passar todo o seu tempo a produzir artefactos, passa mais tempo a questionar pressupostos e a validar o comportamento do código.

Governação da IA

Também alterámos a forma como governamos a própria IA. Registamos a atividade assistida por IA quando apropriado, mantemos as informações sensíveis dos clientes fora das ferramentas de IA para consumidores, controlamos quais os modelos e serviços que podem aceder aos dados empresariais e separamos a experimentação do acesso à produção. No setor dos seguros e dos serviços financeiros, “o modelo achou que era uma boa ideia” nunca constituirá uma estratégia de governação.

Como a IA desloca o estrangulamento da engenharia

O maior resultado que observei ao integrar a IA nos nossos fluxos de trabalho de engenharia é a velocidade, mas acrescento sempre uma ressalva a essa resposta, porque a velocidade na direção errada não é produtividade.

A IA encurtou drasticamente o nosso ciclo de desenvolvimento. Estamos a ver trabalhos que anteriormente demoravam vários dias a um programador passar do requisito para uma implementação testável em poucas horas. No que diz respeito especificamente à prototipagem, calculo que tenhamos reduzido o tempo do ciclo entre 50 e 70 por cento, aproximadamente.

E a documentação terá provavelmente produzido o ganho de eficiência menos glamoroso, mas mais imediato. A documentação de APIs, as notas de versão, a documentação de testes, as explicações do código e os primeiros rascunhos das especificações técnicas já não precisam de começar com um cursor intermitente. A IA produz os primeiros 70 ou 80 por cento, e a minha equipa passa o seu tempo a corrigir e melhorar, em vez de criar tudo de raiz.

Mas há uma desvantagem, e penso que os líderes tecnológicos precisam de falar mais sobre isto: a IA torna incrivelmente barato produzir rapidamente código de má qualidade.

Descobrimos que o fator limitador se desloca para as fases seguintes. Se consigo gerar cinco vezes mais código, mas os humanos continuam a ter de o compreender, rever, testar, proteger, implementar, monitorizar e manter, não aumentei necessariamente o débito do sistema. Posso simplesmente ter criado um engarrafamento na revisão de código.

Essa foi provavelmente a lição mais valiosa para mim. Já não otimizo a minha organização de engenharia principalmente em função da rapidez com que conseguimos escrever software. A IA está a transformar rapidamente essa parte numa mercadoria. Otimizo em função da rapidez com que conseguimos provar que o software merece ser executado em produção. Essa é uma organização de engenharia muito diferente.

Onde a IA pode dar a sua opinião e onde pode votar

Tenho sido bastante deliberado quanto a separar duas coisas: onde a IA tem voz e onde a IA tem voto. Na nossa organização, a IA tem agora voz em quase todas as fases do nosso ciclo de vida tecnológico. Não tem voto em todas as decisões.

Alguns exemplos:

• Arquitetura: Utilizamos o ChatGPT e o Claude como parceiros de discussão arquitetural. Se estivermos a conceber um novo serviço, posso fornecer ao modelo os nossos requisitos, restrições, interfaces existentes, limites de segurança, volume de transações esperado e cenários de falha. Peço-lhe que proponha várias arquiteturas, identifique compromissos, questione os nossos pressupostos e até argumente contra a sua própria recomendação. O que não faço é perguntar: “Que arquitetura devemos utilizar?” e depois construir aquilo que for apresentado. A decisão final sobre a arquitetura continua a ser humana, porque a arquitetura envolve um contexto que vai muito além da otimização técnica. Tenho de considerar a nossa estratégia empresarial, obrigações regulamentares, maturidade operacional, tolerância ao risco, custos, dívida técnica e aquilo que a minha equipa consegue realmente suportar às 2:00 da manhã.
• Código: Aqui damos à IA consideravelmente mais margem de manobra. Utilizamos o GitHub Copilot para gerar código, fazer refatorações, criar documentação e criar testes unitários. Também utilizamos o ChatGPT e o Claude para diagnosticar defeitos, explorar abordagens de implementação e gerar casos de teste adversariais. A IA consegue escrever uma primeira implementação de forma incrivelmente rápida. Um engenheiro humano continua a ser responsável pelo pedido de integração e aprova aquilo que acaba por ser integrado.
• Testes: Esta é provavelmente a área que mais se aproximou da IA. Gosto de utilizar a IA para perguntar: “Como quebrarias isto?” Conseguimos encontrar casos que um programador que acabou de passar dois dias a desenvolver a funcionalidade poderia inconscientemente não detetar. A IA torna-se um adversário muito económico e extremamente persistente.
• Segurança: É aqui que inverto deliberadamente a equação. A IA ajuda-nos a identificar vulnerabilidades, inspecionar padrões de código, modelar ameaças e gerar cenários de ataque, mas, como referi, os humanos mantêm a autoridade sobre a aceitação de segurança, as decisões relativas a identidade e acesso, o tratamento de dados sensíveis e as exceções. A injeção de instruções e a divulgação de informações sensíveis continuam a ser riscos reconhecidos nas aplicações de LLM, pelo que ligar a IA a sistemas empresariais exige mais controlos, não menos.
• Resposta a incidentes: Esta área situa-se algures no meio. A IA pode ingerir registos, correlacionar eventos, resumir milhares de linhas de telemetria, propor causas-raiz prováveis e recomendar medidas de remediação. Isso pode reduzir drasticamente os primeiros 30 minutos de um incidente. Mas se alguém quiser desativar um serviço de produção, reverter uma implementação crítica, alterar uma política de segurança ou tomar uma medida que afete os clientes, essa decisão é tomada por um humano.
• Priorização do backlog: Utilizo aqui a mesma regra. A IA pode analisar problemas de suporte, esforço de engenharia, dependências, utilização do produto e objetivos empresariais e dizer: “Eis como eu priorizaria estas 40 coisas e eis a razão.” Isso é extremamente útil. Mas a IA não compreende a nossa estratégia melhor do que nós. Os responsáveis pelo produto e pela tecnologia tomam a decisão final de priorização.

Por isso, a minha regra é bastante simples: a IA obtém mais autonomia quando a ação é reversível, observável, testável e tem consequências reduzidas. A autoridade humana aumenta à medida que uma ação se torna mais difícil de reverter ou acarreta um impacto maior para os clientes, financeiro, de segurança, regulamentar ou reputacional.

Um fluxo de trabalho de engenharia do mundo real

Eis um exemplo de um fluxo de trabalho de “requisito até à produção com a IA no circuito”. Suponhamos que precisamos de adicionar uma nova capacidade a um fluxo de trabalho de agentes que obtém informações de clientes e de apólices, aplica um conjunto de regras empresariais e recomenda a ação seguinte adequada:

1. Tudo começa com o requisito. Em vez de um engenheiro receber um pedido escrito de forma vaga e começar imediatamente a programar, usamos o ChatGPT ou o Claude para questionar o requisito. Fornecemos a história de utilizador, os critérios de aceitação, as regras de negócio relevantes, os contratos da API e as restrições técnicas. Depois, pedimos-lhe que identifique ambiguidades, casos-limite em falta, dependências, preocupações de segurança e questões às quais devemos responder antes de alguém escrever código. Parece simples, mas permite detetar logo no início uma quantidade surpreendente de confusão dispendiosa.
2. Em seguida, passamos à arquitetura e à decomposição das tarefas. Usamos o Claude e o ChatGPT para explorar opções de implementação e dividir os requisitos em componentes. O modelo pode identificar uma alteração à API, uma alteração ao modelo de dados, uma dependência de integração, requisitos de autorização, telemetria e os casos de teste necessários. Também lhe pedimos que argumente contra a arquitetura que propôs. Um engenheiro humano toma a decisão arquitetural. A IA fornece opções. Somos nós que assumimos as consequências.
3. Depois, avançamos para a implementação. Usamos o GitHub Copilot dentro do ambiente de desenvolvimento para gerar código predefinido, implementar funções bem definidas, refatorizar código, criar clientes de API, explicar secções desconhecidas da base de código e gerar documentação. O engenheiro deixa de escrever cada linha e passa a orientar, rever e aperfeiçoar a implementação. Essa distinção é importante. Não quero que os programadores se transformem em operadores de preenchimento automático extremamente dispendiosos. Quero que pensem no sistema.
4. Depois, fornecemos ao ChatGPT ou ao Claude o requisito e a implementação e dizemos-lhe, essencialmente: “Ótimo. Agora destrói isso.” A IA ajuda a gerar cenários adversariais, e o Copilot ajuda a transformá-los em testes unitários e de integração automatizados.
5. Depois, a maquinaria determinística assume o controlo. O pedido de integração entra no nosso processo de CI/CD. Executamos testes automatizados, análise estática, análise de dependências e vulnerabilidades e os nossos controlos de qualidade habituais. Um engenheiro humano revê o pedido de integração.
6. Depois, fazemos a implementação de forma incremental. A alteração passa pelo desenvolvimento e pela preparação antes de chegar à produção. Quando apropriado, usamos sinalizadores de funcionalidades ou padrões de lançamento controlado para limitar a exposição, observar o comportamento e reverter rapidamente.
7. E o trabalho da IA também ainda não terminou. Assim que a funcionalidade está em execução, a IA torna-se um assistente de observabilidade. Usamo-la para resumir registos, correlacionar padrões de erro, analisar comportamentos inesperados e ajudar os engenheiros a passar de “há algo de errado” para uma causa-raiz plausível muito mais rapidamente.

Como mudar o comportamento da engenharia com a IA

Gostaria de ter percebido mais cedo que dar ferramentas de IA aos engenheiros é fácil. Mudar o comportamento da engenharia é a parte difícil.

Quando começámos a utilizar ferramentas como o GitHub Copilot, o ChatGPT e o Claude, abordei a implementação da forma como muitos líderes tecnológicos o fazem. Dar ferramentas poderosas a engenheiros talentosos, estabelecer algumas salvaguardas sensatas e esperar que a produtividade aumente.

A produtividade aumentou, mas não de forma uniforme nem sempre das formas que eu esperava.

A primeira coisa que aprendi foi que o acesso não é igual à adoção, e a adoção não é igual à proficiência.

Dois engenheiros podem ter exatamente a mesma ferramenta de IA e obter resultados radicalmente diferentes. Um trata a IA como preenchimento automático e poupa algumas teclas. Outro aprende a fornecer contexto, a decompor problemas, a questionar os resultados, a gerar testes, a explorar alternativas e a utilizar o modelo como parceiro de debate técnico. A diferença de produtividade entre essas duas pessoas pode tornar-se enorme.

Eu teria investido muito mais cedo na literacia em IA e nos padrões de trabalho. Não “aqui está uma aula de duas horas sobre engenharia de instruções”, mas exemplos práticos baseados no nosso trabalho de engenharia real.

Comentários de Tyrone

Eu teria investido muito mais cedo na literacia em IA e nos padrões de trabalho. Não “aqui está uma aula de duas horas sobre engenharia de instruções”, mas exemplos práticos baseados no nosso trabalho de engenharia real.

Como a IA está a transformar a liderança tecnológica

Passamos muito tempo a perguntar o que a IA fará aos programadores, arquitetos, analistas e a outras funções técnicas. Penso que os CTO têm de inverter essa questão e aplicá-la a nós próprios.

Durante a maior parte da minha carreira, a liderança tecnológica era valorizada por saber coisas que os outros não sabiam. A experiência proporcionava reconhecimento de padrões. A competência técnica conferia autoridade. Podia entrar numa sala e dar uma resposta que poderia ter levado outra pessoa dias a encontrar.

Agora, posso colocar um sistema de IA incrivelmente capaz nas mãos de todos. Isso muda a liderança.

Já não penso que o meu valor enquanto CTO advém de ter as respostas. Advém de fazer perguntas melhores, fornecer contexto, avaliar compromissos, exercer discernimento e criar um ambiente onde os seres humanos e as máquinas se tornam melhores uns com os outros.

Isso exige humildade. Por vezes, a IA identificará uma abordagem que eu não considerei. Um engenheiro júnior com excelentes competências de IA poderá contestar uma suposição que alguém com 25 anos de experiência considera óbvia. Penso que os grandes líderes tecnológicos têm de acolher isso.

O CTO da era da IA não pode ser simplesmente a pessoa tecnicamente mais inteligente da sala. Temos de nos tornar nas pessoas que concebem a sala. Quem tem direito a falar? O que é que a IA pode decidir? Onde é que o discernimento humano continua a ser essencial? Como sabemos quando estamos errados?

Essa é a transformação da liderança.

Porque devem os CTO ter cautela com os ganhos de eficiência

O meu principal conselho para os CTO neste momento é este: não confundam avançar depressa com fazer progressos.

Existe uma enorme pressão sobre os líderes tecnológicos para “fazer alguma coisa com a IA”. Os conselhos de administração perguntam por ela. Os CEO perguntam por ela. Os funcionários já a estão a utilizar, tenha ou não uma política definida. De repente, todos os fornecedores descobriram que o seu produto sempre foi “alimentado por IA”.

É muito fácil tornar-se reativo. Mas penso que o trabalho do CTO neste momento é criar clareza no meio desse ruído.

• Primeiro, use a tecnologia. E refiro-me a utilizá-la realmente. Não construa a sua estratégia de IA inteiramente com base em relatórios de analistas e demonstrações de fornecedores. Utilizo ferramentas como o ChatGPT, o Claude e o GitHub Copilot porque preciso de experiência em primeira mão sobre aquilo em que são extraordinárias, onde falham e a rapidez com que esses limites estão a mudar. Não é possível liderar eficazmente uma transição tecnológica que se experiencia apenas através do PowerPoint.
• Em segundo lugar, comece pelas restrições do negócio, não pelas capacidades da IA. Estou muito menos interessado em perguntar “Onde podemos utilizar IA generativa?” do que em perguntar “Onde somos lentos, dispendiosos, inconsistentes, temos limitações de capacidade ou estamos a deixar os clientes frustrados?” Depois, posso determinar se a IA faz realmente parte da solução.
• Em terceiro lugar, corrija os seus fundamentos. A IA não irá salvar dados de má qualidade, APIs frágeis, observabilidade deficiente, documentação inexistente ou práticas de engenharia disfuncionais. Muitas vezes, irá amplificá-los. A IA funciona como um amplificador da organização e do sistema técnico subjacentes.
• Em quarto lugar, conceba a governação em torno das consequências, não do medo. Não quero uma política de IA com 47 páginas que diga efetivamente “Por favor, não façam nada interessante”. Quero controlos proporcionais ao risco. Permita que as pessoas experimentem de forma ambiciosa quando as ações são reversíveis e têm poucas consequências. Aumente a supervisão humana à medida que as decisões começam a afetar dados dos clientes, dinheiro, segurança, obrigações regulamentares ou sistemas de produção.
• Em quinto lugar, e esta poderá ser a mais importante, reformule o trabalho em vez de simplesmente adicionar IA ao trabalho. Se o meu processo de desenvolvimento tem doze etapas e a IA torna a quarta 70 por cento mais rápida, não transformei a engenharia. Acelerei a quarta etapa.
• E por fim, proteja o discernimento humano enquanto elimina agressivamente o trabalho enfadonho das pessoas.

Penso que os CTO têm agora uma oportunidade rara. Não perguntem apenas de que forma a IA torna a vossa organização atual mais eficiente. Perguntem que organização construiriam se estivessem a começar hoje. Essa é a questão mais desconfortável. É também aquela que distinguirá as empresas que simplesmente utilizam a IA das empresas que se transformam verdadeiramente por causa dela.

Acompanhe

Pode acompanhar o trabalho de Tyrone Grandison no LinkedIn e no seu site pessoal. Pode também consultar os seus livros, A Revolução da IA e Cultura que Perdura.

Haverá mais entrevistas com especialistas no Clube dos CTO!