Adding AI to Existing Systems: A Retrofit Flow

Most companies in the Philippines that want AI already run something. An inventory system a former staff member built. A booking sheet that grew into a workflow. An accounting package the head office chose in 2015 and will not be replacing.

The advice these companies usually receive is to modernise first and add AI afterwards. That advice is not wrong in principle. It is simply unaffordable for most of them, and it delays the AI work by a year or more.

There is a middle path, and it is what full-stack work in practice usually means: leave the existing system running and attach the new capability at a seam.

The Cost Nobody Puts in the Quote

Rebuilding an old system is rarely priced honestly, because the largest cost is not development.

It is the knowledge sitting inside the current setup. Every strange rule in that inventory database — the client who is always invoiced on the 25th, the product code that must never be reused — exists because something went wrong once. None of it is documented. Rebuild from scratch and you rediscover each rule the expensive way.

The second cost is the parallel period. For weeks, staff run the old process and the new one at the same time, and productivity drops in both.

Neither cost appears in a development quotation. Both are real, and for a company of thirty people they are usually larger than the build itself.

Related: How AI Integration Helps Philippine Businesses Modernize Legacy Systems explains this in detail.

Why "Just Add AI" Stalls

Companies that avoid the rebuild often stall anyway, and the reason is consistent: they look for a place to put the AI instead of a job for it to do.

A demonstration is arranged. Someone asks where it would connect. Nobody can answer, because the question was never "which tool" — it was "which task, in which system, producing what output for whom."

The second reason is data access. An older system may hold everything you need and expose none of it. There is no API, the database sits on a machine under someone's desk, and the vendor stopped answering email in 2021. This is a solvable problem, but it has to be solved before anything is promised to management.

Related: What to Put in an AI Vendor Contract: Handover, Audit Logs and Termination for Philippine Operations explains this in detail.

What Retrofitting Actually Looks Like

Map what the system already does

Write down what goes in, what comes out, and who touches it in between. Do this on paper, with the people who use it daily, not from the documentation. The documentation, where it exists, describes the system as designed rather than as used.

Related: How AI Consulting Actually Works for Philippine Businesses: The Five Stages From Strategy to Deployment explains this in detail.

Find the seam

A seam is a point where data already leaves or enters the system: an exported CSV file, a printed report, an email notification, a shared folder someone checks each morning. You can attach something at a seam without changing the system itself.

Most retrofits that succeed start at an export. Nothing inside the old system changes, so nothing inside it can break.

I have been doing this kind of work since the 1990s, when server administration meant typing every command by hand and automation arrived one small script at a time. One of the more useful lessons came from a failure: an automated rank-checking tool I relied on lost accuracy when the search engines changed how they worked, and I had to go back to checking by hand. Attaching something new to a system you do not control means accepting that the attachment can come loose.

Build alongside, not inside

The new component reads from the seam, does its work, and writes somewhere new. It does not write back into the old database at first, however tempting that is. Keeping the direction one-way means the worst possible failure is a bad output that nobody has to unwind.

Run both, then switch

Keep the manual process running next to the new one for a defined period, and compare outputs. Set the period in advance — three weeks, four weeks — because "we will switch when we are confident" tends to mean never.

Where This Goes Wrong

Writing back too early. Two-way integration is the natural next step and the most common cause of damage. Earn it after the one-way version has been correct for a month.

Treating the seam as permanent. A CSV export is a starting point, not an architecture. If the retrofit works, budget for a proper interface later.

Skipping the data question. If the workflow touches customer or employee records, the legal position is not softened by the fact that a machine is doing the processing. Under the Data Privacy Act of 2012, a personal information controller may subcontract processing, but remains responsible for ensuring that proper safeguards are in place. The Act also states that the controller is accountable for personal information under its control, including information transferred to a third party, whether domestically or internationally. Sending records to an external model is a transfer. Decide where that data goes before the pilot, not after.

Letting the pilot run forever. A pilot with no end date quietly becomes the real system, except that nobody wrote down how it works or who checks it. Give every pilot a review date when you start it.

FAQ

Q: Is it always cheaper to retrofit than to rebuild? A: No. If the existing system is genuinely at end of life — unsupported, insecure, or no longer matching how the business runs — retrofitting adds a layer to something that should be retired. The test is whether the current system still does its core job correctly. If it does, attach. If it does not, replace.

Q: How long does a first retrofit take? A: For a single well-chosen task working from an existing export, a first working version is usually a matter of weeks rather than months. What extends the timeline is almost never the build. It is deciding which task to start with and getting access to the data.

Q: What if our vendor will not give us access? A: You still have the seams. Reports, exports and notifications are outputs the vendor already gives you, and a retrofit can be built entirely on those. It is less tidy than a direct interface, and it works.

Q: Who should own this inside a small company? A: Someone who does the work daily, not only the person who signs off on it. The hardest part of a retrofit is describing what the current process really does, including the exceptions, and only the daily user knows those. Pair that person with whoever builds it, and keep the pairing for the whole pilot.

Q: How do we know the pilot worked? A: Measure the task before you start. Record how long it takes now and how often it has to be corrected. Without those two numbers, the review at the end becomes a discussion of impressions, and impressions favour whoever argued for the project.

Start at the Seam, Not the Core

The companies that get AI working in the Philippines are rarely the ones with the newest systems. They are the ones that picked a single task, found a point where data was already leaving the system, and built next to it rather than inside it.

Nothing about that requires replacing what you have. It requires knowing what you have, which is a smaller and much cheaper piece of work.

If you are weighing a rebuild against a retrofit, it is worth talking through where your seams actually are before committing to either. Please feel free to get in touch. The initial consultation is free.

References

• Republic Act 10173 — Data Privacy Act of 2012 (Sec. 14 Subcontract of Personal Information, Sec. 21 Principle of Accountability) — National Privacy Commission