Someone used AI to draft a client contract without review
What to do when you discover employees are using AI tools you didn't authorize
What happened
A team member used ChatGPT to draft a client service agreement. They entered the client's name, project scope, and timeline into the tool, got back a professional-looking contract, made a few edits, and sent it to the client. The client signed it. Two weeks later, during a project kickoff call, the client referenced a deliverable that wasn't part of the original scope. It was in the contract—a hallucinated requirement that the AI added and the employee didn't catch.
Now you're wondering: Do we need to audit every contract this employee has sent out? What about other employees—are they doing this too? Should we ban AI tools entirely? Should we require legal review of everything? According to research on unauthorized AI use at work, most employees are now using AI tools without explicit authorization. This isn't an isolated incident. It's a preview of what happens when you don't have operating rules.
The immediate question is what to do about the signed contract. The medium-term question is what to do about this employee. The real question is what to do about the gap in your operating procedures that allowed this to happen. This brief addresses the third question, because fixing it prevents the first two from recurring.
Before establishing new rules, assess whether past work needs review. If this employee sent contracts in the past 90 days, have someone qualified review them for unexpected terms, obligations you can't meet, or liability you didn't intend to accept. If you find problems, consult an attorney about your options. If the contracts look fine, document that you reviewed them and move on. Don't audit everything ever sent unless you find a pattern of problems.
What appeared to be the problem
The surface problem looks like unauthorized technology use. An employee used a tool without permission. The instinctive response is to control the technology: ban the tools, require approval for new software, or implement monitoring to catch unauthorized AI use.
Some businesses will respond by looking for governance technology. There are frameworks for AI governance that help larger organizations manage AI deployment at scale. But most small businesses don't need comprehensive AI governance frameworks. They need basic operating rules about what requires review before it leaves the building.
The technology-focused response misses the point. Banning ChatGPT doesn't solve the problem if the underlying issue is that employees don't know which work products require expert review. They'll just use a different AI tool, or they'll make the same judgment errors with traditional software, or they'll send out inadequate work that they drafted themselves. The problem isn't the tool. The problem is the absence of rules about what can go directly to clients and what needs review first.
What the actual problem was
The actual problem is that you didn't have clear rules about three things: which outputs carry liability, who's qualified to review them, and what happens when someone isn't sure. The employee who sent the contract didn't know that contracts require expert review regardless of how they're created. They didn't know who to ask. They didn't know that pasting client information into ChatGPT might violate confidentiality obligations.
Most small businesses using AI lack clear policies about approved use and prohibited contexts. Without explicit guidance, employees make their own judgments about what's safe and what isn't. Those judgments are often wrong because employees don't understand the liability implications of the documents they create.
The data privacy risk is particularly serious. When your employee pasted the client's name, project scope, and timeline into ChatGPT, they likely shared information covered by an NDA or implied confidentiality obligation. Public AI tools like ChatGPT may use inputs to train future versions of the model. Even if the specific contract language doesn't appear elsewhere, you've shared client information with a third party without authorization. That's a breach of confidentiality that exists independent of whether the contract itself had errors.
Legal frameworks generally hold businesses responsible for the work product they deliver to clients, regardless of what tools were used to create it. Legal experts and regulatory bodies generally hold AI mistakes as the responsibility of the people and organizations that deploy and use the tools. If an AI-generated contract contains terms you can't fulfill, you're still bound by those terms. If it omits protections you needed, you still face the consequences. The fact that AI wrote it is not a defense.
The liability exists whether the contract was drafted by AI, traditional software, or a human. What matters is that it went to a client without review by someone qualified to catch errors. That's the operating failure that needs fixing.
The overlooked condition
The overlooked condition is knowing which outputs carry liability and therefore require expert review before they leave your organization. This isn't about AI. It's about understanding which work products create legal obligations, financial commitments, or regulatory exposure.
Contracts create binding obligations. If you promise to deliver something you can't deliver, or accept liability you can't afford, or agree to terms that conflict with your other agreements, you face legal and financial consequences. Technical specifications that become part of a contract create the same binding obligations—if the AI hallucinates a product capability that doesn't exist, you're contractually obligated to build it or face breach of contract claims.
Proposals and quotes create enforceable commitments in many contexts. If you quote a price and scope, then discover the AI miscalculated or omitted costs, you may still be bound by what you proposed. Financial reports and tax filings carry regulatory obligations and penalties for errors. Marketing claims about your products or services create liability under consumer protection laws and false advertising regulations if they're inaccurate.
Employee-facing documents like offer letters, performance reviews, and termination notices create employment law exposure. A hallucinated policy or incorrect termination reason can turn into a wrongful termination claim. Client-facing communications about security, compliance, or data handling create contractual obligations and regulatory exposure if they're inaccurate.
The common thread is that these documents do something beyond conveying information—they create obligations, make commitments, or expose you to liability if they're wrong. Internal drafts, research summaries, and brainstorming notes generally don't carry the same risk. The line between low-risk and high-risk outputs should be explicit, written down, and communicated to everyone who creates client-facing work.
If your team doesn't know which outputs fall into the high-risk category, they can't make good decisions about when to use AI assistance and when to get expert review. This knowledge gap is what allowed a contract to go out without review. It would allow the same thing to happen with proposals, specifications, financial reports, or any other high-stakes document.
What should have happened first
Before anyone used AI to draft client-facing documents, someone should have written down three lists. First, the types of work where AI is fine without special review. Second, the types of work where AI requires expert review before it goes out. Third, the types of work where AI is prohibited entirely because the risk of exposure is too high.
Then someone should have told the team about those lists in a 15-minute meeting. Not a training program. Not an e-learning module. A short meeting where you say: "Here's where you can use AI. Here's where you need review. Here's where you can't use it at all. If you're not sure, ask me before you start." Small businesses that successfully govern AI use start with acceptable use policies that employees can actually remember.
Then someone should have made it easy to ask for clarification. Not a formal request process. Not a committee review. A Slack channel or an email address where someone can ask "I'm about to draft a client proposal, can I use AI for the first draft?" and get an answer the same day. The goal is to make following the rules easier than guessing.
Then someone should have documented the first time someone asked a question and what you told them. That documentation becomes the beginning of your operating rules. It's not a policy document. It's a record of decisions. "Sarah asked if she could use AI to draft blog posts. We said yes as long as she reviews for accuracy. Tom asked if he could use AI to draft employment agreements. We said no, those go to our attorney." Over time, that record becomes the reference that new employees can read to understand the boundaries.
This sequence takes about two hours of work spread over a week. It doesn't require a consultant. It doesn't require software. It requires someone to think through the boundary, communicate it clearly, and make it easy to ask questions. That's what should have happened first. Instead, the employee made their best guess and got it wrong.
How to prevent repetition
Do the work you should have done first. Write down the three lists. Tell your team in a meeting. Create a way to ask questions. Document the answers. That prevents repetition by giving people clarity instead of expecting them to guess.
But you also need to acknowledge that people are already using AI for things you don't know about. Research shows that employees want to use AI tools and will use them whether they're authorized or not. The question is whether they'll tell you about it or hide it. If your rules are too restrictive or too vague, they'll hide it. If your rules are clear and practical, they'll follow them most of the time and ask questions when they're unsure.
You need a lightweight incident reporting mechanism. Not a formal investigation process. Just a way for people to say "I think I might have used AI for something I shouldn't have" without fearing they'll be fired. The goal is visibility, not punishment. You want to know about mistakes before clients find them. That means you need to make it safe to report mistakes.
You also need to define what happens when someone crosses the boundary. If someone uses AI for a contract without review, what's the consequence? Is it a conversation? Is it a written warning? Is it termination? The answer depends on whether it was a first offense, whether they knew the rule, and whether the output went to a client. But you need to decide this in advance, not in the moment. Otherwise you'll either overreact and create fear or underreact and signal that the rules don't matter.
Finally, you need to review the rules every six months. AI tools change. Your work changes. Regulations change. The boundary you drew in September might not make sense in March. Set a recurring calendar event to review your three lists and update them based on what you've learned. Ongoing policy updates are a core operational requirement for AI governance, not a one-time project. If you treat this as "done" after you write the first version, you'll end up back here in a year with a different incident.
I've watched too many small businesses write AI policies that nobody reads and then act surprised when employees ignore them. The policies that work are short, specific, and tied to real decisions people make every day. "Don't use AI" doesn't work. "AI is fine for drafting internal emails, but client contracts require attorney review" works because it tells people what to do next.
Recommended decision
Conditional proceed with creating basic operating rules. The conditions are non-negotiable: you must define the boundary between low-risk and high-risk AI use, you must communicate that boundary in plain language, and you must create a way for employees to ask questions before they make a mistake.
Do not proceed if you're planning to write a comprehensive AI policy that nobody will read. Do not proceed if you're planning to prohibit all AI use and hope people comply. Do not proceed if you're not willing to answer employee questions about AI use within 24 hours. Those approaches will fail and you'll be back here in six months with a worse incident.
The smallest next step is to write down three categories of work: AI-assisted with casual review, AI-assisted with expert review required, and AI prohibited. Put it in a document. Send it to your team. Schedule a 15-minute meeting to answer questions. That's the minimum viable version of operating rules.
The metric to establish is how many times employees ask for clarification about whether AI is allowed for a specific task. If nobody asks questions, either your rules are perfectly clear (unlikely) or people are afraid to ask (more likely). You want questions. Questions mean people are thinking about the boundary before they cross it.
The person who should own this is your operations manager or office manager. Not your IT person, unless they also own process documentation. Not an outside consultant. Someone internal who already handles questions about how work gets done. Someone who can update the rules when they learn something new. Someone who can answer questions the same day.
Review your rules in six months. Look at what questions people asked. Look at what mistakes happened. Look at what work people are doing with AI that you didn't anticipate. Update the three lists based on what you learned. If you go six months without updating the rules, you're not learning from reality.
This is not a comprehensive AI governance framework. This is not an enterprise-grade policy. This is the minimum set of operating rules that prevents the next contract incident. Small businesses need practical AI readiness, not enterprise governance. Start with the minimum. Add complexity only when you have evidence that the minimum isn't working.
