Policy permission is not workflow approval
A firm can finish an acceptable use policy and still lack a clear answer when someone asks to add a new AI workflow. Who signs off. What evidence is required. Who reviews outputs. What event forces a fresh review.
Raleigh-Durham buyers, including firms that use Raleigh-Cary or Durham-Chapel Hill as their home market language, run into that gap when research tools, drafting assistants, and endpoint agents multiply. The need is a workflow approval record, not a second copy of the AUP.
This guide explains an operational approval artifact. It is not legal advice.
Use North Carolina sources as counsel reading, not as a settings list
North Carolina lawyers can review 2024 Formal Ethics Opinion 1 with their responsible lawyer. NCBA Center for Practice Management materials, including commentary on realistic AI policies, are separate practice-management resources. Counsel owns interpretation of competence, confidentiality, supervision, client communication, and related duties.
This article does not interpret those obligations. It gives IT, knowledge, and risk owners a record format they can complete before a workflow reaches more users.
Keep this distinct from Charlotte's AUP companion
The Charlotte policy enforcement companion focuses on monitoring, exceptions, and consequences after launch. Raleigh-Durham’s focus is the per-workflow decision after that policy exists.
| Artifact | Primary question |
|---|---|
| AI AUP (Charlotte companion) | Which standing rules and tools apply to everyone in scope? |
| Workflow approval record (this piece) | May this specific workflow go live, for whom, with what evidence? |
A user who completed AUP training still needs a workflow approval to enable a new agent path, connector-backed process, or matter-adjacent automation.
For the policy launch sequence, use the AUP rollout guide. The AI agent governance guide provides broader oversight context.
Name four owners on every request
Blank “IT will handle AI” language fails under pressure. Record four roles, even if one person temporarily holds two of them in a small firm:
- Technical owner. Builds or configures the workflow, documents controls, and runs acceptance tests.
- Output reviewer. Checks AI-assisted results against sources before external or client use.
- Records owner. Decides where prompts, outputs, and logs live, and how long they stay.
- Risk / lawyer approver. Accepts residual risk for the information classes in scope.
If any role is missing, the workflow stays in lab status.
AI workflow approval process: the decision record
Complete one record before expanding beyond a test identity.
| Field | What to capture |
|---|---|
| Workflow name and purpose | Short description a managing partner can understand |
| Users and groups in scope | Named pilot population, not “anyone with a license” |
| Tools and plans | Exact products, environments, and versions where known |
| Information classes allowed | Public, internal administrative, or restricted client material |
| Prohibited data and actions | Explicit exclusions, including connectors or writes if out of scope |
| Technical evidence attached | Identity test, boundary test, sample monitoring events |
| Output review path | Who reviews, on what cadence, before external use |
| Records location and retention | Systems of record for outputs and logs |
| Support and stop procedure | How users escalate; who can disable access the same day |
| Residual risk and review date | Named approver, accepted gaps, next mandatory review |
| Re-review triggers | Events that void the approval until rechecked |
Store the record where security and firm leadership can find it during an incident. A private slide on someone’s laptop is not an approval.
Re-review triggers that should reopen the decision
Approvals age poorly when products change underneath them. Build triggers into the record:
- Vendor adds tools, connectors, MCP servers, or browser capabilities the firm did not test.
- Pilot population expands beyond the named group.
- Information class changes, especially any move toward client or matter content.
- Monitoring destination changes or sample events stop arriving.
- A near-miss: unexpected file access, hallucinated authority used externally, or a stop-procedure failure.
- Employment or vendor offboarding reveals lingering access.
When a trigger fires, return to lab status until the four owners sign again. Do not treat last quarter’s approval as permission for this quarter’s connector.
Evidence the technical owner should attach
Borrow the launch tests from the Atlanta Claude Enterprise governance hub and the live Claude Enterprise deployment runbook: sign-in and denial tests, folder boundary checks, disabled-capability checks, and a sample monitoring event. Attach results rather than asserting that “controls are on.”
For connector-backed workflows, require the separate read-only and write gates described in the Nashville expansion companion before approval. Workflow approval without those tests is paperwork, not readiness.
Handoff that survives the first absence
Write the handoff for the week the technical owner is out:
- Where the approval record lives.
- Who covers output review.
- Who can disable the workflow.
- Which ticket queue receives stop reports.
If those answers depend on one person’s memory, the workflow is not ready to scale.
Quick answers
How is a workflow approval different from an AUP?
An AUP sets standing rules for everyone in scope. A workflow approval decides whether a specific workflow may go live, for whom, with what evidence.
Which owners belong on every request?
Technical owner, output reviewer, records owner, and risk or lawyer approver. If any role is missing, the workflow stays in lab status.
What reopens an approval?
Untested vendor capabilities, population expansion, information-class changes, monitoring failures, near-misses, or lingering access after offboarding.
When should approval be refused?
Refuse or defer when restricted data lacks intake documentation, monitoring evidence is missing, output review is unnamed, or nobody can stop the workflow quickly.
Close with a clear no
Refuse or defer approval when restricted data is in scope without intake documentation, when monitoring evidence is missing, when output review is unnamed, or when nobody can stop the workflow quickly. Record the refusal reason. A delayed yes is better than an undefended rollout.
Raleigh-Durham and broader North Carolina buyers should ask advisors to show the completed approval record for a comparable pilot before buying a wide enablement project. Agree on advisory versus hands-on responsibilities before configuration work starts.
For a starting point, request the free AI Readiness Snapshot. It makes no changes to your environment and requires no software installation. Use the findings to see which workflows are ready for a formal approval conversation and which still lack owners or evidence.
