Proof-of-Control de Advanced AI Society abre un nuevo frente en la seguridad de agentes
Advanced AI Society lanzó Proof-of-Control para revisión pública el 17 de septiembre, pese a que persisten interrogantes sin resolver sobre la versión, el alcance y el grado de preparación del borrador. El estándar propuesto pide a los agentes de IA que generen evidencia resistente a manipulaciones que demuestre que cada acción controlada se mantuvo dentro de sus límites autorizados. También aleja la seguridad de los agentes de la confianza en los registros privados de un proveedor.
Este cambio importa porque los agentes están dejando atrás la mera generación de texto. Pueden invocar herramientas, acceder a registros, modificar software, comunicarse con servicios externos e iniciar transacciones. Una auditoría trimestral no puede observar cada decisión a medida que ocurre, mientras que un registro controlado por el operador del agente puede ofrecer garantías independientes limitadas.
Advanced AI Society afirma que más de 80 líderes de seguridad contribuyeron a dar forma a su enfoque. El grupo está situando el trabajo dentro de Linux Foundation Decentralized Trust, lo que proporciona al proyecto un espacio neutral para la gobernanza técnica. Sin embargo, una gobernanza neutral no completa un borrador, ni la evidencia criptográfica garantiza que una organización haya seleccionado los controles adecuados.
El Congreso está abordando el mismo problema desde otra dirección. Una propuesta bipartidista de la Cámara de Representantes ordenaría al NIST desarrollar prácticas de seguridad para agentes que abarquen la verificación continua, la evaluación de seguridad, los inventarios y los registros resistentes a manipulaciones. La convergencia entre estándares abiertos voluntarios y requisitos respaldados por el gobierno constituye la verdadera noticia.
Proof-of-Control de Advanced AI Society es más que un anuncio de afiliación
El cambio importante es el lanzamiento de una propuesta verificable de inspección para agentes, no el titular sobre la afiliación que la rodea.
Advanced AI Society describió su anuncio de septiembre como su incorporación a Linux Foundation y LF Decentralized Trust. Sin embargo, los registros de Linux Foundation muestran que la organización se convirtió en miembro asociado de LF Decentralized Trust el 21 de abril de 2026. Por tanto, el anuncio más reciente combina un avance previo de afiliación con la presentación pública de Proof-of-Control y su laboratorio asociado.
Esta distinción importa. La afiliación sitúa a una organización dentro de una red colaborativa, pero no valida cada afirmación o diseño técnico que publique. La acción relevante es llevar un estándar de verificación propuesto a un entorno de fundación donde colaboradores externos puedan inspeccionarlo, cuestionarlo y ampliarlo.
El registro de afiliación de abril identifica a Advanced AI Society como uno de dos nuevos miembros asociados. El aviso de lanzamiento de septiembre presenta Proof-of-Control como un laboratorio de LF Decentralized Trust e invita a comentarios públicos.
Proof-of-Control se articula en torno a una pregunta directa: ¿puede una parte independiente verificar que un agente de IA se mantuvo dentro de los controles asignados? Un control podría impedir que un agente transfiera dinero sin aprobación, restringir los registros de clientes a los que puede acceder o limitar las herramientas disponibles durante una tarea.
La propuesta se centra en el límite de acción, el punto en el que un agente intenta invocar una herramienta o crear un efecto externo. Su arquitectura sitúa una puerta de enlace de interceptación independiente en ese límite. La puerta de enlace evalúa la acción propuesta, bloquea las acciones que quedan fuera de la política declarada y emite evidencia sobre la decisión.
Este diseño es más específico que las promesas convencionales sobre IA responsable. Describe dónde se aplica el control, qué evidencia debe producirse y cómo otra parte podría verificarla. Advanced AI Society también identifica seis ámbitos de verificación: procedencia, privacidad, portabilidad, autorización, identidad y seguridad.
La idea central del marco es que el registro de ejecución de un agente sigue siendo una afirmación cuando el mismo operador controla tanto la ejecución como la conservación de los registros. Un sistema comprometido podría omitir una acción, reescribir un registro o eludir el registro. Por tanto, un mecanismo de verificación útil debe revelar alteraciones e identificar los supuestos de los que depende su evidencia.
El proyecto propone varios niveles de garantía. Los niveles inferiores dependen de las afirmaciones del operador o del acceso de un auditor. Los niveles superiores buscan registros verificables de forma independiente o puertas de ejecución que impidan una acción controlada sin la evidencia correspondiente.
Esto crea una distinción significativa entre observar una acción y restringirla. Un registro resistente a manipulaciones puede ayudar a los investigadores a establecer qué se registró tras un incidente. Una puerta de ejecución correctamente implementada puede impedir una acción cubierta cuando fallan sus condiciones de autorización.
Proof-of-Control no pretende determinar si el modelo subyacente es seguro, preciso o está alineado. Tampoco decide si una empresa otorgó demasiada autoridad a un agente. Busca establecer si los controles declarados rigieron las acciones incluidas dentro de un alcance determinado.
Este objetivo más limitado es una fortaleza porque ofrece a los implementadores algo que se puede probar. También es el origen de la mayor limitación del proyecto. La evidencia de que un agente siguió una política débil solo demuestra el cumplimiento de esa política débil.
El Congreso está convirtiendo la verificación de agentes en una cuestión de contratación pública
La seguridad de los agentes está pasando de ser una preferencia técnica a una condición para hacer negocios con compradores regulados y el gobierno federal.
La propuesta Stop Rogue AI Act ordenaría al National Institute of Standards and Technology publicar estándares, directrices y mejores prácticas para el despliegue seguro de agentes. Según los detalles del proyecto de ley reportados, el trabajo abarcaría inventarios continuos de agentes, evaluaciones de seguridad, registros resistentes a manipulaciones y verificación de las acciones de los agentes.
La propuesta procede de los representantes Josh Gottheimer, demócrata de Nueva Jersey, y Mike Lawler, republicano de Nueva York. La mayoría de las organizaciones utilizarían voluntariamente las prácticas resultantes del NIST. Los contratistas federales que compitan por nuevos trabajos afrontarían una presión mayor para cumplirlas.
Este mecanismo importa más que una declaración regulatoria amplia. Los requisitos de contratación pública pueden influir en los mercados tecnológicos sin imponer una arquitectura obligatoria a todas las organizaciones privadas. Los proveedores suelen adoptar controles orientados al gobierno en todos sus productos porque mantener sistemas de seguridad independientes incrementa el coste y la complejidad.
El NIST ya trabajaba en este ámbito antes de que surgiera la propuesta de la Cámara de Representantes. En febrero, la agencia anunció una iniciativa de estándares para agentes que abarca interoperabilidad, identidad, autorización y seguridad. También solicitó aportaciones de organizaciones desplegadoras, desarrolladores, investigadores y proveedores de infraestructura.
La coincidencia con Proof-of-Control es clara. Ambos esfuerzos se centran en la identidad persistente, la autoridad definida, las acciones observables y la evidencia que sobrevive fuera de la propia narrativa del agente. Ambos reconocen también que los agentes interactúan con sistemas existentes mediante herramientas, credenciales e interfaces de servicio.
Sus funciones siguen siendo distintas. El NIST desarrolla directrices mediante un proceso federal de estándares y puede influir en las expectativas de contratación pública. Advanced AI Society propone un estándar orientado a la implementación a través de una comunidad abierta y busca que se desarrollen herramientas de verificación independientes a su alrededor.
La propuesta de la Cámara de Representantes genera presión sobre tres grupos. Los proveedores de agentes deben explicar cómo sus sistemas identifican a cada agente y restringen sus permisos. Las empresas que los despliegan deben mantener inventarios y determinar qué sistemas pueden realizar acciones relevantes. Los proveedores de seguridad deben generar evidencia que evaluadores externos puedan examinar.
Los contratistas federales afrontan el mecanismo de presión potencial más claro. Un proveedor podría considerar opcional la verificación abierta mientras vende en mercados comerciales convencionales. Esa postura se vuelve más difícil de mantener cuando un comprador importante exige inventarios legibles por máquinas, registros continuos y controles comprobables de forma independiente.
Las aseguradoras y los auditores crean otra fuente de presión. Una aseguradora que evalúa a un agente capaz de iniciar pagos necesita más que un documento de política. Necesita evidencia que muestre qué identidad actuó, qué autoridad existía, qué control evaluó la solicitud y si el registro resultante se mantuvo intacto.
La misma cuestión aparece en la atención sanitaria. Un agente puede recuperar historiales médicos, resumir un caso o preparar una orden. Un hospital debe distinguir entre confirmar la integridad del registro y confirmar que la decisión clínica fue adecuada. Proof-of-Control aborda lo primero, mientras que la gobernanza y la revisión profesional siguen determinando lo segundo.
Los desarrolladores notarán el cambio en los puntos de integración. La seguridad ya no puede terminar con la protección de un endpoint de modelo. Los equipos deben tener en cuenta las credenciales, los permisos de herramientas, las cadenas de delegación, el acceso a los datos y los efectos secundarios en cada servicio al que pueda llegar un agente.
Por eso la seguridad de los agentes se está convirtiendo en una cuestión de contratación pública, en lugar de una comparación de funcionalidades. Los compradores necesitan evidencia que siga siendo significativa entre distintos proveedores. Los paneles propietarios ayudan a los operadores a gestionar sus propios sistemas, pero no crean automáticamente un lenguaje compartido de garantía para auditores, aseguradoras, reguladores y clientes.
La verificación abierta cuestiona los registros controlados por proveedores
La principal disputa enfrenta la evidencia portátil de terceros con los registros de seguridad que siguen bajo el control del proveedor evaluado.
Los registros empresariales tradicionales no son inútiles. Sirven para la respuesta a incidentes, la monitorización, la depuración y el cumplimiento. El problema es que el valor de un registro depende de quién lo generó, de si capturó todas las rutas pertinentes y de si alguien pudo modificarlo después.
Los agentes de IA dificultan estas cuestiones. Sus acciones pueden depender de un contexto cambiante, datos recuperados, resultados del modelo, respuestas de herramientas y permisos delegados. Un sistema puede registrar la invocación final de una herramienta sin conservar suficiente contexto para establecer por qué la invocación fue autorizada.
Proof-of-Control propone evidencia generada durante la ejecución, no reconstruida después de un incidente. También busca registros portátiles que distintas partes puedan interpretar sin obtener acceso privilegiado a todo el entorno del operador.
La visión general del estándar publicada por el proyecto describe la evidencia como binaria, contemporánea, resistente a manipulaciones y transparente respecto a los supuestos de confianza residuales. Binaria significa que la acción controlada se mantuvo dentro del límite declarado o no lo hizo. No significa que el resultado más amplio fuera correcto.
Considere un agente de compras autorizado a realizar pedidos por debajo de un límite definido por la empresa. La capa de verificación podría registrar la identidad del agente, la autoridad delegada, el importe evaluado y el resultado de la política. También podría rechazar un pedido que supere ese límite.
Sin embargo, la evidencia no establecería que la compra fuera necesaria, que el proveedor tuviera buena reputación o que el precio representara una buena relación calidad-precio. Son juicios empresariales independientes. La verificación muestra si se respetó un control explícito, no si la organización diseñó un control sensato.
Esta separación es esencial porque el lenguaje de seguridad suele fusionar varias afirmaciones diferentes. Un proveedor puede describir a un agente como seguro porque cuenta con permisos, registros de auditoría y opciones de aprobación humana. Esas características no demuestran que no exista una vía de elusión ni que toda acción relevante pase por el punto de control.
La pasarela propuesta por Proof-of-Control para interceptar acciones busca resolver ese problema. Se sitúa fuera del proceso del agente y media las llamadas controladas a herramientas. Para que la arquitectura funcione, el agente no debe disponer de ninguna ruta alternativa de credenciales o red que eluda la pasarela.
Esa condición de imposibilidad de elusión es difícil de cumplir. Los entornos de software modernos contienen cuentas de servicio, credenciales almacenadas en caché, procesos en segundo plano, complementos y rutas directas de red. Un verificador debe probar el sistema circundante, no limitarse a inspeccionar la salida de la pasarela.
La propuesta también introduce compromisos en materia de privacidad. Las evidencias de verificación deben aportar información suficiente para respaldar una conclusión significativa sin exponer prompts, registros personales, pesos del modelo ni datos empresariales propietarios. Las afirmaciones criptográficas pueden reducir la divulgación, pero su utilidad depende de la calidad de la medición y la implementación subyacentes.
La portabilidad plantea otro desafío. Dos proveedores pueden utilizar lenguajes de políticas, sistemas de identidad, entornos de ejecución y formatos de registro diferentes. Un esquema compartido de evidencias puede normalizar parte de esa variación. No puede eliminar todas las diferencias en la forma en que se definieron o aplicaron los controles originales.
La gobernanza abierta ofrece una respuesta creíble a esta fragmentación. Las especificaciones públicas, los vectores de prueba, el código de referencia y los modelos de amenazas documentados brindan a compradores e investigadores material que pueden inspeccionar. Un programa de aseguramiento controlado por un proveedor puede divulgar menos información y cambiar sin acuerdo externo.
La Linux Foundation proporciona la infraestructura institucional para este trabajo. Puede respaldar la gobernanza comunitaria, las reglas de propiedad intelectual, los procesos de contribución y la administración a largo plazo. No certifica que el diseño haya resuelto la contención de agentes ni la adopción empresarial.
Ese límite debe permanecer visible. El alojamiento en una fundación demuestra que un proyecto cuenta con un espacio para colaborar. No demuestra que cada implementación cumpla, que cada prueba sea completa ni que los clientes acepten los registros resultantes.
El Borrador Ya Muestra Por Qué Importa la Revisión Independiente
Las primeras inconsistencias de Proof-of-Control revelan la diferencia entre lanzar un estándar y consolidarlo.
El anuncio de Advanced AI Society de septiembre denomina al lanzamiento un “v1.0 working draft” y afirma que los comentarios públicos seguirán abiertos hasta el 30 de octubre de 2026. Su página más detallada sobre el estándar identifica el documento como “Working Draft v0.1” y fija como fecha límite para comentarios el 7 de octubre.
La descripción del evento de la Linux Foundation también lo denomina Proof-of-Control v0.1. Estas diferencias pueden reflejar publicaciones no sincronizadas, un cambio en el plan de lanzamiento o etiquetas distintas para artefactos relacionados. Sea cual sea el motivo, la ambigüedad sobre la versión y el plazo es relevante para quienes deciden qué revisar.
Un estándar depende de identificadores estables. Los implementadores necesitan saber qué requisitos normativos aplican, si un vector de prueba coincide con el texto vigente y cuándo se produjo un cambio incompatible. Los auditores no pueden evaluar la conformidad frente a una etiqueta cambiante.
Esto no invalida el objetivo del proyecto. Demuestra por qué son importantes los repositorios neutrales, las etiquetas de lanzamiento, los registros de cambios y el seguimiento público de incidencias. Un estándar abierto debe hacer verificable su propia procedencia antes de pedir a los proveedores de agentes que hagan lo mismo.
La sesión informativa pública prevista para el 23 de septiembre reúne a líderes de la Linux Foundation, representantes de Advanced AI Society, inversores en seguridad, proveedores de identidad, aseguradoras y la Agentic AI Foundation.
Ese evento puede aclarar la gobernanza, pero el debate público por sí solo no resolverá la incertidumbre técnica. Los colaboradores necesitan una especificación normativa, un modelo de amenazas explícito, pruebas de conformidad e implementaciones reproducibles. También necesitan un proceso para decidir qué mecanismos satisfacen cada requisito.
El proyecto afirma que su repositorio incluye una implementación de referencia, definiciones de afirmaciones legibles por máquina, escenarios de ataque y vectores de prueba firmados. Describe la implementación como una referencia, no como un producto de producción. Esa advertencia es importante porque el código inicial puede demostrar viabilidad sin cumplir los requisitos de seguridad operativa.
Una pasarela de referencia puede mostrar cómo evaluar una política y generar evidencias firmadas. Una pasarela de producción también debe resistir el robo de credenciales, las condiciones de carrera, los intentos de repetición, la telemetría incompleta, el compromiso de claves, las fallas de infraestructura y los operadores hostiles.
La completitud plantea otro problema difícil. Los registros a prueba de manipulaciones pueden demostrar que las entradas registradas no fueron alteradas. No pueden, por sí solos, demostrar que cada acción relevante entró en el registro. Un agente con una ruta no supervisada podría actuar fuera del registro mientras la cadena de evidencias visible mantiene coherencia interna.
El nivel más sólido propuesto por Advanced AI Society aborda esto mediante el control de la ejecución. Bajo ese modelo, una acción cubierta no puede producirse a menos que pase por el control y genere evidencia. La cuestión pendiente es si toda acción relevante está realmente cubierta.
Los efectos externos también complican el panorama. Una pasarela puede verificar que un agente envió una solicitud de pago autorizada. No puede demostrar automáticamente que un banco liquidó el pago exactamente como se esperaba. El aseguramiento debe conectar la evidencia del lado del agente con los comprobantes de sistemas externos.
Las cadenas de identidad introducen riesgos similares. Un agente puede delegar trabajo en otro, que después llama a un servicio de terceros. Cada transferencia puede cambiar la autoridad, el contexto o la exposición de datos. Un estándar creíble debe preservar la atribución sin asumir que un único token de identidad explica toda la cadena.
La calidad del control sigue siendo la mayor limitación conceptual. Proof-of-Control evita explícitamente juzgar si una regla elegida fue prudente. Esa separación hace manejable la conformidad técnica, pero las organizaciones pueden presentar la conformidad como una evidencia más amplia de seguridad.
Los compradores deberían resistirse a ese atajo. Un agente verificado puede seguir fielmente una política insegura. También puede generar acciones autorizadas basadas en un razonamiento incorrecto del modelo. La verificación en tiempo de ejecución complementa las pruebas, la supervisión humana, el análisis de riesgos y la respuesta a incidentes. No los sustituye.
Por ello, la afirmación más responsable del proyecto es la limitada. Busca mejorar la evidencia sobre si los controles declarados gobernaron las acciones cubiertas. Las afirmaciones sobre seguridad completa de los agentes, cumplimiento normativo o eliminación de responsabilidad superarían lo que esa evidencia establece.
El Estándar Debe Demostrar que Funciona en Pilas Reales de Agentes
La adopción dependerá de si Proof-of-Control puede operar entre modelos alojados, sistemas locales y flujos de trabajo de múltiples proveedores sin crear otra capa aislada de cumplimiento.
Las pilas empresariales de agentes rara vez proceden de un solo proveedor. Una empresa puede utilizar un modelo alojado, un marco interno de orquestación, un proveedor externo de identidad, bases de datos en la nube y herramientas especializadas de varios proveedores. Cada capa expone controles y telemetría distintos.
Proof-of-Control afirma que su modelo de límites de acción puede funcionar en configuraciones abiertas y cerradas. El proveedor del modelo no necesita necesariamente revelar sus pesos ni sus datos de entrenamiento. En su lugar, la capa de verificación observa las acciones controladas cuando el sistema de orquestación invoca capacidades externas.
Este enfoque favorece a las organizaciones que controlan su propio bucle de agentes. Pueden insertar una pasarela, restringir credenciales y dirigir las llamadas a herramientas a través de un límite definido. Un servicio de agentes gestionado es más difícil porque el proveedor controla el entorno de orquestación y decide qué evidencias exponer.
Esta diferencia convierte la arquitectura en un criterio de compra. Los clientes que evalúan un agente gestionado deben preguntar si emite evidencias verificables de forma independiente, si las evidencias cubren cada llamada relevante a herramientas y si un operador puede eludir la ruta declarada.
Un equipo financiero ofrece una prueba concreta. Supongamos que un agente prepara facturas, actualiza registros contables e inicia transferencias bancarias. El sistema de verificación debe distinguir entre leer un libro mayor, proponer un pago, obtener aprobación y enviar la instrucción final.
Cada acción necesita una identidad, una fuente de autoridad, una política aplicable, una referencia temporal y un resultado. El sistema debe preservar esa cadena entre herramientas sin filtrar datos de cuentas a un registro público de verificación. También debe gestionar una aprobación revocada o un cambio de política durante la ejecución.
Un agente de ingeniería de software plantea una prueba distinta. Puede inspeccionar código privado, modificar archivos, ejecutar pruebas y solicitar un despliegue. Proof-of-Control podría verificar a qué repositorio accedió el agente y si el despliegue requirió una aprobación identificada.
El estándar aún tendría que contemplar efectos indirectos. El código que supera una puerta de autorización puede posteriormente exponer datos o alterar el comportamiento de producción. La evidencia en tiempo de ejecución muestra cómo el agente cruzó un límite, mientras que la revisión de software y las pruebas de seguridad evalúan el artefacto que produjo.
El sector sanitario pone a prueba la privacidad y la autoridad profesional. Un agente podría recuperar el historial de un paciente bajo delegación de un profesional clínico y enviar una orden preliminar para su aprobación. La evidencia debe demostrar que el acceso se mantuvo dentro de la autorización sin divulgar la información médica subyacente.
Estos escenarios requieren más que un registro genérico firmado. Necesitan semánticas comunes para identidades, permisos, evaluación de políticas, retención de evidencias y comportamiento ante fallos. Un registro que un verificador interpreta de forma distinta a otro no crea interoperabilidad.
Por tanto, las pruebas de conformidad determinarán la credibilidad del proyecto. Equipos independientes deberían poder ejecutar el mismo conjunto de pruebas contra implementaciones distintas y obtener resultados coherentes. Las pruebas negativas deberían mostrar cómo fallan los sistemas cuando se alteran registros, las acciones eluden la pasarela o la autoridad expira.
El rendimiento también importará. Los agentes suelen realizar varias llamadas a herramientas durante una tarea. La generación continua de evidencias añade trabajo de firma, almacenamiento, verificación y evaluación de políticas. Las empresas necesitarán datos de latencia y operación procedentes de implementaciones representativas.
Los materiales públicos de Proof-of-Control hacen hincapié en la verificación a velocidad de máquina porque la revisión humana no puede igualar la ejecución de los agentes. Esa premisa es razonable, pero la automatización también puede repetir una regla defectuosa a velocidad de máquina. Por tanto, los cambios en los controles deben gobernarse con el mismo cuidado que los cambios de código.
La propiedad operativa es otra cuestión abierta. Los equipos de seguridad pueden definir políticas de referencia, los equipos de aplicación pueden integrar pasarelas, los equipos de identidad pueden gestionar la delegación y los equipos de cumplimiento pueden conservar las evidencias. Un estándar que presuponga un único propietario unificado tendrá dificultades dentro de grandes organizaciones.
El proyecto aún puede tener éxito sin convertirse en el único estándar de seguridad para agentes. Su modelo de evidencias podría informar las directrices de NIST, las API de proveedores, los cuestionarios de seguros o las plantillas de contratación. Los conceptos compartidos pueden influir en el mercado incluso cuando las implementaciones varían.
El riesgo mayor es la adopción ceremonial. Los proveedores pueden afirmar alineación mientras cubren solo acciones seleccionadas o utilizan el lenguaje de la verificación abierta sin proporcionar pruebas independientes. Los niveles claros de conformidad y los requisitos verificables por máquina pueden reducir ese comportamiento.
Tres Señales Determinarán si la Verificación Abierta se Convierte en Infraestructura
Las próximas tres pruebas son la coherencia de la especificación, la implementación independiente y la adopción regulatoria.
La primera señal será si Advanced AI Society resuelve los conflictos del borrador sobre versiones y plazos para comentarios. Una etiqueta de lanzamiento pública debería vincular el texto normativo, los esquemas, los vectores de prueba, la implementación de referencia y el historial de cambios.
Ese paso reforzaría el argumento central del proyecto. La procedencia verificable debería comenzar por el propio estándar. Si los artefactos siguen etiquetados de forma inconsistente, las empresas dudarán antes de diseñar controles o contratos a su alrededor.
La segunda señal es la implementación independiente. El código de referencia de la organización fundadora puede demostrar que sus autores construyeron lo que describieron. Un equipo separado debe demostrar que la especificación comunica suficiente detalle para producir evidencias y resultados de verificación compatibles.
Los informes de implementación útiles deben documentar tanto los fallos como los éxitos. Deben identificar la latencia, la carga de integración, los marcos de agentes no compatibles, las restricciones de privacidad y cualquier vía de elusión detectada durante las pruebas. Las afirmaciones sobre producción necesitan pruebas procedentes de entornos fuera del control directo de los autores.
La tercera señal es cómo NIST y el Congreso definen los requisitos de verificación de agentes. Si las directrices federales solicitan inventarios continuos, registros resistentes a manipulaciones, identidades atribuibles y controles verificables de forma independiente, Proof-of-Control atenderá una necesidad de contratación pública reconocible.
El proyecto ganaría aún más impulso si contratistas federales o compradores regulados solicitaran evidencias portables en lugar de capturas de pantalla de proveedores. Ese requisito premiaría la interoperabilidad y abriría espacio para múltiples proveedores de verificación.
El resultado contrario debilitaría el argumento a favor de un ecosistema compartido. Las agencias podrían aceptar registros convencionales y auditorías periódicas, o el Congreso podría no lograr avanzar la legislación subyacente. En ese caso, las empresas podrían tratar la verificación abierta como un experimento de seguridad opcional.
El debate más amplio de Washington sobre la IA sigue sin resolverse. Los líderes del Congreso han hablado de salvaguardas y, al mismo tiempo, han enfatizado un enfoque regulatorio ligero y la competencia con China. Esa tensión hace más plausibles los estándares técnicos específicos que una ley integral sobre IA.
La distinción entre legislación y promulgación debe mantenerse clara. La propuesta de la Cámara de Representantes sobre seguridad de agentes no es una política federal establecida. La iniciativa existente de NIST está activa, pero sus directrices finales y sus efectos en el mercado aún están en desarrollo.
Por lo tanto, Advanced AI Society tiene una ventana limitada para influir en el vocabulario emergente. Si logra demostrar controles implementables antes de que se endurezcan las normas de contratación, sus definiciones podrían moldear la forma en que los compradores describen la garantía en tiempo de ejecución.
Los desarrolladores deberían observar si los marcos de agentes comunes incorporan soporte nativo para evidencias portables. Los compradores empresariales deberían pedir a los proveedores que identifiquen cada acción controlada y cualquier ruta que eluda la aplicación de controles. Los equipos de seguridad deberían comparar la integridad de la evidencia con su completitud.
Los trabajadores del conocimiento también tienen interés en ello. Un agente que actúa sobre el correo electrónico, los documentos, el calendario o las cuentas financieras de una persona puede generar consecuencias antes de que el usuario las revise. Los usuarios necesitan un registro comprensible de la autoridad que concedieron y de lo que el agente hizo con ella.
La iniciativa Proof-of-Control de Advanced AI Society ofrece una respuesta seria a esa necesidad, pero sigue siendo un borrador inicial. Su valor dependerá de una interoperabilidad probada, un alcance preciso y evidencias que resistan el escrutinio de partes distintas de sus creadores.
El siguiente paso adecuado no es asumir que el estándar resuelve la seguridad de los agentes. Compradores y desarrolladores deberían examinar el borrador, probar el requisito de imposibilidad de elusión y enviar fallos concretos de implementación durante la revisión pública. La verificación abierta solo se convierte en infraestructura cuando participantes independientes pueden reproducir sus afirmaciones e identificar sus límites.
