Los datos que necesitas antes de un proyecto de IA (y no son big data)
Por el equipo de Aito · Actualizado el 10 de agosto de 2026 · 10 min de lectura
Antes de un proyecto de IA no necesitas más datos: necesitas menos datos, definidos igual por todo el mundo y con un dueño claro. La conversación pública ha instalado la idea de que la IA exige volumen —millones de registros, años de histórico, un almacén de datos montado—, y esa idea paraliza a muchas pymes que ya tienen delante lo único que hace falta para empezar: entre cinco y quince campos que describen cómo entra el trabajo, cómo se decide y cómo se cierra. El problema casi nunca es que falten datos. Es que los mismos datos significan cosas distintas según quién los rellene.
Esta distinción no es semántica: cambia la inversión. Preparar un almacén de datos es un proyecto de meses y presupuesto alto. Estandarizar quince campos, asignarles responsable y arreglar la forma en que se capturan es un trabajo de semanas que además mejora la operación aunque el proyecto de IA nunca llegue a hacerse. Uno es una compra tecnológica; el otro es una decisión operativa con retorno propio.
Por qué el mercado confunde volumen con calidad
El malentendido tiene origen. Los casos que se cuentan en prensa vienen de empresas que entrenan modelos propios, y ahí sí manda el volumen. Pero una pyme que va a usar IA en 2026 casi nunca entrena nada: usa modelos ya existentes para clasificar correos, extraer campos de una factura, redactar un borrador, buscar dentro de su documentación o resumir una conversación con un cliente. En ese escenario el modelo no aprende de tu histórico; lee lo que le pasas en cada ejecución. Y lo que le pasas es exactamente el punto débil: si el campo "estado del pedido" tiene once valores posibles porque cada comercial se inventó el suyo, ningún modelo va a devolverte un resultado fiable a partir de ahí.
Hay un segundo motivo, menos técnico. "Nos faltan datos" es una explicación cómoda. Convierte un problema de disciplina interna —nadie ha decidido cómo se registra un cliente, quién cierra una incidencia, qué significa "entregado"— en un problema de infraestructura que se resuelve comprando algo. Comprar es más rápido que acordar. Por eso se compra.
El contexto europeo apunta en la misma dirección. Entre las barreras que declaran las empresas que no han implantado IA, la falta de conocimiento aplicable y las dudas legales y de protección de datos pesan más que la carencia de infraestructura (Eurostat, encuesta de uso de TIC en empresas, 2025). La OCDE señala en pymes una combinación de habilidades, datos, capacidad de cómputo y madurez digital. Ninguna de esas listas dice "les faltan terabytes".
La calidad del dato define el techo de la automatización. El volumen sólo define su coste.
Los cinco atributos que hacen utilizable un dato
Un dato sirve para un proyecto de IA cuando cumple cinco condiciones. No son técnicas: son organizativas. Si falla una, el resultado será inestable por mucho que el modelo sea bueno.
1. Definición única
Una frase escrita que diga qué es ese campo y qué no es. "Fecha de entrega" ¿es la comprometida, la real o la que puso el transportista? Si tres áreas responden distinto, el dato no existe todavía: existen tres datos con el mismo nombre. Esta es la causa más frecuente de que los informes no cuadren, algo que tratamos en detalle en por qué tus informes no cuadran.
2. Dueño identificable
Una persona —con nombre, no un departamento— que decide cómo se rellena, aprueba cambios en su definición y responde cuando algo llega vacío o mal. Sin dueño, la calidad se degrada sola: cada excepción crea un valor nuevo y nadie lo corrige porque nadie tiene el encargo de hacerlo. Un dato sin dueño no se gobierna; se abandona.
3. Origen único y trazable
El mismo dato no puede nacer en dos sitios. Si el precio se teclea en el CRM y también en el sistema de facturación, tarde o temprano divergen y ninguna IA sabrá cuál es el bueno. Cuando el problema es este, la respuesta correcta no es IA sino integración: lo desarrollamos en integración, automatización o IA.
4. Formato estable
Valores cerrados donde se pueda —una lista de estados, no un campo de texto libre—, misma unidad, misma moneda, mismo formato de fecha, mismo criterio para "vacío". Un modelo tolera bien el lenguaje natural del cuerpo de un correo; tolera muy mal que el campo que usas para decidir cambie de forma según quién lo escribe.
5. Base legal y permisos resueltos
Qué datos personales hay ahí, con qué base legal se tratan, quién puede verlos, dónde se procesan y qué se registra de cada uso. No es burocracia: es lo que determina si el caso de uso puede pasar de prueba a producción. El AI Act añade además obligaciones para quien despliega sistemas de IA —entre ellas formación mínima del personal implicado— y prohíbe usos concretos como el reconocimiento de emociones en el entorno laboral, así que conviene comprobarlo antes de diseñar nada, no después.
La ficha de dato: el entregable que casi nadie tiene
Todo lo anterior cabe en una tabla de una página por proceso. La llamamos ficha de dato y es, en la práctica, el entregable que separa un proyecto de IA que aguanta de uno que se cae al tercer mes. Para cada campo relevante del proceso que quieres tocar, anota:
- Nombre y definición en una frase, con un ejemplo de valor correcto y uno incorrecto.
- Dueño: quién decide y quién corrige.
- Sistema de origen y sistemas donde se copia hoy.
- Momento de captura: en qué paso del proceso y por quién se rellena.
- Formato y valores admitidos: lista cerrada, unidad, obligatorio u opcional.
- Calidad actual: porcentaje de registros vacíos o incoherentes, medido, no estimado.
- Uso previsto: qué decisión de la IA depende de este campo.
- Sensibilidad: si contiene datos personales o confidenciales y quién accede.
Con quince fichas tienes más base para un proyecto de IA que con un almacén de datos lleno de campos que nadie sabe interpretar. Y tienes algo más valioso: la lista exacta de lo que hay que arreglar antes, ordenada por impacto.
Seis pasos para preparar los datos sin comprar nada
- Elige un solo proceso, el que más te duele en dinero o en tiempo. No prepares "los datos de la empresa": prepara los de un flujo concreto de principio a fin.
- Lista las decisiones que la IA tendría que apoyar en ese flujo. Clasificar, extraer, priorizar, redactar, avisar. Cada decisión te dirá qué campos necesita, y suelen ser pocos.
- Traza cada campo hasta su origen. Dónde nace, quién lo teclea, en qué momento, cuántas veces se vuelve a escribir después. Aquí aparecen los dobles registros.
- Mide la calidad actual: cuenta vacíos, duplicados, valores fuera de lista e incoherencias entre sistemas. Este número es tu línea base y sin él no podrás demostrar mejora después.
- Cierra definición, dueño y formato campo a campo. Es una reunión de una hora por área, no un proyecto. Lo difícil no es documentarlo: es que las áreas acepten una sola versión.
- Arregla la captura, no el histórico. Cambia el formulario, el campo obligatorio, la lista desplegable o el paso del proceso que genera el dato sucio. Limpiar el pasado sin arreglar el origen es un gasto que se repite cada trimestre, como explicamos en limpieza de datos en el CRM.
Fíjate en lo que no aparece en la lista: comprar una herramienta. Cinco de los seis pasos son trabajo de proceso y acuerdo interno. El sexto suele resolverse con configuración de lo que ya tienes.
¿Sabes qué diez campos sostienen tu proceso crítico?
Si la respuesta no es inmediata, el primer paso no es un proyecto de IA: es mapear el flujo y fijar definiciones y responsables. Eso es lo que hacemos en una consultoría de procesos antes de recomendar ninguna capa tecnológica.
Cuándo sí puedes empezar y cuándo no
Señales de que estás listo
- Los campos que alimentan la decisión tienen definición escrita y una persona responsable.
- Sabes de qué sistema sale cada uno y no se teclea dos veces en sitios distintos.
- Puedes decir, con un número medido, qué porcentaje de registros llega incompleto hoy.
- Existe un revisor humano designado para las salidas del modelo y un criterio de aceptación escrito.
- Tienes claro qué indicador demostraría la mejora: tiempo de ciclo, tasa de error, coste por operación, reaperturas.
Señales de que todavía no
- Dos áreas dan cifras distintas del mismo indicador y nadie tiene autoridad para zanjarlo.
- El campo clave es texto libre y cada persona escribe lo que le parece.
- El proceso tiene tantas excepciones que nadie sabe describir el caso normal. Ahí falta diseño, no IA: lo tratamos en la IA no arregla procesos rotos.
- No hay nadie que pueda revisar las salidas ni tiempo asignado para hacerlo.
- No sabes qué datos personales entran en el flujo ni con qué base legal se tratan.
Una matización importante: "todavía no" no significa "dentro de dos años". Significa que las próximas semanas se dedican a definiciones, dueños y captura, no a elegir herramienta. Es la parte del proyecto con mejor relación entre esfuerzo y retorno, porque mejora la operación aunque después decidas que ese caso de uso no compensa.
Qué medir para justificar la inversión
No se puede prometer un retorno sin diagnóstico previo, pero sí se puede decir qué hay que medir para calcularlo cuando llegue el momento. Antes de tocar nada, registra en el proceso elegido:
- Horas dedicadas hoy a corregir, buscar o reconciliar información entre sistemas.
- Porcentaje de operaciones que se rehacen por un dato mal capturado.
- Tiempo de ciclo del flujo completo y cuánto de ese tiempo es espera por falta de información.
- Número de decisiones que hoy se toman sin el dato correspondiente disponible.
- Coste de los errores que llegan al cliente y se resuelven con abono, repetición o descuento.
Estas cinco cifras son la línea base. Sin ellas, cualquier cálculo posterior de retorno será una opinión con decimales. Con ellas, además, casi siempre descubres que una parte del problema se resuelve sin IA —con una lista desplegable, una validación obligatoria o una integración— y que sólo el resto justifica una capa inteligente. Ese ejercicio de priorización es el mismo que planteamos en cómo calcular el ROI de una automatización.
El marco de gestión de riesgos de IA del NIST ordena esta lógica en cuatro funciones —gobernar, mapear, medir y gestionar— y coloca gobernar como capacidad transversal, no como fase final. Traducido a una pyme: decidir quién responde de cada dato no es papeleo posterior a la implantación; es la condición que hace que la implantación tenga sentido.
Si después de este trabajo el caso de uso sigue en pie, el siguiente filtro es operativo más que informacional: qué entra, quién valida, qué excepciones existen y quién es dueño del proceso completo. Lo recogemos en cinco condiciones antes de un agente de IA.
La conclusión práctica es incómoda para quien esperaba una compra y tranquilizadora para quien temía no estar preparado: tus datos probablemente bastan; lo que falta es acuerdo sobre qué significan y quién responde de ellos. Eso no se compra, se decide.
No necesitas más datos para empezar con IA. Necesitas que los pocos que ya usas signifiquen lo mismo para todo el mundo y que alguien responda cuando no sea así.