Noticia8 min

Google mueve AP2 a FIDO y suma pagos Human Not Present: por qué eso sí cambia la conversación sobre agentes que compran

Google anunció el 28 de abril de 2026 que donará AP2 a la FIDO Alliance y liberó AP2 v0.2 con soporte para pagos Human Not Present. La señal útil no es marketing de commerce: es empujar identidad, mandato y rendición de cuentas antes de que los agentes compren solos.

Google Pay
Mesa editorial con mandatos de pago, identidad verificable y agentes ejecutando compras autorizadas

Por qué importa

Esta nota se enfoca en la decisión práctica para builders: qué cambia, qué riesgo agrega y cómo aplicarlo sin romper operación.

La mayoría de notas sobre “agentic commerce” se quedan en la parte vistosa: el agente compra boletos, reserva algo o llena un carrito. Lo difícil empieza un paso antes: cómo demuestras que el agente estaba autorizado, qué compró exactamente y quién responde si algo sale mal.

Google movió esa conversación el 28 de abril de 2026 con dos piezas que sí importan. La primera: donar el Agent Payments Protocol (AP2) a la FIDO Alliance. La segunda: publicar AP2 v0.2 con soporte para pagos Human Not Present, es decir, compras que un agente puede ejecutar de forma autónoma a partir de instrucciones preautorizadas.

Eso ya no suena a demo. Suena a infraestructura.

Composición editorial con mandatos firmados, identidad verificable y un flujo de autorización antes del pago

Por qué donar AP2 a FIDO sí cambia el tablero

Google dice explícitamente que mover AP2 a FIDO busca mantenerlo platform-agnostic y community-led. Esa frase importa porque el peor futuro posible para pagos entre agentes sería tener un protocolo atado a un solo vendor, wallet o superficie.

Si AP2 quiere ser serio, necesita al menos tres cosas:

  1. interoperabilidad;
  2. gobierno neutral;
  3. y una forma verificable de capturar intención.

La misma nota añade otra pieza útil: Verifiable Intent, co-desarrollado con Mastercard y también donado a FIDO, para dejar un registro verificable de las acciones autorizadas por el usuario.

Ahí está la mejora real. No es “ahora los agentes compran”. Es cómo dejas evidencia fuerte de que podían comprar eso, en esas condiciones.

El detalle nuevo de v0.2: Human Not Present

La actualización AP2 v0.2 agrega soporte para Human Not Present payments. Google lo ejemplifica con una tarea muy concreta: comprar entradas limitadas apenas salgan a la venta según instrucciones ya autorizadas por el usuario.

Ese cambió importa porque mueve el modelo mental:

  • antes pensabas en un agente que asiste una compra;
  • ahora piensas en un agente que ejecuta una compra cuando la condición se cumple.

Eso exige mucha más disciplina sobre mandatos, límites y revocación. Y justo por eso AP2 gira alrededor de evidencia y no solo de API calls.

Escena editorial con un agente ejecutando una compra programada bajo reglas preautorizadas y registro verificable

Dónde sí le veo valor para builders

1. Flujos delegados que hoy viven en automatizaciones frágiles

Si alguna vez intentaste armar compras, renovaciones o procurement con bots caseros, sabes el problema: el bot actúa, pero luego cuesta demostrar con precisión qué estaba autorizado a hacer. AP2 apunta justo a ese hueco.

2. Agentes que necesitan pagar sin meter una persona en cada clic

No todos los casos requieren autonomía de pago, pero cuando sí la requieren, el costo de no tener un protocolo claro es alto. Terminas improvisando con tokens, aprobaciones parciales y auditoría débil.

3. Ecosistemas multiagente donde una compra es solo un paso más

AP2 no intenta ser el agente entero. Intenta ser la pieza que vuelve defendible la parte del pago dentro de flujos mayores con A2A, MCP y servicios externos.

Lo que no deberías comprar sin cuestionar

No asumiría que AP2 ya resuelve por sí solo:

  • fraude;
  • abuso de permisos;
  • prompt injection;
  • ni errores de contexto previos al pago.

De hecho, cuanto más autónomo se vuelve el agente, más importante es separar:

  1. la intención original del usuario;
  2. el mandato firmado;
  3. el carrito o payload final;
  4. y la evidencia del pago ejecutado.

Si uno de esos pasos queda opaco, el protocolo sirve menos de lo que promete.

Por qué esta nota tiene intención de búsqueda real

Aquí las búsquedas valiosas no son genéricas. Son más bien:

  • ap2 payments
  • agent payments protocol
  • human not present payments ai agents
  • fido ap2

La señal de demanda no depende de inventar volumen. Está en:

  • la publicación oficial de Google;
  • el repositorio público google-agentic-commerce/AP2;
  • y la conversación creciente alrededor de machine payments, agent commerce y protocolos verificables.

Mi lectura

Para mí, el movimiento importante no es que Google “siga apostando por agentic commerce”. El movimiento importante es que está intentando sacar la discusión del terreno de demos y llevarla a identidad, mandato, evidencia y estándares abiertos.

Si tu equipo jamás va a dejar que un agente compre algo, esta noticia te puede parecer lejana. Si sí vas hacia compras, procurement o acciones financieras autónomas, conviene prestarle atención desde ya. Y si todavía estás en la fase previa de herramientas, permisos y supervisión, primero ordena la base con el curso gratis y luego compara este problema con algo más cercano como Stripe y machine payments para agentes.

La conclusión corta es esta: AP2 no importa por la demo de compra autónoma; importa porque empieza a tratar los pagos de agentes como un problema de autorización verificable y gobernanza abierta.