Terminamos la lección anterior constatando que la mayoría de los sistemas que NovaMarket va a construir son subsimbólicos: aprenden de datos. Esta lección se dedica a esa materia prima. Marta lleva semanas diciéndolo en cada reunión: "antes de hablar de modelos, hablemos de qué datos tenemos y en qué estado están". Tiene razón, y en esta lección veremos por qué. Explicaremos por qué los datos son el combustible de la IA, qué tipos de datos existen y cómo se organizan, cuál es el ciclo de vida del dato en una organización, cómo se mide su calidad y qué problemas concretos esconden los ficheros de NovaMarket, de dónde vienen los sesgos que después se convierten en decisiones injustas, qué obligaciones conceptuales impone la protección de datos personales y por qué la calidad importa más que la cantidad. Cerraremos con un programa en Python que lee un pedidos.csv de ejemplo y produce un pequeño informe de calidad, exactamente el tipo de comprobación que debería preceder a cualquier proyecto de IA.

1. Por qué los datos son el combustible de la IA
2. Tipos de datos
3. Datos etiquetados y no etiquetados
4. El ciclo de vida del dato: recogida, almacenamiento, calidad, gobernanza
5. Dimensiones de la calidad de los datos, con los problemas reales de NovaMarket
6. Sesgo en los datos: el origen de la injusticia algorítmica
7. Datos personales y RGPD: minimización, anonimización y seudonimización
8. Cantidad frente a calidad; datos sintéticos
9. Ejemplo en Python: un informe de calidad de pedidos.csv

Recuerda el esquema de 01-02: en la programación tradicional, datos + programa → resultados; en el aprendizaje automático, datos + resultados → modelo, y después el modelo produce resultados para datos nuevos. El modelo no contiene más conocimiento que el que había en los datos con los que se construyó. De ahí se derivan tres consecuencias que conviene grabarse:

• Sin datos no hay modelo. El recomendador de 01-03 no podía recomendar nada para el televisor hasta que hubo pedidos con televisores (el "arranque en frío").
• Con datos malos hay modelos malos. La expresión clásica es garbage in, garbage out: si el 50 % de la columna "causa" de incidencias.csv está vacía, ningún algoritmo va a diagnosticar bien las incidencias.
• El modelo hereda todo lo que hay en los datos, incluidos los errores, las lagunas y los sesgos. Si históricamente NovaMarket revisó más los pedidos de ciertos códigos postales, un modelo entrenado con ese historial aprenderá a sospechar de esos códigos postales (lo desarrollaremos en la sección 6 y en 02-04).

Por eso, en un proyecto real de IA, entre el 60 % y el 80 % del esfuerzo se dedica a obtener, entender, limpiar y preparar datos, no a entrenar modelos. Es lo primero que Marta quiso que Diego entendiera: el "coste de la IA" es en gran parte el coste de poner en orden los datos, y ese coste se amortiza en todos los proyectos posteriores.

Los datos se clasifican de varias maneras complementarias. Conocerlas ayuda a saber qué técnica se puede aplicar y qué preparación necesitarán.

La mayoría del volumen de datos de una empresa es no estructurado, y la mayoría del valor histórico se ha extraído de los estructurados. El deep learning (módulo 5) cambió eso al hacer explotable el texto y la imagen.

Un mismo fichero mezcla varios: pedidos.csv tiene identificadores, una fecha, un importe numérico, una ciudad categórica y una columna devuelto categórica binaria. Saber qué es cada columna es el primer paso de cualquier análisis, y es sorprendente cuántos problemas vienen de tratar un identificador como número (sumar códigos postales) o un número como texto (ordenar importes alfabéticamente: "1000" antes que "200").

Una distinción decisiva para el aprendizaje automático:

• Datos etiquetados: cada ejemplo lleva asociada la respuesta correcta que queremos que el modelo aprenda a producir. En pedidos.csv, la columna devuelto es la etiqueta si queremos predecir devoluciones. En resenas.csv, una columna "sentimiento" (positivo/negativo) puesta por una persona sería la etiqueta.
• Datos no etiquetados: solo tenemos los ejemplos, sin respuesta. Miles de reseñas sin clasificar, el historial de navegación sin saber qué acabó comprando el cliente.

Con datos etiquetados se puede hacer aprendizaje supervisado (aprender la relación entre las características y la etiqueta); con datos no etiquetados, aprendizaje no supervisado (descubrir estructura: grupos de clientes parecidos, productos que se compran juntos). Ambos se desarrollan en 04-02; aquí basta con saber que las etiquetas son caras (a menudo hay que ponerlas a mano) y valiosas, y que su calidad condiciona todo.

Un ejemplo de lo cara y delicada que es la etiqueta: incidencias.csv tiene unos 400 registros y la mitad de la columna causa vacía. Esa columna es la etiqueta que el caso de uso 9 (diagnóstico de incidencias) necesitaría aprender. Con 200 ejemplos etiquetados de forma desigual (los operadores rellenaban la causa cuando tenían tiempo, es decir, más en los días tranquilos y menos en los picos), el sistema aprendería de una muestra sesgada. Diego propuso una solución no técnica pero correcta: hacer obligatoria la causa en el formulario a partir de ahora y organizar una sesión para etiquetar retrospectivamente las 200 que faltan.

Los datos no aparecen listos para usar; atraviesan un ciclo, y cada etapa puede introducir o corregir problemas:

• Recogida: cómo entran los datos. Cada canal tiene sus vicios: el formulario web de devoluciones permite dejar campos vacíos; el terminal del almacén guarda el peso en gramos y la web en kilos; la mensajería externa envía las fechas en formato DD/MM/AAAA mientras el sistema interno usa AAAA-MM-DD. La regla de oro es validar en origen: es mucho más barato obligar a rellenar la causa de la incidencia en el momento que reconstruirla meses después.
• Almacenamiento: dónde y cómo se guardan. Bases de datos transaccionales (las que soportan la tienda), almacenes de datos para análisis, ficheros planos como los CSV con los que trabajamos en el curso. Aquí importan la trazabilidad (¿de dónde viene cada dato?, ¿cuándo se cargó?) y el esquema (qué significa cada columna, en qué unidades).
• Calidad: comprobar y corregir (sección 5). Idealmente es un proceso continuo, no un arreglo puntual antes de cada proyecto.
• Uso: análisis, informes, entrenamiento de modelos, decisiones. Es lo que justifica todo lo anterior.
• Gobernanza: el conjunto de normas y responsabilidades sobre los datos: quién es propietario de cada conjunto de datos (Marta propuso que cada área lo sea de los suyos: operaciones de incidencias.csv, marketing de resenas.csv), quién puede acceder a qué, cuánto tiempo se conservan, cómo se documentan (un diccionario de datos con la definición de cada columna) y cómo se cumple la legislación (sección 7). La gobernanza cierra el ciclo porque sus normas mejoran la siguiente recogida.

Sin gobernanza, cada proyecto de IA vuelve a descubrir los mismos problemas. Con ella, el segundo proyecto de NovaMarket (previsión de demanda) reutiliza los datos limpios del primero (recomendación).

"Datos de calidad" no es un juicio vago: se descompone en dimensiones medibles. Las cinco más usadas, con los problemas que Marta encontró al abrir los CSV de NovaMarket por primera vez:

Dos comentarios importantes:

• La calidad se mide, no se supone. Marta hizo lo que haremos en la sección 9: contar vacíos, duplicados y formatos por columna y ponerle números. Descubrir que un 58 % de las filas de una muestra tenía algún problema fue lo que convenció a Diego de dedicar tiempo a la limpieza antes que a los modelos.
• La calidad depende del uso. Un código postal vacío es irrelevante para clasificar reseñas y grave para planificar rutas. No existe "el" nivel de calidad: existe el suficiente para cada caso de uso.

Cómo se limpian estos problemas para preparar un modelo (imputación de valores, codificación de categorías, escalado, tratamiento de atípicos) es el contenido de 04-03; aquí nos quedamos en detectarlos y medirlos.

Un sesgo en los datos es una desviación sistemática entre lo que los datos representan y la realidad que deberían representar. No es un problema de "datos sucios" (los datos pueden estar limpísimos y sesgados) sino de qué se recogió, de quién y cómo se etiquetó. Como el modelo hereda lo que hay en los datos, el sesgo se convierte en decisiones sistemáticamente desviadas, y cuando esas decisiones afectan a personas, en injusticia algorítmica. Los tres orígenes principales:

Otros sesgos frecuentes: el de supervivencia (solo vemos los datos que "sobrevivieron": analizamos a los clientes que siguen comprando y olvidamos por qué se fueron los que se fueron), el de medición (un sensor o formulario captura peor a un grupo: el formulario de devoluciones en la app es más incómodo que en la web, así que los clientes de móvil rellenan menos) y el de confirmación en el análisis (buscar en los datos lo que ya creíamos, como la regla de 300 € de Diego).

Lo esencial en esta lección: el sesgo entra por los datos y se manifiesta en las decisiones. Cómo evaluar sus consecuencias éticas, cómo medir la disparidad entre grupos y qué hacer al respecto es el contenido de la próxima lección, 02-04.

Buena parte de los datos de NovaMarket son datos personales: identifican o permiten identificar a una persona (nombre, correo, dirección, teléfono, historial de compras, incluso una combinación de código postal, fecha de nacimiento y sexo). En la Unión Europea su tratamiento está regulado por el Reglamento General de Protección de Datos (RGPD). Aquí no vamos a estudiar la norma (que se retoma en el marco regulatorio de 02-04) sino los principios que afectan directamente al trabajo con datos para IA:

• Finalidad y base jurídica: los datos se recogen para un fin concreto y con una base legal (contrato, consentimiento, interés legítimo...). Usar el historial de compras para recomendar productos puede encajar; usarlo para algo no previsto (venderlo, perfilar con fines ajenos) no.
• Minimización: recoger y usar solo los datos necesarios para el fin. Si para prever la demanda basta con la fecha, el producto, la ciudad y las unidades, no hace falta cargar el nombre y el correo del cliente en el conjunto de entrenamiento. Menos datos personales significa menos riesgo y menos obligaciones.
• Limitación del plazo de conservación: no guardar datos personales más tiempo del necesario. Esto choca con el instinto de "guardar todo por si sirve para entrenar algo"; hay que definir plazos.
• Derechos de las personas: acceso, rectificación, supresión ("olvido"), oposición al perfilado y a decisiones automatizadas con efectos significativos. Un modelo entrenado con los datos de un cliente que pide su supresión plantea preguntas prácticas que el proyecto debe prever.
• Seguridad: proteger los datos frente a accesos indebidos, especialmente cuando se copian a entornos de análisis o se envían a servicios en la nube (recuerda la dicotomía nube/dispositivo de 02-02).

Dos técnicas que reducen el riesgo y que aparecerán constantemente:

Marta decidió que los conjuntos de datos que se usen para entrenar modelos en NovaMarket estén siempre, como mínimo, seudonimizados, y que la previsión de demanda trabaje con datos agregados (anónimos).

Aviso importante: todo lo anterior es una descripción conceptual con fines formativos, no asesoramiento jurídico. Cualquier proyecto que trate datos personales debe revisarse con el delegado de protección de datos o un profesional legal, que evaluará la base jurídica, la necesidad de una evaluación de impacto y las medidas concretas.

Es habitual oír que "cuantos más datos, mejor". Es cierto a medias:

• Más datos ayudan cuando son variados y representativos: permiten aprender patrones más finos y reducen el peligro de que el modelo memorice casos concretos (el sobreajuste, tema de 04-06). Los grandes avances del deep learning se apoyaron en conjuntos enormes.
• Más datos malos no ayudan: multiplicar por diez un conjunto sesgado da un modelo diez veces más seguro de su sesgo. Doscientos ejemplos bien etiquetados de causas de incidencia valen más que dos mil etiquetados de cualquier manera.
• Los datos deben ser relevantes: para el recomendador de NovaMarket, los pedidos de otra tienda de otro sector aportan poco.

Regla práctica: primero calidad y representatividad; después, cantidad. Y mide siempre si más datos mejoran realmente el resultado.

Los datos sintéticos son datos generados artificialmente (mediante reglas, simulación o modelos generativos) que imitan las propiedades estadísticas de los reales. Se usan para: completar clases poco frecuentes (hay muy pocos fraudes reales de los que aprender), probar sistemas sin exponer datos personales, o simular escenarios que aún no han ocurrido (una campaña de Navidad para un producto nuevo). Tienen un límite evidente: solo contienen lo que quien los generó sabía o supuso; no descubren nada nuevo del mundo, y si se generan a partir de datos sesgados, heredan el sesgo. Son un complemento, no un sustituto.

Vamos a hacer lo que hizo Marta el primer día: leer un extracto de pedidos.csv, contar los problemas por dimensión y producir un pequeño informe. Para que el ejemplo sea autocontenido, el CSV está escrito dentro del programa como una cadena de texto; en la práctica lo leerías con open("pedidos.csv"). Solo usamos la biblioteca estándar: csv, io, re y collections.

Salida:

Explicación: csv.DictReader lee la primera línea como cabecera y convierte cada línea siguiente en un diccionario, lo que nos permite acceder a los valores por nombre (fila["importe"]). Observa que todo se lee como texto: '89.90' es una cadena, no un número; convertirlo será responsabilidad nuestra. Si miras los datos con atención ya verás los problemas sembrados: un importe vacío, un id_cliente vacío, un devuelto vacío, un codigo_postal vacío, tres formatos de fecha, una fecha con mes 13, un importe de 15990 que huele a céntimos, "zaragoza" en minúsculas y el pedido 48202 dos veces.

Salida:

Explicación: para cada columna recorremos las filas y contamos las que tienen la celda vacía tras quitar espacios (strip()); un espacio en blanco también es un vacío. La expresión sum(1 for f in filas if ...) es una forma compacta de contar. Con el incidencias.csv real, este informe es el que mostraría "causa: 50,0 %".

Explicación: Counter construye un diccionario valor → número de apariciones; nos quedamos con los que aparecen más de una vez. Aquí el duplicado es exacto (la misma fila cargada dos veces), el caso fácil. Los duplicados difíciles son los de clientes.csv: mismo cliente con correo en mayúsculas o con espacio final. Para esos, la clave habría que normalizarla antes de contar: f["email"].strip().lower(). Pruébalo como variante.

Explicación: cada patrón es una expresión regular: ^\d{4}-\d{2}-\d{2}$ significa "exactamente cuatro dígitos, guion, dos dígitos, guion, dos dígitos". clasificar_fecha devuelve el nombre del primer patrón que encaja. El Counter final nos dice cuántas fechas hay de cada formato: tres filas no siguen el estándar. Ordenar o comparar esas fechas como texto daría resultados absurdos, y cualquier programa que esperase AAAA-MM-DD fallaría en ellas.

Explicación: la exactitud no se puede comprobar del todo sin una fuente de verdad, pero sí podemos detectar valores imposibles (mes 13) y valores fuera del rango razonable (un pedido de 15.990 € en una tienda cuyo ticket medio ronda los 100 € huele a importe en céntimos: 159,90 €). El umbral de 5.000 € es una regla de negocio que fijó Diego. Fíjate en que el importe sospechoso aparece dos veces porque la fila está duplicada: los problemas de calidad se acumulan.

Salida:

Explicación: contando los valores tal cual hay siete ciudades; normalizando (sin espacios, en minúsculas) hay seis. La diferencia es exactamente el número de inconsistencias. Este truco (comparar el número de valores distintos antes y después de normalizar) sirve para cualquier columna categórica.

Salida:

Explicación: el informe reúne las comprobaciones anteriores y añade una métrica global: el porcentaje de filas con al menos un problema. Un 58 % de filas problemáticas en una muestra pequeña y exagerada; en el fichero real de NovaMarket la cifra fue menor pero suficiente para justificar un proyecto previo de limpieza. La "puntuación de calidad" es una simplificación (todas las dimensiones pesan igual), pero convierte una sensación en un número que se puede seguir en el tiempo: el objetivo de Marta es que suba mes a mes. Como ejercicio mental, piensa qué añadirías para medir la actualidad (necesitarías una columna con la fecha de última actualización) y qué necesitarías para medir la exactitud de verdad (una fuente de referencia con la que comparar).

• Empezar por el modelo. El impulso natural es entrenar algo cuanto antes. Empieza siempre por un informe de calidad como el de la sección 9; una hora de comprobaciones ahorra semanas de depurar por qué el modelo "hace cosas raras".
• Confiar en que un fichero limpio no está sesgado. Calidad y representatividad son cosas distintas. Pregunta siempre quién falta en los datos y por qué.
• Tratar el vacío como cero, o como una categoría más, sin pensarlo. Un importe vacío no es un importe de 0 €; una causa vacía no es "sin causa". Antes de decidir qué hacer con los vacíos hay que entender por qué faltan (¿es aleatorio o falta más en los días de pico?).
• Ignorar las unidades. Céntimos frente a euros, gramos frente a kilos, hora local frente a UTC. Documenta las unidades en el diccionario de datos y valida los rangos.
• Guardar todo "por si acaso". Choca con la minimización y la limitación de conservación del RGPD y aumenta el riesgo. Recoge y conserva lo necesario para un fin definido.
• Anonimizar quitando solo el nombre. Código postal + fecha de nacimiento + sexo identifican a una gran parte de la población. Si necesitas anonimizar de verdad, agrega o generaliza, y pide revisión experta.
• Consejo: crea el diccionario de datos desde el primer día (columna, significado, tipo, unidad, valores permitidos, quién es responsable). Es el documento más útil y menos glamuroso de un proyecto de IA.

Para cada uno de los cinco ficheros (clientes.csv, pedidos.csv, productos.csv, resenas.csv, incidencias.csv), indica: (a) si es estructurado, semiestructurado o no estructurado (o mixto: qué columnas de cada tipo); (b) qué columna podría ser una etiqueta y para qué caso de uso de la lista de 01-03; (c) si contiene datos personales y qué medida (seudonimización, anonimización, minimización) aplicarías antes de usarlo para entrenar.

NovaMarket quiere entrenar un modelo que prediga si un pedido será devuelto, usando el histórico de pedidos.csv de los últimos tres años. Durante ese periodo: (i) las devoluciones de la app móvil se registraban en otro sistema y no están en el fichero; (ii) el equipo de Diego revisaba manualmente y anulaba muchas devoluciones "dudosas" de pedidos de más de 300 € (su antigua regla); (iii) la columna motivo_devolucion la rellenaban los clientes libremente. Identifica qué tipo de sesgo introduce cada circunstancia y qué efecto tendría en el modelo.

Amplía el programa de la sección 9 con dos comprobaciones: (a) el campo devuelto solo admite los valores si y no (cualquier otro, incluido el vacío, es un problema de consistencia); (b) el codigo_postal, cuando no está vacío, debe tener exactamente 5 dígitos y sus dos primeros dígitos deben ser coherentes con la ciudad para al menos estos casos: Zaragoza → 50, Madrid → 28, Getafe → 28 (problema de exactitud). Añade el recuento de ambos al informe.

Solución 1.

Solución 2.

• (i) Devoluciones de la app ausentes: sesgo de muestreo (o de medición). El modelo subestimará las devoluciones de los clientes que compran por móvil; si el canal está correlacionado con la edad o el tipo de producto, el modelo se equivocará sistemáticamente en esos grupos.
• (ii) Anulaciones manuales de devoluciones dudosas de más de 300 €: sesgo histórico (los datos reflejan una política pasada). El histórico contiene menos devoluciones "consumadas" en pedidos altos de lo que ocurriría sin la intervención de Diego; el modelo puede aprender que los pedidos caros se devuelven poco, justo lo contrario de lo que motivó la regla, y además incorpora el criterio subjetivo de qué era "dudoso". Si el modelo se usa para decidir qué revisar, se crea un bucle de retroalimentación.
• (iii) Motivo escrito libremente por el cliente: sesgo de etiquetado (y problema de consistencia). "No me gusta", "no era lo que esperaba", "talla" y "calidad mala" pueden ser lo mismo o no; el modelo aprende las palabras que usa cada cliente, no la causa real. Habría que normalizar los motivos a una lista cerrada antes de usarlos como etiqueta.

Solución 3.

Para incorporarlo al informe basta añadir dos líneas dentro de informe_calidad con len(problemas_devuelto(filas)) y len(problemas_codigo_postal(filas)) e incluir esos identificadores en la condición de "fila con problema". Con los datos de ejemplo la comprobación de código postal no encuentra errores; añade una fila 48212,C1009,2026-03-06,20.00,Madrid,50003,no y comprueba que la detecta.

En esta lección hemos tratado los datos como lo que son en la IA moderna: la materia prima de la que el modelo hereda todo, tanto el conocimiento como los errores y los sesgos. Hemos clasificado los datos por estructura (estructurados, semiestructurados, no estructurados), por naturaleza (numéricos, categóricos, texto, imagen, series temporales) y por la presencia de etiquetas, anticipando la distinción entre aprendizaje supervisado y no supervisado. Hemos recorrido el ciclo de vida del dato (recogida, almacenamiento, calidad, uso, gobernanza) y hemos desglosado la calidad en cinco dimensiones medibles (completitud, exactitud, consistencia, actualidad, unicidad) ilustradas con los problemas reales de los CSV de NovaMarket: la mitad de la columna causa vacía, clientes duplicados, fechas en tres formatos y precios en céntimos. Hemos visto que el sesgo entra por los datos (muestreo, histórico, etiquetado) y se convierte en decisiones desviadas, hemos presentado los principios del RGPD que afectan al trabajo con datos (finalidad, minimización, conservación, derechos, seguridad) junto con la seudonimización y la anonimización, y hemos matizado el mito de "más datos siempre es mejor". Por último, hemos escrito un programa que lee un CSV con la biblioteca estándar y produce un informe de calidad: la primera herramienta que debería ejecutarse en cualquier proyecto de IA.

Con los datos ya sobre la mesa, la siguiente lección, Ética y Consideraciones en IA, aborda lo que ocurre cuando esos datos, con sus sesgos, alimentan decisiones que afectan a personas: qué principios éticos deben guiar a NovaMarket, qué problemas concretos (discriminación, privacidad, opacidad, responsabilidad, impacto laboral, desinformación, sostenibilidad) hay que prever, qué exige el marco regulatorio europeo y qué herramientas prácticas (checklist, evaluación de impacto, revisión humana, métricas de equidad) permiten pasar de las buenas intenciones a los hechos. Retomaremos allí el modelo de riesgo de devolución y el código postal para medir, con números, si un modelo trata igual a todos los grupos.