Cómo construir un conjunto de datos fiable para análisis posteriores

Introducción: preparar datos no es lo mismo que construir un dataset fiable

La fiabilidad, la trazabilidad, la granularidad, la consistencia y la reproducibilidad son cinco condiciones que convierten una colección de registros en una base útil para tomar decisiones. Sin ellas, una tabla aparentemente ordenada puede producir conclusiones equivocadas.

Imagina que una empresa quiere analizar cuánto tarda en resolver las incidencias de sus clientes. Dispone de exportaciones de su sistema de atención, un fichero de clientes y varios informes mensuales. Reunirlo todo en una hoja de cálculo parece sencillo, pero pronto surgen preguntas: ¿cada fila representa una incidencia o una intervención?, ¿qué ocurre si una incidencia se reabre?, ¿qué fecha se utiliza para el análisis?, ¿los clientes sin coincidencia se descartan?, ¿puede reconstruirse el mismo resultado dentro de tres meses?

Construir un conjunto de datos fiable significa definir, transformar, comprobar y entregar una unidad de información con reglas explícitas. El objetivo no es conseguir una tabla sin celdas vacías, sino un conjunto de observaciones adecuado para una finalidad concreta, con límites conocidos y resultados verificables.

Esta guía explica un procedimiento práctico, desde la definición de la unidad de análisis hasta la publicación de una versión validada del dataset. Está orientada a profesionales que preparan información para informes, estadística, cuadros de mando, modelos predictivos o decisiones operativas, también cuando trabajan en equipos pequeños y con herramientas asequibles.

Índice de contenidos

1. Empezar por la pregunta que deberá responder el conjunto de datos

Antes de abrir un CSV, crear una consulta SQL o escribir un script, conviene formular la decisión que los datos ayudarán a tomar. Un dataset puede ser técnicamente correcto y, aun así, inútil para el análisis previsto si recoge la población equivocada o mezcla niveles de detalle.

Por ejemplo, «analizar incidencias» es demasiado ambiguo. Una formulación operativa sería: «Comparar, por mes de apertura y segmento de cliente, el tiempo de resolución de las incidencias recibidas entre enero y septiembre, considerando únicamente la información disponible al cierre del periodo».

De esa formulación se obtienen varios requisitos:

• Una población: incidencias registradas durante unos meses determinados.
• Una unidad de observación: cada incidencia, no cada cambio de estado ni cada mensaje.
• Un horizonte temporal: apertura y situación conocida a una fecha de corte.
• Variables indispensables: identificador, fechas, cliente, segmento y estado.
• Una salida esperada: un registro por incidencia, apto para agrupar y calcular indicadores.

Es útil distinguir entre dataset operativo, preparado para examinar cómo funciona un proceso, y dataset analítico, diseñado para contestar una pregunta determinada. El mismo origen puede necesitar representaciones diferentes: una tabla de eventos sirve para reconstruir el historial de una incidencia; una tabla de incidencias sirve para contar expedientes y calcular tiempos. Ninguna es universalmente mejor.

Si la cuestión es si existen datos suficientes o adecuados para empezar, esa evaluación debe hacerse antes de construir el conjunto definitivo. En este artículo nos concentramos en el paso siguiente: convertir fuentes identificadas en un activo analítico controlado.

2. Escribir un contrato mínimo del dataset antes de procesar nada

El contrato del dataset es un acuerdo verificable sobre qué contiene, cómo se interpreta y qué condiciones debe cumplir. No necesita una plataforma especializada: puede comenzar como una tabla en un documento de proyecto. Lo importante es que las decisiones no dependan de la memoria de quien prepara los datos.

Definir la granularidad: qué significa exactamente una fila

La granularidad es la unidad que representa cada registro. En nuestro ejemplo: «una fila por ticket_id». Si el fichero de origen incluye una fila por intervención, las incidencias con tres intervenciones aparecerán tres veces. Contarlas directamente triplicaría parte del volumen.

La granularidad también determina las claves: ticket_id deberá ser único, mientras que cliente_id podrá repetirse porque un cliente puede tener varias incidencias. Si no puedes explicar la identidad de una fila en una oración, todavía no has definido correctamente el dataset.

Fijar población, exclusiones y fecha de referencia

Especifica quién o qué entra en la tabla y por qué. Puedes incluir todas las incidencias abiertas en el periodo, incluso las no resueltas, y excluir únicamente registros de pruebas identificados conforme a reglas documentadas. Excluir por defecto las incidencias abiertas generaría una visión demasiado optimista de los tiempos de resolución.

Determina también si el conjunto representa una fotografía histórica o la situación actual. «Datos de septiembre» no aclara si se han incorporado correcciones realizadas en octubre. Una fecha de corte explícita reduce esa ambigüedad.

Declarar el esquema y la semántica

Un contrato inicial para incidencias puede recoger los siguientes campos:

Conviene definir unidades, zona horaria, valores permitidos, obligatoriedad y método de cálculo. El significado de «duración» es particularmente importante: ¿horas naturales, horas laborables o tiempo neto descontando suspensiones? Elegir una fórmula sin declarar esta decisión puede hacer incomparables los resultados.

También es útil registrar quién autoriza cambios en estas definiciones. La gobernanza del dato no requiere una gran estructura jerárquica, pero sí un responsable de resolver ambigüedades.

3. Identificar las fuentes válidas y decidir cuál prevalece

Una empresa puede almacenar el mismo concepto en una base de datos, una exportación de Excel y un informe descargado a mano. Que las tres fuentes contengan una columna llamada «cliente» no significa que compartan identificadores, fechas de actualización o criterios de registro.

Para cada origen, responde a estas preguntas:

• ¿Qué aplicación o proceso crea el dato y cuál es su finalidad original?
• ¿Es una fuente primaria, una copia o un cálculo derivado?
• ¿Quién puede explicar sus campos y corregir errores de origen?
• ¿Con qué frecuencia cambia y hasta qué fecha está completa?
• ¿Qué identificador permite relacionarla con los demás sistemas?
• ¿Qué derechos y restricciones existen para utilizarla?

Por ejemplo, el sistema de incidencias puede ser la fuente autorizada para fechas y estados, mientras que el maestro de clientes lo es para identificadores y clasificación comercial. Cuando hay discrepancias, la solución no debe ser «quedarse con el fichero más reciente» sin comprobar qué fuente es competente para cada atributo.

Si todavía hay que inventariar procesos y orígenes dispersos, resulta útil disponer de un catálogo corporativo de datos. En cambio, cuando ya existen orígenes definidos, el trabajo consiste en establecer precedencias, reglas de conciliación y condiciones de incorporación al conjunto final.

No confundir actualidad con validez histórica

Una ficha de cliente descargada hoy puede mostrar el segmento actual, no el que tenía cuando se abrió una incidencia hace seis meses. En un análisis histórico esa diferencia importa. Si se necesita el segmento vigente en cada fecha, habrá que recurrir a un historial de cambios o reconocer la limitación de usar la clasificación actual.

La regla es sencilla: un atributo debe interpretarse en el momento temporal relevante para la pregunta. La fecha de extracción, por sí sola, no garantiza que la información sea históricamente correcta.

4. Extraer los datos sin destruir la evidencia original

El primer resultado de la extracción no debería ser el dataset final. Debería ser una copia identificable de los datos tal y como llegaron, acompañada de información que permita explicar su procedencia y repetir el proceso.

Un flujo sencillo separa tres zonas de trabajo:

1. Origen conservado: exportaciones o respuestas recibidas, sin ediciones manuales, protegidas contra sobrescritura accidental.
2. Trabajo intermedio: campos normalizados, uniones, reglas de exclusión y registros pendientes de revisión.
3. Entrega validada: versión final del conjunto, preparada para un análisis concreto.

La separación impide que una transformación fallida haga imposible contrastar lo ocurrido. También facilita localizar si un problema apareció en el origen, en una conversión o en una unión posterior.

Registrar la ejecución

Un manifiesto mínimo debería indicar identificador de ejecución, fecha y hora de extracción, origen, parámetros utilizados, periodo cubierto, número de registros obtenidos, versión del procedimiento y, cuando proceda, una huella criptográfica del fichero. Una suma SHA-256 sirve para detectar diferencias de contenido entre dos copias, pero no demuestra por sí sola que los datos sean verdaderos o completos.

Si la fuente cambia mientras se extraen varias tablas, conviene disponer de una instantánea coherente o de una estrategia de lectura con corte común. De lo contrario, es posible combinar una tabla de incidencias tomada a las 10:00 con una de clientes actualizada a las 10:30 y producir inconsistencias difíciles de reproducir.

Para convertir esta secuencia en un proceso periódico, puede estudiarse el diseño de pipelines sencillos de datos empresariales. La automatización es útil, pero no sustituye la definición de reglas que deben cumplir los ficheros generados.

5. Estandarizar formatos y significados sin borrar información

Los registros de distintos sistemas pueden expresar el mismo dato con formatos incompatibles: fechas como 30/09/2026 o 2026-09-30, importes con coma o punto decimal, códigos con ceros iniciales, nombres con espacios accidentales y estados con abreviaturas diferentes.

Estandarizar significa escoger una representación común manteniendo la posibilidad de comprobar qué valor se recibió originalmente. No implica reemplazar todos los valores sospechosos por lo que parezca más razonable.

Separar problemas sintácticos de problemas de negocio

Convertir una fecha textual a un tipo fecha es una operación técnica. Decidir si una incidencia registrada un domingo es válida es una cuestión de negocio. Del mismo modo, 000123 puede ser un identificador legítimo; transformarlo en el número 123 puede romper futuras relaciones.

Una secuencia prudente consiste en conservar la columna original durante el procesamiento, normalizar en una columna nueva, identificar los casos que no se pueden convertir y decidir su tratamiento conforme a las reglas acordadas.

• Identificadores: tratarlos como texto cuando su función sea identificar y no calcular.
• Fechas: definir zona horaria, interpretación de días y precisión necesaria; evitar fechas ambiguas.
• Categorías: utilizar tablas de equivalencias controladas y registrar las categorías desconocidas.
• Unidades: convertir magnitudes a una unidad común e indicar si son euros, horas, kilómetros o porcentajes.
• Ausencias: distinguir entre «no disponible», «no aplicable», «todavía no ocurrido» y «error de captura» cuando esa diferencia sea relevante.

No hace falta desarrollar aquí todas las técnicas de limpieza: para profundizar en esa fase puedes consultar cómo limpiar datos empresariales antes de analizarlos. En la construcción del dataset importa especialmente que cada limpieza sea justificable, registrable y compatible con la finalidad del análisis.

Evitar transformaciones irreversibles

Hay decisiones que destruyen información útil: redondear antes de tiempo, sobrescribir una fecha sin conservar la zona horaria de origen, eliminar todos los valores extremos o convertir categorías desconocidas en una categoría habitual. Siempre que una transformación reduzca detalle, conviene documentar su motivo y conservar la versión anterior fuera del conjunto de entrega.

6. Integrar tablas sin multiplicar filas ni perder observaciones

Los errores de unión son una de las causas más silenciosas de datasets poco fiables. Si una tabla contiene 8.000 incidencias y se cruza con otra que tiene dos filas por cliente, el resultado puede duplicar parte de las incidencias sin generar ningún mensaje de error.

Comprobar la cardinalidad antes de unir

Antes de ejecutar una unión, establece la relación esperada. En el ejemplo, varias incidencias pueden corresponder a un cliente, pero cada identificador de cliente debe aparecer una sola vez en la tabla maestra que se va a utilizar. Por tanto, la relación esperada es muchas incidencias a un cliente.

Las comprobaciones mínimas son:

• Unicidad de la clave en la tabla donde se espera una sola fila por identificador.
• Ausencia de identificadores vacíos en los registros que necesitan relacionarse.
• Porcentaje y número de claves sin correspondencia.
• Conteo de registros antes y después de la unión.
• Ausencia de un incremento inesperado de observaciones.

Si 8.000 incidencias pasan a 8.450 filas tras incorporar la ficha de cliente, no hay que aceptar el resultado y seguir adelante: primero debe explicarse el incremento.

No eliminar sin más los registros que no se pueden unir

Una unión interna puede descartar incidencias cuyo cliente no figure en la tabla maestra. El fichero resultante parecerá limpio, pero habrá perdido parte de la población y podría sesgar los resultados. Es preferible usar inicialmente una unión que preserve las incidencias, contar las no emparejadas y decidir si se corrigen, se ponen en cuarentena o se admite un campo desconocido conforme al contrato.

La existencia de duplicados tampoco justifica quedarse arbitrariamente con «la primera fila». Primero hay que decidir si son copias, revisiones del mismo registro o hechos legítimamente distintos. La metodología detallada para distinguirlos pertenece al tratamiento específico de duplicidades en los datos.

Conciliar totales y conservar el rastro de exclusiones

En cada paso anota cuántos registros entran, cuántos salen, cuántos se rechazan y por qué. Esta conciliación es especialmente importante cuando se unen orígenes con distintos niveles de detalle, como pedidos y líneas de pedido, clientes y contactos, o incidencias y eventos.

La igualdad del número de filas antes y después de una transformación no es prueba suficiente de exactitud: puede haberse eliminado una fila y duplicado otra. Por eso la conciliación debe acompañarse de comprobaciones de claves y, cuando proceda, de agregados de control.

7. Controlar el tiempo para no introducir información del futuro

Una tabla puede contener datos válidos y, sin embargo, ser engañosa si mezcla información de momentos diferentes. El problema aparece tanto en informes retrospectivos como en proyectos de predicción.

Definir qué se conocía en la fecha de corte

Supongamos que queremos comparar el estado de las incidencias a las 00:00 del 1 de octubre. Una incidencia abierta el 28 de septiembre y cerrada el 4 de octubre debe figurar como abierta en la fotografía de septiembre. Si usamos su estado actual, introducimos un hecho que todavía no había sucedido.

Para evitarlo, cada variable debe responder a una pregunta temporal: ¿en qué momento ocurrió el hecho?, ¿cuándo fue registrado?, ¿cuándo pasó a estar disponible para el análisis? Estas tres fechas pueden ser distintas.

Prevenir la fuga de información en usos predictivos

Si después se utiliza el dataset para predecir si una incidencia tardará más de dos días en cerrarse, no pueden incluirse como variables de entrada datos que solo se conocen al finalizarla, como la duración real o una clasificación calculada al cierre. Usarlos produciría resultados aparentemente excelentes en pruebas, pero imposibles de reproducir al realizar predicciones reales.

También conviene separar entrenamiento, validación y prueba respetando el orden temporal cuando el caso de uso lo exija. Dividir filas al azar no siempre reproduce las condiciones de uso y puede permitir que información del mismo cliente, expediente o periodo se filtre entre conjuntos.

Los cambios históricos de códigos, segmentos y responsables requieren el mismo cuidado. Si necesitas analizar cómo evolucionaron registros a lo largo del tiempo, puede ayudarte la guía sobre gestión de históricos empresariales con trazabilidad.

8. Pasar de revisiones visuales a pruebas de aceptación objetivas

La inspección manual puede descubrir errores llamativos, pero no basta para afirmar que un conjunto es fiable. Es necesario establecer pruebas repetibles con resultado «apto» o «no apto», preferiblemente antes de producir la versión definitiva.

Las pruebas dependen del uso previsto. No existe un porcentaje universal de valores nulos aceptable ni una cifra de calidad que sirva para todas las organizaciones. Un identificador ausente puede impedir completamente una unión; una fecha de cierre nula puede ser correcta cuando la incidencia sigue abierta.

Separar fallos que bloquean de advertencias

En el contrato pueden diferenciarse controles críticos, que impiden publicar, y advertencias, que exigen explicación. Por ejemplo, una clave primaria duplicada puede bloquear la entrega; una variación elevada en el volumen mensual puede generar una alerta para comprobar si responde a un cambio real del negocio.

Las alertas de volumen o de distribución necesitan una referencia razonable: estacionalidad, cambios de operación y tamaño de muestra influyen en el comportamiento esperado. Una alarma sin contexto puede hacer perder tanto tiempo como la ausencia de controles.

Conservar el resultado de cada prueba

Un informe de validación puede registrar fecha de ejecución, control aplicado, filas afectadas, resultado, gravedad y decisión. De este modo no solo se entrega «un CSV correcto»; se entrega un conjunto cuya aptitud puede justificarse ante otra persona.

Para profundizar específicamente en dimensiones, métricas y umbrales de calidad de los datos, conviene tratarlas como una disciplina propia. Aquí son un mecanismo de aceptación dentro de un proceso más amplio de construcción y entrega.

9. Ejemplo práctico: construir y validar un dataset de incidencias con Python

Veamos una versión pequeña, pero operativa, del proceso. Se parte de dos ficheros CSV. tickets.csv contiene ticket_id, cliente_id, fecha_apertura y fecha_cierre. clientes.csv contiene cliente_id y segmento.

Suponemos que los instantes de los CSV están representados en formato ISO 8601 con zona horaria explícita, por ejemplo 2026-09-28T09:30:00+02:00. La fotografía se obtiene para el instante 2026-10-01T00:00:00Z, equivalente a un corte definido en UTC. Para otro negocio o periodo habría que acordar primero el instante correcto de corte.

Este ejemplo usa pandas, una biblioteca de Python. Su intención es ilustrar controles básicos; no sustituye pruebas adicionales, gestión de versiones o revisión de reglas específicas del negocio.

import pandas as pd

CORTE = pd.Timestamp("2026-10-01T00:00:00Z")

tickets = pd.read_csv(
    "tickets.csv",
    dtype={"ticket_id": "string", "cliente_id": "string"}
)
clientes = pd.read_csv(
    "clientes.csv",
    dtype={"cliente_id": "string", "segmento": "string"}
)

# Las claves identifican: no deben convertirse en números.
for df, clave in ((tickets, "ticket_id"),
                  (tickets, "cliente_id"),
                  (clientes, "cliente_id")):
    if df[clave].isna().any() or df[clave].eq("").any():
        raise ValueError(f"Clave vacía: {clave}")

if tickets["ticket_id"].duplicated().any():
    raise ValueError("Hay incidencias duplicadas")
if clientes["cliente_id"].duplicated().any():
    raise ValueError("El maestro de clientes no es único")
if clientes["segmento"].isna().any():
    raise ValueError("Hay segmentos de cliente sin informar")

for columna in ("fecha_apertura", "fecha_cierre"):
    original = tickets[columna]
    tickets[columna] = pd.to_datetime(
        original, utc=True, errors="coerce"
    )
    if columna == "fecha_apertura":
        invalidas = tickets[columna].isna()
    else:
        invalidas = original.notna() & tickets[columna].isna()
    if invalidas.any():
        raise ValueError(f"Fechas inválidas: {columna}")

if (tickets["fecha_cierre"].notna() &
    (tickets["fecha_cierre"] < tickets["fecha_apertura"])).any():
    raise ValueError("Se ha detectado un cierre anterior a apertura")

# Fotografiar solo las incidencias abiertas antes del corte.
tickets = tickets.loc[
    tickets["fecha_apertura"] < CORTE
].copy()

n_origen = len(tickets)
resultado = tickets.merge(
    clientes, on="cliente_id", how="left",
    validate="many_to_one", indicator=True
)

if (resultado["_merge"] != "both").any():
    raise ValueError("Existen incidencias sin cliente asociado")
if len(resultado) != n_origen:
    raise ValueError("La unión ha cambiado el número de filas")

cerrada_al_corte = (
    resultado["fecha_cierre"].notna()
    & (resultado["fecha_cierre"] < CORTE)
)
resultado["estado_al_corte"] = "abierta"
resultado.loc[cerrada_al_corte, "estado_al_corte"] = "cerrada"

resultado["duracion_horas"] = (
    (resultado["fecha_cierre"].where(cerrada_al_corte)
     - resultado["fecha_apertura"])
    .dt.total_seconds() / 3600
).round(2)

# Entregamos solo variables válidas para la fotografía.
columnas = [
    "ticket_id", "cliente_id", "segmento",
    "fecha_apertura", "estado_al_corte", "duracion_horas"
]
dataset = resultado[columnas].sort_values("ticket_id")
assert dataset["ticket_id"].is_unique
assert len(dataset) == n_origen

dataset.to_csv("dataset_incidencias_corte_20261001.csv", index=False)

El código ejecuta cinco decisiones importantes. Primero, conserva los identificadores como texto. Segundo, impide continuar cuando las claves no cumplen la regla de identidad. Tercero, interpreta los instantes en UTC. Cuarto, exige una unión de muchas incidencias a un único cliente. Quinto, calcula la situación conocida en el corte, sin revelar cierres posteriores.

Matiz importante: este ejemplo no valida que todas las columnas de entrada existan, no comprueba expresamente las zonas horarias incluidas en el texto y no reconstruye históricos de segmento de cliente. En producción, debe añadirse una validación previa del esquema, rechazar marcas temporales sin zona inequívoca y usar una tabla histórica de clientes cuando el análisis requiera el segmento vigente en cada fecha.

Asimismo, una incidencia reabierta necesitaría un historial de eventos para calcular correctamente su estado en cada instante; dos fechas de apertura y cierre no representan todos los ciclos posibles. Un ejemplo sencillo solo es fiable dentro de las hipótesis que declara.

Dos pruebas manuales que conviene realizar

Crea registros de prueba controlados y comprueba que una incidencia cerrada después del corte aparece como abierta y sin duración definitiva. Después introduce intencionadamente un identificador duplicado en el maestro de clientes y verifica que el programa detiene la ejecución. Estas pruebas comprueban el comportamiento del procedimiento, no únicamente la apariencia de su resultado.

Si el conjunto debe actualizarse cada semana, las mismas pruebas pueden ejecutarse de forma automática con cada nueva extracción. Un proceso que detecta un error y no publica el fichero defectuoso es más seguro que otro que siempre produce una salida.

10. Publicar una versión que pueda reconstruirse y auditarse

Un dataset no está terminado cuando se guarda el fichero. Está terminado cuando otra persona puede identificar qué versión se utilizó, cómo se obtuvo y qué limitaciones debe respetar. Esto es especialmente relevante si varios informes consumen la misma información durante meses.

Definir una entrega mínima

Una entrega profesional puede organizarse con cuatro elementos:

• Archivo de datos: CSV, Parquet o tabla controlada, con nombre y versión inequívocos.
• Contrato y diccionario: granularidad, campos, tipos, unidades, población, exclusiones y fecha de corte.
• Manifiesto de procedencia: sistemas consultados, parámetros, fechas de extracción, versión del procedimiento y controles de integridad.
• Informe de validación: pruebas realizadas, resultados, incidencias conocidas y decisiones de aceptación.

El formato depende del uso. CSV favorece el intercambio sencillo, pero no conserva por sí solo todos los tipos de datos ni la semántica de las columnas; Parquet suele resultar conveniente para datos tabulares de mayor volumen o procesos analíticos. La elección debe acompañarse de un esquema documentado. Un fichero de Excel puede ser suficiente para determinados trabajos pequeños si se preservan las mismas garantías.

Gestionar versiones de contenido, no solo nombres de archivo

Es recomendable separar la versión del esquema —qué campos existen y cómo se interpretan— de la versión de datos —qué observaciones incluye una extracción concreta—. Corregir el significado de duracion_horas puede exigir una nueva versión del esquema; incorporar las incidencias del mes siguiente produce otra versión del contenido.

Para informes que deban reproducirse, no conviene sustituir silenciosamente un fichero ya publicado. Una corrección debe generar una nueva versión identificable, junto con el motivo del cambio. El informe anterior puede seguir asociado a la versión original, evitando que cambien resultados históricos sin explicación.

Crear un pequeño historial de decisiones

Un registro de cambios debe anotar, por ejemplo: «Versión 1.1: se corrigió la interpretación de cierres posteriores a la fecha de corte; afecta a 18 incidencias». Esa anotación es mucho más informativa que un archivo llamado dataset_final_definitivo_3.csv.

Si el dataset pasa a ser consumido por varios departamentos, su documentación puede integrarse en los mecanismos de documentación de datos de la empresa, con responsables, definiciones y normas comunes.

11. Construir un conjunto útil sin exponer información innecesaria

La fiabilidad no se limita a cálculos correctos. También importa que el dato se obtenga y utilice con controles adecuados. Un dataset para estudiar tiempos de resolución probablemente no necesita nombres completos, correos electrónicos, teléfonos ni textos libres de las comunicaciones con los clientes.

Conviene aplicar minimización desde el diseño: incluir solo las columnas necesarias para la pregunta, restringir accesos y definir dónde se guardan los originales y las versiones de trabajo. Eliminar nombres no garantiza anonimato si los identificadores y las combinaciones de variables siguen permitiendo reconocer a una persona.

Algunas medidas prácticas son:

• Evitar exportar datos personales que no sean necesarios para el análisis.
• Usar identificadores sustitutos cuando permitan responder a la pregunta, manteniendo su correspondencia separada y protegida si hace falta.
• Limitar la lectura y modificación según las funciones de cada usuario.
• Proteger las copias y los intercambios de ficheros con mecanismos adecuados.
• Establecer plazos de conservación y procedimientos para borrar copias temporales.
• Comprobar permisos antes de compartir el fichero por correo o subirlo a una herramienta externa.

La seudonimización reduce exposición, pero no elimina automáticamente la condición de dato personal. Si se tratan datos de personas, las decisiones de acceso, finalidad y conservación deben encajar en las obligaciones aplicables a la organización.

Para los aspectos operativos del intercambio entre aplicaciones, puede consultarse cómo compartir datos entre aplicaciones de forma segura. En el dataset, la medida más eficaz suele empezar antes: no incorporar lo que no es necesario.

12. Caso práctico completo: de tres fuentes a una tabla analítica confiable

Supongamos que una microempresa de servicios técnicos desea analizar la carga de trabajo de su área de soporte. Tiene una exportación de incidencias, un registro de intervenciones y un maestro de clientes. Quiere conocer el número de incidencias abiertas y la distribución de tiempos de resolución por segmento, a fecha de corte.

Paso 1. Distinguir las unidades de observación

La exportación de incidencias contiene una fila por expediente; el registro de intervenciones contiene una fila por actividad realizada. Una incidencia puede tener varias actividades. Si se unen ambas tablas directamente, aparecen varias filas por incidencia y queda alterado el número de expedientes.

La solución es mantener el dataset principal con una fila por incidencia y, si resulta necesaria una variable como número de intervenciones, calcularla previamente mediante una agregación por ticket_id. Solo después se une ese resumen, que sí tiene una fila por incidencia.

Paso 2. Resolver la relación con clientes

El maestro contiene dos registros con el mismo código de cliente, uno antiguo y otro actualizado. En lugar de escoger la primera coincidencia, se solicita una regla clara: cuál es el registro vigente y qué fecha determina su validez. La resolución queda incorporada al procedimiento para no depender de una corrección manual en cada ejecución.

Paso 3. Aplicar el corte temporal

Una incidencia abierta el último día del periodo, pero cerrada dos días más tarde, debe contarse entre las incidencias abiertas a la fecha de referencia. El tiempo definitivo de resolución no es todavía una variable disponible en aquella fotografía. Se mantiene la observación y se evita asignarle una duración futura.

Paso 4. Conciliar el resultado

Consideremos cifras ficticias para ilustrar la conciliación. La extracción inicial contiene 1.260 filas. De ellas, 20 son registros identificados como pruebas mediante una marca de origen y se excluyen según una regla documentada. Quedan 1.240 incidencias de la población. La incorporación de atributos de cliente y de recuentos de intervenciones debe seguir dejando exactamente 1.240 filas, con 1.240 identificadores únicos.

Si aparecen 1.255 filas, existe una multiplicación que hay que investigar. Si aparecen 1.217, han desaparecido observaciones y es necesario localizar sus identificadores. Si el resultado mantiene 1.240 filas, todavía deben comprobarse las claves y los atributos: el conteo por sí solo no garantiza la corrección.

Paso 5. Entregar datos y límites de interpretación

La microempresa entrega un fichero de incidencias, un diccionario de campos, un manifiesto del corte y un informe de pruebas. También declara dos limitaciones: los cierres reabiertos no pueden reconstruirse si no existe historial de eventos, y el segmento de cliente es el vigente en la extracción salvo que se use un maestro histórico.

El resultado es valioso precisamente porque no oculta esas limitaciones. Un analista puede calcular indicadores apropiados y detectar cuáles requieren información adicional, sin confundir la ausencia de un dato con una conclusión.

13. Errores frecuentes que hacen poco fiable un dataset aparentemente correcto

Muchas incidencias de calidad aparecen después de empezar a utilizar la tabla, cuando ya se han producido informes o decisiones. Una revisión preventiva debería buscar, especialmente, estos errores:

1. No definir una fila: mezclar clientes, pedidos, líneas y eventos en una misma tabla sin decidir la unidad de análisis.
2. Unir sin comprobar cardinalidad: multiplicar importes o incidencias por varias coincidencias en una tabla auxiliar.
3. Eliminar nulos automáticamente: convertir «aún no ha ocurrido» en «registro inexistente» y sesgar el resultado.
4. Corregir datos a mano: generar una versión imposible de reconstruir a partir del origen.
5. Confundir identificadores con cantidades: eliminar ceros iniciales o modificar códigos al importarlos.
6. Ignorar periodos y zonas horarias: atribuir registros al día o mes equivocado.
7. Utilizar datos posteriores al corte: introducir información del futuro en un análisis histórico o predictivo.
8. Admitir cualquier fichero de entrada: no detectar cambios de nombres, tipos o significados de columnas.
9. Dar por válidos los totales sin conciliarlos: no comprobar bajas, incorporaciones o duplicaciones durante el proceso.
10. Sobrescribir la versión utilizada en un informe: impedir que se reproduzcan cifras que antes se consideraban correctas.

No todos requieren herramientas complejas. Una consulta de unicidad, un recuento antes y después de una unión, una lista de exclusiones y un manifiesto de ejecución pueden prevenir una gran parte de estos problemas.

La mejora no consiste en añadir cientos de controles de golpe, sino en seleccionar los que protegen los supuestos críticos del análisis. Los controles deben seguir el riesgo real: una clave que determina importes merece prioridad sobre una columna descriptiva que apenas se utiliza.

14. Lista de comprobación antes de declarar fiable un conjunto de datos

Antes de utilizar una versión en un informe, modelo o cuadro de mando, conviene poder responder afirmativamente a las siguientes preguntas:

1. ¿Está definida la pregunta de negocio o investigación que el dataset debe permitir responder?
2. ¿Sabemos qué representa cada fila y qué clave la identifica?
3. ¿Están declaradas la población, las exclusiones y el instante de corte?
4. ¿Se han identificado los orígenes autorizados para cada dato relevante?
5. ¿Conservamos los originales y el registro de cómo se extrajeron?
6. ¿Se han normalizado formatos sin perder identificadores ni interpretaciones importantes?
7. ¿Se ha comprobado que las uniones no duplican ni eliminan observaciones indebidamente?
8. ¿Los nulos, los cierres pendientes y las excepciones tienen un tratamiento acordado?
9. ¿Se evitan cambios posteriores al corte y variables que revelen información futura?
10. ¿Han superado las pruebas críticas de unicidad, integridad, esquema y coherencia?
11. ¿La salida puede reconstruirse y está vinculada a una versión concreta?
12. ¿La información incluida y los permisos son proporcionales a la finalidad del análisis?
13. ¿Se han documentado las limitaciones que pueden modificar la interpretación de los resultados?

Un «no» no siempre significa que el proyecto deba abandonarse. Puede indicar que el análisis debe acotarse, que falta una fuente o que la entrega necesita una advertencia. La decisión debe quedar explícita. La verdadera fiabilidad no exige afirmar que los datos son perfectos, sino demostrar que son adecuados para el uso declarado y que se conocen sus incertidumbres.

Conclusión: la fiabilidad se diseña antes de calcular indicadores

Un conjunto de datos fiable no se obtiene simplemente al combinar archivos y eliminar errores visibles. Se construye mediante decisiones coherentes: definir qué se quiere estudiar, fijar la unidad de observación, seleccionar fuentes autorizadas, preservar los originales, integrar registros con controles, respetar el tiempo y validar el resultado antes de publicarlo.

El criterio decisivo es la capacidad de explicar y repetir el proceso. Si otro profesional puede reconstruir la misma versión, comprender el significado de sus campos, comprobar sus principales restricciones y reconocer sus límites, el dataset ya ofrece una base mucho más sólida para los análisis posteriores.

Para una microempresa, este enfoque puede empezar con dos CSV, algunas consultas y una lista de pruebas. Para un entorno más grande, los mismos principios se implementan con sistemas de integración, validaciones automatizadas y repositorios versionados. Cambia la escala, pero no la necesidad de mantener reglas claras y resultados comprobables.

Preguntas frecuentes sobre la construcción de datasets fiables