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 autodenomina listo para la IA. Seis semanas después, el piloto se estanca. El flujo de trabajo que intentaba automatizar nunca se había documentado. Nadie podía aprobar lo que hacía el agente una vez que interactuaba con el 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 manera 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 empresarial, y para la mayoría ese impacto se mantuvo por debajo del 5%. La brecha no está en la calidad del modelo. Está en las condiciones operativas que sustentan al modelo.

La mayoría de las evaluaciones se limitan a asignar una etiqueta de madurez. Esta guía plantea la evaluación como una ruta de decisión que se va estrechando: definir el alcance de un flujo de trabajo, eliminar las ilusiones de las tarjetas de puntuación y luego abordar los bloqueos que determinan el veredicto en el orden real en que suelen frustrar los pilotos. Al finalizar, tendrá una decisión clara de construir, comprar, configurar, pilotar o esperar para un flujo de trabajo concreto, además de un plan de 30-60-90 días para resolver cualquier carencia.

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, requiere el flujo de trabajo un rediseño previo, o debe esperar? Una evaluación de madurez de IA mide qué tan avanzada se encuentra una organización a nivel global. La preparación decide si un proceso específico es desplegable.

Robert Half define el objetivo central de la preparación de forma 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 manera que aporten un valor empresarial 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, aborda 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, analizando un obstáculo a la vez. Para los equipos que ya están invirtiendo en trabajo impulsado por IA, el artículo complementario sobre cómo utilizar la IA para la innovación aborda dónde suele concentrarse el retorno de la inversión.

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 puntuación a nivel de toda la empresa produce una etiqueta. La acotación del 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 Copilot Studio team 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 acotable

"Mejorar el servicio 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 el agente toca (entrada y corpus) frente al costo de una mala decisión. Solo la segunda puede ser evaluada.

Tres preguntas de delimitación

Antes de calificar 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 porción 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. Calificarlo de todos modos solo ocultaría la brecha.

El costo de evaluar de manera demasiado amplia

McKinseyencontró 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 estrecho obliga a discutir el rediseño; un alcance amplio permite esquivarlo.

Paso 3: ¿Qué errores en el cuadro de mando convierten la preparación para la IA en puro teatro?

El fallo habitual consiste en asignar el mismo peso a cada pilar y considerar que un promedio alto equivale a una autorización para el despliegue. Un solo obstáculo sin resolver invalida una puntuación media elevada. Las organizaciones que diluyen sus obstáculos en promedios no los eliminan, los consolidan. Los promedios ocultan el único factor de bloqueo 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 ineficientes. Cada una de ellas parece un avance en el cuadro de mando. Cada una de ellas actúa como una deuda en producción.

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

Las herramientas genéricas como ChatGPT son excelentes para los usuarios individuales 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 de ritmo" (Pacesetters) totalmente preparadas, y la diferencia se manifiesta en pilares específicos como las salvaguardas 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 se limitan 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 hace un inventario de 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 depende de 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 obstáculo. 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 2025 AI Readiness Survey 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, Agent Readiness Framework (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 de criterio 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 nombra el desencadenador 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 fase de documentación antes de un piloto, no después.

Los propietarios de procesos 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 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 datos a nivel empresarial es un programa de una década. Un piloto acotado necesita suficiencia local. Evalúe la sección que realmente ha delimitado 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 más estricta para el despliegue de agentes.

El 80% reporta datos que 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 de las demás. Que estén lo suficientemente centralizados para su supervisión 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 delimitación (un corpus acotado, curado y con permisos definidos, no un lago de datos abierto).

La verificación de datos falla cuando el desorden afecta los controles de acceso, la trazabilidad o la delimitación del flujo de trabajo específico. De lo contrario, la verificación delimitada se sostiene por sí sola. 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 frustran 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 cobra relevancia después del flujo de trabajo y los datos, ya que esos bloqueos previos suelen determinar 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 coste 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 tratamiento 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 viabilidad 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 expectativa de la demostración. 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 que tomará varios trimestres, el veredicto honesto de preparación para este trimestre suele ser "esperar", y esa es una decisión que corresponde al 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 tiempo real, los controles de reversión (rollback) y el registro de auditoría capaz de 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 tiempo real sí.

Solo el 24% de las organizaciones pueden controlar las acciones de los agentes con barreras de seguridad adecuadas y monitoreo en tiempo real, frente al 84% de los "Líderes de vanguardia" 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 sobrevivirán al contacto con el entorno de producción. La auditabilidad es una condición previa para la preparación. La investigación contable revisada por pares considera 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 crítico.

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

Un PDF de políticas es una declaración de intenciones. El monitoreo en tiempo real es un control. La política establece 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 datos de entrada. Los entornos regulados exigen aún más, 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 existen cinco controles. Una persona designada es responsable de las aprobaciones para 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 los riesgos del flujo de trabajo. Un flujo de trabajo que redacta resúmenes de reuniones internas, sin acción externa y con un humano leyendo 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 todavía necesita salvaguardas centrales.

Paso 8: ¿Su personal puede realmente absorber el cambio?

Cuando la autoridad de decisión no está asignada, los despliegues fallan independientemente de la preparación técnica. Si los propietarios de procesos, operadores, seguridad y liderazgo no han acordado los cambios de roles, las rutas de escalamiento 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 crea un flujo de trabajo de IA. La absorción del cambio predice la escala mejor que el entusiasmo, y se alinea estrechamente con 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% de las demás. El trabajo revisado por pares añade que las barreras son tanto psicológicas y organizacionales 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.

Un ejemplo práctico de clasificación

Analicemos 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 severa: acciones financieras en vivo con medidas de seguridad 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 un beneficio potencial medio y una 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 un beneficio potencial medio y una 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 con mayor beneficio potencial. Una sola brecha en las medidas de seguridad 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 medidas de menor compromiso como la configuración, el pilotaje o una pausa deliberada. Una evaluación de preparación para IA que termina en una puntuación de madurez en lugar de 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 las implementaciones de proveedores especializados tienen éxito alrededor del 67% de las veces, frente a aproximadamente el 33% 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 sobre 5 no dice nada sobre si construir o esperar específicamente en el flujo de trabajo de facturación.

Paso 11: ¿Qué cifras 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 aspectos como indicadores adelantados, no como mero adorno. Cada uno de ellos altera el veredicto, ya que cada uno identifica un obstáculo 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 copiloto 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 elemento, 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 estar listo

Cambie tres variables y el veredicto pasa a ser de espera. Un corpus no acotado 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 la 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 califiquen 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 datos escasos 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 tome la decisión en función de este.

En el trabajo regulado, la carga de aprobación y la supervisión demostrable tienen prioridad sobre la calidad del modelo.El borrador de la guía de enero de 2025 de la FDA 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 datos escasos dependen del problema de arranque en frío (el período antes de que el sistema haya acumulado suficientes datos de interacción para realizar predicciones calibradas y confiables), 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 tomar 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 transformar 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 un plan de remediación ordenado y una fecha programada para volver a ejecutar la verificación del flujo de trabajo. Esto se debe secuenciar 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, ya que 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 asignados a cada elemento, el resultado es solo un simulacro de madurez.

La estructura de 30-60-90

• 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 delimitado. 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. Conectar el registro de logs y una puerta de aprobación. Añadir una muestra de salida monitoreada 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). Monitorear la métrica única de éxito definida en el Paso 2. Decidir si desarrollar, comprar, configurar, continuar o detenerse 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 único 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 que identifique la evaluación. Sin ambos, un hallazgo tiende a durar más que la propia revisión que lo generó.Microsoft plantea la preparación como algo 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 desarrollan una mayor capacidad de absorción, la habilidad de aplicar lo que cada piloto enseña en la práctica 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 evaluaciones 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 salvaguardas en tiempo real para controlar 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 reportan 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 trazables, una vía de integración viable, salvaguardas en tiempo real 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 fechado para cerrar la brecha.

¿Cuál es la diferencia entre la preparación para la IA y la madurez de la IA?

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 ganaba, no ofrecía 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 rastreable 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, llegando hasta el patrocinio ejecutivo. Cada uno responde a una pregunta de preparación distinta, 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.