Un modelo de frontera es un modelo de IA grande y de propósito general, entrenado y operado por un laboratorio externo, al que se accede a través de la API de ese laboratorio. Cuando un equipo regulado planea integrar uno en un flujo de trabajo, la respuesta honesta a “¿podemos auditarlo?” es: en parte. Puede verificar qué hace el modelo con sus entradas, aquí y ahora. No puede verificar cómo se construyó, qué cambió la semana pasada ni por qué rechazó una solicitud. Esta entrada separa ambas cosas, con justicia, para que el responsable de cumplimiento sepa exactamente dónde terminan las pruebas y dónde deben empezar sus propios controles.
El sentido de este texto no es que los laboratorios de frontera se comporten mal. No hay pruebas de que ningún laboratorio debilite deliberadamente un modelo para perjudicar a clientes o competidores, y no lo vamos a insinuar. El sentido es más concreto: existe una brecha entre lo que un modelo cerrado le permite ver y lo que un auditor, un regulador o su propia asesoría jurídica necesitan ver. Nombrar esa brecha con precisión es el primer paso para diseñar a su alrededor.
¿Qué puede verificar realmente sobre un modelo de frontera cerrado?
Bastante, siempre que se mantenga en el exterior del modelo y observe su comportamiento.
Puede verificar las salidas frente a sus propias entradas. Puede ejecutar un conjunto fijo de casos de prueba y registrar lo que devuelve. Puede medir la precisión, la tasa de rechazo, la latencia y el coste en tareas que le importan. Puede capturar la solicitud y la respuesta completas, y puede comparar dos versiones en paralelo sobre las mismas entradas. Nada de esto requiere la cooperación del laboratorio, porque todo es observable desde donde usted está.
Esta es la superficie verificable, y es la base de todo lo que sigue. Si construye su propio conjunto de evaluación (una colección fija y etiquetada de casos de prueba que representen su trabajo real) y lo ejecuta en cada modelo que considere, dispone de pruebas sólidas sobre el comportamiento. Esas pruebas son suyas, son reproducibles y no dependen de ninguna divulgación del proveedor.
¿Qué no puede verificar y por qué importa?
Cinco cosas quedan al otro lado de la brecha. Cada una es un punto donde las preguntas de su auditor se quedan sin respuesta.
| Lo que no puede verificar | Por qué importa a un equipo regulado |
|---|---|
| Los datos de entrenamiento exactos | No puede confirmar de qué aprendió el modelo, si se incluyeron datos de su sector ni si lo moldeó contenido con derechos de autor o regulado. |
| El prompt de sistema oculto | Un prompt de sistema es la instrucción permanente que el laboratorio adjunta a cada solicitud. Puede cambiar el comportamiento de rechazo y el tono sin aviso, y la mayoría de los laboratorios no lo publican. |
| Actualizaciones silenciosas dentro de la versión | Un modelo con el mismo nombre puede reajustarse. Su validación del trimestre pasado puede describir un modelo que ya no existe. |
| El efecto real del ajuste de seguridad | Los rechazos y las cautelas son deliberados, pero su efecto en una tarea concreta (una revisión jurídica, un resumen clínico) es difícil de medir desde fuera y aún más difícil de predecir. |
| La reproducibilidad de benchmarks y evaluaciones | Las puntuaciones públicas pueden derivar, filtrarse u optimizarse en su contra. Un número en una tabla de clasificación no es prueba de que el modelo rendirá en su trabajo. |
Dos de estas merecen un examen más detenido, porque son las que sorprenden a los responsables no técnicos.
Los modelos cambian manteniendo el mismo nombre
El ejemplo documentado más claro es un estudio de 2023 de Stanford y UC Berkeley, “How Is ChatGPT’s Behavior Changing over Time?”. Los investigadores compararon las versiones de marzo de 2023 y junio de 2023 de GPT-4 y GPT-3.5 en tareas idénticas. En una tarea matemática (identificar números primos), la versión de marzo obtuvo un 97,6 por ciento y la de junio un 2,4 por ciento. Otras tareas se movieron en sentido contrario. El estudio no demuestra que el modelo empeorara en conjunto, y los autores son cuidadosos al respecto. Demuestra algo más simple y más importante para la gobernanza: el mismo nombre de producto puede dirigir a comportamientos sustancialmente distintos con el tiempo, y no se le avisará el día en que cambie.
Por eso una validación puntual no es un control. Es una instantánea de un objetivo en movimiento.
Los benchmarks no son prueba sobre su trabajo
Los benchmarks públicos son útiles para comparar modelos en general, pero tienen límites conocidos cuando la apertura se cruza con la competencia. Un análisis de 2025, “Pitfalls of Evaluating Language Models with Open Benchmarks”, muestra cómo los conjuntos de prueba abiertos pueden filtrarse al entrenamiento y cómo los modelos pueden optimizarse frente a tareas publicadas, lo que infla las puntuaciones sin mejorar la capacidad en el mundo real. Incluso el proyecto HELM de Stanford, creado específicamente para una evaluación transparente y reproducible, existe porque la reproducibilidad es difícil y merece que se diseñe para ella. La conclusión para un comprador es clara: un benchmark le dice cómo le fue a un modelo con las preguntas de otros, no cómo le irá con las suyas.
¿Por qué los laboratorios mantienen esto en privado? El argumento justo
Sería fácil leer la lista anterior como una lista de agravios. Es más justo reforzar primero el razonamiento del laboratorio.
Seguridad. Publicar el prompt de sistema completo y la receta exacta de ajuste facilita diseñar jailbreaks (intentos deliberados de eludir los controles de seguridad). Un laboratorio que retiene detalles está protegiendo, en parte, los controles que impiden que el modelo produzca salidas dañinas.
Propiedad intelectual. La composición de los datos de entrenamiento, los métodos de limpieza de datos y las técnicas de ajuste son el activo competitivo central del laboratorio. Ninguna empresa de software publica su código fuente y su canalización, y un modelo de frontera está entre los artefactos más caros jamás construidos. Exigir divulgación total no es realista y frenaría el avance del campo.
Prevención de abusos. Una divulgación detallada de cómo se puede dirigir un modelo es también un manual para dirigirlo mal. Cierta opacidad es una función de seguridad, no un encubrimiento.
Estas son razones reales, y un comprador serio debería concederlas. El error es concluir que, como el secretismo del laboratorio es razonable, el problema de auditoría de la empresa queda resuelto. No lo está. Dos cosas pueden ser ciertas a la vez: el laboratorio actúa de buena fe, y usted aún no puede mostrar a su regulador las pruebas que exige.
¿No cierra la regulación la brecha?
En parte, y ayuda, pero no lo suficiente como para depender de ella sola.
La Ley de IA de la UE ahora exige que los proveedores de modelos de IA de propósito general publiquen un resumen del contenido usado para entrenar el modelo, mediante una plantilla obligatoria que la Comisión Europea publicó en julio de 2025, con obligaciones que comenzaron a aplicarse el 2 de agosto de 2025. Esto es un avance real. También es, por diseño, un resumen. Le indica las categorías y las fuentes principales de los datos de entrenamiento. No le da a un auditor el conjunto de datos, el registro de ajuste ni la garantía de que el modelo que invoca hoy coincida con el descrito. Los modelos heredados presentes en el mercado antes de agosto de 2025 también tienen hasta el 2 de agosto de 2027 para cumplir, así que el panorama de divulgación será desigual durante un tiempo.
Algunos laboratorios van más allá de forma voluntaria. Anthropic, por ejemplo, publica los prompts de sistema de sus modelos Claude y los actualiza con cada lanzamiento, lo que es más de lo que hacen la mayoría de los laboratorios. Eso merece reconocimiento. Pero la transparencia voluntaria es exactamente eso: voluntaria, parcial y revocable. Un control que no puede hacer cumplir no es un control que pueda presentar ante un auditor.
Entonces, ¿qué puede controlar? Lleve las pruebas a su lado
La brecha de transparencia es real y no se va a cerrar pronto desde el lado del laboratorio. La respuesta práctica no es ganar una discusión sobre divulgación. Es reubicar las pruebas que necesita en su propio perímetro, donde pueda producirlas a demanda. Cuatro controles hacen la mayor parte del trabajo, y cada uno es algo que un equipo regulado puede tener en sus propias manos.
-
Sus propias evaluaciones sobre sus propios datos. Construya un conjunto de evaluación fijo y etiquetado a partir de sus tareas reales y ejecútelo contra cada modelo y cada versión, antes y después de ponerlo en producción. Esto convierte “confiamos en el proveedor” en “esta es la puntuación sobre nuestro trabajo, fechada y reproducible”. Este es el núcleo de lo que describimos en el coste por tarea completada: la calidad debe medirse sobre el trabajo, no en una tabla de clasificación.
-
Sus propias trazas de ejecución. Registre cada solicitud, respuesta, llamada a herramienta y decisión, y conserve los registros dentro de su entorno. Una traza es la diferencia entre “el agente hizo algo” y “esto es exactamente lo que hizo, con qué entrada, bajo qué versión de política”. Este es el registro de auditoría que un auditor realmente pide, y reside en su lado de la línea. Vea cómo lo estructuramos en la torre de control.
-
Un modelo fijado o propio. Fije una versión de modelo concreta y fechada para que una actualización silenciosa no pueda mover su objetivo sin que lo sepa, y prefiera modelos de pesos abiertos que pueda ejecutar dentro de su propio perímetro cuando la carga de trabajo lo exija. Un modelo propio no cambia por debajo de usted. Uno fijado solo cambia cuando usted decide moverlo. Nuestra visión sobre mantener la inferencia dentro de su perímetro está en dentro del perímetro de confianza.
-
Un registro de auditoría que usted conserva. Mantenga los resultados de evaluación, las trazas, los manifiestos de versiones y las decisiones de política en un almacenamiento que usted controla, con la retención que usted defina. Cuando el regulador, el auditor o su propia asesoría jurídica pidan pruebas, usted las produce desde sus propios sistemas, no desde un ticket de soporte del proveedor.
Nada de esto requiere que el laboratorio se abra. Ese es el sentido. No puede auditar lo que no puede ver, así que deja de depender de verlo. Mide el comportamiento sobre sus datos, registra lo que ocurrió, fija lo que puede y conserva el registro. El modelo sigue siendo una caja parcialmente cerrada. Sus pruebas, no.
El gráfico es una escala aproximada de cuántas pruebas puede conservar usted mismo, de ninguna (0) a completa (3). Las dos primeras se quedan cerca de cero porque residen dentro del laboratorio. La estabilidad de versión sube en el momento en que usted fija. El comportamiento y las trazas son totalmente suyos. La estrategia es apoyar su postura de cumplimiento en las columnas que puede llenar, no en las que no puede.
Este es el mismo razonamiento que recorre nuestro trabajo sobre el perímetro de confianza y nuestra postura de seguridad: mantener la carga regulada y la prueba de conformidad dentro de una infraestructura que usted posee, y tratar el modelo de frontera como un componente capaz pero parcialmente opaco que usted envuelve en controles en lugar de confiar a ciegas. Para ver cómo encaja esto en un despliegue gradual, consulte la escalera de autonomía y el resto de nuestras reflexiones.
Preguntas frecuentes
¿Puedo auditar por completo en algún momento un modelo de frontera cerrado?
No, no desde dentro. No puede verificar sus datos de entrenamiento, su prompt de sistema completo ni el motivo interno exacto de una salida concreta. Puede auditar por completo su comportamiento sobre sus entradas, y puede conservar registros completos de lo que hizo dentro de sus flujos de trabajo. El objetivo realista es un registro de comportamiento verificable bajo controles que usted posee, no una inspección completa de la construcción del modelo.
¿Es justo decir que los laboratorios ocultan cosas para perjudicar a los clientes?
No. No hay pruebas de que los laboratorios de frontera degraden deliberadamente los modelos para perjudicar a clientes o competidores, y afirmarlo sería infundado y difamatorio. Los laboratorios retienen detalles por razones defendibles: seguridad, propiedad intelectual y prevención de abusos. La preocupación legítima no es la mala fe. Es que un secretismo razonable deja igualmente a una empresa incapaz de producir las pruebas que sus reguladores exigen, un problema que la empresa tiene que resolver por su cuenta.
¿Fijar una versión de modelo elimina la brecha de transparencia?
Elimina un riesgo concreto: la actualización silenciosa dentro de la versión que cambia el comportamiento sin aviso. Fijar una versión fechada significa que el modelo no se mueve por debajo de usted hasta que decida moverlo. No revela los datos de entrenamiento ni el prompt de sistema. Para cerrar más la brecha, combine la fijación con sus propias evaluaciones, sus propias trazas y, cuando la carga de trabajo lo justifique, un modelo de pesos abiertos que ejecute dentro de su propio perímetro.