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

Los programas de IA empresarial rara vez se estancan porque un equipo no pueda invocar un modelo. Se estancan porque la organización no puede determinar qué significan sus datos, si están actualizados, qué registro es la referencia autorizada, quién puede actuar a partir de una salida o cómo se medirá un resultado. Utilizamos un marco de preparación de seis componentes para resolver estas preguntas antes de seleccionar un modelo: procedencia, grado de actualización de los datos, duplicados, líneas de base, permisos para actuar y medición de resultados.

El modelo no suele ser la primera restricción

La parte visible de un sistema de IA es el modelo. La parte operativa es todo lo que lo rodea: sistemas de origen, identificadores, definiciones de negocio, permisos, colas de revisión, mecanismos de escritura y retroalimentación. Un modelo potente que trabaja con datos operativos poco fiables produce incertidumbre expresada con fluidez. Un modelo modesto integrado en un sistema de decisión bien definido puede generar valor de forma fiable.

Esta distinción importa a la dirección porque es fácil presupuestar y anunciar la adquisición de un modelo. La preparación de los datos se reparte entre distintas áreas: operaciones conoce la realidad de los procesos; tecnología se encarga de los sistemas; finanzas define conceptos importantes; las áreas jurídica y de seguridad limitan los usos; y los equipos de negocio controlan muchas de las acciones que generan resultados. Ningún equipo puede declarar por sí solo que los datos están preparados.

La evidencia respalda abordar esta cuestión como un problema operativo. La investigación de RAND sobre el fracaso de proyectos de IA, basada en entrevistas con profesionales experimentados, identifica datos inadecuados, infraestructura débil y falta de alineación con el problema de negocio entre los patrones recurrentes de fracaso. También señala que los conjuntos de datos conservados por cumplimiento normativo o registro (logging) pueden no conservar el contexto necesario para un nuevo propósito analítico. El capítulo sobre economía del Stanford AI Index 2026 documenta una rápida adopción e inversión empresarial, pero la adopción no equivale a un retorno operativo medible. En conjunto, estos hallazgos llevan a una conclusión práctica: la preparación debe comprobarse en relación con una decisión y un flujo de trabajo, no deducirse del volumen de datos ni del entusiasmo de la dirección.

Empezar con un contrato de decisión

Antes de examinar las tablas, redactamos un breve contrato de decisión. Identifica la decisión recurrente, quién es responsable de tomarla, las acciones permitidas, el tiempo disponible, la evidencia necesaria y el resultado de negocio que se observará. «Usar IA para los datos de producto» no es un contrato. «Recomendar valores para los atributos ausentes al responsable del catálogo antes de la fecha límite de publicación semanal, sin sobrescribir registros aprobados» sí lo es.

El contrato evita un fallo habitual: que un equipo optimice una métrica fuera del entorno operativo sin una vía fiable para aplicarla a las operaciones. También permite determinar si la IA es necesaria. Algunas decisiones son consultas deterministas, comprobaciones de umbrales o conciliaciones y deben seguir resolviéndose mediante reglas. La IA tiene sentido cuando la entrada es ambigua, no estructurada o lo bastante variable como para que las reglas por sí solas dejen de ser fiables.

A continuación, evaluamos la preparación mediante seis controles de aceptación. Un control no es un eslogan sobre madurez: tiene evidencia, un responsable y una condición para superarlo.

Control 1: procedencia

La procedencia responde a estas preguntas: ¿de dónde proviene este campo, con qué definición, a través de qué transformaciones y bajo la autoridad de quién?

Para cada entrada utilizada por el sistema, necesitamos poder rastrear el valor presentado hasta su origen. Esto incluye el sistema de origen, la hora de extracción, la clave del registro, la versión de la transformación y cualquier corrección humana. Si dos informes muestran valores distintos de ingresos, inventario o estado, el problema no se resuelve eligiendo la tabla más grande: hay que conciliar las definiciones y las secuencias de transformación.

Los equipos de desarrollo deben permitir consultar el linaje de datos. Una predicción o recomendación generada debe conservar referencias a los registros de origen y a la versión de la lógica de procesamiento que la produjo. La dirección no necesita examinar cada evento del linaje, pero sí contar con un responsable que rinda cuentas de cada dominio de datos crítico y con una vía documentada para escalar los conflictos entre definiciones.

El punto de extracción importa tanto como el almacén de datos. Un flujo de trabajo reproducible de extracción de datos operativos registra qué se solicitó, qué llegó y qué falló, para no confundir una ausencia con un cero.

Una condición útil para superar el control es sencilla: un revisor puede seleccionar una salida relevante y reconstruir su origen sin preguntar al desarrollador original. Si esto exige conocimientos que solo tienen algunas personas y no están documentados, el control no se ha superado.

Control 2: grado de actualización de los datos

El grado de actualización de los datos no se define mediante un objetivo universal de marcas de tiempo. Se refiere a la antigüedad máxima con la que los datos siguen siendo adecuados para una decisión concreta. Una clasificación mensual puede tolerar días de antigüedad; una decisión de disponibilidad puede no tolerar horas. El contrato de decisión determina el nivel de servicio.

Definimos el grado de actualización en tres momentos: cuándo ocurrió el evento, cuándo lo registró el sistema de origen y cuándo lo consumió el flujo de trabajo de IA. Estas marcas de tiempo revelan retrasos en las integraciones y actualizaciones que llegan tarde. También distinguimos entre «el pipeline se ejecutó correctamente» y «los datos están actualizados»: una tarea puede completarse correctamente mientras copia la misma instantánea de ayer.

El control en producción establece un límite de antigüedad y un comportamiento explícito cuando se supera. El sistema puede emitir una advertencia, abstenerse, recurrir a un valor determinista como alternativa de respaldo o bloquear una escritura. No es aceptable operar silenciosamente con datos desactualizados. Por ello, una capa fiable de almacén de datos e ingesta forma parte del producto que sustenta la decisión, no es una simple conexión técnica preliminar.

Control 3: duplicados e identidad

Los duplicados suelen ser fallos de identidad que se presentan como tareas de limpieza. Un mismo proveedor, producto, pedido o ubicación puede aparecer con identificadores diferentes; a la inversa, un identificador puede reutilizarse en distintas regiones o sistemas. Un modelo no puede corregir un modelo de entidades sin definir.

Primero establecemos la regla de identidad del negocio: ¿qué hace que dos registros correspondan a la misma entidad y en qué ámbito? Después conservamos tanto los identificadores originales como un identificador canónico, junto con el método de correspondencia y su nivel de confianza. Las claves deterministas deben tener prioridad. La resolución probabilística de entidades puede proponer coincidencias, pero las fusiones inciertas deben pasar por una cola de revisión, ya que una fusión incorrecta puede contaminar todas las variables y resultados posteriores.

La preparación exige medir las tasas de duplicados por fuente y segmento, no un único porcentaje global. También requiere decisiones de fusión reversibles, reglas para determinar qué valores se conservan cuando hay campos en conflicto y monitoreo de nuevos patrones de colisión. Si el equipo no puede explicar qué registro prevalece y por qué, no está preparado para automatizar una decisión basada en esa entidad.

Esta es una de las razones por las que importa la propiedad completa de los datos operativos: conservar el historial original y los identificadores estables permite conciliar y volver a procesar los datos más adelante, incluso cuando cambian las interfaces de los sistemas de origen.

Control 4: líneas de base

Sin una línea de base, un resultado de IA se convierte en una demostración en lugar de una intervención. Documentamos el rendimiento actual antes de cambiar el flujo de trabajo: tasa de errores, tiempo de ciclo, esfuerzo de revisión, cobertura, volumen de excepciones y resultado de negocio en el que la decisión pretende influir.

Cuando la confidencialidad es importante, publicamos la evidencia interna como un índice normalizado. El estado previo a la intervención es Baseline = 100. Los períodos posteriores muestran la variación relativa respecto a esa referencia, mientras que los valores absolutos subyacentes permanecen dentro del entorno de medición autorizado. Deben mantenerse el mismo denominador, población y ventana temporal; de lo contrario, el índice crea una falsa comparabilidad.

El diseño de la línea de base también exige segmentación. Una mejora global puede ocultar un deterioro en un mercado de alto riesgo, una clase de productos o un grupo de clientes. Definimos de antemano los segmentos relevantes y registramos los cambios simultáneos, como promociones, actualizaciones de políticas o cambios de personal. Esto no permite una inferencia causal perfecta, pero evita los errores de atribución más evidentes.

La condición para superar el control es poder reproducir la línea de base a partir de datos y definiciones bajo control de versiones. Una captura de pantalla de un panel no basta.

Control 5: permisos para actuar

El acceso a los datos no implica permiso para actuar. Una aplicación puede tener autorización para leer un pedido pero no cancelarlo, consultar un registro de producto pero no publicarlo, o calcular una recomendación pero no cambiar un precio. Elaboramos un mapa de autorizaciones para cada acción.

Este mapa incluye el sistema de registro de referencia, el actor autorizado, los requisitos de aprobación, los límites de valor o riesgo, la separación de funciones y la vía de reversión. El modo inicial normalmente debe ser de solo lectura o de recomendación. Después, una simulación sin cambios permite comparar las acciones propuestas con las decisiones humanas. Las escrituras aprobadas solo se habilitan cuando se han probado los controles de identidad, validación, registro y recuperación.

Este control conecta la gobernanza con el diseño del software. Las credenciales deben conceder únicamente los permisos mínimos; las herramientas deben separar las lecturas de las escrituras; las acciones de alto impacto deben exigir un token de aprobación explícito; y cada modificación debe ser idempotente cuando sea posible y llevar un ID de correlación. «Supervisión humana» es demasiado vago si no sabemos qué persona interviene, en qué momento, con qué información y con qué tiempo de respuesta.

Control 6: medición de resultados

La calidad del modelo es necesaria, pero insuficiente. La precisión, la exhaustividad o las puntuaciones de éxito de una tarea describen el comportamiento en un conjunto de evaluación. La pregunta operativa es si el sistema cambió una decisión y si ese cambio mejoró el resultado previsto sin efectos secundarios inaceptables.

Instrumentamos toda la cadena, desde la entrada hasta la recomendación, la revisión, la acción y el resultado. Cada etapa necesita un identificador estable para vincular el resultado final con la versión del modelo, las reglas y los datos de origen que intervinieron. Registramos las abstenciones y las recomendaciones rechazadas, no solo las salidas aceptadas. De lo contrario, el conjunto de retroalimentación queda sesgado hacia los casos fáciles.

El plan de medición define un resultado principal, métricas de protección y una frecuencia de revisión. Los controles de protección pueden incluir la gravedad de los errores, la tasa de modificaciones excepcionales, las quejas, las infracciones de políticas, la latencia o la carga de trabajo transferida a otro equipo. Un sistema que reduce una cola creando otra mayor y oculta no ha mejorado las operaciones.

Una ficha práctica de evaluación de la preparación

Utilizamos el marco como registro de decisiones, no como una puntuación decorativa. Cada control recibe uno de cuatro estados:

Estado	Significado	Consecuencia para la puesta en producción
Desconocido	No se ha recopilado evidencia	No se permiten pilotos que afirmen resultados operativos
Definido	Existen un responsable, una definición y una prueba	Solo evaluación fuera del entorno operativo
Verificado	Prueba superada con datos representativos	Piloto controlado del flujo de trabajo
Monitoreado	Existen un umbral de producción y una respuesta	Puede optar a un escalado con límites definidos

Los promedios resultan engañosos: cinco controles monitoreados no compensan unos permisos para actuar desconocidos. El nivel de puesta en producción queda limitado por el control más débil que pueda causar un daño sustancial o invalidar la medición.

Para los equipos de desarrollo, la ficha se convierte en una lista de pruebas de aceptación pendientes: consultas de linaje, comprobaciones del grado de actualización, pruebas de unicidad, tareas para calcular la línea de base, comprobaciones de permisos y cruces de datos para vincular resultados. Para la dirección, se convierte en un filtro de la cartera de iniciativas. Muestra cuáles necesitan trabajo sobre los datos, cuáles pueden pasar a un piloto controlado y cuáles deberían detenerse porque la propia decisión está mal especificada.

Ordenar la inversión antes de seleccionar un modelo

Una vez que los controles están claros, la inversión se vuelve más racional. Podemos resolver un problema de identificadores antes de comprar más capacidad de inferencia. Podemos añadir contexto a los eventos antes de encargar una predicción. Podemos negociar los permisos para actuar antes de construir un agente sin posibilidad de actuar. Podemos establecer la línea de base antes de que un cambio de proceso destruya el período de comparación.

Solo entonces adquiere sentido elegir modelos. El conjunto de evaluación debe proceder de la población operativa verificada e incluir las excepciones conocidas. Los modelos candidatos pueden compararse por éxito en la tarea, calibración, latencia, restricciones de privacidad y costo. Un modelo más potente no puede compensar un resultado que no se puede observar ni una vía de escritura no autorizada.

Así también es como los pilotos se convierten en sistemas de producción. La preparación no es una fase de limpieza de datos que se realiza una sola vez. Las fuentes se desvían, los identificadores cambian, los permisos caducan y las definiciones de negocio evolucionan. Por ello, cada control necesita un responsable, comprobaciones automatizadas cuando sea posible y una respuesta documentada cuando no se cumplan los umbrales.

La pregunta que debe hacer la dirección

La pregunta más útil al revisar un programa de IA empresarial no es «¿Qué modelo estamos usando?», sino «Muéstrennos la cadena que va desde la evidencia de origen hasta la acción autorizada y el resultado medido».

Si el equipo puede mostrar esa cadena y reproducirla, el programa tiene una base para aprender. Si no puede, una mayor capacidad del modelo normalmente aumentará la velocidad y la confianza de un proceso sin verificar. La preparación de los datos no es un requisito previo que deba completarse antes de comenzar el trabajo interesante con la IA. Es el diseño central del sistema operativo en el que se puede confiar en la IA.