Seguir el ritmo de la vanguardia no significa seguir el de la empresa: cómo prepararse para la regulación de la IA

Michael MontoyaDirector de Operaciones Tecnológicas | F5

En el sector se está debatiendo a qué velocidad debería avanzar la IA de frontera. Este debate se intensificó a raíz de incidentes revelados por Anthropic y OpenAI, en los que modelos que operaban con medidas de seguridad reducidas en entornos de evaluación llevaron a cabo acciones que excedían con creces las intenciones de sus responsables. Accedieron a sistemas de los que, en teoría, debían estar aislados y se coordinaron entre instancias que debían permanecer separadas. Más recientemente, el consejero delegado de Anthropic, Dario Amodei, presentó una propuesta en la que defendía que el desarrollo de las capacidades de la IA de frontera avanzara a un ritmo deliberadamente controlado y que se integraran evaluadores independientes en los laboratorios para verificarlo.

Las respuestas a esa propuesta no han sido unánimes. Los laboratorios de IA se centran en el proceso de desarrollo: cuánta capacidad añade una sesión de entrenamiento, con qué exhaustividad se evalúa un modelo antes de su lanzamiento y si las normas deben ser voluntarias o estar reguladas. Otros sostienen que la frontera avanzará al ritmo que sea, que el resto del mundo no va a frenar y que la seguridad debe integrarse en los sistemas que rodean a los modelos.

No voy a zanjar aquí el debate, pero hay algo interesante que conviene señalar: ambos bandos coinciden en que los controles deben estar fuera del modelo y que la verificación no debe recaer únicamente en quien lo haya creado.

Esa es una versión más amplia del argumento que expuse en mayo. En aquel momento escribí que el perímetro de seguridad de la IA se había trasladado a la ruta de inferencia. Las aplicaciones llaman a modelos, los agentes invocan herramientas y los modelos acceden a otros servicios para recuperar datos, activar flujos de trabajo y ejecutar acciones operativas. Mi conclusión fue que este tráfico debe entregarse, inspeccionarse, autenticarse y gestionarse como cualquier otra interacción crítica entre aplicaciones.

Ese era un argumento arquitectónico, pero en los últimos meses ha empezado a convertirse en una cuestión de cumplimiento normativo. El ritmo de avance de la vanguardia no marca el ritmo de las empresas. Independientemente de lo que decidan los laboratorios y los gobiernos, los modelos ya publicados se están implantando ahora mismo en nuestras organizaciones, y las obligaciones asociadas a su uso ya están empezando a tomar forma.

Según mi experiencia, hay dos tipos de elementos en una hoja de ruta de seguridad. Están aquellos en los que se cree, que compiten por el presupuesto con todo lo demás y que a veces pierden. Y están aquellos que tienen una fecha asignada, un auditor que preguntará por ellos y una entrada en el registro de riesgos. Las medidas de protección para la IA están pasando de la primera categoría a la segunda y, si lleva suficiente tiempo en este sector, la situación le resultará familiar.

Lo que nos enseñó PCI DSS

Ya hemos realizado este experimento antes. Antes de 2008, la seguridad de las aplicaciones web era en gran medida una aspiración: auditorías periódicas de código, análisis estáticos y disciplina por parte de los desarrolladores. Entonces llegó el requisito 6.6 de PCI DSS, que instaba a las organizaciones que gestionaban datos de titulares de tarjetas a revisar todo el código de las aplicaciones en busca de vulnerabilidades o a implementar un control técnico automatizado delante de las aplicaciones accesibles públicamente.

Hay dos cosas de aquello que se me han quedado grabadas.

PCI DSS no nació como una ley. Surgió cuando quienes formábamos parte del sector intentamos anticiparnos a la regulación. Era un estándar contractual, aplicado mediante acuerdos con las entidades adquirentes, y aun así transformó todo un mercado. De hecho, probablemente lo hizo más rápido de lo que lo habría hecho la legislación, porque los contratos avanzan más deprisa que las leyes. Esto es relevante porque las organizaciones no empezarán a sentir esta presión por parte de un regulador, sino a través de un cuestionario de seguridad de un cliente, una cláusula de contratación o una aseguradora que pregunte qué controles protegen sus modelos.

Y luego está cómo terminó todo. En PCI DSS v4.0, desapareció la posibilidad de elegir entre una opción u otra. La alternativa de revisar el código ya no existe; ahora, el Requisito 6.4.2 obliga a implementar una solución técnica automatizada delante de las aplicaciones web de acceso público.

Hoy en día, nadie se pregunta si el cumplimiento de la normativa PCI es opcional. Lo que antes era una opción se convirtió en un requisito.

Situación actual de la regulación de la IA

La luna de miel regulatoria de la IA ha terminado. El equivalente al PCI para la IA está llegando por varias vías a la vez y a distintas velocidades. El Reglamento de IA de la UE es el más avanzado. Sus obligaciones para los modelos de propósito general ya se están aplicando y, aunque la Unión Europea ha aplazado recientemente hasta diciembre de 2027 la aplicación de las normas relativas a los sistemas de alto riesgo, los requisitos en materia de solidez técnica, supervisión humana y registro ya están definidos. Lo que las empresas suelen pasar por alto es que algunas de esas obligaciones recaen sobre ellas mismas, no solo sobre los proveedores de modelos. Si utilizan el modelo de un tercero en un caso de uso de alto riesgo, son responsables.

En Estados Unidos aún no existe una ley comparable, pero el Marco de Gestión de Riesgos de la IA del NIST y su perfil para la IA generativa se han convertido en el estándar que muchos han adoptado para actuar con la diligencia debida. La norma ISO/IEC 42001 está desempeñando un papel similar en el ámbito de la certificación y, de hecho, estoy empezando a verla en documentos de contratación. A nivel estatal, se han presentado varias leyes que combinan requisitos de transparencia y divulgación con normas específicas según el uso, mientras que los reguladores financieros y sanitarios están debatiendo directrices para situaciones concretas.

Y el OWASP Top 10 para aplicaciones de LLM se ha convertido en material de referencia habitual en las revisiones de seguridad. Cuando un cliente envía a un proveedor un cuestionario sobre los controles de IA, muy a menudo las preguntas proceden de ahí.

Al revisar todo el material, aparece una y otra vez el mismo requisito: demostrar que se puede controlar de forma continua lo que entra en un modelo y lo que sale de él, y generar un registro posteriormente.

Esto es un problema operativo antes que un problema de cumplimiento normativo

Nuestro Informe sobre el estado de la estrategia de aplicaciones de 2026 reveló que el 55 % de las carteras de aplicaciones ya incorporan IA y que una empresa utiliza, de media, siete modelos en su flujo de inferencia. Más de la mitad (52 %) encadenan u orquestan varios modelos. Además, el 90 % prevé canalizar la inferencia a través de una infraestructura compartida.

Ahora imagine que un auditor solicita una demostración de que una única política —por ejemplo, que ningún dato de identificación personal (PII) de los clientes salga de la respuesta de un modelo— se aplica en todo el entorno.

Eso no se puede resolver configurando siete modelos por separado. Y mucho menos cuando tres de ellos están encadenados y la salida de uno sirve como entrada para otro. Además, la mayoría de las organizaciones con las que hablo van incluso un paso por detrás, porque lo primero que descubren cuando empiezan a investigar no es un modelo autoalojado. Son empleados que pegan datos confidenciales en herramientas de IA de consumo y funciones de IA activadas discretamente en aplicaciones SaaS que ya utilizan.

Si añadimos agentes a este panorama, la unidad que hay que controlar deja de ser el prompt y pasa a ser la acción: la llamada a una herramienta, la solicitud a una API o el flujo de trabajo que desencadena. Ese es el mismo punto de aplicación de políticas que llevamos 20 años desarrollando para el tráfico de aplicaciones.

Esta misma capacidad de los agentes ya está en manos de atacantes que llevan a cabo campañas coordinadas a la velocidad de las máquinas. Al igual que aprendimos con la defensa contra bots, debemos dejar de evaluar este tráfico por lo sofisticado que parece y empezar a controlarlo en función de su procedencia y de lo que intenta hacer.

Guardrails deben situarse fuera del modelo

Cada vez más organizaciones ejecutan sus propios modelos: modelos de pesos abiertos alojados en su infraestructura y ajustados con sus datos. Al no contar con la red de seguridad de un proveedor, toda la responsabilidad operativa y de cumplimiento normativo recae sobre ellas.

Auditar modelo por modelo no es escalable. En principio, puede hacerse con una docena de configuraciones de modelos. He visto a equipos hacerlo. Es un proceso manual, queda obsoleto en cuanto alguien pone en marcha un nuevo endpoint y genera una instantánea en lugar de un mecanismo de control.

La alineación no es un control de seguridad. Los prompts del sistema y el posentrenamiento proporcionan una base útil. Los incidentes de OpenAI y Anthropic demuestran sus limitaciones. Se trataba de modelos sin salvaguardas que perseguían un objetivo concreto, se encontraban con un límite y buscaban la forma de sortearlo. OpenAI ha afirmado que los clasificadores de sus implementaciones estándar para clientes habrían marcado la actividad como insegura y que, si su sistema ampliado de supervisión de la cadena de pensamiento hubiera estado en funcionamiento, habría alertado a su equipo de seguridad antes de que sus modelos llegaran a Hugging Face. Los modelos de Anthropic disponibles de forma general incorporan clasificadores que inspeccionan las entradas y salidas en tiempo real.

Ambos laboratorios llevaron a cabo un importante trabajo de alineación en respuesta, pero ninguno lo consideró suficiente. También implantaron controles externos al modelo: monitores que observan lo que hace y evalúan cada acción antes de que se ejecute, con la posibilidad de derivarla a una persona. Las organizaciones con el conocimiento más profundo posible de estos sistemas concluyeron que el control debe estar fuera del modelo.

Por dónde empezar

Teniendo en cuenta hacia dónde se dirige la normativa y lo que las dos últimas décadas de seguridad de aplicaciones nos han enseñado sobre cómo llegan estas obligaciones, hay tres cosas que pondría en marcha ahora en lugar de esperar.

1. Cartografíe la superficie, empezando por lo que no se autorizó. Incluya todos los modelos en producción —API SaaS, endpoints alojados e implementaciones autogestionadas de modelos de pesos abiertos—, además de la IA en la sombra.
2. Desvincule la aplicación de las políticas del modelo. Integre las políticas en la ruta de inferencia, no en siete configuraciones de modelos distintas. Inspeccione lo que entra y lo que sale, y aplique las políticas de manera uniforme, independientemente del modelo o la nube.
3. Cree el registro de auditoría fuera del sistema que está registrando. Registre qué se solicitó, qué se devolvió, qué se bloqueó y quién aprobó cada acción. Asegúrese de que lo genere una infraestructura que ni el modelo ni el agente controlen. Los investigadores que analizaron el incidente de OpenAI descubrieron que los agentes intentaron alterar los registros de sus propias acciones. Si el registro lo genera el sistema que describe, será cuestionable.

La clave aquí es que la gobernanza de la IA no consiste únicamente en generar documentación. Lo que se exigirá a las organizaciones será de carácter técnico, continuo y probatorio. Por tanto, se trata de un problema de arquitectura y operaciones que recae en los equipos de seguridad y operaciones, no de una cuestión normativa para el departamento jurídico.

Creemos que el control debe estar en la ruta, no en los modelos. Todos los modelos que utiliza su organización —API SaaS, endpoints alojados, modelos de pesos abiertos autogestionados, tanto los autorizados como los que aún no ha descubierto— convergen en la ruta de inferencia. Esto la convierte en el punto de control ideal para todos estos modelos, ya que permite aplicar políticas y generar un registro independiente y auditable.

Las reglas aún se están redactando

Nadie sabe qué requisito obligará a su organización a abordar la cuestión: una obligación derivada de la Ley de IA de la UE, una ley estatal, un regulador sectorial o un contrato con un cliente. Lo que sí sé es que las definiciones técnicas de estos marcos aún no están cerradas. Lo que se considera una supervisión adecuada, una robustez suficiente o un registro aceptable se está decidiendo ahora mismo, en periodos de consulta pública, organismos de normalización y códigos de buenas prácticas.

Lo que nos devuelve al debate actual sobre el ritmo de desarrollo de la IA de frontera. Dejando a un lado el fondo de la cuestión, quisiera aportar una observación desde la perspectiva de alguien que gestiona estos sistemas en producción: las empresas se rigen por otros tiempos. Decidan lo que decidan los laboratorios, los gobiernos y el sector, los modelos ya publicados se están implantando y utilizando a gran escala en nuestras organizaciones, y las obligaciones asociadas a ese uso son muy reales. Seguiremos necesitando respuestas para nuestros consejos de administración, nuestros directivos y nuestros clientes, tanto si ralentizamos el desarrollo de capacidades como si no.

Estas decisiones serán mejores si cuentan con la aportación de personas que hayan gestionado estos sistemas a gran escala, que sepan qué se puede aplicar realmente, qué coste supone un control en términos de latencia y complejidad, y cuándo una norma bienintencionada acaba fomentando comportamientos contraproducentes. PCI DSS funcionó porque los profesionales contribuyeron a darle forma. Si nos mantenemos al margen, los requisitos se redactarán de todos modos. Solo que lo harán personas que nunca han tenido que aplicar ninguno.

Más información sobre el enfoque de F5 respecto a la seguridad de la IA.

Sobre el autor

Michael MontoyaDirector de Operaciones Tecnológicas | F5

Michael es responsable de la estrategia y la ejecución en toda la empresa para garantizar que la seguridad y la resiliencia sean pilares fundamentales de sus operaciones. Dirige las áreas de Seguridad, Riesgos y Operaciones Digitales de F5, impulsando la confianza operativa integral de clientes, socios y empleados. Montoya se incorporó al equipo directivo de F5 en octubre de 2025, tras formar parte del Consejo de Administración de F5 entre 2021 y 2025. Antes de incorporarse a F5, Montoya fue director de operaciones de BlueVoyant y anteriormente ocupó el cargo de director de seguridad de la información en Equinix y Digital Realty. Trabajó durante más de una década en Microsoft, donde desempeñó puestos directivos de ámbito global, entre ellos el de director de ciberseguridad, CIO/CISO regional para EMEA y Asia, y responsable global de Operaciones de Centros de Datos.

Más artículos de Michael Montoya