La IA para atención al cliente puede clasificar solicitudes, recuperar respuestas, preparar borradores y asistir a agentes. No debería desplegarse como sustituto sin supervisión de todo el soporte. Empieza por un problema acotado, una métrica base y límites explícitos: clientes, canales, idiomas y decisiones incluidas.
Arquitectura para producción
Coloca una capa de aplicación controlada entre el canal y el modelo. Debe autenticar al cliente, eliminar datos sensibles innecesarios, recuperar conocimiento según permisos, llamar solo a herramientas autorizadas y guardar una traza. Una capa de políticas decide si responder, aclarar o escalar. Las escrituras en CRM y ticketing deben validarse, ser idempotentes y quedar atribuidas.
Conocimiento y calidad
Documentación, políticas y casos resueltos necesitan propietario, versión y caducidad. La recuperación debe respetar permisos de cliente y tenant. Exige referencias para respuestas factuales y una salida de “evidencia insuficiente”. Evalúa preguntas reales anonimizadas, varios idiomas y casos ambiguos, hostiles o fuera de alcance.
Coste por consulta resuelta: qué incluir
Separo la inversión inicial del coste de operación. La primera incluye alcance, preparación documental, integración y pruebas. La segunda incluye plataforma, modelos, búsqueda, seguimiento, revisión humana, correcciones y mantenimiento. Para comparar propuestas de construcción, utiliza la guía de presupuestos de software y automatización.
Propongo medir coste operativo por consulta resuelta = costes operativos atribuibles al flujo durante el periodo / consultas únicas de ese mismo periodo cuya resolución se ha verificado. Incluye en el numerador el trabajo dedicado a intentos fallidos y escalados; cuenta cada consulta una sola vez, aunque genere varios mensajes o tickets. Si no hay resoluciones verificadas, el indicador todavía no es calculable.
Antes del piloto, acuerda qué evidencia permite cerrar una consulta y durante cuánto tiempo comprobarás reaperturas. El silencio del cliente no demuestra por sí solo resolución. Separa los casos resueltos por IA de los terminados por una persona y compara con una muestra manual de dificultad similar. Registra también calidad, tiempo de espera y reclamaciones: abaratar una respuesta incorrecta no mejora el servicio. Presenta la inversión inicial aparte o explica su amortización, sin mezclarla silenciosamente con el gasto recurrente.
Riesgos y controles
Políticas inventadas, fugas de privacidad, prompt injection, acciones no autorizadas y degradación silenciosa son riesgos previsibles. Minimiza datos, define retención, cifra secretos y limita herramientas por rol. Reembolsos, cambios de cuenta o compromisos legales necesitan reglas deterministas y normalmente aprobación humana. El cliente debe poder hablar con una persona.
Pruebas para aceptar un piloto de atención con IA
Antes de elegir modelo, pediría al responsable de soporte un canal, un idioma, una categoría de consulta y ejemplos anonimizados con la respuesta esperada. Separaría los ejemplos usados para ajustar el sistema de los reservados para evaluarlo. El volumen de pruebas depende de la variedad y del riesgo; unas pocas conversaciones correctas no justifican abrir todos los canales.
Este es un ejemplo hipotético: un asistente informa sobre el estado de pedidos y prepara solicitudes de devolución. Consulta el sistema de pedidos tras verificar al cliente y utiliza la política vigente para explicar opciones. La autorización del reembolso queda fuera del piloto.
| Situación | Resultado que exigiría | Evidencia para revisar |
|---|---|---|
| Pedido de otro cliente | Deniega el acceso sin mostrar datos privados. | Prueba de permisos y registro sin contenido sensible. |
| Política ausente o contradictoria | Pide aclaración o deriva; no inventa condiciones. | Fuente y versión consultadas, motivo de derivación. |
| Petición de reembolso | Prepara el caso y solicita aprobación; no mueve dinero. | Estado pendiente y ausencia de una operación de pago. |
| Cliente pide hablar con alguien | Entrega el contexto a una cola con responsable. | Ticket asignado y resumen disponible para soporte. |
| La API cae o llega dos veces el mensaje | Informa de la limitación y evita acciones duplicadas. | Estado recuperable y una sola solicitud válida. |
| Mensaje intenta cambiar las instrucciones | Mantiene permisos y acciones autorizadas. | Resultado de la prueba y herramientas ejecutadas. |
La revisión debe comprobar el estado real del ticket y las acciones realizadas, además del texto. La guía técnica de Anthropic sobre evaluación de agentes explica la diferencia entre conversación registrada y resultado final.
Empieza con borradores revisados por soporte y abre después una fracción acordada de consultas elegibles. Fija antes los límites de error, espera, reapertura y coste con el equipo. Mi criterio de parada para este ejemplo sería una fuga de datos, un reembolso no autorizado o una derivación perdida: suspender respuestas automáticas, conservar evidencia y corregir antes de reabrir. Superar la muestra no garantiza ausencia de fallos futuros.
La derivación humana también se entrega y se prueba
Un mensaje que dice «te paso con un compañero» no completa el traspaso. Debe existir una cola, un responsable y un estado visible. El agente humano recibe la consulta, la identidad verificada cuando proceda, las fuentes utilizadas y las acciones ya intentadas. Fuera de horario, comunica el siguiente paso real sin prometer una respuesta inmediata.
Acuerda quién actualiza políticas, quién revisa respuestas y quién desactiva la automatización ante un fallo. En Adslyfy están documentados registros de ejecución, capturas y alertas para revisar fallos. Es evidencia de ingeniería operativa; este ejemplo de soporte necesita su propia evaluación.
Errores comunes
- automatizar todos los contactos antes de entender la demanda
- indexar documentos obsoletos sin propietario
- permitir que texto generado active herramientas sin límites
- medir desvío sin contar tickets reabiertos
- guardar conversaciones completas indefinidamente
- ocultar que el cliente interactúa con IA
- lanzar sin escalado ni procedimiento de caída
- suponer que un prompt sirve para todos los idiomas
Checklist práctico
- elige un flujo frecuente y de bajo riesgo
- mide tiempo, precisión, escalado y satisfacción actuales
- inventaría datos, finalidad, permisos y retención
- asigna propietarios a las fuentes de conocimiento
- crea pruebas representativas y casos de rechazo
- autoriza herramientas explícitamente y valida acciones
- exige aprobación para reembolsos y cambios de cuenta
- registra fuentes, versión, decisiones y latencia
- monitoriza calidad, coste, drift y reclamaciones
- documenta escalado humano y apagado de emergencia
Cuándo tiene sentido contratar a una persona técnica
Contrata a un ingeniero de IA o responsable técnico si el asistente conecta con CRM, facturación o datos privados; si los permisos cambian por tenant; o si un prototipo necesita SLA. Puede separar reglas deterministas del lenguaje generado y construir evaluación, auditoría y fallback. Revisa RAG para empresas y agentes frente a workflows.
Si gestionas un negocio de cerrajería, la guía de marketing para cerrajeros conecta captación local, marketplaces y atención de mensajes con un flujo de avisos y confirmación humana.
Qué traer para definir el alcance
Para valorar un piloto, tráeme ejemplos anonimizados, volumen por tipo de consulta, herramientas de soporte, fuentes de conocimiento, idiomas y responsables. Definiremos qué puede responder, qué debe derivar, qué pruebas permitirán aceptarlo y quién lo mantendrá. Puedes revisar mis servicios de automatización e IA aplicada o contactar conmigo para acotar el piloto.