Sarah Webb（LawVu COO 兼聯合創辦人）訪談

Sarah Webb is COO and Co-Founder of LawVu, bringing a background in engineering and software leadership that includes roles at LOVEFiLM and Amazon. She joined LawVu as CTO in 2015 and became COO in 2020, combining experience across technology, operations, security, and governance. Her work focuses on helping legal teams connect their data and workflows while balancing AI innovation with enterprise risk.

LawVu provides a legal operating system for in-house legal teams, bringing intake, matters, contracts, spend, and knowledge into a connected platform. Its AI capabilities and integrations help teams work across their existing tools while maintaining permissions and oversight. In this interview, Webb discusses shadow AI, agentic workflows, institutional knowledge, and the foundations enterprises need for governed AI adoption.

You co-founded LawVu after spending much of your career building and leading software teams, including at LOVEFiLM and Amazon. What led you to identify corporate legal operations as a problem worth solving, and how has your original vision for LawVu evolved as AI has transformed the technology landscape?

I spent most of my early career in engineering and technology roles, including LOVEFiLM and Amazon, and the move into legal tech wasn’t something I set out to do, it happened more by circumstance. I’ve been at LawVu for almost 11 years now, originally as CTO, but with a fairly quick move to COO, and that shift alone has changed a lot about how I think about the business.

In the early days, the first problem we were solving for was visibility. Most customers were coming off Outlook and Excel spreadsheets, and just getting everything into one place felt like a real win. Then we moved into a period where teams went remote, and without a centralized platform, collaboration got even harder. That reinforced something we were already seeing, which is that a lot of repetitive legal work wasn’t being valued or even seen by the rest of the business, because there was nowhere for it to be visible. That period pushed us to do real education work with customers on how to structure their data and manage the change internally, not just hand them a tool.

We also built out integrations across the Microsoft suite early on, because the goal was always to meet the business where it already worked day to day, rather than asking teams to abandon what they knew. What’s changed since then is the scale of what that same idea now demands. Reducing the barrier to entry to get a usable dataset used to be about convenience. Now it’s the difference between AI that can actually act on legal work and AI that’s just reflecting the same fragmentation back at you.

You’ve argued that “shadow AI” is often a workflow problem rather than an employee problem. What does that mean in practice, and what can organizations learn when employees bypass approved AI tools or systems in favor of their own solutions?

If you don’t make the right tooling available internally, people will go find their own for the efficiency gains. That’s the root of it. When someone bypasses an approved system, the instinct is to treat it as a compliance failure, something to lock down or write a policy against. In practice, it’s usually telling you something about the workflow itself, that the approved path was slower or more painful than the alternative, so people found their own way around it.

That’s exactly why shadow AI is a bigger liability than shadow IT ever was. Incidents involving shadow AI now account for 20 percent of data breaches, at an average cost of 10.2 million dollars, because people aren’t just adopting an unapproved tool, they’re feeding it the sensitive material directly, contract language, deal terms, internal reasoning.

What organizations should actually learn from this is where the gap is. The absence of a secure, grounded alternative doesn’t stop people from turning to AI, it just pushes them toward doing it somewhere you can’t see. And there’s a deeper risk underneath that, one that goes beyond security. When work is scattered across personal AI tools instead of a shared, structured system, the business ends up making decisions on an incomplete picture, without even realizing part of the picture is missing. If an AI tool can only see 60 percent of the relevant data because the rest is sitting in someone’s own account, its accuracy drops and the risk of a wrong call goes up. Banning the workaround doesn’t fix any of that. Giving people something better than the workaround does.

Through LawVu’s work with hundreds of enterprise legal teams, what are the most common mistakes you see organizations making when establishing AI governance, particularly as employees gain access to increasingly powerful general-purpose AI tools?

The most common one is mistaking a written policy for an actual control. Plenty of organizations have a document now that says how AI should and shouldn’t be used. Very few have built anything operational behind it, something that actually governs what a tool can access, logs what it did, and lets you reconstruct that afterward if you ever need to.

The second mistake is not accounting for how much risk gets added one tool at a time. Every point solution a team adopts, whether it’s for contracts, spend, or intake, requires its own integration, keeps its own authentication protocol, and holds its own copy of sensitive data. Individually each one seems manageable. Together they turn the legal tech stack into a fragmented nexus of risk, and more than a third of breaches trace back to exactly that kind of third-party access. Most teams don’t realize how much that adds up until they’re the one being reviewed after something’s gone wrong.

The third is treating general-purpose AI tools differently from every other piece of software that touches sensitive data. Every customer we’ve worked with since day one, including government clients, has gone through a full security assessment with us, because what ends up in a system like ours is some of the most sensitive information a company holds, trade secrets, M&A data, PII. Employees are handing that same kind of information to public AI tools every day without anywhere near that level of scrutiny, because it doesn’t feel like adopting a new vendor, it feels like using a tool. That gap between what gets audited and what actually holds risk is where most governance programs fall apart.

LawVu has been incorporating AI agents and agentic workflows into legal operations. How do you determine which legal processes are appropriate for autonomous AI execution and which should always require human review or approval?

We look at impact and reversibility more than how complicated a process looks on paper. If a mistake is cheap to catch and easy to undo, that’s usually a good candidate for autonomy, which is why high-volume, well-defined work like intake and triage tends to fit well.

Anything touching an external commitment, legal exposure, or a decision that’s hard to unwind gets a human in the loop, no matter how accurate the agent looks in testing. It’s the same logic behind how we think about risk tolerance more broadly at LawVu. We figure out what a team can live with, put the right controls around it, and only then open it up further. The real test isn’t accuracy, it’s whether we can say what the agent accessed, why it took that action, whether it was authorized to, and whether we can prove it afterward. If we can’t answer those, the process isn’t ready to run on its own yet.

These decisions aren’t ‘one and done’; a process that’s safe to automate today can stop being safe as usage scales or the workflow starts touching more sensitive material than it did at the start, so the line needs revisiting, not just drawing once.

LawVu’s MCP server allows organizations to connect tools such as ChatGPT, Claude, and Microsoft Copilot directly to their legal operating environment. How can companies give external AI systems useful access to enterprise data while still maintaining permissions, auditability, privacy, and control?

The instinct is to think connected and secure are in tension, but they don’t have to be. The platform has to stay the source of truth for permissions, not the AI tool sitting on top of it. Whether someone starts a conversation in ChatGPT, Claude, or Copilot, what they’re allowed to see and do shouldn’t change based on which interface they happened to open that day.

That only works if the environment on the other end already has the right controls in place before you connect anything, which is exactly the groundwork most companies skip. Everyone treats MCP as an automatic security win because less data is moving around, and that’s true, but only if the receiving system can say what was accessed, why, and by which agent on whose behalf, and prove it after the fact.

There’s a business case here too. If the central AI tool can recognize when a request has a legal dimension and route it into LawVu automatically, that removes the back and forth of an employee having to know which system to go to in the first place. It also means they’re not reaching for a personal AI tool that has no access to a grounded, secure dataset at all. Giving people one well-governed starting point ends up doing more for adoption than locking everything down ever would.

General-purpose AI models may be powerful, but they often lack an organization’s institutional memory, historical decisions, and specific risk profile. What information and infrastructure need to surround an AI model before it can become genuinely useful for high-stakes enterprise work?

I think about horizontal AI as a brilliant stranger, someone who has read an extraordinary amount, writes beautifully, and can hold a conversation about almost anything. But they’ve never met your client. They’ve never sat in your negotiations. They don’t know how your organisation balances risk. They’ve never seen the conversations that led to the exceptions your team agreed six months ago.

That’s why one of the first things many legal teams do is connect AI to a playbook, and to be clear, that’s incredibly valuable. Give an AI model access to your preferred clauses, fallback positions, approval thresholds and negotiation guidance, and the efficiency gains appear almost immediately. The challenge is that the most important legal decisions often happen when the standard position no longer fits: a strategic customer needs an exception, a high-growth opportunity justifies additional risk, a negotiation reaches a point where commercial priorities outweigh the preferred clause.

That’s where legal judgement starts to become visible. Some of the most valuable knowledge is stored in the exceptions, not the playbook. Why did we make an exception for this customer? What happened the last time we negotiated this position with the same counterparty? Has the business accepted this risk elsewhere? Was this issue escalated previously, and what was ultimately decided?

The answers rarely live in a single document, they’re scattered across contracts, approvals, emails, matter records, meeting notes and the accumulated experience of the people who were involved at the time. The document simply records the outcome, and the organization carries the reasoning elsewhere.

A brilliant stranger can learn the rules remarkably quickly, but understanding why the rules were bent in the first place is a different challenge altogether. What usually separates useful AI from transformative AI is how much of its own experience the organization has preserved for AI to learn from.

Many companies have accumulated disconnected contract systems, matter-management tools, spreadsheets, email archives, and other sources of enterprise knowledge. How important is having a unified data foundation before deploying AI agents, and what does an organization need to do to make its data truly AI-ready?

Legal is the perfect example of why this matters: contracts are redlined in Word, approvals come through email, decisions happen over Slack, and then AI gets layered on top of the document repository instead of actually connecting the work. Dropping AI on top of a fragmented system is just faster access to chaos.

The companies that spent years building real data infrastructure and getting their systems in order before AI arrived are the ones where AI is already paying off. That’s really the core of it. You can’t scale agents on top of disconnected contract systems, matter-management tools, spreadsheets, and email archives and expect trustworthy results. The foundation has to come first: connected systems, clear access controls, and defined risk tolerance, before you can even think about scaling AI.

As enterprises evaluate whether to build their own AI applications, purchase specialized AI platforms, or connect general-purpose models to existing systems, how should technology leaders think about the build-versus-buy-versus-integrate decision?

Build vs. buy sounds like a technology decision. In my experience, it’s really a legal operations maturity question. It’s about how seriously a legal team is treating itself as a function, with its own workflows, data, and operating model. Get that maturity piece right, and the right legal AI strategy tends to follow on its own.

On build: for the handful of teams with the resources to operate like a software company, it can make sense. Models evolve, infrastructure changes, and the work never really finishes. For most teams, the challenge isn’t building it once, it’s maintaining it forever.

On buy: most teams land here, but “buy” isn’t one option. It’s at least three different things people lump together. Horizontal AI, like ChatGPT, Copilot, and Claude, is powerful but doesn’t inherently understand matter structures, intake, or approval workflows. AI connected to a single point solution, through something like MCP, is a meaningful step forward, but its view is still constrained to whatever exists in that one system.

The bigger opportunity is AI that understands how legal work connects across the function, not just what happens within any one tool. When intake, matters, contracts, spend, and knowledge all sit together, AI can reason across the full picture instead of a single slice of it.

You have served in both CTO and COO roles at LawVu, giving you responsibility across technology, operations, security, and product execution. How has that combination shaped your approach to balancing rapid AI innovation against security, compliance, reliability, and enterprise risk?

I joined LawVu as CTO in 2015 and took on the COO role in 2020, so I’ve spent over a decade sitting across both technology and operations.

That combination changes how you think about AI innovation versus security and compliance, because you don’t experience them as separate conversations. Owning governance, risk, and compliance internally, while also building a platform that helps customers manage those same functions, means I can’t treat innovation and security as sequential steps, one doesn’t come after the other, they happen at the same time or not at all. Every customer we’ve had since day one has gone through a full security assessment, and every time you add a new tool to your ecosystem, you’re increasing the risk landscape around that data. That’s as true internally for us as it is for our customers, so building the thing and being accountable for how it’s governed forces you to hold both at once.

Looking ahead, how do you expect agentic AI to change the role of corporate legal teams? Do you see legal departments primarily using AI as a productivity layer, or could they eventually become supervisors of largely autonomous workflows operating across the broader enterprise?

Generative AI has shifted the conversation from incremental efficiency to fundamentally rethinking how legal work gets done, and what the operating model needs to look like in a world that’s moving quickly toward agentic capability. I think about agentic AI not as hype, but as an execution layer that can help legal move from managing work to actively executing it, with the right controls and guardrails in place.

There’s a “front door” shift happening across organizations right now: business users increasingly start with tools like Microsoft Copilot or Claude, and the question becomes how legal ensures those interactions are connected to the right systems, the right data, and the right workflows.

So I don’t see it as a productivity layer versus supervisor, I see it as a progression. Legal starts by using AI to move faster on individual tasks, but as agentic capability matures, the real opportunity is legal owning the execution layer itself, actively executing work through governed systems rather than just producing faster first drafts.

Thank you for the great interview, readers who wish to explore connected legal operations and governed AI workflows should visit LawVu.