Daniel Cho is CIO at a specialty healthcare network with operations across thirty-one states. The network runs a stack that has to satisfy HIPAA on the patient-data side, SOC 2 on the operational side, and the procurement scrutiny of a board that has watched two peer networks suffer breaches that became national stories. He spent the first half of 2025 evaluating AI deployments for the network's clinical-operations workflow and the second half of 2025 doing the install. The deployment has been in production for six months without producing a compliance event. We sat down with him for forty-one minutes.
On why he refused the pilot framing.
Knyte: Most healthcare AI deployments start as pilots. You did not.
Daniel Cho: We did not, and I think we are about to see a lot of evidence for why pilots in regulated environments are a category mistake. A pilot in healthcare is operationally a real system. It touches patient data, or it does not — and if it does, it is subject to the same compliance regime as a production system. The pilot framing creates a fiction that the system is not yet load-bearing, which encourages the team to defer the controls that would have made it load-bearing. Then the pilot succeeds — by which I mean it produces some demos that look good — and the team is asked to graduate it to production. At which point the controls have to be added retroactively, which never works.
Knyte: What did you do instead.
Daniel Cho: Architecture first. I told the vendor team — and I told my own team — that we were not going to deploy anything that was not built to the controls a production system would need. If that meant the deployment took four extra weeks, it took four extra weeks. The vendor's first reaction was to push for a smaller scope so we could ship faster. I refused. The reason for the refusal is that a smaller-scope pilot in a regulated environment generates the same compliance risk as a full deployment, and the risk-adjusted economics of a small pilot are catastrophic. The right choice is to build the architecture once, with the controls in place, and then deploy carefully.
On what "architecture-first" meant in practice.
Knyte: Walk me through the controls you would not compromise on.
Daniel Cho: Five things. First, tenant-owned weights. The model lives inside our environment, fine-tuned against our data. No part of the patient corpus crosses our tenancy boundary. The compliance team would not have approved a deployment with shared embeddings, and frankly I would not have either. Second, audit trails on every model call. We need to be able to tell a regulator who saw what data, when, and what the model produced from it. The audit trail is signed and surfaceable.
Daniel Cho: Third, editor-in-the-loop as the default for any output that would touch a patient record. The runtime defaults to review; bypassing requires explicit opt-out and is logged. We have not bypassed once. Fourth, an eval suite that includes our specific failure modes — patient-identifying-information leak detection, clinical-coding regression, our specific tone requirements. The vendor's generic eval suite was not enough. We built ours and run it on every model promotion. Fifth, a defined rollback procedure that any operator can execute in under five minutes. We have rolled back twice in six months, both times preemptively after eval signals that turned out to be benign. The discipline of the rollback being available is what made the deployment safe.
Knyte: Five controls is a lot to get in place before deployment.
Daniel Cho: It is the right amount. Each one of them maps to a regulatory or operational risk that has bitten somebody in this industry. None of them is theoretical. The cost of building them up front is bounded. The cost of adding them retroactively after a compliance event is unbounded.
On the install timeline.
Knyte: How long did this take.
Daniel Cho: The architecture call was forty-five minutes. The data classification and security review were three weeks, which was the bulk of the calendar time. The install itself was the standard ninety-day rollout with the controls layered in. We went live with one workflow at the end of week thirteen. We added the second workflow in week eighteen and the third in week twenty-four. The pace was deliberately slow, by the standards of pilots in this industry, because the consequence of moving fast in a regulated environment is the consequence I do not want to have.
On the eighteen-month transformation.
Knyte: You have called this an eighteen-month transformation in other conversations. What do you mean.
Daniel Cho: The first six months were the install and the initial workflow ramps. The next twelve months are the depth phase — expanding the corpus, refining the editor-in-the-loop signal, watching the compounding curves, and adding workflows on top of the same architecture. The transformation is not the deployment. The transformation is the eighteen-month discipline of letting one architecture do the work of what would otherwise have been seven or eight overlapping vendors.
Daniel Cho: I will say one specific thing about that timeline. We are at month six. The compounding curve on the first workflow is bending exactly the way the architecture-first frame predicted it would. The deployment is producing materially more useful output than it was three months ago, with the same headcount. That is the reason we are not buying additional vendors. The architecture is doing the work, and the curve is the proof.
On the cultural change.
Knyte: What did you have to change in your organization to make this work.
Daniel Cho: The biggest change was the procurement conversation. We had been treating AI tooling like SaaS — small contracts, individual department decisions, low procurement bar. We changed to treating AI tooling like infrastructure — every AI procurement decision now goes through the same architecture review that, say, our cloud-region decisions go through. The bar is higher. The decisions take longer. They are also better.
Daniel Cho: The second change was inside the operations team. We had been allowing operators to use whatever AI tooling they liked individually for tasks that were not in scope of the official deployment. We have stopped allowing this. Not because the individual usage was wrong, but because the asset that compounds is the corpus, and operators using individual tooling were producing outputs that the corpus never saw. The institutional learning was leaking out into vendors we did not control. We tightened the policy. The operators understand. The architecture compounds because the editorial signal stays inside the architecture.
On what he tells peer CIOs.
Knyte: What is the message you are giving peer CIOs at conferences.
Daniel Cho: Three things. First, do not pilot. The pilot framing is a fiction in regulated environments. Build the architecture and deploy carefully. Second, the controls cost less to build up front than to add later by a factor I would not have believed before I had measured it. Third, the architecture-first frame produces a deployment that compounds. The pilot frame produces a series of theaters that have to be redone. After eighteen months you can either be six months into a compounding deployment, or you can be on your fourth pilot of the same workflow. I know which side of that I would rather be on.