El registro de modelos es el nuevo tablón de anuncios público

Un registro de modelos puede informar al público qué es un sistema, quién lo respalda, dónde puede usarse y qué ha cambiado. No puede convertir una entrada...

El registro de modelos es el nuevo tablón de anuncios público

La página que empieza admitiendo que no es magia

Lo primero que hace un registro de modelos útil es decepcionarte. No dice que un modelo sea seguro. No dice que una organización sea competente. No convierte la promesa de un proveedor en un hecho, ni una etiqueta verde en un motivo para dejar de hacer preguntas. En su lugar, te ofrece un registro acotado: esto es la cosa, esta es la versión, este es el propietario, este es el propósito declarado, este es el estado, y aquí es donde se guarda la evidencia de respaldo.

Esa modestia es el comienzo de la confianza pública. Un registro es un tablón de anuncios, no un santuario. Un tablón de anuncios le cuenta a un vecindario qué se está construyendo, quién es responsable de ello y qué avisos se han reemplazado. No certifica la calidad de la obra de cada edificio de la calle. Le da a la gente un lugar por donde empezar a mirar, y una manera de notar cuando el propio aviso se ha quedado obsoleto.

Abra el Registro de Algoritmos del gobierno neerlandés y el diseño es inusualmente sobrio. Las organizaciones gubernamentales publican información sobre los algoritmos que utilizan en su trabajo. El registro se centra en algoritmos de alto impacto, incluidos los sistemas de IA de alto riesgo, y ofrece a los visitantes una explicación de cómo funcionan esos sistemas. La página también hace una distinción útil que muchos catálogos de IA brillantes evitan: un algoritmo es un conjunto de reglas e instrucciones que un ordenador sigue para calcular una respuesta, no una personalidad con lanzamiento de producto.

La página es pública porque el trabajo es público. Un ciudadano no necesita una cuenta privada para descubrir que una autoridad utiliza un algoritmo, para qué dice la autoridad que lo utiliza, o dónde hacer la siguiente pregunta. Eso no hace públicos todos los detalles técnicos. Sí hace que la existencia del sistema, su papel declarado y su propietario institucional sean más difíciles de ocultar detrás de un expediente de contratación.

Los registros de modelos se están convirtiendo en el mismo tipo de objeto cívico. Se sitúan entre un catálogo técnico y un registro público. Los ingenieros necesitan una identidad estable y una versión para integrar. Los operadores necesitan un estado y un propietario para operar. Los proveedores posteriores necesitan capacidades, límites y condiciones. Los auditores necesitan un rastro que los lleve a la evidencia. Las personas afectadas necesitan saber que un sistema existe y cómo impugnar lo que hace. Una sola página no puede responder a todas esas preguntas, pero un registro bien diseñado puede señalar a cada lector la capa adecuada.

El peligro es que la palabra registro haga que un documento suene más completo de lo que es. Una guía telefónica es un registro, pero no puede decirte si un número sigue funcionando. Un manifiesto de embarque es un registro, pero no puede decirte si la carga sobrevivió al viaje. Una ficha de modelo es un registro, pero no puede contener toda la prueba de rendimiento, equidad, seguridad, legalidad y consecuencia social. La pregunta útil no es si un modelo está en el registro. Es qué establece la entrada, qué deja abierto y qué puede inspeccionar a continuación el lector.

Un tablón de anuncios es una promesa de selección

Un inventario intenta contarlo todo. Un catálogo intenta ayudarte a elegir. Un registro hace una promesa más formal: estas entradas pertenecen a un ámbito definido, tienen un propietario, y la información se mantiene bajo una regla. La promesa trata de la selección antes que del software. Sin un ámbito declarado, una lista atractiva es solo una colección de cosas que resultó que se recordaron.

Por eso todo registro necesita una frase que diga qué incluye y qué deja fuera deliberadamente. La base de datos central de la Ley de IA de la UE no es una lista de todos los modelos que circulan por Europa. El artículo 71 establece una base de datos de la UE para sistemas de IA de alto riesgo específicos y para los sistemas que se registran según las vías descritas en el artículo 49. El Registro de Algoritmos neerlandés no es una lista de todos los cálculos que se hacen en una oficina gubernamental. Se centra en algoritmos de alto impacto, incluidos los sistemas de IA de alto riesgo. El límite forma parte del registro, no es una nota a pie de página para abogados.

Un registro de modelos debería responder en lenguaje corriente a la misma pregunta sobre sus límites. ¿Incluye modelos fundacionales, sistemas de IA desplegados, experimentos internos, descendientes ajustados, paquetes de evaluación o solo modelos ofrecidos a usuarios externos? ¿Una nueva configuración de servicio recibe una entrada nueva, una versión nueva o un registro de despliegue vinculado? ¿Un estado capturado de un sistema adaptativo cuenta como la misma identidad de modelo? Si el registro no decide estas cuestiones, cada lector las decidirá de manera distinta. Así es como una lista corta se convierte en una discusión larga.

La selección también da sentido a la ausencia. Si el ámbito dice que deben aparecer todos los sistemas de alto riesgo accesibles públicamente, una entrada que falta es un problema de gobernanza. Si el ámbito dice que solo se incluyen los modelos comercializados, un experimento interno puede ausentarse por diseño. El público no puede interpretar un resultado de búsqueda vacío sin saber cuál de esas dos situaciones se aplica. El silencio no es neutral cuando el registro no ha explicado su vocabulario.

Decirlo con claridad tiene una pequeña virtud administrativa. Los registros no necesitan fingir que lo saben todo. Necesitan decir al lector qué saben, de qué son responsables y qué queda fuera del marco. Un registro gana autoridad al hacer explícito el límite de su ámbito, no al decorar la portada. La tecnología es más nueva. El instinto burocrático no lo es.

Lo que la norma europea pone realmente sobre la mesa

La Ley de IA da a la palabra registro una forma jurídica concreta, pero no una única forma universal. El artículo 49 exige que un proveedor o un representante autorizado registre determinados sistemas de IA de alto riesgo antes de comercializarlos o ponerlos en servicio. También exige el registro cuando un proveedor ha concluido que un sistema no es de alto riesgo en las condiciones del artículo 6, apartado 3. Las autoridades públicas y los organismos públicos equivalentes que despliegan determinados sistemas de alto riesgo tienen su propio deber de registro, incluido el registro de su uso.

El mismo artículo hace explícito el límite entre lo público y lo privado. Determinados sistemas de alto riesgo utilizados en la aplicación de la ley, la migración, el asilo y la gestión de fronteras se registran en una sección no pública y segura. Los sistemas de alto riesgo del segundo punto del anexo III se registran a nivel nacional. No son detalles de implementación que puedan resolverse en un panel de control. Describen públicos distintos, riesgos distintos y permisos distintos para ver el registro.

El artículo 71 dice que la Comisión, en colaboración con los Estados miembros, creará y mantendrá la base de datos de la UE. La información registrada en virtud del artículo 49 debe ser accesible y estar disponible públicamente de forma fácil de usar, y debe ser fácilmente navegable y legible por máquina, con excepciones para las secciones restringidas. La base de datos debe contener datos personales solo en la medida necesaria. Esta es una definición útil de transparencia pública: un registro que las personas puedan encontrar y procesar, sin convertir el registro en un segundo problema de datos personales.

El anexo VIII es donde el tablón de anuncios se vuelve específico. Para un proveedor que registra un sistema de alto riesgo, el registro incluye la identidad y los datos de contacto del proveedor, un nombre comercial o referencia inequívoco, la finalidad prevista, una descripción básica de la información utilizada y la lógica de funcionamiento, el estado del sistema, los certificados pertinentes, los Estados miembros en los que se comercializa o se pone en servicio, la declaración de conformidad, las instrucciones de uso y una URL opcional para más información. No son campos de marketing. Son asideros para la identificación y la rendición de cuentas.

Para un responsable de despliegue público, la información es distinta. El registro incluye la identidad del responsable de despliegue, la persona que presenta la información, la URL de la entrada del proveedor y resúmenes de una evaluación de impacto relativa a los derechos fundamentales y, cuando proceda, de una evaluación de impacto relativa a la protección de datos. La distinción importa porque un proveedor de modelos y una autoridad pública no conocen las mismas cosas ni asumen la misma responsabilidad. Un registro que los fusione en una sola ficha de proveedor borra el punto donde un sistema se encuentra con una institución.

La base de datos jurídica tiene por tanto un carácter estratificado. Registra una identidad de sistema. Registra un proveedor. Puede registrar un responsable de despliegue y un uso. Registra el estado y las declaraciones de respaldo. No sustituye a la documentación técnica, la gestión de riesgos, el sistema de calidad ni la vigilancia poscomercialización que el Reglamento exige en otros lugares. La base de datos es un índice público de hechos sujetos a rendición de cuentas. No es el expediente de cumplimiento completo.

Esta distinción es fácil de perder porque a la gente le gusta una única URL que parezca contener la respuesta. La ley es menos sentimental. Crea una superficie pública, superficies restringidas y vías de documentación controladas. La superficie pública debe ser utilizable. La superficie restringida debe seguir restringida. La documentación debe permanecer disponible para la autoridad competente o el proveedor posterior que la necesite. Un registro serio es una interfaz entre esas obligaciones, no un atajo para evitarlas.

Un registro resulta útil cuando identidad, estado y cambio están conectados. Un color sin transición es solo decoración.

Hay otro límite importante. Las disposiciones sobre IA de uso general del Reglamento de IA no son lo mismo que un catálogo público de todos los modelos de uso general. El artículo 53 exige a los proveedores que mantengan documentación técnica, pongan información a disposición de los proveedores posteriores de sistemas de IA, mantengan una política de derechos de autor y publiquen un resumen suficientemente detallado del contenido utilizado para el entrenamiento. La orientación de la Comisión explica que la documentación técnica es para la Oficina de IA y las autoridades nacionales competentes cuando lo soliciten, mientras que la documentación para proveedores posteriores ayuda a los integradores a comprender capacidades y limitaciones. Solo parte de ese material pertenece a un tablón público.

El Reglamento también exige a la Comisión que publique y mantenga una lista de modelos de IA de uso general con riesgo sistémico. Una lista de modelos con riesgo sistémico es una señal pública valiosa, pero no es lo mismo que un registro completo de modelos. Tiene un propósito más limitado y debe respetar los derechos de propiedad intelectual, la información comercial confidencial y los secretos comerciales. Llamar registro a cualquier lista solo es inofensivo hasta que alguien asume que una lista demuestra más de lo que demuestra.

Un modelo no es una sola línea

La gente habla de un modelo como si fuera un tarro en una estantería. El nombre está impreso en la etiqueta, la versión está sellada debajo y el contenido permanece sin cambios hasta que alguien abre la tapa. Esa imagen funciona para un artefacto estático. Se vuelve poco fiable cuando un modelo se adapta, se ajusta, se envuelve en herramientas, se sirve a través de varias vías o se modifica durante su uso.

Un registro necesita al menos dos identidades: la identidad del modelo y la identidad de lo que realmente se ejecutó. La primera responde a qué modelo se refiere el proveedor. La segunda puede identificar un estado capturado, un paquete de despliegue sellado, una exportación local o un paquete de reproducción. Vincularlas evita dos errores opuestos. Un servicio puede dejar de fingir que cada estado en vivo tiene un único hash permanente, y un operador puede dejar de fingir que un resumen del paquete por sí solo describe toda la familia de modelos.

Los números de versión solo son útiles cuando su regla de cambio es visible. Una versión puede significar un nuevo conjunto de parámetros aprendidos, un nuevo catálogo de restricciones, un cambio en la recuperación, una capa de seguridad modificada o un cambio material en el contrato de servicio. Si un proveedor usa un único número para todo eso, el número se convierte en una forma cortés de decir que algo ha cambiado. Un registro debe vincular un sucesor con su predecesor e indicar qué parte del contrato se ha movido.

El comportamiento adaptativo añade otra complicación. Si un sistema puede cambiar mientras está en uso, el registro debe decirlo. Eso no es admitir que el sistema no está controlado. Es admitir que la palabra versión no puede hacer todo el trabajo. El registro puede mantener una identidad de modelo estable, asociarle estados capturados con límite temporal y documentar las condiciones en las que se creó un estado. La cuestión no es congelar un sistema vivo en una fotografía falsa. Es dar a cada fotografía significativa una fecha y un encuadre.

La identidad también tiene un borde social. Un nombre de modelo no basta cuando varias entidades legales distribuyen artefactos similares, cuando un proveedor posterior modifica el modelo o cuando un producto integra un modelo bajo su propio nombre. El registro debe hacer visible la cadena: proveedor, distribuidor cuando sea distinto, despliegue cuando proceda, y el sistema o la ruta en la que se usa el modelo. Una persona afectada por una decisión no debería tener que hacer arqueología forense sobre un logotipo de producto para descubrir quién puede responder por él.

El estado es un verbo, no un color

Los campos de estado suelen mostrarse como insignias porque las insignias encajan bien en las tarjetas. La insignia no es el estado. El estado es una declaración sobre una acción y un momento. Las pruebas internas significan una cosa cuando el acceso lo controla el proveedor. La versión preliminar significa otra cosa cuando personas externas invitadas pueden usar una ruta en condiciones definidas. En el mercado, en servicio, suspendido, retirado y retirado del mercado conllevan cada uno una consecuencia operativa distinta.

Un registro útil indica qué permite el estado y qué no. Si un sistema es solo interno, el lector no debería inferir disponibilidad pública a partir de una página de documentación. Si se planea una beta externa, la fecha debe etiquetarse como planificada y no presentarse como un lanzamiento. Si un sistema se retira, el registro debe conservar la identidad anterior e indicar si los despliegues existentes pueden continuar, deben detenerse o están siendo migrados. Un estado sin fecha de vigencia es un rumor con uniforme.

El estado también debe tener un responsable. ¿Quién puede mover una entrada de interna a externa? ¿Quién puede suspender una ruta? ¿Quién puede declarar que una fecha de lanzamiento ha cambiado? ¿Qué evidencia se requiere antes de la transición? Esas preguntas pertenecen al proceso operativo, pero la entrada pública debe hacer legible la decisión resultante. Un registro que muestra la insignia actual mientras oculta la autoridad detrás de ella es solo un tablero de inspiración para la gobernanza.

Ejemplo ilustrativo, no un listado real: un registro podría indicar que un modelo está en evaluación controlada, que no hay ninguna ruta externa abierta, que se propone un ensayo solo por invitación para una fecha posterior y que la propuesta sigue sujeta a un control de lanzamiento. El ejemplo no menciona ninguna organización, modelo ni evento. Su propósito es mostrar cómo un registro mantiene un plan separado de un hecho. La misma disciplina se aplica a una retirada, una afirmación de capacidad o una certificación que aún no se ha emitido.

Esta separación protege a los lectores de un truco conocido. Una intención futura se repite con la frecuencia suficiente para empezar a sonar como historia. Los registros deberían ser el lugar donde ese truco deja de funcionar. La entrada puede mostrar un plan, pero el plan debe conservar su etiqueta. Europa ya tiene suficientes calendarios. Una fecha no es un hecho solo porque se haya colocado en un rectángulo de color.

El registro no es la sala de evidencia

Una entrada pública debe ser lo bastante breve para leerse y lo bastante sólida para orientar una pregunta seria. La sala de pruebas que hay detrás puede ser mucho mayor. Las obligaciones de documentación del artículo 53 de la Ley de IA lo ilustran. Los proveedores de modelos de IA de uso general deben elaborar y conservar documentación técnica que abarque el desarrollo, el entrenamiento, las pruebas y la evaluación. Deben poner la información y la documentación a disposición de los proveedores de sistemas de IA posteriores para que estos puedan comprender las capacidades y las limitaciones. Deben publicar un resumen suficientemente detallado del contenido de entrenamiento y mantener una política en materia de legislación de la Unión sobre derechos de autor.

Esas obligaciones sirven a distintos lectores. Una autoridad competente puede necesitar el expediente técnico completo. Un proveedor posterior necesita información de integración y limitaciones. El público necesita una explicación clara de qué es el modelo y de cómo se acota el resumen de su contenido de entrenamiento. Una entrada del registro puede enlazar esas superficies sin dar a entender que una página pública deba contener cada detalle sensible para la seguridad, cada archivo de pesos o cada muestra de prueba con datos personales.

Los enlaces tampoco son pruebas por arte de magia. Un registro que apunte a un informe de evaluación debe indicar qué versión cubre el informe, qué midió la evaluación y qué condiciones limitan el resultado. Un enlace a un resumen de entrenamiento debe indicar si el resumen abarca el preentrenamiento, el ajuste fino o un conjunto definido de categorías de contenido. Un enlace a un certificado debe mostrar quién lo expidió, qué certifica y cuándo caduca. De lo contrario, la página es una estantería de sobres sin abrir.

La misma regla se aplica a las afirmaciones sobre seguridad. Un registro puede decir que existe una evaluación de riesgos, que hay un plan de supervisión enlazado o que se ha publicado una vía para incidentes graves. No debe dar a entender que la existencia de un documento demuestra que el sistema subyacente es seguro. La documentación es una forma de examinar una afirmación. No es un sustituto de la afirmación.

Aquí es donde la escritura pública necesita disciplina. Una ficha de modelo, una página de transparencia o una entrada de registro pueden describir el uso previsto y las limitaciones conocidas. No pueden usar la palabra «fiable» como conclusión salvo que las pruebas y el alcance hagan defendible esa conclusión. La frase honesta suele ser más útil: estas son las condiciones que evaluamos, estos son los límites que observamos y estos son los casos que no afirmamos cubrir.

El registro neerlandés muestra el valor de una lista pública ordinaria

El Registro de Algoritmos neerlandés es instructivo precisamente porque no intenta parecer una sala de control futurista. Ofrece a las organizaciones gubernamentales un lugar público para describir los algoritmos que usan en su trabajo. Su página en inglés advierte de que las descripciones se han traducido automáticamente y de que el original neerlandés es la versión autoritativa de la descripción. Esa pequeña nota es una lección de procedencia. El acceso no es lo mismo que la exactitud, y una interfaz traducida no debe borrar la lengua de origen.

La finalidad pública del registro también se expresa sin lenguaje teatral. Se centra en algoritmos de gran impacto, incluidos los sistemas de IA de alto riesgo, y ofrece a los visitantes una visión de cómo funcionan. El visitante puede consultar algoritmos, organizaciones y plantillas. El objetivo no es ofrecer una puntuación para cada algoritmo. Es hacer que el uso de sistemas algorítmicos sea lo bastante visible para que las personas, las organizaciones y los medios puedan seguir, cuestionar y examinar la práctica gubernamental.

El Algoritmekader neerlandés que lo acompaña convierte esa finalidad en un requisito. Dice que, salvo que se aplique una exclusión, los organismos públicos publican en el registro los algoritmos de gran impacto y los sistemas de IA de alto riesgo. También dice que una publicación incorrecta o incompleta puede dificultar que las personas afectadas y otras partes interesadas comprendan y cuestionen el uso de una tecnología que puede afectar a sus derechos. La transparencia no es, por tanto, solo una cortesía. La calidad de la entrada puede afectar a la calidad del control público.

La misma guía es cuidadosa con el alcance. Describe el registro como una herramienta dentro de un conjunto más amplio de leyes y requisitos, y advierte de que el marco no está completo y puede no incluir legislación específica del sector. El hecho de que un algoritmo aparezca en un registro no resuelve todas las cuestiones legales o éticas. El hecho de que no aparezca no demuestra que sea inofensivo. El lector necesita la regla de inclusión del registro y el marco circundante para interpretar la entrada.

Ese es el patrón útil para los registros de modelos. Una lista pública debe ser fácil de encontrar, estar escrita para personas que no estuvieron en la reunión de contratación y estar conectada con los registros que contienen más detalle. Debe exponer la incertidumbre en lugar de ocultarla. Debe indicar cuándo una descripción en inglés se ha traducido automáticamente. Debe explicar qué sistemas están incluidos y cuáles no. Debe convertir una entrada ausente o desactualizada en un problema de gobernanza visible, en lugar de una decepción privada.

No hace falta inventar un incidente dramático para ver por qué esto importa. Un ciudadano que intenta entender un proceso gubernamental automatizado ya tiene una pregunta práctica: ¿se está usando un sistema, por quién, con qué propósito y bajo qué explicación? Un registro da a esa pregunta una dirección. La respuesta puede seguir siendo incompleta. Al menos la institución no puede fingir que no hay dónde preguntar.

Público no significa desnudo

La transparencia se vuelve contraproducente cuando se trata como una orden de publicarlo todo. Los registros públicos pueden exponer datos personales, información sensible para la seguridad, detalles de propiedad intelectual y vías de ataque. También pueden crear una falsa confianza al publicar fragmentos técnicos que ningún lector común puede interpretar. El límite entre lo público y lo privado debe diseñarse, documentarse y revisarse, no improvisarse por el equipo que casualmente gestiona el sistema de gestión de contenidos.

La Ley de IA ofrece un ejemplo legal. El artículo 49, apartado 4, sitúa determinados sistemas en una sección segura no pública y limita el acceso a la Comisión y a las autoridades nacionales pertinentes. El artículo 71 hace pública la información registrada en virtud del artículo 49, salvo las secciones restringidas, mientras que la información registrada en virtud del artículo 60 solo es accesible para las autoridades de vigilancia del mercado y la Comisión, salvo que el proveedor consienta el acceso público. La publicidad es, por tanto, una regla con excepciones, no un valor por defecto universal.

El artículo 53 establece una distinción similar para los modelos de propósito general. Los proveedores deben poner la documentación técnica a disposición de la Oficina de IA y de las autoridades nacionales competentes cuando lo soliciten, y deben facilitar la documentación posterior a los proveedores integradores. Las obligaciones están explícitamente sujetas a la necesidad de respetar y proteger los derechos de propiedad intelectual, la información comercial confidencial y los secretos comerciales. Un registro no debe obligar a un proveedor a publicar el material que la ley dice que debe controlarse. Tampoco la confidencialidad debe convertirse en una excusa cortés para ocultar la existencia, el propósito o el estado de un sistema que afecta al público.

Un registro de modelos práctico puede usar capas. La capa pública identifica el modelo, el proveedor, el estado, el propósito previsto, las capacidades generales, los límites conocidos, las vías de acceso, las condiciones de publicación, los enlaces a las pruebas y el historial de cambios. Una capa controlada contiene documentación técnica detallada, modelos de amenazas, material de evaluación restringido, detalles de incidentes y otra información que los revisores autorizados necesitan. Una capa operativa privada contiene secretos, datos personales e información de control interno que no debe exponerse en absoluto. Las capas son registros distintos con enlaces, no una sola página con un acordeón etiquetado como transparencia.

La buena transparencia tiene un límite. Publica lo que las personas necesitan para entender el sistema y protege lo que los revisores autorizados deben controlar.

La capa pública debe seguir siendo específica. Puede decir que un modelo es adaptativo durante su uso sin exponer una representación privada de su estado. Puede afirmar que una ruta es solo por invitación sin publicar los tokens de invitación. Puede describir las modalidades de salida y una política de marcado de contenido sin exponer las claves de firma. Puede indicar que existe una evaluación de riesgos e identificar su alcance sin publicar un diagrama de seguridad que facilitaría el ataque al servicio.

La capa controlada necesita su propia honestidad. Un documento marcado como confidencial no es automáticamente completo, actual o correcto. Necesita un propietario, una versión, una regla de acceso y una regla de retención. Si un registro público enlaza a un registro controlado, el enlace debe revelar su estado y la ruta responsable incluso cuando el contenido esté restringido. De lo contrario, el público ve un agujero negro y se le pide que lo llame gobernanza.

El versionado es donde un registro se vuelve útil

La mayoría de los fallos de los registros no son dramáticos. Son pequeños actos de olvido. Un modelo nuevo reemplaza a uno antiguo, pero la entrada se edita en el mismo lugar. Una política cambia, pero el párrafo de uso previsto permanece. Un proveedor mueve una ruta de pruebas internas a una beta externa, pero la insignia de estado cambia antes de que se registre la fecha de vigencia. Un despliegue se retira, pero la entrada antigua desaparece, llevándose el historial con ella. El presente parece ordenado. El pasado se vuelve imposible de responder.

Un registro versionado mantiene al menos cuatro relojes separados. La versión de contenido indica qué texto y campos del registro están vigentes. La fecha de vigencia indica cuándo se aplica la declaración. La versión del modelo o paquete indica qué objeto técnico se está describiendo. La fecha de verificación indica cuándo alguien revisó el registro. Estas fechas pueden coincidir. No tienen por qué hacerlo. Tratarlas como una sola fecha es conveniente y a menudo incorrecto.

Las versiones anteriores deben seguir siendo localizables bajo una regla de retención adecuada. El público no necesita cada edición interna, pero sí necesita saber cuándo cambió una declaración material de propósito, estado, ruta, limitación o propiedad. Un registro de cambios puede indicar qué se movió sin exponer información privada. Un registro legible por máquina puede enlazar la versión anterior y un manifiesto. Una página legible por humanos puede explicar la consecuencia en lenguaje ordinario. Las dos superficies deben coincidir.

El versionado también hace que la retirada sea significativa. Si un modelo se retira porque una ruta se cierra, eso es diferente de una retirada por un defecto grave o un problema legal que requiere acción. Si un modelo permanece en despliegues privados existentes, el registro público debe decirlo. Si un sucesor es compatible solo con algunas integraciones, el límite de migración debe ser visible. Un registro que elimina un nombre sin registrar el motivo deja que cada lector posterior invente una razón.

El historial de cambios es especialmente importante para los sistemas adaptativos. La identidad del modelo puede permanecer estable mientras cambian los estados capturados, los conjuntos de restricciones, las fuentes de recuperación o los controles de salida. El registro puede indicar qué cambios crean un paquete nuevo, qué cambios requieren una evaluación nueva y qué cambios permanecen dentro del límite de identidad declarado. Esto no es detalle excesivo. Es la diferencia entre un sistema que puede reproducirse y un sistema que solo puede recordarse.

Los propietarios forman parte del registro

Una entrada de registro de modelos sin propietario es un parte meteorológico. Te dice cómo estaba el cielo y te deja sin nadie a quien llamar cuando el tejado tiene goteras. Los roles de proveedor y de implementador no son lo mismo, y ninguno de los dos debería poder diluirse en la palabra plataforma.

El proveedor es dueño de la identidad del modelo, del historial de desarrollo y de la decisión de publicación dentro de su ámbito. Un implementador es dueño de la decisión de usar un sistema bajo su autoridad, incluidos el propósito local, las salvaguardas, la evaluación de impacto y los controles operativos. Un proveedor posterior puede integrar un modelo de propósito general en un sistema de IA y asumir responsabilidades que el proveedor del modelo no puede ver. Un registro público debería exponer esas relaciones cuando la ley y el riesgo lo exijan.

La información de contacto no es un relleno administrativo. Ofrece a una persona afectada una vía para preguntar quién tomó una decisión, qué versión se usó o cómo se puede solicitar una corrección. Un buzón genérico puede ser adecuado, pero debe conducir a un proceso mantenido. La entrada también debería indicar si el contacto es para soporte técnico, solicitudes de derechos, notificación de incidentes, contratación o rendición de cuentas pública. Una sola bandeja de entrada no puede ser todas las instituciones a la vez, por mucho que se esfuercen los formularios modernos.

La propiedad debería incluir la autoridad para modificar el registro. Si el propietario designado no puede pausar una ruta, corregir un estado o publicar una retirada, la entrada es decorativa. La organización puede tener un propietario legal en otro lugar, pero la brecha operativa persiste. Un buen registro hace visible la responsabilidad antes de que un incidente obligue a la gente a dibujar el organigrama en una pizarra.

Diseñar un registro que la gente pueda leer de verdad

El primer lector de un registro de modelos no siempre es un regulador o un ingeniero. Puede ser un periodista, un responsable de contratación, un funcionario local, un investigador, un empleado al que se le pide usar el sistema, o una persona que intenta entender por qué un servicio automatizado afectó a su caso. La página debería responder a la pregunta común antes de recurrir a vocabulario especializado.

Empieza por la identidad y el motivo de la entrada. Di quién proporciona el modelo, qué versión se describe, qué tipo de objeto es y si se trata de un modelo, un sistema de IA integrado o un registro de implementación. Di si es interno, está disponible para usuarios invitados, está en el mercado, suspendido o retirado. El lector no debería tener que deducir el estado a partir de un botón de descarga.

Luego muestra el propósito y el límite. Indica para qué está pensado el modelo, qué usos quedan fuera de lo declarado y qué decisiones no está autorizado a tomar. Explica si el modelo puede adaptarse durante el uso, si se requiere un estado capturado para la reproducción y si una ruta posterior cambia las condiciones. Una lista de capacidades sin propósito es un menú sin cocina.

Usa la divulgación progresiva. La parte superior de la página debe ser serena y legible. Las secciones más profundas pueden exponer el registro técnico, los métodos de evaluación, el resumen del contenido de entrenamiento, los documentos legales y la evidencia de publicación. Un lector público puede detenerse tras la primera capa. Un auditor puede continuar. Un ingeniero puede descargar una representación estable. Ocultar el detalle no es simplicidad. Es solo una sorpresa que tarda en cargar.

La accesibilidad forma parte de la credibilidad del registro. La página y la representación técnica deberían usar etiquetas claras, navegación con teclado, encabezados útiles y alternativas de texto para las visualizaciones. Las fechas no deberían codificarse solo con color. Una insignia roja no es un estado para un lector que no puede ver el rojo, y un gráfico que no se puede leer sin ratón no es una explicación accesible. Un tablón de anuncios en la plaza no se vuelve público si la rampa termina en el primer escalón.

La legibilidad por máquina importa por una razón distinta. Permite que los investigadores comparen registros, que los organismos públicos construyan inventarios, que los auditores detecten registros obsoletos y que una herramienta posterior verifique que la página y el registro estructurado se refieren a la misma versión. Legible por máquina no significa solo para máquinas. La página para humanos y el registro para máquinas deben compartir identificadores, estado, fechas y enlaces, con una relación de integridad que pueda comprobarse.

Los campos del registro son decisiones

Cada campo indica al lector qué considera la organización que merece la pena conservar. Un campo de proveedor indica quién respalda el modelo. Un nombre y una versión del modelo indican cómo distinguirlo de un sucesor. Un campo de ruta indica dónde se puede acceder a él. Un campo de finalidad prevista indica qué trabajo está dispuesto a describir el proveedor. Un campo de limitaciones indica dónde termina la descripción. El esquema es un documento de gobernanza escrito en pequeños rectángulos.

Los campos de identidad deben ser inequívocos y estables. Pueden incluir el nombre legal del proveedor, el nombre del modelo, la versión, una referencia única y enlaces a un registro canónico. Si el modelo puede ofrecerse a través de varios productos, el registro debe distinguir la identidad del modelo de la superficie de integración. Si un producto contiene varios modelos, la entrada no debe ocultar ese hecho tras el nombre del producto.

Los campos de estado deben incluir el valor, la fecha de entrada en vigor, el motivo o la autoridad de la transición y cualquier sucesor o predecesor. Una fecha meramente prevista debe etiquetarse como prevista. Un registro que no se ha verificado recientemente debe indicarlo. El lector debe poder saber si un modelo está disponible, propuesto, en pausa o histórico sin interpretar un adjetivo inventado por un equipo de marketing.

Los campos de finalidad y alcance deben describir el trabajo en términos que un no especialista pueda entender. Deben nombrar a los usuarios previstos cuando eso importe, los tipos de entradas y salidas implicados y las decisiones o acciones que el modelo puede respaldar. También deben indicar los usos prohibidos o no admitidos. Un modelo que puede generar texto no está autorizado por ello a redactar una decisión de elegibilidad, y un modelo que puede clasificar documentos no está autorizado por ello a clasificar personas.

Los campos de capacidad necesitan condiciones. Las modalidades, los límites de contexto, el acceso a herramientas, la cobertura de idiomas, el comportamiento de adaptación y el marcado de salidas solo tienen sentido cuando se vinculan a una ruta y a una versión. Una capacidad que existe en un experimento interno pero no en la ruta externa no debe presentarse como una característica universal. El registro no es una lista de deseos.

Los campos de datos deben indicar qué recibe el modelo, qué almacena, de qué aprende durante el uso y qué se utiliza para la evaluación, en el nivel que pueda hacerse público sin exponer material personal o confidencial. Los resúmenes del contenido de entrenamiento y las políticas de derechos deben enlazarse cuando sea necesario. Una frase vaga como entrenado con datos diversos no dice casi nada al lector y le pide que aporte una interpretación halagüeña.

Los campos de evaluación deben identificar la pregunta, el método, el límite de los datos, la fecha, el resultado y las limitaciones. La entrada no necesita reproducir todas las tablas, pero no debe mostrar una puntuación sin un denominador ni una prueba sin un propósito. Un buen enlace de evaluación permite al lector ver si la evidencia cubre el uso previsto, un uso cercano o solo una condición de laboratorio.

Los campos de supervisión deben identificar quién puede pausar, anular, revisar e investigar el sistema. Si un modelo solo recomienda, indique qué acción queda en manos de la persona. Si una ruta puede actuar sobre sistemas externos, indique qué permisos y controles se aplican. Si la notificación de incidentes tiene una ruta dedicada, publíquela. La supervisión no es un párrafo sobre mantener a las personas en el circuito. Es un mapa de quién puede hacer qué cuando el sistema es incierto.

Los campos de evidencia e integridad deben conectar la entrada pública con un registro de máquina versionado, un paquete de publicación, una declaración, un paquete de evaluación o un registro de transparencia. Un hash puede establecer que un archivo cambió o no cambió. No puede establecer que el archivo fuera veraz, por lo que el registro debe mantener separadas la afirmación y la comprobación de integridad. La precisión técnica no sustituye al juicio, pero facilita localizar el juicio.

Por último, los campos de cambio deben explicar el historial. Qué cambió, cuándo, por qué, quién lo aprobó, qué rutas están afectadas y si se necesita una nueva evaluación. La entrada debe permitir responder a la pregunta más ordinaria de la sala: qué es diferente respecto al registro que leímos el mes pasado.

Qué puede establecer un registro

Un registro bien mantenido puede establecer que un objeto definido está siendo descrito por un proveedor nombrado bajo una versión de registro concreta. Puede establecer el propósito declarado, el estado, la ruta de acceso y la titularidad. Puede establecer qué documentos de respaldo y registros de integridad puede inspeccionar un lector, y qué información se controla deliberadamente. Puede establecer que se publicó un cambio y que un registro anterior permanece disponible según la regla de retención indicada.

También puede establecer la posición propia de la organización. Si un proveedor dice que un modelo es para apoyo a la decisión y no para denegación automática, la afirmación es un límite público. Si un despliegue dice que se completó una evaluación de impacto, la afirmación plantea una pregunta sobre dónde se puede encontrar el resumen o el registro controlado. Si un proveedor marca una publicación como planificada, la etiqueta impide que el plan se haga pasar por historial.

Estos son datos útiles. Hacen la contratación más precisa, la integración menos especulativa y las preguntas públicas más fáciles de canalizar. También hacen el desacuerdo más nítido. Un lector puede decir que el propósito declarado es demasiado amplio, que el estado está desactualizado, que falta la limitación o que la evidencia de respaldo no cubre la afirmación. Un registro cumple su función cuando hace posible esa crítica.

Qué no puede establecer un registro

Una entrada de registro no puede establecer que un modelo sea preciso para cada usuario, seguro en cada entorno, justo para cada grupo o lícito para cada despliegue. No puede establecer que una autoridad pública siguió el procedimiento correcto solo porque un sistema esté listado. No puede demostrar que un revisor humano entendió una salida, que un interesado tuvo un recurso efectivo o que un incidente se detectaría a tiempo. Esas conclusiones requieren evidencia sobre el sistema en uso, la institución que lo utiliza y las personas afectadas por él.

Tampoco puede establecer que un modelo sea independiente de su proveedor, que una ruta sea soberana porque está alojada en Europa, o que una licencia abierta haga desaparecer la responsabilidad. Titularidad, jurisdicción, cadena de suministro, control operativo y mantenimiento son cuestiones separadas. Un registro puede exponer los nombres y enlaces necesarios para plantearlas. No puede responderlas con tipografía.

Ni puede un registro probar la negativa. Una entrada ausente puede significar que el objeto está fuera de alcance, que se aplica una exclusión, que la publicación va con retraso o que alguien no publicó. El lector necesita una declaración de cobertura clara y una vía para notificar errores. Un tablón público solo es tan fiable como el proceso que detecta cuándo falta un aviso.

Un registro ilustrativo, no un caso de estudio oculto

Lo siguiente es un diseño de registro ilustrativo, no un informe de una organización, modelo o evento real. No utiliza ningún cliente, autoridad pública, fecha de despliegue ni resultado medido. Su propósito es mostrar cómo un lector puede pasar de una entrada pública a una vía de evidencia controlada sin confundir ninguna de las dos capas.

  • Identidad: un nombre de proveedor, un nombre de modelo, una versión y un identificador de máquina estable.
  • Estado: evaluación controlada, con una fecha de entrada en vigor y una nota de que no hay ninguna vía externa abierta.
  • Finalidad: asistencia en el análisis de documentos para personal formado, quedando las decisiones externas automáticas fuera del ámbito declarado.
  • Entradas y salidas: las modalidades representadas, los tipos de material de origen previstos y los tipos de salida que la vía puede producir.
  • Límites: fronteras conocidas de idioma, dominio, actualidad, seguridad y acceso, cada una vinculada a la evaluación o política correspondiente.
  • Supervisión: el rol que puede pausar la vía, el procedimiento de revisión para resultados inciertos y el contacto de incidencias.
  • Evidencia: un resumen público, un registro técnico versionado para revisores autorizados y un manifiesto de integridad para los archivos publicados.
  • Cambio: un enlace al registro anterior, una declaración de qué ha cambiado y la condición que exigiría una nueva evaluación.

Nada en ese registro afirma que el modelo sea bueno. Dice lo que el proveedor está dispuesto a declarar, dónde se aplica esa declaración y cómo otra persona puede comprobarla o impugnarla. Eso basta para un tablón de anuncios. También basta para impedir que gran parte del lenguaje de folleto se cuele sin ser detectado en una decisión jurídica u operativa.

Por qué el estado de prelanzamiento merece respeto

El prelanzamiento no es una versión más débil de lo público. Es un estado distinto. Las pruebas internas pueden respaldar el trabajo de ingeniería y seguridad manteniendo el acceso controlado. Una beta con invitación puede exponer una vía a personas externas conservando las condiciones, el ámbito y el derecho a detenerla. Una publicación pública cambia quién puede confiar en el sistema y qué obligaciones recaen sobre el proveedor, los integradores y los despliegues. El registro debería hacer visibles esas transiciones en lugar de tratar la publicación como una única nota de trompeta.

Un registro de prelanzamiento puede seguir siendo útil para el público. Puede identificar el modelo, el proveedor, la vía prevista, el estado, la evidencia que existe y la que aún está pendiente. Puede indicar que hay una fecha planificada y que el acceso no se ha abierto. Puede publicar el umbral de publicación sin fingir que ya se ha superado. Este es un lugar especialmente bueno para que un registro sea aburrido. Un estado aburrido es más seguro que una ambigüedad emocionante.

En Dweve intentamos aplicar esa disciplina a nuestro propio registro público. En nuestro Trust Centre, el registro de modelos está marcado como prelanzamiento y lista Dweve Loom 1.0 como pruebas internas exclusivas de prelanzamiento a partir del 1 de agosto de 2026. Registra que no se ha producido ninguna publicación externa en esa fecha y lista el 1 de septiembre de 2026 como fecha planificada de acceso al mercado de la Unión para una beta externa con invitación. Planificada es la palabra importante: la entrada no convierte un plan en un acontecimiento.

Nuestro registro público también deja claro que Loom es el único modelo listado allí, que es propietario y no se publica bajo una licencia de modelo de código abierto, y que nuestros productos y herramientas de código abierto con licencia independiente no se presentan como modelos adicionales. Esa frontera evita que un catálogo de productos se confunda con un registro de modelos. También mantiene la declaración pública lo bastante pequeña para poder comprobarla.

Eso es todo lo que necesitamos decir sobre Dweve aquí. Un registro de modelos es útil cuando hace que nuestro propio estado de publicación sea menos halagador pero más preciso. Debería hacer lo mismo para cualquier otra persona.

La frontera entre lo público y lo privado es una decisión de diseño

El registro más sólido no es el que tiene más campos. Es aquel cuyos campos tienen una razón, un responsable y un límite. Los lectores públicos necesitan una identidad estable, un propósito declarado, un estado veraz, una organización responsable, enlaces utilizables y suficientes limitaciones para comprender la afirmación. Los revisores autorizados necesitan pruebas más profundas, detalles técnicos controlados y una vía para inspeccionar incidentes o pruebas sensibles. Los operadores necesitan secretos, permisos y manuales de operaciones que no deberían estar en el tablón de anuncios.

Esas capas deberían coincidir en los hechos que cruzan el límite. Si la página pública dice que una ruta está en pausa, el registro controlado debería indicar quién la pausó y por qué. Si un archivo técnico queda superado, la entrada pública no debería seguir enlazándolo como vigente. Si una evaluación está restringida, la página pública debería seguir indicando su alcance y su estado. El límite debería limitar el acceso al detalle, no crear tres versiones incompatibles de la realidad.

Los lectores deberían poder formular cinco preguntas sencillas y recibir cinco respuestas estables. ¿Qué es este objeto? ¿Quién es responsable de él? ¿Qué puede hacer? ¿Cuál es su estado actual? ¿Qué pruebas y recursos existen cuando se cuestiona la afirmación? Un registro que responde a esas preguntas ya está haciendo trabajo institucional. Un registro que no puede responderlas no debería salvarse con insignias animadas ni con un panel de doce filtros.

Hay una forma optimista de leer el movimiento europeo hacia los registros de modelos y algoritmos. No es que una base de datos vaya a resolver la gobernanza de la IA. Es que las instituciones públicas están construyendo lugares donde las afirmaciones tienen nombres, fechas, responsables y límites. Esos son los pequeños componentes con los que se construyen los grandes sistemas de rendición de cuentas.

El tablón de anuncios tiene que sobrevivir al cambio

Un registro de modelos es el nuevo tablón de anuncios público solo si los avisos siguen siendo legibles después de que cambie el tiempo. La página debe sobrevivir a una actualización del modelo, un cambio de proveedor, un nuevo despliegue, una limitación corregida, una ruta retirada y una pregunta difícil de alguien que no estaba en la sala. Eso implica conservar el historial, etiquetar los planes, enlazar las pruebas y decir lo que el registro no puede demostrar.

El trabajo es menos glamuroso que una página de lanzamiento. También es más duradero. Un registro público que distingue la identidad del modelo del estado del despliegue, el estado de la intención, la documentación de la prueba y los hechos públicos de la evidencia controlada ofrece a las personas algo mejor que tranquilidad. Les ofrece una vía a través del sistema.

Los buenos registros no piden a los lectores que confíen en un color, un número o un nombre famoso. Hacen que la afirmación sea lo bastante concreta para inspeccionarla y que el límite sea lo bastante claro para cuestionarlo. Dejan un rastro hasta las personas que pueden responder, los registros que pueden comprobarse y la decisión que puede cambiarse. Es una idea cívica muy antigua, con un formato de archivo razonablemente moderno.

Pon el aviso en el tablón. Pon las pruebas detrás. Conserva el aviso anterior donde alguien pueda seguir leyéndolo. Luego deja que el público decida qué se gana el registro.

Fuentes