Qué preguntas hacer antes de aprobar un proyecto de IA (guía para directivos)

La mayoría de proyectos de IA no fracasan porque la tecnología no funcione. Fracasan porque nadie hizo las preguntas correctas antes de empezar. Y cuando digo «antes de empezar», no me refiero a antes del primer sprint. Me refiero a antes de aprobar el presupuesto. Antes de decir que sí en la reunión de dirección.

Cuando empecé a usar este checklist de forma sistemática, el patrón fue inmediato: los proyectos que pasaban estas doce preguntas con respuestas concretas tenían muchas más posibilidades de llegar a producción y generar ROI real. Los que no podían responderlas —o respondían con generalidades— entraban en el modo piloto eterno o se cancelaban tras seis meses de trabajo y presupuesto quemado.

No es magia. Es que estas preguntas obligan a sacar a la luz los problemas que existen antes de empezar, cuando todavía se pueden resolver sin coste.

Las 12 preguntas que eliminarán el 80% de los proyectos que nunca van a funcionar

Esta lista no está diseñada para paralizar decisiones. Está diseñada para que las decisiones que se tomen estén basadas en información real en vez de en expectativas optimistas. Si un proyecto no puede responder estas preguntas antes de arrancar, la respuesta correcta no es empezarlo de todas formas y esperar que se aclare solo. La respuesta correcta es dedicar dos semanas más a tenerlas respondidas.

1. ¿Qué problema concreto resuelve?

«Queremos usar IA para ser más eficientes.» Esta frase ha justificado más proyectos fallidos que cualquier otra decisión tecnológica que he visto. No es un problema. Es una aspiración.

Un problema concreto tiene un proceso específico, una métrica actual medible y una métrica objetivo también medible. «Reducir el tiempo medio de respuesta a consultas de clientes de 48 horas a 6 horas» es un problema. «Mejorar la atención al cliente con IA» no lo es.

La pregunta que más proyectos habría salvado: «¿Puedes decirme exactamente qué tarea hace hoy una persona que el sistema de IA haría en su lugar, con qué frecuencia y cuánto tiempo le lleva?» Si no hay respuesta específica para eso, el proyecto no está listo.

2. ¿Cómo se mide si funciona?

La métrica de éxito se define antes de construir, no después. Esta es la regla que más frecuentemente se viola y la que más cara sale cuando se viola.

Si defines la métrica después de construir, siempre encontrarás una métrica que el sistema cumple. Lo cual es completamente inútil como señal de éxito real. «El sistema procesa 200 documentos al día» puede ser verdad y el proyecto puede ser un fracaso completo al mismo tiempo, si lo que importa no es la velocidad sino la precisión.

La métrica debe ser: qué indicador de negocio mejora, cuánto mejora, y en qué plazo. Y debe estar acordada y firmada antes de que el equipo técnico escriba una sola línea.

3. ¿Qué pasa cuando falla?

Todo sistema falla. No estoy siendo pesimista. Es que es un hecho operativo: los sistemas complejos tienen fallos. La pregunta no es si va a fallar, sino cómo se gestiona el fallo cuando ocurre.

Los proyectos que no piensan en los modos de fallo construyen sistemas que funcionan en condiciones ideales y colapsan cuando se encuentran con datos inesperados, volúmenes atípicos o cambios en los procesos de negocio que nadie comunicó al equipo técnico.

Antes de aprobar el proyecto, necesitas saber: ¿qué ocurre si el agente da una respuesta incorrecta? ¿Quién lo detecta? ¿En cuánto tiempo? ¿Qué proceso de escalado existe? ¿Hay un mecanismo de fallback al proceso manual?

4. ¿Con qué datos trabaja y cuál es su calidad?

Garbage in, garbage out. Es el principio más antiguo de la informática y el que más se olvida cuando hay entusiasmo con una tecnología nueva. Un modelo de IA es tan bueno como los datos que consume. Y la calidad de los datos en las empresas medianas suele ser significativamente peor de lo que nadie admite en la reunión de presentación del proyecto.

Las preguntas específicas que hay que hacer: ¿Los datos están estructurados o están en PDFs, emails y documentos Word dispersos? ¿Están actualizados? ¿Quién los mantiene? ¿Hay datos duplicados, inconsistentes o incompletos? ¿Existe un proceso para actualizar los datos cuando el negocio cambia?

He visto proyectos donde el 40% del tiempo de implementación se fue en limpiar y estructurar datos que se asumía que estaban listos. Sin esa información antes de empezar, la estimación de plazo y coste es fiction.

5. ¿Quién supervisa el agente?

Una persona con nombre y apellido, no «el equipo». Esta distinción no es burocrática. Es la diferencia entre responsabilidad real y responsabilidad difusa que en la práctica equivale a que nadie es responsable.

El supervisor del agente es la persona que revisa los outputs de forma periódica, detecta cuando el rendimiento degrada, tiene autoridad para pausar el sistema si algo va mal, y es el punto de contacto cuando hay un problema. Si esa persona no está identificada antes de lanzar, el sistema opera sin control y los problemas se detectan semanas tarde.

6. ¿Hay un gate de calidad antes de que el output llegue al usuario final?

Este es el punto donde más consistentemente fallan los proyectos que arrancan con confianza y terminan siendo desconectados a los tres meses.

Un agente sin revisión independiente no es un sistema robusto. Es un sistema con degradación programada. Los errores se acumulan en silencio —pequeños al principio, invisibles porque el formato es correcto y la velocidad es buena— hasta que llega el error que sí tiene consecuencias visibles, normalmente cuando la confianza en el sistema es máxima y la vigilancia es mínima.

El gate de calidad puede ser un agente crítico —un componente separado cuya única función es revisar el output antes de que salga del sistema— o un checkpoint humano estructurado. Lo que no puede ser es la ausencia de cualquier mecanismo de verificación.

Un sistema de producción que conozco bien tiene cuatro gates obligatorios: antes de implementar, en staging, en producción y en la retrospectiva post-lanzamiento. Ninguna fase avanza sin pasar su gate. La pregunta que un directivo puede hacer directamente al equipo técnico: «¿Cuáles son vuestros gates de calidad y qué ocurre exactamente cuando un output no los pasa?» Si no hay respuesta clara, el proyecto no está diseñado para ser robusto. Puedes leer más sobre este mecanismo en el artículo sobre agentes críticos de revisión.

7. ¿Cuál es el coste real?

El coste de un proyecto de IA tiene dos componentes que habitualmente se confunden o se presentan por separado de forma que el número total nunca aparece con claridad.

El coste de setup incluye el tiempo de desarrollo, la limpieza de datos, la integración con los sistemas existentes y la formación del equipo. El coste de infraestructura mensual incluye las llamadas a la API del modelo, el almacenamiento, el cómputo y el mantenimiento continuo.

Ambos números deben estar sobre la mesa antes de aprobar. Y el coste de setup debe estar amortizado sobre un horizonte temporal realista para que el ROI tenga sentido. Un proyecto que cuesta €40.000 de setup y €2.000 al mes de infraestructura tiene una estructura de costes muy diferente a la de uno que cuesta €8.000 de setup y €800 al mes, aunque ambos prometan el mismo resultado.

8. ¿Cuándo es el break-even?

Esta pregunta obliga a conectar los costes reales del punto anterior con los ahorros o ingresos que el proyecto genera. Y obliga a hacerlo con números, no con estimaciones de «mejora de productividad» sin respaldo.

Si el proyecto ahorra 3 horas semanales a un equipo de 5 personas con un coste medio de €35/hora, eso es €525 a la semana o €27.300 al año. Si el coste total del proyecto es €50.000, el break-even está en 22 meses. ¿Es aceptable ese plazo para la dirección? Esa es una decisión de negocio. Lo que no es aceptable es no tener ese cálculo antes de aprobar.

9. ¿Qué hace IT y qué hace negocio?

La frontera entre la responsabilidad técnica y la responsabilidad de negocio es la fuente de más conflictos no resueltos en proyectos de IA. Cuando algo falla y no está definido quién es responsable de qué, el conflicto se transforma en bloqueo y el proyecto se paraliza.

IT define la arquitectura, construye el sistema, gestiona la infraestructura y garantiza la seguridad técnica. Negocio define el problema que se resuelve, proporciona los datos, valida que el output sea correcto desde el punto de vista de la función, y toma las decisiones sobre qué hacer cuando el sistema falla. Muchos pilotos que no llegan a producción se quedan así justo por no hacerse estas preguntas.

Lo que no puede ocurrir: IT construyendo lo que cree que negocio necesita sin validación continua. O negocio cambiando los requisitos sin comunicación estructurada. Esa frontera debe estar acordada antes de empezar y documentada.

10. ¿Cuáles son los criterios de producción?

Un piloto sin criterios de producción definidos desde el inicio no es un piloto. Es una forma cara de no tomar una decisión. Y los pilotos eternos son el cementerio donde van los proyectos de IA que tenían buenas intenciones pero no tenían gobierno.

Antes de empezar el piloto hay que acordar: ¿qué nivel de precisión tiene que alcanzar el sistema para pasar a producción? ¿Cuánto volumen tiene que procesar sin errores? ¿En qué plazo? ¿Quién toma la decisión de paso? Si el piloto llega al plazo acordado y los criterios no se han cumplido, ¿qué ocurre? ¿Se extiende, se cancela o se rediseña?

Estas decisiones son fáciles de tomar antes de empezar y muy difíciles de tomar cuando hay semanas de trabajo invertidas y el equipo tiene apego emocional al proyecto.

11. ¿Con qué sistemas se integra?

No el stack tecnológico ideal. El stack que existe hoy. El CRM que lleva diez años en producción, el ERP que se implementó en 2015, el sistema de gestión documental que tiene una API de 2012 que nadie quiere tocar porque la última vez que alguien lo intentó se cayó media empresa durante una tarde.

Las integraciones son donde los proyectos se alargan, se encarecen y generan fricciones organizativas que nadie anticipó. Antes de aprobar, hay que tener una respuesta honesta de IT sobre qué sistemas hay que conectar, cuál es el estado de sus APIs o conectores, y cuánto esfuerzo de integración representa cada uno.

12. ¿Qué pasa con los datos de usuarios?

GDPR y AI Act no son detalles que se resuelven al final. Son restricciones que pueden cambiar el diseño completo del sistema si se descubren tarde.

El AI Act, en vigor desde agosto de 2024, impone obligaciones específicas según el nivel de riesgo del sistema de IA. Sistemas que toman decisiones sobre personas —contratación, crédito, acceso a servicios— entran en categorías de riesgo alto con requisitos de transparencia, auditabilidad y supervisión humana obligatoria. Si el proyecto entra en esa categoría y nadie lo ha identificado en la fase de diseño, hay que rediseñar en producción, que es la forma más cara de cumplir con la regulación.

Las preguntas concretas: ¿el sistema procesa datos personales? ¿De clientes, empleados, proveedores? ¿Dónde se almacenan? ¿Qué proveedor de IA procesa esos datos y bajo qué condiciones? ¿Cuál es la base legal del tratamiento? Si hay decisiones automatizadas sobre personas, ¿hay mecanismo de revisión humana? Para profundizar en los errores de implementación más comunes y cómo evitarlos, puedes leer el artículo sobre los 7 errores al implementar IA en empresa.

Lo que estas preguntas no resuelven

Este checklist identifica los proyectos que no están listos para empezar y obliga a tomar decisiones antes de que sean costosas. Eso elimina el 80% de los problemas más frecuentes.

Lo que no hace es decirte cómo aplicar las preguntas 3 a 6 al contexto específico de tu empresa: cómo diseñar el gate de calidad para tu proceso concreto, cómo definir los modos de fallo para tu caso de uso particular, qué tipo de supervisión es la adecuada para tu equipo. Eso requiere conocer tus procesos, tus datos, tu arquitectura técnica y las restricciones de tu organización. No hay respuesta genérica que funcione para todos los casos.

Cómo usarlo en la práctica

La forma más directa de usar este checklist: antes de la reunión de aprobación del proyecto, envíalo al equipo que propone la iniciativa y pide que vengan con las doce respuestas por escrito. No en bullets generales. Con números concretos, personas identificadas con nombre, plazos específicos y supuestos explícitos.

Lo que descubrirás es que los proyectos bien pensados responden estas preguntas sin dificultad porque ya se las han hecho internamente. Los proyectos que todavía no están listos se atoran en dos o tres preguntas y eso te dice exactamente dónde está el trabajo que falta por hacer antes de arrancar.

El objetivo no es bloquear iniciativas de IA. Es que las que arranquen tengan posibilidades reales de llegar a producción y generar el retorno que justifica la inversión.

---

Preguntas frecuentes

¿Estas preguntas aplican igual a proyectos pequeños que a proyectos grandes?

Aplican a cualquier proyecto que vaya a tener un agente o sistema de IA en producción con impacto en procesos de negocio reales. Un proyecto pequeño con buen diseño desde el inicio tiene más probabilidades de éxito que un proyecto grande con requisitos vagos. La escala cambia el coste del error, no la necesidad de responder las preguntas.

¿Quién debería completar este checklist, IT o negocio?

Ambos, por separado, y luego comparar las respuestas. Las discrepancias entre lo que IT cree que el proyecto hace y lo que negocio espera que haga son exactamente los problemas que van a aparecer durante la implementación. Mejor detectarlos antes de empezar que a mitad del desarrollo.

¿Qué hago si el equipo no puede responder algunas de estas preguntas?

Eso es información útil, no un problema. Si no pueden responder la pregunta sobre métricas de éxito, hay que definirlas antes de aprobar el proyecto. Si no pueden responder la pregunta sobre integración con sistemas existentes, IT necesita hacer un análisis técnico previo. El checklist no es una barrera. Es un mapa de lo que falta por resolver.

¿Cómo encaja el AI Act con proyectos de IA internos que no afectan a clientes?

El AI Act aplica también a sistemas que afectan a empleados en decisiones sobre contratación, evaluación de rendimiento, acceso a formación o asignación de roles. Un sistema interno que toma o influye en decisiones sobre personas puede entrar en la categoría de riesgo alto independientemente de si tiene cara al cliente o no. La recomendación es hacer la clasificación de riesgo antes de diseñar la arquitectura, no después.