Hay un tipo de fallo que la prueba habitual no llega a provocar, así que la prueba sale limpia y el fallo sigue ahí. El 1 de septiembre se publicó uno de manual, contado por quien lo cometió.
Qué ha pasado
Lo cuenta VentureBeat. Egiziago Cioffi —CEO de SynSphere Italia, un partner de Microsoft con sede en Milán— había montado sobre Azure OpenAI un asistente que lee el correo que entra y lo resuelve solo en buena parte, sin que intervenga una persona.
El asistente aprobó todas las evaluaciones que le pasó su equipo. Y aun así, cuando alguien le preguntaba, devolvía contenido de documentos internos que esa persona no habría podido abrir por su cuenta.
Cioffi lo descubrió así: le hizo al asistente, desde una cuenta con pocos permisos, las mismas preguntas que ya le había hecho desde una cuenta con muchos. Las respuestas no coincidieron. El registro de qué documentos había consultado el asistente para responder fue después la prueba de lo que estaba pasando: según el reportaje, esos registros contaban una historia distinta de la que contaban las puntuaciones de las evaluaciones.
El fallo no estaba en el modelo: estaba en quién preguntaba
Conviene entender la mecánica, porque no es exótica: la comparte cualquier sistema que responda a partir de documentos.
Un asistente de este tipo funciona en dos tiempos. Primero indexa: recorre los documentos y los guarda troceados en un almacén propio para poder buscarlos rápido. Después consulta: cuando alguien pregunta, busca los trozos que vienen al caso y se los pasa al modelo para que redacte la respuesta.
El problema estaba en el segundo tiempo: el sistema no comprobaba los permisos al responder. En el momento de contestar, nadie preguntaba quién estaba preguntando.
Y el primer tiempo explica por qué eso importa tanto. El reportaje lo cuenta como un patrón, no como un detalle de este caso concreto: los desarrollos propios de recuperación que se saltan el buscador de la plataforma acaban indexando con una cuenta de servicio de permisos amplios, la que lo ve todo, que es lo cómodo para indexar.
Dicho sin tecnicismos: el asistente se había leído el archivador entero con la llave del jefe, y luego respondía a cualquiera con lo que recordaba de esa lectura.
Hay un detalle del caso que conviene no saltarse, porque es incómodo justo para quien programa a medida. La plataforma ya ofrecía de serie el recorte por permisos: el reportaje señala que Azure AI Search lo trae de forma nativa, documento a documento, desde su vista previa de mayo de 2025. Lo que pasó es que el desarrollo propio de recuperación no pasó por ahí. No fue una plataforma que no protegiera: fue una pieza a medida que dejó fuera la protección que había.
El arreglo fue proporcionado al problema: un filtro en el momento de la consulta, que comprueba los permisos de quien pregunta antes de que el modelo llegue a ver un solo fragmento. Y con él llegó su consecuencia, que es la mitad que se suele olvidar: el asistente pasó a alcanzar menos cosas, y parte del contenido con el que antes respondía dejó de estar a su alcance. No hizo falta cambiar de plataforma ni comprar un producto de identidad; el reportaje lo contrasta con dos compras de miles de millones hechas en ese mercado en los últimos meses. Con el filtro funcionando, el asistente sigue resolviendo alrededor del 60 % del correo que entra: la cifra es de Cioffi y es la de después del arreglo, y ese es justo el punto —el recorte no se llevó por delante lo que el asistente servía para hacer—.
Por qué las pruebas salieron verdes
Aquí está lo que hace este caso útil para quien no programa.
Las evaluaciones de un asistente miden si responde bien: si acierta, si no se inventa cosas, si encuentra el documento que toca. Y se hacen desde una cuenta. Lo normal —esto es criterio nuestro, no un dato del reportaje— es que sea la cuenta de quien lo está construyendo, que tiene permiso para verlo todo.
Con esa cuenta el sistema se comporta de maravilla. Responde bien, encuentra lo que tiene que encontrar y no revela nada que esa persona no pudiera ver. La prueba no falla porque no llega a poner al sistema en la situación que falla.
Por eso la comprobación que destapó el caso es tan barata: las mismas preguntas desde una cuenta con muchos permisos y desde una con pocos, y las respuestas comparadas una al lado de la otra. El reportaje le pone precio: dos cuentas y media hora.
Es la misma familia de problema que contábamos en el artículo sobre lo que un asistente se cree cuando lee, y a la vez es el paso siguiente. Aquel iba de hasta dónde llega el asistente. Este va de algo que sobrevive aunque eso esté bien resuelto: el alcance puede estar bien medido para el sistema y estar mal para cada persona que pregunta.
Dos asistentes distintos, dos preguntas distintas
Bajo el mismo nombre —«asistente»— conviven dos cosas que se rompen de manera distinta. Antes de aplicar nada de lo anterior, conviene saber cuál es la tuya.
El que atiende a cualquiera: todo lo que lee es público
Es el asistente de la web, el que responde dudas a quien entra: horarios, servicios, condiciones, cómo funciona algo. Aquí no hay permisos que comprobar, porque todos los que preguntan son la misma persona a ojos del sistema: un visitante anónimo.
Eso simplifica el problema y lo vuelve más severo a la vez. No hay filtro que poner, porque no hay a quién distinguir. La única pregunta que queda es qué le has dejado leer, y conviene sacarle la consecuencia: un documento que el asistente puede leer hay que darlo por publicado, porque para sacárselo basta con preguntar bien.
La comprobación, aquí, es más corta todavía: pregúntale algo que no debería saber. Márgenes, condiciones de un cliente concreto, precios que no están publicados. Si contesta, ya sabes qué había en su índice.
El que atiende a los tuyos: la prueba de las dos cuentas
Es el asistente interno, el que responde sobre documentos que no son públicos y donde no todo el mundo puede ver lo mismo: un histórico de expedientes, un repositorio con documentación por proyecto, una carpeta por departamento.
Este es el del caso de arriba, y aquí sí hay permisos, porque el sistema que guarda esos documentos ya los tiene: alguien decidió en su día quién ve qué. Según el patrón que describe el reportaje, lo que suele fallar no es que esos permisos no existan, sino que el asistente se monta por un lado y los permisos viven por otro, y no se juntan en el momento de responder.
Dos preguntas lo cubren casi entero:
- ¿Con qué cuenta se indexaron los documentos? Si la respuesta es «con una que lo ve todo», hace falta la segunda.
- ¿Se comprueba el permiso de quien pregunta en el momento de responder, antes de que el modelo vea el documento? Si la comprobación llega después, cuando el texto ya está redactado, llega tarde.
Dónde toca esto lo que hacemos
De los dos asistentes de esta página, el que describen nuestras soluciones es el primero: «asistentes que responden con la información de tu negocio». Es el que atiende a quien entra en tu web, y ahí la conversación no va de permisos —no hay a quién distinguir—, va de inventario: qué entra en lo que puede leer y qué se queda fuera. Es una lista que se decide antes de escribir una línea de código, y suele ser corta.
Que se decida es la parte que depende de programar a medida. Los módulos avanzados de esa página —el de inteligencia artificial y el de integraciones por API— están descritos como módulos «que ya desarrollamos y mantenemos», y con una frase que aquí importa: «No son integraciones de terceros: son parte de nuestra tecnología». Lo que se sigue de eso, y es lo único que se sigue, es que el alcance de tu asistente es una decisión de tu proyecto y no una casilla que venga marcada de fábrica.
Y el caso de arriba obliga a decir la otra mitad, que es incómoda para cualquiera que programe a medida, nosotros incluidos: lo que se hace a medida también puede dejar fuera una protección que la plataforma ya ofrecía de serie. Programar a medida no es una garantía por sí mismo. Lo que da es la posibilidad de decidirlo, y la obligación de responder de la decisión.
Para el segundo caso —el asistente interno sobre documentos con permisos por persona— la pregunta que hay que hacer es la misma, y hay que hacérsela a quien te monte ese sistema: «¿comprueba quién pregunta en el momento de responder?». La respuesta buena es concreta y sobre tu sistema; si es sobre la categoría, no es una respuesta.
Qué pedir mañana
Si ya tienes un asistente funcionando, o estás valorando uno, no hace falta una auditoría para empezar. Hacen falta tres cosas que puede contestar quien te lo montó:
- Si atiende al público: pregúntale tres cosas que no debería saber. Lo que conteste te dice qué hay en su índice.
- Si atiende a gente tuya con permisos distintos: la prueba de las dos cuentas, que en el caso de arriba costó media hora. Las mismas preguntas desde la cuenta con más permisos y desde la que menos tiene, y las respuestas comparadas.
- En los dos casos: pide ver el registro de qué documentos consultó para responder. En este caso fue justo ese registro el que sirvió de prueba, y sin él no hay nada que mirar cuando algo se tuerce.
Ninguna de las tres exige comprar nada. Las tres exigen que alguien tenga la respuesta.
Esto es trabajo de quien mantiene tu sistema, sea quien sea. Si lo que tienes es la duda de por dónde meter esto en tu negocio, eso sí es una conversación de partida: nos cuentas cómo trabajas y te decimos qué se puede digitalizar y qué no.
Cuéntanos cómo trabajas hoy, sin compromiso.
Fuentes
- Louis Columbus, «Closing an Azure OpenAI assistant's retrieval gap didn't take a new identity platform. It took one filter and a narrower assistant», VentureBeat, 1 de septiembre de 2026. https://venturebeat.com/security/azure-openai-agent-passed-every-evaluation-served-files-user-couldnt-open — leído entero. De aquí salen el caso, la cifra del 60 %, la causa técnica, el arreglo, el detalle del recorte por permisos de la plataforma y el precio de la prueba de dos cuentas.
