En qué canal poner un agente de IA: la decisión que se toma tarde y manda desde el principio
En qué canal poner un agente de IA es una pregunta que casi siempre llega al final, cuando el agente ya funciona y toca enseñárselo a alguien. Y llega tarde, porque no es una decisión de presentación: es la que determina quién lo va a usar de verdad, cuánto tiempo tiene para contestar, con qué permisos nace y qué queda escrito cuando se equivoque. Elegir superficie es elegir arquitectura, presupuesto de latencia y modelo de seguridad a la vez.
La tesis de esta guía es sencilla y se comprueba en cualquier empresa: el agente que vive donde ya trabaja la gente se usa; el que vive en una pestaña aparte se muere solo, por bueno que sea. No es una cuestión de entusiasmo ni de formación. Es que cada superficie nueva que pides abrir es un peaje de atención que alguien paga todos los días, y ese peaje tiene precio medido: la investigación publicada por Harvard Business Review en agosto de 2022, sobre 137 trabajadores de tres empresas del Fortune 500, contabilizó unos 1.200 saltos diarios entre aplicaciones y ventanas, cerca de cuatro horas a la semana —en torno al 9 % del tiempo de trabajo— consumidas solo en reorientarse. Fuente: How Much Time and Energy Do We Waste Toggling Between Applications?, Harvard Business Review, agosto de 2022.
El contexto tampoco ayuda a que una herramienta nueva se abra paso. El informe de Microsoft WorkLab sobre la jornada infinita, publicado en junio de 2025 a partir de señales agregadas y anonimizadas de Microsoft 365, sitúa una interrupción cada dos minutos durante la jornada —275 al día en el 20 % de usuarios que más notificaciones recibe— entre reuniones, correos y chats. Fuente: Breaking down the infinite workday, Microsoft WorkLab, junio de 2025. Contra ese ruido, pedir que alguien recuerde una pestaña más no es una petición pequeña: es competir por el hueco más caro que tiene tu equipo.
Las cinco superficies reales y quién está al otro lado de cada una
En la práctica solo hay cinco sitios donde un agente de empresa se instala, y cada uno viene con un usuario distinto pegado. La superficie no se elige por gusto: se elige identificando dónde está esa persona en el momento exacto en que aparece el trabajo.
- Dentro del CRM o el ERP. Usuario: el empleado que ya vive ahí ocho horas al día. Es la superficie con mejor adopción y peor visibilidad para quien compra: nadie hace una demo lucida de un panel lateral. A cambio, el agente aparece junto al registro que va a tocar, con la cuenta y el historial delante, y no hay que explicarle a nadie dónde encontrarlo.
- Slack o Teams. Usuario: el equipo, en conversación. Sirve para el trabajo que nace hablando —«¿alguien sabe si este cliente tiene contrato de soporte?»— y para procesos donde la decisión es colectiva. Ventaja real: la pregunta y la respuesta quedan a la vista de todos, y eso acelera la confianza mucho más rápido que un chat privado.
- WhatsApp. Usuario: el cliente que ya te escribe por ahí. Es el canal con más tracción comercial en España, Italia y Portugal, y el que más reglas de plataforma arrastra. Se elige cuando el cliente ya está ahí, nunca para llevarlo.
- El chat de la web. Usuario: un visitante anónimo que está decidiendo. Es la superficie más exigente en latencia y la más pobre en contexto: no sabes quién es. Su trabajo es cualificar y capturar, no resolver casos de cliente.
- El correo. Usuario: el proceso, más que la persona. Facturas de proveedor, pedidos, solicitudes que ya llegan a una bandeja. Es la superficie menos glamurosa y la que más trabajo repetitivo esconde, porque nadie la mira como un canal: la mira como una carpeta.
Falta una sexta que casi todo el mundo elige por defecto y que no está en la lista a propósito: la pestaña propia, la aplicación interna con su URL y su login. No es que no sirva nunca —vale para trabajo profundo, con sesiones largas y un usuario experto que va expresamente a eso—, es que se elige por comodidad de quien construye, no por dónde está el trabajo. Si el caso de uso es «resolver algo que surge mientras haces otra cosa», la pestaña propia es la peor opción disponible.
Latencia: cuánto silencio aguanta cada canal antes de perder al usuario
Cada superficie tiene un presupuesto de tiempo implícito que nadie escribe y todo el mundo respeta. Se nota cuando se incumple: el usuario da por muerto al agente y se va. Estos son los órdenes de magnitud con los que conviene diseñar.
| Superficie | Presupuesto de respuesta | Qué te obliga a montar |
|---|---|---|
| Chat de la web | Segundos | Modelo rápido + respuesta parcial mientras trabaja; nada de esperar a tener la respuesta completa |
| Segundos a un par de minutos | Acuse de recibo inmediato; el cliente no tiene la pantalla abierta esperando | |
| Slack / Teams | Decenas de segundos | Reacción o «estoy en ello» y luego el mensaje bueno; la asincronía ya está aceptada |
| Dentro del CRM / ERP | Segundos si es un botón; minutos si escribe en el registro | Decidir si es interacción o proceso de fondo — son dos diseños distintos |
| Correo | Horas | Casi nada: aquí la latencia deja de ser el problema y pasa a serlo la trazabilidad |
La consecuencia que más cuesta aceptar es que el canal manda sobre el modelo. Si la superficie exige segundos, no puedes permitirte tres llamadas encadenadas al modelo más capaz por muy bien que respondan; tendrás que repartir —barato para clasificar y enrutar, capaz para decidir— y devolver algo antes de terminar. Ese reparto está desarrollado en qué modelo usar en un agente de IA, y es una decisión que se toma después de la de superficie, no antes.
Permisos: cada superficie llega con los suyos ya puestos
Instalar un agente en una superficie no es neutro en seguridad: hereda el modelo de permisos de esa superficie, y por defecto casi siempre pide de más. Conviene mirarlo antes de firmar, no después de la primera incidencia.
- CRM / ERP: hereda, y eso es lo bueno. El agente puede correr con el rol del usuario que lo invoca, así que si el comercial no ve esa cuenta, el agente tampoco. Es el único caso donde la superficie te regala el trabajo hecho. Lo que hay que vigilar es la tentación de darle un usuario de servicio con permisos de administrador «para que no falle nada».
- Slack / Teams: ámbitos propios, y el peligroso es el histórico. Se instala como aplicación con sus permisos. Leer el historial completo de un canal es mucho más de lo que suele hacer falta: para la mayoría de casos basta con recibir los mensajes en los que se le menciona. Pedir el histórico entero convierte al agente en un lector permanente de conversaciones internas, y eso es una decisión que merece ser consciente.
- Chat de la web: desconocidos. Habla con visitantes sin autenticar, así que no puede tener acceso de lectura a datos de clientes concretos. Todo lo que huela a «dime el estado de mi pedido» exige un paso de identificación antes, o acabas con una fuga de datos elegantemente diseñada.
- WhatsApp: identidad frágil. Un número de teléfono no es una identidad verificada: los números se reciclan y los teléfonos se prestan. Para cualquier acción con consecuencias, hace falta una verificación adicional.
- Correo: el alcance es la trampa. Dar acceso a un buzón es dar acceso a todo su histórico. El alcance se acota por etiqueta, carpeta o alias dedicado, nunca por buzón completo.
La regla común a las cinco: el permiso se pide por caso de uso y se revisa con fecha, no se acepta el que trae el instalador. El desarrollo completo —qué se le da, cómo se retira y qué se registra— está en qué permisos darle a un agente de IA.
Qué queda registrado y qué se evapora al cerrar la pestaña
El día que el agente se equivoque —y va a pasar— la pregunta no será «¿por qué?», será «¿dónde miro?». La superficie decide si esa pregunta tiene respuesta en dos minutos o en dos días.
Slack y Teams son la mejor superficie en este eje y casi nadie lo tiene en cuenta al elegir: la conversación queda escrita, con quién preguntó, qué contestó el agente y quién le llevó la contraria, en un sitio que la empresa ya retiene y ya sabe exportar. Dentro del CRM pasa algo parecido si el agente escribe en el registro en vez de en un panel volátil: la nota queda pegada al cliente y al caso. El chat de la web es el extremo contrario: la sesión se cierra y, si no has montado la persistencia a propósito, no queda nada que auditar salvo lo que tu proveedor decida guardar y por cuánto tiempo.
Esto conecta con lo que pasa cuando el agente duda o se queda sin respuesta: el traspaso a una persona solo es barato si la superficie conserva el contexto. En Slack o en el CRM, la persona entra y lee lo que ya hay. En un chat de web sin persistencia, la persona empieza de cero y el cliente lo repite todo. Lo que tiene que viajar en ese traspaso está en qué hace un agente cuando no sabe la respuesta.
Las reglas del canal que no se negocian: WhatsApp y el correo
Dos de las cinco superficies traen normativa de plataforma propia, y no es orientativa: si la ignoras, el canal deja de funcionar. Conviene saberlo antes de prometer una experiencia que la plataforma no permite.
En WhatsApp, cuando un usuario te escribe se abre una ventana de atención al cliente de 24 horas; dentro de esa ventana puedes responder con mensajes libres, y si el usuario vuelve a escribir, el contador se reinicia. Fuera de ella solo puedes contactar mediante plantillas aprobadas previamente, clasificadas por categoría —utilidad, autenticación, marketing— con reglas y coste distintos según el tipo. Fuente: documentación oficial de Meta, Política de mensajería de WhatsApp Business, consultada el 14 de septiembre de 2026. La traducción operativa para el diseño del agente es directa: un agente de WhatsApp es reactivo por defecto, y cualquier flujo que requiera iniciar la conversación hay que diseñarlo como plantilla aprobada antes de escribir una línea de código. El detalle de qué permite y qué no está en qué permite Meta en un agente de IA en WhatsApp, y la versión comercial del caso, en responder WhatsApp 24 horas.
El correo no tiene una plataforma que te sancione, pero tiene dos restricciones igual de duras: la identidad del remitente (si el agente responde desde una dirección genérica, la tasa de respuesta se hunde; si responde desde la de una persona, esa persona es responsable de lo que diga) y el hilo (contestar creando un hilo nuevo rompe el seguimiento de cualquier proceso). Ninguna de las dos es técnica y las dos deciden si el canal sirve.
La tabla de decisión: cuatro preguntas y una superficie
La decisión se cierra en una tarde con cuatro preguntas, en este orden. El orden importa: la primera descarta la mitad de las opciones y las demás afinan.
- ¿Quién es el usuario y qué tiene abierto cuando aparece este trabajo? Empleado dentro de un sistema → ese sistema. Equipo hablando → Slack o Teams. Cliente que ya te escribe → su canal. Visitante anónimo → chat de la web. Nadie, porque el trabajo llega solo → correo.
- ¿Cuánto puede esperar sin darse por abandonado? Si la respuesta son segundos, la arquitectura tiene que devolver algo antes de terminar. Si son horas, te sobra presupuesto y puedes gastarlo en verificar mejor.
- ¿Qué permisos me obliga a pedir esa superficie, y cuántos de ellos necesito de verdad? Si el mínimo que la superficie permite ya es más de lo que el caso justifica, es un motivo legítimo para cambiar de superficie.
- Cuando falle, ¿dónde está escrito? Si no hay respuesta, o montas la persistencia antes de lanzar o eliges otra superficie.
Y una regla de arquitectura que hace todo lo anterior reversible: el agente es un servicio, el canal es una capa fina encima. Si la lógica —los pasos, las condiciones, las llamadas a tus sistemas— vive dentro del constructor visual del proveedor de chat, cambiar de superficie no es mover, es volver a construir. Si vive en tu lado, detrás de un contrato de entrada y salida, mover el mismo agente de la web a WhatsApp o de una pestaña propia a Teams es trabajo de días. Esa condición es la que convierte la decisión de superficie en algo que puedes corregir cuando los datos de uso te contradigan.
Nosotros empezamos por aquí, antes que por el modelo y antes que por el prompt: dónde está el trabajo, quién lo hace y qué tiene abierto en ese momento. Es lo que hay debajo de Adopción IA para equipos —porque tener IA en la empresa no es lo mismo que la empresa use IA— y lo que se monta con infraestructura de IA empresarial cuando el agente tiene que vivir dentro de sistemas que ya están en producción. El resto del montaje —permisos, autonomía, memoria, evals— está en crear un agente de IA que aguante producción.