Saltar al contenido
← Insights

Gobernanza y seguridad

Por qué los agentes de IA no deben usar cuentas de personas

Los agentes de IA que operan con credenciales de empleados destruyen la trazabilidad y transfieren riesgos operativos graves a la cuenta de quien cedió el acceso.

Por Renato Paes Leme

Cuando un agente de inteligencia artificial recibe el inicio de sesión de un empleado para automatizar tareas, la empresa pierde la capacidad de auditar sus operaciones. La ganancia inmediata de velocidad cuesta la eliminación del límite entre lo que decidió una persona y lo que ejecutó un modelo probabilístico. Productividad sin trazabilidad no es eficiencia, es pasivo oculto.

La cuenta prestada y el colapso de la auditoría

Considere un área de compras con un alto volumen de facturas y registros. Para ahorrar tiempo, el equipo conecta un agente al correo corporativo y al ERP utilizando la credencial de un comprador sénior. La función del agente es leer mensajes de proveedores, extraer comprobantes y actualizar registros de rutina.

Llega un mensaje solicitando el cambio de domicilio bancario de un proveedor de servicios. El agente interpreta el texto como legítimo y ejecuta la modificación del registro directamente en el sistema. En el log de seguridad del ERP, la transacción registra el identificador del comprador, a la misma hora en que él participaba en una reunión interna.

Si esa modificación resulta ser un fraude externo o un error de procesamiento, la empresa no puede separar técnicamente tres eventos distintos: el ingreso de la información, la interpretación del agente y la aprobación del empleado. Para el sistema y para la auditoría contable, el empleado cometió la acción. Si el equipo de seguridad decide interrumpir al agente de forma preventiva, tendrá que bloquear la cuenta del propio profesional, paralizando sus actividades operativas.

Controles del sistema versus instrucciones de contexto

El error común en esta transición es tratar las restricciones en el prompt de comando como controles de seguridad de la información. Escribirle al modelo "nunca modifique datos bancarios" no equivale a denegar el permiso técnico de escritura en la tabla de proveedores. Si la credencial utilizada tiene permiso para escribir en la base de datos, el riesgo permanece activo. Un error de interpretación o una manipulación en el texto del mensaje recibido puede ignorar la instrucción.

Además, diseñar flujos con aprobaciones humanas genéricas genera fatiga de consentimiento. Cuando un profesional recibe decenas de solicitudes automáticas de confirmación por hora, el análisis crítico desaparece. El clic en la confirmación se vuelve mecánico y la responsabilidad jurídica recae sobre el operador, enmascarando la ausencia de gobernanza en el proceso.

Los pilares de la identidad autónoma

Los agentes que consultan datos, modifican registros o disparan transacciones deben tratarse como identidades de servicio independientes. Esta separación exige cinco parámetros fundamentales:

Primero, identidad propia. Cada agente debe poseer una credencial única, asociada a una cuenta no humana claramente identificada en los registros del sistema.

Segundo, delegación explícita. El sistema debe registrar formalmente en nombre de qué usuario o área de negocio está actuando el agente y para qué alcance específico.

Tercero, permisos mínimos y temporales. El acceso debe limitarse al recurso estrictamente necesario para la operación, con validez corta y revocación programada.

Cuarto, segregación de funciones. El permiso de lectura no puede incluir acceso de escritura. La capacidad de completar un registro jamás debe conceder autorización para la aprobación o liberación de pagos.

Quinto, pista de auditoría completa. El log debe registrar cuatro datos en secuencia: la intención del flujo, la autorización concedida, la llamada técnica de la acción y el resultado obtenido.

El ciclo de vida antes de la autonomía

Antes de expandir la autonomía de los agentes en sistemas críticos, el liderazgo ejecutivo debe exigir respuestas claras a tres preguntas operativas: qué identidad presenta el agente en la API, qué acciones tiene técnicamente impedido realizar y cómo se reconstruirá una transacción en detalle dentro de seis meses.

Las referencias técnicas para esta estructuración ya están consolidadas en las discusiones del NIST sobre identidades no humanas y en las directrices de OWASP sobre control de privilegios. Las respuestas no están en declaraciones de principios éticos, sino en la configuración de los logs y en la arquitectura de acceso de la infraestructura.

Los agentes de software deben nacer con un propósito definido, operar bajo un alcance monitoreado y permitir una suspensión inmediata sin afectar a las personas. La gobernanza efectiva en inteligencia artificial no comienza en comités teóricos, sino en la garantía de que cualquier acción dentro del sistema corporativo sea técnicamente limitada, atribuible y revocable.

Por Renato Paes Leme — 20 sept 2026

¿Quiere entender cómo se aplica este tema a su empresa?

Podemos conversar sobre su contexto y los próximos pasos.