Tu agente de IA puede trabajar las 24 horas. También puede cometer errores las 24 horas.
Soy Juan Manuel Garrido, fundador de EGA Futura y cofundador de Vantegrate. Trabajo con empresas medianas que viven en Salesforce y que ahora quieren sumar agentes de IA a procesos reales: casos, pedidos, actualizaciones de registro, respuestas al cliente. El mensaje de hoy es simple: pensemos bien el freno, porque el accidente va a pasar.
Va a faltar un dato. Va a fallar una herramienta. Le van a pedir algo fuera de su alcance. Y si nadie lo definió, el agente decide solo. Muchas veces decide seguir adivinando. En un CRM eso no es un detalle técnico: es un mail al cliente equivocado, un campo mal actualizado o un caso cerrado con la lectura incorrecta del tono.
Armé cinco preguntas para responder antes de salir a producción. No es un framework de powerpoint. Es el mínimo que pedimos cuando un agente va a tocar datos reales, plata o al cliente.
1. Cuándo debe frenar
Definilo vos. Si no, el agente decide solo.
Los gatillos más frecuentes:
- Falta un dato clave
- Una herramienta devuelve error
- El pedido está fuera de su alcance
- No está seguro de la respuesta
Si eso no está escrito, el modelo improvisa. Y la improvisación en producción no se siente como creatividad: se siente como un ticket de soporte a las 2 de la mañana.
En Salesforce el problema se agrava porque el agente suele tener acceso a objetos sensibles: Contact, Account, Opportunity, Case, y a veces a automatizaciones que disparan acciones hacia afuera. Sin umbral de incertidumbre, el modelo trata cada duda como una oportunidad de “completar” el trabajo. Completar mal es más caro que detenerse.
2. Qué hace cuando frena
Nada de adivinar y seguir.
Cuando frena, la secuencia tiene que ser clara:
- Se detiene
- Avisa a una persona
- Pasa el contexto
La persona tiene que recibir qué pasó, qué intentó y qué falta. Si el handoff llega vacío, no hay handoff: hay un agente que se cayó y un humano que empieza de cero.
En operaciones de CRM eso se traduce en cola, caso o tarea con el payload completo: objeto tocado, tool que falló, prompt o intención del usuario, y el estado parcial. Sin eso, el “humano en el loop” es solo un eslogan.
Si están evaluando Agentforce u otro stack de agentes sobre Salesforce, pidan ver el camino de falla antes que el camino feliz: quién recibe la alerta, qué contexto llega y en cuánto tiempo.
3. Qué nunca puede tocar sin permiso
Lo que no se puede deshacer, lo aprueba una persona.
Puede solo: consultar datos, crear un borrador.
Con aprobación: borrar registros, mover plata, enviar al cliente.
Esa línea no es paranoia. Es el mismo criterio que usamos con un Flow o con una integración: lo reversible puede ir más automático; lo irreversible lleva firma humana. En agentes sobre Salesforce esto se vuelve crítico porque el CRM concentra clientes, pedidos y a veces cobros.
Un patrón sano es separar capacidades:
- Lectura y resumen: más autonomía
- Escritura reversible (borrador, campo no crítico): autonomía con log
- Escritura irreversible o salida al cliente: aprobación explícita
Si el agente puede “enviar” sin un paso humano, el error más caro ya está habilitado. No hace falta un bug exótico: alcanza con una interpretación razonable pero equivocada.
4. Quién se hace cargo
Un responsable con nombre y apellido, no “el equipo”.
Cuando el agente se manda una, alguien tiene que poder decir “esto lo miro yo”. Si la respuesta es “lo vemos entre todos”, en la práctica no lo mira nadie hasta que el cliente ya se quejó.
En empresas que ya ordenan procesos con un ERP nativo sobre Salesforce, este punto suele quedar más claro: hay dueño de proceso, hay dato confiable y hay un camino de escalamiento. El agente hereda esa claridad o hereda el caos.
5. Cómo se prueba la falla antes de que la vea un cliente
Hay que provocar la falla en pruebas. Dejar registro de cada paso.
No alcanza con el camino feliz. Probar el dato faltante, la herramienta caída, el pedido fuera de alcance y la incertidumbre. Si no provocaste la falla en sandbox, la vas a conocer en producción.
Un checklist mínimo de prueba negativa:
- Quitar un campo obligatorio y ver si frena
- Tirar abajo una integración y ver el handoff
- Pedir algo fuera de scope y verificar rechazo
- Forzar baja confianza y confirmar que no “completa” solo
Sin trazas (qué tool, qué input, qué decisión), el post-mortem es adivinanza. Con trazas, el equipo mejora el freno en días, no en meses.
El error más caro no es el bug técnico
El error caro es el agente que “casi” sabe y manda igual.
En Salesforce eso se ve todo el tiempo: un borrador de email que se envía, un registro que se actualiza con el valor equivocado, un caso que se cierra porque el modelo interpretó mal el tono del cliente. Ninguno de esos fallos parece dramático en la demo. En producción cuestan confianza.
Por eso el checklist no es cosmética. Es la diferencia entre un piloto asistido y un piloto automático sin freno de emergencia.
Si tu empresa está evaluando Agentforce u otro stack de agentes de IA, pidan ver el camino de falla antes que el camino feliz. Quién recibe la alerta. Qué contexto llega. Qué acciones están bloqueadas sin aprobación. Si eso no está, todavía están en experimento, no en producción.
Checklist antes de salir
Antes del próximo go-live, marcar estas cinco:
- Sé cuándo debe frenar
- Sé qué hace al frenar
- Sé qué necesita aprobación
- Hay un responsable
- Probé la falla
Guardarlo y compartirlo con el equipo. Si alguna casilla queda en blanco, todavía no están listos para producción.
Por qué esto importa si la operación vive en el CRM
Meter un agente sin frenos no es “moverse rápido”. Es externalizar el juicio a un sistema que no conoce el negocio como lo conoce tu equipo.
En Vantegrate ayudamos a empresas a poner agentes donde suman, no donde rompen. Y en EGA Futura llevamos años ordenando procesos y datos sobre Salesforce: sin dato confiable y sin proceso claro, el agente solo acelera el desorden. Si quieren ver cómo se apoya una operación en un ERP sobre la plataforma, pueden empezar por EGA Futura Software o agendar una demo.
La pregunta útil no es “qué tan inteligente es el modelo”. Es: qué hace hoy tu agente cuando no sabe qué hacer.
Si la respuesta es “sigue igual”, frenen el proyecto una semana y respondan estas cinco preguntas. Sale más barato que explicar un mail mandado solo al cliente equivocado.