We run what we recommend.

Healthcare is a hard place to put AI. Decisions move fast and the tolerance for error is low. That is exactly why it makes a good proving ground: a method that holds up where a wrong output can hurt someone will hold up anywhere. Across three courses, the founder took one problem, clinical decision support, through three levels of the same discipline.

It started as a system design. In a four-person team project, the group specified a physician's assistant AI: a tool that reads test results such as imaging, bloodwork, and patient history and flags areas of concern as a secondary check for the clinician, never a replacement for clinical judgment. The founder's contribution was the systems and process scoping and the alignment and accountability sections. The team named the risks before the tooling: data privacy, accountability for the final decision, and the quality of the data underneath.

He then took the problem further alone. A structured risk and impact assessment stacked real standards into one operating plan: the NIST AI Risk Management Framework as the lifecycle backbone, FDA guidance to set intended-use boundaries, a human-rights overlay, and a named map of every actor from system owner to impacted patient. One design move did most of the work. Limiting the tool to summarization and evidence retrieval, rather than treatment recommendations, lowered the risk profile before a single control was written.

The capstone was a policy brief written for a hospital chief compliance officer. It argues that no new legislation is required to govern EHR-embedded decision support: four federal instruments already in force, from the FDA, ONC, HHS, and NIST, can be unified into one risk-tiered program with a pre-deployment gate and a post-deployment monitoring loop, owned by a cross-functional committee. Out of this work came one sentence of the founder's, first written in the risk assessment and carried into the policy brief: the model is rarely the risk; workflow, validation, and accountability design are.

Take one problem all the way down: design the system, assess the risk, then write the governance program a named person can run.

A modernization program can install every piece of hardware on schedule and still fail. The founder's graduate case study in organizational change management starts from that premise: the change will not succeed or fail on the strength of the technology. It will succeed or fail on whether the people touched by it understand why it is happening and decide they want it.

The case is a branch-modernization program at a major retail bank, anonymized in the coursework. The plan applies the ADKAR model stage by stage and deliberately spends its effort on the two stages organizations skip. Knowledge and Ability get budgets and training plans. Awareness and Desire get an email and an all-hands, and then leadership wonders why adoption stalled.

Measurement got its own deliverable: an eight-item survey instrument, weighted across the ADKAR stages and triangulated against behavioral signals such as training completion and error rates, so adoption is diagnosed rather than assumed. One caveat, stated plainly: the evaluation was run on planning estimates to prove out the method, and the deliverables label those figures as estimates, not field data. We hold this page to the same standard.

The most useful finding was not in the plan. Analyzing a stalled AI-metrics adoption effort, the founder identified a gap that standard change models have no clean home for: people who are structurally rewarded to use an AI tool but do not trust it, because they cannot audit its reasoning the way they audit a formula. Trust sits before desire. When we assess whether an organization will adopt an AI system, we check trust before we check training.

Working technology does not produce adoption. Diagnose whether people trust the tool and want the change before funding training, measure adoption instead of assuming it, and plan reinforcement before go-live.

Looking back across the degree, the founder's governance work turned out to be one method applied at three altitudes: design time, assessment time, and program time. We have since built our AI governance, risk and compliance service around that method.

At design time the method is a mitigation skeleton, extracted from the team-designed clinical AI project. State the problem, the operator's goals, and the AI's tasks and outputs. Name the direct risks around privacy, accountability, and data quality, and name the externalities beyond them. Then stack the mitigations: a human making the final decision, explicit disclaimers, retrieval grounded in cited sources, and recurring audits of model performance.

Move up one level and it becomes the impact framework from the clinical work: NIST AI RMF as the backbone, intended-use boundaries from regulatory guidance, named actors, and a staged plan for engaging stakeholders from scoping through operations. The point is to know, before deployment, who is accountable for what and how you will know when something drifts.

The top of the ladder is a risk-tiered governance program: take the instruments already in force, unify them into a pre-deployment gate and a post-deployment monitoring loop, and give the loop an owner. The recurring conclusion is that organizations rarely need new rules. They need the existing ones assembled into something a named person can run. That is the shape of our governance engagements, and we worked the method out on paper, in graduate research, before offering it as a service.

Same questions, three altitudes: mitigate at design time, assess before deployment, operationalize as a program. Meet the organization at whichever altitude it is at and run the method from there.