Calidad de Datos

Operadora Horizonte quiere evitar facturas duplicadas y respuestas de IA basadas en contratos desactualizados. “Datos de calidad” necesita una definición ligada a cada uso: un dato puede servir para una exploración y ser insuficiente para emitir una factura.

Conceptos Clave

La calidad expresa si los datos sirven para una finalidad concreta. Antes de medir, identifica la población, el periodo y la evidencia autorizada: un resultado aceptable para explorar puede ser insuficiente para facturar.

Completitud pregunta si está el valor requerido; validez, si respeta el formato o dominio permitido; exactitud, si coincide con la realidad que representa. Son pruebas distintas: la fecha de inicio 31 AGO puede estar presente y tener formato admitido, pero ser incorrecta si el contrato verificado dice 01 SEP.

Consistencia comprueba que no existan contradicciones entre valores relacionados; unicidad, que una identidad empresarial no se repita según la regla acordada; oportunidad, que el dato esté disponible dentro del plazo que necesita el uso. Un control de fechas no demuestra ninguna de estas tres dimensiones. Cada una necesita su propia regla, población y evidencia.

La fecha de inicio del contrato verificado es 01 SEP, pero se captura 31 AGO. El mismo valor atraviesa tres comprobaciones: está presente y supera completitud; tiene un formato admitido y supera validez; no coincide con el contrato y falla exactitud. Debe corregirse contra la evidencia autorizada. El caso no prueba consistencia entre fuentes, unicidad de la identidad ni oportunidad de llegada: cada dimensión requiere su propia regla, población y evidencia para el uso previsto. ↗

Reglas, Umbrales y Remediación

La regla comienza en una necesidad: “no emitir dos veces la misma factura”. El propietario de Facturación define la clave empresarial, la tolerancia y el efecto de un incumplimiento. El steward traduce esa decisión a una regla comprensible. El ingeniero implementa la comprobación y registra resultado, periodo y versión.

Un umbral debe indicar numerador, denominador, tratamiento de exclusiones y operador de comparación. “Al menos 99 %” incluye 99 %; “más de 99 %” no. La tolerancia depende del riesgo: ciertos controles impiden publicar, otros permiten continuar con una excepción autorizada. El promedio de muchas reglas no debe ocultar una falla crítica.

La necesidad es no emitir dos veces la misma factura. El propietario acuerda la clave emisor más número, el corte de septiembre, las exclusiones y el umbral de unicidad del 100 %; el steward documenta R-02 y el ingeniero conserva su versión y resultado. La medición encuentra 198 claves distintas para 200 filas: 99 % es menor que 100 %, por lo que se bloquea la publicación y se abre D-17. Se asignan responsable, prioridad y fecha objetivo, se investiga la causa y se corrige en el origen. Después se repite R-02 sobre el corte corregido: cerrar sólo con evidencia de cumplimiento; si falla, el incidente continúa abierto. ↗

La remediación incluye responsable, prioridad, causa, fecha objetivo y verificación posterior. Limpiar una copia puede ser útil para un consumo específico, pero no elimina el problema en la captura. Horizonte distingue dato corregido, dato rechazado y excepción aceptada; conserva la razón para poder explicar el resultado publicado.

Calidad con Oracle AI Data Platform y Oracle Autonomous AI Lakehouse

Oracle AI Data Platform permite preparar y transformar datos mediante notebooks y workflows; el equipo puede expresar comprobaciones con SQL o código y conservar resultados. Oracle Autonomous AI Lakehouse y Data Studio de Oracle Autonomous AI Database aportan estadísticas, análisis y preparación. Table AI Assist propone SQL y recetas que una persona revisa antes de aplicarlas; no certifica que el dato sea verdadero.

Implementa las reglas de aceptación en notebooks y coordina su ejecución con workflows de Oracle AI Data Platform. Para Horizonte, comprueba unicidad de factura y existencia del cliente, registra los resultados y separa los incumplimientos con su motivo. El propietario aprueba la regla y la acción; el flujo publica los datos aceptados y vuelve a medir los registros corregidos. Así conviertes una dimensión de calidad en un control repetible.

Una regla aprobada se evalúa mediante notebooks y workflows de Oracle AI Data Platform. Los datos conformes siguen hacia una publicación autorizada en Oracle Autonomous AI Lakehouse. Los que fallan conservan motivo, responsable y estado; se corrigen y vuelven a medir. La ruta de publicación necesita aceptar la regla y los demás controles correspondientes al uso. ↗

Oracle Data Transforms permite organizar transformaciones y ejecuciones. Las estadísticas muestran patrones útiles para perfilar, pero una distribución inesperada requiere interpretar el negocio. La detección técnica no decide sola si se bloquea el cierre. Asimismo, la validación de calidad de una Analytic View tiene un alcance específico: no es una certificación integral de todas las fuentes.

Documenta cada regla en una ficha con propósito, población, lógica, umbral, responsable, resultado y acción. Oracle AI Data Platform y Oracle Autonomous AI Lakehouse permiten implementarla; la ficha continúa siendo válida si cambian los motores o la ubicación de los datos.

Ejemplo Explicado

Horizonte recibe 1 000 contratos. Diez no tienen fecha de inicio y otros veinte presentan una fecha fuera del periodo permitido. Para la regla de presencia, 990 de 1 000 cumplen: 99 %. Si las dos poblaciones defectuosas no se solapan, la regla combinada de presencia y periodo tiene 970 conformes: 97 %.

La cuadrícula representa 1 000 contratos, diez por cuadrado, con defectos sin superposición. La completitud alcanza 990/1 000 = 99 % y supera su umbral. La regla de fecha presente y dentro del periodo alcanza 970/1 000 = 97 % y falla el mínimo del 98 %. Distingue población, defectos y umbrales de cada regla antes de combinar o comparar porcentajes. ↗

El propietario había acordado al menos 99 % para presencia y 98 % para la regla combinada. La primera pasa y la segunda falla. El pipeline no debe reemplazar ambas por un promedio que parezca aceptable. El steward asigna los casos, identifica si la captura permite fechas imposibles y coordina la corrección del formulario o proceso de origen.

Después se vuelve a medir sobre una población identificada. Una mejora declarada sin periodo ni denominador no permite comparar resultados y puede ocultar simplemente que se excluyeron los casos difíciles.

Errores Frecuentes

• “Sin nulos significa exacto”. La presencia no verifica el valor contra la realidad.
• “Una limpieza resuelve la causa”. El error puede seguir entrando por el mismo proceso.
• “El promedio de calidad permite publicar”. Una falla crítica puede exigir bloqueo aunque otras reglas sean perfectas.

Ejercicio de Decisión

Una carga de 200 facturas contiene dos registros excedentes según la clave y el criterio de conteo acordados: quedan 198 claves únicas. La política exige 100 % de unicidad para publicar facturas. Otra regla de completitud alcanza 100 %. El equipo propone promediar ambas reglas y continuar. Decide qué hacer y quién debe resolverlo.