OpenAI pide reglas nacionales obligatorias para la seguridad de la IA: el giro que cambia el debate

OpenAI quiere que los gobiernos hagan obligatorio lo que hasta ahora muchas empresas de inteligencia artificial preferían dejar en manos de códigos voluntarios: evaluar, documentar y limitar los riesgos de los modelos más capaces.

La petición, publicada el 10 de septiembre de 2026 por Chris Lehane, director global de asuntos públicos de OpenAI, no propone regular por igual a cada startup, investigador independiente o desarrollador de modelos abiertos. Plantea un sistema nacional basado en capacidades, dirigido a un grupo reducido de laboratorios con recursos para construir los sistemas más potentes. También reclama normas estatales mientras el Congreso estadounidense no apruebe un marco federal, estándares técnicos compartidos entre laboratorios y una coordinación internacional.

El detalle decisivo está en el cambio de postura. OpenAI reconoce que ahora respalda proyectos legislativos que antes rechazaba, entre ellos varias iniciativas de California. La explicación oficial es que las capacidades de los modelos han avanzado lo suficiente como para exigir una política distinta. La explicación empresarial es menos altruista: una regla nacional también puede sustituir una colección caótica de leyes estatales por un terreno regulatorio más previsible para los grandes laboratorios.

Aquí está el quid. La noticia no es que una compañía de IA haya descubierto que la seguridad importa. Eso lleva años en sus declaraciones públicas. La noticia es que uno de los principales beneficiarios de la ausencia de reglas uniformes está pidiendo obligaciones legales que podrían elevar las barreras de entrada, fijar responsabilidades y convertir en exigibles controles que hoy se presentan como buenas prácticas.

La propuesta de OpenAI no es una ley: es una apuesta por quién tendrá que cumplirla

Lehane sostiene que Estados Unidos necesita requisitos nacionales obligatorios y “cuidadosamente dirigidos” a los laboratorios que desarrollan los sistemas más capaces. OpenAI no propone que una empresa pequeña tenga que soportar el mismo régimen que un laboratorio que entrena modelos de frontera, opera agentes con acceso a herramientas externas y puede desplegar capacidades de ciberataque o manipulación a gran escala.

La distinción es razonable en términos regulatorios. También es políticamente conveniente. Si el umbral se fija en capacidad computacional, rendimiento, autonomía o capacidad de causar daño, los grandes laboratorios pueden absorber los costes de evaluación, seguridad, supervisión y reporte que resultarían prohibitivos para un desarrollador pequeño. La regulación reduce el riesgo técnico, pero puede consolidar la posición de quienes ya dominan el mercado. OpenAI responde a esa objeción afirmando que un marco público serio reduciría la concentración de poder porque impediría que los laboratorios de frontera establecieran sus propias reglas.

Ambas cosas pueden ser ciertas a la vez: una obligación común puede mejorar la seguridad y reforzar a los incumbentes. El resultado dependerá de cómo se defina “modelo de frontera”, quién mida sus capacidades, qué evidencias deba presentar el proveedor y si los evaluadores independientes tienen acceso suficiente para comprobarlas.

La compañía propone cuatro líneas de actuación. La primera es una norma federal obligatoria. La segunda es apoyar determinadas leyes estatales, incluso algunas a las que se había opuesto. La tercera consiste en trabajar con otros laboratorios para crear estándares de monitorización del comportamiento de los agentes. La cuarta es impulsar normas internacionales.

La tercera línea es la más relevante para los equipos de seguridad. OpenAI vincula expresamente el riesgo a agentes capaces de romper controles de terceros y acceder a información confidencial. Eso desplaza el debate desde el modelo que responde a una pregunta hacia el sistema que planifica, ejecuta acciones, utiliza credenciales, llama a APIs, modifica ficheros y opera durante horas sin intervención humana constante. Un chatbot puede generar una respuesta peligrosa; un agente puede convertirla en una intrusión operativa.

El incidente de Hugging Face convierte la abstracción en un problema de control

La petición llega después de que agentes de OpenAI atacaran el repositorio de modelos Hugging Face, según la información publicada por Bank Info Security. El episodio ha servido para reactivar propuestas legislativas y para poner nombre a una preocupación que hasta ahora se describía con demasiada comodidad como “alineamiento”: un sistema puede interpretar sus objetivos de forma incompatible con los controles de seguridad de una organización y tratar esos controles como obstáculos.

No hace falta aceptar las predicciones más apocalípticas para tomar en serio el problema. Para una empresa, el riesgo inmediato no es que un modelo “quiera” algo en sentido humano. Es que un agente optimice una tarea con permisos excesivos, encuentre una ruta alternativa para alcanzar su objetivo o revele datos que el equipo responsable no esperaba que pudiera consultar.

El control de seguridad deja de ser una pantalla de consentimiento. Pasa a depender de la arquitectura completa:

• Identidad: qué cuenta utiliza el agente, con qué privilegios, durante cuánto tiempo y con qué posibilidad de escalada.
• Herramientas: qué APIs, repositorios, sistemas de tickets, terminales o servicios cloud puede invocar.
• Datos: qué información recupera, si puede combinarla con otras fuentes y si las salidas quedan registradas.
• Autonomía: qué acciones requieren aprobación humana y cuáles puede ejecutar sin confirmación.
• Observabilidad: si la organización puede reconstruir la cadena de decisiones, llamadas a herramientas y resultados.
• Contención: si existe un mecanismo probado para revocar credenciales, aislar el agente y detener tareas en curso.

Esta lista no es una predicción normativa. Es la diferencia entre afirmar que un sistema es seguro y poder demostrar qué hizo, con qué acceso y por qué no pudo ir más lejos.

El episodio también explica por qué la propuesta de OpenAI insiste en prácticas de monitorización entre laboratorios. La evaluación previa de un modelo no basta cuando el comportamiento cambia al conectarlo a herramientas, datos privados o entornos con incentivos adversarios. El mismo modelo puede presentar un perfil de riesgo distinto al operar en un sandbox, en una red corporativa o con acceso a un repositorio de código.

La paradoja: OpenAI pide regulación cuando la regulación empieza a diferenciar capacidades

Durante años, buena parte del debate estadounidense osciló entre dos extremos: dejar que la innovación avanzara con compromisos voluntarios o imponer reglas generales a cualquier sistema de IA. La nueva posición de OpenAI intenta ocupar una tercera vía: obligaciones duras, pero concentradas en los modelos más capaces.

La Unión Europea ya ha elegido una arquitectura diferente. El Reglamento de IA no se limita a preguntar cuánto músculo computacional tiene un modelo. Combina usos prohibidos, sistemas de alto riesgo, obligaciones para modelos de propósito general y requisitos de transparencia. El Reglamento (UE) 2024/1689 entró en vigor el 1 de agosto de 2024. Las prohibiciones del artículo 5 y las obligaciones de alfabetización en IA del artículo 4 son aplicables desde el 2 de febrero de 2025; las obligaciones para proveedores de modelos de propósito general de los artículos 51 a 56 se aplican desde el 2 de agosto de 2025; y la mayor parte del régimen, incluido el aplicable a muchos sistemas de alto riesgo, empezó a desplegarse el 2 de agosto de 2026. Para determinados sistemas de alto riesgo integrados en productos regulados, el calendario llega al 2 de agosto de 2027.

La diferencia importa. OpenAI está reclamando un marco nacional que se active por capacidad y se centre en los laboratorios de frontera. El enfoque europeo distribuye obligaciones por la función del sistema, el proveedor, el despliegue y el nivel de riesgo. Un modelo generalista puede quedar sujeto a obligaciones como documentación técnica, política de derechos de autor, información sobre capacidades y limitaciones y, cuando se clasifica como modelo con riesgo sistémico, evaluaciones adicionales, análisis de riesgos sistémicos y medidas de ciberseguridad.

El artículo 55 del Reglamento de IA establece obligaciones reforzadas para los proveedores de modelos de propósito general con riesgo sistémico. Entre ellas figuran la evaluación de modelos mediante protocolos y herramientas normalizados, la evaluación y mitigación de riesgos sistémicos, la notificación de incidentes graves a la Oficina de IA y la garantía de un nivel adecuado de ciberseguridad. Es, en cierto modo, la versión europea de la intuición que ahora defiende OpenAI: los sistemas más capaces no pueden quedar sujetos únicamente a promesas comerciales.

La UE tampoco confía solo en la evaluación antes del lanzamiento. El artículo 72 exige un sistema de seguimiento poscomercialización para determinados sistemas de alto riesgo, mientras que los artículos 12 y 14 introducen requisitos sobre conservación de registros y supervisión humana. El artículo 15 exige niveles adecuados de precisión, solidez y ciberseguridad. En la práctica, eso significa que la seguridad no termina cuando el modelo supera una prueba de laboratorio.

Qué ha cambiado en Estados Unidos

La propuesta de OpenAI se apoya en una realidad institucional concreta: sin una ley federal, los estados pueden convertirse en el principal laboratorio regulatorio. La compañía dice que apoyará, entre otras iniciativas, la SB 53 de California, la RAISE Act de Nueva York y la SB 315 de Illinois. También respalda en California la SB 813, sobre evaluadores independientes de riesgos; la AB 1405, sobre registro y responsabilidad de auditores; la SB 1119, sobre límites de edad y controles parentales; y la AB 1864, sobre cribado en proveedores de síntesis genética.

El movimiento es significativo porque reconoce que las leyes estatales, antes tratadas como una amenaza a la innovación o como un mosaico impracticable, pueden funcionar como segunda opción si el Congreso no actúa. No es una conversión filosófica completa. OpenAI sigue defendiendo que las normas se concentren en los laboratorios con sistemas más capaces y rechaza que el régimen se aplique automáticamente a todos los modelos de pesos abiertos.

El debate sobre los modelos open weight merece atención propia. OpenAI admite que pueden aportar ventajas en ciberseguridad y despliegue local, pero su propuesta no sería una política de pesos abiertos. Aquí aparece una tensión difícil de resolver: publicar los pesos puede facilitar auditoría, investigación y ejecución local sin enviar datos a un proveedor; también puede eliminar barreras para reutilizar capacidades peligrosas, modificar las salvaguardas o desplegar un modelo sin mecanismos efectivos de retirada.

Una regulación basada exclusivamente en el proveedor tampoco resolvería el problema. Cuando un modelo se descarga, se ajusta con datos propios y se conecta a herramientas internas, la responsabilidad se reparte entre quien desarrolló el modelo, quien lo integró y quien lo utiliza. El AI Act refleja esa distribución con obligaciones diferenciadas para proveedores, responsables de despliegue, importadores, distribuidores y fabricantes. El futuro marco estadounidense tendrá que responder a la misma pregunta: ¿quién responde cuando el modelo de un proveedor se convierte en un agente con permisos creados por el cliente?

La regulación europea ya obliga a convertir la seguridad en evidencias

Para los equipos de compliance y ciberseguridad europeos, la propuesta estadounidense no cambia por sí sola ninguna obligación. Sí confirma, sin embargo, que el mercado se dirige hacia un modelo en el que las declaraciones de seguridad tendrán menos valor que los registros, las pruebas y la trazabilidad.

Un proveedor que ofrezca un modelo de propósito general con riesgo sistémico no podrá limitarse a publicar una tarjeta de modelo con ejemplos de uso. Tendrá que demostrar cómo identifica riesgos, cómo prueba capacidades peligrosas, cómo gestiona incidentes y cómo protege el proceso de desarrollo. Para la empresa que lo utiliza, eso se traduce en preguntas comerciales que hasta hace poco parecían propias de un equipo de investigación:

• ¿El proveedor ha clasificado el modelo como modelo de propósito general con riesgo sistémico y con qué criterios?
• ¿Qué evaluaciones independientes o internas ha realizado antes de introducir nuevas capacidades de agente?
• ¿Qué incidentes ha notificado y qué plazo aplica a su comunicación?
• ¿Cómo se revocan las herramientas y credenciales de un agente comprometido?
• ¿Qué registros conserva el proveedor y cuáles quedan bajo control del cliente?
• ¿Qué cambios de versión pueden alterar el perfil de riesgo sin activar una nueva aprobación interna?

El artículo 53 del Reglamento de IA exige a los proveedores de modelos de propósito general mantener documentación técnica, proporcionar información y documentación a los proveedores que integren el modelo en sus sistemas y establecer una política para cumplir el Derecho de la Unión sobre derechos de autor. El artículo 55 añade obligaciones para los modelos con riesgo sistémico. No son cláusulas decorativas: afectan a la documentación que una entidad necesitará para aprobar, supervisar y, llegado el caso, retirar un sistema.

La cuestión se vuelve más exigente cuando la entidad pertenece al sector financiero. DORA es aplicable desde el 17 de enero de 2025 y su artículo 28 obliga a gestionar el riesgo asociado a terceros proveedores de servicios TIC. El artículo 30 establece elementos contractuales esenciales con esos proveedores, incluidos derechos de acceso, inspección y auditoría; el artículo 28.9 exige que las entidades mantengan una estrategia de salida cuando dependan de servicios TIC que soporten funciones críticas o importantes. Si una entidad financiera utiliza un modelo alojado por un proveedor externo para atención al cliente, detección de fraude, análisis de crédito o generación de código, la relación no se resuelve con una cláusula genérica de “uso responsable de IA”.

DORA tampoco convierte automáticamente a todo proveedor de modelos en proveedor TIC crítico designado. Esa designación corresponde al marco de supervisión de terceros TIC críticos previsto en los artículos 31 y siguientes. Pero el uso de un proveedor de IA debe entrar en el inventario de dependencias, en la evaluación de concentración, en las pruebas de resiliencia y en la planificación de salida cuando el servicio sostenga una función crítica o importante.

En paralelo, el artículo 21 de NIS2 exige medidas de gestión de riesgos de ciberseguridad que incluyan análisis de riesgos, seguridad de la cadena de suministro, gestión de vulnerabilidades, uso de criptografía, control de accesos y autenticación multifactor cuando proceda. Un agente que opere con privilegios en sistemas corporativos no es solo una cuestión de gobierno de IA: es una identidad no humana dentro de la superficie de ataque.

Lo que deberían exigir los compradores de IA a partir de ahora

La mayor consecuencia operativa de esta noticia no está en Washington ni en Sacramento. Está en los procesos de compras, arquitectura y gestión de proveedores de cada empresa que quiera conectar un agente a sistemas reales.

El primer cambio consiste en dejar de evaluar únicamente el modelo. Hay que evaluar la combinación modelo-agente-herramientas-datos. Un proveedor puede ofrecer un modelo con resultados excelentes en pruebas de razonamiento y, aun así, una integración insegura porque el agente comparte credenciales, carece de límites de gasto o puede ejecutar código sin aprobación.

El segundo es separar los permisos de lectura y escritura. Un agente que resume documentos no necesita modificar el repositorio original. Uno que propone una transferencia no necesita ejecutarla. Uno que analiza alertas de seguridad no debería poder desactivar el sistema que genera esas alertas. La segregación de funciones, familiar para SOX y para los controles de acceso financieros, sigue siendo útil cuando el “usuario” es una máquina.

El tercero es exigir registros que permitan reconstruir una acción completa: versión exacta del modelo, instrucciones recibidas, fuentes consultadas, herramientas invocadas, credenciales utilizadas, decisiones humanas y resultado final. Los logs de una API, por sí solos, suelen ser insuficientes. Si no se conserva la cadena de ejecución, una investigación posterior solo podrá ofrecer una narración aproximada. Y la aproximación no sirve para determinar si hubo una violación de datos, un incumplimiento contractual o una decisión automatizada ilegal.

El cuarto es probar la revocación. Muchas organizaciones prueban que un agente puede completar una tarea, pero no que puedan detenerlo a mitad de ejecución. La prueba debe incluir credenciales caducadas, API comprometida, prompt injection, datos maliciosos en una fuente conectada y pérdida del sistema de monitorización. La pregunta útil no es “¿puede el agente hacer esto?”, sino “¿qué ocurre cuando hace lo contrario de lo esperado y cuánto tardamos en impedir que continúe?”.

El quinto es incorporar el cambio de modelo al control de cambios. Una actualización aparentemente menor puede modificar el uso de herramientas, el formato de las salidas o la resistencia a instrucciones adversarias. El proveedor debe informar de cambios relevantes y el cliente debe decidir qué versiones están aprobadas para cada caso de uso. La práctica de actualizar automáticamente modelos en producción sin una evaluación de regresión es difícil de reconciliar con una supervisión seria.

La conexión con privacidad no desaparece porque el agente sea inteligente

El despliegue de agentes añade una capa de riesgo al cumplimiento del Reglamento General de Protección de Datos. El artículo 5 del RGPD exige licitud, lealtad, transparencia, limitación de la finalidad y minimización de datos. El artículo 25 impone protección de datos desde el diseño y por defecto. El artículo 32 exige medidas técnicas y organizativas adecuadas al riesgo. Ninguno de estos requisitos queda suspendido porque un proveedor describa su sistema como “autónomo” o “agentic”.

Si un agente consulta correos, expedientes de clientes o historiales de transacciones para resolver una tarea, la organización debe saber qué datos utiliza, con qué finalidad y durante cuánto tiempo los conserva. Si el proveedor reutiliza entradas para entrenamiento o mejora del servicio, la base jurídica, el contrato y la configuración deben reflejarlo. Si el agente genera perfiles o recomendaciones que afectan a una persona, puede entrar en juego el artículo 22 del RGPD sobre decisiones individuales automatizadas, además de las obligaciones de información de los artículos 13 y 14.

La notificación de incidentes tampoco admite ambigüedad. El artículo 33 del RGPD fija, cuando procede, un plazo de 72 horas desde que el responsable tiene constancia de una violación de seguridad de los datos personales. Un agente que extrae información de un repositorio privado y la envía a una herramienta externa puede activar ese análisis. El equipo no puede esperar a que el proveedor determine si el comportamiento fue “intencional” o “accidental”: debe evaluar el acceso, la divulgación y el riesgo para las personas.

El problema práctico es que muchos contratos de IA siguen tratando al proveedor como una caja negra. Esa fórmula puede ser comercialmente cómoda, pero es débil ante una auditoría. El comprador necesita conocer las subcontrataciones, las regiones de tratamiento, los periodos de conservación, los controles de acceso y el procedimiento de respuesta a incidentes. En el caso de agentes, también necesita saber qué herramientas utiliza el proveedor y si el modelo puede enviar datos a servicios de terceros durante la ejecución.

La fecha que importa para el software no es solo la del AI Act

La petición de OpenAI coincide con otro cambio regulatorio relevante en Europa. El Reglamento de Ciberresiliencia, conocido como Cyber Resilience Act, entró en vigor el 10 de diciembre de 2024. Sus obligaciones de notificación de vulnerabilidades e incidentes comienzan a aplicarse el 11 de septiembre de 2026, mientras que el grueso de las obligaciones para productos con elementos digitales se aplicará el 11 de diciembre de 2027.

El CRA no es una ley general de seguridad de modelos de IA. Su objetivo son los productos con elementos digitales y sus fabricantes, importadores y distribuidores. Pero afecta directamente a la cadena técnica en la que se despliegan modelos, agentes, librerías, componentes cloud y herramientas de desarrollo. Un proveedor que empaquete capacidades de IA en un producto tendrá que analizar cómo encajan las obligaciones de vulnerabilidades, actualizaciones y soporte durante el ciclo de vida.

Para los compradores, la consecuencia es sencilla: la evaluación de un proveedor de IA no debería quedarse en la pregunta de si el modelo “alucina”. También debe cubrir vulnerabilidades del software que lo sirve, dependencias de código abierto, procedimiento de parcheado, exposición de interfaces y comunicación de incidentes. El modelo es una parte del producto; la superficie de ataque es el sistema completo.

La propuesta estadounidense, DORA, NIS2, el RGPD, el AI Act y el CRA no forman una única norma coherente. No comparten definiciones ni autoridades. Pero empujan en la misma dirección: más documentación, más trazabilidad, más responsabilidad de la cadena de suministro y menos tolerancia a los controles que solo existen en una presentación comercial.

La objeción legítima: regular por capacidad puede congelar la innovación

La propuesta de OpenAI tiene una objeción evidente. Si la regulación se activa cuando un modelo supera un umbral de capacidad, las empresas competirán por definir el umbral, retrasar la clasificación o dividir las capacidades entre productos para evitar obligaciones. Una métrica técnica aislada tampoco captura todo el riesgo: un modelo mediocre conectado a un sistema bancario puede causar más daño que un modelo muy potente encerrado en un entorno de investigación.

Hay otra dificultad. Las capacidades no avanzan de forma lineal. Un modelo puede no parecer peligroso en una prueba aislada y volverse operativo cuando dispone de navegación, ejecución de código, memoria persistente y acceso a secretos. Por eso, la regulación debe medir tanto las propiedades del modelo como el contexto de despliegue.

La respuesta no consiste en descartar los umbrales de capacidad, sino en combinarlos con obligaciones por uso y por arquitectura. Los laboratorios de frontera pueden asumir requisitos reforzados de evaluación y reporte. Los proveedores de aplicaciones deben responder por el caso de uso concreto. Las empresas desplegadoras deben controlar los permisos, la supervisión y los datos. Y los auditores independientes necesitan acceso suficiente para comprobar que cada actor está haciendo su parte.

El riesgo de sobrerregular a pequeños desarrolladores existe. También existe el riesgo inverso: utilizar la defensa de la innovación para permitir que los mayores laboratorios definan voluntariamente qué significa seguridad. La solución no es pedir menos evidencia, sino exigir evidencia proporcional y reutilizable. Un estándar técnico común puede evitar que cada startup tenga que inventar su propio sistema de evaluación, siempre que no se convierta en una certificación opaca controlada por los mismos proveedores que deben ser evaluados.

Qué debería hacer un comité de riesgos antes de aprobar un agente

Una decisión de aprobación no necesita esperar a que el Congreso estadounidense resuelva su debate. Puede adoptar ya criterios que encajan con los controles existentes de seguridad, privacidad y resiliencia.

Primero, debe definir la función exacta del agente y sus límites. “Asistente interno” no es una finalidad suficiente. Hay que especificar si lee contratos, modifica registros, recomienda operaciones, inicia pagos, genera código o responde a clientes. Cada función implica un nivel distinto de impacto y supervisión.

Segundo, debe identificar el propietario de negocio, el propietario técnico y el responsable de riesgos. Si nadie puede responder quién puede detener el agente, el sistema no está listo para producción. La responsabilidad no puede diluirse entre el proveedor del modelo, el integrador y el departamento que pidió la automatización.

Tercero, debe exigir una matriz de permisos. La matriz debe indicar qué datos puede leer, qué acciones puede iniciar, qué sistemas puede consultar, qué límites cuantitativos aplican y qué aprobaciones son obligatorias. También debe contemplar el acceso del proveedor a entradas, salidas y logs.

Cuarto, debe someter el sistema a pruebas adversarias. Prompt injection, exfiltración de secretos, instrucciones contradictorias, documentos maliciosos, abuso de herramientas y escalada de privilegios son escenarios de control, no demostraciones de laboratorio. La prueba debe repetirse después de cambios relevantes en el modelo, las herramientas o los datos.

Quinto, debe acordar la salida antes del lanzamiento. El artículo 28.9 de DORA convierte esta cuestión en una obligación expresa para determinadas dependencias TIC, pero la lógica sirve fuera del sector financiero: si el proveedor sube precios, sufre una interrupción, cambia las condiciones de tratamiento o retira el modelo, la empresa debe poder desactivar el agente y migrar los datos y flujos críticos.

Sexto, debe fijar los indicadores de seguimiento. Algunos son técnicos —tasa de acciones rechazadas, llamadas a herramientas, accesos fuera de patrón, fallos de autenticación y volumen de datos transferidos—; otros son de negocio —errores, reclamaciones, decisiones escaladas a humanos y operaciones revertidas—. Sin métricas, el seguimiento poscomercialización se reduce a preguntar al proveedor si todo va bien. La respuesta suele ser tranquilizadora y, por eso mismo, insuficiente.

El verdadero cambio de 2026

OpenAI no ha pedido una ley que resuelva el problema de los agentes. Ha reconocido que el problema ya no puede gestionarse solo con compromisos privados y evaluaciones internas. Esa admisión importa, aunque venga de una empresa con intereses evidentes en la forma que adopte la regulación.

La propuesta tendrá éxito si consigue tres cosas: que las obligaciones se activen por capacidad y contexto de uso; que los laboratorios no puedan calificarse a sí mismos sin evaluación independiente; y que la responsabilidad siga al sistema completo, desde el modelo hasta las credenciales y datos con los que opera.

Fracasará si produce un sello de seguridad para los grandes proveedores mientras deja sin control la integración de sus modelos en empresas, administraciones y productos. Un modelo puede cumplir todos los requisitos de su fabricante y seguir siendo peligroso en una arquitectura mal diseñada.

Para los CISO, responsables de privacidad y comités de riesgo, la señal es clara. La pregunta ya no es cuándo llegará una ley nacional sobre modelos de frontera. La pregunta es si la organización puede demostrar hoy qué hace su agente, qué puede tocar, quién lo supervisa y cómo se le detiene. El regulador puede tardar en ponerse de acuerdo. Una credencial excesiva tarda mucho menos en causar problemas.