Una carretera, un hospital y un modelo comparten un problema: la evidencia
La evidencia tiene que sobrevivir al traspaso
Un diseñador de carreteras, un equipo hospitalario y un proveedor de modelos pueden ofrecer todos una demostración convincente. El cruce puede parecer ordenado en un plano. La pantalla clínica puede parecer tranquila en un taller. El modelo puede devolver una respuesta sensata sobre un conjunto de ejemplos cuidadosamente seleccionado. Nada de eso resuelve la cuestión que importa cuando el sistema entra en la vida ordinaria: ¿qué evidencia respalda esta acción concreta, para estas personas, en estas condiciones, y quién tiene derecho a cambiar el rumbo cuando la evidencia deja de sostenerse?
Esa pregunta es más útil que un debate sobre si una carretera, un hospital o un sistema de IA es «seguro». La seguridad no es una propiedad que llega en una caja de cartón con el dispositivo. Es una relación continua entre un propósito, un entorno, un conjunto de personas, los límites de un sistema y el trabajo que se hace cuando se alcanza un límite. Una carretera necesita dar cabida a personas que cometen errores y a condiciones que cambian. Un servicio clínico necesita preservar el juicio cuando la información es incompleta, urgente o controvertida. Un sistema de IA necesita seguir siendo lo bastante comprensible como para que una persona pueda ver cuándo su resultado ha dejado de ser una contribución útil a una decisión.
Europa ya tiene partes de esta disciplina en distintos lugares. Las normas de infraestructura viaria exigen procedimientos como la evaluación de impacto, las auditorías, las inspecciones de seguridad y la evaluación de toda la red. La Ley de Inteligencia Artificial pide que los sistemas de alto riesgo trabajen con gestión del riesgo del ciclo de vida, documentación técnica, registros, supervisión humana, precisión adecuada, robustez y ciberseguridad. Las instituciones sanitarias europeas están debatiendo seguridad, equidad, gobernanza, preparación de la plantilla y rendición de cuentas de manera conjunta, en lugar de tratar un modelo clínico como un software que se vuelve inofensivo porque su interfaz lleva un estetoscopio dibujado.
El hilo común es la evidencia. No la evidencia como una carpeta gruesa montada una sola vez, ni la evidencia como un marcador con una media halagüeña. La evidencia como algo vinculado a una afirmación, un contexto y una decisión. Un registro de evidencia útil dice para qué se pensó el sistema, dónde se aplica la afirmación, qué observaciones la respaldan, qué supuestos la sustentan, qué sigue siendo incierto, quién puede intervenir y qué cambio implica que el argumento deba reconsiderarse.
Esta es una idea menos glamurosa que la autonomía. También es más duradera. Da a los ingenieros una manera de declarar sus límites sin fingir que un conjunto de pruebas es un mundo completo. Da a los gestores una manera de preguntar qué están aceptando realmente. Da a los operadores algo mejor que un panel que se ilumina después de que la decisión ya se haya vuelto difícil. Y lo más importante: da a las personas afectadas por un sistema una vía que va del resultado a las razones y condiciones que lo produjeron.
Tres ámbitos, una pregunta incómoda
La carretera, el hospital y el modelo no son el mismo sistema. Sus daños, obligaciones legales, bases de evidencia y culturas profesionales difieren. Nadie debería copiar una auditoría de carreteras en un flujo de trabajo clínico, ni pegar una lista de verificación de dispositivo médico a un modelo de lenguaje y dar el trabajo por terminado. La cuestión no es aplanar las diferencias. La cuestión es advertir un problema de ingeniería compartido: un sistema automatizado o semiautomatizado actúa a través de un entramado más amplio de personas, procedimientos, interfaces, entornos y supuestos.
Una carretera es un recordatorio especialmente claro porque no toma decisiones en el sentido humano. Las moldea. La geometría, las líneas de visión, la separación, los cruces, las marcas viales, la gestión de la velocidad, el mantenimiento y la red circundante influyen en lo que las personas pueden ver, de qué pueden recuperarse y en la gravedad que alcanza un error. Las buenas prácticas de seguridad vial no dependen de la fantasía de un usuario de la vía permanentemente alerta y perfectamente informado. Intentan que los errores previsibles sean menos probables y menos punitivos. El marco europeo para la gestión de la seguridad de las infraestructuras viarias refleja esa visión sistémica mediante procesos repetibles de evaluación e inspección, en lugar de una única declaración de que una ruta ha sido aprobada.
Un hospital es diferente, pero también convive con la brecha entre una descripción limpia y una realidad cambiante. Una vía clínica incluye roles del personal, traspasos, registros, equipos, prioridades, interrupciones y una persona cuyo estado puede no parecerse al caso medio que dio forma a un protocolo. Una recomendación puede ser útil y, aun así, insuficiente. Una advertencia puede ser técnicamente correcta y llegar, no obstante, en un momento en que no se puede actuar sobre ella con seguridad. Un sistema puede mejorar una parte de un flujo de trabajo mientras crea una nueva carga en otro lugar. Por eso la discusión sobre la IA en la salud no puede detenerse en el rendimiento aparente de un modelo. Tiene que incluir gobernanza, responsabilidad clínica, calidad de los datos, formación, confianza pública y los medios para identificar y corregir daños.
Un modelo se encuentra dentro del mismo tipo de disposición. Se entrena o configura en un lugar, se conecta a datos en otro, una persona le da un aviso o una tarea, se coloca detrás de una interfaz, algunas personas lo observan y otras no. Produce un resultado, pero el resultado solo se vuelve relevante cuando alguien lo trata como una razón para actuar. Entre el resultado y la acción se interponen umbrales, autoridad, presión de tiempo, acceso al material fuente, formación, incentivos y la posibilidad de disentir. Esos no son detalles operativos decorativos. Deciden si un componente técnicamente competente sigue siendo un componente seguro del sistema más amplio.
Considere lo siguiente como un compuesto explícitamente hipotético, no como un relato de una carretera, un hospital, un paciente, un empleado o un incidente reales. Una autoridad local está considerando un sistema que señala ubicaciones para una revisión de seguridad vial. Un hospital está considerando una herramienta que ayuda a clasificar documentos administrativos antes de que los vea el personal clínico. Una tercera organización está considerando un modelo que redacta un resumen de riesgos para un gestor de infraestructuras. En cada entorno, una demostración temprana muestra que el sistema puede encontrar patrones en los registros existentes. La demostración aún no responde si los registros representan las condiciones que el servicio verá el próximo mes, si se puede reconocer un caso inusual, si las personas que reciben una recomendación tienen suficiente tiempo y autoridad para cuestionarla, o si la organización notará un patrón dañino antes de que se convierta en trabajo normal. El problema de la evidencia comienza exactamente ahí.
El error fácil es pedir un único número. ¿Cuál es la precisión? ¿Cuánto tiempo ahorrará? ¿Cuántos riesgos detectará? Esas preguntas son legítimas pero incompletas. Un número necesita un denominador, una muestra, una definición, una fecha, un uso previsto y una declaración de lo que se excluyó. También necesita una relación con la siguiente decisión. Una puntuación alta en una tarea estrecha y estable puede respaldar una afirmación estrecha y estable. No puede autorizar silenciosamente un flujo de trabajo diferente, una población diferente o una decisión con una consecuencia diferente.
La evidencia no es un accesorio decorativo
La evidencia resulta útil cuando puede cambiar la opinión de alguien. Esto parece obvio, pero muchos paquetes de evidencia se crean para parecer completos, no para que una decisión pueda cuestionarse. Contienen capturas de pantalla, declaraciones de políticas, resúmenes de pruebas y firmas, pero no muestran qué afirmación respalda cada elemento, qué condición limita la afirmación ni qué debería ocurrir si la condición cambia. El resultado es papeleo con un papel ceremonial. Puede demostrar que se celebró una reunión. Pero no necesariamente indica al operador qué hacer a las 07:40 cuando el servicio está saturado, los datos llegan tarde y una recomendación no encaja con el caso que tiene delante.
Un mejor punto de partida es una decisión con nombre. No «implementar la IA de forma responsable» ni «mejorar la seguridad vial», sino una proposición con un límite. Por ejemplo: este sistema puede priorizar una clase definida de trabajo de revisión, en un contexto operativo especificado, mientras un rol con nombre sigue siendo responsable de aceptar o rechazar la recomendación. O bien: este diseño puede abrirse al tráfico después de que los peligros identificados se hayan evaluado mediante el proceso requerido y de que los controles identificados estén en marcha. La redacción es deliberadamente menos emocionante que un anuncio de producto. Es un contrato con la realidad.
Una vez que la decisión tiene nombre, el resto del registro tiene dónde anclarse. El propósito previsto indica al lector qué no debe inferir. El contexto le indica qué sitio, flujo de trabajo, usuarios, datos, equipos y proceso circundante son relevantes. La evidencia registra pruebas, observaciones, material de origen, revisiones y ejercicios. Los supuestos hacen visibles las dependencias: quizá un operador tenga formación, quizá un registro de fuentes esté actualizado, quizá una alerta concreta llegue a un rol concreto a tiempo. El responsable identifica quién puede interpretar el material e intervenir. Los desencadenantes de revisión indican qué señal, cambio o fallo de un supuesto exige una nueva revisión.
Esta estructura tiene una consecuencia importante. Impide que la evidencia se separe de su uso. Una prueba no se archiva simplemente en «validación». Se conecta con una afirmación sobre un comportamiento concreto en condiciones declaradas. Una auditoría no es solo la prueba de que un auditor visitó el lugar. Se convierte en un registro de qué se examinó, qué se encontró, qué seguía siendo incierto y qué autoridad decidió qué ocurriría después. Una evaluación de modelo no es una insignia genérica. Es una observación acotada cuya relevancia depende de la versión del modelo, la tarea, los datos, la configuración y las condiciones de implementación.
El mismo registro debe hacer visible la ausencia. Si nadie ha probado un sistema con una entrada poco común pero de consecuencias importantes, eso no es una pequeña vergüenza que ocultar bajo un promedio. Es un límite de evidencia. Si un humano puede técnicamente anular una recomendación pero no tiene tiempo, acceso o autoridad para hacerlo en el flujo de trabajo real, eso no es supervisión significativa. Es una brecha de diseño. Si una inspección de seguridad vial detecta una condición recurrente pero ninguna organización es responsable del trabajo correctivo, la observación aún no se ha convertido en un control. En sistemas serios, la evidencia faltante es un resultado. Le dice a la organización dónde aún no puede hacer una afirmación.
La seguridad vial ofrece una lección práctica de humildad
La seguridad vial ha pasado décadas aprendiendo que el daño rara vez se explica por un solo mal actor o un solo componente defectuoso. La persona que conduce demasiado rápido, el cruce que es difícil de leer, el vehículo, el clima, la iluminación, el estado de mantenimiento, la mezcla de tráfico y la respuesta de emergencia pueden ser todos relevantes. Eso no disuelve la responsabilidad individual. Sí previene la conclusión superficial de que todo fallo se puede arreglar diciéndole a la gente que preste más atención. Un sistema que solo funciona cuando nadie comete un error previsible no es un sistema impresionantemente estricto. Es uno frágil.
Las normas de gestión de seguridad de la infraestructura vial de la UE ofrecen un contrapeso útil a la idea de que la aprobación es un evento único. Organizan el trabajo de seguridad en torno a procedimientos que examinan las consecuencias prospectivas, el diseño, la operación y la red existente. El alcance legal exacto importa, y las normas deben leerse como legislación de infraestructura vial, no como una plantilla general para toda tecnología. Aun así, su hábito subyacente es ampliamente valioso: inspeccionar el sistema en las condiciones en las que operará, buscar patrones en lugar de esperar un evento dramático, y tratar el conocimiento como una razón para ajustar el arreglo.
Ese hábito no es simplemente "recopilar más datos". Datos sin una pregunta son una forma muy eficiente de almacenar confusión. La pregunta de seguridad vial podría referirse a dónde un cruce crea un conflicto, qué personas están expuestas a él, con qué frecuencia ocurren las condiciones, qué tipo de error es previsible, qué medidas físicas u operativas reducen el riesgo, y cómo sabrá la organización si la medida ha cambiado la situación. La evidencia que importa es, por tanto, mixta. Incluye condiciones de tráfico, registros de diseño, observaciones de inspección, información de mantenimiento, informes de daños y juicio profesional. Un mapa solo no puede sostener la afirmación. Tampoco puede hacerlo una sola estadística de colisiones.
Hay un punto útil de factores humanos aquí. El sistema tiene que estar diseñado para las personas tal como son, no para un usuario ficticio que lee cada señal, juzga cada velocidad perfectamente y nunca llega distraído, cansado, sin experiencia, apurado, enfermo o simplemente sorprendido. Eso no es una excusa para el comportamiento descuidado. Es un reconocimiento de que la ingeniería de seguridad tiene que funcionar en el espacio entre la intención y la capacidad humana real. Cuando un sistema depende de que una persona note, comprenda y actúe, esos tres pasos necesitan evidencia propia. ¿Se puede ver la señal? ¿Se puede entender su significado? ¿Puede la persona actuar a tiempo y con suficiente autoridad?
Los equipos de IA a menudo pasan por alto esto porque el humano está representado como una caja al final de un diagrama de flujo. La caja dice "revisor", "operador" o "humano en el circuito" y por lo tanto parece resolver el problema. Pero un nombre de rol no describe una interacción. Un diseño de revisión útil necesita decir qué ve la persona, qué no ve, qué evidencia puede inspeccionar, si puede solicitar otra ruta, cuándo se espera que discrepe, qué sucede después del desacuerdo y cómo aprende la organización de ello. Estas preguntas son tan ordinarias como verificar si un cruce se puede usar de manera segura bajo lluvia u oscuridad. También son mucho más informativas que una promesa de que una persona sigue involucrada.
Un hospital no puede hacer desaparecer la incertidumbre
La atención sanitaria hace que el problema de la evidencia sea especialmente visible porque las consecuencias son personales y el entorno es complejo. Un sistema clínico o administrativo útil puede ayudar al personal a encontrar información, reducir el trabajo repetitivo, detectar un posible patrón o preparar material para su revisión. Eso no lo convierte en una autoridad clínica. La transición de la información al tratamiento, la priorización o la denegación de la atención conlleva obligaciones que no pueden externalizarse a una interfaz. La persona responsable de la atención debe saber qué hizo el sistema, qué no hizo y cómo responder cuando el resultado entre en conflicto con los hechos disponibles en el caso.
El trabajo de la OMS/Europa sobre la IA en la salud enmarca la cuestión con el vocabulario que merece: seguridad, eficacia, equidad, derechos humanos, transparencia, rendición de cuentas, gobernanza y preparación de la fuerza laboral. La cuestión no es que cada trabajador clínico deba convertirse en un especialista en aprendizaje automático. La cuestión es que un sistema no puede utilizarse de forma responsable si las personas que deben confiar en él, supervisarlo o cuestionarlo no disponen de una explicación útil de sus limitaciones. La formación forma parte del entorno de control. También lo son las vías de escalado, los acuerdos de responsabilidad, la evidencia del rendimiento en el mundo real y una forma de que pacientes y profesionales planteen sus inquietudes sin tener que convertirse primero en expertos en la tecnología.
La Comisión Europea sitúa igualmente la IA en la salud dentro de un marco normativo y operativo más amplio. Su material de salud pública señala que el software de IA con fines médicos puede estar sujeto a los requisitos de alto riesgo de la Ley de IA, incluidos la mitigación de riesgos, la calidad de los datos, la información al usuario y la supervisión humana. Eso no es una afirmación de que toda herramienta utilizada en un hospital reciba la misma clasificación jurídica. Es un recordatorio de que la palabra «salud» no suaviza la necesidad de un análisis cuidadoso de la finalidad prevista. Cuanto más trascendental sea el uso, menos creíble será confiar en garantías generales.
La práctica clínica también demuestra por qué los umbrales de intervención deben ser explícitos. Un sistema puede tener permiso para recuperar una fuente, preparar un resumen, señalar un campo que falta o sugerir que un caso merece atención. Son actos distintos. Cada uno se aleja un poco más de la información hacia la influencia. En algún momento, un sistema puede tener permiso para dar un paso operativo limitado, quizá con reglas que acoten el alcance y un registro que haga reversible ese paso. Más allá de ese punto, podría pedírsele que actúe sin una decisión humana simultánea. La evidencia, la autoridad y el diseño de recuperación necesarios en esos niveles no son intercambiables.
Esto no hace imposible la automatización. Hace que las afirmaciones sean proporcionadas. Una organización puede elegir una tarea modesta y bien delimitada y hacerla fiable antes de imaginar una más amplia. Puede mantener disponible el material de origen en lugar de convertir un resumen en el único registro. Puede dar a un clínico u otro trabajador responsable un medio real para pausar el sistema, no un botón teórico escondido en un manual de políticas. Puede supervisar lo que ocurre después del despliegue y tratar el comportamiento inesperado como evidencia de que el argumento original necesita revisión. Eso es más lento que declarar que el modelo se ha hecho cargo. Generalmente es más rápido que intentar reconstruir una decisión después de que la confianza ya se haya perdido.
El modelo no es todo el sistema
The AI Act is valuable here because it refuses, in its high-risk provisions, to treat the model as the only relevant object. Article 9 sets out a documented, maintained and continuous iterative risk-management process. Article 10 concerns data and data governance. Article 11 and Annex IV address technical documentation. Article 12 addresses automatic recording of relevant events. Article 14 addresses effective human oversight, including the ability to understand relevant limits, override or reverse output where appropriate, and stop the system safely. Article 15 concerns accuracy, robustness and cybersecurity. These are not interchangeable paperwork categories. Together they point at a system that has to be understood across its lifecycle.
The law does not make a technical judgement for every organisation. It does not announce that a given performance measure is enough, nor does it make an operator competent by naming them in a document. It does something more demanding. It requires a way of connecting intended purpose, risk, documentation, records, human oversight and ongoing monitoring. That connection is precisely what gets lost when an AI project is described as a model acquisition rather than an operational change.
Take the commonplace claim that a human can override the model. Override what, exactly? A probability, a ranking, a generated paragraph, a routing decision, an automatic notification, a resource allocation or a physical action? Before or after it takes effect? With which information? Under which time constraint? Does the human see why the system reached the output, or merely that it did? Are there consequences for disagreeing? Is the disagreement recorded? Is it reviewed as a possible model, data or workflow problem? A truthful answer to these questions is more reassuring than a glossy assurance because it describes a control that can actually be exercised.
Human oversight is sometimes treated as a moral accessory: add a person to the process and the system becomes humane. It is better understood as an engineering relationship. The person needs a meaningful opportunity to detect a limitation, the authority to intervene, an action that changes the outcome, and a system state that remains safe when the intervention happens. A powerless reviewer is a witness. A reviewer who only sees an output after it has become irreversible is an auditor of a decision already made. Neither arrangement is equivalent to oversight.
Evidence should therefore grow as discretion and irreversibility grow. A retrieval tool that helps a professional find source material has one kind of evidence burden. A system that ranks work for attention has another, because ranking shapes what may be seen late or not at all. A constrained system that automatically performs an operational task needs clear boundaries, monitoring and a recovery route. A system that acts without a live decision needs the strictest case: a narrow purpose, evidence for the operating context, fail-safe behaviour, independent challenge where appropriate, clear ownership and continuing review. The designation is less important than the principle. More autonomy is a larger claim, not a marketing upgrade.
Los umbrales evitan que una herramienta útil se convierta en una decisión sin dueño
Un umbral de intervención es una respuesta práctica a una pregunta práctica: ¿cuándo se le permite al sistema actuar y cuándo debe devolver el asunto a una persona? Debe ser visible antes del despliegue, no descubrirse a través de una reclamación. Un umbral puede depender de la confianza, pero la confianza por sí sola no basta. Puede depender del tipo de decisión, de las consecuencias de un error, de la calidad y actualidad de los datos, de la presencia de evidencia contradictoria, de la disponibilidad de una persona cualificada, de la capacidad de recuperación y del grado en que el caso se ajusta al propósito declarado.
Los umbrales no son una prueba de que un sistema sea seguro. Son una forma de impedir que un sistema reclame más autoridad de la que su evidencia puede respaldar. Un modelo puede ser capaz de resumir un registro, pero no de evaluar su integridad. Puede identificar un término, pero no determinar su significado jurídico. Puede producir una explicación plausible, pero no establecer la veracidad de esa explicación. Puede reconocer un patrón habitual y seguir siendo inadecuado para casos excepcionales, fuentes contradictorias o situaciones en las que un pequeño error sería difícil de revertir. El umbral es el punto donde la organización convierte esas distinciones en comportamiento.
Para una autoridad vial, un umbral podría establecer que una combinación de hallazgos de inspección e indicadores de riesgo definidos conduzca a una revisión formal, mientras que una combinación distinta exija una medida temporal urgente. Los criterios exactos pertenecen al marco jurídico y profesional correspondiente. La idea transferible es que la ruta desde la observación hasta la intervención no debe depender por completo de quién esté de turno ni de qué preocupación se recuerde con más viveza en la reunión. La evidencia no sustituye al juicio profesional. Le proporciona al juicio un registro compartido y una ruta repetible.
Para un hospital, un umbral podría distinguir entre una herramienta que prepara material para su revisión y un sistema que puede realizar una acción administrativa limitada. Este último necesita un registro claro de su alcance, una forma de detectar una excepción, un responsable designado para esa excepción y una forma de restaurar el estado anterior si la acción fuera incorrecta. Si el sistema afecta a una decisión clínicamente relevante, el umbral debe tener en cuenta las obligaciones clínicas, jurídicas y profesionales pertinentes. No se debe pedir a la persona responsable que repare un resultado de automatización opaco sin rastro de origen y sin tiempo para inspeccionarlo.
En un sistema de IA para infraestructura, un umbral puede distinguir una previsión de una acción de control. Una previsión puede alertar a un operador sobre una condición que merece la pena comprobar. Una acción de control puede alterar un estado físico u operativo. La segunda afirmación exige un relato mucho más sólido sobre la calidad de los datos de entrada, los límites del sistema, las condiciones ambientales, la supervisión, la autoridad, los mecanismos de respaldo y la recuperación. Esto no es burocracia impuesta para frustrar a los ingenieros. Es la descripción técnica de lo que ocurre cuando el coste de equivocarse no es una respuesta decepcionante en una ventana de chat.
El umbral más útil suele ser el umbral de rechazo. ¿Qué debería hacer que el sistema se negara a actuar? ¿Qué dato de entrada ausente, conflicto, registro tardío, condición fuera de distribución, revisor no disponible o cambio sin probar debería provocar una pausa segura? Las organizaciones tienden a describir lo que esperan que su sistema haga. Son menos proclives a escribir cuándo debe detenerse. Sin embargo, el comportamiento de detención de un sistema a menudo revela más sobre su madurez que su comportamiento de exhibición. La capacidad de decir «este caso está fuera de la evidencia» no es un defecto. Es la prueba de que el límite existe.
Los factores humanos forman parte de la evidencia, no una nota a pie de página
Los factores humanos a veces se reducen a la observación de que las personas son falibles. Eso es cierto, pero no muy útil por sí solo. La cuestión técnica es cómo se organiza el trabajo en torno a la atención, la memoria, la percepción, la carga de trabajo, la comunicación y la autoridad humanas reales. Una advertencia que no se puede notar no es una advertencia. Una explicación compleja que no se puede entender bajo presión de tiempo no es transparencia significativa. Un control de detención que requiere la aprobación de alguien que no está disponible no es un control de detención. Una pantalla de revisión que oculta el registro subyacente no es una superficie de evidencia.
El diseño de carreteras hace esto concreto. Las personas se mueven por un entorno físico con tiempo limitado para ver, interpretar y actuar. El sistema no se puede evaluar solo describiendo sus señales previstas. Debe evaluarse considerando si las personas pertinentes pueden utilizarlas en el entorno real. La atención sanitaria plantea el mismo punto en un registro diferente. El lector de una alerta o recomendación puede ser interrumpido, lidiar con prioridades contrapuestas, cubrir a un compañero o enfrentarse a un caso que no encaja perfectamente en el proceso. La IA añade otra capa, porque una salida fluida puede crear la falsa impresión de que el sistema ha sopesado evidencia que simplemente ha reformulado.
La respuesta no es exigir una concentración sobrehumana. Es diseñar y probar la transferencia. ¿Qué muestra el sistema primero? ¿Qué fuente puede inspeccionar la persona? ¿Cómo expresa la incertidumbre? ¿Puede la persona solicitar una ruta diferente? ¿Distingue la interfaz un registro confirmado de una inferencia? ¿Puede saber si cambiaron el modelo, la fuente de datos, la regla o la configuración? ¿Qué ocurre con los comentarios? Estas son cuestiones empíricas y organizativas. Merecen ejercicios, observación, investigación de usuarios y revisión posterior al despliegue, no solo una declaración de que la interfaz se diseñó pensando en el usuario.
Un registro de evidencia responsable debe capturar la disposición humana sin convertirse en un expediente sobre trabajadores individuales. Puede registrar el rol, la autoridad, el requisito de formación, la intervención esperada, el tiempo disponible, la superficie de información, la ruta de escalado y el resultado del ejercicio. Puede registrar que un proceso se probó bajo un escenario declarado sin pretender que el escenario demuestre todas las condiciones futuras. Puede preservar un rastro de decisiones sin usar la supervisión como excusa para una vigilancia innecesaria. Estos equilibrios son difíciles. Aun así, se gestionan mejor abiertamente que dejándolos en una instrucción vaga de que las personas «usen su criterio».
El instinto neerlandés de hacer legibles los sistemas complicados tiene aquí un lugar útil. Un cruce ciclista, un registro público o un proceso bien etiquetado no se vuelve bueno solo por ser claro, pero la claridad permite ver dónde reside la responsabilidad. El buen gobierno tiene una modestia similar. No promete que no surgirá ningún juicio difícil. Hace visible la ruta para el juicio difícil antes del día en que se necesite. No hay ceremonia de corte de cinta para una vía de escalado bien definida, quizá por eso se deja tan a menudo para más tarde.
La evidencia tiene fecha de caducidad
La parte más difícil del trabajo basado en la evidencia es aceptar que la evidencia de ayer puede ser precisa y, aun así, dejar de ser suficiente. Un modelo cambia. Una fuente de datos cambia. Un proveedor cambia un componente. Un flujo de trabajo se reorganiza. Un grupo nuevo de personas usa el servicio. Una carretera se modifica, se mantiene de otra manera o se expone a un patrón de tráfico distinto. Un hospital cambia la dotación de personal, el software, los acuerdos de triaje o los registros. La prueba original puede seguir siendo válida como observación histórica, pero la afirmación construida sobre ella puede necesitar un límite distinto.
Por eso el historial de versiones no es un detalle administrativo. Un lector que no puede identificar qué versión de un modelo, configuración, fuente de datos, política o interfaz produjo un resultado no puede reconstruir las condiciones de la decisión. Un equipo que no registra los cambios materiales no puede distinguir un problema nuevo de uno antiguo. Una organización que trata el lanzamiento como el final de la garantía tendrá que redescubrir con el tiempo por qué su confianza estaba justificada, precisamente en el momento en que la respuesta importa más.
La vigilancia poscomercialización en virtud del Reglamento de IA reconoce esta realidad del ciclo de vida para los sistemas de alto riesgo. El requisito no es una promesa de que la vigilancia elimine la incertidumbre. Es un reconocimiento de que la información llega después del despliegue y debe tener una vía de regreso a la gestión de riesgos. La lección equivalente en seguridad vial es conocida: los sistemas deben inspeccionarse y evaluarse mientras funcionan, en lugar de suponer que siguen siendo seguros porque una vez cumplieron un requisito de diseño. En el ámbito sanitario, el uso en el mundo real, la experiencia de la plantilla, el impacto en los pacientes y los acuerdos de gobernanza importan junto con cualquier evaluación previa al despliegue.
Un desencadenante de revisión debe ser lo bastante específico para poder usarse. «Revisar periódicamente» es una forma educada de pedir a los futuros colegas que adivinen. Un desencadenante mejor nombra el evento material: una nueva versión del modelo, un cambio en una fuente de entrada, una nueva ubicación de despliegue, un grupo de usuarios modificado, una discrepancia sin resolver, un patrón de quejas, una señal de seguridad, la incapacidad de realizar un paso de supervisión o un cambio en la autoridad que posee la decisión. La lista será distinta para cada sistema. Lo que importa es que el argumento original nombre las condiciones que podrían hacerlo obsoleto.
Esto también cambia el significado de una pista de auditoría. Una pista de auditoría no debe ser un almacén lleno de eventos que nadie pueda interpretar. Debe ser una ruta a través de la historia del sistema. ¿Qué afirmación estaba en vigor? ¿Qué evidencia la respaldaba en ese momento? ¿Qué versión produjo el resultado? ¿Qué persona o rol tomó la acción consecuente? ¿Qué ocurrió cuando se cuestionó el sistema? ¿Qué problema se resolvió y cuál quedó abierto? El registro debe ser proporcionado. También debe poder responder a una pregunta real sin exigir una expedición arqueológica heroica a través de los registros de la aplicación.
Cómo suena una pregunta seria sobre la evidencia
Cuando una organización evalúa un sistema crítico para la seguridad, la pregunta útil rara vez es «¿funciona?». ¿Funciona para quién, con qué fin, bajo qué condiciones, en comparación con qué, y con qué consecuencia si falla? Esas preguntas pueden parecer lentas porque impiden un sí fácil. También son las preguntas que hacen que un sí posterior valga algo.
Una buena revisión pide, por tanto, una cadena y no una colección. Pide al equipo que nombre el propósito previsto y la decisión que se deriva. Pide qué daños y modos de fallo son relevantes. Pide qué pruebas respaldan cada afirmación material y qué no muestran esas pruebas. Pide qué supuestos deben seguir siendo ciertos. Pide quién tiene autoridad para supervisar, anular, pausar y reparar. Pide cómo se comporta el sistema cuando faltan pruebas o el caso queda fuera de alcance. Pide qué se supervisará tras el lanzamiento y qué cambio activa una reevaluación.
No existe una puntuación universal que complete este ejercicio. La carretera tiene un contexto, el hospital otro, y el modelo otro más. Un sistema pequeño bien diseñado puede tener un caso de pruebas más sólido que un sistema amplio descrito con más confianza. Una afirmación acotada con un límite claro no es una afirmación débil. Es el comienzo de una honesta.
Por eso también nuestras páginas de investigación describen preguntas explícitas, límites de las pruebas y estado de acceso, en lugar de presentar el material de investigación como una capacidad terminada por defecto. El método es modesto: identificar la pregunta, hacer visible el límite de las pruebas y mantener legible el estado de publicación. No demuestra que un producto sea adecuado para un despliegue concreto, ni sustituye a una garantía específica del sector. Es, no obstante, un hábito útil. Si una organización no puede decir qué respaldan sus pruebas, qué no respaldan y quién puede cuestionarlas, aún no ha ganado una afirmación más sólida.
Una carretera, un hospital y un modelo comparten un problema. Cada uno necesita una forma de convertir el conocimiento en acción sin ocultar las condiciones bajo las cuales esa acción está justificada. La respuesta no es un archivo ceremonial, una puntuación media ni un botón marcado como supervisión humana. Es una práctica de pruebas que sigue conectada con el propósito, las personas, la autoridad y el cambio. Ese trabajo no es glamuroso. Es así como un sistema se vuelve responsable antes de tener que volverse explicable.
Fuentes
- Reglamento (UE) 2024/1689, Ley de Inteligencia Artificial, EUR-Lex
- Directiva 2008/96/CE sobre gestión de la seguridad de las infraestructuras viarias, EUR-Lex
- Política de seguridad vial, Comisión Europea
- La inteligencia artificial está remodelando los sistemas de salud: estado de preparación en la Región Europea de la OMS, OMS/Europa
- Inteligencia artificial en la atención sanitaria, Comisión Europea
- Programa de investigación Dweve