TL;DR: Before any new AI tool goes live, run it through this six-phase intake workflow. Phase 1 captures the request and business case. Phase 2 classifies risk. Phases 3 and 4 handle security and legal review. Phase 5 sets deployment conditions. Phase 6 establishes ongoing monitoring. Low-risk tools can move through the process in a day. High-risk tools need the full workflow before a single employee touches them.
An AI intake workflow is the internal process your organization uses to evaluate, approve, and onboard new AI tools before they go into production use. It sits upstream of vendor evaluation. The AI vendor evaluation checklist asks whether a specific vendor is trustworthy. The intake workflow asks whether you should adopt this type of tool at all, for what purpose, under what constraints, and with what oversight.
Without an intake workflow, AI adoption happens informally. Someone in marketing signs up for an AI writing tool using a company card. Engineering adds an AI code assistant to the shared repository. Customer success connects a chatbot to your CRM. Each of these decisions carries legal exposure, data handling risk, and compliance implications that never get reviewed. That is shadow AI, and it is the most common source of AI governance failures at small organizations.
This template gives you a six-phase workflow you can adapt to your team size and risk tolerance. It is designed to be proportionate: a low-risk tool (an AI grammar checker with no sensitive data access) should move through this process in one business day. A high-risk tool (an AI system that influences employment decisions) needs the full workflow, documented and signed off before deployment.
Phase 1: Request and business justification
Purpose: Capture what is being requested and why, before any technical review begins.
Every AI tool request should start with a written intake form. The form does not need to be complex. It needs to answer four questions:
- What is the tool, and what does it do?
- What business problem does it solve, and what is the expected benefit?
- Who will use it, and in what context?
- Who is the business sponsor accountable for this tool?
The business sponsor is the person who owns the use case and will be accountable for the tool's outcomes. This is not the person who requested the tool; it is the manager or team lead responsible for the function where the tool will operate. Without a named sponsor, there is no one to call when something goes wrong.
Output: Completed intake request form with named business sponsor.
Intake form fields:
- Tool name and vendor
- Requested by (name, team, date)
- Business sponsor (name, title)
- Intended use case (one paragraph)
- Data the tool will access or process
- Number of employees who will use it
- Estimated cost and contract term
- Does the tool replace an existing process or vendor?
Phase 2: Risk classification
Purpose: Determine how much scrutiny this tool requires before the review teams spend time on it.
Not every tool carries the same risk. A risk classification at the intake stage routes low-risk tools through a fast track and ensures high-risk tools get the attention they need.
Classify by the combination of data sensitivity and decision impact:
High risk (requires full workflow, all six phases, legal sign-off, documented approval):
- Tool processes personal data of employees or customers
- Tool influences hiring, performance evaluation, promotion, or termination decisions
- Tool influences access to financial services, credit, or insurance
- Tool processes health, biometric, or other sensitive category data
- Tool is customer-facing and makes automated decisions affecting individuals
- Intended use case falls within EU AI Act Annex III categories (see EU AI Act Annex III guide)
Medium risk (requires phases 1-4 with abbreviated review):
- Tool accesses business-confidential data but not personal data
- Tool is used internally by a small group with no customer-facing outputs
- Tool produces outputs that inform but do not automate decisions
Low risk (fast track, phases 1, 2, and 5 only):
- Tool processes only publicly available or non-sensitive data
- Tool is used by a single employee for personal productivity
- Tool has no integration with company systems or data
Output: Risk tier assigned (High / Medium / Low). High-risk tools proceed to Phase 3. Low-risk tools skip to Phase 5.
Phase 3: Security and privacy review
Purpose: Confirm the tool meets your organization's data handling standards before legal review begins.
Security and privacy review is typically owned by IT or the DPO. It focuses on how the vendor handles data, what data flows are created, and whether those flows comply with applicable law.
Data handling:
- Does the vendor train on customer or user data by default? If yes, can training be opted out?
- Where is data processed and stored? Is EU data processed outside the EU?
- What is the vendor's data retention period? Can data be deleted on request?
- Does the vendor have a published data processing agreement (DPA)?
- Will this tool process personal data of EU residents? If yes, a DPA is required before deployment.
- Will this tool process personal information of California residents? If yes, confirm the vendor qualifies as a service provider under CCPA and a data processing addendum is in place.
- Does the tool involve automated decision-making that produces legal or similarly significant effects on individuals? If yes, GDPR Article 22 obligations apply.
Security baseline:
- Does the vendor hold SOC 2 Type II, ISO 27001, or equivalent certification?
- Does the vendor have a published incident response and breach notification policy?
- What authentication and access control does the tool provide?
- Has your IT team reviewed the tool's API access and data scope?
Output: Security and privacy clearance (approved / approved with conditions / not approved).
Conditions commonly imposed at this stage: restricting which data categories the tool can access, requiring a DPA to be signed before login credentials are issued, or limiting integration to read-only access.
Phase 4: Legal and compliance sign-off
Purpose: Confirm the tool does not create regulatory exposure before deployment conditions are set.
Legal review at the intake stage is not about reviewing the entire vendor contract. It is a focused check on three questions: does this tool trigger regulatory obligations, does the intended use create liability, and does the contract protect the organization?
EU AI Act check:
- Is the tool's intended use case listed in Annex III of the EU AI Act? If yes, deployer obligations under Article 26 apply.
- Has the vendor provided technical documentation and instructions for use as required for high-risk systems?
- Is a fundamental rights impact assessment (Article 27) required for this deployment context?
Employment law check:
- Will this tool be used in any employment decision process? If yes, check NYC Local Law 144, EEOC guidance, and applicable state bias audit requirements.
- Does the tool monitor employee activity? If yes, confirm employee notification requirements under applicable law.
IP and output ownership:
- Who owns outputs generated by the tool? Confirm contract terms.
- Does the tool's training data or output create copyright exposure for your use case?
Contract review:
- Does the vendor contract include appropriate indemnification for regulatory compliance failures?
- What are the data deletion and portability terms at contract end?
Output: Legal sign-off (approved / approved with conditions / escalated to outside counsel).
For tools that qualify as high-risk AI under the EU AI Act, add the tool to your AI register at this stage, before deployment.
Phase 5: Deployment conditions
Purpose: Define the specific terms under which the tool is approved for use.
Approval is not binary. Most tools are approved for specific use cases, with specific data access limits, specific employee groups, and specific restrictions. These conditions need to be documented and communicated before any employee uses the tool.
- Approved use case(s): specify exactly what the tool may be used for
- Prohibited use cases: specify what the tool may NOT be used for
- Approved data types: list what data the tool may access or process
- Prohibited data types: list what data must not be entered into the tool
- Approved users: name the team or role group authorized to use the tool
- Integration scope: specify which systems the tool may connect to
- Employee notification: confirm employees have been informed that this tool is in use (required for monitoring tools under many jurisdictions)
- Training requirement: specify any required training before use
The deployment conditions are the operational terms of your AI acceptable use policy for this specific tool. They should be communicated to the approved user group before access is provisioned.
Output: Signed deployment conditions document. Tool added to the AI governance checklist and AI register.
Phase 6: Ongoing monitoring
Purpose: Ensure the tool continues to operate within approved conditions over time.
Approval at intake does not mean permanent approval. Tools change. Vendors change their data practices. Use cases drift. Regulations change. A quarterly monitoring check catches problems before they become incidents.
Quarterly review:
- Is the tool still being used only for approved use cases?
- Has the vendor changed their data handling or privacy policy?
- Have any incidents, breaches, or near-misses been reported?
- Are the employees using the tool still within the approved user group?
- Has the regulatory landscape changed in ways that affect this tool?
Annual renewal:
- Re-run the risk classification check: has the tool's capabilities or your use case changed?
- Confirm the vendor's DPA and security certifications are current.
- Confirm the tool's contract and pricing still reflect business value.
Offboarding process:
- When the tool is decommissioned, confirm all data is deleted per the vendor's process.
- Revoke all employee access and integrations before contract termination.
- Document the offboarding in the AI register.
Output: Quarterly monitoring record. Annual renewal decision (continue / reclassify / offboard).
Printable intake checklist (all phases)
Use this flat list for a quick reference during the intake process.
Phase 1: Request
- Intake form completed with tool name, vendor, use case, and business sponsor
Phase 2: Risk classification
- Risk tier assigned: High / Medium / Low
- Fast-track or full workflow confirmed
Phase 3: Security and privacy
- Vendor training data policy confirmed
- Data storage and transfer locations confirmed
- DPA signed (if personal data involved)
- CCPA service provider addendum signed (if applicable)
- Security certifications reviewed (SOC 2 / ISO 27001)
- IT integration scope approved
Phase 4: Legal and compliance
- EU AI Act Annex III check completed
- Employment law triggers checked
- IP and output ownership confirmed in contract
- Legal sign-off obtained
Phase 5: Deployment conditions
- Approved and prohibited use cases documented
- Approved data types documented
- Approved user group defined
- Employee notification completed
- Training requirement confirmed
- Tool added to AI register
Phase 6: Monitoring
- Quarterly review date set
- Monitoring owner named
- Offboarding trigger conditions defined
Related Reading
- Your Coworker Is Fact-Checking You With AI Mid-Conversation
- AI vendor evaluation checklist: 30 questions before you sign
- Shadow AI policy for small teams: what to do when employees use unapproved AI
- AI governance checklist 2026: complete list for small teams
- AI acceptable use policy template for small teams
- EU AI Act Annex III: full guide to high-risk AI system categories
- Free AI register template: track every AI tool in your organization
- CEO AI tool approval checklist: what to review before signing
