The AI at Work Handbook

Start with the failure that actually happens, because it is not the one people imagine. It is not a rogue algorithm or a dramatic leak. It is a capable employee at six in the evening, under deadline, pasting a customer’s contract into a free chatbot to get a summary, because it was faster and nobody had ever told them not to. Nothing bad happens that day. The problem is what the tool’s terms allowed it to do with that contract, and what the customer’s contract said about where their information could go, and the fact that nobody in the company knows either.

Every AI problem an organization is likely to meet falls into one of three exposures. What goes in: confidential information, customer data, personal information protected by privacy law, material you licensed but do not own, entered into a system whose terms you have not read. What comes out: text, images and decisions that may be wrong, may be biased, may reproduce someone else’s work, and may not be protected by copyright at all when you want to enforce it. And what you promised: warranties in customer contracts written for a world where people made the deliverables, marketing claims about what your AI does, notices you owe job candidates, and statements to investors.

Each exposure has a small, specific fix, and none of the fixes require slowing anyone down. They require knowing, in writing, what tools are in use, what may go into them, what a person checks before the output leaves the building, and who owns the question. The chapters that follow are those fixes in order. How long the work takes depends on how many tools are in use, what data they touch, and what your customer contracts already promised.

One idea runs through the whole handbook and is worth stating once. A named person has to review what goes out and answer for it. “The tool wrote it” has never been a defense anywhere it has been tried, not in a court, not with a regulator, not with a customer. That single rule, understood by everyone, prevents most of what follows.

You cannot write rules for tools you do not know about, and every organization we have looked at has more in use than anyone thought. The inventory is the first job and it takes less time than it sounds.

There are three kinds of AI in a typical organization. The tools people chose: the chatbots and assistants employees use directly, on company accounts or personal ones. The features vendors turned on: the AI summaries inside your email, your customer-service platform, your document system, your recruiting software, often switched on by the vendor in an update nobody read. And the systems that make or shape decisions: pricing, screening, scoring, routing, anything that sorts people or money automatically. The third kind is the smallest list and the one with the most law attached.

The fastest way to build the inventory is to ask. Ten minutes at an all-hands, with one honest promise: nobody is in trouble for the tool they have already been using. That promise is what turns shadow use into disclosed use. You will learn more in those ten minutes than an audit would tell you, and the list will be longer than the approved one. That gap is where the policy starts.

A board does not need a technical document. It needs a one-page table with three columns: what, where, and who owns it. Most boards are surprised by its length and by how much of it was never approved by anyone.

A company of twenty, or a nonprofit of fifty, does not need an AI governance framework. It needs a short document that answers four questions clearly enough that an employee under pressure can follow it without asking anyone. Which tools are approved. What data may go into them. Which uses are permitted and which are not. And what a person must check before the output leaves the building. Add one named owner and one review date, and you have the whole thing in about two pages.

Which tools. Name them, with the account tier that counts, because the consumer version and the business version of the same product often carry opposite data terms. Say what an employee does when they want something not on the list: a two-day answer from a named person, not a refusal, because a refusal produces shadow use.

What data. Tiers work where blanket rules fail. Open: published material, marketing copy, public documents; any approved tool. Internal: drafts, plans, unpublished numbers; approved business-tier tools only. Restricted: customer personal data, anything under a confidentiality agreement, credentials, health or payment information, anything a contract says stays in a particular place; not into a general-purpose tool at all without a named approval.

Which uses. The prohibitions are shorter and more useful than the permissions. No final decision about a person (hiring, discipline, credit, termination) made on model output. No legal, medical or financial advice generated for a customer. No customer data in a personal account. No AI-generated likeness or voice of a real person without written permission. Nothing published without a human check.

What must be verified. Every factual claim, number, citation and name, by the person who sends it. Then the two lines people skip: a named owner who maintains the tool list, answers exception requests and is allowed to say yes; and a review date every six months, or whenever a new tool is adopted, because vendors change their terms without asking you.

What you can leave out: most of what enterprise governance material contains. Risk tiering, impact assessment templates, standing committees, bias-testing protocols for models you did not build. Those exist for organizations that build or deploy models at scale. At your size they produce a document nobody reads, which is worse than a short one people do. The well-known public frameworks are good structure to borrow the shape of; they are not documents to implement clause by clause.

An AI vendor’s terms run to thousands of words, and six clauses decide almost everything. Read those six and you know which tier of your own policy a tool belongs in. This is worth doing even when nothing is negotiable: a click-through you cannot change still tells you whether the tool may see customer data, internal drafts, or nothing but published material.

Training rights. Almost nobody writes “we will train our models on your data.” They write that the provider may use customer data to develop, maintain and improve the services. Unqualified, that is a training right, and it is the most consequential sentence in most AI agreements. Look for an explicit statement that your content is not used to train or improve models; whether that is the default or an opt-out you must switch on; whether it covers inputs, outputs or both; and whether it holds on the tier you are actually using.

Retention and deletion. How long is data kept in the ordinary course (a short period for abuse monitoring is common and usually fine), and what happens when you delete: is the record purged, or does your access end while the data lives on in logs and backups? Ask for the period as a number. “As long as necessary” is not a retention period.

Subprocessors and location. Who else touches the data, where it is processed, and whether you are told before that changes. If your own customer contracts promise data stays in a particular country, this clause either honors that or quietly breaks it. Ask separately whether people review a sample of traffic, because that may be a disclosure your customers are owed.

Output ownership and the license back. Do you own the output, and what license does the vendor keep in it? A broad license back can matter as much as a training right. Remember, too, that owning the output as against the vendor is not the same as owning it against the world: the same output may be produced for another customer, and copyright requires human authorship.

Indemnity and its conditions. Several major vendors now promise to defend you against copyright claims over their output. Read the conditions (safety features on, filters not disabled, no infringing input, unmodified output) and the cap. An indemnity capped at a year’s subscription fees is not a backstop for a real claim.

Exit and change. What you can take out, in what format, and what happens to the rest. And how the terms change: many AI agreements allow amendment on notice, so the training clause you approved in the spring may not be the one in force by autumn. Diary a re-read.

Before any of the six, one prior question: what have you already promised someone else about this data? Customer contracts, confidentiality agreements and data-processing terms frequently restrict who may process the other side’s information and where. A vendor’s terms can be perfectly reasonable and still be incompatible with a promise you made last year to a customer who has never heard of that vendor. The vendor read is the second step. The list of what you already agreed to is the first, and for most organizations nobody has assembled it.

This is the exposure that surprises people most. Under current United States law, a work created entirely by a machine, with no meaningful human creative contribution, is not protected by copyright at all. The Copyright Office has said so in guidance and in registration decisions, and courts have agreed when asked. A detailed prompt has not been treated as enough. A person has to have made real creative choices in the result.

Consider what that means. If your new logo was generated by a tool and adopted as is, you may hold no copyright in it, and may be unable to stop a competitor using something identical. If your website copy, product documentation or training videos were machine-generated end to end, the machine-generated part may not be protected by copyright at all. That is not the same as putting it in the public domain on purpose, and the human work around it (what you selected, how you arranged it, what you rewrote) can still be protectable on its own. Your trademark in the brand name is separate and still works; the copyright in the artwork may simply not exist.

The mirror-image problem is that output can reproduce material from the model’s training data. If a tool hands you three paragraphs that closely track a copyrighted article and you publish them, you published them. The vendor’s terms are careful to leave that with you, subject to whatever indemnity you read in the last chapter.

The lawsuits against the model builders continue, and the early decisions have not all pointed the same way: some judges have found that training a model on lawfully obtained works can be a fair use, others have rejected that argument on different facts, and how the copies were acquired has mattered a great deal. The honest summary is that the law of AI training is still being written. A business that uses these tools should plan for uncertainty rather than assume the vendor has it covered.

Organizations talk about AI in four directions, and each is a place a statement can be untrue. To customers, in contracts and marketing. To investors, in decks and disclosures. To job candidates and employees. And to regulators, when they ask.

Look first at your standard customer contract, the one your company signs as the vendor. It probably says the work is original, that you own it, that it does not infringe anyone’s rights, and that you will defend the customer if someone claims otherwise. That language was drafted for a world in which people made the deliverables. If a meaningful share of what you deliver is now machine-generated, each promise deserves a second look: “original” may not be accurate, “we own it” may not be true for the reasons in the last chapter, and the indemnity now covers a risk you did not price. Sophisticated customers have noticed. Requests for proposals increasingly ask vendors to disclose their use of AI, and some contracts now forbid it for certain work or require written consent.

Then the marketing. Regulators have brought cases for what they call AI washing: claiming a product uses AI when it does not, or claiming capabilities it does not have. “AI-powered” is a claim, and it will be read as one.

Then the people you hire. In New York City, an employer that uses an automated tool to screen or rank candidates must have that tool independently audited for bias, publish the results, and tell candidates in advance that it is being used. Other places have similar rules arriving. Recruiting software you licensed may have switched such a feature on without anyone in the company deciding to use it.

The fix in every direction is honesty in writing. Describe how the work is produced. Where AI tools are used, say so, and say what a human does before delivery. Adjust the warranties to promise what you can deliver: that the work does not knowingly infringe, that it has been reviewed by a person, that the customer owns whatever rights you have in it. Customers do not mind that you use these tools. They mind finding out later.

The uses of AI with the most law attached are the ones that decide something about a human being: who gets interviewed, who gets credit, who gets a warning, whose claim is paid, whose account is closed. Tools that do these things are useful and increasingly common, and the rules around them are stricter than around any other use.

The core principle is old law applied to new tools. Decisions that affect people’s employment, credit, housing, insurance or access to services must not discriminate on protected grounds, and the fact that a model made the decision is no defense; the organization that deployed it is responsible for its outcomes. On top of that general principle, specific rules are arriving: New York City’s requirement of an independent bias audit and advance notice for automated hiring tools is the clearest example, and others follow the same pattern of audit, notice and a human path.

The practical rule for an organization that does not build these systems is simple. No final decision about a person is made on model output alone. A tool may sort, flag, suggest or draft; a person decides, can see why the tool suggested what it did, and can overrule it. That rule is both what the emerging law requires and what protects the organization when a decision is challenged, because it means someone can explain it.

Two further habits matter. Keep records of what the tool recommended and what the human decided, so that patterns can be checked. And give people a way to ask for a human review of a decision that affected them, because that is what several of the new rules require and what a fair organization would offer anyway.

Owners now take questions to a chatbot before they take them to anyone, including legal questions about the business. It is a useful habit and a dangerous one, and the difference is knowing what the tool cannot do.

Nothing you tell it is privileged. What you tell your lawyer, in confidence, to get legal advice, cannot be forced out of either of you. Nothing like that attaches to a chatbot. If a dispute ends in litigation, the chat history can be demanded. Worse, the question itself becomes evidence: type “is it legal to do X,” then do X, and you have created a dated record showing you wondered whether X was legal before you did it. Ask your lawyer the same question and the exchange is protected.

Your confidential information may leave the building. Depending on the product and the settings, what you paste may be kept, seen by people, or used to train the next model. The term sheet, the customer list, the unsent letter: once they sit in someone else’s system under someone else’s terms, you will struggle to say you took reasonable steps to keep them secret, and reasonable steps are what trade-secret protection depends on. If the material belonged to a customer under a confidentiality agreement, you may have breached it the moment you pressed enter.

And the tool does not know you. It answers in general; your problem is specific. It does not know New York’s rule that a corporation’s board can act without a meeting only if every director signs, or the clause in your lease, or the fact you did not think to mention. It does not know when the law changed. It cannot check what it was not told, and it will not ask. When it is wrong, it is wrong in a confident voice, and nobody is accountable.

Used well, it is a very good way to learn the vocabulary of a problem before you call anyone, so the call is shorter and cheaper. It is good at summarizing a document you already have and at helping you write down your questions. Used that way it makes you a better client. Used as counsel, it is the most expensive free thing your business will touch.

Law firms, accounting firms, medical practices and anyone else who holds client information under a professional duty face everything in this handbook plus a layer of rules specific to their profession. For lawyers, the clearest statement is the American Bar Association’s formal opinion on generative AI, issued in 2024, and the guidance from New York’s bar associations that followed. Neither created new duties. The opinion names seven duties a lawyer already owes and works out what each one means once a generative tool is in the workflow.

Competence: a reasonable understanding of the specific tool’s capabilities and limits, not technical mastery, and no uncritical reliance on its output. Confidentiality: before client information goes into a tool, an assessment of the risk it will be disclosed, and, for a tool that learns from what users enter, the client’s informed consent first, which a boilerplate waiver in an engagement letter does not supply. Communication: no standing duty to announce AI use, but disclosure when the client asks how the work was done, when the engagement terms or the client’s own rules for its outside lawyers require it, when client information is entered, when the use affects the fee, and when the output will shape a significant decision in the matter; the engagement letter is the natural place. Meritorious claims and contentions: a position you would not have signed after reading the authority yourself is not one a tool can make arguable. Candor: the filings that cited invented cases were lawyers signing what they had not checked; New York’s courts have since adopted a statewide policy (Part 161). It says two things: using AI to prepare a submission should not be prohibited, and nobody should have to tell the court they used it. The review requirement people quote is not in that policy. It sits in a model rule at Appendix A, and section 161.4 leaves each court free to adopt it or not. Where a court has adopted it, the filer must carefully review the paper and independently ensure it contains no fabricated or fictitious cases, statutes or other material, and signing certifies that the review happened. Where a court has not, the older duties still bite, because signing a paper already certifies it carries no false statement of fact and no frivolous argument. Read the part rules of the judge you are actually filing in front of. Supervision: managing lawyers must establish clear policies on permissible use and make reasonable efforts to see that lawyers and staff follow them, which is what a malpractice carrier is testing when it asks whether the firm has a written AI policy. Fees: bill the time actually spent; if a tool turns four hours into one, the client is billed one, and the hours spent learning a tool you will use across the practice are the firm’s, not the client’s. The exception runs the other way: where a client asks you to use a particular tool you do not know, the time to learn that one can be billable.

In practice the two that take real work are the consent question for self-learning tools, which means someone has to read the terms of every tool and know which ones learn, and the supervision requirement, which means the policy is not optional. What the opinion does not require is worth stating too, because firms overcorrect: no blanket disclosure to courts or opponents, no consent for every use, no particular vendor or committee, and no requirement to stop.

For a six-lawyer firm the work looks like this. List the tools (three, it turns out, one on an associate’s personal account, which stops today). Read the terms of each; one learns from inputs on the consumer tier and not on the business tier, so upgrade or stop putting matter information into it. Add a paragraph to the engagement letter. Where a self-learning tool will see matter information, have the consent conversation and note it in the file. Write two pages of policy. Fix the billing narrative. Train everyone once and put the date in the file, because that date is what the carrier asks for. The first, second and sixth items are the work; the rest is drafting.

A board is not asked to understand how the technology works. It is asked to know where the organization is exposed, to satisfy itself that someone competent is managing that exposure, and to write down that it did. That is the standard for every other risk a board oversees, and it is the standard for this one. Directors of New York corporations and nonprofits owe a duty of care that the courts have long read to include oversight: a board cannot assume management is handling a significant risk; it has to make a reasonable effort to be informed.

Five questions, asked in one meeting and answered from the earlier chapters, meet that standard. Where are we using it? (The inventory: the three-column table.) What goes in and what comes out? (The policy’s tiers and the verification rule; the vendor reads.) What have we told people? (Contracts, marketing, candidates, investors.) Who is accountable? (The named owner, and how this reaches the board.) What happens when it goes wrong? (The incident plan, and whether the insurance covers it.)

Record the answers. The minutes should show that the board discussed AI use and risk, what management reported, what the board asked and what follow-up was agreed. Then set a date to return to it, once a year for most organizations and more often for one that builds AI into its products. This is not paper for its own sake. When something goes wrong, the difference between a board that can show a record of informed attention and one that cannot is the difference between a difficult week and a claim against the directors personally.

Something will go wrong eventually: a tool leaks confidential information, an automated decision is challenged, an employee publishes something the tool invented, a vendor changes its terms overnight. The organizations that handle it well are the ones that decided in advance who would find out, who could pause a tool, and how the customer or the regulator would be told. That is the last item on the checklist, and it is the one that turns a policy into a practice.