AI System Intake and Approval Workflow

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, data protection impact assessment or 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 or personally identifiable information, PHI or protected health information, 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, the connection through which a vendor's AI service receives data)

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 (run on the organization's own infrastructure) 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 (chief information security officer) 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 (AI tools used without the governance team's knowledge or approval) 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) and IT security review (no API access keys or network access without intake). It also connects intake to shadow AI detection (MGV-007, PRC-014).