AI readiness is built in layers. Mindset creates accountability, Lanes provide safe speed, Mechanisms build trust. Below are the working materials behind each layer — not slides, the actual toolkit.
Governance starts here. People own the risk they understand.
The foundational layer isn't technical — it's mindset. You teach people to drive before you hand them the keys. This is operationalized as a full Prosci-structured change toolkit: 21 templates across the three phases, so "change management is the foundation" is a capability, not a slogan.
Phase 1 · Prepare
Change Management Strategy — anchor document
Change Characteristics — size + risk profile
PCT Assessment — leadership / PM / CM health
AI Change Readiness — baseline mindset, shadow AI
Sponsor & Coalition Map
Stakeholder Analysis — impact + lane mapping
Phase 2 · Manage
Sponsor Roadmap — incl. authority-to-say-no
Communications Plan — ADKAR-staged
Manager Coaching — CLARC for lane enforcement
Training Curriculum — "driver's ed for AI"
Resistance Management — shadow-AI signals
ADKAR Assessment + Gap Action Guide
Phase 3 · Sustain
Reinforcement & Sustainment — drift triggers
Adoption Metrics Dashboard — KPI + RAG
Lessons Learned / AAR — red-team the change
Change Agent Network Playbook
AIM Collateral
AIM–Prosci Mapping one-pager
Executive Briefing Deck
Lane Onboarding Guide — one per lane
AI Acceptable-Use Acknowledgment
21 operational templates — the change management that makes governance stick.
Why it matters: 46% of healthcare organizations cite their own workforce's skills as the #1 technology gap. The weakest boundary in any system is the person who doesn't know they're crossing one. This layer closes that gap before a single model is connected.
Approved use cases, controlled paths — the governed path is the fast path.
Don't stand at every gate. Build a small number of paved lanes with the guardrails built into the lane itself. Try it — describe a use case and it finds your lane, shows the controls, and provisions it. Vendor-procured AI follows the same lanes, but is governed by the contract, the connection, and the kill switch — because you can't govern the model.
1 · Describe your AI use case
Who built it?
Built in-houseSageMaker / Bedrock
Vendor-procured AISaaS / third-party
Can you shut off the vendor's API on demand? (your kill switch)
Yes — we control the key
No — can't cut it independently
No independent shut-off fails the containment floor — it caps the lane.
Vendor red-team / safety evidence?
Published resultswe can review
Integration onlyour boundary, not their model
None available
Real PHI and agentic lanes need published evidence — or integration testing + update-as-revalidation.
What kind of AI is it?
Generativeproduces output
Agentictakes actions
What data does it need?
Public / syntheticno patient data
Fake PHIrealistic, not real
Real PHIactual patient data
Where does the fake PHI come from?
Certified catalogpre-vetted
Your own datawe scrub + certify
Either way the data is guaranteed safe — so no review is needed to run.
Will this agent ever need to touch PHI?
No, neverpublic only
Yes, eventually
No PHI = fast track to production. PHI = full path through Lanes 5 and 6.
Already proven in the lane below? (passed red-team, zero breaches)
Not yet
Yes — validated
No model gets real PHI or production until it has earned it on synthetic first.
Which cloud?
AWS
Azure
GCP
One lane definition; enforced with each platform's native controls — owned by the CISO.
Containment is universal. A fail-closed, out-of-band perimeter sits outside the guardrails. If a model reaches it, it shuts down automatically — the kill switch lives where the model can't touch it. For vendor AI, the kill switch is your ability to revoke the API.
Real PHI is earned, never granted. Every model proves itself on synthetic data before going near real patient data or production. Vendor models that can't prove it — no shut-off, no red-team evidence — are capped at the no-real-data lanes.
The board sees everything. Lanes 1–2 as an FYI, Lane 3 with a BA recommendation, Lanes 4–6 for approval — plus cost vs. measurable benefit for every lane, with authority to shut any lane down.
Why it matters: prohibition drives AI underground into personal accounts where nothing is logged. Lanes make the safe path the fast path — so nobody has to hide the work, vendor tools included.
Five controls for AI you can't keep up with.
None of this requires predicting where AI is going — all of it assumes you can't. All five are mandatory in every lane, dialed to the lane's risk. Click a mechanism to see the evidence it produces.
Mechanism
The knob that turns
Lightest → heaviest lane
1 · Bound it
How narrow the allowed actions are
Broad allowlist → deny-by-default, explicit approval per action
Evidence: the action boundary written in code and in plain language — what it may decide, escalate, and never touch.
2 · Attribute it
Granularity + immutability + ownership
Basic logging → full ALCOA+, immutable WORM, a named owner per action
Evidence: a tamper-evident audit trail you can reconstruct — inputs, model version, role, and controls in force at the moment.
3 · Monitor drift
Threshold tightness + what a breach triggers (monitoring is continuous in every lane)
Evidence: a live drift dashboard against the validated baseline — never periodic, always on.
4 · Red-team
Rigor + independence (results always published to the board)
Self-test → independent red-team required before each promotion
Evidence: red-team results — including the failures — published to the board as the basis for its approval. For vendor AI: the vendor's published results, or your integration-level testing.
5 · Say no
Who can pull it, and how fast
Automatic perimeter shutdown → committee/exec halt + documented stop criteria
Evidence: documented stop criteria and kill-switch test logs. For vendor AI: proof you can revoke the API and sever the integration.
You tune the guardrails. You never tune the perimeter. The perimeter is the constant; the inner guardrails are what you iterate. A perimeter trip is always a guardrail failure — never a reason to loosen the perimeter.
1
Perimeter trips → automatic shutdown (the hard floor, every lane).
2
The trip is a finding → the team redefines the inner guardrails.
3
Re-test under red-team until the perimeter no longer trips.
4
Publish the red-team results to the board.
5
Committee decides — promote, more testing, or kill.
Why it matters: a control you can't produce evidence for doesn't exist, and a control you've never tried to break is an assumption. You cannot bring a model to committee while it's still tripping the perimeter.