Vejo que existe muita atividade de IA nas empresas e ainda pouca evidência de transformação. Pilotos se multiplicam, licenças são distribuídas, copilotos chegam a diferentes áreas e começam as primeiras experiências com agentes. Tudo isso pode ser necessário para aprender. O problema aparece quando atividade passa a ser apresentada como resultado.

Depois de algum tempo, algumas organizações descobrem que têm dezenas de iniciativas, mas continuam com dificuldade para responder questões básicas: onde a IA efetivamente criou valor, quais casos merecem escalar, quais deveriam ser interrompidos, quanto custam quando chegam à produção e quais novos riscos foram introduzidos.

O desafio não é escolher entre velocidade e prudência. É aumentar a velocidade de aprendizado sem aumentar irresponsavelmente a exposição da empresa.

Isso começa pela escolha dos problemas.

Um bom caso de uso não deveria nascer simplesmente porque surgiu uma nova capacidade em um modelo. Deveria partir de um problema ou oportunidade relevante para o negócio, com baseline, resultado esperado e alguma forma de verificar se a intervenção funcionou. Só então faz sentido avaliar se IA é a tecnologia adequada.

Pilotos têm papel importante nesse processo. Mas um piloto deveria ser um experimento com hipótese e critérios de decisão, não apenas uma demonstração de que determinada tecnologia funciona.

Antes de começar, deveriam estar claros o problema, o resultado esperado, as métricas, os riscos aceitáveis e as condições para escalar, modificar ou interromper a iniciativa. Caso contrário, cria-se facilmente o conhecido pilot purgatory, com muitos experimentos e pouca transformação operacional.

Também não se deve começar pelos processos mais críticos.

Quanto maior a consequência potencial de um erro, maior deve ser a exigência de evidência e controles antes de ampliar a autonomia. Uma IA que sugere uma resposta para um funcionário está em uma categoria diferente de um agente autorizado a alterar cadastros, aprovar transações, movimentar recursos ou tomar decisões com impacto sobre clientes.

Por isso considero mais adequada a ideia de autonomia conquistada, não presumida. O sistema pode começar assistindo uma pessoa. Com desempenho suficientemente validado, pode recomendar ações. Em determinados contextos, pode executar ações limitadas, observáveis e reversíveis. A ampliação da autonomia depende não apenas da acurácia média do modelo, mas também da gravidade dos erros possíveis, previsibilidade do ambiente, qualidade dos mecanismos de monitoramento, permissões concedidas, capacidade de reversão e existência de caminhos claros de escalonamento. Um modelo acertar 99% das vezes diz pouco sem sabermos o que acontece no 1% restante.

E simplesmente colocar uma pessoa no circuito também não resolve automaticamente o problema. Human-in-the-loop só funciona como controle quando essa pessoa possui contexto, competência, tempo e autoridade para identificar e interromper uma ação inadequada. Caso contrário, o humano pode se transformar apenas em um aprovador automático de decisões da máquina.

Existe ainda uma dimensão organizacional frequentemente subestimada. Preparar pessoas para IA não significa ensinar prompts ou distribuir ferramentas. Significa redesenhar processos, responsabilidades, controles e direitos de decisão.

É necessário estabelecer quem valida resultados, quem permanece accountable pelas decisões, quais atividades podem ser delegadas, quais exigem supervisão e quais devem permanecer essencialmente humanas. Também é preciso redefinir competências, porque automatizar parte da execução frequentemente aumenta a importância de revisão, julgamento, conhecimento de domínio e capacidade de lidar com exceções.

A mesma disciplina precisa aparecer nas métricas.

Número de usuários, prompts, tokens consumidos, pilotos realizados ou agentes colocados em produção são indicadores de atividade e adoção. Podem ser úteis operacionalmente, mas não demonstram, isoladamente, transformação ou criação de valor.

As métricas precisam chegar aos resultados: aumento de receita, redução de custo, diminuição do tempo de ciclo, melhoria de qualidade, redução de erros, mitigação de risco, aumento de capacidade ou viabilização de algo que anteriormente não era economicamente possível.

Nem todo benefício precisa aparecer imediatamente como ROI financeiro. Projetos de segurança, compliance ou construção de capacidades estratégicas podem produzir valor principalmente pela redução de exposição ou criação de opções futuras. Mas mesmo nesses casos é necessário explicitar qual valor se pretende criar e quais evidências demonstrarão que isso ocorreu.

Também precisamos contabilizar o custo completo. Não apenas tokens ou licenças, mas integração, infraestrutura, dados, observabilidade, segurança, avaliação, revisão humana, manutenção e mudança organizacional.

É muito fácil demonstrar ROI em um PowerPoint quando parte do custo permanece fora da conta. Por isso, IA corporativa deveria ser tratada menos como uma corrida tecnológica e mais como um processo disciplinado de construção de evidências.

O board tem razão em não aceitar imobilidade. Esperar certeza absoluta antes de experimentar seria outra forma de errar. Mas pressionar simplesmente por “mais IA” cria incentivos para maximizar aquilo que é fácil mostrar: pilotos, licenças, usuários e agentes.

Uma organização madura não deve tentar provar que está usando muita IA. Deve ser capaz de provar onde a IA está criando valor, onde ainda está apenas produzindo aprendizado e onde simplesmente não vale a pena usá-la.