La respuesta corta
Antes de conectar un agente de IA a un CRM o ERP, separa qué puede leer, qué puede preparar y qué puede ejecutar.
Entrega una herramienta pequeña por acción, usa permisos mínimos y exige confirmación justo antes de una operación con impacto comercial, financiero o sobre datos de una persona. El modelo no debería recibir acceso general al sistema ni credenciales reutilizables.
Cada capa reduce alcance, valida la acción y deja evidencia.
La integración correcta no entrega “acceso al CRM”. Entrega funciones acotadas, como buscar un contacto por correo, crear un borrador de lead o agregar una nota. Cada función valida la entrada y devuelve evidencia de lo ocurrido.
De responder a actuar cambia el riesgo
Un chat aislado puede equivocarse en una frase. Un agente conectado puede duplicar un cliente, cambiar una etapa o enviar información incorrecta. La calidad de la respuesta sigue importando, pero el diseño de permisos pasa a ser central.
OWASP identifica la agencia excesiva como un riesgo cuando un sistema recibe más funciones, permisos o autonomía de la necesaria. La respuesta práctica es directa: reducir alcance y aumentar control según la consecuencia.
Mapea acciones antes de integrar
| Acción | Ejemplo | Control inicial recomendado |
|---|---|---|
| Leer | Consultar una oportunidad | Permitida y registrada |
| Preparar | Crear un borrador de nota | Permitida, sin enviar |
| Crear | Registrar un contacto | Validación e idempotencia |
| Modificar | Cambiar una etapa | Confirmación o regla explícita |
| Irreversible | Eliminar o pagar | Fuera del alcance inicial |
Esta matriz reemplaza el permiso ambiguo de “acceder al sistema”. Acceder no explica qué ocurrirá ni qué consecuencias tendrá.
No todas las tools necesitan la misma fricción ni el mismo permiso.
Diseña tools simples
Una herramienta útil tiene un solo propósito: buscar un contacto, crear un borrador, agregar una nota o proponer horarios. Evita una función genérica capaz de ejecutar cualquier operación del CRM con decenas de parámetros.
La tool debe responder en lenguaje operativo:
- qué ocurrió;
- cuál es el identificador del registro;
- qué dato falta;
- si se puede reintentar;
- qué debería comunicar el agente.
Un error técnico aislado no le dice al modelo si debe pedir el correo, corregir una fecha o derivar el caso.
Mantén permisos mínimos
La credencial necesita solo los permisos de sus herramientas. Si el agente crea leads y agrega notas, no necesita eliminar clientes ni exportar toda la base.
Las pruebas iniciales deberían usar datos ficticios o un entorno de staging. Los secretos permanecen en el servidor: nunca dentro del prompt ni expuestos al navegador.
Confirma solo cuando corresponde
La confirmación no debería transformar la conversación en un interrogatorio. Aparece justo antes de una acción sensible y muestra los datos que se usarán.
- El agente reúne los antecedentes.
- Resume lo entendido.
- Propone la acción.
- La persona o un operador confirma.
- La herramienta ejecuta y devuelve evidencia.
Para guardar un borrador quizá no necesites confirmación. Para enviar, modificar o comprometer algo, sí. El control depende del impacto, no de una regla universal.
Evita duplicados y reintentos peligrosos
Los servicios fallan y las solicitudes se reintentan. Si la operación “crear lead” se ejecuta dos veces, no deberían aparecer dos clientes.
Usa una clave de idempotencia o busca primero por un identificador estable. Recuerda que un timeout no demuestra que la acción falló: el sistema externo pudo completarla aunque la respuesta no regresara.
Deja una historia reconstruible
Para investigar un problema necesitas saber qué pidió la persona, qué contexto recibió el modelo, qué herramienta eligió, cuáles fueron sus argumentos, qué respondió el sistema, quién confirmó, cuánto costó y cuál fue el resultado.
Eso no significa guardar todo para siempre. Define retención, cifra conversaciones sensibles y conserva solo lo necesario.
Haz visibles las fallas
Si el CRM no está disponible, el agente debe informarlo sin fingir éxito. Puede guardar temporalmente la solicitud, entregar un método de seguimiento y avisar a una persona.
La interfaz también debe terminar correctamente su estado de carga: un análisis interno o una tarea de resumen no debería dejar el chat bloqueado después del último token visible.
Separa costo y latencia
Conversación, extracción estructurada, resumen para el equipo y clasificación no necesitan ocurrir en el mismo camino crítico. Lo que no cambia la respuesta visible puede ejecutarse después.
Mide tiempo hasta el primer token, duración de cada tool y tiempo total. Un promedio único puede ocultar que el problema está en una API externa o en trabajo posterior al streaming.
Checklist técnico
- cada herramienta realiza una sola acción;
- los errores indican cómo recuperarse;
- la credencial tiene permisos mínimos;
- las escrituras son idempotentes;
- las acciones sensibles requieren confirmación;
- existe una ruta alternativa ante fallas;
- las llamadas quedan trazadas;
- costos y latencias se miden por etapa;
- hay límites por usuario y período;
- el equipo sabe cómo deshabilitar una herramienta.
Preguntas para un proveedor
- ¿Qué datos verá el modelo y dónde se procesan?
- ¿Qué permiso exacto tendrá cada integración?
- ¿Cómo evita operaciones duplicadas?
- ¿Qué acciones necesitan revisión humana?
- ¿Cómo se reconstruye una decisión?
- ¿Qué ocurre si el modelo, CRM o ERP falla?
- ¿Cómo se limita el gasto?
- ¿Cómo se revoca el acceso?
Las respuestas deberían aparecer en la arquitectura y en una prueba, no quedar solo como promesas comerciales.
Siguiente paso
Una integración segura comienza con un mapa pequeño de acciones y permisos. Revisa el servicio de agentes de IA para empresas en Chile. La meta no es conectar todo: es habilitar la acción mínima que produzca valor, pueda revertirse y sea fácil de explicar después.