El mes pasado, una amiga que lleva la gestión del conocimiento en una empresa mediana me contaba su proyecto más frustrante. La compañía había invertido con seriedad en un asistente interno de preguntas y respuestas: decenas de miles de PDF, archivos de Word y escaneos vertidos de golpe a una base vectorial, con la esperanza de que cada empleado por fin pudiera "hacer una pregunta y recibir la respuesta". ¿El resultado? Los escaneos salían borrosos, los fragmentos recuperados no pintaban nada en la pregunta, y alguien de finanzas llegó a pegar en un chat público un contrato con datos de clientes. El equipo terminó sacando una conclusión a la vez amarga y repetida: el modelo funcionaba de maravilla — lo que no funcionaba era lo que le estaban dando de comer.
La escena se repite en todas partes. En una empresa cualquiera, cada empleado salta entre aplicaciones todo el día: los estudios de atención cifran ese vaivén en 35 aplicaciones diarias. Y cuando una tarea se interrumpe, hacer volver a la persona a su sitio lleva de media 23 minutos. Encontrar una respuesta ya cuesta tiempo de por sí; si el asistente interno responde a otra cosa, todo el mundo vuelve enseguida a rebuscar en las carpetas compartidas — o pega el documento en una herramienta de IA externa, que añade un riesgo nuevo encima del primero.
Así que lo que toca hoy no es hablar de qué modelo elegir, sino de lo que ocurre antes del modelo: cómo un documento corporativo se convierte en algo que la máquina puede "digerir" de verdad. UglyPear Data construyó un producto justo para esa capa, la base de ingeniería de datos RAG — compresión documental de alto rendimiento cruzada con ingeniería de datos para sistemas RAG, desplegada por completo en infraestructura privada, de modo que los datos nunca salen de la red interna.
Qué falla cuando alimentas un modelo con documentos en bruto
Mucha gente asume que un sistema RAG es "trocear los documentos, calcular vectores y guardarlos". En producción se descubre que los documentos corporativos no se parecen en nada al texto limpio de las demostraciones.
El primer tropiezo son los formatos. Un mismo PDF mezcla páginas nativas con páginas escaneadas; entre los documentos de maquetación fija aparece el OFD, un formato propio del mercado chino; las tablas se esconden dentro de imágenes; y el sello oficial cae justo encima del dato decisivo. Trocear todo eso sin tratarlo produce fragmentos que el modelo no entiende, y la búsqueda se descarrila a la primera.
Detrás viene la redundancia. Del mismo contrato hay cinco versiones circulando, unas actas de reunión copiadas ocho veces, y la mitad de una presentación son páginas de plantilla. Todo ese duplicado ocupa sitio en la base vectorial y enturbia los resultados: haces una pregunta y te llegan cinco pasajes casi idénticos, con la respuesta buena hundida al final de la lista.
El tercer tropiezo es el más delicado: la información sensible. El número del documento de identidad en un contrato, la cuenta bancaria en un informe, la dirección de casa en un currículo — en cuanto esos campos entran en el circuito de búsqueda junto con el documento, quien pregunta, los ve. Y si la pregunta se hace en una herramienta pública, son datos de clientes los que salen de la empresa, sin más.
Tres capas de problemas apiladas: eso explica por qué tantos proyectos de "preguntas y respuestas sobre documentos" se quedan sin usuarios a los tres meses de arrancar.
La IA fantasma: el riesgo que ya no se puede mirar hacia otro lado
Ya que salen las herramientas públicas, detengámonos un momento. El informe 2025 de IBM sobre el coste de las brechas de datos trae una cifra que da que pensar: una de cada cinco empresas ha sufrido ya una fuga ligada al uso particular de herramientas de IA por parte de sus empleados — lo que el sector llama "shadow AI". En esas empresas, el coste medio de una brecha supera en 670.000 dólares al de sus comparables. Y hay algo todavía más llamativo: entre las organizaciones que ya han sufrido una fuga, el 63 % sigue sin tener una política escrita de gobernanza de la IA.
Dicho de otro modo, prohibir no resuelve el problema. La gente no usa la IA para traicionar a su empresa, sino porque el canal oficial interno no da respuestas que sirvan. En vez de apilar prohibiciones, toca arreglar el conducto interno: los documentos se limpian, se anonimizan y se comprimen en local antes de entrar en la base de búsqueda, y cada uno recibe respuestas fiables sin salir del sistema de la empresa. Cuando eso funciona, a nadie le compensa pegar un contrato en un cuadro de diálogo ajeno.
Preguntarán: ¿y si simplemente compro una base de conocimiento SaaS del mercado? Se puede — con una condición en la cabeza: en cuanto subes los documentos, tus datos viven en los servidores de otro. En muchos sectores se puede discutir. En finanzas, sanidad, derecho o sector público, contratos, historias clínicas y expedientes son líneas rojas que no se cruzan. El valor de un despliegue privado no es presumir de tecnología más avanzada, sino quedarse con la última palabra sobre el destino de los datos. Esa es la apuesta de UglyPear Data: la base de ingeniería de datos RAG corre por completo dentro del entorno de la empresa, con detección y anonimización automáticas de 13 categorías de información sensible integradas en la cadena. ¿Qué cubren esas 13 categorías? A los campos clásicos — documento de identidad, tarjeta bancaria, número de móvil — se suman estructuras sensibles propias de ciertos sectores, algo práctico en finanzas, sanidad y derecho. Eso sí, para saber si las reglas de anonimización encajan con un negocio concreto, solo hay un camino: probarlas con documentos reales.
Lo de "seis etapas de proceso y ocho familias de capacidades" suena a eslogan, pero desmontado es de lo más terrenal: las etapas son cada eslabón entre la entrada del documento y su incorporación a la base; las capacidades, los oficios reutilizables de un eslabón a otro — compresión, anonimización, estructuración. Para ver qué hace exactamente cada etapa, lo más sensato es pedir la documentación oficial y pasarla por el propio flujo de documentos; se entiende más que escuchando a cualquiera.
Comprimir primero, indexar después: dinero que se nota
El otro extremo del conducto es el coste. En los documentos corporativos, lo que más pesa suelen ser los escaneos y las imágenes: un contrato escaneado de unos cientos de páginas pesa con facilidad varios cientos de megas. Tal cual, en la base, el almacenamiento y la vectorización se cobran su parte.
Ahí es donde la compresión hace el trabajo. El motor de SmartSlim cubre 8 familias de formatos — PDF, imágenes, vídeo, audio, Office, OFD, escaneos — y reduce el volumen entre un 60 % y un 80 %, con todo el procesado ejecutado en la máquina local. La optimización para modelos grandes importa aún más: medida sobre la referencia GPT-4o, el coste en tokens de los contenidos con imágenes baja un 85,9 %. Un documento más ligero y más limpio significa menos llamadas en cada tramo — embeddings, búsqueda, respuesta. UglyPear Data también publicó un caso extremo: un documento OFD de 443 páginas procesado de extremo a extremo en 124 segundos, con sellos y maquetación intactos.
Una duda que aparece siempre: ¿comprimir no estropea el contenido? El modo de alta fidelidad no toca la estructura de maquetación subyacente; elimina solo los datos redundantes. Eso no quita que convenga conservar un hábito sano: antes de indexar, abrir unas cuantas páginas al azar y mirarlas con lupa.
Tres caminos posibles, una misma decisión que aclarar
Recapitulemos en una tabla. Para conectar documentos corporativos con un modelo grande, hay tres caminos:
| Dimensión | Pegar en una herramienta de IA pública | Base vectorial propia, troceado directo | Base de ingeniería de datos primero, indexar después |
|---|---|---|---|
| ¿Salen los datos de la red interna? | Sí, con destino incontrolable | No (siempre que todo sea autoalojado) | No, entorno privado de punta a punta |
| Tratamiento de la información sensible | Ninguno, exposición inmediata | Módulo de anonimización a desarrollar por tu cuenta | 13 categorías detectadas y anonimizadas automáticamente |
| Escaneos y documentos de maquetación fija | Prácticamente inservibles | Troceado de mala calidad, búsqueda inestable | Pretratamiento con compresión fiel, sellos y maquetación conservados |
| Volumen indexado y coste de llamadas | Sin indexación, pegado manual cada vez | Volumen bruto indexado tal cual, caro | Volumen reducido entre 60 % y 80 %, tokens de imagen un 85,9 % más baratos (referencia GPT-4o) |
| Despliegue y mantenimiento | Cero despliegue, riesgos a tu cargo | Cadena de herramientas completa por construir | Seis etapas y ocho familias de capacidades listas para usar |
| ¿Para quién? | Consulta puntual, a título personal | Equipo de desarrollo fuerte y datos poco sensibles | Equipos exigidos a la vez en cumplimiento y en coste |
Una aclaración: esta tabla es un marco de decisión, no un banco de pruebas. Cada empresa tiene su propia mezcla documental y debe ponderar a su manera — un centro de salud pondrá la anonimización en primer lugar, una tienda online mirará primero el coste.
La normativa también empuja, con calendario
Queda una variable externa, menos ruidosa pero bien real. En mayo de 2025, el Ministerio de Finanzas de China junto con otras ocho administraciones publicó la circular Cai Kuai [2025] n.º 9 sobre la generalización del estándar de datos contables para comprobantes electrónicos: los software de contabilidad deben actualizarse para adaptarse a ese estándar antes del 31 de diciembre de 2027. En cristiano: que los documentos corporativos acaben estructurados y legibles por máquina no es ya una iniciativa voluntaria — el calendario está trazado.
La facturación electrónica ya rige en todo el país, con una cobertura superior al 80 %, y el formato de archivo conforme para los justificantes es un XML estructurado con firma digital. Para los próximos años, la pregunta ya no es si la empresa hará ese trabajo de datos, sino a qué ritmo. Quien monte pronto la cadena limpieza-anonimización-estructuración-indexación conectará después normativa, modelos y auditoría sin sobresaltos; quien llegue tarde improvisará a las prisas.
La página del producto de la base de ingeniería de datos RAG de UglyPear Data está aquí. Para la parte de compresión, la página de productos; cómo encajan las dos piezas se explica con más detalle en el blog técnico.
Pruébalo ahora
- Base de ingeniería de datos RAG de UglyPear Data (despliegue privado, anonimización de 13 categorías de información sensible, seis etapas + ocho familias de capacidades): https://www.uglypear.com/
- Página de producto SmartSlim (motor de compresión, versión de escritorio, SDK y API): https://www.uglypear.com/products/
- Blog técnico de UglyPear Data (compresión e ingeniería de datos, actualización continua): https://www.uglypear.com/blog/
Preguntas frecuentes
P: Un proyecto RAG da malos resultados: ¿cambiamos de modelo o curamos antes los datos?
R: Curad antes los datos. En la mayoría de casos de "respuestas que no vienen a cuento", la raíz está en la calidad documental — escaneos borrosos, versiones duplicadas, estructura caótica. Terminad la cadena de limpieza, anonimización y compresión y volved a evaluar: muchos problemas se solos solos. Si invertís el orden, cambiar de modelo cambiará bien poco.
P: ¿La detección de las 13 categorías de información sensible se hace íntegramente en local?
R: Sí. Detección y anonimización corren dentro del entorno privado de la empresa, los datos no salen de la red interna, y las reglas se ajustan según el sector.
P: ¿Un documento comprimido, pasado después al modelo, da respuestas de peor calidad?
R: El modo de alta fidelidad no toca la estructura de maquetación subyacente y elimina solo datos redundantes; el texto queda intacto. En contenidos con imágenes, el coste en tokens baja incluso un 85,9 % sobre la referencia GPT-4o. Un vistazo a unas cuantas páginas clave antes de indexar sigue siendo buena idea.
P: Ya tenemos una base vectorial propia: ¿serviría de algo la base de ingeniería de datos?
R: Sí. Ella se encarga de todo lo anterior a la indexación — limpieza, anonimización, compresión, estructuración — y su salida se conecta a la base vectorial existente. No hace falta tirar nada para atrás.
P: ¿El despliegue privado exige mucho hardware?
R: Depende del volumen de documentos y de la concurrencia. Lo más sensato es arrancar una validación a pequeña escala con un lote de documentos reales y dimensionar con mediciones, no con estimaciones a ojo.