Every enterprise that adopts Claude eventually faces the same coordination problem: ideas for new uses arrive faster than any central team can build them, and without a defined front door, they either die in email threads or ship as shadow IT. An intake process solves this with two artifacts — a short form that captures what reviewers need to know, and a funnel with named owners at each stage. This article describes a structure to adapt; sizes and stages should scale to your organization.
The form: eight questions, one page
The intake form's job is to collect exactly enough for triage and risk tiering — no more. Eight questions cover most of it:
1. Owner. One named person accountable for the use case (see defining AI roles). 2. Purpose. What the use case does, in two sentences a non-specialist can understand. 3. Data in. Which data types and classification tiers will enter prompts — answered against your data sensitivity matrix. 4. Audience. Who sees the output: the author only, internal teams, or external parties. 5. Output destination. Where the output goes — a human reader, a document, or a downstream system that acts on it. 6. Autonomy. Does a human review output before anything happens, or does it flow automatically? 7. Platform. Which approved deployment — the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Vertex AI, or Microsoft Foundry. 8. Scale. Rough expected volume and users, so cost and rate expectations are visible early.
The funnel: five stages, each with an owner
| Stage | What happens | Owner |
|---|---|---|
| 1. Submission | Employee files the form; automatic acknowledgment with a tracking ID | Requesting employee |
| 2. Triage | Deduplicate, reject out-of-scope ideas kindly, assign a preliminary risk tier | AI program lead |
| 3. Risk assessment | Tier confirmed; low-risk cases route to the fast track, higher tiers to full review | Risk/governance function |
| 4. Review & approval | The relevant approval gates examine evidence and sign off, with conditions if needed | Gate owners (security, privacy, legal, business) |
| 5. Deployment & registration | Use case is provisioned, entered in the AI registry with owner, tier, and review date | Platform/engineering team |
Two funnel disciplines matter more than the stage count. Time bounds: publish a target turnaround per tier — if low-risk requests take six weeks, the funnel is training people to bypass it. No silent deaths: every submission ends in an explicit approve, reject-with-reason, or park-with-date. A funnel that swallows ideas breeds shadow deployments.
Provisioning: make approval mean something concrete
On the Claude API and Claude Platform on AWS, the natural unit to provision per approved use case is a workspace: workspaces separate projects, environments, or teams under centralized billing and administration, an organization can have up to 100 (archived ones don't count), and API keys are scoped to a single workspace. That makes the approval tangible — the use case gets its own keys, its own spend cap and rate limits (settable lower than the organization's, never higher), and its own line in usage reporting. When a use case is rejected later or sunset, archiving its workspace immediately revokes all its API keys. On Bedrock, Vertex AI, and Foundry, the equivalent provisioning unit is your cloud's account/project structure — align it with the same registry entry.
Where to go next
The intake funnel hands off to approval gates for review and to the enterprise AI registry for the permanent record. For what reopens a closed review, see when use-case changes require a new review.