De seguridad de IA a seguridad de agentes

La seguridad de la IA empresarial no puede resolverse simplemente aplicando los controles tradicionales a una nueva clase de software.

La razón es sencilla: la IA cambia qué puede hacer un sistema, qué información puede interpretar y cómo puede interactuar con el entorno empresarial.

Durante años, la seguridad tecnológica se construyó alrededor de aplicaciones, usuarios, redes, dispositivos y datos. Con la incorporación de IA generativa y sistemas agénticos, aparece una nueva superficie de riesgo: sistemas capaces de interpretar lenguaje, inferir intenciones, trabajar con información no estructurada y, cada vez más, ejecutar acciones.

Esto obliga a replantear una pregunta fundamental:

¿Cómo protegemos sistemas que no solo procesan instrucciones, sino que pueden interpretar contexto y actuar sobre él?

La IA amplía la superficie de riesgo

Una implementación empresarial de IA puede interactuar con muchas más fuentes y sistemas que una aplicación convencional.

Puede consultar documentos internos, recuperar información desde diferentes repositorios, utilizar APIs, procesar conversaciones, acceder a herramientas empresariales o generar respuestas que posteriormente desencadenan acciones.

Cada nueva conexión aumenta el valor potencial del sistema.

Pero también aumenta la superficie que debe protegerse.

El riesgo ya no está únicamente en el modelo.

Está en todo el sistema que lo rodea:

• los datos que puede consultar;
• las instrucciones que recibe;
• las herramientas que puede utilizar;
• las identidades con las que opera;
• los sistemas a los que puede acceder;
• y las decisiones o acciones que sus resultados pueden desencadenar.

Por eso, proteger IA empresarial exige pensar más allá del modelo.

El modelo no es el único activo que debe protegerse

En muchas conversaciones sobre seguridad de IA, la atención se concentra en proteger el modelo.

Eso es necesario, pero insuficiente.

Un modelo puede estar correctamente protegido y aun así existir un riesgo importante en la arquitectura que lo utiliza.

Por ejemplo, un sistema puede tener controles adecuados sobre su API, pero permitir que el modelo acceda a información que el usuario original no debería poder consultar.

También puede existir una política correcta de acceso a datos, pero una herramienta conectada al agente permitir una acción que exceda el propósito original del sistema.

La seguridad debe proteger el conjunto de relaciones entre modelo, identidad, datos, herramientas y acciones.

El dato se convierte en una superficie dinámica

La IA empresarial aumenta el valor de los datos internos porque puede convertir grandes volúmenes de información dispersa en contexto operativo.

Pero esa capacidad también introduce nuevos riesgos.

No basta con preguntar:

“¿Quién puede acceder a esta base de datos?”

También hay que preguntar:

• ¿Qué información puede recuperar el sistema de IA?
• ¿Con qué contexto puede combinarla?
• ¿Puede mezclar información de diferentes niveles de sensibilidad?
• ¿Qué ocurre cuando un documento cambia sus permisos?
• ¿Cómo se revoca el acceso?
• ¿Qué información puede aparecer en una respuesta?
• ¿Qué queda registrado sobre esa consulta?

La seguridad de los datos debe acompañar al dato hasta el momento en que es utilizado por la IA.

Esto resulta especialmente importante en arquitecturas de conocimiento empresarial, donde la recuperación de información forma parte del funcionamiento cotidiano del sistema.

La identidad sigue siendo el perímetro fundamental

La llegada de IA no elimina los principios fundamentales de seguridad.

Los vuelve más importantes.

Cada usuario, servicio y agente debe tener una identidad claramente definida.

Y esa identidad debe determinar qué información puede consultar y qué acciones puede realizar.

Una arquitectura madura evita depender de accesos genéricos o credenciales compartidas.

En su lugar, establece:

• identidades diferenciadas;
• privilegios mínimos;
• permisos específicos;
• separación de funciones;
• autenticación adecuada;
• y trazabilidad de las operaciones.

La pregunta correcta no es simplemente:

“¿El sistema está autenticado?”

Sino:

“¿Está autenticado exactamente quién —o qué— debe ejecutar esta acción, con exactamente los privilegios necesarios?”

El contexto también necesita protección

Los sistemas de IA trabajan con contexto.

Ese contexto puede incluir instrucciones, documentos, conversaciones, resultados de búsquedas, datos operativos y señales provenientes de otros sistemas.

Si ese contexto no está correctamente gobernado, un atacante o incluso una fuente de información maliciosa puede intentar alterar el comportamiento del sistema.

Este problema adquiere especial relevancia cuando la arquitectura utiliza información externa o contenido que no está completamente bajo control de la organización.

Por eso, la seguridad debe considerar no solamente quién puede acceder a un sistema, sino qué información puede influir en su comportamiento.

De la seguridad de aplicaciones a la seguridad de decisiones

Existe una diferencia importante entre una aplicación que procesa una solicitud y un sistema que puede influir en una decisión empresarial.

Una aplicación tradicional puede producir un resultado incorrecto.

Un sistema de IA puede producir una recomendación que posteriormente sea interpretada como válida por una persona o utilizada automáticamente por otro sistema.

Cuando la IA participa en procesos críticos, la seguridad debe considerar también las consecuencias de sus resultados.

Esto introduce una nueva dimensión:

no solo debemos proteger el sistema; debemos proteger la cadena de decisión que depende de él.

En procesos financieros, operativos, regulatorios o de atención al cliente, esa distinción puede ser determinante.

La observabilidad es parte de la seguridad

Si una organización no puede reconstruir qué ocurrió, tampoco puede investigar adecuadamente un incidente.

En sistemas de IA esto es más complejo que registrar una llamada a una API.

Puede ser necesario conocer:

• quién inició la interacción;
• qué identidad utilizó el sistema;
• qué información recuperó;
• qué instrucciones recibió;
• qué herramientas utilizó;
• qué resultado generó;
• qué acción se ejecutó posteriormente;
• y qué sistemas fueron afectados.

La trazabilidad debe diseñarse desde el principio.

No como una capacidad que se agrega después de que ocurre un incidente.

Una arquitectura que no puede explicar sus propias operaciones es difícil de asegurar a escala empresarial.

Seguridad no significa bloquear la innovación

Existe un riesgo contrario: responder a la incertidumbre creando controles tan restrictivos que la organización no pueda utilizar IA de forma efectiva.

Ese enfoque tampoco es sostenible.

El objetivo de la seguridad empresarial no debería ser eliminar todo riesgo.

Debería ser hacer que el riesgo sea conocido, controlable y proporcional al impacto potencial.

Una aplicación experimental de bajo impacto no necesita necesariamente los mismos controles que un agente capaz de modificar información financiera.

La madurez consiste en diferenciar ambos escenarios.

Cuanto mayor sea el impacto potencial, mayor debe ser la capacidad de prevención, supervisión y recuperación.

La seguridad debe evolucionar con la autonomía

No todos los sistemas de IA representan el mismo nivel de riesgo.

Podemos imaginar una progresión:

IA informativa → IA asistida → IA recomendadora → IA operativa → IA autónoma.

A medida que aumenta la autonomía, también aumenta el impacto potencial de un error, una vulnerabilidad o un uso indebido.

Por eso, la arquitectura de seguridad debe evolucionar en paralelo.

Un sistema que únicamente genera un resumen puede necesitar controles relativamente simples.

Un agente que puede modificar sistemas empresariales necesita controles mucho más rigurosos sobre identidad, autorización, observabilidad, intervención y recuperación.

La autonomía no debería crecer más rápido que la capacidad de control.

La arquitectura debe asumir que algo fallará

Ningún sistema complejo debería diseñarse suponiendo que todos sus controles funcionarán siempre.

La pregunta relevante es qué ocurre cuando alguno falla.

Una arquitectura empresarial de IA debería poder responder:

• ¿Cómo se detecta un comportamiento anómalo?
• ¿Cómo se revoca un acceso?
• ¿Cómo se limita una herramienta?
• ¿Cómo se detiene un proceso?
• ¿Cómo se recupera el sistema?
• ¿Cómo se investiga lo ocurrido?
• ¿Cómo se evita que vuelva a suceder?

La capacidad de recuperación es tan importante como la prevención.

Esto es especialmente relevante para sistemas que incorporan cierto grado de autonomía.

El verdadero desafío es proteger el sistema completo

La seguridad de IA empresarial no es una función aislada del equipo de ciberseguridad.

Es una propiedad de la arquitectura completa.

Incluye:

identidad → datos → contexto → modelo → herramientas → decisiones → acciones → observabilidad → recuperación.

Cada componente introduce riesgos diferentes.

Y una debilidad en cualquiera de ellos puede comprometer el conjunto.

Por eso, las organizaciones que están llevando IA a producción necesitan dejar atrás la idea de que “seguridad” significa simplemente proteger el modelo o controlar el acceso a una API.

El objetivo es construir un sistema en el que la IA pueda operar dentro de límites explícitos y verificables.

La seguridad como habilitador de la confianza empresarial

La seguridad no debería ser una barrera que aparece cuando un piloto está listo para producción. Debe formar parte de la arquitectura desde el momento en que se define qué información utilizará la IA, qué sistemas podrá tocar y qué impacto tendrán sus decisiones.

El desafío no es simplemente implementar controles de seguridad alrededor de la IA, sino determinar si la arquitectura empresarial tiene la capacidad de absorber el riesgo asociado al nivel de autonomía que se pretende habilitar.

La confianza en la IA empresarial no se declara. Se construye arquitectónicamente.

Controlada y segura, la IA debe demostrar su valor. El ROI es el siguiente tema.