Produce a one-page AI acceptable-use policy from a structured intake. A useful policy is specific enough that an employee knows what to do without interpretation, short enough that they read it, and clear about the limits of its visibility.

Intake questions

Ask these questions one group at a time. Don’t dump all of them at once.

Group 1: The basics.

What industry are you in? (Determines regulatory baseline.)
How many employees? Roughly how many use AI tools today?
What AI tools are currently approved or in use? Include personal accounts, expensed tools, scheduled tasks, and anything informal.

Group 2: Data sensitivity. 4. What types of data do your people handle? (Customer PII, financial records, health data, trade secrets, source code, legal documents.) Ask them to name the two or three most sensitive categories. 5. Are any of your AI tools on enterprise plans with data-processing agreements? Which ones? 6. Has anyone raised a concern about data going into an AI tool? What happened?

Group 3: Current state. 7. Is there an existing AI policy, even informal? If yes, ask them to share it or describe it. 8. Who would own this policy going forward? (Name and title, not “the AI committee.”) 9. How do new tool requests get handled today? Is there a process or does it happen ad hoc? 10. What scheduled or unattended agents, routines, scripts, or automations run against company systems today? Ask for the list, not an estimate. If they cannot produce one, record that as an inventory gap.

Group 4: Unattended work. 11. For each scheduled or unattended agent, who is the named human owner? What does it do, and on what cadence? 12. Which systems does it touch? Which connectors can it use? What human or service identity is connected to each connector? 13. What is the review path? Name who checks the output, what they check, and what stops or escalates the agent when it is wrong. 14. Which plan and execution surface does it use: organization-managed or personal, cloud or local? What exact admin controls, logs, or export path has the organization verified? Do not accept “it is on Enterprise” as an answer. 15. Which agents touch restricted or customer data, a system of record, or work other people depend on? Those need named approval before they run.

Group 5: Risk posture. 16. What’s the worst thing that could happen if an employee put the wrong data into an AI tool? (This question calibrates the restricted-data list.) 17. Are there any AI uses you want to prohibit outright? (Common: generating customer-facing content without review, submitting AI output to regulators, using AI for hiring decisions without human sign-off.) 18. How do you want to handle people using unapproved tools? (This question reveals whether they want enforcement or guidance.)

If they can’t answer a question, note the gap and move on. Gaps become action items in the policy.

How to draft the policy

The policy is one page. Not two. Not five. One page forces hard decisions. If it doesn’t fit on one page, something is too vague.

Structure it as three lists, a compact scheduled-agent rule, and a footer. The policy states the rule; the agent inventory holds the per-agent records. Do not paste the whole inventory into the policy.

Header block

Policy title: AI Acceptable Use Policy
Owner: [Name and title from question 8, or flag as TBD]
Effective date: [Today’s date]
Review cadence: Quarterly. Next review: [date three months out]

List 1: Approved tools

Name every approved tool, its plan tier, and a link to its first-party data-processing terms. If a tool does not have an agreement that covers the intended data, it does not belong on this list for that data.

Format each entry as: Tool Name (Plan Tier) - [first-party DPA, BAA, or data-terms link]

If they have tools in use without a verified agreement, flag them as “Approved for non-sensitive use only; data terms pending” with a deadline.

List 2: Restricted data

Five to eight specific lines. Not generic categories. Tailor to their industry and their answers from Group 2.

Bad example: “Confidential information should not be entered into AI tools.” Good example: “Do not enter customer Social Security numbers, account credentials, or health records into any AI tool, including approved tools without enterprise data agreements.”

Each line should be specific enough that an employee reading it knows exactly what they can’t paste. If a restriction only applies to certain tools, say which ones.

Scheduled and unattended agents

Keep every scheduled or unattended agent in a separate inventory. The policy should require named approval before an agent reaches restricted or customer data, a system of record, or load-bearing work.

Every inventory record must name the agent’s owner, purpose and cadence, systems, connectors, connected human or service identity, review path, plan and execution surface, verified admin visibility, and stop or escalation path. Do not substitute a plan name for any of those fields.

For work that needs a central compliance record, require a verified centrally accessible log and name who reviews it. If the plan or execution surface cannot provide that record, do not describe the agent as auditable. Do not approve it for that work until there is a real review path and an appropriate control.

For a local session, use the exact visibility the organization has verified. Do not promise central management, export, or auditability based on the plan alone. If the only record is local history, say so and treat it as an inventory and review gap.

List 3: Logged and reviewed

What gets monitored, by whom, and how often. This section pairs each of the five real failure modes with a control:

Data leakage: [Verified DLP, vendor, or endpoint signal] reviewed [weekly/monthly] by [role]. Tools without that control are restricted to non-sensitive data.
Wrong answers in high-risk workflows: Any AI-assisted output reaching a customer, court, or regulator requires human review by [role] before sending. Name the system or record that captures the sign-off if one exists; do not invent one.
Over-reliance: [Optional, calibrate to their risk posture.] Junior staff in regulated functions must be able to defend AI-assisted work without the tool open. At least one recurring task per role stays manual.
Shadow AI: [Verified endpoint, proxy, or DLP control] flags unapproved AI tool usage. Reported within 48 hours: documentation only. Discovered by IT: security incident. The goal is disclosure, not punishment.
Ungoverned automation: The policy owner reviews the agent inventory quarterly. Any unapproved agent, missing owner, unverified connector or identity, missing review path, or visibility gap is removed from the approved state until resolved.

New tool requests: Submitted to [owner] with a two-week SLA for approval or denial.
Violations: First occurrence handled by [owner]. Pattern violations escalated to [role].
Questions: [Owner’s email]

What to output

Produce the complete one-page policy using the structure above, filled in with their specific answers. Where they left gaps, insert bracketed placeholders with a note: “[TBD - needs enterprise DPA before approval].”

After the policy, add a short section titled Action items listing anything unresolved: tools without verified data terms, unnamed policy owners, data categories that need legal review, monitoring capabilities not yet in place, and every agent with a missing owner, systems list, connector list, connected identity, review path, visibility record, or stop path. Call out agents whose plan or local session cannot provide the visibility their work requires.

Don’t add a preamble about the importance of AI governance. Don’t add definitions. Don’t add an appendix. Every restriction should be specific enough that an employee knows what to do and what not to do.

Vendor-control claims

Use first-party vendor documentation for current plan, connector, monitoring, DPA, and audit claims. Do not fill a policy with a control because a sales page or a secondary source says it exists.

For Claude controls, verify the exact plan and execution-surface claim against Anthropic’s official documentation before naming it:

Those controls change. If the organization cannot verify a claimed control in its own tenant and on the relevant execution surface, write the limitation plainly and make it an action item.

AI Policy Draft