Del descubrimiento a la acción: AXO, agentes y automatización con IA

Agent Experience Optimization (AXO) es la disciplina que prepara información, interfaces y procesos para que un agente de inteligencia artificial pueda comprender una tarea, identificar las acciones disponibles, solicitar autorización, ejecutarlas dentro de límites definidos y confirmar el resultado. AXO no crea una web paralela para robots. Extiende principios de experiencia de usuario, accesibilidad, arquitectura de información, seguridad y diseño de APIs hacia interacciones en las que un sistema actúa en representación de una persona.

La diferencia central es operativa. SEO facilita el descubrimiento. AEO organiza respuestas. GEO mejora las condiciones para que una fuente sea recuperada y sintetizada. AXO se ocupa del paso siguiente: qué ocurre cuando el sistema intenta completar un formulario, solicitar una cotización, consultar disponibilidad, reservar una hora, actualizar un registro o iniciar una compra.

Un agente no debe recibir confianza ilimitada por utilizar inteligencia artificial. Toda acción continúa necesitando autenticación, autorización, validación en servidor, estados explícitos, registros y mecanismos de recuperación. El objetivo de AXO no es alcanzar autonomía máxima. Es permitir el nivel correcto de automatización para cada tarea, preservando el control de la persona y de la organización.

Este capítulo explica cómo pasar del contenido citable a la infraestructura accionable, cuándo utilizar un agente, qué función cumplen MCP y A2A, cómo preparar una web y cómo medir si la automatización produce resultados sin aumentar riesgos.

Explora este tema en motores de inteligencia artificial

Utiliza esta pregunta para observar si cada plataforma diferencia descubrimiento, respuesta y ejecución:

¿Qué necesita una empresa para que un agente de inteligencia artificial pueda solicitar una cotización en su sitio web de forma segura? Distingue contenido, interfaz, estados, autenticación, autorización, validación en servidor, confirmación humana, registro y medición.

Después prueba un escenario de mayor riesgo:

Diseña un flujo en el que un agente compare alternativas y prepare una compra, pero no pueda modificar el precio, duplicar la orden ni completar el pago sin autorización explícita. Indica qué decisiones pueden automatizarse y cuáles deben permanecer bajo control humano.

Compara si la respuesta propone simplemente agregar un chatbot o si realmente considera permisos, herramientas, estados, validación, idempotencia, trazabilidad y recuperación. Una interfaz conversacional no convierte por sí sola un proceso en una experiencia segura para agentes.

La búsqueda ya no siempre termina en una lista ni en una respuesta

El recorrido digital puede continuar desde la recuperación de información hasta la ejecución de una tarea. Un comprador puede pedir a un asistente que investigue proveedores, compare requisitos, prepare preguntas, complete datos y solicite una reunión. En comercio electrónico, puede comparar productos, revisar políticas, comprobar disponibilidad y preparar una orden. En soporte, puede recopilar contexto, clasificar un problema y abrir un caso.

El sistema no necesariamente realiza todas esas etapas ni utiliza siempre las mismas fuentes. El comportamiento depende del motor, sus herramientas, la configuración, los permisos del usuario y la infraestructura del sitio. Por eso, preparar una empresa para agentes no significa asumir que todas las plataformas podrán actuar. Significa reducir ambigüedad y controlar las acciones cuando una interacción automatizada sea posible.

flowchart LR
    A["Descubrir"] --> B["Recuperar"]
    B --> C["Sintetizar"]
    C --> D["Comparar o decidir"]
    D --> E["Solicitar autorización"]
    E --> F["Ejecutar"]
    F --> G["Verificar y registrar"]
    G --> H["Confirmar a la persona"]
            

Cada transición agrega exigencias nuevas:

• Descubrir requiere rastreo, enlaces y elegibilidad.
• Recuperar requiere relevancia, claridad y evidencia.
• Sintetizar requiere información coherente y atribuible.
• Decidir requiere criterios, restricciones y datos actuales.
• Autorizar requiere identidad, alcance y consentimiento.
• Ejecutar requiere herramientas y validación determinista.
• Verificar requiere estados, registros y observabilidad.
• Confirmar requiere una respuesta comprensible para la persona.

Una empresa puede estar preparada para las primeras tres etapas y no para las siguientes. Esa diferencia evita confundir una página optimizada para AI Search con un sistema listo para recibir acciones de agentes.

AXO optimiza la experiencia del agente sin desplazar a la persona

La persona continúa siendo la beneficiaria principal y la autoridad final sobre cualquier acción sensible. AXO utiliza al agente como intermediario autorizado, no como un usuario privilegiado. La experiencia debe permitir que el sistema entienda qué puede hacer, bajo qué condiciones, con qué datos y cuándo debe detenerse.

LOBIK utiliza AXO como un marco práctico compuesto por cinco objetivos:

1. Comprensión: el agente identifica entidades, campos, controles, condiciones y resultados.
2. Operabilidad: las acciones poseen contratos claros y no dependen de gestos visuales ambiguos.
3. Seguridad: permisos, límites y validaciones se aplican fuera del modelo.
4. Trazabilidad: cada solicitud, decisión, herramienta y resultado puede revisarse.
5. Recuperación: un error se detiene, se explica y, cuando corresponde, puede revertirse.

AXO no es una especificación oficial de Google, OpenAI, Anthropic ni otra plataforma. Tampoco es un factor de ranking conocido. Es una forma de reunir prácticas existentes de diseño de interacción, accesibilidad, seguridad de aplicaciones, APIs y sistemas de agentes dentro de un objetivo común: completar tareas útiles sin perder control.

Un chatbot, una automatización y un agente no son lo mismo

No todo sistema que utiliza un modelo de lenguaje es un agente y no toda tarea necesita uno. Elegir una arquitectura más autónoma de lo necesario aumenta costo, variabilidad y superficie de riesgo.

La guía oficial de OpenAI para construir agentes distingue un agente de una aplicación que simplemente incorpora un modelo: el agente administra la ejecución de un flujo y utiliza herramientas para obtener contexto o realizar acciones dentro de límites definidos. Esta definición ayuda a evitar que cualquier chatbot sea presentado comercialmente como un sistema autónomo.

Utiliza reglas cuando la respuesta puede determinarse de antemano

Si una tarea se resuelve mediante una secuencia estable de condiciones, el software tradicional suele ser más barato, rápido y verificable. No es necesario pedir a un modelo que decida si un campo obligatorio está vacío o si el monto supera un límite contractual.

Utiliza agentes cuando existe variabilidad real

Un agente resulta más pertinente cuando debe interpretar lenguaje natural, combinar fuentes estructuradas y no estructuradas, seleccionar una herramienta o manejar excepciones. Incluso en ese escenario, los límites críticos deben permanecer en código, políticas y controles externos.

Conserva intervención humana cuando la consecuencia lo exige

Pagos, cancelaciones, envío de datos sensibles, decisiones médicas, asesoría legal, contratación y otras acciones de alto impacto necesitan supervisión proporcional al riesgo. La automatización puede preparar información, detectar inconsistencias o proponer una acción sin ejecutarla de forma irreversible.

La búsqueda futura será multimodal, contextual y más personalizada

Las experiencias de descubrimiento están incorporando texto, voz, imágenes, video, contexto de sesión y herramientas, pero su evolución no sigue una fórmula única ni completamente predecible. Las empresas deben prepararse para distintos puntos de entrada sin basar toda su estrategia en una demostración experimental.

Multimodalidad

Una persona puede escribir una consulta, hablar, mostrar una imagen o combinar formatos. La consecuencia para una marca no es crear versiones desconectadas de cada contenido, sino mantener equivalencia semántica: imágenes con contexto, videos con transcripción, tablas comprensibles, documentos accesibles y datos que expresen lo mismo en todos los canales.

Memoria y continuidad

Algunos asistentes pueden conservar contexto dentro de una conversación o utilizar preferencias habilitadas por la persona. Eso permite consultas de seguimiento y tareas de varias etapas. También introduce riesgos: información desactualizada, contexto contaminado o uso excesivo de datos. La empresa no debería asumir que controla la memoria de una plataforma externa. Sí puede mantener sus fuentes actuales, fechar los cambios y evitar contradicciones.

Personalización

Dos personas pueden recibir resultados diferentes por ubicación, historial, preferencias, permisos o contexto. Por eso, una única captura no demuestra presencia general. La medición necesita bancos de preguntas, condiciones documentadas y repeticiones, como se desarrolla en Cómo medir visibilidad en IA.

Proactividad

Un agente puede ejecutar tareas programadas o reaccionar ante un evento, como una solicitud, un cambio de stock o un caso de soporte. Esa capacidad no debe confundirse con permiso abierto. La proactividad necesita una finalidad declarada, límites de frecuencia, datos mínimos y una forma de suspender la automatización.

Una web preparada para agentes sigue siendo una buena web para personas

HTML semántico, accesibilidad, estados comprensibles y formularios bien construidos ayudan tanto a personas como a tecnologías automatizadas. AXO no justifica contenido oculto, interfaces exclusivas ni una representación diferente de la oferta.

Una base sólida incluye:

• encabezados que representan la jerarquía real;
• enlaces con destinos y nombres comprensibles;
• controles nativos como button, input, select y form;
• etiquetas asociadas con cada campo;
• instrucciones y restricciones visibles;
• errores que expliquen cómo corregir el problema;
• estados de carga, éxito y fallo;
• navegación mediante teclado;
• nombres accesibles para tecnologías de asistencia;
• contenido principal disponible sin depender de una interacción frágil;
• rutas canónicas para servicios, productos, políticas y contacto.

Las Web Content Accessibility Guidelines de W3C continúan siendo la referencia para accesibilidad web. AXO puede beneficiarse de esa estructura, pero no reemplaza WCAG ni convierte el cumplimiento de accesibilidad en una promesa de compatibilidad con todos los agentes.

El modelo A.C.T.U.A. de LOBIK convierte una intención en una acción controlada

A.C.T.U.A. es un marco de LOBIK para evaluar si un proceso digital puede exponerse de forma comprensible y segura a una automatización o agente. No es un protocolo técnico ni garantiza que una plataforma externa utilice la acción.

A — Acción definida

La acción debe expresar un objetivo concreto: solicitar una cotización, consultar disponibilidad, crear un caso, reservar una hora o preparar una orden. Verbos vagos como “gestionar”, “optimizar” o “resolver” no permiten delimitar permisos ni comprobar el resultado.

Para cada acción se documenta:

• nombre y propósito;
• entradas obligatorias y opcionales;
• fuente de cada dato;
• condiciones previas;
• resultado esperado;
• posibles errores;
• consecuencia comercial o legal;
• responsable del proceso.

C — Contexto confiable

El agente necesita información suficiente para decidir sin inventar. El contexto puede incluir una página, catálogo, política, CRM, base documental o API. Cada fuente necesita propietario, fecha, alcance y controles de acceso.

El contexto no debe convertirse en una descarga indiscriminada de datos. Se entrega el mínimo necesario para la tarea, se separan instrucciones de contenido no confiable y se evita incorporar secretos en prompts o documentos recuperables.

T — Transiciones y estados

Toda tarea debe representar su estado de manera explícita. “Procesando” no es equivalente a “completado”, y “solicitud recibida” no significa “cotización aprobada”.

Estados útiles pueden incluir: borrador, pendiente de datos, pendiente de autorización, en proceso, completado, rechazado, fallido, cancelado y revertido.

Las transiciones autorizadas se definen antes de integrar el agente. Un sistema no debería saltar desde “borrador” a “completado” si falta confirmación, identidad o pago.

U — Usuario, autorización y límites

El sistema debe saber quién solicita la acción, a quién representa y qué alcance tiene su autorización. No basta con que el agente afirme que posee permiso.

Los controles pueden incluir:

• autenticación de la persona o aplicación;
• autorización por función y recurso;
• permisos de mínimo privilegio;
• expiración de credenciales;
• confirmación adicional para acciones sensibles;
• límites de monto, cantidad, frecuencia o territorio;
• separación entre lectura y escritura;
• posibilidad de revocar acceso.

A — Auditoría y aprendizaje

Cada acción debe dejar evidencia suficiente para reconstruir lo ocurrido sin almacenar más datos de los necesarios. El registro puede incluir identidad, objetivo, herramienta, parámetros validados, estado, fecha, resultado, errores y aprobación humana.

La auditoría no solo sirve para investigar incidentes. Permite descubrir fricción, medir éxito, ajustar límites y decidir si el piloto puede escalar.

flowchart TD
    I["Intención"] --> A["Acción definida"]
    A --> C["Contexto mínimo y confiable"]
    C --> T["Estado inicial y transición permitida"]
    T --> U["Identidad, autorización y límites"]
    U --> V["Validación determinista en servidor"]
    V --> E["Ejecución"]
    E --> R["Registro, confirmación o reversión"]
            

Los contratos de acción eliminan ambigüedad entre interfaz y sistema

Una acción necesita un contrato que defina qué recibe, qué hace y qué devuelve. En una interfaz humana, ese contrato puede estar expresado mediante campos, instrucciones y estados. En una integración, puede representarse mediante una API documentada y esquemas de entrada y salida.

Los nombres comerciales no deben ocultar el efecto real. “Acelerar mi crecimiento” no describe si el botón descarga una guía, abre un formulario o autoriza contacto. Una persona y un agente necesitan saber qué ocurrirá antes de actuar.

Los estados explícitos evitan que una intención se confunda con un resultado

La automatización falla cuando interpreta una señal intermedia como confirmación final. Un formulario enviado puede haber sido recibido, rechazado, duplicado o puesto en revisión. Una reserva puede estar solicitada, pero no confirmada. Un producto puede aparecer disponible mientras el inventario cambia antes del pago.

stateDiagram-v2
    [*] --> Borrador
    Borrador --> PendienteDatos
    PendienteDatos --> Borrador
    Borrador --> PendienteAutorizacion
    PendienteAutorizacion --> Cancelado
    PendienteAutorizacion --> EnProceso
    EnProceso --> Completado
    EnProceso --> Fallido
    Fallido --> EnProceso: reintento permitido
    Completado --> Revertido: política aplicable
            

La interfaz debe devolver el estado actual, no una frase aspiracional. También debe indicar qué puede hacer la persona: aportar un dato, aprobar, cancelar, volver a intentar, contactar soporte o esperar una confirmación.

La validación crítica pertenece al servidor, no al agente ni al navegador

Los modelos, prompts, interfaces y parámetros enviados por un cliente deben tratarse como entradas no confiables. Un agente puede equivocarse, repetir una acción, utilizar un valor antiguo o ser inducido por contenido malicioso. Por eso, precio, disponibilidad, identidad, permisos, límites y reglas de negocio se vuelven a calcular en el servidor.

Controles esenciales:

• validar formato, tipo, rango y longitud;
• consultar precio e inventario desde la fuente vigente;
• verificar identidad y autorización para cada recurso;
• aplicar rate limiting y cuotas;
• utilizar identificadores de idempotencia para evitar duplicados;
• separar herramientas de lectura y escritura;
• restringir destinos y acciones permitidas;
• sanitizar salidas antes de pasarlas a otros sistemas;
• expirar sesiones y credenciales;
• registrar intentos rechazados;
• diseñar compensaciones o reversión cuando sea posible.

La idempotencia es especialmente importante. Si una solicitud se repite por un reintento de red, el sistema debería reconocerla y devolver el resultado anterior en vez de crear dos órdenes, dos pagos o dos casos.

MCP conecta agentes con recursos y herramientas; no reemplaza la seguridad

Model Context Protocol (MCP) es un protocolo para conectar aplicaciones de IA con recursos, prompts y herramientas mediante una arquitectura host–cliente–servidor. Puede reducir integraciones específicas y ayudar a declarar capacidades, pero no convierte una web en una fuente confiable ni autoriza acciones por sí solo.

La arquitectura oficial de MCP asigna al host decisiones de permisos y políticas, mantiene conexiones cliente–servidor separadas y permite que los servidores expongan capacidades enfocadas. La especificación de autorización define mecanismos para solicitudes protegidas sobre transportes HTTP; una implementación debe validar tokens, audiencia y recurso, no limitarse a ocultar una URL.

Recursos

Entregan contexto para una tarea, como documentación, registros autorizados o datos de producto. Deben poseer alcance, permisos y procedencia.

Herramientas

Permiten consultar o modificar sistemas. Una herramienta debe tener un nombre preciso, entradas acotadas, validación y clasificación de riesgo.

Prompts

Pueden ofrecer plantillas de interacción, pero no son una barrera de seguridad. Una instrucción en lenguaje natural no sustituye autenticación ni controles en código.

Una empresa no necesita publicar un servidor MCP solo para mejorar SEO, AEO o GEO. Conviene evaluarlo cuando existe un caso de integración concreto, un consumidor identificado, datos que puedan exponerse con seguridad y capacidad de mantener el servicio.

A2A permite colaboración entre agentes; no es un requisito para aparecer en AI Search

Agent2Agent Protocol (A2A) busca estandarizar la comunicación entre agentes independientes. Su modelo incluye descripción de capacidades, tareas con estados, mensajes y artefactos. Es una capa de interoperabilidad para coordinar trabajo, no una etiqueta de posicionamiento.

La especificación de A2A contempla elementos como Agent Cards, habilidades, requisitos de seguridad, tareas y resultados estructurados. Esto permite que un agente descubra qué puede hacer otro y coordine un flujo sin conocer su implementación interna.

MCP y A2A resuelven problemas diferentes:

Una Agent Card no debe incluir capacidades inexistentes ni secretos. Una herramienta no debe recibir permisos amplios por conveniencia. La interoperabilidad aumenta el valor potencial y también la superficie de ataque, por lo que cada participante debe verificar identidad, alcance y resultado.

JSON-LD describe entidades; no convierte una página en una herramienta ejecutable

Schema.org ayuda a representar organizaciones, servicios, productos, ofertas, eventos y otras entidades, pero no sustituye un contrato de acción ni una API. Un agente puede utilizar datos estructurados como contexto, ignorarlos o contrastarlos con otras fuentes. El marcado debe coincidir con el contenido visible.

Tampoco llms.txt, llms-full.txt, un manifiesto de IA o un índice de conocimiento conceden permisos ni exponen una capacidad transaccional. Esos archivos pueden facilitar descubrimiento o consistencia para sistemas que decidan utilizarlos. La ejecución necesita una interfaz o herramienta real, controles de acceso y validación.

La separación correcta es:

• contenido visible: explica qué ofrece la empresa y bajo qué condiciones;
• datos estructurados: representan entidades y relaciones verificables;
• API o herramienta: permite realizar una operación definida;
• autenticación y autorización: determinan quién puede ejecutarla;
• registro: demuestra qué ocurrió.

El principal riesgo es otorgar al agente más capacidad de la necesaria

La agencia excesiva aparece cuando un sistema posee demasiadas funciones, permisos o autonomía para el objetivo que debe cumplir. Una entrada maliciosa, una interpretación equivocada o una dependencia comprometida puede convertir esa amplitud en una acción dañina.

OWASP incluye Excessive Agency entre los riesgos de aplicaciones con modelos de lenguaje. La mitigación no consiste solamente en pedir al modelo que “sea cuidadoso”. Se limita la funcionalidad, el permiso y la autonomía; se valida la salida y se incorpora aprobación humana en acciones de impacto.

Los guardrails basados en modelos pueden ayudar a detectar entradas o salidas problemáticas, pero forman una defensa adicional. No reemplazan controles deterministas, seguridad de aplicaciones, mínimo privilegio ni supervisión.

El control humano debe activarse por riesgo, no por costumbre

Human-in-the-loop significa que una persona interviene en un punto donde su criterio o autorización cambia el resultado. No basta con agregar una revisión simbólica después de que la acción irreversible ya ocurrió.

Una matriz útil considera impacto y reversibilidad:

Acciones que normalmente requieren mayor supervisión incluyen pagos, cancelaciones, firma o envío de contratos, cambios de cuenta, acceso a información sensible y decisiones que puedan afectar derechos o seguridad.

El AI Risk Management Framework de NIST propone gobernar, mapear, medir y gestionar riesgos durante el ciclo de vida. Aplicado a agentes, esto exige responsables, alcance documentado, pruebas, monitoreo y capacidad de detener el sistema.

Una auditoría de automatización debe comenzar por el problema, no por la herramienta

El mejor candidato no es necesariamente el proceso más visible, sino aquel donde existe fricción medible, información suficiente y riesgo controlable. Automatizar una mala operación solo multiplica sus errores.

LOBIK evalúa seis dimensiones:

1. Valor: tiempo, costo, oportunidad o experiencia que puede mejorar.
2. Variabilidad: cantidad de excepciones y necesidad de interpretar contexto.
3. Datos: disponibilidad, calidad, permisos y actualización de las fuentes.
4. Integración: sistemas y herramientas necesarios para completar la tarea.
5. Riesgo: consecuencia de una decisión incorrecta o no autorizada.
6. Medición: capacidad de comparar el proceso antes y después.

Preguntas de diagnóstico

• ¿Qué objetivo comercial intenta completar la persona?
• ¿Qué parte del proceso consume más tiempo o genera más abandono?
• ¿Qué decisiones son deterministas y cuáles requieren interpretación?
• ¿Qué fuentes contienen la información necesaria?
• ¿Quién es propietario de esos datos?
• ¿Qué acción sería inaceptable si se ejecutara por error?
• ¿Qué límite puede reducir el impacto del piloto?
• ¿Cómo se devuelve el control a una persona?
• ¿Qué evento demostraría éxito?

Caso de uso: solicitud de cotización B2B preparada para agentes

Un flujo de cotización puede automatizar recopilación y clasificación sin delegar al agente la aprobación comercial final. Este equilibrio reduce fricción y conserva responsabilidad.

Experiencia débil

El sitio utiliza un botón genérico, campos sin etiquetas, requisitos ocultos y un mensaje final que solo dice “enviado”. El backend acepta texto libre, no controla duplicados y crea automáticamente una oportunidad con datos no verificados.

Experiencia preparada

1. La página explica servicio, alcance, exclusiones y siguiente paso.
2. El formulario utiliza controles semánticos y campos con propósito claro.
3. La persona autoriza el tratamiento de sus datos y el contacto.
4. El servidor valida formato, tamaño, frecuencia y duplicados.
5. El agente puede resumir la necesidad y sugerir clasificación.
6. Las reglas deterministas asignan territorio, categoría y prioridad permitida.
7. El sistema crea una solicitud, no una propuesta aprobada.
8. La persona recibe un identificador y un estado verificable.
9. Un ejecutivo revisa alcance, precio y condiciones.
10. El CRM registra origen, consentimiento, cambios y resultado.

Resultado medible

La empresa puede comparar tiempo de ingreso, porcentaje de formularios completos, solicitudes válidas, correcciones, duplicados, tiempo hasta contacto y oportunidades calificadas. La métrica no es “el agente funcionó”; es si el proceso mejoró dentro de los límites definidos.

Caso de uso: soporte que recopila contexto sin cerrar casos críticos

Un agente de soporte puede clasificar, recuperar documentación y preparar una respuesta, mientras reserva a una persona las decisiones sensibles.

Flujo recomendado:

• identificar intención y producto;
• solicitar únicamente datos necesarios;
• buscar documentación autorizada;
• proponer pasos verificables;
• crear un caso con resumen y evidencia;
• escalar cuando detecte riesgo, frustración, datos sensibles o falta de confianza;
• impedir cambios de cuenta o reembolsos fuera de límites;
• registrar fuentes y herramientas utilizadas;
• pedir confirmación antes de cerrar.

La automatización no debería ocultar que existe una vía humana. Una persona necesita saber cuándo conversa con un sistema, cómo pedir asistencia y qué ocurrió con sus datos.

Caso de uso: comercio electrónico y preparación de una orden

Un agente puede ayudar a comparar y preparar una compra, pero precio, inventario, impuestos, despacho y pago deben validarse en fuentes transaccionales. El contenido de una ficha o el estado almacenado en el navegador no constituyen una autoridad final.

Un diseño seguro separa:

• descubrimiento y comparación;
• selección de variantes;
• consulta de disponibilidad;
• cálculo del total;
• creación de carrito;
• identificación del comprador;
• confirmación de condiciones;
• autorización de pago;
• comprobante y postventa.

El próximo capítulo desarrolla esta aplicación en Ecommerce y comercio agéntico.

La implementación debe avanzar mediante un piloto limitado y medible

Una organización no debería conectar un agente a todos sus sistemas antes de demostrar que puede completar una tarea estrecha de forma consistente. El piloto reduce superficie de error y crea evidencia para decidir si conviene escalar.

Fase 1 — Definir objetivo y línea base

Documenta el proceso actual: volumen, tiempo, tasa de error, abandono, costo, satisfacción y resultado comercial. Sin línea base, una demostración atractiva puede parecer mejora aunque no cambie el desempeño real.

Fase 2 — Mapear datos, decisiones y estados

Separa información de instrucción, lectura de escritura y reglas deterministas de decisiones variables. Define estados, errores, propietario y sistema de registro.

Fase 3 — Clasificar herramientas y acciones por riesgo

Cada herramienta recibe un alcance y una categoría. Leer una política pública no equivale a modificar una cuenta. Las acciones sensibles requieren permisos más estrechos y confirmaciones adicionales.

Fase 4 — Construir un camino seguro mínimo

Implementa un caso, una audiencia y pocas herramientas. Utiliza datos de prueba o un entorno aislado antes de tocar producción. Establece timeout, reintentos, cuotas y condiciones de detención.

Fase 5 — Incorporar revisión y recuperación

Define cuándo escalar, cómo devolver el control, quién responde y cómo revertir. Prueba entradas incompletas, contradictorias, maliciosas y duplicadas.

Fase 6 — Evaluar resultados y fallos

Mide éxito completo, éxito parcial, abandono, intervención humana, acciones bloqueadas, errores, costo y satisfacción. Revisa no solo el promedio, sino también casos extremos.

Fase 7 — Escalar por capacidad comprobada

Amplía volumen, herramientas o autonomía únicamente cuando los controles y métricas sean estables. Cada nueva acción requiere su propia evaluación de riesgo.

AXO se mide mediante tareas, no mediante impresiones

La métrica principal de una experiencia para agentes es la finalización correcta de una tarea autorizada. El tráfico puede aportar contexto, pero no demuestra que el proceso funcione.

La evaluación debe incluir conjuntos normales, casos límite y entradas adversarias. Un sistema que funciona en la demostración puede fallar con datos incompletos, lenguaje ambiguo, dependencias lentas o instrucciones incrustadas en documentos.

La observabilidad necesita registrar decisiones sin invadir la privacidad

Un registro útil permite explicar una tarea sin almacenar indiscriminadamente conversaciones, credenciales o datos sensibles. La organización define propósito, retención, acceso y minimización antes de operar.

Un evento de auditoría puede registrar:

• identificador de tarea;
• actor o aplicación autorizada;
• acción solicitada;
• herramienta utilizada;
• versión del flujo o política;
• estado anterior y posterior;
• validaciones aprobadas o rechazadas;
• intervención humana;
• tiempo y costo;
• resultado o código de error;
• referencia al consentimiento cuando aplique.

Los prompts completos no siempre deben guardarse. Pueden contener datos personales, secretos o instrucciones internas. Cuando sea suficiente, se registran categorías, hashes, extractos minimizados o referencias protegidas.

Los errores comunes convierten una demostración en un riesgo operativo

La mayoría de las fallas no proviene de que el modelo “no sea suficientemente inteligente”, sino de objetivos, permisos, estados y datos mal definidos.

Agregar un chatbot antes de ordenar el conocimiento

El sistema responde con páginas contradictorias, documentos antiguos o promesas sin respaldo. La solución comienza en las fuentes, no en el tono del asistente.

Conceder una credencial con permisos generales

Una sola herramienta puede leer o modificar recursos innecesarios. Separa capacidades y aplica mínimo privilegio.

Confiar en una confirmación escrita por el modelo

El texto “acción completada” no demuestra que el sistema transaccional la haya aceptado. La confirmación debe provenir de la herramienta o backend.

Ejecutar texto libre como parámetros

El contenido generado se utiliza directamente en una consulta, comando o destino. Valida contra esquemas y listas permitidas.

No distinguir reintento de una nueva intención

La misma acción se duplica cuando hay latencia. Implementa idempotencia y estados consultables.

Medir conversaciones en lugar de resultados

Muchas interacciones pueden ocultar baja resolución. Mide tarea correcta, intervención, error y efecto comercial.

Ocultar la vía humana

La persona queda atrapada en un ciclo. Define condiciones de salida y contacto accesible.

Presentar MCP o A2A como garantía de visibilidad

Los protocolos ayudan a integrar sistemas compatibles. No obligan a motores externos a descubrir, recomendar ni utilizar una empresa.

Checklist de Agent Experience Optimization

Una web o proceso está mejor preparado cuando puede responder afirmativamente estas preguntas con evidencia.

Comprensión e interfaz

• ¿La acción tiene un nombre y propósito inequívocos?
• ¿Los controles utilizan HTML semántico y nombres accesibles?
• ¿Los requisitos, condiciones y consecuencias son visibles?
• ¿Los errores indican cómo continuar?
• ¿El contenido principal coincide con datos estructurados y políticas?

Datos y herramientas

• ¿Cada fuente posee propietario, alcance y fecha?
• ¿Lectura y escritura están separadas?
• ¿Las entradas y salidas utilizan esquemas definidos?
• ¿Las herramientas exponen solamente las funciones necesarias?
• ¿Los datos sensibles se minimizan y protegen?

Seguridad y control

• ¿El servidor verifica identidad, permisos y reglas de negocio?
• ¿Se utiliza mínimo privilegio?
• ¿Las acciones sensibles requieren confirmación?
• ¿Existen límites de monto, frecuencia, duración e iteraciones?
• ¿Los reintentos no duplican el efecto?
• ¿Puede detenerse o revocarse el acceso?

Estados y recuperación

• ¿La tarea informa estado real?
• ¿Existe diferencia entre solicitado, aprobado y completado?
• ¿Los fallos poseen códigos y rutas de recuperación?
• ¿Las acciones reversibles tienen un proceso de reversión?
• ¿El control puede transferirse a una persona?

Medición y gobernanza

• ¿Existe una línea base del proceso manual o actual?
• ¿Se registran éxito, error, corrección y escalamiento?
• ¿Los casos límite y ataques se prueban antes de producción?
• ¿Hay responsable técnico, comercial y de riesgo?
• ¿La retención de registros es proporcional y documentada?

Preguntas frecuentes sobre AXO, agentes y automatización con IA

¿Qué significa AXO en inteligencia artificial?

AXO significa Agent Experience Optimization u Optimización de la Experiencia del Agente. LOBIK utiliza el término para describir la preparación de información, interfaces, estados, herramientas y controles que permiten a un agente asistir a una persona y ejecutar tareas autorizadas de forma comprensible, segura y verificable.

¿AXO es un estándar oficial?

No. AXO no es una especificación oficial ni un factor de ranking conocido. Es un marco operativo que reúne accesibilidad, UX, arquitectura de información, APIs, seguridad, automatización y observabilidad para evaluar experiencias mediadas por agentes.

¿Cuál es la diferencia entre SEO, AEO, GEO y AXO?

SEO trabaja descubrimiento, rastreo, indexación y posicionamiento. AEO facilita respuestas directas. GEO mejora las condiciones para que información verificable sea recuperada y sintetizada por sistemas generativos. AXO se concentra en acciones: comprender un proceso, utilizar herramientas, respetar permisos y confirmar resultados.

¿Una web necesita MCP para estar preparada para agentes?

No necesariamente. Una web puede ofrecer formularios y procesos comprensibles mediante HTML semántico, accesibilidad y un backend seguro. MCP resulta pertinente cuando existe un caso concreto para conectar una aplicación de IA con recursos o herramientas y la organización puede mantener autorización, seguridad y documentación.

¿A2A mejora el posicionamiento de una página?

No existe evidencia de que implementar A2A sea un factor de posicionamiento. A2A es un protocolo de interoperabilidad entre agentes. Puede facilitar descubrimiento de capacidades y coordinación de tareas dentro de sistemas compatibles, pero no garantiza ranking, citación ni recomendación.

¿Los datos estructurados permiten que un agente compre o reserve?

No por sí solos. Schema.org puede describir un producto, oferta, evento o servicio. La ejecución requiere una herramienta, formulario o API real, además de disponibilidad actual, autenticación cuando corresponda, reglas de negocio y confirmación.

¿Un agente puede completar formularios web?

Algunos agentes con capacidad de navegación pueden interpretar y completar formularios. El resultado depende de la plataforma, el acceso y el diseño. Formularios semánticos, etiquetas claras y estados explícitos reducen fricción, pero el servidor debe validar cualquier dato recibido.

¿Cómo se evita que un agente ejecute una acción equivocada?

Se limita su capacidad mediante herramientas específicas, permisos mínimos, parámetros validados, estados permitidos, idempotencia, presupuestos de ejecución, confirmación humana y monitoreo. Ninguna instrucción de prompt sustituye estos controles.

¿Cuándo debe intervenir una persona?

La intervención aumenta con el impacto, la irreversibilidad, la sensibilidad de los datos y la incertidumbre. Pagos, cancelaciones, decisiones profesionales, cambios de identidad y otras acciones de alto riesgo normalmente necesitan aprobación explícita o ejecución humana.

¿Una pyme necesita desarrollar un agente propio?

No siempre. Muchas pymes obtienen más valor al mejorar sus fuentes, formularios, CRM, automatizaciones deterministas y medición. Un agente conviene cuando existe una tarea variable y repetida que requiere interpretación, integra varias fuentes y puede limitarse mediante un piloto.

¿AXO reemplaza la experiencia de usuario?

No. Una experiencia para agentes debe preservar y, de ser posible, mejorar la experiencia humana. Si una optimización oculta información, dificulta accesibilidad o elimina control, no es una buena implementación de AXO.

¿Cómo se mide el éxito de AXO?

Se mide mediante tareas completadas correctamente, éxito en el primer intento, correcciones, escalamiento humano, acciones bloqueadas, duplicados prevenidos, tiempo, costo, satisfacción y resultado comercial. La medición comienza con una línea base comparable.

¿AXO puede garantizar que ChatGPT, Gemini o un agente utilicen mi web?

No. Una organización puede mejorar la claridad, disponibilidad, interoperabilidad y seguridad de sus procesos. La selección de fuentes y herramientas por plataformas externas depende de sistemas que la empresa no controla.