Chatbot IA empresa: como implantar la plataforma agentica
La mayoria de proyectos de chatbot en empresa se atascan en el mismo punto: el bot sabe responder, pero no sabe hacer. Contesta horarios y tarifas, y en cuanto el cliente pide algo real deriva a un humano. La diferencia no esta en el modelo de lenguaje, esta en la plataforma que tiene debajo.
De bot que responde a agente que ejecuta
Un chatbot de preguntas frecuentes hace una sola cosa: busca en una base de documentos y redacta una respuesta. Sirve para horarios, politicas de devolucion y fichas de producto. Se cae en el primer caso concreto: ¿teneis esta referencia en el almacen de Valencia? ¿podeis cambiar mi cita del jueves?
Un agente no responde, ejecuta. Consulta el ERP, escribe en el CRM, abre un ticket en soporte, bloquea un hueco en la agenda, lanza un pedido de recambio. La conversacion es solo la interfaz. El valor esta en las herramientas que el agente puede invocar y en las reglas que deciden cuando puede invocarlas.
Esa linea separa el piloto que se queda en demo del sistema que entra en operacion. Si el agente no toca sistemas, el equipo humano sigue haciendo el mismo trabajo con un paso mas por delante.
Las seis capas que tiene que traer la plataforma
Cuando evalues una plataforma, mira por debajo de la demo. La demo siempre funciona. Lo que decide el proyecto son las capas que hay detras.
- →Capa de conocimiento: ingesta de documentacion, catalogo y tarifas con actualizacion automatica y control de version. Si hay que resubir un PDF a mano cada semana, el conocimiento envejece solo.
- →Capa de acciones: conectores hacia ERP, CRM, ticketing, agenda y pasarela de pago. Cada accion definida como herramienta, con parametros tipados y validacion antes de ejecutar.
- →Motor de politicas: que puede hacer el agente sin supervision, que exige confirmacion humana y que esta prohibido. Configurable por canal, por tipo de cliente y por importe.
- →Memoria de cliente: identidad resuelta e historico de pedidos e incidencias. Sin esto, el agente vuelve a preguntar lo que la empresa ya sabe.
- →Orquestacion multicanal: web, WhatsApp, email y telefono con la misma logica detras. Un agente distinto por canal son cuatro proyectos, no uno.
- →Trazabilidad: registro de cada accion ejecutada, con que datos y en nombre de quien. Es lo que permite auditar y lo primero que te van a pedir en la primera incidencia.
Como se implanta: lectura, escritura supervisada, autonomia
La implantacion no empieza por el modelo. Empieza por el inventario. Exporta los ultimos meses de tickets, chats y correos de atencion y agrupa por intencion real. Sale una lista mas corta de lo que espera cualquiera, y un grupo reducido de intenciones suele concentrar la mayor parte del volumen. Esas son las que se automatizan primero.
A partir de ahi, tres fases:
- →Fase de lectura: el agente consulta sistemas y responde con datos reales, pero no escribe nada. Riesgo tecnico bajo y ya resuelve estado de pedido, stock, factura y envio.
- →Fase de escritura supervisada: el agente propone la accion y una persona la confirma con un clic. Sirve para calibrar, y cada confirmacion o rechazo es una señal operativa aprovechable.
- →Fase de autonomia acotada: se liberan las acciones con tasa de acierto alta e impacto bajo. Las de importe alto o efecto irreversible se quedan siempre con confirmacion.
Integraciones y permisos: donde se gana o se pierde
El proyecto se gana o se pierde en la integracion, no en el prompt. Antes de firmar hay tres cosas que cerrar: si tus sistemas exponen API y quien construye la capa intermedia si no la exponen, como se resuelve la identidad de quien escribe, y si existe un entorno de pruebas donde el agente pueda equivocarse sin consecuencias.
Los permisos se heredan del rol, nunca del agente. Un agente que atiende a cliente final no debe poder consultar margenes ni datos de otras cuentas. Eso se configura en la plataforma. Una instruccion en lenguaje natural no es un control de acceso.
Cuando la empresa pasa de un agente suelto a varios coordinados, el problema deja de ser una integracion y pasa a ser una arquitectura: Potenciado lo desarrolla en la arquitectura de una empresa con agentes. Y el detalle cambia mucho por sector; en automocion, un mismo agente toca stock de vehiculo, lead de prueba y postventa, y Agent Hub lo explica aplicado a concesionarios.
Que medir cuando ya esta en produccion
La satisfaccion del chat es una metrica pobre para decidir inversiones. Mide operacion.
- →Tasa de resolucion sin intervencion humana, desglosada por intencion.
- →Acciones ejecutadas y porcentaje de ellas revertidas o corregidas despues.
- →Tiempo desde el mensaje hasta la accion completada, comparado con el proceso manual equivalente.
- →Coste por conversacion resuelta, sumando modelo, infraestructura y soporte.
- →Motivo de cada escalada a humano. Ese listado es el backlog de la siguiente iteracion.
Este tema tambien se trata, desde otro enfoque, en Potenciado · Agent Hub · GEOySEO.
Si ya tienes claro que intenciones concentran tu volumen de atencion y que sistemas deberia tocar el agente, el siguiente paso es mapear esas acciones contra tus integraciones reales y decidir cuales salen en modo lectura y cuales necesitan confirmacion. Cuentanos con que sistemas trabajas y revisamos contigo ese mapa antes de escribir una sola linea de configuracion. Y si te interesa el otro lado del asunto, la visibilidad, GEOySEO analiza como un chatbot de empresa afecta a tu SEO y a que te citen.
Preguntas frecuentes
¿Cuanto tarda en estar operativo un chatbot de IA en una empresa?
El plazo lo marcan las integraciones, no el modelo. La capa conversacional se monta rapido. Lo que consume tiempo es conectar ERP, CRM o ticketing, resolver la identidad del cliente y validar cada accion en un entorno de pruebas. Por eso conviene salir en fase de lectura, que solo necesita permisos de consulta, y abrir la escritura despues, accion a accion.
¿Que diferencia hay entre un chatbot y un agente de IA?
El chatbot genera texto a partir de documentos: describe, explica y deriva. El agente ejecuta tareas en tus sistemas mediante herramientas conectadas, con reglas que definen que puede hacer solo y que necesita confirmacion. Un chatbot te dice como pedir una devolucion; un agente la abre, genera la etiqueta y actualiza la ficha del pedido.
¿Puede el agente ejecutar una accion equivocada?
Puede, y la plataforma tiene que asumirlo desde el diseño. Se controla con tres mecanismos: validacion de parametros antes de ejecutar, confirmacion humana obligatoria para acciones de importe alto o efecto irreversible, y registro completo de cada operacion para revertirla y entender que fallo. Si una plataforma no ofrece estas tres cosas, el riesgo no esta gestionado.
¿Hay que cambiar el CRM o el ERP para implantarlo?
No, si esos sistemas exponen API o base de datos accesible. La plataforma se conecta a lo que ya usas. Cuando el sistema es antiguo o cerrado, se construye una capa intermedia que expone solo las operaciones necesarias. Es trabajo adicional, pero mucho menor que una migracion, y conviene presupuestarlo desde el principio.