Why We Don't Use AI to Classify People in Prisons

When the Michigan Department of Corrections announced it was updating the way it classifies people in its prisons, with Recidiviz's help, some coverage assumed AI was doing the work. It isn't. Michigan's classification system doesn't use AI, and AI is never used in Recidiviz tools to make decisions about anyone's security level or release.

AI is showing up in more corners of the justice system, often with more enthusiasm than clarity. Corrections staff, the people living in these facilities, and the legislators and advocates who oversee this work all deserve to know what a given tool actually does. This post explains where Recidiviz uses AI, where we don't, and how we decide.

Our starting point: if it can be done without AI, we do it without AI

Our first question about any new feature isn't "how could AI help here?" It's "what's the simplest and most effective way to solve this problem?" And then we build that solution.

Most of the Recidiviz platform doesn’t use AI at all. When a tool shows a resident their parole eligibility date, or tells an officer which people on their caseload may qualify for early discharge, that answer comes from rules written directly from state policy and checked against the agency's own records. Anyone can trace exactly how the tool reached its answer.

Generative AI is powerful, but it works by approximation, so it can sound confident when it's wrong and sometimes makes things up. When the work touches someone's release date or supervision, those errors matter. Before we consider AI for any problem, we ask these questions:

• What decisions will be made based on the shown information? If a near miss could affect someone’s liberty, a rules-based tool is the better fit. 
• Does the information we’re showing already exist somewhere? If the answers already exist anywhere in the department’s database, we pull from those areas directly. We won’t add another system to update where there’s already a system of record in place.
• Does the logic need to be easily accessible and repeatable? If staff, residents, and oversight bodies need to understand why a tool said what it said, we build rules-based software, because “the AI model said so” is not an explanation.
• Would learning from the past repeat its mistakes? In a field where past decisions have reflected real disparities, a tool like AI that learns from historical data and draws from the past can continue harmful patterns.

Whenever those answers call for software that’s deterministic — same inputs, same result, every time — that’s what we build. No exceptions. Our CTO Joshua Essex laid out this framework in more depth in Spotting good uses of AI tools.

Classification: a better process, no AI required

Classification determines a person’s security level in prison, and is a good example of a process that can be improved without AI. Both Michigan’s old classification instrument and its new one are rules-based: a fixed set of factors and points that staff can read line by line. No AI was involved before, and none is now. What changed is which factors count, and how much.

Classification shapes a person’s safety, daily life, access to programs and work, and in some states, how much time they can earn off their sentence. It touches nearly everyone in the prison system, and getting it right is essential for maintaining safe and rehabilitative prisons.

Many states' classification instruments are decades old. They often weigh factors that don't predict behavior in prison, double- or triple-count others, and make it hard for people to work their way down to lower security even after years of good conduct. Staff often end up overriding the score by hand, which can be a sign the instrument isn't accurate.

We’re proud to be working with the Michigan Department of Corrections to update its classification instrument, following similar work with the Tennessee Department of Correction. In Michigan, the work looked like this:

• Start from the agency's own data. In Michigan, that meant analyzing 10 years of the state's classification data and applying evidence-based practices for predicting violence in prisons, to see which factors actually matter and which don't, and how much weight each factor should be given in the final classification assessment score. 
• Keep what matters, drop what doesn't. A team of MDOC experts considered each potential factor for inclusion in the instrument. Factors shown to have a statistically significant relationship with institutional violence were kept in. Any factor that did not meet that standard was individually considered by the group of experts and was either dropped or included as a potential reason for staff to justifiably override the instrument. Data analysis also determined how each factor is scored, because some factors—like disciplinary incidents—are more important than others. 
• Let good conduct count. Since disciplinary incidents that occurred a long time ago are less predictive of future institutional violence than incidents that occurred more recently, residents have the opportunity to let good behavior over time reduce their security level. Similarly, completing certain programs is predictive of lower institutional violence, so participation in those programs can create a real path to lower security custody.
• Decisions made by DOC experts. In Michigan, every change was made by a working group of subject matter experts and classification practitioners on MDOC staff, and agency leadership reviewed every decision about which factors are included in the instrument and which they preferred to drop.

The result is a scoresheet with a set number of points for each factor. Anyone can read it line by line, see exactly why a person landed where they did, and get the same result every time. 

Our classification tool is the mechanism that staff use to score each resident when they are due for a security screening. It pulls data from the agency’s internal records and calculates each person's assessment score automatically, with the ability for staff to check each factor and the associated point value. It also flags people for review when their record changes, alerting staff automatically so they don’t have to rely on manual tracking. 

At MDOC, Recidiviz’s tool automates the point value calculations that make up the classification assessment score, and staff review the scores to make the final decisions on all security placements. They always have the ability to override the score when they know something about the individual that might not appear in the data, like medical needs or safety concerns.

What we don't use AI for

There are many things we don’t use AI for: the things that humans do best. Our AI tools:

• Don't make decisions about liberty and safety. No AI tool we build decides custody levels, parole, program placement, early release, or supervision responses. People make the decisions.
• Don't predict behavior or score risk. We don't use AI to forecast what someone will do or to rank people by risk. Early predictive tools in criminal justice were shown to reproduce the biases in the data they learned from, and generative AI carries the same danger. Where an agency does need to assess people, as in classification, we use transparent, points-based methods rooted in statistics that staff can check line by line.
• Don't create or change official records on their own. AI produces drafts. Nothing enters an agency's system until a staff member has reviewed it and chosen to submit it, and that staff member remains its author.

When people hear that a corrections technology organization uses AI, many people picture a system deciding who gets out and who stays in. We don’t build that, and we don’t think anyone should. Letting AI decide someone’s freedom shouldn’t start to seem normal just because AI is showing up elsewhere in corrections.

Where AI earns its place

Recidiviz only deploys generative AI where it will safely and reliably lead to better workflows for staff and better outcomes for the population they serve. 

One area where AI is genuinely the best tool available is making sense of messy, human language. People don’t talk in database fields. They use nicknames, shorthand, and offhand references, and corrections records are full of handwritten forms and decades of free-text notes. Rules can’t anticipate every way a person might describe their job or their housing, and no template can anticipate a conversation between an officer and the person they supervise, where anything could come up. AI can make sense of that language and turn it into something staff can use: a draft note, a filled-in field, a match between two mentions of the same place.

We use AI for specific, narrow jobs:

• Drafting case notes from meetings. Our Meetings module supports corrections staff with meeting preparation, transcription, and note-taking. The tool uses AI to reduce manual paperwork so officers can spend more time supporting people under their supervision. Meetings drafts detailed case notes, which staff then review, edit, and submit. The tool allows staff to spend less time typing notes, and more time listening to and supporting the people on their caseloads. 
• Organizing information already in case notes. AI can read through existing notes and sort what's there into set categories, like someone's current housing situation, picking from fixed options rather than writing freely. It must point back to the exact text that supports each answer.
• Recognizing the same person or place across a conversation. AI can tell that "the restaurant on 3rd Ave" is the same employer mentioned earlier by name, something no reference table could anticipate. Simpler matching handles the rest, like catching misspellings.

Even with these tasks, we leave as little up to AI as possible. Wherever a list, filter, or fixed rule can do part of the work more reliably, it does. Some inputs never reach AI at all. Signs of a crisis in a meeting, like a disclosure of self-harm, are flagged for staff to handle. Our teammate Mayuka Sarukkai describes these constraints in detail in How to constrain AI to do its job well.

How we keep AI tools in check

When we do use AI, the tool gets more scrutiny than anything else we build. Every Recidiviz tool rolls out gradually to a small group of trusted testers chosen with agency leadership. Our teammate Tadesh Inagaki walks through that process in How we deploy AI, and why we do it carefully. AI tools also get these safeguards:

• A person reviews every draft. Officers are the legal authors of their case notes, and both their training and the tool itself make clear that the AI produces a draft. Officers review, edit, and approve any AI-generated content before it becomes part of the record, and they can check the draft against the full transcript and their own past case notes, the same inputs the AI worked from. When our automated evaluation flags a draft as potentially off, the officer sees that flag too, so the people closest to the work know when to look harder. Research on automation bias shows that people reviewing automated output get complacent, and a checkbox alone invites a quick click. So the review has teeth: the officer who was in the meeting must make edits and spends real time with each note before the system marks it reviewed, and nothing is submitted without them. 
• We check the AI's work, too. One of Recidiviz’s core AI values is continuous evaluation: every single AI-generated output is evaluated against our safety rules, not just a sample. How we do that evolves as a tool matures. During early testing, Recidiviz staff manually review 100% of outputs, which is the only way we feel confident giving more than a few users in a new state or user group access to a generative AI tool. As a tool expands, a second, independent AI model grades every output within seconds, and our staff monitor that model’s accuracy daily.
• We track the errors that matter. Word-for-word accuracy isn’t the bar. We sort mistakes by how much they’d matter to the person involved: a misspelled name is not the same as a note that wrongly says someone admitted to drug use. Harmful errors, including any sign of bias, are tracked in their own category with a strict ceiling.
• We’ll pull a tool back if it crosses the line. Continuous evaluation only means something if we act on what it finds. If a tool crosses our ceiling for harmful errors, we’ll roll back or remove access entirely until we’ve found and fixed the cause, no matter how many people are already using the tool.
• Every change is treated like a new launch. Regular software behaves the same until someone changes the code. AI tools can shift behavior from a one-line tweak to their instructions or an update to the underlying model. So we don’t patch and move on: every change is evaluated like the tool is brand new. There are no small changes.
• Clear data commitments. All outputs from the Meetings tool remain the property of the corrections department, are stored according to their guidelines, and are not used to train AI models. And our code is open source for anyone to review.

Why we're spelling this out

We think anyone using an AI tool in the justice system should be able to say clearly what it does and what it doesn't. Vague claims about "AI-powered" software make it harder for agencies to choose tools well, for oversight bodies to do their jobs, and for the people affected to trust the system. We welcome questions about our use of AI from legislators, auditors, advocates, other technology organizations, and the public.

We also take seriously what it means to introduce AI into a new part of the justice system. Errors in these settings can cost someone their freedom, and the people most affected often have the least say. We only incorporate AI into a new area when the value to staff and the people they serve clearly outweighs the risks, and when we have AI safeguards in place. Because the stakes are high, we build tools that people can trust and see into—whether they use AI or not.