La respuesta corta es esta: un agente de IA no debe responder desde la memoria del modelo cuando la pregunta depende de información de tu empresa. Debe consultar fuentes autorizadas, mostrar qué evidencia respalda la respuesta, respetar permisos y entregar el caso a una persona cuando la información sea insuficiente, contradictoria o sensible.
Este diseño ayuda a reducir las llamadas “alucinaciones” de la IA. NIST utiliza el término confabulación para describir contenido falso o erróneo presentado con seguridad. El riesgo no desaparece por redactar un prompt más largo: se gestiona con arquitectura, datos, reglas, evaluación y supervisión.
Para una empresa, el problema no es solamente que el agente se equivoque en una frase. Una respuesta inventada puede comunicar una cobertura inexistente, prometer inventario, citar una política vencida, ofrecer un plazo que la operación no confirmó o activar una acción fuera de autorización. Por eso, la calidad de un agente de servicio al cliente depende tanto de qué sabe como de qué puede hacer cuando no sabe.
Qué significa fundamentar un agente de IA
Fundamentar o *grounding* significa conectar la respuesta del modelo con información verificable. En un flujo de generación aumentada por recuperación, conocido como RAG, el sistema primero busca contenido relevante en fuentes empresariales y después entrega ese contexto al modelo para redactar una respuesta.
La secuencia básica es:
1. El cliente hace una pregunta por WhatsApp, webchat, correo o voz.
2. El sistema identifica la intención y los permisos aplicables.
3. El agente busca fragmentos relevantes en las fuentes autorizadas.
4. Evalúa si la evidencia encontrada es suficiente y vigente.
5. Responde con base en esa evidencia o se abstiene de afirmar lo que no puede respaldar.
6. Si el caso supera sus límites, crea un handoff con la conversación, las fuentes consultadas y el motivo del escalamiento.
Microsoft describe RAG como la combinación de búsqueda y generación para producir respuestas basadas en conocimiento específico de la organización. Google Cloud añade que una comprobación de fundamentación puede evaluar cuánto de una respuesta está respaldado por los textos de referencia y asociar citas con las afirmaciones. La lección operativa es importante: conectar documentos es solo el inicio; también hay que medir si realmente respaldan la respuesta.
La base de conocimiento importa más que la cantidad de documentos
Subir todos los archivos de una empresa a un índice no crea automáticamente una fuente confiable. Si existen versiones duplicadas, políticas vencidas, propietarios desconocidos o permisos demasiado amplios, el agente recuperará incertidumbre con mayor velocidad.
Una base de conocimiento lista para agentes de IA debería definir, como mínimo:
- Propietario: área o persona responsable de cada fuente.
- Vigencia: fecha de publicación, revisión y expiración cuando aplique.
- Alcance: producto, país, sede, canal, segmento o proceso al que corresponde.
- Autoridad: qué fuente prevalece cuando dos documentos se contradicen.
- Permisos: quién puede consultar información pública, interna, confidencial o restringida.
- Trazabilidad: título, versión y ubicación que permitan revisar el origen de una respuesta.
- Ciclo de actualización: evento o frecuencia que activa una revisión.
Por ejemplo, una política comercial vigente aprobada por el área responsable debería prevalecer sobre una presentación antigua. Un dato transaccional —como el estado de un pedido o una cita— no debería provenir de un manual, sino del CRM, ERP o sistema operativo que mantiene el estado actual.
Fuente documental y dato operativo no son lo mismo
| Pregunta del cliente | Fuente apropiada | Respuesta segura |
|---|---|---|
| ¿Cuál es la política de cambios? | Política vigente por país y canal | Explica condiciones y enlaza la fuente aplicable |
| ¿Mi pedido ya salió? | OMS, ERP o sistema logístico | Informa únicamente el estado confirmado |
| ¿Hay disponibilidad para mañana? | Inventario y agenda en tiempo real | Ofrece espacios o unidades realmente disponibles |
| ¿Me pueden aprobar una excepción? | Regla de negocio y responsable autorizado | Recopila el caso y escala; no promete la aprobación |
| ¿Qué datos guardan sobre mí? | Política de privacidad y proceso de derechos | Informa el procedimiento vigente y deriva solicitudes sensibles |
Esta separación evita un error frecuente: pedirle a la IA que convierta contenido descriptivo en una decisión operativa. Un documento puede explicar cómo funciona un proceso, pero no necesariamente autoriza una devolución, reserva inventario o modifica un contrato.
Reglas para que el agente sepa cuándo no responder
Un agente empresarial necesita una política explícita de abstención. No basta con decirle “no inventes”. El flujo debe reconocer condiciones verificables que cambian su comportamiento.
Conviene escalar o pedir aclaración cuando:
- No aparece una fuente relevante para la pregunta.
- La evidencia recuperada tiene baja relación con la consulta.
- Dos fuentes vigentes ofrecen instrucciones incompatibles.
- Falta un dato imprescindible, como país, producto, número de caso o identidad validada.
- La pregunta solicita una excepción, decisión regulada o compromiso comercial no autorizado.
- La información necesaria está fuera de los permisos del usuario o del agente.
- Una integración falla y no es posible confirmar el estado real.
- El cliente expresa una situación sensible, una queja grave o solicita hablar con una persona.
El escalamiento útil no debería obligar al asesor a empezar de cero. El inbox debe recibir el historial, la intención detectada, los datos confirmados, las fuentes consultadas, el punto exacto de incertidumbre y el siguiente paso sugerido.
Permisos mínimos: responder no equivale a ejecutar
Un agente puede tener permiso para leer el estado de una factura sin tener permiso para modificarla. También puede preparar una tarea sin aprobarla, proponer un horario sin reservarlo o redactar una respuesta sin enviarla automáticamente.
OWASP identifica la agencia excesiva como un riesgo que aparece cuando un sistema tiene demasiadas funciones, permisos o autonomía. Su recomendación de limitar extensiones y capacidades al mínimo necesario se traduce en una regla práctica: cada herramienta del agente debe tener un propósito acotado, parámetros validados y controles adicionales para acciones de mayor impacto.
Una matriz simple puede separar cuatro niveles:
1. Consultar: leer fuentes o estados permitidos.
2. Preparar: resumir, clasificar o completar un borrador.
3. Proponer: presentar una acción para confirmación del cliente o del equipo.
4. Ejecutar: cambiar un sistema mediante una función autorizada, con validaciones, registro y aprobación cuando corresponda.
El modelo puede ayudar a interpretar lenguaje y seleccionar el siguiente paso, pero las reglas determinísticas deben validar identificadores, rangos, estados permitidos y permisos antes de una escritura en CRM, ERP, agenda o plataforma de pagos.
Cómo implementar un agente con conocimiento verificable
1. Elige un caso de uso delimitado
Empieza con preguntas frecuentes de alto volumen y bajo riesgo, o con un proceso donde las fuentes y el resultado esperado estén claros. Define qué consultas quedan fuera desde el primer día.
2. Construye un inventario de fuentes
Lista documentos, páginas, tablas y sistemas operativos. Asigna propietario, vigencia, prioridad, permisos y método de actualización. Retira o marca el contenido obsoleto antes de indexarlo.
3. Diseña la recuperación
Prueba cómo busca el sistema con el lenguaje real de los clientes, incluidos sinónimos, errores comunes y preguntas incompletas. Conserva metadatos como título, versión, país, producto y URL para mejorar filtros y trazabilidad.
4. Define umbrales y salidas seguras
Especifica cuándo responder, cuándo pedir un dato adicional y cuándo escalar. No presentes un puntaje técnico de confianza como garantía para el cliente; úsalo junto con reglas, evidencia y riesgo del caso.
5. Limita herramientas y acciones
Entrega al agente solo las funciones necesarias. Separa lectura y escritura, valida cada parámetro, registra las ejecuciones y exige confirmación o aprobación humana en decisiones de mayor impacto.
6. Evalúa antes y después de publicar
Crea un conjunto de preguntas reales con respuesta esperada, fuente correcta y conducta deseada. Incluye casos sin respuesta, documentos contradictorios, datos vencidos, intentos de obtener información restringida y fallas de integración.
Métricas para saber si el agente responde con respaldo
- Porcentaje de respuestas con una fuente vigente y pertinente.
- Exactitud de la fuente recuperada frente a una muestra revisada.
- Respuestas no respaldadas detectadas en QA.
- Tasa de abstención correcta cuando no existe evidencia suficiente.
- Escalamientos correctos y falsos escalamientos.
- Incidentes por uso de contenido vencido o fuera de permisos.
- Acciones bloqueadas por validaciones antes de escribir en un sistema.
- Tiempo de actualización desde que cambia una política hasta que el agente usa la nueva versión.
- Resolución y satisfacción del cliente, comparadas con la línea base.
Una tasa de escalamiento baja no siempre es una señal de éxito. Si el agente responde más porque ignora la incertidumbre, el indicador puede mejorar mientras aumenta el riesgo. La meta es resolver automáticamente lo que está respaldado y entregar con contexto lo que necesita criterio humano.
Preguntas frecuentes
¿RAG elimina por completo las alucinaciones?
No. RAG puede aportar información relevante y actualizada, pero todavía puede recuperar el fragmento incorrecto, interpretar mal la evidencia o redactar una afirmación que la fuente no respalda completamente. Por eso se combinan recuperación, validación, evaluación, abstención y supervisión.
¿Es suficiente conectar una carpeta de documentos?
No. La carpeta necesita gobierno: versiones, propietarios, vigencia, autoridad y permisos. Además, las preguntas sobre estados actuales deben consultar sistemas operativos, no documentos estáticos.
¿El agente siempre debe mostrar citas al cliente?
Depende del canal y del caso. En un chat puede enlazar una política o indicar su nombre; en voz puede ofrecer enviarla por mensaje. Aunque la cita no sea visible en cada interacción, la operación debería conservar qué fuentes sustentaron la respuesta para auditoría y mejora.
¿Cuándo debe intervenir una persona?
Cuando falta evidencia, hay contradicciones, el cliente pide una excepción, existe riesgo relevante o la acción supera los permisos del agente. La persona debe recibir el caso con contexto, no solo una alerta genérica.
Cómo lo aplica Seelai
Seelai conecta agentes de IA, inbox omnicanal, CRM inteligente, voz y automatizaciones para que una respuesta no quede aislada del proceso real. El agente consulta conocimiento autorizado; el inbox conserva conversación y handoff; el CRM aporta contexto permitido; y los webhooks o triggers activan únicamente acciones validadas en los sistemas correspondientes.
El objetivo no es crear un agente que conteste todo. Es construir uno que resuelva lo verificable, reconozca sus límites y deje trazabilidad cuando interviene una persona o un sistema operativo.
Fuentes
- NIST, Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile: https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence
- Microsoft Learn, Enhance AI responses by using Retrieval Augmented Generation: https://learn.microsoft.com/en-us/microsoft-copilot-studio/guidance/retrieval-augmented-generation
- Google Cloud, Check grounding with RAG: https://cloud.google.com/generative-ai-app-builder/docs/check-grounding
- OWASP Gen AI Security Project, LLM06:2025 Excessive Agency: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
Si quieres que tus agentes respondan con conocimiento vigente, respeten permisos y escalen con el contexto completo, agenda una demo de Seelai en /demo. Revisaremos un caso de uso real, sus fuentes, límites, integraciones y métricas antes de automatizarlo.