¿Puede un regulador auditar un objetivo en movimiento?

Sí, pero no pretendiendo que un sistema adaptativo es un objeto estático. Una auditoría necesita un estado capturado, una afirmación acotada, evidencia con...

¿Puede un regulador auditar un objetivo en movimiento?

Una auditoría puede tomar una fotografía

Un objetivo en movimiento no escapa al escrutinio. Solo escapa al tipo de escrutinio que plantea una pregunta intemporal y espera una respuesta intemporal. Esa distinción importa. Los sistemas de IA cambian de varias maneras a la vez. Un proveedor publica una nueva versión del modelo. Un despliegue cambia el prompt o el umbral de decisión. Un corpus de recuperación incorpora un nuevo documento de política. Una regla de identidad cambia quién puede invocar una herramienta. Una herramienta gana un campo, pierde un campo o empieza a devolver un significado distinto bajo el mismo nombre de campo. Un equipo humano cambia su procedimiento. El mundo que suministra las entradas cambia sin pedir permiso al responsable de versiones de nadie.

Nada de esto hace que una auditoría sea inútil. Hace que el objeto de la auditoría sea más preciso. La cuestión no es si una organización puede demostrar que un sistema permanecerá inalterado para siempre. Esa sería una promesa extraña incluso para una calculadora conectada a una base de datos. La cuestión es si la organización puede mostrar qué sistema estaba en funcionamiento en un momento relevante, qué se suponía que debía hacer, qué evidencia respaldaba ese uso, qué condiciones limitaban la evidencia, quién era el responsable de la decisión y qué cambio posterior debería llevar a reabrir la decisión.

Una auditoría puede tomar una fotografía. Solo que no debe llamar al paisaje fotografía. Un registro adecuado identifica el estado que se inspeccionó y conserva la ruta de ese estado al siguiente. Así puede decir algo útil: esta evaluación se refería a este modelo, estos ajustes, este límite de datos, estas herramientas, esta política, este flujo de trabajo y esta decisión de publicación. También puede decir algo menos cómodo y más valioso: la conclusión no viajaba automáticamente al siguiente estado.

Ese es un mejor punto de partida que el conocido teatro de las insignias inmutables. Una insignia sugiere que alguien ha zanjado el asunto. Un registro de auditoría debería permitir ver qué se zanjó, sobre qué base, para qué uso y durante cuánto tiempo esa base siguió siendo aplicable. Un regulador no necesita una organización congelada. Un regulador necesita una organización que sepa distinguir un registro congelado de un servicio en vivo sin tratar a ninguno de los dos como un objeto místico.

Las normas europeas sobre IA ya apuntan en esta dirección. Para los sistemas de IA de alto riesgo, la Ley de Inteligencia Artificial exige documentación técnica antes de que un sistema se comercialice o se ponga en servicio, y exige que se mantenga actualizada. También exige el registro automático de eventos relevantes durante la vida útil del sistema y un sistema documentado de seguimiento posterior a la comercialización proporcional a la tecnología y al riesgo. No son instrucciones para capturar una única captura de pantalla ceremonial. Son instrucciones para mantener un rastro de evidencia a través del cambio.

El objetivo en movimiento suele ser un sistema

Resulta tentador describir un sistema de IA como un modelo y luego hablar de versionado como si un nuevo archivo de pesos del modelo fuera toda la historia. Eso es cómodo para las presentaciones e inexacto para la mayoría de las cuestiones operativas. Un modelo es un componente importante. Rara vez es el objeto completo cuyo comportamiento afecta a una persona, un flujo de trabajo o una obligación legal.

Considere una ruta ordinaria de apoyo a la decisión, descrita aquí como un ejemplo hipotético y no como un relato de un despliegue real. Un usuario envía una solicitud. El servicio recupera documentos que tiene permitido usar. Un modelo redacta una recomendación. Una regla comprueba si la evidencia requerida está presente. Un revisor capacitado puede aceptar, modificar o rechazar la recomendación. Un flujo de trabajo registra entonces una acción. El resultado observado depende de más que el modelo. Depende de las versiones de las fuentes, los ajustes de recuperación, los permisos, la redacción de la interfaz, los umbrales, las reglas de cola, la autoridad humana y el límite de la acción.

Si el corpus de origen cambia, el modelo puede recibir una base fáctica distinta sin que cambie ni un solo parámetro. Si cambia un prompt, puede pedirse al modelo que emita un tipo de juicio diferente. Si una pantalla de revisión deja de mostrar la incertidumbre, la supervisión humana descrita en un archivo de riesgos puede dejar de ser la supervisión que las personas ejercen realmente. Si una integración empieza a aplicar recomendaciones automáticamente, el sistema ha adquirido una nueva autoridad aunque la respuesta del modelo sea idéntica byte por byte.

Por eso un registro de auditoría sensato comienza por la finalidad prevista y el límite del sistema. Los requisitos de documentación técnica de la Ley de IA en el anexo IV incluyen descripciones de la finalidad prevista, las versiones, las funciones de supervisión y control, la validación y las pruebas, la gestión de riesgos, los cambios realizados durante el ciclo de vida y las métricas de rendimiento pertinentes. La cuestión no es que todo sistema necesite una catedral de papeleo. La cuestión es que un revisor no puede evaluar una afirmación cuando el objeto al que se refiere esa afirmación cambia de forma silenciosa.

Llamar sistema al objeto más amplio no es una forma de hacer que el trabajo suene más importante. Es una forma de evitar un error de categoría. Una evaluación de modelo puede responder a una pregunta sobre el modelo. Una auditoría de sistema debe responder a una pregunta sobre el sistema. La primera puede establecer cómo se comportó un componente en condiciones definidas. La segunda debe mostrar cómo se conectó ese componente con personas, datos, reglas, herramientas y consecuencias. Ninguna sustituye a la otra. Una puntuación de modelo no es una descripción del flujo de trabajo, del mismo modo que una buena prueba de neumáticos no es un plan de ruta.

Qué intenta establecer realmente un auditor

Auditar un sistema cambiante no significa reproducir en una sala de reuniones cada momento de su vida. Significa hacer inspeccionables determinadas proposiciones. ¿Se usó el sistema dentro de la finalidad declarada? ¿La decisión de lanzamiento se apoyó en pruebas adecuadas a esa finalidad? ¿Conservó la organización la información necesaria para investigar un resultado impugnado? ¿Los cambios significativos desencadenaron una reevaluación? ¿La supervisión hizo visible la diferencia entre una actualización benigna y un cambio material? ¿Podían las personas responsables pausar, limitar o corregir la ruta cuando las pruebas dejaron de sostenerse?

Son preguntas prácticas porque cada una tiene una contrapartida observable. La finalidad prevista pertenece a un registro. Una evaluación tiene un conjunto de pruebas, una configuración, una población de prueba o un límite de entrada, un método, un resultado y una limitación. Una decisión de lanzamiento tiene un responsable y unas condiciones. Un cambio tiene una identidad, una fecha, un motivo y un efecto evaluado. La supervisión tiene señales designadas, umbrales o desencadenantes de revisión. Una ruta de pausa tiene una autoridad y una operación. Los detalles varían, pero la auditabilidad proviene de convertir las garantías abstractas en cosas que otra persona pueda inspeccionar.

Hay un límite importante aquí. Una auditoría no demuestra que todos los resultados futuros serán correctos, justos o inofensivos. No puede convertir un mundo incierto en uno determinista. Puede establecer si una organización hizo afirmaciones lo bastante acotadas para examinarlas, si recopiló pruebas capaces de respaldar esas afirmaciones y si conservó la capacidad de reconsiderarlas. Puede parecer modesto. También es donde comienza la rendición de cuentas.

La diferencia entre pruebas y lenguaje de garantía importa. Decir que un modelo fue evaluado no es todavía prueba de una evaluación útil. La palabra necesita un objeto. ¿Evaluado respecto a qué tarea, criterios y datos? ¿Con qué modelo y estado del sistema? ¿En qué condiciones de funcionamiento? ¿Quién comprobó el método? ¿Qué quedó fuera del alcance? ¿Qué haría que el resultado quedara obsoleto? Sin estas preguntas, la evaluación es solo un pasado tranquilizador.

Las directrices éticas anteriores de la Comisión Europea para una IA fiable definían la reproducibilidad en términos sencillos: un experimento de IA debería mostrar el mismo comportamiento al repetirse en las mismas condiciones. Es una definición útil porque contiene su propio límite. Las mismas condiciones hacen un trabajo real. Un experimento repetido puede demostrar si la afirmación registrada es reproducible. No puede demostrar que un comportamiento inalterado surgirá tras un cambio en la fuente de datos, la política o la vía de despliegue. Por tanto, la reproducibilidad no es una promesa de que el mundo se detenga. Es una disciplina para decir con exactitud qué fue lo que ocurrió.

Una evaluación capturada es un punto en el tiempo. La auditoría se vuelve duradera cuando el siguiente estado se puede comparar con ella.

Un número de versión es necesario, pero no suficiente

Los números de versión son útiles porque impiden que un registro pretenda que los nombres bastan. Sin embargo, una etiqueta de versión también puede crear una falsa sensación de seguridad. Una etiqueta como versión 4.2 puede identificar una versión de software, pero no identifica necesariamente el estado efectivo de una ruta de IA. Un valor de configuración puede residir fuera del repositorio del modelo. Un índice de recuperación puede reconstruirse a partir de documentos cambiantes. Una característica puede elegir una ruta de herramienta diferente. Un motor de políticas puede modificar una acción permitida. Por lo tanto, un servicio puede tener un número de versión impecablemente formateado y seguir siendo difícil de reconstruir.

Lo que importa es la identidad adecuada a la afirmación. Si la afirmación se refiere a una evaluación comparativa de un modelo sin conexión, el artefacto del modelo, el código de inferencia, los ajustes de parámetros, la versión del conjunto de datos, la definición de la métrica y el entorno de ejecución pueden ser esenciales. Si la afirmación se refiere a un servicio de apoyo a la decisión en vivo, el registro puede necesitar además el mensaje o la plantilla, la configuración de recuperación, los identificadores y la frescura de las fuentes, el estado de los permisos, los esquemas de las herramientas, la versión de la política, la interfaz del revisor y la regla del flujo de trabajo. Un paquete de auditoría no necesita contener cada byte de cada sistema. Necesita contener o señalar de forma fiable los elementos que podrían cambiar el significado de la afirmación.

Por eso un manifiesto suele ser más útil que un archivo volcado en un disco duro. Un manifiesto indica qué artefactos pertenecen juntos, sus identificadores, sus referencias de integridad, sus relaciones y sus condiciones de acceso. Permite al auditor localizar el paquete relevante sin asumir que cada fuente puede copiarse en una carpeta sin restricciones. Algunas pruebas contienen datos personales, detalles sensibles para la seguridad, material con licencia o secretos comerciales. La auditabilidad exige un acceso controlado y una trazabilidad significativa, no la divulgación pública obligatoria de todo lo que hace funcionar un sistema.

El anexo IV adopta un enfoque práctico similar. No trata la documentación técnica como una breve descripción del producto. Solicita información sobre el sistema y su ciclo de vida, incluidos los cambios realizados durante el desarrollo y después de la comercialización, las funciones de supervisión y control, los procedimientos y resultados de validación y pruebas, las medidas de gestión de riesgos y una descripción de las métricas de rendimiento. El documento debe ser lo bastante claro para que las autoridades nacionales competentes y los organismos notificados puedan evaluar el cumplimiento. En otras palabras, la información debe organizarse para su examen, no limitarse a recopilarse porque existía un sistema de almacenamiento disponible.

Detrás de todo esto hay una pequeña pero decisiva cuestión de diseño: ¿qué tendría que cambiar para que las pruebas anteriores ya no pudieran respaldar la afirmación actual? La respuesta crea el límite de versión. Si una nueva fuente de recuperación altera la base fáctica de las recomendaciones, pertenece a la identidad. Si una nueva interfaz de revisión oculta una advertencia, pertenece a la identidad. Si una corrección cosmética de redacción no puede afectar al comportamiento evaluado, probablemente pertenezca al historial de cambios, pero no a la huella de evaluación. Un buen control de versiones no consiste en recopilar al máximo. Consiste en una relevancia razonada.

Capturar el contrato, no solo el resultado

Un resultado es prueba de algo, pero no siempre es prueba suficiente. Una captura de pantalla puede mostrar lo que apareció en una pantalla. A menudo no puede mostrar qué modelo la produjo, qué fuente se recuperó, qué devolvió una herramienta, qué regla se aplicó, qué entradas se omitieron o si la vista ocultaba una advertencia. Esta es una de las razones por las que las capturas de pantalla se acumulan en las carpetas de cumplimiento con la solemnidad de los hallazgos arqueológicos y bastante menos poder explicativo.

Un contrato capturado es más rico. Vincula el resultado con las condiciones en las que se esperaba que actuara el sistema. Para una evaluación, puede incluir el conjunto de pruebas exacto, las entradas o una referencia protegida a ellas, las aserciones esperadas, la configuración del modelo y del servicio, las versiones pertinentes de políticas y herramientas, el entorno de ejecución cuando afecta al resultado y la regla de aceptación. Para una ejecución en vivo, puede incluir la identidad de la solicitud, el ámbito autorizado, los registros de fuente y recuperación, la ruta del modelo, las llamadas a herramientas, los controles, la intervención humana y el cambio de estado resultante. El objetivo no es registrar un diario interminable. Es conservar suficiente información causalmente relevante para poder plantear una pregunta seria más adelante.

Conviene establecer una distinción útil. Una captura de evaluación demuestra una afirmación sobre una prueba o ejercicio definido. Un registro operativo ayuda a reconstruir un evento o decisión concreto. Un registro de publicación explica por qué una organización permitió que un sistema entrara en una ruta definida. Un registro de cambios explica qué se modificó después. Estos registros se solapan, pero no deben confundirse. Tratar un registro de producción como un punto de referencia, o un punto de referencia como prueba de un flujo de trabajo de producción, es una forma eficaz de hacer que cada registro soporte más de lo que puede soportar.

La norma de registro del Reglamento de IA para los sistemas de alto riesgo está igualmente vinculada a su finalidad. El artículo 12 exige el registro automático de los eventos pertinentes durante toda la vida del sistema, con capacidades de registro adecuadas a la finalidad prevista. El Reglamento se refiere a la trazabilidad del funcionamiento del sistema, la supervisión de la operación y el seguimiento posterior a la comercialización. No exige un hábito de registro indiscriminado. Exige registros con una función.

Esa frase, registros con un trabajo, es una guía mejor que una demanda genérica de observabilidad. El identificador del modelo puede ayudar a distinguir una actualización. La procedencia de los datos de entrada puede explicar una recomendación sorprendente. Una versión de regla puede explicar por qué se bloqueó un resultado. Una anulación del revisor puede explicar por qué la acción operativa difiere de la propuesta del modelo. Una marca de tiempo puede establecer el orden. Un diseño consciente de la privacidad aún pregunta si cada campo es necesario, proporcionado, conservado durante un período definido y protegido del propio sistema que se supone que debe inspeccionar.

La reproducibilidad tiene dos formas honestas

La gente suele usar reproducible para referirse a varias cosas distintas. La confusión es comprensible. Un equipo puede querer decir que puede volver a ejecutar una evaluación fija y obtener la misma puntuación. Un investigador puede querer decir que otro equipo puede ejecutar el método indicado e inspeccionar el resultado. Un operador puede querer decir que una investigación puede recrear el estado utilizado para una decisión concreta. Un cliente puede querer decir que un flujo de trabajo ofrece un trato coherente en lugar de cambiar arbitrariamente de martes a jueves. Son objetivos relacionados. No son una sola propiedad con varios disfraces.

Primero, está la reproducibilidad de la ejecución capturada. Si el artefacto, la configuración, las entradas, el estado relevante y las condiciones de ejecución se mantienen fijos, una repetición debería producir el resultado documentado dentro de las condiciones prometidas por el sistema. Algunos sistemas pueden hacer una afirmación determinista más sólida para una ruta de ejecución definida. Otros dependen de aleatoriedad controlada, infraestructura distribuida o servicios de terceros y solo pueden hacer una afirmación más limitada. El lenguaje responsable es específico. Dice qué está fijo, qué se mide, qué variación sigue siendo posible y cómo se realiza la comparación.

Segundo, está la reproducibilidad del argumento de evaluación. Un revisor debe poder ver por qué la suite representa la afirmación, si la métrica tiene el significado indicado, si el umbral de aceptación está justificado y si la evidencia puede trasladarse al contexto operativo. Esto no se resuelve con una suma de verificación. Una suma de verificación puede establecer que un archivo no ha cambiado. No puede establecer que el archivo haya probado la pregunta correcta, que la población fuera adecuada o que una puntuación respalde la decisión asociada a ella.

Las dos formas deberían encontrarse. Una prueba perfectamente repetible que mide lo incorrecto sigue siendo la prueba incorrecta. Un argumento sofisticado vinculado a una ejecución no repetible deja a los revisores sin poder distinguir un hallazgo de una tarde con suerte. El estándar útil no es una demanda abstracta de reproducibilidad perfecta. Es una correspondencia visible entre la afirmación, el método, las condiciones capturadas, el resultado observado y el uso que la organización desea permitir.

La orientación de la Comisión sobre las obligaciones para los proveedores de IA de propósito general también mantiene la evaluación conectada con la documentación y el riesgo. Describe documentación técnica para las autoridades e información separada para los proveedores posteriores, incluidas capacidades, limitaciones e información de integración. Para los modelos de IA de propósito general con riesgo sistémico, el artículo 55 exige una evaluación mediante protocolos estandarizados y herramientas de última generación, incluido un test adversarial documentado para identificar y mitigar riesgos sistémicos. Una evaluación que no puede decir qué se probó, bajo qué condiciones y con qué limitaciones no se vuelve más útil por llamarse estandarizada.

La evidencia tiene una condición de caducidad

La evidencia no caduca porque alguien haya decidido ponerse difícil. Caduca cuando las condiciones que le permitían respaldar una afirmación han cambiado lo suficiente como para que la conexión ya no pueda darse por sentada. Esto es razonamiento ordinario. Una prueba de un diseño de puente no cubre automáticamente un material distinto. Un control de seguridad alimentaria no cubre a un nuevo proveedor por la fuerza del optimismo. Una evaluación de una ruta de IA no debería cubrir automáticamente un modelo cambiado, un límite de datos cambiado, una autoridad de herramientas cambiada o una consecuencia de decisión cambiada.

El trabajo difícil es decidir qué cambios importan. Esto es una cuestión de juicio técnico, análisis de riesgos y gobernanza, no un porcentaje único escrito en una política. Un parche que cambia el color de un botón puede no tener relación con una evaluación. Un cambio que hace que una advertencia sea menos visible puede ser material si el argumento de seguridad depende de que un revisor la vea. Reindexar un corpus fuente puede ser inofensivo para una tarea y crítico para otra. Un nuevo punto final de modelo puede preservar una capacidad amplia mientras cambia la latencia, el comportamiento de rechazo, la cobertura de idiomas o los patrones de uso de herramientas que importan para la ruta.

Un control de cambios útil comienza, por tanto, con una pregunta de impacto, no con un ritual de publicación. ¿Qué afirmación podría verse afectada por este cambio? ¿Qué suposición altera? ¿Qué evidencia dependía del estado anterior? ¿Una comprobación acotada responde a la pregunta, o la ruta necesita una nueva evaluación y una decisión de publicación? ¿Quién puede tomar esa decisión y quién puede impugnarla? Las respuestas deben quedar registradas porque, de lo contrario, el siguiente revisor tendrá que inferirlas a partir de títulos de incidencias, folklore y un ligero cambio en la fuente del panel de publicación.

Aquí es también donde la monitorización pasa a formar parte de la evidencia, en lugar de ser un pasatiempo de observabilidad aparte. El artículo 72 exige que los proveedores de sistemas de IA de alto riesgo recopilen, documenten y analicen de forma activa y sistemática datos relevantes sobre el rendimiento durante toda la vida útil del sistema, para poder evaluar el cumplimiento continuo. El plan de monitorización posterior a la comercialización forma parte de la documentación técnica. La monitorización no es, por tanto, solo una forma de saber si el servicio está ocupado. Es una forma de aprender si las condiciones que respaldaban la afirmación original siguen cumpliéndose.

La monitorización no hace que cada resultado se explique por sí mismo. Un aumento del desacuerdo entre revisores y un sistema puede tener muchas causas. Un cambio en la frescura de la fuente podría reflejar un problema en la canalización de datos, más que una deriva del modelo. Una tasa de rechazo más alta podría representar una política más segura, una integración rota o una nueva población de solicitudes. El registro debe conservar suficiente contexto para una investigación humana. Las métricas son señales. No son testigos.

La evidencia es válida en un contexto definido. Un cambio material plantea una pregunta para la revisión, no una vía para eludirla.

Un cambio material necesita una vía de decisión

La expresión cambio sustancial suele tratarse como si nombrara una propiedad evidente por sí misma. No es así. ¿Sustancial respecto a qué afirmación, qué riesgo y qué usuario? La respuesta debe ser lo bastante concreta como para que la gente pueda usarla cuando está cansada, con prisa y deseosa de calificar un cambio de menor. Una buena política no promete clasificar de antemano todas las actualizaciones posibles. Nombra los factores que determinan si es necesaria una reevaluación.

Esos factores suelen incluir la finalidad prevista, las personas afectadas, la autoridad concedida a la ruta, las fuentes de datos y sus controles de calidad, la arquitectura del modelo o del sistema, el alcance de la evaluación, los umbrales de decisión, las señales de supervisión, la supervisión humana, los controles de seguridad y las vías de recuperación. Una modificación que cambie cualquiera de estos elementos puede ser sustancial o no. Lo que importa es si puede alterar la evidencia necesaria para la afirmación existente o el riesgo que queda después de los controles.

El Reglamento de IA contiene una responsabilidad explícita en torno a la modificación sustancial. Su aplicación jurídica exacta depende del sistema y de los actores implicados, por lo que no debe comprimirse en un eslogan. La lección operativa es más sencilla y más amplia: una organización debe saber cuándo un cambio transfiere o crea responsabilidad, cuándo la documentación existente ya no es adecuada y cuándo el sistema debe evaluarse de nuevo antes de que continúe un nuevo uso. Es menos emocionante que el lanzamiento de una función. También es menos probable que genere una decisión difícil en la que todos coincidan en que el sistema ha cambiado pero nadie asuma la decisión.

Una vía de decisión da a un cambio un lugar al que ir. Una vía puede permitir una constatación documentada de ausencia de impacto. Otra puede exigir una evaluación de regresión específica. Otra puede exigir una revisión de riesgos más amplia, un cambio en las instrucciones de uso, un plan de supervisión revisado o una nueva aprobación de publicación. La vía más grave puede exigir que la ruta permanezca limitada o en pausa hasta que se disponga de evidencia. La cuestión no es encarecer cada edición. Es hacer que la edición importante sea imposible de disfrazar de mantenimiento rutinario.

Hay una satisfactoria ausencia de romanticismo en todo esto. Un registro de cambios puede mostrar el estado anterior, el estado propuesto, las afirmaciones afectadas, la evidencia revisada, la decisión, la autoridad y las condiciones posteriores a la publicación. Eso es gobernanza en su ropa de trabajo. Nunca parecerá tan apasionante como una demostración de modelo. Tiene la propiedad más útil de ayudar a una organización a explicarse cuando una demostración se ha convertido en un servicio real.

La evaluación debe poder fracasar en público, o al menos en el archivo

La evaluación se vuelve performativa cuando se da por hecho que cada resultado es un resultado de publicación. Un programa de evaluación maduro debe poder concluir que la evidencia es incompleta, que no se alcanzó un umbral, que una limitación conocida impide un uso propuesto o que una afirmación debe acotarse. No son excepciones vergonzosas al proceso. Son resultados del proceso.

Esto es especialmente importante para sistemas adaptativos o conectados externamente. Un equipo puede descubrir que una batería de pruebas ya no representa una población de entrada viva. Un contrato de herramienta puede volverse demasiado inestable para respaldar una afirmación de reproducción. Una actualización del modelo puede mejorar una tarea pero dificultar la supervisión de una ruta protegida. Una señal operativa puede mostrar que la transferencia del sistema al revisor falla bajo una carga de trabajo ordinaria. La respuesta correcta no es necesariamente un apagado drástico. Puede ser un límite, un flujo de trabajo revisado, una prueba adicional, una nueva condición de aceptación o la decisión de no hacer la afirmación original.

El registro debe permitir que un revisor vea ese resultado negativo. De lo contrario, una organización construye una máquina muy eficaz para recopilar únicamente la evidencia que le gusta. Los requisitos de gestión de calidad del artículo 17 son relevantes aquí. Cubren, entre otras cosas, técnicas y procedimientos para el diseño, el desarrollo y el control de calidad; examen, prueba y validación; gestión de datos; gestión de riesgos; vigilancia poscomercialización; notificación de incidentes; y comunicación con las autoridades. Un sistema de calidad no es una carpeta que hace desaparecer los fallos. Es una forma de detectarlos, documentarlos y abordarlos.

El mismo principio rige el acceso. Un regulador externo, un organismo notificado o un revisor autorizado puede necesitar evidencia técnica que no puede publicarse abiertamente. Un resumen público puede ser apropiado para otras partes del registro. Son vías de acceso diferentes, no hechos diferentes. El público no debería recibir un relato optimista mientras el registro controlado describe una realidad más limitada y condicionada. La confidencialidad puede ser legítima. La contradicción es un fallo de gobernanza.

En Dweve, nuestro Trust Centre público ofrece un ejemplo pequeño y deliberadamente limitado de esta distinción. Su página de evaluaciones indica que una evaluación identifica el modelo, la suite exacta, la configuración, el estado capturado, la evidencia y la decisión del revisor. También indica que un contrato capturado repetido debería producir resultados idénticos byte a byte en las arquitecturas compatibles, mientras que una reejecución en vivo puede diferir cuando cambia la evidencia externa o el estado adaptativo. La página separa el método público de un resultado de marketing rellenado. Eso no es una prueba de la calidad de un modelo. Es simplemente la forma correcta de una afirmación sobre los registros de evaluación.

La monitorización en vivo no sustituye a una decisión previa al lanzamiento

La monitorización se describe a veces como la respuesta a la incertidumbre: lanzar el sistema, observar el panel, mejorar continuamente. Hay un instinto útil en esa frase. Los sistemas necesitan observación después del lanzamiento porque el despliegue produce información que un laboratorio no puede. Pero la monitorización no puede respaldar retroactivamente una decisión para la que la evidencia nunca fue adecuada. No puede decirle a una persona afectada por una acción de alto impacto defectuosa que la organización aprenderá del gráfico el próximo mes.

La evaluación previa al lanzamiento y la monitorización posterior al lanzamiento responden a preguntas diferentes. La evaluación pregunta si la organización tiene suficiente evidencia para permitir un uso definido ahora. La monitorización pregunta si las condiciones detrás de ese permiso siguen vigentes y si están surgiendo nuevos riesgos o fallos. La primera establece un límite inicial. La segunda observa el límite en funcionamiento. Un sistema creíble necesita ambas, así como una vía para que los datos y el aprendizaje operativo regresen a la evaluación de riesgos, la documentación y el control de cambios.

Ese bucle es lo que convierte un paquete de aseguramiento estático en un registro vivo. Una evaluación proporciona una línea base. Un registro de despliegue indica qué línea base se adoptó. El registro y la monitorización muestran el comportamiento relevante. Un cambio puede alterar la línea base o revelar sus límites. Una revisión actualiza entonces la afirmación, su evidencia, sus restricciones o su estado. El sistema se mueve. El registro se mueve con él, pero no reescribe su propio pasado. Un auditor puede ver tanto la posición actual como el camino por el que llegó allí.

Para los sistemas de alto riesgo, la AI Act es explícita en que la vigilancia poscomercialización debe recopilar y analizar datos de rendimiento relevantes durante toda la vida útil y permitir evaluar el cumplimiento continuo. También exige que los responsables del despliegue supervisen el funcionamiento según las instrucciones de uso e informen al proveedor y a la autoridad competente sin demora indebida cuando tengan motivos para considerar que el uso puede presentar un riesgo. Estos requisitos no eliminan la necesidad de juicio profesional. Dan al juicio profesional registros, desencadenantes y vías.

Existe una tentación organizativa de tratar la supervisión como responsabilidad del equipo de operaciones y la evaluación como responsabilidad del equipo de modelos. Esa división fracasará ante la primera pregunta relevante sobre una ruta en producción. El modelador puede saber por qué se eligió una prueba. El operador puede saber que las fuentes estaban desactualizadas. El responsable de la política puede saber que cambió una regla de decisión. El revisor puede saber que la interfaz genera sesgo de automatización. Un registro de auditoría debe unir sus evidencias sin pretender que una sola persona ve el sistema completo.

¿Puede un regulador reproducir una decisión?

A veces la respuesta debería ser sí, dentro de un alcance definido. Si una organización afirma que una decisión o evaluación puede reproducirse, debe especificar qué significa reproducir. ¿Significa repetir una llamada al modelo con el mismo prompt? ¿Significa reconstruir la secuencia completa de recuperación y herramientas? ¿Significa reconstruir el registro que vio el revisor? ¿Significa validar un cálculo determinista a partir de las entradas conservadas? Cada opción es útil. Cada una tiene requisitos técnicos y legales distintos.

Una reproducción significativa comienza con la identidad conservada. El revisor necesita saber qué versión del sistema y qué configuración estaban vigentes, qué entradas y versiones de fuentes eran admisibles, qué políticas y permisos se aplicaban, qué dependencias externas respondieron y qué acciones humanas alteraron la ruta. Algunos elementos puede que deban almacenarse directamente. Otros pueden referenciarse mediante identificadores estables y reconstruirse a través de sistemas controlados. Lo que no es aceptable es calificar un ejercicio de reproducible cuando depende de una búsqueda web en vivo, una fila de base de datos sobrescrita y un ajuste recordado del portátil de un ingeniero.

Aun así, una reproducción puede reproducir un registro en lugar de repetir el mundo. Una fuente en vivo puede actualizarse o retirarse. Un servicio de terceros puede cambiar. Un servicio adaptativo puede acumular nuevo estado gobernado. Una persona puede emitir un juicio distinto ante la misma información. Estos no son defectos de la idea de reproducción. Son distinciones que el registro debe conservar. La reproducción puede mostrar qué hizo el sistema bajo el contrato capturado. No afirma que el mundo actual sea idéntico a ese contrato.

Por eso los registros de decisiones humanas deben situarse junto a los registros técnicos cuando la supervisión humana forma parte del argumento de seguridad o de derechos. Una auditoría puede necesitar saber que una persona revisó una recomendación, qué información tenía disponible, qué eligió y qué autoridad ostentaba. No necesita convertir a cada revisor en un objetivo de vigilancia ni conservar material personal sin límite. Sí necesita información suficiente para establecer si la supervisión prometida existió en el evento en cuestión.

La reproducción es, por tanto, una escalera, no una jactancia. En un peldaño, el revisor puede identificar la versión. En el siguiente, puede inspeccionar la evidencia. Más arriba, puede recrear una prueba o analizar una ruta de decisión en vivo. La organización debería indicar qué peldaño respalda, dónde están los límites y qué partes requieren acceso autorizado. Una afirmación de reproducción modesta y comprobable es mucho más sólida que una garantía vaga de que todo es trazable.

Las auditorías necesitan registros que discrepen entre sí

El registro público de estado de una organización, el registro interno de versiones, el informe de evaluación, los registros operativos y el registro de incidentes no deberían decir cosas distintas sobre el mismo estado básico. Pero tampoco deberían ser documentos idénticos. Cada uno tiene una audiencia y un propósito diferentes. El registro público puede indicar el propósito previsto, el estado, las limitaciones conocidas y una vía para obtener más información. El archivo técnico puede contener arquitectura detallada, datos, pruebas y controles. El registro operativo puede contener trazabilidad a nivel de evento. El archivo de cambios puede explicar por qué se revisó una conclusión anterior.

La integridad proviene de la correspondencia. Si una página pública dice que una ruta se limita a la recomendación, los registros técnicos y operativos no deberían describir una acción automática. Si una evaluación dice que concierne a un conjunto de fuentes capturado, el registro de publicación no debería aplicarla silenciosamente a uno posterior. Si un registro de cambio dice que una actualización del modelo fue irrelevante, la evaluación de impacto debería indicar la afirmación afectada y la evidencia. Si una señal de monitoreo genera una revisión, la decisión posterior debería ser trazable. Los documentos pueden diferir en granularidad. No deben diferir sobre la realidad.

Esa correspondencia es útil para los reguladores porque reduce la necesidad de confiar en un único artefacto pulido. Un revisor puede comparar registros. Es útil para las organizaciones porque expone la divergencia entre equipos antes de que una auditoría externa lo haga. Y es útil para las personas afectadas porque la explicación pública puede convertirse en una vía real de rendición de cuentas en lugar de una capa decorativa colocada sobre un sistema privado separado.

La arquitectura no tiene que ser elaborada. Una organización pequeña puede usar un registro controlado, documentos con versiones, exportaciones firmadas y revisiones de cambios disciplinadas. Una organización más grande puede usar manifiestos estructurados, registros de solo añadidura, motores de políticas y captura automatizada de evidencia. La cuestión importante es si el método puede conectar de manera fiable la afirmación, el estado, la evidencia, la decisión y el cambio posterior. Un enorme conjunto de herramientas que pierde esta relación es simplemente una forma más cara de ser vago.

Hay una virtud particularmente europea en hacer que el registro sea inspeccionable sin hacerlo teatral. No todas las respuestas pertenecen a un panel público. No toda incertidumbre documentada necesita un icono alegre. Pero cuando una organización ha hecho una afirmación trascendental sobre un sistema adaptativo, debería poder mostrar a un regulador dónde vive esa afirmación, a qué estado se refería y cómo sabría la organización que se ha vuelto obsoleta.

La pregunta de auditoría cambia la pregunta de diseño

Pregunte pronto si un regulador podría auditar el sistema tal como operará realmente. La respuesta cambia las decisiones de diseño mucho antes de que comience una auditoría formal. Favorece identificadores estables sobre etiquetas ambiguas. Favorece versiones de políticas explícitas sobre reglas incrustadas en prosa. Favorece contratos de herramientas que puedan registrarse y probarse. Favorece la procedencia de las fuentes y los marcadores de frescura. Favorece un límite claro entre recomendación y acción. Favorece pantallas de revisión que preserven la información que un revisor necesita. Favorece mecanismos de pausa y recuperación con autoridad nombrada.

También cambia la contratación. La declaración de un proveedor de que un modelo se mejora regularmente no es suficiente cuando el despliegue depende de un estado evaluado definido. El comprador necesita saber cómo se notifican los cambios, qué artefactos pueden identificarse, qué información está disponible para la evaluación de impacto, si los registros históricos siguen siendo interpretables y cómo una ruta puede limitarse o pausarse. Estas no son demandas exóticas. Son los términos prácticos bajo los cuales una organización sigue siendo responsable de un sistema que contiene un componente de proveedor.

La misma pregunta cambia el diseño de la evaluación. Un conjunto útil tiene una identidad y una justificación. Sus entradas o referencias están controladas. Sus métricas y umbrales se definen antes de leer el resultado. Sus exclusiones son visibles. Sus resultados se adjuntan al estado del sistema realmente en discusión. Sus fallos tienen una vía hacia una decisión. Sus condiciones de reejecución son claras. Una evaluación con estas propiedades puede ser cuestionada. Eso es una característica, no un efecto secundario desafortunado de ser minucioso.

Sobre todo, la pregunta cambia el papel del cambio. El cambio deja de ser una molestia que la documentación intenta ocultar. Se convierte en un evento de primera clase en el modelo de evidencia del sistema. Algunos cambios requerirán poco más que un registro. Algunos activarán una prueba. Algunos reabrirán la decisión de publicación. La organización disciplinada no confunde esas categorías, y no necesita un incidente futuro para descubrir que existían.

Así que sí: un regulador puede auditar un objetivo en movimiento. La auditoría comienza rechazando la falsa disyuntiva entre una ficha de modelo congelada y un servicio en vivo completamente incognoscible. Capture el estado. Declare la afirmación. Preserve las condiciones. Vincule la evidencia con la decisión. Registre lo que cambia. Reevalúe cuando el vínculo ya no se sostenga. El objetivo puede moverse. El rastro debe permanecer legible.

Fuentes