Q: How to deploy health AI: what is the main bottleneck keeping tools out of hospitals and universities? A: The University of Texas at Austin study found the main bottleneck is enterprise integration—tasks like single sign-on, role-based access, and deeper information security reviews—rather than coding or early provisioning. These enterprise steps were the longest and most variable stages across the cases studied. Q: What do the authors mean by “deployment burden”? A: Deployment burden is the organizational, technical, and coordination work required to move a locally developed AI web application into legitimate institutional use, operationalized across five dimensions. Those dimensions are temporal burden, pathway-discovery burden, dependency burden, enterprise integration burden, and collaboration-context burden. Q: Which early provisioning steps were consistently fast in the study and how long did they take? A: Early provisioning steps were fast: obtaining cloud storage access took about one business day, subdomain setup took three business days, and enterprise AI licenses plus Information Security Office review took one to two business days. The study shows the long delays occurred later during enterprise integration rather than during these initial steps. Q: How can teams avoid delays from “pathway discovery” when they plan how to deploy health AI? A: The article recommends mapping the pathway before writing code by deciding on the owner, users, data, hosting, sign-in, and required approvals on day one to prevent weeks lost to figuring out next steps. Clear sequencing and named contacts reduce misread orders, such as waiting for an AI license before setting up cloud storage, which the study found could be unnecessary. Q: What staged rollout approach does the study suggest for deploying health AI safely and efficiently? A: The study suggests starting with a low-risk web pilot using minimal data, collecting real usage logs and feedback, then adding SSO, audit logging, and stricter controls only when the pilot demonstrates value. Deeper integrations like EHR or student records should be staged last with a clear risk–benefit justification. Q: How should cross-institution collaborations be managed to prevent months-long access and hosting delays? A: Plan for external collaborators by setting up a shared sandbox with clear data-use terms, defining ownership of the domain, code repository, and cloud bills, and using guest accounts or federated SSO so outside staff can contribute without workarounds. Teams should also agree in advance on where the app will live at launch and who will maintain it to avoid control disputes. Q: What institutional changes can reduce repeated deployment work across teams without lowering governance? A: The authors propose a studio-like shared service that offers early scoping sessions, maintains reusable assets (cloud buckets, subdomains, enterprise AI licenses), publishes templates and a live playbook, and escalates complex integration issues. This approach standardizes repeat steps while preserving compliance and review processes. Q: Which metrics should teams track to measure and reduce deployment burden? A: Teams should log calendar days for each stage, tag waits by the owning office (security, identity, networking, legal, IRB, or team), and count back-and-forth communications and resubmissions to identify root causes. Weekly reviews to clear stuck items and fix process gaps were recommended to reduce ongoing maintenance burden.