Your Team Isn't Just Using AI Anymore — Some of Them Are Building Software With It

A separate, newer problem has grown up alongside the one where employees paste client data into a chatbot to get through the day. This one is not about typing information into someone else's tool. It is about employees building their own tools. A new generation of AI app builders — the kind that turn a plain-language description into a working, deployed web application in an afternoon — has made it possible for someone with no engineering background to build a real piece of software: a customer intake form that writes to a database, an internal dashboard that pulls from a shared spreadsheet, a small scheduling tool for the team. None of this requires a developer, a procurement process, or a line item IT ever sees.

The appeal is obvious and mostly legitimate. Most small and mid-sized businesses have no in-house developer, and a request to "just build us something" to a contractor or agency used to mean weeks of turnaround and a real invoice. Now the person who felt that friction most — the operations lead who needed a better intake process, the office manager tired of a spreadsheet everyone edits wrong — can describe the tool they want and have something working the same day. That is a genuine gain, and it is why this is spreading fastest in exactly the businesses that never had the budget to commission custom software in the first place.

The trouble is that these builders are optimized to produce something that works, not something that is safe to leave running. The pattern shows up consistently once you look for it: an API key or database password typed straight into the app because that was the fastest way to get it working, a database connection with far broader read-and-write access than the tool actually needs, a login screen skipped entirely because it slowed down testing and nobody circled back to add it before the link got shared with the team. None of this reflects carelessness on the builder's part. It reflects that the tool was built to answer "does this work," and nobody at any point asked "is this safe to leave running with real customer data flowing through it."

The organizational risk compounds after the tool is built, not during. A sanctioned piece of software comes with a vendor, a support contract, and someone whose job includes knowing it exists. A tool one employee built over a weekend has none of that. It becomes a piece of infrastructure the business now quietly depends on, with no owner beyond the person who happened to build it. When that person changes roles or leaves, the tool does not stop running — it keeps handling whatever it was handling, un-patched and unreviewed, and the business often does not rediscover it until something breaks or a customer's data turns up somewhere it should not have.

The instinct to lock this down entirely runs into the same problem an outright ban on AI chat tools does: it does not remove the underlying need, it just pushes the behaviour further out of view. A business that forbids AI app builders outright does not get fewer homegrown tools — it gets the same tools built without even the modest visibility a permissive policy would have provided. The more workable response treats this as a lightweight gate, not a blockade: before any AI-built tool goes anywhere near real customer, financial, or employee data, it needs a named owner, a real login rather than an open link, and a specific answer to what data it touches and why. That is three questions, not a development process, and most people building these tools will happily answer them if asked before the tool goes live rather than after.

The other practical step costs nothing but a short conversation. Ask each team lead, plainly, what tools or small applications their team has spun up using AI in the last six months. Most owners who do this are surprised by the answer — not because anyone was hiding anything, but because nobody had previously had a reason to mention it. The tool that quietly handles new-client intake or tracks a vendor list was never a secret; it just never came up, because nothing had prompted the question.

None of this is an argument for slowing down the part of this trend that is working. A small business getting a genuinely useful internal tool built in an afternoon, for the cost of nobody's time but the person who needed it, is a real and durable gain that did not exist a few years ago. The argument is for treating what gets built the same way the business would treat any other piece of software that touches its customers' data: with an owner, a login, and a plain answer to what it does — decided once, before the tool is already load-bearing, rather than during the conversation that happens after something has gone wrong.