Chatbot, copiloto y agente no son sinónimos. Un chatbot responde dentro de un alcance definido; un copiloto propone respuestas a una persona que decide; un agente puede consultar sistemas y ejecutar acciones por sí mismo. La arquitectura debe elegirse por impacto y reversibilidad: cuanto mayor es la autonomía, más necesarios son la identidad verificada, los permisos, la validación, la supervisión, las trazas y el escalado humano.
Comparativa
Antes de decidir qué construir conviene situar cada arquitectura según su función y su nivel de riesgo:
| Arquitectura | Función | Riesgo | Uso adecuado |
|---|---|---|---|
| FAQ / chatbot | Responder información | Bajo / medio | Preguntas frecuentes |
| RAG | Responder con fuentes | Medio | Políticas y producto |
| Copiloto | Ayudar a un agente humano | Medio | Resúmenes y borradores |
| Agente | Ejecutar acciones | Alto | Citas o cambios acotados |
La regla general es sencilla: no se concede capacidad de escritura a un sistema si basta con que informe.
Diseñar por intención
El primer paso no es elegir tecnología, sino clasificar los contactos que va a recibir el canal:
- Información.
- Estado.
- Cambio.
- Reclamación.
- Pago.
- Baja.
- Emergencia.
- Derechos de datos.
Cada intención lleva asociados sus propios datos, su propio requisito de autenticación, su propia acción y su propia ruta de escalado. El modelo no debe improvisar fuera de ese catálogo.
Transparencia
El artículo 50 del Reglamento de Inteligencia Artificial de la UE (AI Act) exige informar a las personas cuando interactúan con un sistema de IA en los supuestos aplicables, salvo que resulte evidente. Esa información debe aparecer al inicio de la conversación, no escondida en un aviso legal.
Debe indicarse:
- Que interviene inteligencia artificial.
- La finalidad de la interacción.
- Sus límites.
- El posible registro de la conversación.
- El acceso a una persona.
- La política de privacidad aplicable.
Protección de datos
El chat puede recibir datos de salud, números de cuenta o de documento, documentos adjuntos o datos de terceros. Conviene advertir al usuario de que no aporte información innecesaria y aplicar filtros y minimización desde el propio diseño del sistema.
Es necesario analizar:
- Finalidad y base de legitimación.
- El proveedor del sistema.
- Los subencargados del tratamiento.
- La región de tratamiento y las posibles transferencias internacionales.
- Si los datos se usan para entrenamiento.
- El plazo de conservación.
- Los derechos de las personas.
- Si procede una evaluación de impacto (EIPD).
Un bot debe reconocer las solicitudes de ejercicio de derechos o derivarlas a una persona, y no debe seguir enviando comunicaciones comerciales después de que el usuario se haya opuesto.
Conocimiento y RAG
Las respuestas deben basarse en fuentes autorizadas, con fecha y versión identificables. Si no hay evidencia que las respalde, el sistema debe abstenerse de responder.
Es imprescindible separar el contenido público, los contratos y los datos de cada cliente, y aplicar los permisos correspondientes antes de recuperar cualquier información, no después.
Autenticación
Antes de mostrar el estado de un caso o de ejecutar un cambio, la identidad del interlocutor debe verificarse con factores proporcionales al riesgo. Conocer el nombre o el número de pedido no siempre es prueba suficiente.
La autenticación no se delega en el modelo de lenguaje: es el sistema de identidad de la empresa el que entrega el contexto ya autorizado.
Herramientas
Cada herramienta que se pone a disposición del sistema debe definir:
- Una operación específica.
- Un esquema de entrada y salida.
- Un permiso asociado.
- Un límite de uso.
- Idempotencia.
- Un mecanismo de aprobación.
- Un registro de auditoría.
Consultar un pedido, cambiar una dirección y tramitar un reembolso son capacidades distintas y deben tratarse como tal.
Escalado humano
El escalado a una persona debe activarse ante:
- Solicitud expresa del cliente.
- Baja confianza en la respuesta.
- Repetición de la consulta.
- Señales de enfado.
- Situaciones de vulnerabilidad.
- Reclamaciones.
- Excepciones fuera de catálogo.
- Caída de una herramienta.
- Casos de alto impacto.
La persona que recibe el caso debe disponer de un resumen, los datos ya confirmados y los pasos dados hasta ese momento. El cliente no debe repetir toda la conversación.
Calidad
Las métricas deben cubrir varias capas:
| Capa | Métrica |
|---|---|
| Resolución | Caso resuelto correctamente |
| Fidelidad | Respuesta respaldada por una fuente |
| Seguridad | Datos o acciones prohibidas evitadas |
| Experiencia | Abandono y escalado |
| Operación | Latencia y disponibilidad |
| Negocio | Coste por caso válido |
La «deflection» —el porcentaje de casos que no llegan a una persona— no es un éxito por sí sola si oculta frustración del cliente o respuestas incorrectas.
Conjunto de prueba
Antes de poner en producción cualquier arquitectura conviene validarla frente a un conjunto de prueba que incluya:
- Preguntas normales.
- Casos de ambigüedad.
- Normativa o condiciones ya desactualizadas.
- Datos sensibles.
- Reclamaciones.
- Ejercicio de derechos.
- Intentos de ataque.
- Caída de una herramienta.
- Clientes en situación de vulnerabilidad.
- Ausencia de respuesta disponible.
Seguridad
Las amenazas más relevantes sobre estos sistemas incluyen:
- Inyección de instrucciones (prompt injection).
- Extracción de datos.
- Suplantación de identidad.
- Abuso de descuentos.
- Devoluciones fraudulentas.
- Enlaces maliciosos.
- Consumo ilimitado de recursos.
Frente a ellas se aplican límites de frecuencia, validación de entradas, permisos por herramienta y monitorización continua. El propio texto de instrucciones (prompt) no es un control de seguridad suficiente.
Copiloto para agentes humanos
Suele ser el primer paso más seguro para introducir IA en atención al cliente. Puede resumir la conversación, buscar la fuente adecuada y preparar una respuesta, pero es la persona quien la revisa antes de enviarla.
Se debe medir tanto la corrección de sus propuestas como el grado de dependencia del equipo hacia ellas. El equipo debe conservar siempre la posibilidad de discrepar del copiloto.
Plan de 90 días
Días 1-30
Definición de intenciones, riesgos, fuentes de conocimiento y línea base de partida.
Días 31-60
Construcción del chatbot o copiloto, pruebas, revisión de privacidad y diseño del escalado.
Días 61-90
Piloto en producción, medición de métricas y activación de acciones acotadas.
Errores frecuentes
- Elegir la arquitectura de «agente» por moda, sin justificarla por el riesgo real.
- No disponer de un catálogo de intenciones.
- Ocultar que se trata de un sistema de IA.
- Pedir datos excesivos al usuario.
- Responder sin fuentes que respalden la información.
- Autenticar solo a partir de lo dicho en la conversación.
- Conceder demasiadas herramientas al sistema.
- No prever el escalado a una persona.
- Medir solo la contención de casos, no su resolución real.
- Guardar las conversaciones sin un plazo de conservación definido.
Checklist
- Arquitectura elegida por riesgo, no por moda.
- Catálogo de intenciones definido.
- Transparencia sobre el uso de IA.
- Protección de datos revisada.
- Fuentes de conocimiento identificadas.
- Autenticación proporcional al riesgo.
- Herramientas mínimas necesarias.
- Escalado humano definido.
- Evaluación y conjunto de prueba.
- Seguridad y coste bajo control.
Preguntas frecuentes
¿Chatbot o agente?
Empiece por un chatbot con RAG o por un copiloto. Reserve el agente únicamente para acciones acotadas y reversibles.
¿Debe decir que es IA?
Sí, en los supuestos del artículo 50 del AI Act, salvo que resulte evidente, y siempre de forma clara.
¿Puede gestionar reclamaciones?
Puede recibirlas y clasificarlas, pero los casos complejos necesitan la intervención de una persona y trazabilidad completa.
Summum IA puede diseñar la arquitectura, el sistema de RAG, las herramientas, la evaluación y el escalado del canal de atención al cliente.