📌 En resumen
Antes de lanzar un proyecto de IA, es imprescindible evaluar si tus datos cumplen unos mínimos de calidad, consistencia y accesibilidad. No se necesitan datos perfectos, pero sí suficientes registros históricos, campos clave completos y un formato que permita al modelo aprender patrones reales del negocio. Como referencia, la mayoría de modelos predictivos necesitan al menos 12 meses de histórico limpio con las variables relevantes bien identificadas.
«Tenemos datos. Muchos datos. Pero no sabemos si sirven para hacer algo con IA.» Esta frase aparece en la mitad de las primeras conversaciones que tenemos con empresas que quieren empezar un proyecto de inteligencia artificial. Y es una pregunta honesta, porque la calidad de los datos es lo que determina si un proyecto de IA dará resultados o será una frustración cara.
La buena noticia: evaluar si tus datos están preparados no requiere un consultor ni un proyecto de tres meses. Puedes hacerte una idea bastante fiable con unos criterios claros y un par de horas de trabajo.
¿Cómo saber si tus datos son realmente útiles para IA?
Casi todas las empresas con más de 5 años de vida tienen datos. El problema rara vez es la cantidad. Es la calidad, la consistencia y la accesibilidad. Un data lake con millones de registros no vale nada si la mitad están duplicados, un tercio tiene campos vacíos y el resto cambia de formato cada trimestre.
Para un proyecto de IA —ya sea un modelo predictivo, un sistema de clasificación o un copilot con datos internos—, lo que necesitas es que los datos sean fiables, consistentes y accesibles. No perfectos: fiables.
5 criterios para evaluar si tus datos están preparados
1. Completitud
¿Faltan campos importantes en tus registros? Si tu tabla de clientes tiene el 40% de los emails vacíos o tu historial de ventas no incluye el margen porque «eso lo lleva contabilidad», hay un problema. No necesitas el 100% de completitud, pero sí que los campos críticos para tu caso de uso estén razonablemente cubiertos.
2. Consistencia
¿Un mismo concepto se registra igual en todos los sistemas? Si en el CRM un cliente se llama «Industrias García S.L.» y en el ERP aparece como «IND GARCIA» y en la hoja de comisiones es «García Ind.», cruzar esos datos requiere un trabajo manual que puede invalidar cualquier análisis automático.
3. Actualización
¿Los datos reflejan la realidad actual? Un CRM con 10.000 contactos de los cuales 6.000 no se han actualizado en tres años no es una base de datos de clientes: es un cementerio de registros. Para un modelo predictivo, los datos recientes son mucho más valiosos que los históricos si estos últimos están desactualizados.
4. Accesibilidad
¿Se pueden extraer los datos de forma automática? Si la única forma de sacar datos del ERP es que alguien haga un export manual a Excel cada lunes, hay un cuello de botella. Un proyecto de IA necesita acceso programático a los datos: una API, una conexión a base de datos o al menos exports automatizados.
5. Volumen histórico
¿Hay suficiente historia para entrenar un modelo? Para un modelo predictivo de demanda necesitas al menos 18-24 meses. Para un modelo de churn, 12 meses mínimo. Para un sistema de clasificación documental, unos cientos de documentos etiquetados. La cantidad exacta depende del caso de uso, pero si solo tienes datos de los últimos 3 meses, la mayoría de modelos predictivos no van a funcionar.
Problemas de calidad que matan un proyecto de IA
Estos son los problemas que vemos con más frecuencia y que pueden hacer inviable un proyecto si no se resuelven antes:
- Duplicados masivos en el CRM: el mismo cliente aparece 3-5 veces con variaciones del nombre. Cualquier análisis por cliente queda distorsionado.
- Campos de texto libre donde debería haber categorías: si el motivo de una incidencia se registra como texto libre en lugar de una lista cerrada, clasificar automáticamente se vuelve diez veces más difícil.
- Datos de ventas sin margen o sin coste: si solo registras facturación pero no coste, cualquier análisis de rentabilidad requiere cruzar con contabilidad, que probablemente tiene otra estructura.
- Históricos que cambian de formato cada año: si en 2023 los productos se clasificaban de una forma y en 2025 de otra, el modelo necesita una tabla de equivalencias que alguien tiene que construir a mano.
Cómo hacer un diagnóstico rápido
No necesitas un proyecto formal para evaluar el estado de tus datos. Puedes hacer un diagnóstico básico en una tarde siguiendo estos pasos. Si después necesitas un análisis más profundo, un servicio de gobierno del dato y calidad te da un mapa completo con recomendaciones accionables.
- 1Exporta las 3-4 tablas de datos principales que usarías en tu proyecto de IA (ventas, clientes, productos, incidencias…).
- 2Mira la completitud: ¿qué porcentaje de campos críticos están vacíos? Si supera el 20%, hay trabajo previo.
- 3Busca duplicados: ¿cuántos registros de cliente o producto están repetidos con variaciones?
- 4Comprueba la consistencia: ¿los mismos conceptos se registran igual en diferentes sistemas?
- 5Revisa el histórico: ¿cuántos meses de datos limpios y consistentes tienes?
💡 Consejo
Si al hacer este ejercicio descubres que más del 30% de tus datos tienen problemas evidentes, no significa que no puedas hacer IA. Significa que tu primer proyecto debería incluir una fase de calidad de datos. Es mejor saberlo antes que descubrirlo en la semana 6 de un proyecto que iba a durar 8.
Si tus datos no están listos, qué hacer antes
Que los datos no estén perfectos no significa que haya que parar. Un sprint de calidad de datos de 2-4 semanas puede desbloquear un proyecto: limpiar duplicados, estandarizar categorías, completar campos críticos y documentar reglas de calidad. Es una inversión que beneficia no solo al proyecto de IA, sino a toda la operativa de la empresa. Y si ya tienes claro que necesitas un proyecto de inteligencia artificial aplicada, empezar con una fase de preparación de datos es la forma más segura de asegurar resultados.
El peor escenario no es tener datos malos. Es asumir que son buenos sin comprobarlo y montar un proyecto de IA sobre cimientos que no aguantan.
⚠️ Atención
Esto es exactamente lo que se aprende trabajando con datos: que una consulta o una carga se ejecute sin errores no significa que el resultado sea correcto. Ese mismo criterio de comprobar volumen, consistencia y valores antes de confiar en un dato aplica igual de bien a un pipeline de IA que a cualquier ETL tradicional.
Cómo cambia el listón según el tipo de proyecto
| Tipo de proyecto | Qué dato debe estar más fuerte | Qué tolera peor |
|---|---|---|
| Modelo predictivo | Histórico, granularidad y consistencia temporal | Huecos largos, categorías cambiantes y falta de etiquetas |
| Automatización con IA | Campos operativos fiables y criterios de validación | Texto libre descontrolado y excepciones no documentadas |
| Copilot o RAG | Documentación clara, permisos y trazabilidad | Versiones duplicadas, PDFs escaneados sin estructura y ausencia de ownership |
Mini checklist para salir de la duda en una mañana
- 1Elige un caso de uso concreto, no hacer IA en general.
- 2Revisa 2-3 fuentes reales y no la versión idealizada que se cuenta en reuniones.
- 3Comprueba si los campos críticos pueden extraerse sin trabajo manual heroico.
- 4Valida con negocio si las definiciones son estables o cambian según quién mire.
- 5Decide si el siguiente paso es un quick win de calidad, una base de datos mejor o directamente un proyecto.
Si fallas en dos o más criterios, no significa que debas parar para siempre. Significa que antes conviene reforzar la plataforma de datos, activar algo de gobierno del dato y calidad o revisar requisitos más específicos, como los de una base documental para RAG o los de un proyecto de predicción de demanda.
Si te interesa profundizar, en gobierno del dato en pymes: guía práctica exploramos este tema en detalle.
Si te interesa profundizar, en calcular el roi de un proyecto de datos o ia exploramos este tema en detalle.
Si te interesa profundizar, en master data management: cuándo lo necesitas exploramos este tema en detalle.
Si te interesa profundizar, en justificar proyecto de datos ante dirección exploramos este tema en detalle.
Si te interesa profundizar, en datos propios vs terceros en ia: cuál usar exploramos este tema en detalle.
Si te interesa profundizar, en big data en empresa: beneficios y cómo empezar exploramos este tema en detalle.
Para más contexto, puedes consultar la informe de Gartner sobre datos listos para IA.
Preguntas frecuentes sobre calidad de datos antes de IA
¿Necesito datos perfectos?
No. Necesitas datos suficientemente fiables para el caso de uso que quieres resolver. La perfección rara vez existe; la consistencia y trazabilidad sí pueden construirse.
¿Qué suele fallar más: volumen o calidad?
En pymes suele fallar más la calidad y la accesibilidad que el volumen puro. Muchas veces hay datos de sobra, pero mal definidos, duplicados o difíciles de extraer.
¿Esto se puede revisar sin hacer un proyecto largo?
Sí. Un diagnóstico corto y bien enfocado suele bastar para saber si conviene avanzar, limpiar primero o cambiar el alcance inicial.
Siguiente paso recomendado
Gobierno del dato y calidad
¿Tus datos están listos para IA? El primer paso es definir reglas de calidad, responsables y trazabilidad.
Sin compromiso · Respuesta en < 24h
Autor
Fundador y Consultor de Datos e IA
David Aldomar es fundador y consultor principal de MERIDIAN Data & IA, consultora especializada en ayudar a pymes y empresas medianas en España a tomar mejores decisiones con sus datos. Su trabajo se centra en cuatro áreas: diseño e implantación de plataformas de datos (data warehouses, pipelines ETL con dbt, integración de ERPs y CRMs), reporting y dashboards ejecutivos en Power BI, automatización de procesos de negocio con herramientas como n8n, y desarrollo de soluciones de inteligencia artificial aplicada — desde modelos de forecasting de demanda hasta copilots internos basados en RAG con LangChain y FastAPI. Ha liderado proyectos en sectores como logística y transporte, retail y distribución, servicios financieros, manufacturing y construcción, siempre con un enfoque pragmático: diagnóstico corto, entregables concretos y transferencia de conocimiento al equipo del cliente para que sea autónomo desde el primer día. Antes de fundar MERIDIAN, trabajó como ingeniero de datos y BI en entornos empresariales reales: arquitecturas Data Warehouse por capas (Bronze/Silver/Gold), pipelines ETL/ELT en AWS (S3, Glue, Redshift Serverless, Athena) y stacks Microsoft (SQL Server, Power BI, Azure), integrando fuentes tan dispares como ERPs, CRMs y bases de datos operacionales — PostgreSQL, MariaDB — en una única fuente fiable para negocio, finanzas y reporting. Tiene un Máster en Ciencia de Datos e Ingeniería del Dato en la Nube. Su filosofía es que un buen proyecto de datos no se mide por la tecnología que usa, sino por las decisiones de negocio que permite tomar. Escribe regularmente en el blog de MERIDIAN sobre reporting, gobierno del dato, automatización e IA aplicada, con guías prácticas orientadas a responsables de negocio y equipos técnicos de empresas que quieren sacar partido real a sus datos sin depender de grandes consultoras.
Fuentes
Contenido y servicios relacionados
- Plataforma de datos — centraliza y consolida tus fuentes antes de escalar
Si el problema es que los datos están dispersos en silos sin integrar, una plataforma de datos centralizada es el paso previo a cualquier proyecto de IA.
- Gobierno del dato y calidad
Reglas, trazabilidad y ownership para que los datos aguanten reporting, automatización e IA.
- Base de conocimiento para IA: requisitos para RAG
Qué debe cumplir tu documentación interna antes de alimentar un copilot o asistente.
- Requisitos para predicción de demanda
Cómo validar si el histórico y la estructura del dato son suficientes para forecasting.
- Inteligencia artificial
- Cómo preparar tus datos para un proyecto de IA
Guía paso a paso para limpiar, estructurar y documentar los datos antes de un proyecto IA.
