AI 扩展计划 / Playbooks

AI Shadow AI / Citizen Development Governance Playbook

text

751 行AI_SHADOW_AI_CITIZEN_DEVELOPMENT_GOVERNANCE_PLAYBOOK.md

AI Shadow AI / Citizen Development Governance Architecture Playbook

定位: 面向高级 AI PM / AI BA / Enterprise Architect / Solution Architect / AI Governance Lead / Security Architect / Risk Partner / Financial Retail AI Owner 的 shadow AI 与 citizen development 治理架构手册。核心问题: 组织内的员工、业务团队、分行、运营小组和开发者正在用未批准 AI 工具、自建 Bot、浏览器插件、低代码 Agent 和个人账号解决真实痛点。治理目标不是压制有效需求, 而是把 uncontrolled AI use 转成可发现、可分级、可引导、可控制、可审计和可迁移的平台化能力。重要说明: 本文是学习、作品集和治理设计材料, 不构成法律意见、合规结论、模型验证意见、审计意见或监管解释。正式项目必须由 Legal、Compliance、Risk、Model Risk、Privacy、Security、Internal Audit、Business Owner、Technology Owner、Data Owner 和管理层确认。

1. Executive Framing

1.1 一句话定义

Shadow AI governance architecture =
discover uncontrolled AI use
-> classify workflow, data, tool, vendor and customer impact
-> risk-tier the usage
-> route useful demand to approved pathways
-> enforce data, prompt, tool and records controls
-> monitor, train, handle exceptions and migrate to golden paths.

Shadow AI is not the same as adoption.

Topic	Generic AI adoption	Shadow AI governance
Starting point	sanctioned tool or platform is launched	unsanctioned use already exists
Main question	how do we drive effective usage	what is being used, with what data, by whom, for which workflow
Product lens	training, adoption, support, value realization	unmet workflow need, approved alternatives, migration path
Risk lens	misuse of approved capability	data leakage, unapproved vendor, records gap, conduct, third-party, model and customer harm
Architecture lens	platform rollout and integration	discovery telemetry, DLP, policy, gates, catalog, exception and migration
Success signal	target users adopt approved tool	high-risk shadow use declines and useful demand moves to approved paths

1.2 Why shadow AI exists

Shadow AI is usually a rational local workaround:

Official intake is slow.
Approved tools do not cover the workflow.
Users do not know what is allowed.
The sanctioned tool lacks the needed data, templates or integrations.
Citizen developers can solve a team pain point faster than the central platform.
Managers reward speed but do not give safe tooling.
Governance messages say "no" more clearly than "use this path instead."

The governance response should start with this question:

What job is this shadow AI usage doing that the formal platform failed to support?

1.3 Financial services nuance

In financial retail, shadow AI creates risk across several control domains:

Risk domain	Shadow AI example	Why it matters
Data leakage	employee pastes customer complaint, transaction history or credit data into public AI	PII, bank secrecy, privacy and contractual exposure
Conduct	AI-generated customer email promises a fee waiver or gives product advice	customer harm, complaints, UDAAP-style risk, brand damage
Records	AI output enters case notes without prompt/output retention	incomplete books and records, audit gap
Third-party	free plugin processes customer or internal documents	vendor due diligence, data terms, resilience and exit risk
Model risk	AI draft influences credit, AML, fraud or wealth recommendation	unvalidated decision support
Audit	no inventory, owner, approval, KRI, exception or evidence	inability to prove governance operated
Security	browser extension, copied code, secrets in prompt, agent tool misuse	credential leakage and software supply-chain exposure
Customer harm	incorrect dispute rights, fees, loan conditions or escalation path	direct customer impact

1.4 Governance design principles

Principle	Practical meaning
Treat shadow AI as signal, not only misconduct	every case is both demand research and risk signal
Provide sanctioned pathways before enforcement escalates	users need a safer route that solves the same job
Risk-tier everything	a public brainstorming prompt and a loan decision narrative are not the same
Control data movement	prompt, file upload, retrieval, output and retention boundaries matter
Keep gates lightweight where risk is low	over-control creates more shadow behavior
Move reusable demand into platform golden paths	repeated patterns become catalog services and templates
Monitor migration, not just violations	success is lower residual risk plus higher approved adoption
Preserve evidence	decisions, exceptions, training, policy blocks and migration closure must be auditable

2. Source Anchors

These anchors are used as governance language and architecture design references. They are not a complete legal or control inventory.

Anchor	Official link	Playbook usage
NIST AI RMF	https://www.nist.gov/itl/ai-risk-management-framework	Use Govern / Map / Measure / Manage to structure discovery, risk tiering, measurement and management action
ISO/IEC 42001	https://www.iso.org/standard/42001	Use AI management system thinking for roles, lifecycle controls, performance evaluation, improvement and management review
FFIEC Management booklet	https://ithandbook.ffiec.gov/it-booklets/management.aspx	Use IT governance, risk management, audit, third-party and board/management oversight expectations in financial institutions
OWASP Top 10 for LLM Applications	https://genai.owasp.org/llm-top-10/	Use LLM-specific risk categories such as prompt injection, sensitive information disclosure, excessive agency and supply chain
CISA Secure by Design	https://www.cisa.gov/securebydesign	Design sanctioned AI pathways that reduce unsafe burden on employees and make secure use the default

3. Shadow AI Governance Lifecycle

3.1 Lifecycle view

Signal
-> discovery record
-> workflow interview
-> usage taxonomy
-> data and tool classification
-> risk tier
-> decision route
-> approved pathway / restriction / block / exception
-> evidence and monitoring
-> migration or closure
-> platform roadmap feedback

3.2 Decision states

State	Meaning	Example
Approved	already uses sanctioned tool within policy	employee uses approved internal copilot for non-sensitive summary
Approve with guardrails	acceptable if extra controls are added	internal team uses approved model with prompt logging and DLP
Migrate	useful but currently uses unsafe path	move public AI customer summary to internal copilot
Restrict	partially allowed, but certain data/actions blocked	no customer PII, no attachments, no customer-facing output
Block	prohibited or unacceptably risky	upload full loan file to public AI
Investigate	unclear ownership, data or tool behavior	unknown browser extension with AI document access
Exception	time-limited deviation with compensating controls	30-day low-risk pilot before catalog service is ready
No-impact rationale	signal reviewed and not material	public AI used for generic learning with no organization data

4. Discovery Methods

4.1 Discovery should be multi-signal

No single source finds shadow AI. Procurement finds paid SaaS, but misses free tools. DLP finds data movement, but misses copy-paste into personal devices. Surveys reveal demand, but underreport sensitive behavior.

Method	Finds	Blind spot	Owner
Network egress logs	calls to known AI domains and APIs	personal device, encrypted unknown domains	Security / Network
Browser extension inventory	AI plugins, summarizers, document assistants	unmanaged browsers	Endpoint / Security
SaaS expense and procurement	paid AI tools and subscriptions	free tiers, individual cards	Finance / Procurement
CASB / SaaS security logs	cloud app usage and file sharing	local apps and unmanaged accounts	Security
DLP events	sensitive data pasted, uploaded or sent	paraphrased data, screenshots	Data Protection
Endpoint telemetry	local AI apps, code assistants, file access	privacy and collection limits	Endpoint Security
Code scanning	AI-generated code patterns, secret exposure	non-code business tools	Engineering
Surveys	perceived demand and unclear policy areas	social desirability bias	AI Governance / HR
Workflow interviews	real jobs, pain points, informal tools	sample coverage	BA / PM
Process mining	unusual manual steps and copy-paste behavior	off-system work	Process Excellence
Vendor review	embedded AI in existing SaaS	feature changes after approval	TPRM / Vendor Owner
Incident reports	harm, leakage, misuse	late signal	Risk / Security

4.2 Discovery interview script

Ask non-punitive questions first:

Question	Why it matters
What task were you trying to complete faster or better?	identifies unmet workflow need
Which data did you put into the tool?	classifies data risk
Did the output go into a customer, regulatory or operational record?	identifies records and customer impact
Did the tool call any system or update any file?	identifies excessive agency
Was the tool a personal account, vendor feature or internal prototype?	identifies third-party and inventory state
Would you use an approved version if it solved the same workflow?	tests migration feasibility
What made the approved option insufficient?	creates platform roadmap signal

5. Usage Taxonomy

5.1 Usage categories

Category	Examples	Default posture
Public learning	explain public concepts, summarize public articles	allow with literacy
Personal productivity	agenda, generic writing, translation with no company data	allow in approved tools
Internal knowledge work	summarize internal docs, draft requirements, create diagrams	approved tool with data boundary
Customer data handling	summarize complaints, applications, transactions	approved platform, DLP, retention
Customer-facing content	emails, chatbot responses, fee explanation	formal gate, policy citation, HITL
Regulated decision support	lending, AML, fraud, wealth, collections	high-tier review and evidence
System action	update CRM, send email, create ticket, change limit	tool gateway and approval
Software engineering	code assistant, code agent, test generation	secure SDLC and secret controls
Analytics	spreadsheet analysis, SQL generation, dashboard narrative	data classification and reproducibility
Vendor-embedded AI	CRM AI, ticketing AI, office suite AI	TPRM, data terms, admin controls
Citizen-built workflow	low-code Bot, no-code agent, spreadsheet macro	citizen developer guardrails
Prohibited behavior	secrets, credentials, full customer files in public AI, autonomous regulated decision	block and remediate

5.2 Tool taxonomy

Tool type	Governance focus
Public chat	prompt/data policy, DLP, training, blocking sensitive data
Enterprise chat	identity, retention, data boundary, approved usage
Browser extension	page/file access, data exfiltration, extension approval
Low-code builder	connector permissions, owner, lifecycle, testing
Agent builder	tool authority, excessive agency, HITL, kill switch
Code assistant	source code, secret handling, license and generated code review
Embedded SaaS AI	vendor terms, tenant controls, data processing, logging
Local model	endpoint risk, data retention, model provenance, supportability
API direct use	model gateway, key management, logging, quota and allowlist

5.3 Data taxonomy for prompts and uploads

Data class	Examples	Default handling
Public	website, public policy, public product brochure	allowed
Internal low sensitivity	meeting agenda, generic internal process	approved enterprise tool
Confidential internal	strategy, pricing, internal controls	approved tool with retention and access limits
Customer PII	name, account, address, transaction, complaint	approved platform only, DLP and retention
Credit / eligibility	credit score, income, underwriting notes	high-tier gate and records
Payment / card	PAN, merchant data, dispute evidence	PCI/security review and masking
Authentication / secrets	password, token, private key, session cookie	prohibited in prompts
Regulatory / audit	SAR narrative, audit finding, exam response	controlled environment and evidence
Employee sensitive	HR, medical, performance, investigations	privacy review and restricted access

6. Risk Tiering

6.1 Tier model

Tier	Description	Examples	Default route
Tier 0	public learning or generic ideation with no organization data	explain tokenization, brainstorm meeting names	allow with literacy
Tier 1	low-risk internal productivity with non-sensitive data	draft internal agenda, summarize generic policy	approved catalog, light logging
Tier 2	sensitive internal or customer-adjacent support, no final decision	summarize complaint for agent review, draft internal KYC checklist	approved platform, DLP, retention, QA sample
Tier 3	customer-facing, regulated, financial, legal, credit, AML, fraud or wealth impact	customer response, lending narrative, AML alert summary	formal review gate, HITL, audit evidence
Tier 4	prohibited or unacceptable risk	public upload of full customer files, autonomous credit denial, secrets in prompt	block, investigate, remediate

6.2 Scoring dimensions

Dimension	Low	Medium	High
Data sensitivity	public or generic	confidential internal	customer PII, credit, payment, secrets
Customer impact	none	indirect employee support	direct customer content or decision support
Automation	learning or draft	recommendation	system action or autonomous decision
Vendor status	approved enterprise route	existing vendor feature under review	unapproved public tool
Records	not a record	internal work product	customer/regulatory/business record
Tool authority	no connector	read-only connector	write, send, approve, change limits
Output reliance	human edits heavily	user accepts with review	output drives decision or commitment
Scale	single low-risk use	team workflow	broad customer or enterprise use

6.3 Risk tier decision rules

Use the highest applicable rule:

Any secrets, credentials or private keys in a prompt: Tier 4.
Full customer files in public or unapproved AI: Tier 4.
Autonomous decision affecting credit, account access, pricing, fraud action, AML filing or customer rights: Tier 4 unless explicitly approved through formal governance.
Customer-facing regulated content: at least Tier 3.
Credit, AML, fraud, complaint, wealth, collections or payment dispute support: at least Tier 3.
Customer PII in an approved internal tool with no direct customer output: at least Tier 2.
Confidential internal strategy or controls: at least Tier 2.
Public learning with no organization data: Tier 0.

6.4 Decision matrix

Tier	Review speed	Controls	Evidence
Tier 0	self-service	literacy, allowed-use guidance	training acknowledgment where required
Tier 1	same day to 3 days	approved catalog, basic logging	catalog record
Tier 2	3 to 10 business days	DLP, access control, retention, QA sampling	intake, data review, approval
Tier 3	formal gate	HITL, eval, policy, audit, vendor/security/model screen	evidence pack and release memo
Tier 4	immediate containment	block, investigate, incident or remediation	investigation record and closure

7. Approved Pathway Design

7.1 Why approved pathways matter

Governance fails when it says only what is forbidden. Users need visible, fast and useful routes:

I have a workflow.
I know which AI path is allowed.
I can request access quickly.
The path supports my data and output type.
The controls happen by default.
I do not need to invent governance myself.

7.2 Pathway catalog

Pathway	Suitable usage	Default controls
Approved enterprise chat	Tier 0/Tier 1 learning and productivity	identity, retention policy, data guidance
Internal employee copilot	internal knowledge and document work	RAG, source permissions, prompt logging, feedback
Customer-data safe workspace	Tier 2 summaries and drafts	DLP, masking, retention, access control
Customer-facing RAG golden path	policy/FAQ responses	citation, no-answer behavior, human handoff, eval
Agent workflow golden path	tools and workflow automation	tool gateway, RBAC/ABAC, HITL, audit, kill switch
Citizen developer sandbox	low-code apps and automations	approved connectors, templates, review gates
Secure code assistant	development productivity	repo policy, secret scanning, license and code review
Vendor AI feature route	embedded SaaS AI	TPRM, admin controls, data terms, usage monitoring
Exception route	time-bound deviation	residual risk owner, expiry, compensating controls

7.3 Pathway selection

User need	Recommended path
"I need to summarize public research"	enterprise chat or public learning guidance
"I need to summarize internal policy"	internal employee copilot
"I need to summarize customer complaint notes"	customer-data safe workspace
"I need to answer customers from policy"	customer-facing RAG golden path
"I need AI to update case status"	agent workflow golden path with tool gateway
"I need a small team automation"	citizen developer sandbox
"I need a SaaS vendor AI feature"	vendor AI feature route
"The approved path cannot support my deadline"	exception route with expiry

7.4 Golden path contract

Each approved pathway must publish:

Field	Meaning
path_id	stable path identifier
owner	product, tech, risk and support owner
allowed use	what the pathway supports
prohibited use	what it must never be used for
data classes	allowed, restricted and blocked data
default controls	DLP, logging, retention, HITL, eval, vendor checks
intake SLA	expected time for access or review
evidence output	logs, approvals, dashboards, training, exceptions
support route	documentation, office hours, incident path
migration promise	how shadow use moves into this path

8. Intake and Review Gates

8.1 Lightweight intake form

Use this for Tier 1/Tier 2 candidate tools and citizen-built workflows:

request_id: SHAI-INTAKE-2026-0008
requester: retail_operations_manager
business_unit: Retail Operations
workflow_name: complaint_summary_and_routing
current_tool_or_shadow_use: public_ai_chat_copy_paste
business_need: reduce first-pass complaint triage time and improve routing consistency
users: 40 complaint operations analysts
data_classes: [customer_PII, complaint_text, account_reference]
output_destination: case_management_system
customer_visible: false
decision_support: true
system_action: draft_routing_recommendation_only
vendor_or_tool: not_approved_public_tool
requested_pathway: customer_data_safe_workspace
expected_volume: 300 cases per day
target_date: 2026-07-31

8.2 Gate model

Gate	Trigger	Decision
G0 Discovery Triage	new signal or intake	no-impact, investigate, tier, contain
G1 Data Gate	customer, confidential, regulated or secret data	allowed data boundary and DLP controls
G2 Tool/Vendor Gate	unapproved tool, extension, SaaS feature or API	approve, restrict, block, TPRM review
G3 Workflow Gate	output enters record, customer channel or system action	workflow control and records decision
G4 Risk Tier Gate	Tier 2 or above	pathway, controls, owner and evidence
G5 Release/Migration Gate	shadow use moves to sanctioned path	pilot, limited release, full migration
G6 Exception Gate	standard path not ready	time-limited waiver or no-go
G7 Quarterly Review	active inventory	continue, improve, retire, escalate

9. Data, Prompt and DLP Policy

9.1 Policy statements

Policy area	Rule
Public AI	no customer PII, confidential internal data, credentials, source code secrets, regulatory records or full internal documents
Approved enterprise AI	allowed data depends on tool configuration, retention, access and pathway
Customer data	only approved pathways with DLP, retention, logging and access control
Credit/AML/fraud/wealth	only high-tier governed pathways with human oversight and evidence
Prompt retention	prompts and outputs that influence records or decisions must follow records policy
Output use	AI output must not be represented as verified fact unless the workflow includes verification
External sharing	AI-generated customer communication follows the same review as human-drafted content plus AI-specific controls
Training data	vendor training and model improvement settings must follow approved data terms

9.2 DLP rules by pattern

Pattern	DLP action
customer identifier in public AI domain	block and notify user with approved pathway link
credit score or income in unapproved AI	block, alert data protection, create triage record
secret or API key in prompt	block, revoke/rotate secret, security incident path
internal confidential doc upload to unapproved tool	block or quarantine, investigate
regulated record copied to personal AI	block and route to records/risk review
high-volume copy-paste to AI domain	alert for shadow workflow investigation
approved tool but wrong data class	warn, redact or require higher pathway

10. Citizen Developer Guardrails

10.1 Citizen developer scope

Citizen development is allowed when it is bounded:

Allowed by default	Needs review	Usually prohibited
personal productivity with no sensitive data	team workflow touching internal data	customer-impacting autonomous decision
low-code form assistant using approved connector	customer-data summary	public AI with customer files
internal draft generator with approved template	workflow that writes into system of record	agent with unrestricted write tools
non-production prototype using synthetic data	vendor plugin with document access	hidden Bot used for regulated process

10.2 Guardrail catalog

Guardrail	Control
Identity	builders and users must use enterprise identity
Connector allowlist	only approved data connectors by tier
Data classification	app declares allowed data classes
Environment separation	prototype, pilot and production are separate
Owner requirement	every app has business and technical owner
Review threshold	customer data, system action or external send triggers gate
Logging	prompt, input class, output, connector call and user action are logged as appropriate
HITL	high-risk output/action requires review
Change control	material prompt, connector or workflow change triggers review
Retention	record-generating apps follow retention rules
Kill switch	platform can disable app, connector, model route or external send
Recertification	active citizen tools are reviewed on a cadence

10.3 Citizen developer checklist

I can name the workflow and business owner.
I know which data classes are allowed.
I am using approved AI tools and connectors.
The app does not make final regulated decisions.
Any customer-facing output is reviewed through the required path.
The app logs enough information for support and audit.
Users understand when to verify, escalate or stop.
The app has a retirement or migration path if it becomes business-critical.

11. Platform Migration Patterns

11.1 Migration playbook

Discover shadow use
-> understand job-to-be-done
-> contain high-risk data movement
-> choose target sanctioned pathway
-> create migration backlog item
-> pilot approved path with same users
-> compare workflow fit and risk reduction
-> retire unsafe tool
-> monitor recurrence

11.2 Common migration patterns

Shadow pattern	Migration target	Design note
public chat for customer summaries	customer-data safe workspace	add DLP, retention, source tagging
team-built FAQ Bot	customer-facing RAG golden path	add source registry, citation, no-answer and handoff
spreadsheet AI for underwriting notes	governed decision-support copilot	keep final decision human and auditable
browser summarizer for CRM pages	embedded internal copilot	use enterprise identity and permission filters
no-code agent updates tickets	agent workflow golden path	tool gateway, approval and idempotency
developer uses external code agent	secure code assistant	repo policy, secret scanning and review
vendor AI feature enabled by team admin	vendor AI route	TPRM, admin config, data terms and monitoring

11.3 Migration success metrics

Metric	Good signal
high-risk shadow usage	declining by team and workflow
approved pathway adoption	rising among previous shadow users
time-to-approved-path	decreasing without weakening gates
DLP blocks	fewer repeat violations after training and migration
user satisfaction	approved path solves original job
risk exceptions	bounded, expiring and closing
platform backlog conversion	repeated shadow demand becomes reusable service

12. Monitoring, Dashboards and KRIs

12.1 Dashboard tiles

Tile	Decision supported
Shadow AI signals by source	where discovery is working
Signals by business unit and workflow	where unmet demand is concentrated
Risk tier distribution	how much exposure is high-risk
Data classes detected	which sensitive data types are moving
Decision state aging	which items are stuck
Migration funnel	signals -> migrated -> adopted -> retired unsafe path
DLP blocks and repeats	which teams need training or better pathways
Unapproved vendor usage	third-party exposure
Citizen app inventory	owner, tier, active users and recertification
Exceptions and expiry	residual risk and overdue closure
Customer harm indicators	complaints, wrong commitments, escalation failures
Platform demand backlog	which golden paths need investment

12.2 KRIs

KRI	Threshold example	Response
Tier 3/Tier 4 shadow signals	any sustained increase	management review and containment
customer PII to unapproved AI	zero tolerance for confirmed event	block, investigate, train, remediate
repeat DLP event by same team	more than 2 in 30 days	manager escalation and pathway review
unowned citizen apps	any production app without owner	disable or assign owner
expired exceptions	zero active expired exceptions	escalate and disable if unresolved
migration overdue	over target date by 15 days	review blocker and alternative path
unapproved browser AI extensions	above approved baseline	endpoint action and communication
policy-block bypass attempts	recurring attempts	security investigation
customer-facing AI without approval	zero tolerance	immediate containment

13. RACI

Activity	Business Owner	AI Governance	AI PM	BA	Architect	Security	Privacy/Data	Risk/Compliance	TPRM	Internal Audit
Policy and risk appetite	A	R	C	C	C	C	C	A/R	C	I
Discovery program	C	A/R	C	R	C	R	C	C	C	I
Workflow triage	A	C	R	R	C	C	C	C	I	I
Risk tiering	A	R	C	C	C	C	C	A/R	C	I
Data classification	C	C	C	R	C	C	A/R	C	I	I
Tool/vendor review	C	C	C	I	C	C	C	C	A/R	I
Approved pathway design	C	C	A/R	R	R	C	C	C	C	I
Citizen guardrails	C	A/R	R	R	R	C	C	C	C	I
Exception approval	A	R	C	C	C	C	C	A/R	C	I
Monitoring dashboard	A	R	R	C	C	R	C	C	C	I
Audit evidence review	C	R	C	C	C	C	C	C	C	A/R

RACI notes:

Business Owner accepts workflow value and residual business risk.
AI Governance owns policy, tiering consistency and management reporting.
Architecture owns control-plane integration and pathway design.
Security owns technical containment and detection.
Internal Audit independently tests whether the process operates as described.

14. Financial Retail Examples

14.1 Retail banking relationship manager

Item	Detail
Shadow use	personal AI summarizes customer meeting notes and drafts follow-up email
Risks	PII leakage, customer commitment, records gap, unapproved vendor
Tier	Tier 3 when customer data or customer-facing output is included
Response	block customer data in personal AI, migrate to internal copilot, require approved email template and manager review for sensitive commitments
Evidence	DLP event, intake, migration plan, training completion, approved copilot logs

14.2 AML analyst narrative drafting

Item	Detail
Shadow use	analyst pastes alert details into public AI to draft narrative
Risks	suspicious activity confidentiality, model-risk misuse, records and audit gaps
Tier	Tier 3 or Tier 4 depending on data and regulatory record handling
Response	immediate restriction, approved AML copilot with source controls, final investigator attestation
Evidence	alert-level trace, policy, review queue, QA sample, model-risk screen

14.3 Branch policy FAQ Bot

Item	Detail
Shadow use	branch manager creates team Bot from outdated product PDFs
Risks	stale policy, customer misstatement, permission and source owner gap
Tier	Tier 2 internal, Tier 3 if used for customer answers
Response	migrate to RAG golden path with source registry, effective date, citation and no-answer behavior
Evidence	source card, eval report, user training, retirement of old Bot

15. Templates

15.1 Shadow AI signal record

signal_id: SHAI-2026-0061
source: DLP_EVENT
detected_at: 2026-06-30T14:20:00Z
business_unit: Customer Operations
user_role: complaint_specialist
tool_name: public_ai_chat
tool_status: not_approved
workflow: complaint_summary
data_classes: [customer_PII, complaint_text]
output_destination: case_note
customer_impact: indirect
automation_level: draft
initial_tier: Tier2
temporary_action: block_customer_data_to_public_ai
assigned_owner: ai_governance_triage_lead
target_pathway: customer_data_safe_workspace
closure_condition: users migrated and repeat DLP events below threshold

15.2 Approved AI tool catalog card

tool_id: AI-CATALOG-EMP-COPILOT
name: Enterprise Employee Copilot
owner: AI Platform Product
allowed_use:
  - public learning
  - internal low-sensitivity writing
  - approved internal knowledge search
blocked_use:
  - secrets
  - unmasked customer PII unless pathway extension is approved
  - final regulated decisions
data_retention: enterprise_retention_policy
logging: prompt_metadata_and_output_trace_by_policy
support: ai-platform-office-hours
review_cadence: quarterly

15.3 Citizen app registration

app_id: CITAI-OPS-012
app_name: Branch Procedure Summarizer
builder: branch_operations_lead
business_owner: head_of_branch_operations
technical_owner: productivity_platform_admin
users: 85 branch supervisors
data_classes_allowed: [internal_low_sensitivity, approved_policy_documents]
connectors: [approved_policy_repository_read_only]
customer_visible: false
system_write_actions: none
risk_tier: Tier1
review_triggers:
  - customer_data_added
  - external_send_enabled
  - connector_write_permission_requested
  - user_count_above_200
monitoring: usage, errors, feedback, policy_blocks
recertification_date: 2026-09-30

15.4 Exception memo

exception_id: SHAI-WVR-2026-0009
use_case: low_risk_marketing_copy_pilot
standard_control_gap: approved_brand_phrase_checker_not_integrated
scope: internal_draft_only_for_debit_card_campaign
duration: 21_days
residual_risk_owner: head_of_marketing
compensating_controls:
  - compliance_review_before_external_use
  - no customer_data_inputs
  - prompt_and_output_retention
  - daily_sample_review
hard_stops:
  - external_publication_without_review
  - customer_data_detected_in_prompt
  - misleading_fee_claim_detected
exit_path: integrate approved phrase checker or stop pilot

15.5 Policy communication snippet

You may use approved AI tools for public learning and low-risk internal productivity.
Do not enter customer PII, account data, credit data, complaint records, credentials,
source code secrets or regulatory records into unapproved AI tools.
If AI would help a workflow not covered by the catalog, submit the AI intake form.
The governance team will route the request to an approved pathway or explain the restriction.

16. 30-Day Lab

Day	Exercise	Output
1	Read the source anchors and define shadow AI vs adoption	one-page framing memo
2	Build a shadow AI signal taxonomy	signal schema
3	Draft a data classification policy for prompts	prompt/data policy
4	Interview two workflow personas	interview notes and pain points
5	Create a discovery source map	discovery matrix
6	Design a risk tier model	tiering table
7	Classify ten sample shadow AI cases	triage decisions
8	Draft an approved pathway catalog	pathway list
9	Write a lightweight intake form	intake template
10	Define DLP block/warn/allow rules	DLP rule matrix
11	Design citizen developer guardrails	guardrail checklist
12	Create a citizen app registration template	registration card
13	Map a public chat workflow to internal copilot	migration plan
14	Map a team Bot to RAG golden path	migration plan
15	Map a no-code agent to tool gateway	migration plan
16	Define KRIs and dashboard tiles	dashboard spec
17	Draft a RACI for governance operation	RACI table
18	Write an exception memo for a limited pilot	waiver memo
19	Create user-facing policy language	communication snippet
20	Create manager escalation guidance	manager playbook
21	Build training scenarios by role	scenario set
22	Design audit evidence pack	evidence checklist
23	Run tabletop: customer PII in public AI	incident notes
24	Run tabletop: branch FAQ Bot gives wrong fee answer	remediation plan
25	Run tabletop: no-code agent writes CRM field incorrectly	control improvement
26	Prioritize platform backlog from shadow demand	roadmap matrix
27	Create executive dashboard narrative	management memo
28	Prepare 30-second interview answer	interview answer
29	Prepare 2-minute architecture answer	interview answer
30	Package portfolio artifact	governance architecture case study

17. Interview Answers

17.1 30 秒版本

Shadow AI is a governance problem and a product signal. I would not start with a blanket ban. I would discover actual usage through telemetry, DLP, procurement, browser inventory and workflow interviews, then classify each case by workflow, data, tool, vendor, output destination, customer impact and automation level. Low-risk use goes to an approved catalog, high-risk use gets formal gates, prohibited use is blocked, and useful patterns are migrated into platform golden paths with DLP, logging, HITL and evidence.

17.2 2 分钟版本

I treat shadow AI as uncontrolled AI usage that already exists outside the approved lifecycle. The first architectural task is discovery: network egress, CASB, browser extensions, DLP, expense data, surveys, interviews and incident reports. Each signal becomes a normalized record with user role, workflow, tool, account type, data class, output destination, customer impact, automation level and vendor status.

Then I risk-tier the use. Public learning with no company data is low risk. Customer data, records, credit, AML, fraud, wealth, complaint or payment workflows move to higher tiers. Secrets, full customer files in public AI or autonomous regulated decisions are prohibited. The governance decision is not just approve or reject. It can be approve with guardrails, migrate, restrict, block, investigate or issue a time-limited exception.

The product part is important: every shadow AI case reveals unmet workflow demand. If many teams use public AI to summarize customer complaints, the answer is not only DLP blocking. The answer is a customer-data safe workspace or RAG/copilot golden path that solves the same job with identity, DLP, retention, HITL, logging and evidence. The dashboard should show high-risk signals, migration progress, DLP repeats, exceptions, citizen app inventory and platform backlog conversion.

17.3 CTO / Architect version

I would build a control plane around shadow AI: discovery connectors, signal registry, risk-tiering service, approved tool catalog, policy engine, DLP integration, identity, citizen app registry, exception workflow, evidence store and dashboard. The architecture routes users toward golden paths rather than forcing every team to invent local controls. It also gives Security and Risk a way to block prohibited behavior while giving Product a roadmap signal about missing platform capabilities.

17.4 PM / BA version

My focus is workflow conversion. I would interview users to understand why they chose an unsanctioned tool, map the AS-IS workflow, classify data and output, then design a sanctioned TO-BE path that preserves the productivity benefit. For BA work, that means turning policy into concrete requirements: allowed data classes, review triggers, records retention, output verification, exception handling and success metrics.

17.5 Risk / Compliance version

The key is risk-tiered governance with evidence. I would define prohibited uses, high-risk review triggers, data handling rules, citizen developer guardrails, exception authority and monitoring KRIs. For financial services, I would pay special attention to PII leakage, conduct risk, records retention, third-party exposure, model-risk misuse, auditability and customer harm.

18. Common Pitfalls

Pitfall	Consequence	Better approach
Treating all shadow AI as misconduct	users hide the behavior and governance loses visibility	start with workflow demand and risk tiering
Publishing a ban without approved alternatives	productivity need remains unmet	provide catalog and intake routes
Ignoring low-code and SaaS embedded AI	citizen tools become untracked production systems	register apps and review connectors
Relying only on training	sensitive data still moves	combine literacy, DLP, gateway and monitoring
Over-gating low-risk use	employees bypass slow process	self-service for low-risk tiers
Under-gating customer workflows	customer harm and audit gaps	formal gates for Tier 3/Tier 4
No platform migration backlog	every discovery becomes manual casework	convert repeated demand into golden paths
No exception expiry	temporary deviations become permanent shadow policy	time-box exceptions and monitor aging
Dashboard counts only violations	management misses unmet demand	show demand, migration, adoption and risk reduction

19. Final Principle

The goal is not an AI-free enterprise.

The goal is an enterprise where employees can safely use AI for real work because:

the approved paths are easy to find,
the data boundaries are clear,
high-risk workflows have appropriate friction,
citizen developers can build inside guardrails,
useful shadow demand becomes platform capability,
prohibited behavior is blocked and remediated,
and management can see risk, value, adoption and evidence in one operating system.

Shadow AI maturity is reached when discovery no longer feels like policing and migration no longer feels like punishment. It becomes a product feedback loop for building safer, better AI pathways.