We’ve been busy at Zuva! As part of a bunch of changes around publicly launching Zuva Analyze, we renamed a few of our products. This piece explains what we did, and why.
DocAI is now Zuva API
Followers of Zuva will know our first product, DocAI, an API-only solution designed to easily embed contracts AI into your applications.
We built DocAI because of a problem we saw time and time again in our Kira Systems days (followers of Zuva will also recall that Zuva is a spinoff of Kira Systems – we started with the same underlying technology): there was demand for contracts AI tech embedded in other systems (e.g., CLMs and homegrown repositories), but it takes a lot of effort to build high quality contracts AI. We have seen this trend towards contracts-AI-built-in-all-over play out lots in recent months. We also saw a need for tighter integrations across legaltech, and thought an API-first product could help enable that. However, on this second point, our forecast was very off (at least so far)! If anything, legaltech looks less likely to integrate than it did three years ago when we sold Kira, which surprises us.
Enter DocAI: Zuva’s contracts AI API. While there are other contracts AI APIs, they tend to exist as an extension of a UI system. Our experience has been that API features of UI systems tend to primarily exist to get documents and information into and out of the UI system, not work as a standalone that’s well built for building on top of. DocAI is different. It’s just an API, meant for developers (including “citizen developers” using low code tools like Power Automate or Tungsten Automation’s TotalAgility) to build with.
In the almost three years since Zuva came to be, there’s been a lot of excitement around DocAI’s flexibility. With DocAI’s easy-to-use API connectors, we’ve seen Zuva’s capabilities embedded into CLMs and homegrown contract management solutions, connected to storage solutions like Google Drive or SharePoint (check out this quick video from the team at Microsoft on how DocAI cut their legal team’s review time by 70%!), and even incorporated into dedicated contract management and workflow automation technology solutions (we love seeing the power of our API combined with tools like LawVu and Kofax’s TotalAgility).
At Zuva, we seek to provide great contracts AI that is dead easy to use. Our API product is dead easy for technical users to use. But its name could be simpler. We are happy to announce that DocAI is being renamed, “Zuva API”. The name Zuva API speaks for itself; it’s Zuva’s tech as an API-only product. Same core technology, same simplicity of use, just a simpler name to help clarify what Zuva API is.
AI Trainer and Answers Builder are now Zuva Create
Zuva comes knowing how to find over 1,300 data points in contracts, and automatically identify ~225 document types. But sometimes that’s not enough. Some users decide to build new models, or customize our existing ones. Over the years, between Kira and Zuva, we’ve seen our users build >20,000 additional models using our underlying tech. What’s really cool is that subject-matter-experts (i.e., lawyers) can do all the training work themselves, without assistance from data scientists or the like.
Shortly after our spinout, we rushed to get our “AI Trainer” product out, giving Zuva users a way to build new models. (They can also use our APIs to build new models, but this means building a training interface, and our experience has been that our UI training product is right for most users.) More recently, we realized that LLMs could be used to help solve a problem we had long struggled with: how to get our tech to not just find clauses, but interpret them too. This caused us to build an extension to AI Trainer called “Answers Builder,” which allows users to build answer models, which can interpret contract clauses, putting results into structured categories.
While these products are cool, we thought having two different training products might be confusing, so we decided to combine both and rename the combined version Zuva Create. Check it out!
Share this article:
