Policy and training are the start. The value lives in the operating model.

There's a predictable arc to first-generation AI programs. Leadership approves a policy. Staff attend a training. Licenses get bought. For a few weeks, everyone experiments — and then the pilot energy dissipates, usage settles onto two or three enthusiasts, and a year later someone asks "whatever happened with the AI thing?"

Nothing failed, exactly. The organization did the visible parts — basic enablement: acceptable-use policy, staff awareness, tool rollout. What it never built was the machinery that turns individual experimentation into organizational capability. That machinery is the operating model, and it's the difference between AI as an event and AI as a competence.

The questions basic enablement can't answer

Policy and training tell staff what they're allowed to do. They're silent on the questions that determine whether anything compounds:

• Which work should AI touch first — and who decides?
• Of the forty ideas staff will generate, which three are worth a pilot?
• Is our data actually ready for the use case we're most excited about?
• How do we know whether a pilot worked, and who calls it?
• When something works for one person, how does it become how the whole team works?

No policy answers these. They need owners, intake, criteria, and cadence — process, not prose.

The eight artifacts of a working operating model

In our AI Depth engagements, the operating model is deliberately concrete: eight working documents your team runs without us in the room.

1. Use Case Register — every candidate use case, ranked by value and risk tier. The intake point for staff ideas, so enthusiasm has somewhere to go.
2. Approved Tools Register — what's cleared, for what, on which accounts. Reviewed quarterly.
3. Governance Operating Model — who approves use cases, who owns exceptions, who reviews incidents. Names, not committees.
4. Data Readiness Report — each data domain scored Ready / Address / Block. This is where most "let's automate member service!" ideas meet reality — and get sequenced instead of abandoned.
5. Pilot Design Playbook — every pilot gets a scope, a small named user group, allowed data, a success measure, and a go/no-go date. Pilots without stop conditions become zombies.
6. 90-Day Adoption Review — evidence and a written recommendation: scale, hold, or stop. The forcing function that keeps the program honest.
7. Acceptable Use Policy — one component among eight, in plain language. (Our free template covers this piece.)
8. Operating Roadmap — what happens next quarter, and who owns it.

The people layer: why cohorts beat courses

Documents don't adopt AI; people do — and skill spreads socially, not by curriculum. When ETTE ran its own internal AI Champions program — fifteen staff, four months, on live ticket work and client deliverables — the mechanisms that mattered most weren't training sessions. They were mentor pairing (every full-team joiner paired with a pilot-group peer who'd hit the same walls a month earlier) and skills as shared IP (when someone built a useful pattern, it was reviewed and promoted to an organizational skill everyone gets by default). Six-plus organizational skills were deployed to the whole team by closeout, each one version-controlled.

A course teaches what's possible. A cohort working on real tasks, with a library that captures what works, teaches what's repeatable.

The cadence that keeps it alive

The last ingredient is rhythm: a quarterly governance review where the registers get updated, stalled pilots get called, and one or two new use cases get promoted. Ninety minutes a quarter is enough — the point isn't ceremony, it's that the operating model is a living system with a heartbeat, not a binder from an engagement that ended.