Your employees are already using artificial intelligence (“AI”) at work, whether you have approved it or not. The question is not whether to allow it but whether you have written rules that keep ordinary, well-meaning use from quietly damaging the company. An AI acceptable use policy is that set of rules: which tools employees may use, what information they may put into them, who checks the output, and what happens when someone gets it wrong. Without one, a single paste of a confidential document into a free chatbot can undercut the legal protection around your most valuable information. In my practice advising business owners, the gap between how fast employees adopt these tools and how slowly companies write rules for them is one of the widest I see, and it sits squarely in your company’s day-to-day operations and the legal exposure they create.

What is an AI acceptable use policy, and why does your business need one?

An AI acceptable use policy is the internal rulebook that governs how your company uses AI tools: which tools are approved, what data may be entered into them, how employees must verify the output, and how the rules are enforced. It is not a public statement or a marketing document. It is an operating control, in the same family as your confidentiality agreement and your written workplace policies, and it exists to keep routine use from creating legal harm.

The reason a Minnesota business needs one is concrete. Two bodies of law turn on choices your employees make every day inside these tools. Trade-secret protection depends on whether you guarded the secret, and Minnesota’s privacy law imposes duties on how you handle personal data. A public AI tool can defeat both at once: it can strip information of its trade-secret status and put you crosswise with your data-security obligations in the same keystroke. A written policy is how you keep the people doing real work from triggering either outcome by accident.

Which AI tools should the policy approve, and which should it keep out?

The policy should name an approved-tools list and treat everything off the list as prohibited until reviewed. The deciding factor is not the tool’s brand or popularity. It is whether the vendor is contractually bound to keep your data confidential and out of model training. An enterprise account governed by a signed agreement that says your inputs will not train the vendor’s models, and will not be shared, sits in a different legal world from the same vendor’s free consumer version.

Free public tools generally reserve broad rights to use what users type in, including to improve their models, and they make no confidentiality promise to your business. That is the category to keep sensitive work out of. The most dangerous tool is the one no one approved at all: shadow AI, the personal accounts employees sign up for on their own. The policy should make clear that only approved tools handle company information, give employees a fast way to request a new tool, and put someone in charge of vetting requests. When you negotiate an enterprise agreement, the contract language that limits how a vendor uses your data to train its models is the clause that does the protective work.

What data must never go into a public AI tool?

Three categories of information must stay out of any public AI tool, and the policy should name them in plain words. First, trade secrets and confidential business information: pricing models, customer lists, formulas, source code, strategic plans, and anything that gives you an edge because competitors do not have it. Second, client-confidential and privileged material: anything you hold under a duty of confidentiality to someone else. Third, regulated personal data, which Minnesota law defines broadly as “any information that is linked or reasonably linkable to an identified or identifiable natural person.” (Minn. Stat. § 325M.11.)

Within personal data, one subset warrants a hard stop. Minnesota’s privacy law singles out “sensitive data,” which includes information revealing a person’s racial or ethnic origin, religious beliefs, mental or physical health condition or diagnosis, sexual orientation, or citizenship or immigration status, along with biometric and genetic data used to uniquely identify someone, the personal data of a known child, and precise geolocation. (See Minn. Stat. § 325M.11.) Health records, fingerprints, and similar information carry their own consent rules, covered below, and they have no business in a consumer chatbot. If your work touches fingerprints, retina scans, or similar identifiers, Minnesota’s rules on biometric data add a further layer. A short, specific list of forbidden inputs is worth more than a paragraph of caution, because employees follow rules they can remember.

How can putting confidential information into AI defeat your trade-secret protection?

Minnesota trade-secret law protects information only when its owner works to keep it secret, and a careless AI disclosure can erase that protection. Under the Minnesota Uniform Trade Secrets Act (“MUTSA”), a trade secret must be “the subject of efforts that are reasonable under the circumstances to maintain its secrecy.” (Minn. Stat. § 325C.01, subd. 5.) The same information must also derive economic value from “not being generally known” and “not being readily ascertainable by proper means.” When an employee feeds that information into a public tool that trains on inputs or owes your company no confidentiality, you weaken the reasonable-efforts element and risk that the information is no longer kept from others, which is the whole basis of the protection.

This is not a theoretical risk. Where a company fails to guard its information, the secrecy element alone can defeat a trade-secret claim, because information the owner did not work to keep secret is not a trade secret in the first place. The protection reaches only what the owner actually protects. The federal track runs in parallel: the Defend Trade Secrets Act lets an owner sue when a misappropriated secret is “related to a product or service used in, or intended for use in, interstate or foreign commerce.” (18 U.S.C. § 1836(b)(1).) Its definition of a protectable secret sets the same condition Minnesota does, requiring that “the owner thereof has taken reasonable measures to keep such information secret.” (18 U.S.C. § 1839(3).) An AI policy that keeps confidential information inside governed tools is part of the reasonable-efforts story you will tell a court if a dispute ever arises. For the foundation, see what legally counts as a trade secret in Minnesota and the reasonable measures Minnesota courts expect.

What privacy-law duties does AI use create under Minnesota law?

If your company meets the thresholds of the Minnesota Consumer Data Privacy Act (“MCDPA”), AI use puts three specific duties in play, and an unvetted tool strains all three. The act, codified at Minn. Stat. § 325M.10 and the sections that follow, took effect July 31, 2025. It applies to companies that do business in Minnesota or target their products or services to Minnesota residents and that either control or process the personal data of 100,000 consumers or more, or derive over 25 percent of gross revenue from selling personal data while handling the data of at least 25,000 consumers. (See Minn. Stat. § 325M.12.) Several sectors already governed by federal law, including health data under HIPAA and financial data under the Gramm-Leach-Bliley Act, are excluded.

A company within the act is a “controller,” and three of its duties bear directly on AI use:

  • Limit what you collect. A controller “must limit the collection of personal data to what is adequate, relevant, and reasonably necessary” for the disclosed purpose. (Minn. Stat. § 325M.16, subd. 2.) Dumping a customer file into a tool to draft one email collects far more than the task needs.
  • Secure the data. A controller must “establish, implement, and maintain reasonable administrative, technical, and physical data security practices.” (Id.) Sending personal data to a tool with no contractual security commitment is hard to defend as reasonable.
  • Get consent for sensitive data. A controller “may not process sensitive data concerning a consumer without obtaining the consumer’s consent.” (Id.) Routing health or biometric information through a public tool ignores that step.

The Minnesota Attorney General enforces the act; there is no private lawsuit under it. (Minn. Stat. § 325M.20.) Even so, a data mishap can create personal exposure for leadership under other laws, which is why the policy is a leadership concern, not just an IT one. For the full picture of your duties under the Minnesota Consumer Data Privacy Act, map your data flows before you map your tools.

Why does the policy need a mandatory human-review rule for AI output?

Because AI tools produce confident, fluent text that is sometimes wrong, fabricated, or built on someone else’s protected work, the policy must require a competent human to verify every AI-assisted work product before anyone relies on it or sends it out. The tool is a drafting assistant, not an author of record, and the accountability for what leaves your company stays with the employee and the business.

The review rule should be specific about what verification means for each kind of output. A contract clause an AI drafted must be read against the actual deal. A statistic it produced must be traced to a real source. A customer-facing message must be checked for accuracy and tone. In my experience, the costliest AI errors are not exotic; they are ordinary mistakes that a quick human check would have caught, shipped because no one was assigned to look. Build the human checkpoint into the workflow, name who owns it, and treat skipping it as a policy violation in its own right. If you disclose AI use to the people you serve, the standards for disclosing AI use in your service contracts should match what your policy actually requires.

Who owns AI-assisted work, and what should the policy say about it?

AI-assisted work raises two ownership questions, and the policy should answer both. The first is whether you can own the output as copyright. Under the U.S. Copyright Office’s current practice, copyright protects only human-authored material, so work generated entirely by AI is not registrable, and in a mixed work only the human contributions are protected. Prompts alone generally do not make the user the author of the result. For anything you need to own and defend, the policy should require meaningful human authorship and a record of that human role.

The second question is contractual: what rights the tool’s own terms give you in what it produces. Vendor terms vary widely on who may use the output, whether you get exclusive rights, and what the vendor may do with your inputs. The policy should require employees to use only approved tools whose terms have been read, so that ownership is settled before the work matters rather than after. Ownership inside your company matters just as much: clear work-for-hire and IP-assignment terms in your employee and contractor agreements decide who holds the rights to what your team makes with these tools.

How do you roll the policy out so employees actually follow it?

A policy no one reads protects no one, so adoption is part of the policy, not an afterthought. The version that works is short and written in plain language, paired with role-specific training, because a marketing team and a finance team face different AI risks. Give employees an approved-tools list they can actually use for real work, a low-friction way to request new tools, and one named owner accountable for keeping the policy current as the tools change.

Training does double duty here. It makes the rules stick, and it is itself part of the legal showing the law rewards. The privacy statute asks for “reasonable” security practices, and trade-secret law asks for “reasonable” efforts to maintain secrecy; documented training that tells employees what to keep out of public tools is direct evidence that your efforts were reasonable. Companies that skip this step often discover the cost later. The pattern behind most of those failures is the same one behind what tends to go wrong when a company runs on unwritten procedures: the rule existed in someone’s head, not on the page, so no one followed it.

How should the policy handle enforcement and violations?

Enforcement turns the policy from paper into protection, so it must connect to consequences your company will actually apply. Tie the AI policy into your existing confidentiality obligations and discipline process rather than building a separate track. Define consequences that fit the breach, so an honest mistake and a deliberate disclosure are not treated alike. Set out an incident-response path for accidental disclosures, because the first thing employees need when something goes wrong is to know whom to tell, fast.

The policy should also reserve the company’s right to monitor AI use, within the limits Minnesota places on watching employees. (See the limits Minnesota places on monitoring employees.) Consistent enforcement matters beyond any single incident: a company that enforces its confidentiality rules unevenly weakens its claim that it took reasonable steps to protect its secrets, which is the same standard that decides whether an employee leaves with company data and whether you can do anything about it. Enforcing the AI policy is part of the broader work of how you protect confidential information without relying on a noncompete, and it is the part most companies forget until they need it.

Can employees put company data into ChatGPT?

Not without clear rules. Free public AI tools generally train on what users type in and owe your company no duty of confidentiality, so trade secrets, client-confidential material, and regulated personal data should never go into them. Approved enterprise accounts with a signed contract that bars training on your inputs are a different matter, and that distinction belongs in your policy.

Does using AI tools put our trade secrets at risk?

It can. Minnesota trade-secret protection depends on the owner making reasonable efforts to keep the information secret. Pasting confidential information into a public tool that trains on inputs or owes you no confidentiality undermines that element and can cost you the protection entirely. The risk is controllable through an AI policy and an approved-tools list, not a reason to avoid AI.

Is our small company covered by the Minnesota Consumer Data Privacy Act?

Only if you meet the statutory thresholds, which turn on how many consumers’ data you process and how much revenue comes from selling personal data. Many small businesses fall outside them, and several regulated sectors are excluded outright. Even when the act does not reach you, your trade-secret duties and contractual confidentiality promises still do, so the policy still earns its keep.

Do we have to tell clients we use AI?

No general Minnesota statute requires a blanket disclosure that your business uses AI. Your client contracts, professional or licensing obligations, and confidentiality promises may require it in specific situations, so the safe move is to check those documents rather than assume silence is fine. Some industries are moving toward disclosure as a norm even where no law compels it.

Should we ban AI entirely to stay safe?

Usually not. A blanket ban tends to push use underground, where employees adopt personal accounts you cannot see or govern. A short approved-tools list paired with clear rules on what data may go where protects the company better than a prohibition no one follows. The goal is governed use, not no use.

What if an employee already pasted sensitive data into a public AI tool?

Treat it as a data incident. Identify exactly what was disclosed and to which tool, follow your data-security and breach-response steps, and reassess whether the information still qualifies as a protected trade secret. Document what you did, because consistent incident response is part of the reasonable-security and reasonable-secrecy showing the law rewards.

A good AI acceptable use policy does something simple and valuable: it lets your team use powerful tools without trading away the legal protections that make your information yours. It keeps trade secrets inside governed tools so they stay secret, keeps regulated personal data out of places it does not belong, puts a human between AI output and the outside world, and gives you a record that your efforts were reasonable if anyone ever asks. The two laws that make this matter, Minnesota’s trade-secret act and its consumer data privacy act, both reward businesses that act before a problem arises and penalize those that do not. If you would like a second set of eyes on a draft AI policy or on how these rules apply to your specific data, email [email protected] with a short description of how your team is using these tools. You can find more on managing risk in your daily operations through our operations practice.