AI is drafting your clauses, redlining your agreements, and reading the data inside your contracts, and you're on the hook for all of it. Where the risk actually falls depends on who you ask.
To your general counsel, it's a question of privilege, work product, and the ethics rules. To your security lead, it's about isolation, hallucination, and whether you can prove what the AI did after the fact.
"AI in Contract Management: Legal Risks, Ethical Duties, and Practical Guidance" is a one-hour CLE-accredited* webinar we’re hosting on July 27, 2026 at 11:00 AM ET to explore both perspectives. IntelAgree’s General Counsel Lee Rone and Director of Information Security Marlon Abbott will lead it, and they’ll be joined by Stanislav Zakharenko, a Principal at GTC Law Group.
We asked Lee and Marlon for a preview of what they'll cover. First, here’s the legal perspective from Lee:
Q: Lawyers have always owned their work product. Which part of that duty is hardest to hold onto once AI, or a vendor's AI you can't see into, does some of the work?
Lee: One thing AI makes harder is identifying what counts as work product in the first place. Which of the things I've produced — opinions, emails, Teams messages — actually qualify? And the second part is, do I still own it, or have we lost privilege to it? I think it's already well established that if a lawyer uses a public large language model and puts something that would otherwise be considered work product, confidential, covered by privilege into that public model, privilege is broken, and there's no way for the lawyer to undo that. It's very hard to put the horse back in the barn, so to speak.
Q: Generative AI hands you a draft to review; agentic AI can act on its own. Why does that line change what a lawyer is on the hook for?
Lee: Generative AI takes that input and your prompt and produces something, and then you decide what to do with it. That output could be work product and could be protected by attorney-client privilege.
Agentic AI can be stateful. In other words, it can take action on your behalf, say, sending an email that lays out your opinion as a set of five recommendations. That email, especially if it goes out to the public, is not going to be considered work product. But even internally, you may lose privilege, because the AI went ahead and took that action for you. You also lost the chance to step in and revise the second and fourth recommendations before it went out. Once the AI has sent them, you answer for all five.
Q: How should a GC handle confidentiality when client data may be feeding a vendor's AI they never evaluated?
Lee: Evaluating AI is part of vendor review now. You're not just checking a vendor for privacy and information security, you're asking whether they use AI, and if so, how. The focus has shifted from “am I getting good results” to “what is my vendor doing with AI to produce them,” and then to what their vendors are doing downstream. For confidentiality, the question is what client data that first-tier vendor can access, and whether you have confidentiality and data-protection agreements in place with them. Then you have to ask whether that vendor has the same agreements with their tier-two and tier-three vendors. Your client's data can travel further down the chain than you think.
Q: What's one piece of popular AI advice you'd push back on, and what do you tell people instead?
Lee: One is that AI is neutral, so it's fine to use without disclosure. That probably violates multiple model rules for lawyers. I'm sure we've all heard about it in the news, where a lawyer files a brief with a court that has AI-generated content that hasn't been checked by a human lawyer, and it turns out to be hallucinating, incorrect, citing the wrong cases or citing them incorrectly.
Just because you think AI is neutral doesn't mean it is. It may be giving you a biased opinion, or just flat out the wrong answer.
Q: Looking at what's coming, from the EU AI Act to state frameworks in California, Colorado, and Texas to IP and copyright on AI-generated output, what should legal teams be preparing for now?
Lee: The EU AI Act is in existence and already in force, and like a lot of other laws in the EU, it takes effect gradually. Bits and pieces of it come online over time. If you have operations outside the U.S., especially customers, employees, or vendors in the EU, you need to be familiar with the basics. It has different classifications of information based on risk, and you need to know when the different parts come into force.
In the U.S., there is still not a comprehensive federal law on AI, so you get states like California, Colorado, and even Texas passing their own state laws, similar to the approach those states took with privacy in the absence of a federal law. And in general, AI-generated output is not considered a work of authorship, so it typically cannot be copyrighted. If intellectual property is important to your business, using AI to generate that output, whether it's a new logo for the marketing team or a blog, may not be protected.
Q: A lot of teams treat AI governance as a one-time project: write the policy, done. Why doesn't that work, and what does it look like to run it as an ongoing operating cadence instead?
Lee: It may not be day-to-day, but it's not a one and done thing, because the regulatory standards that apply to every industry, and certainly the industry specific standards, keep evolving. If you're in healthcare, for example, HIPAA is evolving.
The other reason it's not one and done is that the technology itself is constantly evolving and changing, as we've already seen with the difference between generative AI and agentic AI. Because of technology changing like that, and changing quickly, your compliance project that you finished in January of 2026 may be outdated in January of 2027.
Here’s Marlon’s security perspective:
Q: You came to information security from outside legal tech, including years as a virtual CISO in critical-infrastructure industries. What lesson from that world do you wish more legal teams applied to AI risk?
Marlon: It comes down to upfront risk avoidance, and testing your incident response. Legal teams should mandate aggressive separation of duties, making sure the right people have the right access. From there it translates into two or three specific actions.
The first is to mandate zero-trust boundaries. Just like in critical infrastructure, where we used to protect the operational technology environment from the IT environment by having air gaps, legal teams should enforce logical isolation, with the human in the loop and internal audits.
The second is planning for model compromise and hallucination. Sometimes AI will overreach and create a solution that doesn't necessarily exist, so rather than assuming the guardrails are 100% effective, they'll need an incident response playbook, and they should explicitly address what happens if the AI model hallucinates and provides data that's incorrect.
The third is insisting on explainability for the audits. In critical infrastructure, we had to know how a system behaved and why it took a certain action. You want to be able to explain how your AI functions, and track its lineage by performing rigorous testing.
Q: What should every legal team add to their vendor contracts and security questionnaires to cover AI?
Marlon: Vendor agreements should restrict models from training on your data, because that raises the risk. They should clarify who owns the intellectual property in AI-generated outputs, and require compliance with frameworks like the NIST AI Risk Management Framework. On the questionnaire side, verify encryption at the large language model layer, set strict data retention policies, and confirm there are robust model auditing processes in place. The auditing in particular ends up serving you well, including on the questionnaires themselves.
Q: Vendors point to SOC 2 reports, ISO certificates, and “AI-ready” or “AI-secure” labels. What do those genuinely tell you about a vendor's AI, and what do they leave out?
Marlon: SOC 2 and ISO are great control certifications. They give you a high level view of how the security controls are being utilized and implemented, and how they're working for an organization.
But labels like AI ready or AI secure are mostly marketing type terms, and they're not really regulated certifications. Often they signify data hygiene, but the one thing they miss is the reliability, the transparency, and the ongoing safety of the AI system itself.
Q: On the standards side, from SOC 2 and ISO's AI components to emerging AI audit expectations, which one are you watching most closely, and how should teams prepare?
Marlon: End-to-end auditability, being able to explain AI from inception to usage. There are a couple of regulatory standards now demanding immutable logs, showing exactly what inputs, prompts, and reasoning go into every AI model. There are also federal mandates coming down with AI.
The auditability of AI is one thing that kind of keeps me up at night. What actually helps me sleep at night is that we're taking an active approach, with internal auditability and technical partners, so we can see how the landscape is changing from an audit, risk, and compliance perspective.
Finally, we posed the same question to both of them:
Q: You're both responsible for how IntelAgree uses AI, and how the business uses it overall. Where does that create tension, and how do you handle it?
Marlon: A lot of it comes down to speed versus accuracy. AI gets used for how fast it is, and teams want the output right now. But if I'm reviewing 6,000 lines of code or a hundred pages, checking it for accuracy takes time. Someone will say they need it within the hour, and I'm explaining the data needs a real review first. AI also answers the question it thinks you asked, which sometimes isn't the one you meant. On the security side it might respond about the wrong control, and you won't catch that unless you know how the controls work and go read the answer closely. So a lot of it is explaining that the data needs a genuine review before we act on it, even when the timeline is tight.
Lee: At a software company like ours, you have a lot of smart people who want to be efficient, and AI lets them move faster. That's the appeal, and it's also the tension. Part of my job, and information security's job, is understanding who's using AI and how. We manage that with a policy, whether it's an employee using AI day to day or a vendor using AI in what they deliver to us. There's also a softer cost. When everyone leans on AI, you can lose some of the collaboration that used to happen when a person asked a colleague or a supervisor to look something over. That feedback has real value, and too much AI use can erode it.
Supervising the AI is your job now
The job used to be reviewing contracts. Now it's reviewing what an AI reviewed on the contracts, and reviewing what your vendor's AI did to the ones you sent out. But how do you keep up with it all?
During the webinar, Lee, Marlon, and Stanislav will map AI duties to ABA rules, read the standards for what they actually cover, and show where regulation is heading. If you're putting AI to work on contracts, the webinar will explain how to stay ahead.
*This webinar is expected to qualify for 1 hour of CLE credit in AK, AL, AZ, CA, CT, DC, FL, ID, MN, MO, MT, ND, NJ, NM, NY, OH, PA, RI, UT, VA, WI, WV, WY. Attorneys may be eligible to receive CLE credit through reciprocity or attorney self-submission in other states. For more information about CLE accreditation please contact sdornbush@nacle.com.
Additional Reading
Getting AI Contract Review Right: Tailor, Test, and Trust — A practical guide to tailoring an AI contract review tool to your standards, testing its output, and knowing when to trust what it flags.
IntelAgree to Host CLE-Accredited Webinar on Managing AI Risk in Contracts — The press release announcing the July 27 session, with the speaker lineup, what attendees will learn, and how to register.
Why Contract Negotiation Is the Highest-Risk Stage for Legal Teams in 2026 — A look at why negotiation creates more friction than any other lifecycle stage, and how growing cross-department involvement makes it harder to control.