Agentes de IA sobre tu ERP o CRM: cómo definir qué pueden y qué no pueden hacer con tus APIs

Después de leer esta guía sabrás cómo establecer, antes de conectar un agente autónomo a un sistema crítico, qué acciones puede ejecutar sin supervisión, cuáles requieren aprobación humana y cuáles deben estar técnicamente bloqueadas. Incluye ejemplos concretos para ERP, CRM y plataformas de RRHH, y distingue entre controles que funcionan en producción y promesas que solo existen en un PDF contractual.

Si has llegado aquí desde el caso del gimnasio, el punto de partida es claro: un agente explotó una vulnerabilidad en una API para avanzar en una lista de espera porque tenía objetivo claro y acceso amplio. La misma combinación que muchos equipos están a punto de poner en producción sobre su SAP, Salesforce o Workday.

---

1. Mapea las acciones disponibles antes de hablar de permisos

No puedes limitar lo que no has inventariado. El primer paso no es escribir políticas: es listar exhaustivamente qué puede hacer el agente a través de cada API que vas a conectar.

Para cada sistema, genera una tabla con tres columnas:

1. Endpoint / método: por ejemplo, POST /orders, DELETE /employee/{id}, PATCH /opportunity/stage.
2. Efecto en el mundo real: “crea un pedido en firme”, “borra un registro de empleado”, “cambia la fase de una oportunidad de venta”.
3. Reversibilidad: irreversible, reversible con auditoría, reversible automáticamente.

Este ejercicio suele revelar que las APIs empresariales exponen muchas más acciones de las que el equipo de negocio había imaginado. Un conector genérico de Salesforce, por ejemplo, puede incluir acceso a merge records, mass delete o change owner aunque nadie haya pedido esas funciones explícitamente.

---

2. Clasifica cada acción en tres niveles de riesgo

Con la tabla del paso anterior, clasifica cada acción:

• Verde – autónoma: el agente puede ejecutarla sin supervisión. Criterio mínimo: efecto reversible, dato no sensible, volumen acotado. Ejemplos: leer registros, generar borradores de oferta, crear tareas internas.
• Amarillo – supervisada: el agente prepara la acción y espera confirmación humana antes de ejecutarla. Ejemplos: enviar un email a un cliente, modificar el importe de una línea de pedido, cambiar el estado de un contrato.
• Rojo – bloqueada: el agente no tiene acceso técnico al endpoint, independientemente de lo que le pidas. Ejemplos: borrar registros, modificar configuración de permisos, ejecutar operaciones masivas sobre la base de datos, acceder a nóminas o datos de salud.

El criterio para lo rojo no es “poco probable que ocurra”: es “el daño si ocurre justifica eliminarlo del menú aunque complique el caso de uso”.

---

3. Implementa los controles técnicamente, no solo en el prompt

Aquí está la distinción más importante de esta guía: un prompt que dice “no borres nada” no es un control de seguridad. Es una sugerencia que el modelo puede ignorar si recibe instrucciones contradictorias, si sufre una inyección de prompt o si simplemente interpreta mal el contexto.

Los controles técnicamente aplicables son:

• API keys con scope reducido: genera credenciales específicas para el agente que solo cubran los endpoints de la lista verde. Si tu ERP no permite scopes granulares por endpoint, es una limitación real que debes documentar y compensar con otros controles.
• Cuentas de servicio sin privilegios de escritura en tablas críticas: en ERPs on-premise (SAP, Microsoft Dynamics), el agente opera con un usuario técnico cuyo perfil de autorización excluye transacciones destructivas.
• Rate limiting y cuotas por agente: limita el número de llamadas por minuto y por volumen de registros afectados. Un agente que puede modificar 5 registros por minuto tiene un radio de daño muy diferente a uno sin límite.
• Proxy o gateway de API intermediario: todo el tráfico del agente pasa por una capa que inspecciona y puede bloquear peticiones según reglas predefinidas antes de llegar al sistema de registro. Este es el control más robusto para la lista roja, pero también el más costoso de mantener.

Lo que no es un control técnico aplicable en producción:

• Las instrucciones del sistema del agente (“nunca hagas X”).
• Las cláusulas contractuales con el proveedor del agente sobre comportamiento permitido.
• La promesa del proveedor de que el modelo “no hará” determinadas acciones.

Esto no significa que esas capas sean inútiles: la inyección indirecta de prompts es un vector real, y las instrucciones del sistema son la primera línea de defensa ante él. Pero no son suficientes solas.

---

4. Define el mecanismo de aprobación humana para la lista amarilla

Las acciones supervisadas necesitan un flujo concreto, no una política abstracta. Para cada acción amarilla, especifica:

1. Quién aprueba: un rol, no una persona. Si es el responsable de cuenta en el CRM, documenta qué ocurre si está de baja.
2. En qué canal: un ticket en el sistema ITSM, una notificación en Teams con botones de aprobar/rechazar, un email con enlace firmado. Elige el canal que el aprobador realmente usa.
3. Con qué timeout: si el aprobador no responde en N horas, el agente cancela la acción o escala. La acción por defecto ante silencio debe ser no ejecutar, nunca ejecutar.
4. Qué información recibe el aprobador: el agente debe presentar la acción propuesta en lenguaje legible, no en JSON. “Quiero cambiar el importe del pedido P-2024-1847 de 12.400 € a 11.900 €” es aprobable. Un volcado de parámetros de API no lo es.

---

5. Registra todo lo que hace el agente, con suficiente detalle para auditar

Sin logs, no hay gobierno. El registro mínimo para cada acción ejecutada por el agente debe incluir:

• Timestamp exacto.
• Acción ejecutada y parámetros (con enmascaramiento de datos personales si aplica RGPD).
• Resultado: éxito, error, rechazado por aprobador.
• Si hubo aprobación humana: quién aprobó y cuándo.

Este log debe estar fuera del alcance de escritura del propio agente. Si el agente puede modificar su historial de acciones, el registro pierde valor como evidencia.

Para profundizar en cómo aplicar esto desde el principio, el principio de mínimo privilegio aplicado a agentes de IA desarrolla por qué los controles de API tradicionales no son suficientes por sí solos en contextos de agentes.

---

Errores más comunes al definir límites a agentes sobre APIs empresariales

Confiar solo en el prompt del sistema. Las instrucciones en lenguaje natural no son controles de seguridad. Son el primer escudo, no el único.

Dar al agente una cuenta de administrador “temporalmente”. Temporal se convierte en permanente. Las credenciales con privilegios elevados deben tener fecha de expiración técnica, no solo intención de revocarlas.

No inventariar los endpoints secundarios. Los agentes que usan conectores o SDKs heredan todos los métodos del conector, no solo los que el equipo de negocio pidió. Revisa el scope completo del conector, no solo el caso de uso principal.

Asumir que el proveedor del agente responde si algo va mal. Antes de conectar cualquier agente a un sistema crítico, revisa qué exigir al proveedor antes de desplegarlo y cómo auditar su seguridad. La cadena de responsabilidad no se define sola.

Omitir el escenario de fallo del mecanismo de aprobación. Si el sistema de notificaciones cae, ¿qué hace el agente? Si la respuesta es “ejecutar igualmente”, el mecanismo de aprobación no existe en producción.

---

Qué cubre esta guía: pasos para establecer límites operativos reales a agentes autónomos sobre ERP, CRM y RRHH
Controles técnicos: scopes de API, cuentas de servicio sin privilegios, rate limiting, proxy de API
Controles no técnicos (insuficientes solos): instrucciones de prompt, cláusulas contractuales
Mecanismo de aprobación: opt-in, no opt-out; silencio = inacción
Estado: guía práctica, sin verificación en producción por redacción