A governação da IA não pode ser uma reflexão tardia

Abhishek Ranjan é o CTO da Apna e da Blue Machines, onde está profundamente envolvido na transformação tanto da força de trabalho humana como da força de trabalho de IA.

Sentámo-nos com ele para discutir a governação nos fluxos de trabalho de IA. Eis o que nos disse.

Tecnologia lado a lado com as pessoas

Chamo-me Abhishek Ranjan. Sou o CTO da Apna e da Blue Machines. Duas realidades muito ligadas, mas diferentes, moldaram o meu percurso até este momento de transformação impulsionada pela IA.

Na Apna, desenvolvemos soluções para a força de trabalho humana. A Apna é uma das empresas unicórnio de crescimento mais rápido da Índia, com mais de 60 milhões de utilizadores na plataforma. A essa escala, observamos muito de perto a força de trabalho indiana. Vemos milhões de pessoas à procura de melhores oportunidades, empregadores a tentar contratar mais rapidamente, diferentes línguas, diferentes níveis de competências e níveis variados de acesso e confiança digitais.

Na Blue Machines, desenvolvemos soluções para a força de trabalho de IA. Concentramos-nos na IA de voz empresarial, processando milhões de minutos todos os dias. Desenvolvemos mais do que simples robôs que respondem a perguntas. Desenvolvemos trabalhadores de IA capazes de falar com os clientes, compreender o contexto, receber feedback, melhorar ao longo do tempo e executar fluxos de trabalho empresariais reais.

Vi a tecnologia ajudar as pessoas a encontrar emprego, a crescer e a participar na economia. E agora vejo a própria IA a tornar-se um novo tipo de força de trabalho, capaz de trabalhar lado a lado com as pessoas.

Por isso, para mim, este momento não diz apenas respeito à utilização da IA para aumentar a produtividade ou escrever código mais rapidamente. Diz respeito a reimaginar a forma como as empresas funcionam e como o trabalho é realizado.

A arquitetura de duas empresas muito diferentes

A arquitetura da Apna foi concebida como a de uma grande plataforma de mercado. Temos sistemas para consumidores, sistemas para empregadores, plataformas de dados, sistemas de IA e correspondência, pesquisa, comunicação, camadas de prevenção de fraude e de confiança e, agora, capacidades de recrutamento com IA e de preparação para entrevistas com IA. O modelo de implementação assenta prioritariamente na nuvem, é altamente escalável e foi concebido para garantir uma elevada disponibilidade, porque milhões de utilizadores e milhares de empresas utilizam a plataforma.

A organização de engenharia tem mais de 100 pessoas, que trabalham nas equipas de engenharia de produto, back-end, front-end, dispositivos móveis, dados, IA, infraestrutura, segurança e plataforma. O nosso foco não está apenas na criação de funcionalidades, mas também na criação de sistemas fiáveis capazes de funcionar a uma escala enorme.

A Blue Machines é uma organização tecnológica de um tipo diferente. Está concentrada na IA de voz empresarial e nos fluxos de trabalho agênticos. Estamos a desenvolver trabalhadores de IA capazes de falar, raciocinar, executar ações, integrar-se com sistemas empresariais e melhorar através do feedback. Atualmente, já operamos a uma escala significativa, com milhões de minutos de IA de voz processados todos os dias.

A arquitetura da Blue Machines é mais orientada para o tempo real e nativa de IA. Inclui infraestrutura de voz, telefonia, conversão de voz em texto, raciocínio de LLM, conversão de texto em voz, orquestração de fluxos de trabalho, integrações, análise, observabilidade e sistemas de avaliação. A complexidade do produto é elevada porque a IA de voz empresarial tem de funcionar em produção, em conversas reais, com baixa latência, elevada precisão, salvaguardas de conformidade e resultados empresariais claros.

Na Blue Machines, uma equipa principal de quatro engenheiros criou uma plataforma distribuída de orquestração de voz em apenas algumas semanas. Temos também uma equipa de investigação muito experiente, que trabalha profundamente em IA de voz, avaliação de agentes, raciocínio, latência, sistemas multilingues e melhoria contínua dos agentes. Essa profundidade de investigação é importante porque a IA de voz empresarial não pode ser resolvida apenas ligando modelos entre si. Exige uma engenharia de produto sólida, uma engenharia de sistemas sólida e uma investigação aplicada em IA igualmente sólida.

De um modo geral, a organização tecnológica que lidero situa-se na interseção entre plataformas de grande escala e sistemas nativos de IA.

Como uma IA bem governada melhora o ciclo de vida do software

Ao longo do último ano, a IA mudou a forma como desenvolvemos, testamos e lançamos tecnologia.

Anteriormente, o nosso processo de lançamento era mais tradicional. Os engenheiros desenvolviam funcionalidades, criavam PRs, passavam por revisões pelos pares, executavam casos de teste e, depois, disponibilizavam-nas através do processo habitual de implementação. Funcionava, mas a velocidade dependia dos ciclos de revisão humana, do controlo de qualidade manual e da confiança da equipa no lançamento.

À medida que a programação assistida por IA se tornou uma parte mais relevante da engenharia, adotámo-la — e rapidamente percebemos que as melhorias de velocidade, por si só, não eram suficientes. A IA pode ajudar os engenheiros a escrever código mais rapidamente, mas, se a governação não melhorar, também pode criar mais erros ocultos, casos-limite não detetados ou abstrações inadequadas.

Por isso, alterámos o modelo operacional.

1. Adicionámos uma camada de revisão de PRs assistida por IA. Cada PR era submetido a verificações de lógica de risco, casos-limite em falta, quebras de contratos de API, problemas de segurança, riscos de migração e cobertura de testes insuficiente antes da revisão humana. Isto reduziu as falhas mais evidentes antes da revisão.
2. Reforçámos os controlos do CI. Uma alteração não podia avançar apenas porque o código parecia estar correto. Tinha de passar testes unitários, testes de integração, análise de estilo, verificações de segurança, testes de contratos de API e conjuntos de testes de regressão para a área de produto afetada.
3. Criámos conjuntos de testes de regressão mais robustos para fluxos de trabalho críticos. Por exemplo, adicionando casos de teste para cenários de utilizadores reais, casos-limite, comportamento multilingue, tratamento de falhas e resultados empresariais.
4. Alterámos a governação das instruções. Falarei mais sobre isso dentro de momentos.
5. Tornámos obrigatórios os lançamentos canário para áreas de alto risco. Em vez de lançar para todos, lançamos para uma pequena percentagem do tráfego, monitorizamos erros, latência, conversão, desistências, qualidade do agente e impacto nos clientes e, depois, promovemos ou revertemos a alteração.
6. Adicionámos uma observabilidade melhor. Quando algo falhava, queríamos saber exatamente que versão do código, versão da instrução, modelo, fluxo de trabalho ou dependência tinha causado o problema.

O impacto tem sido muito visível. A velocidade dos nossos lançamentos aumentou significativamente. As equipas que anteriormente faziam lançamentos maiores e agrupados passaram a fazer lançamentos mais pequenos e frequentes. Em algumas áreas, a frequência de lançamento aumentou quase 2 a 3 vezes, porque as verificações estão mais automatizadas e a confiança é maior. E foi assim que uma equipa de quatro pessoas construiu uma plataforma distribuída e complexa numa questão de semanas.

O número de problemas em produção também diminuiu, porque cada lançamento é mais pequeno, melhor testado e mais fácil de reverter. Observamos uma redução significativa dos erros em produção, especialmente nas áreas em que os testes de regressão automatizados e os lançamentos canário são agora obrigatórios. Atualmente, os defeitos estão quase 40% abaixo da linha de base original.

A IA, por si só, proporciona velocidade. A IA com governação proporciona velocidade e qualidade.

Porque devemos tratar as instruções como código

Abhishek partilha

Para os sistemas de IA, também começámos a tratar as instruções como código… Esta foi uma melhoria importante. Sabemos que instrução estava ativa, o que mudou, o que melhorou e se os resultados para os clientes melhoraram.

Para os sistemas de IA, também começámos a tratar as instruções como código.

Agora, criamos versões, revemos, testamos, promovemos as instruções entre ambientes e implementamo-las por fases. As instruções já não são tratadas como pequenas atualizações de configuração. São submetidas a conversas de teste, casos-limite, verificações multilingues, verificações de latência, verificações de conformidade e verificações dos resultados empresariais.

Podemos lançar primeiro uma nova instrução ou fluxo de trabalho de um agente para uma pequena percentagem do tráfego, observar os resultados e, depois, promovê-la se as métricas forem melhores.

Esta foi uma melhoria importante. Anteriormente, era difícil saber se uma alteração numa instrução tinha melhorado o agente ou apenas alterado o seu comportamento. Agora, podemos comparar versões de forma mais objetiva. Sabemos que instrução estava ativa, o que mudou, o que melhorou e se os resultados para os clientes melhoraram.

A maior mudança foi o facto de todo o sistema tecnológico se ter tornado mais automatizado, mensurável e sujeito a governação.

Um fluxo de trabalho de lançamento de engenharia com agentes

Utilizamos um fluxo de trabalho de lançamento de engenharia com agentes, com intervenção humana em pontos-chave.

Este fluxo de trabalho não é adequado para todos os lançamentos. Para alterações muito complexas na plataforma, alterações profundas à arquitetura ou sistemas sensíveis, continuamos a utilizar um processo mais tradicional, conduzido por pessoas. No entanto, para algumas áreas de produto, especialmente os fluxos de trabalho que evoluem mais rapidamente, tornou-se a forma padrão de desenvolvimento.

Eis o fluxo de trabalho:

1. O processo começa quando chega um requisito de produto ou um problema de engenharia. Um agente de planeamento de IA lê o requisito, divide-o em tarefas, identifica dependências, assinala áreas de risco e sugere um plano de implementação. O engenheiro revê o plano, corrige pressupostos e decide a abordagem final.
2. Em seguida, um agente de programação gera código, refatora módulos, escreve código padrão e cria testes unitários e de integração. Um agente de revisão verifica o pedido de extração para identificar lógica arriscada, casos-limite em falta, problemas de segurança, quebras de contratos de API e lacunas nos testes.
3. Depois, um agente de testes cria cenários de regressão e valida casos-limite. Nos fluxos de trabalho de IA, também executa avaliações de prompts, testes de conversação, verificações multilingues, verificações de latência e verificações dos resultados empresariais.
4. O agente de lançamento recomenda então se a alteração é segura para uma implementação canário, com base nos resultados dos testes, na área de impacto, em falhas anteriores e no grau de preparação da observabilidade. No entanto, os humanos continuam a aprovar promoções críticas, sobretudo quando a alteração afeta as receitas, a experiência do cliente, a segurança ou a infraestrutura principal.
5. Depois de lançada, o agente de monitorização procura erros, latência, conversões, abandonos, qualidade dos agentes e impacto nos clientes. Se algo parecer estar errado, recomenda uma reversão, abre um incidente, resume os registos e cria um primeiro rascunho da análise da causa-raiz.

Este fluxo de trabalho é agentivo, mas não é cegamente autónomo. Os agentes de IA planeiam, programam, reveem, testam, lançam, monitorizam e resumem. Os humanos aprovam, questionam, definem prioridades e assumem a decisão final.

Onde o Claude Code e o Cursor se destacam

As minhas ferramentas favoritas são o Claude Code e o Cursor, dependendo do fluxo de trabalho.

O Cursor destaca-se quando os engenheiros querem a IA profundamente integrada no seu IDE para a programação diária, a refatoração, a compreensão da base de código e uma implementação mais rápida.

O Claude Code revela-se extremamente útil para tarefas mais agentivas: compreender bases de código maiores, fazer alterações em vários ficheiros, gerar testes, corrigir problemas e iterar como um parceiro de engenharia.

Porque é que a IA proporciona alavancagem enquanto os humanos fornecem discernimento

Atualmente, dependemos fortemente da IA para tudo o que melhora a velocidade, a cobertura ou a consistência, mas não para tarefas que exigem discernimento, responsabilidade ou compromissos a longo prazo.

Por exemplo, a IA ajuda-nos agora na revisão de código, na geração de casos de teste, na cobertura de regressões, na documentação, na depuração, na análise de registos e até na triagem de incidentes. Consegue identificar rapidamente caminhos de código arriscados, casos-limite em falta, possíveis problemas de segurança ou padrões em falhas de produção. Nos sistemas de IA, também nos ajuda a comparar versões de prompts, avaliar conversas e compreender onde um agente está a falhar.

Mas as decisões finais continuam a ser humanas. Eis alguns exemplos:

• As decisões de arquitetura devem continuar a ser humanas, porque envolvem compromissos relacionados com a escala, o custo, a fiabilidade, as capacidades da equipa e a direção do produto a longo prazo.
• A análise da causa-raiz de ponta a ponta pode ser apoiada pela IA, mas os humanos continuam a ter de ligar os pontos, validar a hipótese e decidir a correção.
• A definição de prioridades do backlog continua a ser humana, porque exige conhecimento do cliente, estratégia empresarial e discernimento sobre o que realmente importa.
• As revisões de segurança utilizam IA, mas é necessário discernimento especializado. A IA pode assinalar problemas, mas também pode gerar falsos positivos ou não detetar riscos relacionados com o contexto empresarial. Os humanos mantêm a responsabilidade, porque o risco e a responsabilização são demasiado elevados.

Exemplos reais de falhas da IA no discernimento técnico

Eis alguns exemplos da importância do discernimento humano.

O primeiro envolveu picos de latência ao nível dos milissegundos no nosso fluxo de voz. A IA comentou corretamente o problema e identificou que a latência num dos caminhos poderia tornar-se problemática. Mas o código que sugeriu estava errado. Parecia limpo, mas teria criado um gargalo diferente sob carga. Um engenheiro humano interveio, compreendeu o comportamento em tempo de execução e resolveu-o corretamente.

Outro exemplo surgiu durante a triagem em produção. Vários sistemas a jusante estavam a falhar e a IA continuava a analisar esses sistemas de forma independente, sugerindo otimizações. Mas nós já sabíamos que o verdadeiro problema era uma dependência a montante que tinha falhado primeiro. A IA estava a confundir falhas visíveis com a causa raiz.

É aqui que a IA ainda enfrenta dificuldades. Consegue ler registos, resumir rastreios, sugerir correções e acelerar a depuração. Mas, em sistemas distribuídos complexos, pode não detetar a causalidade, o timing e o contexto ao nível do sistema.

Porque estão as equipas a tornar-se mais pequenas e mais abrangentes

A IA alterou mais o perfil de contratação do que o organograma.

Anteriormente, contratávamos tendo em vista uma especialização funcional mais restrita: backend, frontend, QA, DevOps, dados, etc. Essas competências continuam a ser importantes, mas agora valorizo engenheiros que consigam trabalhar em toda a pilha tecnológica, utilizar a IA profundamente e passar do problema à produção com muito menos orientação.

Atualmente, os melhores engenheiros não se limitam a escrever código. Concebem fluxos de trabalho, utilizam a IA para a implementação, geram testes, analisam resultados, depuram mais rapidamente e preocupam-se com a qualidade das versões.

Por isso, o nível de exigência na contratação passou a privilegiar engenheiros com elevado sentido de responsabilidade e capacidade de decisão. Pessoas que conseguem colocar as perguntas certas, verificar os resultados da IA, compreender profundamente os sistemas e disponibilizar trabalho de forma autónoma.

Também reduziu a necessidade de equipas grandes em algumas áreas. Atualmente, uma equipa mais pequena, com uma forte alavancagem da IA, consegue realizar trabalho que anteriormente exigia muito mais pessoas.

Porque é que a IA torna mais difícil formar engenheiros em início de carreira

Abhishek Partilha

Não penso que proibir a IA ou obrigar as pessoas a programar como se estivéssemos em 2010 seja a resposta. Isso seria errado. Mas também não penso que tenhamos resolvido completamente a forma de desenvolver uma capacidade de decisão técnica profunda quando a IA faz grande parte do trabalho inicial. Por enquanto, a minha melhor resposta é tornar visível a compreensão.

Como formamos engenheiros em início de carreira na era da IA? Ainda não tenho uma resposta perfeita.

Quando começámos, os IDE ajudaram-nos. Depois, o Google ajudou-nos. Em seguida, o Stack Overflow ajudou-nos. Mas, em todas essas fases, ainda tínhamos de enfrentar o problema. Tínhamos de compreender a resposta, adaptá-la, depurá-la e aprender porque funcionava.

Com a IA e a programação por descrição, podemos evitar essa dificuldade. Um engenheiro em início de carreira pode gerar código funcional sem compreender verdadeiramente o sistema, as contrapartidas ou os modos de falha. Isso preocupa-me.

Não penso que proibir a IA ou obrigar as pessoas a programar como se estivéssemos em 2010 seja a resposta. Isso seria errado. Mas também não penso que tenhamos resolvido completamente a forma de desenvolver uma capacidade de decisão técnica profunda quando a IA faz grande parte do trabalho inicial.

Por enquanto, a minha melhor resposta é tornar visível a compreensão. Os engenheiros devem ser capazes de explicar porque é que o código funciona, onde pode falhar, que testes são importantes, o que acontece à escala e como o depurariam em produção.

Como gerir a utilização de tokens

O custo também tem sido um desafio da IA.

A utilização de tokens parece inofensiva no início, mas, quando a IA entra na programação, nas revisões, nos testes, na depuração e nos fluxos de trabalho agênticos, o custo pode crescer muito rapidamente.

Por isso, temos agora de medir o ROI por fluxo de trabalho e utilizar uma orquestração mais inteligente. Nem todas as tarefas precisam do modelo mais dispendioso.

O futuro passa por utilizar o modelo certo para a tarefa certa.

Porque têm os CTO de avançar rapidamente — com controlos

Eis o meu conselho: Construa rapidamente. Experimente rapidamente. Integre a IA em fluxos de trabalho reais de engenharia, produto, suporte, vendas, operações e processos internos. Não finja que não funciona. Funciona, por vezes surpreendentemente bem.

Mas não se torne um crente cego. A IA é poderosa, mas não é magia. Precisa de controlo, governação, testes, observabilidade e responsabilidades claras. Caso contrário, estará apenas a criar caos mais rapidamente.

A mentalidade certa não é nem “a IA vai substituir tudo” nem “a IA está sobrevalorizada”. A mentalidade certa é “como posso utilizar isto para tornar a minha organização 10 vezes mais capaz?”

Acompanhe

Acompanhe Abhishek Ranjan no LinkedIn. E consulte a sua newsletter Hacktivate.

Mais entrevistas com especialistas em breve no Clube dos CTO!