Skip to content
Home Prices Guides FAQ Journal

¿Qué eSIM puede comprar realmente una IA?

Hay una amplia brecha entre un servicio de eSIM que vende en internet y uno del que un agente de IA puede comprar de verdad — de forma autónoma, de principio a fin, sin que un humano intervenga en el pago. La mayor parte del mercado no pasa la prueba. Aquí está la prueba en sí, aplicada con honestidad, para que puedas ejecutarla tú mismo con cualquier proveedor.

Pregunta "¿tiene este proveedor de eSIM una API?" y obtendrás muchos síes. Pregunta "¿puede un agente de IA completar una compra desde él, por su cuenta, sin un humano en el teclado?" y los síes en su mayoría se evaporan. Las dos preguntas suenan parecidas y no lo son. La primera trata de si el software existe; la segunda trata de si un comprador autónomo puede llegar todo el camino desde "necesito datos" hasta "aquí está tu eSIM funcionando" sin caer en un paso que supone una persona.

Esa segunda pregunta es la que importa si estás construyendo un agente, y rara vez se responde con honestidad porque la respuesta suele ser no. Así que, en lugar de clasificar marcas, esta es una prueba que puedes ejecutar tú mismo. Cinco pasos. Un proveedor tiene que pasar los cinco para que un agente compre de verdad de él; la mayoría pasa uno o dos.

La prueba: ¿puede el agente llegar hasta el final?

Recorre los cinco pasos que exige una compra y pregúntate, en cada uno, si un programa sin navegador y sin ayudante humano puede completarlo.

  1. ¿Puede leer el catálogo sin un navegador? Los precios y la cobertura tienen que estar disponibles como datos — una API pública, un endpoint de catálogo, un llms.txt — no encerrados dentro de un escaparate JavaScript que solo se renderiza para un ojo humano.
  2. ¿Puede empezar sin un registro? Si lo primero que se exige es una cuenta — un correo que confirmar, un flujo de OAuth en el que hacer clic — un agente sin bandeja de entrada y sin navegador se queda atascado antes de empezar.
  3. ¿Puede pagar sin un humano en un formulario de tarjeta? El pago con tarjeta archivada supone una persona tecleando un número en una página ligada a una cookie de sesión. Un agente necesita un raíl que pueda completar de verdad: un saldo que mantiene, una transferencia en stablecoin, un protocolo de pago para agentes — algo que no sea un formulario.
  4. ¿Puede recibir la eSIM como datos, no como un QR enviado por correo a una persona? La entrega tiene que volver a través de la API como un identificador más superficies de activación que el agente pueda usar — una URL de imagen QR, una carga útil en bruto, un enlace de instalación de un toque — no un código enviado por correo a un humano para escanearlo con la cámara de un teléfono.
  5. ¿Se puede confiar en él, no solo es capaz? La capacidad técnica no basta. Sin topes de gasto, alcances e interruptor de apagado, "un agente puede comprar esto" significa en realidad "un agente puede vaciar esto", y nadie debería cablear eso. La autonomía acotada es la diferencia entre una demo y algo que de verdad dejarías correr.

Cómo puntúa realmente el panorama

Una advertencia antes de las categorías: este mercado se mueve rápido, y los proveedores añaden capacidades. Trata lo que sigue como una forma de clasificar, no como un veredicto permanente — y vuelve a ejecutar tú mismo los cinco pasos antes de fiarte de nada de esto.

Mercados de consumo convencionales

Los nombres conocidos — Airalo, Holafly, Nomad, Saily, Ubigi y el resto — están construidos, bueno, para consumidores. El catálogo vive en una app o en un escaparate JavaScript; comprar quiere una cuenta o una tarjeta guardada; la activación es un código QR pensado para la cámara de un teléfono. Varios ofrecen APIs de socios o B2B, pero esas viven detrás de un acuerdo firmado y un proceso de aprobación dirigido a empresas, no a un agente individual cableando algo esta tarde. En la prueba de cinco pasos suelen superar solo parcialmente el paso 1 (una API B2B con puertas no es lo mismo que una pública) y caen en el registro, el formulario de tarjeta y la ausencia de cualquier modelo de gasto para agentes. Son excelentes en aquello para lo que se diseñaron, que es un humano en una página de pago. La comparativa Roamzy vs Airalo recorre uno de ellos a través de la prueba en detalle y es franca sobre dónde aún gana el establecido.

eSIM de privacidad y cripto

Una segunda categoría — Silent Link, Surfroam y servicios similares inclinados a la privacidad — resuelve el paso del pago que hace tropezar a los convencionales, al aceptar cripto, y a veces también afloja el requisito de registro. Eso los acerca de forma significativa en los pasos 2 y 3. Pero siguen siendo, en su mayoría, pagos web orientados a humanos: sin API de agente pública ni servidor MCP para conducir el flujo de forma programática, y sin un modelo de topes de gasto e interruptor de apagado para la autonomía delegada. Más cerca en el raíl, pero aún no construidos para que los conduzca un programa.

El grupo nativo para agentes

Una tercera categoría, mucho más pequeña y más nueva, construye para agentes a propósito — una API pública o un servidor MCP como puerta de entrada, no como ocurrencia tardía. Roamzy está en ella; también esfuerzos tempranos como eSIM.dog y eSIM Copilot. Esta es la única categoría donde pasar los cinco pasos siquiera está sobre la mesa, porque el flujo se diseñó para un comprador no humano desde el principio en lugar de adaptarse sobre una tienda de consumo. También es diminuta y temprana — un puñado de nombres, no un mercado maduro — así que el encuadre honesto es "aquí es donde mirar", no "esto está resuelto".

Ejecutar la prueba sobre Roamzy

Como esta es nuestra publicación, aquí está Roamzy frente a sus propios cinco pasos, incluido dónde es débil. Sin calificar con curva.

  • Leer el catálogo sin un navegador — sí. Una API REST pública con una especificación OpenAPI, un endpoint de catálogo con CORS abierto, un llms-full.txt escrito para motores, y un servidor MCP con doce herramientas disponible tanto como paquete npm como endpoint remoto al que te conectas por URL.
  • Empezar sin un registro — sí. Anónimo primero: el agente llama a un endpoint, obtiene una sesión, y puede tarificar y comprar sin cuenta. La identidad es opcional después. Esta es, con diferencia, la mayor barrera que la mayoría de los proveedores nunca elimina.
  • Pagar sin un formulario de tarjeta — sí, con un asterisco honesto. El pago es en USDT o USDC en la red de tu elección, así que no hay formulario de tarjeta de por medio. El asterisco: un usuario sin monedero cripto está genuinamente peor aquí que en un pago con tarjeta, y los raíles nativos de pago para agentes en cadena que tanto entusiasman a todos no están conectados todavía — eso requiere una tesorería y está aparcado a propósito. Lo que funciona hoy es un enlace de pago que el usuario salda desde cualquier monedero.
  • Recibir como datos — sí. La respuesta del pedido devuelve un número de teléfono más tres superficies de activación: una URL de imagen QR, la carga útil QR en bruto, y un enlace de instalación de un toque, así que funciona tanto si el agente y el teléfono son el mismo dispositivo como si no.
  • Ser de confianza, no solo capaz — sí, y este es el punto. Cada token lleva topes diarios y mensuales, un techo de enfriamiento en los tokens nuevos, una puerta de confirmación de transacción grande, y tres interruptores de apagado independientes; las sesiones anónimas se atan más corto que las nominales. La guía para desarrolladores cubre el modelo.

Dos notas honestas más. La capa de identidad OAuth está construida y publicada, pero por cómo se comportan los conectores hoy en su mayoría queda sin usar — la mayoría de los agentes se conectan de forma anónima, por diseño. Y la categoría nativa para agentes en la que está Roamzy tiene semanas, no años. Lo que Roamzy puede reclamar es la combinación actual más completa de los cinco — inicio anónimo, raíl cripto, facturación por MB sin caducidad, entrega programática, y un modelo de gasto real — no que esté solo en la categoría ni que la categoría esté terminada.

Qué hace que la combinación importe

Cualquiera de estos se puede encontrar en otra parte. El pago en cripto existe en las eSIM de privacidad. Una API más o menos pública existe en el nivel B2B de los mercados. El punto es que un agente tiene que pasar cada paso en un solo flujo continuo — y una cadena se rompe por su eslabón más débil. Un proveedor que clava el pago pero fuerza un registro falla. Uno con una gran API pero un pago solo con tarjeta falla. Uno que pasa los primeros cuatro pero no tiene topes de gasto no debería cablearse en absoluto. La preparación para agentes no es una función que puedas tener en su mayoría; es toda la secuencia o no es nada. Esa restricción de flujo único es la razón por la que el argumento de la conectividad como primera compra de un agente descansa en hacer los cinco, no cuatro.

Ejecútala tú mismo

Las cinco preguntas son cortas a propósito. Apúntalas a cualquier proveedor de eSIM — incluido este — y sabrás en unos minutos si un agente puede comprar de verdad de él: ¿puede leer el catálogo sin un navegador, empezar sin un registro, pagar sin un formulario de tarjeta, recibir la eSIM como datos, y estar acotado por un modelo de seguridad real? La mayor parte del mercado responde no a tres o más. Los que responden sí a los cinco valen tu tiempo de integración. Para ver cómo es un sí de principio a fin, el tutorial de configuración de cinco minutos recorre todo el flujo, y agents.html es la visión general de una página.