Quando vais ao supermercado e escolhes um produto, na embalagem está indicado de onde ele vem. País de origem, condições de produção, se é ecológico ou não. Não vês o processo, mas tens informação suficiente para decidir se confias nele. 

Agora pensa no software que adquires para operar o teu Data Center: o sistema DCIM que gere o teu inventário físico; o BMS que controla o cooling, os acessos e a segurança; as ferramentas de monitorização das quais depende a tua operação todos os dias. 

Sabes como foi desenvolvido? Que processo de QA está por trás? Alguém o validou em condições adversas antes de chegar até ti? 

Provavelmente não. E até há pouco tempo também não importava muito perguntar. O que existia era uma relação de confiança ou, pelo menos, não nos questionávamos sobre como tinha sido o processo de desenvolvimento no nosso setor. 

No entanto, algo está a mudar. O desenvolvimento de software com IA e agentes já é uma realidade em muitas equipas. O meu colega Sergio analisava isso há alguns dias com muito critério: a promessa de construir aplicações em horas, de que qualquer pessoa pode gerar código funcional sem escrever uma única linha manualmente, de que o papel do desenvolvedor se transforma quase de um dia para o outro. Ultimamente, conceitos e palavras estranhas que eram próprios do ambiente de desenvolvimento e do produto digital chegaram ao nosso vocabulário do dia a dia, e não sei se isso é bom ou mau. 

O uso de agentes e de IA na criação de produtos digitais faz sentido em muitos contextos. Nos casos mais ligados ao testing, onde a velocidade tem valor; em ambientes académicos, onde a aprendizagem é a base. Mas e nas aplicações produtivas? E mais além, nas aplicações produtivas de ambientes de missão crítica como as comunicações, o transporte de energia, a navegação aérea ou, claro, os Data Centers? 

Há uma consequência desta tendência que quase ninguém está a mencionar: dentro de dois ou três anos, uma parte do software empresarial que está a chegar ao mercado terá sido desenvolvido com processos radicalmente diferentes dos de antes. Mais rápidos, mais automáticos, com equipas mais pequenas, com testing mais leve. E tu, como comprador, não terás forma de o saber ao olhar para a caixa. No entanto, estarão presentes em ambientes onde o software toma decisões com impacto real. 

De forma habitual no B2B compramos software como se estivéssemos a comprar um produto terminado. Avaliamos pelo que faz, não por como foi construído. E durante décadas isso funcionou razoavelmente bem porque os processos de desenvolvimento tinham fricções naturais que funcionavam como filtro: as equipas eram grandes, os ciclos eram longos, as revisões existiam mesmo que fossem imperfeitas, porque nada é perfeito, mas existia um grande controlo. Importava-nos mais a segurança do que a velocidade.. 

E eu pergunto-me: quanto tempo mais nos importará a segurança mais do que a velocidade?  

Então, o que fazemos?

Não tenho uma resposta definitiva. Mas tenho claro que tipo de perguntas deveriam poder ser respondidas antes de assinar um contrato de software para um ambiente crítico: 

 Que percentagem do código foi revista por pessoas com conhecimento do domínio, não       apenas da linguagem? 

 Como foi testado o comportamento em condições de falha, não apenas no caminho             feliz? 

 Existe rastreabilidade do processo de desenvolvimento: quem decidiu o quê, quando e          porquê? O código está documentado? 

 O que acontece quando algo falha em produção e como se pode intervir? 

Não sou desenvolvedora, nem sequer estou perto disso, e provavelmente há muitas outras perguntas muito mais interessantes para fazer. Não sei se são estas ou quais deveriam ser, mas tenho claro que devemos começar a pensar nelas.

A rastreabilidade como diferenciador voluntário

Não sou sempre a favor de regulações, mas sou a favor da transparência. Não tem necessariamente de vir de um regulador (embora o AI Act europeu já comece a apontar nessa direção para certos sistemas de alto risco). Acredito que a oportunidade mais interessante é para os próprios vendors: aqueles que voluntariamente colocarem nas mãos do utilizador os seus sistemas de qualidade. Sem isso, não estou tão convencida de que vamos dar um salto na automatização de processos tão críticos como os que acontecem num Data Center. 

Num mercado onde toda a gente poderá dizer que o seu software “tem IA” e foi desenvolvido “com as últimas tecnologias”, a transparência sobre o processo pode tornar-se um argumento para transmitir confiança. Não “o que faz o nosso produto”, mas “assim o construímos e assim o validámos”.

É o mesmo que aconteceu com a rastreabilidade alimentar. Ninguém a exigia. Depois houve uma crise, o mercado passou a exigi-la, e quem já tinha o processo documentado saiu a ganhar. Quem não tinha teve de correr. 

A pergunta que me faço é se o setor do software empresarial vai esperar por uma crise para começar a pensar nisto, ou se alguém se vai mover antes. 

Reflexão final

Não sei como isto deveria chamar-se. Um selo? Uma declaração de processo? Uma auditoria de desenvolvimento? Provavelmente não é uma única coisa, mas uma combinação que depende do setor e do nível de criticidade. 

O que tenho claro é que comprar software para ambientes críticos sem saber nada do processo que existe por trás vai ser, cada vez mais, um risco que alguém terá de assumir explicitamente. E esse alguém normalmente não é o vendor. É quem assina a compra. 

Por isso deixo-vos uma pergunta simples: perguntariam ao vosso fornecedor de software como foi desenvolvido aquilo que vos está a vender? E se a resposta fosse “com agentes de IA em três semanas”, assinariam na mesma? 

Porque eu, antes de responder, precisaria de saber bastante mais.