La advertencia de Brad Smith sobre la regulación de la IA desafía la apuesta de Estados Unidos por la autorregulación
El presidente de Microsoft, Brad Smith, lanzó esta semana una advertencia contundente: la inteligencia artificial cuenta con menos controles de seguridad que la leche o las lavadoras. Su argumento sobre la regulación de la IA de Brad Smith cuestiona la preferencia de Washington por la autorregulación de la industria a medida que los agentes de IA obtienen mayor libertad operativa.
Smith quiere que los gobiernos exijan informes de incidentes, notificaciones a las víctimas, evaluaciones independientes y controles de emergencia para sistemas avanzados. Estas propuestas van más allá de los compromisos voluntarios, que las empresas responsables pueden cumplir mientras que los desarrolladores menos cuidadosos los ignoran.
El conflicto no enfrenta simplemente a Microsoft con la desregulación. Es una disputa entre normas exigibles de seguridad de productos y promesas voluntarias diseñadas para preservar la velocidad de desarrollo. La Unión Europea ya ha optado por obligaciones vinculantes, mientras Estados Unidos sigue debatiendo cuánta autoridad deberían recibir los reguladores.
Las declaraciones de Brad Smith sobre la regulación de la IA elevan el listón
La exigencia central de Smith es que la IA avanzada debe afrontar obligaciones de seguridad exigibles antes de que los fallos graves se vuelvan habituales.
Durante una entrevista con la BBC publicada el 11 de octubre, Smith comparó la supervisión de la IA con las inspecciones aplicadas a productos de consumo convencionales. La leche y las lavadoras deben cumplir requisitos de seguridad establecidos, mientras que muchos sistemas de IA llegan a los usuarios sin un escrutinio equivalente antes de su lanzamiento.
La analogía fue deliberadamente contundente. La regulación de la leche aborda la contaminación, el etiquetado, la manipulación y la trazabilidad. Las normas para electrodomésticos cubren riesgos eléctricos, consumo energético y fallos mecánicos previsibles. La IA presenta riesgos distintos, pero la comparación de Smith apunta a la ausencia de una estructura de responsabilidad igualmente madura.
Su argumento incluyó cuatro medidas prácticas. Los desarrolladores deberían mantener controles de emergencia, documentar incidentes graves, informar a las víctimas de brechas habilitadas por IA y aceptar evaluaciones independientes antes de lanzar sistemas especialmente relevantes.
Un control de emergencia, a veces denominado interruptor de apagado, permite a un operador pausar o restringir un sistema cuando su comportamiento supera los límites aprobados. Parece sencillo, pero los agentes autónomos complican la idea.
Un agente de IA es un software capaz de planificar y ejecutar múltiples pasos con una orientación humana limitada. Puede navegar por sistemas, llamar herramientas, escribir código, mover datos o comunicarse con otros servicios.
Pausar un modelo no detiene necesariamente un flujo de trabajo distribuido. Los controles pertinentes quizá deban abarcar credenciales, acceso a redes, permisos de herramientas, agentes copiados y aplicaciones posteriores.
Por ello, Smith se centró en la responsabilidad operativa, no solo en la precisión del modelo. Si un agente traspasa los límites esperados y compromete a otra organización, la parte afectada debería recibir una notificación formal.
La propuesta se asemeja a las reglas de notificación de brechas usadas en la legislación de ciberseguridad y privacidad. Crea un registro, establece plazos y brinda a las víctimas la información necesaria para contener los daños.
Según las normas globales de seguridad descritas en la entrevista, Smith también quiere que los gobiernos decidan cuándo los evaluadores externos deben revisar productos de IA antes de su lanzamiento. Calificó a la IA como una herramienta y un arma.
Microsoft ha promovido controles similares durante años. Su plan de gobernanza de 2023 pidió frenos de seguridad cuando la IA controle infraestructuras críticas, incluidas redes eléctricas, sistemas de agua y flujos de tráfico.
El plan de gobernanza de la IA también sostuvo que la supervisión de la IA no debería permanecer exclusivamente en manos de las empresas tecnológicas. Los comentarios más recientes de Smith refuerzan esa postura en torno a los agentes autónomos y el riesgo cibernético.
El cambio importa porque la IA generativa ya no produce únicamente texto o imágenes. Los sistemas más recientes pueden realizar acciones mediante navegadores, terminales, bases de datos y aplicaciones empresariales.
Un error de un chatbot puede inducir a error a un usuario. Un agente con credenciales puede modificar registros, exponer datos confidenciales o crear una cadena de acciones automatizadas antes de que intervenga una persona.
Esa diferencia hace más importante la notificación de incidentes. Las organizaciones no pueden estudiar fallos recurrentes cuando los desarrolladores revelan eventos de forma selectiva o definen los incidentes graves de maneras incompatibles.
La advertencia de Smith no demuestra que la IA carezca literalmente de regulación en todas partes. Ya pueden aplicarse leyes de privacidad, protección del consumidor, discriminación, responsabilidad por productos, derechos de autor y normas sectoriales.
Su argumento más acotado es más defendible. Estados Unidos carece de un marco integral de seguridad de productos diseñado específicamente para la IA avanzada de propósito general y los agentes autónomos.
Esa brecha genera el conflicto central del artículo. La cooperación voluntaria puede establecer prácticas útiles rápidamente, pero no obliga a todos los desarrolladores a cumplir el mismo estándar mínimo.
La presión recae sobre los gobiernos y los compradores de IA
Los desarrolladores de IA quieren margen para avanzar con rapidez, pero los clientes necesitan cada vez más pruebas de que la velocidad no está sustituyendo a la responsabilidad.
Los comentarios de Smith ejercen presión inmediata sobre los responsables políticos. Los gobiernos deben decidir si la IA avanzada debería seguir siendo principalmente un servicio de software o convertirse en una categoría de productos regulada cuando realiza acciones relevantes.
La respuesta afecta a las pruebas, la documentación, las auditorías y la responsabilidad legal. También determina qué regulador recibe autoridad cuando un agente provoca daños en varias industrias o a través de fronteras nacionales.
Un asistente médico, una herramienta de contratación, un agente de programación y un bot de atención al cliente pueden utilizar el mismo modelo subyacente. Sus riesgos difieren porque cada sistema recibe datos, permisos y responsabilidades distintos.
Un único proceso de aprobación sería demasiado tosco. Un marco sin requisitos mínimos obligatorios dejaría a las organizaciones negociando individualmente las normas de seguridad con los proveedores.
Los compradores empresariales ya soportan gran parte de esa carga. Los equipos de seguridad revisan controles de acceso, retención de datos, comportamiento del modelo, registros y contratos de proveedores antes de aprobar implementaciones de IA.
Estas comprobaciones se vuelven más difíciles cuando un agente puede ejecutar comandos. Un modelo podría comportarse de forma segura durante una evaluación comparativa y, aun así, fallar después de recibir instrucciones inesperadas de un documento, un sitio web o una herramienta comprometida.
La inyección de prompts ilustra el problema. Una instrucción maliciosa oculta en contenido externo puede redirigir a un agente, incluso cuando el usuario nunca tuvo intención de realizar esa acción.
Las organizaciones pueden reducir la exposición limitando permisos, aislando sistemas y exigiendo aprobación para pasos sensibles. Sin embargo, estos controles dependen de una documentación clara por parte de los proveedores de modelos y aplicaciones.
Los informes obligatorios de incidentes ayudarían a los compradores a comparar fallos entre sistemas. Los informes estandarizados podrían registrar la capacidad afectada, los permisos del sistema, las salvaguardas que fallaron y el daño resultante.
La notificación a las víctimas es igual de importante. Una empresa no puede contener una intrusión si el desarrollador que detectó la participación del agente no tiene obligación de comunicarse con rapidez.
Las pruebas independientes también podrían reducir las brechas de información. Los proveedores de modelos poseen conocimientos técnicos más profundos, pero afrontan presión comercial para lanzar productos rápidamente y presentar los resultados de manera favorable.
Los evaluadores externos pueden probar capacidades en condiciones controladas y cuestionar supuestos internos. Su independencia sigue dependiendo del acceso, la financiación, la autoridad legal y la protección frente a conflictos de interés.
Las normas de seguridad de IA de Microsoft generarían costes tanto para Microsoft como para sus competidores. Eso hace que la postura de Smith sea más significativa, aunque no elimina los intereses comerciales de la empresa.
Las grandes compañías pueden absorber los costes de cumplimiento con mayor facilidad que las startups. Por tanto, una regulación compleja puede proteger a los usuarios y, al mismo tiempo, elevar las barreras de entrada para desarrolladores más pequeños.
Esta tensión da a los críticos una preocupación legítima. Las normas diseñadas con grandes laboratorios podrían favorecer a empresas que ya cuentan con amplios equipos jurídicos, de seguridad y de políticas públicas.
Los gobiernos deben separar las salvaguardas esenciales del papeleo que mide la capacidad administrativa. Informar de un evento grave de pérdida de control cumple un propósito claro. Producir documentos repetitivos sin pruebas técnicas no lo hace.
Los compradores también necesitan registros internos que conecten las afirmaciones de los proveedores con las decisiones de implementación. Una base de conocimientos de IA con capacidad de búsqueda puede ayudar a los equipos a preservar evaluaciones, aprobaciones, incidentes y cambios de políticas entre departamentos.
La documentación por sí sola no puede garantizar la seguridad. Aun así, puede establecer quién aprobó un sistema, qué controles existían y cómo respondió una organización tras una advertencia.
Por tanto, la presión es compartida. Los gobiernos deben definir requisitos mínimos exigibles, los desarrolladores deben proporcionar pruebas significativas y los clientes deben controlar cómo operan los sistemas dentro de sus entornos.
Las normas voluntarias de seguridad de la IA tienen un problema de cobertura
La autorregulación funciona mejor entre empresas cooperativas, mientras que la regulación importa más cuando una empresa se niega a cooperar.
Smith reconoció que los acuerdos voluntarios representan un avance. También identificó su debilidad estructural: las empresas responsables participan, pero las organizaciones que generan mayor riesgo pueden mantenerse al margen.
Esta distinción importa más a medida que el desarrollo se vuelve accesible. Un compromiso voluntario firmado por laboratorios destacados no vincula a un proveedor más pequeño, un operador extranjero ni a un desarrollador que distribuya modelos modificados.
El mismo problema aparece tras el lanzamiento. Una empresa puede prometer evaluaciones, pero elegir sus propias pruebas, umbrales y lenguaje de divulgación, salvo que una norma común los defina.
La autorregulación sigue teniendo ventajas. Los grupos industriales pueden actualizar prácticas técnicas más rápido que los legisladores, incorporar especialistas y experimentar antes de que los gobiernos comprendan las capacidades emergentes.
Las pruebas voluntarias también pueden comenzar de inmediato. Una nueva ley puede requerir meses de redacción, audiencias, normas de aplicación, desafíos legales y contratación de reguladores.
El marco más sólido combinaría ambos enfoques. La ley establecería obligaciones mínimas, mientras que las normas técnicas definirían métodos adaptables para cumplirlas.
La posición de Smith entra en conflicto con el énfasis del presidente Donald Trump en el rápido desarrollo estadounidense y la competencia con China. La administración sostiene que las normas gravosas pueden ralentizar a las empresas nacionales mientras avanzan los rivales extranjeros.
Una orden de la Casa Blanca de 2026 afirmó que Estados Unidos lidera en parte porque se niega a sofocar la innovación con una regulación excesiva. Destacó un despliegue rápido y seguro, y una cooperación más estrecha entre el gobierno y la industria.
Esta política federal de IA refleja una teoría distinta del riesgo. Perder el liderazgo tecnológico se convierte en un peligro para la seguridad nacional junto con los despliegues inseguros.
El desacuerdo no es una simple elección entre seguridad e innovación. Ambas partes sostienen que su enfoque protege la competitividad nacional y la seguridad pública.
Smith argumenta que los sistemas confiables lograrán una adopción más amplia. La administración sostiene que las normas prematuras podrían congelar la tecnología actual, aumentar los costes y ceder impulso.
China también complica el debate. Las normas aplicadas únicamente a empresas estadounidenses no pueden regular directamente a desarrolladores extranjeros, lanzamientos de modelos con pesos abiertos ni sistemas desplegados desde otra jurisdicción.
Sin embargo, las normas de producto aún pueden influir en el acceso al mercado. Un gobierno puede exigir pruebas, informes y trazabilidad para los sistemas utilizados en sectores críticos, independientemente de dónde se haya entrenado el modelo.
Los sectores de la aviación y los dispositivos médicos aplican una lógica similar. Los fabricantes operan globalmente, pero los productos deben cumplir requisitos locales antes de entrar en mercados regulados.
La regulación de la IA vista desde esta perspectiva se centra menos en aprobar cada modelo y más en controlar los despliegues de alto impacto. Un asistente de redacción no debería recibir el mismo escrutinio que un agente que opera infraestructura eléctrica.
La clasificación por riesgos puede preservar la flexibilidad. Puede reservar la revisión independiente para sistemas con capacidades peligrosas, amplia autonomía, datos sensibles o acceso a operaciones críticas.
Sin embargo, la clasificación crea sus propias lagunas. Los desarrolladores pueden describir un sistema de forma limitada durante la revisión, mientras que los clientes posteriormente lo conectan a herramientas que generan consecuencias mucho más graves.
Por lo tanto, la responsabilidad debe extenderse a toda la cadena de suministro. Los proveedores de modelos conocen las capacidades básicas, los desarrolladores de aplicaciones definen los flujos de trabajo y quienes despliegan los sistemas asignan datos y permisos.
Ningún participante ve el riesgo completo. Las normas eficaces deben especificar qué documenta cada parte y cuándo se transfiere la responsabilidad.
La crítica de Smith a la autorregulación es más sólida en materia de cobertura. Una promesa compartida por empresas reputadas no puede establecer obligaciones universales ni imponer consecuencias a un operador que las ignore.
Su debilidad se refiere a la precisión. «Regular la IA» abarca demasiados sistemas y contextos como para funcionar como una política aplicable sin umbrales detallados.
Europa demuestra que la regulación es posible, pero no sencilla
La Unión Europea ha pasado de principios voluntarios a obligaciones exigibles, aunque su sistema escalonado demuestra lo difícil que se vuelve una regulación integral de la IA.
La Ley de IA de la UE utiliza una estructura basada en el riesgo. Prohíbe ciertas prácticas, crea obligaciones para los modelos de propósito general y aplica controles adicionales a los sistemas utilizados en ámbitos sensibles.
Las facultades de aplicación de varias disposiciones comenzaron a aplicarse en agosto de 2026. Las obligaciones de transparencia exigen que los usuarios reciban un aviso cuando interactúan con determinados sistemas de IA o encuentran contenido sintético especificado.
Las normas también abordan los modelos de IA de propósito general con riesgo sistémico. Los proveedores pertinentes se enfrentan a obligaciones relacionadas con evaluación, documentación, ciberseguridad y mitigación de riesgos.
El marco de la Ley de IA no regula todas las aplicaciones por igual. La UE afirma que la mayoría de los sistemas de riesgo mínimo permanecen fuera de controles obligatorios adicionales.
Esto cuestiona directamente la idea de que los gobiernos deben elegir entre restricciones integrales y una autorregulación completa. Los reguladores pueden concentrar las obligaciones allí donde el daño potencial es mayor.
Sin embargo, el calendario de implementación revela fricciones prácticas. Las normas para varios usos de alto riesgo no se aplicarán hasta diciembre de 2027, mientras que los requisitos para la IA integrada en productos regulados se extienden hasta 2028.
Las normas técnicas, las orientaciones, la capacidad de los reguladores y los métodos de prueba necesitan tiempo. Las empresas también necesitan claridad sobre las clasificaciones y la documentación antes de que la aplicación de la ley resulte predecible.
Por lo tanto, el enfoque de la UE respalda el argumento de Smith al tiempo que matiza su urgencia. Aprobar una ley inicia el proceso, pero no crea de inmediato evaluadores competentes ni métodos de evaluación fiables.
La evaluación de modelos de propósito general sigue siendo especialmente difícil. Un modelo puede mostrar capacidades distintas tras obtener acceso a herramientas, ajustes finos, instrucciones de sistema o integración con datos propietarios.
La evaluación previa al lanzamiento puede identificar capacidades peligrosas, pero no puede reproducir todas las configuraciones posteriores. El seguimiento continuo y los informes posteriores al despliegue siguen siendo necesarios.
La ley también genera inquietudes competitivas. El cumplimiento puede requerir experiencia jurídica, documentación técnica y una gestión continua del riesgo que los proveedores más pequeños tienen dificultades para financiar.
Los defensores responden que los productos de alto riesgo deben asumir costes de seguridad. Una startup no recibe una exención para proteger a los pacientes simplemente porque el cumplimiento médico sea caro.
Los críticos replican que el software cambia más rápido que los productos físicos. Las normas fijas pueden quedar obsoletas, recompensar el cumplimiento procedimental o desalentar la investigación abierta sin reducir el riesgo práctico.
Ambas preocupaciones son válidas. La regulación puede fracasar por ser insuficiente y dejar daños graves sin abordar. También puede fracasar por excederse y dirigir recursos hacia formularios en vez de hacia la ingeniería de seguridad.
La experiencia de aplicación de la UE aportará pruebas al debate sobre la regulación de la IA planteado por Brad Smith. Los reguladores deben demostrar que los requisitos mejoran la transparencia y la rendición de cuentas sin crear barreras arbitrarias.
El Reino Unido sigue un camino diferente. Ha invertido en capacidad de evaluación técnica mientras evita una ley horizontal al estilo de la UE que cubra todo el mercado de la IA.
Smith describió al Reino Unido como bien posicionado para liderar el trabajo mundial sobre seguridad gracias a su AI Security Institute. El instituto comenzó como AI Safety Institute y recibió un mandato centrado en la seguridad en 2025.
Su trabajo incluye estudiar capacidades avanzadas, usos indebidos cibernéticos, salvaguardas y preparación gubernamental. La misión del instituto de seguridad describe una organización respaldada por el Estado que realiza investigación técnica para apoyar la gobernanza de la IA avanzada.
Esa experiencia podría respaldar normas internacionales de pruebas. Sin embargo, un instituto de investigación no posee automáticamente autoridad para exigir divulgaciones, bloquear lanzamientos o sancionar infracciones.
Smith quiere que la capacidad técnica y la obligación legal se refuercen mutuamente. El Reino Unido ha desarrollado la primera parte, mientras el Parlamento aún debe decidir sobre la segunda.
El liderazgo global también requiere cooperación. Una norma adoptada por un país tiene un alcance limitado cuando los desarrolladores pueden lanzar modelos, pesos o servicios a través de las fronteras.
Los formatos comunes de informes y los métodos de evaluación pueden ser más alcanzables que un regulador global único. Los países podrían reconocer pruebas compatibles preservando al mismo tiempo distintos sistemas de aplicación.
La postura de Microsoft merece su propia prueba de resistencia
El argumento de Microsoft a favor de normas más estrictas es creíble, pero los responsables políticos deberían examinar quién se beneficia y si los controles propuestos funcionan en la práctica.
Microsoft vende infraestructura en la nube, servicios de seguridad, software para el trabajo y sistemas de IA a organizaciones fuertemente reguladas. Unas normas nacionales claras pueden reducir la incertidumbre para esos clientes.
La empresa también cuenta con los recursos para satisfacer amplios requisitos de cumplimiento. Los rivales más pequeños pueden afrontar costes proporcionalmente mayores, especialmente si las evaluaciones requieren especialistas escasos o capacidad de cómputo costosa.
Eso no hace que las propuestas de Smith sean incorrectas. Significa que los responsables políticos deben comprobar si cada medida reduce el riesgo sin afianzar a los mayores proveedores actuales.
La evaluación independiente es un ejemplo. Un requisito puede mejorar la rendición de cuentas, pero solo si los evaluadores tienen acceso adecuado y pueden publicar conclusiones relevantes.
Una revisión basada por completo en pruebas seleccionadas por el proveedor ofrecería una independencia limitada. Una revisión sin acceso a los detalles del sistema podría pasar por alto comportamientos que surgen dentro de entornos de producción.
Los evaluadores gubernamentales también necesitan personal cualificado. Las agencias compiten con las empresas tecnológicas por investigadores que comprendan la seguridad de los modelos, las operaciones cibernéticas y los sistemas distribuidos.
Los límites de capacidad pueden generar retrasos. Si cada modelo nuevo requiere una aprobación completa, las colas de evaluación podrían ralentizar productos de bajo riesgo mientras los revisores pasan por alto sistemas realmente peligrosos.
Por lo tanto, los umbrales son esenciales. Un mandato de revisión podría centrarse en modelos que superen niveles de capacidad definidos o en sistemas que controlen infraestructura crítica.
Los umbrales de capacidad también requieren revisiones frecuentes. Una evaluación que hoy identifica una capacidad excepcional podría convertirse en una prueba rutinaria a medida que mejoran los modelos.
Los controles de emergencia presentan otro desafío. Un servicio centralizado puede suspender el acceso, revocar credenciales o desactivar herramientas. Un modelo de pesos abiertos copiado en muchas máquinas no puede retirarse con tanta facilidad.
Incluso los sistemas alojados pueden escapar de un único punto de control mediante datos almacenados en caché, aplicaciones conectadas o credenciales delegadas. Un interruptor de apagado debe abordar todo el despliegue, no solo el punto de acceso al modelo.
Los informes de incidentes plantean preguntas sobre el alcance. Los desarrolladores necesitan definiciones que separen los errores inocuos de los eventos de seguridad que justifican atención regulatoria.
Requisitos excesivamente amplios podrían inundar a las agencias con errores menores. Las definiciones estrechas podrían permitir a las empresas excluir incidentes graves evitados por poco o daños posteriores.
Las normas también necesitan protecciones para los informes. Las organizaciones pueden ocultar incidentes cuando la divulgación genera responsabilidad inmediata, daño reputacional o exposición de información de seguridad sensible.
La política de ciberseguridad suele equilibrar la confidencialidad con la rendición de cuentas. Los reguladores pueden recibir informes detallados mientras publican lecciones agregadas que ayuden a otras organizaciones a mejorar.
La propuesta de Smith de notificar a las víctimas merece especial atención. Un objetivo necesita información inmediata tras una brecha habilitada por IA, pero los investigadores deben establecer qué sabía el proveedor y cuándo lo sabía.
Un sistema de IA puede ayudar a un atacante sin actuar de manera independiente. Los reguladores deberían evitar definiciones que traten cada uso de software generativo como un incidente de IA distinto.
La cuestión relevante es si el sistema introdujo, aceleró u ocultó un daño material. Los informes deberían describir esa contribución en lugar de basarse en etiquetas llamativas como IA rebelde.
Los propios despliegues de Microsoft deberían someterse a las normas que recomienda Smith. Esto incluye los productos Copilot, los modelos alojados en Azure, los agentes de seguridad y los sistemas suministrados mediante asociaciones comerciales.
Una norma creíble no puede depender de la estructura corporativa preferida por el proveedor. Las responsabilidades deben permanecer claras cuando un desarrollador de modelos, un anfitrión en la nube, un proveedor de aplicaciones y un cliente comparten el control.
Aquí es donde las normas de seguridad de la IA de Microsoft necesitan resultados medibles. Los reguladores deberían preguntar si los controles reducen el tiempo de detección, limitan las acciones no autorizadas y mejoran la recuperación tras fallos.
También deberían examinar la falsa confianza. Una evaluación aprobada puede convertirse en una insignia de marketing incluso cuando la configuración desplegada difiere del sistema revisado.
Ninguna auditoría puede garantizar la seguridad. Las pruebas independientes ofrecen evidencia sobre condiciones definidas, no una garantía permanente frente a todos los usos futuros.
Por lo tanto, la comparación de Smith con la leche es retóricamente eficaz, pero técnicamente incompleta. La leche es un producto físico estandarizado con vías de contaminación conocidas y métodos de inspección maduros.
Los sistemas de IA son servicios adaptables cuyo comportamiento cambia según el contexto. Esa complejidad refuerza el argumento a favor de la supervisión, al tiempo que dificulta diseñar una regulación al estilo de los productos.
La conclusión escéptica no es que la regulación deba esperar. Es que las normas deben vincularse a capacidades, permisos y daños reales, en lugar de a la amplia etiqueta «IA».
Tres señales mostrarán si la advertencia cambia la política
La próxima prueba consiste en determinar si los gobiernos convierten el amplio acuerdo sobre el riesgo de la IA en obligaciones específicas que resistan el escrutinio político y técnico.
La primera señal es una propuesta vinculante de notificación de incidentes. Los responsables políticos deberían definir los sistemas cubiertos, los incidentes graves, los plazos de notificación, las notificaciones a víctimas y las protecciones de confidencialidad.
Si una jurisdicción importante adopta esos elementos, el argumento de Smith habrá pasado de la analogía a una política operativa. Un registro voluntario o una promesa de informar sin definir representaría una respuesta más débil.
La segunda señal es un acceso ampliado para evaluadores independientes. Los gobiernos necesitan acuerdos que permitan a investigadores cualificados probar sistemas avanzados antes de despliegues de alto impacto.
El Instituto de Seguridad de la IA del Reino Unido ofrece una posible base. Su valor dependerá de si los desarrolladores conceden acceso oportuno y de si sus conclusiones influyen en las decisiones de despliegue.
El acceso obligatorio para sistemas de alto riesgo claramente definidos reforzaría la postura de Smith. La dependencia continuada de una cooperación discrecional demostraría que la autorregulación sigue marcando el límite práctico.
La tercera señal son las pruebas derivadas de la aplicación de la normativa de la UE. Las autoridades deben demostrar cómo funcionan en casos reales la transparencia, las obligaciones para los modelos de propósito general y los controles de riesgo sistémico.
Una aplicación coherente demostraría que las normas vinculantes sobre IA pueden funcionar en un mercado amplio. Las interpretaciones contradictorias o los retrasos procedimentales respaldarían las preocupaciones sobre la complejidad regulatoria.
Estados Unidos sigue siendo la incertidumbre más relevante. El Congreso ha debatido la preeminencia federal, las normas estatales, la seguridad de los productos y un marco nacional de intervención ligera, sin resolver la disyuntiva de fondo.
Durante debates anteriores en el Congreso, Smith apoyó el liderazgo federal en materia de seguridad de productos y revisión previa al lanzamiento. También se mostró abierto a dar tiempo al país para desarrollar un enfoque unificado.
Ese historial aporta matices. Microsoft no pide que cada estado invente reglas separadas ni que cada aplicación de IA reciba aprobación.
La empresa parece favorecer un marco coherente a nivel nacional, centrado en capacidades avanzadas y despliegues de consecuencias significativas. Los líderes del sector suelen preferir la uniformidad federal porque las normas estatales fragmentadas elevan los costes de cumplimiento.
El debate sobre el marco federal también revela una trampa política. La preeminencia federal puede simplificar las obligaciones, pero puede dejar un vacío si el Congreso bloquea a los estados sin crear protecciones.
Para los desarrolladores, la lección inmediata es diseñar sistemas como si las obligaciones de notificación y auditoría fueran a llegar. Eso implica conservar registros, documentar los permisos de las herramientas, probar los procedimientos de desconexión y separar las acciones sensibles de los resultados rutinarios.
Los compradores empresariales deberían exigir ahora las mismas pruebas. Los equipos de compras pueden preguntar a los proveedores quién recibe las notificaciones de incidentes, qué evaluadores obtienen acceso y cómo los administradores revocan la autoridad de un agente.
Los trabajadores del conocimiento también deberían preocuparse, porque las herramientas agénticas actúan cada vez más sobre correo electrónico, documentos, calendarios, repositorios de código y registros de clientes. Una respuesta equivocada es incómoda. Una acción no autorizada puede ser irreversible.
Los equipos deberían mantener la aprobación humana para los pasos de mayor impacto, minimizar las credenciales y registrar qué fuentes influyeron en una acción. Esos controles seguirán siendo útiles independientemente de la legislación futura.
La advertencia de Brad Smith sobre la regulación de la IA solo importará si genera responsabilidades exigibles y estándares técnicamente creíbles. Una comparación memorable puede abrir el debate, pero no puede resolver el trabajo de diseño.
La mejor política no tratará a todos los modelos como si fueran un cartón de leche. Identificará cuándo el software adquiere suficiente autonomía, acceso o capacidad peligrosa como para requerir una supervisión más estricta.
Durante los próximos tres meses, preste atención a un proyecto de ley concreto sobre notificación de incidentes, a un mayor acceso para evaluadores y a pruebas públicas derivadas de la aplicación de la normativa de la UE. Esas señales mostrarán si los gobiernos están construyendo mecanismos de rendición de cuentas o prolongando la era de las promesas.
Las organizaciones no deberían esperar esa respuesta. Revisen qué agentes de IA pueden actuar, qué credenciales poseen y quién recibe una notificación cuando cruzan un límite aprobado. Después, hagan a los proveedores una pregunta directa: ¿sus compromisos de seguridad seguirían protegiéndoles si cumplirlos dejara de ser opcional?
