Cómo detectar errores y anomalías en conjuntos de datos

Introducción: por qué conviene investigar los datos antes de analizarlos

Un conjunto de datos puede abrirse sin problemas, contener miles de filas y producir gráficos aparentemente convincentes. Sin embargo, entre sus columnas pueden esconderse errores de captura, anomalías estadísticas, duplicados, incoherencias entre variables y problemas de trazabilidad que cambian las conclusiones de un análisis.

Imagina una tabla de pedidos en la que una operación aparece dos veces, otra registra una entrega anterior a la compra y una tercera presenta un importe cien veces superior al habitual. Las tres merecen atención, pero no necesariamente la misma respuesta: el duplicado podría ser un defecto de integración; la fecha imposible puede indicar un error de conversión; y el pedido extraordinario podría ser perfectamente legítimo.

Detectar una anomalía no equivale a demostrar que un dato es incorrecto. La tarea consiste en encontrar señales, contrastarlas con las reglas del conjunto de datos y decidir qué hacer sin eliminar información válida. Esta guía aborda ese proceso desde la perspectiva de la Ciencia de Datos: controles estructurales, reglas de coherencia, métodos estadísticos, revisión de series temporales y un ejemplo reproducible con Python.

Índice de contenidos

1. Diferenciar errores, anomalías y cambios legítimos
2. Reconocer los principales tipos de anomalías
3. Entender el conjunto de datos antes de aplicar pruebas
4. Detectar errores mediante reglas verificables
5. Localizar valores atípicos con métodos estadísticos
6. Investigar anomalías entre varias variables
7. Examinar anomalías temporales y de secuencia
8. Detectar cambios de distribución y problemas de muestreo
9. Ejemplo práctico reproducible con Python
10. Investigar y clasificar cada hallazgo
11. Priorizar la revisión según el impacto
12. Prevenir recurrencias sin perder trazabilidad
13. Errores habituales al buscar anomalías
14. Preguntas frecuentes
15. Conclusión

Antes de empezar: error confirmado, dato sospechoso y observación excepcional

En un proyecto de análisis, una regla incumplida, un valor raro y un cambio de comportamiento no significan lo mismo. Separarlos evita tanto la limpieza agresiva como la aceptación indiscriminada de información defectuosa.

Error confirmado

Existe una evidencia suficiente de que el registro contradice una definición o un hecho comprobable. Por ejemplo, dos filas tienen el mismo identificador cuando ese campo debe ser único; una fecha de finalización precede al inicio de un proceso en el que eso es imposible; o un campo categórico contiene un código no contemplado por su catálogo oficial.

Incluso aquí hay que verificar la definición. Un identificador de pedido puede repetirse de forma correcta en una tabla de líneas de pedido, aunque no debería hacerlo en una tabla con una fila por pedido.

Dato sospechoso

Una observación incumple una expectativa, pero todavía no hay prueba de que sea errónea. Una factura con un importe elevado, una medición que se aparta mucho de la mediana o un registro que rompe la relación habitual entre dos variables deben marcarse para investigar, no corregirse automáticamente.

Observación excepcional válida

El dato es real aunque poco frecuente: una compra mayorista, una caída de servicio, un proyecto de duración inusual o un aumento estacional de actividad. Eliminarlo podría ocultar justo el fenómeno que interesa estudiar.

Conviene mantener, como mínimo, cuatro estados: pendiente de revisión, error confirmado, valor válido y no concluyente. Esta clasificación separa la detección de la decisión y deja constancia de la incertidumbre.

La diferencia también delimita este artículo: aquí se examina la calidad y la coherencia de las observaciones del dataset. Para interpretar variaciones en ventas, costes o actividad de una empresa, el enfoque complementario se desarrolla en cómo detectar anomalías empresariales con datos sencillos.

Qué tipos de anomalías pueden aparecer en un conjunto de datos

Una buena estrategia de detección no utiliza un único algoritmo para todos los problemas. Empieza identificando la naturaleza del dato y el tipo de fallo que podría producirse.

Anomalías estructurales

Afectan a la forma del conjunto: columnas ausentes, encabezados alterados, tipos inesperados, registros truncados, codificaciones incompatibles o cambios imprevistos en el número de columnas. Un archivo CSV puede importarse correctamente y, aun así, interpretar un separador decimal como delimitador de campo.

Anomalías de dominio y coherencia

Son valores que contradicen restricciones conocidas. Ejemplos: unidades negativas en una tabla exclusiva de ventas, porcentajes fuera de un intervalo declarado, estados inexistentes, referencias a clientes que no aparecen en la tabla correspondiente o un total que no coincide con sus componentes.

Anomalías estadísticas o puntuales

Una observación se separa del comportamiento predominante de una variable. Puede ser una medición extrema, una transacción inusualmente grande o un tiempo de ejecución mucho mayor que los demás. Se detecta comparándola con una distribución de referencia, pero esa distancia por sí sola no demuestra error.

Anomalías contextuales

El valor parece normal globalmente, pero resulta extraño dentro de un grupo o circunstancia. Un plazo de 24 horas puede ser normal para un servicio y anómalo para otro; una temperatura puede ser habitual en verano y sospechosa en invierno. El contexto puede venir dado por categoría, canal, ubicación, día de la semana o versión del sistema.

Anomalías colectivas y de secuencia

El problema no reside en un registro aislado, sino en un conjunto de registros que, tomados juntos, forman un patrón inusual: cientos de eventos idénticos en segundos, un tramo de valores constantes en un sensor o una sucesión de estados que no respeta el proceso esperado.

Una inspección completa contempla varias de estas categorías. Aplicar únicamente un filtro de «valores demasiado grandes» dejaría intactas muchas inconsistencias relevantes.

Preparar el contexto: la unidad de observación y las reglas del dato

La misma cifra puede ser correcta o incorrecta según lo que represente. Antes de buscar anomalías hay que responder algunas preguntas esenciales: ¿qué significa cada fila?, ¿de dónde procede?, ¿qué unidades utilizan los campos?, ¿qué registros deberían existir y con qué frecuencia se actualizan?

Definir la unidad de observación

Una fila puede representar una persona, un cliente, un pedido, una línea de factura, una visita web o una medición horaria. Esta definición determina qué duplicados son reales, qué comparaciones tienen sentido y qué variables deberían compartir una relación.

Establecer un contrato mínimo de datos

Para cada campo crítico conviene disponer de nombre, significado, tipo, unidad, dominio permitido, política de ausencias y fuente de referencia. No es necesario producir una documentación monumental: basta con especificaciones comprobables que permitan explicar cada alerta.

• Identidad: claves únicas o combinación de campos que identifica una observación.
• Formato: texto, entero, decimal, fecha, booleano o categoría.
• Semántica: diferencia entre importe neto y bruto, fecha del evento y fecha de carga, unidades y devoluciones.
• Integridad: campos obligatorios, relaciones entre tablas y reglas de negocio.
• Procedencia: sistema de origen, instante de extracción y versión del proceso de transformación.

Es especialmente importante conservar los identificadores como texto si pueden incluir ceros iniciales. El valor 000173 puede dejar de ser una referencia válida si se convierte sin criterio en el número 173. También hay que definir la zona horaria de las fechas y si las cantidades monetarias incluyen impuestos o descuentos.

Cuando todavía no se conocen estas condiciones, la mejor decisión no es «limpiar por intuición», sino registrar las hipótesis y contrastarlas con la persona responsable del dato. La documentación del proceso global se desarrolla en cómo documentar completamente un proyecto de Ciencia de Datos.

Cómo detectar errores con validaciones que producen resultados explicables

La primera capa de control debería basarse en reglas deterministas: condiciones cuyo incumplimiento puede describirse y reproducirse. Suelen detectar defectos más directamente corregibles que un algoritmo estadístico avanzado.

1. Comprobar esquema y tipos

Verifica que aparecen las columnas previstas, que sus tipos son compatibles y que las conversiones no generan silenciosamente valores vacíos. Una fecha mal formada debe identificarse como fallo de conversión, no desaparecer en una columna de nulos sin explicación.

Al importar, distingue entre el valor original y el convertido. La secuencia «entrada original → interpretación → validación» permite localizar si el defecto venía del sistema de origen o se introdujo durante el procesamiento.

2. Revisar rangos y dominios permitidos

Comprueba límites respaldados por la definición del campo. Por ejemplo, una proporción expresada entre cero y uno debe respetar ese intervalo; un código de estado debe pertenecer al catálogo vigente. Un precio igual a cero, en cambio, no debería declararse erróneo sin saber si existen promociones o muestras gratuitas.

3. Comprobar unicidad y relaciones

Busca identificadores repetidos cuando la unidad de observación exige unicidad y verifica las referencias entre tablas. Para detectar duplicados funcionales quizá haga falta una clave compuesta, como identificador de pedido más número de línea.

La coincidencia exacta de dos filas no basta siempre para borrar una de ellas: podrían representar dos eventos legítimos capturados con los mismos atributos visibles. La decisión depende del modelo de datos.

4. Contrastar reglas entre columnas

Las reglas cruzadas son especialmente útiles porque detectan contradicciones que pasan inadvertidas al examinar cada columna por separado:

• La fecha de entrega no debería ser anterior a la fecha del pedido cuando ambas representan esos hitos del mismo proceso.
• En una línea de venta sin descuentos ni impuestos, el importe esperado debería ser unidades × precio unitario, dentro de una tolerancia de redondeo definida.
• Un registro marcado como «entregado» debería tener fecha de entrega si ese dato es obligatorio según el proceso.
• El identificador de una categoría debería existir en la tabla de categorías asociada a la extracción.

5. Analizar ausencias con significado

Un campo vacío no representa siempre un fallo. La fecha de entrega de un pedido pendiente puede faltar correctamente; la misma ausencia en un pedido confirmado como entregado puede necesitar investigación. También hay diferencias entre «no aplicable», «desconocido», «no informado» y «fallo de extracción».

En lugar de sustituir todos los vacíos por cero, conserva el motivo de la ausencia cuando pueda conocerse y evalúa si se concentra en ciertos periodos, canales o versiones de la aplicación. El análisis completo del tratamiento de nulos merece una decisión propia, distinta de la mera detección de anomalías.

Estas comprobaciones generales se relacionan con la detección de errores frecuentes en datos empresariales, pero aquí sirven como primera etapa de un procedimiento específico de preparación de conjuntos destinados al análisis estadístico.

Cómo localizar valores atípicos sin eliminar casos legítimos

Un valor atípico, también llamado outlier, es una observación que se aleja del comportamiento habitual conforme a un criterio definido. Detectarlo requiere elegir una referencia apropiada; interpretarlo requiere contexto.

Inspección visual y estadística descriptiva

Antes de aplicar umbrales, examina mínimo, máximo, cuantiles, mediana, dispersión y frecuencia de valores. Los diagramas de caja permiten visualizar extremos; los histogramas muestran asimetrías y agrupaciones; y un gráfico de dispersión puede descubrir relaciones ocultas entre variables.

Es frecuente que una variable tenga una distribución muy asimétrica: muchas operaciones pequeñas y unas pocas muy grandes. En ese caso, un umbral único puede señalar como sospechosas numerosas transacciones reales.

Rango intercuartílico (IQR)

El rango intercuartílico se calcula como IQR = Q3 − Q1, donde Q1 y Q3 son los percentiles 25 y 75. Una regla exploratoria habitual señala valores inferiores a Q1 − 1,5 × IQR o superiores a Q3 + 1,5 × IQR.

Este método no presupone una distribución normal, pero tampoco es universal. Con muestras pequeñas, distribuciones asimétricas o subpoblaciones mezcladas puede generar alertas poco útiles. Los límites son criterios de cribado, no fronteras entre verdad y error.

Puntuación z y mediana con desviación absoluta mediana

La puntuación z mide cuántas desviaciones típicas separan un valor de la media. Es interpretable cuando la media y la desviación representan razonablemente la distribución, pero los extremos pueden distorsionar ambos parámetros.

Una alternativa robusta utiliza la mediana y la desviación absoluta mediana (MAD): MAD = mediana(|x − mediana(x)|). Una puntuación modificada habitual es 0,6745 × (x − mediana(x)) / MAD. Puede ayudar cuando existen valores extremos, pero exige tratar explícitamente el caso MAD = 0, habitual en variables con muchos valores idénticos. Ni una puntuación elevada ni un umbral convencional constituyen una prueba automática de error.

Comparar dentro de grupos homogéneos

Calcular un único IQR para todos los pedidos puede mezclar compras minoristas y mayoristas. En ocasiones es preferible obtener referencias por categoría de producto, canal, región o tipo de cliente, siempre que cada grupo tenga suficientes observaciones para justificar la comparación.

También hay que vigilar grupos con muy pocos registros: su dispersión puede resultar inestable. Si los datos son escasos, una revisión manual fundamentada puede ser más fiable que un umbral que aparenta precisión estadística.

Anomalías multivariantes: cuando el problema está en la combinación

Algunos registros no destacan por ninguna columna aislada. Lo que resulta extraño es la relación entre varias características.

Piensa en una base de operaciones con distancia recorrida y duración. Una distancia de 100 kilómetros puede ser normal; una duración de diez minutos también podría aparecer en ciertas operaciones; pero ambas cifras juntas podrían implicar una velocidad imposible para el contexto estudiado.

Empezar por relaciones que pueden explicarse

Antes de utilizar modelos complejos, calcula variables derivadas con significado: importe por unidad, tiempo entre eventos, ratio de consumo por equipo o porcentaje de desviación frente a una referencia. Comprueba después las combinaciones con gráficos de dispersión y reglas de plausibilidad.

Las restricciones físicas, contables y operativas conocidas suelen ser más fiables para confirmar errores que cualquier algoritmo genérico.

Cuándo recurrir a modelos de detección de anomalías

Cuando existen muchas variables y relaciones no lineales, pueden explorarse métodos como Isolation Forest, Local Outlier Factor o técnicas de agrupamiento. Estos procedimientos asignan una puntuación de rareza según la estructura observada; no determinan por sí mismos si un registro está mal.

• Isolation Forest: puede servir para identificar observaciones inusuales en espacios con varias características, pero depende de las variables y de la configuración utilizada.
• Local Outlier Factor: compara la densidad local de los puntos y puede ser útil cuando existen regiones con distintas densidades.
• Modelos de reconstrucción: en escenarios más complejos, un error de reconstrucción elevado puede señalar diferencias respecto al patrón aprendido, sin demostrar que sean errores.

Antes de entrenar estos métodos hay que tratar escalas, valores ausentes, categorías y posibles fugas de información. Además, se necesita un procedimiento para verificar alertas y estimar cuántas son falsas alarmas. Aplicar una técnica sofisticada sin conocer el proceso generador de datos puede aumentar el ruido en lugar de reducirlo.

Cómo detectar anomalías en fechas, secuencias y series temporales

Los datos con dimensión temporal requieren controles adicionales. Una serie puede tener valores aparentemente razonables y estar mal construida por eventos duplicados, zonas horarias inconsistentes o intervalos ausentes.

Controlar la coherencia temporal básica

• Comprobar si las marcas de tiempo tienen la zona horaria esperada.
• Verificar el orden permitido entre creación, aprobación, ejecución y cierre.
• Distinguir fecha del evento, fecha de recepción y fecha de carga.
• Detectar intervalos faltantes solo cuando se espera una cadencia fija.
• Examinar registros que llegan tarde antes de atribuir un cero a falta de actividad.

Comparar con una referencia que respete la estacionalidad

Una subida de actividad un lunes puede ser normal aunque supere la media de toda la semana. Para datos diarios puede ser más útil compararla con lunes anteriores que con todos los días indistintamente. Lo mismo ocurre con horarios laborales, vacaciones o campañas.

Las medias móviles, medianas móviles y bandas construidas a partir de residuos pueden servir como métodos exploratorios. La ventana debe corresponder al ritmo del proceso; de lo contrario, los cambios legítimos de tendencia se marcarán como anomalías.

Detectar cambios persistentes

Un pico aislado y un desplazamiento sostenido del nivel de una serie son fenómenos diferentes. Un cambio de versión del software, un instrumento recalibrado o una modificación en el método de captura puede alterar todas las observaciones posteriores. En estos casos conviene investigar el punto de cambio y no limitarse a etiquetar cada nuevo registro como atípico.

Si los valores se han agregado por día o mes, comprueba también el denominador y la cobertura. Un descenso de registros puede significar una caída real del fenómeno, pero también una extracción incompleta.

Detectar cambios de distribución, sesgos y problemas de cobertura

Un conjunto puede superar todas las reglas fila por fila y seguir siendo inadecuado para el análisis. Quizá falte una región completa, las observaciones procedan de otro periodo o haya cambiado el criterio con el que se seleccionan los registros.

Comparar poblaciones equivalentes

Observa si cambian las proporciones por categoría, la dispersión, los cuantiles, la tasa de ausencias o la frecuencia de valores. Antes de interpretar la diferencia, verifica que ambos conjuntos cubren periodos, unidades y poblaciones comparables.

Por ejemplo, que el importe mediano aumente no implica necesariamente un error: puede haber aumentado la proporción de clientes empresariales. La distribución global ha cambiado, pero la explicación puede estar en la composición de la muestra.

Vigilar las transformaciones que crean anomalías

Los problemas pueden introducirse en uniones, agregaciones o conversiones, no solo en la captura. Una combinación de tablas con una relación de varios a varios no prevista puede multiplicar filas e inflar importes. Una conversión de unidades puede transformar gramos en kilogramos incorrectamente. Un filtro mal aplicado puede excluir todos los casos negativos.

Por eso es útil comprobar el número de filas, el número de claves distintas y los totales antes y después de cada transformación importante. Las diferencias deben explicarse por una regla documentada, no por la confianza en que «el proceso se ejecutó sin errores».

Separar anomalías de fugas de información

En proyectos de modelos predictivos, una columna puede parecer extraordinariamente eficaz porque incluye información que solo estaría disponible después del evento que se quiere predecir. No se trata de un valor atípico, sino de una fuga de información que invalida la evaluación. El control correcto consiste en verificar la disponibilidad temporal y el significado de las variables.

La combinación de estas comprobaciones ayuda a construir conjuntos verdaderamente utilizables. Para un enfoque más amplio sobre la fiabilidad antes de ejecutar procesos, puede consultarse cómo mejorar la calidad de los datos antes de automatizar procesos.

Ejemplo práctico: detectar registros sospechosos en un conjunto de pedidos con Python

Supongamos que recibimos una extracción de pedidos con una fila por pedido, importes sin descuentos ni impuestos y un catálogo en el que las unidades de venta deben ser positivas. El objetivo es localizar problemas demostrables y, por separado, cantidades atípicas que necesiten contexto comercial.

El ejemplo siguiente es autocontenido: crea datos ficticios en memoria y utiliza pandas. Puede ejecutarse en un entorno de Python que tenga instalada esa biblioteca. No requiere acceso a información privada ni modifica archivos.

1. Crear los datos de prueba

import pandas as pd

registros = [
    # id, pedido, entrega, unidades, precio, total, estado
    ("P001", "2026-10-01", "2026-10-03", 2, 20.0, 40.0, "entregado"),
    ("P002", "2026-10-01", "2026-10-02", 1, 15.5, 15.5, "entregado"),
    ("P003", "2026-10-02", "2026-10-04", 3, 10.0, 30.0, "entregado"),
    ("P003", "2026-10-02", "2026-10-04", 3, 10.0, 30.0, "entregado"),
    ("P004", "2026-10-03", "2026-10-02", 1, 25.0, 25.0, "entregado"),
    ("P005", "2026-10-03", "2026-10-05", -2, 9.0, -18.0, "entregado"),
    ("P006", "2026-10-04", "2026-10-05", 10, 8.0, 80.0, "entregado"),
    ("P007", "2026-10-04", "2026-10-07", 1, 12.0, 15.0, "entregado"),
    ("P008", "2026-10-04", None, 1, 12.0, 12.0, "entregado"),
    ("P009", "2026-10-05", None, 2, 18.0, 36.0, "pendiente"),
    ("P010", "2026-10-05", "2026-10-07", 2, 22.0, 44.0, "entregado"),
    ("P011", "2026-10-06", "2026-10-08", 1000, 8.0, 8000.0, "entregado"),
]

columnas = ["pedido_id", "fecha_pedido", "fecha_entrega",
            "unidades", "precio_unitario", "total", "estado"]
df = pd.DataFrame(registros, columns=columnas)

for campo in ["fecha_pedido", "fecha_entrega"]:
    df[campo] = pd.to_datetime(df[campo], errors="coerce")

El mismo identificador P003 aparece dos veces. P004 tiene fechas incoherentes; P005, unidades negativas; P007, un total que no coincide con unidades por precio; y P008 consta como entregado sin fecha de entrega. El pedido P011 registra mil unidades: es inusual, pero todavía no sabemos si es erróneo.

2. Aplicar reglas deterministas y un indicador estadístico

alertas = pd.DataFrame(index=df.index)

alertas["id_repetido"] = df["pedido_id"].duplicated(keep=False)
alertas["unidades_invalidas"] = df["unidades"] <= 0
alertas["fecha_invertida"] = (
    df["fecha_entrega"] < df["fecha_pedido"]
)
alertas["entrega_sin_fecha"] = (
    df["estado"].eq("entregado") & df["fecha_entrega"].isna()
)

importe_esperado = df["unidades"] * df["precio_unitario"]
alertas["total_incoherente"] = (
    (importe_esperado - df["total"]).abs() > 0.01
)

# Detección exploratoria de cantidades atípicas mediante IQR.
q1 = df["unidades"].quantile(0.25)
q3 = df["unidades"].quantile(0.75)
iqr = q3 - q1
limite_inferior = q1 - 1.5 * iqr
limite_superior = q3 + 1.5 * iqr

alertas["cantidad_atipica"] = (
    (df["unidades"] < limite_inferior) |
    (df["unidades"] > limite_superior)
)

resultado = pd.concat([df[["pedido_id", "unidades"]], alertas], axis=1)
resultado = resultado.loc[alertas.any(axis=1)]
print(resultado.to_string(index=False))

Las comparaciones de fecha se hacen una vez convertidas las columnas. La condición sobre el total utiliza una tolerancia didáctica de 0,01, que debe adaptarse a la política monetaria y de redondeo del caso real. Para cálculos contables exactos conviene utilizar tipos decimales y reglas de redondeo explícitas, no confiar de forma indiscriminada en números de coma flotante.

3. Interpretar las alertas sin confundirlas con sentencias

• P003: revisar si las dos filas son una duplicación accidental de la misma operación. En este ejemplo, la especificación exige identificadores únicos.
• P004: comprobar si se han invertido fechas, si hay una transformación incorrecta o si los campos representan hitos distintos de los documentados.
• P005: verificar si es una devolución mal clasificada o una venta con error; la regla de positividad se definió para operaciones de venta, no para abonos.
• P007: contrastar el importe con los datos originales y la definición contable, incluida la posibilidad de conceptos que el ejemplo deliberadamente excluye.
• P008: investigar la falta de fecha porque el estado «entregado» la exige; el pedido pendiente P009 no necesita ese dato todavía.
• P006 y P011: podrían quedar marcados como cantidades atípicas. Sin contexto, no debe concluirse que 10 o 1000 unidades estén mal: una compra especial podría explicarlas.

Se han incluido pocas observaciones para hacer el ejercicio legible. Los límites IQR calculados sobre esta muestra pequeña no deben adoptarse como umbrales de producción. En un proyecto real habría que contrastar muestras mayores, estacionalidad, segmentos y casos revisados por personas conocedoras del proceso.

4. Llevar el patrón a una extracción real

Si el origen es un CSV, conviene importar primero los identificadores como texto, conservar una copia de la fuente y registrar qué valores no se han podido convertir. Las reglas deben mantenerse separadas de la lógica de lectura para que puedan repetirse sobre diferentes extracciones.

En bases de datos relacionales, parte de las mismas verificaciones puede ejecutarse en SQL. Por ejemplo, si se ha confirmado que las cantidades son positivas y el total es el producto directo de cantidad por precio:

SELECT pedido_id, unidades, precio_unitario, total
FROM pedidos
WHERE unidades <= 0
   OR ABS(total - unidades * precio_unitario) > 0.01;

La consulta localiza candidatos a revisión sin modificar filas. Como en el ejemplo de Python, solo es válida si la regla contable descrita corresponde a la tabla real. Es preferible obtener un listado de incidencias justificadas que corregir valores mediante una actualización masiva.

Cómo investigar una alerta y convertirla en un hallazgo útil

El detector proporciona una lista de candidatos. El trabajo profesional comienza al explicar qué ocurre, dónde se originó y si es necesario actuar.

1. Guardar la evidencia: referencia del registro, conjunto y versión, regla activada, valor observado y fecha de detección.
2. Repetir la comprobación: descartar errores introducidos durante la importación, el filtrado o la ejecución del control.
3. Revisar el origen: contrastar con el documento, sistema o evento que generó el dato, si existe acceso legítimo.
4. Consultar el contexto: analizar segmento, periodo, unidad, campaña, excepciones operativas o cambios de procedimiento.
5. Clasificar el hallazgo: error confirmado, valor excepcional válido, no concluyente o falso positivo de la regla.
6. Definir una acción: corregir en origen, actualizar el conjunto derivado, excluir de un análisis concreto con justificación o aceptar el registro.
7. Registrar la resolución: quién verificó, qué evidencia utilizó y qué cambio se aplicó, si lo hubo.

Una misma observación puede ser válida para un propósito e inadecuada para otro. Por ejemplo, una incidencia extraordinaria puede mantenerse en el histórico de operaciones, pero quizá necesite un tratamiento específico en un modelo que pretende describir la carga ordinaria de trabajo. En ese caso se documenta la selección analítica; no se modifica el hecho histórico.

La investigación debe proteger también la confidencialidad: para analizar un patrón no siempre es necesario compartir nombres, correos o identificadores personales. Las muestras y evidencias pueden minimizarse o seudonimizarse según el caso.

Cómo priorizar las anomalías cuando aparecen cientos de alertas

Un detector puede generar muchas incidencias en pocos segundos. Revisarlas todas en orden de aparición no suele ser la mejor estrategia. Conviene valorar el impacto potencial y la solidez de la evidencia.

Una matriz sencilla de atención

La prioridad aumenta cuando el fallo puede alterar decisiones, propagarse a otros conjuntos, afectar a muchas observaciones o comprometer un uso crítico. También importa la facilidad de comprobación: una verificación sencilla y concluyente puede resolverse antes que una investigación costosa de bajo impacto.

Es útil separar severidad de confianza de detección. Un valor estadísticamente muy raro puede tener confianza baja como «error», mientras que una clave foránea inexistente frente a un catálogo completo ofrece una evidencia bastante más concreta.

Evitar que los mismos errores reaparezcan y conservar la trazabilidad

La limpieza puntual mejora una extracción, pero no garantiza que la siguiente sea correcta. Para que la detección aporte valor a largo plazo, sus reglas deben integrarse en un circuito repetible de preparación de datos.

Situar controles en distintas etapas

• En la captura: validar formatos, dominios y campos obligatorios cuando el sistema lo permita.
• En la ingestión: comprobar el esquema, el número de registros, la integridad de archivos y las conversiones.
• Tras cada transformación crítica: contrastar claves, cardinalidades, unidades y agregados de control.
• Antes del análisis: revisar el perfil estadístico, la cobertura y las excepciones pendientes.
• En ejecuciones posteriores: observar tendencias en incidencias y cambios del comportamiento de los datos.

No sobrescribir silenciosamente el dato recibido

La práctica más segura consiste en mantener el origen inalterado y generar una versión preparada o corregida con un registro de transformaciones. Si se reemplaza un valor, debe conocerse cuál era, por qué se cambió y en qué revisión.

En ocasiones el tratamiento correcto es añadir una bandera de calidad, no alterar la variable. Una columna como requiere_revision permite excluir provisionalmente registros de un cálculo sin perderlos del conjunto original.

Medir la eficacia del control

Además del número de alertas, interesa observar cuántas se confirmaron, cuántas fueron legítimas, cuánto tardaron en resolverse y qué causas se repiten. La tasa de falsos positivos se estima sobre alertas revisadas; si solo se inspecciona una selección no representativa, debe indicarse esa limitación.

Los umbrales pueden requerir ajustes cuando cambian los productos, la población o la instrumentación. Una regla que funcionaba hace seis meses puede haber dejado de representar la realidad. La revisión periódica evita tanto la fatiga de alertas como la pérdida silenciosa de cobertura.

Errores habituales al detectar anomalías en conjuntos de datos

Eliminar todo lo que supera un umbral

Un filtro estadístico no distingue entre errores y casos excepcionales auténticos. Borrar automáticamente extremos puede sesgar medias, ocultar riesgos y hacer que un modelo falle precisamente cuando aparecen condiciones poco frecuentes.

Aplicar un umbral global a poblaciones diferentes

Mezclar productos, regiones o clases de clientes con comportamientos distintos crea referencias engañosas. Es preferible estudiar los segmentos relevantes y justificar cuándo se utilizan umbrales comunes.

Confundir cero, valor ausente y ausencia de actividad

Un cero medido, un campo no informado y un intervalo sin registros tienen significados diferentes. Transformarlos en un único valor impide interpretar correctamente tendencias y ratios.

No comprobar las uniones de tablas

Una relación mal definida puede multiplicar operaciones y aparentar una subida de ventas o de volumen. Las comprobaciones de cardinalidad y conciliación deben acompañar a cualquier integración importante.

Usar modelos complejos sin etiquetas ni revisión humana

Un detector puede encontrar observaciones raras sin saber cuáles son defectuosas. Sin evidencia de validación, el porcentaje de anomalías señalado por un algoritmo no equivale a una tasa de error real del conjunto.

Corregir una extracción y olvidar la causa

Si la anomalía procede del sistema de origen, la siguiente carga volverá a introducirla. El resultado de la revisión debería traducirse, cuando sea posible, en controles preventivos o cambios documentados del proceso.

Preguntas frecuentes sobre detección de anomalías en datos

Conclusión: la detección es una investigación, no una limpieza automática

Un conjunto de datos fiable no es aquel en el que todos los valores parecen normales, sino aquel cuyas observaciones pueden interpretarse, comprobarse y relacionarse con su origen. Las mejores revisiones combinan reglas de negocio, controles de estructura, análisis estadístico y conocimiento del proceso que generó la información.

El orden importa: primero se define qué representa cada registro; después se buscan contradicciones verificables; a continuación se analizan desviaciones y patrones; y, finalmente, se decide qué corregir, conservar o investigar. Así se evita tanto utilizar datos defectuosos como borrar hechos excepcionales que podrían ser decisivos.

El resultado más valioso no es una tabla sin valores atípicos, sino un conjunto de datos con decisiones de calidad justificadas y reproducibles. Esa disciplina permite realizar análisis posteriores con mayor confianza y explicar sus límites a quienes utilizarán las conclusiones.