Meet Plexus Counsel, your new AI-powered digital lawyer > See it in action
Manage all legal work in one AI powered platform.
Discover moreYour new team member, available 24/7.
Learn moreWHY PLEXUS
Calculate hours and budget savings in just two mins
Discover moreTOOLS & TEMPLATES
Our people are building the future of legal work
Take a lookGET IN TOUCH
LATEST NEWS
adsflkshdflhasdf
June 02, 2026
CONTENTS
or
Most legal AI programmes stall. The technology does not fail. The implementation does.
The Plexus Future-Ready General Counsel 2026 survey of 150 GCs found that the overwhelming majority of legal teams have engaged with AI in some form. Fewer than 7% have fully operationalised it. The distance between those two numbers is not explained by a shortage of compelling AI tools. It is explained by a set of identifiable, avoidable implementation traps that legal teams fall into, often simultaneously, and that reinforce each other in ways that make forward progress feel impossible.
We have mapped fifteen of these traps. The pattern that appears most consistently is not that teams fall into one. They fall into three or four at once, and each one makes the others harder to escape. That is the doom loop.
Here is what the most common traps look like, why they are so persistent, and what the teams that have broken out have done differently.
Believing a generalist tool is sufficient to check the AI box
This trap is the belief that deploying a general-purpose AI assistant, most commonly Microsoft Copilot, constitutes an AI strategy for the legal function. The tool is acquired, legal is included in the enterprise rollout, and the GC can truthfully say that the team has access to AI. The box is checked. Nothing changes.
Generalist AI tools are designed for productivity at scale across an entire organisation. They are not designed for legal accuracy at the level that in-house work requires. A tool that describes itself as "for entertainment purposes only" in its own terms of service cannot be the foundation of a legal AI strategy. But because it exists and it is paid for, it becomes a reason not to look for something better.
Formalise the distinction between productivity AI and legal AI in your AI strategy. Copilot has a legitimate role in administrative productivity. That role is not legal work. Once that distinction is documented and agreed, the conversation about purpose-built legal AI becomes much easier to have.
Running endless proofs of concept instead of deploying, learning, and iterating
A pilot that was designed to run for six weeks has been running for fourteen months. Success criteria were never clearly defined. The pilot is being used to avoid a decision rather than to inform one. There is always one more question to answer, one more use case to test, before the organisation is ready to commit.
Pilots are safe. They carry no long-term commitment, no full budget exposure, and no accountability for outcomes. They can be pointed to as evidence of progress without requiring any of the organisational work that real progress demands. Some legal teams have run pilots with multiple vendors simultaneously for extended periods, not because they needed the comparison, but because the act of piloting deferred the decision.
Define success criteria before the pilot starts. Document in advance: what metric, at what threshold, within what timeframe, will trigger a decision to scale. Agree on this before the pilot begins, not after the results are in. Set a hard end date. The absence of a pre-agreed decision framework is almost always the reason a pilot does not end.
Waiting for the perfect tool while the business fills the vacuum
The team is evaluating. They have been evaluating for eighteen months. There are twelve vendors on the longlist. The evaluation criteria keep expanding. Meanwhile, the business units that generated the original demand for legal AI support have found their own solutions, most of which are ungoverned consumer AI tools, and have started building habits around them that are much harder to change than the original problem would have been to solve.
Legal teams are trained to be thorough. That thoroughness is professionally appropriate and genuinely valuable in most contexts. In the context of AI tool selection, it creates a perfectionism trap. The perfect tool does not exist. The tool that exists today and is deployed now is worth substantially more than the perfect tool that will be selected in eighteen months.
Accept that iteration is better than perfection. Set a maximum evaluation timeline, typically three months from shortlist to decision, and commit to it. The first platform deployed will be imperfect. Twelve months of using an imperfect platform and iterating on it produces better outcomes than twelve months of evaluating the perfect one.
Delegating AI strategy to someone without authority or AI literacy
The AI strategy has been handed to a junior team member as a development opportunity. Or it has been passed to IT as a technology project. In either case, the person nominally responsible for legal AI does not have the authority to make platform decisions, the budget to act on them, or the legal context to evaluate options intelligently.
AI strategy in a legal function is not a technology project. It is a legal operations transformation that happens to involve technology. It requires someone who understands both the legal work and the organisational dynamics, and who has the authority to make decisions that affect how the function operates. When that ownership sits in the wrong place, every meaningful decision escalates back to the GC, who is too busy to engage with it consistently.
The GC must own legal AI strategy directly, or appoint a named owner with genuine authority, a reporting line to the GC, and a ring-fenced budget to act on their decisions. This person does not need to be the most technically sophisticated person in the team. They need to understand the legal work, have credibility with the team, and have the authority to make and hold to decisions.
No ring-fenced budget or bandwidth for what adoption actually requires
AI adoption is being asked to happen on top of existing workloads, in the gaps between everything else. There is no dedicated time, no protected budget, and no acknowledgement that implementation requires real effort from real people who are already doing full-time jobs.
This is the most common reason implementations stall after the initial excitement. The platform is procured. The kick-off happens. And then the implementation work, data migration, workflow design, user training, change management, is distributed across a team that has no capacity to absorb it. Progress slows. Momentum dissipates. The platform sits partially deployed for months, then quietly de-prioritised.
Treat AI implementation as a programme with its own budget line, resourcing plan, and protected timeline. This typically means ring-fencing a portion of at least one team member's time for the implementation period, and resisting the pressure to add them back to the full workload until implementation is complete. The investment in protected implementation time is almost always recovered within the first six months of full deployment.
Deploying AI on a broken operating model
AI increases throughput. It does not fix a broken foundation. If matter intake is a shared inbox and contract tracking is a spreadsheet, deploying AI on top of that does not fix the intake or the tracking. It makes a broken process faster, which can actually make the problems harder to see because the superficial speed improvement creates the impression of progress.
Teams that have not yet centralised their legal work into a structured platform often find that AI outputs are unreliable or unusable because the underlying data is inconsistent, incomplete, or inaccessible. The AI has nothing to work with. The solution, better data infrastructure, feels like a prerequisite that pushes the AI benefit even further into the future.
Matter management and contract lifecycle management are prerequisites for AI, not alternatives to it. The sequence is: centralise first, then automate. Teams that try to reverse this sequence almost always end up revisiting the data infrastructure problem after their AI implementation fails to perform.
Letting IT own the legal technology roadmap
The legal AI evaluation is complete. The platform has been selected. The business case has been approved. And then IT raises a security concern, a procurement requirement, or an integration constraint that was not in scope during the evaluation, and the implementation stalls for months while the issue is resolved.
IT and legal have legitimately different incentives. IT prioritises consistency, security, and manageability across the enterprise. Legal prioritises accuracy, adoption, and workflow fit for the legal function. When IT owns the legal technology decision, the result is frequently technology that IT can manage rather than technology that legal can use.
Involve IT and InfoSec in the first month of evaluation, not the last. Establish the non-negotiable technical requirements, data residency, security certification, integration capability, at the outset and make them part of the vendor brief. Teams that bring IT into the conversation early avoid the late-stage veto. Those that treat IT as a final sign-off hurdle consistently hit it.
Using risk requirements as a reason not to start
Governance is important. Explainability, audit trail, data classification, and escalation paths all matter in a legal context. The trap is treating unresolved governance questions as a reason not to deploy rather than as a design requirement to meet during deployment. Every legitimate AI platform has answers to these questions. The conversation about them does not need to precede deployment. It should happen alongside it.
Governance frameworks, when positioned as prerequisites, tend to expand. New questions arise. Edge cases are identified. The scope of what needs to be resolved before deployment grows faster than the resolution process. The result is a governance conversation that has been running for a year and a legal AI deployment that has not started.
The organisations generating the most value from legal AI built governance into their deployment from day one, not as a prerequisite to it. Start with the highest-volume, lowest-risk use case. Define the governance requirements for that specific use case. Deploy. Measure. Extend to the next use case. Governance grows with the deployment, rather than blocking it.
What makes the doom loop so persistent is that each trap reinforces the others. Pilot paralysis leads to analysis paralysis. Under-resourcing creates the conditions for abdication of ownership. The IT veto enables the business to fill the vacuum with ungoverned AI, which then becomes the justification for treating governance as a brake.
Breaking out requires addressing the traps systemically, not one at a time. The teams that have done it share consistent characteristics: a written strategy with a named owner, ring-fenced resource, a pre-agreed decision framework for the pilot, IT in the room from the start, and governance designed alongside the deployment rather than before it.
The organisations that have broken the loop are not doing fundamentally different things from the ones still inside it. They just started, and they did not stop.
The clearest indicator is the length of your evaluation or pilot phase relative to the decisions it has produced. If you have been evaluating or piloting AI for more than six months without a clear deployment decision, you are in the loop. Secondary indicators include: AI ownership sitting with someone who cannot make a platform decision, governance conversations that have been running longer than the implementation itself, and a growing number of business units using consumer AI tools for legal questions.
Define success criteria before the pilot starts. Document in advance what metric, at what threshold, within what timeframe, constitutes a successful result that triggers a scale decision. This turns the pilot from an indefinite evaluation into a bounded experiment with a clear endpoint. The absence of pre-agreed decision criteria is the primary reason pilots do not end.
Governance delays typically occur when governance requirements are scoped as a blanket prerequisite for all AI use cases rather than being calibrated to specific use cases. A promotional T&C review has different governance requirements from an M&A advisory matter. Starting with governance designed for the first use case, rather than governance designed for every conceivable future use case, removes the most common source of pre-deployment delay.
Teams that address the structural causes systematically, rather than treating each trap as a separate problem, typically move from the decision to change to a fully operational first use case within four to six months. The traps are interconnected, and solving them together, through a written strategy with named ownership, ring-fenced resource, IT involved from the start, and governance alongside the deployment, produces faster results than addressing them sequentially.
The key capabilities to evaluate are: context accumulation (does the system improve with use?), workflow coverage (does it span the full matter lifecycle from intake to closure?), integration architecture (can it connect to existing systems without significant custom development?), and data portability (if you change platforms, can you take your accumulated context with you?). Platforms that score well on all four are built for compounding returns. Those that score well only on task speed are sophisticated point tools.
Source: Plexus Future-Ready General Counsel 2026 Survey, n=150 General Counsels, January 2026. External citations: Thomson Reuters Generative AI in Professional Services Report 2025; ACC/Everlaw GenAI Survey 2025, n=657; Gartner Legal and Compliance Leader research 2025.
Ready to find out where your team sits on the maturity spectrum? Take the AI maturity assessment or explore the Plexus platform.
Andrew Mellett is the Founder and CEO of Plexus, a global leader in AI-powered legal technology. Recognised by the Financial Times and Harvard Business Review for his pioneering work in legal innovation, Andrew leads Plexus’s mission to train digital lawyers, helping the world’s top companies streamline legal operations and scale expertise with artificial intelligence.
Faster reviews, self-service for business teams, and smarter compliance in every workflow.
Cadell Falconer
As Head of Product at Plexus, Cadell Falconer brin...
Legal news, innovation and insights delivered straight to your inbox.
.svg){kind=small}
.svg){kind=small}
