Introducción

Este artículo tiene como objetivo, hacer una introducción a las personas no técnicas a algo que está creciendo de manera exponencial, las economías entre máquinas.

La llamada “economía entre máquinas” o M2M por su nomenclatura en inglés (machine to machine), no es una promesa a futuro ni un eslogan de marketing (aunque un poco sí).

Es una consecuencia directa de la creciente demanda de sistemas automatizados que interactúan entre sí sin intervención humana, software que compra datos, agentes que pagan por cómputo, dispositivos que intercambian energía o ancho de banda y un largo etcétera de crecientes necesidades de estos sistemas.

Y es muy importante asimilar que este crecimiento en la demanda está evidenciando algo que es irrefutable, en un contexto de demanda de insumos para los sistemas automatizados, los supuestos sociales tradicionales dejan de aplicarse. Las máquinas no negocian reglas sociales. Ejecutan protocolos.

Es por eso que en este artículo me voy a centrar en realizar un análisis del concepto Machine to Machine, partiendo de sus bases y centrándolo en la interacción entre Inteligencias artificiales o IAs, sin entrar en el detalle filosófico, de si una IA lo es en realidad o no, daré por entendido que un sistema automatizado que necesita interactuar con otros, de manera desatendida y que es capaz de aprender de esas interacciones, lo es.

Comentaré las exigencias que esta tecnología plantea a los sistemas monetarios y se postulará que Bitcoin, especialmente mediante la red Lightning, emerge como la solución más avanzada frente a la mayoría de las alternativas. Esta posición de liderazgo se debe a su capacidad inherente para minimizar las suposiciones necesarias y ofrecer la máxima previsibilidad a largo plazo.

Desde luego que pueden existir factores que limiten esa posición de liderazgo, como podrían ser los marcos regulatorios, la coacción legislativa y el temor de los Estados, pero dado que esos son factores exógenos a Bitcoin, los obviaré.

Qué es la economía entre máquinas (M2M)

Cuando se habla de M2M o de economías entre IAs, normalmente se hace referencia a interacciones con características muy concretas (estos son solo unos ejemplos):

Pagos muy frecuentes.

Importes muy pequeños (micropagos o incluso nanopagos).

Interacciones completamente automáticas, sin intervención humana.

Necesidad de finalidad clara: la máquina debe saber si ha pagado o cobrado.

Riesgo operativo elevado: no existe la posibilidad de “confiar” ni de escalar un problema a soporte.

Ejemplos realistas:

Un modelo de IA que paga por acceso a datos en tiempo real.

Un agente autónomo que paga por segundos de cómputo.

Dispositivos IoT (Internet de las cosas o Internet of Things) que compran energía, almacenamiento o ancho de banda bajo demanda.

En todos estos casos, el dinero no es un medio social, sino un componente del sistema.

Las tres variables clave en M2M

Estos escenarios ponen el foco en tres variables fundamentales:

Coste por transacción: si el coste supera el valor intercambiado, el sistema es inviable.

Capacidad de automatización: el pago debe ser programático, determinista y sin fricción humana.

Nivel de confianza requerido: cuantas más suposiciones externas (proveedores, identidades, permisos), mayor fragilidad del sistema.

La mayoría de propuestas fallan no por falta de innovación, sino por introducir dependencias sociales, legales o políticas incompatibles con agentes automáticos.

Aquí aparece un punto crítico: en M2M no basta con que el pago sea digital; debe ser nativamente integrable en protocolos, no en plataformas.

Bitcoin on-chain en contextos M2M

Cuando analizamos la economía M2M, es importante distinguir entre la capa base de Bitcoin y sus capas superiores.

La red principal no está diseñada para pagos frecuentes y de bajo valor, sino como sistema de liquidación altamente seguro y resistente a la censura.

Por eso en un entorno M2M, su encaje no es masivo, pero sí estructural.

Fortalezas

Bitcoin on-chain ofrece:

Seguridad máxima respaldada por el consenso distribuido.

Finalidad fuerte tras confirmaciones suficientes.

Independencia de intermediarios: si una transacción cumple las reglas, la red la valida.

Neutralidad absoluta respecto al participante.

Y aquí es donde cobra sentido la idea de que necesitamos un protocolo, no una plataforma.

Un protocolo no distingue entre una empresa, una persona o un agente de software. Solo valida reglas. En el caso de Bitcoin: firmas válidas y cumplimiento del consenso.

Desde el punto de vista de la red, una IA y un usuario humano son indistinguibles. Esta neutralidad elimina fricciones basadas en identidad y permisos que sí existen en sistemas financieros tradicionales.

Limitaciones

Sin embargo, la capa base tiene restricciones claras:

El coste por transacción depende del mercado de comisiones.

La latencia (≈10 minutos por bloque) no es compatible con interacciones en tiempo real.

No está optimizada para micropagos continuos o streaming de valor.

Rol dentro de una arquitectura M2M

Por tanto, Bitcoin on-chain encaja mejor como:

Capa de liquidación final.

Mecanismo de ajuste o reconciliación periódica.

Infraestructura para pagos de mayor valor entre entidades automatizadas.

No es la capa adecuada para micropagos M2M continuos, pero sí el fundamento sólido sobre el que otras capas pueden operar.

Lightning Network y economías M2M

El encaje de LN es muy alto. Probablemente el mejor disponible hoy.

Si la capa base de Bitcoin actúa como sistema de liquidación, Lightning es la capa que hace viable una economía máquina a máquina en tiempo real.

Ofrece:

Pagos casi instantáneos.

Costes extremadamente bajos.

Arquitectura pensada para nodos siempre conectados.

Pagos programáticos sin identidad ni permisos.

Pero lo realmente relevante no es solo la eficiencia. Es el cambio de naturaleza del dinero dentro de la red.

Lightning no funciona como una pasarela de pago integrada en Internet. Funciona como un protocolo más de Internet.

No necesitas abrir una cuenta, no necesitas aceptar términos de un proveedor, no necesitas que una institución valide tu identidad.

Entonces, ¿qué necesitas? Una clave, liquidez y conectividad. Nada más.

Y eso es un cambio profundo.

En el modelo tradicional, el dinero es una capa institucional superpuesta a la red. La comunicación ocurre en Internet; el pago ocurre en bancos, procesadores o plataformas. Son sistemas distintos que se coordinan.

Con Lightning (y, en general, con capas 2 de Bitcoin), el intercambio de valor puede integrarse directamente en el flujo del protocolo. El pago deja de ser un evento externo y se convierte en una operación de red.

Cuando un servidor responde con un 402 Payment Required* y adjunta una invoice Lightning, el pago no es una redirección a un tercero. Es parte del intercambio técnico entre cliente y servidor. La preimagen asociada a la invoice actúa como prueba criptográfica verificable dentro del propio flujo de comunicación.

Aquí ocurre algo relevante: el dinero empieza a comportarse como TCP/IP o como HTTP. No depende de una entidad concreta para funcionar. Depende de reglas compartidas.

Veámoslo con un ejemplo simplificado (SenaaS*)

Sensor ofrece dato sobre tráfico

Responde con HTTP 402 + invoice para cliente.

Cliente paga vía Lightning.

Sensor recibe el preimage asociado al pago.

El preimage actúa como prueba criptográfica del pago.

Sensor da acceso al dato y cliente lo recibe.

Esto no significa que desaparezcan las instituciones. Significa que ya no son condición necesaria para que dos agentes intercambien valor.

Y en un contexto M2M, esta diferencia es estructural. Las máquinas no pueden firmar contratos legales ni negociar términos comerciales. Pero sí pueden seguir reglas criptográficas y ejecutar protocolos.

Lightning convierte el pago en una primitiva técnica: algo que puede invocarse, verificarse y automatizarse igual que cualquier otra operación de red.

La web deja de ser únicamente legible por máquinas.
Puede volverse también liquidable por máquinas.

Cuando el dinero opera como un protocolo, el control económico se desplaza: ya no reside en las instituciones que otorgan permisos, sino en la ejecución de reglas. La economía depende menos de confianza institucional y más de reglas ejecutables.

Un detalle que merece atención es el uso de HTTP 402 (“Payment Required”). Este código lleva décadas definido en el estándar de Internet, pero había quedado prácticamente sin uso real.

Lo que Lightning hace es darle un uso real por primera vez. Por primera vez, un servidor puede responder con un 402 y adjuntar una invoice de manera “natural”, sin salir a sistemas distintos que necesitan coordinación. El cliente paga, obtiene el preimage como prueba criptográfica y continúa la interacción.

Desde el punto de vista del protocolo, el pago deja de ser un proceso externo y pasa a formar parte del propio flujo HTTP. Igual que existe un 404 o un 500, puede existir un 402 ejecutable.

No hay cuentas, no hay API keys, no hay registro humano previo. Solo pago verificable.

Agentes económicos autónomos y custodia programática

Antes de definir con precisión qué es un agente económico soberano, vale la pena preguntarse cómo se implementa eso en la práctica.

Una objeción habitual es pensar que, en última instancia, siempre debe haber una persona supervisando cada movimiento. Que una máquina no puede “tener dinero” sin control humano constante, y técnicamente, no es así.

Una wallet no es una persona. Es una clave privada.
Y una clave privada no es más que información.

Si algo es información, puede ser generado, almacenado y utilizado por un sistema automatizado.

Una máquina puede:

Generar entropía (aleatoriedad) suficiente para crear una semilla segura.

Custodiar esa semilla en un entorno aislado.

Firmar transacciones.

Verificar pagos entrantes.

Aplicar límites internos de gasto.

Nada de esto requiere conciencia. Requiere criptografía y reglas.

Yo creo que aquí es donde la soberanía deja de ser un concepto abstracto y se convierte en arquitectura técnica.

La infraestructura moderna permite separar la custodia de claves de la lógica de negocio.

Se pueden utilizar firmantes remotos, módulos de seguridad o sistemas de permisos de mínimo privilegio.

Así, un agente no tiene acceso ilimitado a fondos, sino capacidad estrictamente delimitada.

Un agente puede estar programado para:

Pagar hasta cierto límite diario.

Interactuar solo con determinados servicios.

Rechazar operaciones fuera de parámetros definidos.

Si el agente falla, el alcance del daño no depende de confianza humana, sino de límites programáticos y criptográficamente definidos.

Eso es soberanía operativa: el control reside en la posesión de claves y en la ejecución de reglas, no en la aprobación de una institución.

Esto no implica conciencia ni ciencia ficción. Implica que el presupuesto y las reglas económicas pueden formar parte del propio diseño del sistema.

En ese contexto, Bitcoin y Lightning no solo permiten pagos entre máquinas. Permiten que las máquinas sean agentes económicos soberanos en sentido estricto: capaces de custodiar valor, asignarlo y liquidarlo bajo reglas matemáticas públicas, heredando además la resistencia a la censura de la capa base de Bitcoin.

No estamos hablando de que sea autonomía desde un punto de vista filosófico. Esto se traduce en autonomía técnica.

Descentralización y censura en M2M

Si aceptamos que una máquina puede custodiar claves y ejecutar reglas económicas, podría aparecer una pregunta: ¿qué ocurre cuando el entorno donde opera no es neutral?

Hoy, la mayoría de arquitecturas para agentes autónomos dependen de:

Proveedores cloud.

Sistemas de identidad gestionados por terceros.

APIs centralizadas.

Permisos que pueden revocarse unilateralmente.

Nada de esto es necesariamente problemático en contextos tradicionales. Pero introduce algo estructural: puntos de veto humanos y políticos.

Un proveedor puede cerrar una cuenta.
Una API puede cambiar sus condiciones.
Un servicio puede decidir que ya no quiere atender ciertas solicitudes.

Para sistemas humanos, eso es gestionable. Para economías máquina a máquina, es un riesgo sistémico.

Bitcoin funciona de otra manera. Es un protocolo abierto con reglas públicas y extraordinariamente estables.

No hay una entidad que decida quién puede participar. La única “censura” posible es la derivada de sus propias reglas de consenso.

Mientras un agente cumpla las reglas criptográficas y pague las comisiones necesarias, puede emitir transacciones y verificar pagos. No necesita permiso adicional.
Para economías M2M esto es crítico. Las máquinas no negocian términos legales ni interpretan cláusulas ambiguas. Necesitan infraestructuras previsibles, con reglas que no cambien arbitrariamente.

Un agente con una wallet no necesita cuenta bancaria, jurisdicción específica ni autorización previa. Solo necesita cumplir reglas matemáticas.

Esa neutralidad reduce al mínimo las suposiciones sociales y políticas del sistema. Cuando las reglas son estables, el poder no reside en quien decide excepciones, sino en quien cumple el protocolo.

Otras capas

Si Lightning representa hoy la solución más alineada con economías M2M en tiempo real, no es la única aproximación que existe sobre Bitcoin.

El objetivo de las soluciones de segunda capa, como Ark (que se encuentra aún en fase de desarrollo) y otras arquitecturas en desarrollo, es abordar un desafío clave: minimizar la complejidad operativa sin comprometer el resultado final que se dirige a la capa base.

En general, este tipo de arquitecturas buscan:

Agrupar múltiples micropagos.

Reducir la necesidad de transacciones on-chain frecuentes.

Simplificar la experiencia de uso.

Mantener un mecanismo claro de salida hacia Bitcoin.

Desde el punto de vista humano, eso es atractivo. Reduce complejidad y mejora usabilidad.

Desde el punto de vista M2M, la evaluación es más matizada.

Algunas de estas propuestas introducen:

Dependencia operativa de coordinadores o agregadores.

Rondas o ventanas temporales que estructuran la liquidez.

Modelos diseñados pensando primero en usuarios humanos.

Eso no las invalida. Pero cambia su encaje.

En entornos M2M puramente reactivos, donde una máquina paga por milisegundo de cómputo o por cada petición API, la latencia estructural o la coordinación externa pueden convertirse en fricción.

En cambio, en economías M2M más “humanizadas”, suscripciones automatizadas, agregación de pagos periódicos, consolidaciones de balances. este tipo de capas podrían encajar mejor.

En mi opinión lo relevante aquí no es elegir un ganador. Es entender que cada capa introduce un equilibrio distinto entre soberanía, eficiencia y complejidad operativa.

Y en economías máquina a máquina, esos equilibrios importan.

Resumen de capas y sus funciones

Después de comentar la capa base, Lightning y otras propuestas adicionales, creo que es conveniente ordenar las piezas para no perdernos.

Como ya comenté, creo que no se trata de decidir cuál es “mejor”. Se trata de entender qué función cumple cada una dentro de una posible economía M2M.

Capa base (Bitcoin)

Función principal: liquidación definitiva y anclaje de reglas.

Máxima resistencia a la censura.

Reglas monetarias públicas y estables.

Finalidad fuerte.

No está pensada para alta frecuencia ni micropagos continuos. Está pensada para que las reglas del sistema no cambien arbitrariamente.

Es el suelo sobre el que se construye todo lo demás.

Lightning Network

Función principal: intercambio de valor en tiempo real.

Pagos instantáneos.

Costes mínimos.

Integración directa en flujos de red.

Lightning permite que el pago se convierta en una operación programable. Es la capa que hace viable la economía M2M reactiva.

Pero su seguridad última sigue anclada en la capa base.

Otras capas

Función principal: optimización de coordinación y simplificación operativa.

Agrupación de pagos.

Reducción de fricción técnica.

Modelos híbridos entre eficiencia y soberanía.

Algunas pueden introducir coordinadores o estructuras temporales. Eso no las invalida, pero sí modifica el equilibrio entre autonomía pura y comodidad operativa.

La clave no es competir, es componer.

En una arquitectura M2M madura, estas capas no compiten entre sí. Se superponen.

La base garantiza reglas estables.

Lightning habilita pagos dinámicos.

Otras capas pueden optimizar casos específicos.

Lo importante no es elegir una sola, sino entender qué problema resuelve cada una y qué concesiones introduce.

En economías máquina a máquina, la arquitectura importa más que la marca de la solución.

Y cuando las reglas fundamentales son estables, las capas superiores pueden innovar sin poner en riesgo el sistema completo.

Por qué la arquitectura importa más que la narrativa

La esencia de la economía máquina a máquina (M2M) reside en la previsibilidad, no en la sofisticación institucional.

Los agentes automáticos se limitan a ejecutar condiciones lógicas, sin capacidad para interpretar matices sociales o negociar excepciones. Por lo tanto, cualquier dependencia externa, ya sea jurídica, política o corporativa, introduce una variable que estos procesos no pueden gestionar.

Mientras que en los sistemas humanos estas variables pueden administrarse, en los entornos automatizados se transforman en incertidumbre estructural.

Esta realidad obliga a que, en las economías M2M, la minimización de supuestos sea prioritaria sobre la expresividad de la normativa.

El valor de Bitcoin no radica en ser inherentemente «más moderno» o eficiente en todo contexto, sino en su capacidad para reducir el sistema económico a un conjunto de elementos estrictamente verificables:

Criptografía.

Reglas transparentes y públicas.

Incentivos con ejecución automática.

Esta simplificación no es una postura ideológica, sino un requisito arquitectónico.

En un ecosistema donde los participantes son procesos automatizados, la arquitectura del sistema es el factor determinante, superando la importancia de cualquier narrativa.

Qué es un Agente Económico Soberano

Ya que hemos usado el término «agente económico soberano» a lo largo del artículo, creo que es el momento de definirlo con algo más de precisión.

A mi entender no todo software autónomo es económicamente soberano. Hay una progresión:

Agente automático: software capaz de ejecutar tareas sin intervención humana directa.

Agente económico: software que puede asignar recursos escasos —dinero— según reglas internas.

Agente económico soberano: software que, además de lo anterior, opera sin depender de permisos externos, identidades otorgadas por terceros o infraestructuras que puedan revocar su capacidad de actuar.

En este marco la soberanía es operativa.

¿Qué implica eso en la práctica?

Un agente económico soberano debe poder custodiar sus propias claves criptográficas, firmar transacciones según reglas definidas, verificar de forma independiente el estado del sistema monetario y ejecutar pagos sin solicitar autorización a ningún intermediario.

Si alguna de esas capacidades depende de un proveedor que puede revocar el acceso, el agente deja de ser soberano. Se convierte en un cliente con API.

La diferencia estructural

En sistemas financieros tradicionales, la existencia económica de un agente depende de una entidad que puede cerrarle el acceso: un banco, una plataforma, un proveedor. Alguien, en algún punto, tiene un botón.

En Bitcoin, esa existencia depende de dos cosas: la posesión de claves privadas y el cumplimiento de reglas públicas de consenso. No hay un registro central que pueda apagar la identidad económica del agente. Mientras tenga conectividad, conserve sus claves y existan nodos validando el protocolo, puede operar.

Por qué esto importa en M2M

En economías máquina a máquina, esta distinción no es filosófica. Es funcional.

Si el presupuesto operativo de un agente depende de credenciales revocables, ese agente no es autónomo. Es un proceso subordinado a la política de un proveedor.

De la arquitectura a la economía

Si todo lo anterior es cierto, y creo que lo es, surge una pregunta inevitable: ¿por qué las máquinas no están ya intercambiando valor de forma autónoma a gran escala? ¿Por qué no vemos economías M2M funcionando de manera generalizada sobre Bitcoin y Lightning?

Es la pregunta correcta. Y hacerla no debilita el argumento, lo completa.

Porque una cosa es que la arquitectura técnica exista y otra muy distinta es que una economía emerja. Las economías no son solo infraestructura. Son coordinación entre actores que tienen que elegir el mismo estándar, incentivos que tienen que alinearse para que el nuevo modelo sea más atractivo que el anterior, entornos que lo estresan, que lo permiten o que lo dificultan, y tiempo: para que se adopte, para que madure, o para que fracase y deje paso a otra cosa.

Ninguna tecnología, por sólida que sea su base, se convierte en economía por sí sola. Internet tardó décadas en generar los modelos de negocio que hoy damos por sentados. Y eso fue con incentivos claros, regulación favorable y usuarios humanos capaces de adaptarse.

Las economías M2M añaden una capa de complejidad adicional: los actores que tienen que coordinarse son, en gran parte, máquinas. Y las máquinas no adoptan estándares. Los adoptan quienes las diseñan, quienes las regulan y quienes deciden invertir en ellas.

¿Por qué Bitcoin no garantiza que surja una economía M2M?

Bitcoin proporciona la infraestructura necesaria para que exista una economía entre máquinas, pero no puede garantizar su aparición. Conviene ser honestos sobre esto.

Para que emerja un mercado M2M significativo, múltiples actores deben decidir utilizar los mismos estándares. Los protocolos habilitan, pero no fuerzan coordinación. Y la coordinación, en última instancia, es un problema humano.

A eso se añade que gestionar nodos Lightning, liquidez y disponibilidad continua requiere ingeniería real. Si las alternativas centralizadas resultan más simples o baratas a corto plazo, muchos optarán por ellas, al menos durante un tiempo.

Como argumentaba al inicio del artículo, el entorno regulatorio también importa. Aunque el protocolo sea neutral, los sistemas donde operan las máquinas no lo son. Restricciones legales o presión sobre infraestructuras pueden condicionar despliegues concretos, independientemente de lo que el protocolo permita.

Y finalmente, no basta con que el pago sea técnicamente posible. Debe ser económicamente racional frente a modelos basados en suscripción, publicidad o crédito. Cambiar eso requiere que los incentivos se alineen, y eso no ocurre solo.

Bitcoin elimina barreras técnicas fundamentales: dependencia de intermediarios, necesidad de identidad, riesgo de censura directa. Pero no puede obligar a que los desarrolladores diseñen sistemas M2M abiertos, ni a que el mercado los adopte.

Es condición habilitante. No causa suficiente.

Mirando hacía el futuro, Bitcoin, M2M y por qué la soberanía técnica importa

Creo que la economía M2M tiene muchas trampas conceptuales y merece un análisis serio, no un futurismo de película, exagerado y barato.

Pero bajo mi forma de ver, esta economía conecta de forma natural con Bitcoin y Lightning porque estos protocolos convierten el pago en una operación de red más: algo que puede invocarse, verificarse y automatizarse sin depender de instituciones, identidades ni permisos, algo que ninguna o casi ninguna otra red puede ofrecer.

Si las máquinas van a intercambiar valor durante décadas, necesitarán reglas estables, neutrales y resistentes a la censura. Bitcoin no garantiza que surja esa economía. Pero sí proporciona la base sobre la que puede existir sin pedir permiso a nadie.

Las herramientas están ahí. Bitcoin lleva años demostrando que la descentralización no es solo una idea. Solo falta la voluntad de conectarlas.

Referencias recomendadas

Para quienes quieran profundizar en los conceptos expuestos, especialmente en la intersección entre IoT, economías máquina a máquina y pagos programáticos sobre Bitcoin, pueden resultar útiles las siguientes lecturas:

When Money Learns to Fly: Towards Sensing as a Service Applications Using Bitcoin
Introduce el modelo de Sensing-as-a-Service (SenaaS), donde sensores y dispositivos IoT pueden monetizar datos en tiempo real utilizando Bitcoin como capa de intercambio de valor.

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments — Lightning Network whitepaper
Documento técnico fundacional que describe cómo Lightning permite pagos rápidos y de bajo coste mediante canales off-chain, manteniendo la seguridad anclada en la capa base de Bitcoin.

An Empirical Study of the Bitcoin Lightning Network: Measurement and Insights
Análisis empírico del comportamiento real de Lightning Network, incluyendo aspectos como disponibilidad, enrutamiento y limitaciones prácticas, aportando una visión más cercana a su uso en producción.

Pay-to-Access: Micropayments for the Web
Explora modelos de micropagos integrados en el propio flujo de acceso a recursos web, anticipando patrones similares al uso del código HTTP 402 (“Payment Required”) como mecanismo de control de acceso.

Aunque el código HTTP 402 lleva décadas definido dentro del estándar web, su uso práctico ha sido limitado hasta la aparición de mecanismos como Lightning Network.
A día de hoy, no existe aún (o no he sido capaz de encontrar) una literatura académica consolidada que explore en profundidad la integración de HTTP 402 con sistemas de pago descentralizados, lo que abre una línea interesante de investigación futura.