AI Governance Should Start With Strategy, Not Committees

AI governance has become one of those phrases that can mean everything and nothing at the same time.

In one meeting, it means a policy about which tools employees may use. In another, it means a review board for AI projects. In another, it means model risk, vendor due diligence, legal compliance, data access, security controls, cost management, human oversight, or a spreadsheet where someone tracks every experiment that has the word “AI” in it.

All of those things can matter. None of them is enough by itself.

The mistake is treating governance as the place where AI ideas go to wait for approval. That kind of governance may create activity, but it rarely creates direction. People fill forms, committees rank requests, teams compete for scarce engineering time, and leaders feel as if risk is being managed because there is a process. Meanwhile, the real question stays vague: what is the organization actually trying to become with AI?

That question matters more now because AI has moved beyond small demonstrations. McKinsey’s 2025 State of AI survey reported that 88 percent of respondents said their organizations were using AI in at least one business function, while most had still not scaled AI across the enterprise. It also found that many organizations were experimenting with agents, but only a minority were scaling them broadly. That is the uncomfortable middle stage: enough adoption to create real risk, not enough strategic clarity to create lasting value.

Governance should help leaders cross that gap. It should not merely slow things down, and it should not rubber-stamp whatever has momentum. Good AI governance connects business strategy, technical reality, risk appetite, funding, ownership, and operating discipline. It helps the organization choose what deserves energy and what should be stopped.

If governance does not create focus, it becomes internal traffic control.

AI governance is not a substitute for strategy

A governance process can rank projects. It cannot decide what matters unless leaders have already made strategic choices.

This is where many organizations get into trouble. Every department can produce a reasonable AI proposal. Sales wants lead scoring and account research. Support wants automated ticket triage. Finance wants variance explanations. HR wants candidate screening. Legal wants contract review. Product wants AI features. Engineering wants coding assistants and internal developer tools. Operations wants document processing. Executives want dashboards that explain the business without waiting for an analyst.

Most of these ideas are not foolish. Some may be useful. But if every proposal enters the same queue with the same vague promise of productivity, governance becomes a negotiation between local priorities. The loudest department, the most persuasive sponsor, the most politically important workflow, or the easiest demo can win.

That is not strategy. It is project selection under pressure.

Strategy begins with choices. Are we using AI mainly to improve customer experience, reduce cycle time, improve decision quality, make employees more effective, reduce operational risk, or create new products? Which workflows are important enough to redesign, not just decorate with a chatbot? Which use cases are too risky for the maturity level we have today? Which capabilities should be shared across the company instead of rebuilt by every team?

Without those choices, the organization may still have governance rituals. It may not have direction.

This distinction matters for technical leaders. A review board can ask whether a proposed AI tool has a data owner, an evaluation plan, and a security review. Those are good questions. But a leader still has to ask a harder question: why this use case, now, instead of the other ten?

The answer should come from business direction, not only from the quality of a proposal template.

A committee can approve a bad portfolio

One common failure mode is approving projects one at a time while nobody owns the shape of the whole portfolio.

Individually, each AI project may look defensible. A team has a pain point. A vendor has a demo. A manager has budget. Security has a checklist. Legal has reviewed the terms. The project passes.

Six months later, the company has five document assistants, three separate model providers, two overlapping agent frameworks, inconsistent prompt logging, unclear cost ownership, duplicate vector stores, separate evaluation methods, and several teams arguing about whose use case deserves platform support. Nobody planned that result. It emerged from local approvals.

Governance should prevent that kind of drift.

The portfolio view asks different questions:

• Which AI capabilities should be platform capabilities?
• Which use cases justify custom engineering?
• Which experiments should remain small?
• Which tools create vendor concentration risk?
• Which projects depend on the same data quality problem?
• Which teams are solving the same workflow twice?
• Which systems need stronger controls because they affect customers, employees, money, safety, or regulated decisions?

This is not bureaucracy for its own sake. It is how leaders avoid spending scarce AI talent on disconnected work.

AI engineering capacity is limited. Data engineering capacity is limited. Security review capacity is limited. Product attention is limited. Leadership attention is limited. If governance only distributes that scarcity across competing requests, it may create fairness, but fairness is not the same as focus.

The better goal is coherence. A coherent AI portfolio has a visible relationship to strategy. It has a small number of priority workflows. It has reusable patterns. It has clear owners. It has a sensible risk model. It has stopped projects as well as approved projects.

Stopping matters. A governance process that never says “not now” is not governing. It is documenting demand.

Risk should be tied to business impact

AI governance often becomes too abstract because the organization talks about risk in general terms. Privacy risk. Security risk. Accuracy risk. Bias risk. Compliance risk. Reputation risk. Cost risk. These are real, but they need context.

The practical question is not “Is AI risky?” The practical question is “What can this system affect?”

A writing assistant for public marketing copy has one risk profile. A retrieval system over internal policies has another. A support assistant that drafts replies has another. A pricing recommendation system has another. A hiring screen, credit decision, clinical workflow, or agent that can update production systems belongs in a much stricter category.

The EU AI Act reflects this broad principle through a risk-based approach. The European Commission’s AI Act overview describes categories ranging from minimal risk to prohibited practices, with strict obligations for high-risk systems such as risk mitigation, data quality, logging, documentation, human oversight, robustness, cybersecurity, and accuracy. Even outside the EU, the lesson is useful: the governance burden should rise with potential harm and business consequence.

That is the opposite of one-size-fits-all review.

Low-risk experimentation should be easy. A team testing AI to summarize public documentation should not need the same approval process as a system that influences employment decisions. But high-impact workflows should not move forward because the demo looked convincing or a vendor had strong references.

The organization needs tiers. For example:

• Personal productivity use with public or non-sensitive information.
• Internal assistance over approved data with limited operational impact.
• Business workflows where AI recommendations influence decisions but humans remain accountable.
• Agentic workflows that can call tools, update records, or trigger actions.
• High-impact systems that affect people, regulated processes, safety, security, money, or legal obligations.

Each tier should have different requirements for approval, logging, evaluation, human review, data access, vendor assessment, and monitoring. This gives teams a path instead of a wall. It also keeps leaders from wasting governance energy on harmless work while under-controlling serious systems.

Good governance is not maximum friction. It is proportionate friction.

Agentic systems make vague governance dangerous

The old version of AI governance could often focus on models and outputs. Is the model accurate enough? Is the data appropriate? Are users warned about limitations? Is there a human review step?

Agentic systems widen the problem. An agent can search documents, call APIs, query databases, write code, create tickets, send messages, update records, or trigger workflows. The governance question is no longer only “What answer did the model produce?” It becomes “What can this system do inside the organization?”

That changes the control model.

An agent needs identity. It needs permissions. It needs tool boundaries. It needs logs that show what it saw, what it decided, which tools it called, what action it proposed, and what a human approved. It needs failure handling. It needs cost limits. It needs a rollback plan. It needs evaluation that tests not only final answers but also intermediate steps.

This is why I think AI governance has to be close to engineering. A high-level policy can say that agents require human oversight. The implementation still has to decide where approval appears in the workflow, which actions are read-only, which are write-capable, how secrets are handled, whether tool calls are traced, and what happens when the model calls the wrong tool with plausible confidence.

NIST’s AI Risk Management Framework is helpful because it frames AI risk management across the design, development, use, and evaluation of AI systems. NIST’s Generative AI Profile goes further for generative AI, emphasizing governance, mapping, measurement, and management across the lifecycle. Those words can sound formal, but the engineering translation is direct: know what you are building, know what it can affect, test how it behaves, monitor it in use, and keep improving controls as the system changes.

Agent governance should start small and concrete. Before an agent can take action, answer these questions:

• Which business process owns the agent?
• Which system identity does it use?
• What data can it read?
• What tools can it call?
• Which actions require approval?
• What is logged?
• Who reviews failures?
• What metric tells us to pause deployment?

If the team cannot answer those questions, the system is probably not ready for real operational authority.

Standards help, but they do not lead

Frameworks and standards are useful. They give teams shared language. They help organizations avoid starting from a blank page. They help with audits, vendor conversations, compliance, and consistency across teams.

ISO/IEC 42001 is one example. ISO describes it as a standard for establishing, implementing, maintaining, and continually improving an artificial intelligence management system for organizations that provide or use AI-based products or services. That is useful because it treats AI governance as a management system, not a one-time policy document.

But standards cannot decide your strategy.

A company can create an AI policy, assign roles, document risk assessments, classify systems, review vendors, maintain inventories, and still spend most of its AI effort on low-value work. Compliance can make a weak strategy more orderly. It cannot make it wise.

This is an important distinction for leaders who want a mature AI program. The goal is not to collect frameworks and then declare the organization responsible. The goal is to use frameworks to make strategic choices operational.

For example, if the strategy is to improve customer support quality, governance should help the organization choose the right support workflows, connect approved knowledge sources, define what the AI may and may not answer, measure resolution quality, monitor escalation patterns, and decide which responses require human approval. If the strategy is to improve software delivery, governance should clarify approved coding tools, source code boundaries, secret handling, review expectations, security testing, and how AI-generated code is evaluated.

In both cases, governance is not separate from execution. It shapes the execution.

This is where many AI policies fail. They describe responsible use in general language but do not change how projects are funded, built, measured, or retired. People read the policy once, then return to the same incentives they had before. Teams are still rewarded for launching pilots, not improving workflows. Vendors are still evaluated by demos, not operational fit. Leaders still ask how many AI projects exist, not which ones matter.

The policy may be better than nothing, but it is not leadership.

The operating model is where strategy becomes real

If strategy says what matters, the operating model explains how work moves.

For AI governance, the operating model should answer practical questions:

• How does a team propose an AI use case?
• Who decides whether it aligns with strategy?
• Who classifies the risk tier?
• Who owns data readiness?
• Who approves access to models, tools, and sensitive datasets?
• What evaluation is required before launch?
• Who pays for usage and platform costs?
• Who monitors quality, latency, security events, and cost after release?
• Who can pause or roll back the system?
• How are lessons reused across teams?

These questions may sound ordinary. That is the point. AI does not remove the need for normal operating discipline. It adds new reasons to care about it.

IBM’s 2025 Cost of a Data Breach Report highlights why this cannot be treated casually. IBM reported that 63 percent of organizations lacked AI governance policies to manage AI or prevent shadow AI, and that many organizations with AI-related security incidents lacked proper AI access controls. The exact numbers will not describe every company, but the pattern is clear: AI adoption without ownership and access control creates risk that is hard to see until it becomes expensive.

The operating model should make the safe path easier than the hidden path. If employees need AI help for common tasks, give them approved tools and clear rules. If teams need retrieval over internal documents, provide a secure pattern instead of making every group invent one. If business units need agents, give them a route that includes identity, permissions, logging, evaluation, and approval. If a request is too risky, explain what would need to change before it can move forward.

This is closely related to the problem of employee tool use. In How IT Leaders Should Govern Employee AI Tools, I argued that banning tools is rarely enough because hidden AI use often reveals unmet demand. Strategy-first governance takes that signal seriously without surrendering control. It asks: which demand should become an approved capability, and which demand should be redirected or stopped?

Measurement should include value and control

AI governance should not measure only risk reduction. If governance is seen only as a brake, teams will route around it when pressure rises.

It should also measure value.

Did the support workflow reduce repeat contacts without lowering answer quality? Did the internal assistant reduce time spent searching for policy information? Did the coding tool improve developer flow without increasing insecure code? Did the document processing system reduce manual review while preserving auditability? Did the agent save time in a workflow without creating unacceptable exception rates?

The best metrics combine value and control:

• Time saved and error rate.
• Adoption and escalation rate.
• Cost per successful task.
• User satisfaction and quality review results.
• Automation rate and human override rate.
• Retrieval quality and unsupported answer rate.
• Agent task completion and tool-call failure rate.
• Security events and policy exceptions.

This is the same practical mindset I wrote about in Make AI Work Visible Before Trust Breaks. Leaders do not need every technical detail, but they do need enough evidence to understand whether a system is useful, controlled, and improving.

Without measurement, governance becomes opinion. One sponsor says the project is strategic. Another says it is too risky. A vendor says accuracy is strong. Users say the tool saves time. Security says the logs are not enough. Finance says costs are rising. Everyone may be partly right.

Measurement creates a better conversation. It does not remove judgment, but it gives judgment something to stand on.

Leadership is choosing what not to automate

AI strategy is not only about where to use AI. It is also about where not to use it.

Some workflows need a better search experience, not a generative assistant. Some decisions need clearer data definitions, not a model. Some processes should be simplified before they are automated. Some tasks should remain human because context, accountability, empathy, or legal responsibility matter. Some AI ideas are attractive because they avoid fixing the underlying system.

Governance should give leaders permission to say that.

This may be one of the most useful tests of an AI governance program: does it help the organization reject fashionable but weak ideas? If every use case becomes a pilot, the company is not being innovative. It is avoiding prioritization.

Technical leaders can help by making tradeoffs concrete. Instead of saying “this is risky,” explain the risk in operational terms. The model would need access to sensitive data. The process has no reliable ground truth. The workflow affects customers materially. The system cannot be evaluated with the data we have. The expected volume will make costs unpredictable. The human approval step is not designed. The vendor cannot provide the logging we need. The model output sounds fluent but is not dependable enough for this decision.

That kind of explanation is not resistance to AI. It is responsible AI work.

And when the use case is worth doing, the same discipline helps it succeed. Clear strategy makes funding easier. Clear ownership reduces confusion. Clear risk tiers reduce delay. Clear evaluation improves trust. Clear operating rules make adoption safer. Clear measurement helps leaders keep investing when the system proves useful.

Governance should create direction

The durable lesson is simple: managing AI demand is not the same as leading an AI strategy.

An organization can have committees, forms, policies, inventories, dashboards, and approval workflows and still lack direction. It can also move quickly without being reckless if leaders have made clear choices about where AI matters, what risks they will accept, which capabilities should be shared, and how systems will be tested and operated.

AI governance should create that clarity. It should connect ambition to accountability. It should help teams move faster on the work that matters and slower on the work that can create serious harm. It should make the organization more focused, not merely more controlled.

For learners, managers, and technical professionals, this is a practical career lesson too. The valuable skill is not only knowing the latest model, agent framework, or compliance term. It is being able to connect AI work to strategy, explain tradeoffs, design controls, measure outcomes, and help people make better decisions.

Tools will keep changing. Regulations will keep evolving. Standards will mature. New agents will make old policies look incomplete. That is normal.

What should not change is the leadership question: what are we trying to accomplish, and how do we make AI serve that direction without pretending risk has disappeared?

Governance that cannot answer that question becomes process. Governance that can answer it becomes strategy in motion.