Una prueba realizada en julio a 200 restaurantes de Ámsterdam demostró que los asistentes de IA actuales no pueden completar una reserva de mesa porque el widget de reserva está oculto dentro de un iframe.

Por qué el iframe bloquea a los agentes

La mayoría de las herramientas de reserva en línea se entregan como un iframe incrustado. Un visitante hace clic en un botón de "Reservar", aparece un calendario y el usuario selecciona un horario. Para un humano, el proceso funciona; para un agente de IA, se detiene.

  • El agente analiza la página HTML principal.
  • El botón de reserva apunta a una URL en un dominio diferente.
  • El navegador carga esa URL dentro de un iframe, aislándola de la página principal.

Debido a que la política de mismo origen (same-origin policy) impide que los scripts de la página principal lean el DOM del iframe o intercepten sus llamadas de red, un agente de IA que lee el contenido de la página y envía solicitudes HTTP solo ve el botón. Nunca ve el calendario, los horarios o el flujo de confirmación. Incluso si hace clic en el botón, todavía debe resolver captchas, adaptarse a cambios en el diseño o esquivar las defensas anti-automatización que emplean muchos servicios de reserva.

El enlace legible por máquinas que falta

Una auditoría independiente de 163 sitios web de restaurantes funcionales encontró solo nueve que exponían algún tipo de datos de reserva legibles por máquinas. Esos nueve enumeraban información básica (nombre y dirección) utilizando marcado de schema.org, pero ninguno incluía acciones de reserva que un agente pudiera invocar. Schema.org define tipos como ReserveAction para este propósito; sin embargo, la mayoría de los sitios publican únicamente metadatos descriptivos, no instrucciones accionables.

En la práctica, un asistente busca datos estructurados que le indiquen cómo realizar una tarea, no solo cuál es la tarea. Sin un ReserveAction o un endpoint comparable, el agente recurre a imitar un clic humano, lo cual, como se describió anteriormente, no es fiable.

Una solución práctica que no destruye la interfaz de usuario

  1. Publicar una API de reservas – Crear un endpoint HTTP ligero que acepte solicitudes JSON para consultas de disponibilidad y creación de reservas. La API devuelve campos como fecha, hora, número de comensales y código de confirmación. Cualquier agente puede consumirla sin necesidad de renderizar una página.
  2. Hacer que la API sea descubrible – Colocar un puntero en una ubicación conocida, como /.well-known/booking, o incrustar una entrada de ReserveAction en el marcado schema.org de la página. Esto le indica a los agentes que "hay una forma programática de reservar aquí" sin necesidad de realizar scraping.
  3. Adoptar el Model Context Protocol (MCP) – El MCP permite que los asistentes invoquen herramientas externas directamente, pasando entradas y recibiendo salidas estructuradas. Los principales proveedores de IA ya son compatibles con MCP, por lo que un restaurante que implemente un endpoint compatible con MCP puede ser llamado por los agentes como si fuera una función integrada.

Estos pasos permiten que el iframe visual permanezca para los usuarios humanos, al tiempo que ofrecen a los agentes una vía limpia y fiable para acceder a los mismos datos de reserva.

Conclusión

Incrustar un calendario dentro de un iframe protege el flujo visual para los humanos, pero deja ciegos a los asistentes de IA. Añadir una API de reservas modesta y bien documentada, y promocionarla a través de metadatos estándar o MCP, abre un nuevo canal de reservas sin tener que reformar todo el sitio web. El esfuerzo aumenta la visibilidad ante la próxima generación de asistentes digitales, y el riesgo puede gestionarse con los mismos controles de seguridad que ya se utilizan en la interfaz de usuario existente.