The Do Not Touch List: AI Governance Framework for Public Sector Leaders
The most strategically valuable document in any public sector AI governance framework is not the list of what AI will do. It is a clearly reasoned, formally maintained list of workflows AI should never touch, and building that list before a crisis forces it is the work of leadership, not legal review after the fact.
Key takeaways
Every credible AI governance framework for the public sector needs an explicit Do Not Touch list alongside any approved-use register.
The criteria for that list are built from consequence severity, accountability structure, irreversibility of harm, and the institutional trust the workflow carries.
A vendor who cannot articulate what their tool should not do is not a governance partner; they are transferring risk to you.
Drawing the line before deployment is a leadership function, not a post-incident legal exercise.
The Do Not Touch list is a living document, not a one-time policy artifact.
Why most AI policies start from the wrong end
When public sector organizations begin drafting AI policy, they almost always start with a use-case inventory. What can we automate? Where does this tool save time? Which departments are eager to pilot? Those are reasonable questions, but they frame governance as an optimization problem when it is actually a risk-calibration problem. The list of permitted uses is only as trustworthy as the reasoning behind everything that did not make it onto that list.
In emergency services, government administration, healthcare delivery, and emergency management, the consequences of a misapplied AI decision are not an inconvenience. They are a missed 911 call, a wrongly denied benefit, a delayed evacuation order, or a triage error. The asymmetry between upside and downside in these domains is severe enough that the Do Not Touch list deserves at least as much deliberate attention as the approved-use register. In our experience working at the intersection of systems design and emergency operations, it usually receives far less.
What belongs on a Do Not Touch list?
The Do Not Touch list is not a general expression of caution. It is a specific, reasoned register of workflow categories where AI involvement, even as a decision-support tool rather than a decision-maker, introduces risks that outweigh any efficiency gain. Four criteria help determine what belongs on it.
1. Consequence severity and irreversibility
Any workflow where an error produces harm that cannot be corrected in time to matter belongs on the list. In fire and emergency services, dispatch prioritization under mass-casualty conditions is one example. An AI system that systematically deprioritizes a category of call, even once, can cost lives before the error is detected. The irreversibility test is blunt: if you cannot undo the consequence before it becomes permanent, the workflow warrants exclusion or extreme restriction.
2. Accountability that cannot be delegated
Public sector institutions carry accountability structures that are statutory, not optional. A medical officer of health cannot delegate clinical judgment to an algorithm and retain the legal and ethical standing that judgment requires. A fire chief cannot assign command authority to an AI system and remain responsible under occupational health and safety legislation. Whenever a workflow's legitimacy depends on a named human being accountable, the AI belongs out of the decision chain, not in it. This does not mean the AI cannot inform the decision; it means it cannot own any part of it.
3. Institutional trust as a public good
Some workflows carry a symbolic and relational weight that efficiency calculations cannot capture. A social worker conducting a child welfare assessment is not simply gathering data; they are representing the state's duty of care in a moment of profound vulnerability. If citizens come to understand that consequential determinations about their lives were made or substantially shaped by an AI system they cannot interrogate, the legitimacy of the institution itself erodes. Workflows that serve as trust-bearing contact points between government and the public deserve serious scrutiny on the Do Not Touch list, even when the technical performance of an AI tool looks acceptable in testing.
4. Data quality and representational risk
AI systems perform on the distribution of data they were trained on. In public sector contexts, that training data frequently reflects historical inequities in service delivery, enforcement patterns, or resource allocation. A workflow where an AI recommendation would disproportionately affect already-marginalized populations, and where the organization lacks the capacity to audit that output continuously, is a candidate for the Do Not Touch list until those conditions change. This is not a permanent prohibition; it is a conditional one tied to organizational readiness.
How to build the list: a practical methodology
Building a Do Not Touch list is not a one-afternoon exercise, but it is also not a two-year research project. Here is the methodology we use with public sector clients working through AI governance frameworks.
Start with your organization's most consequential workflows, the ones where an error would trigger a formal inquiry, a coroner's review, a legislative audit, or a front-page story. Map them out without AI in the picture at all, just the human process as it currently exists. Then ask, for each workflow: what would have to be true for AI involvement to be safe and accountable? If the honest answer is that you cannot currently verify those conditions, the workflow goes on the Do Not Touch list, with the specific conditions noted as criteria for eventual reconsideration.
That last point matters. The list is not a permanent no. It is a reasoned not yet, tied to criteria that the organization can actually monitor. A workflow moves off the list when your governance infrastructure has matured to the point where you can audit AI outputs continuously, assign clear accountability, and demonstrate that performance is equitable across the populations you serve. Our advisory services are structured around exactly this kind of phased governance design.
Once the list exists, it needs an owner, a review cycle, and a mechanism by which frontline staff can flag emerging concerns. Governance documents that live only in a policy binder do not function as governance. The Do Not Touch list should be as operationally alive as your incident management procedures.
Why a vendor who never says no is selling you risk
This is the part of the conversation that procurement processes rarely create space for. When an AI vendor is asked what their tool should not be used for, the quality of their answer tells you almost everything about their suitability as a governance partner. A vendor who responds with comprehensive capability claims and no meaningful constraints is not being forthcoming about the actual performance envelope of their system. Every AI tool has conditions under which it performs poorly. Every AI tool has use cases its developers have not tested and cannot stand behind. A vendor who will not name those conditions is transferring the risk of discovering them to your organization, your staff, and the people you serve.
When we built the AI platform at the center of our own practice, we were deliberate about defining what it is not designed to do. Not because it limits the commercial appeal of the product, but because clarity about scope is a precondition for trust. That standard should apply to every tool you evaluate. Ask the vendor directly: what should this tool not be used for? If they cannot give you a specific, thoughtful answer, that is the answer. See more about how we approach that evaluation in our AI readiness work.
The governance document that earns its place
A mature AI governance framework for any public sector organization will eventually include approved-use registers, data governance policies, audit protocols, and training standards. All of that matters. But the document that most clearly demonstrates that an organization's leadership has thought seriously about AI is the Do Not Touch list, because it is the one that requires saying no to something, and in our experience, organizational cultures that cannot say no to a technology do not govern it. They follow it.
The line between what AI will do and what it will never do is not a technical line. It is a values line, drawn by people who understand both the system and the mission. Drawing it before a crisis makes it a governance decision. Waiting for the crisis makes it an incident report. Reach out to our advisory team if you want support building that line into your organization's AI policy before you need it.
Frequently asked questions
What is a Do Not Touch list in an AI governance framework?
A Do Not Touch list is a formally maintained register of workflow categories that an organization has determined AI should not influence, own, or automate, based on criteria including consequence severity, accountability structure, institutional trust, and data quality. It sits alongside an approved-use register and is treated as a living governance document with a defined review cycle.
How is the Do Not Touch list different from a general AI use policy?
A general AI use policy typically defines what AI may do and under what conditions. The Do Not Touch list specifically names what AI may not do and, critically, articulates the reasoning behind each exclusion. That reasoning is what makes the document defensible when decisions are reviewed after the fact, and what allows it to evolve as organizational capacity and technology mature.
Should the Do Not Touch list ever change?
Yes, but deliberately. Items on the list should carry explicit conditions under which reconsideration is appropriate, such as the establishment of continuous audit capacity, demonstrated equitable performance across affected populations, or changes in the accountability and oversight structure. The list is not a permanent prohibition; it is a conditional boundary that moves when the conditions that justified it are genuinely met.
How do we handle vendor pressure to expand AI use beyond what governance allows?
The Do Not Touch list provides a factual, reasoned basis for those conversations that is far more durable than general reluctance. When the list is documented, reviewed, and formally adopted, it becomes an institutional position rather than an individual judgment call. Vendors who cannot work within a governance structure that includes clear exclusions are giving you important information about their relationship to accountability.
Where does the Do Not Touch list fit in a broader AI governance framework for public sector organizations?
It belongs at the foundation. Before an organization builds out approved-use registers, procurement criteria, or AI training programs, it should have a clear, reasoned answer to the question: what will we never ask this technology to do? That answer shapes everything downstream, including what vendors you engage, what pilots you run, and what metrics you use to evaluate performance. Our AI Readiness Assessment is designed to help organizations establish exactly that foundation.