Métricas de calidad de datos: una guía completa para 2026

Un dashboard se veía bien a las 8:00 a.m. Para las 9:15, finanzas cuestionaba la cifra de ingresos, operaciones perseguía un problema con un envío y el equipo de datos intentaba resolver si el problema comenzó en la ingesta, en la transformación o en un sistema de origen que cambió de forma de la noche a la mañana.

Ahí es donde suelen encontrarse las organizaciones cuando empiezan a tomarse en serio la calidad de los datos. No en el momento de la teoría, sino en el momento del fallo. Un campo de dirección faltante bloquea el cumplimiento. Un registro de cliente duplicado infla un KPI. Una tabla desactualizada alimenta un modelo que era preciso ayer y no es confiable hoy.

Los métricas de calidad de datos son la forma de dejar de discutir por instinto y empezar a operar basados en la evidencia. Convierten el “algo se siente mal” en señales medibles, verificaciones repetibles y flujos de trabajo de incidentes en los que la gente puede confiar.

Índice de contenidos

• Por qué las métricas de calidad de datos son no negociables en 2026

  • Qué métricas cambian en la práctica

• Explicación de las seis dimensiones fundamentales de la calidad de datos

  • Precisión

  • Integridad

  • Consistencia

  • Oportunidad

  • Validez

  • Unicidad

• Cómo calcular métricas clave de calidad de datos

  • Comenzar con un contrato de métricas

  • Fórmulas SQL que los equipos realmente usan

  • Los umbrales pertenecen a los casos de uso, no a las tablas

• De métricas brutas a insights accionables

  • Umbrales en los que la gente confiará

  • Alertas que no enseñan a los equipos a ignorar las alertas

  • Muestreo y establecimiento de líneas base en entornos desordenados

• Operacionalización de la calidad de datos: Un ejemplo de dashboard de KPI

  • Qué muestra el dashboard a simple vista

  • Qué hace cada equipo con él

• Desafíos avanzados sin respuesta en las métricas estándar

  • Microerrores que se ocultan dentro de buenos promedios

  • Por qué una puntuación única es más difícil de lo que parece

• Cómo las plataformas de Data Observability automatizan las métricas de calidad

Por qué las métricas de calidad de datos son no negociables en 2026

Los equipos suelen descubrir la necesidad de métricas de calidad de datos después de un incidente evitable. Un informe de la junta es incorrecto. Una tabla de características de machine learning está desactualizada. Un cambio de esquema llega sin previo aviso y la lógica descendente sigue ejecutándose como si nada hubiera pasado.

El problema no son solo los datos incorrectos. El problema son los datos incorrectos sin instrumentación.

Según el resumen de estadísticas de calidad de datos de Monte Carlo, Gartner predice que el 30% de las organizaciones no logrará llevar a cabo con éxito iniciativas impulsadas por datos debido a la mala calidad de los mismos, mientras que el 41% de las organizaciones tiene dificultades para gestionar más de 1,000 fuentes de datos. A esa escala, la verificación manual deja de ser una disciplina y se convierte en una expresión de deseos.

Qué métricas cambian en la práctica

Un equipo maduro no se pregunta: “¿Es bueno este conjunto de datos?”. Se hace preguntas operativas más específicas:

• ¿Están los datos lo suficientemente frescos para la decisión que respaldan?

• ¿Llegaron los campos requeridos para la carga actual?

• ¿Cumplen los registros con las reglas de negocio y de formato?

• ¿Cambió de forma un origen sin un lanzamiento coordinado?

• ¿El problema es local o sistémico a través de dominios y pipelines?

Estas preguntas son las que transforman la calidad de los datos de un lenguaje de governance a un trabajo de ingeniería.

Regla práctica: Si no puedes asociar una métrica a un modo de fallo, aún no tienes una estrategia de monitoreo. Tienes una política.

Esta es también la razón por la que el trabajo de calidad de datos comienza a solaparse con la telemetría operativa. Los equipos que ya están dominando la gestión centralizada de logs suelen adaptarse más rápido, porque ya entienden las líneas base, el ruido en las alertas, la correlación de eventos y la propiedad de los incidentes. Las métricas de datos necesitan el mismo modelo operativo.

Un buen sistema no persigue la perfección. Mide lo que importa, en la capa correcta, con umbrales vinculados a las consecuencias de negocio.

Explicación de las seis dimensiones fundamentales de la calidad de datos

El vocabulario estándar sigue importando. La precisión, integridad, consistencia, oportunidad, validez y unicidad son las seis dimensiones más utilizadas en la práctica y se alinean con el marco ISO/IEC 25012:2008 resumido en este estudio.

Si deseas una referencia complementaria sobre detalles de implementación, esta guía sobre dimensiones de calidad de datos y cómo medirlas a escala es de gran utilidad. Sin embargo, la parte importante es mapear cada dimensión a una pregunta de negocio.

Precisión

La precisión plantea si los datos reflejan lo que realmente pretenden describir.

La dirección de un cliente puede estar completa, ser válida en formato y, aun así, ser incorrecta. El precio de un producto puede estar presente en todas las tablas descendentes y, aun así, no coincidir con la fuente aprobada. Los fallos de precisión son costosos porque a menudo parecen estructuralmente saludables.

Pregunta de negocio: ¿Podemos confiar en que este valor representa la realidad?

Integridad

La integridad mide si los datos requeridos están presentes.

Esta es la dimensión con la que tropiezan primero los equipos porque los nulos son fáciles de contar y de explicar. Si un pedido no tiene dirección de envío, el almacén no puede enviarlo. Si a la historia clínica de un paciente le falta un atributo requerido, los flujos de atención y los registros de auditoría se rompen rápidamente.

Pregunta de negocio: ¿Tenemos todos los campos necesarios para ejecutar el proceso?

Consistencia

La consistencia verifica si el mismo hecho se mantiene alineado a través de sistemas y transformaciones.

Muchos problemas empresariales se ocultan en situaciones como esta. Una plataforma de facturación dice que un cliente está activo. El CRM dice que está inactivo. El almacén de datos une ambos y expone el último valor que llegó. Ninguno de esos registros es técnicamente nulo o inválido, pero el negocio no puede actuar con confianza ante estados contradictorios.

Pregunta de negocio: ¿Significa la misma entidad lo mismo en todas partes?

Mucha de la “confusión analítica” es en realidad un problema de consistencia disfrazado de semántica.

Oportunidad

La oportunidad se refiere a si los datos llegan cuando se necesitan para su uso.

Una tabla de ingresos diarios que llega a mediodía puede estar bien para la planificación mensual, pero ser inaceptable para una reunión operativa a las 8:30. La oportunidad es siempre contextual. Los datos tardíos se convierten en datos malos cuando se pierde la ventana de decisión.

Pregunta de negocio: ¿Estuvieron los datos disponibles dentro de la ventana de tiempo que requiere el proceso?

Validez

La validez comprueba si los valores cumplen con las reglas, dominios y formatos.

Una columna de fecha podría contener texto. Una columna de estado podría incluir valores fuera del conjunto aprobado. Un registro puede cumplir con la tipificación del esquema y, aun así, violar la lógica empresarial, como tener una fecha de finalización anterior a la fecha de inicio.

Pregunta de negocio: ¿Cumple este registro con las reglas que acordamos?

Unicidad

La unicidad plantea si los registros aparecen una sola vez allí donde deberían aparecer una sola vez.

Los clientes, facturas o transacciones duplicados generan fricciones visibles rápidamente. Los conteos se inflan, los de cruce multiplican las filas y los equipos terminan debatiendo si el problema está en el origen o en el modelo. Las comprobaciones de unicidad deben existir tanto a nivel de clave técnica como de entidad empresarial, porque no todos los duplicados comparten el mismo identificador.

Pregunta de negocio: ¿Estamos contando algo una sola vez, o muchas veces?

Este es el atajo operativo que utilizo:

Cómo calcular métricas clave de calidad de datos

Las definiciones solo ayudan si se pueden transformar en verificaciones repetibles. El punto de partida más confiable es calcular un conjunto pequeño de métricas en el almacén de datos, almacenar los resultados en una tabla de métricas y analizar su tendencia a lo largo del tiempo.

Comenzar con un contrato de métricas

Antes de escribir SQL, define cuatro cosas para cada métrica:

1. Alcance del dataset. ¿Qué tabla, partición o dominio del negocio estás midiendo?

2. Lógica. ¿Qué cuenta exactamente como aprobado o fallido?

3. Responsable. ¿Quién clasifica la alerta cuando la métrica se mueve?

4. Impacto de negocio. ¿Qué se rompe si esta métrica queda fuera de la tolerancia?

Sin ese contrato, los equipos terminan discutiendo después de que suena la alerta, no antes.

Una tabla básica de métricas suele verse así:

Fórmulas SQL que los equipos realmente usan

La Integridad es el punto de partida más claro. En el material de origen de Alation, la integridad se define como el porcentaje de valores no nulos en los campos requeridos frente a los recuentos totales de filas; y los datos de referencia en salud y finanzas muestran que los conjuntos de datos con menos del 97% de integridad generan un 40% más de hallazgos de Cumplimiento regulatorio en esos sectores según el artículo de Alation sobre métricas de calidad de datos.

Una fórmula básica es:

Integridad = (valores requeridos no nulos / filas totales) * 100

Ejemplo:

select
  current_date as metric_date,
  'orders' as dataset_name,
  'shipping_address_completeness' as metric_name,
  100.0 * sum(case when shipping_address is not null then 1 else 0 end) / count(*) as metric_value
from analytics.orders;

select
  current_date as metric_date,
  'orders' as dataset_name,
  'shipping_address_completeness' as metric_name,
  100.0 * sum(case when shipping_address is not null then 1 else 0 end) / count(*) as metric_value
from analytics.orders;

select
  current_date as metric_date,
  'orders' as dataset_name,
  'shipping_address_completeness' as metric_name,
  100.0 * sum(case when shipping_address is not null then 1 else 0 end) / count(*) as metric_value
from analytics.orders;

Para múltiples columnas requeridas, no promedies a ciegas. Calcula cada campo de forma independiente y calcula también una puntuación de integridad a nivel de registro si el flujo de trabajo depende de que todos los campos estén presentes.

select
  100.0 * sum(
    case
      when customer_id is not null
       and order_date is not null
       and shipping_address is not null
      then 1 else 0
    end
  ) / count(*) as record_completeness
from analytics.orders;

select
  100.0 * sum(
    case
      when customer_id is not null
       and order_date is not null
       and shipping_address is not null
      then 1 else 0
    end
  ) / count(*) as record_completeness
from analytics.orders;

select
  100.0 * sum(
    case
      when customer_id is not null
       and order_date is not null
       and shipping_address is not null
      then 1 else 0
    end
  ) / count(*) as record_completeness
from analytics.orders;

La Unicidad se mide generalmente como la proporción de filas que no violan una clave esperada.

Unicidad = 1 - (filas duplicadas / filas totales)

with keyed as (
  select
    order_id,
    count(*) as row_count
  from analytics.orders
  group by order_id
)
select
  100.0 * sum(case when row_count = 1 then 1 else 0 end) / count(*) as unique_key_rate
from keyed;

with keyed as (
  select
    order_id,
    count(*) as row_count
  from analytics.orders
  group by order_id
)
select
  100.0 * sum(case when row_count = 1 then 1 else 0 end) / count(*) as unique_key_rate
from keyed;

with keyed as (
  select
    order_id,
    count(*) as row_count
  from analytics.orders
  group by order_id
)
select
  100.0 * sum(case when row_count = 1 then 1 else 0 end) / count(*) as unique_key_rate
from keyed;

Si la entidad empresarial puede duplicarse bajo diferentes identificaciones técnicas, añade coincidencias aproximadas o basadas en reglas más adelante. Comienza primero con duplicados estrictos.

La Validez necesita reglas explícitas. No confíes únicamente en los tipos de esquemas.

select
  100.0 * sum(
    case
      when order_status in ('pending','paid','shipped','cancelled')
       and order_total >= 0
       and order_date <= current_date
      then 1 else 0
    end
  ) / count(*) as validity_rate
from analytics.orders;

select
  100.0 * sum(
    case
      when order_status in ('pending','paid','shipped','cancelled')
       and order_total >= 0
       and order_date <= current_date
      then 1 else 0
    end
  ) / count(*) as validity_rate
from analytics.orders;

select
  100.0 * sum(
    case
      when order_status in ('pending','paid','shipped','cancelled')
       and order_total >= 0
       and order_date <= current_date
      then 1 else 0
    end
  ) / count(*) as validity_rate
from analytics.orders;

Para modelos de investigación o de salud, los equipos a menudo necesitan bibliotecas de reglas específicas de su dominio. En ese ámbito, OMOPHub para validación de datos OMOP es una referencia relevante porque se centra en flujos de trabajo de validación estructurados en lugar de consejos de calidad genéricos.

La Oportunidad a menudo se expresa de mejor manera como un retraso en lugar de como un porcentaje.

select
  max(load_timestamp) as latest_load_timestamp,
  current_timestamp - max(load_timestamp) as freshness_lag
from analytics.orders;

select
  max(load_timestamp) as latest_load_timestamp,
  current_timestamp - max(load_timestamp) as freshness_lag
from analytics.orders;

select
  max(load_timestamp) as latest_load_timestamp,
  current_timestamp - max(load_timestamp) as freshness_lag
from analytics.orders;

Si necesitas un patrón de diseño de reglas de validez más allá de fragmentos SQL, este manual sobre qué significa la validación de datos en sistemas operativos es un gran complemento.

Los umbrales pertenecen a los casos de uso, no a las tablas

El error común es definir un solo umbral por dimensión y aplicarlo en todas partes. Eso falla rápidamente.

Una tabla de identidad de clientes merece reglas de integridad más estrictas que un archivo histórico de clickstream. El conjunto de características de un modelo de riesgo puede tolerar cierta información de enriquecimiento tardía, pero no cambios de esquema. Una extracción financiera puede aceptar pequeñas variaciones en el recuento de filas, pero ni un solo código de entidad legal inválido.

Mide la misma dimensión de manera diferente cuando el costo del fallo es distinto. Eso no es inconsistencia. Es diseño responsable.

El almacén de datos debe calcular la métrica. El proceso empresarial debe determinar el umbral.

De métricas brutas a insights accionables

Una métrica por sí sola es solo un número en una tabla. Los equipos necesitan una lógica de interpretación que la rodee. Esto implica umbrales, detección de anomalías, enrutamiento y el contexto suficiente para decidir si el problema es superficial u operativo.

Umbrales en los que la gente confiará

Los umbrales estáticos funcionan bien cuando la regla es clara y absoluta. Los campos requeridos, las enumeraciones aceptadas y las verificaciones de unicidad de claves suelen ajustarse a este modelo.

Los umbrales dinámicos ayudan cuando la métrica es naturalmente variable. El recuento de filas cambia con la estacionalidad. Los patrones de frescura varían según el cronograma. Los cambios en la distribución pueden ser normales en ciertos días y sospechosos en otros.

Una división práctica se ve de la siguiente manera:

• Usa umbrales estáticos para reglas de negocio y campos sensibles al Cumplimiento normativo.

• Usa líneas base aprendidas para el volumen, la frescura y las anomalías de comportamiento.

• Usa verificaciones de tendencia cuando el deterioro gradual importe más que una sola ejecución fallida.

Alertas que no enseñan a los equipos a ignorar las alertas

El sistema de alertas falla cuando cada desviación notifica a alguien.

Las buenas alertas de calidad de datos incluyen contexto la primera vez que se activan. El responsable debe ver el conjunto de datos, la métrica con fallos, la tendencia reciente, el cambio sospechoso aguas arriba y de qué dashboards, modelos o procesos operativos depende ese activo. Si todo lo que dice la alerta es “disminuyó la integridad”, el encargado de responder aún tiene que realizar el diagnóstico inicial de manera manual.

He visto que una regla simple funciona muy bien en equipos maduros:

La forma más rápida de perder la confianza en un sistema de monitoreo es enviar alertas técnicas sin contexto operativo.

Muestreo y establecimiento de líneas base en entornos desordenados

No todas las tablas merecen la misma profundidad de monitoreo. Algunas son críticas, otras intermedias y algunas descartables.

Para una cobertura amplia, comienza con señales de bajo costo. El recuento de filas, la frescura, los patrones de nulos, los cambios de esquema y las comprobaciones de duplicados revelan una gran parte de los fallos reales. Agrega validaciones a nivel de registro cuando la lógica del negocio sea estricta. Realiza muestreos cuando el costo sea un factor, pero hazlo intencionalmente. Por ejemplo, valida cargas completas en conjuntos de datos esenciales (gold) y perfila muestras representativas en modelos de menor prioridad.

El establecimiento de líneas base mediante IA es de mayor ayuda cuando el entorno es demasiado ruidoso para límites ajustados manualmente. Esto es especialmente útil en organizaciones con múltiples fuentes y patrones de actualización desiguales. El objetivo no es eliminar el criterio humano. Se trata de reservar la atención del personal para aquellas desviaciones que se ven sustancialmente distintas del comportamiento normal del sistema.

Operacionalización de la calidad de datos: Un ejemplo de dashboard de KPI

Un buen dashboard no es un conjunto de gráficos de galería. Es una interfaz de trabajo para la respuesta ante incidentes, revisión de tendencias y propiedad de los datos.

Comienza la página con un resumen de salud que responda de inmediato tres preguntas: qué está fallando ahora, qué está empeorando y qué requiere un responsable hoy mismo.

Qué muestra el dashboard a simple vista

La primera fila suele presentar la perspectiva operativa:

• Incidentes abiertos clasificados por severidad para que los ingenieros de guardia sepan por dónde empezar

• Estado de frescura de los datasets más críticos para visibilizar cargas rezagadas o ausentes

• Historial de cambios de esquema para columnas agregadas, eliminadas o con cambios de tipo

• Métricas principales con mayor deterioro dentro de una ventana de revisión reciente

Luego, añade la vista del analista. Las líneas de tendencia para la integridad, tasas de duplicados, fallos de validez y desfases de actualización ayudan a los equipos a distinguir anomalías puntuales de un declive continuo. Los paneles de posiciones también son útiles. Una vista de “tablas más inestables” a menudo promueve una mejor priorización que un extenso registro de problemas desorganizado.

Una métrica merece especial atención: el tiempo de inactividad de datos (data downtime). Según la discusión de Monte Carlo sobre métricas de calidad de datos, las organizaciones que realizan un seguimiento del tiempo de inactividad de los datos descubren que el 68% de los incidentes se originan por desviaciones silenciosas del esquema (schema drift) o violaciones de frescura, y que dichos incidentes pueden provocar una reducción del 15 al 25% en la exactitud del modelo descendente en un plazo de 48 horas. Por ello, el dashboard debe mostrar no solo si falló una validación, sino también cuánto tiempo lleva el dataset afectado sin ser confiable.

Qué hace cada equipo con él

Los ingenieros de datos necesitan una sección técnica. Les interesan las comprobaciones fallidas, la duración del incidente, el linaje y las probables causas aguas arriba.

Los ingenieros de analítica y desarrolladores de BI necesitan una sección semántica. Quieren saber si un modelo confiable todavía cumple con las expectativas de las reglas de negocio y si los dashboards deben anotarse, pausarse o reconstruirse.

Los responsables corporativos y de governance requieren una sección de riesgo. Desean identificar qué dominios fallan de forma recurrente, qué controles son débiles y si los problemas se resuelven dentro de los plazos acordados.

Una breve demostración del producto ayuda a concretar ese modelo operativo:

Los mejores dashboards de KPI no se limitan a luces rojas y verdes. Muestran la tendencia, el radio de afectación y el responsable. Esto es lo que convierte al monitoreo en un sistema que la gente utiliza en la práctica bajo presión, y no solo en presentaciones de prueba.

Desafíos avanzados sin respuesta en las métricas estándar

La mayoría de las guías se detienen en las seis dimensiones clásicas. En producción, es ahí donde comienzan las preguntas más difíciles.

Microerrores que se ocultan dentro de buenos promedios

Las métricas agregadas pueden lucir bien mientras un pequeño defecto genera daños desproporcionados.

Unas pocas filas erróneas en una tabla de clientes pueden desviar pedidos de alto valor de manera incorrecta. Un conjunto reducido de registros mal formados puede averiar una sola variable descendente utilizada por un modelo. La integridad, validez y unicidad general pueden seguir pareciendo aceptables porque la puntuación agregada diluye el impacto real.

Ese problema se refleja también en los debates de los especialistas. Un hilo de ingeniería de datos sobre errores de microimpacto describe lo complejo que resulta cuantificar el impacto de fallos que afectan solo a unas pocas filas pero que, aun así, desencadenan problemas graves aguas abajo.

La solución no es calcular otro promedio. Consiste en la segmentación y en comprobaciones conscientes del impacto.

Utiliza patrones como los siguientes:

• Monitoreo de campos críticos para columnas donde un fallo detiene por completo un flujo de trabajo, incluso si afecta solo a un puñado de filas

• Métricas basadas en agrupaciones (slices) por región, canal, línea de producto o nivel de cliente para que un fallo localizado no pase desapercibido dentro de un porcentaje de aprobación global

• Validación sensible a rutas que prueba de forma prioritaria los registros con mayor probabilidad de alcanzar procesos regulados, financieros o críticos para modelos de decisión

• Métricas de síntomas de negocio tales como transacciones rechazadas, registros huérfanos que no se pueden cruzar o pedidos bloqueados para su distribución

Una métrica debe reflejar el costo de estar equivocado, no solo el conteo de filas incorrectas.

Por qué una puntuación única es más difícil de lo que parece

Los líderes corporativos suelen pedir una cifra única para entender la situación. Es una solicitud razonable. Quieren ver tendencias, comparar áreas y definir prioridades sin necesidad de interpretar decenas de gráficos.

El problema radica en la ponderación.

Una tabla de marketing desactualizada y una fila de pago duplicada no deben influir de igual manera en una nota global. Un fallo de integridad en un archivo histórico de consulta no asume el mismo riesgo que un error de validez en el dominio de identidad de clientes. Asimismo, los pesos estáticos envejecen de forma deficiente; los procesos del negocio cambian, los datos de entrada para los modelos evolucionan y lo que antes era una advertencia leve puede transformarse en un bloqueo crítico.

Por lo tanto, un Score de Calidad de Datos verdaderamente útil debe ser contextual. Necesita pesos adaptados a cada dominio, multiplicadores de impacto en el negocio y recalibraciones periódicas. También debe diferenciar el estado actual descriptivo del riesgo predictivo futuro. De lo contrario, se obtiene un número vistoso adecuado para juntas directivas que ayuda muy poco a los administradores del día a día.

Un modelo práctico consiste en calificar en tres niveles distintos:

Esto tampoco resolverá todas las situaciones posibles. No obstante, evita el peor error de todos: simular que una sola métrica universal puede representar cada posible caso de uso con la misma eficacia.

Cómo las plataformas de Data Observability automatizan las métricas de calidad

Las comprobaciones manuales en SQL son una excelente base para empezar. Sin embargo, resultan insuficientes cuando debes lidiar con numerosas fuentes de datos, esquemas que evolucionan constantemente y equipos con necesidades de monitoreo continuo en lugar de revisiones semanales.

Ahí es donde las plataformas de Data Observability se vuelven indispensables. Automatizan la recolección de métricas, establecen líneas base de comportamiento normal, detectan anomalías, monitorean la frescura y enrutan problemas con el contexto necesario para un diagnóstico veloz. También reducen la carga de mantenimiento inherente a las reglas codificadas a mano y dispersas en tareas de Airflow, pruebas de dbt, procedimientos de almacenes de datos y correcciones en la capa de BI.

Las plataformas más potentes combinan diferentes métodos de control:

• Validaciones estructuradas para reglas del negocio indispensables

• Detección de anomalías ante desviaciones que nadie había modelado de forma explícita

• Monitoreo de oportunidad para cargas tardías o incompletas

• Seguimiento de esquemas para identificar cambios estructurales que quebrantan de imprevisto las premisas descendentes

• Análisis histórico para señalar deterioros silenciosos o progresivos

Si estás analizando soluciones en esta categoría, un excelente punto de partida es este artículo sobre por qué la Data Observability es crucial para la gestión de datos moderna. Un ejemplo destacado en este sector es digna, que integra el cálculo de métricas en la base de datos, detección de anomalías, monitoreo de frescura, validaciones a nivel de registro y seguimiento de esquemas dentro de entornos operados de forma directa por el cliente.

El fin práctico no consiste en generar más dashboards, sino en tener menos sorpresas, identificar de forma más ágil la causa raíz de las fallas y clarificar responsabilidades para cuando los datos dejen de ser confiables.

Si tu equipo busca transicionar de comprobaciones puntuales a una práctica de calidad de datos operativa y monitoreada, vale la pena evaluar digna. Ha sido desarrollada para equipos que precisan validaciones estructuradas, detección de anomalías operacionales, monitoreo de oportunidad y seguimiento del esquema sin necesidad de transferir datos de producción fuera de su propia infraestructura física.