AI Esquire
Menu
Plans from $497/monthBuy Intake AI
Court technology · AI governance · Judicial administration

The Court Bought the Servers. It Also Bought the Risk.

A courthouse in Gretna, Louisiana, has purchased two artificial-intelligence servers, upgraded the power and cooling in its server room, and begun helping technologists translate court work into software. That is more interesting than another announcement that a judge tried a chatbot. The Louisiana Fifth Circuit Court of Appeal is attempting to own part of the technical stack on which future court operations may depend. Its stated plan is cautious: begin with filing compliance and document intake, test open-weight models locally, keep experimenting with commercial products, and treat AI as augmentation rather than adjudication. The ambition deserves attention. So does the consequence. When a court brings AI inside the courthouse, privacy and vendor dependence may improve. Responsibility does not disappear. It changes address.

This is an infrastructure decision, not a chatbot trial

Chief Judge Susan Chehardy and Judge Scott Schlegel described the project in an October 20 post. The court purchased two AI servers and related equipment, including additional power and improved air conditioning. It partnered with the nonprofit ALEA Institute to develop applications using an open-weight model running on that hardware. Reuters later reported that the Dell servers use Nvidia chips and cost about $65,000 each at the time of purchase.

The distinction between using an AI product and operating AI infrastructure matters. A subscription places much of the operational burden on a vendor. Running a model locally gives an institution greater control over data movement, configuration, retention, updates, and access. It can also reduce dependence on a provider whose pricing, terms, product design, or availability may change.

But local control is not synonymous with safety. The courthouse now has to decide who can access the system, which models and versions may run, what data may enter, how outputs are logged, when patches are installed, what happens after a security incident, and when an application is too unreliable to remain in service. Those are policy decisions expressed through technical administration.

The court is therefore doing more than buying equipment. It is accepting a continuing institutional role that commercial software usually obscures. Ownership makes responsibility more visible. It does not make responsibility smaller.

Keeping the model in the courthouse may reduce one category of dependence. It also turns maintenance, testing, and security into court functions.

The project starts where court technology should start: with the work

The judges say the project began with interviews and questionnaires for court employees. Staff members explained how filings move through the institution, which decisions recur, what experienced clerks notice, and where workarounds have become routine. Only then did the development team begin translating that knowledge into possible applications.

That order is easy to praise and surprisingly rare. Technology projects often begin with a product demonstration and end with employees rearranging their work around the tool. This project begins with tacit institutional knowledge. A clerk may recognize a missing exhibit or procedural irregularity without being able to reduce the recognition immediately to a written rule. Designing around that expertise forces the court to identify where judgment actually enters the process.

The first planned uses are filing compliance and intake, bookmarking pleadings and records, classification, and routing. Those tasks are less dramatic than drafting an opinion, but they are consequential. A system that misclassifies a filing, overlooks an attachment, or routes a document incorrectly can delay review without ever generating a fake citation. Administrative error is still legal-system error when it changes who sees a filing and when.

The operational discipline is to define the task narrowly enough to test it. A useful evaluation is not whether a model appears intelligent. It is whether the application reliably performs a specified function on representative court material, exposes uncertainty, preserves the original record, and routes exceptions to a human who has authority to act.

Bench memoranda change the accountability question

The court may eventually explore AI assistance with neutral bench memoranda. That is the point at which a workflow tool begins to approach legal analysis. A bench memorandum does not decide a case, but it can frame the facts, authorities, unresolved questions, and perceived weaknesses that a judge encounters before a hearing or ruling.

Federal judiciary guidance offers a useful boundary. It cautions against delegating core judicial functions, including decision-making and adjudication, recommends independent verification of AI output, asks courts to consider disclosure, and encourages institutions to define the tasks for which approved AI tools may be used. The Louisiana project is a state initiative, but the underlying governance questions are the same.

A locally operated system does not answer them automatically. Courts will need rules for source grounding, citation verification, access to sealed material, version control, retention of prompts and outputs, correction of discovered errors, and review of unequal performance across case types. They also need to decide what belongs in an administrative record when AI materially shapes an internal work product.

The most important safeguard is not a general promise that humans remain in the loop. It is a defined allocation of responsibility. Which employee reviews the output? What must that review include? Can the reviewer reconstruct the source material and model version? Who can stop use after a failure? A human signature means little if the institution has not specified what the human is expected to know.

A human in the loop is not a governance plan until the institution defines the human's authority, evidence, and duty of review.

Local AI creates a maintenance constitution

Models change even when the legal rules do not. An updated model may summarize better, refuse more often, follow hidden instructions differently, or behave less predictably on a narrow document class. A court that operates its own stack needs a controlled process for approving versions, testing changes, documenting performance, and rolling back when results degrade.

Security is equally concrete. Court filings are adversarial inputs. Some are wrong by accident; others may be crafted to influence a reader or a system. The judges have identified possible future tools for flagging nonexistent cases and detecting hidden instructions designed to manipulate AI. That is sensible, but it creates an arms race inside a public institution. Detection tools themselves require testing, updating, and limits on false accusations.

NIST treats secure and resilient operation as a core characteristic of trustworthy AI and recommends managing risk across the system lifecycle. For a court, lifecycle governance should include inventories of models and applications, permissions tied to job roles, logging that respects confidentiality, incident reporting, independent evaluation, change approval, recovery procedures, and a retirement plan. A server purchase is capital expenditure. Trustworthy operation is recurring labor.

There is also a procurement lesson for law firms. Bringing a model in-house can be justified by sensitive data, customization, economics, or control. It should not be sold internally as escape from governance. The organization has instead chosen to become part vendor, part evaluator, and part security operator. Its budget and staffing should reflect that choice.

The experiment is valuable because it admits that it is an experiment

The judges do not describe a completed transformation. They say development has begun, some ideas may prove harder than expected, and some tasks may be better handled by traditional software. They intend to learn through testing rather than confuse a compelling demonstration with a dependable court application. That restraint is the strongest reason to take the project seriously.

Courts need room to improve systems that are slow, repetitive, and difficult for the public to navigate. Refusing all experimentation would preserve familiar failures. But judicial institutions carry a distinctive burden. Their internal tools influence the timing, framing, and quality of decisions backed by public authority. Efficiency cannot be the only measure of success.

The Louisiana Fifth Circuit has chosen a revealing path. By owning the infrastructure, it may gain unusual visibility into how models behave and how court knowledge becomes software. That can produce better governance than a black-box subscription. It can also expose how much work governance really is.

The project should be judged by what the court can demonstrate over time: narrowly defined uses, measured error rates, documented human review, secure handling of case material, transparent boundaries, and a willingness to turn off tools that do not earn institutional trust. The servers are the easy part. The public system built around them is the real experiment.

Sources and further reading

Primary and industry sources used to support this page. External guidance should be reviewed in context and for your jurisdiction.

  1. Building AI Inside the CourthouseOctober 20, 2026 account by Chief Judge Susan Chehardy and Judge Scott Schlegel describing the court's servers, open-weight model, staff interviews, intended applications, and experimental posture.
  2. Reuters: Louisiana court buys AI serversOctober 22, 2026 reporting on the equipment, cost, development partnership, and planned court applications.
  3. Federal judiciary interim AI guidepostsOfficial federal judiciary summary addressing delegation, verification, disclosure, accountability, and task-specific approval for judicial AI use.
  4. NIST AI RMF Generative AI ProfileOfficial cross-sector framework for governing, mapping, measuring, and managing generative-AI risk across the lifecycle.
  5. NIST AI security and resilienceOfficial NIST research and guidance emphasizing secure and resilient AI systems as a condition of trustworthiness.
The AI Esquire Journal

The server is only the beginning.

Attorney-led analysis of courts, technology, professional responsibility, law-firm operations, and the systems through which legal judgment is delivered.

Read the journalAbout AI Esquire