Hay una conversación que se repite en juntas directivas y comités técnicos por toda la región. Alguien plantea: "tenemos que empezar a usar IA". Hay entusiasmo. Y también hay una pregunta operativa que casi nunca se hace antes: ¿este programa necesita machine learning, o lo que necesita es otra cosa hecha bien?
La diferencia importa por dos razones. La primera es presupuestaria: implementar machine learning de forma rigurosa cuesta entre dos y cinco veces más que un análisis estadístico clásico bien hecho. La segunda es metodológica: aplicar ML a un programa que no tiene los datos, la teoría del cambio o la pregunta correcta no genera mejores decisiones, genera ruido sofisticado que se ve científico pero no es accionable.
Este artículo ofrece el marco que usamos en Innoval para decidir si un programa social debe usar machine learning. No es una defensa de la IA y tampoco una crítica a la IA. Es un filtro de criterio operativo que ahorra dinero y produce mejores decisiones.
Las tres preguntas previas
Antes de contratar análisis con machine learning, hay tres preguntas que toda organización debe responder con honestidad. Si la respuesta a alguna es "no", lo más probable es que ML no sea todavía la herramienta correcta.
1. ¿Tiene suficientes datos, y con suficiente calidad?
Machine learning aprende patrones de datos históricos. Con muestras pequeñas o datos sucios, los modelos sobreajustan: aprenden el ruido, no la señal. Como referencia operativa, la mayoría de los algoritmos de clasificación útiles para programas sociales requieren al menos varios miles de observaciones por clase relevante, con variables consistentes a lo largo del tiempo.
Lo que importa no es solo el volumen. Es la coherencia: que la misma variable se haya recolectado igual durante el período analizado, que las personas beneficiarias tengan identificadores únicos, y que haya documentación de cómo se construyó cada campo. Sin esa coherencia, lo primero que entrega cualquier proyecto serio de ML es una auditoría de datos, no un modelo.
2. ¿Su pregunta es predictiva, explicativa o descriptiva?
ML es muy bueno para preguntas predictivas ("¿quiénes son las personas en riesgo de abandonar el programa?") y para identificar patrones que el ojo humano no detecta en datos complejos. No es tan bueno para preguntas causales directas ("¿por qué este programa funciona mejor que el otro?"), donde el diseño metodológico (cuasiexperimental, regresión discontinua, diferencias en diferencias) sigue siendo superior.
La trampa más común es usar ML para responder preguntas causales como si fueran de predicción. El resultado son modelos que predicen muy bien pero que no explican nada de por qué pasa lo que pasa. Para juntas directivas que necesitan decidir si seguir invirtiendo, esa diferencia es la que separa una buena decisión de una mala.
3. ¿Las decisiones que tomará justifican la complejidad?
El criterio operativo más subestimado. Un modelo de ML que mejora la precisión de un diagnóstico del 75% al 82% es técnicamente impresionante. Pero si la decisión que sigue al diagnóstico es la misma en ambos escenarios (intervenir igual a la persona), la diferencia de 7 puntos no cambia nada en términos de impacto real.
Antes de invertir, hay que poder describir con precisión cómo será distinta una decisión específica si el análisis es ML y no estadística clásica. Si la respuesta es vaga, casi siempre la herramienta correcta no es ML.
El mejor modelo de machine learning es el que no se hace, porque todo está tan bien construido que los datos solos ya dicen suficiente. La IA llega después, a ponerle esteroides a algo que ya funciona.
Cuando NO usar machine learning
Tres situaciones donde una organización se ahorra mucho dinero (y mucho ruido) al no contratar ML, ordenadas por frecuencia:
1. Cuando el reporte estándar ya responde la pregunta
Si el sistema de monitoreo regular del programa ya muestra que la deserción se concentra en jóvenes de zonas rurales con dos o más factores de pobreza, no hace falta ML para confirmarlo. Lo que hace falta es focalizar la intervención. La inversión correcta es en la acción operativa, no en un nuevo análisis.
2. Cuando los datos son pocos, ruidosos o inconsistentes
Programas con menos de mil beneficiarios, con variables que cambiaron de definición a mitad del ciclo, o con tasas de datos faltantes superiores al 30% no son candidatos para ML. Lo primero es ordenar el sistema de datos. Después se evalúa si ML aporta. Si se invierten los pasos, el resultado es un modelo que parece funcionar pero que en realidad está aprendiendo errores de captura.
3. Cuando lo que falta es teoría del cambio, no predicción
A veces el problema no es identificar qué pasa, sino entender por qué. Programas que se han ejecutado durante años sin una teoría del cambio explícita necesitan primero formalizar esa teoría con el equipo (un trabajo de dos a cuatro semanas con criterio técnico). Aplicar ML antes de ese paso es prometerle a la dirección que se le va a dar la respuesta de fondo cuando en realidad solo se le entregará una correlación.
Cuando SÍ usar machine learning
Tres situaciones donde ML aporta un valor distintivo y la inversión se justifica:
1. Anticipar comportamientos críticos con datos masivos
Cuando un programa tiene decenas de miles de beneficiarios, con datos administrativos longitudinales, y la decisión operativa depende de identificar a las personas en riesgo antes de que el evento ocurra. Ejemplos: riesgo de deserción escolar, riesgo de pobreza multidimensional, probabilidad de éxito en programas de inclusión financiera. Acá los modelos predictivos ganan claramente a la estadística descriptiva.
2. Encontrar patrones en datos complejos no obvios al ojo humano
Cuando los datos del programa tienen muchas variables y la pregunta es "¿qué combinaciones de factores explican mejor el resultado?", técnicas como árboles de decisión, random forest o análisis de componentes principales identifican interacciones que ningún análisis bivariado encuentra. Es donde más se diferencia ML de la estadística clásica.
3. Análisis causal sobre datos de monitoreo existentes
Cuando la organización tiene datos de monitoreo pero no diseñó la evaluación con grupos de comparación, ML moderno permite construir grupos contrafactuales a posteriori (matching, métodos doblemente robustos, machine learning causal). No reemplaza un diseño experimental, pero sí permite hacer estimaciones de impacto sin levantamiento adicional.
- Usar ML cuando: hay miles de observaciones, la decisión es predictiva o de focalización, y la complejidad del problema supera lo que el análisis clásico resuelve.
- No usar ML cuando: los datos son pocos o sucios, la pregunta es causal directa, falta la teoría del cambio, o la decisión que sigue es la misma con o sin ML.
Caso documentado · Programa Avancemos
¿Quiénes desertan del sistema educativo aunque reciben el beneficio?
El programa Avancemos transfiere recursos a familias en pobreza para mantener a sus hijos en el sistema educativo. La transferencia funciona para la mayoría, pero una proporción sigue desertando. La pregunta operativa de UNICEF y PANI era qué perfiles concretos predicen la deserción a pesar de recibir el beneficio, para focalizar acompañamiento adicional.
Era el caso correcto para ML por tres razones simultáneas: el programa tenía datos longitudinales de decenas de miles de beneficiarios, la pregunta era predictiva (perfil de riesgo) más que causal, y la decisión operativa que seguía dependía directamente de poder anticipar la deserción antes de que ocurriera.
Innoval aplicó modelos de machine learning supervisado sobre los datos del programa, identificó los factores predictivos más relevantes del riesgo de exclusión educativa, y construyó una hoja de ruta de focalización por perfil de beneficiario. La metodología fue defendida ante contrapartes técnicas de UNICEF.
Qué entrega Innoval (siempre) en un proyecto de machine learning
Independientemente del método específico (análisis exploratorio, modelos predictivos o análisis causal), todo proyecto de este tipo cierra con cuatro entregables. No se entrega solo el modelo. Se entrega el sistema operativo para que la organización tome decisiones la semana siguiente.
Informe de hallazgos
Documento técnico con interpretación accionable, no solo resultados numéricos.
Tablero de visualización
Power BI, Tableau, Looker o Streamlit. Operable por el equipo del cliente.
Recomendaciones priorizadas
Acciones específicas, con horizonte de implementación y responsable sugerido.
Hoja de ruta operativa
Plan de focalización o reasignación de recursos basado en los hallazgos.
Cómo empezar (sin contratar nada todavía)
Tres pasos previos que cualquier organización puede hacer antes de invertir en ML, y que aumentan significativamente la probabilidad de que el proyecto produzca valor real:
- Auditoría de datos. Inventario de tablas, variables, calidad, coherencia temporal y documentación. Tres a cinco días de trabajo de un analista interno o externo.
- Pregunta-anchor clara. Una pregunta predictiva o de focalización, formulada con verbos y métricas concretas. No "queremos entender el programa", sí "queremos identificar el 20% de beneficiarios con mayor riesgo de deserción para focalizar acompañamiento adicional".
- Diagnóstico de evaluabilidad. Verificación de que la teoría del cambio existe, los datos cubren la pregunta y la organización tiene capacidad de actuar sobre los hallazgos. Si alguno falta, hay que cerrar esa brecha antes.
Con esos tres elementos resueltos, la conversación con cualquier proveedor de ML (incluyendo Innoval) parte de un piso técnico mucho más alto y reduce el riesgo de pagar por un análisis que no se va a usar.
Cierre
La pregunta correcta no es si usar inteligencia artificial. Es si se está usando con el criterio y la sensibilidad correctos. ML aporta un diferencial real en problemas predictivos sobre datos masivos. En el resto de los problemas sociales (que son la mayoría), análisis estadístico bien hecho, teoría del cambio formalizada y sistemas MEL que el equipo del cliente usa, valen más.
En Innoval aplicamos ML todos los días, y también recomendamos no aplicarlo todos los días. Esa segunda parte es la que más valor agrega.