Cómo preparar los datos de tu empresa para que la IA sirva de algo (y no se quede en demo bonita)

La razón número uno por la que un proyecto de IA en empresa no llega a producción no es el modelo, ni el proveedor, ni el presupuesto. Es que preparar los datos para IA empresa se trata como un detalle técnico cuando es la mitad del proyecto. Casi todo el mundo descubre esto tarde: contrata el piloto, monta el agente, lo conecta a “los datos” y a las dos semanas el copiloto está alucinando precios desactualizados, citando políticas de hace tres años o dando contestaciones contradictorias según en qué carpeta del Drive haya pescado el contexto.

En Everglow entramos en empresas medianas y grandes españolas como implantadora de IA, y la conversación que más repetimos en las primeras semanas es esta: tus datos no están listos, y eso no es un problema de IA, es un problema de empresa. Este artículo es la versión condensada de cómo abordamos esa fase, qué priorizamos, qué dejamos fuera y qué arquitectura mínima necesitas para que un LLM aporte algo más que una sensación de modernidad.

Por qué la calidad de los datos decide el ROI de tu IA

Un LLM es una máquina de razonar sobre el contexto que le das. Si el contexto es bueno, las respuestas son útiles. Si el contexto es malo, las respuestas son inútiles con una seguridad alarmante. Un agente que cita una política caducada con tres notas a pie de página suena más fiable que uno que dice “no lo sé”, y ese es exactamente el peligro: la confianza generada no se corresponde con la calidad de la fuente.

La consecuencia operativa es simple. Si la base documental que alimenta tu IA no está curada, el copiloto se convierte en un riesgo: equivoca a empleados nuevos, contradice al departamento legal, propone descuentos que ya no existen y deja a atención al cliente respondiendo cosas que el cliente luego usa contra ti. El proyecto se cancela y la conclusión interna que se queda en la cabeza de dirección es “la IA no funciona en nuestro caso”, cuando lo que falló fue la fontanería de datos.

Un copiloto interno con datos sucios no es un activo, es un pasivo. Genera respuestas plausibles a partir de fuentes incorrectas, y eso erosiona la confianza más rápido que no tener IA en absoluto.

Inventario de datos: lo primero que casi nadie hace bien

Antes de pensar en modelos, embeddings o agentes, necesitas un inventario serio de las fuentes de datos que tu IA va a consumir. No vale “tenemos todo en el Drive”. Un inventario útil distingue cinco categorías y, para cada fuente, anota propietario, frecuencia de actualización, sensibilidad y estado actual:

• Datos estructurados internos. CRM, ERP, base de datos de producto, tablas de pedidos, sistema de tickets. Suelen ser los más limpios y los que peor se aprovechan, porque la mayoría de implantaciones empiezan por documentos en lugar de por tablas.
• Documentación operativa. Procedimientos, políticas internas, manuales de proceso, FAQs internas. Aquí es donde más versiones contradictorias conviven, porque casi nadie ha hecho limpieza desde 2021.
• Conocimiento tácito en correo y chat. Hilos de email importantes, decisiones tomadas por Slack, conversaciones de WhatsApp con clientes. Suele ser oro si se filtra, basura si se ingiere en bruto.
• Contenido externo de referencia. Documentación de proveedores, normativa aplicable, contratos marco. Puede o no entrar en el RAG según el riesgo y los derechos de uso.
• Datos generados por procesos automatizados. Logs, exportaciones, dashboards. Útiles para análisis, peligrosos si el agente los lee como “fuente de verdad” sin contexto.

Mientras no sepas qué tienes, no puedes decidir qué subir, qué dejar fuera y qué necesita una pasada de limpieza previa. Y sin esa decisión, vas a indexar todo y rezar — que es exactamente como llegan los pilotos a la fase de “no nos fiamos del agente”.

Los cinco problemas de datos que te van a frenar

Después de auditar varias docenas de empresas, los bloqueos se repiten. Si te ves en alguno, ya sabes por dónde empezar:

1. Duplicados con versiones distintas. El mismo procedimiento existe en tres carpetas, con tres redacciones, y todas se actualizaron en momentos distintos. El RAG indexa las tres y el copiloto cita la peor.
2. Documentos vivos sin marcar. Borradores, plantillas y “drafts internos” mezclados con la versión final. Si tu sistema no distingue versión publicada de borrador, la IA tampoco lo hará.
3. PDF escaneados sin OCR decente. Mucha empresa todavía guarda contratos y políticas como imágenes dentro de PDFs. Sin pasada de OCR (y revisión), esa información es opaca para cualquier LLM.
4. Permisos heredados desordenados. Carpetas compartidas con todo el equipo “porque era más fácil”. Cuando metes un copiloto encima, multiplica el problema: ahora cualquiera puede preguntar y obtener síntesis de información que no debería ver.
5. Datos personales mezclados con datos operativos. Hojas de cálculo con nóminas en la misma carpeta que procedimientos. Antes de tocar nada, esto se separa, porque el día que tu agente filtre un dato personal el problema deja de ser técnico.

Ninguno de estos cinco se arregla con tecnología. Se arreglan con una decisión, un dueño y un par de semanas de trabajo poco glamuroso. Pero saltárselos garantiza que el proyecto fracase.

Arquitectura mínima viable de datos para IA en empresa

No hace falta un data lake ni un proyecto de gobernanza de doce meses para empezar. Con esta arquitectura mínima, una empresa mediana puede tener su primera implantación seria en producción en seis a ocho semanas:

• Una capa de fuentes con conectores claros a CRM, ERP, sistema documental y un par de canales internos (Notion, Slack, correo). Cada conector con permisos de lectura limitados a lo que la IA necesita.
• Una capa de normalización que limpia, deduplica, marca versiones y convierte todo a un formato común (texto plano + metadatos). Aquí entra el OCR, la extracción de tablas y el etiquetado por área de negocio.
• Una capa vectorial con embeddings actualizados de forma incremental, no recreados cada noche desde cero. Si tu pipeline tarda doce horas en reindexar, no sobrevive a una empresa real.
• Una capa de control de acceso que respete los permisos del origen. El agente no debería poder leer en respuesta a un usuario lo que ese usuario no podría leer él mismo abriendo la carpeta.
• Una capa de observabilidad que registre qué fragmentos se han recuperado para cada respuesta, con qué scoring y desde qué fuente. Sin esto no puedes auditar errores ni corregir el sistema.

Esto no es teoría: es exactamente la espina dorsal sobre la que Everglow construye implantaciones que sobreviven al primer trimestre. Sin esta arquitectura, cada error del agente es un misterio. Con ella, cada error es una incidencia rastreable que se cierra en horas, no en semanas.

Cuánto cuesta esta fase y por qué nadie quiere venderla

La parte incómoda: preparar los datos para IA empresa cuesta dinero, no es vistosa y no genera demos para enseñar al consejo. Por eso casi ningún proveedor la vende como producto principal. Es más fácil enseñar un chatbot brillante que explicar tres semanas de OCR, deduplicación y reorganización de permisos.

En la práctica, en una empresa mediana, esta fase suele ocupar entre un 30 % y un 50 % del coste total del primer proyecto serio de IA. Quien te diga que se puede hacer “sobre la marcha” o que “el RAG ya limpia eso por ti”, o no ha implantado nada en producción, o te está vendiendo humo. La buena noticia es que esta inversión es transversal: una vez tienes los datos en condiciones, todos los siguientes proyectos de IA aprovechan el mismo trabajo. El segundo agente cuesta la mitad. El tercero, una cuarta parte.

Cómo medir que tus datos están listos antes de implantar

No hace falta un comité ni un framework propio. Con cuatro métricas simples, sabes si puedes pasar a la fase de implantación o necesitas otro mes de trabajo previo:

• Cobertura útil: porcentaje de las preguntas reales del área que tu base documental puede responder sin recurrir a conocimiento externo. Si es menor del 70 %, tu RAG va a alucinar mucho.
• Frescura: edad media de los documentos críticos. Si tu manual de procesos lleva tres años sin tocarse, el agente va a hablar de un mundo que ya no existe.
• Conflictividad: cuántos documentos del corpus se contradicen entre sí cuando un humano los lee en frío. Si encuentras más de cinco contradicciones serias en una muestra de cien documentos, hay que limpiar antes de indexar.
• Trazabilidad: porcentaje de documentos cuya autoría, fecha y estado (vigente, derogado, borrador) están claros. Sin trazabilidad, no se puede auditar al agente.

Si esas cuatro métricas están en verde, ya puedes hablar de modelos, agentes y experiencia de usuario. Si están en rojo, ningún proveedor va a salvarte el proyecto por mucho que prometa.

Conclusión: el cuello de botella no es el modelo, son tus datos

La conversación pública sobre IA en empresa sigue obsesionada con qué modelo elegir, qué proveedor cerrar y qué herramienta lanzar antes que la competencia. La realidad operativa es mucho más aburrida y mucho más decisiva: el cuello de botella casi siempre está en los datos, no en el modelo. Las empresas que entienden esto antes ganan dieciocho meses de ventaja respecto a las que descubren el problema después de tres pilotos fallidos.

Si tu empresa está en el momento de “vamos a implantar IA en serio” y no quieres descubrir esto a las malas, este es el orden correcto: primero auditas datos, luego decides arquitectura, luego eliges modelo, y solo entonces hablas de casos de uso concretos. Si necesitas a alguien que recorra ese camino contigo en lugar de venderte un producto cerrado, en Everglow montamos exactamente este tipo de implantación. Cuéntanos por dónde estás y vemos si encajamos en contacto.