Gobernanza de IA: cuándo revisar autorizaciones y controles

Una empresa autoriza un asistente de inteligencia artificial para preparar propuestas de compra. Meses después, el mismo sistema consulta inventario y correo, conserva memoria sobre proveedores y puede confirmar pedidos dentro de un límite económico. El producto puede seguir llamándose igual; la capacidad que la organización ha autorizado ya no es la misma.

Éste es uno de los problemas prácticos de la gobernanza de la inteligencia artificial y cumplimiento: una aprobación inicial deja de ser suficiente cuando cambian las funciones, los permisos, la supervisión o las dependencias que hacen posible la operación. Gobernar no consiste en revisar cualquier ajuste, sino en distinguir qué puede evolucionar dentro de límites conocidos y qué cambio exige reabrir una decisión.

Proponemos tres criterios. Primero, gobernar la configuración real que realiza una función, no únicamente la herramienta contratada. Segundo, autorizar su evolución y diseñar las condiciones de transición, en lugar de confiar indefinidamente en una fotografía inicial. Tercero, comprobar que cada cambio deja a la organización mejor preparada para afrontar el siguiente, no simplemente con más controles.

Llamamos continuidad gobernable a la capacidad de mantener esa relación entre transformación, autoridad, evidencia y corrección. No significa conservar intacta la organización ni someter cada ajuste a una nueva auditoría. Significa establecer qué puede evolucionar, qué condiciones deben permanecer y cómo actuar cuando dejan de cumplirse.

La diferencia es práctica. Un asistente que prepara propuestas plantea otra decisión de gobierno cuando empieza a ejecutarlas. Un piloto sostenido por sus promotores no demuestra todavía que la organización pueda operarlo sin ellos. Una mejora de productividad tampoco acredita, por sí sola, que se haya preservado la capacidad de supervisar, corregir o cambiar de proveedor.

Desde esta perspectiva examinamos las iniciativas de OpenAI, Anthropic, Google DeepMind y Meta, junto con el desarrollo del AI Act. Su interés no termina en la seguridad de los modelos. Permiten plantear una cuestión que afecta a empresas, instituciones y gobiernos: cómo ampliar capacidades sin perder la posibilidad de dirigir, limitar y corregir su transformación.

La IA de frontera está llevando la seguridad del compromiso al diseño institucional

Las iniciativas de 2026 ofrecen motivos para una lectura constructiva. Parte de la discusión está dejando de limitarse a declaraciones de intención y empieza a concretarse en reglas, acceso, pruebas y responsabilidades. Conviene distinguir tres movimientos, porque cada uno resuelve un problema diferente.

El primero es la búsqueda de reglas comunes. El 9 de septiembre, OpenAI pidió regulación nacional obligatoria basada en capacidades, evaluación independiente y estándares internacionales compatibles, incluidos criterios sobre cuándo ralentizar o detener el desarrollo. En su ensayo de septiembre, Dario Amodei plantea acompasar el avance de la frontera con la capacidad de protegerla, combinando compromisos unilaterales, coordinación sectorial y cooperación internacional. Son propuestas empresariales, no un régimen ya implantado ni una posición unánime del sector.¹²

El segundo es la construcción de mecanismos de verificación. El 18 de septiembre, Anthropic anunció una colaboración con Accenture para desarrollar evaluación integrada en el laboratorio, con acceso a procesos de entrenamiento y decisiones de despliegue. Semanas antes, el 27 de agosto, DeepMind presentó un piloto de evaluación externa en un entorno criptográfico que protege tanto las pruebas del evaluador como los pesos del modelo. El avance no consiste solo en evaluar más, sino en diseñar condiciones que hagan más creíble la evaluación.³⁴

Ese movimiento tiene antecedentes. El marco de escalado que Meta publicó el 8 de abril amplió los riesgos evaluados, incorporó pérdida de control y añadió informes sobre seguridad y preparación. Su interés está en vincular capacidades, salvaguardas y decisiones de despliegue.⁵

El tercero es la traducción a autoridad pública. El proyecto presentado en el Senado estadounidense el 24 de septiembre por Warner y Schatz propone un órgano de seguridad y acceso previo al despliegue que comprende modelos, configuraciones y entornos de ejecución. Sigue siendo una propuesta legislativa. En la Unión Europea, las facultades de la Comisión para exigir el cumplimiento de las obligaciones sobre modelos de propósito general son aplicables desde el 2 de agosto de 2026; subsiste el régimen transitorio para modelos introducidos en el mercado antes del 2 de agosto de 2025.⁶⁷

La lectura conjunta es positiva, pero precisa: se están construyendo condiciones para que la seguridad sea verificable y tenga consecuencias. Ninguno de estos anuncios demuestra por sí solo que esas condiciones sean suficientes.

Para las organizaciones usuarias, la consecuencia es inmediata: la evaluación del proveedor constituye una entrada al gobierno de la implantación. No describe, por sí sola, todo lo que ocurrirá cuando esa tecnología se integre en datos, procesos y decisiones propios.

Primera decisión: gobernar la capacidad real, no el nombre de la herramienta

La unidad de gobierno debe coincidir con aquello que realmente puede actuar. Esa unidad no siempre coincide con el producto adquirido, el modelo utilizado o el departamento que aprobó la compra.

El trabajo técnico sobre evaluaciones ya reconoce parte de este desplazamiento. OpenAI explica que, cuando un sistema utiliza herramientas, conserva información entre pasos y actúa dentro de un proceso, su capacidad observada depende también del entorno que organiza esas acciones. Un mismo modelo puede producir resultados distintos con otra memoria, otros mecanismos de recuperación u otras herramientas.⁸

Consideremos un ejemplo hipotético que utilizaremos a lo largo del artículo. Una empresa autoriza un asistente para preparar propuestas de compra. Después lo conecta al inventario, incorpora memoria sobre proveedores y le permite consultar correo. Finalmente habilita la confirmación de pedidos dentro de un límite económico.

El nombre comercial puede seguir siendo el mismo. La capacidad, no. Se han modificado la información disponible, las acciones posibles y el reparto de decisiones entre personas y software.

Ahora supongamos que los pedidos salen correctamente porque una empleada revisa cada noche las excepciones. El indicador de operaciones completadas puede mostrar éxito, mientras la nueva dependencia permanece fuera del análisis. No toda supervisión es una ineficiencia: el problema es desconocer qué parte constituye un control deliberado y qué parte está reparando silenciosamente un diseño insuficiente.

Aquí aparece un límite de la forma de mirar. Compras puede ver un proveedor; tecnología, una integración; cumplimiento, una clasificación; negocio, productividad. Todas esas perspectivas son necesarias. Las fronteras entre departamentos no deberían convertirse en las fronteras de lo que puede observarse.

Para analizar estos cambios proponemos trabajar con cuatro elementos: función, configuración, autoridad y evidencia. La función define qué resultado debe producirse. La configuración identifica cómo se produce. La autoridad determina quién puede aprobar, modificar, limitar o detener. La evidencia permite reconstruir por qué se consideró válido.

Preparar un pedido, aprobarlo y comunicar un compromiso al proveedor son resultados diferentes. Delimitarlos permite aprovechar la automatización sin convertir una mejora técnica en una transferencia tácita de poder de decisión.

Segunda decisión: autorizar la evolución, no solo la fotografía inicial

Una autorización útil debe permitir cambios y reconocer cuándo sus propias razones han dejado de ser suficientes. Esa capacidad de discriminación evita dos extremos: que todo ajuste paralice la operación o que cualquier transformación quede cubierta por una aprobación antigua.

La gestión continua no es un descubrimiento nuevo. El AI Act la contempla en su artículo 9 para los sistemas de alto riesgo, y el AI RMF de NIST también incorpora el ciclo de vida y las interdependencias entre actores. El problema no es sustituir esos marcos, sino hacer que operen sobre una descripción fiel del sistema y de sus cambios.⁹¹⁰

Nuestra propuesta utiliza una envolvente de autorización: el conjunto de usos y transformaciones que una configuración puede experimentar dentro de límites previamente definidos. Su amplitud depende de la función, el riesgo y la capacidad disponible para observar y corregir.

En el ejemplo de compras, ajustar la presentación de una propuesta no equivale a conectarla a una nueva fuente de datos, eliminar una confirmación humana o permitir que el sistema cambie las condiciones de un pedido. Estos cambios requieren decisiones distintas.

Qué cambia	Qué decisión debe poder adoptar la organización
Un aspecto sin efectos relevantes sobre función, riesgo o control	Continuar sin añadir una revisión innecesaria.
Un elemento previsto dentro de los límites autorizados	Verificar las condiciones aplicables y conservar la evidencia necesaria.
La capacidad, los permisos, la supervisión o un riesgo material	Reabrir la autorización en el alcance afectado y determinar pruebas y límites.
La finalidad o el reparto constitutivo de autoridad	Examinar una nueva autorización, una configuración distinta o la retirada.

La diferencia material es aquí un criterio interno de gobierno. No se identifica automáticamente con la modificación sustancial del AI Act ni sustituye su análisis jurídico.

También puede aparecer sin actualización técnica. Si aumenta el volumen hasta impedir la supervisión prevista, la configuración real ha cambiado aunque el software conserve su versión. Si otra persona asume una decisión sin disponer del mismo acceso a la evidencia, el organigrama puede permanecer intacto y la capacidad de control haberse reducido.

La pregunta de revisión es concreta: ¿sigue describiendo nuestra autorización el sistema que está operando?

Reabrir no significa necesariamente reconocer un error pasado. Puede ser la respuesta correcta a una situación nueva. La continuidad exige conservar las condiciones relevantes, no fingir que nada ha cambiado.

La transición necesita gobierno propio antes de que pueda retirarse el apoyo

El paso entre dos formas de trabajar también es una configuración que debe gobernarse. Durante la implantación conviven procesos antiguos, nuevas herramientas, personas aprendiendo y apoyos que todavía no pueden retirarse.

En compras, el piloto puede funcionar porque sus promotores conocen las excepciones y las resuelven informalmente. Si se elimina el procedimiento anterior antes de transferir esa capacidad, la organización pierde una función que el piloto solo aparentaba haber sustituido.

Por eso proponemos vincular el avance a condiciones verificables, no únicamente a fechas. Debe saberse qué función necesita mantenerse, qué apoyo es temporal, qué control debe permanecer y qué prueba autoriza el siguiente paso.

Antes de ampliar la autonomía, por ejemplo, puede comprobarse cómo responde la configuración ante un proveedor no reconocido, una discrepancia entre fuentes o la ausencia del supervisor habitual. Antes de retirar un apoyo extraordinario, puede probarse si otro equipo identifica la excepción, localiza el criterio y activa la autoridad adecuada.

Este diseño también delimita el trabajo jurídico desde el principio: mandato, competencias, uso de datos, contratos, información a los afectados, reclamación y reparación. Las obligaciones concretas dependen del sector y del supuesto; no se resuelven con una plantilla universal.

Reversibilidad tampoco significa prometer que todo podrá deshacerse. Recuperar una versión anterior no retira un mensaje ya enviado ni borra sus consecuencias. Diseñar una salida consiste en conservar opciones reales para contener, sustituir y reparar.

La oportunidad está en intervenir mientras el diseño todavía puede cambiar, antes de que las soluciones provisionales se conviertan en dependencias permanentes.

Los límites deben existir en los permisos y las decisiones, no solo en las políticas

Una restricción material debe tener una expresión operativa. En nuestro diseño, pedir al asistente que no confirme compras sin aprobación no equivale a impedir técnicamente el envío hasta que exista una aprobación válida.

El primer mecanismo depende de una instrucción. El segundo incorpora una condición de paso. Ambos pueden ser complementarios, pero no deberían confundirse al valorar el control.

Esta distinción se aplica también a la autoridad. Un sistema puede detectar que necesita una nueva fuente, proponer una herramienta o recomendar más autonomía. No debe convertir esa propuesta en autorización para ampliar sus propios permisos o eliminar controles.

La evaluación externa plantea una separación semejante. Evaluar, verificar y decidir son funciones diferentes. Un tercero puede producir un informe riguroso sin tener mandato para detener una operación. Una persona puede tener autoridad formal de parada y carecer de información o tiempo para ejercerla.

El anuncio de Anthropic permite concretar el problema. La compañía reconoce que financiará directamente el trabajo de Accenture y que todavía deben desarrollarse estándares sobre acceso, comunicación de resultados y financiación. También afirma que la evaluación no reduce su responsabilidad por los modelos.³

Eso no demuestra por sí solo falta de independencia. Obliga a examinar su diseño: qué puede observar el evaluador, qué limitaciones declara, cómo comunica una conclusión adversa y qué decisión puede activar.

Dentro de una organización, el circuito debería quedar igualmente claro: un hallazgo llega a alguien competente, puede alterar el estado de autorización y desencadena una actuación comprobable. La discrepancia con el promotor no puede desaparecer simplemente porque la implantación esté funcionando comercialmente.

La supervisión humana se vuelve efectiva cuando tiene información, competencia, tiempo, medios y autoridad para intervenir. Añadir un nombre a una matriz no demuestra que esas condiciones existan.

Continuar con menos capacidad puede ser mejor que simular normalidad

Entre operar sin cambios y detener toda la función puede existir una continuación limitada y gobernable. No siempre existe, y nunca debería darse por supuesta.

Esa posibilidad puede diseñarse como un modo de operación reducido y gobernable: conservar una parte de la función con capacidad reducida, controles reforzados, límites temporales y condiciones explícitas de suspensión y recuperación.

Si en compras falla la verificación de destinatarios, podría bloquearse el envío y mantenerse únicamente la preparación de borradores, siempre que pueda justificarse la seguridad de esa función limitada. Si el problema compromete también las fuentes o la fiabilidad de los datos, esa alternativa puede dejar de ser admisible.

La decisión exige definir una configuración mínima gobernable. No describe lo mínimo que necesita el software para funcionar, sino lo que necesita la organización para gobernar esa operación reducida: saber qué está activo, limitar sus permisos, conservar evidencia suficiente y disponer de autoridad y medios para contenerla.

Por debajo de ese mínimo, cambiar la etiqueta de estado no restaura el control. La salida tendrá que ser aislamiento, suspensión, sustitución o retirada, según corresponda.

Este enfoque permite diseñar recuperación en lugar de improvisarla. La operación limitada no es un atajo para posponer una reparación ni una excepción a obligaciones legales. Es una opción que debe probarse, autorizarse y tener un final.

La pregunta deja de ser solamente si el sistema resiste un fallo. Pasa a ser a qué estado gobernable puede dirigirse cuando el fallo aparece.

Tercera decisión: convertir cada cambio en capacidad para gobernar el siguiente

Resolver el episodio no basta si la organización vuelve a encontrarse indefensa ante el mismo mecanismo. El aprendizaje debe modificar decisiones posteriores, no limitarse a aumentar el archivo de incidencias.

Supongamos que, en el caso hipotético, una instrucción incluida en un documento de proveedor altera indebidamente la preparación de un pedido. Corregir ese documento resuelve el caso inmediato. Todavía falta comprobar si otras configuraciones reciben documentos por el mismo canal, comparten permisos o utilizan una regla equivalente.

Una respuesta más completa identifica la vulnerabilidad, acota la familia afectada, introduce la corrección pertinente y comprueba que funciona. Las razones de la decisión quedan accesibles para quien tenga que evaluar otra implantación.

Esa es la diferencia entre archivo y memoria operativa. El archivo conserva lo ocurrido; la memoria operativa permite que lo ocurrido cambie cómo se actúa después.

También importa qué señales llegan al gobierno. Los casi-incidentes, los fallos recuperados a tiempo y las correcciones manuales repetidas pueden mostrar una fragilidad antes del daño. Si informar de buena fe genera automáticamente una respuesta punitiva, la organización puede perder acceso a esas señales. Proteger su comunicación no equivale a eximir fraude, sabotaje o conductas que deban tener consecuencias.

La forma de medir debe acompañar ese cambio. Menos reportes no significa necesariamente más seguridad. Más expedientes cerrados no demuestra mejor resolución. Una reducción de tiempo puede esconder trabajo desplazado a otra persona.

Por eso proponemos observar, antes y después de la intervención, capacidades concretas: detectar diferencias relevantes, reconstruir decisiones, activar límites, corregir y transferir lo aprendido. No hace falta condensarlas en una puntuación universal.

La prueba más reveladora puede ser sencilla: otro equipo recibe una excepción comparable y sabe reconocerla, recuperar el criterio y decidir dentro de su competencia sin reconstruir todo desde cero. Si solo puede hacerlo llamando a quien diseñó la implantación, la transferencia sigue incompleta.

Esto no exige eliminar toda dependencia. El apoyo especializado puede ser necesario y proporcionado. Lo que debe distinguirse es una dependencia explícita y activable de una tutela permanente que nadie había previsto.

La propia gobernanza debe demostrar que mejora la capacidad de decidir

Los instrumentos anteriores pertenecen a una arquitectura de trabajo en desarrollo y contraste, no a una certificación cuya eficacia general pueda darse por demostrada. Su valor debe medirse por las diferencias que permiten reconocer y las decisiones que ayudan a tomar.

Esa exigencia importa porque la gobernanza también puede producir dependencia, opacidad o falsa seguridad. Una envolvente demasiado estrecha puede atascar cambios irrelevantes. Una demasiado amplia puede legitimar transformaciones no examinadas. Un registro exhaustivo puede resultar inútil si nadie recupera de él la razón que necesita.

Antes de ampliar el marco, proponemos probarlo sobre una función real: introducir un cambio controlado, simular un fallo parcial y comprobar si la organización identifica la diferencia, alcanza a la autoridad competente, adopta una respuesta y conserva evidencia útil.

Después hay que comparar el resultado con el punto de partida: calidad de decisión, tiempo, carga humana, recurrencia de errores y capacidad de recuperación. Añadir documentación no constituye por sí mismo una mejora.

Si el marco añade carga sin mejorar esas capacidades, debe corregirse o simplificarse. Gobernar la transformación incluye poder transformar la propia gobernanza.

Para empresas, instituciones y gobiernos, avanzar significa conservar opciones reales

Un laboratorio de frontera, una empresa usuaria y una administración pública no tienen las mismas competencias ni las mismas obligaciones. Las escalas no pueden confundirse. Sí pueden compartir una exigencia de diseño: que el crecimiento de capacidad no borre la posibilidad de atribuir decisiones, contrastarlas, impugnarlas y corregirlas.

Para un consejo de administración, esto propone cambiar la información que solicita. Junto al inventario de herramientas y el balance de productividad, necesita conocer qué funciones se están transformando, qué autoridad se delega, qué dependencias se crean y qué opciones de salida siguen disponibles.

Para quienes diseñan políticas públicas, propone otra comprobación: que los mecanismos de seguridad puedan revisarse y no dependan exclusivamente de los actores evaluados para definir el riesgo, producir la evidencia y determinar las consecuencias. Los requisitos deberían responder a capacidades y riesgos, con proporcionalidad y condiciones de acceso que no conviertan la verificación en una barrera injustificada.

No se trata de elegir abstractamente entre acelerar y frenar. Se trata de construir condiciones bajo las que determinadas capacidades puedan desarrollarse y utilizarse, y de saber reconocer cuándo esas condiciones no están presentes.

Las iniciativas de evaluación, regulación y supervisión ofrecen una oportunidad para hacerlo. Aprovecharla exige llevar su lógica hasta la organización real: allí donde una nueva herramienta modifica quién sabe, quién decide, quién actúa y quién puede corregir.

La ambición no debería ser una organización rodeada de más controles, sino una organización capaz de ampliar lo que hace sin perder el gobierno sobre aquello en lo que se convierte.

En Hipólito & Candomeque desarrollamos una arquitectura jurídica de esa continuidad: funciones y configuraciones, autoridad y evidencia, transiciones y capacidad de corrección. El punto de partida es una operación concreta y una pregunta: ¿qué está cambiando y qué necesitamos conservar para poder dirigir ese cambio?

Footnotes

1. OpenAI, The AI policy window is open. We need to act., 9 de septiembre de 2026. https://openai.com/index/ai-policy-window/ ↩

2. Dario Amodei, We Must Pace the Frontier, septiembre de 2026. https://darioamodei.com/post/we-must-pace-the-frontier ↩

3. Anthropic, Partnering with Accenture on embedded evaluation, 18 de septiembre de 2026. https://www.anthropic.com/news/accenture-embedded-evaluation ↩ ↩²

4. Google DeepMind, Piloting the world’s first double-blind AI evaluations, 27 de agosto de 2026. https://deepmind.google/blog/piloting-the-worlds-first-double-blind-ai-evaluations/ ↩

5. Meta, Scaling How We Build and Test Our Most Advanced AI, 8 de abril de 2026. https://ai.meta.com/blog/scaling-how-we-build-test-advanced-ai/ ↩

6. Oficina del senador Mark Warner, Warner, Schatz to Take to Senate Floor to Demand Passage of New AI Security Legislation, 24 de septiembre de 2026. Fuente primaria del anuncio y de la descripción de la propuesta, no prueba de su aprobación. https://www.warner.senate.gov/newsroom/press-releases/warner-schatz-to-take-to-senate-floor-to-demand-passage-of-new-ai-security-legislation/ ↩

7. Comisión Europea, Guidelines for providers of general-purpose AI models, apartado sobre aplicación y enforcement. Las obligaciones para nuevos modelos son aplicables desde el 2 de agosto de 2025; las facultades de enforcement de la Comisión desde el 2 de agosto de 2026; los modelos introducidos antes del 2 de agosto de 2025 cuentan con transición hasta el 2 de agosto de 2027. https://digital-strategy.ec.europa.eu/en/policies/guidelines-gpai-providers ↩

8. OpenAI, A shared playbook for trustworthy third party evaluations, apartados sobre configuración de las evaluaciones y entorno de ejecución. https://openai.com/index/trustworthy-third-party-evaluations-foundations/ ↩

9. Reglamento (UE) 2024/1689, artículo 9.2: gestión de riesgos como proceso iterativo continuo durante el ciclo de vida. Se cita este contenido, no un calendario general de exigibilidad de todos sus requisitos. https://eur-lex.europa.eu/eli/reg/2024/1689/oj/spa ↩

10. NIST, AI RMF Core, apartados 5, 5.1 y 5.2, sobre gestión continua, gobernanza transversal e interdependencias. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/ ↩