An effective AI policy is a set of decisions, specific to your company, about which categories of information may be processed by which tools under which terms, written into the instruments that already govern your commitments: employment agreements, customer and supplier contracts, privacy representations, technical controls, and incident response. Two companies with the same headcount and the same software can need very different policies, because the right policy is a function of two things a template cannot know: the commitments you have already made, and the categories of information you actually handle. A generic framework is a workable starting point only if you treat it as a list of questions rather than a set of answers. Adopted unedited, it creates a written record of controls you are not following, and that record is discoverable. The same effort, pointed at your actual commitments and data, produces a policy the company can follow, defend, and use to say yes quickly to the AI that fits.

This article is part of our series on AI, confidentiality, and the law. Our separate articles set out the attorney’s professional-responsibility framework and explain how routine consumer AI use can breach commitments a business has already made; further articles will take up the litigation lifecycle of AI prompts and outputs and the intellectual property questions. This one is the operational piece: how to build the policy. The audience is company management and in-house counsel. It assumes you accept that consumer AI use puts existing commitments in play and are ready to build, whether by adapting a generic framework or drafting from scratch. Either way the work is the same set of questions about how your company actually operates.

I. There Is No One-Size-Fits-All AI Policy

When the board asks for an AI policy, the instinct is to find a good template, change the names, and call it adopted. The template is where the work begins. A policy that protects one company can leave the company next door exposed, because the policy that works is determined by two variables no template can supply.

The first is the set of commitments the company has already made. Customer contracts warrant how data is handled and who may touch it. Regulatory filings and privacy notices represent what the company does. Employment agreements and confidentiality covenants define what the workforce may disclose. Nondisclosure agreements and protective orders bind specific information to specific uses. Every one of these is a promise that an AI tool can break, and the set of promises is different at every company.

The second is the categories of information the company actually handles. A company that processes protected health information, regulated financial data, unfiled patent matter, or material nonpublic information needs controls that a marketing agency producing public copy does not. The policy has to be built around the most sensitive category the company touches, not the average one, because a single misrouted prompt is judged by what it contained.

The law is not uniform, and it is not static. A policy pinned to one regime breaks the moment the company crosses a border or a statute moves. Colorado is the live illustration: its Artificial Intelligence Act, the first comprehensive state AI statute, was set to take effect in February 2026, then pushed to June 2026, then stayed by a federal court, then repealed and replaced by a narrower notice-based statute whose own enforcement waits on rulemaking and the same litigation, all within a single year.[1] California’s automated decisionmaking rules took effect on the same timeline. The volatility has a named federal driver: a December 2025 executive order directs the Department of Justice to challenge state AI laws in court, and the Department intervened against Colorado’s statute within months.[2] The footprint question also crosses borders: the EU AI Act reaches companies outside the Union when their systems or outputs are used within it, with obligations phasing in through 2027.[3] A policy that does not account for where the company operates, and that no one revisits, is wrong within a year.

The common deficiency is to begin with a list of approved tools. The best practice is to begin with a map: what have we promised, and what information do we hold. The approved-tool list is the last step in that analysis, not the first.

The map starts as a self-evaluation, specific to your context. Most of the policy falls out of honest answers to a short list of questions:

• Where is an LLM likely to touch our work? Marketing copy, code, client work product, operational reporting, and internal analysis each carry a different risk profile, and the policy should follow the actual uses rather than a generic list.
• What data would each use expose, and where are the risks? Identify the categories in play, from public marketing material to PHI, client confidences, trade secrets, and material nonpublic information, and let the most sensitive category a use touches govern that use.
• What have we promised, and where? Customer contracts, privacy notices, regulatory filings, NDAs, and protective orders each contain commitments an AI tool can put in play, and the inventory of those commitments is the spine of the policy.
• Is ownership or intellectual property an issue? The question runs in both directions: the rights to submit what goes in, and the protectability, inventorship, and infringement posture of what comes out.
• What are the known issues with the content and work product an LLM is likely to touch or generate? Accuracy, citation integrity, bias, and industry-specific disclosure duties set the review standard before output ships.
• How will quality control occur? Name who reviews AI-assisted work, against what standard, and at what point before it reaches a client, a regulator, or the public.
• What authorizations are required? Decide who approves a tool, a use, and an exception, and where customer or client consent is part of the answer.
• What secrecy programs or obligations bind us, our employees, or our customers? Trade-secret programs, professional duties of confidentiality, export controls, and government-information rules each impose requirements the policy has to carry.
• Where do we operate, sell, and employ? The footprint determines which AI regimes attach, at home and abroad.
• What AI use is occurring today, approved or not? The honest answer is the baseline the policy has to govern.

The sections that follow put these questions to each domain the policy has to reach.

II. Integrate, Do Not Append

The mechanism that makes a policy context-aware, and that keeps it alive, is integration. Employees follow the documents they already reference. They ignore a standalone AI policy that arrives once as an email attachment and is never opened again. Each domain that AI governance has to reach already has an instrument that governs it: the acceptable use policy signed on day one, the confidentiality covenant acknowledged annually, the master services agreement, the privacy policy, the security stack, the incident response plan. The work is to extend those instruments rather than to run a parallel compliance track beside them.

Integration also makes the policy inherit the company’s specific commitments. An AI rule written into the customer contract automatically reflects what that customer was promised. An AI rule written into the privacy policy is tested against what the company actually represents. A freestanding policy floats above all of that and connects to none of it. The five domains below are where the extension happens. Each is framed the same way: the failure that recurs, the questions that locate your company, then the fix.

III. Employment and HR

Most employment documents predate generative AI, and the gaps are predictable: confidentiality language that never names AI, discipline that treats AI misuse as a minor infraction, which tells employees the rule is advisory, and a single training module for a workforce whose AI questions differ by function. Each is fixable inside documents the company already maintains. There is also a blind spot worth naming: companies treat an HR AI tool as an internal-use question when it is also a privacy and an anti-discrimination question. Under California’s automated-decisionmaking rules, an automated hiring, promotion, or performance tool that makes a significant decision triggers pre-use notice, opt-out, and risk-assessment obligations, and the rules define “consumer” to include employees, applicants, and independent contractors.[4] New York City requires an independent bias audit and advance candidate notice before an automated employment decision tool is used, Illinois makes discriminatory effect from AI in employment decisions a civil rights violation and requires notice of AI use, and Colorado’s replacement framework adds notice and human-review rights for consequential employment decisions.[5] The HR tool is not one policy decision. It is three.

Start with an honest picture of current use:

• Which teams are using AI today, through which tools, on what categories of information, and how do you know? Usage data answers this faster than assumptions.
• Do the employment agreements, handbook, and confidentiality covenants name AI, or rely on generic language? The documents employees actually sign are where the rule has to live.
• Is any tool scoring, screening, ranking, or monitoring applicants or employees, and in which states do those people sit? Location determines which notice, audit, and opt-out obligations attach.
• Is discipline for AI misuse calibrated to other confidentiality violations? Consequences tell employees whether the rule is real.
• Does offboarding capture AI accounts and AI-generated work product? Departures are where unmanaged accounts surface.

The updates worth making now:

• Confidentiality provisions should name AI use, identify approved and prohibited tools by category of information rather than by vendor, and require escalation for sensitive matters. Whether generic language reaches AI use is a question a court answers after the dispute arrives; naming AI removes the question.
• Invention-assignment provisions should reach AI-assisted invention and require documentation that identifies human contribution with enough specificity to preserve inventorship.[6] The protectability analysis is in our separate article on AI and intellectual property.
• Acceptable use policies should require firm-managed accounts for any AI use touching company information, prohibit submission of named categories (PHI, customer data, trade secrets, export-controlled technical data, unfiled patent matter) to unapproved tools, and state consequences.
• Offboarding should treat AI artifacts the way it already treats documents and devices: export and deletion of AI-generated work product, termination of company AI access, and attestation about personal AI accounts that may have processed company information.

Training should match the categories each team actually handles, and discipline should sit at the same level as any other confidentiality violation.

IV. Customer and Supplier Contracts

The exposure here usually sits in existing contracts no one re-reads. A customer agreement signed in 2022, with a subprocessor list that names no AI vendor, is breached the moment an employee runs customer data through a consumer tool, whether or not the word “AI” appears anywhere in the document. The remediation is an inventory, and it is finite work: identify every contract with confidentiality, subprocessor, or data-residency provisions, and confirm that current AI practice is consistent with each.

The contract review asks:

• Can anyone produce the list of contracts containing confidentiality, subprocessor, audit, or data-residency provisions? If the list does not exist, building it is the first deliverable.
• For the largest customer relationships, what exactly was promised about who may process their data? Current practice either keeps the promise or gets conformed to it.
• Are suppliers and contractors bound to the restrictions the company has accepted upstream? Flow-down is how the company’s promises survive its supply chain.
• Who reviews the AI representations in new deals, and can the company verify what it is promising? Verification is what makes a representation safe to sign.

Integration runs both directions. Outbound, new customer contracts should describe AI processing accurately:

• Representations about the tools in use and how new ones are approved. Accuracy here is what makes the rest of the contract performable.
• Flow-down provisions binding AI subprocessors to the confidentiality the customer expects. The customer’s protection should not dilute as the data moves downstream.
• Training-use restrictions tied explicitly to the no-training commitment in the upstream vendor agreement. The promise made to the customer should mirror the promise received from the vendor.
• Audit rights with practical verification mechanisms, such as vendor certifications, SOC reports, and technical attestations. A right the company can actually exercise is worth negotiating for.
• Data-residency terms that match what the customer was promised. Confirm tool architecture before signature.
• Indemnification addressing AI-specific risk. Allocate it deliberately rather than by silence.

Inbound, supplier contracts should flow down whatever the company has committed upstream. Many pre-2024 contracts already capture AI use through broad subprocessor or confidentiality language even though AI is unnamed; the question is whether the company has confirmed that or merely hopes so. For federal contractors, safeguarding and flow-down clauses in government contracts already reach AI processing of government and controlled information, and AI-specific clauses are in rulemaking, so approved-tool decisions are also compliance decisions under those contracts.[7]

V. Public Representations: Privacy Policy and Website Terms

These are where regulatory exposure crystallizes, because they are public and enforceable, by regulators and under state consumer-protection law.[8]

These documents fail in one of two ways: silence, or its mirror image, overstatement. A policy that says nothing about AI processing that actually occurs is an omission a regulator can charge as deceptive where the processing is material, and AI processing of personal data usually is. A policy that promises controls the company does not maintain is a misrepresentation by assertion, and a discoverable one. The operational test is simple to state and uncomfortable to apply: the policy must match actual practice. If practice exceeds the policy, fix the policy. If the policy exceeds practice, fix the practice. Kept current, the public story becomes an asset: customers and regulators read a precise privacy policy as evidence of a company in control of its data.

The disclosure review asks:

• Does the privacy policy disclose the AI processing that actually occurs, including AI features inside software already deployed? Embedded features are the ones most often missed.
• Does it promise any control the company does not maintain? Every promise should have an owner who can demonstrate it.
• Do the privacy policy, security marketing, and regulatory filings tell the same story? One consistent story is easier to maintain and easier to defend.
• Where does the company automate decisions significant enough to trigger notice and opt-out rights, and for whom, counting employees and applicants? The answer sets the disclosure and rights architecture.

Brought current, the privacy policy addresses:

• The categories of personal data processed by AI and the categories of AI subprocessors. A generic reference to “service providers” no longer carries the weight under modern state regimes.
• The legal bases for processing, stated per purpose. AI features often add purposes to data the company already holds.
• The consumer rights affected, including the access and opt-out rights that attach where a significant decision is automated. Rights language should match what the company can operationalize.
• Consistency with the company’s other filings, including SEC cybersecurity disclosures, HIPAA Notices of Privacy Practices, and sector-specific notices. A regulator will read them together, and the story should be one story.

VI. Technical and Procurement Controls

Policy language does its work only when the environment supports it. A rule that says “do not paste confidential data into ChatGPT,” with nothing in the environment that stops it, will be broken by the first employee in a hurry. The controls below are standard equipment in most environments; the work is pointing them at the policy’s categories.

Ask what the environment actually enforces:

• What actually stops an employee in a hurry: a control, or a sentence in a policy? Controls carry the load when attention lapses.
• Which categories of information does the company hold, and which is the most sensitive category each approved tool touches? Tools are approved for categories, and the mapping is the approval.
• For each approved tool, what do the contract terms say about training, retention, and access, and who has verified them? Verification turns the vendor’s promise into the company’s answer.
• Who has authority to reject a tool for a category of information, and does that authority hold when the business wants the tool? Decide the answer in advance; it is a governance design choice.

The controls that make the policy real:

• Data loss prevention matched to the confidentiality categories defined in the acceptable use policy. The same categories do double duty in the policy and in the tooling.
• Network-level blocks for unapproved consumer AI endpoints, with exceptions managed through IT. A working exception process is what keeps the block credible.
• Single sign-on, multi-factor authentication, conditional access, and audit logging for approved tools. Logging is also what makes incident response and discovery answerable.
• Endpoint and mobile-device-management controls that prevent installation of unapproved AI applications, including on BYOD devices. Personal devices are where approved-tool rules most often leak.

Procurement is where tool selection actually belongs, and the question is not which AI is best but whether a given tool’s contract honors the commitments that a given category of information triggers. Our separate articles on professional responsibility and on consumer AI use develop the analysis; the short version is that three contractual terms control fitness for any category of information: whether the vendor trains on the data, how long it retains the data, and who may access it. Tier labels and brand names are proxies for those terms, and unreliable ones. The OpenAI copyright litigation makes the point concrete, with a caution. The 2025 preservation order reached consumer ChatGPT logs; Enterprise accounts and zero-retention API use sat outside it because their contractual and architectural terms differed; and the 20-million-log sample the court later ordered produced was drawn from the consumer population. Contract terms determined which population was exposed. They do not immunize data from a discovery order, and the pending sanctions motion alleging that the vendor misrepresented its own retention and search capabilities is the reason to negotiate audit and litigation-hold cooperation rights rather than rest on tier labels.

Vendor diligence should ask the AI-specific questions a generic security review omits:

• Training and opt-out mechanics. Confirm the default, the opt-out scope, and whether either differs by service tier.
• How long inputs and outputs persist, and who can shorten it.
• Access and subprocessor disclosure. Who can see the data, including the vendor’s own vendors.
• BAA availability and scope, where PHI is in play. Scope matters as much as availability.
• Breach-notification timelines that work with the company’s own notification obligations. The vendor’s clock has to fit inside the company’s.
• IP-infringement indemnification for outputs. Coverage terms vary widely by provider and tier.
• Data residency that matches the company’s own customer commitments. Geography promised downstream has to exist upstream.

Where a vendor will not commit to the terms a category of information requires, that vendor is not appropriate for that category. Where the company holds export-controlled technical data, tool access is also an export-control question: releasing controlled technology to a foreign person, including an employee inside the United States, is a deemed export, so infrastructure location, subprocessor staffing, and which employees may use which tool can each require a licensing analysis, and the government demonstrated in June 2026 that it will apply the framework to AI models themselves.[10]

Retention and litigation-hold architecture for prompts and outputs also belongs in this section: set when tools are configured and contracts are signed, it determines what the company can preserve, search, and produce when litigation arrives; our separate article on AI discovery develops the mechanics.[11] The controls also do affirmative work: a federal court has held that developing information through a consumer AI tool is a voluntary disclosure that extinguishes trade-secret status, which makes the DLP rules and network blocks part of the reasonable measures the company must prove when it asserts its own trade secrets.

VII. Incident Response

The goal is modest and buys a lot: when an AI incident arrives, the response should already have an owner and a privileged path. The existing incident response framework should extend to AI incidents rather than stand up a parallel one. The triggers are new; the mechanics are familiar.

• Unauthorized disclosure of confidential information through AI submission, by an employee or a contractor. This is the most common trigger, and the one the technical controls should surface first.
• Company confidential information or trade secrets surfacing in a third party’s AI output. Detection usually comes from the business side, so the escalation path should be known outside legal.
• A regulatory inquiry or civil discovery demand targeting AI use or AI-generated material (the discovery-side response is in our separate article on that topic). Preservation duties will already be running when it arrives.
• A vendor or AI-subprocessor breach affecting AI-processed data. Contract notification clocks start here, and the playbook should name who watches them.
• A policy violation requiring disclosure, mitigation, or discipline. Handled consistently, these are how the policy earns credibility.

Each category needs a defined path coordinating legal, IT, compliance, HR, and communications, tested by tabletop before it is needed rather than improvised during a real event. The two scenarios that reach the general counsel most often have a clear operational shape. When an employee has submitted confidential information to a consumer tool, the sequence is contain, assess what went where under what terms, attempt vendor deletion (rarely available on consumer terms), and document; the privilege, breach-notification, and IP analysis is in our separate article on consumer AI use. When a trade secret appears in a competitor’s output, identify the likely source and inputs and weigh remedial options; the misappropriation analysis is in our separate article on AI and intellectual property. Privilege protects the response only if the response stays inside protected channels: a federal court has held that using a consumer AI tool to prepare investigation-related documents waived both attorney-client privilege and work-product protection, because the vendor’s terms defeated any expectation of confidentiality, so the playbook should name the tools the response team itself may use. Insurance belongs in the same playbook: carriers began attaching AI exclusions to general liability and professional lines in 2026, so the playbook should include carrier notice and a coverage check, and the renewal file should show that the AI endorsements were read.[14] The policy’s job is to make sure the response begins under privilege and with a named owner, not to relitigate doctrine in the moment.

The readiness check:

• Who owns an AI incident, and does the response begin under privilege? Ownership decided in advance is most of the battle.
• Would the company detect any of the five triggers above, and through what logging? Detection is a configuration decision made long before any incident.
• When was the last tabletop, and who was in the room? An hour of rehearsal buys composure when it counts.

VIII. Ownership, and Keeping the Policy Current

A policy with no owner is not enforced, and a policy no one revisits is wrong within a year. Ownership fragments unless someone designs it. A workable model assigns legal the policy and contractual integration, IT the technical controls and the approved-tool list, compliance the regulatory disclosures and training, and HR the acknowledgment and offboarding, with a small cross-functional group coordinating across them. Because the two inputs that determine the policy, the company’s commitments and the categories of information it handles, change as the business grows and the law moves, the deliverable is a living mapping with a review cadence. Colorado is the cautionary tale again: a control built to a February 2026 effective date had to be reconsidered four times in under a year as the date moved, enforcement was stayed, the statute was repealed and replaced, and the replacement was held for rulemaking and renewed litigation. The companies that fared best were the ones whose policy was built to the underlying commitment, the duty not to discriminate in consequential decisions, rather than to a particular statute’s effective date.

The maintenance questions:

• Who owns each piece of the policy, and who coordinates across owners? A named owner per piece and one coordinating group are enough.
• What events force an off-cycle review: a new state, a new tool, a new business line, a statute that moves? Trigger-based review catches what a calendar misses.
• When was the mapping of commitments and information categories last checked against practice? The mapping moves with the business, and checking it is how the policy stays true.

IX. Common Questions

What is the minimum AI policy a company needs?

A clear, enforced rule about which tools are approved for which categories of information, backed by technical controls that stop the most common violation. Everything else depends on having this in place; without it, contract representations cannot be verified and regulatory disclosures cannot be accurate.

Does a Business Associate Agreement make a tool HIPAA compliant?

Necessary, not sufficient. The BAA binds the vendor contractually, but the covered entity or business associate remains responsible for its own safeguards, access controls, audit logging, retention, and workforce training.[15] A BAA over a product that is not configured for PHI processing produces nothing useful.

How do we handle AI use by outside counsel, vendors, and service providers?

Through flow-down provisions matching what the company has committed to its own customers and regulators. Outside counsel engagement letters should address approved tools, disclosure obligations, and prohibitions on submitting matter-related information to unapproved platforms; vendor contracts should carry equivalent terms.

What about AI features built into software we already use (Microsoft 365, Google Workspace, Salesforce)?

These features generally inherit the contractual architecture of the underlying enterprise agreement, which differs materially from consumer-tier terms. That inheritance is a starting point: specific features, and anything marked beta or preview, still require verification of configuration before sensitive information runs through them.

The Shape of a Policy That Holds

The policy that survives contact with regulators, opposing counsel, and the company’s own employees is the one built from the company’s actual commitments and actual data, integrated into the instruments that already bind, enforced by controls that actually stop the conduct, and revisited as the business and the law move. A template can supply the outline; it knows neither what the company has promised nor what it holds. The questions in this article supply the rest, and only people inside the company can answer them. That is the encouraging part: the answers are already in the building, the work is finite, and a company that has done it can say yes to new AI uses quickly, on a record that holds.

For more information, contact Ted Theofrastous (TCT@kjk.com) and KJK’s AI Practice Group. We would be happy to have a short pre-engagement discussion about your specific questions and needs and try to provide guidance. We are also happy to assist with the review and audit of your work environment and legal dynamics to develop a custom policy that addresses relevant issues your company is facing in its use of AI.

[1]Colorado Artificial Intelligence Act, S.B. 24-205 (2024), codified at Colo. Rev. Stat. §§ 6-1-1701 to 6-1-1707; effective date postponed to June 30, 2026 by S.B. 25B-004 (Aug. 28, 2025); enforcement stayed by stipulated order in X.AI, LLC v. Weiser, No. 1:26-cv-01515 (D. Colo. Apr. 27, 2026), which by its terms extends to successor legislation; repealed and reenacted by S.B. 26-189 (signed May 14, 2026) as a notice-and-transparency framework for automated decision-making technology in consequential decisions, dropping the duty-of-care, impact-assessment, and risk-management-program requirements, effective Jan. 1, 2027, with enforcement contingent on completed rulemaking and subject to a renewed injunction motion in the same litigation. The point is the volatility, not the detail.

[2]CCPA regulations, Cal. Code Regs. tit. 11, §§ 7000 et seq., as amended (automated decisionmaking technology, risk assessments, and cybersecurity audits), approved by the Office of Administrative Law on Sept. 23, 2025, effective Jan. 1, 2026. Businesses using ADMT to make a “significant decision” about a consumer must comply with the notice, opt-out, and access requirements by Jan. 1, 2027. “Consumer” includes employees, applicants, and independent contractors who are California residents.

[3]FTC Act § 5, 15 U.S.C. § 45; state consumer-protection and privacy statutes including the California Consumer Privacy Act, Cal. Civ. Code § 1798.100 et seq., the Colorado Privacy Act, the Connecticut Data Privacy Act, the Texas Data Privacy and Security Act, and the Virginia Consumer Data Protection Act.

[4]In re OpenAI, Inc., Copyright Infringement Litig. (S.D.N.Y.) (consolidated MDL). The May 2025 order requiring preservation of consumer output logs did not reach ChatGPT Enterprise accounts or API use under a zero-data-retention agreement, and prospective preservation ended in September 2025. On January 5, 2026, the district court affirmed the magistrate judge’s November 2025 order compelling production of a 20-million-log de-identified sample of consumer conversations under protective-order safeguards. A motion for sanctions filed July 9, 2026 alleges that OpenAI misrepresented its ability to search its training data and output logs; the allegations are contested. The litigation exposure and the discovery mechanics are developed in our separate articles on those topics.

[5]45 C.F.R. §§ 164.502(e), 164.504(e) (business associate contracts); id. §§ 164.308 (administrative safeguards, including § 164.308(b) business associate arrangements), 164.312 (technical safeguards: access controls and audit controls), 164.314(a) (organizational requirements for business associate contracts); see HHS, Guidance on HIPAA and Cloud Computing.

[6] Exec. Order No. 14,365, Ensuring a National Policy Framework for Artificial Intelligence, 90 Fed. Reg. 58,499 (Dec. 11, 2025) (directing the Attorney General to establish an AI Litigation Task Force to challenge state AI laws). The United States intervened in X.AI, LLC v. Weiser, No. 1:26-cv-01515 (D. Colo.), in April 2026.

[7] Regulation (EU) 2024/1689 (AI Act), art. 2(1) (application includes providers and deployers located outside the Union where the output of the AI system is used in the Union). Obligations for general-purpose AI models applied from Aug. 2, 2025; most high-risk obligations apply from Aug. 2, 2026, with certain embedded high-risk systems extended to Aug. 2, 2027.

[8] N.Y.C. Admin. Code §§ 20-870 to 20-874 (Local Law 144 of 2021) (independent bias audit, published results, and advance candidate notice for automated employment decision tools; enforced since July 5, 2023); 775 Ill. Comp. Stat. 5/2-102, as amended by Pub. Act 103-0804 (eff. Jan. 1, 2026) (discriminatory effect and notice of AI use); Colo. S.B. 26-189 (2026) (eff. Jan. 1, 2027).

[9] USPTO, Revised Inventorship Guidance for AI-Assisted Inventions, 90 Fed. Reg. 54,636 (Nov. 28, 2025) (rescinding the February 2024 guidance in its entirety; inventorship turns on human conception under the traditional standard, with AI treated as a tool, and the USPTO presumes the named inventors are correct).

[10] FAR 52.204-21 (basic safeguarding of covered contractor information systems); DFARS 252.204-7012 (safeguarding covered defense information; NIST SP 800-171); National Defense Authorization Act for Fiscal Year 2026 § 1513 (directing an AI security framework for incorporation into the DFARS and the Cybersecurity Maturity Model Certification program); proposed GSAR 552.239-7001 (rev. June 2026) (safeguarding of government data processed by large language models, with flow-down through the LLM supply chain).

[11] 15 C.F.R. § 734.13(a)(2), (b) (release of controlled technology or source code to a foreign person in the United States is a deemed export); see also 22 C.F.R. pts. 120-130 (ITAR). In June 2026 the Bureau of Industry and Security informed a frontier-model developer by letter that a license is required before release of its newest models to any foreign national, including employees inside the United States.

[12] See Fed. R. Civ. P. 37(e).

[13] Trinidad v. OpenAI, Inc., No. 4:25-cv-06328 (N.D. Cal. Jan. 2026) (dismissing a Defend Trade Secrets Act claim; developing the claimed secrets through consumer ChatGPT disclosed them to a party under no confidentiality obligation, extinguishing the right) (citing Ruckelshaus v. Monsanto Co., 467 U.S. 986, 1002 (1984)). The ruling came at the pleading stage against a pro se plaintiff under consumer terms; enterprise deployments with contractual confidentiality commitments present a different analysis.Our separate article on AI and intellectual property develops the trade secret framework.

[14] United States v. Heppner, No. 25 Cr. 503 (JSR), 2026 WL 436479 (S.D.N.Y. Feb. 17, 2026). The ruling addressed a consumer tool under consumer terms; enterprise deployments with contractual confidentiality commitments present a different analysis.Our separate article on the attorney’s professional-responsibility framework develops the privilege analysis.

[15] Insurance Services Office endorsements CG 40 47, CG 40 48, and CG 35 08 (Jan. 2026 ed.) (generative-AI exclusions for commercial general liability); carriers have filed comparable exclusions in directors-and-officers, errors-and-omissions, and fiduciary lines.