AI Governance Intake Checklist

AI governance starts before the AI system goes live.

Not after a model is deployed.
Not after employees start using an AI tool.
Not after customer data is processed.
Not after a vendor contract is signed.
Not after a privacy issue is discovered.
Not after cyber asks how the tool connects to production systems.
Not after legal asks whether outputs are being disclosed.
Not after the board asks how many high-risk AI use cases exist.

AI governance starts at intake.

That is the moment when the organization should ask:

• What is this AI use case?

• Who owns it?

• What business process does it support?

• What data will it use?

• Who could be affected?

• Is a vendor or model provider involved?

• Does it involve personal, sensitive, confidential, regulated, or customer data?

• Could it affect decisions about people?

• Does it require human oversight?

• Does it create cyber risk?

• Does it create legal, privacy, regulatory, IP, or third-party risk?

• What controls are needed?

• What evidence will prove approval?

• What monitoring is required after launch?

• What issues, exceptions, or risk acceptances need to be tracked?

An AI intake checklist helps answer those questions before risk becomes harder to control.

Without intake, AI governance becomes reactive.

Teams discover AI use through expense reports, vendor renewals, audit requests, privacy incidents, cyber reviews, or board questions.

That is too late.

A good intake workflow gives the organization a reliable AI inventory, a risk-tiering process, a review path, approval evidence, monitoring requirements, and a way to escalate issues.

In Connected GRC, AI intake is not just a form.

It is the front door to the AI governance operating model.

What is AI governance intake?

AI governance intake is the process of capturing, assessing, routing, approving, monitoring, and documenting AI use cases before they are purchased, built, deployed, expanded, or materially changed.

A strong AI governance intake process should capture:

• AI use case

• business purpose

• owner

• lifecycle stage

• data used

• affected stakeholders

• vendor or model provider

• intended output

• decision impact

• risk tier

• privacy review

• cyber review

• legal review

• compliance review

• vendor review

• required controls

• evidence

• approval decision

• monitoring requirements

• exceptions

• risk acceptance

• reassessment triggers

NIST’s AI RMF Core provides a useful structure because it is organized around Govern, Map, Measure, and Manage. Intake is where organizations begin to map context, identify risks, and route the use case into governance.

A weak intake process asks:

“What AI tool do you want to use?”

A strong 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 it be monitored after launch?”

That is the difference.

Why AI intake matters

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 can enter the organization through:

• employee productivity tools

• SaaS platforms with embedded AI

• customer-facing products

• vendor-provided AI features

• internally developed models

• generative AI pilots

• analytics workflows

• automation tools

• code assistants

• chatbots

• document processing

• fraud detection

• hiring tools

• pricing or underwriting models

• customer support workflows

• marketing content generation

• cyber detection tools

• legal review tools

• AI-enabled third-party services

Each one may create different risks.

Some are low risk.

Some are high risk.

Some are acceptable with monitoring.

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

Some should be rejected or paused.

The European Commission describes the AI Act as risk-based, with categories such as minimal risk, specific transparency risk, high risk, and unacceptable risk. Even outside EU AI Act scope, that risk-based mindset is useful: not every AI use case needs the same review, but every AI use case needs enough review to know what path it belongs on.

AI intake is not only for new AI systems

AI intake should apply when an AI use case is:

• proposed

• piloted

• purchased

• built internally

• enabled in an existing vendor tool

• expanded to new users

• expanded to new data

• moved from internal to customer-facing use

• moved from pilot to production

• connected to production systems

• used in a regulated process

• used for employee or customer decisions

• materially changed

• renewed with a vendor

• retired or replaced

Many AI risks appear after initial approval.

The use case expands.
The vendor changes model behavior.
The data changes.
The audience changes.
The output becomes more important.
The tool moves from “drafting support” to “decision support.”The business starts relying on it.

A good intake workflow includes reassessment triggers.

AI governance should not stop at first approval.

The AI Governance Intake Checklist

Use this checklist before approving, piloting, purchasing, deploying, or expanding an AI use case.

For each question, mark:

• Green: complete and acceptable

• Yellow: incomplete, pending, or acceptable with conditions

• Red: missing, high risk, blocked, or requiring escalation

For any yellow or red item, assign:

• owner

• action

• due date

• required evidence

• review path

• approval condition

• issue or risk acceptance, if needed

Section 1: Use case identity and ownership

1. Is the AI use case clearly described?

The intake record should explain what the AI use case does in plain language.

Avoid vague descriptions such as:

• “AI chatbot”

• “automation tool”

• “AI assistant”

• “analytics model”

• “vendor AI feature”

Better descriptions include:

• “AI chatbot that answers internal HR policy questions for employees.”

• “Generative AI tool used by customer support agents to draft responses.”

• “Machine learning model that predicts invoice payment risk.”

• “AI-enabled vendor tool that summarizes customer call transcripts.”

• “AI system used to rank candidate resumes during recruiting.”

Healthy answer: The use case description explains what the AI does, who uses it, and what process it supports.

Warning sign: The intake record names the tool but not the business use.

2. Is there a named business owner?

Every AI use case needs a business owner.

The business owner should understand:

• why the AI use case is needed

• how it will be used

• who will use it

• what data it will touch

• what decisions it may influence

• what risks it may create

• what evidence is needed for approval

• what monitoring is required after launch

AI governance should not be owned only by the AI governance team, legal, risk, compliance, or IT.

The business owner owns the use case.

Healthy answer: A named business owner is accountable for the AI use case.

Warning sign: The owner is listed as “Product,” “IT,” “Innovation,” or “the business” without a named accountable person.

3. Is there a technical or model owner?

Some AI use cases need a technical owner or model owner.

This may be the person responsible for:

• model configuration

• integration

• data pipeline

• deployment

• monitoring

• model performance

• vendor technical coordination

• change management

• retirement

Not every AI tool has an internal model owner.

For third-party tools, the technical owner may be responsible for implementation and vendor coordination.

Healthy answer: Technical ownership is clear where needed.

Warning sign: No one can explain how the AI system works, integrates, or changes over time.

4. Is the lifecycle stage documented?

The intake should show whether the use case is:

• idea

• proof of concept

• pilot

• pre-production

• production

• expanded use

• under review

• conditionally approved

• suspended

• retired

Lifecycle stage matters because review requirements may differ.

A small pilot may be acceptable with restrictions.

Production use may require full review, controls, evidence, and monitoring.

Healthy answer: Lifecycle stage is documented and drives review requirements.

Warning sign: A “pilot” quietly becomes production without reassessment.

5. Is the intended business outcome documented?

AI use should have a business purpose.

Examples:

• reduce manual document review time

• improve customer support response quality

• detect anomalies

• summarize call transcripts

• support internal policy search

• prioritize vendor risk reviews

• classify support tickets

• improve fraud detection

• assist code development

• improve forecasting

Business outcome matters because it helps evaluate proportionality and risk.

Healthy answer: The business benefit is clear and connected to the process.

Warning sign: AI is being adopted because it is available, not because the business outcome is defined.

Section 2: Users, stakeholders, and decision impact

6. Who will use the AI system?

Document user groups.

Examples:

• employees

• contractors

• customer support agents

• sales teams

• engineers

• compliance analysts

• legal teams

• HR staff

• customers

• vendors

• regulators

• public users

The user group affects training, disclosure, access control, monitoring, and risk.

Healthy answer: User groups are documented.

Warning sign: The tool is approved for one group but used by another.

7. Who could be affected by the AI output?

AI risk depends on who is affected.

Affected groups may include:

• customers

• employees

• job applicants

• patients

• students

• borrowers

• vendors

• consumers

• investors

• regulated users

• vulnerable populations

• the public

If AI affects people, the review should be stronger.

Healthy answer: Affected stakeholders are documented.

Warning sign: The use case is described as internal, but outputs affect customers or employees.

8. Does the AI influence decisions about people?

This is one of the most important intake questions.

Examples:

• hiring

• promotion

• termination

• performance management

• lending

• pricing

• insurance

• healthcare

• education

• access to services

• fraud investigation

• law enforcement support

• customer eligibility

• identity verification

AI that influences decisions about people may require stronger legal, privacy, fairness, human oversight, and monitoring review.

The EU AI Act identifies certain high-risk use cases, including AI tools for employment, worker management, access to essential services, education, law enforcement, migration, and administration of justice.

Healthy answer: Decision impact is documented and routed to the right review path.

Warning sign: The intake says “decision support” but does not explain who is affected or how.

9. Is the AI output advisory, automated, or decisioning?

Clarify the role of the AI output.

Categories may include:

• drafting support

• summarization

• recommendation

• risk scoring

• ranking

• classification

• prediction

• decision support

• automated decision

• autonomous action

• customer-facing response

• system control action

The more the AI output drives action, the stronger the governance requirements should be.

Healthy answer: The output role is documented.

Warning sign: AI is described as “assistive” but users treat it as authoritative.

10. Is human oversight required?

Human oversight may be required when AI supports higher-risk decisions or outputs.

Document:

• who reviews AI output

• what they review

• when they review it

• whether they can override

• how overrides are documented

• what training reviewers receive

• what escalation path exists

Human oversight should be a control, not a slogan.

Healthy answer: Human oversight is defined, assigned, and evidenced where required.

Warning sign: The intake says “human in the loop” but does not define what the human does.

Section 3: AI type, sourcing, and vendor involvement

11. Is the AI internally built, externally purchased, embedded, or open-source?

AI sourcing affects risk.

Common categories:

• internally developed model

• third-party SaaS tool

• embedded AI feature in existing platform

• open-source model

• vendor-provided model

• general-purpose AI model

• fine-tuned model

• custom model

• AI-enabled workflow automation

• agentic AI or autonomous workflow

Healthy answer: AI sourcing is clearly documented.

Warning sign: The business enables an AI feature inside an existing tool without intake review.

12. Is a vendor or model provider involved?

If yes, capture:

• vendor name

• model provider

• contract owner

• business owner

• data processed

• hosting location

• subprocessors

• AI functionality

• support model

• service criticality

• renewal date

• vendor risk tier

Healthy answer: Vendor and model provider records are linked to the AI use case.

Warning sign: AI review happens without vendor risk or contract context.

13. Is the vendor review complete?

AI vendor review may include:

• cyber review

• privacy review

• legal review

• contract review

• AI data-use review

• model provider review

• business continuity review

• evidence review

• issue review

SmartSuite’s AI Governance page describes linking models to risks, controls, laws, frameworks, business processes, and evidence in a connected platform. That same connected model is important when vendors are involved because vendor records, contract terms, data use, risks, and evidence should not be reviewed separately.

Healthy answer: Vendor review is complete or routed based on risk tier.

Warning sign: AI use is approved before vendor terms, evidence, or data-use conditions are reviewed.

14. Are contract terms sufficient for AI use?

AI-related contract terms may need to address:

• data use

• training restrictions

• prompt and output retention

• confidentiality

• IP ownership

• security obligations

• incident notification

• audit rights

• subprocessors

• model changes

• service levels

• termination and data deletion

• regulatory cooperation

• human oversight support

• transparency support

Healthy answer: Contract terms are reviewed for AI-specific risk.

Warning sign: Standard SaaS terms are accepted without reviewing AI data use or model behavior.

15. Are fourth parties or subprocessors involved?

AI tools may rely on additional model providers, cloud services, data processors, or subprocessors.

Document:

• model provider

• hosting provider

• subprocessors

• data transfer path

• subprocessor change notification

• critical dependencies

• fourth-party risk

Healthy answer: Material AI subcontractors or model dependencies are documented.

Warning sign: The vendor uses third-party AI services but the organization has no visibility.

Section 4: Data, privacy, and confidentiality

16. What data will the AI use?

Document data categories.

Examples:

• public data

• internal business data

• confidential information

• customer data

• employee data

• personal data

• sensitive personal data

• financial data

• health data

• authentication data

• source code

• legal documents

• vendor data

• prompts

• outputs

• logs

Healthy answer: Data categories and sensitivity are documented.

Warning sign: Intake says “no sensitive data” without explaining what data will actually be used.

17. Will personal or sensitive data be used?

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

Ask:

• What personal data is used?

• Is sensitive data involved?

• Who are the data subjects?

• What is the processing purpose?

• Is the data minimized?

• Is consent or legal basis relevant?

• Is a DPIA or PIA required?

• Are retention rules defined?

• Are data subject rights affected?

• Are cross-border transfers involved?

Healthy answer: Privacy impact is assessed and linked to the AI record.

Warning sign: Personal data use is identified after approval.

18. Will prompts or outputs be stored, reused, or used for training?

This is a critical AI intake question.

Ask:

• Are prompts stored?

• Are outputs stored?

• Are prompts or outputs used for model training?

• Can the vendor use data to improve its models?

• Are users warned not to enter sensitive data?

• Is data retention defined?

• Can data be deleted?

• Are logs reviewed?

• Are outputs used downstream?

Healthy answer: Prompt and output handling is documented and contractually understood.

Warning sign: The organization does not know whether user inputs can be reused by the vendor.

19. Is data quality or data provenance important?

Some AI use cases depend heavily on data quality.

Ask:

• Where does the data come from?

• Who owns the data?

• Is the data current?

• Is the data representative?

• Is the data complete?

• Is the data biased or skewed?

• Is the data approved for this use?

• Is training, tuning, or retrieval data controlled?

Data quality is especially important for AI use cases that generate recommendations, classifications, rankings, or decisions.

Healthy answer: Data source, owner, quality, and limitations are documented.

Warning sign: AI outputs are trusted without understanding the data behind them.

20. Are confidentiality and IP risks reviewed?

AI use can create confidentiality and intellectual property risks.

Ask:

• Will confidential company information be entered?

• Will source code be entered?

• Will customer information be entered?

• Will legal documents be entered?

• Who owns outputs?

• Could outputs infringe third-party rights?

• Are training data or generated content risks relevant?

• Are copyright, patent, trade secret, or licensing issues relevant?

Healthy answer: Confidentiality and IP considerations are reviewed where relevant.

Warning sign: Teams use AI tools with confidential information without legal or contract review.

Section 5: Risk classification and regulatory relevance

21. Has the AI use case been risk-tiered?

Risk tiering helps route review.

Possible tiers:

• low risk

• moderate risk

• high risk

• prohibited / blocked

• regulatory review required

• executive escalation required

Risk tier should consider:

• data sensitivity

• decision impact

• affected stakeholders

• customer impact

• vendor involvement

• cyber exposure

• regulatory relevance

• operational criticality

• model autonomy

• output reliance

• human oversight

• potential harm

Healthy answer: Risk tier is assigned using documented criteria.

Warning sign: All AI use cases are treated the same.

22. Has prohibited or unacceptable use been screened?

Some AI uses may be prohibited by policy or law.

Examples may include:

• social scoring

• harmful manipulation or deception

• exploitation of vulnerabilities

• certain biometric or emotion recognition uses

• prohibited surveillance use

• unacceptable employee or customer profiling

• uses prohibited by internal policy

The European Commission lists unacceptable risk as a category for AI systems considered a clear threat to people’s safety, livelihoods, or rights, and identifies examples such as social scoring.

Healthy answer: Prohibited-use screening is documented.

Warning sign: High-impact AI use moves forward before legal or policy screening.

23. Could the AI use case be high risk?

High-risk screening should ask whether the AI system affects:

• health or safety

• critical infrastructure

• education

• employment

• worker management

• access to essential services

• credit or financial eligibility

• law enforcement

• migration or border management

• administration of justice

• democratic processes

• regulated decisions

The European Commission identifies high-risk AI use cases and states that high-risk systems are subject to strict obligations such as risk mitigation, high-quality datasets, clear information, human oversight, robustness, cybersecurity, and accuracy.

Healthy answer: High-risk screening is completed and routed to legal, compliance, privacy, cyber, and executive review where needed.

Warning sign: Use cases involving people-impacting decisions are treated as normal technology requests.

24. Are transparency or disclosure obligations relevant?

Some AI use cases require users to know they are interacting with AI or that content is AI-generated.

Ask:

• Is the AI customer-facing?

• Is it a chatbot or virtual assistant?

• Does it generate content?

• Does it create synthetic media?

• Does it produce recommendations users may rely on?

• Are disclosures required by law, policy, contract, or customer commitment?

• Where will disclosures appear?

• What evidence proves disclosure is active?

The Commission describes “specific transparency risk” as including systems like chatbots that must clearly inform users they are interacting with a machine, and certain AI-generated content that must be labeled.

Healthy answer: Disclosure requirements are identified, implemented, and evidenced where relevant.

Warning sign: Users cannot tell when AI is involved.

25. Are applicable laws, frameworks, or standards identified?

AI governance may need to consider:

• internal AI policy

• EU AI Act

• privacy laws

• sector regulation

• customer commitments

• contractual obligations

• NIST AI RMF

• ISO/IEC 42001

• CRI AI RMF, where relevant

• cyber frameworks

• model risk management standards

• records retention requirements

ISO/IEC 42001 provides a management-system approach for AI governance, including establishing, implementing, maintaining, and continually improving an AI management system.

Healthy answer: Applicable obligations and frameworks are mapped to the AI use case.

Warning sign: AI review is disconnected from legal, compliance, or policy obligations.

Section 6: Cyber, security, and technical risk

26. Does the AI system connect to production systems or sensitive environments?

Document system access.

Examples:

• production application

• customer database

• identity system

• API

• internal network

• cloud environment

• data warehouse

• code repository

• ticketing system

• security tools

• financial reporting systems

Healthy answer: System access and integration points are documented.

Warning sign: AI is integrated into production systems without cyber or change review.

27. Has cyber review been completed?

Cyber review may include:

• authentication and access controls

• encryption

• logging

• API security

• prompt injection risk

• data leakage risk

• model abuse risk

• vendor security posture

• vulnerability management

• incident response

• monitoring

• cloud security

• secure development practices

• change management

Healthy answer: Cyber review is complete or routed based on risk tier.

Warning sign: AI use is approved before security implications are understood.

28. Are logging and audit trails available?

AI governance needs traceability.

Ask:

• Are prompts logged?

• Are outputs logged?

• Are approvals logged?

• Are human overrides logged?

• Are model changes logged?

• Are vendor changes logged?

• Are monitoring exceptions logged?

• Are incidents logged?

• Are logs retained appropriately?

Healthy answer: Required logs and audit trails are defined.

Warning sign: AI output affects business activity, but no one can reconstruct what happened.

29. Are security and abuse scenarios considered?

AI-specific abuse scenarios may include:

• prompt injection

• data exfiltration

• insecure plugin or agent behavior

• model manipulation

• unauthorized use

• sensitive data leakage

• malicious outputs

• hallucinated instructions

• phishing or impersonation support

• poisoning or tampering, where relevant

• overreliance on outputs

Healthy answer: Security misuse scenarios are considered for relevant use cases.

Warning sign: AI security review treats the tool like ordinary SaaS without AI-specific risks.

30. Is incident response defined for this AI use case?

AI incidents may include:

• harmful output

• data leakage

• biased or discriminatory output

• privacy issue

• unauthorized use

• vendor AI incident

• model performance failure

• security abuse

• customer harm

• regulatory concern

Define:

• incident trigger

• owner

• escalation path

• legal review

• privacy review

• cyber review

• customer notification path, where relevant

• remediation workflow

• evidence retention

Healthy answer: AI incident triggers and response paths are defined.

Warning sign: The organization has no process for AI-caused or AI-enabled incidents.

Section 7: Controls, evidence, and approval

31. Are required controls defined before approval?

Controls may include:

• AI inventory registration

• risk tiering

• privacy review

• cyber review

• vendor review

• legal review

• human oversight

• transparency disclosure

• access control

• data-use restriction

• monitoring

• issue escalation

• periodic reassessment

• change review

• model validation

• output review

• incident response

Healthy answer: Required controls are defined based on risk tier and use case.

Warning sign: Approval is granted without specifying controls.

32. Is approval evidence required?

Approval evidence may include:

• intake form

• risk assessment

• data review

• privacy review

• cyber review

• vendor review

• legal review

• human oversight plan

• monitoring plan

• contract review

• policy attestation

• training record

• issue disposition

• approval record

Healthy answer: Evidence required for approval is defined.

Warning sign: Approval happens in chat or email with no evidence trail.

33. Are approvers identified?

Approvers may include:

• business owner

• AI governance owner

• legal

• privacy

• cyber

• compliance

• data owner

• vendor risk

• risk owner

• executive sponsor

• operating committee

Higher-risk use cases may require more reviewers.

Low-risk use cases may follow a lighter path.

Healthy answer: Approval path is risk-based and documented.

Warning sign: Every use case follows the same approval route, regardless of risk.

34. Are approval outcomes standardized?

Possible outcomes:

• approved

• approved with conditions

• rejected

• more information needed

• pilot only

• internal use only

• no sensitive data

• no customer-facing use

• legal review required

• privacy review required

• cyber review required

• executive escalation required

• risk acceptance required

• suspended

• retired

Healthy answer: Approval outcomes are standardized and traceable.

Warning sign: Approval language is inconsistent and difficult to enforce.

35. Are conditional approvals tracked?

AI use cases are often approved with conditions.

Examples:

• pilot only

• limited users

• no personal data

• no customer-facing output

• human review required

• monitoring must be implemented before production

• vendor terms must be updated

• security review must be completed

• reassessment required before expansion

Conditions should become tracked actions.

Healthy answer: Approval conditions have owners, due dates, and evidence requirements.

Warning sign: Conditions are written in approval notes but not monitored.

Section 8: Monitoring and lifecycle management

36. Is post-approval monitoring required?

AI risk changes after approval.

Monitoring may include:

• performance

• accuracy

• drift

• bias or fairness indicators

• hallucination or error rates

• user complaints

• human override rates

• data quality

• security alerts

• privacy incidents

• vendor changes

• scope expansion

• output quality

• policy violations

NIST’s AI RMF emphasizes continuous and timely risk management throughout the AI system lifecycle.

Healthy answer: Monitoring is defined for higher-risk use cases.

Warning sign: The organization approves AI but does not monitor it after launch.

37. Are monitoring metrics and thresholds defined?

Monitoring should include thresholds.

Examples:

• error rate above threshold

• drift detected

• bias metric outside threshold

• human override rate above threshold

• complaints above threshold

• monitoring not performed by due date

• vendor model change notice received

• unauthorized data use detected

• output review failure

• issue not remediated by deadline

Healthy answer: Metrics, thresholds, owners, cadence, and escalation rules are defined.

Warning sign: Monitoring is described generally but not operationalized.

38. Are reassessment triggers defined?

Reassessment should occur when:

• use case expands

• new data is added

• sensitive data is added

• new users are added

• customer-facing use begins

• vendor changes model or terms

• model performance changes

• monitoring exception occurs

• incident occurs

• regulation changes

• business process changes

• risk tier changes

• control fails

Healthy answer: Reassessment triggers are built into the workflow.

Warning sign: AI systems are approved once and never reviewed again.

39. Are issues and remediation linked?

AI issues should be tracked.

Examples:

• missing privacy review

• incomplete cyber review

• vendor terms unresolved

• monitoring not implemented

• human oversight not evidenced

• transparency disclosure missing

• data-use restriction violated

• AI output error

• bias concern

• security issue

• policy violation

• unapproved use

Each issue should include:

• owner

• severity

• root cause

• remediation plan

• due date

• evidence

• validation

• dashboard status

Healthy answer: Issues are linked to the AI use case and remediation workflow.

Warning sign: AI concerns are discussed in meetings but not tracked as issues.

40. Is retirement or suspension defined?

Some AI use cases should be suspended or retired.

Reasons may include:

• risk exceeds appetite

• legal concern

• privacy concern

• cyber issue

• vendor issue

• monitoring failure

• performance degradation

• business process change

• duplicate tool

• contract termination

• policy violation

• regulatory change

Retirement should include:

• owner

• decision

• data disposition

• vendor offboarding

• user communication

• evidence retention

• dashboard update

Healthy answer: Suspension and retirement paths exist.

Warning sign: AI systems remain active after approval even when use or risk changes.

Summary AI Governance Intake Checklist

Use this table before approving, piloting, purchasing, deploying, or expanding an AI use case.