Legal Practices Bought the AI. They Did Not Buy the Infrastructure It Needs to Work.

The Software Is Installed. It Is Waiting.

At some point in 2024 or 2025, a procurement decision was made. A vendor gave a demo. Someone came back from a conference persuaded that the organization needed an AI-powered document management system, a predictive analytics platform, or a compliance automation tool. The budget was approved. The contract was signed. The onboarding call happened.

The software is installed. It is waiting.

It is waiting because the documents it was supposed to analyze are scanned PDFs from 2011 that were never run through OCR. It is waiting because the case data it was supposed to pull from lives in three systems that do not communicate with each other, entered under naming conventions that made sense to one paralegal in 2016 and nobody else since. It is waiting because the matter-type field contains values including “civil,” “Civil,” “civ,” “civil matter,” “CM,” “N/A,” and, in eleven records, the word “misc” followed by initials that correspond to a staff member who left in 2022.

The status field, in at least one review Clutch Justice has been made aware of, contained the entry: “ask Denise.”

Denise retired in March.

This is not sector-specific. It appears in legal aid organizations trying to deploy intake automation on case records that predate their current database by a decade. It appears in county agencies attempting to integrate predictive tools on compliance data that was never standardized across field offices. It appears in mid-size law firms that purchased contract review AI and are now confronting the reality that a meaningful portion of their historical agreements are scanned sideways, filed under partner names that no longer work at the firm, in a shared drive that IT has flagged as over storage limit since 2023.

The technology acquisition happened years ahead of the institutional readiness to use it. The gap between those two things is not a software problem. It is an accountability problem, and it is the same kind of problem this platform documents in Michigan courts and public agencies every week.

What Institutional Data Failure Actually Looks Like

The phrase “messy data” understates what is happening in most of these environments. Messy implies a temporary state of disorder. What most legal and public sector institutions have is structural fragility: records built incrementally over decades, by different staff under different leadership, with no governing logic that survived any of the transitions between them. Several failure patterns appear consistently enough to name them.

The Person Who Is the System

Every institution has at least one. This is the staff member who has maintained a critical operational record for so long that the process exists entirely in their head. The record is accurate. It is updated on a schedule only they know. It uses categories and shorthand only they can interpret. When asked to describe the process, they describe it as straightforward. When they leave, the organization discovers that “straightforward” was doing an enormous amount of work in that sentence.

The Spreadsheet That Runs Everything

This spreadsheet was built by someone who has not worked at the organization in years. It was passed from person to person with no documentation of its logic, no version control, and no backup protocol. It contains formulas that reference tabs that no longer exist. It has columns that have not been updated in three years but that everyone is afraid to delete because no one is certain they are not load-bearing. It is the single authoritative record for something that should never be tracked in a spreadsheet.

It is maintained by one person. That person has been making noises about retirement since 2024.

The organization bought an AI tool to automate the reporting that currently runs through this spreadsheet. The AI tool cannot read it. This is because the spreadsheet was never designed to be machine-readable. It was designed to be interpretable by the person who built it, communicated to successors through a thirty-minute verbal walkthrough, and held together through years of manual corrections that never made it into any documentation anyone else can find.

The Taxonomy Nobody Designed

Case types, matter categories, violation codes, service classifications: every legal and public sector organization tracks some version of these. In functional records systems, these categories are standardized, documented, and applied consistently. In most institutions reviewed through forensic systems work, they are the accumulated product of a decade of staff preferences, three software migrations, and four reorganizations, applied inconsistently across thousands of records, with no crosswalk document explaining what any legacy category maps to now.

Running analytics on this dataset produces outputs that look precise. They are measuring the inconsistency, not the underlying reality. The AI model is not hallucinating. It is accurately reporting on what it was handed.

The Compliance Record That Is Not a Record

The institution is required, by statute, contract, or grant obligation, to maintain certain records. Those records technically exist. They exist as emails in someone’s inbox. They exist as notes in a shared folder with no naming convention. They exist as entries in a system that was deprecated two platforms ago and can no longer export its own data. They exist as the institutional memory of people who are no longer employed there.

When a FOIA request arrives, or a compliance audit, or discovery in active litigation, the institution discovers that “we kept records” and “we can produce records” are two different statements with very different operational implications. The distance between them is where liability lives.

The Diagnostic: What to Actually Do About It

Organizations that recognize themselves in the patterns above have a concrete remediation path. It does not begin with another software purchase. It begins with a structured audit of what the institution actually has, where it lives, who is responsible for it, and what the failure mode is when any one of those things changes. The following is the minimum viable version of that diagnostic.

Step One: Data Inventory and Ownership Mapping

Identify every critical record category the institution maintains, formal and informal. For each one, document the actual source of the data, not the system it is supposed to live in but where it actually lives. Document who maintains it, the update frequency, the format, and the access controls. This exercise almost always produces records that exist outside any institutional system: in a personal inbox, a shared drive with no governance, a deprecated application IT was never told to decommission, or a format that has not been natively readable since a migration five years ago.

Step Two: Dependency Analysis

For each record category, model the failure mode. If the person responsible for this record left the organization on Friday, what would be inaccessible, lost, or uninterpretable by Monday morning? Then apply the harder question: what regulatory, contractual, or legal obligation depends on the institution’s ability to produce that record on demand? The intersection of those two answers is the actual risk map. Most organizations have never produced it.

Step Three: Taxonomy and Consistency Audit

Pull a representative sample from every major data category and assess consistency. Are case types applied using the same controlled vocabulary across the entire dataset? Are dates formatted uniformly? Do status fields use a defined set of values or do they use whatever the entering staff member felt like typing that day? Are records from past system migrations complete, or did the migration silently drop fields, truncate entries, or introduce encoding errors that have been propagating through the data ever since? The answers determine whether the data is analytically usable. There is no middle category.

Step Four: Process Documentation Gap Assessment

Every critical process in a well-governed institution has written documentation sufficient for a qualified person to perform it without institutional memory. Identify which of the institution’s critical processes have this documentation. For every process that does not, note who is currently carrying it, how long they have been with the organization, and what their retirement timeline looks like. Then schedule the uncomfortable conversation about knowledge transfer before the institution is forced to have it as an emergency response to a vacancy.

Step Five: AI and Automation Readiness Scoring

Only after completing the prior four steps is an institution in a position to honestly assess what it can automate. Map each proposed use case against the data infrastructure it would require. Apply the findings from the dependency analysis and the taxonomy audit to each one. The result is a readiness score that tells the organization which use cases are viable now, which require remediation first, and which should not be attempted until the foundational records infrastructure is rebuilt. This is the step most organizations skipped. This is why most institutional AI implementations are underperforming.

Why Clutch Justice Covers This

Institutional data governance is a Clutch Justice issue because it is an accountability issue. Courts that cannot produce consistent records invite challenges to their own proceedings. Public agencies with undocumented process ownership create conditions where procedural violations are undetectable until they surface in litigation. Legal organizations with broken intake records cannot demonstrate compliance with the grant obligations that fund their operations.

The investigative work this platform does on Michigan courts and agencies is document work. It is tracing record chains, identifying gaps between what official records say happened and what the supporting documentation shows, and mapping the distance between procedure and practice. The forensic consulting work applies the same methodology to organizations that want to find those gaps before someone else does.

The difference between a procedural failure that becomes a public records dispute and one that gets caught and corrected internally is almost always the quality of the institution’s own record-keeping. Organizations with coherent, traceable, consistently maintained records can identify problems early. Organizations without that infrastructure find out about their problems from a journalist, an auditor, or opposing counsel. The timing tends to be less convenient than the alternative.