Datos listos para IA antes del primer piloto

Muchos pilotos de IA se aprueban con una demostración convincente y se detienen semanas después por una pregunta que nadie se hizo al principio: ¿podemos usar estos datos? A veces el problema es técnico (el campo clave viene vacío en un tercio de los registros). Otras veces es de gobierno: nadie sabe quién es dueño de la tabla, de qué sistema sale o si contiene datos personales que no deberían salir de su perímetro.

En un sector regulado esas preguntas no se pueden dejar para después. Un modelo que aprende de datos incorrectos produce respuestas incorrectas con mucha seguridad, y un piloto que usa datos sin autorización es un incidente de cumplimiento aunque funcione bien. Este artículo propone cuatro cimientos que conviene tener antes del primer piloto: catálogo, calidad, linaje y permisos. No hace falta tenerlos completos para toda la organización; basta con tenerlos para los datos que el piloto va a usar.

Por qué los pilotos tropiezan con los datos

El patrón es conocido. El equipo elige un caso de uso atractivo, consigue una extracción de datos "para probar", entrena o configura el modelo y obtiene resultados prometedores. Cuando llega el momento de pasar a producción aparecen las preguntas de Riesgo, Seguridad y Cumplimiento: de dónde salió esa extracción, quién la autorizó, si incluye datos de clientes, si se puede repetir todos los días con la misma calidad. Si las respuestas no existen, el piloto vuelve a empezar o se archiva.

El costo no es solo el tiempo perdido. Una extracción manual que vive en una carpeta compartida es un riesgo en sí misma: copia datos fuera de sus controles, no tiene dueño y nadie la borra. Por eso conviene invertir el orden: primero preparar los datos del caso de uso, después construir el piloto. La preparación no tiene que ser un programa de varios años. Para un piloto bien acotado, puede ser un trabajo de pocas semanas si las preguntas se hacen desde el principio.

Un buen punto de partida es el NIST AI Risk Management Framework. Su función Mapear pide entender el contexto del sistema de IA, incluidos los datos que usa y sus limitaciones; su función Medir pide evaluar con métricas y documentar los resultados. Los cuatro cimientos de este artículo son una forma concreta de responder a ambas.

Catálogo: saber qué existe y de quién es

El catálogo responde a dos preguntas básicas: qué datos existen para el caso de uso y quién responde por cada conjunto. Sin dueño no hay a quién pedir permiso, a quién reportar un problema de calidad ni quién aprueba un cambio de estructura.

No hace falta una herramienta de catálogo corporativa para empezar. Para el piloto, cada conjunto de datos debería tener una ficha con lo mínimo:

• Nombre y descripción en lenguaje de negocio, no solo el nombre técnico de la tabla.
• Dueño de negocio (decide sobre su uso) y custodio técnico (lo opera).
• Sistema de origen y frecuencia de actualización.
• Clasificación según la política de la organización (por ejemplo, pública, interna, confidencial, restringida) y si contiene datos personales.
• Definición de los campos clave: qué significa "cliente activo" o "fecha de operación" en ese conjunto.

El último punto parece menor y no lo es. Dos áreas pueden usar el mismo término con definiciones distintas, y un modelo entrenado con una definición se evalúa con la otra. Esa ficha, además, es la semilla del catálogo corporativo: cada piloto que la completa deja el terreno mejor preparado para el siguiente.

Calidad: dimensiones que se miden

"Los datos son buenos" no es un criterio. La calidad se expresa en dimensiones medibles, con un umbral acordado con el dueño antes de empezar. La serie ISO/IEC 5259 (Artificial intelligence. Data quality for analytics and machine learning) ofrece un marco reconocido: define un modelo de calidad de datos y medidas para analítica y aprendizaje automático, y extiende el modelo clásico de ISO/IEC 25012 con características propias de estos usos, como la representatividad, la diversidad o el equilibrio de los datos.

Para un primer piloto recomendamos elegir pocas dimensiones y medirlas bien. La siguiente tabla es ilustrativa; los umbrales concretos dependen del caso.

Dimensión	Pregunta que responde	Medida de ejemplo (ilustrativa)
Completitud	¿Faltan valores en campos clave?	Porcentaje de registros con el campo informado
Exactitud	¿El dato refleja la realidad?	Coincidencia con una muestra validada a mano
Consistencia	¿Dos sistemas dicen lo mismo?	Diferencias en una conciliación entre fuentes
Actualidad	¿Llega a tiempo para el uso?	Horas entre el evento y su disponibilidad
Representatividad	¿Cubre la población real del caso?	Distribución por segmento frente a la de producción

La representatividad merece atención especial en IA. Un conjunto de datos puede estar completo y ser exacto, pero si solo cubre un tipo de cliente, un canal o un período sin estacionalidad, el modelo aprenderá un mundo que no es el real. En sectores como banca, seguros o salud esto tiene además una dimensión de trato justo que Riesgo y Cumplimiento querrán revisar.

Medir una vez no basta. Si el piloto avanza, la calidad debe vigilarse de forma continua, igual que la disponibilidad de un servicio. Lo desarrollamos en observabilidad de datos.

Linaje: de dónde viene cada dato

El linaje documenta el recorrido de un dato: en qué sistema nace, qué procesos lo transforman y en qué tablas, reportes o modelos termina. Sirve para tres cosas concretas en un piloto de IA:

• Explicar un resultado. Si el modelo produce una respuesta extraña, el linaje permite rastrear qué datos de entrada la provocaron y de dónde salieron.
• Medir el impacto de un cambio. Si un sistema de origen cambia la estructura de un campo, el linaje dice qué modelos se ven afectados antes de que fallen.
• Responder a una auditoría. Riesgo o un auditor externo pueden pedir que demuestres de dónde vienen los datos con los que se entrenó o se alimenta el sistema.

El linaje documentado a mano en un diagrama envejece rápido. Conviene capturarlo de forma automática desde los procesos que mueven los datos. OpenLineage, un proyecto abierto de la LF AI & Data Foundation, define un estándar para emitir eventos de linaje a partir de tres entidades (conjuntos de datos, trabajos y ejecuciones) que se enriquecen con metadatos adicionales llamados facetas. Muchos orquestadores y motores de procesamiento tienen integraciones con este estándar, lo que permite empezar sin reescribir los procesos.

Para el piloto, el mínimo razonable es poder responder, para cada dato que entra al modelo, de qué sistema de origen viene y qué transformaciones sufrió. Si eso no se puede responder hoy, es el primer trabajo.

Permisos: quién puede usar qué

El cuarto cimiento es el que más pilotos detiene en organizaciones reguladas. Tener acceso técnico a un dato no significa tener permiso para usarlo en un sistema de IA. Hay tres preguntas que responder:

¿Hay base para este uso?

Si los datos incluyen información personal, el uso en un sistema de IA debe ser compatible con la finalidad para la que se recogieron y con la base legal que aplica. En España rige el Reglamento General de Protección de Datos; en Latinoamérica, cada país tiene su propia ley de protección de datos personales. La respuesta la da el delegado de protección de datos o el área legal, no el equipo del piloto.

¿Hace falta el dato tal como está?

Muchos casos de uso funcionan igual con datos seudonimizados, agregados o con campos sensibles eliminados. Minimizar antes de empezar reduce el riesgo y simplifica las aprobaciones.

¿Quién accede al resultado?

Un modelo o un asistente puede exponer información de los datos con los que trabaja. Si un empleado no puede ver un dato en el sistema de origen, tampoco debería poder obtenerlo preguntándole a la IA. Los permisos del piloto deben heredar los del origen. Este punto conecta con la discusión más amplia sobre el rol del CISO frente a la IA.

Lista de verificación antes del piloto

Recomendamos revisar esta lista con el dueño de los datos, Seguridad y Cumplimiento antes de aprobar el inicio del piloto. Si algún punto no se cumple, no significa que el piloto no pueda empezar, pero sí que ese trabajo entra en el plan y tiene responsable.

• Catálogo. Cada conjunto de datos del piloto tiene ficha, dueño de negocio y custodio técnico identificados.
• Catálogo. Los términos clave del caso de uso tienen una definición acordada y escrita.
• Calidad. Se eligieron las dimensiones relevantes y se fijaron umbrales antes de medir.
• Calidad. Existe una medición inicial y se sabe cómo se repetirá si el piloto avanza.
• Linaje. Para cada dato de entrada se conoce el sistema de origen y las transformaciones aplicadas.
• Linaje. Los datos llegan por un proceso repetible, no por una extracción manual.
• Permisos. Los datos están clasificados y se sabe si incluyen datos personales.
• Permisos. La base para el uso fue validada por el área de protección de datos o Legal.
• Permisos. Se aplicó minimización y el acceso al resultado respeta los permisos del origen.
• Gobierno. El caso de uso está registrado en el inventario de sistemas de IA de la organización.

El último punto enlaza con el sistema de gestión de la IA. ISO/IEC 42001 incluye controles sobre los datos usados por los sistemas de IA, entre ellos su calidad, su procedencia y su preparación. Si tu organización ya trabaja con esa norma, esta lista es una forma práctica de aterrizar esos controles en un caso concreto. Lo explicamos con más detalle en ISO/IEC 42001 en la práctica.

Un último criterio: el primer piloto debería elegirse también por sus datos, no solo por su valor. Un caso de uso con datos ya catalogados, de un solo dueño y sin datos personales es un mejor primer paso que uno más ambicioso con datos dispersos. El aprendizaje sobre cómo preparar datos sirve para todos los pilotos siguientes. Antes de usar datos con impacto regulatorio, valida el enfoque con Cumplimiento, Riesgo y el delegado de protección de datos.