Los hallazgos de IDC ponen los resultados de los proyectos de IA bajo el escrutinio de los CIO
La investigación de IDC ha desencadenado un debate en google news sobre el fracaso de los proyectos de IA, con un titular que afirma que el 45% de los proyectos no genera resultados.
La evidencia subyacente requiere una lectura más cuidadosa. Una investigación vinculada a IDC indica que, en promedio, solo el 45% de las iniciativas de IA ofrece resultados medibles. Este hallazgo implica una brecha de valor mayor de lo que sugiere el titular, según cómo definan las organizaciones el éxito.
La distinción importa porque los CIO ya no son evaluados por la cantidad de pilotos de IA que lanzan. Los consejos de administración ahora esperan retornos medibles, implementaciones seguras y una gobernanza capaz de controlar a los agentes autónomos una vez que entran en producción.
Ese es el verdadero conflicto detrás del titular. Los líderes empresariales quieren sistemas de IA que realicen más trabajo con mayor autonomía. Sin embargo, esa misma autonomía dificulta contener los costes, las decisiones, los permisos y los fallos.
Por tanto, IDC está describiendo algo más que otro ciclo tecnológico decepcionante. Está documentando una transferencia de responsabilidad desde los equipos experimentales de IA hacia CIO que deben defender los resultados empresariales y los riesgos operativos.
Lo que realmente dice la afirmación de IDC en Google News
La cifra comunicada del 45% mide las iniciativas que logran resultados medibles, no una tasa de fracaso universal para todos los proyectos empresariales de IA.
El titular original de google news presenta al 45% de los proyectos de IA como incapaces de ofrecer resultados. Sin embargo, el material de apoyo vinculado con IDC plantea la estadística de otra manera.
Un análisis de Fujitsu cita el Technology Investment and Innovation Monitor de IDC de septiembre de 2025. Indica que el 45% de las iniciativas de IA a escala mundial logra resultados medibles en promedio.
La investigación abarcó a 894 encuestados, según la cita de Fujitsu. También concluyó que solo el 11% de las organizaciones informó de éxito en más de tres cuartas partes de sus proyectos de IA.
Esas mediciones no establecen que exactamente el 45% haya fracasado. Muestran que el 45% produjo resultados medibles, lo que deja al 55% sin un resultado demostrado según el enfoque de medición de la encuesta.
Esa brecha puede incluir varias situaciones. Un proyecto podría seguir en pruebas, llegar a producción sin valor medible, no alcanzar su objetivo original o carecer de datos suficientes para evaluarlo.
Son resultados distintos. Agruparlos en una única tasa de fracaso crea un titular más claro, pero una imagen menos precisa del rendimiento empresarial.
La evidencia disponible tampoco demuestra que los modelos de IA subyacentes hayan causado todos los resultados débiles. La adopción empresarial, el diseño del flujo de trabajo, la calidad de los datos, los costes operativos y las métricas poco claras pueden impedir, cada uno por sí mismo, la materialización del valor.
Esta distinción separa el fracaso técnico del fracaso organizativo. Un modelo puede generar resultados aceptables mientras el proyecto que lo rodea sigue sin alcanzar su objetivo empresarial.
Un asistente interno, por ejemplo, puede responder con precisión a las preguntas de los empleados. Aun así fracasa comercialmente si los trabajadores no lo utilizan, las respuestas llegan demasiado tarde o los costes de soporte superan los ahorros.
Un modelo de previsión también puede funcionar bien en pruebas controladas. Aporta poco valor si los directivos siguen tomando decisiones mediante un proceso anterior que ignora sus recomendaciones.
La investigación más amplia de IDC respalda esa interpretación. La firma afirma que las organizaciones tienen dificultades para conectar la experimentación con resultados empresariales medibles, especialmente cuando nunca se definieron métricas de referencia.
Por eso el titular merece escrutinio sin que deba descartarse. El porcentaje exacto sigue dependiendo de las definiciones, pero el problema de valor subyacente está bien respaldado.
Otras investigaciones apuntan en la misma dirección. La encuesta de CIO.com de 2026 concluyó que solo el 19% de los encuestados afirmó que sus iniciativas de IA cumplieron o superaron los objetivos empresariales.
La investigación State of the CIO abarcó a 662 líderes de TI y 249 usuarios empresariales. Determinó que el 18% informó de que menos de un tercio de sus casos de uso cumplían las expectativas.
Los estudios emplean muestras y definiciones distintas, por lo que sus porcentajes no deben tratarse como comparaciones directas. En conjunto, muestran que el valor empresarial medible sigue siendo poco común.
La conclusión responsable es más limitada que la afirmación viral. Muchas organizaciones no pueden demostrar retornos consistentes de la mayoría de sus iniciativas de IA, y los CIO ahora deben explicar por qué.
Esa conclusión es lo bastante seria sin forzar la cifra.
La experimentación con IA da paso a un mandato de ROI
El cambio central no es la disminución del interés por la IA. Es el fin de financiar experimentos sin responsables definidos, referencias de partida y resultados empresariales.
La inversión empresarial en IA continúa incluso cuando resulta difícil demostrar los retornos. Esta aparente contradicción refleja la presión competitiva más que la confianza en cada proyecto.
Los consejos temen que reducir la inversión deje rezagadas a sus empresas. También quieren que los CIO demuestren que el gasto existente mejora los ingresos, los costes, el servicio al cliente, la resiliencia o la velocidad de decisión.
Esto crea un camino más estrecho para los líderes tecnológicos. Deben mantener el impulso de adopción mientras cierran proyectos que no pueden justificar su carga operativa.
IDC informa de que al 42% de las organizaciones le resulta difícil o imposible evaluar el ROI de las inversiones digitales y de IA. La firma identifica las referencias de partida inconsistentes y la escasa visibilidad a largo plazo como obstáculos importantes.
Su marco de ROI agéntico sostiene que los sistemas agénticos agravan esos problemas. Su valor y sus costes cambian a medida que evolucionan los flujos de trabajo, los modelos y los patrones de uso.
El software tradicional suele respaldar un caso de negocio relativamente estable. Los compradores estiman los costes de implementación, las necesidades de licencias, los usuarios esperados y los ahorros de proceso antes de la implementación.
La IA agéntica se comporta de forma diferente. Un agente es software que puede planificar pasos, usar herramientas y realizar acciones hacia un objetivo con una intervención humana limitada.
Su coste operativo puede variar según las llamadas al modelo, el tamaño del contexto, el uso de herramientas, los reintentos y las revisiones humanas. Su rendimiento también puede cambiar cuando cambian las condiciones empresariales o los datos de origen.
Por tanto, un piloto exitoso ofrece evidencia incompleta. El piloto podría utilizar datos seleccionados, un grupo reducido de usuarios y una supervisión técnica intensiva que los equipos de producción no pueden mantener.
Una vez desplegado ampliamente, el mismo sistema se enfrenta a entradas inconsistentes, restricciones de acceso, casos poco habituales y empleados que lo utilizan de maneras inesperadas.
El ejecutivo de TIAA Sastry Durvasula describió esta tensión en el informe de CIO.com. Dijo que un piloto exitoso aún puede tener dificultades para generar un ROI real después de que las organizaciones consideren los costes operativos.
Esos costes incluyen el consumo de tokens, la gestión del tráfico, el mantenimiento de integraciones, las evaluaciones, las revisiones de seguridad y el soporte. Rara vez aparecen en una demostración inicial.
El nuevo mandato del CIO comienza por definir el valor antes de desarrollar. Un proyecto necesita una referencia medible que muestre cómo funciona el proceso sin IA.
También necesita un responsable empresarial que se beneficie del resultado. Los equipos técnicos no pueden certificar de forma independiente el valor empresarial cuando otro departamento controla la adopción y los cambios en el flujo de trabajo.
CIO.com descubrió que el 83% de los líderes de TI encuestados contaba con estructuras de IA interfuncionales o planeaba implantarlas durante el año. Sin embargo, la aprobación formal y la medición seguían estando menos maduras.
Solo el 53% tenía un proceso oficial de aprobación de proyectos de IA. Otro 28% planeaba introducir uno durante los 12 meses siguientes.
Existían métricas formales en el 47% de las organizaciones participantes, mientras que el 34% planeaba establecerlas. Esa brecha ayuda a explicar por qué las implementaciones y los retornos medibles a menudo divergen.
Las organizaciones no pueden demostrar mejoras si nunca registraron el coste del proceso original, la tasa de error, el tiempo de finalización o el resultado para el cliente.
El resultado es una inversión de la rendición de cuentas. Los primeros programas de IA premiaban el volumen de pilotos y la experimentación visible. La siguiente fase premia la selección disciplinada y el valor repetible.
Este cambio también modifica las conversaciones con proveedores. Las afirmaciones sobre la calidad de los modelos importan menos cuando un comprador no puede vincular esa calidad con un resultado operativo.
Los CIO necesitan cada vez más evidencia a lo largo de todo el flujo de trabajo. Deben medir si los empleados usan el sistema, si la calidad de los resultados se mantiene estable y si los costes permanecen dentro de los límites.
También necesitan una regla de interrupción. Los proyectos que incumplen repetidamente los umbrales de adopción, calidad o rentabilidad deberían perder financiación antes de convertirse en infraestructura permanente.
Esta práctica no representa hostilidad hacia la IA. Trata el gasto en IA con la misma disciplina aplicada a otras inversiones estratégicas.
El conflicto principal es la promesa de la IA frente a la realidad operativa
Los proyectos empresariales de IA suelen fracasar en la frontera entre una demostración convincente y el entorno complejo donde ocurre el trabajo real.
El principal adversario en esta historia no es un proveedor de IA frente a otro. Es la promesa de valor rápido de la IA frente a la realidad de las operaciones empresariales.
Las demostraciones suelen aislar una tarea limitada. Los sistemas de producción deben sortear permisos, registros obsoletos, políticas contradictorias, datos incompletos y varias aplicaciones interdependientes.
Cada dependencia adicional crea otra vía de fallo. El modelo puede devolver una respuesta razonable mientras una herramienta no disponible, un registro desactualizado o un permiso incorrecto impide la acción necesaria.
La calidad de los datos presenta un problema similar. Los sistemas de IA pueden resumir, clasificar o recuperar información, pero no pueden reparar todas las contradicciones ocultas en los repositorios empresariales.
Un agente de soporte puede encontrarse con tres versiones de la misma política de reembolso. Sin una fuente autorizada y un historial de versiones, puede elegir con seguridad la regla equivocada.
El trabajo del conocimiento crea otro reto de medición. Redactar más rápido no genera automáticamente valor financiero si los empleados dedican el tiempo ahorrado a revisar resultados poco fiables.
El proyecto debe medir todo el proceso. Esto incluye la preparación, la generación, la revisión, la corrección, la escalada y cualquier error posterior.
Aquí es donde un enfoque de knowledge blending puede resultar relevante. Combinar fuentes aprobadas con el contexto de trabajo puede reducir las brechas de recuperación, pero la gobernanza sigue determinando qué material es fiable.
La adopción del flujo de trabajo también importa. Los empleados suelen eludir un sistema nuevo cuando añade pasos, exige interfaces desconocidas o falla en casos poco habituales.
Ese comportamiento puede permanecer invisible durante un piloto patrocinado. Los participantes reciben formación y soporte, mientras que los usuarios habituales afrontan prioridades en competencia.
Por ello, una adopción exitosa exige rediseñar los procesos, no solo dar acceso a un modelo. Los equipos deben decidir qué tareas cambian, qué aprobaciones se mantienen y quién se encarga de las excepciones.
La diferencia entre asistencia y autonomía eleva aún más lo que está en juego. Un asistente de redacción propone texto para que una persona lo revise. Un agente puede crear tickets, modificar registros, contactar con clientes o activar transacciones.
Una sugerencia inexacta cuesta tiempo de revisión. Una acción autónoma inexacta puede modificar sistemas reales antes de que una persona lo advierta.
La investigación de IDC sostiene que las organizaciones no deberían aplicar tecnología agéntica a todas las tareas. La automatización determinista sigue siendo más adecuada para procesos estables con reglas claras.
Los sistemas agénticos tienen más sentido cuando el trabajo requiere varios pasos, contexto cambiante, criterio y orquestación entre herramientas. Incluso entonces, la autonomía debe generar suficiente valor para justificar el riesgo añadido.
Esta disciplina de casos de uso ayuda a explicar el debate sobre el fracaso de proyectos de IA de IDC. Algunos proyectos débiles empiezan con una tecnología en busca de un problema.
Los equipos eligen primero un modelo o una plataforma de agentes. Después buscan un flujo de trabajo que pueda justificar la compra.
Esa secuencia suele producir prototipos interesantes con una importancia operativa limitada. Ninguna unidad de negocio asume el resultado porque el proyecto no surgió de una necesidad medida.
Una secuencia más sólida comienza con un flujo de trabajo costoso o limitado por restricciones. Los equipos documentan su línea base, identifican las decisiones implicadas y prueban si la IA mejora el resultado global.
La comparación debe incluir software convencional y cambios en los procesos. La IA debe imponerse porque se ajusta al problema, no porque los ejecutivos solicitaron una iniciativa de IA.
Las organizaciones también deben distinguir la productividad del valor capturado. Ahorrar a un empleado varios minutos no tiene automáticamente un significado financiero.
La empresa captura valor solo cuando ese tiempo mejora la producción, acorta la respuesta al cliente, aumenta la capacidad o reduce un gasto identificado.
La experiencia de los empleados y la resiliencia también pueden ser importantes. Sin embargo, los líderes deben definir cómo se medirán esos beneficios en lugar de tratarlos como explicaciones convenientes después de que fallen los objetivos financieros.
IDC propone un mapeo de valor más amplio por este motivo. Su marco incluye la confianza del cliente, la resiliencia, la sostenibilidad y los horizontes temporales junto con las métricas financieras convencionales.
Ese modelo más amplio no debe convertirse en una excusa para afirmaciones vagas de éxito. Cada dimensión sigue necesitando un responsable, una línea base, un método de medición y una fecha de revisión.
Por tanto, la realidad operativa es menos dramática que el colapso de un modelo, pero más difícil de corregir. Requiere coordinación entre los equipos de tecnología, finanzas, seguridad, legal y negocio.
Ninguna actualización de modelo puede crear esa coordinación automáticamente.
La Gobernanza de la IA Agéntica Convierte la Seguridad en una Restricción Empresarial
La gobernanza de la IA agéntica determina si la autonomía puede escalar de forma segura, porque los agentes convierten resultados inciertos en acciones a través de sistemas conectados.
La seguridad siempre ha influido en las decisiones de tecnología empresarial. Los sistemas agénticos cambian el problema al combinar la incertidumbre del modelo con credenciales, herramientas, memoria y acceso operativo.
Un chatbot convencional normalmente devuelve información. Un agente puede interpretar una solicitud, elaborar un plan, llamar a aplicaciones y seguir actuando después de recibir nuevos resultados.
Esa capacidad amplía la superficie de ataque. El contenido malicioso puede influir en las instrucciones de un agente, mientras que los permisos excesivos pueden convertir una decisión equivocada en un incidente mayor.
La inyección de prompts es un ejemplo. Un atacante coloca instrucciones dentro del contenido que lee el modelo, intentando desviar el sistema de su tarea autorizada.
El peligro aumenta cuando un agente puede enviar mensajes, modificar bases de datos, recuperar registros confidenciales o ejecutar código. Una respuesta engañosa pasa a ser solo uno de los posibles fallos.
IDC advierte sobre cascadas de decisiones sin control, comportamiento opaco y escalamiento fragmentado. Su análisis de gobernanza describe la gobernanza como infraestructura operativa, en lugar de una revisión final de cumplimiento.
La firma prevé que hasta el 20% de las organizaciones Global 1000 podrían enfrentarse a demandas, multas o destituciones de CIO para 2030. IDC vincula ese riesgo con interrupciones de alto perfil provocadas por una gobernanza débil de los agentes de IA.
Se trata de una previsión, no de una tasa de fracaso observada. Señala la magnitud de la posible rendición de cuentas, no un resultado garantizado.
IDC recomienda trazabilidad, gobernanza integrada y ciclos definidos de rendición de cuentas. Estos controles ayudan a los equipos a reconstruir decisiones e interrumpir acciones antes de que crucen límites establecidos.
La trazabilidad implica registrar los datos, el modelo, las instrucciones, las llamadas a herramientas y los resultados implicados en una decisión autónoma. Sin esos registros, los equipos no pueden investigar errores ni defender los resultados.
La gobernanza integrada reúne a los responsables de seguridad, datos, legal, riesgo y negocio durante todo el ciclo de vida del sistema. Un comité que revisa únicamente el modelo no puede gobernar el flujo de trabajo completo.
Los ciclos de rendición de cuentas definen cuándo una persona debe aprobar, revisar o detener una acción. El umbral debe depender de la posible consecuencia, no solo de la confianza del modelo.
Las acciones de bajo riesgo pueden recibir mayor autonomía. Enviar un recordatorio interno tiene consecuencias distintas de aprobar un pago o modificar la cuenta de un cliente.
Los controles de identidad son igualmente importantes. Cada agente necesita su propia identidad, permisos, responsable y propósito, en lugar de tomar prestadas credenciales sin restricciones de un desarrollador o servicio compartido.
Los permisos deben seguir el principio de mínimo privilegio. Un agente recibe únicamente el acceso necesario para su flujo de trabajo asignado y ninguna autoridad más amplia.
Las organizaciones también necesitan un inventario fiable. Los equipos de seguridad no pueden proteger agentes cuya existencia desconocen, especialmente cuando los departamentos pueden configurarlos dentro de aplicaciones empresariales.
El inventario debe registrar la propiedad, los sistemas conectados, los datos aprobados, los proveedores de modelos, los resultados de evaluación y los controles de emergencia.
La evaluación continua se vuelve necesaria tras el lanzamiento. El comportamiento de los agentes puede cambiar cuando se actualizan los modelos, evolucionan los prompts, cambian las herramientas conectadas o los datos empresariales desarrollan nuevos patrones.
IDC señala que el rendimiento puede degradarse a medida que cambia el contexto y se acumulan los casos límite. Eso convierte a un agente en un servicio gestionado continuo, en lugar de un despliegue terminado.
Por tanto, la seguridad y el ROI convergen. La monitorización, las evaluaciones, los controles de acceso, la respuesta a incidentes y la revisión humana añaden costes operativos.
Un caso de negocio que excluye esos controles presenta un retorno artificialmente favorable. Eliminarlos para proteger la previsión traslada la presión financiera a la exposición de seguridad.
Este es el equilibrio central que deben gestionar los CIO. Una mayor autonomía puede aumentar la velocidad y la capacidad, pero también incrementa el coste de garantizarla.
La respuesta no es revisar sin límites cada acción. Eso eliminaría la eficiencia que justificaba el agente.
Las organizaciones necesitan autonomía basada en el riesgo. Pueden automatizar acciones reversibles y observables, mientras exigen aprobación humana para decisiones con consecuencias legales, financieras o de seguridad.
La gobernanza de la IA agéntica también debe cubrir los procedimientos de desconexión. Los equipos necesitan poder revocar credenciales, detener flujos de trabajo, aislar la memoria y preservar pruebas durante un incidente.
Sin esas capacidades, un agente puede seguir operativo mientras varios equipos debaten quién es responsable. Se trata de un fallo de control organizativo, incluso si el modelo se comportó según lo previsto.
Lo Que las Cifras Aún No Pueden Demostrar
Las estadísticas disponibles muestran un problema generalizado de valor, pero no respaldan una tasa universal de fracaso de proyectos de IA.
El enfoque de Google News fomenta una lectura binaria. Un proyecto tiene éxito o fracasa, con un único porcentaje que resume todo el mercado.
Los despliegues empresariales rara vez se ajustan a ese modelo. Un proyecto puede cumplir un parámetro técnico, no alcanzar un objetivo de adopción, mantenerse dentro del presupuesto y aun así no generar ingresos medibles.
Otro proyecto puede superar sus costes originales mientras crea conocimiento o beneficios para el cliente estratégicamente importantes. Que se considere exitoso depende del marco de evaluación.
La redacción de las encuestas también cambia los resultados. “Obtuvo resultados medibles” es distinto de “cumplió las expectativas”, “entró en producción” o “generó retorno financiero”.
La selección de la muestra también importa. Una encuesta de líderes tecnológicos puede producir resultados distintos de un estudio de usuarios de negocio, equipos financieros o proyectos individuales.
El denominador crea otro problema. Algunos estudios cuentan cada prototipo. Otros incluyen únicamente despliegues en producción o iniciativas conocidas por líderes sénior.
Los horizontes temporales también difieren. Un sistema de IA puede necesitar varios trimestres de rediseño del flujo de trabajo y adopción antes de que aparezcan sus beneficios.
Declararlo un fracaso después de un trimestre puede ser prematuro. Continuar indefinidamente sin pruebas puede desperdiciar más capital.
Estas limitaciones no invalidan las conclusiones de IDC. Definen lo que los lectores pueden concluir responsablemente a partir de ellas.
La conclusión más sólida es que las empresas tienen dificultades para medir y repetir el valor de la IA. La conclusión más débil es que un porcentaje fijo de todos los proyectos fracasó definitivamente por la misma razón.
La distinción también afecta a la rendición de cuentas. Si se culpa automáticamente al modelo, las organizaciones pueden reemplazar proveedores mientras mantienen los problemas de flujo de trabajo, datos y gobernanza que causaron resultados débiles.
Si se atribuye cada problema a la preparación organizativa, los proveedores pueden eludir la responsabilidad por productos poco fiables. Ambas narrativas merecen escrutinio.
La calidad del modelo sigue importando. Las alucinaciones, el razonamiento inconsistente, la latencia, el contexto limitado y los errores en el uso de herramientas pueden hacer que una aplicación no sea adecuada para producción.
El diseño del proveedor también importa. Los compradores necesitan registros de auditoría utilizables, controles de permisos, avisos de cambios en el modelo, herramientas de evaluación y un comportamiento de servicio predecible.
Las organizaciones siguen siendo responsables de seleccionar casos de uso apropiados y configurar el acceso de forma segura. Los proveedores siguen siendo responsables de describir con precisión las capacidades y limitaciones.
Por tanto, el debate sobre el fracaso de proyectos de IA de IDC debería generar mejores preguntas, no un único culpable conveniente.
¿Qué línea base pretendía mejorar el proyecto? ¿Qué responsable de negocio aceptó el objetivo? ¿Se incluyeron los costes de seguridad y operación antes de la aprobación?
¿Los empleados utilizaron el sistema cuando terminó el soporte del piloto? ¿La calidad de los resultados siguió siendo aceptable ante casos poco frecuentes y datos cambiantes?
¿Podían los equipos reconstruir las acciones de un agente después de un error? ¿Podían detener el flujo de trabajo de inmediato sin desactivar sistemas no relacionados?
Esas preguntas convierten un titular controvertido en una revisión operativa. También son más difíciles de responder que determinar si un piloto se lanzó a tiempo.
Una comparación independiente refuerza la necesidad de cautela. Gartner informó de que el 45% de las organizaciones con alta madurez mantuvieron operativos proyectos de IA durante al menos tres años.
Su encuesta sobre madurez de IA vinculó la longevidad con prácticas maduras, pero la longevidad por sí sola no demuestra valor empresarial.
Un proyecto puede mantenerse operativo por razones estratégicas o políticas. Un proyecto también puede finalizar después de transferir con éxito su capacidad a otra plataforma.
Ninguna métrica por sí sola recoge el resultado completo. Las organizaciones necesitan una visión de cartera que separe el rendimiento técnico, la adopción, el impacto financiero, el riesgo y el valor estratégico.
Esa cartera debe incluir proyectos sin éxito. Ocultar pilotos abandonados crea una imagen engañosa e impide que los equipos reconozcan causas recurrentes.
También debe distinguir entre una cancelación saludable y un fracaso descontrolado. Terminar pronto un proyecto débil puede demostrar una gobernanza disciplinada en lugar de un mal desempeño.
Una fuente de CIO.com describió como saludable cancelar aproximadamente un tercio de los proyectos iniciados. La organización utilizó financiación por etapas y puntos de control de resultados para impedir que el trabajo débil consumiera recursos permanentes.
Ese enfoque replantea el fracaso. El proyecto peligroso no siempre es el que se detiene. Puede ser el que continúa sin pruebas porque nadie asume la decisión.
Tres Señales Que los CIO Deben Vigilar a Continuación
La próxima prueba es si las organizaciones sustituyen el recuento de pilotos por informes de resultados, autonomía controlada y pruebas de que los empleados utilizan la IA en flujos de trabajo reales.
La primera señal es la adopción de manuales formales de valor de IA. IDC espera que al 60% de los CIO de Asia-Pacific 500 se les encargue crearlos para 2027.
Un manual de valor estandariza la selección de casos de uso, las líneas de base, los modelos de costes, la responsabilidad y los umbrales de revisión. Permite a los líderes comparar proyectos con evidencia coherente.
Esta señal reforzaría el argumento de IDC si las organizaciones empiezan a cerrar proyectos que carecen de resultados medibles. Lo debilitaría si la medición formal se amplía sin mejorar el rendimiento de la cartera.
La métrica clave no es el número de manuales publicados. Es la proporción de iniciativas en producción con responsables designados, líneas de base, costes operativos completos y revisiones programadas de resultados.
Los consejos de administración también deberían observar cómo las organizaciones informan sobre beneficios indirectos. La confianza de los clientes, la resiliencia y una toma de decisiones más rápida pueden importar, pero cada uno requiere un método de medición observable.
La segunda señal es el despliegue de controles exigibles para agentes. Las políticas por sí solas no pueden gobernar software que actúa de forma continua en los sistemas empresariales.
Los CIO deberían hacer seguimiento de cuántos agentes tienen identidades dedicadas, permisos limitados, registros completos de acciones, reglas de escalamiento a humanos y procedimientos de apagado probados.
Los equipos de seguridad también deberían informar de los incidentes por gravedad y causa raíz. Un aumento del número de incidentes puede reflejar tanto un deterioro de la seguridad como una mayor visibilidad de actividad antes oculta.
La tendencia más significativa es si los incidentes graves disminuyen a medida que se amplía el uso de agentes. Las organizaciones deberían comparar las tasas de incidentes con las acciones de los agentes, los sistemas conectados y los niveles de riesgo.
Las perspectivas de IDC para Asia-Pacífico prevén consecuencias graves por controles inadecuados de los agentes, incluida la exposición legal y la responsabilidad de los directivos. Ese pronóstico resulta más creíble si los despliegues autónomos se expanden más rápido que la supervisión técnica.
Resulta menos creíble si las organizaciones demuestran que los controles basados en riesgos escalan con el uso. La evidencia debería incluir resultados de auditorías, tiempos de contención, infracciones de permisos e intervenciones humanas exitosas.
La tercera señal es la adopción en producción vinculada a resultados de los flujos de trabajo. La precisión en pilotos y el entusiasmo de los empleados no pueden sustituir el uso sostenido en las operaciones diarias.
Los CIO deberían supervisar el uso activo, las tasas de finalización, la frecuencia de excepciones, el tiempo de revisión y el porcentaje del trabajo generado que alcanza un resultado útil.
También deberían medir qué ocurre cuando disminuye el soporte posterior al despliegue. Un sistema que depende de la intervención constante de sus creadores no ha alcanzado una producción repetible.
Las unidades de negocio deben informar si la IA acorta los tiempos de ciclo, amplía la capacidad, reduce los errores o mejora los resultados para los clientes. Los equipos financieros deberían verificar cualquier ahorro declarado.
Esta señal reforzaría la narrativa de google news si el uso crece mientras el valor medible sigue siendo débil. Mostraría que la adopción por sí sola no puede resolver el problema del ROI.
Debilitaría esa narrativa si los programas maduros demuestran ganancias repetibles en varios flujos de trabajo después de incluir todos los costes de seguridad y operación.
Estas tres señales están conectadas. Mejores modelos de valor seleccionan casos de uso más sólidos, controles más robustos permiten una autonomía segura y la adopción sostenida de los flujos de trabajo genera evidencia medible.
Eliminar un elemento produce un resultado frágil. Un sistema rentable sin controles conlleva una exposición oculta. Un sistema seguro sin usuarios no crea valor.
Un sistema popular sin mediciones de línea de base genera una actividad impresionante, pero retornos inciertos.
Los CIO deberían resistir la presión de responder al debate con otro porcentaje general. Sus propias carteras aportan evidencia más útil que un titular agregado.
Pueden empezar seleccionando un pequeño número de flujos de trabajo relevantes y documentando el rendimiento actual. Cada proyecto debería contar con un responsable de negocio, un responsable técnico, una clasificación de riesgo y un calendario de revisión.
Los equipos deberían calcular los costes más allá del desarrollo inicial. Esos costes incluyen el uso de modelos, el mantenimiento de integraciones, la supervisión, las evaluaciones, la seguridad, el soporte y la revisión humana.
Deberían definir los resultados inaceptables antes de conceder autonomía. Esos límites pueden abarcar la exposición de datos, los límites financieros, el impacto en los clientes y las acciones de herramientas prohibidas.
Por último, deberían publicar los resultados internos, incluidas las cancelaciones. La presentación transparente de informes dificulta que los proyectos débiles sobrevivan solo gracias al entusiasmo.
Por tanto, la controvertida afirmación del 45 % es útil como advertencia, no como una tarjeta de puntuación universal. Expone la facilidad con la que una medición imprecisa se convierte en un titular seguro sobre IA.
La mejor respuesta no es debatir sobre un porcentaje de google news. Es exigir pruebas de que cada sistema de IA crea valor después de contabilizar todos sus costes y riesgos.
¿Qué proyectos superarían esa prueba dentro de su organización y cuáles siguen financiados porque nadie ha definido qué significa el éxito?
