La seguridad de la IA y la gobernanza de la IA no son el mismo problema.

La mayoría de las organizaciones están abordando el problema equivocado. Aquí te mostramos cómo diferenciarlos y por qué es importante antes de tu próxima implementación de IA.

Por qué la seguridad de la IA y la gobernanza de la IA no son el mismo problema

La mayoría de las organizaciones de TI tratan la seguridad y la gobernanza de la IA como un único flujo de trabajo. Ambos temas se abordan en la misma reunión, se gestionan con el mismo equipo y se analizan mediante los mismos marcos de trabajo. Sin embargo, se trata de dos problemas distintos. La seguridad de la IA evita la entrada de amenazas, mientras que la gobernanza de la IA controla las acciones internas de la propia IA.

Ignorar esa diferencia tiene un costo. Se puede aprobar una auditoría de seguridad y reprobar una regulatoria. Se puede reportar cero incidentes y aun así carecer de gobernanza. Ambas situaciones pueden darse el mismo día.

La situación se complica a medida que los agentes de IA pasan de responder preguntas a tomar medidas en sistemas de producción. Su equipo de seguridad puede proteger a un agente de los atacantes y aun así no tener forma de demostrar qué acciones tenía autorizadas. Este artículo explica cómo diferenciar ambos problemas, quién debe responsabilizarse de cada uno y qué preguntas hacer a los proveedores antes de su próxima implementación.

¿Qué es la seguridad de la IA?

La seguridad de la IA protege su sistema de inteligencia artificial y los datos que maneja de amenazas externas. Responde a una pregunta clave: ¿puede alguien infiltrarse, manipular el sistema o robar información?

Abarca tres áreas:

• El modelo . Protege el modelo de entradas adversarias, inyección instantánea y manipulación que lo empujen hacia una salida dañina.
• Los datos. Impide la exposición no autorizada o la filtración de los registros confidenciales a los que la IA puede acceder.
• La infraestructura. Refuerza la capacidad de procesamiento, la red y las integraciones sobre las que se ejecuta la IA para que los atacantes no puedan comprometerlas.

La seguridad basada en IA amplía la estrategia de seguridad que ya implementas. Mantienes los mismos equipos y las mismas disciplinas, pero añades una nueva superficie de ataque. Una organización de seguridad madura está bien preparada para afrontar esto. Son buenas noticias, pero también es donde empieza la confusión.
 

¿Qué es la gobernanza de la IA y por qué es diferente?

La gobernanza de la IA controla lo que hace tu IA cuando funciona exactamente como fue diseñada, sin la intervención de ningún atacante. Responde a una pregunta diferente: ¿qué está autorizada a hacer nuestra propia IA y podemos demostrarlo?

La gobernanza se basa en tres componentes:

• Autorización. Esto define qué puede hacer la IA, bajo qué condiciones y con qué alcance.
• Responsabilidad. Esto permite determinar quién aprobó cada acción y si existe algún registro que vincule la acción con esa persona.
• Auditabilidad. Esto determina si se puede mostrar a un regulador qué hizo la IA, cuándo y por qué, sin tener que reconstruir los eventos a partir de registros dispersos.

Seguridad pregunta: "¿Puede alguien entrar sin autorización?" Gobernanza pregunta: "¿Qué tiene permitido hacer mi propia IA y dónde están las pruebas?"

Un agente perfectamente protegido aún puede reiniciar una tarea incorrecta, leer datos que nunca necesitó o actuar sin autorización. Nada de esto se registra como un incidente de seguridad. Todo sale a la luz en una auditoría.
 

¿Por qué la seguridad de la IA y la gobernanza de la IA requieren equipos y marcos de trabajo diferentes?

Necesitan diferentes responsables porque los marcos que los sustentan miden aspectos distintos. Los marcos de seguridad como SOC 2, ISO 27001 y el Marco de Ciberseguridad del NIST se centran en las amenazas externas y en la protección de sistemas y datos. Son esenciales, pero no plantean cuestiones de gobernanza.

Los marcos de gobernanza se centran en el interior. El Marco de Gestión de Riesgos de IA del NIST, la Ley de IA de la UE, las directrices de gestión de riesgos de modelos de la OCC y la Ley de Resiliencia Operativa Digital (DORA) de la UE apuntan a las mismas expectativas: autorización clara, supervisión humana y decisiones trazables. Estos marcos no evalúan el perímetro de seguridad.

Si delegas la gobernanza al equipo de seguridad y le pides que utilice marcos de seguridad, obtendrás exactamente lo que esos marcos producen: una auditoría de seguridad. No obtendrás una arquitectura de gobernanza.

El mejor modelo divide la propiedad:

• La seguridad controla el perímetro. Protege el modelo, los datos y la infraestructura.
• Cumplimiento normativo, gestión de riesgos y operaciones de TI comparten la misma gobernanza. Estos equipos comprenden qué acciones conllevan riesgos empresariales y regulatorios.

Cada parte organiza sus propias reuniones, establece sus propios criterios de éxito y formula sus propias preguntas a los proveedores. Para los equipos de mainframe, la participación de las operaciones de TI en la toma de decisiones es fundamental. El personal de operaciones sabe qué trabajos por lotes no pueden reiniciarse a las 8 de la mañana y qué subsistemas dependen unos de otros.
 

¿Qué cuestiones distinguen la seguridad de la IA de la gobernanza de la IA?

La forma más rápida de distinguirlas es comparar las preguntas que cada una le hace a un proveedor. Utilice ambos conjuntos de preguntas en cada evaluación de IA.

Preguntas de seguridad que debe hacerse:

• ¿Cómo se protege el modelo de entradas adversarias?
• ¿Cómo se controla y registra el acceso a los datos para la detección de intrusiones?
• ¿Cuál es su proceso de respuesta ante incidentes si un atacante compromete el modelo?

Preguntas clave sobre gobernanza:

• ¿Qué funciones está autorizadas a realizar el agente de IA y cómo se garantiza el cumplimiento de dichas funciones?
• ¿Quién aprobó cada una de las acciones que realizó el agente y dónde se encuentra ese registro?
• ¿Puede generar un registro de auditoría inmutable de la actividad del agente para una revisión regulatoria?

Un proveedor que cumple bien con la primera lista pero falla en la segunda carece de una arquitectura de gobernanza. Ese proveedor ofrece un agente bien protegido del que nadie puede dar cuenta por completo.

¿Qué ocurre cuando se trata la seguridad y la gobernanza de la IA como si fueran lo mismo?

Se producen fallos de gobernanza que las herramientas de seguridad nunca detectan. Aquí hay tres ejemplos que se dan en operaciones reales.

La interrupción no fue autorizada. Un agente de IA reinició un proceso por lotes durante la jornada laboral, y los tiempos de respuesta colapsaron. El equipo de seguridad revisó los registros y no encontró ninguna brecha, intrusión ni anomalía. Pero nadie pudo determinar quién autorizó el reinicio, ya que no existía ningún proceso de aprobación. Esto constituye un fallo de gobernanza.

La auditoría que responde a la pregunta equivocada. Un organismo regulador solicita un registro de todas las acciones del agente de IA durante los últimos 90 días, incluyendo quién aprobó cada una. El equipo de seguridad genera un registro perimetral impecable. El registro demuestra que nadie vulneró la seguridad, pero no indica qué hizo el agente. Esto representa un fallo de gobernanza.

El agente con acceso total. Un agente de IA opera bajo las credenciales completas de un operador senior. No se ha producido ninguna brecha de seguridad ni se ha hecho mal uso de nada hasta el momento. Pero nada limita el alcance del agente, por lo que puede leer, modificar o eliminar todo lo que el operador pueda. Esto representa un fallo de gobernanza a punto de desencadenarse.

En todos los casos, su postura de seguridad se mantuvo. Su postura de gobernanza nunca existió.

¿Cómo se construyen la seguridad y la gobernanza de la IA sin confundirlas?

Ejecútalos como dos flujos de trabajo paralelos con responsables y criterios de evaluación independientes. No los fusiones en un solo programa. Sigue invirtiendo en seguridad y, a partir de ahí, desarrolla la capa de gobernanza que tu infraestructura de seguridad nunca fue diseñada para proporcionar.

Esa capa necesita cuatro capacidades:

• Identidad del agente: Cada agente actúa bajo sus propias credenciales, separadas de las del operador humano.
• Autorización limitada: Los agentes acceden únicamente a lo que requiere cada tarea.
• Controles de aprobación humana: Las acciones de alto riesgo se pausan hasta que una persona las autoriza.
• Registro de auditoría inmutable: Cada acción, su justificación y su aprobador quedan registrados de forma que nadie puede editarlos posteriormente.

Rocket^® EVA^™ Rocket EVA está diseñado con este tipo de arquitectura de gobernanza. A cada agente se le asigna una credencial temporal y con alcance definido. Aplica reglas operativas mediante políticas definidas por código y retiene las acciones de alto riesgo bajo aprobación humana. Además, registra cada paso en un registro de auditoría inmutable vinculado tanto al agente como al aprobador humano.

Rocket EVA se integra con su infraestructura de seguridad existente en lugar de reemplazarla. Esta infraestructura incluye gestión de identidades y accesos, gestión de servicios de TI y herramientas de observabilidad. Su equipo de seguridad mantiene el perímetro. Sus equipos de cumplimiento, riesgo y operaciones obtienen un registro que pueden defender. Sus operadores obtienen operaciones gobernadas basadas en agentes que aceleran los diagnósticos en entornos de mainframe, distribuidos y en la nube, sin generar nuevos riesgos.

No tienes que elegir entre actuar con rapidez y rendir cuentas. Si desarrollas ambos flujos de trabajo ahora, tu próxima implementación de IA se basará en una base que los reguladores reconocerán.

Descubre cómo la arquitectura de Rocket EVA aborda la gobernanza de la IA, no solo la seguridad.

Rocket es una marca registrada de Rocket Software, Inc. y sus filiales.