Cómo preparar los datos para proyectos de inteligencia artificial

Introducción

Los proyectos de inteligencia artificial no empiezan con el modelo. Empiezan con los datos que permiten entrenarlo, ajustarlo, evaluarlo o darle contexto. Una empresa puede disponer de años de información y, aun así, descubrir que gran parte de ella no está preparada para utilizarse de forma fiable en un proyecto de IA.

El problema no suele ser únicamente la falta de volumen. También aparecen registros incompletos, duplicados, categorías utilizadas de manera distinta, fechas incoherentes, textos sin contexto, históricos mezclados, campos cuya interpretación ha cambiado con el tiempo o datos que reflejan solo una parte de la realidad que se quiere analizar.

Preparar los datos significa transformar ese material operativo en un conjunto que pueda utilizarse con una finalidad concreta sin perder su significado. Eso exige seleccionar, revisar, limpiar, estructurar, documentar, proteger y, cuando sea necesario, etiquetar la información.

Este proceso es distinto de preparar la infraestructura que almacena los datos. Una base de datos puede estar perfectamente diseñada, ser segura, rápida y escalable, y contener aun así información inadecuada para un determinado caso de IA. Del mismo modo, un conjunto de datos bien preparado puede proceder de varias fuentes diferentes.

Por eso este artículo se centra en la preparación del dato como materia prima: qué datos elegir, cómo evaluar su calidad, cómo tratar errores y valores ausentes, cómo evitar sesgos evidentes, cómo documentar transformaciones y cómo construir conjuntos reproducibles para experimentación, validación y uso posterior.

Índice

• Empezar por el caso de uso, no por todos los datos disponibles
• Definir la unidad de análisis
• Inventariar las fuentes necesarias
• Seleccionar solo los datos relevantes
• Evaluar la calidad antes de transformar
• Tratar valores ausentes con criterio
• Detectar y resolver duplicados
• Normalizar formatos, unidades y categorías
• Distinguir errores de valores extraordinarios
• Preparar datos de texto
• Etiquetar cuando el proyecto necesita una referencia
• Comprobar representatividad y sesgos
• Evitar fugas de información
• Separar entrenamiento, validación y prueba
• Mantener trazabilidad y reproducibilidad
• Proteger datos sensibles y limitar su uso
• Preparar un proceso de actualización
• Lista de comprobación antes de utilizar un conjunto de datos
• Conclusión
• Preguntas frecuentes

Empezar por el caso de uso, no por todos los datos disponibles

Uno de los errores más habituales consiste en reunir toda la información disponible y decidir después qué se puede hacer con ella. Ese enfoque suele producir conjuntos enormes, difíciles de entender y llenos de variables que no aportan valor.

La preparación debe empezar con una pregunta concreta. Por ejemplo:

• clasificar solicitudes por tipo;
• detectar incidencias con mayor riesgo de retraso;
• estimar demanda futura;
• buscar información relevante dentro de documentación técnica;
• agrupar clientes por patrones de comportamiento;
• detectar anomalías en mediciones;
• generar borradores apoyados en documentación interna;
• predecir una variable operativa a partir de información histórica.

Cada caso de uso necesita datos diferentes. Una clasificación de incidencias puede depender del texto y de categorías históricas. Una previsión de demanda puede necesitar fechas, cantidades y factores estacionales. Un sistema de búsqueda semántica puede necesitar documentos limpios, bien segmentados y con metadatos.

Definir qué se quiere producir

Conviene escribir qué salida se espera del sistema: una categoría, una probabilidad, una cantidad, una lista ordenada, una alerta, una respuesta contextual o una representación vectorial.

Esta definición permite decidir qué información es entrada y qué información representa el resultado que se quiere aprender o evaluar.

Evitar objetivos ambiguos

“Aplicar inteligencia artificial a los datos de clientes” no es un caso de uso. “Estimar qué solicitudes comerciales tienen mayor probabilidad de convertirse en venta durante los próximos treinta días” sí lo es.

Cuanto más concreta sea la pregunta, más precisa será la preparación de datos.

Definir la unidad de análisis

Antes de limpiar columnas hay que decidir qué representa cada fila, documento o elemento del conjunto.

Una fila debe tener un significado inequívoco

Puede representar:

• un cliente;
• una venta;
• una solicitud;
• una factura;
• una incidencia;
• una medición;
• un día;
• una interacción;
• un documento.

Mezclar unidades de análisis es una fuente importante de errores. Si unas filas representan clientes y otras representan operaciones, las variables dejan de ser comparables.

Elegir el nivel adecuado de granularidad

Una previsión de consumo mensual puede requerir una fila por mes, mientras que una detección de anomalías quizá necesite una fila por lectura de sensor.

El nivel debe ser suficientemente detallado para capturar la señal útil, pero no tan granular que introduzca ruido innecesario.

Definir el momento temporal

En proyectos predictivos es especialmente importante saber qué información estaba disponible en el instante de la predicción. Un dato registrado después del resultado no debería utilizarse como si hubiera existido antes.

Inventariar las fuentes necesarias

Una vez definido el caso, hay que localizar dónde viven los datos relevantes.

Pueden encontrarse en:

• bases de datos;
• hojas de cálculo;
• archivos CSV;
• documentos;
• correos exportados;
• registros de aplicaciones;
• sistemas de soporte;
• sensores;
• repositorios de archivos;
• servicios externos.

Registrar procedencia y responsable

Para cada fuente conviene saber quién la genera, con qué frecuencia se actualiza, qué periodo contiene y qué persona conoce mejor su significado.

Comprobar si las fuentes se pueden relacionar

Dos conjuntos pueden contener información complementaria pero carecer de un identificador común fiable. Unir por nombre o texto libre puede crear coincidencias falsas.

Distinguir fuente original de exportación

Una hoja generada desde otra aplicación no es necesariamente la fuente de verdad. Trabajar sobre exportaciones sucesivas sin conocer su origen puede introducir versiones distintas del mismo dato.

Seleccionar solo los datos relevantes

Más variables no significan necesariamente mejores resultados. Añadir información irrelevante aumenta ruido, complejidad, coste y riesgo.

Preguntar por qué existe cada variable

Cada campo debería tener una razón relacionada con el caso de uso. Si no puede explicarse qué información aporta, conviene cuestionar su inclusión.

Eliminar variables que revelan directamente la respuesta

En un proyecto predictivo puede existir un campo generado después del resultado y que prácticamente lo codifica. Utilizarlo produciría una evaluación artificialmente buena y un sistema inútil en producción.

Evitar identificadores sin significado predictivo

Un número de factura o un ID interno puede ser necesario para mantener trazabilidad, pero no tiene por qué formar parte de las variables que consume un modelo.

Conservar campos auxiliares fuera del conjunto de entrada

Identificadores, fechas de extracción o fuentes pueden mantenerse como metadatos para auditar los resultados sin utilizarlos directamente como características.

Evaluar la calidad antes de transformar

Limpiar sin medir primero puede ocultar la magnitud del problema. Conviene realizar un diagnóstico inicial.

Completitud

Calcula qué porcentaje de valores falta en cada campo importante y si la ausencia se concentra en determinadas épocas, grupos o sistemas.

Validez

Comprueba formatos, rangos y reglas básicas. Una fecha imposible, una cantidad negativa que no debería serlo o una categoría inexistente son señales claras.

Consistencia

Busca contradicciones entre campos relacionados. Por ejemplo, una fecha de cierre anterior a la apertura o un estado “cancelado” con una fecha de entrega posterior.

Unicidad

Identifica registros que podrían representar la misma entidad o evento más de una vez.

Actualidad

En algunos proyectos la información antigua sigue siendo valiosa. En otros, el comportamiento ha cambiado tanto que datos de hace muchos años pueden describir una realidad distinta.

Distribución

Revisa mínimos, máximos, frecuencias, medias, percentiles y categorías. Muchas anomalías se detectan simplemente observando cómo se distribuyen los valores.

Tratar valores ausentes con criterio

Los valores vacíos no deben rellenarse automáticamente con cero, promedio o la categoría más frecuente. La ausencia también puede contener información.

Comprender por qué falta el dato

Puede faltar porque:

• nunca se solicitó;
• la persona no respondió;
• el sistema antiguo no tenía ese campo;
• solo se registra en ciertos casos;
• hubo un error de integración;
• el valor no aplica.

Estas situaciones no son equivalentes.

Decidir entre eliminar, imputar o conservar la ausencia

Si faltan pocos registros y no son importantes, quizá puedan excluirse. Si el campo es valioso, puede imputarse mediante una regla razonable. En otras ocasiones conviene crear una categoría explícita de “desconocido”.

No inventar precisión

Una imputación es una estimación, no una observación real. Debe quedar documentada y, cuando sea relevante, poder identificarse qué valores fueron imputados.

Evitar que la imputación use información futura

En series temporales o predicción, rellenar valores utilizando datos posteriores puede introducir fuga de información.

Detectar y resolver duplicados

Los duplicados pueden distorsionar frecuencias, medias y probabilidades. También pueden provocar que el mismo caso aparezca en entrenamiento y prueba.

Distinguir duplicado exacto de entidad repetida

Dos filas idénticas pueden ser una duplicación técnica. Dos registros con nombres ligeramente distintos pueden representar a la misma persona o empresa.

Definir una regla de identidad

La deduplicación necesita criterios: identificadores internos, correo, combinación de campos, número de documento u otras claves adecuadas.

No eliminar eventos legítimos

Dos compras iguales realizadas por el mismo cliente no son necesariamente un duplicado. Hay que distinguir entidad de evento.

Conservar trazabilidad de las fusiones

Si varios registros se consolidan, conviene saber cuáles dieron origen al resultado final.

Normalizar formatos, unidades y categorías

La heterogeneidad es uno de los problemas más comunes cuando se combinan fuentes.

Fechas

Conviene transformar fechas a una representación inequívoca y conservar la zona horaria cuando tenga importancia.

Unidades

Metros y centímetros, euros y miles de euros, segundos y minutos no pueden mezclarse sin normalización.

Decimales

Los separadores y formatos regionales deben convertirse de manera consistente.

Categorías

“Madrid”, “MADRID”, “Mad.” y “Madrid capital” podrían representar lo mismo o conceptos diferentes. La normalización debe basarse en una regla definida.

Texto libre utilizado como categoría

Cuando los usuarios escriben una clasificación manualmente, aparecen variantes ortográficas. Si el campo debe funcionar como categoría, conviene mapearlas a valores controlados.

No destruir el dato original

Siempre que sea posible, es útil conservar una versión original junto a la transformada. Esto facilita corregir reglas sin tener que recuperar la fuente desde cero.

Distinguir errores de valores extraordinarios

Un valor extremo puede ser un error, pero también puede representar precisamente el caso interesante que un sistema debería aprender a detectar.

Investigar antes de eliminar

Una venta diez veces superior a la habitual puede ser un error de decimal o una operación excepcional real. Eliminarla automáticamente puede borrar información valiosa.

Utilizar conocimiento del proceso

Los límites técnicos deben combinarse con conocimiento empresarial. Un valor puede ser estadísticamente raro y perfectamente válido.

Marcar anomalías

En ocasiones es mejor conservar el registro y añadir una marca que indique su condición extraordinaria.

Documentar correcciones manuales

Modificar un dato sin dejar rastro dificulta reproducir el conjunto posteriormente.

Preparar datos de texto

Los textos necesitan una preparación distinta de las tablas numéricas.

Eliminar ruido que no aporta significado

Firmas repetitivas, cabeceras técnicas, menús, pies de página, cadenas automáticas o bloques duplicados pueden introducir ruido.

Conservar estructura útil

Títulos, secciones, fechas, autores, referencias y otros metadatos pueden ser importantes. Limpiar texto no significa convertir todo en un bloque plano.

Separar documentos en unidades coherentes

Para búsqueda semántica o sistemas de recuperación de información, un documento muy largo puede dividirse en fragmentos. Los fragmentos deben mantener suficiente contexto para poder interpretarse.

Eliminar duplicados de contenido

Copias de la misma política, manual o artículo pueden sobreponderar información repetida.

Identificar versiones

Si existen documentos antiguos y nuevos, el sistema debe saber cuál está vigente o qué fecha corresponde a cada versión.

Etiquetar cuando el proyecto necesita una referencia

Muchos proyectos supervisados necesitan una variable objetivo o etiquetas creadas por personas.

Definir la etiqueta antes de etiquetar

Dos personas pueden interpretar de forma distinta “incidencia grave”, “cliente interesado” o “documento correcto”. Hace falta una guía que reduzca ambigüedad.

Crear ejemplos positivos y negativos

Las reglas se entienden mejor cuando incluyen casos reales y casos límite.

Revisar discrepancias entre etiquetadores

Si varias personas clasifican el mismo caso de forma diferente con frecuencia, quizá la definición sea deficiente.

No confundir opinión con verdad objetiva

Algunas etiquetas representan juicios humanos. Conviene documentar quién las creó y bajo qué criterio.

Controlar cambios de criterio

Si una categoría cambia de significado durante el proyecto, mezclar etiquetas antiguas y nuevas puede reducir la coherencia.

Comprobar representatividad y sesgos

Un conjunto puede estar limpio y ser inadecuado porque no representa el contexto donde se utilizará el sistema.

Revisar periodos

Datos recogidos durante una situación excepcional pueden no representar la actividad habitual.

Revisar grupos y categorías

Si casi todos los ejemplos pertenecen a una categoría, el sistema tendrá menos información sobre las demás.

Revisar cambios de proceso

Si la empresa modificó una política, una herramienta o un canal, los datos anteriores pueden proceder de un proceso distinto.

Evitar conclusiones basadas solo en disponibilidad

Los datos más fáciles de recoger no siempre son los más importantes. Puede existir un sesgo hacia aquello que las aplicaciones ya registran.

Comparar el conjunto con la realidad objetivo

La pregunta clave es: ¿la distribución de casos que verá el sistema se parece razonablemente a la de los datos con los que se ha preparado?

Evitar fugas de información

La fuga de información ocurre cuando el conjunto contiene datos que no estarían disponibles en el momento real de utilizar el sistema.

Variables creadas después del resultado

Una fecha de cierre, una categoría final o un comentario posterior pueden revelar aquello que se intenta predecir.

Agregaciones que incluyen el futuro

Calcular “ventas totales del año” para predecir una situación en marzo utiliza información de meses posteriores.

Transformaciones calculadas antes de dividir el conjunto

Algunas operaciones estadísticas pueden transferir información del conjunto de prueba al entrenamiento si se calculan sobre todos los datos a la vez.

Duplicados entre particiones

Si el mismo caso aparece en entrenamiento y prueba, la evaluación puede ser artificialmente alta.

Evitar fugas exige reconstruir mentalmente la situación real: ¿qué información conoceríamos exactamente en el instante en que el sistema debe responder?

Separar entrenamiento, validación y prueba

Cuando el proyecto implica aprendizaje automático, no conviene utilizar todos los datos para construir el modelo y después medirlo sobre los mismos ejemplos.

Conjunto de entrenamiento

Se utiliza para aprender patrones.

Conjunto de validación

Permite comparar configuraciones y tomar decisiones durante el desarrollo.

Conjunto de prueba

Debe mantenerse apartado para obtener una estimación final más independiente.

Respetar el tiempo cuando importa

En predicción temporal suele ser más realista entrenar con periodos anteriores y probar con periodos posteriores que repartir filas aleatoriamente.

Agrupar entidades relacionadas

Si existen varias filas del mismo cliente, dispositivo o documento, puede ser necesario mantenerlas en la misma partición para evitar que información casi idéntica aparezca a ambos lados.

Mantener trazabilidad y reproducibilidad

Un dataset preparado debería poder reconstruirse. Si el resultado depende de una serie de cambios manuales que nadie recuerda, será difícil corregir errores o actualizarlo.

Conservar la fuente original

Siempre que sea posible, la preparación debe trabajar sobre una copia controlada y mantener intacto el origen.

Versionar transformaciones

Scripts, consultas o reglas que limpian los datos deberían quedar guardados y documentados.

Identificar la versión del dataset

Una fecha o identificador de versión permite saber qué conjunto se utilizó en cada experimento.

Registrar parámetros

Umbrales de limpieza, reglas de imputación, listas de categorías y criterios de exclusión deben poder recuperarse.

Relacionar resultados con los datos utilizados

Si meses después un sistema produce un comportamiento extraño, debe ser posible saber qué versión de datos participó en su creación o evaluación.

Proteger datos sensibles y limitar su uso

Que un dato exista no significa que deba utilizarse automáticamente en un proyecto de IA.

Aplicar minimización

Incluye solo la información necesaria para el caso de uso. Reducir campos sensibles disminuye riesgo y complejidad.

Separar identificadores directos cuando no son necesarios

Nombres, correos, teléfonos u otros identificadores pueden sustituirse por claves internas cuando el análisis no necesita conocer la identidad.

Controlar accesos

Los conjuntos de experimentación no deberían convertirse en copias sin control circulando por ordenadores personales.

Conocer la procedencia y las condiciones de uso

Los datos externos pueden tener restricciones contractuales, de licencia o de privacidad.

Revisar antes de enviar información a servicios externos

Un proceso de IA puede implicar proveedores o APIs. Antes de transferir datos debe conocerse qué información sale, con qué finalidad y bajo qué condiciones.

Preparar un proceso de actualización

Un dataset no debería considerarse una fotografía eterna. Los procesos cambian y los datos envejecen.

Definir frecuencia

Puede ser diaria, mensual, trimestral o bajo demanda según el caso.

Repetir las mismas transformaciones

La automatización del pipeline de preparación reduce inconsistencias entre versiones.

Detectar cambios de esquema

Una columna nueva, una categoría que desaparece o un formato diferente pueden romper la preparación.

Vigilar cambios de distribución

Si los valores actuales se alejan mucho de los históricos, el conjunto antiguo puede dejar de representar el entorno real.

Revisar etiquetas y definiciones

Los criterios empresariales también evolucionan. Un objetivo definido hace dos años puede necesitar actualización.

Lista de comprobación antes de utilizar un conjunto de datos

• ¿Existe un caso de uso claramente definido?
• ¿Está clara la unidad de análisis?
• ¿Sabemos de qué fuentes procede cada dato?
• ¿Los identificadores permiten relacionar registros de forma fiable?
• ¿Se ha medido la cantidad de valores ausentes?
• ¿Se han revisado duplicados?
• ¿Los formatos, unidades y categorías son coherentes?
• ¿Se han investigado valores extremos?
• ¿Las transformaciones están documentadas?
• ¿Las etiquetas tienen una definición clara?
• ¿El conjunto representa razonablemente el contexto donde se utilizará?
• ¿Se han revisado posibles fugas de información?
• ¿Las particiones de entrenamiento, validación y prueba están separadas correctamente?
• ¿La versión del dataset puede identificarse?
• ¿Puede reconstruirse a partir de la fuente?
• ¿Se han limitado datos sensibles innecesarios?
• ¿Está controlado quién puede acceder?
• ¿Existe un procedimiento para actualizar el conjunto?

Responder afirmativamente a estas preguntas no garantiza el éxito de un proyecto de IA, pero reduce una gran cantidad de errores evitables.

Conclusión

Preparar los datos para inteligencia artificial no consiste en aplicar una limpieza genérica ni en exportar todas las tablas disponibles a un archivo grande. Consiste en construir un conjunto que represente correctamente el problema que se quiere resolver.

El trabajo empieza definiendo el caso de uso y la unidad de análisis. Después se localizan fuentes, se seleccionan variables, se mide calidad y se corrigen problemas con reglas explícitas. Los valores ausentes, duplicados, formatos inconsistentes y valores extremos deben tratarse según su significado, no mediante recetas automáticas.

En proyectos que utilizan aprendizaje supervisado también es fundamental definir etiquetas coherentes, comprobar representatividad, evitar fugas de información y separar correctamente entrenamiento, validación y prueba.

La preparación termina solo cuando el conjunto es reproducible: se conoce su procedencia, las transformaciones están documentadas, la versión puede identificarse y existe un procedimiento para actualizarla.

Una buena infraestructura de datos facilita este trabajo, pero no lo sustituye. La calidad de un proyecto de IA depende en gran medida de la capacidad para transformar información empresarial real —con sus errores, excepciones e historia— en datos comprensibles y controlados.

En inteligencia artificial, preparar bien los datos no es una tarea previa menor. Es una parte central del propio proyecto.

Preguntas frecuentes