Un sistema de alto riesgo no es un modelo de alto riesgo

El riesgo no vive dentro de un modelo como una etiqueta de advertencia. Surge del propósito previsto, el despliegue, la autoridad, las interfaces y las...

Un sistema de alto riesgo no es un modelo de alto riesgo

La etiqueta se atribuye a un uso, no a una caja

Un modelo puede copiarse de un servidor a otro sin aprender nada. Sus pesos, código y capacidades anunciadas pueden permanecer inalterados. Sin embargo, la pregunta que Europa formula sobre lo que lo rodea puede cambiar por completo. ¿Para qué sirve? ¿Quién lo utiliza? ¿De quién puede alterar la posición? ¿Qué registro entra en el flujo de trabajo? ¿Quién puede cuestionar la respuesta, corregirla, detenerla o descubrir más tarde por qué se siguió?

No se trata de un intento de engrandecer un asunto sencillo. Es la diferencia ordinaria entre un componente y un sistema. Un disco de freno no es un vehículo de carretera. Una fórmula de hoja de cálculo no es una decisión fiscal. Un modelo de IA de propósito general no es, por sí mismo, todo sistema de IA que pueda construirse después a su alrededor. La distinción es fácil de aceptar con un gesto y notablemente fácil de perder en cuanto una reunión de contratación empieza a hablar de un modelo como si ya contuviera todo el despliegue futuro.

El Reglamento de Inteligencia Artificial de la UE mantiene la distinción a la vista. Define un sistema de IA y define por separado un modelo de IA de propósito general. Sus normas de alto riesgo se refieren a sistemas de IA en circunstancias concretas, incluidos los sistemas que son componentes de seguridad de productos regulados y los sistemas utilizados en ámbitos enumerados. El Reglamento también hace que la finalidad prevista sea central en la clasificación y documentación de un sistema de IA. No invita a un equipo a señalar el nombre de un modelo, colocar una etiqueta roja, ámbar o verde y declarar el trabajo terminado.

Eso debería ser liberador además de exigente. Un modelo no lleva un horóscopo moral permanente. Un análisis cuidadoso puede ser limitado cuando la finalidad prevista es limitada, y puede volverse serio donde la autoridad, la exposición y las consecuencias se vuelven serias. La condición es que el análisis debe seguir el sistema real. No la demostración. No la presentación del proveedor. No la tarea inofensiva que abrió el proyecto hace seis meses. El sistema que recibirá entradas, pondrá las salidas a disposición, dará forma a una decisión y se operará un martes cualquiera.

Considérese una ilustración deliberadamente hipotética. El mismo modelo de lenguaje se conecta primero a una herramienta interna de búsqueda de conocimiento. Recupera pasajes de políticas para un colega formado, que puede abrir la fuente original y redactar su propia respuesta. Más tarde, una organización conecta el modelo a un formulario de admisión, coloca su recomendación en un lugar destacado del expediente del caso, aplica un temporizador al caso y hace que la aceptación de la recomendación sea la vía más rápida para despejar la cola. No se necesita ningún consejo, paciente, empleado o incidente ficticio para ver el cambio. El modelo puede ser idéntico. El papel de la salida, la ruta de datos, el incentivo, la persona afectada y la autoridad práctica de la interfaz no lo son.

Ese es el argumento del artículo: un sistema de alto riesgo no es un modelo de alto riesgo. Un modelo puede ser una parte importante del sistema y puede tener obligaciones propias. Pero el análisis de riesgos solo adquiere sentido cuando llega a la finalidad prevista, el contexto de despliegue, los usuarios, las personas afectadas y la integración posterior. Esos detalles no son trámites añadidos después de la ingeniería. Son las circunstancias que dan fuerza institucional a una salida.

Pasa el cursor por encima o selecciona una capa. El modelo es una capa; la consecuencia solo aparece cuando las capas se encuentran.

Europa usa deliberadamente dos sustantivos distintos

La distinción comienza en las definiciones del Reglamento. Un sistema de IA es un sistema basado en máquinas diseñado para funcionar con distintos niveles de autonomía y que puede mostrar capacidad de adaptación tras su despliegue, que infiere de las entradas cómo generar salidas como predicciones, contenidos, recomendaciones o decisiones que pueden influir en entornos físicos o virtuales. Un modelo de IA de uso general es diferente: es un modelo de IA capaz de realizar competentemente una amplia gama de tareas distintas, se comercialice o no, y puede integrarse en una variedad de sistemas o aplicaciones posteriores.

Esas definiciones se solapan en la conversación cotidiana porque la misma palabra, IA, hace una gran cantidad de trabajo no remunerado. No deberían solaparse en una evaluación. Un modelo de uso general está hecho para viajar. Sus usos posibles son deliberadamente amplios. Un sistema de IA es el acuerdo operativo mediante el cual las salidas influyen en un entorno. Tiene un propósito, una configuración, una interfaz y un entorno. Puede incluir un modelo, varios modelos, reglas deterministas, bases de datos, sensores, personas, procedimientos y una gran cantidad de pequeñas decisiones que nadie llama inteligencia artificial hasta que fallan.

Por eso un proveedor de un modelo de IA de uso general y un proveedor o responsable de despliegue de un sistema de IA no pueden simplemente intercambiar listas de verificación. La orientación de la Comisión sobre los modelos de IA de uso general dice que los proveedores de modelos deben poner información y documentación a disposición de los proveedores posteriores de sistemas de IA para que esos proveedores puedan comprender las capacidades y limitaciones del modelo y cumplir sus propias obligaciones. Esa frase es más interesante de lo que parece a primera vista. Presupone que el proveedor posterior tiene un trabajo que el proveedor del modelo no puede completar. La documentación del modelo viaja, pero no termina el viaje.

Hay una humildad práctica en esto. Un proveedor de modelos puede describir la arquitectura, el proceso de entrenamiento, la evaluación, las tareas previstas, los requisitos de integración, las entradas y salidas, las limitaciones y las condiciones conocidas. Un equipo posterior sabe si un usuario es un especialista formado, si una persona afectada puede impugnar un resultado, si una recomendación es de asesoramiento en el nombre pero vinculante en la práctica, si una llamada a un servicio externo cambia un registro y si una acción defectuosa puede revertirse. Ninguna de las partes tiene una imagen completa por sí sola.

La división no es una laguna jurídica. Es un mapa de responsabilidad. Dice que un sistema no puede gobernarse pidiendo al proveedor del modelo que prometa control sobre un despliegue que ni opera ni ve. También dice que un integrador no puede alegar ignorancia cuando la documentación hace visible una limitación importante. La cuestión no es hacer una entrega ordenada entre entidades jurídicas. Es evitar que la pregunta se pierda en el espacio entre ellas.

Junto a la primera distinción, conviene mantener una segunda. Una clasificación de alto riesgo no equivale por sí misma a un permiso, a una garantía de seguridad, imparcialidad o legalidad. En su dictamen conjunto sobre la propuesta original de la Comisión, el Comité Europeo de Protección de Datos y el Supervisor Europeo de Protección de Datos subrayaron que la clasificación como alto riesgo no implicaba necesariamente que un sistema fuera lícito en sí mismo ni que su usuario pudiera desplegarlo como tal. El Reglamento final ha cambiado el panorama jurídico desde aquel dictamen, pero la advertencia de fondo sigue siendo útil. La clasificación es una condición regulatoria. No es un recibo que exima a la institución de seguir pensando.

Esto importa porque una etiqueta de alto riesgo puede provocar dos errores opuestos. Un equipo puede tratarla como una mancha permanente sobre un modelo y decidir que la solución es simplemente no mirar más allá. Otro puede considerar un proceso de conformidad completado como un salvoconducto para cualquier contexto posterior. Ambos enfoques sustituyen un argumento por una etiqueta. Europa ha optado por un enfoque más incómodo: identificar el sistema, su finalidad y su función, y examinar después los riesgos y obligaciones pertinentes a lo largo de su ciclo de vida.

La finalidad prevista es el punto de partida del análisis

La finalidad prevista suena modesta, casi administrativa. No lo es. El Reglamento la define como el uso para el que el proveedor concibe un sistema de IA, incluidos el contexto y las condiciones de uso específicos que figuran en la información facilitada por el proveedor. Dicho de otro modo, la finalidad no es un eslogan de página de producto. Incluye el contexto y las condiciones en los que el proveedor indica que debe utilizarse el sistema. Una declaración de finalidad útil tiene límites. Dice qué hace el sistema, para quién, con qué entradas, dentro de qué flujo de trabajo y dónde termina su autoridad.

Compárense dos descripciones. La primera dice que un sistema utiliza IA para ayudar a las organizaciones a tomar mejores decisiones. Es lo bastante amplia para caber en un telón de fondo de conferencia y demasiado amplia para operar. La segunda dice que un sistema presenta resúmenes redactados con enlace a las fuentes de un expediente existente a revisores formados; no puede tomar, transmitir ni ejecutar una decisión; el revisor debe verificar las fuentes citadas antes de utilizar un resumen; y la función no está disponible para categorías que requieren un procedimiento legal separado. La segunda descripción es menos emocionante. También es algo con lo que un ingeniero, un responsable de contratación, un compañero de cumplimiento y una persona afectada pueden discrepar en términos concretos.

La finalidad no tiene que ser una única frase. En un sistema serio suele ser un paquete compacto: tarea, resultado, usuario, población afectada, entorno, autoridad, exclusiones, dependencias y condiciones. Los requisitos de documentación técnica del Reglamento dejan espacio precisamente para este tipo de descripción. El anexo IV pide una descripción general del sistema de IA, incluida la finalidad prevista, las personas y grupos sobre los que se prevé utilizarlo y las versiones o formas específicas en que se comercializa. También pide descripciones de la arquitectura del sistema, los requisitos de datos, las medidas de supervisión humana, el seguimiento del ciclo de vida y las medidas de gestión de riesgos. La documentación tiene esa amplitud porque una ficha de modelo por sí sola no puede describir un despliegue.

La finalidad es también el punto donde un equipo descubre que ha estado describiendo una ambición en lugar de una operación. «Daremos apoyo a los trabajadores de casos» puede ocultar una docena de acuerdos distintos. ¿La herramienta busca documentos, ordena el trabajo, redacta una respuesta, recomienda una categoría, rechaza una solicitud, eleva una alerta, fija una prioridad o llama a otro servicio? ¿El compañero la utiliza antes o después de formarse una opinión independiente? ¿El resultado es una sugerencia en un panel lateral o un campo que debe completarse antes de que el expediente pueda avanzar? ¿El efecto es inmediato, diferido, reversible o difícil de detectar? La respuesta cambia el sistema incluso cuando la interfaz de usuario parece familiar.

La finalidad prevista de un proveedor no puede hacer desaparecer la realidad. Un equipo no puede otorgar a un sistema una amplia autoridad práctica, describirlo como un asistente inofensivo y esperar que esa descripción resuelva la cuestión. Pero una finalidad debidamente acotada sigue siendo un control. Indica a los usuarios qué pruebas se han considerado, indica a los integradores qué no deben ampliar sin más y indica a los revisores qué cambio reabriría la evaluación. Una finalidad vaga convierte cada pregunta posterior en una discusión sobre lo que se quería decir. Una finalidad acotada permite a una organización preguntarse si sigue haciendo aquello que aprobó.

Esto cobra especial importancia cuando una organización realiza una modificación sustancial. La Ley contiene normas sobre los casos en que un distribuidor, importador, implantador u otro tercero puede convertirse en proveedor, incluidos aquellos en que comercializa un sistema con su propio nombre, realiza una modificación sustancial o modifica la finalidad prevista de forma que el sistema pase a ser de alto riesgo. La aplicación jurídica exacta depende de los hechos y debe comprobarse en cada contexto. La lección operativa es más sencilla: un cambio de integración puede ser un acontecimiento de gobernanza. Trasladar la salida de un modelo de un panel de borrador a una cola de decisiones puede ser a la vez un cambio de producto, un cambio de flujo de trabajo y un cambio de responsabilidad.

El contexto no es un decorado

El contexto de implantación suele tratarse como la parte que llega después del trabajo real: una lista de países, una elección de alojamiento, algunos perfiles de usuario, quizá un diagrama con flechas que conducen obedientes de izquierda a derecha. Pero el contexto da forma al riesgo. El mismo tipo de salida puede ser un inconveniente en un entorno e irrelevante en otro. Una autocompleción errónea en una ayuda a la redacción puede corregirse en la frase siguiente. Una prioridad errónea en un flujo de trabajo de servicios escasos puede decidir qué archivo ve primero una persona. Una puntuación que parece un dato entre muchos puede volverse decisiva si todos los demás datos son lentos, vagos o están ocultos tras otro equipo.

El enfoque de alto riesgo de la Ley refleja esta idea. El artículo 6 vincula la clasificación de alto riesgo a los sistemas destinados a utilizarse como componentes de seguridad de determinados productos o a los sistemas contemplados en el anexo III. El anexo III enumera ámbitos en los que los sistemas de IA pueden ser de alto riesgo porque están destinados a usos específicos, como determinados usos biométricos, infraestructuras críticas, educación y formación profesional, empleo, acceso a servicios y prestaciones esenciales privados y públicos, aplicación de la ley, migración y control de fronteras, y administración de justicia y procesos democráticos. El detalle jurídico importa, pero también la gramática. No dice que un artefacto técnico sea de alto riesgo en abstracto. Dice repetidamente destinado a utilizarse.

El artículo 6 contiene también una matización para determinados sistemas del anexo III: no se considerarán de alto riesgo cuando no planteen un riesgo significativo de daño para la salud, la seguridad o los derechos fundamentales de las personas físicas, incluso por no influir materialmente en el resultado de la toma de decisiones. Los proveedores deben documentar esa evaluación antes de comercializar el sistema o ponerlo en servicio. Esto no es una tarjeta de exención general. Es un recordatorio de que el efecto real del sistema importa. Un análisis útil contiene suficiente detalle para explicar por qué un sistema influye, o no, materialmente en un resultado. Si esa explicación no puede redactarse sin vaguedades, el equipo ha aprendido algo antes del lanzamiento.

El contexto incluye el tiempo. Una recomendación al inicio de una investigación amplia tiene un efecto distinto de una recomendación en el punto en que una persona tiene una única oportunidad de aportar material que falta. Incluye el volumen. Un revisor individual puede cuestionar un resultado cuando llegan cinco casos al día y aceptarlo por defecto cuando llegan quinientos antes del almuerzo. Incluye el idioma. Un revisor que puede leer las pruebas en su propia lengua de trabajo puede ejercer un tipo de supervisión distinto del de un revisor que recibe un resumen contundente de material que no puede inspeccionar de forma independiente. Incluye el procedimiento local, los derechos de recurso, la dotación de personal, el acceso a un especialista, la disponibilidad de un plan alternativo y si un resultado llega a una persona con autoridad suficiente para hacer algo útil.

Nada de eso requiere que un desastre inventado sea real. Es simplemente cómo funcionan los sistemas. Una política formal puede decir humano en el circuito, pero el sistema puede seguir siendo funcionalmente automático si la persona no tiene tiempo, información, autoridad ni vía práctica para discrepar. El artículo 14 de la Ley habla por tanto de una supervisión humana efectiva adecuada a los riesgos, al nivel de autonomía y al contexto de uso. Exige que los sistemas de alto riesgo se diseñen y desarrollen de modo que las personas puedan comprender las capacidades y limitaciones pertinentes, ser conscientes de la tendencia a fiarse automáticamente de los resultados, interpretar correctamente dichos resultados, decidir no utilizarlos, anularlos o revertirlos y detener el sistema de forma segura cuando proceda. Esas son cuestiones operativas. No pueden responderse únicamente con un punto de referencia de un modelo.

Seleccione una postura de despliegue. El modelo permanece igual; la frontera del sistema, la autoridad y las pruebas necesarias no.

Los usuarios forman parte de la superficie de control

Resulta tentador hablar de los usuarios como si estuvieran fuera del sistema, sosteniendo un teclado y haciendo que ocurra la parte humana. Son parte del acuerdo operativo. Sus conocimientos, carga de trabajo, autoridad, incentivos y vías de ayuda determinan qué hace el resultado. Un sistema diseñado para un especialista que puede inspeccionar el material de origen no es automáticamente adecuado para un generalista que se espera que trabaje a buen ritmo. Una herramienta útil para un revisor que puede rechazar una recomendación no es automáticamente adecuada para un colega que solo puede pulsar aprobar o esperar a que otro lo haga.

Esto no significa que una persona usuaria deba cuestionar cada componente en cada ocasión. Esa sería una definición extraña de tecnología útil. Significa que la supervisión debe diseñarse como una tarea real. La persona necesita saber cuándo se utiliza el sistema, cuál es la limitación pertinente, qué pruebas hay disponibles, qué tipo de desacuerdo puede registrar y qué ocurre después de registrarlo. Necesita una autoridad acorde con la responsabilidad. Pedir a alguien que supervise un resultado que no puede pausar, corregir ni encauzar es menos supervisión humana que decoración humana.

El Reglamento otorga a los responsables del despliegue un papel aquí. El artículo 26 exige que los responsables del despliegue de sistemas de alto riesgo adopten medidas técnicas y organizativas adecuadas para garantizar que utilizan los sistemas de conformidad con las instrucciones de uso que los acompañan. Les pide que asignen la supervisión humana a personas físicas que cuenten con la competencia, la formación y la autoridad necesarias, y que supervisen el funcionamiento sobre la base de dichas instrucciones. En determinados casos, también exige que mantengan bajo su control los registros generados automáticamente. Esto no es una petición de tener a una persona experta cerca por si la interfaz se pone nerviosa. Es una exigencia de organizar una práctica de trabajo.

La formación se plantea a menudo como la respuesta completa. No lo es. La formación puede ayudar a una persona a reconocer una limitación, pero no puede crear un registro de origen que la interfaz oculta. No puede crear tiempo que un diseño de colas consume. No puede crear una autoridad que un contrato reserva en otro lugar. No puede reparar una integración que convierte una recomendación prudente en una acción irreversible. Una organización debería formar a las personas, por supuesto. También debería hacer posible, en el sistema que realmente se les entrega, la tarea para la que se las forma.

Hay una prueba útil: describir la acción de la persona usuaria sin usar el verbo revisar. ¿Qué leen? ¿Qué comparación pueden hacer? ¿Qué pueden rechazar? ¿Dónde queda registrado el motivo? ¿Quién lo ve? ¿Qué ocurre con la recomendación tras el rechazo? ¿Puede la persona afectada por el resultado preguntar qué ha pasado? ¿Puede una compañera posterior reconstruir el estado pertinente? Si las respuestas siguen siendo generales, probablemente el diseño de la supervisión también lo sea.

Esa prueba se aplica más allá de los sistemas de alto riesgo. La ley tiene un ámbito y unas fechas específicos; el buen criterio operativo no espera a que una etiqueta de categoría decida si se ha colocado a una persona en un papel meramente performativo. Es perfectamente posible construir una herramienta de bajo riesgo que haga a las personas menos capaces de entender su propio trabajo porque el resultado es demasiado fluido para cuestionarlo. También es posible construir una herramienta limitada que aumente la capacidad de una persona para hacer buenas preguntas porque conserva las pruebas, limita su autoridad y hace visible la incertidumbre. El modelo puede contribuir a cualquiera de los dos resultados. El sistema decide qué resultado tiene un lugar donde materializarse.

Las personas afectadas están fuera de la consola

Muchas de las personas más importantes de un sistema de IA nunca lo tocan. Pueden ser una candidata, un alumno, una trabajadora, un paciente, una pasajera, una residente, una clienta, una solicitante, una prestataria, un testigo o una persona del público. Puede que no sepan que un modelo estaba implicado. Puede que solo experimenten una respuesta que llega rápido, una solicitud que se retrasa, un servicio que deja de estar disponible, una prioridad que cambia o una decisión que parece imposible de entender. Su ausencia de la interfaz no las hace ausentes del sistema.

Esta es una de las razones por las que el marco de riesgo del Reglamento se refiere a la salud, la seguridad y los derechos fundamentales. Dirige la atención a consecuencias que no pueden reducirse a si una colega con sesión iniciada disfrutó de la herramienta. También es el motivo por el que una declaración de finalidad debe nombrar a las personas y grupos sobre los que se prevé utilizar el sistema, como exige el anexo IV. Un sistema construido en torno a una categoría llamada usuario puede ocultar silenciosamente la diferencia entre la persona que maneja la interfaz y la persona que convive con el resultado.

Las personas afectadas cambian las preguntas que un equipo debe plantearse. ¿Hay alguna forma de saber que el sistema tuvo un papel relevante? ¿La decisión se basa en información que puede corregirse? ¿Un idioma, una discapacidad, un dispositivo, una ubicación o una situación administrativa dificultan la participación? ¿El equipo operativo recibe señales de las personas afectadas o solo del panel de control? ¿Una corrección llega a los datos, a la recomendación, a la decisión y a cualquier copia posterior que se basara en ella? Estas preguntas no son una petición para convertir cada sistema en una consulta pública. Son una petición para seguir la consecuencia lo bastante lejos como para ver a la persona al otro lado.

La normativa de protección de datos es pertinente cuando se tratan datos personales, junto con el marco de la Ley de IA. El CEPD y el SEPD lo señalaron claramente en su dictamen conjunto de 2021 sobre la propuesta: la normativa vigente de protección de datos de la UE se aplica al tratamiento de datos personales dentro del ámbito de la propuesta. El análisis jurídico exacto dependerá del tratamiento y de los actores implicados. La lección de gobernanza es sencilla. Un ejercicio de clasificación no puede absorber todas las demás obligaciones. La privacidad, la no discriminación, las obligaciones sectoriales, los requisitos del derecho administrativo, las normas de consumo y los compromisos contractuales no desaparecen porque un equipo haya elaborado un registro de riesgos de buena apariencia.

También hay una cuestión básica de legibilidad. Una persona no necesita convertirse en especialista en aprendizaje automático para entender cómo solicitar una corrección. Pero un sistema no debe usar la complejidad técnica como excusa para imposibilitar la corrección. Una buena vía distingue lo que el sistema registró, lo que una persona decidió, qué pruebas se consideraron, qué sigue siendo incierto y qué aún puede cambiarse. No reclama una precisión que los registros no pueden respaldar. En este ámbito, la honestidad no es solo un tono de voz. Es parte del servicio.

La integración es donde las responsabilidades cambian de manos

A veces los equipos dibujan una arquitectura de IA como una cadena ordenada: modelo, indicación, respuesta, usuario. Los despliegues reales se parecen más a un plano municipal después de que alguien haya recordado las tuberías de servicio. Hay sistemas de identidad, almacenes de recuperación, permisos de herramientas, colas, esquemas, cachés, plataformas de observabilidad, extensiones de navegador, trabajos por lotes, reglas de aprobación, ajustes de retención, proveedores y personas que heredan una tarea porque la anterior se ha ido de vacaciones. El modelo es importante. Rara vez está solo.

Cada integración puede alterar lo que el sistema es capaz de hacer y cómo se propaga un error. La recuperación puede hacer que una salida del modelo parezca fundamentada mientras la fuente está desactualizada, incompleta o mal delimitada. Una llamada a una herramienta puede convertir un borrador en un cambio de estado. Una cola puede convertir una recomendación oportuna en una tardía. Una capa de orquestación puede seleccionar un modelo o una versión de indicación diferente. Una interfaz de usuario puede ocultar la incertidumbre que existe en una capa inferior. Una integración de identidad puede dar a una herramienta útil acceso a material que un usuario no podría abrir de otro modo. Ninguna de estas observaciones acusa a un producto u organización concretos. Describen propiedades ordinarias de los sistemas, que es precisamente por lo que deben documentarse antes de que resulten sorprendentes.

La orientación de la Comisión sobre la IA de propósito general es útil aquí porque sitúa la información en el punto de traspaso. La documentación para los proveedores posteriores pretende ayudarles a comprender las capacidades y limitaciones del modelo, sus tareas previstas, los requisitos técnicos de integración, las especificaciones de entrada y salida y la información sobre los datos de entrenamiento. Esa información es necesaria. Pero no es suficiente. Los equipos posteriores aún tienen que decidir cómo se formula la indicación al modelo, si una salida se muestra con pruebas, qué permisos de herramientas se permiten, cómo se prueba un cambio, qué registros se conservan y si una recomendación puede influir en un flujo de trabajo concreto.

Por eso comprar un servicio de modelo no es comprar una postura de riesgo completa. La documentación del proveedor puede indicar a un equipo que un modelo tiene una limitación conocida o que se evaluó en determinadas condiciones. No puede demostrar que el índice de recuperación del comprador esté actualizado, que el personal del comprador tenga la autoridad necesaria o que una persona afectada tenga acceso a una vía de impugnación. A la inversa, el comprador no puede exigir que el proveedor del modelo conozca todas las políticas locales o los procesos posteriores. Lo responsable no es fingir que una parte puede conocer todo el sistema. Es hacer explícito el límite y mantener la evidencia circulando a través de él.

El artículo 25 ofrece un marcador jurídico útil para esta realidad operativa. Establece las circunstancias en las que una parte distinta del proveedor original se considera proveedor de un sistema de IA de alto riesgo. Entre ellas se incluyen la comercialización del sistema bajo el nombre o la marca de esa parte, la realización de una modificación sustancial o la alteración de la finalidad prevista de forma que el sistema pase a ser de alto riesgo. La disposición es técnica y depende de los hechos concretos; nadie debería autocalificarse a partir de una entrada de blog. Pero su dirección es clara. La integración y el cambio de finalidad pueden alterar quién asume las obligaciones de proveedor. Un acuerdo posterior no es para siempre posterior por el mero hecho de que el modelo original viniera de otro lugar.

Hay una razón institucional para tomárselo en serio. Cuando la responsabilidad cambia en silencio, la seguridad y la reparación se convierten en un juego de ping-pong organizativo. El proveedor del modelo señala al despliegue. El responsable del despliegue señala al modelo. El integrador señala al servicio en la nube. El propietario del servicio señala a una configuración que ya no existe. Las personas afectadas reciben una explicación pulida de lo complejo que es todo. Puede que sea exacta, pero no es una respuesta. El sistema necesita un registro de qué organización es dueña de la pregunta en cada límite, y una vía para que la pregunta viaje cuando la respuesta está en otro lugar.

La documentación debe describir un sistema que aún puede cambiar

La documentación técnica tiene fama de llegar al final de un proyecto con un leve olor a pánico. El Reglamento describe un papel distinto. Para los sistemas de alto riesgo, la documentación técnica debe elaborarse antes de que el sistema se comercialice o se ponga en servicio y mantenerse actualizada. La lista del anexo IV va más allá del comportamiento del modelo e incluye la finalidad prevista, las versiones, la arquitectura del sistema, el desarrollo, los requisitos de datos, la validación y las pruebas, la supervisión humana, la precisión y las medidas de ciberseguridad, la gestión de riesgos, los cambios y el seguimiento posterior a la comercialización. Eso no es un apéndice decorativo. Es un intento de conservar memoria suficiente para que alguien pueda inspeccionar el sistema cuando la reunión de lanzamiento ya sea folklore.

La documentación solo funciona cuando puede mostrar relaciones. Una versión del modelo debe estar conectada a la versión del sistema que la utilizó. Una prueba debe estar conectada a sus condiciones de entrada y a su finalidad. Una política debe estar conectada a un punto de aplicación. Un rol de usuario debe estar conectado a la autoridad que tiene en la interfaz. Una política de registro debe estar conectada al evento que puede reconstruir. Un cambio debe estar conectado a la evaluación que desencadenó. De lo contrario, un equipo tiene una biblioteca de buenos documentos y ninguna forma de responder a una pregunta concreta.

Los registros son un caso similar. El artículo 12 exige que los sistemas de IA de alto riesgo dispongan de capacidades técnicas para el registro automático de eventos durante toda la vida útil del sistema, de forma proporcional a la finalidad prevista. Los registros pueden facilitar la trazabilidad, la vigilancia posterior a la comercialización y la supervisión operativa. No explican una decisión por arte de magia. Un registro puede indicar a un investigador posterior que se invocó una herramienta, que una versión estaba activa o que un revisor hizo clic en un control. Por sí solo, no puede establecer si el revisor comprendió las pruebas, si la fuente de entrada era fiable o si el proceso fue justo. Los registros son valiosos porque ofrecen a una investigación un punto de partida honesto, no porque eliminen la necesidad de juicio.

La vigilancia posterior a la comercialización completa el panorama. El artículo 72 exige que los proveedores de sistemas de alto riesgo establezcan y documenten un sistema de vigilancia posterior a la comercialización de forma proporcional a la naturaleza de las tecnologías y a los riesgos del sistema de IA de alto riesgo. Esto tiene una implicación sencilla para los equipos de despliegue: una versión no es el momento en que el sistema se conoce por completo. La organización necesita una forma de recibir información relevante, distinguir una señal de una conclusión, decidir si el límite de la finalidad prevista sigue siendo válido y realizar un cambio o detener un uso cuando las pruebas lo exijan.

Ese trabajo no es glamuroso. Consiste en identificadores de versión, criterios de publicación claros, un registro de dependencias, una prueba de ruta de reversión, un responsable designado para una limitación y una decisión que siga siendo visible después de que la persona que la tomó cambie de puesto. Consiste en preguntarse si una integración ha cambiado antes de preguntarse si el modelo ha cambiado. Consiste en conservar suficientes pruebas para corregir una consecuencia en lugar de limitarse a explicarla a posteriori. Lo aburrido no es lo contrario de lo ambicioso aquí. Es la parte que hace que la ambición encaje dentro de una institución.

Cómo razonar sobre todo el sistema sin fingir certeza

Un análisis completo no es una búsqueda de una puntuación de riesgo universal. Es una secuencia de preguntas que se vuelve más precisa a medida que un diseño se vuelve más preciso. La primera pregunta es la finalidad: ¿qué se supone que debe hacer este sistema y qué se supone específicamente que no debe hacer? La segunda es la consecuencia: ¿a quién puede afectar, cómo y a través de qué decisión o servicio? La tercera es la autoridad: ¿qué resultado puede alterar un estado, influir en una decisión, establecer una prioridad o cambiar lo que recibe una persona? La cuarta es la evidencia: ¿qué respalda el uso del sistema en este contexto y qué condiciones hacen que esa evidencia sea transferible?

Luego vienen las preguntas incómodas. ¿Qué ocurre cuando el modelo es incierto, incorrecto, no está disponible o se usa fuera de su límite declarado? ¿Qué cambia cuando una fuente está desactualizada o se deniega una herramienta? ¿Qué pasa si un usuario tiene prisa, es nuevo en el puesto o no puede inspeccionar el material subyacente? ¿Qué pasa si una persona afectada solicita una corrección? ¿Qué pasa si una actualización cambia un mensaje, el corpus de recuperación, los valores predeterminados de la interfaz, la versión del modelo o los permisos de un rol? La respuesta es a veces un control técnico, a veces un procedimiento, a veces un uso más limitado, a veces un responsable diferente y a veces una decisión de no desplegar. Una gobernanza que nunca permite esa última respuesta es solo aprobación con un traje más bonito.

Conviene mantener separadas varias afirmaciones. Un hecho confirmado dice lo que el proveedor del modelo documentó o lo que la organización observó en una prueba definida. Una inferencia dice por qué ese hecho puede ser relevante en un flujo de trabajo concreto. Un control propuesto dice lo que el equipo pretende implementar. Un riesgo residual dice lo que queda después del control. Una conclusión jurídica dice lo que se aplica según la ley. Estas cosas no son intercambiables. Un buen documento las etiqueta porque el lector puede necesitar cuestionar una sin descartar las demás.

Por ejemplo, es posible decir: la documentación del proveedor indica que el modelo tiene una limitación concreta; el equipo de despliegue deduce que la limitación podría afectar a un uso especificado; el equipo propone un control de verificación de la fuente; el control aún no se ha probado con la carga de trabajo prevista; y el asesor jurídico debe evaluar el uso resultante conforme a la legislación aplicable. Esa frase resulta menos satisfactoria que una marca verde. Pero es más útil que una marca verde porque no deja ningún misterio sobre qué se ha establecido y qué no.

Los equipos deben tener especial cuidado con la palabra humano. Un rol humano puede ser un control, pero solo cuando tiene una tarea definida, información adecuada, tiempo, formación, autoridad y una vía para actuar. Un rol humano también puede convertirse en una forma de trasladar la culpa a la persona más cercana a la pantalla. La distinción no es filosófica. Es visible en el flujo de trabajo. Si un revisor solo puede aprobar, si el desacuerdo desaparece en un campo de comentarios sin supervisión, o si nadie puede corregir la consecuencia posterior, el sistema no ha ganado una supervisión significativa solo porque una persona haya hecho clic en algo.

La misma cautela se aplica a la transparencia. Un documento extenso puede hacer que un sistema sea describible sin hacerlo cuestionable. Un panel de control puede hacerlo visible sin hacerlo comprensible. Una divulgación puede informar al usuario de que hay IA implicada sin decirle qué puede hacer ante un error. La pregunta útil es práctica: ¿puede la persona pertinente encontrar el límite, la evidencia, el rol responsable y la vía de corrección en el punto donde esas cosas importan? Si no, la información existe en el lugar equivocado para que se produzca la gobernanza.

Una pequeña nota nuestra

En Dweve, nuestro Trust Centre público trata el registro del modelo y la integración posterior como registros relacionados pero separados. Su página de integración posterior indica que los equipos que integran o despliegan Loom necesitan capacidades actuales, límites, interfaces, contexto de evaluación y cambios, mientras que el registro público establece que un modelo es un hilo más en un tejido más amplio de componentes y límites operativos. Esta es una postura documental, no una afirmación de que una página pública clasifique todos los despliegues posibles o demuestre el cumplimiento para un integrador. El propósito de la separación es más modesto: un registro de modelo debe viajar con la integración sin pretender sustituir el análisis del propio sistema del integrador.

Ese es el estándar que merece la pena mantener. Un proveedor de modelos debe poner a disposición información útil. Una organización que despliega o integra el modelo debe describir el sistema real que ha creado: propósito, personas, datos, interfaces, autoridad, supervisión y corrección. Ninguna de las partes debe usar la documentación como un intercambio ceremonial en el que una parte recibe un PDF y la otra recibe la absolución.

La pregunta más difícil suele ser la mejor

Cuando un equipo se pregunta si un modelo es de alto riesgo, puede estar buscando una respuesta rápida a una preocupación razonable. Pero la pregunta más útil suele ser más larga: ¿qué sistema estamos creando a partir de este modelo, con qué propósito, en qué contexto, con qué personas, y qué ocurre cuando falla? Esa pregunta no siempre puede responderse en una sola reunión. Puede revelar que el uso propuesto es más limitado de lo esperado, que la evidencia es incompleta, que un rol de usuario carece de autoridad, que un contrato deja un límite importante sin dueño, o que una integración posterior se ha convertido silenciosamente en el centro del sistema.

Ninguno de esos hallazgos es un fracaso de la innovación. Son las cosas que una institución aprende antes de dar a un sistema el poder de moldear las opciones de otra persona. El enfoque europeo se describe a menudo como un conjunto de obligaciones. También es una disciplina de nombrar: nombrar el propósito, el actor, el contexto, la versión, la persona afectada, la limitación, la evidencia y la vía de intervención. Una vez nombradas, estas cosas pueden probarse, modificarse y cuestionarse. Antes de que se nombren, tienden a reaparecer más tarde como sorpresa.

Un modelo puede ser capaz, estar cuidadosamente documentado y ser valioso. También puede colocarse en un sistema que le exige demasiado, oculta demasiado a sus usuarios o deja demasiado poco margen a una persona afectada por el resultado. La diferencia se crea fuera de los pesos. Ahí es donde vive el trabajo difícil, y donde también está la oportunidad seria: construir sistemas cuya autoridad coincida con su evidencia, cuyos límites sobrevivan a la integración y cuyos operadores aún puedan decir que no.

Fuentes