Una empresa no está lista para IA porque haya comprado licencias o elegido un modelo. Está lista cuando sus datos son confiables, accesibles, gobernados, trazables y útiles para un caso de negocio medible. Omitir esta preparación multiplica reprocesos, errores, riesgo regulatorio y gasto tecnológico sin impacto en EBITDA.
Definiciones taxonómicas
1. Preparación de datos para IA o AI Data Readiness
Es la capacidad de una organización para entregar a modelos, agentes y aplicaciones de inteligencia artificial datos relevantes, confiables, accesibles, protegidos, actualizados y trazables.
No se limita a “limpiar información”. Incluye:
- Calidad y consistencia.
- Integración entre sistemas.
- Metadatos y linaje.
- Seguridad y permisos.
- Disponibilidad operativa.
- Representatividad.
- Evaluación del dato contra un caso de negocio.
- Monitoreo continuo.
2. Producto de datos o Data Product
Es un conjunto de datos diseñado, documentado y administrado para resolver una necesidad específica del negocio. Tiene propietario, usuarios definidos, controles de calidad, reglas de acceso, acuerdos de nivel de servicio y métricas de desempeño.
Por ejemplo, un producto de datos para predecir abandono de clientes no debería limitarse a exportar información del CRM. Debe integrar comportamiento de compra, interacciones, reclamaciones, consentimientos, historial de servicio y una definición corporativa de qué significa “abandono”.
3. Linaje de datos o Data Lineage
Es el registro de dónde se originó un dato, qué transformaciones recibió, qué sistemas lo consumieron y qué versión llegó al modelo de IA.
El linaje permite responder preguntas críticas:
- ¿De qué sistema salió esta respuesta?
- ¿Qué documento utilizó el agente?
- ¿Qué versión de la política estaba vigente?
- ¿Quién modificó el registro?
- ¿Puede reproducirse la decisión?
- ¿Existe evidencia para una auditoría?
Sin linaje, una respuesta generada por IA puede parecer correcta, pero no ser defendible frente a clientes, auditores o reguladores.
Tabla comparativa: datos listos para IA vs. datos no preparados
| Variable | Datos no preparados | Datos listos para IA | Impacto de negocio |
| Calidad | Registros incompletos, duplicados o contradictorios | Reglas de calidad, validación y corrección desde el origen | Menos errores, reprocesos y decisiones incorrectas |
| Integración | Información aislada en ERP, CRM, Excel, correo y sistemas heredados | Pipelines gobernados y fuentes conectadas | Menor tiempo de preparación y automatización de procesos completos |
| Accesibilidad | Dependencia de TI para extraer información | Acceso por roles, APIs y productos de datos reutilizables | Menor time-to-market de nuevos casos de IA |
| Trazabilidad | No puede explicarse de dónde salió una respuesta | Linaje, versión, fuente y evidencia disponibles | Mayor control regulatorio y capacidad de auditoría |
| Datos no estructurados | Documentos cargados sin contexto ni clasificación | Documentos segmentados, etiquetados y vinculados con su fuente | Mejor precisión en asistentes y soluciones RAG |
| Seguridad | Permisos heredados o acceso excesivo | Identidades, privilegios mínimos, clasificación y políticas de uso | Menor exposición de información sensible |
| Actualización | Información obsoleta o cargada manualmente | Frecuencia definida según el proceso de negocio | Decisiones oportunas y menor riesgo operativo |
| Propiedad | “Los datos son de TI” | Dueños de negocio y responsables de calidad definidos | Rendición de cuentas y mejora sostenible |
| Evaluación | La IA se prueba con ejemplos aislados | Conjunto de pruebas, criterios de aceptación y revisión humana | Menor probabilidad de errores en producción |
| Economía | Costos de nube y licenciamiento sin medición | Consumo, beneficios y riesgos vinculados al caso de negocio | Mayor control del ROI y del impacto en EBITDA |
¿Qué significa realmente tener datos listos para IA?
Tener grandes volúmenes de información no significa estar preparado para utilizar inteligencia artificial.
Una organización está lista cuando puede proporcionar al sistema correcto:
- El dato adecuado.
- En el momento requerido.
- Con los permisos correctos.
- En un formato utilizable.
- Con contexto suficiente.
- Con evidencia de su origen.
- Con una calidad compatible con el riesgo de la decisión.
- Con mecanismos para detectar desviaciones.
Esta distinción es relevante porque la adopción de IA ha avanzado más rápido que su capacidad para generar resultados empresariales. En 2026, McKinsey reportó que solo 7% de las empresas había escalado completamente la IA en la organización, identificando la preparación de datos como uno de los principales cuellos de botella.
La diferencia entre una demostración y una capacidad empresarial no suele estar en el modelo. Está en la infraestructura, los datos, los controles y el proceso operativo que rodea al modelo.
¿Por qué los proyectos de IA se estancan por los datos?
Las pruebas de concepto suelen utilizar archivos seleccionados, muestras pequeñas o información preparada manualmente. En esas condiciones, el modelo puede producir resultados convincentes.
El problema aparece al conectarlo con la operación real:
- Los nombres de clientes no coinciden entre sistemas.
- Existen múltiples versiones de una misma política.
- Los documentos no tienen fecha, categoría o propietario.
- El catálogo de productos contiene duplicados.
- Los registros históricos no conservan el contexto de la decisión.
- Los permisos del sistema de origen no se trasladan al agente.
- La información llega después de que la decisión debía tomarse.
- No existe una “respuesta correcta” contra la cual evaluar al modelo.
IBM encontró que 42% de las organizaciones encuestadas consideraba que no tenía suficientes datos propietarios para personalizar sus modelos de IA.
El problema no es únicamente técnico. Cuando la información no está preparada, la empresa enfrenta:
- Mayores horas de limpieza y conciliación.
- Retrasos en la salida a producción.
- Consumo innecesario de nube y procesamiento.
- Resultados inconsistentes entre áreas.
- Dependencia de especialistas.
- Decisiones que requieren verificación manual.
- Riesgo de utilizar datos personales sin autorización.
- Pérdida de confianza de usuarios y clientes.
McKinsey reportó en su estudio global de 2025 que 88% de los participantes ya utilizaba IA en al menos una función, pero aproximadamente una tercera parte había comenzado a escalarla. Solo 39% declaró impacto en EBIT a nivel empresarial. Además, 51% de las organizaciones usuarias de IA había experimentado al menos una consecuencia negativa y cerca de una tercera parte reportó problemas derivados de resultados inexactos.
La lectura ejecutiva es directa: adoptar IA no equivale a capturar valor. Sin datos preparados, la empresa puede acelerar la generación de respuestas, pero también acelerar errores.
Cómo preparar los datos para un proyecto de inteligencia artificial
Paso 1. Comenzar por la decisión de negocio, no por el modelo
Antes de integrar fuentes o seleccionar plataformas, debe definirse qué decisión, proceso o resultado se pretende mejorar.
El caso de uso debe responder:
- ¿Qué problema económico se quiere resolver?
- ¿Qué área será responsable del resultado?
- ¿Qué decisión tomará o recomendará la IA?
- ¿Cuál es el costo actual del proceso?
- ¿Qué error es aceptable?
- ¿Qué decisiones requieren autorización humana?
- ¿Qué KPI financiero u operativo demostrará valor?
- ¿Qué sistemas deberán ejecutar la acción?
Un agente que responde preguntas internas, un modelo que detecta fraude y una solución que aprueba créditos no deben utilizar los mismos umbrales de calidad, supervisión y riesgo.
Mientras mayor sea el impacto de una respuesta incorrecta, más estrictos deben ser los controles sobre el dato.
Paso 2. Identificar los dominios de datos críticos
No es necesario corregir toda la información de la empresa antes de iniciar IA. Es necesario preparar los dominios que determinan el resultado del caso de uso.
Ejemplos:
Atención al cliente
- Clientes y contratos.
- Productos y servicios.
- Historial de interacciones.
- Base de conocimiento.
- Políticas de atención.
- Reclamaciones.
- Niveles de servicio.
- Consentimientos y datos personales.
Finanzas
- Catálogo contable.
- Centros de costos.
- Facturas.
- Órdenes de compra.
- Proveedores.
- Reglas de autorización.
- Presupuestos.
- Evidencia documental.
Manufacturing
- Activos y componentes.
- Sensores.
- Eventos de falla.
- Órdenes de mantenimiento.
- Turnos.
- Lotes.
- Parámetros de calidad.
- Refacciones.
El inventario debe incluir datos estructurados y no estructurados: tablas, correos, imágenes, audio, manuales, contratos, tickets, transcripciones y documentos escaneados.
Paso 3. Medir la calidad con criterios objetivos
La calidad debe evaluarse por dimensión y por campo crítico. Un promedio general puede ocultar errores graves.
Las dimensiones mínimas son:
- Completitud: porcentaje de campos obligatorios disponibles.
- Exactitud: correspondencia con la realidad o fuente autorizada.
- Consistencia: coincidencia entre sistemas y periodos.
- Unicidad: ausencia de registros duplicados.
- Validez: cumplimiento del formato y reglas de negocio.
- Oportunidad: disponibilidad dentro del tiempo requerido.
- Integridad referencial: relación correcta entre entidades.
- Representatividad: cobertura de los escenarios que enfrentará el modelo.
Como control operativo propuesto por Scanda, los campos identificadores y las reglas que habilitan una decisión crítica deben cumplir una exigencia superior al promedio del conjunto:
- Identificadores críticos únicos y válidos.
- Campos obligatorios con umbral explícito.
- Conciliación entre fuentes maestras.
- Tolerancia documentada para datos faltantes.
- Evidencia del origen de los registros.
- Alertas cuando una regla de calidad se incumpla.
- Bloqueo del flujo cuando el error exceda el riesgo aceptado.
Scanda aborda esta etapa con medición objetiva, controles preventivos, monitoreo y gobierno, en lugar de tratar la calidad como una limpieza extraordinaria antes de cada proyecto.
Paso 4. Asignar propietarios y reglas de gobierno
Un proyecto de datos fracasa cuando todos pueden consumir la información, pero nadie es responsable de su significado o calidad.
Cada dominio debe tener:
- Data Owner: responsable del uso y definición del dato desde negocio.
- Data Steward: encargado de aplicar reglas y resolver incidencias.
- Custodio tecnológico: responsable de almacenamiento, disponibilidad y respaldo.
- Responsable de seguridad: valida accesos, clasificación y exposición.
- Responsable del caso de IA: responde por desempeño, adopción y resultados.
También deben documentarse:
- Finalidad autorizada de uso.
- Base legal o consentimiento.
- Reglas de retención.
- Clasificación de información.
- Acceso por rol.
- Uso permitido por modelos externos.
- Requisitos de anonimización.
- Proceso de eliminación.
- Gestión de terceros.
- Evidencia para auditoría.
El NIST AI Risk Management Framework estructura la gestión del riesgo de IA alrededor de cuatro funciones: gobernar, mapear, medir y gestionar. Esto refuerza que el control de los datos no debe realizarse después del despliegue, sino durante todo el ciclo de vida.
Paso 5. Integrar las fuentes sin crear otra capa de desorden
Un proyecto de IA puede conectarse directamente a múltiples sistemas, pero cada conexión punto a punto aumenta la complejidad, el costo de mantenimiento y la probabilidad de inconsistencias.
La arquitectura debe definir:
- Sistemas de registro autorizados.
- Patrones ETL o ELT.
- Integraciones batch, near real-time o en tiempo real.
- Reglas de reconciliación.
- Esquemas y contratos de datos.
- Manejo de errores y reintentos.
- Monitoreo de pipelines.
- Historial de cambios.
- Capa de consumo para aplicaciones de IA.
- Controles de costos.
Dependiendo de la madurez y el caso de uso, la solución puede apoyarse en:
- Data Warehouse.
- Data Lake.
- Lakehouse.
- Master Data Management.
- APIs empresariales.
- Streaming de eventos.
- Productos de datos.
- Plataformas de conocimiento corporativo.
Scanda integra datos de ERP, CRM, sistemas operativos, plataformas SaaS y ambientes heredados mediante arquitecturas gobernadas, pipelines monitoreados y capas preparadas para analítica e IA.
Paso 6. Preparar los datos no estructurados para IA generativa
Cargar miles de archivos en una base vectorial no garantiza respuestas correctas.
Un documento debe convertirse en un activo utilizable. Para ello se requiere:
- Extraer texto, tablas e imágenes.
- Preservar la relación con el archivo original.
- Identificar título, fecha, versión, área y propietario.
- Clasificar sensibilidad.
- Eliminar duplicados y versiones obsoletas.
- Segmentar el contenido sin perder contexto.
- Generar metadatos para filtrado.
- Asociar permisos del documento con el usuario.
- Definir vigencia.
- Mantener referencias verificables.
- Evaluar la recuperación antes de evaluar la respuesta.
En una arquitectura RAG, la calidad no depende solo del modelo. También depende de si el sistema recuperó el documento correcto, el fragmento correcto y la versión vigente.
McKinsey señala que escalar IA exige conectar información estructurada y no estructurada en una base gobernada, trazable y reutilizable. Un PDF, por ejemplo, puede generar texto, tablas, imágenes, metadatos, etiquetas y puntuaciones de calidad que deben permanecer vinculados con el documento original.
Paso 7. Construir un conjunto de evaluación antes de producción
No debe aprobarse una solución porque “las respuestas se ven bien”.
Se requiere un conjunto de evaluación representativo con:
- Preguntas frecuentes.
- Casos excepcionales.
- Situaciones ambiguas.
- Datos incompletos.
- Documentos contradictorios.
- Solicitudes no autorizadas.
- Casos que requieren escalamiento.
- Ejemplos de respuesta correcta.
- Ejemplos de abstención.
- Criterios de revisión humana.
Las métricas pueden incluir:
- Precisión.
- Recall.
- Tasa de respuestas fundamentadas.
- Tasa de recuperación correcta.
- Falsos positivos.
- Falsos negativos.
- Respuestas sin evidencia.
- Violaciones de permisos.
- Tiempo de respuesta.
- Costo por transacción.
- Porcentaje de escalamiento humano.
- Impacto en el KPI de negocio.
Para casos de alto riesgo, una respuesta incorrecta no debe compensarse con un buen promedio general.
Paso 8. Operar el dato como un producto permanente
Los datos no permanecen listos por sí solos. Cambian las fuentes, los procesos, las reglas, los clientes y las condiciones del mercado.
La operación debe monitorear:
- Caídas de pipelines.
- Cambios de esquema.
- Pérdida de completitud.
- Aumento de duplicados.
- Información obsoleta.
- Variaciones en distribución.
- Pérdida de representatividad.
- Cambios en permisos.
- Nuevas versiones documentales.
- Desempeño del sistema de IA.
- Costo por consulta o proceso.
- Incidentes y correcciones.
La preparación de datos no es una fase que termina antes del go-live. Es una capacidad operativa.
Matriz Scanda de Preparación de Datos para IA
Scanda propone evaluar cada caso de uso con seis dimensiones ponderadas. El objetivo no es obtener una calificación decorativa, sino tomar una decisión de inversión.
| Dimensión | Ponderación sugerida | Evidencia requerida |
| Alineación con valor de negocio | 15% | KPI, baseline, beneficio esperado, dueño y decisión afectada |
| Calidad y representatividad | 20% | Perfilado, reglas, excepciones, cobertura y resultados de pruebas |
| Acceso e integración | 15% | Fuentes autorizadas, pipelines, frecuencia, APIs y disponibilidad |
| Gobierno, privacidad y seguridad | 20% | Propietarios, permisos, finalidad, clasificación y retención |
| Trazabilidad y metadatos | 15% | Linaje, versión, fuente, catálogo y evidencia reproducible |
| Operación y monitoreo | 15% | SLA, alertas, observabilidad, respuesta a incidentes y costos |
Interpretación ejecutiva
- Menos de 60 puntos: no invertir todavía en construcción o escalamiento. Corregir las brechas críticas.
- De 60 a 79 puntos: ejecutar un piloto controlado con un plan formal de remediación.
- 80 puntos o más: avanzar a producción si no existe ningún control crítico incumplido.
- Bloqueo obligatorio: aunque la calificación sea alta, no debe escalarse cuando no exista autorización de uso, propietario, trazabilidad, evaluación o control de accesos.
La matriz debe aplicarse por caso de uso. Una empresa puede estar preparada para un asistente interno de consulta, pero no para automatizar decisiones de crédito o mantenimiento crítico.
Cómo traducir la calidad del dato a EBITDA, ROI y riesgo
El presupuesto de preparación de datos debe vincularse con pérdidas evitadas y beneficios capturados.
Costo anual de datos no preparados
Una aproximación financiera puede calcularse así:
Costo de datos no preparados =
- Horas de corrección manual × costo por hora.
- Reprocesos operativos.
- Errores de facturación, inventario o servicio.
- Retrasos en proyectos.
- Infraestructura y nube desperdiciadas.
- Decisiones incorrectas.
- Pérdida esperada por incidentes.
- Multas, reclamaciones o compensaciones.
- Margen no capturado por automatización tardía.
Pérdida esperada por riesgo
Pérdida esperada anual = probabilidad del incidente × impacto financiero estimado
El impacto debe incluir:
- Interrupción operativa.
- Recuperación.
- Investigación.
- Notificación.
- Honorarios legales.
- Compensaciones.
- Multas.
- Pérdida de clientes.
- Daño reputacional.
- Pérdida de productividad.
ROI de la preparación de datos
ROI = [(ahorros operativos + margen incremental + pérdidas evitadas) − inversión total] ÷ inversión total × 100
La inversión total debe contemplar:
- Arquitectura.
- Integraciones.
- Licencias.
- Remediación.
- Gobierno.
- Seguridad.
- Evaluación.
- Operación.
- Adopción.
- Mantenimiento.
El objetivo no es limpiar todo. Es invertir primero en los datos que protegen o generan mayor valor económico.
Errores que deben evitarse antes de implementar IA
Comprar tecnología antes de definir el caso de negocio
Elegir un modelo sin conocer la decisión que debe mejorar produce pilotos llamativos, pero difíciles de justificar financieramente.
Asumir que más datos siempre generan mejores resultados
Agregar información duplicada, obsoleta o irrelevante puede degradar la precisión y elevar el costo de procesamiento.
Delegar toda la responsabilidad al área de TI
TI puede administrar la plataforma, pero las definiciones de cliente, ingreso, riesgo, producto o cumplimiento pertenecen al negocio.
Limpiar los datos una sola vez
Sin controles en el origen, los errores reaparecen después de cada carga.
Ignorar los permisos de los sistemas fuente
Un agente no debe revelar un documento solo porque pudo indexarlo. Los permisos deben aplicarse durante la recuperación y generación.
Evaluar únicamente respuestas promedio
Los casos excepcionales son los que generan mayor riesgo financiero, operativo o regulatorio.
Escalar sin trazabilidad
Cuando una organización no puede explicar qué dato sustentó una decisión, tampoco puede defenderla.
Medir adopción sin medir resultados
Número de usuarios, consultas o prompts no equivale a EBITDA, productividad o reducción de riesgo.
Conclusión predictiva
Durante los próximos ciclos de adopción, la ventaja no estará en acceder al modelo más nuevo, porque esa capacidad será cada vez más disponible. La diferencia estará en qué empresas pueden conectar modelos y agentes con datos confiables, gobernados y utilizables dentro de procesos reales.
La expansión de agentes de IA elevará el riesgo: un asistente incorrecto genera una mala respuesta; un agente incorrecto puede ejecutar una mala acción. El mercado ya muestra una brecha entre uso y valor: la adopción es amplia, pero el escalamiento y el impacto en EBIT siguen concentrados en una minoría.
Las empresas que pospongan la preparación de datos acumularán deuda técnica, controles manuales, consumo de nube y pilotos difíciles de escalar. Las que conviertan sus datos en productos gobernados podrán automatizar procesos completos, desplegar IA con menor riesgo y medir su contribución al negocio.
La pregunta ejecutiva ya no debe ser “¿qué modelo vamos a comprar?”, sino “¿qué decisiones estamos dispuestos a delegar y qué evidencia demuestra que nuestros datos pueden sostenerlas?”.
FAQ
1. ¿Es necesario modernizar toda la arquitectura de datos antes de implementar IA? No. La prioridad debe ser preparar los dominios necesarios para uno o dos casos de negocio con impacto medible. Sin embargo, la solución debe diseñarse con patrones reutilizables de integración, seguridad, linaje y monitoreo. Crear conexiones aisladas para cada piloto reduce la inversión inicial, pero aumenta el costo de escalar.
2. ¿Cómo puede un CFO justificar la inversión en preparación de datos? Debe comparar el costo total de la preparación con tres componentes: ahorros operativos, margen incremental y pérdidas evitadas. El caso financiero debe incluir reprocesos actuales, errores, retrasos, exposición regulatoria, costo de nube y beneficios esperados de la automatización. El presupuesto no se justifica por “tener mejores datos”, sino por proteger EBITDA y habilitar resultados medibles.
3. ¿Se pueden usar documentos de SharePoint, ERP, CRM o sistemas heredados en una solución de IA? Sí, siempre que exista autorización de uso, acceso controlado, metadatos, identificación de versiones, trazabilidad y mecanismos de actualización. También debe evaluarse si la IA recupera la fuente correcta y respeta los permisos del usuario. Conectar un repositorio no significa que su contenido esté listo para utilizarse.
Antes de invertir en IA, confirma que tus datos pueden sostenerla
Scanda ayuda a las empresas a pasar de información dispersa y pilotos aislados a una base de datos confiable, gobernada y preparada para automatización inteligente.
Evaluamos:
- Viabilidad del caso de uso.
- Calidad y representatividad de los datos.
- Integraciones y arquitectura.
- Gobierno, privacidad y seguridad.
- Trazabilidad y documentación.
- Riesgo financiero y operativo.
- Capacidad de escalar.
- Retorno esperado.
El resultado es una ruta priorizada que permite decidir qué corregir, qué integrar y qué casos de IA pueden avanzar sin convertir la innovación en otra fuente de deuda técnica.
Solicita una sesión de AI Value Discovery con Scanda y determina si tus datos están listos antes de comprometer presupuesto, infraestructura y operación.
Español 
English