La responsabilidad de la IA clínica depende de la evidencia

Cuando una herramienta de IA clínica está relacionada con daños a pacientes, nadie empezará preguntando qué modelo generó el resultado. Preguntarán quién pudo ver qué registros de pacientes, bajo la autoridad de quién, y dónde está la prueba de ese acceso. Esa pregunta recae sobre el sistema de salud, y lo hace independientemente de si la herramienta fue creada por un proveedor, ajustada por un equipo interno o simplemente conectada a la historia clínica electrónica por un departamento bien intencionado.

La Asociación Médica Estadounidense (AMA) ya le ha dado un marco a esa pregunta. En un comunicado del 29 de octubre de 2026, la AMA describió un modelo de responsabilidad para la IA clínica que divide la responsabilidad entre tres partes según lo que cada una puede controlar. Los desarrolladores responden por la seguridad y eficacia de lo que crean. Los médicos responden por el juicio clínico que pueden ejercer de manera significativa. Las organizaciones de salud, quienes implementan, responden por cómo se seleccionan, implementan, gobiernan y supervisan los sistemas de IA una vez que están activos en un hospital.

El marco es una posición política, no una ley, y nada en él cambia el análisis de deber de un tribunal de la noche a la mañana. Pero para un CISO de salud o un Chief Compliance Officer, la tercera parte de esa lista es la que tiene un problema de documentación. Cada verbo asociado al implementador—seleccionado, implementado, gobernado, supervisado—es un verbo que deja un registro o deja una brecha. Un investigador, una aseguradora o un abogado contrario buscarán ese registro, y la capa de datos es de donde debe salir la mayor parte. Justo en ese terreno es donde Kiteworks secure data exchange está diseñado para ayudar, gobernando y registrando cómo tanto personas como sistemas de IA acceden a contenido sensible, para que la evidencia exista antes de que llegue la pregunta.

Puntos Clave

1. La responsabilidad se divide según el control.

El marco de la AMA del 29 de octubre de 2026 asignaría la responsabilidad a desarrolladores, sistemas de salud y médicos según lo que cada uno puede controlar.

2. Los sistemas de salud son responsables del registro de gobernanza.

Según el marco, los implementadores responden por cómo se selecciona, implementa, gobierna y supervisa la IA, y cada uno de esos verbos genera evidencia o expone una brecha.

3. HIPAA ya aplica.

La identificación única de usuarios y los controles de auditoría ya están en vigor, la Security Rule no contiene ninguna excepción para IA, y esperar la revisión propuesta no es una estrategia.

4. La brecha de evidencia es medible.

En investigaciones de Kiteworks, la mitad de las organizaciones encuestadas no pudo presentar un registro completo de auditoría de acceso a datos de IA en un solo día hábil.

5. La evidencia es la parte que puedes construir ya.

Una capa de datos gobernada que vincula cada solicitud de IA a una persona identificada, aplica políticas y genera un registro inalterable respalda tu defensa sin pretender corregir la precisión clínica.

Lo que Dice y No Dice el Marco de la AMA

Empieza por la estructura de la propuesta, porque los detalles importan para lo que debe hacer una oficina de cumplimiento. El principio declarado de la AMA es que la responsabilidad debe seguir la autoridad para prevenir o reducir daños. Un desarrollador controla cómo se diseña, prueba y documenta una herramienta, así que asume el riesgo que surge ahí. Un médico controla la decisión clínica junto al paciente, así que asume la responsabilidad por el juicio que realmente puede ejercer. Un sistema de salud controla qué herramientas entran al hospital, quién está capacitado para usarlas y cómo se supervisan después.

El lenguaje dirigido a los sistemas de salud es directo. El comunicado dice que las organizaciones de salud deben ser responsables de cómo se seleccionan, implementan, gobiernan y supervisan los sistemas de IA en entornos reales. Eso es un estándar de gobernanza, y los estándares de gobernanza se demuestran con documentos, registros y decisiones que se pueden reconstruir, no con intenciones.

El lenguaje dirigido a los médicos es igual de claro, y juega en desventaja para el sistema de salud. La AMA dice que los médicos deben responder por el juicio clínico que realmente pueden ejercer, y su comunicado agrega que la supervisión médica no puede sustituir la evidencia adecuada ni un diseño de sistema apropiado. Léelo dos veces. Si no se puede esperar que un clínico detecte una falla invisible en el punto de atención, la responsabilidad por esa falla debe recaer en otro lugar, y el marco apunta al desarrollador y a la organización que eligió, configuró y supervisó la herramienta.

El marco también se dirige a los pacientes. Dice que los pacientes deben conservar vías significativas para buscar responsabilidad y remedios apropiados cuando el daño resulta de sistemas de IA defectuosos u otros fallos relevantes. Esa frase es la razón por la que la cuestión de la evidencia importa. El recurso solo es significativo si alguien puede establecer qué ocurrió, y establecer qué ocurrió es un problema de registros mucho antes de ser uno legal.

Lo que el marco no hace es igual de importante. No crea una nueva causa de acción, no modifica HIPAA y no indica a los hospitales qué controles técnicos comprar. Es una declaración de dónde la AMA cree que deben trazarse las líneas, y se usará como se suelen usar las posiciones de las sociedades profesionales: como referencia en debates de políticas, negociaciones de contratos y, eventualmente, en discusiones sobre el estándar de atención. Un líder de cumplimiento que lo trate como una vista previa de las preguntas que vienen, y no como un reglamento ya vigente, lo interpretará correctamente.

Por Qué los Implementadores Cargan con la Carga de la Evidencia

Conviene ser honesto sobre por qué el rol del implementador está tan expuesto. Los desarrolladores tienen el modelo, los datos de entrenamiento y los resultados de pruebas. Los médicos tienen la relación clínica. Los sistemas de salud tienen algo menos glamoroso y más rastreable: la configuración de acceso, el código de integración, las cuentas de servicio, los contratos con proveedores, los registros de capacitación y los logs. Cuando surge una disputa, esos son los elementos que primero busca una solicitud de registros.

La capacitación es un buen ejemplo para ver la brecha. La encuesta a médicos de la AMA en 2026, realizada del 15 de enero al 2 de febrero de 2026, alcanzó a 1,692 médicos, y el 27 por ciento reportó no haber recibido ninguna capacitación en IA de ninguna fuente, mientras que el 92 por ciento dijo que quiere más educación y formación. Nadie llamaría a ese resultado sorprendente. Sin embargo, es un dato que a un abogado demandante le resultaría útil, porque el marco hace responsables a los implementadores de cómo se implementan las herramientas y una fuerza laboral sin capacitación es parte de la implementación.

La misma encuesta muestra por qué la conversación sobre responsabilidad ha pasado de los márgenes al centro. Entre los 1,419 médicos que respondieron sobre acciones regulatorias que aumentarían su confianza en la IA, los marcos claros de responsabilidad fueron la acción más elegida en primer lugar, seleccionada por el 31 por ciento. Esa preferencia sugiere que los médicos quieren reglas claras antes de asumir el riesgo. Los sistemas de salud que no puedan demostrar cómo se evaluó una herramienta, quién puede usarla y a qué datos puede acceder tendrán dificultades para responder a esa preocupación con algo más que palabras.

Así que la carga del implementador se reduce a unas preguntas sencillas que un CISO puede hacer esta semana. ¿Qué herramientas de IA están en uso clínico u operativo, incluidas las que nadie adquirió formalmente? ¿A qué datos de pacientes puede acceder cada una? ¿Cada herramienta, o cada agente que actúa por ella, está vinculada a una persona responsable de lo que hace? Y si un regulador pidiera el registro de ese acceso del martes pasado, ¿cuánto tiempo tardarías en armarlo? Las secciones siguientes abordan esas preguntas.

HIPAA Regula los Datos, No el Modelo

Las organizaciones de salud tienen aquí una ventaja estructural, aunque rara vez lo parezca. A HIPAA no le importa cuán sofisticado sea el modelo. Regula lo que ocurre con la información de salud protegida y no contiene ninguna excepción para IA. Cuando un asistente de IA recupera una historia clínica, una herramienta de resumen extrae notas en un prompt o un agente reúne registros para una autorización previa, los requisitos de acceso y auditoría de la Security Rule aplican a esa actividad igual que a una enfermera que inicia sesión en el sistema de registros.

Dos disposiciones merecen una lectura directa. Según 45 CFR 164.312, la identificación única de usuarios es una especificación obligatoria, lo que significa asignar un nombre o número único para identificar y rastrear la identidad del usuario. El estándar de controles de auditoría exige mecanismos de hardware, software o procedimientos que registren y examinen la actividad en los sistemas de información. Ninguno menciona si el actor es una persona o un programa. Ambos dicen mucho sobre si puedes reconstruir quién hizo qué.

Ahí es donde las arquitecturas comunes de IA encuentran problemas. Un asistente que consulta datos de pacientes mediante una cuenta de servicio compartida dificulta demostrar la identificación única de usuarios, porque el registro muestra la cuenta de servicio y no el clínico o flujo de trabajo que la activó. Un prompt de sistema con credenciales amplias tiene la misma debilidad. Estos diseños son rápidos de construir, por eso abundan, y son justo lo que un auditor va a examinar porque difuminan la línea entre una decisión humana y una acción de máquina.

El tema del cifrado es más matizado y conviene explicarlo con cuidado. Hoy, el cifrado de información de salud protegida electrónica es una especificación direccionable bajo la misma sección, lo que significa que las organizaciones deben evaluarlo e implementarlo o documentar una alternativa equivalente. La Oficina de Derechos Civiles publicó una propuesta de norma en enero de 2025 para reforzar la Security Rule, y Holland and Knight informó en julio de 2026 que la publicación final está proyectada para julio de 2027, según la agenda regulatoria federal. Una propuesta no es un requisito. Pero un sistema de salud que espere el texto final antes de resolver cómo las herramientas de IA acceden a los datos de pacientes está esperando un plazo que no rige la conducta que ya está bajo la lupa de un demandante o auditor.

La conclusión práctica es que el mejor marco para un líder de cumplimiento en salud es el más sencillo. HIPAA regula los datos, y se aplicará al acceso de IA a esos datos bajo los estándares ya vigentes. La HIPAA Security Rule no necesita ser reescrita para que un investigador pregunte quién accedió a un registro. Solo necesita que el registro exista.

La Brecha de Evidencia Detrás del Marco

Si la evidencia es el punto, ¿qué tan preparadas están las organizaciones para presentarla? La respuesta honesta es que la mayoría no lo está, y los datos son consistentes entre fuentes independientes.

Empecemos por los registros de auditoría de acceso de IA. En el Informe Anual de Seguridad de Datos y Riesgo de Cumplimiento de Kiteworks 2026, basado en respuestas de 459 profesionales de seguridad, cumplimiento y tecnología recogidas en el segundo trimestre de 2026, el 50 por ciento de las organizaciones dijo que no podía presentar un registro completo de auditoría de acceso a datos de IA en un solo día hábil, y solo el 17 por ciento podía hacerlo en una hora. Hay dos advertencias. Los resultados son autoinformados y la cifra cubre todas las industrias, así que no debe interpretarse como un dato exclusivo de salud. Lo que sí muestra es lo común de la brecha. La mitad no cumpliría un plazo de un día.

Ese plazo no es arbitrario. El reloj de un regulador, una retención por litigio o un cuestionario de aseguradora no espera una semana de ensamblar logs manualmente. Una organización que necesita varios sistemas y equipos para responder una sola pregunta de acceso tiene un proceso, pero no evidencia en el sentido que busca un auditor: un registro completo, confiable y disponible bajo demanda.

La confianza en la gobernanza cuenta la misma historia desde otro ángulo. La Encuesta de Impacto de IA 2026 de Grant Thornton, publicada el 13 de abril de 2026, encontró que el 78 por ciento de casi 1,000 altos directivos encuestados no tiene plena confianza en que su organización podría superar una auditoría independiente de gobernanza de IA en 90 días. La encuesta no se limita a salud y Grant Thornton vende servicios de asesoría en este ámbito, así que toma la cifra como una medida de confianza ejecutiva, no como una tasa real de fallos de auditoría. Aun así, la frase «en 90 días» es reveladora. Los líderes no dicen que no tienen gobernanza. Dicen que no podrían demostrarla rápidamente.

Los datos específicos de salud apuntan en la misma dirección. Un informe de referencia de SAI360 y Strategic Management Services, basado en una encuesta de 2025 a 261 entidades cubiertas y asociados comerciales, halló que el 86 por ciento de los encuestados detecta incidentes HIPAA a través de reportes de empleados a la gerencia o cumplimiento, mientras solo alrededor del 35 por ciento usa monitoreo automatizado de acceso de usuarios a información de salud protegida y el 21 por ciento usa revisión automatizada de registros de auditoría de historias clínicas electrónicas. La muestra es autoseleccionada y sesgada hacia hospitales y salud conductual, así que describe a quienes respondieron más que al sector completo. Aun así, sugiere que en muchas organizaciones la primera alarma es un colega que nota algo, no un sistema que genera un registro.

Juntando los tres surge un patrón que poco tiene que ver con el modelo en sí. El punto débil no es la inteligencia. Es la atribución: saber qué identidad accedió a qué datos bajo qué política, y poder demostrarlo rápido. Las herramientas de IA solo hacen esa debilidad más costosa, porque actúan a velocidad de máquina y a menudo mediante cuentas que nunca se diseñaron para cargar con responsabilidad.

Cómo Debe Ser la Evidencia Defendible para el Acceso de IA a PHI

Un investigador que revise un incidente relacionado con IA suele hacer las mismas cuatro preguntas en algún orden. ¿Quién o qué accedió a los datos? ¿Qué exactamente se accedió? ¿Bajo qué política se permitió ese acceso? ¿Y puedes demostrar que el registro no ha sido alterado? Un programa defendible es el que puede responder las cuatro sin improvisar.

Empecemos por la primera pregunta. Una solicitud de IA no es un evento anónimo. Alguien configuró la herramienta, alguien aprobó su uso y, en muchos flujos de trabajo, un clínico o miembro del personal específico activó la solicitud. La calidad de la evidencia depende de vincular la solicitud a una persona identificada y responsable, no a una credencial compartida. Trata al agente de IA como una clase de identidad más bajo la misma gobernanza que ya cubre a empleados, contratistas y socios, con un solo conjunto de políticas, un modelo de identidad y un registro de lo que hizo cada identidad.

La segunda pregunta es sobre el alcance. El principio de mínimo necesario de HIPAA pide a las organizaciones limitar el uso y divulgación de información de salud protegida a lo necesario para el propósito. Cuando un asistente puede acceder a todo un repositorio, ese principio depende de la política aplicada en el punto de acceso, no solo del buen comportamiento de la herramienta. El control de acceso basado en roles y el control de acceso basado en atributos dan al equipo de cumplimiento una forma de expresar quién puede ver qué, bajo qué condiciones, y aplicar las mismas reglas a una persona y a un agente que actúa por una persona.

La tercera pregunta es sobre la política. No basta con que el acceso estuviera permitido. Un revisor quiere ver qué regla lo permitió. Eso significa que la decisión misma, y no solo el resultado, debe quedar registrada. Un motor de políticas que evalúa cada solicitud y registra el resultado le da al CCO algo más útil que una lista de eventos: le da una explicación.

La cuarta pregunta es sobre la integridad. Un registro que puede ser editado por las personas que describe es una evidencia débil. Los registros de auditoría inalterables, enviados a una plataforma de gestión de información y eventos de seguridad que el equipo de cumplimiento pueda consultar, convierten un montón de eventos en evidencia.

Esta es la lógica de diseño detrás de Kiteworks Compliant AI y el Secure MCP Server. Cuando un asistente de IA se conecta a contenido empresarial por esa vía, cada solicitud se vincula a la identidad de la persona que la autorizó, se verifica contra la política basada en atributos, se protege con cifrado validado FIPS 140-3 y se registra en un registro de auditoría inalterable que puede enviarse al SIEM de la organización. El motor de políticas de datos aplica la misma gobernanza a personas y agentes de IA, así que el equipo de cumplimiento revisa un solo registro en vez de conciliar varios. El CISO Dashboard y un informe de cumplimiento HIPAA respaldan el reporte, ayudando a demostrar cómo se accede y comparte contenido sensible.

Vale la pena ser exacto sobre lo que esto cubre y lo que no, porque exagerar también es un riesgo. Este enfoque gobierna el acceso a los datos. No juzga si una recomendación clínica fue precisa, no reemplaza la obligación del desarrollador de monitorear el desempeño del modelo, ni sustituye la respuesta a incidentes cuando una herramienta de IA da un mal consejo clínico. Aplica al tráfico de IA que pasa por la capa gobernada, y su capacidad para tratar contenido como información de salud protegida depende de cómo se etiqueta o clasifica ese contenido. El valor es más limitado que una promesa de hacer segura la IA, y por eso es más útil. Cuando la pregunta es quién accedió a qué, la respuesta ya está registrada.

Dónde Termina el Deber del Desarrollador y Dónde Empieza el Tuyo

Un programa de gobernanza basado en evidencia de acceso a datos no debe confundirse con toda la seguridad de la IA clínica, y la AMA es cuidadosa con la división de responsabilidades. En comentarios a la FDA sobre dispositivos médicos de IA generativa, publicados el 19 de octubre de 2026, la AMA pidió una mayor supervisión poscomercialización que rastree el desempeño de un dispositivo durante todo su ciclo de vida, incluso después de la implementación, y dijo que los fabricantes deben seguir siendo responsables del desempeño de sus productos. También afirmó que la supervisión clínica no puede sustituir la evidencia rigurosa de que un dispositivo funciona de manera segura y confiable en su entorno previsto.

Para un sistema de salud, esa división deja dos lecciones. Primero, el monitoreo de desempeño del proveedor y la gobernanza de acceso del implementador son obligaciones diferentes, y un contrato que solo cubre una deja un vacío. Segundo, el implementador no puede delegar todo el problema al proveedor. Incluso si el fabricante es principalmente responsable del desempeño del modelo, el hospital sigue decidiendo quién puede usar la herramienta, a qué registros puede acceder y cómo se registra su actividad. Esas decisiones son del hospital, y también la prueba de ellas.

Por eso el lenguaje contractual merece tanta atención como la tecnología. Pide a los proveedores documentación sobre el uso previsto, limitaciones conocidas y desempeño, y pregunta qué registros y atribución soportan sus productos al conectarse a datos de pacientes. Luego confirma tu lado. ¿Quién dentro de la organización es responsable de cada herramienta y dónde consta esa asignación? La propiedad del riesgo de IA está indefinida en muchas organizaciones, y algunas no tienen responsable asignado. Un marco que divide la responsabilidad entre partes no ayuda a un hospital cuya responsabilidad interna está sin definir.

Un Plan de 90 Días para el CISO y la Oficina de Cumplimiento

Noventa días es un horizonte útil porque coincide con el plazo que usó Grant Thornton en su pregunta sobre preparación para auditoría, y porque es tiempo suficiente para construir algo real. No hace falta esperar a que el marco de la AMA sea algo más que un marco para empezar a actuar.

Inventario y atribución en los días 1 a 30

Haz una lista de cada herramienta y agente de IA que acceda a datos clínicos o administrativos, incluidas las no oficiales. Para cada uno, registra a qué datos puede acceder, qué identidad usa y quién es la persona responsable. Todo lo que funcione con una cuenta de servicio compartida va a una lista de remediación, porque es el patrón que más probablemente fallará en la identificación única de usuarios. Este también es el momento de identificar herramientas que aceptan datos de pacientes en prompts sin una vía gobernada.

Acceso gobernado y política en los días 31 a 60

Canaliza el acceso de IA a contenido sensible a través de una sola capa gobernada, en vez de múltiples integraciones directas. Define la política en términos que un responsable de cumplimiento pueda leer, como qué roles, qué clases de datos, qué propósitos. Aplica el mismo lenguaje de política a personas y agentes. Confirma que cada solicitud de IA esté vinculada a un autorizador humano y que el registro se envíe a la pila de monitoreo de seguridad. Un objetivo realista para esta fase es cubrir los flujos de trabajo de mayor riesgo, no todos.

El ejercicio de evidencia en los días 61 a 90

Realiza un ejercicio que simule una investigación real. Elige un registro de paciente, una fecha y una herramienta, y pide al equipo que presente un registro completo de acceso de IA a ese dato. Cronometra el ejercicio. Si toma más de un día hábil, trata la brecha como un hallazgo y soluciónalo. Luego informa al comité de gobernanza de IA o a la junta sobre el resultado, en términos de exposición y evidencia, no de métricas de modelo. Repite el ejercicio cada trimestre, porque las integraciones de IA cambian más rápido que las políticas.

Nada de esto requiere certeza sobre cómo se adoptará el marco de la AMA. Requiere poder responder una pregunta que todas las versiones del futuro van a plantear.

Qué Significa Esto para los Líderes de Salud Regulada

El marco de la AMA es una señal de hacia dónde va la tendencia. No resuelve quién pagará cuando la IA clínica falla, y personas razonables en medicina, derecho e industria seguirán debatiéndolo. Pero la dirección es consistente. La responsabilidad se está moviendo hacia quienes pueden controlar el riesgo, y quien controla el acceso a los datos de pacientes es el sistema de salud.

Eso es tanto una oportunidad como una carga. Las organizaciones que puedan demostrar, rápida y creíblemente, cómo se seleccionan las herramientas de IA, quién puede usarlas, a qué pueden acceder y qué hicieron, negociarán contratos con proveedores desde una posición más fuerte, responderán a aseguradoras con menos fricción y enfrentarán a reguladores con un registro ya listo. Las que no, descubrirán la brecha en el peor momento: en medio de una investigación y con el reloj corriendo.

La pregunta para llevar a la próxima reunión del comité de gobernanza no es si tus herramientas de IA clínica son lo suficientemente inteligentes. Es si podrías demostrar, para mañana por la tarde, quién y qué accedió al registro de un paciente específico, y bajo qué política. Si la respuesta honesta es «todavía no», tienes un punto de partida claro.

Para saber más sobre cómo generar evidencia lista para auditoría del acceso de IA a datos de pacientes, agenda una demo personalizada hoy.

Recursos Adicionales

• Artículo del Blog
  Estrategias Zero‑Trust para una Protección de Privacidad de IA Accesible
• Artículo del Blog
  Cómo el 77% de las Organizaciones Falla en la Seguridad de Datos de IA
• eBook
  Brecha de Gobernanza de IA: Por Qué el 91% de las Pequeñas Empresas Juegan a la Ruleta Rusa con la Seguridad de Datos en 2025
• Artículo del Blog
  No Existe un «–dangerously-skip-permissions» para Tus Datos
• Artículo del Blog
  Los Reguladores Ya No Preguntan Si Tienes una Política de IA. Quieren Pruebas de Que Funciona.