Your old system knows everything. The problem is that nobody can ask it anything

Every company that's been around for ten years or so has someone like this. They know why that one customer gets a discount that isn't in any price table, why the invoice only goes out if a certain field is filled in, and what happens if anyone touches the month-end close. Nobody ever wrote any of it down. It's in their head and, in a more scattered way, inside the system.

Now picture the day they go on a long leave, move to another company or retire. The system keeps running just fine. What disappears is the chance to ask it anything.

That's the gap RAG helps close, and you can do it without replacing the system.

Legacy is bigger than the code

When people say legacy system, the picture that comes to mind is an old program on a forgotten server. In real life legacy is the whole bundle: the system, the database with fifteen years of records, the PDF manuals nobody updates, the shared folder full of spreadsheets with questionable names, the support ticket history and those email threads where an important decision got made.

All of that is hard to touch for two reasons. The system works and makes money, so nobody wants to risk it. And the knowledge sits in formats that don't talk to each other. To answer something simple, like why an order was canceled on its own, someone opens three screens, searches a PDF and still messages a coworker.

The classic way out is migration, rewriting everything in a modern system. Sometimes that really is the best path, but it's expensive, it takes months and it forces the company to live with two systems at once. That's why so many people push the subject off for years, and the problem just gets fatter.

What RAG is, in plain English

The name comes from Retrieval-Augmented Generation. The idea is simple, and understanding it clears up a very common fear.

A language model, the kind that writes text and answers questions, knows a lot about the world in general and nothing about your company. If you ask it about the shipping rule in your system, it will invent an answer that sounds very convincing. That's the big flaw of these tools.

RAG gets around it by changing the order of things. Before the model answers, a search goes through your documents, databases and manuals and pulls out the passages related to the question. Those passages go to the model along with the question, with the instruction to answer based only on them. The answer comes back saying where the information came from, so you can check it.

In practice it goes like this: you ask, in normal English, what the discount rule is for customers whose contract predates 2019. The system searches the sources, not just for the exact words but for the meaning. The model writes the answer from what was found and points to the document or screen it came from. If it's wrong, you can see exactly where.

The part that matters most if you have legacy is that RAG doesn't touch the old system. It sits next to it and only reads. You don't have to rewrite code, swap the database or train a model from scratch on your company's data, which is why the risk of putting it live is small.

The idea isn't new, by the way. The paper that named the technique is from 2020 and already proposed joining a language model to a searchable document base. What has changed since then is the cost and quality of the tools, which now make it possible to build this for an ordinary company, not just for tech giants.

What changes day to day

New hires stop spending three months asking the veterans for help. They ask the assistant, see where each answer came from, and the veterans get back the time they used to spend explaining the same things.

Support feels it too. The agent asks why a certain customer's payment slip was rejected and gets the rule, the history of similar cases and the screen where it gets fixed. What used to take a ticket to the technical team now gets solved in the first conversation.

Audits and accountability reports get less painful, because finding out who approved what, and under which rule, stops being a treasure hunt.

And there's an effect few people notice at first. If the company ever decides to migrate, having the business rules documented and searchable is already half the work. A lot of migrations run late precisely because nobody really knows everything the old system does.

Where it doesn't help

Some things RAG doesn't solve, and it's worth knowing that before you get excited. If the system is slow or goes down every week, that's an infrastructure and code problem, and it needs a different kind of work. If the technology is out of support and has known security flaws, RAG helps you understand what you have, but the upgrade is still necessary.

If almost nothing is documented and the knowledge lives only in people's heads, you can still use RAG, but you first have to get that knowledge out of there, with interviews and by reading the code and the old tickets. And if the data is a mess, with three contradictory versions of the same rule, the assistant will quote any one of them. RAG works like a mirror: it hands back what it finds, mistakes included. A good part of the serious work in a rollout is deciding which sources deserve trust and what to do with the outdated ones.

The precautions you can't skip

Putting an assistant in front of company data calls for attention on a few points, and every one of them has a fix if someone thinks about it before launch.

The first is leaks between departments. If the assistant reads everything, any employee might end up seeing what only finance should see. The right approach is to respect the permissions you already have: each person gets only the passages they could already open on their own.

The second is personal data. Customer and employee records fall under Brazil's LGPD, so you need to know what will be indexed, for how long and where it's stored, and you shouldn't send sensitive data to an outside service without controls.

Then there's the answer that looks right and is wrong. You reduce it by forcing the assistant to cite its source and to admit when it found nothing, instead of filling the gap with a guess. There's also the index that goes stale: the system changes and the assistant keeps answering with the version from six months ago, so someone has to look after the updates. And there's cost, which grows unnoticed if every query isn't measured from day one.

Anyone hiring or building something like this should read the OWASP list. OWASP is a reference in software security, and it keeps a document just on the risks of applications built on language models.

How to start without betting the year's budget

The most common mistake is trying to index the whole company at once. The project gets big, expensive and slow, and loses leadership's support before it shows results.

It works better to pick one question that really bothers you. It could be the doubt support sends to the technical team every week, or the billing module rule that only two people have mastered. You build the assistant for just that, with a few well-chosen sources, and put it in the hands of a small group for real use.

Before you start, it's worth answering a few things. Which question does your team repeat every week that only one or two people can answer? Where is the information that answers it: in the system, the database, PDFs, emails? Who can see what, and is there personal or confidential data in the mix? How will you know the assistant got it right, and who checks the first answers?

With that scope, a pilot is ready in a few weeks and the company decides with data whether it's worth expanding. If it isn't, the cost was small and the learning big: at the very least you find out where your documentation is weakest.

How we do it at 360 Brave

We're a software engineering studio and we already work inside old systems, which makes a difference. The hard part of RAG on legacy has never been the model. It's understanding what the system does and where each piece of information lives. In the RAG pilot for legacy systems, we deliver a working assistant on a slice of your system, with scope, timeline and price agreed before we start.

It all begins with a conversation, where you tell us where your team loses the most time hunting for answers. Then, with read-only access, we map where the information is, what state it's in and what can be indexed safely, respecting permissions and the LGPD. After that we put the pilot live: an assistant on the agreed slice, one that cites its source and admits when it doesn't know, used for real by your team while we measure the results. At the end we show what worked, what didn't and what it would cost to expand. If it makes sense, we expand. If you prefer, we hand everything over documented so your team can carry on alone.

Because the assistant sits next to the system and not inside it, operations keep running as always. And if the company later decides to modernize the legacy system, the map we made is already a starting point.

If you want to know whether your case is a good fit, get in touch. First we listen and learn how your system works. Only after a careful look can we say whether it makes sense and, if it does, propose the scope, timeline and price of the pilot. If it doesn't, we'll say that too.