AI Governance Institute logo
AI Governance Institute

Practical Governance for Enterprise AI

Model & Program Governance
MGV · Model & Program GovernanceMGV-002Medium effortAgent-relevant

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

1

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.

2

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.

3

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.

4

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.

5

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 tierApproval authorityAdditional requirements
LowBusiness owner + IT security sign-offStandard intake record; AI inventory entry
MediumDepartment head + AI governance teamVendor due diligence (PRC-001); data handling review
HighAI governance committeeFull vendor assessment; DPIA if personal data; CISO sign-off
CriticalAI governance committee + executive sponsorAll 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)