When a workflow handles sensitive client, employee, or business information, the design needs to control what the system can read, what it can change, and who approves the result. Model instructions alone cannot provide those controls.
The patterns below are practical design requirements for a scoped project. They do not establish legal or regulatory compliance. Your business and its qualified advisers must determine applicable obligations, permitted data use, contracts, retention, and professional-review requirements. An AI workflow should not silently take responsibility for clinical, legal, employment, or other consequential professional decisions.
Set the workflow boundary first
Document the business purpose, data categories, authorized users, allowed sources, possible actions, recipients, and failure path. Review provider terms, processing locations where relevant, subprocessors, retention, training-use terms, and the actual deployment configuration before using sensitive information. Do not infer these properties from a generic product label.
The NIST AI Risk Management Framework supports documenting and managing AI risk throughout use. The controls below are an applied design approach, not a claim of certification under that framework.
Pattern 1: permission-aware retrieval
Use this when the system answers questions from internal records. Authenticate the requester, apply source authorization before retrieval results reach the model, and preserve source identifiers for verification. A restricted document should not become available because it was copied into a different index.
Test cross-role requests, revoked access, stale permissions, deleted sources, and cache reuse. Do not expose restricted content through document titles, citations, search previews, or debugging responses. If permissions cannot be evaluated, stop that retrieval path.
Treat retrieved text and uploaded files as untrusted information, not instructions that grant authority. OWASP's prompt-injection guidance addresses attacks through both direct prompts and external content; a “follow the rules” prompt is not a complete defense.
Pattern 2: draft, verify, and approve
Use this when the system prepares a client update, summary, or proposed response. Separate the generated draft from the approved record. Show the reviewer the supporting material, uncertainty, recipients, and any proposed attachments.
Record approval of the exact content and recipient set. Editing the draft or changing recipients after approval should require reapproval. Set escalation rules for missing facts, disputed sources, and content that needs professional review.
At execution, recheck the requester's authority and the relevant record state; approval should expire or require renewal when those conditions change. Approval of yesterday's draft must not authorize today's different action merely because the case number is unchanged.
For example, an administrative client-status update can be drafted from approved case notes, checked by the responsible employee, and released through a controlled send action. The workflow should not invent advice, decide a deadline, or treat a model-generated assertion as a verified case fact.
Pattern 3: constrain actions outside the model
Use this when an approved workflow updates a CRM, creates a ticket, or sends a message. The application—not the model—should enforce allowed operations, field rules, recipient restrictions, user authority, and approval requirements.
Scroll horizontally to compare all columns.
| Control | Example implementation requirement |
|---|---|
| Least authority | A task-specific identity can create an approved ticket, not administer the whole system |
| Input validation | Required fields and allowed values are checked before the action |
| Recipient/resource checks | The approved business record determines destination; free-form model text cannot redirect it |
| Approval binding | The approved action, payload, and destination are checked at execution time |
| Duplicate prevention | Concurrency-safe operation tracking, destination idempotency where supported, and uncertain-outcome reconciliation |
| Limits | Volume, cost, and action scope are bounded by the application |
Test refusal and bypass cases. A working happy-path demonstration does not prove that a model cannot request an unauthorized operation.
An operation ID and a separate “does this exist?” check are not sufficient protection against simultaneous retries. Use a concurrency-safe claim or unique operation record and the destination's idempotency capability where available, tied to the approved payload. If the destination provides no reliable duplicate protection and the previous outcome is uncertain, reconcile it or require operator review before repeating a consequential action. Do not claim universal exactly-once execution across external systems.
Pattern 4: fail into a controlled work queue
Use this when information is incomplete, a reviewer is unavailable, an integration times out, or a downstream action has an uncertain result.
The workflow should preserve the case state, explain the limitation to an authorized operator, and avoid claiming success without confirmation. Before retrying a write, reconcile whether the first attempt succeeded. A timeout does not prove that nothing happened.
Bound retries and send unresolved cases to a named owner. Provide a manual processing route and an authorized stop control. Restoring an earlier application version is not enough if a previous action already changed an external system; define how those effects are reconciled.
Pattern 5: retain a useful, minimal audit record
Record enough to understand a decision without building an unnecessary archive of sensitive prompts and documents.
Scroll horizontally to compare all columns.
| Field | Purpose |
|---|---|
| Operation/case identifier | Connect related processing steps and detect duplicates |
| Requesting identity and authorization result | Explain who requested the work and whether access was allowed |
| Source identifiers/versions where appropriate | Support investigation of the information used |
| Workflow/model/configuration version | Identify which implementation produced the result |
| Approval reference and action summary | Connect reviewed content to the executed action |
| Outcome, timestamp, and exception reference | Support reconciliation and follow-up |
Where approved, use redacted summaries or references to access-controlled records instead of copying full content. Set retention, deletion, access, and any legal-hold handling with the responsible advisers. Hashes and identifiers are not automatically anonymous and still need appropriate handling.
Restrict access to audit records and protect them against unauthorized modification. Record missing logging or failed evidence capture as an operational exception, with a defined rule for pausing actions that require that evidence.
Test the complete workflow before expansion
Run representative normal cases plus unauthorized access, malicious source instructions, changed content after approval, wrong-recipient attempts, unavailable reviewers, duplicate requests, partial failures, and permission revocation. Use approved synthetic data for adversarial tests where possible.
Define stop conditions and a release approver. Serious disclosure, unauthorized action, or an unreliable approval boundary should block expansion, even if average output quality is high. Repeat relevant tests after changing sources, models, connectors, permissions, or available actions.
Common questions
Does a human approval step make the workflow safe?
Not by itself. Reviewers need enough information and time to check the result, and the executed action must match what they approved. A rubber-stamp button is not effective oversight.
Can we use these patterns with an off-the-shelf tool?
Yes, as evaluation requirements. Verify which controls the product actually supports and which your team must provide. If a critical boundary cannot be enforced, narrow the use case or choose a different approach.
Define the boundaries before choosing the platform
Contact Us About a Governed AI Workflow with the task, systems involved, and approval requirements—without sensitive records. If those boundaries are not yet defined, explore AI readiness and roadmap services.