Las salvaguardas para la IA empresarial pueden importar más que la frontera

Olvídese de la frontera de la IA. Los clientes exigen a las empresas más salvaguardas para la IA que ya utilizan, y la experiencia con PCI DSS ofrece un modelo útil.

La luna de miel regulatoria de la IA ha terminado. Divulgaciones recientes han suscitado conversaciones sobre frenar el desarrollo de los modelos de frontera e imponer controles. Uno de los pocos puntos en los que hay acuerdo es que los controles deben situarse fuera de los modelos y contar con verificación independiente.

Se debate qué ocurrirá a continuación, pero los organismos reguladores ya están actuando. La Ley de IA de la Unión Europea está introduciendo gradualmente obligaciones de seguridad, incluida la responsabilidad de los compradores. En Estados Unidos, el Marco de gestión de riesgos de IA del NIST se está adoptando como norma de diligencia razonable. A escala mundial, el Top 10 de OWASP para aplicaciones de LLM se ha convertido en una referencia habitual en las revisiones de seguridad, y la certificación ISO/IEC 42001 empieza a figurar en los documentos de contratación.

Eso significa que los desarrolladores de modelos no son los únicos responsables. Las obligaciones y los riesgos de seguridad también recaen en las empresas que utilizan modelos ya publicados, sobre todo en casos de uso de alto riesgo. Las respuestas equivocadas a un cuestionario de seguridad de un cliente o a una solicitud de propuestas podrían frenar una operación entre empresas.

PCI DSS marca el camino

Por suerte, esta historia ya la hemos visto. Hace veinte años, la seguridad de las aplicaciones web dependía principalmente de auditorías periódicas del código, análisis estáticos y la disciplina de los desarrolladores. Entonces, el Requisito 6.6 de PCI DSS, publicado en 2006 y cuya aplicación comenzó en 2008, exigió que las organizaciones que manejaban datos de titulares de tarjetas revisaran todo el código de las aplicaciones en busca de vulnerabilidades o instalaran controles técnicos automatizados. Más adelante, se eliminó la opción de revisar el código y pasaron a ser obligatorios los controles técnicos.

Pero PCI DSS no comenzó como una ley. Empezó como una norma contractual que transformó el mercado, probablemente más rápido de lo que lo habría hecho una ley, porque los contratos avanzan más rápido que las leyes gubernamentales.

Del mismo modo, las organizaciones sienten ahora presión para establecer salvaguardas para la IA implementada, no por parte de los organismos reguladores, sino de clientes y socios, mediante cuestionarios de seguridad, cláusulas en solicitudes de propuestas y requisitos de las pólizas de seguro.

Resuelva el problema operativo y el cumplimiento vendrá después

Puede ser difícil responder a esa presión, porque la gobernanza de la IA no consiste solo en establecer políticas. También requiere pruebas técnicas continuas.

Muchas de las empresas con las que hablo ejecutan en producción media docena de modelos o más y, con frecuencia, los encadenan u orquestan para que la salida de uno sirva de entrada a otro. Imagine tener que demostrar, en estas condiciones, que se aplica una política en todo el sistema, como impedir que la salida de un modelo contenga información de identificación personal (PII). Auditar manualmente varios modelos configurados de forma individual consumiría el tiempo de los desarrolladores. Además, a la mayoría de las organizaciones les cuesta controlar el uso de IA no autorizado y de alto riesgo, como cuando los empleados pegan datos confidenciales en herramientas de IA para consumidores o los proveedores de SaaS habilitan discretamente nuevas funciones de IA. Sin embargo, toda la responsabilidad recae en la empresa.

En situaciones tan complejas, los requisitos pueden reducirse a una sola tarea sencilla: demostrar que se pueden restringir continuamente las entradas y salidas de los modelos y registrar esa actividad para su verificación. Cuando las aplicaciones llaman a modelos, los agentes invocan herramientas y los modelos realizan acciones o activan flujos de trabajo, lo que hay que controlar es la acción: la llamada a la herramienta, la solicitud a la API o la activación del flujo de trabajo.

Traslade la seguridad a la ruta de inferencia

Esa acción es el punto de aplicación de controles que los expertos en seguridad de aplicaciones llevan 20 años desarrollando para el tráfico de las aplicaciones. En particular, cuando la inferencia se enruta a través de una infraestructura compartida, esa ruta se convierte en el punto de control ideal para distintos modelos e incluso para el uso de IA no autorizado. El tráfico de inferencia de IA debe entregarse, inspeccionarse, autenticarse y gestionarse como cualquier otra interacción importante con una aplicación, en función de su origen y de lo que intenta hacer. A diferencia de las auditorías manuales, la gobernanza del tráfico de inferencia puede ampliarse a gran escala.

Cómo empezar

Ante la dirección que está tomando la regulación, las organizaciones deben empezar ahora a hacer tres cosas:

1. Trace el alcance de su responsabilidad, desde las API de SaaS y los puntos de conexión alojados hasta la IA en la sombra.
2. Desvincule las políticas de seguridad y su aplicación de los modelos, y sitúelas en la ruta de inferencia.
3. Asegúrese de que se generen registros de auditoría fuera del control de los modelos y los agentes, que han demostrado intentar alterar los registros de sus propias acciones.

Aún se está determinando qué se considera una supervisión y aplicación de controles adecuadas, pero los equipos de operaciones y seguridad de su empresa saben qué se puede hacer cumplir realmente, cuánto cuestan los controles en términos de latencia y complejidad, y en qué casos una norma bienintencionada podría producir un resultado equivocado. Involúcrelos desde ahora. Los riesgos y las obligaciones de seguridad asociados al uso de la IA son reales, y sin duda a sus clientes y directivos les preocupan más los que afrontan hoy que las amenazas que los modelos de frontera podrían plantear mañana.