Tema 8.4 — Gobernanza de la IA y tecnología emergente

En una frase: La inteligencia artificial en la salud y la atención es una tecnología de aprendizaje, dependiente de datos, y a menudo opaca que puede escalar tanto el beneficio como el daño más rápido que cualquier sistema que hayas gobernado antes, así que debes gobernarla como un asunto de seguridad clínica, equidad, y confianza pública a través de todo su ciclo de vida —no tratarla como software ordinario que compras una vez y olvidas.

Por qué esto importa en la salud y la atención#

La mayoría del software que has desplegado se comporta de la misma manera mañana que hoy: su lógica está escrita, su comportamiento es probable, y cuando está equivocado tiende a estarlo de una forma visible y repetible. La inteligencia artificial rompe las tres comodidades. Aprende patrones estadísticos de los datos en lugar de seguir reglas que escribió una persona; su comportamiento depende enteramente de los datos con los que se entrenó y los datos que ahora encuentra; y su razonamiento es frecuentemente opaco incluso para las personas que la construyeron. Esa combinación es por qué la IA necesita su propia disciplina de gobernanza en lugar de plegarse en una lista de verificación de software genérica.

En la salud y la atención las consecuencias no son abstractas. Un modelo que subdetecta enfermedad en un grupo subrepresentado en sus datos de entrenamiento no comete un error aislado —comete el mismo error, silenciosamente, miles de veces, atrincherando y escalando desigualdades en salud. Un modelo generativo que fabrica un detalle clínico plausible puede engañar a un clínico sobrecargado en exactamente el momento equivocado. Una herramienta que funciona bellamente en la población en la que se validó puede silenciosamente decaer cuando cambia la población, la vía de atención, o los datos río arriba. La IA puede escalar buenas decisiones y puede escalar sesgo, error, y daño con igual eficiencia.

Este tema trata sobre gobernar ese riesgo sin ni respirar el bombo ni prohibir la tecnología. Deliberadamente no repite los fundamentos establecidos en otros lugares: la seguridad clínica (véase el Tema 1.6 — Seguridad clínica y gestión de riesgos), la gobernanza de la información, protección de datos y ciberseguridad (véase el Tema 1.7 — Gobernanza de la información, protección de datos y ciberseguridad), y la toma de decisiones impulsada por evidencia (véase el Tema 1.3 — Decisiones impulsadas por evidencia). Se ancla a ellos, y añade lo que es específico de los sistemas de aprendizaje. Trátalo como la extensión con forma de IA de tu aseguramiento existente, y como el hermano gobernado de la introducción escalonada de la innovación (véase el Tema 8.0 — Introducción escalonada de la innovación).

Conceptos clave#

Inteligencia artificial y aprendizaje automático. Para un líder, la distinción práctica es esta: la mayoría de la IA en la salud y la atención hoy es aprendizaje automático —sistemas que infieren patrones a partir de ejemplos en lugar de ejecutar reglas escritas a mano. Esto es por qué los datos son el producto tanto como el código: cambia los datos de entrenamiento y cambias el comportamiento. También significa que un modelo no "sabe" nada; estima, y puede estar confiadamente equivocado. Entender esto a nivel conceptual es suficiente para hacer las preguntas de gobernanza correctas; no necesitas leer las matemáticas.

Software as a Medical Device (SaMD) y la MHRA. Cuando el software tiene un propósito médico —diagnosticar, cribar, triar, calcular una dosis, predecir el deterioro— muy a menudo es un dispositivo médico en la ley, independientemente de si funciona en un teléfono o un servidor. El software médico de este tipo, conocido como Software as a Medical Device (SaMD), es regulado en el Reino Unido por la Medicines and Healthcare products Regulatory Agency (MHRA). Si estás encargando o construyendo una herramienta de IA con un propósito clínico, la primera pregunta de gobernanza es si es un dispositivo regulado y, si es así, si tiene marcado de conformidad válido. Equivocar esto no es un tecnicismo; desplegar un dispositivo médico no registrado es ilegal e inseguro.

El AI Airlock. La MHRA ha establecido una zona de pruebas regulatoria llamada el AI Airlock para trabajar cómo debería regularse la IA como dispositivo médico en un entorno controlado y monitoreado. Una zona de pruebas regulatoria permite a un regulador y un pequeño número de desarrolladores examinar preguntas difíciles y novedosas —por ejemplo cómo validar un modelo que se actualiza con el tiempo— bajo supervisión, antes de que se establezcan reglas generales. Sé sobrio sobre lo que es esto: el Airlock es un entorno de aprendizaje para el regulador y un puñado de participantes, no una ruta de aprobación rápida, y estar asociado con él no significa que un producto esté aprobado para uso clínico general.

Sesgo algorítmico y equidad. El sesgo algorítmico es la tendencia de un sistema a producir resultados sistemáticamente injustos para grupos particulares. En la salud y la atención su fuente más común son los datos de entrenamiento: si un grupo está subrepresentado, mal etiquetado, o medido con un instrumento sesgado, el modelo aprende a servir peor a ese grupo. Porque el modelo luego aplica esto a escala y con un aire de objetividad, la IA sesgada puede ampliar las mismas desigualdades que tu organización está estatutariamente obligada a reducir.

Explicabilidad y la caja negra. La inteligencia artificial explicable se refiere a si un humano puede entender por qué un modelo produjo un resultado dado. Muchos modelos de alto rendimiento son efectivamente "cajas negras": precisos en agregado pero incapaces de dar a un clínico una razón confiable para una decisión individual. En un entorno clínico esto importa para la responsabilidad, el consentimiento informado, y el deber del clínico de ejercer juicio —un médico no puede significativamente asumir la responsabilidad de un consejo que no puede interrogar.

Deriva de modelo y vigilancia posterior al mercado. La precisión de un modelo no es fija. La deriva de concepto —un cambio con el tiempo en la relación entre las entradas y la cosa que se predice— significa que un modelo validado el año pasado puede degradarse silenciosamente este año a medida que cambian las poblaciones, vías, o datos río arriba. Esto es por qué la IA requiere vigilancia posterior al mercado y monitoreo continuo, no solo una validación única en la puesta en marcha.

MLOps y el ciclo de vida del modelo. MLOps es la disciplina operativa de desplegar, monitorear, versionar, y reentrenar modelos confiablemente en producción. Es la maquinaria que hace real la gobernanza del ciclo de vida: saber qué versión de modelo está en vivo, en qué datos, con qué rendimiento, y poder revertir.

Humano en el bucle. Un diseño de humano en el bucle mantiene a una persona —generalmente un clínico— significativamente en la decisión, con la autoridad y la información para anular al modelo. Hecho bien preserva la responsabilidad; hecho como una aprobación automática solo proporciona la ilusión de supervisión.

IA generativa y grandes modelos de lenguaje. La inteligencia artificial generativa, incluyendo los grandes modelos de lenguaje (LLM), produce texto fluido y otro contenido. Su valor realista a corto plazo en la salud y la atención es en gran parte administrativo —redactar documentación, resumir, aliviar el papeleo. Su riesgo definitorio es la alucinación: la generación confiada de contenido falso pero plausible, agravada por riesgos de confidencialidad cuando se introducen datos de pacientes en servicios de terceros.

Terapéuticas digitales y aplicaciones de salud. Las terapéuticas digitales (DTx) son intervenciones impulsadas por software y basadas en evidencia que previenen, gestionan, o tratan una condición —distintas de las aplicaciones generales de bienestar precisamente porque hacen un reclamo clínico, lo que significa que muchas son Software as a Medical Device y exigen la misma evidencia y aseguramiento que cualquier otra intervención que prescribas o recomiendes.

Buenas prácticas#

1. Clasificar la herramienta antes de hacer cualquier otra cosa. Establece, por escrito y con aporte clínico y regulatorio, si la IA tiene un propósito médico y por tanto es un dispositivo médico regulado, y si tiene marcado de conformidad MHRA válido. Esta única determinación gobierna todo lo que sigue río abajo —la ruta de aseguramiento, las responsabilidades, la legalidad del despliegue. Cuando tengas dudas, busca asesoramiento regulatorio en lugar de asumir que una herramienta administrativa está fuera de alcance.

2. Ejecutar la IA a través de tu maquinaria existente de seguridad clínica e IG, extendida no evitada. Cada despliegue de IA clínica necesita la gestión de riesgo clínico de DCB0129/DCB0160 (véase el Tema 1.6) y una Data Protection Impact Assessment bajo tu marco de gobernanza de la información (véase el Tema 1.7). No dejes que la novedad o el entusiasmo del proveedor creen un proceso paralelo y más ligero. Los peligros específicos de IA —sesgo, deriva, opacidad, sesgo de automatización— deberían añadirse al registro de peligros, no sustituirlo.

3. Interrogar los datos de entrenamiento por representatividad y sesgo. Pregunta quién está en los datos y quién falta, cómo se etiquetaron los resultados, y si los instrumentos de medición mismos fueron sesgados a través de grupos. Exige que el proveedor reporte el rendimiento desglosado por subgrupos relevantes —edad, sexo, etnia, privación— no solo la precisión titular. Una herramienta que no puede demostrar rendimiento equitativo es un riesgo de desigualdad en salud por muy impresionante que sea su promedio.

4. Exigir validación clínica apropiada al riesgo, y preferir evidencia prospectiva. La precisión retrospectiva en datos curados es la forma más débil de evidencia. Para cualquier cosa que influya en decisiones clínicas, busca validación en una población y flujo de trabajo como el tuyo, idealmente prospectiva, y enruta el reclamo a través del marco de aseguramiento apropiado —el NICE Evidence Standards Framework para tecnologías de salud digital y el Digital Technology Assessment Criteria (DTAC) como aseguramiento de línea base. Ajusta la fuerza de la evidencia a la magnitud del daño potencial.

5. Insistir en un humano en el bucle significativo y responsabilidad clara. Define quién es responsable de una decisión que informó la IA, y asegura que el humano tenga tanto la autoridad para anular como la información para hacerlo. Guárdate activamente contra el sesgo de automatización —la tendencia a deferir a la máquina— a través de la formación, diseño de interfaz, y auditoría de tasas de anulación. Si las anulaciones nunca suceden, tu "humano en el bucle" es decorativo.

6. Tratar la puesta en marcha como el inicio del monitoreo, no el final del aseguramiento. Establece la vigilancia posterior al mercado desde el primer día: monitorea el rendimiento del mundo real, vigila la deriva de concepto, y define los umbrales y proceso para reentrenar, pausar, o retirar el modelo. Establece el versionado y reversión de modelo a través de buen MLOps para que siempre sepas qué está en vivo y puedas revertir de forma segura. Un modelo que nunca se vuelve a verificar es un control de seguridad que falla lentamente.

7. Gobernar la IA generativa a sus usos realistas y contra sus riesgos reales. Permite los LLM donde el valor es genuino y el riesgo está contenido —redacción administrativa, resumen, apoyo de documentación con revisión humana— y prohíbe la entrada no gestionada de datos identificables de pacientes en servicios de terceros. Asume que cualquier salida generativa puede estar fabricada hasta que un humano la verifique, y nunca dejes que contenido generado no verificado entre en el registro clínico. Una política clara y aplicada vence tanto a una prohibición general que impulsa el uso en la sombra como a un todo-vale que filtra datos.

8. Aplicar la gobernanza de la información a todo el ciclo de vida de datos, incluyendo el entrenamiento. Los datos usados para entrenar, ajustar finamente, y evaluar un modelo están sujetos a las mismas obligaciones de base legal, minimización, y transparencia que cualquier otro uso (véase el Tema 1.7). Sé explícito sobre la base para entrenar con datos de pacientes, si están adecuadamente desidentificados, y qué puede hacer el proveedor con ellos. Los contratos deberían prohibir la reutilización de tus datos para entrenar productos para otros sin una base legal y tu acuerdo.

9. Mantener un registro de modelo legible por humanos y exigir transparencia de los proveedores. Mantén un inventario de la IA en uso: propósito, estado regulatorio, procedencia de datos de entrenamiento, evidencia de validación, plan de monitoreo, y propietario responsable. Exige que los proveedores sean transparentes sobre cómo funciona un modelo, sus limitaciones, y sus modos de fallo; la opacidad de un vendedor es en sí misma una señal de riesgo. No puedes gobernar lo que no has escrito.

10. Escanear el horizonte deliberadamente e introducir a través de evaluación controlada. Más allá de la IA de hoy, vigila las tecnologías emergentes —documentación ambiental, modelos fundacionales, y más adelante, computación cuántica y detección novedosa— con escaneo de horizonte estructurado en lugar de contratación reactiva. Introduce cualquier cosa genuinamente novedosa a través del enfoque controlado, reversible, y evaluado de la introducción escalonada de la innovación (véase el Tema 8.0), comenzando pequeño, midiendo honestamente, y reteniendo la capacidad de detener.

11. Tratar las terapéuticas digitales y aplicaciones de salud como intervenciones, no descargas de consumidor. Cuando una aplicación hace un reclamo clínico —tratar, gestionar, o prevenir una condición— es una intervención sobre la que actuarán los pacientes, y merece el mismo escrutinio que un fármaco o dispositivo antes de que la prescribas o recomiendes. Establece si es Software as a Medical Device con marcado de conformidad válido, exige evidencia proporcional a su reclamo, y completa una evaluación de seguridad clínica (véase el Tema 1.6) en lugar de confiar en una calificación de tienda de aplicaciones o el entusiasmo de un proveedor. Una aplicación no asegurada que un clínico respalda lleva el nombre de tu organización y tu responsabilidad si daña.

12. Enrutar las aplicaciones de salud a través del aseguramiento existente y mantener una biblioteca curada y segura. Evalúa las terapéuticas digitales a través de la misma maquinaria que ya operas —DTAC como línea base, el NICE Evidence Standards Framework ajustado al reclamo clínico, y revisión de seguridad clínica e IG— y construye la evidencia de evaluación del mundo real con el tiempo (véase el Tema 8.6). Mantén una biblioteca curada de aplicaciones que has asegurado y respaldas, con el estado regulatorio, evidencia, y propietario de cada aplicación registrados, para que los clínicos recomienden desde una lista corta segura y gobernada. La alternativa —una dispersión no controlada de aplicaciones no evaluadas recomendadas informalmente entre equipos— es inmanejable e insegura.

Preguntas para debatir con tu equipo#

1. Para cada herramienta de IA que estamos considerando o ya usamos, ¿realmente sabemos si es un dispositivo médico regulado —y podemos producir la evidencia? Esto suena como una formalidad de cumplimiento pero es la pregunta de carga estructural, porque la respuesta determina qué es legal, quién es responsable, y qué aseguramiento le debemos al público. Es fácil asumir que una herramienta que "solo ayuda con el triaje" o "solo resume notas" es software administrativo inofensivo cuando su propósito médico de hecho lo hace un dispositivo regulado que requiere marcado de conformidad MHRA. La discusión debería obligarte a nombrar cada herramienta de IA en uso o en la tubería, declarar su propósito previsto en términos clínicos simples, e identificar quién hizo la llamada de clasificación de dispositivo y sobre qué base. Debería sacar a la luz los casos incómodos donde una herramienta se contrató a través de una ruta de TI ordinaria sin ninguna verificación regulatoria en absoluto. Sé honesto sobre si podrías, hoy, producir la documentación de conformidad y evidencia de validación si un regulador o un forense preguntara. El valor de la conversación es que convierte un sentido vago de que "alguien debe haber verificado" en una posición documentada y poseída —y revela las herramientas donde nadie lo hizo.

2. ¿Hemos exigido ver cómo rinde este modelo para los grupos con más probabilidad de ser dañados, o hemos aceptado una cifra de precisión titular? La precisión promedio es el número con el que lideran los proveedores y el número que oculta el sesgo algorítmico, porque un modelo puede ser altamente preciso en general mientras rinde notablemente peor para un grupo subrepresentado. En la salud y la atención esto no es una curiosidad estadística; es un mecanismo para ampliar las desigualdades que estás legal y moralmente obligado a reducir, aplicado silenciosamente y a escala. El equipo debería discutir qué evidencia de subgrupo realmente has visto —rendimiento desglosado por edad, sexo, etnia, y privación— y si sabes quién estaba en los datos de entrenamiento y quién faltaba. Vale la pena nombrar la incomodidad aquí: presionar a un proveedor sobre la equidad puede sentirse como obstruir una innovación emocionante, y la pregunta honesta es si estás dispuesto a decir no a una herramienta que no puede demostrar rendimiento equitativo. Considera también cómo siquiera detectarías resultados inequitativos después del despliegue, ya que el sesgo que fue invisible en la contratación será invisible en producción a menos que lo monitorees. Una buena discusión termina con una barra evidencial concreta para la equidad que aplica antes de que cualquier IA clínica se ponga en vivo, y un plan para seguir vigilando después.

3. Cuando este modelo esté equivocado —y lo estará— ¿quién es responsable, un humano realmente lo captará, y cómo lo sabríamos siquiera? Cada modelo falla a veces, y los sistemas de aprendizaje pueden derivar hacia fallar más a menudo con el tiempo, así que la pregunta madura no es si ocurren errores sino si tus salvaguardas son reales. El equipo debería probar si el humano en el bucle es significativo o decorativo: ¿tiene el clínico la autoridad y la información para anular, y si miraras las tasas de anulación, encontrarías que realmente anulan alguna vez, o se ha instalado el sesgo de automatización? Discute quién está nombrado como responsable de una decisión que informó la IA —el clínico, la organización, el proveedor— porque "el algoritmo lo hizo" no es una posición defendible ante un paciente o un forense. Confronta tu monitoreo honestamente: ¿tienes vigilancia posterior al mercado que detectaría la deriva de concepto, umbrales definidos para pausar o retirar el modelo, y la maquinaria MLOps para saber qué versión está en vivo y revertirla? Para herramientas generativas, añade la pregunta de alucinación —¿qué detiene que contenido fabricado entre en el registro clínico, y quién verifica la salida antes de que se confíe en ella? La versión más útil de esta conversación expone la brecha entre el diagrama tranquilizador de "supervisión humana" y lo que genuinamente sucedería a las 3am en una sala ocupada.

4. ¿Qué está pasando con los datos de nuestros pacientes cuando entrenamos, ajustamos finamente, y ejecutamos estos modelos —y qué se ha reservado el derecho de hacer el proveedor con ellos? La IA concentra el riesgo de gobernanza de datos precisamente porque los datos son el producto: un modelo es tan confiable como la base legal, minimización, y transparencia detrás de cada conjunto de datos que tocó, incluyendo los datos de entrenamiento y evaluación que preceden a la puesta en marcha. El equipo debería poder declarar, para cada herramienta, la base legal para cualquier uso de datos de pacientes, si la desidentificación es adecuada en lugar de meramente afirmada, y adónde fluyen físicamente los datos una vez que salen de tu control. Una trampa recurrente es el contrato que silenciosamente permite al proveedor reutilizar tus datos para mejorar productos que venderá a otros; discute si tus acuerdos prohíben eso sin una base legal y tu consentimiento explícito, y si alguien realmente ha leído esas cláusulas. Esto se conecta directamente con tu marco de gobernanza de la información (véase el Tema 1.7), y es donde el entusiasmo por una herramienta capaz más a menudo supera la debida diligencia. Una respuesta honesta nombra quién posee la DPIA, qué puede y no puede hacer el proveedor, y dónde estás actualmente expuesto —en lugar de asumir que porque la demostración fue impresionante el papeleo debe ser sólido.

5. ¿Cómo decidimos qué NO adoptar, y podemos resistir la presión de comprar lo que todos están entusiasmados? La disciplina de gobernanza más difícil con una tecnología que se mueve rápido es decir "todavía no" o "esto no", y un equipo que no puede articular sus criterios para declinar terminará adoptando por deriva y bombo en lugar de por evidencia. Discute qué te haría alejarte de una herramienta por lo demás atractiva —evidencia de subgrupo débil, un estado regulatorio poco claro, un caso de uso donde el beneficio realista es delgado en relación al riesgo— y si esas líneas rojas están escritas o meramente sentidas. Hay una tensión real aquí entre el coste de perder una mejora genuina y el coste de un fallo escalado que daña la confianza pública, y personas razonables las sopesarán de forma diferente. Vale la pena nombrar la realidad política de que la presión para adoptar a menudo viene de una junta directiva, una relación de proveedor, o un mandato nacional, no de la necesidad clínica misma. La postura del tema es escanear el horizonte deliberadamente e introducir a través de evaluación controlada y reversible (véase el Tema 8.0), así que una respuesta honesta describe cómo entra una herramienta prometedora pero no probada como un piloto pequeño, medido, y detenible en lugar de un despliegue total —y quién tiene la autoridad para detenerlo.

6. ¿Podemos explicar qué hace este modelo a los clínicos que deben confiar en él y a los pacientes afectados por él —y hemos sido honestos sobre sus límites? Un modelo que un clínico no puede interrogar y un paciente no puede entender corroe el juicio informado y el consentimiento informado de los que depende la atención clínica, por muy preciso que sea en agregado. El equipo debería discutir cuánta explicabilidad realmente requiere este uso particular: una ayuda de priorización de cola exige menos que una herramienta que influye en un diagnóstico o decisión de tratamiento, y ajustar la explicación a lo que está en juego es una elección de gobernanza, no una idea de última hora técnica. Considera qué le dices a los clínicos que se espera que la usen —su propósito, sus modos de fallo conocidos, los grupos para los que es menos confiable— y si esa sesión informativa es franca o un resumen de marketing. La honestidad orientada al paciente también importa: ¿se le dice a la gente cuándo la IA está involucrada en su atención, y en lenguaje sobre el que puedan actuar? Esta también es una pregunta de fuerza laboral, porque la confianza demasiado baja significa que se ignora una herramienta útil mientras que la confianza demasiado alta produce el sesgo de automatización que vacía la supervisión. Una respuesta honesta confronta si tu formación y comunicación están construyendo confianza calibrada o meramente vendiendo la herramienta.

En la práctica: un ejemplo de salud y atención#

A un sistema de atención integrada se le ofrece una herramienta de IA que lee radiografías de tórax y marca probables anormalidades para priorizar la cola de reporte de radiología. El oficial de seguridad clínica y el director médico resisten la presión de contratarla rápidamente y en cambio la someten a la gobernanza apropiada.

Primero, clasificación: la herramienta tiene un propósito médico claro, así que se confirma como Software as a Medical Device, y se verifican su marcado de conformidad MHRA y declaración de uso previsto —el uso previsto es apoyo de triaje, no diagnóstico autónomo, lo que da forma a todo lo que sigue. Luego, aseguramiento: la herramienta pasa por DTAC como línea base, sus reclamos clínicos se verifican contra el NICE Evidence Standards Framework, se completa una evaluación de riesgo clínico DCB0160, y una DPIA cubre los datos de imagenología (véanse los Temas 1.6 y 1.7). El equipo pide rendimiento por subgrupo y descubre que la población de validación subrepresentaba una demografía local; exigen validación local adicional antes de proceder, tratando el sesgo potencial como un riesgo de desigualdad en salud en lugar de una nota al pie.

En el despliegue, el diseño mantiene un humano en el bucle: cada imagen todavía es reportada por un radiólogo, y la IA solo reordena la cola, así que una marca perdida no puede por sí misma causar un diagnóstico perdido. La vigilancia posterior al mercado se establece desde el primer día —monitoreando tasas de detección, discordancia entre el modelo y los radiólogos que reportan, y cualquier deriva a medida que cambia el hardware del escáner y la mezcla de casos— con umbrales preacordados para pausar la herramienta y una ruta de reversión a través del despliegue versionado del proveedor. Por separado, cuando una sala pide pegar historiales de pacientes en un LLM público para redactar resúmenes de alta, el mismo foro de gobernanza dice no a esa ruta no gestionada y encarga en su lugar una herramienta aprobada y contenida con verificación humana. Un año después, la herramienta de priorización de cola ha mejorado modestamente el tiempo de respuesta de reporte, su monitoreo ha capturado un episodio de deriva después de una actualización de escáner, y —crucialmente— la organización puede mostrar exactamente cómo se gobierna.

Perspectivas sectoriales#

Startup#

Una startup de salud digital a menudo es la IA, así que su madurez de gobernanza es su acceso al mercado. Los fundadores deberían tratar la clasificación regulatoria, validación clínica, y evidencia de sesgo como trabajo de producto central, no como un impuesto de cumplimiento añadido antes de una venta, porque el oficial de seguridad clínica de un comprador pedirá exactamente esto y un "no" termina el trato. Involucrarse temprano con la MHRA —potencialmente a través de mecanismos como el AI Airlock para preguntas genuinamente novedosas— y diseñar para DTAC y el NICE Evidence Standards Framework desde el principio convierte el aseguramiento en una ventaja competitiva. El riesgo característico de startup es sobrereclamar: marketing que supera la evidencia, o una demostración de precisión promedio que oculta un rendimiento pobre de subgrupo. El fundador disciplinado construye el monitoreo y vigilancia posterior al mercado en el producto temprano, porque un solo fallo escalado en un sitio de referencia es un evento existencial para una empresa pequeña.

Pequeña empresa#

Un proveedor pequeño y establecido —una consulta de médico de cabecera, una farmacia comunitaria, una residencia de cuidados, una clínica de un solo emplazamiento— generalmente es un comprador de IA en lugar de un constructor, sin embargo lleva los mismos deberes que un gran fideicomiso sin ninguno del personal dedicado de seguridad clínica, IG, o informática para cumplirlos. El riesgo práctico es adoptar una herramienta según las garantías de un proveedor porque no hay capacidad interna para exigir la clasificación de dispositivo, evidencia de subgrupo, o una DPIA, y nadie que note cuando un modelo deriva. Apóyate fuertemente en el aseguramiento que otros ya han hecho: prefiere herramientas que claramente tengan marcado de conformidad MHRA y hayan pasado DTAC, compra a proveedores que publican su evidencia, y recomienda aplicaciones de salud solo de una biblioteca curada que tu ICS o un organismo nacional haya asegurado en lugar de evaluar cada una tú mismo. Donde no puedas verificar personalmente la seguridad de una herramienta, esa es una razón para deferir al aseguramiento compartido de tu sistema, no para saltarte la verificación. Mantener incluso un registro ligero de qué herramientas de IA usas, para qué, y quién las posee convierte un deber inmanejable en uno proporcional.

Gran organización#

Un gran fideicomiso o ICS tiene el aparato para gobernar la IA apropiadamente y la escala que hace serio equivocarse. Su trabajo es extender las funciones existentes de seguridad clínica, IG, y aseguramiento para cubrir la IA —un registro de modelo, barras de equidad de subgrupo, monitoreo posterior al mercado, MLOps para versionado y reversión— en lugar de dejar que la IA llegue a través de rutas de TI o investigación no escrutadas. El peligro real de la gran organización es la fragmentación: docenas de pilotos, ensayos de escriba ambiental, y experimentos departamentales de LLM proliferando sin inventario central, sin DPIA consistente, y sin nadie responsable cuando una herramienta deriva. La fatiga de cambio y la presión de proveedor empujan hacia la adopción rápida, así que el liderazgo debe mantener la línea de que la novedad no se gana un proceso más ligero. Hecho bien, la gran organización también puede generar la evidencia de validación prospectiva y local que los jugadores más pequeños no pueden, y compartirla a través del sistema.

Gobierno#

Los organismos nacionales y locales de gobierno —la MHRA, NHS England, DHSC, NICE, administraciones descentralizadas, y autoridades locales— establecen las condiciones bajo las cuales todos los demás despliegan la IA. Sus instrumentos son la regulación, estándares, marcos de aseguramiento (DTAC, el Evidence Standards Framework), mecanismos de puerto seguro como el AI Airlock, y la financiación y orientación que dirigen la adopción segura a través de un sistema federado que no gestionan de línea directamente. La responsabilidad recae en ministros, el Parlamento, y el público, así que un fallo de IA escalado o un sesgo demostrable en una herramienta nacional es un evento de confianza pública con una sombra larga. El rol apropiado del gobierno es hacer del camino seguro el camino fácil —reglas claras, aseguramiento reutilizable, comunicación pública honesta sobre lo que la IA puede y no puede hacer— mientras resiste tanto los mandatos impulsados por el bombo como la prohibición reflexiva. Equivocar el equilibrio en cualquier dirección cuesta años de confianza.

Modos de fallo comunes#

• Saltarse la clasificación regulatoria. Desplegar una IA clínica como si fuera software ordinario. Evítalo determinando el estado de dispositivo y marcado de conformidad primero, con aporte regulatorio.
• Ceguera de precisión titular. Aceptar una cifra promedio que oculta un rendimiento pobre para grupos subrepresentados. Evítalo exigiendo evidencia de subgrupo antes de la puesta en marcha y monitoreando la inequidad después.
• Validar una vez, olvidar para siempre. Tratar la puesta en marcha como el fin del aseguramiento mientras el modelo silenciosamente deriva. Evítalo estableciendo vigilancia posterior al mercado con umbrales y reversión.
• Supervisión humana decorativa. Un "humano en el bucle" que aprueba automáticamente bajo sesgo de automatización. Evítalo auditando tasas de anulación y diseñando autoridad genuina para intervenir.
• IA generativa no gobernada. Personal pegando datos de pacientes en LLM públicos y confiando en la salida fabricada. Evítalo con política clara más una herramienta aprobada y contenida con verificación humana.
• Proceso paralelo de toque ligero. Dejar que la IA evite la seguridad clínica e IG porque es "innovación". Evítalo extendiendo la maquinaria DCB y DPIA existente a la IA.
• Sin inventario. Nadie sabiendo qué modelos están en vivo, en qué datos, poseídos por quién. Evítalo manteniendo un registro de modelo.

Modelo de madurez#

Lista de verificación#

• El estado de dispositivo médico y marcado de conformidad MHRA de cada herramienta de IA se determinan y documentan.
• La IA clínica ha pasado DTAC, se ha verificado contra el NICE Evidence Standards Framework, y tiene una evaluación de riesgo clínico DCB y una DPIA.
• Se ha visto el rendimiento de subgrupo (edad, sexo, etnia, privación) y cumple una barra de equidad acordada.
• La validación clínica coincide con el nivel de riesgo y prefiere evidencia prospectiva y local.
• Se diseña un humano en el bucle significativo, con autoridad e información para anular.
• La responsabilidad nombrada para decisiones informadas por IA está escrita.
• La vigilancia posterior al mercado, umbrales de deriva, y un plan de pausa/reversión están en vivo desde la puesta en marcha.
• MLOps da versionado de modelo y reversión segura; la versión en vivo siempre se conoce.
• La política de IA generativa permite usos realistas, prohíbe datos de pacientes en servicios no gestionados, y exige verificación humana.
• La gobernanza de la información cubre los datos de entrenamiento, ajuste fino, y evaluación, con límites contractuales sobre la reutilización del proveedor.
• Un registro de modelo legible por humanos registra propósito, procedencia, evidencia, monitoreo, y propietario.
• Las tecnologías emergentes se escanean en el horizonte y se introducen a través de evaluación controlada y reversible.

Fuentes clave#

• MHRA — Software and Artificial Intelligence (AI) as a Medical Device, y la zona de pruebas regulatoria AI Airlock (gov.uk).
• NICE — Evidence Standards Framework (ESF) for digital health technologies (nice.org.uk).
• NHS England — Digital Technology Assessment Criteria (DTAC) para el aseguramiento de línea base de tecnologías de salud digital.
• NHS England / antiguo NHSX — A Buyer's Guide to AI in Health and Care, y la AI Ethics Initiative.
• DCB0129 y DCB0160 — estándares de gestión de riesgo clínico para TI de salud (véase el Tema 1.6).
• MHRA / IMDRF — marco de Software as a Medical Device (SaMD) y buena práctica de aprendizaje automático.
• The King's Fund y the Health Foundation — análisis de IA, datos, y desigualdades en la salud y la atención.
• Véase también el Tema 1.3 — Decisiones impulsadas por evidencia; el Tema 1.6 — Seguridad clínica y gestión de riesgos; el Tema 1.7 — Gobernanza de la información, protección de datos y ciberseguridad; el Tema 8.0 — Introducción escalonada de la innovación.

Referencias#

1. Artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Artificial_intelligence
2. Machine learning — Wikipedia — https://en.wikipedia.org/wiki/Machine_learning
3. Medical software (including Software as a Medical Device) — Wikipedia — https://en.wikipedia.org/wiki/Medical_software
4. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
5. Algorithmic bias — Wikipedia — https://en.wikipedia.org/wiki/Algorithmic_bias
6. Explainable artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Explainable_artificial_intelligence
7. Concept drift — Wikipedia — https://en.wikipedia.org/wiki/Concept_drift
8. MLOps — Wikipedia — https://en.wikipedia.org/wiki/MLOps
9. Human-in-the-loop — Wikipedia — https://en.wikipedia.org/wiki/Human-in-the-loop
10. Generative artificial intelligence — Wikipedia — https://en.wikipedia.org/wiki/Generative_artificial_intelligence
11. Large language model — Wikipedia — https://en.wikipedia.org/wiki/Large_language_model
12. Hallucination (artificial intelligence) — Wikipedia — https://en.wikipedia.org/wiki/Hallucination_(artificial_intelligence)
13. Software and AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
14. AI Airlock: the regulatory sandbox for AI as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/collections/ai-airlock-the-regulatory-sandbox-for-aiamd
15. Evidence standards framework (ESF) for digital health technologies — NICE — https://www.nice.org.uk/about/what-we-do/digital-health/evidence-standards-framework-for-digital-health-technologies
16. Digital Technology Assessment Criteria (DTAC) — NHS England — https://transform.england.nhs.uk/key-tools-and-info/digital-technology-assessment-criteria-dtac/
17. A Buyer's Guide to AI in Health and Care — NHS Transformation Directorate — https://transform.england.nhs.uk/ai-lab/explore-all-resources/adopt-ai/a-buyers-guide-to-ai-in-health-and-care/
18. Software as a Medical Device (SaMD): Key Definitions — International Medical Device Regulators Forum (IMDRF) — https://www.imdrf.org/documents/software-medical-device-samd-key-definitions
19. Digital therapeutics — Wikipedia — https://en.wikipedia.org/wiki/Digital_therapeutics