Un agente de IA no necesita acceso completo al CRM, calendario o ERP para ser útil. La arquitectura más segura expone solo las acciones que necesita —consultar, crear, actualizar o solicitar aprobación— mediante herramientas controladas y permisos mínimos.
El objetivo es que el agente pueda actuar dentro del proceso sin convertirse en una credencial universal. Esta lógica es especialmente importante en agentes de voz y agentes multicanal conectados con datos empresariales.
Piensa en herramientas, no en acceso total
En lugar de “dar acceso al CRM”, define funciones concretas: buscar un contacto, consultar una oportunidad, crear una tarea, proponer una cita o adjuntar una nota. Cada función puede validar parámetros y aplicar reglas antes de ejecutar.
La llamada a funciones permite conectar modelos con herramientas externas. El modelo decide cuándo solicitar una acción, pero la aplicación sigue controlando qué funciones existen, qué parámetros acepta y qué ocurre después.
Cuatro niveles de permiso
| Nivel | Ejemplo | Riesgo |
|---|---|---|
| Lectura | Consultar disponibilidad | Bajo a medio |
| Creación | Crear tarea o borrador | Medio |
| Modificación | Cambiar estado o cita | Medio a alto |
| Acción sensible | Enviar, aprobar o comprometer | Alto |
No todas las acciones deberían ser accesibles al agente ni ejecutarse sin confirmación.
CRM: qué debería poder hacer
- buscar contacto por identificadores fiables;
- leer campos relevantes para el caso;
- crear una nota estructurada;
- proponer o crear una tarea;
- actualizar campos limitados;
- consultar el estado antes de enviar un seguimiento.
Evita que el agente pueda modificar precios, ownership, condiciones comerciales o datos críticos si no es necesario.
Calendario: separa consultar y reservar
“Ver huecos” y “crear una cita” son acciones distintas. El agente puede consultar disponibilidad con permisos reducidos y reservar solo después de confirmar fecha, zona horaria, identidad y reglas de agenda.
También debe comprobar el estado justo antes de confirmar para evitar dobles reservas.
Sistemas internos: crea una capa intermedia
Cuando hay ERP, aplicaciones propias o bases de datos, es preferible no exponer directamente el sistema al modelo. Una API o workflow intermedio puede validar identidad, formato, permisos y reglas de negocio.
Los permisos deberían depender de la acción
No uses una única credencial con privilegios máximos para todos los flujos. Siempre que el sistema lo permita, aplica principio de mínimo privilegio y cuentas de servicio separadas.
Para acciones sensibles, añade aprobación humana, límites de importe, listas permitidas o condiciones explícitas.
Qué registrar en cada llamada a herramienta
- qué agente inició la acción;
- qué usuario o conversación la originó;
- herramienta utilizada;
- parámetros relevantes;
- resultado;
- error si existió;
- aprobación humana cuando aplique.
Los logs permiten investigar errores y medir qué herramientas fallan más.
Cómo gestionar errores sin inventar resultados
Si el CRM no responde, el agente no debería decir “ya lo he actualizado”. La herramienta debe devolver un estado claro y el agente comunicar que la acción no se completó o que necesita reintentarse.
Diseña respuestas para timeout, permisos insuficientes, registro no encontrado, datos ambiguos y conflicto de estado.
Identidad antes de actuar
Consultar información pública o genérica requiere menos garantías que cambiar datos de una cuenta. Para acciones personales, verifica identidad con el nivel adecuado al riesgo y evita confiar solo en lo que el usuario afirma durante la conversación.
Un ejemplo de flujo seguro
- El cliente pide cambiar una cita.
- El agente identifica la cita mediante datos permitidos.
- Consulta disponibilidad.
- Propone alternativas.
- El cliente confirma.
- La herramienta valida que la cita sigue disponible.
- Se actualiza el calendario.
- CRM recibe una nota y queda log del cambio.
Cómo probar antes de producción
Empieza en modo lectura o sandbox. Después habilita acciones reversibles y, finalmente, modificaciones sensibles con controles. Prueba entradas incorrectas, instrucciones ambiguas y casos donde el usuario intenta conseguir una acción fuera de política.
Este enfoque complementa nuestro artículo sobre agentes multicanal y contexto compartido.
Cuándo necesitas una persona
Escala si hay conflicto de identidad, varias opciones con impacto, excepciones comerciales, permisos insuficientes o una acción irreversible. El agente debería entregar a la persona el contexto y las acciones ya intentadas.
Si quieres mapear qué herramientas podría utilizar un agente en tu empresa y con qué permisos, podemos revisar el flujo.
Preguntas frecuentes
¿El agente necesita la contraseña de un usuario?
No debería. Es mejor usar OAuth, cuentas de servicio, tokens limitados u otros mecanismos específicos del sistema.
¿Puede escribir directamente en una base de datos?
Técnicamente sí, pero suele ser más seguro exponer una API o función que valide la operación antes de escribir.
¿Cómo evito que actualice el registro equivocado?
Usando identificadores fiables, confirmación de identidad, validaciones previas y revisando el estado justo antes de ejecutar.
