You are viewing the current published version.
Business Advanced ChatGPT

Evidence-Grounded Shadow AI Risk Assessment and Governance Plan

Analyze unmanaged workplace AI use with explicit evidence, uncertainty, severity scoring, data-exposure analysis, acceptable-use controls, and a phased governance roadmap.

View all versions
Best foranalysis
ToolChatGPT
DifficultyAdvanced
Full Prompt
Analyze Shadow AI risk within the authorized business scope. Shadow AI includes unapproved, unmanaged, or insufficiently governed AI tools, accounts, extensions, agents, integrations, and AI-enabled workflows used for business purposes.

Context
Business context: [Business context]
Industry and jurisdictions: [Industry and jurisdictions]
Company size: [Company size]
Departments and workflows: [Departments and workflows]
Authorized assessment scope: [Authorized assessment scope]
Known AI tools and use cases: [Known AI tools and use cases]
Sensitive data and classifications: [Sensitive data and classifications]
Existing AI security data and procurement policies: [Existing AI security data and procurement policies]
Evidence packet: [Evidence packet]
Recent incidents or concerns: [Recent incidents or concerns]
Compliance and contractual requirements: [Compliance and contractual requirements]
Risk tolerance: [Risk tolerance]
Definition of done: [Definition of done]

Tool and authority boundaries
Use ChatGPT only to analyze information supplied in this conversation, reconcile evidence, identify gaps, score risks, and draft controls and governance artifacts. Do not imply that ChatGPT inspected identity providers, browser telemetry, SaaS logs, endpoints, source repositories, procurement systems, contracts, employee devices, or vendor settings unless corresponding evidence was supplied. Do not claim that a tool was disabled, data was deleted, an incident was contained, a policy was approved, employees were contacted, monitoring was enabled, or remediation was completed.

Do not make system changes, contact employees or vendors, conduct surveillance, approve policy, provide a definitive legal determination, or investigate beyond the authorized scope. Present all operational changes as proposals requiring the named business, security, privacy, legal, HR, procurement, or system owner to authorize and execute them. Preserve responsible, productivity-enhancing AI use; do not recommend a blanket ban unless supplied evidence demonstrates that narrower controls cannot reduce an intolerable risk.

Input sufficiency
Treat the business context, industry and jurisdictions, company size, departments and workflows, authorized scope, sensitive-data classifications, compliance obligations, risk tolerance, and definition of done as blocking inputs for a final assessment. The known-tool list, policies, evidence packet, and incident history improve confidence but may legitimately be unknown.

If a blocking input is absent, ambiguous, or materially conflicting, ask concise clarification questions before producing a final assessment. If answers are unavailable, continue only with a clearly labeled preliminary assessment, retain the unresolved values as unknown, narrow conclusions accordingly, and provide an evidence-collection plan. If there is no evidence packet, produce a discovery plan and hypothesis register rather than presenting suspected usage as confirmed. Never interpret a lack of evidence as proof that Shadow AI is absent.

Evidence and uncertainty rules
1. Assign each material statement one of these evidence states:
   - Confirmed: directly supported by a supplied artifact or consistently corroborated records.
   - Reported: stated by a stakeholder or in an unverified questionnaire.
   - Inferred: a bounded conclusion drawn from identified evidence.
   - Hypothesis: plausible but not yet supported sufficiently.
   - Unknown: evidence is missing.
   - Conflicted: supplied sources disagree.
2. Cite supplied evidence using an artifact name or identifier and, when available, a page, section, date, log interval, or record reference. Do not invent citations.
3. Separate observed current controls from proposed controls. Record evidence freshness and scope limitations where they affect confidence.
4. For conflicts, show both claims, explain why the conflict matters, and identify the evidence or owner needed to resolve it.
5. Do not infer legal compliance solely from the existence of a policy. Mark legal and regulatory interpretations for qualified human review.

Data-protection and stop conditions
Do not request passwords, API keys, authentication tokens, raw customer records, private employee communications, or unnecessary personal data. Recommend redaction, aggregation, least-privilege access, approved evidence storage, and retention limits. Stop substantive analysis and recommend immediate escalation to the authorized incident-response or privacy owner if supplied evidence indicates active credential exposure, ongoing regulated-data disclosure, malicious use, or an incident outside the assessment authority. Preserve evidence; do not recommend destructive cleanup before authorized incident triage determines preservation requirements.

Assessment workflow

1. Establish scope and evidence quality
- Restate included and excluded entities, departments, workflows, data classes, jurisdictions, time period, and systems.
- Build an evidence ledger covering supplied policies, tool inventories, expense or procurement records, identity and access records, endpoint or browser inventories, network or SaaS telemetry, data-loss prevention alerts, repository configurations, vendor terms, training records, questionnaires, interviews, and incident records where supplied.
- For each artifact, record source, date or period, scope, evidence state, limitations, and which assessment questions it can support.

2. Build the Shadow AI discovery matrix
Cover, where relevant: personal AI accounts used for work; unapproved generative AI services; browser extensions; meeting transcription bots; coding assistants; autonomous agents; workflow automations; writing and summarization tools; image, audio, and video generators; customer-support bots; marketing tools; file-upload and data-analysis services; AI features embedded in approved SaaS; model APIs; shared credentials; unsanctioned integrations; and downstream model or plugin connections.

For each discovery area, record the department or workflow, candidate tool or behavior, evidence requested, supplied evidence, current status, data pathway, account or identity model, integration privileges, current control, gap, confidence, and next validation step. Use only these current-status values: Confirmed use, Indicated use, Not evidenced, Unknown, or Out of scope. Treat Not evidenced as inconclusive rather than absent.

3. Create an AI-use inventory
For each confirmed, reported, or indicated use, record: inventory ID; tool and vendor; AI feature; business purpose; department; business owner; technical owner; approval state; account type; user population; input data classes; output destination; retention or model-training setting if evidenced; plugins, agents, APIs, or integrations; access privileges; vendor-review state; contract or data-processing terms if evidenced; jurisdiction or data-residency concern; evidence reference; confidence; and unresolved questions.

4. Identify exposure pathways and control failures
Assess potential exposure involving customer data, employee data, financial records, source code, credentials and secrets, contracts, legal material, strategy, intellectual property, regulated data, and confidential third-party information. Consider prompt and file uploads, retrieval connectors, meeting recordings, generated code, model training or retention, public sharing links, insecure plugins, overprivileged agents, cross-border processing, inaccurate outputs, automated decisions, intellectual-property provenance, shared accounts, weak offboarding, missing logging, and unreviewed vendors.

Distinguish the triggering behavior, data flow, threat or failure mode, affected asset, existing control, control gap, plausible consequence, and evidence state. Avoid claiming that exposure occurred when the evidence supports only a possible pathway.

5. Score and prioritize risks
Apply these qualitative definitions consistently:
- Likelihood Low: limited exposure opportunity with effective evidenced controls and no credible occurrence indicators.
- Likelihood Medium: plausible exposure with partial controls, recurring opportunity, or incomplete evidence.
- Likelihood High: frequent or broad exposure, ineffective or absent controls, or credible occurrence indicators.
- Impact Low: limited reversible operational or confidentiality effect.
- Impact Medium: material internal disruption, contractual concern, or contained sensitive-data effect.
- Impact High: significant regulated-data, security, financial, customer, intellectual-property, legal, or operational consequence.

Calculate severity using this matrix: High likelihood plus High impact is Critical; High plus Medium or Medium plus High is High; Medium plus Medium, High plus Low, or Low plus High is Medium; all remaining combinations are Low. If supplied organizational methodology conflicts with this matrix, show the conflict and ask which method governs rather than silently changing scores.

Assign priority separately: P0 for an evidenced active or imminent critical exposure requiring incident escalation; P1 for Critical or urgent High risks; P2 for other High or material Medium risks; P3 for remaining planned improvements. Explain any departure. Do not inflate likelihood because evidence is missing; express missing evidence through confidence and validation requirements.

6. Design proportionate controls
For each risk, consider the least restrictive effective combination of approved-tool alternatives, data-classification restrictions, vendor due diligence, enterprise accounts, retention and training opt-outs, access controls, secret scanning, data-loss prevention, integration allowlisting, logging, human review, output validation, secure coding review, procurement gates, contractual terms, training, reporting channels, and exception handling.

Draft acceptable-use rules that specify permitted uses, prohibited data and actions, approval triggers, required account types, human-review obligations, output checks, disclosure expectations, recordkeeping, incident reporting, and a time-bound exception process. Separate mandatory controls from recommendations and identify the policy owner and required approver.

7. Build the remediation and governance roadmap
Organize proposed work into Immediate, 30-day, 60-day, 90-day, and Long-term horizons. For every action include the linked risk IDs, accountable owner, required approver, dependencies, effort, expected risk reduction, implementation evidence, validation method, rollback or recovery consideration, target timing, and status. Use only Proposed, Authorized, In progress, Implemented awaiting validation, Verified, Blocked, or Not applicable as action states. Assign Verified only when supplied execution evidence demonstrates implementation and the stated validation check passed.

Include an approved-tools register process, vendor-review gate, exception register, periodic discovery cadence, policy review trigger, employee training, incident intake and escalation, metrics, control testing, ownership, and retention of assessment evidence. Recommend legal, privacy, HR, security, procurement, and employee-representative review where required by jurisdiction or organizational authority.

Required deliverable

A. Assessment status and scope
- State whether the result is Final or Preliminary.
- List scope, exclusions, assessment period, blocking gaps, material conflicts, and confidence limitations.

B. Executive decision brief
- Summarize evidenced conditions, leading risk themes, urgent escalation needs, decisions required, and a balanced enablement strategy.
- Keep hypotheses and unknowns separate from confirmed findings.

C. Evidence ledger
Table columns: Evidence ID | Artifact or Source | Date or Period | Scope | Evidence State | Questions Supported | Freshness or Coverage Limitation

D. Shadow AI discovery matrix
Table columns: Discovery Area | Department or Workflow | Tool or Behavior | Current Status | Evidence Reference | Data Pathway | Existing Control | Gap | Confidence | Next Validation Step | Owner

E. AI-use inventory
Use the inventory fields defined in step 3. Do not invent vendor settings, contractual terms, or approval states.

F. Sensitive-data exposure map
Table columns: Exposure ID | Data Class | Source | AI Tool or Pathway | Destination or Recipient | Triggering Behavior | Existing Safeguard | Exposure Status | Evidence Reference | Consequence | Required Validation

G. Risk register
Table columns: Risk ID | Risk Statement | Department or Workflow | Asset and Data | Threat or Failure Mode | Existing Control | Control Gap | Evidence State and Reference | Likelihood | Impact | Severity | Confidence | Rationale | Business Owner | Recommended Control | Priority | Linked Action IDs

Write each risk as a conditional cause-event-consequence statement. Clearly distinguish confirmed incidents from possible exposure scenarios.

H. Acceptable-use and exception rules
Present a decision table with: Use Scenario | Allowed, Restricted, or Prohibited | Data Conditions | Approved Account or Tool Requirement | Required Human Review | Output Validation | Approval or Exception Owner | Reporting Requirement | Rationale

I. Remediation roadmap
Provide separate Immediate, 30-day, 60-day, 90-day, and Long-term tables using: Action ID | Linked Risk IDs | Proposed Action | Owner | Required Approver | Dependencies | Effort | Expected Risk Reduction | Implementation Evidence | Validation Method | Rollback or Recovery Consideration | Target | State

J. Monitoring and governance plan
Define the approved-tools register, procurement and vendor review, exception lifecycle, discovery cadence, control-testing cadence, policy refresh triggers, training audiences, incident workflow, privacy safeguards for monitoring, metrics, reporting owner, escalation thresholds, and governance forum.

K. Staff training plan
Segment guidance for general employees, managers, developers, customer-facing teams, procurement, security and privacy teams, and executives. Include learning objectives, risky scenarios, approved alternatives, reporting routes, delivery owner, cadence, and evidence of completion without claiming training occurred.

L. Verification and acceptance matrix
Table columns: Check ID | Acceptance Check | Expected Observation | Actual Observation from Supplied Evidence | Evidence Reference | Result | Unresolved State | Owner | Follow-up

Perform and report these checks:
- Scope coverage: every in-scope department and workflow is represented or explicitly marked Unknown with a validation owner.
- Inventory reconciliation: every evidenced tool or use appears in the inventory, and duplicates or conflicting names are identified.
- Evidence traceability: every Confirmed finding and every asserted current control has a valid supplied evidence reference.
- Exposure traceability: each sensitive-data pathway links to an inventory, discovery, incident, or evidence item.
- Risk-action coverage: every High or Critical risk has at least one linked action, owner, approval point, timing, and validation method.
- P0 integrity: every P0 item has evidence of active or imminent exposure and a named escalation route; otherwise reduce the priority or mark it unresolved.
- Severity consistency: likelihood and impact reproduce the stated severity matrix, with departures explained.
- Control feasibility: recommendations fit company size, risk tolerance, authority, and stated dependencies.
- Adoption balance: restrictions are paired with an approved alternative, exception route, or documented reason why neither is safe.
- Completion integrity: actions marked Verified have supplied implementation evidence and a passed validation observation; all others retain their actual state.
- Obligation review: compliance and contractual mappings identify their source and are marked for qualified review when interpretation remains uncertain.

Use Pass, Fail, Blocked, or Not run for verification results. Do not record Pass when expected observations cannot be compared with supplied actual evidence.

M. Unresolved questions and handoff
List unknowns, conflicts, additional evidence requests, decisions needed, responsible owners, escalation items, and the next authorized review point. End with separate lists titled Proposed actions, Evidence-supported completed actions, and Unverified or blocked actions. The second list must remain empty unless completion evidence was supplied.

Variables to Replace

  • Business context
  • Industry and jurisdictions
  • Company size
  • Departments and workflows
  • Authorized assessment scope
  • Known AI tools and use cases
  • Sensitive data and classifications
  • Existing AI security data and procurement policies
  • Evidence packet
  • Recent incidents or concerns
  • Compliance and contractual requirements
  • Risk tolerance
  • Definition of done

How to Use This Prompt

In ChatGPT, replace every bracketed variable with your business context and authorized assessment details. Provide redacted source materials such as policies, approved-tool lists, procurement records, questionnaires, vendor terms, relevant logs, and incident records; label each artifact for citation. Do not provide secrets or unnecessary personal data. Then run the prompt and route consequential findings, legal interpretations, policy changes, monitoring proposals, and remediation actions to authorized human owners for review.

Example Use Case

A software company supplies ChatGPT with its AI policy, approved SaaS register, redacted expense records, developer survey, vendor terms, and data classifications. The prompt distinguishes confirmed and suspected AI use, maps source-code and customer-data pathways, produces an evidence-linked risk register, and proposes approval, training, and monitoring controls without claiming that any control has already been implemented.

Published change

Major: Replace the legacy Shadow AI Risk Assessment for Business Security and Compliance template with a domain-specific input, evidence, authority, safety, workflow, output, and verification contract.