Gobernar la IA antes de escalarla: personas, agentes y herramientas
En las organizaciones que están adoptando IA generativa con rapidez, y especialmente en fintech y pagos, donde PCI DSS y la regulación financiera no son opcionales, aparece una historia muy parecida. Primero cada equipo construye su asistente, su agente de soporte o su automatización, y al poco tiempo nadie tiene un inventario completo de qué agentes existen ni qué pueden hacer. Muchos de esos agentes heredan los permisos amplios de la aplicación que los hospeda, o usan credenciales compartidas para llegar a APIs y herramientas, de modo que el acceso existe pero nadie lo definió explícitamente.
A esto se suma el crecimiento. Cuando una empresa adquiere otra, recibe también sus cuentas en la nube, su proveedor de identidad y sus propios estándares de compliance, y lo que antes era un entorno ya segmentado, ahora se convierte en varias islas. Aparecen además necesidades nuevas, como tomar un agente pensado para el cliente final y ofrecerlo también a B2B o a socios, lo que obliga a separar datos y permisos entre clientes. Y mientras tanto, el equipo de seguridad necesita una vista de conjunto de la postura de la organización que, en la mayoría de los casos, todavía arma a mano.
La conclusión es que el gobierno de la IA es, ante todo, un problema de identidad y acceso. No requiere inventar disciplinas nuevas: se resuelve con los mismos principios que ya aplicamos en la nube, como un único plano de identidad, mínimo privilegio, controles preventivos y auditoría centralizada, extendidos ahora a un nuevo tipo de actor.
Pero no es solo un tema de Seguridad. Un agente en producción es también una carga más de la plataforma: consume modelos y cómputo, depende de integraciones con otros sistemas y puede degradar servicios críticos si no está bien diseñado. Por eso el gobierno funciona mejor cuando Seguridad e IT lo ejercen juntos, como validadores y revisores de lo que construyen los equipos: Seguridad vela por los accesos y los datos, e IT por el costo, la performance, la estabilidad y la calidad de las integraciones que cada agente necesita. Pero, ¿cómo escala todo esto sin que seguridad e IT sean un cuello de botella?
Framework en cinco capas
Capa 1 — Una fundación multi-cuenta que absorbe el crecimiento
Todo empieza por ordenar dónde viven las cargas. Una organización de AWS gestionada siguiendo el Well-architected framework permite agrupar las cuentas por empresa o unidad de negocio y separarlas por entorno, de manera que cada adquisición se incorpora siguiendo un proceso estándar en lugar de quedar como una isla con reglas propias. Sobre esa estructura se definen los límites que no se negocian, como las regiones permitidas, qué servicios de IA se pueden usar o la imposibilidad de desactivar la auditoría, y se aplican de forma preventiva a toda la organización.
Esta capa también es la mejor herramienta para acotar el compliance. Si las cargas que procesan datos de tarjetas viven en cuentas dedicadas, el alcance de una auditoría PCI se reduce a esas cuentas y el resto de la organización puede innovar con más libertad.
Capa 2 — Un único punto de entrada para las personas
La identidad de las personas debería gestionarse en un solo lugar. El proveedor de identidad corporativo, sea cual sea, se federa (por ejemplo con IAM Identity Center), así que dar de alta o de baja a alguien ocurre una sola vez y se refleja en todas las cuentas y herramientas. Los permisos se asignan por rol y por grupo, nunca de forma individual.
Lo importante es que las herramientas de IA para el negocio entren por la misma puerta. Si un asistente como Amazon Quick usa esa misma identidad, los permisos sobre espacios, datos y agentes se derivan de los grupos que ya existen, y el equipo de seguridad gobierna la IA con el mismo modelo con el que gobierna todo lo demás.
Capa 3 — Los agentes también son identidades
Este es el cambio de mentalidad más importante. Un agente que consulta una base de datos, llama a una API o invoca una herramienta a través de MCP no es una extensión invisible de la aplicación: es un actor que necesita su propia identidad, permisos mínimos y un registro de lo que hace. Cuando un agente actúa en nombre de un usuario, además, debería llevar consigo el contexto de ese usuario, para que nunca pueda acceder a algo que la persona no podría ver.
En la práctica esto se resuelve con una plataforma común para hospedar los agentes, como Amazon Bedrock AgentCore, que les asigna identidad, guarda sus credenciales hacia servicios externos sin dejarlas en el código y concentra el acceso a las herramientas en un gateway. En lugar de que cada agente se conecte directamente a cada MCP, todos pasan por un punto de control donde se autentica quién llama y a qué tiene derecho. El resultado es que la pregunta «¿qué agente puede invocar qué herramienta, y en nombre de quién?» se responde mirando una configuración, no leyendo código.
El mismo principio resuelve el caso de un agente compartido entre varios clientes. Si el identificador de cada cliente viaja en la identidad del usuario y las herramientas filtran los datos en el backend, la separación queda garantizada por la capa de acceso y no depende de que el modelo obedezca una instrucción en el prompt.
Capa 4 — Límites sobre el comportamiento del modelo
La identidad define a qué puede acceder un agente; los guardrails definen qué puede decir y hacer con eso. Filtrar temas no permitidos, detectar y enmascarar datos personales en las entradas y salidas, y ajustar esos controles según el caso de uso, más estrictos para un agente que habla con el cliente final que para uno interno, es lo que permite exponer IA con confianza. Bedrock Guardrails permite definir estas políticas una vez y aplicarlas a distintos modelos y agentes.
La otra mitad de esta capa es mantener los datos sensibles fuera del alcance del modelo. Tokenizar números de tarjeta o de cuenta antes de que lleguen al agente, o al entrenamiento de un modelo, reduce el riesgo de exposición sin perder valor: una tokenización consistente, donde el mismo valor siempre genera el mismo token, sigue permitiendo agrupar operaciones o detectar comportamientos anómalos sin que nadie vea el dato real.
Capa 5 — Visibilidad para Seguridad e IT
Nada de lo anterior sirve si no se puede auditar. Un registro centralizado de todas las acciones, incluidas las invocaciones a modelos y lo que hace cada agente, permite reconstruir qué pasó, en nombre de quién y con qué datos. Sobre esa base, consolidar los hallazgos de seguridad y los controles de compliance de todas las cuentas en un mismo lugar, por ejemplo con Security Hub y Security Lake, le da al equipo de seguridad la vista de conjunto que hoy suele armar a mano.
La misma lógica aplica para IT. Medir la latencia, los errores y el consumo de tokens de cada agente, y asignar los costos por equipo o unidad de negocio a través del etiquetado de recursos, permite detectar a tiempo un agente que se volvió caro, lento o inestable, o una integración que se está saturando. La observabilidad de los agentes, con herramientas como CloudWatch y AgentCore Observability, junto con la gestión de costos, es tan parte del gobierno como la auditoría de accesos.
Llevar esa información a un dashboard que muestre la postura por empresa y por cuenta cambia la conversación con la dirección: el gobierno deja de ser una sensación y pasa a ser un indicador que se puede seguir en el tiempo.
Checklist: siete preguntas que Seguridad e IT deberían poder responder
- ¿Tenemos un inventario de todos los agentes en producción, con dueño y propósito?
- ¿Cada agente tiene identidad propia y permisos mínimos, o hereda los de su aplicación?
- ¿Los agentes acceden a herramientas y MCPs a través de un punto de control auditable?
- ¿Las altas y bajas de personas ocurren en un solo IdP que gobierna también las herramientas de IA?
- ¿Podemos reconstruir qué hizo un agente, en nombre de quién y con qué datos?
- ¿Cada agente tiene una métrica de negocio que justifique su costo?
- ¿Sabemos cuánto cuesta, cómo performa y qué tan estable es cada agente y sus integraciones, y quién responde si se degrada?
Si alguna respuesta es «no sé», ese es el punto de partida.
Podés encontrar otras preguntas habilitadoras de acciones acá.
Gobierno como habilitador
Un error frecuente es pensar que gobernar significa restringir. La experiencia nos muestra lo contrario: las organizaciones que más rápido ponen la IA en manos del negocio son las que primero resolvieron identidad, guardrails, auditoría y observabilidad. Cuando el marco está definido, Seguridad e IT pueden decir «sí» a nuevos casos de uso sin evaluar cada uno desde cero. El desafío es poder darle un marco a todo esto, mientras el negocio avanza.
Y si bien aquí nos enfocamos en la parte técnica, vale otra misma regla para cada iniciativa: ningún agente debería llegar a producción sin un business outcome y una métrica que lo midan. Gobernar es también saber qué valor aporta cada agente.
