An AI Policy Starts With Data Handling

An AI policy often begins with a list of names. ChatGPT: yes or no. Copilot: yes or no. Some other tool with an unusually cheerful gradient: perhaps, pending a meeting.

The list feels concrete because it has logos on it. It is also the part most likely to age badly. Products change, features change, contracts change, and the same model can be harmless in one workflow and consequential in another.

The better opening question is not Which AI tool is allowed? It is What is this workflow allowed to receive, produce, decide, and leave behind?

That shift matters because the useful unit of governance is not the model or the vendor. It is the workflow: the specific path through which information enters, is processed, becomes an output, and sometimes turns into a business action.

1. What data may enter this workflow?

“Can we use AI for this?” is usually shorthand for a more precise question: may this particular information enter this particular workflow?

A generic event invitation is not a customer contract. A public product description is not a spreadsheet of employee compensation. A list of meeting topics is not a support ticket history. Good policy gives people a usable way to recognize those differences: public information, ordinary internal work, confidential business material, regulated data, and information governed by a customer or partner commitment.

The important detail is not merely whether a provider says it has strong security. It is whether the proposed use fits the organization’s rules for that kind of information. NIST’s Privacy Framework is useful here because it treats privacy as enterprise risk management and includes the data-processing ecosystem: the other entities, services, and relationships involved when information moves through a business process.

Start by writing down the permitted inputs for each approved workflow. A marketing brainstorming assistant may accept public material and approved internal copy. A workflow intended to summarize a customer record may require an entirely different review. The point is not to produce a classification taxonomy so grand that no one uses it. It is to prevent a familiar shortcut from becoming an unexamined data route.

2. What may the workflow produce or decide without human review?

AI systems can draft, sort, summarize, recommend, route, and increasingly initiate actions. Those verbs deserve different rules.

A draft may be useful precisely because a person will revise it. A recommendation may be useful because a person will weigh it against context the system cannot see. A message to a customer, a change to a record, a purchasing decision, a security response, or an employment-related decision deserves a more deliberate boundary.

One practical policy question is: What is the last point at which a person must review this before it changes the organization’s position? The answer may vary by workflow. A tool may create a first-pass meeting summary without a formal gate. It should not quietly send a customer commitment, alter a system of record, or decide an exception because its prose sounds confident.

NIST’s generative-AI profile and AI Risk Management Framework both emphasize that organizations must adapt risk management to their own context and risk tolerance. That is not an invitation to vague caution. It is a reason to name the decision boundary clearly enough that an employee knows when an assistant is helping and when it is substituting for accountable judgment.

3. What new record, retention, and customer-commitment obligations does it create?

Every new workflow has an afterlife. It may create prompts, uploads, logs, generated files, audit records, drafts, and copies in connected business systems. It may also create a promise—explicit or implied—about how customer information is handled, how long it remains available, or what happens when someone asks for it to be corrected or removed.

People often ask one narrow question: whether a model trains on their data. That can matter, but it is not the whole record question. The broader question is: if this interaction matters six months from now, where is the record, who can retrieve it, what retention rule applies, and what agreement governs it?

This is where a policy becomes operational rather than decorative. Before approving a workflow, identify its record owners and its retention setting. Check whether it changes a customer commitment. Decide whether the output needs to be preserved, reviewed, or routinely deleted. An organization does not need a committee for every prompt; it does need someone able to answer these questions for the workflows that matter.

One brief example

A connected application can be a useful illustration, but it is not the center of the story. If a workflow reads a project folder and produces a summary, the policy questions are still the same: what files may enter, whether anyone checks the summary before it is used, and what new copy or record exists afterward. The connection is simply where those decisions become visible.

Tool lists will keep changing. The three questions will not. They give an organization a way to evaluate the next product without pretending that a logo is a governance model.