An employee wants to summarize a customer complaint. A manager wants to upload a spreadsheet. A vendor offers an assistant that can update records automatically. Your policy should help each person answer a practical question: May I do this particular job, with these records, in this workspace, using these permissions?
A statement such as “use AI responsibly” leaves those decisions to improvisation. A fifty-page policy that nobody can find creates a different version of the same problem. Start with a short operating policy, a register of approved workflows, and an evidence record for each vendor. Together, these should make the next permitted action clear.
Your deliverable is a policy draft with named decision roles, specific approval conditions, and unresolved questions visibly marked. The companion policy is a starting document. It is not adopted, and its blank ownership and effective-date fields do not authorize use.
Make the workflow the unit of approval
A vendor name is too broad an approval boundary. The same product might be suitable for rewriting public product descriptions and unsuitable for a confidential personnel investigation. A paid account, an enterprise contract, and an employee's personal account may have materially different controls.
Register the combination of business purpose, data, workspace, configuration, and action. Give each workflow an identifier that appears in its instructions and evaluation records.
| Register field | Question it must answer |
|---|---|
| Purpose and limits | What finished job may the assistant help with? |
| Data and sources | Which records may it read, and why? |
| Workspace and configuration | Which account, plan, settings, and integrations are covered? |
| Action authority | Can it draft, stage for review, send, or change a record? |
| Review and escalation | Who checks the result, and what requires a handoff? |
| Evidence and expiry | What supports approval, and when must it be reconsidered? |
For fictional Mesa, the Part 9 exercise stages an inspection-fee answer in a local review queue. It does not send a customer message or confirm an appointment. A future approval for that narrow task would not authorize refunds, new booking permissions, or access to employee records.
The exercise itself remains a local simulation. Its role fixtures are not production authentication, and its pause setting is not durable across restart. Those limitations must remain visible in any proposal to use the design in a real business.
Give decisions to people who can make them
Small organizations can combine roles, but they still need to distinguish responsibilities. The business owner decides whether the workflow serves a worthwhile purpose. A data owner confirms which records can be used. A technical owner controls access and configuration. A reviewer checks individual outputs within a defined scope. An incident contact can stop use and coordinate a response.
Write actual names and backup contacts into the adopted version. “Management” is not a usable escalation destination when a customer is waiting and the manager is absent. If one person performs several roles, record that arrangement and use an additional check for actions whose consequences justify it.
Explain what a reviewer is accepting. Approval of wording is different from approval to send. Approval to send one exact message is different from permission to send future messages automatically. The register should point to the separate action controls described in the automation chapters.
Staff also need permission to stop when information is missing. A useful policy explicitly allows an employee to use the manual process and report an unclear case without being penalized for low AI usage.
Describe data rules in terms of actual records
Identify public material, ordinary internal material, confidential business information, and sensitive personal information in language your team recognizes. Add examples from your work: published opening hours, draft supplier negotiations, customer addresses, employee health information, and account credentials.
Then specify which categories are permitted in each workflow. Do not assume that replacing a name makes a document anonymous; combinations of facts can still identify a person. Prefer the smallest necessary excerpt, omit irrelevant fields, and keep secrets out of prompts and attachments.
A rule about provider training does not answer every data question. Check storage duration, application history, operational logs, support access, subprocessors, deletion processes, and any configuration-dependent exceptions separately. “Not used for training” should never be copied into an evidence register as “nothing is retained.”
Retention also applies to your own exports, review queues, screenshots, and evaluation records. Identify who can see them, where they live, when they should be removed, and what business or applicable legal requirements affect that schedule. Obtain qualified advice for your jurisdiction and data where needed; this chapter does not establish a universal retention period.
Ask vendors for evidence tied to your intended use
NIST's voluntary AI Risk Management Framework playbook includes governance of third-party data and systems, related rights, and contingency arrangements. Its guidance supports treating supplier review as an ongoing part of managing a particular use case; it does not certify a vendor or replace your decision. NIST AI RMF Playbook: Govern
Build an evidence table before comparing sales presentations. For every important requirement, record the vendor's answer, the document supporting it, the applicable product and plan, the date reviewed, and the unresolved limitation. Use distinct statuses such as requested, claim received, evidence reviewed, and decision recorded.
“Claim received” is not a failed requirement. It is also not a verified one. Preserve that distinction so an attractive demonstration cannot silently turn missing evidence into approval.
| Requirement | Useful evidence to request |
|---|---|
| Data handling | Applicable terms, retention settings, and documented exceptions |
| Access control | Supported identity controls, role scope, and revocation behavior |
| Integrations | Permissions requested, action boundaries, and audit visibility |
| Reliability | Incident process, support commitments, and service limitations |
| Security assurance | Relevant assessment scope, date, exceptions, and coverage |
| Exit | Export formats, export procedure, termination terms, and deletion process |
| Commercial fit | Actual plan price, usage charges, limits, and renewal conditions |
An assurance report covering one service does not automatically cover every integration. A contractual promise may require a particular plan or setting. Ask someone capable of interpreting the evidence to review the parts that matter to your use, rather than collecting document titles as a substitute for judgment.
Verify performance claims with your own task
A vendor demonstration can show a capability without establishing its value in your workflow. Ask what the reported metric includes: drafting only, final accepted work, human correction, setup, difficult cases, and failures. Ask whether examples were selected and whether the comparison used equivalent work.
For U.S. advertising, the FTC's substantiation policy concerns a reasonable basis for objective claims before they are made. This is a useful reason to examine the support behind specific performance promises rather than repeating them as established facts. FTC Policy Statement Regarding Advertising Substantiation
Your purchase decision should also consider your own evidence. Use representative permitted examples and explicit acceptance criteria. Keep exploratory demonstrations separate from measured evaluations. A high average score cannot compensate for an unmet essential requirement such as access boundaries or an export you cannot recover.
Avoid a universal vendor ranking. A tool that fits a low-volume public-content task may be a poor fit for a time-critical operational process. Record a decision for the proposed workflow, with the evidence and conditions that justify it.
Address rights without making promises you cannot support
Check whether you have permission to provide the input material and whether the proposed output use fits the applicable agreements. Public availability alone does not establish unrestricted reuse. Customer contracts, licenses, confidentiality commitments, and employment arrangements may affect what you can upload or publish.
Read the provider terms that actually apply to your account and use. Do not convert a broad statement about output ownership into a guarantee that every result is original, protectable, or free of third-party claims. Escalate uncertain uses before publication or commercial distribution.
For routine content, make source tracking part of the workflow. Keep the original reference, identify quotations and factual claims requiring verification, and record whether images or other licensed materials have separate conditions. The policy should point to that process rather than forcing staff to interpret rights from memory.
Plan the exit before you depend on the product
Ask what you would need if the account were inaccessible tomorrow. Useful assets may include source documents, prompts, configuration records, evaluation cases, action receipts, customer work awaiting review, and the mapping between exported records and your business systems.
An export button does not prove that another person can restore usable work. Inspect the format, try a small permitted export, and check whether identifiers, attachments, timestamps, and relationships survive. Record anything that requires manual reconstruction. Keep exports protected under the same data rules as the originals.
Also review who can cancel, what charges continue, when access ends, and how deletion requests are handled. Do not promise immediate disappearance from every backup unless the applicable evidence supports that statement. Chapter 39 turns these questions into a recovery exercise.
Make exceptions narrow, visible, and temporary
A policy needs a route for useful new work. Require an exception request to identify purpose, data, tools, actions, duration, owner, review method, and fallback. The decision should be recorded before the exceptional use begins and should expire unless renewed.
Do not use an exception to bypass requirements the business cannot waive. If a necessary control is missing, change the task or keep it manual. A lower-risk trial may answer the business question without the original data or action permissions.
Review approved workflows when the purpose, vendor terms, model behavior, data access, integration, or accountable owner changes. A routine review date is helpful, but a material change should not wait for the calendar.
Finish with a decision staff can follow
Take one proposed workflow and complete the policy, use register, and vendor evidence record. Mark unknown facts as unknown. Assign each unresolved essential item to a person and a decision date. Ask a colleague to explain what they may do, what they must review, and how they stop the workflow.
If they cannot answer from the documents, simplify the instructions or fill the gap. The result should be a usable operating agreement: a specific job, bounded access, supported vendor assumptions, clear authority, and a workable exit. In the next chapter, you will test whether that job produces enough value to keep doing.