Business Teams Are Shipping AI Code. IT Needs a Triage Queue.

Seventy-one percent of IT leaders report an increase in shadow IT driven specifically by generative AI, according to Salesforce’s 2024 State of IT report. That’s not a warning about some hypothetical risk lurking down the road. It’s a description of what’s already running in production — inside finance, ops, and recruiting teams that never filed a single ticket with engineering.

The AI Shadow IT Reality

Here’s the part nobody wants to say out loud: this is mostly a win. A finance analyst who can generate a working script in twenty minutes doesn’t need to wait six weeks for a slot on the engineering sprint. That’s a real gain, and IT shouldn’t apologize for it or pretend it isn’t happening.

But velocity without ownership is a liability with a delay timer. The moment a non-developer’s script touches live transaction data, a customer database, or a logistics API, it stops being an experiment. Someone is now depending on its output. It’s a production dependency with no on-call rotation, no patch cycle, and — six months from now — often nobody left who even remembers it exists.

Banning it outright doesn’t work. Business users will keep reaching for Codex, Copilot, or whatever browser-based assistant is handy, policy or no policy, because the alternative is going back to spreadsheets stitched together by hand. The more durable move is shifting from prohibition to interception: catch the script before it touches anything real, not after.

Compiling Does Not Mean Correct

We ran into this directly on a finance dashboard project. A finance team member used an AI assistant to write a Google Apps Script that pulled transaction data from an external API into a reporting sheet. It worked in testing. It worked in the demo. It worked for three weeks.

Then transaction volume crossed 100 records — the API’s default page size — and the script started silently dropping rows. No error. No warning. Just a dashboard quietly under-reporting revenue, because the generated code never called the next page.

That’s the common failure mode with AI-generated business code: it optimizes for the happy path the prompt described, not the edge cases a professional developer would ask about by reflex. Pagination. Rate limits. Retry logic. Timezone handling. A finance user has no reason to ask “what happens past record 100,” because nothing in their domain expertise trains them to think that way. No prompt template fixes that. Someone with classical CS grounding still has to own the mathematical correctness of the pipeline, even when a non-developer wrote the first draft.

Secrets in Plaintext Are Not Architecture

The second case was worse — though, to be fair, the business outcome was genuinely good. An operations team at a local logistics SME used AI to write a Python script automating route consolidation, work that used to eat hours of manual data entry every week. The logic held up. The time savings were real.

It also had two live, hardcoded production API keys sitting in a plaintext file in a local directory, synced to a shared drive.

That’s not really a surprise once you think about how the model was prompted. Ask for “a script that pulls delivery addresses from our routing API,” and you get credentials embedded inline — because that’s the fastest path to a working answer, and nothing in the prompt asked for a secrets manager. The model isn’t choosing insecure practice out of malice. It’s defaulting to whatever gets the demo running, and nobody in the loop knew enough to object.

We stripped the hardcoded keys, moved the logic into an Azure Function, and put the credentials behind Azure Key Vault. The business logic didn’t change at all. What changed was the blast radius of a leaked laptop.

Building the Engineering Sign-Off Lane

Both incidents point to the same fix, and it isn’t a policy memo — it’s a triage queue. Any business-generated script that requests network access, touches a production data source, or requires an API key gets routed into a formal review lane before it goes anywhere near real data. Yes, that adds friction. A script that took twenty minutes to write now waits in a queue. But it’s friction applied before the damage, not paperwork filed after it.

The lane needs three mechanical gates: automated secret scanning, standard linting, and execution in an isolated sandbox before production credentials ever get issued. None of this is exotic — it’s the same CI/CD discipline engineering already applies to its own commits, just extended to code that didn’t originate from a developer. And it’s not sufficient on its own. A scanner catches a hardcoded key. It won’t catch a script that silently stops paginating at record 100. That still takes a person reading the code, not just a pipeline running it.

The division of labor has to be explicit. The business user owns domain logic and the prompt — what data, what output, what business rule. Engineering owns security posture, secrets management, and the deployment pipeline. Neither side should be doing the other’s job, and in both incidents above, that overlap is exactly the gap that got exploited.

Executable Requirements

Drop the framing of “rogue software that snuck past IT.” That’s not what this is. It’s requirements that happen to compile.

Business analysts used to write a document describing what they wanted, and engineering translated that into code — usually losing something in the handoff. Now the business user generates a working prototype directly. The intent is visible; the correctness is not. What’s missing is the gate that turns a working prototype into reviewed production code: a review lane that treats the AI-generated script like a pull request, scans for hardcoded keys, runs it against sandbox fixtures, and requires a reviewer to check failure modes like pagination before credentials touch anything real.

Process over prohibition. The business keeps shipping fast. Engineering keeps owning what breaks.