Data & Analytics
Machine Learning & AI
Applied machine learning and language models for defined agency use cases.
What this covers
Machine learning can help agencies prioritize inspections, forecast demand, classify documents, route service requests, and answer routine questions. It can also fail quietly and unfairly if applied without care. HQT builds models for defined use cases with the documentation and human oversight public accountability requires.
Typical activities
- Use case evaluation: is this a problem where a model helps, and what could go wrong
- Data preparation and feature engineering
- Model development, validation, and bias testing
- Retrieval-augmented language model applications over agency documents
- Deployment with monitoring for drift and performance
- Model cards and plain-language documentation for the public record
What you receive
A use case assessment, a validated model with documentation, a deployed service with monitoring, and an operating procedure that keeps a human responsible for consequential decisions.
Considerations for public agencies
Automated decisions that affect residents attract scrutiny and, increasingly, regulation. We design for explainability and appeal from the start and align to published guidance such as the NIST AI Risk Management Framework.
Signals that a model is the right tool here
The conditions that favor machine learning are narrow: a decision made many times a week, taken from data the agency already retains in a stable structure, with past examples of the correct outcome that can be assembled without a manual labeling project.
- Staff triage a queue by reading it every morning: permit applications, service requests, claims, code complaints, plan review intake.
- The binding constraint is the order of work rather than total capacity, so better ranking recovers time that added headcount would not.
- A records or call center team answers a narrow set of repeated questions out of documents that already exist and are already disclosable.
- A vendor has switched on an AI feature inside a system the agency already owns, and no one can say what it was trained on or how to check its output.
- A score, risk flag, or routing rule already runs in production, arrived with a product, and has never been revalidated against local data.
The signals against matter as much. If source data changes structure without notice, if statute defines the decision in terms a rules engine can express exactly, or if only a handful of labeled examples exist, the better answer is data plumbing or a clearer written rule.
Failure modes to name before work starts
- Performance quoted on the same data the model was fit to, or on a random split that lets later information leak into training.
- Targeting models trained on past enforcement activity, which tend to rediscover the places already inspected rather than the places with problems.
- A pilot with no acceptance criteria, which runs indefinitely because no one wrote down what would end it.
- Prompts, retrieval settings, and model versions changed in production without version control, so no one can reconstruct what produced a given answer.
- An upstream system changes a field, the input goes stale, and nothing alerts anyone.
- A score with no program owner outside IT, so no one is accountable for how the output is used.
What to require in the solicitation and the contract
- A named baseline, such as the current process or an oldest-first rule, and a performance floor tied to acceptance, measured on held-out data from a period after the model was built.
- Error rates broken out by subgroup and jurisdiction, with the evaluation method described in enough detail to reproduce.
- Disclosure of training data sources, exclusions, and known limitations, including for any pretrained or foundation model the vendor builds on.
- Ownership and license terms covering trained models, prompts, evaluation datasets, and derived labels, not only source code.
- A prohibition on using agency data to train or improve the vendor's general models, plus a list of every subprocessor that can see the data.
- Where inference runs and under what authorization. Authorizations are granted service by service, so a newer AI service can sit outside the one the parent cloud platform holds. Ask by service name.
- Notice and revalidation rights when the vendor changes model versions, since a foundation model upgrade can change behavior with no change on the agency side.
- Logging of inputs, outputs, and the reviewer's decision, mapped to the applicable records retention schedule.
Measuring after go live
Model metrics are not program outcomes. Run in shadow mode first, with the model producing recommendations while the existing process still decides, and compare the two before switching over. After launch, track the operational measure the project was justified on, such as violations found per inspection, days to first response, or the share of requests routed correctly the first time. Watch the reviewer override rate in both directions, since a rate near zero often means reviewers are approving without reading and a very high rate means the output is not useful. Compare the distribution of current inputs against the data the model was fit on, and trigger revalidation on a fixed schedule and on any upstream schema change, vendor model version change, or policy change that redefines the target variable.
Working with HQT on this
HQT scopes this kind of work as a fixed-price or time-and-materials engagement with a written statement of work, named staff, and a defined acceptance process. We are candid about what we can take on and prefer a well-run project to an oversized one. Contact us to discuss a requirement, a draft scope, or an upcoming solicitation.
Frequently asked questions
How do we know whether a problem needs machine learning or just a business rule?
If the decision can be written as a list of conditions that stays stable over time, a rules engine is cheaper to build, easier to explain in an appeal, and easier to change when policy changes. Machine learning is worth the added overhead only when the pattern is real but too complex or too variable to enumerate, and when historical examples of the correct outcome already exist. The evaluation should cost out the rule-based option first and say plainly when it wins.
Can we use a commercial AI service with data covered by CJIS, HIPAA, or state confidentiality law?
Sometimes, but the answer turns on the specific service rather than the vendor as a whole, because authorizations and contract terms are granted service by service. Criminal justice information generally carries requirements about who may access it, where processing happens, and what agreements are signed, and protected health information generally requires a business associate agreement with the provider. Ask for the authorization status of the named service, a data flow showing where inputs are processed and stored, and the signed agreement before any protected data is sent to it.
Are prompts and AI-generated outputs public records?
In many jurisdictions, records made or kept by an agency in the course of business are open to disclosure regardless of the tool that produced them, and prompts and outputs can meet that definition. They may also fall under a retention schedule, which means they have to be captured somewhere the agency controls rather than left inside a vendor interface. Build logging and export into the design, and confirm the treatment with your records officer and counsel rather than assuming the vendor handles it.
Do we have to tell residents when a model was involved in a decision about them?
Requirements vary by jurisdiction and by the type of decision, and some states and local governments have adopted rules requiring agencies to inventory automated decision systems or disclose their use. Even where no statute applies, a contested decision is easier to defend when the agency can show which inputs produced a given result and what a person did with it. Check the current requirements in your state and your own administrative policy before deployment, and keep the record that would answer the question if someone asks.
How much data does an agency need before a model is feasible?
There is no universal threshold, because it depends on how rare the outcome is, how many factors influence it, and how much the process changed over the period the data covers. What usually decides feasibility is whether there are enough labeled examples of the outcome itself, spread across enough time and enough of the jurisdiction to be representative, rather than the raw row count. A short feasibility check on the actual data settles this faster than any general rule, and it sometimes concludes that improving collection comes first.