Descobertas da IDC Colocam Resultados de Projetos de IA Sob Escrutínio dos CIOs

Uma pesquisa da IDC desencadeou um debate no google news sobre o fracasso de projetos de IA, com uma manchete afirmando que 45% dos projetos não geram resultados.

As evidências subjacentes exigem uma leitura mais cuidadosa. Uma pesquisa vinculada à IDC diz que, em média, apenas 45% das iniciativas de IA produzem resultados mensuráveis. Essa constatação implica uma lacuna de valor maior do que a manchete sugere, dependendo de como as organizações definem sucesso.

A distinção importa porque os CIOs já não são julgados pela quantidade de pilotos de IA que lançam. Os conselhos agora esperam retornos mensuráveis, implantações seguras e governança capaz de controlar agentes autônomos depois que entram em produção.

Esse é o verdadeiro conflito por trás da manchete. Líderes empresariais querem sistemas de IA que realizem mais trabalho com maior autonomia. No entanto, essa mesma autonomia torna custos, decisões, permissões e falhas mais difíceis de conter.

A IDC, portanto, está descrevendo mais do que outro ciclo tecnológico decepcionante. Está documentando uma transferência de responsabilidade de equipes experimentais de IA para CIOs que precisam defender resultados de negócio e riscos operacionais.

O Que a Alegação da IDC no Google News Realmente Diz

O número reportado de 45% mede iniciativas que geram resultados mensuráveis, não uma taxa universal de fracasso para todos os projetos empresariais de IA.

A manchete original do google news apresenta 45% dos projetos de IA como incapazes de entregar resultados. No entanto, o material de apoio conectado à IDC apresenta a estatística de outra forma.

Uma análise da Fujitsu cita o Technology Investment and Innovation Monitor da IDC, de setembro de 2025. Segundo ela, 45% das iniciativas de IA globalmente alcançam, em média, resultados mensuráveis.

A pesquisa abrangeu 894 respondentes, segundo a citação da Fujitsu. Também constatou que apenas 11% das organizações relataram sucesso em mais de três quartos de seus projetos de IA.

Essas medições não estabelecem que exatamente 45% fracassaram. Elas mostram que 45% produziram resultados mensuráveis, deixando 55% sem um resultado demonstrado segundo a abordagem de medição da pesquisa.

Essa lacuna pode incluir várias situações. Um projeto pode permanecer em testes, chegar à produção sem valor mensurável, não atingir sua meta original ou não dispor de dados suficientes para avaliação.

São resultados diferentes. Reuni-los em uma única taxa de fracasso cria uma manchete mais simples, mas um retrato menos preciso do desempenho empresarial.

As evidências disponíveis também não provam que os modelos de IA subjacentes causaram todos os resultados fracos. A adoção pelo negócio, o desenho do fluxo de trabalho, a qualidade dos dados, os custos operacionais e métricas pouco claras podem, cada um, impedir a realização de valor.

Essa distinção separa falha técnica de falha organizacional. Um modelo pode gerar uma saída aceitável enquanto o projeto ao seu redor ainda não alcança sua meta de negócio.

Um assistente interno, por exemplo, pode responder com precisão às perguntas dos funcionários. Ainda assim, ele fracassa comercialmente se os trabalhadores o evitam, as respostas chegam lentamente demais ou os custos de suporte superam as economias.

Um modelo de previsão também pode ter bom desempenho em testes controlados. Ele entrega pouco valor se os gestores continuarem tomando decisões por meio de um processo antigo que ignora suas recomendações.

A pesquisa mais ampla da IDC sustenta essa interpretação. A empresa afirma que as organizações têm dificuldade para conectar experimentação a resultados de negócio mensuráveis, especialmente quando métricas de referência nunca foram definidas.

É por isso que a manchete merece escrutínio sem ser descartada. A porcentagem precisa continua dependente de definições, mas o problema de valor subjacente é bem sustentado.

Outras pesquisas apontam na mesma direção. A pesquisa de 2026 da CIO.com constatou que apenas 19% dos respondentes disseram que suas iniciativas de IA atingiram ou superaram as metas de negócio.

A pesquisa State of the CIO abrangeu 662 líderes de TI e 249 usuários de negócio. Ela constatou que 18% relataram que menos de um terço de seus casos de uso atendiam às expectativas.

Os estudos usam amostras e definições diferentes, portanto suas porcentagens não devem ser tratadas como comparações diretas. Juntos, mostram que o valor empresarial mensurável continua incomum.

A conclusão responsável é mais restrita do que a alegação viral. Muitas organizações não conseguem demonstrar retornos consistentes da maioria das iniciativas de IA, e os CIOs agora precisam explicar o motivo.

Essa conclusão já é séria o suficiente sem distorcer o número.

A Experimentação com IA Está Dando Lugar a uma Exigência de ROI

A mudança central não é a queda do interesse em IA. É o fim do financiamento de experimentos sem responsáveis definidos, referências e resultados de negócio.

O investimento empresarial em IA continua mesmo quando os retornos permanecem difíceis de comprovar. Essa aparente contradição reflete pressão competitiva, e não confiança em todos os projetos.

Os conselhos temem que reduzir os investimentos deixará suas empresas para trás. Eles também querem que os CIOs mostrem que os gastos existentes melhoram receita, custos, atendimento ao cliente, resiliência ou velocidade de decisão.

Isso cria um caminho mais estreito para líderes de tecnologia. Eles precisam manter o ritmo de adoção enquanto encerram projetos que não conseguem justificar sua carga operacional.

A IDC informa que 42% das organizações consideram o ROI dos investimentos digitais e em IA difícil ou impossível de avaliar. A empresa identifica referências inconsistentes e visibilidade limitada de longo prazo como obstáculos importantes.

Seu framework de ROI agêntico argumenta que sistemas agênticos tornam esses problemas mais difíceis. Seu valor e seus custos mudam à medida que fluxos de trabalho, modelos e padrões de uso evoluem.

O software tradicional geralmente sustenta um caso de negócio relativamente estável. Os compradores estimam custos de implementação, necessidades de licenças, usuários esperados e economias de processo antes da implantação.

A IA agêntica se comporta de modo diferente. Um agente é um software que pode planejar etapas, usar ferramentas e tomar ações em direção a uma meta com intervenção humana limitada.

Seu custo operacional pode variar conforme chamadas de modelo, tamanho do contexto, uso de ferramentas, novas tentativas e revisões humanas. Seu desempenho também pode mudar quando as condições de negócio ou os dados de origem se alteram.

Por isso, um piloto bem-sucedido oferece evidências incompletas. O piloto pode usar dados selecionados, um pequeno grupo de usuários e supervisão técnica extensiva que as equipes de produção não conseguem sustentar.

Depois de implantado de forma ampla, o mesmo sistema enfrenta entradas inconsistentes, restrições de acesso, casos incomuns e funcionários que o utilizam de maneiras inesperadas.

O executivo da TIAA Sastry Durvasula descreveu essa tensão na reportagem da CIO.com. Ele disse que um piloto bem-sucedido ainda pode ter dificuldade para produzir ROI real depois que as organizações contabilizam os custos operacionais.

Esses custos incluem consumo de tokens, gestão de tráfego, manutenção de integrações, avaliações, revisões de segurança e suporte. Raramente aparecem em uma demonstração inicial.

A nova missão do CIO começa pela definição de valor antes da construção. Um projeto precisa de uma referência mensurável que mostre como o processo funciona sem IA.

Também precisa de um responsável de negócio que se beneficie do resultado. As equipes técnicas não podem certificar de forma independente o valor de negócio quando outro departamento controla a adoção e as mudanças no fluxo de trabalho.

A CIO.com constatou que 83% dos líderes de TI pesquisados possuíam estruturas interfuncionais de IA ou planejavam implementá-las durante o ano. Ainda assim, a aprovação formal e a medição permaneciam menos maduras.

Apenas 53% tinham um processo oficial de aprovação de projetos de IA. Outros 28% planejavam introduzir um nos 12 meses seguintes.

Métricas formais existiam em 47% das organizações respondentes, enquanto 34% planejavam estabelecê-las. Essa lacuna ajuda a explicar por que implantações e retornos mensuráveis frequentemente divergem.

As organizações não conseguem comprovar melhoria se nunca registraram o custo do processo original, a taxa de erros, o tempo de conclusão ou o resultado para o cliente.

O resultado é uma inversão de responsabilização. Programas de IA anteriores recompensavam o volume de pilotos e a experimentação visível. A próxima fase recompensa seleção disciplinada e valor repetível.

Essa mudança também altera as conversas com fornecedores. Alegações sobre a qualidade do modelo importam menos quando um comprador não consegue relacionar essa qualidade a um resultado operacional.

Os CIOs precisam cada vez mais de evidências em todo o fluxo de trabalho. Eles devem medir se os funcionários usam o sistema, se a qualidade da saída permanece estável e se os custos ficam dentro dos limites.

Também precisam de uma regra de interrupção. Projetos que repetidamente não atingem limites de adoção, qualidade ou financeiros devem perder financiamento antes de se tornarem infraestrutura permanente.

Essa prática não representa hostilidade à IA. Ela trata os gastos com IA com a mesma disciplina aplicada a outros investimentos estratégicos.

O Principal Conflito É a Promessa da IA Contra a Realidade Operacional

Projetos empresariais de IA frequentemente fracassam na fronteira entre uma demonstração convincente e o ambiente complexo em que o trabalho real acontece.

O principal oponente nesta história não é um fornecedor de IA contra outro. É a promessa de valor rápido da IA contra a realidade das operações empresariais.

As demonstrações normalmente isolam uma tarefa restrita. Os sistemas de produção precisam lidar com permissões, registros desatualizados, políticas conflitantes, dados incompletos e diversos aplicativos dependentes.

Cada dependência adicionada cria outro caminho de falha. O modelo pode retornar uma resposta razoável enquanto uma ferramenta indisponível, um registro desatualizado ou uma permissão incorreta impede a ação necessária.

A qualidade dos dados apresenta um problema semelhante. Sistemas de IA podem resumir, classificar ou recuperar informações, mas não conseguem reparar todas as contradições ocultas em repositórios empresariais.

Um agente de suporte pode encontrar três versões da mesma política de reembolso. Sem uma fonte autoritativa e histórico de versões, ele pode selecionar com confiança a regra errada.

O trabalho do conhecimento cria outro desafio de medição. Redigir mais rapidamente não gera automaticamente valor financeiro se os funcionários gastarem o tempo economizado revisando uma saída pouco confiável.

O projeto precisa medir todo o processo. Isso inclui preparação, geração, revisão, correção, escalonamento e quaisquer erros posteriores.

É aqui que uma abordagem de knowledge blending pode se tornar relevante. Combinar fontes aprovadas com contexto de trabalho pode reduzir lacunas de recuperação, mas a governança ainda determina em quais materiais se confia.

A adoção do fluxo de trabalho também importa. Os funcionários frequentemente ignoram um novo sistema quando ele adiciona etapas, exige interfaces desconhecidas ou falha em casos incomuns.

Esse comportamento pode permanecer invisível durante um piloto patrocinado. Os participantes recebem treinamento e suporte, enquanto usuários comuns enfrentam prioridades concorrentes.

Uma adoção bem-sucedida, portanto, exige redesenho de processos, não apenas acesso a um modelo. As equipes devem decidir quais tarefas mudam, quais aprovações permanecem e quem lida com exceções.

A diferença entre assistência e autonomia eleva ainda mais os riscos. Um assistente de escrita propõe texto para revisão por uma pessoa. Um agente pode criar tickets, modificar registros, contatar clientes ou disparar transações.

Uma sugestão imprecisa custa tempo de revisão. Uma ação autônoma imprecisa pode alterar sistemas reais antes que um humano perceba.

A pesquisa da IDC argumenta que as organizações não devem aplicar tecnologia agêntica a todas as tarefas. A automação determinística continua mais adequada para processos estáveis com regras claras.

Sistemas agênticos fazem mais sentido quando o trabalho exige várias etapas, contexto variável, julgamento e orquestração entre ferramentas. Mesmo assim, a autonomia precisa gerar valor suficiente para justificar o risco adicional.

Essa disciplina de casos de uso ajuda a explicar o debate sobre o fracasso de projetos de IA da IDC. Alguns projetos fracos começam com uma tecnologia à procura de um problema.

As equipes escolhem primeiro uma plataforma de modelo ou de agentes. Depois, procuram um fluxo de trabalho que possa justificar a compra.

Essa sequência frequentemente produz protótipos interessantes com importância operacional limitada. Nenhuma unidade de negócio assume a responsabilidade pelo resultado porque o projeto não se originou de uma necessidade mensurada.

Uma sequência mais sólida começa com um fluxo de trabalho caro ou restrito. As equipes documentam sua linha de base, identificam as decisões envolvidas e testam se a IA melhora o resultado como um todo.

A comparação deve incluir software convencional e mudanças de processo. A IA deve vencer porque se adequa ao problema, não porque executivos solicitaram uma iniciativa de IA.

As organizações também precisam distinguir produtividade de valor capturado. Economizar alguns minutos do tempo de um funcionário não tem significado financeiro automático.

A empresa só captura valor quando esse tempo melhora a produção, reduz o tempo de resposta ao cliente, aumenta a capacidade ou corta uma despesa identificada.

A experiência dos funcionários e a resiliência ainda podem ser importantes. No entanto, os líderes devem definir como esses benefícios serão medidos, em vez de tratá-los como explicações convenientes após o fracasso das metas financeiras.

A IDC propõe um mapeamento de valor mais amplo por esse motivo. Sua estrutura inclui confiança do cliente, resiliência, sustentabilidade e horizontes temporais ao lado de métricas financeiras convencionais.

Esse modelo mais amplo não deve se tornar uma desculpa para alegações vagas de sucesso. Cada dimensão ainda precisa de um responsável, linha de base, método de medição e data de revisão.

A realidade operacional é, portanto, menos dramática do que um colapso dos modelos, mas mais difícil de corrigir. Ela exige coordenação entre equipes de tecnologia, finanças, segurança, jurídico e negócios.

Nenhuma atualização de modelo pode criar essa coordenação automaticamente.

A Governança de IA Agêntica Transforma a Segurança em uma Restrição de Negócio

A governança de IA agêntica determina se a autonomia pode escalar com segurança, porque os agentes transformam resultados incertos em ações em sistemas conectados.

A segurança sempre influenciou as decisões de tecnologia empresarial. Os sistemas agênticos mudam o problema ao combinar a incerteza dos modelos com credenciais, ferramentas, memória e acesso operacional.

Um chatbot convencional normalmente retorna informações. Um agente pode interpretar uma solicitação, elaborar um plano, chamar aplicações e continuar agindo após receber novos resultados.

Essa capacidade amplia a superfície de ataque. Conteúdo malicioso pode influenciar as instruções de um agente, enquanto permissões excessivas podem transformar uma decisão equivocada em um incidente maior.

A injeção de prompt é um exemplo. Um invasor insere instruções no conteúdo que o modelo lê, tentando redirecionar o sistema de sua tarefa autorizada.

O perigo aumenta quando um agente pode enviar mensagens, modificar bancos de dados, recuperar registros confidenciais ou executar código. Uma resposta enganosa torna-se apenas uma das possíveis falhas.

A IDC alerta sobre cascatas de decisões descontroladas, comportamento opaco e escalonamento fragmentado. Sua análise de governança descreve a governança como infraestrutura operacional, e não como uma revisão final de conformidade.

A empresa prevê que até 20% das organizações do Global 1000 poderão enfrentar processos judiciais, multas ou demissões de CIOs até 2030. A IDC relaciona esse risco a interrupções de grande repercussão causadas por uma governança fraca de agentes de IA.

Trata-se de uma previsão, não de uma taxa de falha observada. Ela sinaliza a escala da possível responsabilização, e não um resultado garantido.

A IDC recomenda rastreabilidade, governança integrada e ciclos de responsabilização definidos. Esses controles ajudam as equipes a reconstruir decisões e interromper ações antes que ultrapassem limites estabelecidos.

Rastreabilidade significa registrar os dados, o modelo, as instruções, as chamadas de ferramentas e os resultados envolvidos em uma decisão autônoma. Sem esses registros, as equipes não conseguem investigar erros nem defender resultados.

A governança integrada reúne segurança, dados, jurídico, risco e responsabilidade de negócios ao longo do ciclo de vida do sistema. Um comitê que analisa apenas o modelo não pode governar o fluxo de trabalho completo.

Os ciclos de responsabilização definem quando uma pessoa deve aprovar, revisar ou interromper uma ação. O limite deve depender da possível consequência, não apenas da confiança do modelo.

Ações de baixo risco podem receber maior autonomia. Enviar um lembrete interno traz consequências diferentes de aprovar um pagamento ou alterar a conta de um cliente.

Os controles de identidade são igualmente importantes. Cada agente precisa de sua própria identidade, permissões, responsável e finalidade, em vez de usar credenciais irrestritas de um desenvolvedor ou serviço compartilhado.

As permissões devem seguir o princípio do menor privilégio. Um agente recebe apenas o acesso necessário para seu fluxo de trabalho designado, sem autoridade mais ampla.

As organizações também precisam de um inventário confiável. As equipes de segurança não podem proteger agentes cuja existência desconhecem, especialmente quando departamentos podem configurá-los dentro de aplicações empresariais.

O inventário deve registrar responsabilidade, sistemas conectados, dados aprovados, provedores de modelos, resultados de avaliações e controles de emergência.

A avaliação contínua torna-se necessária após o lançamento. O comportamento dos agentes pode mudar quando modelos são atualizados, prompts evoluem, ferramentas conectadas mudam ou os dados de negócios desenvolvem novos padrões.

A IDC observa que o desempenho pode se deteriorar à medida que o contexto muda e casos extremos se acumulam. Isso faz de um agente um serviço gerenciado contínuo, e não uma implantação concluída.

Segurança e ROI, portanto, convergem. Monitoramento, avaliações, controles de acesso, resposta a incidentes e revisão humana acrescentam custos operacionais.

Um caso de negócio que exclui esses controles apresenta um retorno artificialmente favorável. Removê-los para proteger a previsão transfere a pressão financeira para a exposição de segurança.

Esse é o trade-off central que os CIOs precisam administrar. Mais autonomia pode aumentar a velocidade e a capacidade, mas também eleva o custo de garantia.

A resposta não é revisar sem limites cada ação. Isso eliminaria a eficiência que justificava o agente.

As organizações precisam de autonomia baseada em risco. Elas podem automatizar ações reversíveis e observáveis, exigindo aprovação humana para decisões com consequências jurídicas, financeiras ou de segurança.

A governança de IA agêntica também deve abranger procedimentos de desligamento. As equipes precisam ser capazes de revogar credenciais, interromper fluxos de trabalho, isolar a memória e preservar evidências durante um incidente.

Sem essas capacidades, um agente pode continuar operacional enquanto várias equipes discutem quem é responsável. Isso é uma falha de controle organizacional, mesmo que o modelo tenha se comportado como projetado.

O Que os Números Ainda Não Conseguem Provar

As estatísticas disponíveis mostram um amplo problema de valor, mas não sustentam uma taxa universal de fracasso de projetos de IA.

O enquadramento do Google News incentiva uma leitura binária. Um projeto tem sucesso ou fracassa, com uma única porcentagem resumindo todo o mercado.

As implantações empresariais raramente se encaixam nesse modelo. Um projeto pode atingir uma referência técnica, não cumprir uma meta de adoção, permanecer dentro do orçamento e ainda assim não produzir receita mensurável.

Outro projeto pode ultrapassar seus custos originais enquanto cria conhecimento estrategicamente importante ou benefícios para clientes. Se ele é considerado bem-sucedido depende da estrutura de avaliação.

A redação das pesquisas também altera os resultados. “Entregou resultados mensuráveis” é diferente de “atendeu às expectativas”, “entrou em produção” ou “gerou retorno financeiro”.

A seleção da amostra também importa. Uma pesquisa com líderes de tecnologia pode produzir resultados diferentes de um estudo com usuários de negócios, equipes financeiras ou projetos individuais.

O denominador cria outro problema. Alguns estudos contam todos os protótipos. Outros incluem apenas implantações em produção ou iniciativas conhecidas por líderes seniores.

Os horizontes temporais também diferem. Um sistema de IA pode precisar de vários trimestres de redesenho de fluxo de trabalho e adoção antes que seus benefícios apareçam.

Declará-lo um fracasso após um trimestre pode ser prematuro. Continuar indefinidamente sem evidências pode desperdiçar mais capital.

Essas limitações não invalidam as conclusões da IDC. Elas definem o que os leitores podem concluir de forma responsável a partir delas.

A conclusão mais forte é que as empresas têm dificuldade para medir e repetir o valor da IA. A conclusão mais fraca é que uma porcentagem fixa de todos os projetos fracassou definitivamente pelo mesmo motivo.

A distinção também afeta a responsabilização. Se o modelo for culpado automaticamente, as organizações podem substituir fornecedores enquanto preservam os problemas de fluxo de trabalho, dados e governança que causaram resultados fracos.

Se todos os problemas forem atribuídos à prontidão organizacional, os fornecedores poderão evitar a responsabilidade por produtos não confiáveis. Ambas as narrativas merecem escrutínio.

A qualidade do modelo ainda importa. Alucinações, raciocínio inconsistente, latência, contexto limitado e erros no uso de ferramentas podem tornar uma aplicação inadequada para produção.

O design do fornecedor também importa. Os compradores precisam de logs de auditoria utilizáveis, controles de permissão, avisos sobre mudanças de modelos, ferramentas de avaliação e comportamento de serviço previsível.

As organizações continuam responsáveis por selecionar casos de uso apropriados e configurar o acesso com segurança. Os fornecedores continuam responsáveis por descrever com precisão as capacidades e limitações.

A discussão sobre o fracasso de projetos de IA da IDC deve, portanto, gerar perguntas melhores, e não um único culpado conveniente.

Qual linha de base o projeto pretendia melhorar? Qual responsável de negócio aceitou a meta? Os custos de segurança e operação foram incluídos antes da aprovação?

Os funcionários usaram o sistema quando o suporte ao piloto terminou? A qualidade da produção permaneceu aceitável em casos incomuns e com dados em mudança?

As equipes conseguiriam reconstruir as ações de um agente após um erro? Conseguiriam interromper o fluxo de trabalho imediatamente sem desativar sistemas não relacionados?

Essas perguntas transformam uma manchete contestada em uma revisão operacional. Elas também são mais difíceis de responder do que saber se um piloto foi lançado dentro do prazo.

Uma comparação independente reforça a necessidade de cautela. A Gartner informou que 45% das organizações com alta maturidade mantiveram projetos de IA operacionais por pelo menos três anos.

Sua pesquisa de maturidade em IA relacionou a longevidade a práticas maduras, mas a longevidade por si só não prova valor de negócio.

Um projeto pode permanecer operacional por razões estratégicas ou políticas. Um projeto também pode terminar após transferir com sucesso sua capacidade para outra plataforma.

Nenhuma métrica única captura todo o resultado. As organizações precisam de uma visão de portfólio que separe desempenho técnico, adoção, impacto financeiro, risco e valor estratégico.

Esse portfólio deve incluir projetos malsucedidos. Ocultar pilotos abandonados cria uma imagem enganosa e impede que as equipes reconheçam causas recorrentes.

Ele também deve distinguir um cancelamento saudável de um fracasso descontrolado. Encerrar cedo um projeto fraco pode demonstrar governança disciplinada, e não desempenho ruim.

Uma fonte da CIO.com descreveu o encerramento de aproximadamente um terço dos projetos iniciados como algo saudável. A organização usou financiamento por fases e pontos de controle de resultados para impedir que trabalhos fracos consumissem recursos permanentes.

Essa abordagem redefine o fracasso. O projeto perigoso nem sempre é aquele que para. Pode ser aquele que continua sem evidências porque ninguém assume a decisão.

Três Sinais que os CIOs Devem Observar a Seguir

O próximo teste é verificar se as organizações substituirão a contagem de pilotos por relatórios de resultados, autonomia controlada e evidências de que os funcionários usam IA em fluxos de trabalho reais.

O primeiro sinal é a adoção de manuais formais de valor de IA. A IDC espera que 60% dos CIOs da Asia-Pacific 500 recebam a tarefa de criá-los até 2027.

Um playbook de valor padroniza a seleção de casos de uso, linhas de base, modelos de custo, responsabilidades e limites de revisão. Ele permite que líderes comparem projetos com base em evidências consistentes.

Esse sinal reforçaria o argumento da IDC se as organizações começarem a encerrar projetos sem resultados mensuráveis. Ele enfraqueceria o argumento se a medição formal se expandir sem melhorar o desempenho do portfólio.

A métrica-chave não é o número de playbooks publicados. É a parcela de iniciativas em produção com responsáveis nomeados, linhas de base, custos operacionais completos e revisões de resultados programadas.

Os conselhos também devem acompanhar como as organizações relatam benefícios indiretos. Confiança dos clientes, resiliência e decisões mais rápidas podem importar, mas cada um exige um método de medição observável.

O segundo sinal é a implementação de controles aplicáveis a agentes. Políticas, por si só, não conseguem governar software que atua continuamente em sistemas empresariais.

CIOs devem acompanhar quantos agentes têm identidades dedicadas, permissões limitadas, registros completos de ações, regras de escalonamento humano e procedimentos de desligamento testados.

As equipes de segurança também devem reportar incidentes por gravidade e causa-raiz. O aumento no número de incidentes pode refletir tanto uma piora na segurança quanto uma maior visibilidade de atividades antes ocultas.

A tendência mais significativa é verificar se os incidentes graves diminuem à medida que o uso de agentes se expande. As organizações devem comparar as taxas de incidentes com as ações dos agentes, os sistemas conectados e os níveis de risco.

A perspectiva da IDC para a região Ásia-Pacífico prevê consequências graves decorrentes de controles inadequados sobre agentes, incluindo exposição jurídica e responsabilização de executivos. Essa previsão se torna mais crível se as implantações autônomas se expandirem mais rapidamente do que a supervisão técnica.

Ela se torna menos crível se as organizações demonstrarem que os controles baseados em risco acompanham a escala de uso. As evidências devem incluir resultados de auditorias, tempos de contenção, violações de permissões e intervenções humanas bem-sucedidas.

O terceiro sinal é a adoção em produção vinculada a resultados de fluxo de trabalho. A precisão em pilotos e o entusiasmo dos funcionários não substituem o uso sustentado nas operações diárias.

CIOs devem monitorar o uso ativo, as taxas de conclusão, a frequência de exceções, o tempo de revisão e a porcentagem do trabalho gerado que chega a um resultado útil.

Eles também devem medir o que acontece depois que o suporte à implantação diminui. Um sistema que depende de intervenção constante de seus criadores não alcançou uma produção repetível.

As unidades de negócio precisam relatar se a IA reduz os tempos de ciclo, amplia a capacidade, reduz erros ou melhora os resultados para os clientes. As equipes financeiras devem verificar quaisquer economias alegadas.

Esse sinal reforçaria a narrativa do google news se o uso crescer enquanto o valor mensurável permanecer fraco. Isso mostraria que a adoção, por si só, não pode resolver o problema do ROI.

Ele enfraqueceria essa narrativa se programas maduros demonstrarem ganhos repetíveis em vários fluxos de trabalho depois que todos os custos de segurança e operação forem incluídos.

Esses três sinais estão conectados. Modelos de valor melhores selecionam casos de uso mais fortes, controles mais robustos permitem autonomia segura, e a adoção sustentada dos fluxos de trabalho produz evidências mensuráveis.

A remoção de um elemento cria um resultado frágil. Um sistema lucrativo sem controles carrega exposição oculta. Um sistema seguro sem usuários não gera valor.

Um sistema popular sem medições de linha de base produz atividade impressionante, mas retornos incertos.

CIOs devem resistir à pressão de responder ao debate com outra porcentagem abrangente. Seus próprios portfólios oferecem evidências mais úteis do que uma manchete agregada.

Eles podem começar selecionando um pequeno número de fluxos de trabalho relevantes e documentando o desempenho atual. Cada projeto deve receber um responsável de negócio, um responsável técnico, uma classificação de risco e um cronograma de revisão.

As equipes devem calcular os custos além do desenvolvimento inicial. Esses custos incluem uso de modelos, manutenção de integrações, monitoramento, avaliações, segurança, suporte e revisão humana.

Elas devem definir resultados inaceitáveis antes de conceder autonomia. Esses limites podem abranger exposição de dados, limites financeiros, impacto sobre clientes e ações de ferramentas proibidas.

Por fim, devem publicar os resultados internos, incluindo cancelamentos. Relatórios transparentes dificultam que projetos fracos sobrevivam apenas com base no entusiasmo.

A alegação contestada de 45% é, portanto, útil como um alerta, não como um placar universal. Ela expõe como medições imprecisas podem facilmente se transformar em uma manchete confiante sobre IA.

A melhor resposta não é discutir uma porcentagem do google news. É exigir evidências de que cada sistema de IA cria valor depois que seus custos e riscos completos são contabilizados.

Quais projetos sobreviveriam a esse teste dentro da sua organização, e quais continuam financiados porque ninguém definiu o que significa sucesso?