Every in-house legal team negotiates the same clauses over and over again. With every signed deal, your team builds up valuable knowledge: what liability caps you've accepted; which indemnification language is standard for your industry; or how often mutual NDAs get pushed to one-sided. That history is a real competitive advantage, but almost none of it is accessible.
It lives in people's heads, buried in shared drives, or locked inside a CLM that nobody has time to search. So when a new agreement lands, you start from scratch. You track down whoever worked on a similar deal. You dig through old contracts. Or you make your best judgment call and move on.
That is, until today. What if you could access the full knowledge of your previously negotiated contracts with a single click?
Ivo Benchmarks gives your team institutional memory, inside your review workflow, at the precise moment you need it.
When you upload a contract into Ivo, Benchmarks automatically scores each clause against your history of executed agreements. Within seconds, you can see how a provision compares to similar contracts you've negotiated before, filtered by counterparty type, industry, and governing law. Then you get a clear recommendation on whether to accept or push back.
You don’t have to hunt for answers or guess the right approach anymore. Your past becomes your strength.
Point Ivo at your contracts, and Benchmarks begins its work.
Ivo evaluates each clause in the contracts you’re reviewing and compares them against your previously executed agreements. You can see how often your team has agreed to that exact provision before and what Ivo recommends based on that history.
When you want to understand why Ivo made its recommendations, you can see the exact language from your historical agreements. Then, you can pull relevant clauses from your contract library, compare and contrast them, and see the reasoning in seconds. The logic is always visible and traceable.
While Benchmarks works, a multi-step process is occurring to both retrieve the relevant documents your new contracts are being compared to and scored against. Here’s what’s happening under the hood:
Only facts relevant to this specific contract type are surfaced. Ivo uses LLM-driven relevance filtering to skip topics that don't apply, so you're never shown a benchmark for a provision that doesn't exist in the agreement you're reviewing.
This is what Benchmarks produces when assessing annual liability caps in a SaaS agreement review.
When a provision falls below your median (for example, a counterparty is proposing uncapped liability), Benchmarks will flag it, and Ivo's review agents will draft a redline toward your 50th-percentile position, using language drawn directly from your own past agreements.
Benchmarks is most valuable when you’re reviewing high-volume agreement types where your team has built up a considerable negotiating history. Here are the patterns we see most often:
1. Vendor and SaaS MSA review
Third-party paper · Typical library: 50–300 executed agreements
Benchmarks can measure liability caps, IP ownership, data processing terms, SLA minimums, and auto-renewal windows against your history with your vendors. When a vendor proposes a mutual indemnification clause you've never accepted, Ivo will flag it with a finding like “accepted 0 of 67 times.” It will then suggest language from the agreements where you held the line.
2. Customer contract negotiation
Own paper · Typical library: 100–500 executed agreements
Benchmarks tells you how many concessions you’ve made in the past on your own paper. If a customer is pushing for a shorter term than you typically accept—say, 12 months vs your standard 24—the feature will surface a pattern like 82% of comparable deals closed at 24+ months, giving your team a data-backed position to help you respond.
3. NDA and confidentiality review
Both paper types · High volume, lower stakes per agreement
For high-volume, lower-stakes agreements like NDAs, Benchmarks is useful. Your team has signed hundreds of these; Ivo can tell you whether a one-way NDA (instead of mutual) is something you've consistently pushed back on (accepted mutual structure 91% of the time), or whether it's worth the round trip.
Benchmarks adds to your existing playbook positions; it doesn’t replace them. When a benchmark overlaps with a playbook item, the playbook position always takes precedence. Where you have playbook coverage, benchmarks add historical context, and where you don't have playbook coverage, benchmarks can fill the gap automatically, surfacing facts your team has taken positions on through hundreds of past deals.
Every benchmark recommendation shows its sources, which are the verbatim clauses from your historical agreements that define the distribution of the legal positions.
Benchmarks activates when you connect a repository of your executed agreements to Ivo. The minimum threshold is 10 comparable contracts in a given category, although most teams find meaningful benchmarks emerging around 25–50 agreements and richer distributions forming at 100+.
Once your repository is indexed, Benchmarks runs automatically on every new review. There's nothing to configure: Ivo extracts the market parameters from any agreement you review and pulls the right historical comparisons.
Benchmarks is now generally available (GA). See it in action.
Playbooks are how you tell Ivo Review your standards (e.g., the positions you take, the language you prefer, the lines you won't cross) so its redlines track to how your team actually works.
With Playbook Builder, you start from the contracts you already have. Point Ivo at the agreements in your repository, or upload from your local folders, and it will direct a few questions to you about which agreements to learn from and what to focus on. It then begins to draft the playbook from your own contracts, templates and guidance documents: standard positions, fallback language, all learned from your own precedents. You review every position in the output, choose whether it stays personal or goes to your whole organization, and save it as a playbook in a single step.
Most teams carry a long list of agreement types they've never found the time to build a playbook for at all. Now you can build those yourself, in minutes.
Every position Playbook Builder drafts comes from your own agreements, with a citation back to the contract it came from. You're never taking the output on faith as you can trace each position to the source and confirm it reflects how your team actually contracts.
Because you build it yourself in minutes, you can finally cover the agreement types your team has never gotten around to, the ones that have sat on the someday list while higher-priority work came first. More of your review runs against a real playbook instead of none.
You decide which contracts Ivo learns from and review every position before it's saved. And because creating playbooks is governed by role, administrators control who can author them and whether a playbook stays personal or becomes a company standard, so self-serve speed never costs you a single source of truth.
Playbook Builder gives your team a faster way to turn its own contracts into working playbooks, with the guardrails to keep your standards consistent. If you need any additional support building playbooks, our solutions attorneys are always here to help.
Where are your contracts right now? For many organizations, the answer is “inside a filing cabinet”— physical or digital, it doesn’t really matter which. They’re executed, archived, and consulted when something goes awry. But Adam Becker, the Director of Legal Operations at Cockroach Labs, thinks that’s about to change. And he couldn’t be more excited.
In our new series, Car Counsel, Adam describes contract intelligence as the ability to know what’s in your contracts without the manual effort that always made getting those answers so difficult. He elaborates. “[Contract intelligence is] a program that can tell you what's in your contracts without the need for traditional CLM tagging and review.” Suddenly, contracts are actually becoming useful.
Becker says that the first way many legal teams feel this shift is in moments of urgency. Perhaps a contract dispute might arise, or, as Adam notes, a global event like a pandemic makes force majeure language the most important text imaginable. You need to find that language quickly without having to sift through dozens of documents.
"If you have something that can just tell you, that's awesome, and if it's as good as a person, or close to it, that's awesome, too."But reactive retrieval is just the starting point. The more interesting question is what happens when contract data becomes proactively useful as a matter of course.
Where contract intelligence comes into its own is when legal teams can spot patterns that are valuable to the rest of the business. Becker's clearest illustration of this involves the finance team, which might want to know how many customer agreements carry 120-day payment terms. It's a reasonable business question, the kind of question that used to require a manual review project that could take weeks or months.
"That is not something that I'm particularly interested in," Becker says, "and a tool can do it for them and they can learn how to use that themselves.” Now, contracts stop being a legal artifact and start functioning as a data source. Becker imagines a world where finance, procurement, and operations can access that data themselves. The upshot is that businesses are using data, until now buried inside contracts, for actual revenue opportunities.
What Becker is describing is a different relationship between an organization and its own agreements. The intelligence was always there: buried in executed PDFs, scattered across shared drives, indexed by no one. Contract intelligence, powered by AI, makes it retrievable.
He sees this as part of a broader shift in how organizations are connecting data sources across departments to get a holistic view of all relevant data sources. "The things that we put into place should have an impact outside of legal," Becker says. That requires legal ops practitioners to think past the mechanics of contract management and into the underlying business logic. "It's not enough to say, 'Oh, they care about these five clauses in the contract, so this is how we built the flow,'" he explains. "Well, why do they care? What does it mean? What happens when it goes wrong? You need to be able to build that now."
For legal ops professionals thinking about what this moment demands of them, Becker's advice is consistent: stay curious, keep up with what leadership is being asked to do, and make sure the work you're building has reach beyond the legal team.
"We have to keep up with what our bosses are being tasked to do — figure out how we strategically support them as they are involved in more of the organization. And we should be, too.” After all, he points out, thanks to AI-powered legal technology, legal teams are now considered the center of innovation in many companies. "The legal department's starting to look like the ones who have these innovative products that help everybody," Becker says. "And it's actually true."
When considering adopting AI, legal teams often ask themselves whether they should buy a tool or build it in-house. We’ve seen the splashy stories: law firm Kirkland & Ellis, for example, is spending $500M USD to build its own AI tool. On the opposite extreme, former Latham & Watkins associate Will Chen has created MikeOSS, an open-source legal platform that claims to offer the same functionality as very well-known legal AI tools. Comments like this turn up regularly on the r/legaltech subreddit: “You can easily vibe code all of the functionality of [a major AI legal tech vendor] in a weekend. In fact, you can vibe code a better solution since you can customize it to your situation.”
So the question remains: with vibe coding tools, open-source projects, and general-purpose AI tools entering the legal market, should enterprises create their own AI tools in-house? Can you vibe code a legal AI tool that can do the work that in-house counsel needs it to do?
“You can absolutely vibe code a legal AI tool,” Didier Smith, Ivo’s Head of Engineering, says. “But whether that’s a good idea depends a great deal on who is doing the vibe coding.”
The reason, Didier points out, comes down to a software principle. “There's this rule in software called the 90/90 rule,” he notes. “Ninety percent of a software project takes 10% of the time. Then the last 10% takes the other 90% of the time. I believe that now, with AI vibe coding tools, it's actually closer to the 99.99 rule. You can get something that is 99% complete in a very short amount of time. But then that last 1% takes the other 99% of the time. It's that level of detail that makes the difference between software that normal people want to use and software that only tinkerers want to use.”
Didier notes that the best example of obsessing over this type of detail is the fate of FreeBSD, an open-source operating system that dates back to the original Unixes in the 1970s. “People have been tinkering away on FreeBSD in their spare time for about 50 years. And many people do run FreeBSD on their laptops. But they just don't know it, because Apple did the last 10%. macOS is, in fact, built on top of FreeBSD. Apple did all the bits that the guys tinkering in their spare time didn't want to do.”
The same principle applies to vibe-coded or open-source software. “People love to smash out these open-source projects when they're fired up,” Didier observes. “You go on the weekend and think: I want to build a legal AI tool, I want to build an operating system. And that first 99% is really satisfying because you just have your concept in your head and you bash it out and you've got something that sort of works. But then you run into the edge cases you didn't anticipate. The number and diversity of those edge cases determines how long you're going to be grinding away before you have something that's actually acceptable in practice.”
Didier elaborates on why the profession of law, in particular, has such a high number of edge cases. “One reason is purely technical,” he says. “Lawyers deal a lot with Word documents, and Word documents are an obscure, complex format. Lawyers care a lot about formatting—the numbers on their bullet points, the clause numbers—and those have legal implications. Getting a clause reference wrong can actually cause trouble down the line. So just editing a Microsoft Word document in a way that a lawyer would be happy with is surprisingly difficult. And then there's the legal substance itself. A lot of people think contracts are like code written in English, but that's not true. Code is designed to be unambiguous, whereas contracts are often designed to be ambiguous. Lawyers, when negotiating a contract, are under a dual tension. They have to protect their company from risk, but they also need to get the deal closed. So they'll deliberately put in ambiguous language that lets the deal move faster—language they can later fall back to arguing in court.”
Didier points out the importance of domain expertise in both engineering and law. He notes that the two professions have different skill sets, which means lawyers are unlikely to enjoy using open-source or vibe-coded software. “The people who can orchestrate agents and vibe code Claude Code instances just tend not to be the same people who know the difference between a good redline and a bad redline. This is why we have companies with different people in them and different departments—so the people who are great at programming can focus on programming, and they can leverage the domain expertise of people who are great at law.”
That said, he points out, there is some crossover between people who enjoy vibe coding and people who are good at practicing law. And in those cases, it’s possible that creating these types of software projects might be a good solution to working more efficiently. “If you're a tinkerer and you like tinkering, and you don't mind when your software kind of breaks a little bit because you can fix it, and you enjoy that, then it probably is a good idea to tinker away and build your own legal AI setup. But your average lawyer won’t want to go through the grind that it takes to build something that works really well in a high-edge-case environment. And if it breaks, the lawyers aren't going to be the ones to fix it. They're just going to say it's broken. You're not going to get the lawyer open-source community submitting PRs to your GitHub,” he jokes.
Didier is clear that none of this is a criticism of the tinkerers themselves. If you enjoy building, you should build. The question that legal leaders should ask themselves is whether these types of tools will survive contact with a legal team under pressure that has neither the time nor the inclination to scrutinize their output or fix them when they break.
Linda Evans is Senior Director, Commercial Legal & Operations at Hootsuite, and has run procurement, supported a high-volume sales organization, and sat through more vendor demos than she can count. She’s also spent the last year getting her legal team to actually use AI and has valuable insights about the experience.
Like many legal leaders at fast-moving tech companies, Linda faced an impossible math problem. The volume of work was rising, and headcounts weren’t increasing. Legal teams are being asked to absorb more work with the same amount of resources. The only answer is to innovate.
“It's part of our DNA to use software where we can. If you don't use the tools that are readily available, you won't succeed," Linda says.
Many legal leaders find themselves in a situation where they have a directive and a budget to find AI tools to streamline the workload, but they face a market full of vendors making similar promises. There’s no established roadmap of how to buy or implement an AI tool yet. So the reality is that you have to figure it out as you go, just like everyone else. And that was the experience at Hootsuite.
Linda came to vendor evaluations with a clear point of view: she knew her problem, she'd done her research, and she didn't have time for a fluffy pitch.
"You've got my time for a reason," she says. "I've done enough background research to get me in the room. Use your time wisely. Show me what you can do."
Her specific need was narrow and well-defined: faster contract review for a small legal team supporting a high-volume sales organization. She didn’t need a company-wide platform, and she didn’t want to roll out a repository that would require change management across the sales org. She wanted one thing done well for lawyers who needed to move faster.
That clarity made the evaluation process easier. She thinks having it is critical for anyone in the market for an AI tool; the best way to get what you want is to know what problem you're solving before you get to the demo. Many vendors will try to sell you more than you want. The right vendor will listen to what you actually need.
Issues that Linda had to consider, as she went through the vendor selection process, were how to mitigate the risk of non-legal professionals using AI tools for legal purposes, as well as how to ensure that the AI tools are actually trustworthy.
General-purpose AI tools are accessible to everyone in a company, and not everyone using them to review a contract knows what they don't know. Anyone could run a contract through a general AI tool and miss something a lawyer would catch. This could create risk exposure that the legal team wouldn’t know about until it's too late.
The answer, Linda says, isn't to ban the tools. It's to build the structure around them.
"That's down to having governance policies, having frameworks, educating a team," she says. "And it has to be from the top down."
Linda’s point of view is that creating these guardrails is a responsibility for leadership, not a legal ops task. It requires clear internal communication about which tools are sanctioned for which purposes, what the boundaries are, and why they exist. The legal team can write the policy, but someone at the executive level has to support it.
When you roll out an AI tool, there’s a secret no one talks about. Things will often go slower before they go faster. And that’s expected. It’s even okay.
Playbooks have to be built, lawyers have to learn to prompt, and the tool has to be trained on how your organization works. In the meantime, work still comes in, and timelines don't shift. It’s a significant ask for a lawyer who is already under pressure to do something the harder way, on purpose, even just temporarily. That’s the situation Linda found herself in.
"In the beginning, the lawyers told me, it's taking us longer," Linda recalls. "And I said, I understand, because you're training it."
If she had the chance to do it again, she’d make a deliberate space in the implementation schedule for that period, and she’d plan it with intention. There might be a structured onboarding roadmap rather than an open-ended expectation that people would learn the tool themselves. There would be dedicated weekly training sessions with the team. There should be a realistic conversation upfront with her team about what the first few months would actually look like.
"Nothing is plug and play," she says. "Nothing is out of the box and immediately you've got an ROI. There is a real time involved in this. And you have to put the time in yourself upfront."
The teams that go through this bumpy introduction period are the ones who actually get value out of the tool. The ones who don't plan for it often wonder why adoption is low, and face renewal conversations they're not ready to have.
The single most important factor in whether a legal team actually adopts an AI tool is whether their leader is willing to use it.
"How can anyone buy into doing something differently if you're not doing it yourself?" Linda points out. "Change comes from the top. You have to walk the walk."
Linda notes that she doesn't ask her team to do things she won't do herself; she models the behavior she wants to see. Not only does she use AI, she shares results in the team Slack channel so everyone can see what she’s doing. To make AI adoption actually stick, the leaders have to be visibly, consistently in the tool alongside everyone else.
The roadmap for adopting AI is still nebulous. But Linda’s experience shows that the teams that are using AI well, with the adoption to show for it, are the ones that treated it as a way to think about changing behavior and ways of working, not as a pure technology problem. People use technology, and understanding how they work and what they need will make its adoption easier and the investment more valuable.
.jpeg)
When Ivo was founded in Auckland, the ambition was clear: take it to the world and win.
Ivo is proud to announce a partnership with New Zealand Football as the Official Legal AI Partner of the All Whites, New Zealand's men's national team.
Founded in New Zealand and now headquartered in San Francisco, Ivo has spent the last several years building an AI-powered contract intelligence platform for the world's most dynamic organizations, including Meta, Uber, IBM, Shopify, and Mitsubishi Electric. Ivo has increased ARR sixfold and recently opened offices in London and New York.
"As a New Zealand-founded company, we know what it takes to build something and take it to the world stage," said Min-Kyu Jung, CEO and co-founder of Ivo. "Standing with New Zealand Football as they prepare for one of the most significant moments in the program's history is something we're really proud of."
Ivo branding will appear on the front of the All Whites' training and press kit as the team prepares for international competition, as well as across select New Zealand Football initiatives. New Zealand Football will use Ivo's contract intelligence platform to draft, review, and analyze agreements across all their teams.
For New Zealand Football, the partnership is a natural fit. "Ivo is a real Kiwi success story of a company taking on the world, and that's exactly what we strive to do every time our national teams step onto the field," said Andrew Pragnell, Chief Executive of New Zealand Football. "It's exciting to partner with a New Zealand-founded company experiencing strong global growth while remaining connected to its roots."
We're excited to support the All Whites as they take the field.
It sounds like an old riddle. Q: When is a contract not a contract? A: When it’s a source of enterprise intelligence. The subject came up numerous times at CLOC 2026. As a department that reviews contracts and mitigates risk, the legal team can be seen by finance departments as a support function and a cost center. But once legal teams can speak the same language as finance teams, and can care about the same things that finance cares about—margin, revenue recognition, risk exposure—then that gives legal teams a bigger seat at the table.
Until about two years ago, computers couldn’t read contracts. They could store them, search by keyword, and extract a few fields if a human told them where to look. But they couldn't understand a contract. When LLMs emerged, they offered a new capability to read contracts at scale. The shift that made it possible for an AI to write a coherent essay also made it possible for an AI to read a contract the way a senior associate would and understand the obligations it creates, the relationships it has to other agreements, and the way its terms compare to your standards and your history.
When contracts can be read at scale, they can be analyzed for insights. Emelita Hernandez-Bravo, Head of Legal Operations for the Royal Caribbean Group, noted: "We are the data stewards of this contract data. It's different data that means different things to different people within the organization. There's the risk data—limitation of liability, that's important to the CLO. But then there are obligations tracking, which is important to our CFO."
The intelligence buried in contracts contains valuable insights that the entire business can benefit from. Legal ops leaders at CLOC described specific, high-value data points their teams can now surface to the rest of the business. This data used to live in institutional memory, in a spreadsheet or an old PDF, or nowhere at all.
Alex Gao, senior director of legal operations at Hilton, described one contract intelligence use case—a founder attorney needed to find a clause she'd negotiated years earlier on a specific hotel deal. Previously, that meant asking around, hoping someone remembered. With their CLM's AI search capability, she typed a natural language query and got five results, including the right one first, with citations. "That's the power of AI," Gao said. "Switching that tacit knowledge—institutional knowledge that resided in somebody's mind—to structured, explicit data."
Alyse Wilkinson, Senior Director, Global Legal Operations at WSP, described her goal of mapping the total limitation of liability exposure across her entire contract portfolio. "If you look across your ecosystem of contracts, how many of you would know off the top of your head what your total exposure is in limitations of liability?” she asked. “That would be a huge, powerful data point for our risk professionals, our insurers, our CFO, our CLO." Most organizations wouldn’t know the answer to that question. And not knowing can be costly.
The unspoken theme beneath all of these conversations at CLOC is that AI is changing where lawyers create value for an organization. When AI takes over the execution layer of legal work—manually reading, reviewing, and analyzing documents—then the contribution legal makes to the rest of the business is concentrated in judgment, analysis, and strategic counsel. The role of legal is shifting from gatekeeper to strategic partner, and the teams moving fastest are those who have structured their contract data well enough to support that shift.
When legal can identify strategic challenges like risk exposure and revenue recognition impact, and offer quantifiable solutions to those challenges, it’s not making a case for relevance anymore. It’s delivering data that the rest of the business needs.
The data has always been there, sitting in executed agreements, buried in clauses, scattered across systems. The opportunity now is to organize it, and to hand the rest of the organization answers to questions it didn't know legal could answer.
If you want to play an instrument, you have to practice. If you want to get fit, you have to build a program. And if you want AI to actually work in your organization, you have to prepare for it first.
This was the consensus among legal operations leaders at CLOC 2026: successful AI initiatives require real preparation. That's the nature of change management, and there's no shortcut around it.
Stacy Lettie, VP of Global Legal Operations and Transformation at Organon, was very clear: "There is this urgency with AI. Everybody feels like they need to go out there and get a tool because that's going to make them feel better. Because they're going to feel like, well, we're doing something. We're out there. We're doing AI. We implemented this. We can go back and tell our CEO we are doing AI. But the data is showing adoption isn't as great as it needs to be."
That's the heart of the challenge. You can't announce that you're "doing AI" and expect people to follow. You have to lay the groundwork first.
Here are five things to do before you launch an AI initiative:
1. Define the problem before you buy a tool. You shouldn't be shopping for tools before you know what problems they need to solve. Alexander Shusterman, Staff Technical Program Manager, CLO AI, and Carolyn Wakulchik, Manager, CLO Operations— both from Uber— offered this: "Scope the risk area. What do you care about the most? If you ask everybody, they're going to tell you they want the sun, moon, and stars in the solution, and that is a surefire way to make sure that it doesn't work correctly. Better to start small and focus."
2. Get your data in order. AI is only as good as the data that fuels it. Stacy Lettie described the problem: "You have not gotten your data together. You have not cleaned your data. You have not even put all of your documents in one SharePoint folder, for gosh sakes. And you all of a sudden go, 'Oh wait, I can't do this, and now I've got to stop, and it's going to take me eighteen months to clean my data.'" Don't let this happen to you. Before anything else, make sure the data your AI will use is organized and accessible.
3. Build a governance framework. Guardrails aren't optional. They’re what make AI adoptable for the rest of the organization, and keep your company and your customers safe. Think through policies for accuracy, data protection, and appropriate use. Governance has to be implemented cross-functionally, so involve the right stakeholders early, and make it easy for team members to follow the policies you put in place.
4. Plan for change management. AI initiatives stall when no one owns adoption. Lawyers are risk-averse by training, and they won't use tools they don't understand or trust. Alexander Shusterman from Uber was very frank: "Just like any other legal operations project, the hardest part here is not the tech and it's not the prompting. It is actually the change management piece."
5. Agree on how you'll measure success. Before the initiative launches, define what success looks like, and get alignment from the executive team on those metrics. This discipline helps you scope the problem well and makes it much easier to demonstrate value in the future.
Successful AI initiatives don't happen by accident; they're built on preparation. These steps have been field-tested by legal operations leaders who've done the work. If you’re looking for a framework to start planning your AI projects, this is a good place to start.
Strava, the leading platform for movement, connects more than 195 million athletes across 185 countries. It helps people build new habits, hit new personal bests, and make progress together. More than a few of us on the Ivo team are among them, so we are thrilled that Strava will be joining Ivo as a customer.
Like many high-growth tech companies, Strava's legal team works with a high volume of contracts and a lean headcount. These companies must review more contracts with lean resources, and can’t sacrifice accuracy or quality of analysis. That is exactly the problem that Ivo solves.
We’re excited to be working with Strava’s legal team on the journey ahead.
Welcome, Strava!
Connect with us now to learn how we can streamline your contract review process
