AI governance often starts by naming the thing. Chatbot. Copilot. Model. Agent. Knowledge assistant. Developer tool. The label feels useful because governance needs categories. But labels are bad at carrying risk.
A chatbot that summarises public policy for employees is not the same thing as a chatbot that guides a customer through a decision. A coding assistant that suggests a patch is not the same thing as an agent that can run commands, call tools, read secrets, or write to a repository. The label has barely changed. What the system is allowed to do has changed.
This is where AI domain knowledge matters. Not because every governance participant needs to become an AI engineer. That would be another bad abstraction. Governance still needs the usual risk discipline: ownership, accountability, approval, evidence, audit trail, monitoring, escalation, and change control. Those things are not made obsolete by large language models.
But a generic risk process can miss the point if it cannot tell which technical facts change the control decision. Retrieval quality matters because an answer may only be as good as the corpus it can reach. Source attribution matters because a human cannot review what they cannot trace. Prompt injection matters because the input may be adversarial, not merely wrong. Tool permissions matter because the system may stop being an adviser and become an actor. Memory matters because the system may carry context across interactions. Model and vendor changes matter because the behaviour being governed may move under the same product name.
Human review is another place where labels hide risk. Many systems are described as human-in-the-loop. That phrase can mean a person reads a clean final answer. It can also mean a person sees the source trail, the confidence boundary, the rejected alternatives, the action to be taken, and the moment at which approval still matters. Those are not equivalent controls. One is often comfort. The other may be governance.
The same problem appears with internal tools. Internal does not mean low risk. A tool can be internal and still read confidential data, generate control evidence, influence operational decisions, or act inside a sensitive technical environment. External does not automatically mean high risk either. A public-facing feature that is narrow, read-only, well logged, and clearly bounded may be easier to govern than an internal agent with broad permissions and unclear oversight.
This is why AI governance needs domain expertise at the points where route, evidence, controls, and monitoring are decided. The expert’s job is not to say “this is AI” in a meeting. The useful job is to stop lazy equivalence. Is this just drafting, or relied-upon advice. Is this just Q&A, or decision support. Is this just a developer tool, or an execution environment. Is this just a model update, or a change in the governed behaviour.
Good governance should not be captured by technologists. It should not be reduced to model trivia, benchmark scores, or architecture diagrams. But it also cannot treat technical detail as implementation noise beneath the dignity of governance. In AI systems, technical detail is often where the control boundary lives.
The best version is hybrid. Risk people bring discipline about accountability, evidence, escalation, and control operation. AI-literate people bring an understanding of how these systems fail, where labels mislead, and which behaviours need runtime controls rather than paper controls. Neither side is sufficient by itself.
The label is only the beginning. The governance question is what the system can know, what it can do, who relies on it, what evidence survives, and how quickly the organisation can tell when the boundary has been crossed.