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.
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.