Adopción de IA en Empresas: El Checklist que tu Board Necesita Ver antes de Aprobar el Proyecto

Antes de pedir presupuesto, responde estas preguntas

La mayoría de los proyectos de IA que fracasan no lo hacen por incompetencia técnica. Fracasan porque alguien aprobó un proyecto que no estaba listo para ser aprobado. El entusiasmo con la tecnología reemplazó a la claridad sobre el problema.

Este checklist existe para corregir eso. Es la lista de preguntas que cualquier board informado va a hacer, y que cualquier gestor serio debe poder responder antes de llegar a la reunión.

Sección 1: El problema de negocio

¿El problema tiene un responsable con nombre y cargo? Si la respuesta es "es un problema transversal", el proyecto no tiene un dueño real. Sin un dueño, no hay presión para que funcione.

¿El impacto financiero está calculado? No estimado con vaguedad, calculado. "Reducir en un 20% el coste de procesamiento de siniestros, que actualmente representa 2,4 M€ al año" es un argumento. "Mejorar la eficiencia operacional" no lo es.

¿Ya hemos intentado resolver este problema sin IA? Si la respuesta es no, vale la pena preguntarse por qué. La IA debe aplicarse donde los otros métodos han llegado a su límite, no como primera opción por ser la más moderna.

Sección 2: Los datos

¿Los datos que necesitamos existen y son accesibles? La pregunta parece obvia. En la práctica, es donde tropieza la mayoría de los proyectos. Los datos existen en sistemas heredados, en formatos incompatibles, con calidad insuficiente o con restricciones legales de uso.

¿Los datos representan la realidad actual del negocio? Un modelo entrenado con datos de 2019 para un problema de 2024 puede ser inútil. El comportamiento de los clientes, los procesos operacionales y los patrones de mercado cambian. Los datos de entrenamiento tienen que reflejar el contexto actual.

¿Tenemos procesos para mantener los datos actualizados en producción? Esto no es una cuestión técnica, es una cuestión organizativa. ¿Quién es responsable de la calidad de los datos que alimentan el modelo después del lanzamiento? Si no hay respuesta, el modelo se va a degradar.

Como referencia sobre lo que significa evaluar la calidad de los datos de forma rigurosa, vale la pena consultar el trabajo publicado sobre estimación objetiva de calidad de datos.

Sección 3: El proyecto

¿El socio técnico ya ha entregado proyectos similares en producción, no en piloto? La diferencia entre un piloto y producción es lo que ocurre cuando los datos son imperfectos, cuando los usuarios no siguen el flujo esperado, cuando el sistema falla a las 3 de la mañana. Eso requiere una experiencia distinta.

¿Hay un criterio de go/no-go definido para la prueba de concepto? Sin ese criterio, el piloto se arrastra indefinidamente. El criterio tiene que estar en lenguaje de negocio, no en métricas de modelo. "Si la solución identifica correctamente el 80% de los casos de fraude antes de la aprobación manual, seguimos adelante": eso es un criterio.

¿El plan de implementación incluye la adopción por parte de los equipos operacionales? Formación, cambio de proceso, gestión de la resistencia interna. Estos elementos representan con frecuencia entre el 30 y el 40% del esfuerzo real del proyecto, y aparecen con cero líneas en el presupuesto inicial.

Sección 4: El post-lanzamiento

¿Cómo vamos a monitorizar el modelo una vez esté en producción? Los modelos de ML se degradan. Es inevitable. La cuestión es si la empresa va a saber cuándo está ocurriendo, antes de que los resultados de negocio empiecen a empeorar.

¿Quién es responsable del mantenimiento y la evolución del modelo? ¿Equipo interno? ¿Socio externo con contrato de retainer? Esta decisión tiene un impacto presupuestario y de riesgo que debe quedar claro antes de la aprobación, no seis meses después del lanzamiento.

¿Cuál es el plan si el proyecto no alcanza los objetivos? No es pesimismo, es gestión de riesgo. Un board que aprueba proyectos de innovación quiere saber que existe un proceso de aprendizaje incluso cuando los resultados se quedan cortos.

Lo que este checklist no es

No es una garantía de éxito. Es un filtro para descartar proyectos que no deberían arrancar y para hacer más sólidos los que sí deben avanzar.

La adopción de IA está generando una presión competitiva real. Como ocurrió con la electrificación de las fábricas a principios del siglo XX: las empresas que no adoptaron se quedaron atrás, pero las que adoptaron sin preparación también perdieron dinero y tiempo. Lo que distinguió a las que ganaron fue la claridad sobre el problema antes de encender la máquina.

El trabajo de reducir el desempleo con IA aplicada a un problema social concreto o de combatir el cáncer de cuello de útero con visión computacional en contexto clínico siempre empieza en el mismo lugar: un problema definido con precisión, datos reales y criterios claros de éxito.

El board no necesita entender machine learning. Necesita ver que quien propone el proyecto entiende de negocio.