AI Governance Without Paralysis: Build the Controls Into the Work

Artificial intelligence is starting to cross an important line inside organizations. Much of the recent conversation has focused on helping people draft emails, summarize reports, find information, and write code. Those uses can create real value because a person still sits between the technology and the consequence. The governance problem changes when a system begins communicating with customers, updating records, carrying work across several steps, or taking action without someone directing every move. Once artificial intelligence receives that kind of authority, leaders need more than a broad instruction to “keep a human in the loop.” They need to know who is responsible for review, when it occurs, what the reviewer is expected to examine, and whether that person has enough information and authority to intervene.

Those are operating questions, and a policy can support them without answering them. A policy may define acceptable use, approved tools, data restrictions, disclosure expectations, and the need for human judgment. The harder work begins when leaders translate those expectations into workflows, decision rights, and escalation paths. If the organization cannot explain how control functions inside the work itself, the policy is only one part of the governance system.

POLICY ONLY GETS YOU SO FAR

Take a familiar requirement: verify artificial intelligence output. Verification means something very different when a system drafts an internal email than when it modifies a customer record, interprets financial information, or prepares an external response. Leaders still have to decide who reviews it, what evidence the reviewer uses, what happens when the answer is uncertain, and who owns the decision to proceed. Human oversight raises the same issue because simply placing a person in the process does not create a safeguard. That person needs enough expertise, time, information, and authority to recognize a problem and intervene when the system moves outside expected boundaries.

Recent reporting on advanced OpenAI agents provides a visible example of why those details cannot be assumed. Reuters reported that agents used more than 10 previously undisclosed websites for unauthorized communications after researchers found ways the systems had worked around restrictions on posting to the web (Satter & Seetharaman, 2026). These were frontier research systems rather than normal workplace deployments, so I would not use them as proof that every enterprise use case carries the same risk. The narrower lesson is more useful: the boundary an organization intends to create and the behavior it actually gets may not match. That gap is why governance needs feedback, observation, and the ability to respond rather than relying only on written rules.

NOT EVERY USE CASE NEEDS THE SAME FRICTION

Organizations can also create unnecessary drag when they treat every artificial intelligence use as though it carries the same consequence. An approved tool that summarizes meeting notes has limited authority over what happens next. At the same time, an agent that can access customer information, change records, send external communications, or execute production code has much more. I would begin by examining the authority the system receives, the information it can access, how easily its actions can be reversed, and what happens if it gets something wrong. As potential consequences increase, the organization should expect stronger testing, clearer approval requirements, more deliberate verification, and better monitoring. Friction should rise with the authority and consequences involved rather than being applied equally to every use case.

Newer NIST work focused on AI agents and AI-related cybersecurity reinforces that approach. In May 2026, NIST researchers reported broad agreement that AI agents introduce novel security threats and that traditional cybersecurity practices will need adaptation (Riggs et al., 2026). An August 2026 NIST Cyber AI workshop report also highlighted governance challenges, AI attack surfaces, and the need for more specific, risk-based controls (Megas et al., 2026). The implication for leaders is practical: low-consequence work should stay within defined boundaries, while systems with greater authority should face greater scrutiny. Requiring several senior executives to approve meeting-note summaries is probably bureaucracy; allowing an agent to act on behalf of the company without clear stop authority is a different failure.

DESIGN THE AUTHORITY BEFORE YOU EXPAND THE AUTONOMY

With an executive team, I would take one artificial intelligence use case and follow it end to end rather than starting with a general policy discussion. I would work through six connected areas: result, authority, risk, verification, escalation, and stop authority. Start with the result the organization wants to improve, then define the authority required to pursue it. Be specific about what the system may see, recommend, change, approve, send, or execute without another person acting first. Once those permissions are clear, ask what could go wrong because the organization granted them, what evidence will show whether the system is operating correctly, which conditions require human involvement, and who can restrict or stop the system.

Imagine an agent that reads customer requests, updates the customer relationship management system, prepares responses, and sends routine messages without human review. My first question is not whether legal approved the software; I want to understand the authority the organization granted. Can the agent change a customer record, make a commitment, send information outside the company, or continue acting when confidence is low? How does it handle a request outside the cases used to design or test it? Those answers give leaders a practical basis for deciding where approval, verification, and escalation belong. Without that clarity, “responsible AI” remains an aspiration rather than an operating practice.

APPROVAL IS NOT THE FINISH LINE

Approval captures one moment, while the work keeps changing. A vendor may update its model, a team may connect another data source, employees may discover a new use, or a feature that began by drafting recommendations may eventually receive permission to execute them. None of those changes automatically means something has gone wrong, but each can change the assumptions behind the original approval. NIST’s 2026 concept work on trustworthy AI in critical infrastructure makes the same point through a full-lifecycle approach, including tested guardrails, monitoring outside verified conditions, traceable recommendations, fail-safe behavior, human oversight, and rigorous testing and validation for AI-enabled capabilities (Sheh & Stanley, 2026). A useful governance process must therefore revisit its assumptions as the technology, workflow, and level of authority evolve.

The current debate among frontier artificial intelligence companies points in a similar direction, although their recommendations deserve caution. Anthropic Chief Executive Officer Dario Amodei recently called for embedded independent evaluators, coordination among leading AI companies, and international cooperation around safety (A. D. Shah, 2026). OpenAI has separately called for capability-based national requirements that include independent assessments, cybersecurity protections, and incident reporting (C. Shah, 2026). Both companies have commercial and regulatory interests in how future rules are written, so I would not treat their proposals as neutral evidence. The useful signal is their emphasis on evaluation, monitoring, reporting, and independent checks as ways to detect behavior that moves outside expected boundaries.

I also take seriously the concern that poorly designed regulation and internal bureaucracy can slow useful innovation. That is why I would judge a control by what it actually does in practice rather than by how formal it looks on paper. A useful control should improve visibility, clarify authority, catch meaningful failures, or create an escalation path people can use under pressure. If the control only adds another meeting or approval layer without changing how risk is identified or handled, it may be governance theater. The goal should be enough structure to make authority visible and risk manageable without forcing every use case through the same process.

BUILD THE CONTROLS INTO THE WORK

RISE helps me keep the governance conversation connected to execution. Radiate anchors the discussion to the result the organization wants to improve, while Innovate examines how the new capability changes the work. Serve brings authority, information, workload, expertise, verification, and the people expected to intervene into view. Endure asks whether the controls still work after the technology, data, or workflow changes. Used this way, the framework supports governance without turning it into a separate compliance exercise.

I would build those controls into the work itself. Before granting a system more independence, leaders should understand the authority they are giving it, what evidence shows the system is performing as intended, when a person needs to step in, and who can stop the system when assumptions no longer hold. That approach will not eliminate risk, and no governance model can promise that it will. It does give leaders a clearer way to recognize risk early enough to act and a better basis for deciding when additional autonomy is justified. The principle I would carry into those decisions is simple: design the authority before you expand the autonomy.

REFERENCES

Megas, K., Cuthill, B., Sames, C., & Snyder, J. (2026). Workshop summary report for “Cyber AI Profile” hybrid workshop (NISTIR 8607). National Institute of Standards and Technology. https://doi.org/10.6028/NIST.IR.8607

Riggs, J., Hamin, M., Perry, N., Edelman, B., & Cihon, P. (2026). Summary analysis of responses to the request for information regarding security considerations for AI agents (NIST Trustworthy and Responsible AI 800-5). National Institute of Standards and Technology. https://www.nist.gov/publications/summary-analysis-responses-request-information-regarding-security-considerations-ai

Satter, R., & Seetharaman, D. (2026, September 9). OpenAI’s rogue agents used at least 10 more sites for unauthorized comms, researchers say. Reuters. https://www.reuters.com/world/openais-rogue-agents-used-least-10-more-sites-unauthorized-comms-researchers-say-2026-09-09/

Shah, A. D. (2026, September 12). Anthropic CEO urges AI companies to slow model development amid fears over misuse. Reuters. https://www.reuters.com/business/anthropic-ceo-urges-ai-companies-slow-model-development-2026-09-12/

Shah, C. (2026, September 9). OpenAI pushes for mandatory national AI safety rules. Reuters. https://www.reuters.com/legal/government/openai-pushes-mandatory-national-ai-safety-requirements-2026-09-09/

Sheh, R., & Stanley, M. (2026, April 7). Artificial intelligence risk management framework: Trustworthy AI in critical infrastructure profile [Concept note]. National Institute of Standards and Technology. https://www.nist.gov/system/files/documents/2026/04/08/Draft%20Concept%20Note_%20Development%20of%20the%20NIST%20AI%20RMF%20Trustworthy%20Use%20of%20AI%20in%20Critical%20Infrastructure%20Profile.pdf