Hay una suposición integrada en el diseño de la mayoría de los agentes de IA que casi nadie cuestiona: si un dato es relevante para responder una pregunta, el agente debería poder usarlo.
Suena razonable, pero es un error.
Para las organizaciones que gestionan plataformas con varios grupos de participantes —clientes y comercios, pasajeros y conductores, clientes y proveedores de servicios—, esa suposición es lo que convierte silenciosamente los despliegues de IA en problemas de confianza.
La trampa de la relevancia
Un cliente contacta con soporte por una entrega con retraso. Quiere saber qué pasó y pide un reembolso.
La información más relevante incluye los tiempos medios de preparación del restaurante, el tiempo de preparación concreto de ese pedido, el historial de rutas del repartidor y cualquier alerta que surgiera durante la entrega. Todo es directamente útil y permite dar una respuesta mejor y más precisa.
Pero también expondría datos de rendimiento operativo del restaurante a un cliente que no tiene por qué verlos. Señalaría la conducta de un repartidor sin un proceso justo. Y trazaría una línea directa entre el resultado de una parte y los datos de otra, sin que ninguna lo sepa ni lo haya autorizado.
El agente no se equivocó: hizo exactamente aquello para lo que fue diseñado, encontrar lo relevante y usarlo. El error fue suponer que relevancia y permiso son lo mismo.
Por qué esta distinción es más difícil de lo que parece
En un producto de un solo lado, relevancia y permiso suelen coincidir. El usuario que hace la pregunta es también la persona cuyos datos están en juego. La distancia entre lo útil y lo permitido es tan pequeña que la mayoría de los agentes la gestionan sin incidentes.
Las plataformas multilaterales rompen por completo esa suposición.
Cada grupo de participantes tiene sus propios datos, flujos de trabajo, expectativas de privacidad y su propia idea de lo que es un resultado justo. Cuando un agente de IA opera sobre todos ellos a partir de una base de conocimiento compartida, no navega un único entorno de datos. Navega varios a la vez, sin límites firmes entre ellos.
Hay 3 modos de fallo que aparecen una y otra vez:
Fugas de datos entre superficies. La información relevante en una superficie pertenece a un participante de otra. Un agente para clientes que puede ver el historial de disputas de un comercio, un portal de comercios que muestra detalles de quejas de clientes o una interfaz para conductores que hace referencia a datos de sanciones de la plataforma.
Acciones con consecuencias no revisadas en otra parte. Un reembolso emitido en la superficie del cliente provoca una deducción en el pago al comercio. Un agente de IA que puede ejecutar la primera acción pero no ve la segunda consecuencia tomará decisiones aparentemente razonables que generan problemas que nunca llega a ver. El ciclo de retroalimentación no se cierra.
Trato incoherente según el grupo de participantes. La misma pregunta de fondo —¿por qué se redujo mi pago?— significa algo totalmente distinto si la hace un comercio o un conductor. Los datos disponibles, la respuesta adecuada y las acciones permitidas son diferentes. Un agente sin límites firmes entre superficies genera respuestas técnicamente correctas pero erróneas en su contexto.
Nada de esto es culpa del agente de IA: son fallos de arquitectura. Nadie le dijo al agente dónde estaban los límites.
La relevancia es un punto de partida, no una autorización
Este es el cambio de enfoque que importa: la relevancia debe orientar lo que el agente busca, pero la elegibilidad debe determinar a qué puede acceder realmente.
Son 2 preguntas distintas, que se responden en orden.
Primero va la elegibilidad. Antes de que un agente recupere nada, la plataforma ya debe haber respondido: ¿desde qué superficie llega esta interacción? ¿Qué grupo de participantes está autenticado? ¿Qué datos y acciones están dentro del alcance para esta superficie, este rol y este contexto de políticas? ¿Qué está totalmente fuera de los límites, por muy relevante que sea?
No son preguntas que el modelo deba razonar. Son restricciones que la plataforma aplica de forma determinista antes de que el agente empiece. Después, la relevancia opera dentro de esas restricciones, no en su lugar.
El efecto práctico es importante. Un agente limitado a la superficie del cliente no puede mostrar datos de comercios por accidente. No porque se le haya indicado que no lo haga, sino porque esos datos nunca fueron elegibles. Las instrucciones de un prompt se pueden sortear. Las restricciones de elegibilidad, no.
Esa diferencia importa más de lo que parece. «No debería usarlo» y «no puede acceder» no ofrecen el mismo nivel de protección. A escala, en entornos complejos y con casos límite reales, solo la segunda se sostiene.
Qué significa esto en la práctica
Las plataformas que lo hacen bien no crean agentes más restrictivos: crean agentes con mejor arquitectura. La capacidad de razonamiento del agente no cambia; lo que cambia es la superficie sobre la que razona.
El resultado no es un agente menos capaz. Es un agente en el que pueden confiar todos los grupos de participantes a la vez. En las plataformas multilaterales, esa es la capacidad que escala.
La relevancia te lleva a una buena respuesta. La elegibilidad te lleva a una respuesta fiable.
Míralo con tus propias conversaciones.
Solicita una demo personalizada gratuita.
