Search your popular job board of choice for “AI Governance Director”, and you’ll see 197 open positions. Keep that tab open, and in a new one search “AI Enablement Director” to see different results, different requirements, different skill sets for significantly fewer positions. Weirdly, when you scroll through the job descriptions in each you find half of the sample size asking for both. Ergo, organizations are posting two distinct job titles while writing descriptions that treat them as the same.
That confusion isn’t just a hiring problem, but a symptom of a deeper misunderstanding about what makes AI programs work. An EY survey of 975 C-suite leaders found that while 72% have AI integrated in some form across their organizations, only a third have responsible controls in place.[1] This gap between AI adoption and AI governance reveals how organizations conflate ‘AI Enablement’ with ‘AI Governance’ - treating fundamentally different capabilities as if they’re the same job.
In the end, we know two things:
Governance manages risk.
Enablement builds capability.
You really need both, but they require different skills and conflating them means one might more easily fail. I happen to have worn both hats, but doing so at scale is where this hat-on-a-hat approach gets tricky.
The Governance Trap
Governance answers “should we?” and “how do we stay safe?”. It creates guardrails, establishes approval processes, and defines acceptable use policies. This work is necessary, as without governance frameworks, organizations accumulate risk faster than they can understand it, let alone manage it.
By design, governance creates friction at every approval checkpoint, every risk assessment, and every compliance review adding steps (and time) between “I have an idea” and “I’m implementing something.” You want thoughtful evaluation before deploying AI systems that touch customer data or make business-critical decisions.
The failure mode peaks through when governance becomes a locked gate. In my last position at a non-profit healthcare association, I built a governance framework around the then-new NIST AI RMF. Risk assessment, data classification review, security opinion sign-off, executive sponsor approval. Reasonable steps that delayed the first pilot by a couple of weeks.
Campaign deadlines and project timelines don’t accommodate weeks-long reviews. Corporate card statements revealed the pattern: Jasper subscriptions, ChatGPT Plus accounts expensed as “professional development,” AI features in various SaaS enabled without IT/admin notifications. Teams solved immediate problems with the tools suddenly available to them rather than waiting for approval processes.
This is not a unique story. In my Shadow AI article (published here on Substack), I documented how teams route around governance by not proposing AI projects at all. Subscriptions for copywriting tools show up on marketing expense reports. Sales adopts conversation intelligence features already embedded in their CRM. Finance starts using AI-powered forecasting that came bundled with existing software. Nobody submits these for governance review because (a) the tools are easy to sign up for or otherwise activate to solve immediate problems and (b) the formal process takes too long.
Your governance framework exists as comprehensive, well-documented, aligned with NIST AI RMF or whatever other framework you’ve chosen. “Prompt libraries” on the intranet, and explanation of PII at every staff meeting. If your experience is anything like mine, usage of approved resources is likely minimal. That’s the governance trap: You built the structure but forgot to build the capability for people to actually use AI within it.
What Enablement Actually Means
Just like governance answers its own questions, enablement answers “how do we help people succeed?” It’s the set of activities that turn policy into practice, and frameworks into that ever-elusive adoption.
Organizations that separate these functions - even when one person handles both initially - tend to see better results. The skills required for policy writing and risk assessment are fundamentally different from the skills required for training design and change management. Trying to do both simultaneously usually means doing neither well.
Four components define effective AI enablement:
1. Literacy Programs That Address Real Work
Highly abstract “What is AI” training doesn’t work, and frankly isn’t usually what the business desires. Your finance team doesn’t need to understand transformer architecture or RAG, they need to understand what AI can do for month-end close, variance analysis, and forecast accuracy. Role-specific training that connects AI capabilities to actual job functions works, and generic overviews don’t. Think skills-based training, not theory.
This means developing training that maps to how people actually work. The progression runs from consumer (using AI tools as intended) to power user (understanding how to get better outputs through better prompts) to builder (understanding enough to identify opportunities and specify requirements). Focus on the problems people actually face rather than comprehensive capability surveys, and you can help the right staff figure out where they should focus their skills development.
2. Adoption Support Beyond Documentation
Documentation as a practice is often vilified as a waste of time, or at least something that gets knocked out last. AI is ubiquitous and, let’s face it, packaged as consumer tech; it’s more like opening a productivity application than assembling a dresser from Ikea. But thinking that people actually crack that open when they have a question is a glorious fiction perpetuated by generations of tech workers. Office hours where people can bring actual work problems and get help solving them with AI tools produce better results. This is a shift to coaching, not just information delivery. (Note: I am in no way saying not to document! Quite the contrary, it’s absolutely necessary - how else are you going to train the helpdesk chatbot on how to use the stuff?)
When I had the opportunity, I first deployed Claude to IT staff, then expanded to HR and Marketing as the second tier. These early adopters - they can be found hiding in any department! - found specific applications. HR using it for policy documentation and internal communication drafting, Marketing for member communication development, IT for sanity checks while troubleshooting. The key wasn’t announcing these as wins in corporate communications, building momentum by projecting popularity and stoking the flames of FOMO, but visibility - both good and bad - is the point.
Learning from failures without blame completes the picture. When AI approaches don’t work, understanding why helps everyone. And hey, it happens. Whether it’s the wrong tool for the problem, insufficient data, or the wrong problem entirely, each failed experiment teaches something if you create space to discuss it along with the wins.
3. Internal Champions Who Aren’t IT People
This is key to all adoption, now with added focus: The most effective AI advocates in your organization aren’t the people building the systems. They’re the business users who figured out how to apply AI to their actual work and want to help others do the same.
McKinsey research shows that companies investing in trust-enabling activities through change management are nearly two times more likely to see revenue growth rates of 10% or higher.[4] Internal champions drive this trust by demonstrating real applications rather than theoretical possibilities or enthusiasm.
These people need three things:
time (it’s not free labor to be an advocate),
tools (access to what they need to demonstrate capabilities), and
recognition (acknowledgment that this contribution matters).
Skip any of these and your champion network, however big or small, collapses.
Peer learning networks built around these champions work because people trust colleagues doing similar work more than they trust IT experts explaining possibilities. When a fellow marketer shows how they use AI for campaign analysis, other marketers pay attention. When IT shows the same thing, it may be accurate or even substantively identical content but it’s less credible.
4. Use Case Discovery Through Observation
Suggestion boxes for anything, including/especially AI ideas, generate noise. Process observation generates signal. Watch how people actually work - the repetitive tasks, the places where they’re clearly struggling, the workflows they’ve built workarounds for. Those can reveal some opportunities where AI (or other sanctioned solutions) might help.
The departmental cases I mentioned earlier came from direct observation while working with the business. Watching someone spend days on explanatory text for standard variance patterns, product explainers, or brute-force tasks can make the opportunity obvious. Connecting similar problems across departments builds a portfolio of proven patterns from which teams can learn.
The Skills Gap Nobody Talks About
Someone good at risk assessment and policy writing isn’t automatically good at training design and change management. Just like someone excellent at facilitating workshops and building peer networks might be terrible at compliance monitoring and framework alignment.
Different people, backgrounds, and reporting structures. Well, if your org is big enough.
In sufficiently-sized orgs, governance typically reports to legal, compliance, or risk functions. Enablement typically reports to the CIO, Chief Data Officer, or a business transformation leader or teams. This reflects different drivers: Governance protects. Enablement accelerates.
So when you post a job that asks for both skill sets, you’re either not going to find qualified candidates or you’re going to get someone strong in one area and weak in the other. That’s the reality for SMBs and literally any not-large org who’s dipping their toes in the proverbial AI water.
How They Work Together
There’s an integration point that requires both functions working as partners rather than adversaries:
Governance without enablement produces policies nobody follows.
Enablement without governance produces risk accumulation.
Boston Consulting Group’s 2024 survey of 1,000 executives found that roughly 70% of AI implementation challenges stem from people and process issues, not technical problems.[2] This explains why governance frameworks can have perfect policies, comprehensive risk assessments, and well-documented approval processes, but still struggle with adoption because those things alone don’t/can’t drive adoption. If people don’t know how to use AI effectively - or perceive governance for whatever reason as an obstacle rather than an enabler - things start to unravel.
There’s an important feedback loop that runs both ways: enablement surfaces what governance makes too hard, governance identifies what enablement needs to emphasize. This is a slightly more useful way to think of it than the older-school “Enablement brings opportunities forward and governance evaluates and clears them.”
When governance only says “no” or “slow down,” enablement can’t succeed. Effective governance creates fast paths for low-risk use cases while maintaining appropriate scrutiny for high-risk ones.
My most recent experience demonstrates this. Built the governance framework first - NIST AI RMF alignment over a few weeks, had the foundational pieces in place. Then realized that having the framework wasn’t driving adoption, and we needed a separate enablement motion. Same leader (me), but distinct activities requiring different time allocation and different stakeholder engagement.
Before you can build effective enablement programs for the organization, you need executive understanding of what AI actually does versus what the hype cycle claims. If you don’t think that AI Hype Cycle is a thing, and a generally bad thing at that, just stop reading because you might think this section is about you. It’s perhaps not, but I do have some good first-hand stories.
An executive presented an “obvious win” with AI in that Microsoft Copilot subscriptions would dramatically reduce workload for their team. Based on investment club meetings, relentless YouTube ads, and vendor materials, they pushed for a large-scale pilot. The organization invested in the deployment to roughly 40% of staff. The productivity gains didn’t materialize as expected, though they gave it a solid month to see what their transformed use of Excel would look like. Teams found the tool occasionally useful but not transformative. The investment didn’t deliver expected returns because the expectation didn’t match a capability that was greatly inflated by marketing and, well, fraudulent optimism.
In a surprising case, the pattern repeated with AI-assisted coding. Even some technical staff expected AI to work like outsourced development - hand off problems with minimal ( ! ) description, get pasteable code in reply, rinse, repeat. When that didn’t happen, the tools were dismissed as useless rather than learning how to work with them effectively. The bias against AI-assisted coding persisted, viewing other signal-rich successes in the developer community as part of the hype cycle noise. (To be honest, the signal:noise ratio out there even today makes that divination difficult - the struggle is real.) Only when Claude Code came around was it truly easy to make the case, showing how context-rich projects allowed for better parsing of the problem, and ultimately better solutions. The tools there present the opportunity for augmentation over replacement, in almost every aspect.
Executive AI literacy isn’t about teaching leaders to build models or understand algorithms. (I dare you to go to an executive team meeting and start explaining graph RAG and vector embeddings...) Rather, it’s about developing accurate mental models of what current AI can and cannot do, where it makes sense to apply it, what’s required for successful implementation, and what realistic timelines look like. The opportunity is one to amplify signal, call out noise, and help folks navigate the LinkedIn and Substack jungles.
Scaling Without Unlimited Resources
Most organizations aren’t going to staff governance and enablement as two distinct teams immediately. The answer isn’t to give up on the distinction, but to maintain it conceptually even when one person handles both.
There are only so many hours in the day, though, so you’ll need to block separate time for governance and enablement work. Perhaps more importantly, you’ll need to measure them differently, and track meaningful adoption metrics alongside compliance metrics.
In particular, use your limited time most wisely using these four approaches:
Transform one department at a time rather than attempting organization-wide rollout.
Pick a business unit with clear opportunities and manageable scope. (Identifying departments with staff that have aptitude or intuition for AI - or a general thirst to innovate - doesn’t hurt.)
Build out both governance processes and enablement support for that unit.
Learn what works, document the patterns, and unlock expansion to another unit with your increasingly-large portfolio.
This concentrates resources where they can show results rather than spreading them too thin. It also builds credibility through demonstrated success rather than theoretical frameworks.
Shadow AI is Self-Enablement
One particularly effective argument for enablement investment on top of governance: it reduces shadow AI risk.
Research from the National Association of Corporate Directors shows that while 95% of senior leaders report investing in AI, only 34% are incorporating AI governance.[3] This investment gap creates the conditions for shadow AI to flourish. When you have governance but no enablement, people still need to get work done. They find AI tools that solve their problems, subscribe with corporate cards or personal accounts, and start using them without going through any review process. You discover this later, usually at an inopportune time.
In my article on shadow AI discovery (documented here), I cited research finding that organizations consistently underestimate their AI footprint by 3-5x. Marketing using the new copywriting feature released in their marketing automation SaaS; Sales using conversation intelligence now-embedded in CRM; Finance adopts “breakthrough forecasting capabilities” just by opening Excel. None of it went through governance review because either the team didn’t know about existing governance or policies, or they knew and deliberately avoided it because approved alternatives weren’t available or took too long to access.
Enablement channels this activity, so instead of teams finding their own solutions and creating shadow AI sprawl, you provide approved alternatives with faster access than unauthorized procurement. In this utopia, the path of least resistance leads through governance rather than around it.
This reframes both governance and enablement as risk management investment rather than just adoption acceleration. Yes, it helps people use AI more effectively. But it also reduces the governance challenge by making compliance the easier path.
What to Do Next
I’ve provided a lot of practical tips so far, but in the broad, sweeping sense there are a few things that can guide your burgeoning governance and enablement practices.
Draw a bright line between governance and enablement in your planning even if one person does both initially. Distinct goals, metrics, and activities for each function.
Measure adoption alongside compliance. Number of AI policies published or models approved won’t tell you if your AI program works. You need to know whether people are actually using AI to do better work, and the what that change looks like - metrics like active users, task completion time reduction, or business outcomes achieved with AI assistance.
This is perhaps the most important staff-facing improvement you can make to serve all of your governance initiatives: Create pathways for low-risk experimentation. If everything requires the same scrutiny, you’ll bottleneck on governance approval. Risk-based tiering works better - make low-stakes experiments fast, high-stakes implementations thorough.
When hiring, recognize that “AI Governance Lead” typically focuses on risk, policy, and compliance (backgrounds in risk management, compliance, security, or legal). “AI Enablement Director” typically focuses on adoption, training, and change management (backgrounds in organizational development, training design, internal consulting, or business transformation). If the job description heavily mixes both, define the split.
The Workable Pattern
Organizations using AI effectively - actually improving business outcomes, not just checking compliance boxes - have figured out that you need both governance and enablement as distinct, coordinated functions.
Governance frameworks establish boundaries and manage risk. Enablement programs help people work productively within those boundaries. Neither works without the other.
The failure pattern is treating them as the same thing. Hiring someone strong in governance but weak in enablement, then wondering why adoption stalls. Or building enablement programs without governance, then discovering unmanaged risk accumulation.
The job titles are splitting because organizations are learning this distinction matters. Adapt your hiring and organizational structure accordingly, or keep posting job descriptions that ask for unicorns while wondering why qualified candidates don’t exist.
Key Takeaways
Governance manages risk; enablement builds capability. Different skills, different measures, different organizational purposes.
Adoption is a change management problem, not a policy problem. Documentation doesn’t drive behavior change.
Internal champions do more than training programs. Peer learning from business users outperforms IT-led instruction.
Executive AI literacy isn’t optional. Leaders need accurate mental models before they can make good decisions about governance or set realistic expectations for enablement.
Shadow AI becomes inevitable when governance operates without enablement. Approved alternatives need to be faster than unauthorized procurement.
Credits: Claude Sonnet for editorial support; Google Nano Banana for image generation.
References
[1] EY. (2025, August 13). EY survey: AI adoption outpaces governance as risk awareness among the C-suite remains low. Retrieved from https://www.ey.com/en_ro/newsroom/2025/08/ey-survey-ai-adoption-outpaces-governance-as-risk-awareness
[2] Boston Consulting Group. (2024, October 24). AI adoption in 2024: 74% of companies struggle to achieve and scale value. Retrieved from https://www.bcg.com/press/24october2024-ai-adoption-in-2024-74-of-companies-struggle-to-achieve-and-scale-value
[3] National Association of Corporate Directors. (2024, December 12). Tuning corporate governance for AI adoption. 2025 Governance Outlook. Retrieved from https://www.nacdonline.org/all-governance/governance-resources/governance-research/outlook-and-challenges/2025-governance-outlook/tuning-corporate-governance-for-ai-adoption/
[4] McKinsey. (2025, August 13). Reconfiguring work: Change management in the age of gen AI. Retrieved from https://www.mckinsey.com/capabilities/quantumblack/our-insights/reconfiguring-work-change-management-in-the-age-of-gen-ai