Data leakage: cuando un buen resultado de IA oculta un test incorrecto
Datos futuros, duplicados y pruebas reutilizadas: cómo reconocer la fuga de información que debilita una evaluación de IA.

Un modelo puede lograr un resultado excelente sin haber aprendido lo que realmente importa. Ocurre cuando el test incorpora, directa o indirectamente, información que no estaría disponible al realizar la predicción. Este problema se denomina fuga de información o data leakage. Reconocerlo es esencial para leer un trabajo científico y decidir si una prueba empresarial merece seguir desarrollándose.
La separación que da sentido al experimento
Los datos de entrenamiento construyen el modelo. Los de validación ayudan a elegir configuraciones y umbrales. El test final debería medir el comportamiento en casos separados de esas decisiones. No basta con dividir filas: la separación debe respetar la pregunta. Si queremos predecir nuevos clientes, incluir documentos del mismo cliente en ambos grupos puede facilitar artificialmente la tarea.
Kapoor y Narayanan analizan la fuga de información en investigaciones basadas en aprendizaje automático; el trabajo apareció en arXiv en 2022 y en Patterns en 2023. El mensaje es metodológico: una evaluación puede parecer convincente e incorporar información indebida. No basta con leer el porcentaje final, y la publicación no elimina la necesidad de revisar el diseño experimental.
Un mantenimiento predictivo que conoce el futuro
Imaginemos que queremos prever si una máquina necesitará mantenimiento en una semana. Es un ejemplo hipotético. La base de datos contiene un código de cierre introducido después de la intervención. Si se usa como entrada, el modelo puede reconocer el resultado mediante información futura. El desempeño histórico parece excelente, pero el código todavía no existe cuando debe emitirse la predicción.
Corregirlo exige reconstruir los datos disponibles en la fecha de la decisión. No basta con eliminar la columna más evidente: un coste definitivo, una nota posterior o la duración total también pueden contener la respuesta. Conviene registrar cuándo se genera cada variable, cuándo está disponible y quién puede modificarla. El momento del registro y el del evento pueden diferir y deben tratarse explícitamente.
Duplicados que parecen ejemplos independientes
Otro caso afecta a documentos, imágenes y mensajes casi idénticos. Un escaneo y su versión comprimida pueden acabar en grupos distintos. Así se evalúa el modelo sobre material muy parecido al que ya ha visto. En las empresas ocurre con formularios de una misma plantilla, fotografías consecutivas de una pieza o correos de una conversación. La división aleatoria no resuelve esta dependencia.
La prueba debería reflejar el cambio esperado: nuevos períodos, instalaciones, proveedores o familias documentales. Pueden prepararse varios test con preguntas precisas. Un buen resultado en documentos habituales y otro más débil con un proveedor desconocido no son necesariamente contradictorios: describen condiciones distintas. Agregarlos sin explicación puede ocultar el límite más importante.
Cuando el test pasa a formar parte del desarrollo
Incluso sin duplicados, consultar continuamente un test puede reducir su independencia. Si cada error se transforma en una instrucción y se mide solo sobre los mismos casos, se está optimizando sobre el test. Conviene conservar un conjunto separado para la decisión final y registrar qué ejemplos han visto los desarrolladores. Tras muchas iteraciones puede ser necesario recopilar nuevos casos representativos.
Al leer un artículo o una propuesta técnica, hagamos preguntas concretas: ¿cuál es la unidad independiente? ¿La división respeta el tiempo? ¿Las transformaciones se aprendieron únicamente sobre el grupo correcto? ¿Existe una referencia sencilla? ¿Se describen los errores? Disponer del código ayuda a reproducir el procedimiento, pero no demuestra que los datos representen el futuro entorno de uso.
Qué significa para el trabajo de EL-AI
Para EL-AI, que trata aplicaciones y desarrollo de soluciones de IA, este criterio es necesario antes de atribuir valor a un resultado. Los documentos y procesos de ELAI Nexus pueden ofrecer un contexto de estudio; no certifican automáticamente un conjunto listo para entrenar. Un posible proyecto predictivo debería empezar por reconstruir la información disponible al tomar la decisión.
Una evaluación más rigurosa puede reducir la puntuación inicial y mejorar la elección. Descubrir el límite antes de adoptar la solución permite cambiar el objetivo, recopilar datos faltantes o preferir un procedimiento más sencillo. La reputación de un proyecto también depende de mostrar estos límites sin presentar cada experimento como un éxito ya conseguido.
Artículo preparado con asistencia de IA y verificación de las fuentes citadas. Ejemplos hipotéticos salvo indicación contraria. Fuentes consultadas el 20 de septiembre de 2026.
Portada ilustrativa generada con IA; no representa personas, instalaciones ni proyectos reales de EL-AI.
