Big data: qué son los datos masivos y cómo se usan

Objetivo didáctico

Al terminar esta ficha serás capaz de analizar ecosistemas de datos masivos y evaluar cómo su estructura, escala, uso analítico y gobierno afectan decisiones, privacidad y equidad cuando interpretes tableros, servicios digitales, políticas públicas o sistemas que procesan grandes volúmenes de información.

Introducción

El término big data suele evocar servidores gigantes, inteligencia artificial y cantidades casi incomprensibles de información. Esa imagen es incompleta. Un problema de datos se vuelve “masivo” no solo porque contenga muchos registros, sino porque combina escalas, velocidades, formatos y relaciones que desbordan las formas tradicionales de recopilar, almacenar y analizar información. Además, los datos suelen producirse continuamente como subproducto de otras actividades: pagar, desplazarse, buscar, comprar, publicar, solicitar un servicio o utilizar una aplicación.

Kitchin (2014) propone entender esta transformación como parte de una revolución más amplia de infraestructuras, prácticas y formas de conocimiento. boyd y Crawford (2012), por su parte, advirtieron que el entusiasmo por grandes conjuntos de datos puede ocultar supuestos sobre objetividad, representatividad y acceso. La magnitud no neutraliza los problemas clásicos de la estadística; puede amplificarlos. Un sesgo repetido diez millones de veces sigue siendo un sesgo, aunque ahora pueda calcularse con más decimales.

Desde las matemáticas, el problema atraviesa varias capas. Contar registros exige combinatoria y agregación; estimar patrones requiere estadística y probabilidad; representar relaciones utiliza matrices y grafos; reducir textos o imágenes a variables exige transformaciones numéricas; comparar grupos implica denominadores y distribuciones; y proteger privacidad puede requerir introducir incertidumbre deliberadamente. La matemática no aparece al final del proceso: está incorporada en cada decisión sobre qué medir y cómo resumirlo.

Esto importa en la vida cotidiana porque muchas decisiones que afectan a una persona ya pasan por infraestructuras de datos aunque ella nunca vea la base subyacente. Un comercio ajusta inventario según transacciones; una plataforma ordena contenidos según actividad; una ciudad estudia movilidad; una institución detecta congestión o demanda; una organización segmenta usuarios. Cada sistema transforma rastros en variables y variables en decisiones.

El recorrido seguirá cinco preguntas: ¿qué piezas forman un ecosistema de datos?, ¿qué cambia entre datos estructurados y no estructurados?, ¿por qué la privacidad se vuelve más difícil a gran escala?, ¿cómo la inteligencia de negocios convierte datos en indicadores?, y ¿qué criterios éticos deberían limitar aquello que técnicamente es posible hacer? La conexión entre las cinco es decisiva: ningún análisis puede juzgarse sin conocer cómo nacieron sus datos.

Desarrollo del tema

El ecosistema de datos: una cadena donde cada decisión deja huella

Un conjunto de datos no aparece espontáneamente en una tabla. Existe una cadena que comienza en las fuentes: sensores, formularios, pagos, aplicaciones, sistemas administrativos, encuestas o plataformas. Después ocurre la ingesta, el almacenamiento, la limpieza, la transformación y el análisis. Finalmente, algún resultado —una alerta, un indicador, una clasificación o una recomendación— entra en una decisión. En sistemas maduros existe además retroalimentación: la decisión modifica el comportamiento y genera nuevos datos.

Esta perspectiva cambia el significado de “calidad”. No basta con preguntar si una columna contiene errores. También debe preguntarse qué población genera los registros, qué evento activa la captura, qué unidades faltan y qué transformación produjo cada variable. Kitchin (2014) describió los datos masivos como sistemas caracterizados no solo por volumen, sino también por granularidad, relacionalidad, velocidad, variedad y flexibilidad. Cada propiedad abre posibilidades analíticas y nuevas fuentes de error.

Imagine un sistema metropolitano que desea entender la demanda de transporte. Podría combinar conteos de ascensos, posición GPS de vehículos, horarios programados, reportes de usuarios y datos climáticos. Cada fuente describe un aspecto diferente. Los registros de validación muestran viajes pagados, pero no necesariamente personas que esperaron y desistieron; una aplicación recoge opiniones de quienes pueden y quieren utilizarla, no de toda la población. La arquitectura de datos define qué realidad puede verse.

Por eso la trazabilidad es una competencia central. Una cifra como “demanda diaria = 820,000 viajes” debería poder conectarse con su definición, periodo, fuentes y transformaciones. En un ecosistema serio, el dato no viaja solo: viaja con metadatos, reglas y responsables. Cuando esos vínculos desaparecen, el análisis se parece a recibir una fotografía recortada sin saber cuándo, dónde ni por qué fue tomada.

Datos estructurados y no estructurados: la forma condiciona lo que puede calcularse

Los datos estructurados siguen un esquema explícito: filas, columnas, tipos y relaciones definidas. Una tabla de transacciones puede contener fecha, sucursal, producto, cantidad y precio; una operación como sumar ventas mensuales o agrupar por región resulta directa. En 1970, Edgar F. Codd publicó su modelo relacional para grandes bancos de datos compartidos, proponiendo representar la información mediante relaciones y separarla de los detalles físicos de almacenamiento (Codd, 1970).

Entre la tabla perfectamente definida y el contenido libre existe una zona intermedia. Archivos JSON, registros de eventos y documentos XML son ejemplos de datos semiestructurados: poseen etiquetas o jerarquías, pero no necesariamente una tabla rígida idéntica para cada registro. Por otro lado, textos, fotografías, grabaciones, videos y documentos suelen clasificarse como no estructurados porque su significado no está organizado originalmente en columnas listas para análisis numérico.

Para analizar datos no estructurados es necesario producir alguna representación. Un texto puede convertirse en frecuencias de palabras, temas, etiquetas o vectores numéricos; una imagen puede representarse mediante píxeles o características aprendidas; un audio puede transformarse en señales y espectros. Cada conversión conserva cierta información y descarta otra. Matemáticamente, pasar de un documento a un vector de dimensión 768, por ejemplo, facilita calcular similitudes, pero no significa que 768 coordenadas contengan todo el significado humano del texto.

La diferencia aparece en servicios cotidianos. Suponga que una institución recibe 10,000 solicitudes ciudadanas. La fecha, zona y tipo de trámite pueden analizarse como variables estructuradas. El campo “describe tu problema” contiene matices que una lista de categorías no anticipó. Si solo se analizan columnas cerradas, se pierde contexto; si solo se leen textos, resulta difícil observar tendencias globales. Un ecosistema robusto combina ambas capas y conserva un enlace auditable entre la síntesis y la fuente original.

Privacidad a escala: quitar el nombre no siempre vuelve anónimos los datos

Una intuición frecuente sostiene que una base deja de ser personal cuando se eliminan nombre, teléfono y correo. El problema es que las identidades pueden emerger de combinaciones. Horarios, ubicaciones, edades, trayectorias, consumos o dispositivos pueden funcionar como cuasi-identificadores. Cuantas más fuentes pueden enlazarse, mayor es la posibilidad de que una combinación aparentemente inocua apunte hacia una persona concreta.

Este riesgo es una consecuencia matemática de la unicidad. Si cada atributo divide la población en subconjuntos y varios atributos se intersectan, los grupos resultantes se vuelven progresivamente pequeños. Un registro puede no contener una etiqueta “persona = Ana”, pero un patrón extremadamente raro puede actuar casi como una huella. La anonimización, por tanto, debe analizarse como propiedad del conjunto, del contexto y de las fuentes externas disponibles.

En México, la Ley Federal de Protección de Datos Personales en Posesión de los Particulares publicada el 20 de marzo de 2025 —con reforma reportada al 14 de noviembre de 2025— establece como parte de su objeto regular el tratamiento legítimo, controlado e informado y garantizar la privacidad y la autodeterminación informativa. Para un ecosistema de datos, esto implica pensar desde el diseño en finalidad, proporcionalidad, acceso, conservación y responsabilidades, no añadir un aviso de privacidad después de haber construido el sistema.

Existen técnicas matemáticas para reducir riesgos: agregación, generalización, supresión, privacidad diferencial y controles de consulta, entre otras. Ninguna elimina automáticamente el problema. Aumentar privacidad suele reducir cierta utilidad analítica, y aumentar detalle puede elevar el riesgo de identificación. El diseño responsable consiste en justificar qué resolución necesita realmente la pregunta. Para saber cuántos viajes entran a una zona por hora quizá no sea necesario conservar durante años la trayectoria exacta de cada dispositivo.

La pregunta madura no es “¿podemos guardar estos datos?”, sino “¿qué resolución necesitamos para esta finalidad y qué riesgo adicional produce conservar más?”. A escala masiva, pequeños excesos por persona se transforman en grandes superficies de exposición colectiva. La privacidad debe modelarse como una restricción del sistema, igual que costo, latencia o capacidad.

Inteligencia de negocios: convertir registros en una decisión, no solo en un tablero

La expresión business intelligence tiene una historia anterior a los tableros modernos. En 1958, Hans Peter Luhn publicó “A Business Intelligence System” en IBM Journal of Research and Development. Propuso un sistema automatizado para distribuir información relevante dentro de una organización. Décadas después, bases de datos, almacenes analíticos y herramientas visuales convirtieron esa intuición en arquitecturas capaces de integrar indicadores procedentes de múltiples áreas (Luhn, 1958).

La inteligencia de negocios contemporánea suele condensar datos en KPI —indicadores clave de desempeño—, comparaciones, tendencias, segmentaciones y alertas. El paso matemático decisivo es la definición de cada indicador. “Porcentaje de viajes puntuales” parece una cifra objetiva, pero depende de qué significa puntualidad, cuáles viajes entran en el denominador, cómo se tratan cancelaciones y qué periodo se compara.

Esta pregunta ilustra por qué un tablero es un modelo de la organización. Selecciona unas dimensiones, excluye otras y comprime miles de eventos en unas cuantas cifras. Una media puede esconder dispersión; una tasa global puede ocultar zonas con desempeño muy distinto; un acumulado mensual puede esconder un colapso de tres días. Cambiar agregación temporal, segmentación o denominador puede alterar la historia que parece contar el mismo conjunto de datos.

Una práctica avanzada consiste en asociar cada KPI con cinco elementos: definición matemática, fuente, frecuencia de actualización, segmento de referencia y decisión que pretende informar. Un indicador sin decisión asociada suele convertirse en decoración. Al contrario, si una organización sabe que “espera superior a 15 minutos en hora pico” dispara una revisión operativa, el dato adquiere un papel explícito y auditable.

También debe distinguirse entre descripción y causalidad. Un tablero puede mostrar que las ventas bajaron 12 % después de un cambio de precio, pero la secuencia temporal no demuestra por sí sola que el cambio causó toda la reducción. Competencia, estacionalidad, inventario o contexto económico pueden intervenir. La inteligencia de negocios ayuda a detectar preguntas; para responder algunas de ellas se necesitan diseños estadísticos o experimentales adicionales.

Ética del uso de datos: una operación puede ser correcta y una decisión seguir siendo injusta

La ética de datos comienza donde termina la pregunta “¿funciona?”. Un sistema puede predecir con alta precisión y seguir siendo problemático si la variable objetivo no debería utilizarse, si los errores recaen desproporcionadamente sobre un grupo o si las personas nunca tuvieron una expectativa razonable de que sus datos serían empleados con esa finalidad. La precisión estadística describe desempeño respecto de una métrica; no determina por sí sola legitimidad.

boyd y Crawford publicaron en 2012 seis provocaciones críticas sobre big data. Entre sus preocupaciones estaban la aparente objetividad, los cambios en la definición de conocimiento, las diferencias de acceso y los problemas éticos que surgen cuando la disponibilidad técnica de información se confunde con autorización para utilizarla. Su crítica sigue siendo útil porque obliga a situar los números dentro de relaciones sociales y de poder (boyd & Crawford, 2012).

La distribución de los resultados es particularmente importante. Suponga que un sistema obtiene 90 % de precisión global, pero solo 68 % para una población que representa 8 % de los casos. El promedio puede parecer satisfactorio mientras concentra errores en quienes menos peso tienen dentro de la métrica agregada. Evaluar equidad exige desagregar, comparar tasas y analizar consecuencias, no solamente admirar un número general.

También existe una dimensión de retroalimentación. Si un sistema dirige más inspecciones hacia lugares donde históricamente encontró más incidentes, recogerá aún más datos de esos lugares. Después podrá interpretar esa concentración de registros como evidencia de que allí “ocurre más”, aunque parte del patrón provenga de dónde decidió observar. Los datos no siempre son un espejo pasivo; a veces son producto de decisiones anteriores.

Por eso la ética no debe agregarse como última columna de una lista de requisitos. Debe intervenir en la definición de variables, selección de fuentes, periodo de retención, acceso, métricas y mecanismos de revisión. En sistemas de datos masivos, una pequeña decisión de diseño puede repetirse millones de veces. La escala transforma elecciones técnicas en consecuencias sociales.

Conclusión

El objetivo era aprender a analizar ecosistemas de datos masivos y evaluar cómo su estructura afecta las decisiones. La idea central es que ningún dato llega desnudo al análisis. Tiene una fuente, una población observable, un formato, una historia de transformaciones y una finalidad. Cuando esas capas permanecen visibles, un tablero o modelo puede auditarse. Cuando desaparecen, los resultados adquieren una apariencia de objetividad mayor que la evidencia que los sostiene.

La distinción entre estructurado y no estructurado muestra que transformar información también significa interpretarla. La privacidad a escala demuestra que eliminar identificadores explícitos puede ser insuficiente cuando existen combinaciones únicas y fuentes enlazables. La inteligencia de negocios recuerda que todo indicador depende de definiciones matemáticas y decisiones de agregación. Y la ética obliga a preguntar no solo cuántos errores produce un sistema, sino quién los recibe y qué capacidad tiene para cuestionarlos.

El pensamiento matemático avanzado frente al big data no consiste en desconfiar de toda automatización ni en celebrar cualquier análisis masivo. Consiste en formular preguntas más exigentes: ¿qué universo representa esta base?, ¿qué variable estamos usando como sustituto de lo que realmente importa?, ¿qué inferencia permite la estructura de los datos?, ¿qué riesgo creamos al enlazarlos?, ¿qué decisión cambiará si el indicador cambia? La escala hace más poderosa a la matemática, pero también hace más costosos sus supuestos invisibles.

Actividad de aprendizaje autónoma

Producto esperado: auditoría de un ecosistema de datos y tablero de decisión. Construirá un análisis breve de un sistema hipotético de movilidad urbana. La meta no es programar una plataforma, sino demostrar que puede seguir la cadena desde la captura hasta la decisión e identificar dónde aparecen riesgos matemáticos, de privacidad y de ética.

Suponga que una ciudad latinoamericana desea mejorar su transporte público combinando cuatro fuentes: validaciones de tarjetas, GPS de autobuses, comentarios enviados desde una aplicación y reportes operativos de las rutas. El equipo directivo quiere un tablero para decidir dónde aumentar frecuencias.

1. Defina la pregunta de decisión en una sola oración. Evite objetivos abiertos como “aprovechar mejor los datos”.
2. Clasifique cada fuente como estructurada, semiestructurada o no estructurada y explique qué información conserva y qué información no puede observar.
3. Dibuje un flujo con al menos seis etapas: fuente, ingesta, almacenamiento, transformación, análisis y decisión.
4. Diseñe tres KPI. Para cada uno escriba numerador, denominador, periodo temporal y segmento de referencia.
5. Identifique al menos tres riesgos de privacidad. Incluya uno que pueda surgir al vincular fuentes que por separado parecían poco sensibles.
6. Proponga una regla de minimización: qué dato no conservaría, qué dato agregaría y qué periodo de retención justificaría.
7. Construya un escenario donde un indicador global mejore pero una zona o grupo específico empeore. Explique qué agregación ocultó el problema.
8. Redacte una recomendación final de 250 a 350 palabras. Debe separar explícitamente utilidad analítica, calidad de datos, privacidad y ética.

Antes de cerrar la auditoría, complete las cuatro relaciones. El objetivo es verificar que los conceptos esenciales aparezcan después, con sus propias palabras, dentro de su recomendación.

Criterio global de logro: la auditoría está completa si una persona externa puede identificar de dónde procede cada fuente, qué población representa, cómo se transforma, qué indicador produce, qué decisión activa y qué riesgo permanece. Una buena entrega no afirma simplemente “los datos son útiles”: especifica bajo qué condiciones son útiles y qué límites impiden tratarlos como una representación total de la realidad.

Reflexión final: si una organización descubre que un dato mejora notablemente la precisión de su modelo, pero las personas nunca imaginaron que ese dato se utilizaría para esa finalidad, ¿qué evidencia consideraría necesaria antes de autorizar su uso?