AI governance: practical rules for your team and its data

An employee wants to summarise customer records. The tool says it does not train on business data. That sounds reassuring, but it leaves several practical questions unanswered: which account is being used, what gets stored, where processing happens, who can access the result and whether a connected tool receives a copy. Good AI governance turns those questions into everyday decisions. Start with a small register of real use cases and clear routes for staff, rather than a long list of abstract warnings. This workflow uses a fictional maintenance business to show the result. The proposed rules need local approval and appropriate privacy, security and legal review; no real organization or account has been audited.

Before you start

• A business owner plus responsible privacy/security reviewers; name roles where no dedicated team exists.
• A list of proposed tasks, data classes, users, connected systems and intended outputs; use synthetic examples while designing the process.
• Dated official product guidance and applicable agreements/settings evidence. Mark missing evidence UNKNOWN; a marketing statement does not establish your configuration.

Tools: ChatGPT, Claude, Business AI tools. Use an assistant approved by your organization. This text-based first version does not require new integrations; account features and data policies still apply.

The workflow, step by step

1. Name an owner and register the actual use case

   A rule such as use AI responsibly gives employees very little help. Start with a register of concrete tasks: drafting a public FAQ, summarising support records, or proposing a decision about a person. Name a business owner and someone responsible for privacy and security review. Small organizations can use existing roles. Record the product, account type, workspace, features and connected systems, not just the model brand. Include the business purpose, data involved, output audience, human reviewer and review date. Chat, coding agents and API applications can have different data paths. NIST’s AI Risk Management Framework is voluntary risk-management guidance; its Generative AI Profile is a companion for generative systems. Neither turns a completed spreadsheet into certification. Use the register to connect a task to its risks and controls. The Canadian privacy commissioners’ guidance also calls for defined accountability and assessment. The organization remains responsible for deciding whether a proposed use is appropriate.

2. Give staff three clear routes: permitted, restricted and prohibited

   Define what people can do now, what requires review, and what your organization will not allow. Make each rule specific enough to use at the moment someone is about to paste a document. A permitted route might allow public, approved copy in a named workspace with human review. A restricted route might allow redacted support records only after the data flow and purpose are approved. Prohibited routes might include credentials in prompts or raw payroll uploads to personal accounts. These are example organizational choices, not a claim that every restricted task is illegal or every permitted task is compliant. A ban on one route does not settle whether a differently designed workflow could be approved. Define an exception process with an accountable decision-maker rather than letting staff improvise. For each route, include output limits: draft only, no automatic sending, no purchasing or account changes, and no consequential decision about a person unless a separately assessed process authorizes it. Name the escalation route.

3. Separate five questions that often get bundled into privacy

   Training asks whether content can help develop or improve models. Retention asks what information is stored and for how long. Residency asks where specified data is stored or processed. Access asks which people, systems and organizations can reach it. Deletion asks what is removed, from which systems and under what exceptions. An answer to one is not an answer to the others. OpenAI’s API documentation distinguishes abuse-monitoring logs from application state, and describes training defaults separately. Anthropic likewise documents commercial training policy and retention in separate guidance. A provider’s no-training default therefore does not establish no storage, no safety review or immediate erasure. Nor does a regional storage option establish that every inference, support operation or third-party tool stays in that region. Create separate fields for these questions in your register. When the business requires a location constraint, write exactly what it covers: customer-content storage, processing, backups, administrative access or another defined category. Ask the vendor to resolve gaps; keep unverified requirements marked unresolved instead of compressing them into a misleading yes/no privacy score. A storage region also does not settle which entities, subprocessors or support teams can access data or eliminate lawful-disclosure obligations. Canadian OPC cloud guidance explains that contracts cannot override foreign law. Treat location controls and contract terms as protections to assess, not guarantees against all access; ask the responsible reviewer which jurisdictions and obligations apply.

4. Draw the data path beyond the chat box

   Follow one example input from its source to its final destination. A support summary may pass through an export, a local file, an AI prompt, an uploaded attachment, the assistant’s response and the document where the team saves the result. If a connector retrieves related records, add that service and the retrieval index. If an agent calls another tool, add the tool and its operator too. Then ask about logs, traces, cached files, backups, feedback reports, support access and subprocessors. These are possible locations to investigate, not universal storage claims. Record what exists, what is excluded, what you cannot verify and who must answer. Deleting visible history may not remove every copy. OpenAI’s enterprise guidance specifically warns that connected services have their own data requirements. Keep an external system’s retention and access rules attached to that system rather than assuming the assistant’s settings govern it. This simple map often reveals a more practical mitigation: remove an unnecessary connector or avoid exporting the sensitive fields in the first place.

5. Verify the exact account, feature and contract

   Consumer, business-workspace and API offerings are different purchasing and control arrangements. A paid personal plan is not automatically an enterprise contract. Anthropic’s consumer guidance expressly includes Free, Pro and Max accounts and their Claude Code use; its commercial training guidance covers separate products. Check the active account and applicable terms before treating a personal subscription as an approved business environment. The vendor notes are questions to verify, not a ranking. OpenAI documents Enterprise workspace commitments that depend on configuration and feature, and API controls with endpoint-specific limits. Anthropic describes a commercial no-training default with feedback or data-sharing exceptions, separate retention conditions and location guidance that distinguishes routing from storage. Neither source establishes your organization’s actual settings or contract. Save the relevant documentation date, contractual reference and configuration evidence in the register. If a regional feature is advertised, verify availability for your plan, model, endpoint and tool chain. Do not label an entire vendor Canada-only or zero-retention because one eligible feature offers a regional control. Recheck when the product or connection changes.

6. Minimize the data and the authority

   Begin with public or synthetic material while designing the workflow. Supply only fields needed for the task. Remove identifiers, unrelated history, private attachments and secrets. Redaction needs a human check: an unusual job title, order number or detailed incident can still identify someone. Keep any necessary re-identification key separately with tighter access. Do not call altered text anonymous merely because a name disappeared. Apply the same discipline to retrieval. Select the project folder or record set the task needs; do not connect the entire company drive for convenience. Use role-based access, supported identity controls and read-only tool scopes where they meet the task. Confirm the resulting scope with the system owner. A prompt saying do not open payroll is not a technical access boundary. The Canadian guidance recommends using synthetic or de-identified material where personal information is unnecessary. Our practical adaptation is to reduce the input before upload and restrict what an agent can retrieve or change. Preserve human review and reversal.

7. Set review, usage and failure rules before rollout

   Define what a reviewer must verify: factual claims, source references, private details, fairness where relevant, and whether the proposed action is within authority. Give the reviewer the original approved source, not just a confident AI summary. For external messages, make clear who approves the content and who sends it. Under the proposed policy, AI must not independently approve refunds, send customer commitments or make employment, credit or health-related decisions. A separately assessed process and accountable human authority are required. Also define practical usage limits. Record who may enable paid features, add a connector, increase a quota or run unattended work. Choose limits for your own pilot and name the response to a limit or outage. Do not let an exhausted allowance trigger an automatic switch to an unapproved account or provider. Establish a manual fallback for time-sensitive tasks. Check representative permitted and rejected cases using synthetic material, then record what actually happened. Check staff understand escalation. A policy or unchecked screenshot does not prove controls work. Keep untested controls labelled as planned.

8. Close the loop on retention, deletion and incidents

   Specify where the approved result belongs, how long working copies are needed and who owns disposal. Compare the business retention requirement with the product’s documented controls and exceptions. Include uploaded files, saved outputs, source exports, connected services and any logging or backup arrangements identified in the map. Distinguish a deletion request, a confirmation in the user interface and evidence about backend handling. Anthropic’s retention guidance includes exceptions for particular services, safety requirements and legal obligations. Avoid replacing such conditions with a universal deletion deadline. If a required retention or location condition remains unverified, keep the restricted workflow on hold or redesign it with data that does not require that assurance. Give staff a simple incident route: stop the affected activity, prevent further sharing, notify the designated owner and preserve a minimal factual record through the incident process. Do not spread exposed content into a new help ticket or AI chat. Let the responsible privacy/security team assess containment, notification and evidence preservation under applicable obligations. Review the register after an incident or material vendor change, and retire workflows that no longer meet their conditions.

Try it with a sample

Use this synthetic input to see the distinctions your output should preserve.

What a good result should preserve

A prompt you can adapt

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]

Check the result

• Every use case identifies purpose, owner, exact account arrangement, data, reviewer and permitted actions.
• Permitted/restricted/prohibited routes are proposed organization rules with conditions and an exception owner, not invented legal findings.
• Training, retention, storage, processing, access and deletion have separate evidence or explicit gaps.
• The data map includes connected tools and applicable exports, logs, backups, support access and subprocessors without assuming every category exists.
• Sensitive retrieval and tool authority are technically scoped where supported; prompt instructions are not mistaken for access controls.
• Retention/deletion claims distinguish documented terms, actual configuration, visible history and verification still outstanding.
• An incident route, manual fallback, usage/spend authority and review triggers exist; actual checks are distinguished from planned work.

What to keep in mind

This is a researched workflow and original fictional policy exercise, not legal advice, a privacy-impact assessment, a security audit, certification or a tested control implementation. The relevant law, contract and risk depend on jurisdiction, sector, task and data. Vendor terms, region eligibility, product names, features and retention exceptions change. Official documentation reviewed on 14 October 2026 does not establish a real account’s configuration; verify the current agreement and feature coverage before relying on them.

Sources & review notes

These sources support the tool context and review principles. The workflow, prompt, and synthetic example are original editorial material.

• NIST: AI Risk Management Framework

  Voluntary risk-management framework, not a compliance certificate; official overview currently notes ongoing revision.

• NIST: Generative Artificial Intelligence Profile

  Official publication record for NIST AI600-1, July2024; companion to AI RMF1.0.

• Canadian privacy commissioners: Principles for generative AI

  Official guidance on accountability, purpose, necessity/proportionality, transparency and safeguards. Applicability requires jurisdiction-specific review.

• OpenAI: Data controls in the API platform

  Training default, logs, endpoint state, eligibility and residency exclusions are distinct. No specific regional entitlement or account setting verified.

• OpenAI: ChatGPT Work admin FAQ

  Enterprise commitments depend on workspace, plan, configuration, feature and region; connected systems have their own requirements.

• Anthropic: Commercial model-training policy

  Commercial no-training default has feedback/data-sharing exceptions. Reviewed policy dated August18,2026.

• Anthropic: Organization data retention

  API and saved commercial conversations differ; service, legal, safety and Covered Models exceptions apply. Avoid universal deletion deadline.

• Anthropic: Server locations and commercial routing

  Commercial guidance distinguishes routing, storage and internal processing; verify current contract/feature rather than inferring an end-to-end region guarantee.

• Anthropic: Consumer model-training policy

  Official consumer scope explicitly includes Free/Pro/Max and their Claude Code use; commercial guidance is separate.

• Canadian OPC: Cloud computing for small and medium-sized enterprises

  Canadian regulator guidance on cloud due diligence, location and foreign-law access; this is not a determination of a particular organization’s applicable law.