Una revisión útil de la cartera de IA debería obligar a que cada piloto termine en una de tres decisiones: escalarlo, resolver una incertidumbre concreta o detenerlo. Todo lo que se llame «en pausa» necesita una dependencia identificada, una persona responsable y una fecha de decisión. Sin eso, la pausa no es más que una decisión de cierre que nadie quiere tomar.
A eso me refiero con una lista de proyectos a cerrar. No es una cuota de fracasos ni un arma contra quienes propusieron las iniciativas. Es un registro visible del trabajo cuyo próximo dólar ya no tiene una justificación defendible. Bien utilizada, la lista devuelve capital, capacidad técnica escasa y presupuesto de riesgo a oportunidades mejores.
Este enfoque cierra el ciclo entre planificar un presupuesto de IA, medir la economía completa de la IA y actuar cuando cambia la evidencia. Una cartera capaz de iniciar experimentos pero incapaz de detenerlos no está aprendiendo. Está acumulando obligaciones.
Continuar también es una decisión
Los pilotos de IA son fáciles de aprobar porque cada uno parece pequeño. El coste de la cartera se esconde en el conjunto: consumo de modelos y plataformas, trabajo de datos, revisión de seguridad, integración, evaluación, soporte y la atención de personas que podrían estar resolviendo otro problema.
Por eso, la revisión debe comparar el siguiente incremento de gasto con el mejor uso alternativo de esos recursos. El dinero ya gastado puede explicar cómo aprendió la organización, pero no refuerza la siguiente solicitud de financiación. El Green Book 2026 de HM Treasury establece la misma distinción: los costes hundidos no deberían decidir el siguiente paso, mientras que el coste de oportunidad de seguir utilizando los recursos sí importa.
No debería existir un plazo universal de seis meses. Un asistente documental y un flujo clínico apoyado por IA tienen necesidades distintas de evidencia y garantías. La disciplina importante consiste en fijar el plazo antes de empezar, ajustarlo a la incertidumbre que se quiere probar y evitar que el equipo mueva la meta después de ver el resultado.
Escribe el contrato de revisión antes del piloto
Cada piloto debería entrar en la cartera con un contrato de revisión breve. Si el equipo no puede completarlo en lenguaje claro, probablemente todavía no está listo para gastar dinero.
| Campo de revisión | Lo que la cartera necesita saber |
|---|---|
| Resultado de negocio | ¿Qué cambia para un cliente, empleado, operación, fuente de ingresos o exposición al riesgo? |
| Punto de partida | ¿Cómo funciona hoy el trabajo sin el sistema de IA propuesto? |
| Objetivo de evidencia | ¿Qué resultado justificaría la siguiente fase y cómo se medirá? |
| Coste completo | ¿Qué exigirán el desarrollo, la operación, la revisión, el control y el soporte? |
| Límite de riesgo | ¿Qué fallo o riesgo residual haría inaceptable continuar? |
| Patrocinador | ¿Quién responde del resultado de negocio y puede tomar la decisión de cierre? |
| Fecha de decisión | ¿Cuándo se revisará la evidencia en lugar de limitarse a informar sobre ella? |
| Plan de salida | ¿Cómo se retirarán accesos, datos, integraciones, proveedores e infraestructura? |
Esto no convierte la innovación en un concurso de trámites. El contrato debe ser proporcional al coste, la complejidad y las consecuencias. Su propósito es impedir que la cartera invente los criterios de éxito después de que el experimento ya haya dado un resultado ambiguo.
El NIST AI Risk Management Framework respalda esta visión del ciclo de vida. Su función Manage exige decidir si un sistema de IA cumple su propósito previsto y si su desarrollo o despliegue deben continuar. También pide mecanismos y responsabilidades asignadas para desconectar o desactivar sistemas cuyo rendimiento o resultados entren en conflicto con el uso previsto.
Utiliza tres resultados reales
En la revisión, elige uno de estos tres resultados y deja constancia del motivo.
- Escalar cuando el piloto haya producido evidencia útil, el coste operativo sea creíble, el riesgo esté dentro de la tolerancia y exista una persona responsable preparada para gestionarlo como producto con soporte.
- Reparar cuando quede una incertidumbre importante que pueda probarse mediante un cambio específico y acotado en el tiempo. Reparar no es permiso para reiniciar todo el piloto con una historia nueva.
- Detener cuando la necesidad de negocio haya cambiado, la evidencia no alcance el umbral, la economía ya no funcione, el riesgo no pueda reducirse hasta un nivel tolerable, el patrocinador haya desaparecido o una opción más sencilla sin IA sea mejor.
La categoría de reparación es donde las carteras suelen perder disciplina. Asígnale una hipótesis, una persona responsable, un límite de presupuesto y una nueva fecha de revisión. Si el equipo vuelve con otro caso de uso, otros usuarios y otros criterios de éxito, se trata de una propuesta nueva, no de una prueba de que la anterior funcionó.
La preparación para producción también merece un listón más alto que una demostración convincente. El modelo mínimo viable de gobierno de IA aporta niveles de riesgo y puertas de evidencia, mientras que las operaciones de IA en el día dos hacen visibles la responsabilidad, la supervisión, la respuesta a incidentes y la recuperación. Si esas obligaciones vuelven poco atractiva la economía, la cartera ha aprendido algo importante antes de escalar la responsabilidad.
Cuenta lo aprendido sin inventar ROI
Un piloto detenido no necesita un retorno de inversión ficticio para tener valor. Informa con honestidad de lo aprendido:
- gasto futuro evitado después de la decisión;
- capacidad devuelta a ingeniería, seguridad, datos y negocio;
- un riesgo o una dependencia retirados;
- una suposición refutada;
- datos de evaluación, trabajo de integración o patrones de control reutilizables; y
- una pregunta de selección mejor para la siguiente propuesta.
Mantén el coste futuro evitado separado del efectivo ya gastado y no cuentes como ahorro el tiempo liberado del personal salvo que la organización pueda mostrar dónde se utilizó esa capacidad. El objetivo es crear un registro de decisiones que mejore la siguiente asignación, no un truco aritmético que haga parecer exitoso cada experimento.
La lista también debería conservar el motivo del cierre. Con el tiempo, las causas recurrentes pueden mostrar problemas de toda la cartera: casos de uso sin punto de partida, responsables de negocio ausentes, datos no preparados, controles añadidos demasiado tarde o economías unitarias que fallan ante requisitos realistas de calidad. Esa evidencia sirve más que un panel que solo muestra cuántos pilotos siguen activos.
Haz que decir la verdad sea seguro
El miedo es un mal modelo operativo. Si detener un piloto se trata como una mancha para el equipo, las personas ocultarán señales débiles, estrecharán la medición y seguirán pidiendo otro ciclo. El diseño de gobierno debe separar la calidad del experimento de la decisión de continuar la inversión.
El patrocinador de negocio responde del resultado. El equipo técnico responde de la integridad de la evidencia. El foro de cartera responde del equilibrio para la empresa. Esta división evita pedir al equipo del proyecto que defienda su propia existencia y evita que una división proteja una iniciativa local a costa de la compañía en su conjunto.
Los líderes marcan el tono al preguntar: «¿Qué hemos aprendido y qué debería recibir ahora esta capacidad?». Es una pregunta más difícil y más útil que «¿Quién ha fracasado?».
Haz la próxima revisión de otra manera
Empieza por todos los pilotos de IA activos, no solo por los que piden más dinero. Entrega a cada patrocinador una página con el contrato de revisión, la evidencia real, la incertidumbre pendiente, el coste completo de la siguiente fase y el resultado recomendado.
Después, toma en la reunión la decisión de escalar, reparar o detener. Publica internamente la lista de cierres con el motivo, la capacidad liberada, el aprendizaje reutilizable y la persona responsable de la retirada. Por último, verifica que credenciales, copias de datos, compromisos con proveedores, integraciones e infraestructura se hayan retirado de verdad. Una decisión en una presentación no es un desmantelamiento.
El objetivo no es cerrar más proyectos de IA. Es asegurar que cada proyecto continúe porque la evidencia actual lo justifica, no porque resulte incómodo detenerlo.
