El problema de la preparación de datos en la IA empresarial

Los programas de IA empresarial rara vez se frenan porque un equipo no pueda invocar un modelo. Se frenan porque la organización no sabe qué significan sus datos, si están actualizados, qué registro manda, quién puede actuar o cómo medir el resultado. Resolvemos esas preguntas antes de elegir modelo con seis controles: procedencia, vigencia, duplicados, línea base, derechos de acción y medición de resultados.

El modelo no suele ser la primera restricción

El modelo es la parte visible. La parte operativa incluye fuentes, identidades, definiciones, permisos, colas de revisión, escrituras y feedback. Un modelo potente sobre datos poco fiables genera incertidumbre elocuente; uno modesto dentro de un sistema decisorio claro puede aportar valor fiable.

RAND identifica datos inadecuados, infraestructura débil y desalineación con el problema de negocio entre las causas recurrentes de fracaso. El capítulo Economy del Stanford AI Index 2026 refleja una adopción rápida, pero adoptar no equivale a obtener retorno operativo medible. La preparación se prueba contra una decisión y su flujo de trabajo.

Empezar con un contrato de decisión

Definimos decisión recurrente, responsable, acciones permitidas, plazo, evidencia y outcome. «Usar IA para datos de producto» no es un contrato; «recomendar atributos ausentes sin sobrescribir registros aprobados» sí. Las consultas exactas, umbrales y conciliaciones siguen siendo reglas; la IA se reserva para entradas ambiguas o no estructuradas.

Control 1: Procedencia

Cada campo conserva fuente, hora de extracción, clave, transformación y correcciones. El linaje debe poder consultarse y toda recomendación apuntar a la evidencia. Un flujo reproducible de extracción registra petición, respuesta y error para no confundir ausencia con cero. Se supera el control cuando otro revisor puede reconstruir el resultado.

Control 2: Vigencia

La vigencia es la edad máxima aceptable para una decisión. Distinguimos hora del evento, registro en origen y consumo. Un pipeline correcto no garantiza datos actuales. El presupuesto de vigencia determina aviso, abstención, fallback o bloqueo. Una capa fiable de almacén e ingesta forma parte del producto decisorio.

Control 3: Duplicados e identidad

Definimos cuándo dos registros son la misma entidad y en qué ámbito. Conservamos identificadores brutos y canónicos, método y confianza; las claves deterministas prevalecen y los matches inciertos se revisan. Medimos duplicados por fuente, hacemos merges reversibles y monitorizamos colisiones. La propiedad completa del dato operativo permite conciliar y reproducir cuando cambian las interfaces.

Control 4: Líneas base

Sin baseline, la IA es una demo. Antes del cambio medimos error, ciclo, esfuerzo, cobertura, excepciones y outcome. La evidencia confidencial usa Baseline = 100; los absolutos permanecen en el entorno autorizado. Denominador, población y ventana se mantienen, con segmentos y cambios simultáneos documentados. La baseline debe reproducirse desde datos y definiciones versionados.

Control 5: Derechos de acción

Acceder no autoriza a actuar. Para cada acción mapeamos sistema de registro, actor, aprobación, límites, separación de funciones y rollback. Empezamos en lectura o recomendación, seguimos con dry run y habilitamos escrituras aprobadas tras probar controles. Mínimo privilegio, separación read/write, token de aprobación, idempotencia e ID de correlación hacen concreto el control humano.

Control 6: Medición de resultados

Conectamos entrada → recomendación → revisión → acción → resultado mediante IDs estables, incluidos abstenciones y rechazos. El plan fija outcome, guardrails y cadencia: gravedad, overrides, reclamaciones, infracciones, latencia y trabajo desplazado. Reducir una cola creando otra oculta no mejora las operaciones.

Una ficha práctica

Estado	Significado	Consecuencia
Unknown	No hay evidencia	Sin piloto con claims operativos
Defined	Existen dueño, definición y prueba	Solo evaluación offline
Verified	Prueba superada con datos representativos	Piloto controlado
Monitored	Existen umbral y respuesta	Escalado acotado posible

El control más débil capaz de causar daño limita el release. Para builders es un backlog de pruebas; para ejecutivos, un filtro de cartera.

Ordenar la inversión antes del modelo

Resolvemos identidad antes que capacidad, contexto antes que predicción, derechos antes que agentes y baseline antes que cambios. Después comparamos éxito, calibración, latencia, privacidad y coste. Como fuentes, IDs y permisos cambian, cada control requiere dueño, monitorización y respuesta.

La pregunta ejecutiva

No es «¿Qué modelo usamos?», sino «Muéstrennos la cadena desde la evidencia hasta la acción autorizada y el resultado medido». Si es reproducible, el programa aprende; si no, más capacidad acelera un proceso sin verificar.