El sistema viejo de tu empresa lo sabe todo. El problema es que nadie puede preguntarle

Toda empresa con unos diez años de camino tiene a alguien así. Esa persona sabe por qué aquel cliente tiene un descuento que no aparece en ninguna tabla, por qué la factura solo sale si cierto campo está lleno y qué pasa si alguien toca la rutina de cierre del mes. Nadie escribió nunca nada de eso. Está en su cabeza y, de forma más dispersa, dentro del sistema.

Ahora imagina el día en que se toma una licencia larga, se va a otra empresa o se jubila. El sistema sigue funcionando con total normalidad. Lo que desaparece es la posibilidad de preguntarle algo.

Ese es el hueco que el RAG ayuda a cerrar, y se puede hacer sin cambiar de sistema.

El legado es más grande que el código

Cuando alguien habla de sistema legado, la imagen que viene a la mente es la de un programa viejo en un servidor olvidado. En la vida real el legado es todo junto: el sistema, la base de datos con quince años de registros, los manuales en PDF que nadie actualiza, la carpeta compartida llena de hojas de cálculo con nombres dudosos, el historial de tickets de soporte y esos hilos de correo donde se tomó una decisión importante.

Todo eso es difícil de tocar por dos motivos. El sistema funciona y da dinero, así que nadie quiere arriesgarlo. Y el conocimiento está en formatos que no se hablan entre sí. Para responder algo simple, como por qué un pedido se canceló solo, alguien abre tres pantallas, busca en un PDF y todavía le escribe a un compañero.

La salida clásica es la migración, reescribir todo en un sistema moderno. A veces de verdad es el mejor camino, pero cuesta caro, lleva meses y obliga a la empresa a vivir con dos sistemas a la vez. Por eso tanta gente deja el tema para después durante años, y el problema solo engorda.

Qué es el RAG, en cristiano

La sigla viene de Retrieval-Augmented Generation, algo así como generación con consulta previa. La idea es simple, y entenderla quita un miedo muy común.

Un modelo de lenguaje, de esos que escriben texto y responden preguntas, sabe bastante del mundo en general y nada de tu empresa. Si le preguntas la regla de envío de tu sistema, va a inventar una respuesta que suena muy convincente. Ese es el gran defecto de estas herramientas.

El RAG lo esquiva cambiando el orden de las cosas. Antes de que el modelo responda, una búsqueda recorre tus documentos, bases de datos y manuales y separa los fragmentos que tienen que ver con la pregunta. Esos fragmentos van al modelo junto con la pregunta, con la instrucción de responder solo con base en ellos. La respuesta llega diciendo de dónde salió la información, así que se puede verificar.

En la práctica queda así: preguntas, en español normal, cuál es la regla de descuento para clientes con contrato anterior a 2019. El sistema busca en las fuentes, no solo por las palabras exactas sino por el sentido. El modelo escribe la respuesta con lo que encontró y señala el documento o la pantalla de origen. Si está mal, ves exactamente dónde.

Lo que más le interesa a quien tiene legado es que el RAG no toca el sistema viejo. Se queda al lado y solo lee. No hace falta reescribir código, cambiar la base de datos ni entrenar un modelo desde cero con los datos de la empresa, y por eso el riesgo de ponerlo en marcha es pequeño.

La idea, por cierto, no es nueva. El artículo que bautizó la técnica es de 2020 y ya proponía unir un modelo de lenguaje con una base de documentos consultable. Lo que cambió desde entonces es el costo y la calidad de las herramientas, que ahora permiten armar esto para una empresa común y no solo para gigantes de la tecnología.

Qué cambia en el día a día

Quien entra a la empresa deja de pasar tres meses pidiéndole ayuda a los veteranos. Consulta al asistente, ve de dónde salió cada respuesta, y los veteranos recuperan el tiempo que gastaban explicando siempre lo mismo.

El soporte también lo nota. El agente pregunta por qué se rechazó la boleta de pago de cierto cliente y recibe la regla, el historial de casos parecidos y la pantalla donde se corrige. Lo que antes pedía un ticket al equipo técnico se resuelve en la primera conversación.

Las auditorías y la rendición de cuentas se vuelven menos dolorosas, porque averiguar quién aprobó qué, y con base en qué regla, deja de ser una búsqueda del tesoro.

Y hay un efecto que poca gente ve al principio. Si un día la empresa decide migrar, tener las reglas de negocio documentadas y consultables ya es la mitad del trabajo. Muchas migraciones se atrasan justamente porque nadie sabe bien todo lo que hace el sistema viejo.

Dónde no ayuda

Hay cosas que el RAG no resuelve, y conviene saberlo antes de entusiasmarse. Si el sistema está lento o se cae todas las semanas, el problema es de infraestructura y de código, y necesita otro tipo de trabajo. Si la tecnología ya no tiene soporte y tiene fallas de seguridad conocidas, el RAG ayuda a entender lo que existe, pero la actualización sigue siendo necesaria.

Si casi nada está documentado y el conocimiento vive solo en la cabeza de las personas, se puede usar el RAG, pero antes hay que sacar ese conocimiento de ahí, con entrevistas y con lectura del código y de los tickets antiguos. Y si los datos son un lío, con tres versiones contradictorias de la misma regla, el asistente va a citar cualquiera de ellas. El RAG funciona como un espejo: devuelve lo que encuentra, errores incluidos. Buena parte del trabajo serio de una implantación es decidir qué fuentes merecen confianza y qué hacer con las desactualizadas.

Los cuidados que no se pueden saltar

Poner un asistente a leer los datos de la empresa pide atención en algunos puntos, y todos tienen solución si alguien piensa en ellos antes de lanzar.

El primero es la filtración entre áreas. Si el asistente lee todo, cualquier empleado puede terminar viendo lo que solo finanzas debería ver. Lo correcto es respetar los permisos que ya existen: cada persona recibe solo los fragmentos que ya podría abrir por su cuenta.

El segundo son los datos personales. Los registros de clientes y de empleados están bajo la LGPD, la ley de protección de datos de Brasil, así que hay que saber qué se va a indexar, por cuánto tiempo y dónde queda guardado, y no mandar datos sensibles a un servicio externo sin control.

Después viene la respuesta que parece correcta y está equivocada. Se reduce obligando al asistente a citar la fuente y a admitir cuando no encontró nada, en vez de completar con una suposición. También está el índice que envejece: el sistema cambia y el asistente sigue respondiendo con la versión de hace seis meses, así que alguien tiene que ocuparse de la actualización. Y el costo, que crece sin que nadie lo vea si cada consulta no se mide desde el primer día.

Quien vaya a contratar o construir algo así debería leer la lista de OWASP, una referencia en seguridad de software, que mantiene un material solo sobre los riesgos de las aplicaciones con modelos de lenguaje.

Cómo empezar sin apostar el presupuesto del año

El error más común es querer indexar la empresa entera de una vez. El proyecto queda grande, caro y lento, y pierde el apoyo de la dirección antes de mostrar resultados.

Funciona mejor elegir una pregunta que de verdad moleste. Puede ser la duda que soporte le lleva todas las semanas al equipo técnico, o la regla del módulo de facturación que solo dominan dos personas. Se arma el asistente solo para eso, con pocas fuentes bien elegidas, y se pone en manos de un grupo pequeño, para uso real.

Antes de empezar, vale la pena responder algunas cosas. ¿Qué pregunta repite tu equipo toda la semana y solo uno o dos saben responder? ¿Dónde está la información que la responde: en el sistema, en la base de datos, en PDFs, en correos? ¿Quién puede ver qué, y hay datos personales o reservados de por medio? ¿Cómo van a saber que el asistente acertó, y quién revisa las primeras respuestas?

Con ese recorte, un piloto queda listo en pocas semanas y la empresa decide con datos si vale la pena ampliar. Si no vale, el costo fue pequeño y el aprendizaje grande: como mínimo descubres dónde está más frágil tu documentación.

Cómo lo hacemos en 360 Brave

Somos un estudio de ingeniería de software y ya trabajamos por dentro de sistemas viejos, lo que marca la diferencia. Lo difícil del RAG en legado nunca es el modelo. Es entender qué hace el sistema y dónde vive cada información. En el piloto de RAG para sistemas legados, entregamos un asistente funcionando sobre un recorte de tu sistema, con alcance, plazo y precio acordados antes de empezar.

Todo empieza con una conversación, en la que nos cuentas dónde tu equipo pierde más tiempo buscando respuestas. Después mapeamos, con acceso de solo lectura, dónde está la información, en qué estado y qué se puede indexar con seguridad, respetando permisos y la LGPD. Ahí ponemos el piloto en marcha: un asistente sobre el recorte acordado, que cita la fuente y admite cuando no sabe, usado de verdad por tu equipo mientras medimos los resultados. Al final mostramos qué funcionó, qué no y cuánto costaría ampliar. Si tiene sentido, ampliamos. Si prefieres, te entregamos todo documentado para que tu equipo siga solo.

Como el asistente queda al lado del sistema y no dentro de él, la operación sigue funcionando como siempre. Y si más adelante la empresa decide modernizar el legado, el mapa que hicimos ya sirve de punto de partida.

Si quieres saber si tu caso es bueno para esto, escríbenos. Primero escuchamos y entendemos cómo funciona tu sistema. Solo después de mirarlo con cuidado podemos decirte si tiene sentido y, si lo tiene, proponer alcance, plazo y precio del piloto. Si no, también te lo decimos.