Por Marilyn Cortéz, Miembro de Ciberwarmi, ASICI y WomCy
Incorporar modelos y agentes exige controlar la información que reciben, los permisos que utilizan y las acciones que pueden ejecutar.
Ejes de análisis
- Cada dato abre una decisión
- Los permisos marcan el riesgo
- La vigilancia continúa en producción
Un asistente consulta documentos internos, un modelo resume contratos y un agente ejecuta acciones sobre sistemas corporativos. En cada caso, la aplicación entrega información a un componente que puede operar dentro o fuera de la organización.
Antes de habilitar estas funciones deben responderse varias preguntas: ¿qué datos recibirá el modelo?, ¿dónde serán procesados?, ¿el proveedor podrá conservarlos o utilizarlos para entrenamiento?, ¿qué sistemas estarán al alcance de la aplicación? y ¿cómo se detendrá la integración si presenta un comportamiento inesperado?
Estas preguntas trasladan la seguridad al inicio del proyecto. La clasificación de los datos, la gestión de accesos, la protección de credenciales y la trazabilidad deben definirse antes de conectar el modelo. Una revisión posterior puede llegar cuando la información ya fue expuesta o cuando el componente automatizado tiene más permisos de los necesarios.
La incorporación de IA también cambia la arquitectura de la aplicación. A los componentes tradicionales se suman modelos, servicios externos, repositorios de contexto, vectores o embeddings, instrucciones y, en algunos casos, agentes capaces de actuar sobre otros sistemas. Cada elemento crea nuevas dependencias y amplía la superficie que debe protegerse.
Entre los riesgos se encuentran la inyección de instrucciones, la exposición de información sensible y la asignación de permisos excesivos a componentes automatizados. El modelo debe gestionarse como otro elemento de la arquitectura y someterse a controles durante el diseño, el desarrollo y la operación.
Cada dato abre una decisión
La revisión comienza con el caso de uso y el recorrido de la información. La organización debe identificar qué datos ingresarán, de dónde provienen, quién podrá consultarlos, dónde serán procesados y qué aplicaciones utilizarán las respuestas.
También necesita evaluar el impacto de un resultado incorrecto o manipulado. Un modelo que redacta un borrador interno tiene un nivel de riesgo diferente al de una solución que consulta expedientes, procesa información sensible o ejecuta acciones sobre sistemas críticos.
El OWASP Top 10 para aplicaciones con modelos de lenguaje y el NIST AI Risk Management Framework ofrecen referencias para identificar los riesgos durante el ciclo de vida. Su aplicación dependerá de las características y el alcance de cada solución.
El gobierno del dato parte de una pregunta directa: ¿el modelo necesita esa información para cumplir su función? La clasificación y la minimización permiten establecer qué datos se requieren y bajo qué condiciones pueden utilizarse.
La información pública o de baja sensibilidad puede procesarse con controles proporcionales. Cuando la aplicación necesita contexto, pero no requiere conocer la identidad de una persona, pueden utilizarse técnicas de enmascaramiento, seudonimización o anonimización. Estas medidas deben considerar el riesgo de reidentificación.
Las credenciales, los secretos, los datos sensibles y la información regulada requieren mayores restricciones. Su envío a servicios externos debe estar respaldado por una evaluación de riesgo, una base legal, controles técnicos y un entorno autorizado.
El criterio consiste en entregar al modelo únicamente la información necesaria para el caso de uso. La disponibilidad técnica de un dato no justifica su utilización.
El proveedor también interviene en el tratamiento de la información. Antes de contratar o integrar un servicio, la organización debe conocer si los datos enviados se utilizan para entrenar el modelo, cuánto tiempo se conservan, en qué regiones se almacenan y procesan, y qué terceros participan.
La evaluación comprende los mecanismos de eliminación, las condiciones de cifrado y acceso, y los procedimientos para notificar incidentes. Los acuerdos de tratamiento de datos, las certificaciones disponibles y las posibilidades de auditoría ayudan a determinar si el servicio responde a los requerimientos establecidos.
La transparencia del proveedor permite conocer qué sucede con la información después de enviarla.
Los permisos marcan el riesgo
Los controles de acceso deben aplicarse a las personas, las aplicaciones y los componentes que interactúan con el modelo. El principio de mínimo privilegio, la autenticación robusta y el acceso basado en roles limitan la información y las funciones disponibles para cada usuario o proceso.
Este control adquiere mayor importancia con los agentes de IA. Un agente puede consultar información y ejecutar acciones sobre otros sistemas. Sus permisos deben corresponder a las tareas autorizadas y a los datos necesarios para realizarlas.
Las claves de API y otros secretos requieren mecanismos de administración y rotación. Mantenerlos expuestos en el código o en archivos de configuración facilita su utilización indebida. La información sensible debe protegerse con cifrado durante su transmisión y almacenamiento.
La trazabilidad permite registrar quién utilizó el servicio, cuándo accedió y qué operación realizó. Estos datos apoyan las auditorías y la investigación de incidentes. Sin embargo, el registro puede convertirse en otra fuente de exposición si almacena instrucciones y respuestas completas que contienen información sensible.
Los registros también necesitan minimización, controles de acceso y períodos de retención. La organización debe conservar los elementos necesarios para supervisar la aplicación sin crear nuevos repositorios de información sensible.
La vigilancia continúa en producción
Las prácticas DevSecOps permiten incorporar estos controles durante el desarrollo. Además de revisar el código y sus dependencias, las pruebas deben considerar amenazas relacionadas con la IA, como la inyección de instrucciones, la exposición de información y el uso inseguro de las respuestas.
Las salidas generadas por el modelo deben validarse antes de ser utilizadas por otro componente. Una respuesta puede contener información incorrecta o instrucciones manipuladas. El riesgo aumenta cuando esa salida activa un proceso, modifica datos o ejecuta una acción dentro de un sistema corporativo.
En producción, el monitoreo debe identificar accesos anómalos, consumos inusuales y cambios en el comportamiento de la aplicación. La organización también necesita procedimientos para revocar credenciales, regresar a una versión anterior o desconectar la integración cuando exista un riesgo para los datos o la operación.
Integrar IA en una aplicación empresarial implica conocer qué información se utiliza, quién puede acceder a ella, qué tratamiento realiza el proveedor y qué acciones puede ejecutar la solución.
