Un panel puede estar en verde mientras la decisión que hay detrás es errónea. Un equipo financiero puede recibir un informe regulatorio de aspecto completo aunque un sistema de origen haya cambiado un valor de código. Los analistas pueden comparar dos métricas de cliente que usan definiciones distintas. Un equipo de operaciones puede actuar sobre los datos de ayer porque el pipeline entregó tarde sin lanzar ninguna alerta.

Estos fallos son difíciles de discutir cuando cada equipo entiende algo distinto por «calidad de datos». Uno se refiere a la exactitud, otro a la frescura y un tercero a si la tabla estaba disponible cuando se ejecutó un trabajo. ISO/IEC 25012 da a esas conversaciones un vocabulario común y después aporta una forma estructurada de conectar las expectativas de calidad con comprobaciones medibles.

La pregunta útil no es si un conjunto de datos es «bueno». Es si el conjunto sirve para un propósito concreto y si la organización puede demostrar esa adecuación a lo largo del tiempo. El camino del modelo a la práctica pasa por definiciones, prioridades, controles, cuadros de mando, flujos de excepción y evidencia de auditoría.

Tabla de contenidos

• Introducción: por qué la calidad de datos necesita un modelo compartido

  • El coste oculto de un lenguaje de calidad impreciso

  • Del vocabulario a la evidencia operativa

• Qué es ISO 25012 y por qué existe

  • Piense en ello como un código de edificación

  • En qué ayuda el modelo a los equipos

• Las 15 características de calidad de datos explicadas de forma sencilla

  • Calidad inherente

  • Calidad dependiente del sistema

• Interpretar ISO 25012 para programas de datos empresariales

  • De características a requisitos

  • Un cuadro de mando necesita contexto

• Mapear ISO 25012 a controles de observabilidad y validación

  • Un mapa de control práctico

  • Separar defectos de datos de defectos de plataforma

• Ejemplos sectoriales donde ISO 25012 evita fallos costosos

  • Servicios financieros

  • Sanidad

  • Telecomunicaciones

  • Sector público

• Lista de implementación y elementos esenciales del informe de auditoría

Introducción: por qué la calidad de datos necesita un modelo compartido

Un ingeniero de datos observa que una tabla diaria de clientes se cargó correctamente. El estado del pipeline está en verde, los recuentos de filas parecen los habituales y el panel de BI se actualizó sin errores. Más tarde, el equipo comercial descubre que una aplicación de origen ha empezado a enviar un nuevo código de estado. Los registros están presentes, pero la lógica de negocio los interpreta mal.

Nada en ese incidente parece necesariamente un fichero ausente o un trabajo fallido. Los datos pueden estar disponibles pero no ser exactos para la decisión. Pueden ser completos a nivel de registro pero incoherentes con otro sistema. Pueden ser creíbles en su origen y aun así no ser lo bastante actuales para el proceso que los consume.

El coste oculto de un lenguaje de calidad impreciso

Cuando los equipos carecen de un modelo común, suelen crear definiciones locales. Un conjunto financiero puede tener una regla de completitud mientras uno sanitario usa otra interpretación. Ingeniería puede vigilar el tiempo de entrega, los analistas pueden revisar valores a mano y gobierno puede pedir evidencias tras un incidente. Cada actividad puede ser razonable, pero a la organización le cuesta comparar resultados o asignar responsabilidad.

Un modelo compartido ayuda a los equipos a separar tipos de fallo. Los fallos de exactitud apuntan a valores incorrectos. Los fallos de coherencia indican contradicciones. Los fallos de actualidad afectan a información desfasada, mientras que los fallos de disponibilidad afectan a si los consumidores autorizados pueden acceder a los datos cuando los necesitan.

Regla práctica: nunca pregunte si los datos son «de alta calidad» sin nombrar el caso de uso, la característica y la evidencia esperada.

Del vocabulario a la evidencia operativa

ISO/IEC 25012 importa porque puede servir de puente entre las expectativas del negocio y la observabilidad técnica. Un responsable de gobierno puede definir qué significa «actual» para un conjunto de reporte. Un ingeniero puede implementar la monitorización de entregas. Un analista puede revisar un cuadro de mando y un auditor puede inspeccionar las excepciones registradas y el historial de remediación.

Esa progresión vale más que una lista estática. El modelo aporta las categorías. La empresa decide qué características importan más, define umbrales, selecciona controles y registra los resultados. La monitorización en base de datos puede apoyar ese proceso evaluando los datos donde ya residen, mientras que la validación y la detección de anomalías distinguen los fallos de reglas de negocio del comportamiento inesperado de la plataforma.

Qué es ISO 25012 y por qué existe

ISO/IEC 25012 es un modelo general de calidad de datos para datos estructurados en sistemas informáticos. Se publicó en diciembre de 2008 como parte de la familia ISO/IEC SQuaRE, y la ficha del catálogo ISO para ISO/IEC 25012 la identifica como una norma internacional de 13 páginas.

La norma existe para apoyar tres actividades relacionadas: definir requisitos de calidad de datos, medir la calidad de datos y evaluar si los datos son adecuados para su uso previsto. Se centra en datos estructurados, lo que la hace relevante para bases de datos, sistemas de información, entornos analíticos y procesos de reporte.

Piense en ello como un código de edificación

Un código de edificación no dice a cada arquitecto cómo diseñar exactamente un hospital, un almacén o una vivienda. Identifica preocupaciones de seguridad y restricciones que el diseño debe abordar. El equipo del proyecto sigue decidiendo cómo se aplican esos requisitos al propósito, la ubicación, los materiales y el perfil de riesgo del edificio.

ISO/IEC 25012 funciona de forma parecida. Da a las organizaciones un vocabulario estructurado de características de calidad de datos, no una puntuación universal que todo conjunto deba alcanzar. Una dirección de cliente, una medición clínica y una transacción regulatoria pueden requerir prioridades distintas aunque se almacenen en estructuras de base de datos similares.

Por eso el modelo no debe tratarse como una guía de implementación llave en mano. No proporciona un único conjunto de umbrales, pesos, calendarios de monitorización o asignaciones de responsabilidad para toda empresa. Esas decisiones corresponden a quien evalúa y al contexto de negocio.

En qué ayuda el modelo a los equipos

Una secuencia de adopción práctica es la siguiente:

1. Defina el requisito. Establezca qué significa calidad para un conjunto de datos y su uso previsto.

2. Seleccione las características relevantes. Elija dimensiones que reflejen el riesgo de negocio, regulatorio, analítico y operativo.

3. Especifique la evidencia. Decida qué mediciones, resultados de validación, registros de linaje u observaciones del sistema demostrarán el cumplimiento.

4. Evalúe la adecuación al uso. Determine si el conjunto puede sostener el proceso, informe, modelo o decisión.

Las organizaciones pueden usar el modelo como base para estándares de calidad de datos y prácticas de gobierno, pero la implementación sigue exigiendo decisiones locales. La distinción evita un error habitual: suponer que nombrar una característica equivale a controlarla.

Las 15 características de calidad de datos explicadas de forma sencilla

ISO/IEC 25012 define 15 características de calidad de datos. Un resumen neutral las enumera como exactitud, completitud, coherencia, credibilidad, actualidad, accesibilidad, conformidad, confidencialidad, eficiencia, precisión, trazabilidad, comprensibilidad, disponibilidad, portabilidad y recuperabilidad. La misma lista aparece en el material de buenas prácticas del NPL sobre características de calidad de datos.

El modelo agrupa las características en torno a dos perspectivas. La calidad inherente atañe a los datos en sí. La calidad dependiente del sistema atañe a cómo el sistema circundante permite a personas y aplicaciones acceder, proteger, procesar, mover y restaurar esos datos. Algunas características pueden depender de ambas.

Calidad inherente

• La exactitud significa que el valor representa correctamente el objeto, evento o condición del mundo real. Una dirección de cliente registrada debe reflejar la dirección real del cliente.

• La completitud significa que la información esperada está presente para el uso previsto. Un registro de proveedor sin un identificador obligatorio puede ser inservible aunque todos los campos rellenos sean válidos.

• La coherencia significa que los datos no se contradicen ni entran en conflicto entre sistemas. Un cliente no debería tener estados de ciclo de vida incompatibles en aplicaciones conectadas sin una razón definida.

• La credibilidad se refiere a si los usuarios pueden confiar razonablemente en los datos como verosímiles y fiables, considerando su origen y proceso de recogida.

• La actualidad significa que los datos reflejan el horizonte temporal requerido. Un valor puede ser exacto históricamente pero inadecuado para un proceso que necesita el último estado.

• La precisión describe si los datos tienen el nivel de detalle adecuado. Un valor redondeado puede servir para un resumen pero fallar en un cálculo que exige mayor granularidad.

Calidad dependiente del sistema

• La accesibilidad significa que los usuarios y aplicaciones autorizados pueden recuperar y usar los datos.

• La conformidad significa que los datos y su tratamiento siguen las reglas, normas, contratos y políticas aplicables.

• La confidencialidad protege los datos frente a accesos o divulgaciones no autorizados.

• La eficiencia se refiere a los recursos y al comportamiento de procesamiento necesarios para usar los datos con eficacia.

• La trazabilidad permite a los equipos seguir orígenes, transformaciones, cambios y actores responsables.

• La comprensibilidad hace que campos, códigos, etiquetas y significados resulten claros para sus usuarios previstos.

• La disponibilidad significa que los datos y el servicio asociado pueden usarse cuando se requieren.

• La portabilidad permite el movimiento entre sistemas sin perder significado ni calidad.

• La recuperabilidad atañe a la restauración tras pérdida, corrupción, fallo o interrupción.

Una distinción útil es que exactitud y actualidad no son intercambiables. Un valor con marca temporal pudo ser exacto al capturarse pero estar obsoleto para la decisión de hoy. Del mismo modo, accesibilidad y disponibilidad no son idénticas. Un sistema puede estar funcionando mientras un usuario carece de acceso autorizado, o una tabla puede ser accesible en principio mientras el servicio no está disponible durante un flujo crítico.

Para una discusión más amplia de cómo encajan estas dimensiones, consulte las dimensiones de la calidad de datos.

Interpretar ISO 25012 para programas de datos empresariales

Un modelo se vuelve útil cuando una organización convierte sus características en decisiones. El mismo conjunto puede necesitar fuerte trazabilidad para una auditoría, alta actualidad para el despacho operativo y estricta confidencialidad para registros sensibles. Tratar toda característica como igual de importante genera ruido y hace que los equipos inviertan esfuerzo donde el riesgo de negocio puede ser menor.

ISO/IEC 25012 deja la ponderación, los umbrales y la priorización según contexto a quien evalúa. Esa flexibilidad es necesaria, pero también genera trabajo de implementación. Un programa de datos debe definir qué significa cada característica para un conjunto concreto y después conectar la definición con un indicador medible y un responsable.

De características a requisitos

Empiece por el caso de uso, no por la herramienta de monitorización. Para un informe regulatorio, un requisito podría conectar conformidad, trazabilidad, completitud y coherencia. Para una tabla operativa casi en tiempo real, la actualidad, la disponibilidad y la recuperabilidad merecen más atención.

Un conjunto puede parecer aceptable en conjunto y fallar en una dimensión crítica para el negocio. Una puntuación media puede ocultar incoherencia semántica, atributos incompletos o datos que han quedado demasiado viejos para el proceso. Un estudio de investigación que aplica ISO/IEC 25012 subraya este reto práctico y la necesidad de evaluar características concretas en lugar de confiar solo en una impresión agregada.

Un cuadro de mando necesita contexto

Un cuadro de mando útil debe mostrar más que una nota única. Incluya la característica, la métrica, el resultado observado, el umbral, el responsable de negocio, el responsable técnico, el periodo de evaluación y el estado de excepción. Mantenga disponible la evidencia subyacente para que un revisor pueda pasar del resumen a los registros fallidos, la ejecución de la regla, el evento de entrega o el cambio de esquema.

ISO/IEC 25024:2015 ofrece un enfoque complementario de medidas cuantitativas asociadas a las características definidas en ISO/IEC 25012. La ficha del catálogo ISO para ISO/IEC 25024 describe su papel en la definición de medidas de calidad de datos. Ayuda a pasar de «monitorizar la completitud» a un método de medición definido, mientras la organización sigue decidiendo qué resultado es aceptable para su caso.

Un cuadro de mando solo es creíble cuando un revisor puede rastrear su estado hasta evidencia reproducible.

Un marco empresarial debe, por tanto, combinar priorización con responsabilidad. Las directrices de un marco empresarial de calidad de datos pueden ayudar a estructurar ese modelo operativo, pero la implementación debe seguir reflejando los riesgos, la arquitectura, los contratos y las expectativas de servicio de la organización.

Mapear ISO 25012 a controles de observabilidad y validación

La operacionalización empieza traduciendo cada característica en una pregunta observable. ¿Se puede confiar en el valor? ¿Llegó la carga esperada? ¿Cambió el esquema? ¿Puede el sistema restaurar los datos? Cada pregunta apunta a una familia de controles distinta, y ninguna prueba individual cubre todas las dimensiones.

Use ejecución en base de datos allí donde el control pueda calcularse dentro de la base del cliente. Ese enfoque mantiene la evaluación cerca de los datos y admite patrones de despliegue en nube privada, VPC, on-premises y otros entornos controlados. El resultado del control debe incluir el conjunto de datos, el momento de evaluación, la regla o detector usado, el estado, el responsable y enlaces al incidente o registro de remediación correspondiente.

Un mapa de control práctico

Esta matriz es un punto de partida, no un sustituto del diseño de controles. Una comprobación de actualidad puede inspeccionar la hora de llegada en una tabla y las fechas de vigencia de negocio en otra. Una comprobación de coherencia puede comparar dos sistemas o validar relaciones dentro de un mismo conjunto.

Separar defectos de datos de defectos de plataforma

Un flujo de incidentes útil clasifica el fallo antes de repartir culpas. Un valor fuera del rango aprobado por el negocio no es lo mismo que un tiempo de espera agotado en una consulta. Un campo ausente causado por una aplicación anterior no es lo mismo que una tabla inaccesible por una caída de plataforma.

digna ofrece módulos de Data Anomalies, Data Analytics, Timeliness, Data Validation y Schema Tracker, con el cálculo y análisis de métricas realizados en la propia base de datos. Los equipos pueden usar esos patrones de capacidad junto a sus pruebas de almacén, alertas de orquestación, catálogo, controles de acceso, procedimientos de copia de seguridad y sistema de gestión de incidentes. La visión general de la plataforma de observabilidad de datos aporta el contexto de producto.

La mejor implementación registra tanto la detección como la respuesta. Una validación fallida debe mostrar qué regla falló, mientras que una alerta de Timeliness debe mostrar el patrón de entrega esperado y el evento observado. Esa evidencia convierte la monitorización de una luz de aviso en un control de gobierno repetible.

Ejemplos sectoriales donde ISO 25012 evita fallos costosos

El valor de ISO 25012 se ve más claro cuando el mismo modelo se aplica a entornos operativos distintos. Cada sector enfatiza riesgos diferentes, aunque las características subyacentes siguen siendo reconocibles.

Servicios financieros

Un equipo de reporte regulatorio concilia transacciones de varios sistemas. Los totales parecen plausibles, pero una transformación cambió cómo se representa una categoría de producto. La preocupación inmediata es la conformidad, pero la remediación también exige trazabilidad, coherencia y evidencia clara de validación.

El equipo puede preservar el linaje del origen al informe, validar los valores de código aprobados, comparar medidas relacionadas y dirigir las excepciones a responsables nombrados. El modelo ayuda a describir el fallo con precisión en lugar de etiquetar todo el informe como «malo».

Sanidad

Un grupo de analítica clínica recibe datos de pacientes de varios procesos de recogida. Un feed contiene registros válidos pero omite un campo importante para un subconjunto de episodios. Otro feed usa una interpretación de códigos significativamente distinta.

Aquí importan por igual la completitud, la credibilidad, la exactitud y la comprensibilidad. La validación a nivel de registro puede identificar valores ausentes o inválidos, mientras que las definiciones documentadas y el historial de origen ayudan a los revisores a determinar si una discrepancia es un problema de captura, de mapeo o de interpretación.

Telecomunicaciones

Un equipo de operaciones de red depende de datos de eventos de alto volumen. Un retraso del pipeline deja el panel accesible, pero la vista ya no refleja el estado operativo que los ingenieros necesitan. Un cambio de esquema aparte hace que la lógica posterior ignore un campo recién introducido.

La actualidad, la disponibilidad, la portabilidad y la recuperabilidad dan al equipo un diagnóstico más completo. La monitorización de Timeliness puede señalar el comportamiento de entrega, el seguimiento de esquema puede exponer cambios estructurales y los procedimientos de recuperación pueden abordar las consecuencias de una carga fallida o incompleta.

Sector público

Un programa de reporte gubernamental combina información de departamentos con convenciones de datos distintas. Los registros pueden estar presentes en todas las fuentes y, aun así, los identificadores y los valores de estado no cuadran. Durante una auditoría, la organización debe explicar no solo el resultado publicado, sino también cómo se produjo.

La coherencia, la trazabilidad, la conformidad y la comprensibilidad pasan a ser centrales. Un modelo compartido da a responsables de políticas, ingenieros, analistas y auditores una forma común de describir el objetivo de control y revisar la evidencia.

Lista de implementación y elementos esenciales del informe de auditoría

La implementación funciona mejor cuando los equipos tratan ISO/IEC 25012 como un modelo de control vivo y no como un documento que archivar. Empiece por los conjuntos que sostienen decisiones materiales, reporte regulado, procesos de cliente, trabajo clínico o automatización operativa.

Use esta lista de comprobación:

• Acote los datos críticos: identifique el conjunto, el proceso de negocio, los consumidores, los sistemas de origen y el responsable.

• Elija características: seleccione las dimensiones que encajan con el caso de uso en lugar de aplicar todos los controles indiscriminadamente.

• Defina mediciones: use ISO/IEC 25024 como referencia de medidas cuantitativas y documente después la definición local de la métrica.

• Fije reglas de decisión: registre umbrales, ventanas de evaluación, severidad, escalado y tratamiento de excepciones.

• Asigne responsabilidad: separe la propiedad de las reglas de negocio de la propiedad de ingeniería sobre el comportamiento de plataforma y pipeline.

• Monitorice en el entorno adecuado: considere la ejecución en base de datos dentro de la VPC, la nube privada, el entorno on-premises o el centro de datos de la organización.

• Conserve la evidencia: guarde resultados de reglas, contexto de anomalías, historial de entregas, cambios de esquema, linaje, marcas temporales y decisiones de remediación.

• Informe según la audiencia: dé a los ingenieros el detalle del incidente, a los analistas el contexto de tendencia y a los responsables de gobierno una visión de control concisa.

Un enfoque de calidad de datos preparado para auditoría debe hacer explicable cada estado reportado. Los revisores necesitan saber qué se comprobó, contra qué requisito, cuándo se ejecutó, qué falló, quién respondió y si el problema afectó a decisiones posteriores.

digna ofrece una plataforma empresarial de calidad y observabilidad de datos que monitoriza el comportamiento de los datos, valida registros, sigue la Timeliness, detecta cambios de esquema y da soporte a la monitorización de negocio y plataforma dentro del entorno del cliente. Visite digna para explorar cómo sus patrones de monitorización en base de datos ayudan a convertir las características de ISO 25012 en controles medibles y evidencia de auditoría.

Vea cómo digna convierte estas características en controles en funcionamiento: monitorización de calidad de datos en todas sus plataformas.

Preguntas frecuentes

¿Qué es ISO 25012?

ISO/IEC 25012 es una norma internacional que define un modelo de calidad de datos para información almacenada de forma estructurada. Da a los equipos un vocabulario común de 15 características, de modo que «calidad de datos» deje de significar exactitud para una persona y frescura para otra.

¿Cuáles son las 15 características de calidad de datos de ISO 25012?

Cubren exactitud, completitud, coherencia, credibilidad y actualidad, más accesibilidad, conformidad, confidencialidad, eficiencia, precisión, trazabilidad, comprensibilidad, disponibilidad, portabilidad y recuperabilidad. En conjunto describen tanto los datos en sí como el sistema que los sirve.

¿Cuál es la diferencia entre calidad inherente y dependiente del sistema?

Las características inherentes pertenecen a los datos con independencia de dónde residan, como la exactitud y la completitud. Las dependientes del sistema dependen de la plataforma que los entrega, como la disponibilidad y la recuperabilidad. Separarlas indica si tiene un defecto de datos o un defecto de plataforma.

¿Cómo se mapea ISO 25012 a controles reales?

Traduzca cada característica relevante en un requisito medible y enlácela con un control que se ejecute: la actualidad pasa a ser un umbral de Timeliness, la completitud una monitorización de tasa de nulos, la coherencia una conciliación entre sistemas. Una característica sin un control detrás es vocabulario, no garantía.

¿Existe una certificación ISO 25012?

Es un modelo de referencia y no una norma certificable, así que no hay sello de auditoría que obtener. Su valor en una auditoría es otro: aporta un lenguaje defendible y una estructura para mostrar qué características mide, cómo y con qué evidencia.