How to Build an AI Use Case Intake Workflow

Why does intake come first?

AI governance starts before the AI system goes live.

Not after the vendor is approved.
Not after customer data is connected.
Not after employees start using the tool.
Not after prompts and outputs are stored.
Not after legal asks whether the contract allows training.
Not after privacy asks whether personal data is involved.
Not after cyber asks how the tool integrates.
Not after the board asks how many high-risk AI use cases exist.

AI governance starts at intake.

That is the point where the organization decides whether an AI use case is low risk, high risk, prohibited, allowed only as a pilot, approved with conditions, or ready for deployment.

A good AI intake workflow helps teams answer:

• What is the AI use case?
• Who owns it?
• What business process does it support?
• What data does it use?
• Is personal or sensitive data involved?
• Is a vendor or model provider involved?
• Does the AI affect customers, employees, applicants, or other people?
• Does it influence decisions?
• Is human oversight required?
• What reviews are needed?
• What risk tier applies?
• What controls are required?
• What evidence must be collected?
• What approval conditions apply?
• What monitoring is required after launch?
• What happens if the use case changes?

Without intake, AI governance becomes reactive.

Teams discover AI use through expense reports, vendor renewals, employee experimentation, security alerts, privacy assessments, customer questions, or audit requests.

By then, the AI use case may already be operating.

What is an AI use case intake workflow?

An AI use case intake workflow is the structured process for capturing, assessing, routing, approving, monitoring, and documenting AI use cases before they are purchased, built, piloted, deployed, expanded, or materially changed.

A strong AI intake workflow should capture:

• AI use case
• business purpose
• business owner
• technical owner
• model or system owner
• lifecycle stage
• data used
• affected stakeholders
• vendor or model provider
• decision impact
• risk tier
• privacy review
• cyber review
• legal review
• vendor review
• required controls
• evidence
• approval decision
• approval conditions
• monitoring requirements
• reassessment triggers
• issues and remediation
• risk acceptance

NIST’s AI RMF Core is a useful structure because it organizes AI risk management around Govern, Map, Measure, and Manage, and emphasizes continuous, lifecycle-based risk management. Intake is where organizations begin to map context, establish governance, and route AI risks into the right review workflow.  

A weak AI intake process asks:

“What AI tool do you want to use?”

A strong AI intake process asks:

“What business process will this AI affect, what data will it use, who could be impacted, what risk tier applies, what controls are required, what evidence supports approval, and how will the use case be monitored after launch?”

That is the difference.

Why does AI intake matter?

AI intake matters because organizations cannot govern what they cannot see.

An AI policy is not enough.

A training campaign is not enough.

A spreadsheet inventory is not enough if no workflow keeps it current.

AI use enters organizations through many paths:

• employee productivity tools
• SaaS platforms with embedded AI
• customer support tools
• vendor-provided AI features
• internally developed models
• generative AI pilots
• analytics workflows
• code assistants
• chatbots
• document processing
• fraud detection
• hiring or HR tools
• pricing or underwriting models
• legal review tools
• cyber detection tools
• product features
• customer-facing automation

Some AI use cases are low risk.

Some require privacy, cyber, legal, vendor, compliance, or executive review.

Some should be approved only with conditions.

Some should be paused.

Some should be rejected.

The EU AI Act’s risk-based model is useful because it recognizes that AI systems do not all create the same risk. The European Commission describes categories including unacceptable risk, high risk, transparency risk, and minimal or no risk.  

That risk-based mindset applies broadly:

Not every AI use case needs the same review, but every AI use case needs enough intake to know which review path it belongs on.

Why is AI intake more than a form?

An AI intake form is only one part of the workflow.

A real AI intake workflow should create connected records.

The intake should link to:

• AI inventory
• data inventory
• vendor record
• contract
• system record
• business process
• privacy review
• cyber review
• legal review
• AI risk assessment
• required controls
• evidence
• issues
• approval decision
• monitoring plan
• risk acceptance
• dashboard

If intake is only a form, it becomes a queue.

If intake is connected to records, it becomes the start of the AI governance lifecycle.

SmartSuite’s AI Governance page describes this connected model: centralized AI inventories, structured assessments, monitoring cycles, issues, remediation, evidence, and dashboards linked across AI models, risks, controls, laws, frameworks, business processes, and evidence.  

That is what an AI intake workflow should enable.

The AI Use Case Intake Workflow Model

A practical AI use case intake workflow has 12 stages:

1. Submit the AI use case request.
2. Confirm whether AI is involved.
3. Capture business context and ownership.
4. Identify data used.
5. Identify systems, vendors, and model providers.
6. Screen for prohibited or unacceptable use.
7. Assess people, decision, and transparency impact.
8. Route privacy, cyber, legal, vendor, and compliance reviews.
9. Assign risk tier.
10. Define controls, evidence, and approval conditions.
11. Approve, reject, condition, escalate, or pause.
12. Monitor, reassess, and update dashboards.

Each stage should be simple enough to operate and structured enough to defend.

1. When should an AI use case request be submitted?

The intake process should start whenever a business team wants to:

• purchase an AI tool
• build an AI system
• enable an AI feature
• use a general-purpose AI tool
• integrate AI into a workflow
• deploy an AI model
• use AI in a product
• use AI with customer data
• use AI with employee data
• use AI for decision support
• expand an existing AI use case
• change data used by an AI system
• change users, outputs, or monitoring
• move an AI use case from pilot to production

The request should not begin with a 50-question assessment.

Start with enough information to route the use case.

Useful first fields:

• use case name
• requestor
• business owner
• business process
• AI tool or system
• lifecycle stage
• vendor involved
• data involved
• intended users
• affected stakeholders
• expected output
• launch or pilot date
• urgency
• known risks or constraints

The first goal is routing.

Not exhaustive review.

2. Is AI actually involved?

This sounds obvious, but it is often not.

Teams may not realize AI is involved when:

• AI is embedded in an existing SaaS tool
• a vendor adds AI functionality
• automation uses machine learning
• analytics uses predictive scoring
• a chatbot is powered by a model provider
• a workflow uses generative AI to draft or summarize content
• a tool uses AI for classification, ranking, detection, or recommendations

The intake workflow should ask:

• Does the tool generate, summarize, classify, rank, recommend, predict, score, decide, detect, or automate?
• Does the vendor market the feature as AI, machine learning, generative AI, predictive analytics, or intelligent automation?
• Is a model provider involved?
• Are prompts or outputs used?
• Are model-generated recommendations used in the business process?
• Does the system adapt or learn over time?

If the answer is yes or unclear, route to AI governance screening.

Do not rely on tool names.

AI can be embedded quietly.

3. What business context should intake capture?

AI risk depends on how the AI is used.

The intake should capture:

• business purpose
• business process
• expected benefit
• users
• affected customers, employees, applicants, vendors, or other groups
• decision impact
• operational dependency
• criticality
• current manual process
• owner
• approver
• timeline

Ownership matters.

A use case should have:

• business owner
• technical owner
• AI use-case owner
• model owner, where relevant
• system owner
• data owner, where relevant
• vendor owner, where relevant
• monitoring owner
• issue owner

AI governance should not own the business use case.

AI governance coordinates review and oversight.

The business owns the use.

Business context checklist

If these answers are unclear, the intake record is not ready for risk assessment.

4. What data does the AI use?

Data is often the main AI risk driver.

The intake should identify:

• data categories
• personal data
• sensitive personal data
• regulated data
• confidential business data
• customer data
• employee data
• financial data
• source code
• security data
• prompts
• outputs
• logs
• training data
• fine-tuning data
• retrieval data
• evaluation data

Ask:

• What data will the AI system use?
• Where does the data come from?
• Who owns the data?
• Is the data approved for this use?
• Will the data be uploaded to a vendor?
• Will prompts or outputs be stored?
• Can the vendor use the data for training?
• Can users enter sensitive data?
• Does the AI output contain personal or confidential data?
• What retention applies?

If personal or sensitive data is involved, privacy review may be required.

If confidential business data, source code, security data, or regulated data is involved, legal, cyber, or compliance review may be required.

Data should link to the data inventory.

Data intake checklist

A use case with unknown data should not proceed to approval.

5. Which systems, vendors, and model providers are involved?

AI intake should identify the technology and third-party ecosystem.

Capture:

• internal system
• AI tool
• SaaS product
• model provider
• vendor
• cloud provider
• integration
• API
• data warehouse
• application
• plugin
• agent
• subprocessor
• deployment environment
• production or non-production use

Vendor involvement matters because AI vendors can introduce data, contract, cyber, retention, and monitoring risk.

Ask:

• Is this internally developed or third-party?
• Is the AI feature embedded in an existing vendor tool?
• Is a model provider involved?
• Are subprocessors involved?
• Does the vendor process personal or sensitive data?
• Does the vendor retain prompts, outputs, or logs?
• Does the vendor use customer data for training?
• Does the contract address AI-specific data use?
• Does vendor evidence exist?
• Is renewal affected?

A vendor AI feature should not bypass intake because the vendor is already approved.

New AI functionality can change the risk profile.

6. Screen for prohibited, blocked, or unacceptable use

Some AI use cases should be blocked before full review.

Organizations should define prohibited use based on law, policy, values, risk appetite, and operating context.

Examples may include:

• social scoring
• harmful manipulation
• exploitation of vulnerable groups
• prohibited biometric uses
• unauthorized surveillance
• unapproved employee monitoring
• fully automated decisions in prohibited contexts
• use of sensitive data without required review
• use of unapproved public AI tools with confidential data
• AI-generated legal, medical, financial, or employment decisions without required oversight
• AI use that violates customer commitments
• AI use that violates internal policy

The EU AI Act describes unacceptable-risk AI systems as those considered a clear threat to safety, livelihoods, and rights, and lists prohibited practices such as harmful manipulation, harmful exploitation of vulnerabilities, social scoring, certain biometric categorization, and emotion recognition in workplaces and education institutions.  

Even outside EU AI Act scope, organizations should have an internal prohibited-use screen.

This prevents obviously unacceptable use cases from consuming review capacity.

Prohibited-use screening checklist

Prohibited use should create a clear outcome: rejected, suspended, or escalated.

7. Who could be affected by the AI output?

AI use cases become more sensitive when they affect people.

The intake should ask:

• Who could be affected by the AI output?
• Does the output affect customers?
• Does it affect employees?
• Does it affect applicants?
• Does it affect vendors?
• Does it affect access to services?
• Does it rank, score, recommend, classify, or predict outcomes about people?
• Does it support hiring, promotion, discipline, pricing, credit, fraud, eligibility, or access?
• Is the output customer-facing?
• Is disclosure required?
• Is human oversight required?
• Can users challenge the outcome?
• Is the AI output explainable enough for the use case?

The EU AI Act identifies high-risk AI use cases that can pose serious risks to health, safety, or fundamental rights, including use in education, employment, access to essential services, law enforcement, migration, and administration of justice; it also identifies high-risk obligations such as risk assessment, data quality, logging, documentation, information to deployers, human oversight, robustness, cybersecurity, and accuracy.  

For intake purposes, the practical rule is:

If AI affects people, route it carefully.

Impact checklist

This stage helps separate low-risk productivity use from high-impact AI.

8. Route privacy, cyber, legal, vendor, and compliance reviews

AI intake should not force every use case through every review.

Route based on risk triggers.

Privacy review triggers

Route to privacy when:

• personal data is used
• sensitive data is used
• employee or customer data is involved
• AI output affects people
• profiling, scoring, or automated recommendations are involved
• prompts or outputs contain personal data
• retention or deletion is unclear
• DPIA or PIA may be required

Cyber review triggers

Route to cyber when:

• production systems are connected
• sensitive data is processed
• vendor or model provider access exists
• API integration is used
• authentication or authorization is required
• logs or monitoring are needed
• vulnerability or data leakage risk exists
• AI security risks such as prompt injection or misuse are relevant

Legal review triggers

Route to legal when:

• contract terms are needed
• data-use restrictions are unclear
• training rights are unclear
• IP ownership is relevant
• disclosure obligations may apply
• employment, consumer, financial, health, or regulated decisions are involved
• cross-border processing is involved
• customer commitments are implicated

Vendor review triggers

Route to vendor risk when:

• third-party AI tool is used
• existing vendor adds AI feature
• model provider is involved
• vendor processes data
• subprocessors are involved
• vendor evidence is needed
• renewal or expansion is affected

Compliance or risk review triggers

Route to compliance or risk when:

• regulatory obligations apply
• internal policy exceptions exist
• control framework mapping is needed
• risk acceptance may be required
• executive dashboard reporting is needed

Routing should be defined and automated where possible.

9. Which risk tier applies?

Risk tiering determines the review path.

A simple model:

Risk tier should be based on factors such as:

• data sensitivity
• decision impact
• affected stakeholders
• vendor involvement
• autonomy
• human oversight
• customer-facing use
• regulated context
• operational criticality
• explainability need
• model complexity
• monitoring readiness
• prior incidents or issues
• residual risk

How to Classify AI Use Cases by Risk Tier goes deeper into AI risk tiering, but the intake workflow should at least create an initial risk tier.

10. Define controls, evidence, and approval conditions

Before approval, define controls.

Controls may include:

• AI inventory registration
• data owner approval
• privacy review
• DPIA or PIA
• vendor review
• cyber review
• legal review
• human oversight
• access controls
• prompt and output restrictions
• training restrictions
• transparency disclosure
• output review
• monitoring
• issue escalation
• retention and deletion controls
• periodic reassessment
• risk acceptance

Evidence should include:

• intake record
• risk tier
• data review
• privacy review
• cyber review
• vendor review
• legal review
• contract terms
• AI testing evidence
• human oversight plan
• monitoring plan
• approval record
• issue records
• risk acceptance, where needed

Approval conditions should be explicit.

Examples:

• approved for pilot only
• approved for internal use only
• no personal data
• no sensitive data
• no customer-facing output
• human review required
• vendor cannot use data for training
• monitoring required before production
• DPIA mitigation required before launch
• contract terms must be updated
• reassessment required before expansion

Controls and evidence should be linked to the AI use case.

11. What decision should AI intake produce?

AI intake should produce a decision.

Possible outcomes:

The decision should include:

• approver
• date
• rationale
• evidence reviewed
• conditions
• monitoring
• reassessment triggers
• risk acceptance, if any

Do not approve AI use cases only by email or meeting notes.

The approval should be a connected record.

12. Monitor, reassess, and update dashboards

AI intake does not end at approval.

AI use changes.

Vendors change features.
Models change behavior.
Data scope expands.
Users find new uses.
Outputs become more important.
A pilot becomes production.
Monitoring detects issues.
Regulations change.
Incidents happen.

The workflow should define reassessment triggers.

Reassessment should occur when:

• data changes
• sensitive data is added
• vendor terms change
• model provider changes
• use expands
• new user group is added
• output becomes customer-facing
• decision impact increases
• monitoring exception occurs
• incident occurs
• risk tier changes
• control fails
• approval condition is missed
• regulation or policy changes

Monitoring should be risk-based.

Low-risk tools may require periodic owner attestation.

High-risk use cases may require performance, bias, drift, output quality, override, complaint, incident, and control monitoring.

NIST’s AI RMF emphasizes continuous, timely risk management throughout the AI lifecycle, and ISO/IEC 42001 establishes a management-system approach for maintaining and continually improving AI governance.  

AI Intake Workflow Data Model

A connected AI intake workflow should include these records.

This is how intake becomes Connected GRC.

AI Intake Fields

A practical intake record should include these fields.

Core fields

Data fields

Vendor and system fields

Risk fields

AI Intake Routing Rules

A practical routing model should be rule-based.

Routing should reduce duplication.

It should also prevent missed reviews.

AI Intake Approval Workflow

A typical workflow:

1. Business submits use case.
2. Intake screening confirms AI involvement.
3. Data, vendor, system, and impact fields are completed.
4. Prohibited-use screening runs.
5. Initial risk tier is assigned.
6. Required reviews are routed.
7. Reviewers document outcomes.
8. Issues are created for gaps.
9. Controls and evidence requirements are defined.
10. Approval decision is recorded.
11. Conditions are assigned.
12. Monitoring is scheduled.
13. Dashboard updates.
14. Reassessment triggers are activated.

This workflow should be configurable by risk tier.

Low-risk use cases should move quickly.

High-risk use cases should get deeper review.

Example: Low-Risk AI Intake

Use case:

Internal AI assistant summarizes public industry articles for sales enablement.

Facts:

• no personal data
• no sensitive data
• no customer-facing output
• no automated decisioning
• approved enterprise tool
• internal use only

Routing:

• AI governance review
• light cyber confirmation
• no DPIA
• no vendor review if tool already approved and use within scope

Decision:

Approved for internal use with no confidential customer data and no external publication without human review.

Monitoring:

• annual owner attestation
• policy compliance reminders
• issue trigger if data scope changes

This should not take weeks.

A good intake workflow lets low-risk AI move efficiently.

Example: Moderate-Risk AI Intake

Use case:

Customer support agents use AI to draft responses from support ticket context.

Facts:

• customer data involved
• AI output could be customer-facing
• human review required
• vendor tool involved
• prompts and outputs may be retained

Routing:

• privacy review
• vendor review
• cyber review
• legal review
• AI governance review

Controls:

• human approval before customer response
• no sensitive data beyond approved support context
• prompt/output retention documented
• vendor cannot use data for training
• monitoring of customer complaints and override rates
• approval conditions tracked

Decision:

Approved with conditions for limited pilot.

Monitoring:

• pilot review after 30 days
• issue triggers for complaints, policy violations, or monitoring gaps

Example: High-Risk AI Intake

Use case:

AI ranks job applicants for interview priority.

Facts:

• applicant data involved
• employment decision impact
• possible bias and fairness risk
• vendor model involved
• transparency and human oversight required
• legal and HR implications

Routing:

• legal review
• privacy review
• HR review
• AI governance review
• vendor review
• cyber review
• executive escalation

Controls:

• human review
• bias testing
• model documentation
• vendor evidence
• candidate transparency review
• monitoring
• issue escalation
• periodic reassessment

Decision:

Escalated for executive review. Not approved for production until legal, privacy, AI governance, and monitoring requirements are complete.

This is where intake prevents unmanaged exposure.

AI Intake Dashboard

An AI intake dashboard should show:

SmartSuite’s AI Governance page describes dashboards that provide coverage, risks, health and performance indicators, trends, board-ready summaries, and transparent reporting across business units and domains.  

The dashboard should not only show intake volume.

It should show governance status.

Common AI Intake Mistakes

Mistake 1: Treating intake as a one-time form

AI intake should create a lifecycle record.

The use case should be monitored, reassessed, and updated over time.

Mistake 2: Asking too many questions too early

Intake should route the use case.

Detailed reviews should happen only where triggered.

Mistake 3: Ignoring embedded AI in existing tools

Existing vendors can add AI features that change risk.

Those changes should trigger intake or reassessment.

Mistake 4: Treating all AI use cases the same

Risk-based routing is essential.

Low-risk use cases should not be buried in unnecessary review.

High-risk use cases should not move through lightweight approval.

Mistake 5: Not linking intake to the data inventory

AI risk depends heavily on data.

If the AI record does not link to data categories, privacy and cyber review will be weak.

Mistake 6: Not reviewing prompt and output retention

Prompts and outputs can contain personal, sensitive, confidential, or regulated data.

Retention and vendor terms matter.

Mistake 7: Approving without monitoring

AI risk can change after approval.

Monitoring and reassessment should be built into the workflow.

Mistake 8: Letting approval conditions disappear

Conditional approval should create tracked actions, owners, evidence, and due dates.

How to Build the AI Intake Workflow in 30 Days

Days 1–5: Define the intake trigger

Decide when intake is required:

• new AI tool
• new AI feature
• AI vendor
• internal AI model
• AI use of sensitive data
• AI expansion
• AI pilot to production
• material change
• embedded AI in existing tool

Days 6–10: Build the intake form

Capture:

• use case
• owner
• business process
• data
• vendor
• system
• users
• affected stakeholders
• decision impact
• lifecycle stage
• launch date

Days 11–15: Define routing rules

Route to:

• privacy
• cyber
• legal
• vendor risk
• compliance
• AI governance
• executive review

based on risk triggers.

Days 16–20: Define risk tiers and outcomes

Define:

• low
• moderate
• high
• prohibited
• escalation required

and approval outcomes:

• approved
• conditional
• pilot only
• rejected
• suspended
• risk acceptance required

Days 21–25: Define evidence and issue workflows

Create:

• evidence requirements
• issue triggers
• remediation workflow
• approval conditions
• monitoring records
• reassessment triggers

Days 26–30: Launch pilot and dashboard

Pilot with real use cases:

• one low-risk productivity tool
• one vendor AI feature
• one sensitive-data use case
• one customer-facing or employee-facing use case

Build dashboard views for:

• intake queue
• risk tier
• pending reviews
• open issues
• approvals with conditions
• monitoring required
• decisions needed

This gives the organization a practical AI intake foundation quickly.

AI Intake Workflow Checklist

Use this checklist before launching the workflow.

If several answers are no, the workflow is not ready.

A Practical Test for Your AI Intake Process

Pick one AI use case.

Ask whether your current model can show:

• intake request
• business owner
• technical owner
• business purpose
• lifecycle stage
• data categories
• personal or sensitive data involvement
• vendor or model provider
• contract owner
• system integration
• affected stakeholders
• decision impact
• prohibited-use screen
• risk tier
• privacy review
• cyber review
• legal review
• vendor review
• required controls
• evidence
• approval decision
• approval conditions
• monitoring plan
• open issues
• risk acceptance
• reassessment triggers
• dashboard status

If answering those questions requires spreadsheets, AI forms, vendor records, privacy documents, legal notes, cyber tickets, emails, and meetings, AI intake is not connected enough.

That is common.

It is also the opportunity.

Final Thought

AI governance starts at intake.

That is where the organization learns what AI is being used, who owns it, what data it touches, which vendor or model provider is involved, who could be affected, what risk tier applies, what reviews are needed, what controls must operate, what evidence supports approval, and how the use case will be monitored after launch.

An AI intake workflow should not be a bottleneck.

It should be a risk-based front door.

Low-risk use cases move quickly.
Higher-risk use cases get the right review.
Prohibited use is blocked.
Conditional approvals are tracked.
Issues are remediated.
Evidence is retained.
Monitoring is scheduled.
Dashboards show posture.
Executives see decisions.

That is how Connected GRC makes AI governance operational.

Not by asking every team to fill out another form.

By turning AI intake into a connected workflow from request to approval to monitoring.