Your team can build its own AI apps now. Who’s keeping track?

In my opinion, there’s no worse feeling than starting a new role or taking on a new responsibility and finding out it all relies on an app with an archaic, clunky interface and workflow. Until recently, you were forced to hunker down and go through old documentation (if it existed), contact a rep at the company, or request a feature update that never comes.

Enter AI. Now those processes and interfaces can pretty much be tailored at will for whoever’s using them. Don’t like how something runs? Prompt AI to build you your ideal interface, point it at the API endpoint (for the love of all that is good, do not paste your API keys into the prompt), and voilà.

Building your own apps and workflows with AI is great. Between trackers, project management tools, garden planning assistants, AI second brains, command centers, heck, even a new home screen for my Android TV, you can make just about anything you can dream of.

A simple internal tool that used to take a developer weeks can now take someone with a good idea an afternoon. We think that’s awesome, and we do it ourselves.

Keeping them running after the excitement wears off takes a little more thought, though. Choosing which ones are worth making usable for your coworkers is a whole new ball game. Then you have to make sure they’re secure, that they don’t let anyone do things they otherwise couldn’t, and that they aren’t wide open to attack.

Start with the question that tends to get skipped when the demo goes well.

Who decided this is the process?

Say Phil in accounting builds a workflow that reads invoices and flags which ones to pay first. It works. It saves a few hours a week, so the rest of the team starts using it. Six months later, that’s just how invoices get handled.

Nobody ever sat down and decided those were the right rules. Nobody asked what happens with the weird invoices, or who checks when it gets one wrong. Phil made a reasonable call on a busy Tuesday, and now it’s company policy. Where was any of this documented?

To be fair, none of this is brand new. Plenty of offices have that one Excel file nobody dares touch. What’s changed is how much these apps can do and how fast they show up. A real software project used to be slow and expensive, so somebody usually had to approve it and ask those questions along the way. Now you can skip all that. Sometimes that’s a gift. But when an app is making decisions, you still want to know who signed off on how it makes them.

What happens when Phil leaves?

Phil built it, so it probably runs on Phil’s account, maybe on Phil’s laptop. Then Phil takes a new job and IT shuts off the account, like they should.

Usually one of two things happens next. The workflow stops, and nobody knows why the invoices aren’t getting flagged. Or it keeps running on some key or connection nobody remembers, with nobody watching it, and we’d argue that’s worse. Either way, the one person who had any idea how it worked is gone, and the instructions Phil gave the AI may have gone too. Most importantly, the decisions Phil worked through that shaped how it behaves are nowhere to be found, and that makes the logic hard to reproduce.

How does it get maintained?

When you’re excited about a new build, upkeep is the last thing on your mind. But these things don’t stay put. AI models get updated or retired, so an app can start behaving differently or just stop. The apps they connect to change. A login expires. And if the person who built it did it all by describing what they wanted, they may not be able to fix it when it breaks. So test it after any big change, and make sure someone besides the builder knows how to fix it, or who to call.

Is it secure?

Even careful people get this wrong, because the quickest way to get something working often gives it more access than it needs. What can the app open? Where are its passwords and keys kept? Does it really need access to the whole mailbox?

Here’s what we’d look for first:

• API keys are basically passwords. Anyone who finds one in a prompt, in the code, or anywhere a browser can see it can use it. That can mean your bill, your data, or both.
• Phil’s app may have no real login at all. A link nobody’s supposed to know about stops being protection the moment someone forwards it.
• Logging in doesn’t mean you only see your own stuff. If the app never checks whose record is being asked for, someone can sometimes pull up another person’s data just by changing a number in the web address.
• Hiding a button isn’t a lock. If the app never checks who’s asking behind the scenes, someone can still get to the admin screen.
• Watch for one all-powerful account. If the app connects with an admin login, the app can do anything an admin can. Unless it checks who’s asking, the people using it may be able to do the same, even if their own accounts never could.
• AI reads instructions wherever it finds them. Someone can tuck them inside an email, an invoice, or a web page, and the AI may follow them. It’s called prompt injection, and nobody has a foolproof fix yet. So we’d limit what the AI can reach and keep a person in charge of anything that sends, deletes, or pays.
• Some of this takes someone who can read code. In a poorly built app, a carefully crafted form entry can change or expose what’s in its database. AI also sometimes suggests add-on packages that are insecure or don’t exist, and attackers can publish malicious ones under those made-up names. And the parts an app is built on only get security fixes if someone installs them.

If you want to go deeper, OWASP keeps a top 10 list of the risks specific to AI apps.

I’ve learned some of this the hard way. When I first started, I’d connect API keys to my various apps, sometimes using the same key across tools. That made it hard to figure out what was linked where and where the usage was coming from. I’d forget an app had a certain key set up, and end up with a huge bill at the end of the month. Oh, did I mention I also forgot to set spend limits?

Learn from me and set one. Just check that it actually stops usage, because some budget settings only send an alert.

Now picture that at work. Whose API keys are these? The company’s, or someone’s personal ones? And who’s paying for them?

What should you think about before sharing it?

Not every app needs a process around it. Your garden planner is fine. But before something gets handed to coworkers, start with whether it should exist at all. Will more than one person still need it six months from now? Does something you already pay for do this? A built-in feature someone else supports beats one more thing to maintain.

If it passes that test, these are the questions we’d ask next:

• Where does the data go? Is it running through a business AI account or someone’s personal one, and do the terms fit the data you’re putting in?
• Does the other app allow this? Some vendors limit what you can do with their API, or charge for it.
• What’s the backup plan? If it goes down on a Friday afternoon, how does the work get done?
• Would it survive Phil leaving? We’d have people sign in with their company logins, so shutting off the account shuts off the app too. Anything with its own password or a shared key has to be shut off separately. And keep the code, prompts, and notes somewhere the company controls, not on Phil’s laptop.
• Do any rules apply? Client contracts, regulated data, and records you have to keep can all change the answer, so ask your attorney if you’re not sure.

What should you keep track of?

You don’t need anything fancy for this. For each app or workflow, write down:

• What it does, and who uses it.
• Who owns it, and who backs them up.
• What data and accounts it can reach, and where it runs.
• Which keys it uses, whose they are, who pays for them, and the monthly limit.
• What decisions it makes or influences, and who checks them.
• Why it works the way it does: the rules it follows, and the decisions behind them.
• When someone last reviewed it, and how to turn it off.

Even one row per app beats what we’d bet a lot of places have, which is nothing. Most of it is quick to write down while the person who built it is still around. Later, it’s detective work.

How do you keep it from becoming a mess?

We wouldn’t start by banning this stuff. People are going to build things anyway, and you want the good ideas out in the open where you can see them. So we’d match the rules to how much is at stake:

• A helper one person uses for their own work, with no client data or money involved, just goes on the list.
• Something the whole team relies on gets an owner, a backup, and a company account to run on.
• Anything touching client data, money, or decisions about people gets a second person’s review before anyone relies on it.

Then add two habits. Put “what did this person build?” on your offboarding checklist, so you find out before IT shuts off the account. And look through the list every so often, so you can fix what matters and shut off what nobody uses anymore.

We’re heading into a new frontier in the workforce, and some organizations are further along than others in seeing this wave coming. In my opinion, it’s only a matter of when, not if, you’ll be faced with these decisions. It’s better to be proactive and put some structure around this now, before you’re untangling a web of things you never knew existed until the person who built them leaves.

If you’d rather have help and you’re on Microsoft 365, our Managed AI Governance service keeps a list of your AI tools and the connections and agents built on your approved AI platforms, each with a named owner and regular reviews. And when Phil’s workflow turns out to be worth keeping, our AI Automation work can build a maintainable replacement, in your own accounts, with someone on your team who owns it.