The App Nobody Approved Is Now in Your Critical Path
Updated: 7 days ago
September 2026 | TAAUS Secure Technologies
AI has made building software nearly free. The rules for governing business-critical software still assume its expensive
An associate on your operations team spends a weekend building a small tool. Reconciling the administrator’s capital account file against the internal ledger eats two days a month, and the exceptions are always the same few causes. She describes the problem to an AI coding assistant, gets working code back, and by Sunday night it runs clean.
Monday, it saves her two days. By the end of the quarter, two colleagues use it. By the following quarter, its output is being pasted into the pack that goes to LPs.
Nobody decided this. There was no review, no approval, no change control. There was a spreadsheet problem, and then there wasn’t. Somewhere in that progression, an unmanaged application became load-bearing.
Some version of this is already happening at your firm. The question isn’t whether to allow it. It’s what happens the first time one of these tools fails at the wrong moment, and whether anyone can tell you how long it will take to get it back.
An Old Problem, Moving Faster
Financial services has been here before. The industry spent thirty years learning that critical business logic accumulates in spreadsheets and databases nobody governs. There is an entire discipline devoted to it and the failure patterns are well documented.
What has changed is the cost of building.
Creating an internal tool used to require someone who could actually write code. That meant a hire, a budget line, or an unusually motivated employee with a rare skill. That friction was doing real governance work: it kept the number of homegrown applications small enough that most of them were visible.
AI assistants have dramatically reduced that friction. The person who previously stopped at a pivot table can now build a scheduled job that pulls data, transforms it, and writes the result somewhere your team relies on. Build time collapsed, and the population of potential builders went from your one technical analyst to your entire staff.
You do not have one shadow application. You have a growing portfolio of them, appearing faster than any inventory process can absorb
How It Goes Wrong
The failure is almost always the same, and it happens before anything technical.
The application never gets classified. So it never enters the asset inventory. So it is never assessed for business impact, which means nobody ever set how quickly it must be restored or how much of its data you can afford to lose. And because nobody set those targets, it appears nowhere in the disaster recovery plan and often nowhere in your backups.
Every control downstream depends on a first step that never happened. Your continuity program can be well designed and genuinely tested and still be blind to the tool that produces your LP reporting, because the program never knew it existed.
What Actually Breaks
The infrastructure is personal. The tool runs on a laptop, or in a cloud account someone opened on a corporate card. It is not in your environment and not in your backups. If that person leaves, the account leaves too.
There is no source of truth. The code sits in a shared folder, a Downloads directory, or a chat history. No version control, no way to answer what changed and when.
Failure does not always look like failure. A broken tool is easy to spot. A working tool that drops a row, mishandles a date, or applies the wrong calculation is far more dangerous. If that output feeds a reconciliation, a valuation, or an investor report, availability is only half the problem — you also need a way to establish that the number is right.
A third party is now in the critical path. The tool may depend on an outside service nobody assessed — no vendor review, no SLA, no exit plan. If that service goes down, your process goes down with it, and your vendor inventory does not show the relationship exists.
The dependency can change without the application changing. If the tool calls an external AI model, the provider can update, deprecate, or replace that model while your code stays untouched. The tool keeps running and starts producing materially different output. Without validation, nothing signals that anything changed.
Key-person risk is worse than it used to be. The old version: only one person understands the tool. The new version: nobody does, including the builder. She can tell you what it does. She often cannot tell you how, because she described an outcome and accepted what came back.
Credentials outlive employment. Passwords and access keys get embedded in the tool because it is the fastest path to something working. They persist long after the builder’s last day.
Why This Shows Up in Diligence
For private funds, the sharpest consequence is not an outage. It is operational due diligence.
An analyst asks for your critical application list with recovery targets, your continuity test results, and your vendor list. You provide everything your program knows about. The problem is what it does not know about: the tool behind the portfolio monitoring pack, the reconciliation utility, the fee checker. None are inventoried, so none appear. That gap tends to surface in interviews rather than document review, which is worse — it reads as a governance blind spot rather than a paperwork one. Findings mean remediation requests and follow-up questions at exactly the point you want the operational conversation to be uneventful.
Slower exposures follow. Tools that create or transform business records carry recordkeeping obligations regardless of who built them. A compliance program that does not reflect how work is actually performed has an accuracy problem. Audit scope drawn around known systems does not cover unknown ones.
The Fix Is a Tripwire, Not a Ban
Prohibition does not stop the building. It stops the telling. You end up with the same portfolio, minus the visibility.
The objective is not to put change control around every script an analyst writes. It is to recognize the moment an experiment becomes infrastructure.
So define that moment explicitly. An application gets inventoried and classified as soon as any one of these is true:
• Someone other than the builder relies on its output.
• It touches confidential client, investor, or market-sensitive information.
• It feeds an external deliverable — LP reporting, a filing, an audit response, a valuation input.
• An outage would halt work for more than a set window. Pick a number and write it down.
• It holds credentials to a production system.
Once a tool crosses that line, the requirements are short and proportionate. Add it to the application inventory. Assign an owner, who need not be the builder. Set recovery targets. Move the code and the runtime somewhere managed. Rotate embedded credentials. Write down what it depends on, including any outside service. Define what correct output looks like and how someone would notice if it stopped being correct. Include it in the next continuity test.
Most of that is a couple of hours per application. The expensive part is not the controls. It is discovering, mid-incident or mid-diligence, that the application existed and nobody knew
Where to Start
Ask your operations, finance, and investment teams one question: what do you use to do your job that IT did not give you?
Ask it without consequence attached, because the answer is only useful if it is complete. You will get a longer list than you expect, and it will be the most valuable input to your continuity planning this year.
Asking costs nothing. What comes back is the harder part — deciding which of those tools crossed the line, what recovery targets they need, and what your diligence responses should have said. TAAUS works with private funds on exactly that: application inventory, promotion criteria, and continuity requirements that reflect how the firm actually operates. Schedule a consultation
