Skip to content
A broad charcoal passage separates clay, sage and ochre pastel impressions with irregular painted boundaries.

Governance and policyArticle

What should legal and risk teams review before a new workflow launches?

Prepare an AI workflow for legal and risk review with its information path, output consequences, control evidence and unresolved launch decisions.

Jump to a section

Legal and risk teams need a specific proposed workflow, the evidence behind its controls and a clear decision to make before launch. Show what information enters, which services process it, who receives the output and what happens when someone relies on it. Identify affected people, applicable obligations and the questions that remain unresolved.

Start that conversation while the design can still change. A service on an approved-tool list may have been assessed for a different task, account, data category or audience. Equally, an existing approved pattern may already cover the proposal. The useful question is what permission and evidence apply to this use.

This is preparation for the company's review process. The tools and workflows guide connects it to system choice and operating ownership. The aim here is to make a proposed use assessable, rather than ask reviewers to approve an unspecified “AI assistant.”

Define the launch you are asking to approve

Suppose Jamie Lee manages customer service at a commercial linen-delivery company. Advisers answer messages about missing towels and bedding. They compare the customer's account with delivery records and service terms, then explain the discrepancy or refer a disputed credit to the responsible manager.

Jamie proposes an AI assistant that drafts a shortage reply using those records. An adviser would check the quantities and relevant terms against the originals before sending a response through the ordinary service process. The proposed assistant cannot send email, issue credit or change a delivery route.

The company already permits its chosen work service to help rewrite public brochure descriptions. That earlier permission does not establish whether customer messages and service agreements may be processed through the proposed connection.

One approved service, two different uses

Existing permission

Public brochure wording

The work service is approved for rewriting public descriptions. That is the scope already assessed.

New proposal

Customer shortage replies

Customer messages, delivery records and service terms introduce a processing route that still needs review.

In Jamie’s example, permission for public material does not authorize the proposed customer-information use. Automatic sending, credits and route changes are outside the drafting proposal.

Bring the assessed service and account, proposed connection, participating staff, information categories and intended output together. Name the launch boundary explicitly: a rehearsal with synthetic records, a limited customer-data trial and an operating service are different requests.

NIST's voluntary AI Risk Management Framework 1.0 makes context, intended use and potential impacts central to risk assessment. Its functions are not a prescribed checklist or sequence. The current site also notes that a revision is in progress. Use the framework to improve the questions, without presenting a completed form as legal clearance.

Ask the existing policy owner whether a reviewed pattern covers Jamie's proposal. If it does, retain that reference and demonstrate that its conditions fit. If it does not, identify the difference that needs assessment. The employee AI policy guide explains the underlying permission boundary.

Trace the information beyond the prompt

A description such as “the assistant reads customer emails” hides several important facts. A message may contain a contact's name, an attachment, negotiated commercial terms or information about somebody unrelated to the shortage. The delivery extract may expose other customers if the connection is too broad.

For Jamie's proposal, trace the information from the original record to retrieval, the model service, any stored working copy and the draft. Include logs, support access, exports and downstream systems where they actually exist. Have the technical owner distinguish a demonstrated configuration from a supplier statement or an unanswered question.

A practitioner account illustrates why this detail matters. In an October 2026 Reddit discussion about internal AI assessments, a commenter described repeatedly having to chase business teams to discover whether a proposed tool exported information to another system. The account is unverified, but the missing fact is concrete: reviewers cannot assess a destination nobody has named.

Use an approved synthetic shortage message and delivery record to show the path. Ask what would happen if the message included an unnecessary attachment or the wrong customer's reference. The rehearsal should reveal what the proposed arrangement does; it does not authorize uploading real records while their use remains unresolved.

Keep unknowns visible. If the team cannot explain a provider's retention arrangement, write the question and the owner who will resolve it. Do not turn “we have asked the supplier” into “the supplier deletes everything.” The vendor-evaluation guide helps separate applicable agreements, assurances and observed behavior.

Record where relevant people and processing are located, which customer relationships are involved and who can provide the governing agreements. Legal and privacy specialists need those facts to identify applicable requirements. A generic global compliance label cannot supply them.

Connect each concern to evidence and authority

A list of risks is a starting point. Reviewers need to know how a problem could arise in this workflow, who might be affected and what evidence supports the proposed response.

Jamie can prepare a short working table with the responsible specialists:

Review questionEvidence to bringDecision to resolve
May this customer information enter the proposed service?
Actual data categories, processing path and applicable agreements
Permitted processing scope and any necessary assessment or change
Could a reply misstate the shortage or service terms?
Representative drafts beside their original records, including failures
Required checking and which disputed cases stay with a person
Can the assistant reach another account or produce an external effect?
Demonstration of the connection's access and available actions
Necessary restrictions before the proposed use starts
Can the service be supported when something goes wrong?
Named owner, escalation route and ordinary manual process
Conditions for pausing the affected work and handling it safely

These are preparation questions, not four universal approval tests. Add the issues the actual workflow introduces. Information rights, confidentiality, contractual promises, misleading communications or sector-specific duties need the relevant owner's assessment; they should not be averaged into a favorable overall score.

The UK's Information Commissioner's Office AI accountability guidance describes assessing the particular processing, its effects on people and the need for a data protection impact assessment. Checked in October 2026, this guidance is under review following the Data (Use and Access) Act. Have the responsible privacy and legal owners establish the applicable assessment and any consultation before the affected processing begins. UK guidance does not determine obligations in every country.

An internal launch brief can help those owners understand the facts. It cannot replace a required assessment, consultation or agreement. Nor can a manager's willingness to accept commercial risk waive an applicable legal requirement.

Keep evidence attached to the question it answers. A successful response test does not establish that customer terms permit the processing. A supplier agreement does not demonstrate that a connection is restricted to Jamie's intended records. Both findings can matter without being interchangeable.

Show how review works before an output is used

“An adviser reviews the reply” needs an operating description. Can the adviser see the customer's request, the delivery quantities and the applicable term? Can they reject the draft, correct it and refer a dispute to someone with the right authority? What happens when they are unavailable?

Privacy and AI-governance adviser Gayanthi Gunawardhana makes this distinction tangible in an October 2026 contracting analysis. Her hypothetical describes a service specification promising employee review while a technical schedule permits automatic sending after a timeout. It is an illustrative mismatch, not a reported bank incident. A reviewer needs the arrangement that will actually operate, rather than two incompatible descriptions.

For Jamie's proposal, an unavailable adviser means the draft remains unsent. The customer request continues through the established service process. Show that behavior in the rehearsal, together with an ordinary approved draft and a refusal to use an unsupported answer.

Bring failure examples too. A fluent reply might use the wrong delivery date, overlook a partial delivery or promise a credit the adviser cannot authorize. Define those meaningful checks before treating a successful demonstration as sufficient. The output-quality guide explains how to specify task requirements and distinguish the severity of errors.

If a later proposal gives the assistant authority to send messages or alter accounts, it introduces another effect to assess. Use the agent-action approval guide for the implementation questions. The earlier drafting review should not silently authorize that expansion.

Record the permitted scope and the conditions that remain

End the review with a decision someone can apply. State the assessed workflow, service configuration, allowed information and users, required controls, operating owner and the authority under which the decision was made. Link to the evidence and its limitations.

Separate conditions that must be completed before launch from work that is permitted to continue afterward. “Privacy review pending” is too vague if one team reads it as a prohibition and another reads it as a minor follow-up.

For example, reviewers might permit Jamie to rehearse public or synthetic records through an already approved route while withholding permission for real customer messages until the processing arrangement is resolved. That narrower activity needs its own valid permission; calling it a pilot does not create one. If the unresolved issue also affects the rehearsal, that work waits too.

A practical record should make the next handoff clear:

  • Unresolved question. Which specific fact, obligation or control remains uncertain?
  • Affected scope. What cannot begin or expand until it is resolved?
  • Owner and evidence. Who can supply the answer, and who can make the resulting decision?
  • Operating instruction. What should staff do in the meantime, and where is the final decision kept?

Avoid inventing a new committee when the company's existing authority can handle the question. A repeatable approved pattern can reduce repeated work, provided the proposed use meets its conditions. Higher consequences, a new processing purpose or an unexplained dependency may need a different route. A fixed turnaround promise does not resolve missing evidence.

Keep review triggers with the decision. A new source collection, customer group, provider, output destination or automatic action can change what was assessed even when the product name stays the same. Name the owner who will bring such changes back through the appropriate route. Keep a usable manual process for the affected work while the question is resolved.

Does an approved AI tool mean our new workflow is approved?

Only if the existing permission covers the proposed task, account, information, users and effects. An approved public-writing use does not establish permission to process customer records or send messages automatically. Compare the proposal with the actual approval and ask its owner to resolve material differences. The two-use example shows why the service name alone is insufficient.

Does every AI workflow need a full data protection impact assessment?

The requirement depends on the applicable regime and the actual processing, rather than the AI label alone. Have the responsible privacy and legal owners establish the trigger, document their assessment and complete any required process before the affected use begins. A short intake form or a low internal risk rating does not replace a required assessment. The review-question table helps prepare the facts those owners need.

Who should own the launch review?

Name a business owner who can explain the proposed work and an accountable route for coordinating its review. Legal, privacy, security, procurement and operational specialists resolve matters within their authority; one participant should not be assumed to approve every aspect. Record who supplies missing evidence and who makes the relevant decision. Use the company's established route where it fits, with clear responsibility for communicating the result to staff.

Only within a scope that is already permitted and does not depend on the unresolved question. A synthetic-record rehearsal may be possible when real customer-data processing is not, but its service, inputs and activity still need valid permission. Identify the affected scope explicitly and keep it on hold until the responsible owner resolves the condition. The decision record should prevent different teams from interpreting “pending” differently.

When should a reviewed workflow return for assessment?

Return when a change could invalidate a material assumption, permission or control behind the decision. Examples include new information, another audience or destination, a different provider, or moving from checked drafts to automatic action. Keep the original assessed scope and a named operating owner so these changes are recognizable. Ask that owner to arrange the appropriate review before the affected expansion, rather than assuming an unchanged product name preserves approval.

Updated

aiready

A home for your company’s AI community.

Share what works and help each other put AI into practice.

  • Real use cases

  • Practical guides

  • Company policies

  • Shared experience

Explore aiready
Explore the blog