Datos preparados para IA: calidad, contexto y control para agentes

Los datos preparados para IA son fuentes que un sistema puede localizar, interpretar y usar dentro de unos permisos definidos, con calidad suficiente para una tarea concreta. No significa reunir toda la información de la empresa ni alcanzar una limpieza perfecta. Significa conocer el propósito, el propietario, la definición, el origen, la vigencia y las restricciones de cada dato que afectará a una respuesta o acción.

Esta distinción importa porque un agente puede encadenar consultas, redactar una recomendación y ejecutar un paso en segundos. Si «cliente activo», «margen» o «incidencia resuelta» significan cosas distintas según el sistema, el modelo no corrige por sí solo esa contradicción. La amplifica con una respuesta convincente. Preparar datos es, por tanto, trabajo de producto y proceso, además de trabajo técnico.

Por qué la preparación de datos vuelve al centro

Microsoft explicó el 15 de octubre de 2026 que su marco interno de datos preparados para IA combina calidad, gobierno, descubrimiento, interoperabilidad, disponibilidad, observabilidad y comprensión contextual. Su conclusión más útil para una pyme no es que necesite copiar la plataforma de Microsoft. Es que la preparación debe mantenerse de forma continua y medirse frente al uso previsto, no tratarse como una limpieza única.

Google Cloud presentó el 22 de octubre funciones de enriquecimiento de contexto en Knowledge Catalog, todavía en vista previa. El producto busca añadir semántica a fuentes estructuradas y documentos para que los agentes seleccionen mejor el contexto. Google publica mejoras de precisión, latencia y consumo en sus pruebas internas; esas cifras describen su evaluación, no un resultado transferible a otra empresa. La lección general es más prudente: el nombre de una tabla o el contenido de un PDF rara vez explican por sí solos cómo debe usarse.

El anuncio de BigQuery Graph añade otro elemento: muchas preguntas empresariales dependen de relaciones. Para investigar un pedido retrasado quizá haya que conectar cliente, pedido, almacén, transportista e incidencia. Un documento aislado o una sola tabla no contienen necesariamente la trayectoria completa.

Calidad de datos no equivale a contexto de negocio

Un campo puede estar completo y ser inútil para una decisión. «Estado: cerrado» parece correcto, pero puede referirse a una oportunidad perdida, una factura cobrada o un ticket resuelto. El contexto explica la entidad, la definición, la unidad, el momento y el uso permitido. También indica qué excepciones conoce el equipo.

Microsoft relata un ejemplo interno en el que el nombre «Pigeon» designaba un sistema de red. Sin esa explicación, una IA interpretó el término literalmente como un conjunto de datos sobre aves. Es un caso sencillo de un problema frecuente: el conocimiento necesario existe en la cabeza de una persona, en una conversación o en un documento que el agente no puede relacionar con la fuente.

Conviene documentar al menos cinco elementos para cada fuente prioritaria: qué representa, quién responde por ella, de dónde procede, cuándo se actualiza y qué decisiones admite. Añade una definición para los campos decisivos y ejemplos de valores anómalos. Ese mínimo suele aportar más que generar descripciones extensas que nadie revisa.

Las siete preguntas de una fuente preparada

Antes de conectar una base de datos, una carpeta o un CRM, intenta responder:

1. ¿Qué tarea concreta utilizará la fuente?
2. ¿Quién puede confirmar su significado y corregir errores?
3. ¿Qué sistema es la referencia cuando hay conflictos?
4. ¿Qué antigüedad resulta aceptable para esa tarea?
5. ¿Qué usuarios, agentes y herramientas pueden verla o modificarla?
6. ¿Cómo se cita o reconstruye el dato que sustentó una salida?
7. ¿Qué debe ocurrir si falta, cambia el esquema o no está disponible?

Una respuesta incompleta no impide siempre el piloto. Sí debe limitar su alcance. Por ejemplo, un asistente puede resumir incidencias históricas aunque no deba cerrar una incidencia actual.

Empieza por una decisión, no por el inventario completo

«Preparar todos los datos para IA» no tiene un final verificable. Una tarea sí: proponer la causa de pedidos bloqueados, responder dudas sobre procedimientos o preparar un informe semanal. Elige un flujo con propietario, entradas identificables y una salida que alguien pueda revisar.

Imaginemos una distribuidora de Madrid que quiere explicar retrasos de pedidos. Los datos relevantes pueden estar en el ERP, el sistema de almacén y los correos del transportista. Antes de crear un agente, el equipo define qué cuenta como retraso, qué fecha prevalece, cómo se identifica un pedido y qué información del cliente puede aparecer en la respuesta. Después selecciona casos cerrados que sirvan para probar el razonamiento.

El primer entregable no tiene que ser una gran plataforma. Puede ser un mapa con ocho fuentes, sus propietarios, dos definiciones discutidas y tres controles de acceso. Si ese mapa revela que el identificador de pedido cambia entre sistemas, resolver la correspondencia tendrá más valor que añadir otro modelo.

Para un caso documental, la decisión inicial puede ser elegir entre conectores y RAG. Para datos operativos, probablemente habrá que revisar APIs, esquemas, sincronización y trazabilidad mediante una integración de sistemas.

Un marco práctico para puntuar la preparación

Una puntuación sirve para priorizar, no para declarar que un conjunto de datos es universalmente «apto para IA». Recomendamos valorar cada fuente en una escala sencilla frente a seis dimensiones:

• Significado: definiciones, unidades, relaciones y ejemplos entendibles.
• Calidad: completitud, duplicados, coherencia y errores relevantes para la tarea.
• Vigencia: frecuencia de actualización, latencia y fecha visible de cada dato.
• Propiedad: responsable de negocio y canal para corregir la fuente.
• Acceso: permisos mínimos, datos sensibles, registro y separación por usuario.
• Trazabilidad: origen, transformaciones y posibilidad de citar la evidencia.

No promedies sin mirar los límites. Una fuente con cinco dimensiones fuertes y permisos inadecuados no obtiene un aprobado útil. Define condiciones obligatorias: por ejemplo, ninguna respuesta externa puede usar registros sin control por cuenta, y ninguna acción financiera se ejecuta sin una fuente vigente y una aprobación.

Qué medir durante el piloto

Construye una batería de preguntas y casos que represente el trabajo real. Incluye datos correctos, registros incompletos, definiciones ambiguas, documentos vencidos, conflictos entre fuentes y usuarios con permisos distintos. Registra si el sistema encuentra la fuente correcta, interpreta el término de negocio, cita la evidencia, reconoce la incertidumbre y respeta el acceso.

La exactitud de la respuesta final no basta. También interesa la recuperación: si falla una API, ¿el agente avisa o responde con datos antiguos? Si hay dos cifras, ¿muestra el conflicto? Si no tiene permiso, ¿rechaza la consulta sin revelar que el registro existe? Estas pruebas conectan la preparación de datos con los controles de permisos para agentes.

Mantén una referencia humana para los casos importantes. Dos responsables pueden discrepar sobre la respuesta correcta; ese desacuerdo revela una definición pendiente. Resolverlo mejora tanto el agente como el proceso de negocio.

Permisos, linaje y uso responsable

Dar acceso técnico no concede un uso ilimitado. Un agente de soporte puede necesitar el estado de un pedido y no el historial completo del cliente. Un asistente interno puede consultar una política de recursos humanos y no expedientes individuales. Los permisos deben heredarse o aplicarse en el punto de consulta, no depender de que el prompt pida discreción.

El perfil de seguridad para IA agéntica de AWS incluye gobierno, calidad y linaje de datos dentro de la evaluación de riesgos. El linaje permite saber qué fuente y transformación contribuyeron a una salida. No garantiza que el razonamiento sea correcto, pero facilita investigar errores y retirar una fuente defectuosa.

El perfil de IA generativa del NIST recomienda documentar origen, tratamiento y restricciones de los datos a lo largo del ciclo de vida, además de evaluar privacidad, seguridad y calidad. Es un marco voluntario, no una certificación automática ni una sustitución del análisis jurídico aplicable.

Cuando una fuente contiene datos personales, secretos comerciales o decisiones de alto impacto, el piloto necesita revisión específica. Minimiza campos, separa entornos, limita retención y registra las acciones. Si no puedes explicar qué datos recibe un proveedor o con qué finalidad, el diseño todavía no está listo.

Comprar catálogo, construir una capa de contexto o mejorar lo existente

Un catálogo comercial puede ayudar cuando existen muchas fuentes, equipos y consumidores. Facilita descubrimiento, propiedad, linaje y políticas, pero no inventa definiciones correctas. Las funciones automáticas pueden proponer etiquetas o descripciones; una persona del negocio debe validar las que afecten a decisiones.

Una capa de contexto propia puede encajar en un caso acotado: un diccionario versionado, reglas de unión, permisos y referencias vinculadas a la integración. Reduce el alcance inicial, pero añade mantenimiento. Cada cambio en el ERP o el proceso debe reflejarse en esa capa.

También puede bastar con mejorar lo existente. Si hay diez procedimientos y dos hojas de cálculo, asignar propietarios, retirar duplicados y fijar una plantilla común puede preceder a cualquier compra. El criterio es el coste total de obtener respuestas aceptables y mantenerlas, no el número de funciones del catálogo.

Costes que suelen quedar fuera de la licencia

El presupuesto debe separar inventario y diagnóstico, corrección de identificadores, documentación semántica, integración, permisos, pruebas, consumo, observabilidad y mantenimiento. El mayor esfuerzo puede estar en acordar definiciones o corregir un proceso que genera datos inconsistentes, no en llamar al modelo.

Ejemplo hipotético: un piloto usa cuatro fuentes y requiere 12 horas para mapearlas, 16 para integrar y aplicar permisos, ocho para preparar casos de prueba y cuatro horas mensuales de revisión. A un coste interno supuesto de 35 euros por hora, la preparación inicial equivaldría a 1.260 euros antes de licencias y consumo. No es una tarifa de Niter Agency ni una estimación universal.

Si el agente ahorrase diez horas al mes pero la revisión y mantenimiento consumieran cuatro, la capacidad neta sería de seis horas. La decisión tendría que comparar ese valor, la reducción de errores y la rapidez de respuesta con todos los costes. Un ahorro bruto sin supervisión produce una justificación engañosa; puedes ampliar el cálculo con nuestra guía sobre productividad y supervisión de agentes.

Un plan de 30 días para un primer caso

Durante la primera semana, define tarea, responsable, usuarios y criterio de aceptación. Identifica las fuentes mínimas y recoge ejemplos de éxito, error y excepción. En la segunda, acuerda definiciones, sistema de referencia, vigencia y permisos; corrige solo los bloqueos que afecten al caso.

En la tercera semana, conecta un entorno controlado y ejecuta la batería de evaluación. Exige evidencia visible y registra fallos por categoría: recuperación, interpretación, actualidad, permiso o acción. En la cuarta, calcula revisión, coste y riesgo residual. Decide si ampliar fuentes, mantener el alcance, volver al proceso anterior o detener el proyecto.

El resultado válido puede ser no escalar todavía. Si el piloto demuestra que dos sistemas no comparten identificadores o que nadie mantiene una política, esa evidencia evita automatizar una contradicción. La metodología de Niter Agency prioriza diagnóstico, alcance y criterios de aceptación antes de extender una solución.

Qué pedir a una consultoría o proveedor

Pide que relacione cada fuente con una tarea y un permiso, y que muestre cómo se rastrea una respuesta hasta su evidencia. Solicita una prueba con datos vencidos, conflicto entre sistemas, un usuario sin acceso y una caída de conexión. Pregunta quién mantiene definiciones y evaluaciones después de la entrega.

Desconfía de una propuesta que prometa «unificar todos los datos» sin inventario, responsables ni límites. También de una demostración que solo usa preguntas ideales. Una solución preparada para producción debe saber abstenerse, mostrar incertidumbre y escalar una excepción a una persona.

Niter Agency es una consultora de inteligencia artificial con base en Madrid. Podemos ayudar a seleccionar un caso, revisar datos e integraciones y construir un piloto medible mediante la consultoría de IA para empresas. Para valorar el alcance, contacta con el equipo indicando el proceso, las aplicaciones implicadas y quién valida hoy la información.

Preguntas frecuentes sobre datos preparados para IA

¿Tengo que centralizar todos mis datos antes de usar IA?

No. Para un primer caso puedes consultar las fuentes existentes mediante conectores o APIs, siempre que controles identidad, permisos, vigencia y significado. Centralizar puede ser útil por otros motivos, pero debe justificarse frente al caso y su coste.

¿Limpiar datos históricos es siempre el primer paso?

Solo los datos que influyen en la tarea prioritaria. Empieza por casos representativos y detecta qué errores cambian la salida. Corregir millones de registros irrelevantes puede retrasar el aprendizaje sin mejorar el piloto.

¿Un catálogo de datos hace que un agente sea fiable?

Ayuda a descubrir fuentes, documentar propietarios, linaje y políticas. No valida por sí solo las definiciones de negocio ni el comportamiento del agente. Hace falta evaluación con casos reales, permisos y supervisión.

¿Quién debe ser responsable de los datos para IA?

La responsabilidad se comparte: negocio define significado y uso; datos o tecnología mantienen integración, calidad y observabilidad; seguridad y legal revisan riesgos cuando corresponde. Cada fuente y cada decisión deben tener un responsable identificable.

¿Cómo sé si mis datos ya están preparados?

Cuando el sistema supera una evaluación definida para la tarea: encuentra la fuente correcta, interpreta los términos, usa datos vigentes, respeta permisos, aporta evidencia y gestiona excepciones. La preparación se revisa cuando cambian fuentes, procesos o requisitos.

Fuentes y alcance

Fuentes primarias consultadas el 30 de octubre de 2026: marco de datos preparados para IA de Microsoft, Knowledge Catalog de Google Cloud, BigQuery Graph, seguridad para IA agéntica de AWS y perfil de IA generativa del NIST. Las recomendaciones, la puntuación, el calendario y el cálculo son análisis propio. Las funciones en vista previa, condiciones y resultados publicados por proveedores deben comprobarse en el entorno elegido.