AI System Intake and Approval Workflow
Define a standardized intake process for all new AI system deployments that captures use case, data classification, risk tier, and ownership before the system enters the organization's environment, with cross-functional approval routing and GRC recordkeeping.
Objective
Ensure every AI system deployed in the organization follows a documented intake process that produces a complete risk record, assigns accountability, and routes approval to the appropriate authority before deployment begins.
Maturity Levels
Initial
There is no formal intake process for AI deployments. Teams deploy AI systems independently without centralized visibility or approval. The organization does not have a complete inventory of AI systems in use.
Developing
An informal intake process exists for some AI deployments. High-profile deployments may receive governance review, but smaller or embedded AI capabilities are not captured. Intake records are inconsistent.
Defined
A documented intake form captures: system name and description, intended use case and business owner, data types processed, risk tier classification (per HOC-001), vendor and model details, approval routing based on risk tier, and planned deployment date. Intake records are stored in the GRC system and linked to the AI inventory.
Managed
The intake workflow is integrated into the organization's change management or project management process so that AI systems cannot be procured or deployed without a completed intake record. Risk tier determines approval authority: higher tiers require AI governance committee review. Intake status is tracked to completion.
Optimizing
Intake analytics identify patterns in AI deployment types, risk concentrations, and approval cycle times. Intake requirements are updated when new AI categories (e.g., agentic systems, multimodal) emerge that require additional assessment. Intake records are used to populate the AI model registry automatically.
Evidence Requirements
What an auditor or assessor would expect to see for this control.
- —Documented intake form template covering all required fields and approval routing rules by risk tier.
- —GRC system or equivalent containing intake records for all known AI deployments, with status tracking.
- —Evidence that intake workflow is connected to procurement or IT access controls to prevent deployment without a completed record.
- —AI inventory populated from intake records, with coverage validation showing no material gaps.
Implementation Notes
The intake function in the governance stack
The AI system intake workflow is the first control in a sequence that governs new AI deployments. Its job is to create a record, assign ownership, establish risk tier, and route the deployment to the appropriate approval path before any subsequent governance steps are taken. Downstream controls (staged release policy, milestone framework, vendor due diligence, DPIA) depend on the intake record existing and being accurate.
Without a functioning intake workflow, the organization's other governance controls operate on an incomplete picture of what AI systems are actually deployed. This is one of the most common failure modes identified in enterprise AI governance audits: organizations have strong controls on paper that apply to AI systems they know about, while a significant portion of actual AI use occurs outside the governance perimeter.
Key fields in the intake form
Identity and ownership:
- System name and version
- Business owner (person accountable for the system's outcomes)
- Technical owner (person responsible for maintaining and operating the system)
- Date of first intended use
Use case and scope:
- Description of intended use
- User population (internal employees, external customers, both)
- Decision types the system will support or make (informational, advisory, consequential)
- Integrations with other systems
Data and privacy:
- Data types processed (list all: PII, PHI, financial, regulated, internal, public)
- Whether personal data is involved and whether a DPIA has been completed or is required
- Data residency (where data will be processed and stored)
- Whether data will leave organizational control (e.g., sent to a vendor API)
Risk and compliance:
- Risk tier (per HOC-001): low, medium, high, critical
- Applicable regulations identified
- Any known compliance requirements specific to the use case
System details:
- Vendor name and model identifier (for externally sourced AI)
- Whether the system is self-hosted or vendor-hosted
- Release stage (experimental, production-approved, per MGV-001)
- Related vendor assessment status (per PRC-001)
Approval routing by risk tier
| Risk tier | Approval authority | Additional requirements |
|---|---|---|
| Low | Business owner + IT security sign-off | Standard intake record; AI inventory entry |
| Medium | Department head + AI governance team | Vendor due diligence (PRC-001); data handling review |
| High | AI governance committee | Full vendor assessment; DPIA if personal data; CISO sign-off |
| Critical | AI governance committee + executive sponsor | All high-risk requirements + legal review + board notification |
Preventing shadow AI through intake design
The intake process only prevents shadow AI if it is connected to procurement and IT controls. Intake forms that exist but are optional produce intake data for systems that owners chose to register while leaving unregistered systems undetected. Effective intake design connects the intake trigger to procurement (no AI vendor payment without intake record), IT security review (no API credentials or network access without intake), and shadow AI detection (MGV-007, PRC-014).
Example Implementation
AI System Intake Form — Summary (completed example)
Intake ID: AI-2026-047 | Submitted: 2026-05-12 | Status: Approved
System: Internal Legal Research Assistant (contract analysis, case law summarization) Business owner: General Counsel | Technical owner: IT Engineering Lead Intended first use date: 2026-06-01
Use case: Summarize and extract key provisions from vendor contracts for legal team review. System produces summaries for human review; does not make decisions autonomously. User population: Legal team (12 users) | Decision type: Advisory (human reviews all outputs)
Data: Attorney-client privileged documents, vendor contracts. Contains PII (counterparty names, signatory information). Data sent to vendor API (outside organizational control). DPIA required: Yes — scheduled for 2026-05-20.
Risk tier: High | Applicable regulations: EU AI Act (provider obligations), CCPA (PII in contracts), state bar AI guidance
Vendor: [Vendor name] | Model: [Model identifier] | Hosted: Vendor-hosted SaaS API Vendor assessment status: PRC-001 in progress (due 2026-05-22) Release stage: Experimental (pending full approval)
Approval routing (High tier):
- Department head: Approved 2026-05-14
- CISO: Approved 2026-05-18 (pending DPIA completion)
- AI Governance Committee: Approved 2026-05-28 (conditional on DPIA sign-off)
- DPIA completed and signed off: 2026-05-25
Final approval date: 2026-05-28 | Stage at approval: Limited production (legal team only)
