AI-Assisted Writing Governance

Approved AI Use Case Card

Publish an internal operating card that defines one allowed AI-assisted writing use case, safeguards, owner, permitted data, and prohibited behavior.

Free editable Markdown · AI governance teams, compliance teams, and content operations teams · Updated July 30, 2026

Download Markdown

Accessible HTML preview

Blank template

The downloaded file contains the same fields in editable Markdown.

Authorization

Use case ID and title: [Enter]
Business purpose: [Describe]
Allowed AI task: [One bounded operation]
Eligible users or roles: [List]
Approved service, feature, and account: [Enter]
Intended output and audience: [Enter]
Risk assessment reference: [Enter]
Card owner and version: [Name/version]

Permitted workflow

Permitted data classes: [Define with examples]
Sources required: [List]
Approved prompt or context pattern: [Reference]
Output may be used for: [Internal draft / Alternatives / Other]
Required factual checks: [Who checks what against which evidence]
Required subject review: [Role and trigger]
Final approval: [Role]
Provenance and disclosure: [Requirements]

Prohibited and escalation cases

Additional prohibited inputs: [List]
Additional prohibited outputs: [List]
When to stop and escalate: [List]
Escalation owner and route: [Enter]

Do not enter credentials, secrets, or unapproved personal information.
Do not use the output as proof of facts, citations, or authorship.
Do not automate publication or consequential decisions outside this card.
Do not imitate a real person or create deceptive identity claims.

Control and lifecycle

Training required: [Module/owner]
Monitoring sample and owner: [Define]
Incident reporting route: [Enter]
Suspension authority: [Role]
Approval names and date: [Enter]
Effective date: [YYYY-MM-DD]
Review or expiry date: [YYYY-MM-DD]
Reassessment triggers: [Tool, data, audience, scale, policy, incident]

How to use this template

Link the approved assessment and copy its exact task, tool, data, and audience boundaries.
Translate safeguards into clear steps, named roles, evidence requirements, and examples.
Define prohibited behavior, escalation, incident, suspension, and revocation paths.
Obtain governance and operational approval, then publish a controlled card version.
Train users, sample actual use, and renew or withdraw the card at its trigger date.

Make authorization recognizable at the point of work

A policy document may be too broad for someone deciding what to paste into a tool. Convert an approved risk decision into a concise card that names the business purpose, precise AI task, eligible users, approved service and account, permitted inputs, intended output, and required human review. Include examples of allowed and disallowed behavior drawn from realistic work. Avoid phrases such as “non-sensitive content” without defining relevant classifications. A user should be able to compare their current task with the card and know whether it fits, needs escalation, or must stop.

Express safeguards as executable workflow

State how sources are prepared, sensitive fields removed, prompts stored, outputs marked, facts verified, and final approval recorded. Name roles rather than relying on “someone will review.” If only an editor may publish, say so; if a subject expert must verify product instructions, identify that gate. Define whether the output can be shared externally, whether disclosure is required, and how provenance is logged. Link the card to the approved prompt pattern, data policy, vendor facts, incident route, and risk assessment so users can find details without improvising controls.

Keep the card versioned and revocable

Assign an owner, approval date, version, effective date, review date, and automatic expiry. Changes to the tool, service terms, account configuration, data type, audience, scale, or output consequence should trigger reassessment. Explain how users report a mistaken upload, harmful output, privacy concern, or repeated verification failure and who can suspend the use case. Retire superseded cards from active guidance while preserving the decision history. Training should use the current card, and monitoring should test whether real work matches its scope rather than merely count acknowledgments.

See the fields in context

Fictional example: meeting-note heading alternatives

The organization, tool, and authorization below are invented and confer no real permission.

Allowed: An imaginary editorial team may request heading alternatives from public, approved meeting notes in a managed account.
Not allowed: Private attendee details, unpublished decisions, or generated quotations may not be submitted or published.
Review: The meeting owner verifies meaning, and an editor selects or rewrites every heading.
Incident route: A mistaken private upload is reported immediately to the fictional security contact.
Expiry: The card expires in 90 days or when service data terms change.

Frequently asked questions

Is the card a replacement for an AI policy?

No. It turns one approved policy decision into usable operating guidance and should link to the governing policy and assessment.

Can a user apply the card to another AI service?

No, unless the card explicitly names that service and configuration. Vendor handling and behavior can differ materially.

How detailed should the examples be?

Include enough realistic detail to distinguish permitted work from near-miss cases without exposing sensitive data.

What happens after the expiry date?

The use should stop or revert to the organization's default rule until an authorized owner reviews and renews the card.