> ## Content Index > Fetch the complete content index at: https://www.groktop.us/llms.txt > Use this file to discover other available public pages before exploring further. # AI Governance Is Human Work: Where an AI Skill Helps, and Where It Stops - URL: https://www.groktop.us/ai-governance-human-work/ - Published: 2026-08-17T12:00:17.000Z - Updated: 2026-08-17T12:00:17.000Z - Description: AI governance remains accountable human work. An AI-governance skill can help leaders challenge assumptions, find gaps, and test evidence without pretending to own the decisions. - Author: Magnus Hedemark I made an [AI Governance skill](https://github.com/magnus919/agent-skills/tree/main/ai-governance?ref=groktop.us) because setting up governance is difficult work, and difficult work benefits from a second set of eyes. Do not start with a model or a policy binder. Start with the decision, classify its consequences, limit the system’s authority, demand evidence, and keep the power to stop it. If you have not encountered the term, an agent skill is a reusable bundle of instructions, references, templates, and sometimes small tools that an AI agent loads when it needs to help with a particular kind of work. This one is deliberately agent-agnostic: it is written as Markdown methodology, with Python 3 standard-library scripts, rather than being tied to a particular model vendor or API. It should work on agent platforms that can load instruction bundles and let the agent read local reference files or run standard Python, including Hermes and compatible skill-based systems. The exact installation and invocation method will vary by platform, but the governance method does not depend on a hosted service or API key. If you have not encountered the term, an agent skill is a reusable bundle of instructions, references, templates, and sometimes small tools that an AI agent loads when it needs to help with a particular kind of work. This one is deliberately agent-agnostic: it is written as Markdown methodology, with Python 3 standard-library scripts, rather than being tied to a particular model vendor or API. It is designed for Hermes and for other agent platforms that support equivalent instruction bundles, local reference files, and Python execution. Installation and behavior should be verified on each platform. The governance method does not depend on a hosted service or API key. The skill is a support tool for the people who own that work. It helps an agent review use cases, classify risk, test authority boundaries, inspect evidence, and challenge operational controls. It includes lifecycle guidance, agent-safety questions, reusable templates, and small Python checks for risk classification and governance maturity. ![Five human-owned governance stages: purpose, risk, authority, evidence, and withdrawal.](https://storage.ghost.io/c/f1/0e/f10e80f4-9285-43fc-acd4-35910a12c5f0/content/images/2026/08/ai-governance-loop-latched.png) The governance loop keeps humans responsible from purpose through withdrawal, with authority earned through evidence and kept reversible. It does not set up AI governance for you. It does not certify that your organization is compliant or that an agent is safe. It helps you challenge your assumptions, find missing evidence, and review the work before you rely on it. That distinction is the point. AI governance remains accountable human work. ## 1\. Start with a decision, not a model Good governance begins before anyone chooses a model. Write down the problem. Explain why AI is appropriate instead of a rule, a workflow change, or a human decision. Identify who will use the system, who may be affected by it, what decision it will influence, what data it will touch, and who owns the result. The first useful question is not “Which model should we use?” It is “What authority are we considering giving a machine, and what happens if it is wrong?” This is where I would use the [skill’s use-case intake template](https://github.com/magnus919/agent-skills/blob/main/ai-governance/templates/use-case-intake-form.md?ref=groktop.us). I would not treat the completed form as an approval. I would use it to expose what the proposal has not said yet. Does the proposed purpose describe an outcome, or merely a technology? Are affected people named? Is the decision impact clear? Is the owner a real person with the authority to stop the work? Is the proposed use still acceptable if the system is occasionally wrong? [ISO/IEC 42001](https://www.iso.org/standard/42001?ref=groktop.us) treats governance as a management system, not a launch checklist. Policies, roles, evidence, and controls must change as the system changes. End this step with a named owner, a defined purpose, identified affected groups, and a clear statement of the authority under consideration. The organization still has to decide what to adopt, what to reject, and what risk it is willing to carry. ## 2\. Classify the use case by consequence Not every AI use case deserves the same process. A meeting-summary assistant and an agent that changes a patient’s record should not clear the same gate. The useful unit of classification is consequence. Ask what the system can affect, how many people it can affect, how sensitive the data is, how much authority it has, how reversible its actions are, and how quickly a human can detect and correct an error. The [NIST AI Risk Management Framework](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/?ref=groktop.us) organizes the work around four verbs: Govern, Map, Measure, and Manage. For this step, the practical requirement is simpler: inventory the system, name its owners, classify its consequences, and define the oversight its risk demands. The [skill’s model-risk assessment template](https://github.com/magnus919/agent-skills/blob/main/ai-governance/templates/model-risk-assessment.md?ref=groktop.us) helps turn those questions into a repeatable assessment. Its risk-tier script can produce a structured starting point. Treat the output as a starting point, not a verdict. A human owner has to test whether the proposed tier reflects the real-world consequences. If the script says “moderate” and the system can silently deny access to a service, the script is wrong for the context, even if its arithmetic is flawless. Record the tier, the reasoning behind it, and the controls and reviewers that tier requires. Make the skill show its reasoning, then argue with it. ## 3\. Design the authority boundary Once the risk is understood, define what the system may actually do. An agent should not receive broad permissions because the product demo looked impressive. Give it the smallest useful set of tools. Separate read access from write access. Put authorization in the downstream system, not in the model’s interpretation of a prompt. Make high-impact actions require an explicit human decision when the consequences justify it. [OWASP’s prompt-injection guidance](https://genai.owasp.org/llmrisk/llm01-prompt-injection/?ref=groktop.us) warns that malicious instructions can arrive through websites, files, and other external content. It does not claim that a foolproof prevention method exists. It emphasizes reducing the impact of a successful attack through minimum privileges, segregated external content, downstream controls, and approval for privileged operations. [OWASP’s excessive-agency guidance](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/?ref=groktop.us) identifies excessive functionality, excessive permissions, and excessive autonomy as recurring causes of harm. Its human-approval recommendation is scoped to high-impact actions rather than stated as a blanket requirement for every action. Match the control to the consequence. This is where the skill should act as a design reviewer. Ask it to inspect the proposed tools and permissions. Ask it to find places where the agent could misuse another system’s authority, perform irreversible operations, write through hidden interfaces, bypass rate limits, or enforce a rule that the application should enforce. As I argued in [Agentic QA Is a Control-System Problem](https://groktop.us/agentic-qa-control/?ref=groktop.us), the assurance boundary includes the agent’s tools, permissions, evidence, escalation path, state changes, and environment. The model is only one part of the system. Turn the review into an authority matrix: allowed actions, prohibited actions, approval points, rate limits, and stop conditions. ## 4\. Set the evidence gate before deployment A governance process becomes theater when the team decides what counts as success after seeing the result. Before deployment, define the acceptance criteria. What must the system do reliably? Which failures are tolerable? Which failures are disqualifying? Which scenarios must the team test? Which logs, traces, user reports, and outcome measures will the owner review? What causes a pause, rollback, or withdrawal of authority? Use the [skill’s model-card template](https://github.com/magnus919/agent-skills/blob/main/ai-governance/templates/model-card.md?ref=groktop.us) to make those questions visible. Ask the skill to review the evidence against the intended use, not merely against a benchmark. The [NIST AI RMF Playbook](https://www.nist.gov/itl/ai-risk-management-framework/nist-ai-rmf-playbook?ref=groktop.us) presents suggested actions that organizations can adapt to their use cases. That adaptability is useful, but it also means the organization has to explain its choices. A framework does not eliminate judgment. It makes judgment easier to inspect. The evidence should cover more than model quality. Test the whole operating system around the model: data provenance, permissions, tool behavior, human escalation, error handling, monitoring, and recovery. [The measurement layer Groktopus described for AI ROI](https://groktop.us/ai-roi-question/?ref=groktop.us) matters here. Authority should expand on demonstrated outcomes and control performance, not on a persuasive demo. My opinionated rule is simple: do not grant more authority because the system is fluent. Grant more authority only when evidence shows that the specific action, data, and consequence are understood and controlled. Approve deployment only when the evidence meets criteria written before the team sees the result. ## 5\. Operate, review, and withdraw Deployment is not the end of governance. It is the point where governance meets reality. Assign an owner for the live system. Monitor operational health and behavior. Track incidents, near misses, overrides, appeals, user feedback, and changes in the environment. Define who can pause the system and how quickly they can do it. Reassess when the model, data, tools, permissions, or intended use changes. The [NIST Generative AI Profile](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence?ref=groktop.us) adapts the AI RMF to generative AI and emphasizes governance, provenance, pre-deployment testing, and incident disclosure as cross-cutting concerns. [Anthropic’s framework for safe and trustworthy agents](https://www.anthropic.com/news/our-framework-for-developing-safe-and-trustworthy-agents?ref=groktop.us) emphasizes human control, transparency, privacy, and secure interactions. Its Claude Code examples add read-only defaults, approval before modification, and stoppability. Use the skill to review the monitoring plan, incident process, change triggers, and shutdown procedure. Test the monitoring plan against the failure you fear most. Identify the evidence that would separate a model failure from a data, permission, workflow, or interface failure. Then prove that the shutdown procedure works. Then let the people who own the system decide what to do. [The Org Chart Is the AI Rate Limiter](https://groktop.us/org-chart-rate-limiter/?ref=groktop.us) makes the organizational point: decision rights and feedback speed constrain adoption. A support skill can improve the quality of feedback. It should not become a new central approval queue that takes ownership away from the team closest to the work. ## What the skill cannot do The skill cannot independently know your organization’s full operational, legal, cultural, or political context. It cannot decide that the remaining risk is acceptable. An accountable human must make that call. It cannot replace legal counsel interpreting obligations, security practitioners testing an implementation, auditors assessing evidence, or domain experts who understand the people affected by a system. It cannot certify compliance. It cannot certify safety. It cannot make a governance decision on your behalf. Those limits are not an apology. They are the correct operating boundary. Use the skill to prepare a risk assessment, then validate it. Use it to propose controls, then decide whether they are sufficient. Use it to challenge a launch recommendation, then let accountable humans mitigate, transfer, avoid, or accept the remaining risk. Use it to find an unresolved question, then answer it or stop. I made this skill for myself and my own work. In the spirit of open source, I wanted to give it to you, too. It is [MIT licensed](https://github.com/magnus919/agent-skills/blob/main/LICENSE.md?ref=groktop.us), so you can use it, adapt it, improve it, or decide that another approach suits you better. AI governance is human work. Use the skill to expose missing evidence, challenge weak controls, and sharpen the questions. Then make the decision, name the owner, and keep a human hand on the stop control.