Cuando se habla de seguridad de los agentes de IA en reservas con CRM y ERP, el riesgo deja de ser abstracto: son cambios en registros reales, movimientos de dinero y datos de clientes.
Un agente que «solo gestiona reservas» toca, en la práctica, su CRM, su facturación y su correo. Ahí un error no es una respuesta rara: es una factura mal emitida o un dato de cliente donde no debía estar.
Diseñe permisos por acción, no por aplicación
El error habitual es dar acceso a una aplicación entera porque «lo necesita para funcionar». Lo correcto es bajar al nivel de acción:
- Consultar el estado de un pedido sin poder cancelarlo.
- Crear una reserva sin poder modificar la tarifa.
- Preparar una factura sin poder emitirla.
- Leer una ficha de cliente sin poder exportar la base.
Cada agente con su propia identidad técnica. Nada de una cuenta genérica compartida: si algo sale mal, hay que poder saber quién lo hizo y revocarle el acceso sin tumbar el resto. Microsoft lo desarrolla en su guía sobre sistemas agénticos seguros.
Controle lo que el agente lee, decide y ejecuta
Son tres momentos distintos y cada uno necesita su control:
- Lee. Limite las fuentes a documentación aprobada. Un correo entrante o un PDF de un proveedor pueden llevar instrucciones ocultas; el agente no debe tomarlas por órdenes.
- Decide. Defina una lista cerrada de acciones permitidas. Es más fiable que intentar prohibir de antemano todo lo que podría salir mal.
- Ejecuta. Aprobación humana obligatoria en pagos, reembolsos, altas de proveedor, cambios de datos maestros y descuentos fuera de política.
La misma lógica, aplicada al sector hotelero y al PMS, está en seguridad de los agentes de IA en las reservas de hotel.
Sin trazabilidad no hay control ni mejora
Si no queda registrado qué consultó el agente, qué decidió, qué herramienta usó y con qué parámetros, no puede investigar un incidente ni corregir el proceso. Y sin eso tampoco puede mejorarlo: no sabrá dónde falla.
Registre como mínimo la petición, las fuentes, la herramienta, el resultado y quién aprobó. Revise esos registros de forma periódica. Microsoft trata el gobierno de estos sistemas a escala de organización en su marco de adopción.
Si está valorando ejecutar el modelo en local para que los datos no salgan de casa, aquí lo analizamos: Muse Glimmer y los agentes de IA locales.
Lo que vemos en la práctica
Hace unos días, montando una automatización propia, tuvimos que decidir si darle a un agente acceso a la configuración del DNS de nuestro dominio. Era cómodo: cinco registros que habría creado en un minuto. Dijimos que no. Ese permiso deja modificar cómo se sirve el sitio entero, y a cambio ahorraba dos minutos de trabajo manual. La cuenta no salía.
Esa es la pregunta que casi nadie se hace antes de conectar nada: no qué puede hacer la herramienta, sino qué pasa si falla o si alguien la manipula. En los diagnósticos aparece siempre el mismo patrón: agentes con credenciales de administrador «para que funcione», conectados a sistemas que nadie ha revisado.
