Build, Buy, or Build Together?

We surveyed 74 justice professionals about AI adoption. Here is what they told us, and why neither buying nor building alone is working.

Common Legal Help AI. Working draft for comment. Margaret Hagan, Stanford Legal Design Lab.

Legal aid organizations across the country are making high-stakes decisions about AI right now. Vendors are pitching tools for intake, legal research, and document drafting. Funders want to know what programs are doing with AI. Staff are experimenting with ChatGPT on their own. Most leaders feel stuck between two options: buy from a vendor, or build something in-house.

There is a third path. Before making that case, we wanted to understand how the field is actually thinking about these choices, so we surveyed 74 access to justice professionals: executive directors, technology directors, managing attorneys, court administrators, and others. The findings were striking.

The field is fragmented

When we asked how organizations are approaching AI adoption, no single model dominated. Nearly a quarter are still evaluating. Another quarter are going to vendors. The rest are split across mixing approaches, building in-house, and using open-source tools.

This fragmentation matters. The field is at an inflection point, and the choices being made now will shape justice technology infrastructure for years.

Both dominant paths scare people, for different reasons

We asked what worries people most about relying on vendors. The top answer, by far, was data privacy and security, at 70%. Legal aid work involves deeply sensitive client information, and many AI vendors have opaque data practices. Cost and quality rounded out the top three, and more than half the field is worried about whether vendor AI is accurate enough for the stakes involved.

The deeper problem is structural. When you sign a vendor contract, you are not just buying software, you are outsourcing institutional knowledge. If the vendor raises prices, pivots, or gets acquired, you lose both the tool and the capacity to replace it.

Building in-house appeals to organizations that want control, and the barriers are steep. Two-thirds of respondents said their organization simply does not have the technical staff. Nearly half said they cannot keep up with how fast AI is changing. And more than a third flagged the single-point-of-failure problem: when the one person who built the system leaves, nobody can maintain it.

One respondent put it bluntly:

There is a lot of hesitancy from legal staff. Many are not technical or computer savvy. So seeing what AI can do for them in real world context is paramount.

Technology Director, LSC-funded legal aid

There is a third path, and people want it

We described a commons model for legal AI: open-source shared infrastructure maintained by a dedicated team, a community of practice where organizations share what works, the ability to customize for local needs, and funded stewardship that does not depend on one volunteer. Three-quarters of respondents said they were open to it. Over half said they were very interested or interested.

This is not a hypothetical. The model already works in legal aid. Docassemble, the open-source document assembly platform created by Jonathan Pyle, and the Document Assembly Line project at Suffolk LIT Lab have proven that legal aid organizations will adopt and contribute to shared infrastructure when it is well-maintained, documented, and responsive to their needs. The open question is whether the model can work for AI, which is more complex, more expensive to run, and evolving faster than document assembly ever did.

Who is most enthusiastic

Interest varied dramatically by organization type. Legal aid organizations are the natural core constituency, with nearly 90% positive. Courts and libraries were more cautious. And vendors, the entities that profit from the current model, were the least enthusiastic about the alternative, at 14%.

As one court administrator explained:

Judges are still skeptical and wary of AI and would be more so about a community-driven approach at this point in time.

And one managing attorney offered the most direct counterpoint we received:

We are actively trying to turn off the AI that Google and other platforms force on us. Too many concerns about client data privacy, destruction of the environment, support of the billionaire overlords. Let's shut down AI.

These voices matter. Not everyone is ready for AI adoption, and a commons model must respect that. It is an option, not a mandate.

What would it take

We asked what conditions would need to be met for people to participate. The answers were practical, not ideological.

Show us it is compliant. Show us it is documented. Show us it works. These are solvable engineering and funding problems rather than fundamental objections. The conversion path is clear: skeptics want cost evidence, at 34%, while enthusiasts want to see a working example, at 50%. Demonstration, not persuasion, is what moves people.

What a commons should build first

Document assembly and drafting led the list, which is natural, since the field already has a successful open-source model there. But legal Q&A, intake screening, translation, and document extraction all clustered together in the high twenties to low thirties, which suggests broad demand across multiple AI use cases.

What we are building

The Legal Help Commons is our attempt to build this third path. We are organizing working groups around specific AI workflows: voice intake, building on open-source work by Lemma Legal and Virginia Legal Aid Society, knowledge base safety wrappers, and document extraction pipelines. JusticeBench provides the evaluation layer, the shared benchmarks and task taxonomies so the field can assess AI tools rigorously rather than relying on vendor claims or anecdotal impressions.

The key insight from this survey, and from our analysis of what has and has not worked in the past, is that a commons needs teeth, not just community. Conferences and cohorts build trust and alignment, but trust without shared measurable assets is just good feelings that evaporate between meetings. The commons needs shared benchmarks, tested reference architectures, and published evaluations at its center, not just conversations.

What you can do

If you are an executive director who has been pitched by three AI vendors this month, then before you sign, ask whether an open-source alternative exists. For document assembly, the answer is already yes. For AI use cases, the ecosystem is emerging.

If you have a developer building AI tools in-house, ask whether the work is being shared. The impulse to build is valuable. But if the work is trapped inside one organization, it is fragile and duplicative.

If you are a funder, shared infrastructure needs shared funding. The LSC TIG program has invested over $95 million in legal aid technology and seeded the individual projects that prove what is possible, and the next dollar goes further when it also funds the maintenance, the standards, and the tested tools that many organizations can build on at once.

If you want to join, the working groups are open, and you do not need to be a technologist to participate.

The bottom line

The legal aid field has been here before. When document assembly emerged, some programs bought proprietary tools, some built their own, and some joined an open-source community. The organizations that joined the community got the best outcome. AI is the same choice at higher stakes and faster speed. Three-quarters of practitioners we surveyed are ready to try the third path. The infrastructure is being built. The question is whether enough of us will commit to building it together.

A fuller version of this analysis is forthcoming in the MIE Journal.