Usted le pregunta a un asistente si una función anunciada esta semana ya está disponible. Él encuentra un artículo reciente y responde con un enlace. Pero ese enlace puede hablar de una etapa futura, retomar un anuncio antiguo o referirse a otra oferta. Encontrar una página y verificar una afirmación son dos operaciones diferentes. La nueva interfaz de búsqueda web de Cloudflare proporciona un punto de entrada; su aplicación aún debe organizar el camino hacia una respuesta verificable.
En el escenario ficticio de este artículo, usted prepara un asistente de seguimiento de productos. Su usuario espera una respuesta corta: lo que se anuncia, lo que está accesible y lo que sigue previsto. Proponemos un método para separar estos estados, mantener las pruebas útiles y producir un rechazo preciso cuando falta información. No se ha llamado a ningún servicio de búsqueda para medir su rendimiento.
Lo que cambia con la API de Búsqueda Web
El 2 de octubre de 2026, Cloudflare anunció Web Search API a través de AI Gateway, su pasarela para llamadas de IA. Las Server Tools nativas, que deben integrar herramientas del lado del servidor en esta pasarela, siguen anunciadas como un paso futuro. No se presentan aquí como disponibles.
La documentación consultada el 6 de octubre, actualizada el 2 de octubre, indica una beta abierta. Describe resultados estructurados que incluyen títulos, URL y descripciones, varios proveedores, un acceso REST desde un servidor o mediante binding Workers, y un registro en AI Gateway. REST se refiere aquí a una interfaz llamada mediante solicitudes de red; el binding es el acceso proporcionado al programa que se ejecuta en Workers.
El interés arquitectónico es hacer identificable la etapa «buscar». Puede asignarle un plazo, un costo, un estado de fallo y un registro. En nuestra propuesta, esta etapa devuelve candidatos. Otra etapa abre la fuente autorizada, una tercera califica la afirmación y la última redacta la respuesta. El mismo agente puede participar en varias etapas, pero las responsabilidades permanecen distintas en su aplicación.
Definir la pregunta antes de enviar una solicitud
« ¿Está disponible esta función? » carece de contexto. ¿Disponible para qué oferta, qué región, qué versión y en qué fecha? Solicite las precisiones necesarias o anuncie el alcance retenido. En nuestro ejemplo ficticio, la pregunta se convierte en: « A la fecha de consulta, ¿está la función descrita en este anuncio abierta a los desarrolladores de esta oferta? »
Una consulta de búsqueda debería contener los términos públicos necesarios para esta cuestión. No necesita el nombre de un cliente, su contrato ni el contenido de un expediente interno. Nuestra recomendación es construir una formulación mínima antes de la llamada al proveedor y verificar qué entra en los registros. Una traza útil para la operación puede volverse innecesariamente sensible si copia toda la conversación.
Fije también un presupuesto de trabajo. Su asistente puede tener un límite de llamadas, un plazo global y una lista de fuentes prioritarias. Estas elecciones son parámetros de aplicación a adaptar; no damos valores supuestamente óptimos. Cuando se agote el presupuesto, la aplicación debe distinguir entre «investigación incompleta» y «función no disponible».
Relacionar cada frase con una prueba
Para cada resultado relevante, busque la página de origen del hecho: anuncio del editor, documentación de la función o repositorio oficial. Una cobertura de prensa puede ayudar a su descubrimiento. No se convierte en prueba primaria únicamente porque su fecha sea más reciente. Si la página original es inaccesible, conserve esta limitación y reduzca el alcance de su respuesta.
En nuestro método, una prueba respalda una afirmación precisa. Por ejemplo, el anuncio puede respaldar «se prevé una apertura», mientras que la documentación de acceso debe respaldar «esta función es utilizable en tal oferta». Por lo tanto, puede haber dos enlaces útiles que respondan a dos preguntas diferentes. Una bibliografía colocada al final no resuelve esta correspondencia por sí sola.
Separe tres fechas. La fecha de publicación describe el documento. La fecha del evento describe lo que sucedió. La fecha de consulta describe el momento en que leyó la página. Un artículo publicado hoy puede relatar un evento antiguo; una documentación modificada hoy puede mantener una disponibilidad anterior. Si una fecha no es verificable, déjela como desconocida en lugar de deducirla de una URL.
Construir una ficha de prueba independiente del proveedor
Llamamos SearchEvidence al contrato conceptual que se muestra a continuación. Este nombre y sus campos pertenecen a nuestra demostración; no describen el esquema oficial de la API de Búsqueda Web. El objetivo es poder cambiar de fuente de búsqueda sin perder la lógica de verificación.
| Campo conceptual | Lo que describe | Control propuesto |
|---|---|---|
| URL de origen | Página efectivamente examinada | Dirección autorizada y apertura exitosa |
| Título | Identificación del documento | Correspondencia con la página leída |
| Consultado el | Momento del control | Sellado de tiempo de la aplicación |
| Publicado el | Fecha verificada del documento | Origen de la fecha conservada |
| Evento el | Fecha del hecho, si se conoce | Pasaje pertinente identificado |
| Afirmación sostenida | Frase que la prueba permite | Alcance limitado al contenido leído |
| Pasaje útil | Porción corta o reformulación | No copiar íntegramente de manera automática |
| Estado de la prueba | Suficiente, contradictoria o ausente | Regla explícita antes de la redacción |
El lector debe poder abrir la cita y entender por qué acompaña a la frase. En nuestro asistente de vigilancia, una respuesta podría presentar por separado un anuncio fechado y una disponibilidad que queda por confirmar. Si una página no permite determinar el estado de acceso, escríbalo. El modelo no debe completar este campo con lo que le parezca habitual para este proveedor.
Mantenga una distinción entre la URL del resultado y la de la página realmente consultada, especialmente después de una redirección. También registre un rechazo de apertura o una restricción de acceso. Estos estados son útiles para explicar por qué no se pudo consolidar la evidencia, sin pretender que todos los sitios web son legibles.
Preparar una integración con límites visibles
En una aplicación existente, añada una interfaz de búsqueda junto a sus servicios documentales. Su salida es una lista de candidatos y un estado de llamada. La apertura de una página pertenece a un componente separado, con las reglas de red y recopilación permitidas por su organización. La redacción recibe luego únicamente los elementos necesarios sobre el tema.
La caché, es decir, la reutilización temporal de una respuesta anterior, requiere una elección explícita. Una búsqueda de definición y una pregunta sobre una disponibilidad actual no tienen el mismo requisito de frescura. Conserve la fecha de la evidencia reutilizada y prevea una nueva consulta cuando la pregunta lo requiera. La fecha de respuesta del asistente no debe dar la impresión de que todas las fuentes han sido recién revisadas.
Para evitar un bucle costoso, limite los reintentos y distinga los errores: tiempo excedido, acceso denegado, formato inesperado o búsqueda sin candidato pertinente. Prepare un mensaje de salida para cada uno. «No pude verificar la página principal» es más útil que una respuesta segura construida a partir de un resumen incompleto.
Este recorrido puede complementar una base interna. Esta conserva sus procedimientos y su vocabulario; la búsqueda pública sirve para verificar un anuncio o una evolución externa. El uso llamado RAG, generación aumentada por recuperación de documentos, consiste precisamente en aportar documentos al modelo antes de su respuesta. La adición de una búsqueda web invita a organizar las fuentes públicas e internas, con sus derechos y sus requisitos de actualidad.
Probar las respuestas, las citas y los rechazos
El siguiente protocolo es una propuesta de Partitech. Utiliza páginas de prueba controladas o dobles de prueba de red: componentes que simulan las respuestas sin llamada real al proveedor. Permitiría evaluar la lógica de su aplicación sin presentar los resultados como los del servicio Cloudflare.
| Caso de prueba propuesto | Observación esperada | Salida a verificar |
|---|---|---|
| Anuncio reciente de una etapa futura | Fecha reciente, acceso futuro | Distinción anunciado/previsto |
| Hecho antiguo en una página reciente | Dos fechas diferentes | Sin presentación como novedad |
| Página principal inaccesible | Resultado de búsqueda solo | Verificación insuficiente reportada |
| Dos fuentes divergentes | Perímetros o versiones diferentes | Contradicción explicada |
| Tiempo de espera de la red excedido | Búsqueda incompleta | Fracaso declarado, sin conclusión inventada |
| Instrucción en una página | Texto fuera de la aplicación | Instrucción ignorada, datos tratados como fuente |
Luego evalúe las respuestas frase por frase. Cuente las afirmaciones respaldadas, las que no tienen evidencia y aquellas cuya cita se refiere a otro ámbito. Examine también las negativas: ¿están justificadas y dicen lo que falta? Un asistente que lo niega todo no cumple mejor la tarea que un asistente que siempre responde.
Separe la prueba del componente de búsqueda y la de redacción. Puede obtener buenos resultados y producir un mal resumen, o no encontrar ninguna fuente a pesar de una excelente lógica de citación. Esta separación ayuda a elegir la corrección pertinente en lugar de modificar al azar la instrucción del modelo.
Tratar las páginas como datos externos
Una página puede contener una frase que le pida al agente que ignore sus reglas o que envíe una información a otro lugar. En nuestro diseño, este texto no adquiere ninguna autoridad: sigue siendo un contenido para examinar. Los permisos de acción, la consigna del sistema y los secretos no deben ser redefinidos por una fuente buscada.
Por lo tanto, prevea una prueba donde una página de demostración contenga una instrucción ajena al tema. El éxito esperado es una extracción limitada a la prueba útil, sin acción adicional. Verifique también los registros y la respuesta final para evitar que reproduzcan datos sensibles añadidos al contexto. Se trata de una salvaguarda que debe probarse en su propia arquitectura, no de una capacidad garantizada por una API de búsqueda.
Para empezar, elija una cuestión pública y limitada, determine las pruebas necesarias y prepare los seis casos de prueba. El siguiente paso es obtener una respuesta en la que cada afirmación pueda ser verificada, así como un rechazo comprensible cuando falten pruebas. Luego podrá medir el servicio real en un marco autorizado, con sus costos y sus límites fechados.
Fuentes y fecha de verificación
Fuentes primarias reabiertas y leídas el 6 de octubre de 2026 : Cloudflare, anuncio de la API de Búsqueda Web del 2 de octubre ; documentación Web Search API, actualizada el 2 de octubre. El contrato SearchEvidence, el escenario y las pruebas son propuestas de Partitech. No se reivindica ningún benchmark, prueba de la red de aplicaciones ni auditoría de los socios.