Un agente IA puede responder con rapidez y aun así crear un problema operativo si consulta una política antigua, una tarifa ya sustituida o una instrucción que no corresponde al cliente, al país o al sistema desde el que se realiza la acción. El riesgo no se corrige añadiendo más documentos a una base de conocimiento: se corrige decidiendo qué fuente está autorizada para cada finalidad, quién la mantiene y cuándo deja de poder utilizarse.
Este artículo propone un método para empresas que quieren conectar agentes a procedimientos, catálogos, documentación comercial o conocimiento de soporte sin confundir una respuesta bien redactada con información válida. La IA puede ayudar a clasificar contenido, detectar duplicados y preparar revisiones; no debe declarar una fuente como vigente, interpretar una política ambigua ni ejecutar una acción sensible sin reglas y controles independientes.
El problema no es solo que el agente se equivoque
Cuando el conocimiento está repartido entre carpetas, wikis, CRM, correo y documentos personales, aparecen versiones contradictorias. Un agente que recupera cualquiera de ellas puede dar una respuesta coherente, pero no necesariamente aplicable. Esto afecta a soporte, ventas, operaciones, compras y equipos internos.
Los fallos más costosos suelen tener un patrón común: no se puede explicar de qué documento salió la afirmación, qué versión se consultó, quién aprobó ese contenido ni si el agente tenía derecho a verlo. La trazabilidad debe formar parte del diseño, no ser una tarea posterior cuando ya hay una incidencia.
Empiece por una finalidad concreta y un límite claro
No conviene crear un repositorio genérico para que un agente “sepa de todo”. Delimite una primera finalidad, por ejemplo: ayudar al equipo de soporte a localizar el procedimiento vigente de devolución, preparar una respuesta interna sobre un producto o clasificar una consulta comercial.
Para esa finalidad, defina por escrito:
- qué pregunta o tarea puede atender el agente;
- qué sistemas y tipos de documento puede consultar;
- qué respuesta puede ofrecer y qué acción queda excluida;
- qué debe hacer cuando no encuentra una fuente suficiente o encuentra conflicto.
Un buen criterio de inicio es elegir una tarea repetitiva, con fuentes identificables y con una salida que pueda revisar una persona. Evite empezar por decisiones que cambian precios, condiciones contractuales, accesos, pagos o compromisos externos.
Construya un inventario de fuentes, no una carpeta más
Antes de indexar contenido, prepare un inventario mínimo. Cada fuente candidata debe tener un identificador, ubicación, tipo, propietario, ámbito de uso, nivel de acceso, fecha de revisión y estado. El estado no es decorativo: una fuente debe poder estar propuesta, aprobada, en revisión, retirada o bloqueada.
También conviene registrar la relación con otras fuentes. Si una política corporativa prevalece sobre una guía de equipo, o una ficha vigente sustituye una versión anterior, esa regla debe existir fuera del modelo. De lo contrario, el agente puede recuperar ambas y presentar una mezcla difícil de detectar.
Ejemplo de ficha de una fuente autorizada
Para una guía de soporte, la ficha podría indicar: “procedimiento de sustitución de producto”, propietario en operaciones, aplicable a España, válida para clientes con contrato de mantenimiento, revisada el mes correspondiente y sustituye a la versión anterior. Además de indexar el texto, el sistema debería conservar ese contexto para filtrar y citar la fuente correcta.
Asigne propietario, revisión y fecha de caducidad
Todo contenido que alimente a un agente necesita una persona o área responsable de confirmar si sigue siendo utilizable. No basta con el autor original: el propietario es quien recibe la revisión, aprueba una actualización o retira la fuente cuando cambia una regla.
La fecha de revisión debe responder al tipo de contenido. Un catálogo, una política o una instrucción de seguridad pueden requerir ritmos distintos. Cuando no haya confirmación al vencimiento, la opción segura es reducir la confianza o excluir la fuente del agente hasta que se revise; no prolongarla automáticamente.
Controle permisos antes de conectar el contenido
Que un documento sea útil no significa que todo el mundo pueda usarlo. Clasifique las fuentes según sensibilidad y aplique los permisos del usuario y del proceso que consulta. Un agente de atención al cliente no debería recuperar información interna de costes, datos de otros clientes o borradores de negociación solo porque están en el mismo repositorio.
La arquitectura debe conservar el principio de mínimo privilegio: identidad técnica diferenciada, ámbitos de lectura limitados, registros de acceso y revocación posible. Cuando la plataforma no permite aplicar permisos de origen de manera fiable, limite el conjunto de fuentes o no utilice esa conexión para información sensible.
Haga que cada respuesta pueda mostrar su evidencia
Una respuesta operativa necesita indicar de qué fuente procede, su versión o fecha relevante y el nivel de certeza que permite el contenido. No se trata de llenar la pantalla de enlaces, sino de que la persona que revisa pueda abrir el documento, comprobar el contexto y detectar si se ha usado una fuente incorrecta.
Establezca una regla sencilla: si el agente no puede recuperar evidencia autorizada y pertinente, debe reconocer el límite, crear una consulta o dirigir el caso a quien corresponda. Inventar una respuesta plausible es peor que retrasar una respuesta que requiere verificación.
Separar recuperación, interpretación y decisión
La recuperación identifica documentos candidatos; la interpretación resume qué dicen; la decisión aplica una política o autoriza una acción. Son controles diferentes. Puede automatizarse la preparación de los dos primeros con salvaguardas, pero la decisión debe seguir una regla determinista o una aprobación humana cuando tenga impacto económico, contractual, de seguridad o de derechos de personas.
Pruebe con casos reales antes de abrir el agente
Prepare un conjunto de consultas representativas: preguntas normales, documentos actualizados recientemente, fuentes en conflicto, consultas fuera de alcance y peticiones que no deberían ver determinada información. Para cada caso, defina cuál es la fuente esperada, qué respuesta sería aceptable y cuándo debe escalarse.
Revise al menos estos criterios:
- la fuente recuperada corresponde al ámbito y al usuario;
- la versión mostrada es la vigente;
- la respuesta no añade condiciones que no figuran en la evidencia;
- los casos sin evidencia suficiente se detienen o escalan;
- las respuestas dejan un registro revisable de fuente y resultado.
Las pruebas no demuestran que el agente nunca fallará. Sirven para descubrir huecos en el inventario, permisos y reglas de escalado antes de que el sistema responda a un cliente o influya en una operación.
Diseñe un circuito para cambios y retiradas
Cuando cambia una condición, no basta con publicar el documento nuevo. Hay que identificar qué fuente sustituye, invalidar o retirar la anterior, actualizar los metadatos y comprobar que el índice o sistema de recuperación refleja el cambio. Mantenga una evidencia de quién aprobó la transición y cuándo se completó.
Incluya una ruta de urgencia para información que no debe seguir utilizándose, por ejemplo una instrucción insegura o una condición comercial retirada. Esa ruta debe poder bloquear una fuente y dejar constancia de los agentes o procesos afectados.
Use indicadores que permitan corregir el servicio
No mida solo cuántas preguntas contesta el agente. Revise cuántas respuestas citan una fuente autorizada, cuántas se escalan por falta de evidencia, cuántas fuentes han vencido su revisión y cuántas correcciones se deben a información desactualizada. Analice muestras de respuestas con el propietario del proceso, no únicamente con el equipo técnico.
Si una misma consulta se escala repetidamente, puede indicar que falta una fuente aprobada, que el ámbito está mal definido o que esa decisión no es adecuada para un agente. Ese aprendizaje sirve para ampliar el servicio con prudencia o para restringirlo.
Cuándo pedir apoyo para implantarlo
La implantación exige coordinar proceso, contenido, integración, permisos y supervisión. Es especialmente recomendable contar con apoyo cuando hay varias fuentes con datos sensibles, normativa sectorial, agentes que interactúan con clientes o sistemas que pueden iniciar acciones. En los servicios de KMOOPS podemos ayudar a definir el alcance, mapear fuentes y controles, diseñar los flujos de revisión y desplegar una solución que sea útil sin perder gobierno.
Si ya existe un agente que responde de forma inconsistente o no puede justificar sus respuestas, el primer paso no tiene por qué ser cambiar de modelo. Puede empezar por revisar una finalidad, sus fuentes y su circuito de aprobación. Contacta con KMOOPS para valorar el caso y priorizar una mejora aplicable.
Una lista de decisión antes de ponerlo en producción
- ¿La finalidad del agente y sus límites están definidos?
- ¿Cada fuente tiene propietario, ámbito, estado y revisión?
- ¿Las fuentes retiradas dejan de estar disponibles para recuperación?
- ¿Los permisos aplican también al acceso del agente?
- ¿La respuesta conserva evidencia suficiente para una revisión?
- ¿Hay una ruta clara para conflictos, ausencia de información y decisiones sensibles?
- ¿Se han probado casos reales, incluidos los que deben escalarse?
Un agente IA gana valor cuando recupera conocimiento fiable dentro de un proceso controlado. La prioridad no es que responda más, sino que sepa cuándo una fuente es aplicable, cuándo debe mostrarla y cuándo debe detenerse.