Approval table for AI tools before you write another prompt

Why one table matters

Teams rarely break policy on purpose. Most of the time, they just can't find the latest rule.

One model gets approved in a chat thread. A spending limit sits in a spreadsheet. Data handling notes live in a doc nobody has opened in months. Then a developer starts building an internal AI tool and fills in the gaps from memory.

That's how small mistakes start. One person thinks a model is fine for support drafts. Another thinks it's blocked for any customer data. Someone else assumes the budget is per team, not per project. Nobody is being reckless. The rules are scattered.

A simple approval table fixes that. Keep the current decision in one place. If a team wants to know which model they can use, what it costs, what the rate limit is, and who can approve an exception, they should be able to check one table and move on.

Without that table, rules drift fast. AI tools change fast too. Vendors update pricing. Rate caps change. A model that looked cheap in a test can get expensive once real traffic hits it. Data rules also shift as legal, security, and customer requirements change. When those updates land in different places, people build from stale information.

Ownership is usually the biggest gap. When nobody owns exceptions, people guess. They ask in a group chat, wait two days, then decide on their own because the deadline is close. That's when a team builds on an unapproved model, or a launch stalls because nobody will give a clear yes or no.

One table cuts down the most common problems: duplicate rules across chats and old docs, outdated prices and rate limits, vague data handling decisions, and no named owner for unusual cases.

This matters even more in small companies. A team might have one engineer, one ops lead, and one founder making tool choices. That feels fast, but informal decisions spread quickly and stick around longer than they should.

Picture a company building an internal sales assistant. The prototype works in two days. Then the team learns the chosen model has tighter rate limits than expected, finance didn't approve the projected spend, and nobody knows who can allow CRM data in prompts. A half-hour table could have saved a week.

One table won't solve every governance problem. It does stop the most common failure: people build first and sort out approval rules later, when the bill is real and the launch is blocked.

What to put in the table

The table should remove guesswork. Anyone should be able to scan one row and know whether a tool is allowed, what they can use it for, what data they can send, how much usage is allowed, and who decides edge cases.

Keep the language plain. If a sales manager, designer, or support lead can't read a row in 30 seconds, it's too technical, too legal, or too vague.

Use one row for each tool or model people actually touch. That might be a chat app, an API model, a coding assistant, or an internal wrapper that sits on top of several models. Name the tool clearly, and include the model or version if that changes behavior, price, or data handling.

Each row should answer a few basic questions in everyday language:

• What is this tool approved for?
• What data can go into it?
• What limits apply?
• Who owns the decision?
• What happens if someone needs an exception?

In practice, that usually means a row needs the tool name, allowed use cases, approved data types, spending or rate limits, payment source, one named owner, and a short note on when finance, legal, or security need to step in.

The owner matters more than most teams expect. If three people own a row, nobody owns it. Pick one person who can answer normal questions, approve routine use, and route unusual cases.

It's also worth adding status. Teams need to know whether a tool is active, in trial, restricted, or retired. A stale entry can cause as much confusion as a missing one.

Build it in one afternoon

You don't need a committee, a long policy draft, or a fancy system. A shared spreadsheet or a simple page in your wiki is enough for the first version. The goal is straightforward: when someone wants to use a tool, the team can decide quickly without guessing.

Start with the tools people already use, not the ones you might approve someday. Ask team leads, operations, finance, and anyone building prompts or automations which AI tools people already touch. Include paid tools, browser add-ons, API accounts, and the odd one-person subscription that slipped in under the radar.

This part usually goes faster than expected. Most teams already know the tool names. What they often don't know is who approved them, what data went into them, or who pays the bill.

Create one row per tool. If the same tool has two very different uses, split it into two rows. A chatbot used for public marketing copy is not the same as that same chatbot used with customer data.

Keep the table lean. If a rule doesn't change a decision, skip it for now. You're not writing a handbook. You're building something people can use to say yes, no, or ask one more person.

A good first draft usually includes the tool name, what people may use it for, any spending or rate limit, whether the request needs finance, legal, or security input, and one named owner. Put cross-team input in the same row instead of sending people to separate docs. A note like "security review required if customer data is involved" saves a lot of back-and-forth.

Store the table where people already work. If engineers live in GitLab, keep it near the docs they open every day. If the broader team uses a wiki or operations hub, put it there. The best location is the one people check before they open a new AI account.

Then run one real request through it. If the requester still needs to ask five follow-up questions, the table is too vague. Tighten the row until a normal request takes a few minutes, not three meetings.

A simple company example

A support team at a 60-person software company handles about 1,200 tickets a week. Most are routine: login issues, billing questions, and setup problems. The team wants AI to draft first replies so agents spend less time typing the same answer.

They start with the cheapest model they can find. On paper, it looks fine. The price is low, the rate limits are generous, and the test replies sound good enough for common tickets.

Then the data problem appears.

Support tickets often include names, email addresses, account numbers, order details, and screenshots. The model they picked is approved only for public or fully anonymized text. It isn't approved for raw customer support data. Without a clear approval table, that team would probably lose a week to messages, meetings, and guesswork.

Instead, the support lead opens one shared table and gets the answer in minutes. The row for that model says it's limited to public content, has a small monthly spend cap for internal experiments, names the security lead as the exception owner, and points to a more expensive backup model that's approved for masked customer data.

That changes the conversation right away. Nobody argues about policy because the rule is already written down. The team knows who can answer the exception question, and they know which approved tool can replace the first choice.

The security lead reviews the use case the same day. He doesn't approve the cheap model for live ticket text, but he does suggest a safer path: remove direct identifiers, keep a human agent in the loop, and use the approved model that allows customer support content under the company's retention rules.

The support team switches tools, updates the workflow, and keeps moving. Agents still get AI drafts. Finance still gets cost control because the table includes usage limits. Security still gets a clear boundary on customer data.

That's why a clear exception owner helps more than another policy document. The team doesn't stop at "no." They get a fast route to "use this instead."

Handling exceptions without chaos

Teams usually don't get into trouble because they have rules. They get into trouble because someone breaks the rules quietly for a reason that sounds sensible, and nobody writes it down.

Your table should leave room for exceptions, but that room needs boundaries. If every unusual request turns into a one-off debate, people wait too long, bypass the process, or approve things they don't fully understand.

Draw a clear line between a normal request and an exception. A normal request fits the approved tool list, the allowed data type, the spending limit, and the stated use case. Anything outside that line is an exception.

A simple rule helps: if someone wants a higher spend limit, access to a new model, use of customer data, or a workflow that touches regulated information, treat it as an exception from the start.

Exceptions also need an owner. They shouldn't float around a chat thread until the loudest person answers. In many companies, that means one owner for cost, one for security, and one for business risk. Keep it narrow. Five approvers usually means no real approver.

Urgent cases need a clock. If a product team has a production issue and needs temporary access to a stronger model or a higher rate limit, they should know whether the answer will come in 30 minutes, four hours, or the next business day. A clear deadline lowers panic because people know what to expect.

Keep a short record for every exception: who asked, what rule they needed to break, who approved it, why they approved it, and when it expires. That last part matters. Temporary access has a habit of becoming permanent when nobody closes it.

A quick example makes the point. Say a support team wants to send customer tickets to a new AI tool because it writes better summaries. That request sits outside the approved list, so it becomes an exception. The security owner checks the data risk. The budget owner approves a capped two-week trial. The team records the reason. Next month, someone reviews the log and either adds the tool to the normal table or shuts the exception down.

Review the pattern, not just the request. A monthly review is enough for most teams. Count the exceptions, spot repeats, remove expired approvals, and update the table. If the same kind of exception shows up three times in a month, your standard rules are probably out of date.

Mistakes that slow teams down

An approval table can still fail for a simple reason: people can't use it to make a decision. The worst tables look complete at first glance, but they leave out the facts people need on a busy Tuesday afternoon. Then every tool request turns into a Slack thread, a meeting, and a guess.

One common mistake is policy language that sounds careful but says almost nothing. Phrases like "use approved tools responsibly" or "avoid sensitive data when possible" don't help an engineer, team lead, or finance manager decide what to do. People need plain rules: which data is allowed, who can approve an exception, what spend cap applies, and when a request must stop.

Another problem is listing tools without money or usage limits next to them. A table that names a model, plugin, or coding assistant but skips the monthly budget, seat cap, token limit, or rate limit is only half done. Teams start work, hit a quota wall, and scramble to upgrade plans or split usage across accounts. That wastes time and creates surprise bills.

Shared ownership causes a different kind of mess. If security, engineering, and operations all "own" a tool, nobody feels responsible for answering the hard questions. Who renews it? Who approves extra spend? Who signs off when someone wants to use customer data? One named owner works better than a group label every time.

Trial accounts and personal cards create quiet risk. Someone tries a new AI app on a free plan, likes it, and keeps using it for real work. Later, they upgrade with a personal card to remove limits. Now the company has business data in a tool that may not even appear in the table, and finance can't see the spend.

Old entries cause trouble too. Retired tools stay in the table for months, and people assume they're still allowed. New projects get built on tools the company already dropped for cost, security, or support reasons. A stale table is often worse than a short one.

A clean table avoids most of this. Each row should have one owner, real spend and rate limits, plain approval rules, trial status or payment source, and a clear active or retirement status.

Quick checks before launch

Most teams don't get stuck on the prompt. They get stuck on the small missing rules around it. A five-minute review of the table can catch most of that before people start using the tool for real work.

A simple test works well: hand the table to a new hire and give them five minutes. If they still ask who approves a tool, what data they can send, or what happens when they hit a limit, the table isn't ready.

Before launch, check a few basics. Make sure a new person can understand each row without extra context. Make sure every row has one named owner. Confirm that the limits in the table match the current vendor plan, not an old trial number. Write the data rule in plain language so people know what they may send and what stays out. And spell out the failure path. If a limit is hit, users should know whether to wait, switch to another approved tool, or ask for an exception.

A good row reads like a small instruction card: "Support assistant, owner: Maya, monthly cap: 50,000 requests, allowed data: redacted support tickets only, if cap is hit: move urgent cases to the backup queue and message Maya." That's enough for most people to act without guessing.

One more check matters: compare the table against the real vendor account, not a slide deck or last quarter's notes. Plans change. Limits change. Team owners change too. If the table drifts away from reality, people stop trusting it.

If you want a final stress test, ask someone outside the project to answer one ordinary question with the table alone: "Can I paste this client email into the tool?" If they can answer quickly and correctly, you're close.

What to do next

Don't try to map the whole company on day one. Pick one team that already wants to use AI and focus on the tools they ask for most often. Support, product, marketing, or engineering all work. Five to ten rows are enough for a first version.

That small scope keeps the work honest. If a table only works at slide-deck level, it will fail the first time someone needs an answer before lunch.

Use a real request this week. Try something ordinary, like whether the support team can use a tool to summarize customer chats or whether product managers can paste meeting notes into a model. Walk that request through the table from start to finish. If someone still has to ask legal, security, finance, or a manager in chat, the row isn't finished.

A simple first pass is enough: list the tools one team already wants to use, add rates, usage limits, approved data types, and the exception owner, then test one live request against the table. Write down every question the table didn't answer and fix those rows right away.

Most teams find the same weak spots. A limit says "reasonable use" but nobody knows what that means. A row says "sensitive data" but gives no examples. An exception exists, but no one owns it. These aren't huge policy failures. They're missing details, and those details create the endless back-and-forth that slows adoption.

When you spot a gap, rewrite the row in plain language. If finance allows one model for invoice summaries but not for contracts, say that. If a manager can approve extra usage above a monthly cap, name that person. If customer data needs redaction first, put that rule where people will actually see it.

After one team uses the table for a week or two, copy the format to the next team. Keep the structure the same and only change the rows. Training gets easier, and people stop treating every request like a special case.

If your company keeps getting stuck on approval rules, tool choice, or safe AI adoption, Oleg Sotnikov at oleg.is works with startups and smaller businesses on practical AI use, technical leadership, and AI-first operations. A short review of your table, approval flow, and tool choices can save a lot of wasted time before the next request lands on someone's desk.