Who and why
- Requester and team
- The business use case, in plain language
- Who else would use it — just the requester, or a whole team
Guide
Building an AI tool approval workflow that people actually follow
If "can we use this AI tool?" gets either a slow no or an instant yes, people stop asking. Here is a workflow built around one rule — Conditional-first — that lets you say yes quickly, with bounds, instead of saying no slowly.
The core problem
Why blanket bans fail, and why blanket approvals fail
A blanket ban does not stop anyone from wanting to use AI to get work done faster. It stops them from telling you about it. The result is shadow AI: the same tools, used the same way, minus the visibility, minus any control over what data goes into them, minus any record you could point to afterward.
A blanket approval fails for the opposite reason. "Use whatever you want" has no bounds: no data classification, no requirement for a company-managed account over a personal one, no record of who is using what. When something goes wrong — customer data pasted into a personal free-tier account, say — there is no paper trail and no named owner to point back to.
Both failures share a root cause: treating approval as a single binary gate. A yes/no decision forces a call before you actually have enough information, so requests either queue for weeks or get bypassed entirely. The fix is not a stricter gate — it is a workflow that can say "yes, with conditions" on the first pass.
The core principle
Conditional-first: the intake rule that beats a binary gate
Default every first-time request — and every pilot, including tools that look Low risk — to Conditionally approved, not to a straight Approve or Reject. Standing Approved comes later, once scope has held steady and the conditions you set have actually been observed in practice. That later step is a Promote, covered below.
A binary gate forces you to pick between two expensive options: reject and likely create a shadow-AI user, or approve outright before you know enough about how the tool handles data. Conditional turns "not enough information for a blank check" into an actual decision — named bounds plus a date to revisit it — instead of silence or a rubber stamp.
This is also why Low risk does not mean auto-Approve. A tool one person uses for internal drafts today can be the same tool ten people use against customer data next month. Conditional-first assumes scope will drift and builds in a checkpoint before drift becomes a standing, unrestricted approval. And Approved is not a blank check either — Approved ≠ unrestricted. Approved tools still have a defined use case and still get reviewed.
Step one
What a request intake actually needs to capture
Most approval processes stall because the intake form is too thin for a real decision, or too long for anyone to bother filling out. Aim for the shortest form that still answers these questions:
Data and vendor
- Which data classes would be involved
- Vendor plan or tier (free, business, enterprise)
- Whether the vendor's current terms say it trains on inputs
- Stated data retention period
Notice what is not on that list: a legal opinion, a security audit, or a certification claim. Intake is fact-gathering, not a compliance review. Vendor terms change, so treat "does it train on inputs" and "what is the retention period" as questions to re-check against current vendor documentation each time, not facts to memorize once.
Step two
Four verdicts, not two
A workflow with only "approved" and "rejected" cannot represent most real requests. Four verdicts cover the actual range of decisions you need to make:
Conditionally approved
Yes, for the stated use case, with named conditions and a date to revisit it. The default landing spot for almost every new request, including Low-risk ones.
Approved
A standing decision reached only via Promote. Scope held steady, conditions were actually implemented, and per-use gating is no longer needed — though it still has a defined scope and still gets reviewed.
Not approved
No ambiguity: this tool does not get used for company work. Where possible, pair the "no" with an already-approved alternative that covers the same need.
Needs review
Intake did not capture enough to decide yet. A holding state with a named owner and a due date — not a place requests go to be forgotten.
Step three
What makes "Conditional" a real decision instead of a shrug
"Conditionally approved" only works if the conditions are specific enough to act on. Four elements do most of the work:
- Named data classes that are off-limits. Not "sensitive data" — spell out the actual classes, such as customer records, source code containing secrets, or HR and financial data, that this tool may not touch under this approval.
- Required account type. Company-managed SSO workspace account, not a personal or free-tier account. This one line closes one of the most common gaps between a policy and what people actually do.
- Human review before external use. Anything reaching a customer or leaving the organization gets a person's eyes on it first, for as long as the condition stands.
- A review date. Every Conditional has a date it comes back up for a decision. Without one, "Conditional" quietly becomes permanent — the same as a blanket approval.
Step four
Promote: turning a Conditional into a standing Approved
Promote is a deliberate decision, not something that happens automatically because a review date arrived. Before promoting a tool from Conditional to standing Approved, check that:
- Scope has stayed as described — no new use cases or data types have quietly attached themselves.
- The conditions were actually observed in practice, not just promised on paper.
- There are no open incidents or findings tied to the tool.
- Someone has actively reviewed it since the review date.
If any of that is not true, the outcome is a renewed Conditional with an updated review date, not a default Promote. "Still Conditional" is a fine outcome — it means the process is working.
Keeping it alive
The register and a light quarterly cadence
A tool register — tool, owner, decision, conditions, review date — is only useful if it is the place people actually check, not a document accurate on day one that has since drifted. It does not need to be elaborate. It needs to be current.
A light quarterly review keeps it that way: walk the review dates that have passed or are coming up, note anything new that surfaced as shadow AI, and sunset Conditional entries that were never adopted. It does not need to be a long meeting — it needs to happen on a schedule, whether or not anything feels urgent.
The fast lane
Handling the exception: a pilot that can't wait for the full cycle
Sometimes a team needs to try something in the next two days, not the next review cycle. Give that its own narrow path instead of forcing it through the standard queue or letting it bypass the process: a short, explicit time box (say, 30 days), a named narrow use case, a small named set of users, and a hard sunset date. It still goes in the register — as a time-boxed exception, not an open-ended Conditional. Without that end date, "just a quick pilot" is how unmanaged shadow AI gets its start.
What breaks this in practice
Four failure modes to watch for
Approval bottleneck
Requests queue for weeks on one person's attention. People stop asking and start using tools quietly instead.
A register nobody updates
Decisions exist somewhere, but nobody trusts them, so the same question gets asked again in chat every few weeks.
Decisions with no review date
A Conditional with no date to revisit it is not really conditional — it is a permanent approval nobody chose to make.
One person as the single approver
Beyond the bottleneck: inconsistent judgment and no coverage when that person is out. Name a backup or a small rotating group.
Worked illustration
What a Conditional-first register entry looks like
Fictional ExampleCo scenario. Tool names are used as recognizable categories only — this is not a claim about any real vendor's data handling, and not a recommendation for or against any specific product. Always check a vendor's current terms before relying on anything about training, retention, or account controls.
| Tool | Use case | Risk | Decision |
|---|---|---|---|
| Otter.ai (meeting bot) | Transcribing external sales calls | High | Conditional |
| Fireflies.ai (second meeting bot) | Requested by another team for the same call type | High | Not approved |
| Personal / free AI accounts | Any company work, any team | High | Not approved |
| GitHub Copilot (coding assistant) | Code completion inside company repositories | High | Conditional |
Fictional ExampleCo illustration only. The meeting bot is Conditional on all-party consent and a bounded retention period; the second, overlapping meeting bot is Not approved so the organization is not running two unmanaged tools against the same call data; personal/free accounts are Not approved for any company work; the coding assistant is Conditional on business-tier seats and a secret-scanning check before merge. Risk ratings and conditions are for illustration — not vendor safety claims.
FAQ
Questions people actually ask about this workflow
Should an obviously low-risk tool skip straight to Approved?
Usually no. Low ≠ auto-Approve. A tool that looks harmless on day one can pick up new users or new data types within weeks. Conditional costs almost nothing and adds a checkpoint before that drift becomes a standing, unrestricted approval.
Who should be the approver?
Someone with visibility into both the business use case and the data involved — but never only one person with no backup. A single approver is both a bottleneck and a single point of failure.
What happens if intake doesn't have enough information to decide?
That is what "Needs review" is for: not a rejection, not silence, but a holding state with a named owner and a due date.
Does a Conditional approval expire automatically?
It comes back up for review on its stated date, but moving to standing Approved is a deliberate Promote decision, not an automatic upgrade. If conditions weren't actually followed, the right outcome is a renewed Conditional, not a default Promote.
Where this fits
If you'd rather not build this from scratch
Everything above is the shape of the method — Discover, Decide, Operate — behind the AI Guardrails Kit: an editable acceptable-use policy, approval workflow and intake form, risk-scoring rubric, living tool register, employee guidance, and six tool-specific rollout playbooks, plus sixteen completed sample artifacts in the ExampleCo style shown above.
You can use everything in this guide without buying anything. For the editable, already-built version, browse the ungated sample gallery or the free AI tool checklist first.
The full kit is available now on the product page — Business Pack $79, MSP / Consultant Pack $299, one-time. Questions: hello@railstead.com.
Operational templates only — not legal, compliance, privacy, security, HR, or professional advice. Seller: CurioHausCo LLC.