La inteligencia artificial está dejando de ser una herramienta aislada para convertirse en una capa que se conecta con prácticamente todo el ecosistema tecnológico de una empresa. Un asistente puede consultar el CRM, otro puede buscar información en documentos internos y un agente puede incluso crear registros, enviar correos o ejecutar determinadas acciones en un ERP. El problema es que cada una de esas conexiones amplía la superficie de ataque de la organización. La pregunta ya no es solamente si el modelo de IA es seguro, sino qué información puede consultar, qué sistemas puede utilizar y qué acciones está autorizado a ejecutar.
Esto representa un cambio importante frente a la arquitectura tradicional. Durante años, buena parte de la estrategia de seguridad se concentró en proteger servidores, estaciones de trabajo, redes y aplicaciones. Ahora existe una nueva capa entre el usuario y los sistemas corporativos: modelos de lenguaje, agentes, APIs, conectores, plugins y servicios externos que pueden intercambiar información entre sí. Una integración mal diseñada puede convertirse en una puerta de entrada incluso cuando los sistemas que están detrás de ella cuentan con controles de seguridad adecuados.
El problema no es conectar sistemas, sino conectarlos sin control
Las empresas llevan décadas integrando software mediante APIs. El concepto no es nuevo: un sistema de facturación consulta al ERP, el CRM obtiene información de clientes y una tienda en línea se comunica con el inventario. Lo que está cambiando con la IA es la cantidad de decisiones que pueden quedar en manos de una aplicación capaz de interpretar lenguaje natural y utilizar diferentes herramientas para completar una tarea.
Imaginemos, por ejemplo, un agente conectado al CRM que recibe una instrucción como «revisa los clientes que tienen pagos pendientes y prepara un correo para cada uno». Técnicamente, el agente podría necesitar acceso a información financiera, datos de contacto y una plataforma de correo. El riesgo aparece cuando, en lugar de otorgarle únicamente los permisos necesarios para consultar esa información y preparar los mensajes, se le entrega una cuenta con capacidad para modificar clientes, eliminar registros o enviar comunicaciones sin ningún tipo de validación. El problema, en este caso, no es que la IA sea impredecible: es que la arquitectura le otorgó más capacidad de la que realmente necesitaba.
Cada API nueva es también una nueva superficie de ataque
Una API funciona como una puerta controlada entre dos sistemas. Y, como cualquier puerta, necesita saber quién entra, qué puede hacer y bajo qué condiciones. En un entorno empresarial esto significa utilizar autenticación adecuada, autorización granular, límites de uso, validación de las solicitudes, registros y mecanismos para revocar rápidamente el acceso cuando sea necesario.
El problema aparece cuando las APIs se implementan pensando únicamente en que «funcionen». Una clave API compartida por varios sistemas, una cuenta de servicio con permisos administrativos o un token que nunca expira pueden convertirse en problemas importantes si llegan a quedar expuestos. Cuando además esa API es utilizada por un agente de IA, el impacto potencial aumenta porque la aplicación puede realizar muchas operaciones de manera automática y a una velocidad que un usuario humano difícilmente podría alcanzar.
Por eso, el principio de mínimo privilegio adquiere todavía más importancia. Si un agente solamente necesita consultar información del inventario, debería tener acceso de lectura sobre esa información; no debería contar simultáneamente con permisos para cambiar precios, eliminar productos o modificar usuarios. OWASP identifica precisamente el exceso de permisos y de autonomía como uno de los riesgos relevantes en aplicaciones basadas en LLM, señalando que las funciones, permisos y capacidades disponibles para un modelo deben limitarse al mínimo necesario.
Un modelo de IA no debería decidir qué está autorizado a hacer
Existe una diferencia importante entre pedirle a una IA que proponga una acción y permitirle ejecutarla directamente. Un modelo puede interpretar correctamente una solicitud la mayoría de las veces y aun así producir una respuesta equivocada o ser manipulado mediante instrucciones diseñadas para alterar su comportamiento. Por esa razón, la autorización no debería depender exclusivamente de lo que el modelo interprete.
En una arquitectura bien diseñada, el modelo puede solicitar una determinada operación, pero el sistema que recibe esa solicitud debe comprobar si realmente está permitido ejecutarla. Si un agente intenta consultar información financiera, por ejemplo, la API debería verificar la identidad y los permisos antes de entregar los datos. Si intenta modificar un registro crítico, la aplicación puede exigir una autorización adicional. De esta forma, la IA funciona como una capa de interacción y automatización, pero los sistemas empresariales siguen siendo responsables de hacer cumplir sus propias reglas de seguridad.
El caso de Samsung: cuando el problema está en cómo se utilizan los datos
Un caso que ayuda a entender este riesgo ocurrió en Samsung en 2023. La compañía confirmó que algunos empleados habían introducido información sensible en ChatGPT, incluyendo código fuente y otros datos internos. El incidente llevó a Samsung a restringir temporalmente el uso de herramientas generativas externas y a establecer medidas adicionales para controlar cómo podían utilizarse estos servicios dentro de la organización.
El caso resulta interesante porque no fue necesario que un atacante vulnerara un firewall o explotara una vulnerabilidad de un servidor para generar el problema. Bastó con que información corporativa llegara a una herramienta externa sin los controles adecuados. Es una situación que puede repetirse de formas mucho más sofisticadas a medida que las empresas comienzan a conectar automáticamente sus sistemas con modelos de IA: un empleado puede copiar información en una herramienta, pero también una integración puede enviar datos a una API sin que el usuario sea plenamente consciente de qué información está saliendo de la organización.
El prompt injection cambia parte de las reglas
Las aplicaciones tradicionales suelen distinguir de manera bastante clara entre instrucciones y datos. Una consulta SQL, por ejemplo, puede ser validada antes de llegar a una base de datos. En las aplicaciones basadas en modelos de lenguaje, esa separación es más compleja porque el sistema trabaja precisamente interpretando texto y contexto.
Esto permite un tipo de ataque conocido como prompt injection. Un atacante puede intentar introducir instrucciones diseñadas para modificar el comportamiento del modelo, ya sea directamente a través de una conversación o indirectamente mediante un documento, correo electrónico, página web u otra fuente que el agente pueda consultar. OWASP considera el prompt injection uno de los principales riesgos de las aplicaciones basadas en LLM y advierte que sus consecuencias pueden incluir la exposición de información o la ejecución de acciones no previstas.
El problema se vuelve mucho más serio cuando el modelo tiene herramientas a su disposición. Un chatbot que simplemente genera una respuesta puede producir información incorrecta; un agente con acceso a sistemas corporativos podría, dependiendo de su diseño, convertir esa misma manipulación en una acción. Por eso es fundamental separar el contenido que el modelo interpreta de los permisos que realmente tiene la aplicación y establecer controles entre ambos.
Los datos también necesitan protección cuando pasan por RAG
Muchas empresas están utilizando arquitecturas RAG para conectar modelos de lenguaje con sus propios documentos. En lugar de entrenar nuevamente un modelo, la aplicación busca información relevante en una base documental o vectorial y se la proporciona al modelo como contexto. Es una solución muy útil para construir asistentes internos, pero tampoco está exenta de riesgos.
El hecho de que un documento esté dentro de una base vectorial no significa que cualquier usuario deba poder recuperarlo. Si un empleado no tiene autorización para acceder a determinada información en el sistema original, la capa de IA tampoco debería permitirle recuperarla mediante una consulta formulada en lenguaje natural. OWASP incluye las debilidades relacionadas con vectores y embeddings entre los riesgos de las aplicaciones modernas de IA precisamente porque la capa de recuperación se convierte en otro componente que debe protegerse.
Esto obliga a pensar en algo que a veces se pasa por alto: la seguridad de los datos debe acompañarlos durante todo el recorrido. No basta con proteger la base de datos original si después se crea una nueva copia en un índice vectorial sin los mismos controles de acceso, trazabilidad y actualización.
La cadena de suministro también entra en juego
Una aplicación empresarial rara vez está construida completamente desde cero. Utiliza librerías de código abierto, SDK, APIs de terceros, servicios cloud, plugins, modelos preentrenados y diferentes componentes desarrollados por proveedores externos. En una aplicación tradicional ya existe el riesgo asociado a esta cadena de suministro; con IA, el número de componentes puede crecer considerablemente.
Por eso, antes de incorporar un nuevo conector o servicio de IA, conviene revisar qué permisos solicita, qué información procesa, dónde se almacenan los datos, cómo se gestionan las credenciales y qué ocurre cuando la empresa decide dejar de utilizarlo. OWASP también reconoce la vulnerabilidad de la cadena de suministro como un riesgo relevante para las aplicaciones basadas en LLM, especialmente porque un componente comprometido puede afectar a múltiples aplicaciones que dependen de él.
No significa que las empresas deban evitar las herramientas de terceros. Significa que una integración no debería aprobarse únicamente porque «resuelve el problema». También debe pasar por una revisión técnica y de seguridad proporcional al acceso que tendrá dentro de la organización.
No todas las acciones deberían ser completamente automáticas
Uno de los errores más habituales al diseñar agentes de IA consiste en asumir que automatizar significa eliminar cualquier intervención humana. En realidad, existen operaciones que pueden automatizarse sin mayor riesgo y otras donde una aprobación adicional resulta razonable.
Generar un resumen de un documento probablemente no requiere autorización humana. Modificar una base de datos, aprobar un pago, eliminar información o enviar una comunicación masiva puede ser diferente. En estos casos, una arquitectura puede utilizar un esquema de human-in-the-loop, donde el agente prepara la acción y un usuario autorizado la aprueba antes de ejecutarla.
Esto permite aprovechar la velocidad de la automatización sin convertir al agente en una especie de usuario administrativo con acceso indiscriminado a todos los sistemas. La autonomía debería aumentar de acuerdo con el nivel de confianza y con el impacto potencial de las acciones, no simplemente porque técnicamente sea posible automatizarlas.
Saber qué hizo la IA es tan importante como controlar lo que puede hacer
Cuando una aplicación tradicional presenta un comportamiento extraño, los equipos de TI suelen revisar logs, usuarios, conexiones y cambios realizados. En una arquitectura con IA, esa trazabilidad debe ser todavía más completa porque una misma operación puede involucrar al usuario, la aplicación, el modelo, una base de conocimiento y varias APIs.
Por eso debería ser posible reconstruir una operación y saber quién inició la solicitud, qué modelo intervino, qué información recuperó, qué herramientas utilizó, con qué identidad se realizaron las llamadas y qué cambios se produjeron posteriormente. Sin esta información, investigar un incidente puede convertirse en reconstruir una historia a partir de fragmentos.
La observabilidad también permite detectar comportamientos anómalos antes de que se conviertan en una brecha. Un agente que normalmente realiza unas pocas consultas al día y de repente empieza a solicitar miles de registros, por ejemplo, debería generar una alerta. La seguridad de la IA no termina en impedir accesos; también consiste en detectar cuando un sistema comienza a comportarse de una manera que no corresponde con su función.
La seguridad debe entrar antes que la integración
Uno de los cambios más importantes en la gestión de proyectos de IA debería ser dejar de pensar en la seguridad como una revisión que ocurre al final. Si primero se conecta el CRM, después el ERP, luego el correo y finalmente se intenta determinar quién puede acceder a qué información, probablemente ya exista una arquitectura difícil de corregir.
Es más eficiente definir desde el principio qué datos necesita el caso de uso, qué acciones debe realizar la IA, qué sistemas estarán involucrados y qué permisos requiere cada componente. A partir de ahí pueden diseñarse las APIs, las identidades, los controles de autorización, los registros y los mecanismos de aprobación. El enfoque de Secure by Design, promovido por CISA para sistemas de IA, plantea precisamente incorporar la seguridad desde las etapas iniciales del diseño y desarrollo, en lugar de tratarla como un elemento posterior.
La pregunta no es si vas a integrar IA, sino cómo vas a hacerlo
Las empresas probablemente seguirán conectando inteligencia artificial con sus sistemas internos. La oportunidad de automatizar procesos, consultar información y construir nuevos servicios es demasiado importante como para ignorarla. El reto está en hacerlo sin convertir cada nueva integración en una puerta adicional que nadie sabe exactamente quién controla.
Una arquitectura de IA empresarial debería partir de una premisa sencilla: la IA puede tener acceso a información y herramientas, pero ese acceso debe ser explícito, limitado y trazable. Las APIs deben validar las solicitudes, los permisos deben responder al principio de mínimo privilegio, los datos deben conservar sus controles de acceso y las operaciones de mayor impacto deberían contar con mecanismos adicionales de validación.
Al final, muchas de las vulnerabilidades de la era de la IA no aparecerán porque una empresa haya instalado un modelo inseguro. Pueden aparecer porque se conectó un modelo perfectamente funcional con demasiados sistemas, demasiados permisos y muy pocos controles. La inteligencia artificial puede convertirse en una poderosa capa de productividad, pero la arquitectura que la rodea seguirá siendo la primera línea de defensa.