Quick answer: An AI use policy should name approved tools, permitted data classes, human review requirements, and a path for exceptions. Start with actual employee use cases.
Why this problem persists
Employees already use generative AI before formal governance catches up. A policy written before anyone asks how employees actually use AI tends to be either too strict to follow or too vague to apply.
Start by asking each business function which AI tools people use and for what tasks. Group the answers by the kind of data involved and by what happens if the output is wrong. That gives you real examples to test the draft against, and it shows which uses can be approved quickly and which need a separate decision.
Worked example: AI policy: classify the data before debating the model
Illustrative scenario (not a client engagement). A 140-person professional-services firm discovers that employees use three different AI assistants for meeting summaries, source-code help, and proposal drafts. A blanket prohibition would be difficult to enforce. Blanket permission would expose confidential data. The team creates a two-dimensional decision record: data sensitivity (public, internal, restricted) and use-case consequence (low, moderate, high). Public-language polishing with no customer information can be preapproved. Uploading a contract, personnel record or source repository requires a separate risk decision. Autonomous actions affecting customers are excluded from the first pilot.
| Use case | Data class | Human check | Starting decision |
|---|---|---|---|
| Rewrite a public event announcement | Public | Editorial review | Permitted in approved tools |
| Summarize internal meeting notes | Internal | Verify participants and retention settings | Conditional |
| Analyze client contracts | Restricted | Legal and security assessment | Not permitted by default |
| Send AI-generated customer commitments | Consequential | Named accountable approver | Human approval required |
A useful control is an exception log, not just a policy acknowledgment. Capture requester, purpose, data classes, proposed vendor, retention behavior, approver, decision and expiry date. Ask users to report unexpected output or accidental disclosure without assuming that every report is a disciplinary incident. Revisit the list quarterly or after a material vendor change. This approach fits the NIST AI RMF's governance-first treatment of context and risk rather than treating an AI policy as a one-time notice.
A practical five-step method
1. Survey business functions for actual use cases rather than only asking which tools are licensed
Interview sales, support, development and operations using the same questions: tool, purpose, inputs, output recipients, integrations and business owner. Record undeclared tools without immediately treating use as malicious.
2. Classify each use case by data sensitivity, external exposure and ability to affect customers
Create a row per workflow combining data sensitivity and consequence. Identify any use that would expose customer records, regulated data, credentials or binding commitments.
3. Separate prohibited activities from activities requiring review and ordinary low-risk uses
Write plain-language examples under allowed, prohibited and approval-required categories. Include prompts involving contracts, source code, customer records and externally posted content.
4. Name an accountable owner and approval route for exceptions
Require a documented decision from both the relevant business owner and risk/privacy owner when restricted data or autonomous action is involved. State approval duration.
5. Test the draft policy with real employee scenarios and revise confusing language
Ask employees to classify five anonymized tasks using the policy. Revise any category that produces inconsistent decisions before a wider rollout.
What “done” should look like
For this problem, aim for a living use-case register, practical risk matrix and executive-approved policy draft. It should show provenance, version, owner and outstanding exceptions. The sponsor needs to see what was decided, what was not decided and which actions remain. State the population, sampling method and limitations of any review. A scoped example is not a full assurance engagement.
A quick acceptance test
Ask someone outside the delivery team to locate the latest artifact, identify its accountable owner, explain the top unresolved issue and determine the next authorized action. If any answer depends on someone’s memory, the handoff is incomplete.
Common mistake to avoid
Writing a blanket prohibition that drives use into unmonitored personal accounts. The remedy is not more paperwork for its own sake. Use the smallest set of artifacts that demonstrates scope, evidence, review and the next decision. Automate only after the underlying responsibilities and exceptions are clear.
Copy-ready working checklist
- Survey business functions for actual use cases rather than only asking which tools are licensed.
- Classify each use case by data sensitivity, external exposure and ability to affect customers.
- Separate prohibited activities from activities requiring review and ordinary low-risk uses.
- Name an accountable owner and approval route for exceptions.
- Test the draft policy with real employee scenarios and revise confusing language.
- Confirm who approves the final output and how corrections will be handled.
- Archive the approved version and record the next review or follow-up date.
When a use case calls for a new vendor or an AI agent, apply the AI vendor due diligence questions before any pilot begins.
How this connects to MeritSOLV
MeritSOLV currently lists the linked package as available for a scoped proposal, subject to triage and approval.
MeritSOLV’s AI Use & Risk Baseline provides a useful next reference for teams that want a defined output rather than an unbounded consulting engagement. Its model emphasizes a written scope, a named delivery lead, independent review and documented acceptance. The decision about what to implement, approve or accept remains with the customer.
For the broader set of options, review the MeritSOLV solution catalog and how the process works. Use a small, well-defined first engagement to validate whether the operating model fits your needs.
Frequently asked questions
What belongs in an AI use register?
Owner, tool, business purpose, data categories, human review, third-party sharing and decision status.
Is an acceptable-use policy enough?
No. Pair it with staff education, an exception process, and scheduled reviews as tools and risks change.
Standards and further reading
Next step
Choose one real example, complete the checklist, and identify the evidence that would make a decision easier this week. Only after that should you decide whether an internal owner or a scoped external engagement is the right path.
These examples are illustrative, not reports of MeritSOLV™ client engagements. This guide is general operational information, not legal, audit, or certification advice. Review the cited standards and apply your organization's requirements.
