Qué te llevarás de esta lectura
- Un contrato incluye significado y responsabilidades, además de nombres y tipos.
- La calidad debe comprobarse contra el uso previsto de los datos.
- Versiona cambios incompatibles y prueba a los consumidores antes de migrar.
- Usa datos autorizados y trazables como base para sistemas de IA.
El esquema correcto puede responder una pregunta equivocada
Un asistente puede consultar una tabla de ventas con tipos válidos y entregar una respuesta equivocada si confunde pedidos creados con ventas cobradas. También puede sumar importes de monedas distintas o presentar datos de ayer como actuales. El fallo no siempre está en el modelo: puede estar en un significado que nadie documentó.
Para una arquitectura orientada a IA, el contrato debe explicar qué representa cada registro y qué preguntas permite responder. Esta edición de octubre de 2026 propone un enfoque de preparación de datos; no presenta una nueva certificación ni una regla universal para todos los asistentes.
Empieza con un contrato pequeño y utilizable
| Elemento | Ejemplo para ventas cobradas |
|---|---|
| Identidad y versión | sales_collected, contrato 1.0 |
| Granularidad | Una fila por pago confirmado; no por pedido |
| Campos y significado | payment_id, amount, currency, paid_at |
| Tiempo | paid_at en UTC; horario de actualización acordado |
| Calidad | Identificador único y moneda explícita; importe requerido |
| Responsable | Equipo de pagos y contacto operativo designado |
| Acceso y retención | Roles autorizados y plazo definido por política |
El ejemplo es sintético. Su valor no está en el nombre del archivo que lo describe, sino en que productor y consumidor acuerden las mismas reglas. Guarda el contrato junto con su historial de cambios y conecta cada regla con una comprobación ejecutable o una revisión explícita.
Define qué se rechaza, qué alerta y qué puede esperar
No todos los incumplimientos requieren la misma respuesta. Una clave de pago duplicada puede bloquear la publicación; una descripción opcional ausente puede generar una advertencia. Una fuente retrasada necesita una regla de frescura y una decisión sobre si el consumidor recibe datos anteriores, una indicación de antigüedad o ninguna respuesta.
La documentación de Google Cloud distingue comprobaciones por fila, con umbrales de aprobación, de reglas agregadas evaluadas sobre el conjunto. [1] Esa separación sirve para diseñar controles propios: “cada pago tiene moneda” y “el total del lote coincide con el sistema de origen” validan cosas diferentes.
- Completitud: campos obligatorios presentes y nulos tratados explícitamente.
- Unicidad: claves acordadas sin duplicados inesperados.
- Validez: tipos, rangos y valores permitidos.
- Reconciliación: conteos y totales por moneda comparados con el origen.
- Frescura: tiempo del evento y tiempo de actualización claramente separados.
Evita convertir un umbral arbitrario en una promesa comercial. Negocia tolerancias con el consumidor y ensaya un caso que deba fallar. Una regla que nunca ha sido probada con una infracción conocida ofrece poca evidencia de protección.
Un cambio de significado también rompe el contrato
Renombrar una columna es un cambio visible. Modificar una zona horaria, una unidad o la definición de “activo” puede ser más peligroso porque el esquema permanece igual. Clasifica los cambios según su impacto real: añadir un campo opcional puede ser compatible, pero solo si los consumidores toleran campos adicionales.
Para un cambio incompatible, publica una nueva versión, identifica consumidores, comunica el plazo y ejecuta pruebas de comparación. Mantén el contrato anterior durante una transición acordada cuando sea viable. Define quién puede aprobar la migración y cómo volver a una versión anterior sin perder eventos nuevos.
El contrato acompaña los datos que usa la IA
Si un sistema de IA consulta datos o los recupera desde un índice, conserva procedencia, fecha efectiva y versión del contrato junto con la información relevante. Restringe el acceso al contexto autorizado y aplica retención también a extractos e índices derivados. Obtener una copia no elimina las obligaciones sobre el dato original.
Evalúa preguntas concretas: ¿qué periodo cubre la respuesta?, ¿qué moneda usa?, ¿hay pagos cancelados?, ¿el usuario tiene permiso? Las salidas estructuradas pueden ayudar a organizar respuestas, pero no garantizan su corrección semántica. [2] Cuando falte evidencia o el dato esté vencido, el sistema debe expresar esa limitación según su política.
Del contrato al flujo operable con Dova
En Dova, un Mapping puede representar transformaciones y reglas de calidad documentadas. La referencia describe controles de campos obligatorios, tipos, patrones, rangos y valores permitidos; sus umbrales no equivalen automáticamente a una salida de cuarentena. [3] Comprueba qué acción ejecuta realmente tu diseño cuando una regla falla.
Vincula la versión del contrato con la del Mapping y registra la Session y el Workflow usados en el ensayo. Verifica columnas, valores y conteos de forma independiente. La guía de operación recomienda distinguir una ejecución terminada de un resultado correcto. [4] El contrato sigue requiriendo responsables y acuerdos fuera del canvas.
Empieza por un conjunto de datos de alto valor y pocos consumidores. Mide incidencias de contrato, tiempo de detección, tiempo de recuperación y consumidores migrados. Amplía el método cuando el equipo pueda explicar cómo actúa ante un incumplimiento, no solo mostrar un catálogo de documentos.
Preguntas que vale la pena hacer
¿Un contrato de datos es lo mismo que un esquema?
No. El esquema describe estructura; el contrato añade significado, granularidad, calidad, frescura, acceso, responsabilidades y manejo de cambios.
¿Necesito contratar una herramienta nueva?
No necesariamente. Puedes comenzar con una definición versionada, responsables claros y comprobaciones en el pipeline. El catálogo o la automatización deben resolver necesidades reales.
¿Un contrato garantiza respuestas correctas de la IA?
No. Reduce ambigüedades y aporta controles verificables, pero también necesitas evaluar consultas, permisos, recuperación de información y respuestas del modelo.
Dónde encaja Dova
Una integración gobernada puede hacer visibles responsabilidades y ejecución. Revisa la documentación de Dova sobre mappings, workflows y monitoreo, y define las reglas de calidad de negocio que necesita implementar tu equipo.
Fuentes y lecturas recomendadas
- About auto data qualityGoogle Cloud Documentation · Consultado
Row-level thresholds, aggregate checks and explicit quality rules; no October 2026 product announcement is claimed.
- Structured model outputsOpenAI · Consultado
Structured response shape does not establish semantic truth.
- Transformaciones y reglas de calidadCloudata · Dova Docs · Consultado
Documented required-field, type, pattern, range and allowed-value checks and their limits.
- Seguridad y operación: ejecutar, recuperar y retirar recursosCloudata · Dova Docs · Consultado
Execution evidence, authorized context and independent output validation.
Guía práctica de la edición octubre 2026. Las fuentes respaldan los principios técnicos; los ejemplos son ilustrativos, no anuncios de productos ni resultados de clientes.