Most conversations about responsible AI begin with the model: its training data, accuracy, bias, security, or explainability. These are necessary questions. They are not enough. People rarely encounter a model in isolation. They encounter a service—an application, a notice, a caseworker, a deadline, an appeal process, or a decision that changes what happens next.
That distinction matters in government. A system might summarize policy accurately and still make a service worse if staff cannot identify the controlling source. A chatbot might answer routine questions correctly and still cause harm if it sounds authoritative when the right action is to refer someone to a person. A predictive tool might test well in aggregate and still fail the residents whose records are incomplete because of how an older administrative process collected data.
Responsible AI is not a quality applied to a model. It is a property of the service around it.
Start with the service, not the capability
The first product question should not be “Where can we add AI?” It should be “Where is the service failing, for whom, and why?” Sometimes the answer will involve a model. Often it will involve clearer content, better source ownership, a simpler form, a more reliable handoff, or giving frontline staff access to information that already exists.
Starting with the service also changes how a team defines scope. The relevant boundary includes the offline steps before and after the screen: how a resident learns about a program, what documents they can reasonably obtain, how staff interpret an exception, and what recourse exists when something goes wrong.
Evaluate the point of consequence
Model-level measures should be connected to service-level outcomes. Did the tool help a person complete the task? Did it reduce repeat contacts without suppressing legitimate questions? Did it shift work onto another team? Are errors easy to notice and correct? Do people understand when they are interacting with an automated system and what authority it has?
The most important test cases are often not the most common ones. They are the moments when an answer affects eligibility, safety, a legal deadline, or access to an essential service. Those cases need explicit thresholds, escalation paths, and owners—not a general promise that a human remains “in the loop.”
Make ownership visible
Many apparent AI failures are ownership failures. A source changed but nobody maintained the retrieval index. Staff knew the exception policy but the product team did not. A resident reported a wrong answer but the feedback went to a generic inbox. The model receives the attention while the surrounding institution remains undefined.
A responsible service names who owns each source, who monitors performance, who can pause the system, who handles a disputed result, and who decides when the use case has changed enough to require a new review. That operating model is less dramatic than a launch. It is also what makes the launch defensible.
Public institutions should be ambitious about using new tools. But ambition is not measured by the number of AI features deployed. It is measured by whether services become more accurate, accessible, understandable, and accountable for the people who rely on them.