Aprender a gobernar
la IA en hospitales.

Propósito y tres decisiones de gobierno

Welcome to this audio study guide on artificial intelligence and hospitals in Latin America, shared by Roberto Echeverría. It is made for a walk, a commute, or any time when you prefer to learn without looking at a screen. Our question is simple: before a hospital uses a new AI capability, how does it decide who can approve that use? A demonstration, a vendor contract, and an enthusiastic champion do not answer that question. A usable policy connects decisions to an approved rule, a defined process, and a responsible owner. Keep those three ideas in mind throughout the chapter.

The starting source is the Coalition for Health AI's Domain One playbook on AI policy. It identifies three baseline operational controls for healthcare delivery organizations. One: a formal policy approved by leadership and accessible to relevant staff. Two: key concepts and the scope of AI use, including an approval process. Three: designated oversight for changes to the policy. This episode uses those controls as reference points. The explanations, examples, and study questions are original. The full source is linked with the episode. Always consult it directly, especially where a decision depends on the exact wording of a source.

Control, sugerencia y obligación legal

Begin by separating three kinds of statement. The baseline controls describe what this voluntary governance playbook considers foundational. The implementation guidance offers possible ways to put them into practice. Local laws and accreditation requirements are a different category entirely. The playbook does not create a clinical standard of care or settle the law in any particular jurisdiction. When speaking with a hospital director, precision matters. Saying that CHAI's playbook recommends a named owner is accurate. Saying that every hospital is legally required to create a particular committee because CHAI said so would be misleading.

Use that distinction as a listening technique. When you hear a practice, ask: is this one of the three controls, a suggested implementation, or our own thought experiment? For instance, someone overseeing policy changes is part of the core control. A particular annual timetable is suggested in the playbook's guidance. Testing a fictional hospital case is our learning method. These distinctions make the guide more useful, not less. You can take the governance questions into different health systems while leaving decisions about local law to qualified people in those systems.

Aprobación y patrocinio de la dirección

The first control calls for a formal AI policy approved by organizational leadership. Why at that level? AI decisions cut across departments. Clinical teams consider care and workflow, technical teams examine integration and security, privacy teams examine data flows, and operations teams manage training and resources. A rule written by one group alone may not resolve conflicts among them. Leadership approval creates common authority. It also turns safety, workforce effects, and accountability into management concerns rather than leaving them as technology preferences. A hospital can choose its own approval body; the important point is that approval is real and traceable.

Imagine asking a board to show the current policy. Can someone identify its version, approval date, and approving authority? Can they explain how it relates to rules for patient information, cybersecurity, procurement, and quality? Those are our practical questions, not an official audit checklist. A cross-functional review before approval can prevent contradictions. If one policy permits a data transfer and another forbids it, staff face conflicting instructions. An executive sponsor is useful when they help resolve those conflicts and allocate time for a process that crosses clinical, technical, and operational boundaries.

Acceso del personal e IA no declarada

The policy also has to reach relevant staff. A PDF stored in a committee folder may have formal approval yet little effect on daily decisions. Think of the people who buy, configure, supervise, and use AI. Do they know where the current policy lives? Do they know when a new feature requires review? If a nurse manager and a technology buyer give incompatible answers, the institution has a communication problem even if the document is well written. Accessibility includes discoverability and a practical route to ask questions. It does not mean that everyone must become an expert in the entire AI lifecycle.

The CHAI playbook discusses shadow AI: AI capabilities used, embedded, procured, or developed outside an organization's established intake and approval path. The point is not to catch people out. The point is to make legitimate use visible early enough to govern it. A vendor may enable a feature in an existing system. A research team may run a local model. Staff may use a public assistant to draft material. The risks differ, but each raises a visibility question. A clear and approachable request process can reveal both what people already use and what they hope to use next.

Definiciones y alcance de la política

The second control asks a hospital to define key concepts, its scope of AI use, and an approval process. The word AI is broad. It may refer to predictive models, generative assistants, machine learning in imaging, or functions embedded in existing software. Definitions from regulators and technical standards vary because their purposes vary. A hospital does not need to solve every philosophical disagreement. It needs a usable boundary. Which kinds of function require governance? Which do not? What should a staff member do when a tool sits near the boundary? A definition succeeds when it supports a decision.

Consider four ways a capability can enter a hospital: an external vendor product, an internal project, an update to an existing platform, or direct use of a public AI service. Now consider clinical, research, administrative, and operational settings. A policy can explain which combinations require formal review and what level of review is proportionate. It should also make prohibited uses intelligible, such as sending sensitive patient information to an unapproved public service. A useful scope is broader than a list of purchased products, because the same product can be used in different ways with different consequences.

Ruta de aprobación proporcional al riesgo

If every proposed use requires the same committee and evidence package, governance may become a bottleneck. If almost no use receives meaningful review, the policy becomes decorative. A risk-based route asks what the tool does, who is affected, what information it processes, how much autonomy it has, and what would happen if it failed. A system that drafts an internal meeting note is different from one that influences clinical priority. That does not mean the first is risk-free or the second unacceptable. It means the depth and expertise of review should follow the actual use.

Try a first-pass conversation instead of beginning with a giant form. What task will the tool support? Who will see its output and act on it? Is it drafting, recommending, or deciding? What data enters it and where does the data go? Who can stop its use if it behaves unexpectedly? These questions are our own study exercise. They help identify which clinical, privacy, security, legal, and operational reviewers should participate. The policy should make the route clear to a busy department, including what happens when a use falls into a grey area.

Ciclo de vida, proveedores y cambios de uso

Approval is a starting point, not a finish line. A model can change, a vendor can update its product, and staff can use an output differently from the way a pilot described. The playbook connects policy to governance across the AI lifecycle and points readers toward other playbooks for detailed processes. A hospital should be able to ask what evidence supported an approval, what conditions were attached to it, how the use will be monitored, and what change would require renewed review. A product name alone does not tell you whether an old approval still fits a new feature.

Here is a fictional case. A hospital approves a tool to help allocate staff time. Later, the supplier adds a feature that recommends which patient requests receive priority. The software brand has not changed, but the purpose, people affected, and consequences have. A policy organized only around vendor names may miss that. A policy organized around use and risk can trigger a fresh question. What did we approve, and does it still describe reality? Records, vendor communication, and monitoring help answer. Not every update is a crisis, but every organization needs a way to notice meaningful change.

Relación con privacidad, calidad y seguridad

An AI policy does not replace existing rules for data protection, security, patient safety, clinical quality, procurement, research, or consent. Repeating every rule in one document can create contradictions and unnecessary maintenance. The better question is where the AI policy adds a decision and where it points to an existing authority. If a proposed tool transfers patient information to an external service, AI approval does not override the organization's data protection rules. If a tool changes a clinical workflow, established clinical governance still matters. A cross-functional review helps connect these systems before the policy is approved.

Roles should be clear even if job titles differ by institution. Who reviews the clinical implications? Who examines security and integration? Who checks what a vendor can document? Who records the decision and its conditions? A smaller hospital may extend an existing committee. A larger network may have a dedicated pathway. Either way, the policy must connect requests to accountable people. Informal conversations may be valuable, but they are difficult to audit or repeat when the person who remembers the decision leaves the organization.

Responsables de revisar y actualizar

The third control asks for designated oversight of policy changes. Even an excellent policy can become obsolete. New applications appear, technologies gain new capabilities, and an adverse event may reveal an unclear rule. Someone must notice, propose revisions, obtain appropriate approval, and communicate what changed. The owner may be an individual or a group, but responsibility needs to be identifiable. Without that, a policy may drift through informal edits or remain frozen while the hospital's AI uses evolve.

The playbook suggests regular review, at least annually, and review triggered by important events. That is implementation guidance, not a universal legal timetable. A change record can answer four useful questions: what changed, why, who approved it, and when it took effect. Staff should also know whether a revision affects uses that were approved under an older version. Imagine that a policy expands to cover agents that initiate actions in connected systems. Which existing projects now deserve another look? Maintenance is the bridge between a written rule and the hospital's current portfolio.

Caso práctico: función nueva en un sistema conocido

Test the ideas in a fictional hospital. Its appointment system has been in place for years. An update introduces a model suggesting which requests get an earlier slot. The vendor calls this an ordinary improvement, and a department wants to enable it next week. The policy should help answer whether the function falls within its definition and scope, whether a new review is needed despite the old purchasing approval, what information the model uses, and whose decisions it influences. These questions come before a yes or no. Governance is the ability to make the decision in a visible, responsible way.

Who should participate? Operations can describe the workflow. Clinicians can assess whether prioritization might affect care. Privacy and security teams can inspect data flows. Procurement can ask what the supplier promises and documents. The hospital may decide to test the function before wider use. This example does not prescribe one correct outcome. It shows how a policy turns a vague proposal into specific questions, responsible reviewers, and a recorded decision. If nobody knows who owns that decision, the policy has not yet become a practical process.

Caso práctico: IA generativa para pacientes

Now consider a communications team that wants generative AI to draft patient education material. The team says it will not upload identifying patient data. That may reduce one concern but does not settle all of them. Does the hospital approve this service? Who checks the clinical accuracy and reading level before material reaches patients? Is the tool's output clearly treated as a draft? The policy need not apply exactly the same review as it would to a model that directly influences diagnosis. It should still identify scope, approval, and human responsibility.

Suppose staff later paste real patient examples into prompts or publish drafts without clinical review. The use has materially changed from the one first described. Clear communication and a route for questions help staff recognize that change. This is why governance should enable thoughtful experimentation rather than simply prohibit everything unfamiliar. The institution can support useful exploration while requiring people to describe the use honestly, protect information, and escalate when a project begins to affect patients or clinical decisions in a new way.

Preguntas directivas y repaso activo

If you were advising a hospital director, begin with evidence. Show me the current AI policy and the authority that approved it. Show me how a department decides whether a proposed use falls within scope. Walk me through one recent request from intake to decision. Name the owner of the next policy revision. Show me how staff learn that a rule changed. These are our own diagnostic questions, not an official CHAI checklist or an accreditation audit. Ask local clinical and legal leaders what their own requirements add. Do not import a foreign legal rule by implication.

For active recall, pause and answer four questions aloud. What are the three baseline controls? Why is accessibility different from simply having a PDF? Name two ways AI may enter a hospital without a new product purchase. What is the difference between a designated owner and a suggested review calendar? Use the chapter markers to revisit uncertain answers. This audio guide is a complementary way to learn and deepen the concepts while moving through your day. It does not replace the original document. Open CHAI's Domain One playbook from the source links, compare its controls with its examples and guidance, and note where a decision belongs to the hospital itself.

Propósito y cuatro controles

Welcome to the second chapter of Roberto Echeverría's audio study guide on artificial intelligence and hospitals. This chapter is about people and decisions. A policy may explain what should happen, but an organizational structure determines who receives a request, who asks difficult questions, who approves a use, who watches it after launch, and who acts when something goes wrong. You can use this guide while walking or doing another activity. Return to the original Coalition for Health AI playbook whenever you need its precise wording or examples.

The Domain Two playbook identifies four baseline operational controls. First, assign appropriately trained people to critical AI governance responsibilities. Second, establish a formal committee structure that brings those responsibilities together. Third, create an intake, assessment, and monitoring process for proposed and deployed tools. Fourth, specify how concerns and incidents reach the governance structure for resolution. These are the four anchors of this chapter. The document treats them as baseline controls in a voluntary framework. Its many implementation examples are suggestions to adapt, not universal legal requirements or a clinical standard of care.

Keep one question in mind: if a department proposes a new AI feature this morning, can everyone identify the person who receives it, the body that decides, the evidence required, the owner who monitors it, and the path for a serious incident? If any answer is missing, the organizational chart may look complete while the real process is not.

Funciones y principios de IA responsable

The playbook begins by mapping governance functions before naming job titles. A hospital may need risk, bias, and impact assessment; lifecycle oversight; validation of usefulness and safety; data stewardship; vendor review; workforce education; feedback; and incident response. The same person can sometimes hold several responsibilities, especially in a small institution. What matters is that responsibilities and authority are explicit, and that the institution has the competence and time to carry them out.

Risk-based governance is a recurring idea. A low-risk administrative proposal may need a short review. A system that influences clinical prioritization may need stronger evidence, broader expertise, and closer monitoring. Risk categorization is not a synonym for approval. It decides how deep the review should be. The related CHAI playbooks cover risk assessment and AI lifecycle management in greater depth; Domain Two asks who performs these functions and how their work reaches a decision.

The source also connects governance to responsible AI principles. Consider usefulness, usability, efficacy, fairness, safety, privacy, security, and transparency. Each principle needs an operational counterpart. For example, fairness can imply subgroup evaluation, and transparency can imply suitable documentation and training for the people affected. A principle in a presentation cannot protect patients by itself. The structure must assign evidence collection, review, follow-up, and authority to intervene.

Responsables, capacidades y autoridad

Control two point one concerns critical roles and responsibilities. The playbook suggests surveying the skills of clinical leaders and leaders in technology, quality, risk management, and clinical informatics. A title alone does not establish expertise in predictive, generative, or agentic AI. A skills assessment can reveal who needs training, who can be supported by an external expert, and where a new role may be justified.

Several authorities must be distinguishable. Who may introduce an AI solution? Who performs technical or clinical validation? Who approves a pilot? Who authorizes procurement and deployment? Who owns the tool in daily use? Who can suspend it, switch it off, or retire it? If the institution cannot answer these questions for internally built tools and vendor products, an incident will expose the gap. A useful responsibility map names one accountable owner for every tool while identifying the teams consulted and informed at each stage.

CHAI calls attention to a conflict of interest: the person validating a solution should not simply be the person who developed it. Separation does not always require two large departments. In a small organization, an independent reviewer, shared network resource, or outside expert may supply a second perspective. The goal is credible challenge, not bureaucracy for its own sake. At minimum, the institution should identify responsibility for oversight, validation, monitoring, and data stewardship.

Comité que puede tomar decisiones

Control two point two calls for a formal committee structure that brings relevant governance stakeholders together. This does not necessarily mean creating an entirely new committee. An existing data governance, quality improvement, technology, or patient-safety body may be expanded if its charter, membership, and decision process truly cover AI. The source gives examples of organizations that integrated AI oversight with preexisting structures.

Membership should match the risks being governed. The playbook names executive leadership, finance, regulatory and ethical compliance, information technology, safety and incident reporting, clinical and operational expertise, cybersecurity, privacy, and a perspective reflecting people affected by the tools. That perspective may come from staff, clinicians, patients, or caregivers. It also recommends a designated individual with suitable technology expertise, ideally in AI. Every member does not need to attend every low-risk request, but the right expertise must be available when the decision warrants it.

A committee charter should make the structure usable. It can specify its purpose, scope, decision rights, membership, quorum, meeting cadence, delegation, records, and escalation route. It should also explain which decisions a tool owner can make, which require a subgroup, and which demand full committee or executive attention. Merely announcing that a committee exists says little about whether a nurse, data steward, purchaser, or vendor knows how to use it.

Modelos de gobierno organizacional

CHAI compares three structures rather than declaring a universal winner. In a centralized model, one organization-wide body owns standards and approvals. That can improve consistency and visibility, but a crowded central queue can delay decisions and overlook local workflow details. In a decentralized model, departments make more of their own decisions. That can respond to local needs, yet evidence, terminology, and safeguards may diverge, making undeclared use harder to see.

A distributed model combines central standards with local execution. A central body can establish policy, risk tiers, minimum evidence, and escalation rules. Local teams define intended use, manage day-to-day operations, and monitor performance in their specific setting. This works only when the institution shares concrete artifacts, such as a common intake form, risk classification, inventory, decision record, and monitoring plan. Shared templates turn a policy into comparable, reviewable decisions.

A structure should evolve. A small AI portfolio may initially fit a compact centralized committee. As uses multiply across facilities, a distributed approach may become more practical. Reassess after substantial growth, organizational changes, or shifts in external expectations. The test is not whether a model sounds sophisticated. The test is whether decisions remain timely, consistent, accountable, and sensitive to the setting where the AI is used.

Organizaciones pequeñas y recursos compartidos

The playbook discusses community health centers and other less-resourced organizations. They may not have a separate privacy officer, AI scientist, and clinical informatics specialist available for every proposal. Multiple responsibilities may sit with one person. Existing committees can carry additional work. Regional associations or shared networks may help with policy starters, vendor questions, risk templates, training, procurement, inventories, and incident trend analysis.

Sharing expertise does not remove local accountability. A local organization still determines whether a tool fits its patients and workflows, approves its own use, and responds to incidents. This distinction matters wherever institutions differ greatly in size. The aim of risk-based and shared governance is to make careful adoption possible even when specialist capacity is limited. It is not a license to accept a vendor's assurances as the entire review.

One practical lesson from the source is that committee decisions need an operational path. If a review concludes that a tool needs a restricted data flow, a warning in the user interface, or monthly subgroup checks, someone must turn each condition into an assigned task, a control, and evidence of completion. Otherwise the minutes record a decision that never changes the system.

Admisión y primera revisión

Control two point three links intake, assessment, and monitoring. Governance is continuous. A new AI tool needs review before deployment, but its real-world use can diverge from the pilot, data can change, and a vendor can update the product. The organization needs a way to notice, investigate, and respond. The playbook recommends a standard entry point for both internal developers and vendors.

An initial application can identify the intended use, proposed users, clinical or administrative workflow, expected benefit, patient or staff impact, data involved, vendor or internal developer, and an accountable sponsor. A model card or similar document can organize what is known about the applied solution. CHAI stresses that its applied model card is about a solution in its intended context, not an abstract foundation model detached from a use case. A generic model card alone is rarely enough for procurement, regulatory, security, or risk review.

A short first-stage screen can identify non-negotiable conditions before anyone invests in a deeper evaluation. If a vendor cannot meet a hospital's baseline information or data requirements, that may be apparent early. More detailed questions follow according to risk. The review can request information about security, privacy, compliance, clinical and operational risks, testing, known limitations, mitigation, and monitoring. The institution should know what evidence is missing, who will obtain it, and what happens if it remains unavailable.

Evaluación, despliegue y seguimiento

After the first screen, the source describes risk categorization of the developer and the proposed solution, identifying gaps, asking follow-up questions, and planning how effectiveness and fit will be evaluated. Existing security or procurement reviews can often be extended with AI-specific questions instead of duplicated. Risk should determine the rigor of assessment, the specialists involved, and the monitoring schedule. A proposed use should not be approved merely because a model performs well on a vendor's test set; the local intended use and workflow matter.

Before launch, define success and failure conditions. Decide who owns the model, who trains users, how feedback arrives, which metrics are monitored, how often results are reviewed, and what changes require re-review. A vendor update, altered patient population, or use beyond the agreed scope can turn an earlier approval into a new question. A monitoring plan should make these triggers visible, especially for tools that influence care.

The playbook also explores using AI to support governance itself. Automated checks might flag missing intake documents, unexpected usage, performance drift, or inconsistency between a deployed tool and an updated policy. Reports can summarize queue size, review time, approvals, and open actions. These tools can make human oversight more efficient, but the level of human supervision should still reflect risk. The committee remains accountable for decisions and exceptions.

Escalamiento de incidentes

Control two point four asks for protocols to escalate and communicate concerns or incidents to the governance structure. An AI owner may solve a minor problem locally, but serious harm or a systemic pattern may require broader action. Define triggers in advance. Without them, one team may report every small anomaly while another may wait too long to flag a safety concern.

The playbook illustrates three levels. A routine concern, such as an isolated complaint or small anomaly, may be logged and handled by the operational owner. A moderate concern, such as repeated complaints, a pattern of degraded performance, or use beyond intended scope, reaches a named governance contact within a defined window. A serious concern, such as a patient-safety event involving AI output, suspected unequal harm, a data breach, or substantial deviation from intended function, needs immediate escalation to governance and other relevant functions. The document gives examples of time windows; each organization must define its own actionable deadlines and follow applicable requirements.

A pathway needs a recipient, not just the phrase report to the committee. Name a chair, clinical informatics lead, or AI governance officer to acknowledge the report and triage it. Establish a consistent secure channel and a short minimum report: which tool, intended use, observed event, timing, affected workflow or people, immediate containment, available evidence, and person responsible for follow-up. The governance structure must then know who can convene reviewers, request investigation, pause a pilot, switch off a tool, notify others, and document the decision.

Cerrar el ciclo y aprender

Escalation is incomplete if the reporter never learns what happened. A case should have a disposition: what was decided, why, who is implementing the action, and when the issue will be checked again. The playbook suggests an incident register, which could be part of the AI inventory. Patterns across cases can reveal that a risk tier was too low, monitoring was understaffed, training failed, or the escalation protocol itself needs revision.

Imagine an AI assistant drafting messages to patients. One user reports a confusing instruction. The owner logs a routine concern and checks the output. If similar errors recur, the pattern moves to the governance contact. If a message creates a credible immediate safety risk, the team may need to pause the tool while the appropriate safety, clinical, privacy, and technical people investigate. The example is hypothetical, but it shows why a contact name, a decision authority, and a working stop mechanism all belong in the structure.

A governance meeting should ask not only what the incident was, but whether the reporting channel worked. Was it easy for the user to speak up? Did the owner acknowledge it? Did the issue reach the right people within the defined time? Was the action completed? Did monitoring verify improvement? These questions turn incident handling into organizational learning.

Ejemplos de instituciones

CHAI offers several institutional examples without presenting one as mandatory. A multi-hospital system described decentralized proposals with technology and medical informatics leadership overseeing governance. In the playbook's account of Johns Hopkins, a proposed vendor tool needs an internal sponsor, detailed intake, routing to an appropriate clinical, imaging, or operational review group, and success measures. The example shows how a single front door can still send decisions to specialized reviewers.

The Mayo Clinic example describes an independent multidisciplinary physician-led board assessing risk and regulatory applicability. Lower-risk administrative tools can receive a faster review, while potential medical devices need a more detailed process. The TrueCare example highlights board education, a shared intake path, different clinical and administrative review routes, leadership approval, and monitoring indicators. These examples are useful for comparing design choices, but your institution's actual authorities, resources, and legal duties must be established locally.

Notice the common pattern rather than copying an organization chart. Each approach makes a sponsor visible, separates relevant review functions, asks for evidence, and connects a decision to deployment and monitoring. The source also makes clear that governance structures can start within existing bodies and grow as the AI portfolio grows.

Preguntas directivas y repaso

To finish, imagine that a hospital director asks for a status report. Ask for the AI inventory and the accountable owner of each tool. Ask who can approve, validate, pause, and retire a solution. Ask to see the committee charter and one recent decision record. Ask how an internal developer or vendor submits a proposed use, which evidence is required at the first screen, and how risk changes the depth of review. Ask for a monitoring plan and the name of the person who receives serious incidents. These documents demonstrate whether the structure operates rather than merely exists.

For active recall, pause after each question. What are the four baseline controls in Domain Two? Which roles are essential even if one person holds several? Why should validation be independent from development? When would centralized, decentralized, or distributed governance create a bottleneck or a gap? What is the difference between intake and ongoing monitoring? What information makes an escalation actionable? Who closes the loop with the reporter?

This guide is Roberto Echeverría's independent study material. It helps organize the ideas for listening, but the Coalition for Health AI's Domain Two Organizational Structures Playbook is the primary source. Review that original for its full control language, examples, tools, and important limitations before applying its ideas to a real hospital.