Una de las frases que más escuchamos en el taller de entrada con un cliente: "Tenemos miles de documentos, bases de datos, historial de registros de servicio, correos de clientes — datos no nos faltan." Técnicamente, es verdad. Pero cuando preguntamos cómo es un registro representativo y de dónde viene exactamente, empiezan a aflorar las sorpresas: archivos guardados en tres versiones distintas de SharePoint, registros duplicados con valores contradictorios entre sí, documentos escaneados como imágenes sin OCR, hojas de Excel con nombres de columnas con sentido solo para quien las creó en 2018.
La preparación de datos es, según varios estudios, el factor diferenciador clave entre los proyectos de IA que alcanzan valor medible y los que terminan como pilotos abandonados. Este artículo no trata de qué modelos desplegar. Trata de lo que hay que hacer antes de llegar siquiera a los modelos.
Por qué "tenemos datos" ≠ "los datos están listos"
La preparación de datos para IA tiene una definición distinta a "los datos están almacenados en algún lugar". Un modelo — ya sea para un pipeline RAG o para fine-tuning — necesita los datos en un estado concreto:
- Legibles por máquina: texto extraído de PDFs, imágenes y tablas en formato estructurado
- Consistentes: las mismas entidades nombradas de la misma manera (el cliente "ACME s.r.o." vs. "Acme SR" vs. "ACME Slovakia" son para el modelo tres entidades distintas)
- Relevantes y limpios: sin duplicados, sin versiones obsoletas, sin "ruido" interno (registros de prueba, datos de sandbox, documentos en borrador)
- Correctamente anotados o estructurados: el modelo debe saber qué representan los datos, no solo ver texto en bruto
- Accesibles y gestionables: propiedad clara, versión, fecha de vigencia, permisos de acceso
El Cisco AI Readiness Index indica que solo ~34 % de las empresas valora su preparación de datos como suficiente para el despliegue de IA. Desde nuestra experiencia en campo, ese número suena optimista — la mayoría de los proyectos dedica el primer tercio del engagement precisamente a la preparación de datos, no a los modelos.
Fase 1: Inventario — qué tenemos realmente
Antes de cualquier decisión técnica, es necesario mapear las fuentes de datos existentes. En la práctica, eso significa responder a estas preguntas:
¿Dónde están los datos físicamente?
- Bases de datos (PostgreSQL, MySQL, MSSQL, Oracle)
- Discos compartidos y sistemas de documentos (SharePoint, Google Drive, NAS)
- Sistemas ERP / MES / SCADA (SAP, Infor, Siemens WinCC, Ignition)
- Correo electrónico y herramientas de comunicación
- Documentación en papel escaneada como imágenes
- Logs de máquinas y datos de sensores (MQTT, OPC-UA, bases de datos industriales como InfluxDB)
Cada fuente tiene un formato diferente, una frecuencia de actualización distinta, un grado de estructuración diferente y permisos de acceso propios. El listado de todas las fuentes es el primer artefacto del proyecto de pipeline de datos.
¿Cuál es la calidad?
Para cada fuente, estimar:
- Completitud porcentual de los campos clave (¿qué porcentaje de registros tiene todos los campos obligatorios rellenos?)
- Consistencia de formato (¿las fechas están siempre en el mismo formato? ¿Las categorías provienen de un catálogo fijo o son texto libre?)
- Duplicación (¿existen registros que representan la misma entidad más de una vez?)
- Vigencia (¿cuándo se verificó el registro por última vez? ¿Existen versiones obsoletas?)
Esta auditoría no tiene que ser perfecta — el objetivo es identificar los problemas críticos que bloquearían el proyecto, no alcanzar una limpieza del cien por cien antes del arranque.
¿Quién es propietario de los datos?
Para cada fuente: ¿quién es responsable del contenido? ¿Quién tiene autorización para modificar el acceso? ¿Quién puede explicar qué significa un registro? Sin una propiedad clara de los datos, el proyecto de IA puede quedar atascado en disputas interdepartamentales sobre quién aprueba que su base de datos se use para entrenamiento o retrieval.
Fase 2: Extracción y normalización
Una vez conocidas las fuentes, comienza el trabajo técnico: llevar los datos a un formato unificado con el que pueda trabajar el pipeline.
Extracción desde fuentes estructuradas
Desde bases de datos relacionales y sistemas ERP, la extracción es relativamente directa — consultas SQL, llamadas a APIs, exportación a CSV. Lo crítico es definir:
- 1.Qué tablas / campos son relevantes para el caso de uso concreto (no extraer todo el ERP)
- 2.Cuál es la frecuencia de actualización (batch una vez al día, o streaming de cambios mediante CDC — Change Data Capture)
- 3.Cómo se mapean los nombres técnicos de los campos a denominaciones comprensibles para humanos (columna
ord_stat_cd→ "estado del pedido")
Extracción desde fuentes no estructuradas
Los documentos, correos, planos técnicos y formularios escaneados son más exigentes. Los pasos necesarios:
- OCR para documentos escaneados: herramientas como Tesseract, Azure AI Document Intelligence o Google Document AI pueden extraer texto de imágenes y PDFs. La calidad del output del OCR influye directamente en la calidad de las respuestas del modelo.
- Chunking: los documentos largos deben dividirse en segmentos más pequeños antes de la vectorización. El chunking ingenuo a 512 tokens cortando en mitad de una frase es una fuente habitual de problemas en la calidad del pipeline RAG. Es mejor hacer chunking por unidades lógicas (párrafos, secciones, tablas).
- Extracción de metadatos: cada chunk debe llevar metadatos — de dónde proviene, fecha de creación, vigencia, autor y, si procede, categoría. Estos metadatos sirven para filtrar en el retrieval y para mostrar la fuente en la respuesta.
Normalización de entidades
La misma empresa con tres grafías distintas es para el modelo vectorial tres entidades distintas con embeddings similares, pero para la búsqueda difusa o el filtrado es un problema. La resolución de entidades — unificación de las distintas grafías de la misma entidad — es un trabajo que a veces se realiza manualmente (catálogos de clientes), a veces de forma semiautomática (fuzzy matching sobre nombres de empresa) y a veces con LLM (cuando los registros están en lenguaje natural).
Fase 3: Limpieza y validación de calidad
La limpieza de datos es un proceso iterativo. No es posible hacerlo una vez de forma perfecta — aparecen datos nuevos, cambian los formatos, surgen nuevos patrones de errores.
Pasos concretos que vemos en la práctica
- Eliminación de duplicados: identificar registros que representan la misma información con identificadores distintos
- Corrección de errores de formato: fechas en formatos dispares, valores numéricos con la unidad escrita en el campo, números de teléfono con distintos formatos de prefijo
- Tratamiento de valores ausentes: completar donde sea posible, marcar explícitamente donde falta, decidir la exclusión cuando un registro sin campo obligatorio no es utilizable
- Filtrado de datos irrelevantes: registros de prueba, entornos sandbox, notas internas, documentos clasificados como "borrador" o "archivo"
- Verificación de vigencia: en bases de conocimiento y pipelines RAG, una información obsoleta es a veces peor que ninguna información. Tarifas de hace dos años, fichas técnicas de productos descatalogados — deben tener una fecha explícita en los metadatos o quedar excluidos.
La limpieza para la preparación del dataset de fine-tuning tiene además una capa especial: cada ejemplo de entrenamiento debe tener la forma correcta de par entrada-salida, la salida debe ser correcta (no "nuestra mejor estimación"), y el dataset debe cubrir los temas principales del dominio de forma equilibrada. Los huecos en el dataset se traducen en puntos ciegos del modelo.
Fase 4: Estructura y permisos de acceso
Uno de los aspectos más subestimados de la preparación de datos es quién puede ver qué. En entornos enterprise existen capas de permisos de acceso:
- Contratos comerciales y precios que solo puede ver el equipo comercial
- Registros de RRHH que solo puede ver el departamento de RRHH
- Documentación técnica que es pública internamente pero no puede llegar a los clientes
- Documentación regulatoria que debe ser auditable y no puede modificarse sin registro
Cuando despliega un sistema RAG con acceso a toda la base de conocimiento sin respetar estos permisos, y un empleado del equipo comercial pregunta por los costes de producción (que solo puede ver el director de producción) — el sistema responde. Eso no es una funcionalidad, es un incidente de seguridad.
La solución correcta: los permisos de acceso deben trasladarse también a la base de datos vectorial. Cada documento o chunk debe llevar metadatos sobre quién puede acceder a él. En el retrieval se filtra no solo por relevancia, sino también por si el usuario solicitante tiene acceso. Esta es una arquitectura no trivial, pero en despliegues en sectores regulados (GDPR, secreto comercial) es obligatoria.
Fase 5: Pipeline y actualidad
El pipeline de datos para IA no es una acción puntual — es un proceso continuo. Los datos empresariales cambian cada día. Nuevos pedidos, nuevos documentos, precios actualizados, fichas técnicas revisadas.
Tipos de arquitecturas de pipeline
- Pipeline batch (una vez al día / a la semana): extracción, limpieza y re-indexación de la base de conocimiento a intervalos regulares. Adecuado para la mayoría de los sistemas RAG documentales — una tolerancia de 24 horas de "staleness" es aceptable en la mayoría de los casos de uso.
- Streaming / casi en tiempo real: los cambios en el sistema fuente se propagan a la base de datos vectorial en cuestión de minutos. Necesario para casos de uso en los que los datos envejecen rápidamente (sistemas de ticketing, inventario en vivo, señales de trading). Requiere una arquitectura CDC (Change Data Capture).
- Verificación human-in-the-loop: para datos sensibles (protocolos médicos, documentos legales, manuales de seguridad), cada cambio en la base de conocimiento pasa por aprobación humana antes de aparecer en el índice de retrieval.
La elección de la arquitectura depende de la frecuencia de cambio en los datos fuente y de la tolerancia del caso de uso a la obsolescencia. Para la mayoría de los casos de uso B2B empresariales, el pipeline batch es suficiente — más sencillo de operar, más económico, suficientemente actualizado.
Monitorización de la calidad de datos
El pipeline debe tener alertas sobre anomalías de datos: una caída repentina en el número de documentos (posible eliminación del repositorio fuente), un aumento en la proporción de campos vacíos (cambio de formato en el sistema fuente), duplicados por encima de un umbral (fallo en la deduplicación). Sin monitorización, los problemas de datos solo se detectan cuando el modelo empieza a dar respuestas incorrectas — y no siempre es trivial rastrear la causa hasta el origen.
Fase 6: Gobernanza y documentación
Esta es la parte que los equipos técnicos no hacen con gusto, pero sin la cual el proyecto de IA se desmoronará al escalar.
Qué debe estar documentado
- Data dictionary: para cada fuente de datos y cada campo relevante — qué es, en qué formato, quién es su propietario, cuándo se verificó por última vez
- Lineage: de dónde provienen los datos, qué transformaciones han sufrido, dónde están ahora — capacidad de rastrear un output concreto del modelo hasta el documento fuente concreto
- Change log de la base de conocimiento: cada cambio en el índice de retrieval debe quedar registrado — qué se añadió, qué se modificó, qué se eliminó y cuándo
- Permisos de acceso y su historial: para la conformidad con el GDPR y en auditorías, se necesita el historial de quién tuvo acceso a qué y cuándo
Estos requisitos no son específicos de la IA — son estándares de data governance que las empresas maduras aplican a cualquier sistema crítico. La IA simplemente los pone en evidencia, porque los outputs del modelo son directamente visibles e influyen en las decisiones.
Errores típicos que vemos en la práctica
Antes de la conclusión, algunos patrones que se repiten:
- "Le damos todo el SharePoint": el volumen no es el problema, la relevancia sí. Un modelo que indexa 50 000 documentos incluyendo presentaciones de 2015, archivos de prueba y actas de reuniones internas tendrá una precisión de retrieval inferior a un modelo que indexa 2 000 documentos cuidadosamente seleccionados y limpios. Menos y mejor es casi siempre superior a más y de baja calidad.
- "Lo resolvemos más adelante": la calidad de los datos en proyectos de IA no se corrige "más adelante". Si lanza a producción un sistema RAG con datos de baja calidad, los usuarios dejarán de confiar en él rápidamente — y recuperar la confianza es mucho más difícil que construirla desde el principio.
- "Nuestros datos son sensibles, pero no nos importa": el GDPR y la legislación sobre secreto comercial se aplican también a los sistemas de IA. Si su base de conocimiento contiene datos personales, contratos con NDA o información comercial confidencial, debe tener una base jurídica coherente para su tratamiento también en el pipeline de IA.
- "Hacemos fine-tuning con lo que tenemos": como describimos en el artículo sobre preparación del dataset de fine-tuning, un volumen insuficiente o una cobertura deficiente del dominio en los datos de entrenamiento produce un modelo que responde con seguridad pero de forma incorrecta — lo cual es peor que un modelo que dice "no sé". La suficiencia de datos es una condición previa al fine-tuning, no un supuesto optimista.
Pasos prácticos para empezar
Si quiere comenzar sin perderse en la teoría:
- 1.Elija un caso de uso, no "toda la empresa". Un problema concreto (respuestas a consultas técnicas de clientes, búsqueda en documentación de servicio, generación de ofertas a partir del catálogo) tiene un alcance de datos acotado.
- 2.Mapee las fuentes de datos para ese caso de uso — dónde están, qué formato tienen, quién es el propietario, cuál es su vigencia.
- 3.Realice una auditoría de datos sobre una muestra — tome 100 registros aleatorios y evalúe la calidad manualmente. La mayoría de los problemas serán visibles.
- 4.Defina la calidad mínima para el despliegue en producción — no "perfecta", sino "suficientemente buena para el caso de uso".
- 5.Diseñe el pipeline — batch o streaming, permisos de acceso, monitorización.
- 6.Itere: el primer índice será imperfecto. Evalúe la calidad de las respuestas RAG, identifique las causas más frecuentes de respuestas incorrectas, corrija los datos o el pipeline y repita.
Preguntas frecuentes
¿Cuántos datos necesitamos para un sistema RAG?
Para un sistema RAG funcional no existe un número mínimo de documentos — incluso 50 documentos bien preparados pueden dar resultados excelentes si cubren el alcance relevante del dominio. Más crítica que la cantidad es la cobertura: si los usuarios hacen preguntas cuya respuesta no está en la base de conocimiento, el modelo o bien lo reconocerá (guardrail bien configurado) o bien inventará una respuesta (estado incorrecto). Inventaríe las preguntas que el sistema debe ser capaz de responder y verifique si son respondibles con los datos disponibles.
¿Podemos usar datos internos para fine-tuning sin riesgos legales?
Depende de la naturaleza de los datos. Los manuales técnicos internos, los documentos SOP y los registros históricos sin datos personales son típicamente aceptables — pertenecen a la empresa y no contienen PII. Los registros con datos de clientes, contratos o datos personales de empleados requieren una base jurídica según el GDPR (consentimiento, interés legítimo, ejecución de contrato) también para su tratamiento en el pipeline de IA. Recomendamos consultar con el DPO antes de empezar a construir el dataset de entrenamiento a partir de datos regulados.
¿Cuánto tiempo lleva la preparación de datos?
En la práctica vemos un rango que va de dos semanas (una fuente bien definida, buena documentación interna, propietarios de datos colaborativos) a seis meses (datos fragmentados en tres sistemas distintos, data governance inexistente, obstáculos políticos internos para el acceso). El proyecto medio dedica entre el 30 y el 40 % del tiempo total a la preparación de datos. Si el cliente afirma que lo resolverán en una semana, o el alcance es muy pequeño o se está subestimando la magnitud del problema.
¿Necesitamos un data engineer o puede encargarse el desarrollador de IA?
Para casos de uso más sencillos (documentos PDF, exportación simple de SharePoint), el desarrollador de IA puede gestionar la extracción básica y el chunking. Para escenarios más complejos — pipeline de streaming desde sistemas ERP, arquitectura CDC, normalización de entidades entre múltiples fuentes, lineage conforme al GDPR — se necesita un data engineer con experiencia. Subestimar este rol es una de las causas más frecuentes de retrasos en los proyectos de IA.
¿Los datos tienen que estar en español o también funciona en inglés?
Para un sistema RAG sobre documentos empresariales, el idioma de los documentos es el primario — los modelos de embedding se usan de forma multilingüe (modelos como BGE-M3 cubren más de 100 idiomas), y el retrieval funciona bien en ambos idiomas. Para el fine-tuning, el idioma de los datos de entrenamiento es crítico — si quiere un modelo que responda en español profesional con terminología empresarial propia, los ejemplos de entrenamiento deben estar en ese español con esa terminología.
*Si está afrontando la preparación de datos empresariales para un proyecto de IA y quiere evitar errores innecesarios, estaremos encantados de acompañarle en la auditoría de datos y proponer una arquitectura de pipeline adecuada a su caso de uso. Contáctenos para una consulta sin compromiso.*