Divulgación de la versión del modelo de IA: lo que necesita saber su consejo

Cuando un consejo aprueba un análisis generado por IA, la versión del modelo que lo produjo pasa a formar parte de la base de evidencia de la decisión. Esta guía establece un estándar de divulgación de una sola línea, un test de materialidad para determinar cuándo la actualización del modelo de una plataforma requiere informar al consejo, y las preguntas al proveedor que hacen exigible la responsabilidad a nivel de versión.

Tres cosas que el consejo necesita entender y una que no: necesita saber que la versión está fijada, registrada y recuperable; necesita un test de materialidad para saber cuándo prestar atención a una actualización; y necesita las preguntas correctas que formular a los proveedores. No necesita entender cómo funciona el modelo.

El análisis generado por IA se ha convertido discretamente en un dato habitual en los paquetes del consejo. La supervisión formal no ha avanzado al mismo ritmo. Cuando ISS-Corporate examinó las declaraciones de representación del S&P 500, encontró que solo alrededor del 15% de las empresas proporcionaba alguna divulgación sobre la supervisión del consejo de la IA, y apenas el 1,6% divulgaba una supervisión explícita a nivel de todo el consejo o de comisión.^[1]

• Solo alrededor del 15% de las empresas del S&P 500 divulga algún nivel de supervisión del consejo sobre la IA en sus declaraciones de representación.
• Apenas el 1,6% divulga una responsabilidad de supervisión explícita a nivel de todo el consejo o de comisión.
• Las obligaciones de transparencia del artículo 50 de la Ley de IA de la UE se aplican desde el 2 de agosto de 2026, exigiendo la divulgación de que el contenido es generado por IA y el marcado legible por máquina de los resultados generativos.^[2]

La pregunta más acuciante, en gran medida sin respuesta, es: ¿qué versión del modelo produjo el análisis, y qué ocurre con la responsabilidad cuando la plataforma actualiza silenciosamente ese modelo después de que el consejo haya dado su aprobación? Los consejos que no pueden responder a esta pregunta no pueden reconstruir lo que aprobaron, ni siquiera en principio.

El modelo es un dato fundamental del análisis: determina cómo se estructuran los problemas, qué planteamientos emergen, cómo se ponderan las evidencias y en qué lenguaje se redactan las conclusiones. Volver a ejecutar el mismo encargo con una versión diferente del modelo puede producir un documento materialmente distinto.

Una investigación sobre pruebas de regresión para sistemas de IA generativa construyó un conjunto de referencia de 80 casos de prueba por idioma en ocho categorías de tareas y encontró que los modelos más nuevos generalmente mejoran la precisión en promedio, pero las mejoras pueden ser modestas y desiguales, y una versión más nueva puede mejorar en general pero degradarse inesperadamente en entradas o tareas específicas.^[3]

Tres propiedades que dependen de conocer la versión:

• Reproducibilidad: si no se registra la versión, nadie puede reconstruir posteriormente qué sistema produjo el resultado aprobado.
• Responsabilidad: la persona que presenta el análisis, no el proveedor, responde de su contenido. Esa responsabilidad descansa sobre un estado concreto del sistema.
• Detección de desviaciones: el comportamiento del modelo cambia entre versiones. La orientación de IBM sobre la desviación del modelo identifica su detección como un componente central de la gobernanza sólida de la IA, y comienza por conocer la versión de referencia.^[4]

Tres elementos en una sola línea de portada son suficientes para hacer reconstruible un análisis asistido por IA. El formato exacto importa menos que la disciplina: cada documento asistido por IA que llega al consejo incluye la línea.

1. El nombre de la plataforma o herramienta, para que el artefacto sea atribuible a un sistema concreto.
2. La versión o rango de versiones del modelo, para que el estado exacto del sistema sea identificable.
3. La fecha de generación, vinculada al historial de versiones del proveedor.

Una línea funcional: «Análisis generado en [Plataforma], versión del modelo [X], el [fecha].» Esto proporciona al consejo, a la función de auditoría y a cualquier examinador futuro las tres coordenadas necesarias para localizar el análisis en el historial de versiones del proveedor.

La misma disciplina debe extenderse a cualquier actualización significativa. Si un análisis se actualiza en una fecha posterior, la portada incluirá la línea de divulgación de la versión actualizada – y si la versión del modelo cambió entre el original y la actualización, ese cambio se señala.

Si la plataforma actualiza su modelo subyacente después de que el consejo aprobara el análisis, el artefacto aprobado no se ve afectado siempre que la versión en la que se generó esté fijada, registrada y sea recuperable. La aprobación se vincula al artefacto, no a la versión actual del proveedor.

El cambio se vuelve material cuando el análisis va a ejecutarse de nuevo, actualizarse o utilizarse como base de una decisión en tiempo real. Los proveedores suelen deprecar las versiones antiguas según su propio calendario, y las actualizaciones de los modelos subyacentes pueden cambiar silenciosamente el comportamiento.^[5]

Tres preguntas que formular cuando un proveedor anuncia un cambio de modelo:

• ¿Se va a volver a ejecutar o actualizar este análisis con la nueva versión? Si es así, los resultados pueden diferir y el comité debería ver ambas versiones en paralelo.
• ¿Seguirá dependiendo de él una decisión en tiempo real? La dependencia en tiempo real significa que es el estado actual del modelo el que realiza el trabajo, no el artefacto fijado.
• ¿Dio el proveedor un aviso adecuado? El plazo de aviso determina si el equipo tuvo tiempo de probar la nueva versión antes de confiar en ella.

Regla general: informar al consejo cuando una nueva ejecución con la nueva versión podría plausiblemente cambiar una conclusión material. No informar al consejo cada vez que cambia un número de versión.

Tres preguntas convierten la preocupación por la versión del modelo en compromisos exigibles en el momento de la contratación, en lugar de una vez que el análisis ya figura en un paquete del consejo.

1. ¿Se registra la versión del modelo en el rastro de auditoría de cada resultado generado, y puede exportarse como parte de un paquete de reproducibilidad junto con las fuentes y los prompts?
2. ¿Qué establece el acuerdo de servicio sobre cambios de modelo, deprecaciones y plazos de aviso?
3. ¿Puede un formulario de pedido empresarial reforzar los términos de aviso y fijación de versión en el momento de la firma?

Los plazos de aviso de los proveedores varían considerablemente. El análisis de los términos de los proveedores vigentes indica que OpenAI se compromete a 14 días de aviso para los cambios de modelo, Anthropic y Google a 30 días, y algunos proveedores no se comprometen a ningún plazo.^[6] Estas cláusulas por defecto suelen ser mínimos y no techos; las ventanas de aviso y los compromisos de fijación de versión son genuinamente negociables en el momento de la firma para los clientes empresariales.

El consejo necesita muy poco detalle técnico. Tres propiedades que un consejero no técnico puede verificar son todo lo que importa:

1. ¿Se registra la versión del modelo para cada análisis asistido por IA que nos llega?
2. ¿Se conserva ese registro de una forma que pudiéramos recuperar en un año, si se cuestiona una decisión?
3. ¿Está fijada la versión que hay detrás de un documento determinado, de modo que una nueva ejecución hoy se ejecutaría sobre un estado del sistema conocido y concreto?

El detalle técnico – arquitectura transformer, número de parámetros, puntuaciones en pruebas comparativas – corresponde a un nivel inferior, al secretario del consejo o a la función de auditoría. Los consejos ya confían en modelos de valoración, supuestos actuariales y métodos de muestreo estadístico cuyo funcionamiento interno la mayoría de los consejeros no puede reconstruir. La versión del modelo es el mismo tipo de dato: un estado del sistema concreto y fechado al que se puede hacer referencia posteriormente, no un mecanismo que el consejo necesita entender.

La tarea del secretario del consejo o de la función de auditoría es confirmar, una vez al año, que la disciplina de registro de versiones se está aplicando y que al menos un análisis significativo del año anterior puede reproducirse en la versión con la que se generó.

Este ejemplo es ilustrativo. Un comité de inversión de una empresa de capital privado aprueba un análisis de operaciones asistido por IA en el primer trimestre. La portada incluye la línea de divulgación: nombre de la plataforma, versión del modelo y fecha de generación. Se archiva un paquete de reproducibilidad con el expediente de la operación.

En el segundo trimestre, la plataforma actualiza su modelo subyacente. La revisión de gobernanza realiza tres comprobaciones:

1. ¿El análisis del primer trimestre aprobado sigue siendo reproducible en la versión fijada? Si el proveedor ya la ha deprecado, el paquete de reproducibilidad pasa a ser el único registro de lo que se aprobó.
2. ¿Alguna nueva ejecución del segundo trimestre con el nuevo modelo cambia una conclusión material? Si es así, el punto se señala para una nueva aprobación con los resultados antiguos y nuevos en paralelo.
3. ¿Los términos de aviso del proveedor dieron al equipo tiempo suficiente para probar la nueva versión antes de depender de ella? Si no es así, los términos del contrato deben revisarse en la renovación.

El resultado es una de dos breves notas al comité: o el análisis aprobado no se ve afectado y el artefacto del primer trimestre está archivado, o el punto se señala para una nueva aprobación. Ninguna de las dos requiere que el comité entienda los detalles técnicos del cambio de modelo.

Las plataformas diseñadas para el trabajo estratégico a nivel de consejo, como Decisity, tratan la trazabilidad de fuentes y la auditabilidad como requisitos de diseño fundamentales, de modo que la adjunción de la versión y el paquete de reproducibilidad se producen como parte del flujo de trabajo estándar y no como una tarea documental retrospectiva.

Lecturas relacionadas:

• ¿Quién es responsable cuando una estrategia elaborada con IA sale mal?
• Cláusulas de confidencialidad que exigir a un proveedor de plataforma de IA
• Documentos confidenciales y herramientas de estrategia de IA: qué verificar
• Presentar un análisis estratégico asistido por IA a un consejo escéptico

• ISS-Corporate vía Harvard Law School Forum on Corporate Governance: La gobernanza de la IA aparece en el radar corporativo (abril de 2024)
• Ley de Inteligencia Artificial de la UE: Artículo 50, Obligaciones de transparencia
• GPR-bench: Pruebas de regresión para sistemas de IA generativa
• IBM: ¿Qué es la desviación del modelo?
• The Neural Base: Cómo las actualizaciones de los modelos cambian el comportamiento de la IA
• Digital Applied: Calendarios de precios de IA y compromisos débiles en la contratación