checklist
AI tool request intake form template for small teams
A practical intake form template for reviewing new AI tool requests, data classes, connectors, browser access, meeting bots, developer AI, approval routing, pilot rules, and evidence.
Use this intake form before a new AI tool, connector, browser extension, meeting bot, coding assistant, or AI agent starts touching work data.
The point is not to slow every request down. The point is to capture enough information to decide quickly: approve, pilot, restrict, reject, escalate, or record a temporary exception. If the request is already active, run it through the AI Tool Risk Checker and then add it to the Small Team AI Security Checklist.
Bottom line
A useful AI tool request intake form should answer nine questions:
- Who owns the business need?
- What tool, feature, extension, bot, connector, or agent is being requested?
- Which users or teams need it?
- What data will enter the workflow?
- What systems will it connect to?
- Can it read, write, export, record, send, update, delete, merge, deploy, or run commands?
- What guardrails are needed before the pilot starts?
- Who approves the data, system access, and operating risk?
- When will the request be reviewed or closed?
If the requester cannot answer those questions, the request is not ready for approval.
When to use intake
| Request | Intake needed? | Why |
|---|---|---|
| New AI chat workspace for internal work. | Yes. | The team needs account, user, retention, sharing, and data rules. |
| AI tool that only touches public marketing copy. | Lightweight. | Low risk, but still needs owner and approved tool status. |
| AI connector to email, Drive, Slack, GitHub, CRM, helpdesk, calendar, or meetings. | Yes. | Connectors can expose broad historical data. |
| AI browser extension for work pages. | Yes. | Extensions may read sensitive apps through the browser. |
| AI meeting bot for sales, support, hiring, or customer calls. | Yes. | Notice, consent, storage, retention, and sharing need rules. |
| Developer AI tool with repo, terminal, PR, or deployment access. | Yes. | Source code, secrets, and production-adjacent actions need controls. |
| Embedded AI feature already inside an approved SaaS tool. | Usually. | Existing app approval may not cover AI training, retention, export, or automation behavior. |
| Emergency use during an incident. | Yes, after containment. | Record the exception and closure decision quickly. |
Default rule: if the tool can see company data or change a business record, use intake.
Intake decision table
| Answer pattern | Initial decision |
|---|---|
| Public data only, no connector, no automation, no sensitive output. | Approve lightly or pilot. |
| Internal non-sensitive data, managed account, limited users, human review. | Pilot with review date. |
| Customer data, source code, transcripts, browser page data, or connectors. | Route to owner review before pilot. |
| Broad write access, automation, terminal commands, production workflows, or bulk exports. | Escalate before approval. |
| Secrets, private keys, passwords, regulated records, legal/HR/finance files, or unclear vendor behavior. | Reject or escalate outside the lightweight path. |
| Tool already in use without approval. | Freeze expansion, record current users, and review as an exception. |
Use this as the first triage, not the final decision.
Request form template
Copy this into a form, ticket, or shared doc.
| Field | Response |
|---|---|
| Request ID | AI-REQ-YYYY-MM-### |
| Request date | |
| Requester | |
| Team | |
| Business owner | |
| Admin owner | |
| Tool or feature name | |
| Vendor URL | |
| Tool type | Chat / coding / meeting bot / browser extension / connector / embedded SaaS AI / agent / automation / other |
| Requested users | |
| Business use case | |
| Expected output | Draft / summary / code / analysis / customer response / record update / automation / other |
| Data class | Public / internal / customer / source code / transcript / HR / finance / legal / regulated / secrets |
| Connected systems | Email / Drive / Docs / Slack / Teams / GitHub / CRM / helpdesk / calendar / meeting / browser / other |
| Access requested | Read / write / export / record / summarize / send / update / delete / merge / deploy / run commands |
| Account model | Managed workspace / personal account / vendor account / browser extension / API / unknown |
| Human review | Required before customer-facing output / code merge / record change / not needed / unknown |
| Retention or deletion need | |
| Sharing or export need | |
| Deadline or urgency | |
| Proposed pilot size | |
| Guardrails proposed | |
| Decision | Approve / pilot / restrict / reject / escalate / temporary exception |
| Review date | |
| Evidence links |
Do not paste customer exports, source code, credentials, contracts, regulated records, or private account data into the intake form.
Required fields
| Field | Why it is required | Reject or pause if missing |
|---|---|---|
| Business owner | Someone must decide whether the use case is worth the risk. | Yes. |
| Tool or feature name | AI risk often depends on the exact feature, not just the vendor. | Yes. |
| Requested users | Approval for one team should not become approval for everyone. | Yes. |
| Data class | Data sensitivity drives routing, guardrails, and review cadence. | Yes. |
| Connected systems | Connectors can expose data without copy-paste. | Yes for integrations. |
| Access requested | Read-only and action-taking tools need different controls. | Yes. |
| Account model | Personal accounts are harder to govern and offboard. | Yes. |
| Human review | AI output may need review before customer, code, or record impact. | Yes for high-risk workflows. |
| Review date | Every pilot or exception needs a stopping point. | Yes. |
If the requester cannot classify the data, route the request to the data owner before approving a pilot.
Data classification questions
| Question | If yes |
|---|---|
| Will the tool process customer names, tickets, contracts, transcripts, CRM records, attachments, or account details? | Use the customer data approval form. |
| Will it process private source code, repository context, incidents, logs, or production configuration? | Route to engineering owner. |
| Will it process meeting audio, transcripts, summaries, recordings, or clips? | Route to meeting bot policy review. |
| Will it read browser pages such as Gmail, Docs, CRM, password manager, SSO, admin, HR, finance, or source-control pages? | Route to browser extension review. |
| Will it process HR, finance, legal, health, payment, government, child, or regulated data? | Escalate outside the lightweight intake path. |
| Could it receive secrets, private keys, passwords, API keys, session cookies, or recovery codes? | Reject the workflow and define prevention controls. |
This is where small teams usually find the real risk. The tool name matters less than the data and access path.
Connector and access questions
| Access path | Intake question |
|---|---|
| Which mailbox, labels, attachments, history, and external messages will be available? | |
| Drive or Docs | Which folders, shared drives, file types, comments, and external shares are available? |
| Slack or Teams | Which channels, DMs, files, and message history are available? |
| GitHub or GitLab | Which repos, issues, PRs, actions, code search, and write permissions are available? |
| CRM or helpdesk | Which customer records, tickets, notes, contracts, exports, and attachments are available? |
| Calendar or meetings | Which meeting titles, attendees, recordings, transcripts, summaries, and integrations are available? |
| Browser extension | Which hosts can be read, which permissions are requested, and which OAuth scopes are used? |
| API or automation | Which keys, scopes, rate limits, actions, logs, and rollback paths exist? |
For connector-heavy requests, use the ChatGPT connector approval template even if the vendor is not ChatGPT. The review questions still apply.
Workflow risk questions
| Question | Higher-risk answer |
|---|---|
| Does the AI output go directly to a customer, candidate, vendor, regulator, or public page? | Yes, without human review. |
| Can the tool update CRM, helpdesk, calendar, repo, ticket, document, or production records? | Yes, with broad write access. |
| Can it run terminal commands, deploy code, merge PRs, delete data, or export records? | Yes. |
| Can it remember data across sessions, projects, or users? | Yes, and memory cannot be scoped. |
| Can it share outputs automatically to Slack, email, CRM, Drive, or external users? | Yes, by default. |
| Can employees install or connect it without admin review? | Yes. |
| Is the vendor behavior unclear for training, retention, deletion, subprocessors, or support access? | Yes. |
High-risk answers do not always mean “no.” They do mean the request needs stronger routing and guardrails.
Approval routing
| Trigger | Required approver |
|---|---|
| Public content only | Business owner. |
| Internal non-sensitive data | Business owner and admin owner. |
| Customer data | Business owner, admin owner, and data owner. |
| Source code, repos, terminal, PRs, or CI/CD | Engineering owner and admin owner. |
| Meeting recording, transcript, or CRM sync | Business owner for the function and meeting data owner. |
| Browser extension with work page access | IT/admin owner and affected app owner. |
| Connector to email, Drive, Slack, GitHub, CRM, helpdesk, calendar, or meetings | Source-system owner. |
| HR, finance, legal, regulated, production, or broad automation | Escalate outside lightweight intake. |
For temporary approvals, create an AI tool exception register entry before use.
First response SLA
| Request type | First response target | Response |
|---|---|---|
| Low-risk public-content tool | 2 business days | Approve lightly, ask one follow-up, or reject. |
| Internal tool with managed account and no connector | 3 business days | Pilot or request settings evidence. |
| Customer data, source code, meeting bot, browser extension, or connector | 5 business days | Route to owner review and pilot decision. |
| Production, regulated data, broad write access, or unclear vendor risk | 5 business days for routing only | Escalate or reject from lightweight path. |
| Incident-related urgent request | Same business day | Contain first, then record exception and closure plan. |
The SLA is for triage, not guaranteed approval.
Pilot rules
| Rule | Default |
|---|---|
| Pilot size | 1 team or 3-5 users. |
| Pilot duration | 30 days for high-risk, 60 days for medium-risk, 90 days for low-risk. |
| Data | Use public or internal non-sensitive data unless a data owner approves more. |
| Connectors | Approve exact systems, scopes, and user groups. |
| Browser extensions | Approve exact extension ID and hosts. |
| Meeting bots | Define notice, storage, retention, sharing, and deletion before recording. |
| Developer AI | Define repo scope, secret controls, terminal command tiers, and PR review. |
| Output | Require human review before customer, code, record, or public impact. |
| Closure | End with keep, restrict, reject, escalate, or convert to standard approval. |
If the pilot cannot be contained, it is not a pilot.
Denial and alternatives
Rejecting a request should still help the team move.
| Reason to deny | Alternative |
|---|---|
| Secrets or credentials could enter the tool. | Use a redaction workflow and secret scanning before AI use. |
| Customer data is not approved. | Use synthetic or redacted data and the customer data approval form. |
| Connector scope is too broad. | Limit folders, labels, channels, repos, or user groups. |
| Browser extension can read sensitive sites. | Use an approved web app, limited host permissions, or a separate browser profile. |
| Meeting bot retention is unclear. | Use manual notes or a tool with clear deletion settings. |
| Developer AI can run risky commands. | Restrict to read-only or local-only command tiers. |
| Vendor behavior is unclear. | Ask for documentation or choose an already approved tool. |
The best denial is specific enough that the requester knows how to resubmit safely.
Evidence packet
Keep request evidence lightweight and non-sensitive.
AI tool request intake evidence
Request ID:
Review date:
Requester:
Business owner:
Admin owner:
Tool or feature:
Use case:
Requested users:
Data class:
Connected systems:
Access requested:
Risk Checker result:
Approval routing:
Decision:
Pilot scope:
Guardrails:
Review date:
Evidence links:
Notes:Store the packet outside the AI tool under review. Do not include passwords, API keys, private keys, session cookies, raw customer records, source code, payroll data, legal files, or regulated records.
Metrics to track
| Metric | What it tells you |
|---|---|
| New AI requests per month | Whether demand is growing faster than review capacity. |
| Requests by tool type | Which clusters need standard rules. |
| Requests by data class | Whether risky workflows are increasing. |
| Median first response time | Whether intake is usable or becoming a blocker. |
| Approved, piloted, rejected, escalated | Whether decisions are clear. |
| Temporary exceptions created | Whether requests are bypassing standard approval. |
| Pilots converted to standard approval | Which tools deserve deeper content or product support. |
| Incidents tied to approved tools | Whether intake questions missed important risk. |
Do not overbuild reporting before requests are consistently recorded.
Evidence checked
- NIST: AI Risk Management Framework
- NIST: Cybersecurity Framework
- NIST: Privacy Framework
- Cybergiz: AI Tool Risk Checker
- Cybergiz: Small Team AI Security Checklist
- Cybergiz: AI tool exception register template
- Cybergiz: Monthly AI tool access review checklist
FAQ
Who should fill out the AI tool request form?
The requester should fill out the business need, users, workflow, and deadline. The admin owner should fill out account model, connectors, access, settings, and evidence. The data or source-system owner should confirm the data class.
Should every AI tool request go through this form?
Use a lightweight version for public-content tools. Use the full form for customer data, source code, meeting transcripts, browser extensions, connectors, automation, or tools that can change business records.
What if the tool is already being used?
Record the current users and workflow, freeze expansion, run the tool through the AI Tool Risk Checker, and create an exception record if it needs temporary use while review is pending.
How fast should small teams respond?
Aim for two business days for low-risk public-content tools, three business days for internal tools, and five business days for customer data, developer AI, meeting bots, browser extensions, or connectors. Escalation may take longer.
What should automatically escalate?
Secrets, regulated records, broad write access, production actions, unclear vendor behavior, bulk customer exports, HR/legal/finance data, and terminal-capable agents with risky commands should leave the lightweight intake path.
How does this connect to monthly review?
Approved tools, pilots, rejected requests, and temporary exceptions should feed the monthly AI tool access review checklist. The monthly review checks whether pilots closed, exceptions expired, and standard approvals still match real usage.