It's common to see companies with a well-designed data governance framework on paper, a purchased catalog, roles defined on an org chart — and almost nobody using any of it six months later. The problem is almost never technical. Standing up a governance program is an organizational change like any other, and like any other, it requires explicit change management, not just good process design.
Two models that actually work, applied to data governance
There's no need to invent a bespoke adoption model for data governance: the two most widely used change management models in the corporate world apply directly.
ADKAR (Prosci), applied to Data/AI Governance
| ADKAR stage | What it means | Concrete action in data governance |
|---|---|---|
| Awareness | Understanding why the change is needed | Explain the real problem (an incident, an avoidable fine, a bad decision from wrong data), not just "we have to comply with the AI Act" |
| Desire | Wanting to participate and support it | Show what each team gains, not just what's required of them — less time hunting for data, less rework from errors |
| Knowledge | Knowing how to do it | Short, practical training, not an 80-page manual nobody reads |
| Ability | Actually being able to apply it | Ready-made templates and tools, not asking every team to invent its own process |
| Reinforcement | Making sure the change doesn't get reversed | Visible KPIs and periodic review in the governance committee, not an initiative that launches and gets forgotten |
Kotter, for the program launch
John Kotter's 8-step model fits especially well in the launch phase, when the program has no traction yet: establish a sense of urgency, form a powerful coalition with real decision-making authority (not just the data team), create a vision for change, communicate the vision constantly, empower others to act on the vision by removing obstacles, generate short-term wins, consolidate gains to keep momentum, and anchor the new behavior in the culture before declaring the program "done".
Most common adoption mistakes
- Top-down mandate with no explanation — a leadership email saying "from now on, document everything in the catalog" with no context produces surface-level compliance, not real adoption.
- Treating it as an IT-only or data-team-only project — data governance affects how marketing, sales, and operations work; if those teams don't take part in the design, they won't adopt it.
- No visible result in the first 90 days — without an early, concrete win, internal support erodes before the program has a chance to mature.
- Confusing "the process is documented" with "we have adoption" — a procedure that exists in a document but that nobody actually follows isn't data governance, it's paperwork.
How to measure whether adoption is working
Adoption isn't measured by "did we do the kickoff?" — it's measured by real usage indicators:
- % of new systems/processes that go through the governance process from day one, not retroactively.
- % of teams actually using the catalog or templates without someone having to remind them.
- Average response time when someone asks "can we use this data for this?" — if it takes weeks, the process isn't embedded in daily work.
- Real participation in the governance committee — attendance, decisions made, not just the committee's existence on an org chart.
If the program already has executive sponsorship but lacks the body that sustains the reinforcement phase, how to build an AI governance committee from scratch covers exactly that — who should be in the room and how often it should meet.