Diseñar para agentes de IA: la interfaz que lee el usuario no humano

El usuario no humano es el agente de IA que visita tu producto para actuar por una persona: comparar opciones, rellenar un formulario, reservar una cita o comprar. Diseñar para él significa construir una interfaz que una máquina puede leer y operar, no solo la que una persona ve en pantalla.

Antes era un caso límite. Ahora es tráfico. En la semana del 30 de mayo al 5 de junio de 2026, Cloudflare midió que el 57,2% de las peticiones a contenido HTML venían de clientes automáticos, por delante de los navegadores humanos. Adobe informó de que el tráfico desde fuentes de IA hacia sitios retail de EE. UU. creció un 393% interanual en el primer trimestre de 2026, y que en marzo convertía un 42% mejor que otras fuentes, hasta un 54% en mayo. Gartner prevé que para finales de 2026 el 40% de las aplicaciones empresariales integrará agentes especializados. El lector para el que nunca diseñaste ya está en la página.

¿Quién es el usuario no humano?

Aparecen tres tipos de agente. Los asistentes (ChatGPT, Claude, Perplexity) navegan y resumen. Los agentes de computer-use manejan un navegador real y hacen clic para completar tareas. Los agentes de commerce van un paso más allá y cierran una compra. Comparten un rasgo: ninguno ve tu diseño. Cada uno lee una representación de la página y actúa según lo que esa representación declara presente.

Así que la pregunta deja de ser "¿se ve bien?" y pasa a ser "¿puede un programa entender qué es esto y usarlo?". Una página puede pasar una design review y seguir siendo ilegible para un agente, porque los dos lectores consumen capas distintas de la misma página.

¿Cómo lee de verdad una página un agente de IA?

La mayoría de los agentes lee el árbol de accesibilidad. Es el modelo semántico que el navegador construye desde el DOM: una lista de elementos con roles (button, link, heading), nombres (la etiqueta accesible) y estados (expandido, marcado, deshabilitado). Los lectores de pantalla usan este árbol desde hace veinte años. Los agentes lo reaprovechan porque es más ligero y fiable que analizar los píxeles. OpenAI ha dicho que su navegador Atlas lee las etiquetas ARIA para interpretar la estructura de la página. La consecuencia práctica es clara: una página que funciona para una persona ciega tiende a funcionar para un agente, y la que falla con una falla con el otro.

El coste de un árbol degradado se mide. En el estudio A11y-CUA presentado en CHI 2026, investigadores de UC Berkeley y la University of Michigan ejecutaron Claude Sonnet 4.5 en 60 tareas cotidianas de escritorio y web bajo tres condiciones. Con acceso estándar completaba cerca del 78% de las tareas. Con navegación solo por teclado, que imita cómo se mueve un agente basado en el árbol de accesibilidad, el éxito bajó al 42% y las tareas tardaban alrededor del doble. Con un viewport ampliado cayó al 28%. Casi la mitad de los fallos se reducía a una sola cosa: la información estructural que el agente necesitaba no estaba en el markup.

Por qué la capa visual esconde el problema

La trampa es que una página con estilos parece terminada. Un button hecho con un div y un handler onClick se ve idéntico a un button real. Una persona ve un botón y hace clic. Un agente lee un contenedor genérico sin rol y sin nombre, y lo salta. La misma brecha aparece en todo punto donde un equipo recurre al estilo visual en lugar de la semántica:

• Controles con solo icono y sin etiqueta de texto. El agente ve algo clicable sin saber qué hace.
• Dropdowns y toggles a medida construidos con div y span. Sin rol, sin estado, sin ruta de teclado.
• Contenido dibujado en canvas o WebGL, o texto incrustado en imágenes. Invisible para el árbol.
• Estado mostrado solo con color. "Seleccionado" con un borde azul y nada en el markup que diga seleccionado.

Cada uno de estos casos va bien para una persona vidente y es un muro para el resto, tanto quien usa lector de pantalla como el agente.

¿Cómo se diseña para el usuario no humano?

El trabajo se solapa mucho con la accesibilidad bien hecha. Ocho movimientos cubren casi todo.

1. Usa elementos semánticos reales. button, a, nav, main, label, table, encabezados reales. Los elementos nativos traen el rol correcto y el comportamiento de teclado sin coste extra.
2. Pon nombre a cada control. Texto visible donde puedas, aria-label donde no. Un button de solo icono, sin nombre, para un agente es anónimo.
3. Mantén honesto el árbol en los componentes a medida. Si tienes que construir un widget con elementos genéricos, dale rol, estado y un orden de foco que coincida con lo que ve el ojo.
4. Haz el estado legible por la máquina. aria-expanded, aria-checked, aria-disabled. El color por sí solo no le dice nada al agente.
5. Expón datos estructurados. Con JSON-LD de Schema.org para productos, ofertas, precios y FAQ un agente lee los hechos sin hacer scraping del layout.
6. Deja entrar a los agentes. No bloquees sus crawlers en el edge por defecto. Lo explicamos en cómo desbloquear los rastreadores de IA sin romper la seguridad.
7. Mantén el contenido crítico renderizado en el servidor. Un agente puede no ejecutar tu JavaScript de cliente. Si el precio, el formulario o el texto principal solo aparecen tras la hydration, el agente lee un cascarón vacío.
8. Para el commerce, habla un protocolo. Un checkout estructurado gana a rellenar un formulario frágil. Mira cómo construir un servidor MCP para el lado interfaz-agente.

La capa de commerce se está estandarizando rápido

Si tu producto vende algo, la forma en que un agente compra pasa de adivinar a un estándar. Stripe y OpenAI publicaron el Agentic Commerce Protocol para alimentar Instant Checkout en ChatGPT. Google donó en abril de 2026 su Agent Payments Protocol (AP2) a la FIDO Alliance. Shopify y Google anunciaron en el NRF de enero un Universal Commerce Protocol, y Visa lanzó un on-ramp agnóstico que acepta varios a la vez. La idea compartida es un checkout estructurado y con consentimiento explícito que el agente invoca, en lugar de un agente peleando con un formulario pensado para el ratón. Soportar uno es cómo un agente cierra una venta en tus términos en vez de abandonarla.

La confianza sigue filtrando el último paso. Las encuestas de 2026 sitúan la comodidad de dejar que la IA compare precios en torno al 65%, pero la de dejar que haga el pedido cerca del 14%. La mayoría de los agentes todavía devuelve el clic final a la persona. Está bien. El trabajo es dejar limpios la lectura, la comparación y el traspaso, para que el humano diga que sí con todo ya en el carrito.

Dónde divergen la UI para humanos y la UI para agentes

Casi todo se comparte con la accesibilidad, pero no todo. Los agentes quieren estructura estable, selectores predecibles y una ruta de máquina hacia el mismo resultado al que un humano llega con la vista. No necesitan tu coreografía de scroll, tus estados de hover ni los tiempos de tu modal. La respuesta honesta es un core único, no dos sitios: construye una base accesible, semántica y renderizada en el servidor, y encima pones la experiencia visual. Construir una versión oculta aparte para los bots invita a penalizaciones por cloaking y en semanas se desalinea de la página real. Una sola fuente de verdad, leída por ambos públicos.

El usuario no humano es la persona con lector de pantalla para la que ya deberías haber diseñado, ahora con un presupuesto y un checkout. Los equipos que publican interfaces semánticas, estructuradas y renderizadas en el servidor consiguen dos lectores por el precio de uno. Los equipos que publican interfaces de solo píxeles quedan ignorados por ambos.