Evaluación de preparación para la IA: qué corregir antes de implementar la IA

Un equipo de operaciones de mercado medio realiza el cuestionario del proveedor, obtiene una puntuación de 3.8 sobre 5 y se declara listo para la IA. Seis semanas después, el piloto se estanca. El flujo de trabajo que intentaban automatizar nunca se había documentado. Nadie podía aprobar las acciones del agente una vez que este accedía al registro de un cliente. La puntuación era real. La preparación nunca lo fue.

Una evaluación de preparación para la IA es el análisis que determina si un flujo de trabajo específico puede incorporar IA de forma segura ahora mismo, si necesita un rediseño previo o si debe esperar. A finales de 2025, la investigación sobre el estado de la IA de McKinsey reveló que el 88% de las organizaciones reportaban un uso regular de la IA, pero solo el 39% observaba algún impacto en el EBIT a nivel de toda la empresa, y para la mayoría ese impacto se mantenía por debajo del 5%. La brecha no está en la calidad del modelo, sino en las condiciones operativas que lo sustentan.

La mayoría de las evaluaciones se limitan a asignar una etiqueta de madurez. Esta guía plantea la evaluación como un proceso de decisión descendente: acotar un flujo de trabajo, desmontar las ilusiones de las puntuaciones y abordar los bloqueos que determinan el veredicto en el orden real en que suelen hacer fracasar los pilotos. Al finalizar, dispondrá de una decisión clara para construir, comprar, configurar, pilotar o esperar respecto a un flujo de trabajo concreto, además de un plan de 30-60-90 días para resolver las carencias identificadas.

Paso 1: ¿Qué decisión debe tomar realmente una evaluación de preparación para la IA?

Una evaluación de preparación para la IA es un veredicto de viabilidad de despliegue a nivel de flujo de trabajo. Responde a una pregunta para un caso de uso específico: ¿puede la IA ejecutar este flujo de trabajo de forma segura ahora, necesita el flujo de trabajo un rediseño previo o debe esperar? Una evaluación de madurez de IA mide qué tan avanzada se ve una organización en general. La preparación decide si un proceso específico es desplegable.

Robert Half define el objetivo central de la preparación de manera directa, en sus propias palabras:

La preparación para la IA se refiere a la capacidad de una organización para adoptar, implementar y escalar con éxito las tecnologías de IA... de una manera que entregue un valor comercial significativo. — Robert Half, AI Readiness Plan for Tech Leaders (2025)

El trabajo académico, según la investigación de preparación para la digitalización de Palade & Carutasu, trata la preparación como una extensión de la práctica de madurez digital.

Por qué una puntuación no es una decisión

A principios de 2025, McKinsey descubrió que casi todas las empresas estaban invirtiendo en IA, mientras que solo alrededor del 1% de los líderes consideraban que su organización estaba madura en el despliegue de IA. Esa cifra, proveniente de la investigación Superagency in the Workplace de McKinsey, replanteó la adopción de la IA como un problema de liderazgo en lugar de una brecha de habilidades.

Preparación frente a madurez, en una línea

La madurez describe a la organización. La preparación determina si un flujo de trabajo específico es seguro de automatizar ahora. El resto de esta guía construye ese veredicto, bloqueador por bloqueador. Para los equipos que ya están invirtiendo en trabajo impulsado por IA, el artículo complementario sobre cómo usar la IA para la innovación aborda dónde suele concentrarse el beneficio.

Paso 2: ¿Por qué acotar un flujo de trabajo antes de evaluar a toda la empresa?

Evaluar a toda la empresa es un enfoque demasiado amplio para tomar decisiones. Un alcance tan extenso solo produce una etiqueta. Quien mucho abarca, poco aprieta. La unidad operativa es un flujo de trabajo, un objetivo de negocio, un límite de riesgo, un siguiente paso. Acote el alcance lo suficiente como para que el responsable de un único proceso pueda describir cada paso, cada excepción y el coste de cometer un error. La evaluación a nivel de toda la empresa produce una etiqueta. La acotación por flujo de trabajo produce algo sobre lo que se puede actuar.

El propio marco de preparación de Microsoft advierte contra el error de tratar esto como un ejercicio de una sola vez. Su equipo de Copilot Studio describe la preparación de los agentes como una alineación continua de personas, procesos y tecnología que exige una reevaluación cada vez que cambian las condiciones. Esta es la razón práctica para acotar a pequeña escala: la evaluación se vuelve a ejecutar cada vez que cambia el flujo de trabajo, sus datos o sus controles.

Cómo es un flujo de trabajo delimitable

"Mejorar la atención al cliente con IA" es una ambición. "Redactar borradores de primera respuesta a preguntas de facturación, utilizando los últimos 12 meses de tickets resueltos, con un humano que apruebe cada envío" es un flujo de trabajo. La segunda versión mapea lo que toca el agente (entrada y corpus) frente al costo de una mala decisión. Solo la segunda versión se puede evaluar.

Tres preguntas de delimitación

Antes de evaluar cualquier pilar, responda tres preguntas para el flujo de trabajo candidato: cuál es el objetivo único y cómo lo medirá, cuál es el peor resultado si la IA se equivoca y quién lo asume, y cómo se ve la prueba piloto más pequeña en 90 días sin tocar una ruta regulada o crítica para los ingresos. Las respuestas vagas significan que el flujo de trabajo aún no está delimitado. Evaluarlo de todos modos solo ocultaría la brecha.

El costo de evaluar de manera demasiado amplia

McKinsey descubrió que las empresas de alto rendimiento tienen aproximadamente tres veces más probabilidades de rediseñar flujos de trabajo específicos en torno a la IA que de implementarla en todo a la vez. Un alcance acotado obliga a discutir el rediseño, mientras que un alcance amplio permite esquivarlo.

Paso 3: ¿Qué errores en la tarjeta de puntuación convierten la preparación para la IA en puro teatro?

El fallo común consiste en asignar el mismo peso a cada pilar y considerar que un promedio alto es una autorización para el despliegue. Un solo obstáculo sin resolver invalida una puntuación media alta. Las organizaciones que diluyen sus obstáculos en promedios no los eliminan, los consolidan. Los promedios ocultan el único impedimento crítico que arruina el piloto. Las tres trampas recurrentes son la dispersión de pilotos, la IA en la sombra (shadow AI) y la automatización de procesos defectuosos. Cada una de ellas parece un avance en la tarjeta de puntuación, pero en producción se comportan como deuda técnica.

El estudio NANDA del MIT sobre despliegues empresariales reveló que aproximadamente el 95% de los pilotos de IA generativa tuvieron un impacto nulo o insignificante en los beneficios medibles, situando la causa raíz en la integración y el ajuste del flujo de trabajo, más que en la capacidad bruta del modelo. Su autor principal describió el mecanismo de forma directa.

Las herramientas genéricas como ChatGPT son excelentes para uso individual por su flexibilidad, pero se estancan en el ámbito empresarial porque no aprenden de los flujos de trabajo ni se adaptan a ellos. — Aditya Challapally, MIT NANDA, The GenAI Divide (2025)

Conceptos erróneos comunes

• "Una puntuación de madurez alta significa que estamos listos." Un promedio sólido puede ocultar una única brecha que actúe como bloqueo. El índice de 2025 de Cisco reveló que solo alrededor del 13% de las organizaciones se clasifican como "Líderes" completamente preparados, y la diferencia se manifiesta en pilares específicos como las directrices de seguridad y la gestión del cambio, no en la calificación general.
• "El uso generalizado de la IA demuestra la preparación." La adopción sin gobernanza constituye IA en la sombra (shadow AI). La investigación de 2025 de UpGuard descubrió que más del 80% de los trabajadores utilizan herramientas de IA no aprobadas, siendo los ejecutivos unos de los usuarios no autorizados más frecuentes y menos del 20% de los trabajadores limitándose a las opciones aprobadas por la empresa.
• "Automatizar un proceso lento siempre es una victoria". En realidad, automatizar un proceso roto y no documentado solo escala el desorden. El canon de los profesionales de la automatización, que se remonta al manual de 2020 de Tom Taulli, advierte que codificar el trabajo manual repetitivo y las excepciones no documentadas solo hace que los fallos ocurran más rápido. Ese enfoque proviene de Tom Taulli's RPA Handbook, el canon de los profesionales de la automatización en el que se apoya esta guía para los modos de fallo en la gestión de excepciones.

Steelman: ¿carecen de valor las tarjetas de puntuación?

OWASP mantiene un proyecto formal de Evaluación de Madurez de IA, y los modelos estructurados cumplen una función real.

Los modelos de madurez de IA proporcionan la estructura para crecer con intención, evaluar el riesgo y escalar capacidades de manera medible. — G2, AI Maturity Model: How to Assess and Scale

Un modelo de madurez es una herramienta de gobernanza legítima. Se convierte en teatro solo cuando su resultado promedio reemplaza la decisión del flujo de trabajo. Conserve la tarjeta de puntuación para realizar el seguimiento del progreso, pero no permita que responda a la pregunta de implementación.

Paso 4: ¿Cómo se inventarían las decisiones ocultas que un agente de IA tendrá que deducir?

La capa oculta de la preparación es el contexto documentado. Si un flujo de trabajo se basa en criterios no escritos, gestión de excepciones y memoria institucional, un agente de IA tendrá que inferirlos, y cometerá errores en algunos de ellos. Este paso mapea la lógica de decisión real del flujo de trabajo: la ruta principal, las excepciones, las reglas de escalado y el conocimiento tácito que actualmente solo reside en la cabeza de alguien.

Dos encuestas independientes de 2025 coinciden en el mismo bloqueador. La encuesta de Lucid de 2025 a aproximadamente 2,200 trabajadores del conocimiento reveló que solo el 16% describe sus flujos de trabajo como extremadamente bien documentados, y el 46% afirma que las operaciones dependen principalmente del conocimiento informal o institucional. La propia Encuesta de preparación para la IA de 2025 es la fuente. La encuesta de Microsoft a 500 tomadores de decisiones sobre agentes en 13 países llegó a la misma conclusión a partir de una muestra diferente.

El 78% reportó vacíos al capturar los procesos de negocio y las dependencias de datos para completar sus flujos de trabajo. No se puede identificar lo que no se ha mapeado. — Jack, Microsoft Copilot Studio, Marco de preparación de agentes (2025)

El problema de la ruta de excepción

Los humanos manejan las excepciones con un encogimiento de hombros y un mensaje de Slack. Un sistema de IA agéntica las maneja adivinando. Un flujo de trabajo de reembolso puede tener una ruta documentada y nueve decisiones subjetivas no escritas sobre buena voluntad, señales de fraude y cuentas VIP. En esas nueve es donde un agente de IA inventa políticas silenciosamente. Los sistemas de IA no funcionan con ambición. Funcionan con contexto documentado, límites de permisos y lógica de decisión.

Qué significa realmente "suficientemente documentado"

Un mapa de flujo de trabajo utilizable identifica el desencadenante y los pasos ordenados, y luego documenta la capa de gobernanza que cubre cada regla de ramificación, controlador de excepciones y criterio de éxito. Si alguno de estos elementos reside únicamente en el conocimiento informal del equipo, el flujo de trabajo necesita una revisión de documentación antes de un piloto, no después.

Los propietarios del proceso y los operadores de primera línea revelan las lagunas de documentación cuando recorren juntos el flujo de trabajo. Siente al propietario del proceso y a un operador de primera línea en la misma sala y pídales que recorran el flujo de trabajo de extremo a extremo, incluyendo cada momento de "bueno, depende". Las diferencias entre sus dos versiones son las rutas de excepción que un agente tendría que inventar. Esta es la misma disciplina que hace que los bucles de retroalimentación de innovación funcionen: dibuje el circuito antes de conectarle nada.

Paso 5: ¿Son sus datos lo suficientemente buenos o está buscando la perfección de los datos?

El flujo de trabajo acotado necesita datos delimitados, con permisos y trazables que sean lo suficientemente buenos para la tarea y lo suficientemente seguros para supervisar. La perfección de los datos a nivel empresarial es un programa de una década. Un piloto acotado necesita suficiencia local. Evalúe la sección que realmente delimitó y deje el resto del patrimonio de datos para un ciclo posterior.

La encuesta de preparación de Microsoft identifica el acceso a los datos como la restricción estricta para el despliegue de agentes.

El 80% informa que los datos no son fácilmente accesibles entre sus equipos... Si esos datos no son accesibles, el número de casos de uso viables se desploma antes de empezar. — Jack, Microsoft Copilot Studio, Agent Readiness Framework (2025)

El índice de Cisco define los datos centralizados como uno de los pilares que separa a las organizaciones preparadas del resto. Lo suficientemente centralizado para supervisar es el umbral del piloto. La unificación perfecta es un programa de varios años. El acceso supervisado al corpus acotado es el estándar que realmente condiciona un piloto.

Suficiencia de datos, dimensión por dimensión

Cuatro dimensiones determinan si el corpus delimitado supera el umbral: acceso (alcanzable por el agente con permisos claros, no bloqueado en un sistema que nadie puede leer mediante programación), frescura (lo suficientemente actualizado para que una respuesta obsoleta sea molesta, no peligrosa), trazabilidad (cada salida se remonta a un registro de origen) y acotación (un corpus finito, curado y delimitado por permisos, no un lago de datos abierto).

La verificación de datos falla cuando el desorden afecta los controles de acceso, la trazabilidad o la acotación del flujo de trabajo específico. De lo contrario, la verificación delimitada se sostiene por sí misma. Continúe. Si falla la trazabilidad, deténgase, porque no se puede monitorear lo que no se puede reconstruir.

Paso 6: ¿Cuánto le cuesta la deuda técnica como impuesto de IA?

Las limitaciones de integración acaban con más pilotos que la capacidad del modelo. Las integraciones frágiles, los sistemas heredados y la falta de APIs convierten habitualmente un piloto viable en una reescritura larga y costosa. La deuda técnica es una dimensión de la preparación, pero importa después del flujo de trabajo y los datos, porque esos bloqueos previos suelen decidir si vale la pena financiar el trabajo de integración. Trate la deuda técnica como un impuesto sobre el tiempo de entrega y calcule su precio antes de comprometerse.

En su investigación de abril de 2025, Robert Half descubrió que el 46% de los líderes tecnológicos señalaron la integración de sistemas heredados y el abordaje de la deuda técnica como un desafío principal, y el 63% citó la contratación de talento en IA y ciencia de datos como una barrera crítica.La investigación de Robert Half muestra que el patrón se repite en los estudios de preparación empresarial: el modelo funciona bien en la demostración, pero luego la capa de integración consume el cronograma.

Una demostración prueba la preparación del modelo. Nada más. No dice nada sobre si el agente puede escribir de vuelta en el CRM, respetar los permisos a nivel de registro o sobrevivir a un cambio en una API descendente. Séneca advirtió que sufrimos más en la imaginación que en la realidad, pero con la deuda heredada ocurre lo contrario. El sufrimiento en producción supera cualquier cosa que la demostración sugiriera. Cuando la lógica real de un flujo de trabajo reside en código de acoplamiento heredado, automatizar la interfaz solo expone la deuda más rápido. Si la ruta de integración requiere una reescritura de la plataforma de varios trimestres, el veredicto de preparación honesto para este trimestre suele ser "esperar", y decidir eso es tarea del Paso 10.

Paso 7: ¿Qué controles deben existir antes de que cualquier piloto entre en producción?

El fracaso en la transición de piloto a producción suele ser un problema de control. El modo de fallo es la profundidad de la gobernanza. No es un problema del proveedor. Es un problema de control. Eisenhower lo entendió: los planes no valen nada, pero la planificación lo es todo. Lo que quería decir es que el proceso de analizar el control (quién aprueba qué, quién puede detenerlo, quién es el propietario del registro) es más valioso que cualquier documento que se produzca. Un flujo de trabajo no está listo cuando nadie puede aprobar acciones sensibles, inspeccionar registros o detener el sistema de forma segura. El requisito fundamental es la trazabilidad. Los puntos de aprobación designados reciben la mayor atención, pero el monitoreo en vivo, los controles de reversión y el registro de auditoría que permite reconstruir cualquier decisión a posteriori son lo que hace que el despliegue de un agente sea gobernable y no meramente funcional. Los documentos de políticas estáticas no cuentan. El control en vivo sí.

Solo el 24% de las organizaciones pueden controlar las acciones de los agentes con barreras de seguridad adecuadas y monitoreo en vivo, frente al 84% de los "Líderes de ritmo" preparados, según el [Cisco's AI Readiness Index](https://www.cisco.com/c/dam/m/en_us/solutions/ai/readiness-index/2025-m10/documents/cisco-ai-readiness-index-2025-realizing-the-value-of-ai.pdf). Esa brecha es un predictor directo de qué pilotos sobreviven al contacto con la producción. La auditabilidad es una condición previa de preparación. La investigación contable revisada por pares trata la capacidad de inspeccionar, registrar y revisar las acciones de la IA como un requisito de umbral antes de desplegar la IA en tareas de impacto.

Monitoreo en tiempo real frente a políticas estáticas

Un PDF de políticas es un deseo. El monitoreo en tiempo real es un control. La política dice que el agente "debería" escalar las acciones de riesgo. El monitoreo en tiempo real significa que las acciones del agente se transmiten a un panel de control, un humano puede intervenir a mitad de la tarea y cada decisión se registra junto con sus entradas. Los entornos regulados llevan esto más allá, lo cual se aborda en el Paso 13 con los requisitos de interacción humana de la FDA.

Una lista de verificación de gobernanza mínima

Antes de que un piloto afecte a un flujo de trabajo real, confirme que existan cinco controles. Una persona designada es responsable de las aprobaciones de acciones sensibles, cada acción del agente se registra y es reconstruible, y un interruptor de apagado de emergencia puede detener el flujo de trabajo sin necesidad de un despliegue. El acceso está limitado al corpus del flujo de trabajo en lugar de a todo el patrimonio de datos. Alguien revisa una muestra de resultados monitoreados con una frecuencia fija.

Cuándo es aceptable una gobernanza ligera

La profundidad de la gobernanza debe coincidir con el nivel de riesgo del flujo de trabajo. Un flujo de trabajo que redacta resúmenes de reuniones internas, sin acción externa y con un humano que lee todo antes de que vaya a cualquier parte, no necesita la misma superficie de control que uno que maneja dinero de los clientes. La prueba es la reversibilidad y el radio de impacto (el alcance total del daño si el sistema produce un resultado incorrecto, quién se ve afectado, qué tan rápido y si se puede deshacer). Si un resultado incorrecto es barato de detectar y barato de deshacer, un camino de aprobación más ligero es defendible. Si la acción es irreversible o está de cara al cliente, la lista de verificación completa es el precio de un piloto. Los patrones de gobernanza de innovación federada se aplican aquí: la autonomía distribuida aún necesita salvaguardas centrales.

Paso 8: ¿Puede su personal absorber realmente el cambio?

Cuando la autoridad de decisión no está asignada, los despliegues fracasan independientemente de la preparación técnica. Si los propietarios de los procesos, los operadores, el equipo de seguridad y el liderazgo no se han puesto de acuerdo sobre los cambios de roles, las rutas de escalada y los criterios de éxito, el piloto se estanca después de la demostración. La brecha rara vez se debe a la falta de habilidades técnicas. Se trata de la falta de asignación de responsabilidades sobre las nuevas decisiones, excepciones y revisiones que genera un flujo de trabajo de IA. La capacidad de absorción del cambio predice la escala mejor que el entusiasmo, y está estrechamente ligada a la salud general de la cultura de innovación de una organización.

El [índice de Cisco](https://www.cisco.com/c/dam/m/en_us/solutions/ai/readiness-index/2025-m10/documents/cisco-ai-readiness-index-2025-realizing-the-value-of-ai.pdf) cuantifica la diferencia: el 91% de las organizaciones preparadas cuentan con un plan de gestión del cambio, frente al 35% del resto. El trabajo revisado por pares añade que las barreras son tanto psicológicas y organizativas como técnicas, razón por la cual la capacitación por sí sola no las resuelve.

Brecha de habilidades frente a brecha del modelo operativo

La capacitación resuelve una brecha de habilidades. Una brecha en el modelo operativo, donde nadie asume la responsabilidad de las excepciones del agente y la autoridad de decisión no está asignada, requiere reasignar las decisiones a personas específicas. Confundir ambas de forma temprana reduce la evaluación a un plan genérico de capacitación.

Paso 9: ¿Cómo clasifica los casos de uso por beneficio, complejidad y riesgo?

Una vez que los bloqueos son visibles, es posible priorizar los casos de uso. Califique cada flujo de trabajo candidato según el valor de negocio, la viabilidad técnica y la preparación, y luego aplique los riesgos y las brechas de documentación como penalizaciones en lugar de promedios. La plantilla de matriz de priorización de InitializeAI pondera el valor de negocio entre un 35 y un 45% y la viabilidad entre un 25 y un 35%, aplicando el riesgo y la preparación de los datos como penalizaciones. El primer piloto adecuado rara vez es el caso de uso de mayor valor. Es el flujo de trabajo con un beneficio real y un riesgo aburrido y acotado. Esta es la misma lógica detrás de una buena prueba de validación de mercado: barata, acotada e informativa antes de comprometer un presupuesto real.

Una clasificación práctica

Tomemos tres flujos de trabajo candidatos. Los cambios de precios autónomos obtienen una puntuación de beneficio potencial muy alto y complejidad alta, pero la penalización es grave: acciones financieras en vivo con salvaguardas mínimas, exactamente el perfil que señala el Paso 7. A pesar de tener el beneficio potencial bruto más alto, el veredicto es esperar. La extracción de cláusulas contractuales obtiene una puntuación de beneficio potencial medio y complejidad media, con una penalización moderada por la revisión legal que requiere. El veredicto es rediseñar y luego realizar un piloto. Los borradores de primera respuesta de facturación obtienen una puntuación de beneficio potencial medio y complejidad baja, con una penalización cercana a cero porque un humano aprueba cada envío frente a un corpus delimitado. El veredicto es realizar el piloto ahora, por delante de la opción de mayor beneficio potencial. Una sola brecha en las salvaguardas o en la documentación debería descartar un caso de uso incluso cuando su puntuación de valor bruto parezca sólida: diluir esa penalización mediante promedios es la forma en que las organizaciones eligen un piloto llamativo que fracasa en el segundo mes.

Paso 10: ¿Cómo se toma la decisión de construir, comprar, configurar, pilotar o esperar?

La evaluación demuestra su valor real solo cuando concluye en una decisión de flujo de trabajo. Existen cinco opciones, que van desde desarrollos a medida y compras especializadas hasta acciones de menor compromiso como la configuración, el pilotaje o una pausa deliberada. Una evaluación de preparación para la IA que termina en una puntuación de madurez en lugar de en una decisión de flujo de trabajo es mero teatro: la organización se ha calificado a sí misma pero sigue sin decidir nada.

Los controles y la madurez de datos de la organización determinan qué vía de abastecimiento es viable.La investigación sobre la preparación institucional plantea la elección entre una herramienta de modelo fundacional y un sistema autónomo a medida como una decisión de elegibilidad determinada por los controles y los datos de la organización. La evidencia del mercado se inclina hacia la compra: los datos del MIT muestran que los despliegues de proveedores especializados tienen éxito alrededor del 67% de las veces, frente a aproximadamente un 33% en el caso de los desarrollos internos.

La matriz de cinco caminos

Esperar es un veredicto, no un fracaso. Si el flujo de trabajo carece de monitoreo en vivo o de una lógica de decisión documentada, "esperar" junto con un plan a 30-60-90 días es mejor que un lanzamiento que genere una alerta a las 2 a. m. El enfoque basado únicamente en la puntuación de madurez no puede generar esta decisión, porque un 3.8 de 5 no dice nada sobre si construir o esperar específicamente en el flujo de trabajo de facturación.

Paso 11: ¿Qué números predicen el fracaso de un piloto?

Las organizaciones sobreestiman sistemáticamente su preparación en cuatro dimensiones: calidad de la documentación, profundidad de la gobernanza, solidez de la gestión del cambio y capacidad de escalar más allá de un piloto. Considere estos indicadores como predictivos, no como meros adornos. Cada uno de ellos altera el veredicto final, ya que identifica un obstáculo específico que el promedio de madurez suele ocultar.

Lea la tabla como un filtro de preparación. La brecha del 78% en el mapeo de procesos predice fallas en el Paso 4. La cifra del 24% en las medidas de control predice fallas en el Paso 7. La división del 67% frente al 33% representa la inclinación de abastecimiento del Paso 10. Juntos explican el titular del 95%: los pilotos fallan porque nunca se evaluaron las condiciones operativas, no porque los modelos fueran débiles.

Paso 12: ¿Qué enseña el despliegue del copilot de Morgan Stanley sobre la preparación?

Un piloto de IA sólido suele tener éxito porque el flujo de trabajo es acotado, el corpus está controlado, el humano permanece en el bucle y los permisos son explícitos. El asistente para asesores de Morgan Stanley, desarrollado con OpenAI, es el ejemplo de nivel empresarial de ese perfil. Vale la pena estudiarlo precisamente porque tiene una gobernanza estricta y está delimitado, no porque sea llamativo.

El despliegue colocó un chatbot sobre un corpus interno aprobado de aproximadamente 100,000 documentos, con asesores e ingenieros de prompts calificando la precisión y coherencia de las respuestas antes de un lanzamiento más amplio, según el caso de estudio de OpenAI sobre el despliegue de Morgan Stanley. Los humanos revisaron y ajustaron los resultados antes de que se finalizara cualquier cosa, y la política de retención de datos cero de OpenAI resolvió la restricción de cumplimiento normativo.Más del 98% de los equipos de asesores utilizan activamente el asistente, y el acceso a los documentos aumentó del 20% al 80%.

Por qué este flujo de trabajo estaba listo

Vincúlelo con los pasos anteriores. El flujo de trabajo estaba acotado (Paso 2): recuperar y resumir a partir de una base de conocimientos definida, no actuar de forma autónoma. El corpus estaba delimitado y con permisos asignados (Paso 5). La gobernanza estaba activa: evaluaciones, revisión humana y una política de retención (Paso 7). Las personas formaban parte del proceso por diseño (Paso 8). Cada obstáculo que la guía secuencia se resolvió antes de escalar, razón por la cual la adopción se mantuvo en lugar de estancarse en una demostración.

Qué lo habría hecho no apto

Cambie tres variables y el veredicto pasa a ser de espera. Un corpus ilimitado que extrajera información de cualquier sistema interno habría fallado la prueba de delimitación del Paso 5. La acción autónoma sin aprobación humana habría fallado la prueba de gobernanza del Paso 7. El paso de calificación no era opcional. Sin asesores e ingenieros de prompts que evalúen la precisión de las respuestas, no hay una base de evidencia que justifique confiar en los resultados a escala, solo suposiciones. La lección es aplicable a otros casos: la preparación es una propiedad de las restricciones del flujo de trabajo, no de la marca del proveedor. La misma lógica sustenta el despliegue de un segundo cerebro digital eficaz, donde el corpus y el bucle de revisión deciden si la herramienta se gana la confianza.

Paso 13: ¿Qué casos límite rompen los marcos de evaluación de preparación genéricos?

Algunos flujos de trabajo fallan con las fórmulas de preparación genéricas. El trabajo regulado, los entornos con escasez de datos y los conflictos de propiedad multifuncionales requieren un umbral diferente para decidir entre "pilotar ahora", "rediseñar primero" o "esperar". En estos casos, una sola dimensión domina el veredicto, y promediarla con las demás produce una puntuación peligrosamente optimista. Identifique el bloqueador dominante y decida en función de él.

En el trabajo regulado, la carga de aprobación y la supervisión demostrable tienen más peso que la calidad del modelo.La guía preliminar de la FDA de enero de 2025 para software de dispositivos habilitados para IA exige que las solicitudes documenten el flujo de trabajo humano-IA, registrando cómo interactúan el humano y el modelo en cada punto de decisión. Esto convierte la decisión de preparación en una cuestión de control: ¿puede demostrar la supervisión en cada paso?

Tres casos límite dependen de un único bloqueador dominante: los flujos de trabajo regulados en salud, finanzas o legal dependen de la carga de aprobación y la auditabilidad, por lo que solo se debe realizar un piloto si la supervisión humana en el bucle (human-on-the-loop) es demostrable de extremo a extremo. Los entornos con escasez de datos dependen del problema del arranque en frío (el período antes de que el sistema haya acumulado suficientes datos de interacción para realizar predicciones seguras y calibradas), por lo que es preferible un piloto basado primero en reglas o asistido por humanos. Los conflictos de propiedad multifuncionales dependen de la falta de un propietario único para las nuevas decisiones, por lo que se debe rediseñar la propiedad primero en lugar de lanzar un piloto al vacío.

La guía de la FDAtambién traza una línea útil entre "human-in-the-loop" (humano en el bucle), que implica la intervención en cada decisión, y "human-on-the-loop" (humano sobre el bucle), que significa una supervisión continua con la capacidad de asumir el control. Una industria estricta aún puede ejecutar un piloto acotado cuando el flujo de trabajo es lo suficientemente estrecho como para que la supervisión siga siendo económica. La regulación en sí rara vez es el impedimento. La incapacidad de la organización para demostrar el control dentro de ella suele serlo.

Paso 14: ¿Cómo se transforman los hallazgos en una hoja de ruta de 30-60-90 días?

Sin responsables asignados, no hay progreso. La evaluación debe concluir con una remediación ordenada y una fecha programada para volver a ejecutar la verificación del flujo de trabajo, secuenciada según la gravedad de los bloqueos identificados en los Pasos 4 al 8 en lugar de abordarlo todo a la vez, resolviendo las brechas de documentación y gobernanza antes que cualquier otra cosa porque bloquean cada paso posterior. Esta secuenciación refleja un modelo de etapas y puertas (stage-gate): cada bloque de 30 días es una puerta que el flujo de trabajo debe superar antes de que se abra la siguiente. Sin responsables designados para cada elemento, el resultado es solo un simulacro de madurez.

El esquema de 30-60-90 días

• Días 0 a 30: Resolver los bloqueos de documentación y acceso. Mapear la lógica de decisión y las excepciones del flujo de trabajo seleccionado. Confirmar que el corpus sea accesible, tenga los permisos correctos y sea rastreable. Asignar un responsable del proceso y un responsable de riesgos.
• Días 31 a 60: Establecer la gobernanza antes de cualquier acción en producción. Implementar el registro de logs y una compuerta de aprobación. Añadir un muestreo de salidas monitoreado y un interruptor de apagado de emergencia una vez que el agente esté en ejecución. Ejecutar evaluaciones contra un conjunto de datos de prueba reservado.
• Días 61 a 90: Lanzar el piloto acotado con supervisión humana (human-in-the-loop). Realizar el seguimiento de la métrica única de éxito definida en el Paso 2. Decidir si desarrollar, comprar, configurar, continuar o detener el proyecto basándose en resultados, no en opiniones.

Haga que el plan sea lo suficientemente específico como para poder debatirse. "Mejorar la documentación" no es un hito. "La responsable del proceso, Priya, mapea las rutas de excepción del flujo de trabajo de reembolsos para el día 21, con la revisión del líder de operaciones" sí lo es. Cada brecha identificada en la evaluación recibe un responsable, una fecha límite y una definición de terminado. Tratar todas las brechas con la misma prioridad en la remediación es la forma en que un plan de 90 días se convierte silenciosamente en uno de 18 meses.

Ejecutar de nuevo de forma periódica

Vuelva a ejecutar la evaluación a nivel de flujo de trabajo cuando el flujo de trabajo, sus datos, su clase de riesgo o su entorno de control cambien sustancialmente. Como mínimo, ejecútela una vez por ciclo de remediación. Asigne un responsable directo y una fecha límite a cada brecha identificada en la evaluación. Sin ambos elementos, los hallazgos suelen persistir más allá de la revisión que los originó.Microsoft plantea la preparación como un proceso continuo en lugar de una credencial que se obtiene una sola vez, lo que convierte la verificación en una disciplina recurrente y no en un evento único: el caso específico de preparación de la previsión continua: tratar la detección de cambios como una práctica constante, no como una auditoría única. Los equipos que desarrollan este hábito con el tiempo también fortalecen su capacidad de absorción, es decir, la habilidad de aplicar lo aprendido en cada piloto en lugar de redescubrir las mismas lecciones en el siguiente ciclo.

Resumen (borrador)

• Una evaluación de preparación para la IA es un veredicto por flujo de trabajo: implementar ahora, rediseñar primero o esperar.
• Defina el alcance de un solo flujo de trabajo primero. Las puntuaciones a nivel de toda la empresa producen etiquetas, no decisiones.
• Solo alrededor del 13% de las organizaciones están completamente preparadas, según el Cisco's AI Readiness Index. Otro 24% puede aplicar medidas de control en tiempo real para supervisar las acciones de los agentes.
• La lógica de decisión no documentada es el principal obstáculo oculto: el 78% de las grandes empresas informan brechas en el mapeo de procesos, según el Microsoft's Agent Readiness Framework.
• No permita que la evaluación se quede solo en observaciones. Comprométase a desarrollar, adquirir, configurar, realizar un piloto o esperar, y luego utilice un plan de 30-60-90 días para hacer operativo ese compromiso.

Preguntas frecuentes

¿Qué debe incluir una evaluación de preparación para la IA?

Una evaluación de preparación para la IA a nivel de flujo de trabajo inspecciona cinco aspectos en orden de criticidad: la lógica de decisión documentada y las rutas de excepción, la suficiencia de los datos para la tarea definida, la deuda técnica y el costo de integración, la gobernanza con monitoreo en tiempo real, y la responsabilidad de la gestión del cambio. El proceso concluye con un veredicto. Las cinco opciones posibles son construir, comprar, configurar, realizar un piloto o esperar, no una puntuación de madurez.

¿Cómo sé si mi empresa está lista para la IA?

Evalúe un flujo de trabajo, no toda la empresa. Estar listo significa que el flujo de trabajo seleccionado cuenta con una lógica de decisión documentada, datos con permisos y trazabilidad, una ruta de integración viable, salvaguardas activas y responsables asignados para las nuevas decisiones. Si falta alguno de estos elementos, la respuesta honesta es rediseñar primero o esperar, con un plan programado para cerrar la brecha.

¿Cuál es la diferencia entre la preparación para la IA (AI readiness) y la madurez de la IA (AI maturity)?

La madurez de la IA mide la capacidad organizativa general, una instantánea en una curva. La preparación para la IA es un veredicto de viabilidad de despliegue acotado a un flujo de trabajo específico.

A principios de 2025, aproximadamente el 1% de los líderes consideraba que su organización era madura, según la investigación Superagency in the Workplace de McKinsey. Esta etiqueta, incluso cuando se alcanzaba, no ofrecía ninguna orientación sobre qué flujo de trabajo estaba listo para automatizarse a continuación.

¿Estamos listos para la IA si nuestros datos aún están desorganizados?

Posiblemente. El desorden a nivel empresarial no descalifica un flujo de trabajo acotado. Lo que importa es si el corpus delimitado es accesible, tiene los permisos correctos, es trazable y es finito. Si se cumplen estas condiciones, el desorden de datos en otras áreas no es un impedimento. Si los resultados no se pueden rastrear hasta los registros de origen, deténgase, ya que no puede monitorear lo que no puede reconstruir.

¿Deberíamos desarrollar, comprar o realizar un piloto primero?

Para la mayoría de los flujos de trabajo acotados, comprar o configurar una herramienta especializada es mejor que desarrollar — la investigación de MIT NANDAencontró que las implementaciones de proveedores tienen éxito alrededor del 67% de las veces, frente al 33% de los desarrollos internos. Desarrolle solo cuando el flujo de trabajo sea un diferenciador duradero y su madurez de datos e integración sea sólida. Realice un piloto cuando el beneficio potencial sea real pero existan brechas de preparación que valga la pena probar bajo monitoreo.

¿Quiénes deben participar en una evaluación de preparación para la IA?

Como mínimo: el responsable del proceso y un operador de primera línea. También se necesita el nivel de riesgo y gobernanza superior, hasta llegar al patrocinio ejecutivo. Cada uno responde a una pregunta de preparación diferente, desde "¿está documentada la lógica?" hasta "¿realmente cambiaremos la forma de trabajar de las personas?". La ausencia del responsable de seguridad o del patrocinador es la razón por la que los pilotos se aprueban en el papel pero se estancan en la producción.

¿Con qué frecuencia se debe repetir una evaluación de preparación para la IA?

Repita la verificación a nivel de flujo de trabajo cada vez que el flujo de trabajo, sus datos, su clase de riesgo o su entorno de control cambien de manera sustancial. Realícela como mínimo una vez por cada ciclo de remediación.Microsoftdescribe la preparación de los agentes como un proceso continuo en lugar de un evento único, por lo que debe tratar la evaluación como un hábito recurrente vinculado al cambio, no como una certificación anual.