Por qué los datos de aspecto limpio siguen rompiendo la IA: la inconsistencia semántica

«Basura entra, basura sale» es una de las frases más repetidas en ciencia de datos, y es cierta: si entrenas un modelo con datos malos, no esperes buenos resultados. El problema es que la frase es tan conocida que oculta un caso más traicionero. ¿Y si los datos no son basura? ¿Y si parecen limpios? Las columnas están llenas, los formatos son válidos, no hay duplicados evidentes, el pipeline se ejecuta, los dashboards se ven normales y las comprobaciones de calidad de datos pasan, y aun así el sistema de IA toma decisiones poco fiables.

Eso es la inconsistencia de datos en acción. Los valores no son necesariamente erróneos. Simplemente, los mismos datos significan cosas distintas en sitios distintos.

Los datos limpios también pueden engañar

Tomemos un campo que toda empresa tiene en alguna versión:

customer_status

En el CRM, sus valores podrían significar esto:

Active = Customer currently purchasing
Inactive = Customer hasn't purchased recently

Facturación lee las mismas palabras de otra manera:

Active = Account is financially open
Inactive = Account is closed

Y soporte tiene una tercera interpretación:

Active = Customer currently has an open support relationship
Inactive = No active support case

Cada sistema puede tener valores válidos, formato coherente, registros completos y ningún error visible, así que una revisión tradicional de calidad de datos no encuentra nada. Pero si unes los conjuntos de datos sin aclarar qué significan las palabras, la IA recibe tres definiciones de «active». Los datos no están sucios. Su semántica es inconsistente, y eso es mucho más difícil de detectar.

Deriva semántica

La consistencia no es solo cuestión de formato. También importa si los valores significan lo mismo. Veamos «revenue» en tres lugares. Un sistema lo define así:

System A:
Revenue = Invoiced amount

Otros dos sistemas difieren:

System B:
Revenue = Collected amountSystem C:
Revenue = Contract value

El nombre del campo es idéntico en todas partes, los números son válidos, los esquemas son válidos y los pipelines funcionan. Aun así, combinarlos produce un conjunto de datos engañoso. Un modelo no puede saber que tres nombres de campo idénticos corresponden a tres definiciones de negocio. Alguien tiene que decírselo.

Los significados cambian con el tiempo

Las definiciones también se desplazan. Supongamos que una empresa guarda un segmento en este campo:

customer_segment

De 2022 a 2024 los valores son:

Enterprise
Mid-Market
SMB

Luego el negocio cambia su estrategia de segmentación y, a partir de 2025, los valores pasan a ser:

Strategic
Growth
Core

La base de datos sigue teniendo un solo campo, el pipeline sigue funcionando y el tipo de dato no ha cambiado. El modelo ve algo así:

2022 → Enterprise
2023 → Enterprise
2024 → Enterprise
2025 → Strategic
2026 → Strategic

Técnicamente no hay nada roto, pero el significado se ha desplazado. Si el modelo trata las categorías antiguas como directamente comparables con las nuevas, puede aprender relaciones que ya no describen el negocio. Es una de las razones por las que el tiempo tiene que formar parte de la calidad de datos.

Consistencia estructural frente a semántica

Es fácil confundirlas, así que conviene separarlas.

La consistencia estructural significa que los datos siguen las reglas técnicas esperadas:

customer_id → string
revenue → decimal
created_at → timestamp
status → allowed values

La consistencia semántica significa que un campo tiene el mismo significado de negocio allí donde se use. Por ejemplo, este campo:

revenue

debería significar lo mismo en finanzas, ventas, analítica, el CRM y el data warehouse. Un pipeline puede cumplir el primer requisito y fallar por completo en el segundo, y ahí es donde muchos sistemas de IA se meten en problemas.

Por qué las comprobaciones habituales no lo detectan

La mayoría de los pipelines detectan bien los fallos técnicos:

NULL values
Duplicate rows
Invalid data types
Missing columns
Unexpected formats
Broken joins
Out-of-range values

Esas comprobaciones son útiles. Pero imagina una tabla con los clientes 101, 102 y 103, todos marcados como Active, con ingresos de 50000, 72000 y 31000. Todo parece razonable. Ahora supongamos que Active significa un cliente que compra en el sistema A, una cuenta financieramente abierta en el sistema B y un cliente al que soporte atiende actualmente en el sistema C. Una regla de validación estándar seguirá pasando, porque los valores no son inválidos. Lo es su significado.

La IA lo empeora

Donde más importa es en el machine learning. El software clásico suele tener reglas de negocio explícitas, como esta:

if customer_status == "Active":
    allow_action()

Cualquiera puede leer esa regla y ver qué espera. Los sistemas de machine learning, en cambio, aprenden relaciones a partir de datos históricos. Si los datos de entrenamiento mezclan definiciones, el modelo puede absorber las inconsistencias como si fueran patrones reales:

Historical Data
      ↓
Different Business Definitions
      ↓
Combined Dataset
      ↓
Model Training
      ↓
Learned Relationships
      ↓
Predictions

El modelo no sabe necesariamente qué definición es la autorizada. Aprende de lo que recibe.

RAG sufre el mismo mal

No se limita al ML clásico. Imagina tres documentos de una empresa. El manual de ventas dice que un lead cualificado es un prospecto que cumple los criterios BANT. La documentación de marketing dice que un lead cualificado ha interactuado con al menos tres campañas. La documentación del CRM dice que es un lead que un comercial ha marcado manualmente como cualificado.

Un empleado pregunta a un asistente interno qué hace que un lead esté cualificado. Es muy posible que la búsqueda encuentre los tres documentos, y el modelo de lenguaje puede redactar una respuesta fluida e incluso citar las fuentes. El problema de fondo sigue ahí: la organización no tiene una definición única. La IA no está necesariamente alucinando. Está reflejando una base de conocimiento inconsistente.

Problemas que no parecen averías

Por eso «basura entra, basura sale» se queda corto para la IA moderna. La basura es evidente, y la inconsistencia puede ser invisible. Algunas de sus formas:

El mismo nombre con significados distintos. Esta etiqueta:

"Revenue"

puede ser ingresos facturados en un sistema e ingresos cobrados en otro.

El mismo valor en contextos distintos. Este:

"Active"

puede significar un cliente activo, una cuenta activa o una suscripción activa.

La misma métrica calculada de forma distinta. Esta:

"Churn"

puede calcularla un equipo de forma mensual y otro de forma anual.

La misma marca de tiempo en zonas horarias distintas. Este valor:

2026-08-20 10:00

puede ser hora local en un sistema y UTC en otro.

El mismo cliente con identidades distintas:

Customer ID: 10482
Account ID: C10482
External ID: 10482-IN

Ninguno de estos registros es necesariamente malo. Son representaciones inconsistentes de la realidad del negocio.

Haz otra pregunta

En lugar de preguntar solo si los datos están limpios, los equipos de IA deberían preguntar si significan lo mismo en todos los lugares donde se usan. Eso obliga a indagar: quién es responsable de cada definición, qué reglas de negocio se aplican, cómo han cambiado los significados con los años, cómo se calculan las métricas y desde qué sistema de origen, qué significan los términos y las unidades, cómo se registran las marcas de tiempo y cómo se corresponden las identidades entre sistemas. Esto se parece más a la calidad semántica de los datos que a la limpieza habitual.

Escribe un contrato semántico

Un paso práctico es crear un contrato semántico para los campos críticos. Empieza por nombrar el campo:

Field:
customer_status

Después registra su significado y sus valores permitidos:

Business Definition:
Current commercial relationship with the customer.Allowed Values:
active
inactive
prospectOwner:
Customer OperationsSource of Truth:
CRMEffective From:
2026-01-01Rules:
"active" requires an active commercial relationship.
"prospect" cannot have completed customer status.

Ahora los sistemas de IA posteriores tienen una referencia explícita. Si otro sistema usa esta definición:

active = account has an open invoice

tienes un conflicto, y puedes resolverlo antes de que llegue al modelo.

Trata las definiciones como APIs

Los ingenieros ya saben lo valiosos que son los contratos entre sistemas. Cuando una API promete esto:

{
  "customer_id": "string",
  "status": "active | inactive"
}

los consumidores posteriores dependen de ello. Con los datos debería pasar lo mismo. Para los campos críticos para la IA, detalla toda la cadena:

Field
↓
Type
↓
Allowed Values
↓
Business Meaning
↓
Owner
↓
Source of Truth
↓
Effective Date
↓
Change History

Así los supuestos semánticos se vuelven visibles, y los supuestos visibles son más fáciles de comprobar.

Añade comprobaciones de significado al pipeline

Un pipeline maduro no solo pregunta si la ejecución tuvo éxito, sino también si cambió el significado de los datos. Una capa de validación conceptual podría ser así:

Incoming Data
      ↓
Schema Validation
      ↓
Data Quality Checks
      ↓
Semantic Validation
      ↓
Business Rule Validation
      ↓
AI Readiness Check
      ↓
Model / RAG Pipeline

La validación de esquema detecta «la columna ha desaparecido». La validación semántica detecta «la columna sigue ahí, pero su significado de negocio ha cambiado». Son clases de problemas muy distintas.

Monitoriza definiciones, no solo valores

Supongamos que un pipeline sigue el valor medio de pedido y el dashboard muestra:

Average Order Value
₹4,850

Nada parece raro. Luego la empresa redefine la métrica: antes era el valor bruto del pedido y ahora es el importe neto una vez descontados descuentos y devoluciones. La cifra puede moverse de forma tan gradual que no salte ninguna alerta técnica, pero el modelo que la consume recibe ahora un concepto distinto. La monitorización tiene que pasar de «¿cambió el valor?» a «¿cambió el significado?».

Los agentes lo notan más

Los agentes de IA hablan cada vez más con varias herramientas y fuentes de datos a la vez:

Agent
 ├── CRM
 ├── Billing
 ├── Analytics
 ├── Knowledge Base
 └── Support System

El agente puede preguntar a cada sistema por el mismo cliente y, si las definiciones son inconsistentes, recibe respuestas contradictorias. Por ejemplo, el CRM dice esto:

CRM:
Customer = Active

Mientras que facturación y soporte informan de otra cosa:

Billing:
Account = DelinquentSupport:
Relationship = Closed

El agente tiene ahora tres respuestas técnicamente válidas. ¿A cuál debe creer? Sin reglas semánticas, incluso un modelo muy capaz tiene que adivinar entre significados de negocio contradictorios.

Un diccionario de datos debería servir para algo

Muchas organizaciones mantienen un diccionario de datos, y a menudo acaba siendo documentación estática que nadie consulta. Para la IA, las definiciones clave deberían convertirse en controles operativos:

Definition
    ↓
Data Contract
    ↓
Validation Rule
    ↓
Pipeline Check
    ↓
AI Readiness

Cuando una definición cambia, hay que revisar los sistemas posteriores que dependen de ella. Así el gobierno de datos pasa de ser documentación a ser ingeniería.

Qué comprobar

En los conjuntos de datos críticos para la IA, comprueba al menos cinco tipos de consistencia:

1. Estructural: ¿son coherentes los campos y los tipos?
2. De valores: ¿se representan los valores de la misma manera?
3. Semántica: ¿significa un campo lo mismo en todas partes?
4. Temporal: ¿ha cambiado la definición con el tiempo?
5. Entre sistemas: ¿coinciden los distintos sistemas en la entidad o métrica de negocio subyacente?

Eso da una visión más realista de la calidad de los datos.

Un modelo mental mejor

La imagen habitual es esta:

Bad Data → Bad AI

Una más precisa incluye un paso adicional:

Bad Data
    ↓
Inconsistent Data
    ↓
Ambiguous Business Meaning
    ↓
Unreliable AI Context
    ↓
Unreliable AI Output

Y a veces el camino es este:

Clean-looking Data
        ↓
Hidden Semantic Differences
        ↓
Model Learns False Relationships
        ↓
Production Reliability Degrades

El peligroso es el segundo camino, porque el pipeline parece sano todo el tiempo.

A veces lo difícil es ponerse de acuerdo

Hay una posibilidad incómoda: puede que la organización no tenga un problema de datos, sino un problema de definiciones. Finanzas define al cliente de una manera, ventas de otra, marketing de una tercera y operaciones tiene su propia interpretación. Cada uno cree que su versión es la correcta, y se espera que la IA las concilie. No puede, al menos no de forma fiable, sin reglas de negocio explícitas. Antes de preguntar cómo limpiar los datos, puede ser más útil preguntar si el negocio es capaz de ponerse de acuerdo sobre lo que significan.

Mira antes del modelo

Cuando un sistema de IA da resultados poco fiables, el primer instinto es culpar al modelo: revisar el prompt, cambiar de modelo, ajustar parámetros, añadir recuperación, ampliar el contexto. A veces el modelo simplemente aprende de una imagen inconsistente del negocio. Ninguna actualización resuelve un concepto de negocio sin definir. Si tres sistemas no se ponen de acuerdo sobre qué es un cliente activo, un modelo más potente no cerrará esa brecha de gobierno. Solo dará una respuesta más convincente a una pregunta ambigua.

En resumen

«Basura entra, basura sale» es un buen consejo, pero ya no basta. La IA moderna depende de un significado coherente además de valores limpios. El conjunto de datos más arriesgado no siempre es el que está lleno de errores evidentes. Puede ser uno en el que todas las columnas están presentes, todos los valores superan la inspección, todos los trabajos terminan y todos los dashboards siguen en verde, mientras distintos rincones de la organización atribuyen en silencio significados diferentes a un mismo campo. Ese tipo de problema supera todas las comprobaciones técnicas y aun así perjudica la fiabilidad de la IA. Así que, antes de preguntar si tus datos están limpios, pregunta si todos están de acuerdo en lo que significan.