Prepare a draft AI-use policy and register from the approved business facts below. Use only supplied facts and the official documents provided. Do not access accounts, inspect real customer data, change settings or certify compliance. This is a governance drafting task, not legal advice or an audit.

ORGANIZATION / JURISDICTIONS: [business description and relevant locations]
ACCOUNTABLE OWNER: [name or role; UNKNOWN if unassigned]
PRIVACY / SECURITY REVIEWERS: [roles]
PROPOSED USE CASES: [purpose, users, input data, outputs, audience and actions]
EXACT PRODUCTS: [consumer/business/API, plan, workspace, features and connections]
BUSINESS REQUIREMENTS: [data classes, location, retention, review, cost and authority]
EVIDENCE: [dated official docs, agreements and configuration records we actually have]

Return:
1. A use-case register. Separate permitted, restricted pending review and prohibited-under-proposed-policy routes. Explain each choice; do not invent approval, configuration or legal prohibition.
2. A data-flow inventory from source to prompts/files, retrieval, model/tool processing, output destinations, logs/traces, possible backups, support and subprocessors. Mark each category VERIFIED, NOT APPLICABLE or UNKNOWN with its evidence. Do not assume every category exists.
3. Separate findings for training use, retention, storage location, processing location, access and deletion. Keep consumer, business and API terms distinct. Identify plan/feature/endpoint eligibility, feedback exceptions and third-party boundaries. “No training” must not become “no storage”; a region option must not become an end-to-end residency guarantee.
4. A concise proposed policy: allowed data/tasks, restricted/prohibited routes, least-needed access, human review, permitted external actions, usage/spend approval, manual fallback, retention/deletion ownership and incident escalation.
5. A gap list with owner, required evidence, status and next action. UNKNOWN must remain unknown; leave deadlines UNSET unless supplied.
6. An acceptance checklist distinguishing source review, actual configuration checks, synthetic behavioral checks and checks not performed.

Use synthetic or redacted examples; never reproduce credentials or unnecessary personal data. Proposed policy rules are organizational decisions for approval, not statements that a law universally prohibits the task. If a legal requirement, contract term or setting is unclear, route it to the responsible reviewer. Produce a reviewable draft and questions rather than a compliance verdict.

APPROVED BUSINESS FACTS:
[paste the synthetic example below, or approved business facts without private records]