El agente de IA Gemini Spark necesita una billetera, no una tarjeta
Google anunció Gemini Spark el 19 de mayo de 2026: un asistente agéntico disponible 24/7 que lee tu Gmail, redacta respuestas, hace reservas y sigue trabajando después de que cierras la laptop. La propuesta es un asistente agéntico siempre activo que se encarga de la mitad aburrida de tu bandeja de entrada mientras duermes.
Enterrado bajo las demos de Gmail hay un problema que nadie en el escenario quiso decir en voz alta. En el momento en que un agente actúa sin que estés presente, todos los supuestos sobre los que se basan los pagos con tarjeta se derrumban. Sin un humano que toque "aprobar". Sin teléfono para recibir el código de 3-D Secure. Sin tarjeta presente, sin titular de tarjeta presente, sin sesión.
Creo que esta es la verdadera historia del lanzamiento de Gemini 3.5, y tiene casi nada que ver con el correo electrónico.
Por qué un asistente agéntico siempre activo no puede usar tu tarjeta
Los rieles de tarjetas asumen que hay una persona. Todo el sistema antifraude, el CVV, el 3-D Secure, el pequeño código SMS, los controles de velocidad, existe para confirmar que hay un humano detrás de la transacción. Spark es lo contrario de eso. Es un proceso en la nube de Google que se despierta a las 3 de la madrugada para reservar de nuevo un vuelo cancelado.
Ejecuta un agente autónomo sobre los rieles de Visa y chocas contra una pared rápidamente:
- Las transacciones sin tarjeta presente desde una IP de centro de datos quedan marcadas o rechazadas.
- Los desafíos de 3-D Secure van a parar a un humano que está durmiendo.
- La responsabilidad por contracargos recae en el comerciante por una compra que ningún humano autorizó.
- No existe una forma limpia de darle a un agente un límite de gasto de $40 que se reinicie diariamente y no pueda vaciarse.
El propio posicionamiento de AI Ultra de Google se apoya en la venta por suscripción precisamente porque los pagos por acción siguen sin resolverse. Pagas una tarifa mensual fija a Google, Google absorbe los costos del agente y nadie tiene que resolver cómo paga el agente a terceros. Eso funciona hasta que el agente necesita comprar algo fuera del jardín amurallado de Google.
El lado de la demanda finalmente apareció
Durante dos años, el grupo de pagos para agentes construyó rieles para un cliente que no existía. Escribí sobre esta brecha en AI Agent Payments: Anvita, x402, and Who Owns the Rail, la tecnología estaba lista, los gastadores autónomos no.
Spark cambia los números. Google está a punto de lanzar decenas de millones de agentes siempre activos que, eventualmente, necesitarán realizar transacciones. Esa es la demanda que los rieles estaban esperando.
El stack que ha surgido es aburrido en el buen sentido:
- x402 revive el dormido código de estado HTTP 402 "Payment Required" para que un servidor pueda cotizar un precio y un agente pueda pagarlo en línea, en stablecoins, en una sola solicitud.
- AWS AgentCore añadió una vía de pagos para que los agentes que corren en la nube de Amazon puedan liquidar sin que un humano apruebe cada cargo.
- Pay.sh y herramientas similares envuelven USDC en Base en algo que un agente puede llamar como cualquier otra API.
El hilo conductor: USDC en Base. Finalidad barata, comisiones por debajo de un centavo y una stablecoin que una tesorería corporativa puede mantener sin que el equipo de cumplimiento presente una orden de restricción.
Por qué USDC en Base, específicamente
Los pagos de agentes son micropagos. Un agente podría pagar $0.003 para consultar una API del clima o $2 para comprar un conjunto de datos. El gas de la red principal de Ethereum eclipsaría el pago en sí. Base liquidó más de $1B en volumen diario de DEX en este ciclo, y sus comisiones están en fracciones de centavo, que es el único régimen de tarifas donde los micropagos a velocidad de máquina tienen sentido.
Las stablecoins importan más que la cadena. Un agente no puede tener un activo volátil; una fluctuación de precio del 4% entre la autorización y la liquidación de un pago es inaceptable. USDC está denominado en dólares, es canjeable y lo emite una entidad regulada. Después de que la reglamentación AML del GENIUS Act incluyó a los emisores de stablecoins en un régimen de supervisión similar al bancario, un CFO puede aprobar la tenencia de USDC de una manera que nunca pudo con un token sin respaldo.
Esa claridad regulatoria es la clave, no el rendimiento. He visto morir acuerdos institucionales exactamente por esta pregunta: "quién es responsable y si el emisor está supervisado".
Lo difícil no son los pagos. Es la autorización
Darle una billetera a un agente es el 20% fácil. El otro 80% es la gobernanza:
- Límites de gasto que se cumplan. Una billetera de agente necesita un tope máximo aplicado en la cadena, no un límite flexible en el código de aplicación que una inyección de prompts pueda sortear.
- Delegación revocable. Autorizas al agente para reordenar los víveres, no para mover tus ahorros. Ese alcance debe ser criptográfico, no una casilla de verificación.
- Auditabilidad. Cada pago de un agente debe ser atribuible a una política establecida por un humano. "La IA decidió" no es una respuesta que un regulador acepte.
Aquí es donde el riesgo de inyección de prompts se vuelve real. Ya hemos visto lo que hace una sola clave filtrada, véase el exploit de Polymarket. Ahora imagina que esa clave está en un agente que lee correos no confiables todo el día y puede gastar dinero. La superficie de ataque es toda la bandeja de entrada.
Qué vigilaría a continuación
Google no pondrá USDC en Spark este año. La primera versión enrutará todo a través de Google Pay y la facturación propia de Google, porque eso es controlable y porque Google prefiere ser dueño del riel que alquilarlo.
Pero el agente que reserva tu vuelo a las 3 de la madrugada eventualmente querrá pagar a un proveedor con el que Google no tiene una relación de facturación. Cuando eso ocurra, el camino más barato será un pago en stablecoin sobre un protocolo abierto, no una integración de tarjeta personalizada por comerciante. El riel que gane será aquel al que un agente pueda llamar sin pedir permiso a un gigante de los pagos.
La billetera viene para el agente. La única pregunta abierta es si será un libro mayor cerrado dentro de Google o uno abierto sobre el que cualquiera pueda construir. Mi apuesta es por lo abierto, por la misma razón que la web le ganó a AOL.