Una pequeña herramienta puede conllevar una gran responsabilidad

El tamaño del modelo es una propiedad técnica. La obligación depende de la finalidad, el contexto, los datos, la autoridad y las personas que rodean al sistema.

Una pequeña herramienta puede conllevar una gran responsabilidad

La ley no pregunta cuán grande es

Abra la Ley de Inteligencia Artificial de la Unión Europea y no encontrará un contador de modelos. No hay una primera página en la que una máquina se pese, se mida y se coloque en un cajón jurídico ordenado. La Ley comienza con un sistema: un sistema basado en máquinas que opera con distintos niveles de autonomía, puede adaptarse tras su despliegue e infiere de las entradas cómo generar predicciones, contenidos, recomendaciones o decisiones que pueden influir en un entorno físico o virtual. Su definición trata de lo que el sistema hace y de lo que sus resultados pueden cambiar.

Ese es un buen punto de partida porque la conversación tecnológica insiste en que el tamaño haga el trabajo del contexto. Un modelo más pequeño parece modesto. Puede caber en hardware ordinario, responder a una pregunta concreta o devolver una etiqueta en lugar de un párrafo. Esas pueden ser propiedades valiosas desde el punto de vista técnico. Pueden reducir la superficie que hay que probar, disminuir el apetito de recursos de un despliegue o facilitar la sustitución de un componente. Ninguna de ellas nos dice si una persona puede perder un derecho, un servicio, un empleo o una ruta segura por culpa de la etiqueta.

La obligación aparece en la relación entre un sistema y el mundo que lo rodea. Quién usa el resultado. Qué decisión se deriva. Qué datos entran en el recorrido. Cuánta autoridad tiene el sistema. Puede una persona impugnar el resultado. Puede alguien revertirlo antes de que el daño se vuelva duradero. Depende la persona afectada del resultado, quizá porque no existe una alternativa práctica. Un modelo puede ser técnicamente pequeño e institucionalmente grande. Esa es la tesis de este artículo, y la palabra institucionalmente hace el trabajo pesado.

No se trata de tratar a todo clasificador como una emergencia pública. Se trata de proporcionalidad. La proporcionalidad no significa que los sistemas pequeños reciban una sonrisa ceremonial y ninguna pregunta. Significa que las preguntas siguen la consecuencia real. Un modelo usado para ordenar una colección privada de notas y un modelo usado para decidir quién recibe escrutinio pueden parecer similares en un repositorio. No son similares en el mundo.

El tamaño del modelo describe un componente. La finalidad, las personas afectadas y el control determinan la obligación que conlleva ese componente.

Pequeño es una medición, no un contexto

Pequeño puede significar varias cosas distintas, y a menudo se intercambian esos significados sin decirlo. Puede significar menos parámetros, una huella de memoria más reducida, menos cómputo de entrenamiento, un vocabulario restringido, un esquema de salida limitado o una ventana de entrada corta. Puede significar que un modelo se ejecuta en un dispositivo en lugar de a través de un servicio remoto. También puede significar que un equipo ha asignado al modelo una tarea acotada. No son lo mismo. Un número de parámetros diminuto no implica un papel social diminuto, del mismo modo que un número elevado de parámetros no te dice dónde se le permite actuar al sistema.

Hay una segunda confusión. La gente usa pequeño para referirse a local, y local para referirse a inofensivo. El despliegue local puede mejorar el control sobre el movimiento de datos, la disponibilidad o la propiedad operativa. También puede situar una decisión directamente dentro de un lugar de trabajo, un mostrador público, un flujo de trabajo médico o un dispositivo del que una persona no puede alejarse fácilmente. La proximidad física puede reducir un tipo de dependencia mientras aumenta la importancia de las personas que operan el sistema. Un servidor en el mismo edificio no es una categoría moral.

Luego está pequeño como promesa sobre la capacidad. Un componente puede estar entrenado para una tarea y aun así influir en un proceso más amplio. Puede limitarse a devolver aprobar, revisar o rechazar. El flujo de trabajo posterior puede tratar esas tres palabras como una compuerta. El componente no necesita escribir un ensayo para tomar una decisión significativa. Solo necesita estar colocado donde el siguiente sistema, o la siguiente persona, no pueda cuestionarlo fácilmente.

Para la gobernanza, la unidad útil no es, por tanto, el modelo solo. Es el modelo tal como se despliega, con un propósito, un operador, un límite de entrada, un contrato de salida, una acción posterior y una vía de corrección. Eso es menos ordenado que una tabla de clasificación. También está más cerca de la realidad. La tabla de clasificación puede decirte cómo se desempeñó un modelo en una tarea. No puede decirte si esa tarea estaba permitida, si las personas afectadas pudieron objetar o si la organización tenía autoridad para usar el resultado.

El lenguaje de la Comisión Europea en torno a la IA de propósito general ilustra discretamente esta distinción. La Comisión ofrece criterios técnicos para ayudar a identificar cuándo un modelo puede estar sujeto a las obligaciones de la IA de propósito general, pero también señala que los criterios son indicativos y que sigue siendo necesaria una evaluación caso por caso. La guía no pretende que un solo número pueda describir todos los papeles que un modelo podría desempeñar. Intenta hacer viable una pregunta de clasificación sin convertirla en una teoría universal del daño.

El umbral no es el veredicto

Hay números en la Ley de IA, y esa es una de las razones por las que la gente recurre a los números cuando quiere certeza. El artículo 51 crea una presunción de capacidades de alto impacto para un modelo de IA de propósito general entrenado con una cantidad acumulada de cómputo superior a 1025 operaciones de coma flotante. Esa presunción pertenece a la clasificación de los modelos de IA de propósito general con riesgo sistémico. No es una regla que afirme que un modelo por debajo del umbral sea seguro, ni una regla que afirme que todos los modelos por encima causen el mismo daño.

La guía de la Comisión sobre la IA de propósito general utiliza un umbral indicativo diferente, por encima de 1023 operaciones de coma flotante junto con una amplia capacidad generativa, para ayudar a identificar modelos que pueden ser de propósito general. La página es explícita sobre los límites. Un modelo por debajo del indicador puede seguir cualificando si muestra una generalidad significativa. Un modelo que lo cumpla puede excepcionalmente no cualificar si carece de la generalidad pertinente. La guía es una interpretación para una cuestión jurídica concreta, no un permiso para todos los usos posteriores.

Estos dos umbrales son útiles precisamente porque son estrechos. Ayudan a las autoridades y a los proveedores a clasificar un tipo concreto de obligaciones sobre los modelos. No resuelven si un modelo pequeño integrado en un sistema de alto riesgo merece atención. No resuelven si el tratamiento de datos es lícito. No resuelven si una persona puede impugnar una decisión. Un umbral puede establecer que debe plantearse una pregunta. No puede responder a la pregunta que pertenece a otra capa.

Los umbrales técnicos también envejecen. La Ley establece que la Comisión puede ajustar el umbral de riesgo sistémico en función de la evolución tecnológica, incluidos los avances algorítmicos y la eficiencia del hardware. La orientación de la Comisión señala que su propio criterio no es absoluto. Es una admisión sensata. Una cifra que parece estable en una hoja de cálculo de contratación puede variar cuando cambia la tecnología circundante. La respuesta responsable no es desconfiar de toda cifra. Es mantener la cifra vinculada a la pregunta para la que fue diseñada.

Hay una lección práctica para los equipos que publican fichas de modelos o notas internas de arquitectura. Indiquen el umbral, la unidad, la disposición legal y el límite. Digan si una cifra es una presunción legal, un indicador de la Comisión, una condición de referencia o un objetivo de diseño interno. No permitan que una métrica adquiera un significado más amplio porque resulta cómoda en una presentación. Una métrica pequeña también puede conllevar una obligación grande. La cifra necesita su propia procedencia.

Un sistema es más que el modelo que contiene

La Ley de IA hace visible el límite del sistema. Define a los proveedores y a los responsables del despliegue, separa los modelos de los sistemas y asigna obligaciones a lo largo de la cadena de valor. Un proveedor puede ser la persona u organización que desarrolla un sistema, o que encarga su desarrollo y lo comercializa o lo pone en servicio bajo su propio nombre. El responsable del despliegue es la persona u organización que utiliza un sistema bajo su autoridad. Estos roles importan porque el mismo componente subyacente puede encontrarse en disposiciones distintas con responsabilidades distintas.

Imaginen un clasificador de texto compacto que devuelve una de cuatro categorías. El modelo no tiene interfaz de usuario, ni memoria, ni capacidad para invocar una herramienta. En un contexto, clasifica los documentos del propio equipo en carpetas. En otro, etiqueta solicitudes para un servicio público de modo que algunas personas sean sometidas a un escrutinio adicional. El componente puede ser técnicamente idéntico. El segundo sistema tiene una finalidad distinta, afecta a personas distintas, establece una relación de poder distinta y plantea una necesidad distinta de explicación y reparación.

Las normas de clasificación de alto riesgo de la Ley atienden a ese tipo de diferencia. Se fijan en si un sistema es un componente de seguridad, si se utiliza en un ámbito enumerado en el anexo III y si plantea un riesgo significativo para la salud, la seguridad o los derechos fundamentales. La vía de los usos enumerados no es un juicio sobre la elegancia del modelo. Es un juicio sobre lo que el sistema hace en un contexto en el que una salida errónea puede importar. Una tarea procesal limitada puede acogerse a una excepción redactada con cuidado cuando no influye materialmente en una decisión, pero el proveedor debe documentar esa evaluación.

Ese requisito de documentación es fácil de subestimar. Un equipo que afirma que el sistema es solo preparatorio ha hecho una afirmación sobre la causalidad. Está diciendo que la salida no influye materialmente en la decisión posterior. Si el revisor trata la etiqueta como un motivo para abrir un expediente, si el personal se remite a una clasificación, o si un solicitante no tiene una vía significativa para corregir los datos que sustentan la marca, la influencia práctica puede ser mayor de lo que sugiere la interfaz. La palabra preparatorio no puede significar invisible.

Los límites del sistema también incluyen la maquinaria poco vistosa que rodea a un modelo: la fuente de datos, el umbral, la cola, la persona que recibe el resultado, el registro que se conserva, el contrato con el proveedor, el proceso de actualización y la vía para detener el flujo de trabajo. Un modelo pequeño puede ser el objeto visible mientras que el riesgo real reside en la transferencia. Por eso, una revisión de riesgos que solo pregunta qué predice el modelo es incompleta. La pregunta más difícil es qué hace la organización porque el modelo lo predijo.

El propósito cambia el significado de la misma salida

Una salida no tiene obligación alguna en el vacío. La misma probabilidad, categoría o recomendación puede ser benigna en una tarea y de gran trascendencia en otra. Esto no se debe a que las palabras cambien su significado en el diccionario. Se debe a que una salida entra en una estructura de decisión. Una clasificación que se usa para elegir qué notas de investigación leer primero no es lo mismo que una clasificación que se usa para decidir qué hogar recibe una investigación por fraude. La máquina puede usar las mismas matemáticas. La institución no tiene la misma relación con las personas al otro lado.

El artículo 7 del Reglamento de IA enumera los criterios que la Comisión debe considerar al añadir o modificar casos de uso de alto riesgo. Entre ellos se incluyen la finalidad prevista, la amplitud con la que se utiliza o es probable que se utilice el sistema, la naturaleza y la cantidad de datos, la autonomía y la posibilidad de intervención humana, el alcance y la intensidad de los posibles daños, la dependencia del resultado, el desequilibrio de poder, la vulnerabilidad, la reversibilidad, los beneficios y la disponibilidad de recursos. Leídos en conjunto, esos criterios constituyen una refutación útil al pensamiento centrado en el tamaño del modelo. Describen una relación, no un archivo de pesos.

El componente sigue siendo pequeño mientras que la finalidad, el poder, la dependencia y la reversibilidad circundantes cambian la cuestión del control.

La dependencia es especialmente importante. Una persona a veces puede ignorar una recomendación, buscar otro servicio o pedir a un colega que verifique la respuesta. También puede ocurrir que una persona no tenga una alternativa práctica. Si un paso de selección automatizado determina si un servicio se retrasa, si una solicitud recibe atención o si se convoca a un trabajador a una reunión, la persona afectada puede tener que aceptar la primera interpretación del sistema mientras la organización decide si vuelve a revisarlo. Cuanto más pequeña es la decisión visible, más fácil puede ser pasar por alto la dependencia que hay debajo.

La reversibilidad importa por la misma razón. Un error tipográfico en una etiqueta interna puede repararse antes de que nadie dependa de ella. Una marca de riesgo puede alterar el orden en que se tramita un caso, y la demora puede volverse en sí misma relevante. Una denegación puede provocar que se incumpla un plazo. Una clasificación puede convertirse en la única clasificación que vea un equipo ocupado. El hecho de que un administrador pueda técnicamente editar una base de datos no demuestra que el resultado social sea fácil de revertir. La reversibilidad técnica y la reversibilidad vivida están relacionadas, pero no son idénticas.

Aquí es donde la proporcionalidad tiene sustancia. Una sugerencia interna de bajo impacto puede necesitar un registro ligero y un responsable claro. Un sistema que influye en el acceso a un servicio público necesita una vía de evidencia más sólida, una ruta humana informada y una forma de impugnar tanto la entrada como la salida. Los controles proporcionados no son la ausencia de controles. Son controles seleccionados porque la relación los merece.

Los datos conservan sus obligaciones

El tamaño del modelo no hace que los datos sean anónimos por atmósfera. El Dictamen 28/2024 del Comité Europeo de Protección de Datos afirma que si un modelo de IA puede considerarse anónimo debe evaluarse caso por caso. La prueba en el resumen público del CEPD pregunta si es muy improbable que el modelo pueda identificar directa o indirectamente a las personas cuyos datos se usaron para crearlo, y si es muy improbable que sus datos personales puedan extraerse mediante consultas. Un modelo más pequeño puede contener menos información, pero menos no es una conclusión legal.

El CEPD también mantiene a la vista el contexto en torno al interés legítimo. Su análisis apunta a la necesidad y al equilibrio, y enumera la relación entre las personas y el responsable del tratamiento, la naturaleza del servicio, el contexto en el que se recopilaron los datos, la fuente, los posibles usos posteriores y lo que las personas podrían esperar razonablemente. Esos factores no desaparecen cuando un modelo se comprime, se destila, se cuantiza o se coloca detrás de una API pulcra. La compresión cambia un objeto técnico. No reescribe la historia de por qué se recopilaron los datos ni de qué se informó a las personas.

Hay una disciplina útil en leer ese dictamen junto con la ingeniería de modelos. Pregunte para qué se entrenó o adaptó el modelo, qué datos recibe en tiempo de ejecución, qué registros se conservan y quién puede consultarlo. Luego pregunte qué ocurre aguas abajo. ¿Se copia la salida en un expediente del caso? ¿Una clasificación se convierte en una instrucción? ¿Un revisor humano ve el material de origen o solo la etiqueta del modelo? ¿Existe una vía para que la persona afectada corrija un error fáctico? Estas son cuestiones de datos y gobernanza, no meramente cuestiones de precisión.

El resumen público del CEPD también señala que el uso de datos personales tratados ilícitamente en el desarrollo de un modelo puede afectar a la licitud del despliegue, a menos que el modelo haya sido debidamente anonimizado. Esa frase resiste una vía de escape familiar. Un equipo no puede hacer desaparecer un problema diciendo que el modelo final es pequeño, que los datos ya no son visibles o que el modelo es solo un componente. La historia legal y ética de los datos sigue siendo parte de la historia del sistema.

Para los ingenieros, esto significa que el registro de entrenamiento y el registro de despliegue no deben tratarse como universos separados. Para la contratación, significa que la declaración de un proveedor sobre el tamaño del modelo no sustituye a la procedencia de los datos, la finalidad, la retención, la gestión de derechos ni la documentación aguas abajo. Para una persona afectada, significa que la pregunta útil no es cuántos parámetros estaban implicados. Es qué ocurrió con su información y qué puede hacer la organización cuando el resultado es incorrecto.

Una señal pequeña puede mover una cola grande

Consideremos una mesa de ayuda hipotética que recibe solicitudes de los residentes. Un clasificador compacto lee el primer mensaje y asigna una ruta: información, trabajo rutinario, revisión urgente o gestión especializada. El ejemplo es deliberadamente ordinario y totalmente ilustrativo. No hay ningún ayuntamiento nombrado, ningún despliegue real, ninguna marca de tiempo y ninguna afirmación de que esto haya ocurrido. La cuestión es hacer visible el límite.

Si las categorías solo ayudan a un trabajador a organizar un conjunto privado de notas, el riesgo puede ser moderado. Si la ruta urgente determina quién recibe una inspección de seguridad, el resultado se sitúa ahora más cerca de una decisión pública. Si una palabra clave ausente envía la solicitud de una persona al trabajo rutinario, el retraso puede importar aunque el modelo nunca hable con el residente. Si el trabajador puede ver el mensaje original, cambiar la ruta, registrar el motivo y responder rápidamente a una impugnación, el sistema tiene una postura de control diferente de aquella en la que la etiqueta se convierte en una puerta oculta.

El modelo no se ha vuelto más grande. La obligación se ha vuelto más clara. Sigue el camino desde la entrada hasta la consecuencia. La organización debe saber qué significan las categorías, qué evidencia puede usar el modelo, qué casos requieren rechazo o escalada, quién puede anular la ruta y qué registro permite a un revisor posterior comprender la decisión. La modestia del modelo no es una razón para omitir esas preguntas. Puede ser una razón para responderlas con más precisión porque el contrato del componente puede hacerse estrecho.

Una hipótesis similar aparece en el empleo. Un modelo pequeño podría extraer habilidades de un CV, clasificar un rol o señalar un certificado faltante. La extracción suena menos consecuente que la selección, pero la extracción puede dar forma a la clasificación que sigue. Si el resultado nunca se usa para decidir quién avanza, el sistema puede permanecer en el lado preparatorio de un límite. Si las personas tratan la etiqueta extraída como un resumen objetivo y dejan de mirar el documento, el límite se mueve. La obligación vive en el uso, no en el verbo elegido para la descripción del trabajo del modelo.

En ambas ilustraciones, la respuesta correcta no es entrar en pánico por un modelo pequeño. Es hacer explícita la transferencia. Nombrar el propósito previsto. Declarar qué puede y qué no puede cambiar el resultado. Conservar la fuente y la versión del modelo cuando una decisión depende de ellas. Dar a una persona suficiente información y autoridad para discrepar. Probar los tramos donde se espera que el sistema sea incierto. Revisar el flujo de trabajo cuando la organización cambia los datos, el umbral, la audiencia o la acción posterior.

Lo que realmente enseña la sentencia neerlandesa SyRI

Europa ya tiene un ejemplo documentado de un sistema de riesgo de aspecto compacto que conlleva una obligación proporcional a los derechos. El 5 de febrero de 2020, el Tribunal de Distrito de La Haya describió SyRI como un instrumento gubernamental legal utilizado para combatir el fraude en prestaciones, subsidios e impuestos. El tribunal no decidió el caso preguntando cuántos parámetros tenía el sistema. Evaluó el marco legal en relación con el artículo 8 del Convenio Europeo de Derechos Humanos, incluido si la injerencia en la vida privada lograba un equilibrio justo.

El tribunal concluyó que la legislación SyRI no superaba esa prueba. Según el tribunal, el uso de SyRI era insuficientemente transparente y controlable. Por lo tanto, el marco legal era incompatible con la legislación superior y no podía mantenerse en su forma existente. La página pública del caso es concisa, pero su lección no es pequeña: cuando un estado usa un sistema de indicación de riesgos contra personas que pueden tener poco poder para comprenderlo o impugnarlo, el sistema necesita un nivel de conocimiento y control acorde con esa relación.

SyRI era un instrumento neerlandés de indicación de riesgos de carácter estatutario, no un estudio de caso sobre un modelo neuronal moderno, y la página del tribunal no nos ofrece un recuento de parámetros que podamos comentar. Precisamente por eso pertenece aquí. El ejemplo nos impide tratar la arquitectura del modelo como el único objeto interesante. Un motor de reglas, una tarjeta de puntuación, un modelo estadístico o un clasificador pequeño pueden formar parte de una decisión institucional. La cuestión de los derechos surge a través del uso.

La sentencia también sitúa la transparencia en el lugar correcto. No es meramente una solicitud de explicación después de que una persona haya sufrido un daño. Forma parte de las condiciones bajo las cuales se puede juzgar el sistema antes y mientras opera. Si las personas no pueden ver lo suficiente del propósito, el uso de los datos, las salvaguardas y la vía de impugnación para comprender la injerencia, una organización puede no ser capaz de demostrar el equilibrio justo que afirma haber logrado.

No hay necesidad de convertir SyRI en una analogía universal. El marco jurídico neerlandés, los hechos del caso y el Convenio Europeo son específicos. La transferencia útil es más limitada: no preguntes si un sistema es técnicamente impresionante antes de preguntar si su relación institucional es visible, controlable y cuestionable. Una máquina más pequeña no excusa un silencio más grande.

El uso posterior es donde viaja la etiqueta

Un modelo puede introducirse como componente y aun así convertirse en parte de un sistema que conlleva otra obligación. La orientación de la Comisión sobre la IA de propósito general explica por qué los proveedores posteriores necesitan información sobre las capacidades y limitaciones de un modelo. Necesitan esa información para integrar el modelo de manera responsable y para cumplir con sus propias obligaciones conforme a la Ley de IA. El proveedor del modelo y el proveedor del sistema no redactan el mismo documento porque no responden a la misma pregunta.

Esta distinción importa cuando los equipos tratan la ficha del modelo como un pasaporte. Una ficha del modelo puede describir la arquitectura, el entrenamiento, la evaluación, las limitaciones conocidas y los usos previstos. Por sí sola no puede describir todos los entornos en los que un equipo posterior podría colocar el modelo. El sistema posterior añade un usuario, un propósito, flujos de datos, una interfaz, funciones humanas, una decisión y un conjunto de personas afectadas. Esas adiciones pueden cambiar la obligación incluso cuando los pesos del modelo permanecen intactos.

La responsabilidad también puede cambiar cuando una organización modifica el propósito previsto o realiza una modificación sustancial. Las disposiciones sobre la cadena de valor de la Ley de IA describen circunstancias en las que un actor puede asumir responsabilidades de proveedor, incluido el cambio del propósito previsto de un sistema de IA para que se convierta en de alto riesgo. Esta es una advertencia útil contra la niebla contractual. Un proveedor puede suministrar un componente, pero un implementador no puede hacer desaparecer su propio uso llamando biblioteca al componente.

La entrega práctica debería, por tanto, llevar más que un enlace de descarga. Debería indicar las tareas previstas, los límites de entrada y salida, los requisitos de integración, la información de entrenamiento y validación cuando sea pertinente, las limitaciones conocidas y las condiciones en las que el componente no debe utilizarse. Debería explicar qué no evaluó el modelo. Un equipo posterior no debería tener que inferir la ausencia de una garantía a partir de la presencia de un diagrama confiado.

Hay una razón humana para este papeleo. La persona afectada por el sistema final no se encuentra con un proveedor de modelos en abstracto. Se encuentra con una organización que eligió un flujo de trabajo. La organización debe poder decir qué hizo el componente, qué hizo la organización con él y cómo una persona puede impugnar el resultado. Si las respuestas viven en tres contratos y no hay ningún registro operativo, el sistema no está bien integrado. Simplemente está bien distribuido.

La vía humana tiene que ser real

La supervisión humana suele presentarse como una persona sentada frente a una pantalla. La Ley de IA es más precisa. Para los sistemas de alto riesgo, la supervisión debe ser eficaz y proporcionada a los riesgos, al nivel de autonomía y al contexto de uso. La persona asignada a la supervisión debe poder comprender las capacidades y limitaciones relevantes, detectar anomalías, interpretar el resultado, decidir no utilizarlo, ignorarlo o anularlo, revertirlo e intervenir o detener el sistema de forma segura.

Ninguno de esos verbos está garantizado por un modelo pequeño. Un resultado limitado puede ser más fácil de interpretar, pero interpretar no es lo mismo que tener autoridad. Un botón de anulación que nadie puede usar porque la cola es demasiado larga no es una supervisión eficaz. Un revisor que solo ve un color o una etiqueta no puede comprobar la fuente de forma significativa. Una persona a la que se culpa de una decisión pero que no puede pausar el flujo de trabajo no es el punto de control. Es un hueco decorativo con forma humana en el diagrama.

La supervisión proporcionada puede ser discreta. Puede ser una vía clara para que un trabajador marque que la evidencia es insuficiente, una segunda comprobación para una categoría sensible, un registro de por qué se rechazó una recomendación o una pausa automática cuando faltan campos obligatorios. Puede ser una persona que asume la decisión y tiene tiempo para investigar los casos que el sistema le asigna. Los detalles dependen del contexto. El requisito es que la vía funcione cuando el sistema es incierto, incorrecto, no está disponible o se cuestiona.

Para los modelos pequeños, una negativa estructurada puede ser una ventaja. Si un clasificador puede decir fuente faltante, fuera de alcance o requiere revisión, la organización tiene un evento concreto que gestionar. Eso es mejor que un párrafo fluido que convierte silenciosamente la incertidumbre en una instrucción. Pero la negativa también necesita un responsable. Si cada negativa se convierte en un callejón sin salida, el sistema simplemente ha trasladado la carga a alguien sin darle un camino para resolverla.

La vía humana se extiende a la persona afectada. Una persona no debería necesitar la terminología del proveedor para impugnar un resultado. La organización debería saber qué información se puede explicar, qué se puede corregir, quién revisa el caso y qué ocurre mientras la revisión está abierta. Un modelo pequeño puede facilitar la descripción del rastreo interno. No reduce la importancia de la persona fuera del sistema.

Los controles proporcionados siguen siendo controles

La gobernanza proporcionada comienza rechazando dos malos acuerdos. El primero dice que todo sistema merece el mismo proceso pesado, lo que convierte la gestión de riesgos en papeleo y acaba enseñando a los equipos a ocultar su trabajo. El segundo dice que los modelos pequeños no merecen ningún proceso serio, lo que confunde un componente limitado con una institución inofensiva. Un enfoque proporcionado pregunta qué puede cambiar el sistema, a quién puede afectar y qué evidencia permitiría a la organización reparar un error.

El primer control es una declaración de propósito que un no especialista pueda entender. Debe nombrar la tarea, los usuarios previstos, las personas afectadas, la entrada permitida, el resultado y las acciones que el sistema no puede realizar. Un propósito como apoyo a la priorización es demasiado vago si podría significar organizar un backlog privado, decidir quién recibe una inspección legal o seleccionar candidatos para una revisión disciplinaria. La frase no es texto de marketing. Es el límite contra el que se comprueban los cambios posteriores.

El segundo control es un límite de entrada y evidencia. Qué fuentes puede leer el sistema. Qué campos son autoritativos. Qué actualizados deben estar. Qué ocurre cuando falta un valor o entra en conflicto con otra fuente. Pueden entrar datos personales en la vía. Qué registro se conserva. Un modelo compacto puede ser estricto con la entrada y aun así fallar si el flujo de trabajo circundante amplía silenciosamente los datos. El alcance necesita un responsable, no solo un esquema.

El tercer control es un contrato de salida. Indica las etiquetas permitidas, los estados de incertidumbre, las condiciones de rechazo y las acciones posteriores para cada resultado. Si el sistema devuelve una puntuación, di qué significa y qué no significa. Si devuelve una clasificación, di si es una sugerencia o una barrera. Si devuelve una categoría, di quién puede cambiarla y qué registro captura el cambio. Un vocabulario reducido solo es útil cuando la institución acepta no colar autoridad adicional en él.

El cuarto control es una vía de cambio. Las actualizaciones del modelo, los cambios de umbral, las nuevas fuentes de datos, un grupo de usuarios distinto, un nuevo proveedor o una acción posterior modificada pueden alterar el riesgo del sistema. El lenguaje de ciclo de vida de la AI Act recuerda que la gestión de riesgos es iterativa. Un componente que en enero era limitado puede integrarse en una decisión distinta en agosto. La obligación sigue a la relación modificada, no a la fecha del primer documento de diseño.

El quinto control es una salida. ¿Puede la organización pausar el componente, recurrir a una vía humana, exportar los registros, explicar el historial de decisiones y sustituir al proveedor sin perder la evidencia necesaria para reparar casos? La salida no es un lujo reservado a los sistemas grandes. Un modelo pequeño puede convertirse en un punto único de memoria institucional si nadie conserva la fuente, la versión y la vía de decisión que lo rodean.

Un expediente de evidencia proporcionado

Un expediente de evidencia proporcionado no es un almacén de todo lo que alguien pensó sobre el modelo. Es una respuesta legible a las preguntas que un revisor, un operador, una persona afectada o un regulador pueden plantear razonablemente. Cuál era el propósito previsto. Qué versión se ejecutó. Qué datos recibió. Qué devolvió. Qué regla o umbral convirtió esa salida en una acción. Quién tenía autoridad para cambiar el resultado. Qué ocurrió cuando faltaba evidencia. Cómo se puede reproducir o impugnar la decisión.

Para una sugerencia de bajo impacto, el expediente puede ser pequeño. Puede contener el propósito, la fuente, la versión, la evaluación básica, el responsable, la regla de conservación y un enlace a la vía de corrección. Para un sistema que influye en el acceso, la seguridad, el empleo o los derechos, el expediente necesita más. Debe conectar el análisis de riesgos con los datos y el contrato de salida, mostrar cómo funciona en la práctica la supervisión humana, documentar las limitaciones conocidas y conservar suficiente historial operativo para investigar un resultado impugnado. La proporción crece con la consecuencia, no con el número de parámetros.

Las pruebas deben seguir la misma lógica. Una única cifra de precisión no puede describir la idoneidad de un sistema para todos los contextos. Prueba los segmentos de datos y las condiciones que importan para el propósito. Incluye entradas ausentes y contradictorias. Incluye casos en los que el rechazo es correcto. Comprueba si distintos equipos usan la salida del modelo de forma diferente. Registra qué se midió, bajo qué condiciones y qué sigue siendo desconocido. Un modelo que funciona bien con un conjunto de pruebas limpio puede estar mal ubicado en una institución desordenada.

La supervisión no es un adorno de panel de control. Es la forma en que la organización descubre que el flujo de trabajo real ha cambiado. Vigila los cambios en los datos de entrada, las tasas de discrepancia, las tasas de rechazo, los cambios en las correcciones humanas, los nuevos usos posteriores y las quejas o solicitudes de corrección. Las señales exactas dependen del sistema. El principio es estable: la evidencia debe incluir la relación que crea la obligación, no solo la puntuación interna del modelo.

Una buena evidencia también tiene fecha de caducidad, incluso cuando los registros se conservan durante más tiempo. Una interpretación legal puede cambiar. Un servicio puede llegar a una población nueva. Un proveedor puede actualizar un modelo. Una vía que era reversible puede quedar integrada en otro sistema. Marca qué se evaluó, cuándo, por quién y con qué propósito. El registro se convierte entonces en un historial de decisiones, no en un certificado estático que sobrevive a las condiciones que lo hacían significativo.

Los modos de fallo de los modelos pequeños

Los sistemas pequeños fallan de maneras reconocibles. Un clasificador puede omitir una categoría porque la definición de la etiqueta es ambigua. Un extractor puede devolver un campo plausible de la frase equivocada. Un modelo de clasificación puede preferir casos conocidos y ocultar los inusuales. Un umbral puede convertir una incertidumbre continua en un falso binario. Un modelo local puede funcionar de manera fiable mientras los datos de origen están desactualizados. Ninguno de estos fallos es automáticamente catastrófico. Cada uno cobra importancia cuando el flujo de trabajo trata la salida como más autoritativa de lo que permite el contrato del componente.

El primer modo de fallo es la falsa modestia. El equipo dice que el modelo solo señala, ordena o asiste, y luego diseña el flujo de trabajo para que el personal rara vez discrepe. La etiqueta se convierte en una decisión por costumbre. Esto no es un defecto en el número de parámetros del modelo. Es un defecto en el manejo de la autoridad por parte de la institución. La solución es hacer visible la transferencia, medir las anulaciones y los desacuerdos, y dar a las personas una vía práctica para cambiar el resultado.

El segundo es la composición oculta. Un modelo pequeño puede estar junto a la recuperación, las reglas, una cola, una clasificación y un servicio de notificaciones. Cada componente parece limitado. Juntos pueden crear una vía de decisión poderosa. La revisión de riesgos debe seguir la vía de principio a fin. Qué fuente entra primero. Qué transformación elimina el contexto. Qué etiqueta desencadena una acción. Qué registro sobrevive. Qué persona puede detener la cadena. La garantía a nivel de componente es necesaria, pero no es la visión del sistema.

El tercero es la obligación obsoleta. Un modelo permanece sin cambios mientras su propósito o su audiencia cambian. Un equipo añade una nueva fuente de datos, envía la salida a otro departamento o comienza a usar una herramienta de priorización privada en un flujo de trabajo orientado al público. La ficha del modelo sigue igual, así que todos asumen que el riesgo es el mismo. No lo es. El propósito previsto se ha movido, y el archivo de evidencia debería moverse con él.

El cuarto es el halo del modelo pequeño. Una factura de recursos baja o una implementación local ordenada hacen que el sistema parezca más responsable de lo que es. La organización aún puede fallar al explicar el resultado, conservar la entrada, proporcionar reparación o asignar una persona con autoridad. La eficiencia técnica es bienvenida. No es un sustituto del control institucional. Un sistema puede ser barato de ejecutar y caro de defender.

El quinto es la salida faltante. Los componentes pequeños son fáciles de añadir y difíciles de eliminar cuando se integran en un proceso ocupado. Un reemplazo cambia las categorías, los umbrales o los registros que los equipos posteriores esperan. Si nadie ensayó el cambio, el sistema se vuelve pegajoso. El modelo puede ser pequeño, pero la migración ahora es un problema público. La portabilidad pertenece a la primera conversación de diseño, no a la última reunión de adquisiciones.

Cuando lo pequeño es la elección de ingeniería correcta

Nada de esto debería convertirse en una campaña contra los modelos pequeños. Lo pequeño puede ser exactamente lo correcto. Una tarea estrecha con un contrato claro puede no necesitar un modelo de propósito general. Un componente local puede mantener las entradas sensibles más cerca de las personas responsables de ellas. Una salida fija puede facilitar la validación y el monitoreo. Un modelo que se niega fuera de su alcance puede ser más seguro de componer que uno que responde a cada pregunta con una confianza elegante.

El caso de ingeniería es más sólido cuando el equipo puede nombrar lo que el componente no hará. Clasificará solo las categorías aprobadas. Leerá solo los campos declarados. Devolverá evidencia insuficiente cuando falte un campo requerido. No llamará a una herramienta. No tomará la decisión final. Llevará una versión y un registro de evaluación. Será reemplazable porque la interfaz y el contrato de evidencia están documentados. Esas restricciones no hacen que el sistema sea infantil. Hacen que sus responsabilidades sean legibles.

Los componentes pequeños también pueden favorecer una mejor división del trabajo. Un modelo amplio puede interpretar un lenguaje poco estructurado o redactar una explicación legible. Un componente estricto puede extraer un campo, aplicar una política de control, clasificar un conjunto declarado de fuentes o comprobar si una salida se ajusta a un formato conocido. Un motor de reglas o un solucionador puede encargarse de la parte que debe ser exacta. Una persona puede asumir el juicio que no puede delegarse de forma segura. Lo importante no es la pureza, sino que cada parte tenga una función acotada y que el sistema registre cómo se conectan esas funciones.

Esta disposición tiene una practicidad europea. Las instituciones rara vez pueden sustituirlo todo de una vez. Necesitan sistemas que funcionen en las condiciones reales de hardware, marco legal, idioma y contratación que tienen. Los componentes más pequeños a veces pueden desplegarse más cerca del trabajo, evaluarse con evidencia local y sustituirse sin pedir a toda una organización que cambie su memoria. Esto es una expectativa, no una afirmación sobre todos los modelos pequeños. El despliegue sigue necesitando pruebas de que el encaje es real.

Lo pequeño también es útil como disciplina. Cuando un equipo no puede resolver un problema añadiendo más capacidad general, tiene que decidir qué información importa, qué incertidumbre puede exponerse y qué casos requieren una persona. Ese trabajo de diseño puede revelar que un modelo no es necesario. A veces el componente adecuado es una restricción de base de datos, un índice de búsqueda, un registro firmado o un formulario bien redactado. Un modelo más pequeño puede asumir una obligación grande. Un componente que no es un modelo también puede hacerlo.

Cuando lo pequeño se usa como camuflaje

Lo pequeño se convierte en camuflaje cuando se ofrece como respuesta antes de que nadie haya descrito la pregunta. El discurso puede decir que el componente es ligero, local, privado, eficiente o abierto. Todos pueden ser datos útiles. Pero no le dicen a una persona afectada si el sistema puede impugnarse, ni a un operador si el resultado puede revertirse, ni a un regulador si la organización comprendió su propósito.

El camuflaje suele aparecer en el lenguaje de contratación. Al comprador se le muestra un tamaño de modelo, una cifra de latencia y un coste de inferencia. El contrato dice que el proveedor ofrece una herramienta de apoyo a la decisión. Nadie anota qué decisiones, de quién son los datos, qué poblaciones, qué vía humana o qué cambios activan una revisión. Más tarde, un equipo interno descubre que la herramienta se ha convertido en un filtro porque la cola, el plazo o el panel hicieron que la recomendación fuera cómoda de seguir. El modelo era pequeño. La gobernanza era más pequeña.

Otro camuflaje es la expresión humano en el circuito. Una persona puede tocar técnicamente todos los casos sin tener tiempo, información ni autoridad reales. El circuito funciona entonces como un ritual de aprobación. Un modelo pequeño puede hacer esto especialmente tentador porque la salida parece simple. Llegan tres categorías, una persona hace clic en una y la organización llama al resultado revisado. La revisión exige capacidad para comprender, impugnar y modificar el resultado. Un clic no es por sí solo una salvaguarda.

Un tercer camuflaje es la afirmación de que local significa soberano. El procesamiento local puede ayudar con la residencia, la latencia y el control operativo, pero la soberanía también se refiere a quién puede cambiar el software, custodiar las claves, acceder a los registros y mantener el servicio en funcionamiento cuando un proveedor o una red no están disponibles. El modelo pequeño de un dispositivo puede ser local mientras sus actualizaciones, evaluación y autoridad permanecen en otro lugar. La ubicación es un hecho en el mapa. El control es un hecho en la relación.

El antídoto no es una forma más grande, sino una más nítida. Pregunte por el propósito. Pregunte qué cambia debido a la salida. Pregunte quién puede discrepar. Pregunte qué puede hacer la persona afectada. Pregunte qué evidencia se conserva. Pregunte cómo se pausa, sustituye y reevalúa el sistema. Si las respuestas son claras, el tamaño del modelo puede volver a su lugar propio como una opción de ingeniería entre muchas.

Las preguntas de un comprador

Antes de que un modelo pequeño entre en un flujo de trabajo con consecuencias, un comprador debería poder responder a una secuencia de preguntas sencillas. ¿Cuál es la finalidad prevista en una frase? ¿Qué queda fuera del alcance? ¿A qué personas puede afectar, directamente o a través de una acción posterior? ¿Qué datos se requieren y qué datos están prohibidos? ¿Qué le permite hacer a la organización cada resultado? ¿Qué no le permite hacer?

Después hay que preguntar por la autoridad. ¿Quién es dueño de la decisión? ¿Quién puede anular el modelo? ¿Quién puede detener el flujo de trabajo? ¿Qué información ve esa persona? ¿Cuánto tiempo tiene? ¿Qué ocurre cuando no está de acuerdo? ¿Se informa a la persona afectada lo suficiente como para pedir una revisión? ¿Puede la organización corregir tanto los datos de entrada como los resultados? Estas preguntas no son una acusación contra el proveedor. Son la descripción mínima de la institución que compra la herramienta.

Hay que preguntar por las pruebas. ¿Qué versión se ejecutó? ¿Qué configuración de modelo y de política estaba activa? ¿Qué fuentes estaban disponibles? ¿Qué umbral o regla convirtió el resultado en la siguiente acción? ¿Qué se registra cuando una persona modifica el resultado? ¿Puede la organización reproducir un caso sin pretender que una nueva ejecución es la anterior? ¿Puede exportar los registros en un formato que otro sistema pueda leer? La respuesta no tiene que ser una gran plataforma. Tiene que ser un registro real.

Hay que preguntar por los cambios. ¿Qué cuenta como actualización del modelo? ¿Qué cuenta como nueva fuente de datos? ¿Qué ocurre cuando cambia la finalidad? ¿Qué cambios requieren una nueva evaluación? ¿A quién se notifica? ¿Cómo se protege a las personas afectadas durante una reversión o una migración? Si el proveedor no puede responder, el comprador no está adquiriendo un riesgo pequeño. Está aceptando una descripción pequeña de una gran incógnita.

Por último, hay que preguntar por la salida. ¿Puede el flujo de trabajo funcionar con seguridad sin el modelo? ¿Puede la organización recuperar los datos de entrada, los resultados, las decisiones y el historial de correcciones? ¿Puede otro componente cumplir la misma interfaz sin una nueva dependencia? ¿Puede retirarse el sistema sin dejar a nadie en el limbo? Un modelo no es realmente pequeño si retirarlo exige que la institución olvide cómo tomaba sus decisiones.

Una breve nota nuestra

En Dweve, Loom es un ejemplo de la posición de diseño que aportamos a esta cuestión. Su descripción pública del producto presenta los componentes de lenguaje pequeño como motores de representación en torno a un grafo de razonamiento tipado, con trazas, reproducción y límites explícitos de rechazo. Es una declaración sobre nuestra arquitectura y sobre cómo queremos que la responsabilidad de un componente sea visible. No es una prueba independiente, una clasificación normativa, un despliegue en un cliente ni una promesa de que un componente pequeño sea automáticamente adecuado para un uso con consecuencias.

La parte útil del ejemplo es el límite. Un componente puede ser pequeño y merecer igualmente un contrato preciso. Puede colocarse en un grafo mayor sin convertirse en el dueño de cada decisión. Puede llevar una traza sin afirmar que la traza demuestra que toda la institución actuó conforme a la ley. Mencionamos Loom aquí solo para mostrar cómo nuestro propio trabajo intenta mantener separadas la capacidad del modelo, la finalidad del sistema, las pruebas y la autoridad humana. La cuestión europea sigue siendo la misma para nosotros que para cualquier otro: ¿qué puede cambiar este sistema y pueden las personas responsables seguir inspeccionándolo y corrigiéndolo?

La obligación recae sobre la relación

Un modelo pequeño puede ser más fácil de ejecutar, más fácil de probar y más fácil de sustituir. Esas son buenas razones para elegir uno. No son razones para reducir el deber de diligencia que lo rodea. Las definiciones y las normas de riesgo de la AI Act, la orientación de la Comisión sobre los GPAI, el enfoque caso por caso del CEPD sobre los datos y la sentencia neerlandesa SyRI apuntan todas en la misma dirección práctica sin convertirse en una única prueba jurídica: hay que atender a la finalidad, el contexto, la autoridad, las pruebas, las personas afectadas y la posibilidad de reparación.

La pregunta correcta, por tanto, no es si el modelo es pequeño. Es qué se le permite cambiar. Si solo ayuda a una persona a buscar en sus propias notas, la respuesta puede ser modesta. Si cambia quién recibe atención, qué registro se considera fiable o si un servicio público abre una puerta, la respuesta es mayor. Si la organización no puede explicar el traspaso, conservar las pruebas o dar a alguien una vía para impugnar el resultado, la obligación ya ha superado al componente.

Una buena gobernanza deja margen para la proporcionalidad. No exige que cada modelo se convierta en un comité. Pide al equipo que haga visibles las relaciones importantes, que mantenga las afirmaciones vinculadas a las pruebas y que otorgue a las personas autoridad real cuando el sistema sea incierto o esté equivocado. Los modelos pequeños pueden ayudar en esa labor porque un componente acotado puede nombrarse y probarse. Pero estar acotado es un logro de diseño, no una propiedad automática de ser pequeño.

El tamaño pertenece al registro técnico. La finalidad pertenece al registro del sistema. Las consecuencias pertenecen al registro humano. Cuando esos tres registros pueden comunicarse entre sí, un modelo pequeño puede utilizarse con cuidado sin tratarlo como inofensivo. Cuando se mantienen separados, la modestia del modelo se convierte en teatro, y quienes asumen el resultado pagan por la falta de contexto.

Fuentes