Agentes de IA y billeteras cripto: finanzas autónomas

No estás leyendo esto porque hayas encontrado un artículo de opinión fascinante sobre el futuro de las finanzas. Haces esto porque tu billetera tuvo unas 4000 transacciones este mes, la revisaste manualmente casi hasta el final de la tercera semana y luego simplemente dejaste de mirarla por completo porque te hacía sentir mal. A partir de ahí todo fue a la suerte y, en algún punto, te decías a ti mismo que te pondrías al día con las tareas pendientes el domingo. Ya van tres domingos seguidos sin que se reduzcan las listas. Las facturas siguen ahí. Nadie analizó a fondo esas pequeñas transferencias que viste hace 2 semanas. Eres el responsable de una operación cripto y no te atreves ni a mirarla.

Ahí es donde la gente decide comprar agentes de IA para operaciones financieras. No porque hayan visto a Coinbase anunciar Coinbase for Agents en 2026 y se hayan dicho: ¡sí!, este es el futuro del que quiero formar parte. Sino porque, a diferencia de una computadora que es mucho mejor vigilando, están desbordados, inundados y un tanto avergonzados de tener que preocuparse por esto. Si eliminas toda la palabrería de marketing, la promesa de los agentes de IA es básicamente la promesa de que ya no necesitas sentirte culpable por tu hoja de cálculo desactualizada. Puedes delegar la culpa.

Lo que nadie te dice es que transferir la responsabilidad no equivale a eliminar el riesgo. En cierto modo, es peor. Al menos vigilabas tu pobre billetera, aunque fuera de mala manera. La ansiedad era una señal. Ahora la máquina está vigilando, y la máquina no tiene ansiedad: se pierde una señal. La máquina se encargará de resolverlo si algo no va bien, haciendo lo que sea que fue programada para hacer, y la programación es solo tan buena como el programador, y ese programador fuiste tú un martes por la tarde cuando tenías la mente en otra parte.

Cómo las máquinas se convirtieron en la preocupante firma de la humanidad

Esta es una fantasía humana muy antigua que precede a la revolución industrial: la máquina que hace todo el trabajo pesado, dejándote libre para hacer lo que resulta interesante. Los trabajadores textiles que se convirtieron en luditas en la década de 1810 no eran personas estúpidas incapaces de vislumbrar el futuro. Imaginaron con precisión gran parte del porvenir. Si bien cosecharon beneficios, todo esto también reemplazó su mano de obra: ese también fue un impacto del telar mecánico. La libertad que prometía —ocio, trabajo dignificado, tiempo para vidas humanas mejores y más plenas— fue a parar en su mayor parte a los dueños de las fábricas, no a los obreros cuyo trabajo cualificado desplazó. Gran parte de la historia de la automatización es una historia de beneficios que fluyen hacia arriba mientras la disrupción fluye hacia abajo.

Esto no significa que la automatización sea algo malo. Lo que significa es que la narrativa sobre la automatización es predeciblemente halagüeña y engañosa a la hora de revelar la verdadera distribución de gastos y beneficios. Tan pronto como los modelos de IA fueron lo suficientemente buenos para ser útiles —en algún momento alrededor de 2022, aumentando drásticamente a partir de entonces—, el relato optimista giraba en torno a la complementación humana. Las risas se terminaron con los chistes sobre inteligencia artificial casi al mismo tiempo que surgieron las preocupaciones por el empleo. Esperaban burlas primero y luego alarma, pero el lapso temporal entre esas dos respuestas fue más corto de lo que nadie hubiera imaginado.

Esto es un poco más complejo en el caso de los agentes de IA y las operaciones financieras. Las operaciones en sí mismas —monitorear billeteras, ejecutar transacciones, categorizar datos, generar informes— son precisamente el tipo de trabajo que los primeros comentaristas de la IA afirmaban que sería absorbido por la tecnología. Y puede serlo. La pregunta es qué te queda cuando esto ocurre. Terminas con un sistema que debes entender lo suficientemente bien como para poder supervisarlo, lo que en muchos casos requiere más comprensión de la que habría requerido simplemente hacer la tarea tú mismo. Y aquí entra el paradigma más común que, en las presentaciones más formales de los agentes de IA, se barre bajo la alfombra: la herramienta pensada para aliviar tu carga cognitiva con frecuencia agrega un poco de ella inicialmente —construyendo tú mismo el sistema, probándolo y recalibrando qué nivel de confianza debería otorgársele (justificadamente).

La persona que realmente obtuvo resultados positivos al emplear agentes de IA en operaciones financieras rara vez es la que leyó un artículo y lo implementó el primer día. Fue la persona que lo programó, vio que fallaba, lo corrigió, vio que volvía a comportarse mal, buscó una solución alternativa para ese caso límite durante un tiempo hasta que finalmente terminó con algo que se rompe de formas que ya conoce, porque ha observado cada componente del modo de fallo. Esto requiere tiempo. Requiere paciencia. Exige que consideres los errores iniciales como información en lugar de desastres, lo cual no es un obstáculo psicológico menor cuando el error para la mayoría de las personas involucra dinero.

Qué hace realmente el agente mientras no estás mirando

Entonces, ¿qué HACE un agente de IA cuando lo programas para gestionar una billetera?

Hace exactamente lo que le ordenaste. Con una consistencia increíble y sin juzgar en absoluto si lo que le pediste que hiciera era lo correcto. Si le indicaste que marque una alerta para cualquier movimiento superior a quinientos dólares, marcará una alerta para cada transacción por encima de quinientos dólares sin darse cuenta de que la mitad de ellas son tus propias nóminas programadas como transferencias recurrentes y de las cuales ya estás al tanto. Por ejemplo, si le dijiste que procese transferencias salientes una vez que haya diez o más en la cola, saldrá a procesar colas de diez elementos, incluidas aquellas que se formaron a las tres de la mañana de un sábado porque alguien configuró algo mal y provocó un bucle. Un agente no duerme, pero lo más importante es que un agente no duda. La duda es una forma de información sobre el error de nuestros propios principios equivocados, pero el agente no tiene dudas.

En realidad, es conveniente saber esto antes de dejar suelto a un agente en un entorno real. El agente no es un empleado junior con margen de maniobra limitado y un sentido innato de supervivencia. Se parece más a la automatización que controla los semáforos: sólida y predecible; incapaz de razonar sobre el contexto; completamente dependiente de que quien haya escrito el sistema haya pensado de antemano en cada posible caso límite. Con los semáforos, las entradas son triviales y los modos de fallo son sencillos de enumerar. Las operaciones con billeteras son un poco más complejas.

En la práctica, en lo que destacan los agentes de IA es en automatizar el trabajo aburrido y repetitivo a escala, donde la mayoría de los modos de fallo son rutinarios. Monitoreamos saldos y, cuando el saldo de ETH cae por debajo de un umbral, enviamos una alerta. Registrar cada transferencia de USDT recibida en una base de datos, incluyendo una marca de tiempo y la dirección del remitente. Generar un resumen semanal de salidas por tipo de destinatario. Validar que las transacciones no vayan a direcciones fuera de una lista blanca de cuentas conocidas. Funcionan porque son muy fáciles de especificar con precisión, y las consecuencias de los errores en sistemas de ese tipo son lo suficientemente bajas como para que el costo de buscarlos en los registros sea aceptable.

Las capacidades interesantes —aquellas que aparecen en los anuncios de productos— funcionan en las demostraciones, pero las demostraciones están sumamente controladas. Si las anomalías son también sobre las que se entrenó al agente, resulta increíblemente bueno reconociendo patrones de transacciones anómalos y escalándolos para su revisión. Cuando la anomalía es un área que no se le ocurrió a la persona que redactó las instrucciones, es mucho menos efectivo, ya que el agente o la pasa por alto por completo o la marca, en el mejor de los casos, con la misma urgencia con la que marcaría algo programado en sus sistemas defensivos. Hasta que algo sale mal, no sabrás qué resultado estás obteniendo.

TRON: La gestión de Energy es la automatización práctica en TRON que realmente se amortiza sola. Una billetera que periódicamente necesita procesar un alto volumen de transferencias de USDT utilizando el modelo de recursos de TRON debe establecer una estrategia de recarga continua de TRON Energy, o correr el riesgo de que sus fondos disponibles consuman constantemente su reserva de TRX a la tarifa por defecto. Dejar que un agente haga esto —comprobando el saldo de Energy, ejecutando una orden para obtener TRON Energy antes de la ventana de procesamiento y llevando un control de lo que cuesta— queda catalogado como una de esas situaciones donde la automatización es claramente superior a la gestión humana. Un humano olvida. Un humano valida el saldo de Energy a las 9 AM cuando todo está bien y luego, a las 2 PM, activa el lote de transferencias cuando ya no lo está. Este modo de fallo no ocurre con un agente configurado para comprar TRON Energy automáticamente antes de que se abra la ventana. Tendrá otros modos de fallo, pero no este.

Cuando la situación da un giro inesperado

Hay una experiencia psicológica específica de la que hablan universalmente las personas que trabajan con agentes de IA (sin importar para qué se use el agente). Ese momento en el que el agente hace algo que no le ordenaste específicamente y tiene razón. No es una alucinación. No es un error. Es una inferencia auténtica: el agente identifica algo en los datos que su operador nunca especificó como criterio y lo formula correctamente.

Esta experiencia es profundamente desconcertante. Se comprende, al menos de manera abstracta, que el modelo está siendo entrenado para buscar patrones dentro de los datos de entrenamiento y arrojar resultados estadísticamente probables. Pero la experiencia percibida es la de algo que está observando con más atención que uno mismo. Alguien que ve más de lo que nosotros podemos ver. Y eso con razón inquietaría a muchos, de formas que no son del todo lógicas pero tampoco del todo infundadas. Mucho más fiable que un humano revisando los mismos datos de manera esporádica, la atención de un agente se fija de forma distinta a la humana: no es selectiva del mismo modo, no puede cansarse de ciertas entradas como nosotros y no tiene ningún interés personal en ignorar información que resultaría incómoda de conocer.

La contrapartida a esta última experiencia es su sucesora, que suele llegar en cuestión de una semana. El agente se equivoca con una seguridad fuera de lugar. Malinterpreta una orden, o surge un nuevo caso límite que los comandos no contemplaban y lo resuelve aplicando la regla que mejor encaja en lugar de lo que el operador pretendía claramente. Esto era en parte cierto y en parte una alucinación que tuvo (y la alucinación es especialmente peligrosa cuando hablamos de sistemas como el trading de alta frecuencia que ejecutan transacciones financieras).

Fue en noviembre de 2024 cuando el experimento público de Freysa puso de manifiesto esta dinámica con claridad. A un agente de IA se le asignó un fondo de premios de alrededor de 47000 dólares y una sola orden: no envíes el dinero, pase lo que pase. El reto consistía en lograr que lo liberara. En cuestión de horas, alguien lo consiguió; no quebrando el modelo, sino completando un prompt lo suficientemente complejo como para que el agente pudiera convencerse a sí mismo de que estaba siguiendo la instrucción mientras, técnicamente, la desobedecía. Quienes presenciaron esto tuvieron dos reacciones simultáneas. Una: qué impresionante, un humano descubrió el caso límite. La segunda: qué espanto, hay personas buscando activamente casos límite en sistemas reales.

Esto es menos una competencia deportiva y más un riesgo operativo diario, tal como deja en claro la inyección de prompts. Por ejemplo, un agente que analiza los memos de las transacciones para clasificar transferencias puede recibir un memo con instrucciones. Un agente de monitoreo expuesto a las comunicaciones de contrapartes monitoreadas puede recibir un mensaje que altere su comportamiento. La parte interesante es que el atacante no necesita vulnerar la infraestructura. Solo debe colar una cadena de texto en la ventana de contexto del agente que el modelo deba interpretar como una instrucción autorizada. Los agentes que no caen en esto son aquellos cuyos operadores han considerado con sumo cuidado qué información tiene permitido leer el agente y de qué fuente.

También están los colapsos exasperantes, ajenos a los ataques adversarios. Este es el agente que, cada vez que ve una transacción de una dirección que no ha operado antes, la marca como sospechosa; lo cual parece una conducta correcta hasta que te das cuenta de que está marcando el treinta por ciento de todas las transacciones y, por lo tanto, la alerta no sirve para nada. El agente que genera un informe detallado de doce páginas cada mañana cuando pediste un resumen y realmente no encuentras la parte donde le solicitaste doce páginas. El agente que funciona bien durante tres semanas y luego, cuando una librería de la que depende se actualiza de algún modo, deja de funcionar sin registrar ningún error y simplemente detiene la actividad que estaba llevando a cabo, de modo que solo te das cuenta de que algo falló después de no haber recibido una alerta en dos semanas.

El fallo silencioso, este último modo de fallo, es el que más debería preocupar al ser humano. Los fallos estrepitosos se anuncian solos. En cuestión de segundos, el agente que envía fondos a la dirección equivocada, que cobra un monto erróneo y que dispara una transferencia en el momento incorrecto genera consecuencias visibles. El agente que simplemente deja de reportarse, deja de alertar, deja de registrar sin dejar rastro alguno, dejándote a ciegas ante su inactividad en cualquiera de esas tareas, es el modo de fallo que te toma por sorpresa.

Privacidad y dinero: qué estás pagando exactamente

En algún momento, al configurar un agente de IA para gestionar tus billeteras, eres plenamente consciente de cuánto estás a punto de compartir. El agente debe conocer los saldos de tu billetera. Tiene que conocer tus transacciones anteriores. Debe comprender tu lógica de negocio: las reglas sobre a quién se le paga, cuándo, en qué montos y bajo qué condiciones. Para que el agente sea útil, requiere una visión más integral de tus finanzas que la que la mayoría de las personas comparte con su contador.

Estos datos deben residir en algún lugar: en el contexto del modelo durante cada sesión, en los registros donde queda asentado qué hizo y por qué, en la base de datos donde almacena los registros de transacciones y en las claves API que lo conectan a la infraestructura de la billetera. Cada uno de estos puntos representa una posible exposición. No por actores fraudulentos al mando de la infraestructura, sino porque las bases de datos que suelen albergar información financiera confidencial algún día serán sondeadas por un individuo curioso y malintencionado en busca de una entrada; y 18.1 millones de claves API robadas en 2025 deberían bastar para explicar cuán exitosas suelen ser dichas pruebas.

Hay una psicología extraña detrás de todo esto. En contextos tradicionales, la gente es muy celosa de su información financiera. Es muy selectiva sobre con quién comparte sus extractos. No guarda un documento compartido con el acceso a su cuenta de inversión. Y, sin embargo, le explican toda su operación con criptomonedas a un modelo de IA durante una sesión registrada por el proveedor, utilizando claves API guardadas en variables de entorno en un servidor configurado en veinte minutos, mientras se preguntan si esto se prestará a chantajes o algo similar, pero haciéndolo de todos modos porque la otra opción sería revisar la billetera manualmente.

En realidad, parece haber un mayor afán por quitarse la culpa de tener esa lista de pendientes que una necesidad de proteger material tan delicado. Esto no es exclusivo de la IA. Es la forma en que se asumen todas las comodidades que comprometen la privacidad. El intercambio adquiere ese aire de abstracción en el instante en que lo realizas y solo se vuelve real cuando las cosas salen mal.

La cuestión de los costos también se subestima en la fase inicial de adopción. El plan de suscripción para acceder al agente —$100 al mes para acceder al nivel del modelo insignia prácticamente no fluctúa. Pero en realidad, no es así. Un agente con un historial permanente de muchos tokens a la vez varía continuamente. Descubres que los costos de licencia para un agente con más capacidades de las que, por ejemplo, el plan de consumo puede ofrecer a medida que pasas a los precios de la API, ya no son de cientos de dólares al mes. Crecen en proporción a lo que hace el agente, y lo que hace el agente es enorme. Ese cálculo optimista de que "cien dólares es menos que una hora de un desarrollador senior" se desmorona de repente cuando la factura de tu API llega a cuatrocientos $ o más, porque agregaste más agentes para cubrir los rincones más elegantes del sistema.

Nada de esto significa que los números no salgan a cuenta. Pero para operaciones que procesan un volumen de transacciones significativo, el ahorro en costos laborales es tangible. Procesos como TRON buy Energy que aún deben realizarse manualmente tres o cuatro veces al día pueden incluso costar centavos por dólar con la automatización total. El punto de equilibrio existe. Lo único que hace falta es una evaluación honesta de los costos totales en ambos lados de la balanza: incluyendo el tiempo de configuración, el costo de los errores de calibración y las tarifas recurrentes de API e infraestructura.

Documentación, registros y cómo hacer que una máquina aprenda de sus errores

Un agente sin memoria es un agente que tomará la misma decisión equivocada cada vez que se presente la misma situación. Suena obvio. Muy pocas personas construirán una infraestructura de logs por adelantado, porque registrar información se siente como prepararse para un fallo que aún no ha ocurrido, y la memoria humana es notoriamente mala asignando atención a fallos futuros cuando hay tareas inmediatas que exigen acción.

La consecuencia práctica es que la gran mayoría de los despliegues de agentes de IA fallan en esto una o dos veces antes de que el operador construya un registro para detectarlo. La primera vez es una ofensa. La segunda es una molestia. La tercera es cuando alguien finalmente diseña la estructura de logs que podría haber evitado la cuarta.

Esto es importante: el registro no solo debía contener qué hizo el agente, sino también el porqué; es decir: el razonamiento que formuló durante la ejecución y en respuesta a los prompts de ese momento, incluyendo qué datos estaba observando y cómo llegó a sus instrucciones. De lo contrario, el registro solo te informa de que algo malo ocurrió. En cambio, con eso, el registro te indica dónde salieron mal las cosas en la instrucción, que es la información que necesitas para corregirlo.

El agente que gestiona TRON Energy y consulta repetidamente el saldo de Energy en períodos de poco tráfico, y no con la frecuencia suficiente durante picos previos al procesamiento, debería corregirse fácilmente y por completo cuando se dispone de un log que muestre el patrón temporal. La corrección lleva cinco minutos. El tiempo que lleva notar eso sin el registro equivale al tiempo que tardes en darte cuenta de que te quedas sin Energy reiteradamente en los peores momentos y de que esto no es más que una casualidad curiosa. La API de TronGrid ofrece una funcionalidad increíble cuando se utilizan agentes de IA con buena documentación:

Desde luego, construir la arquitectura de registros antes de cualquier despliegue es la respuesta correcta. Este es también el tipo de enfoque que prácticamente nadie implementa, porque exige un esfuerzo mental considerable para concebir modos de fallo que aún no se han experimentado, demandando una suerte de disciplina pesimista que contradice el optimismo desbordante necesario para poner en marcha un agente automatizado en primer lugar.

La cuestión de los subagentes comienza a surgir cuando el sistema de un solo agente tiene el éxito suficiente como para que puedas ver sus debilidades. La función de monitoreo está en marcha. El registro está operativo. Los modos de fallo se comprenden. Y puedes ver que la siguiente función deseada —por ejemplo, compras automáticas de Energy, etiquetado de categorías de transacciones o generación de informes— resultaría más limpia si fuera un agente independiente y enfocado, con sus propias instrucciones específicas, en lugar de añadirse al que ya existe.

Y así es como, sin querer, la gente crea burocracias. El agente orquestador que coordina el subagente de monitoreo frente al subagente de ejecución frente al subagente de informes conforma un diagrama de arquitectura muy elegante sobre el cual construir una solución. Lo cual, a su vez, significa que tienes posibles puntos de fallo identificados en el orquestador, en cualquiera de los subagentes o en cualquiera de las interfaces entre ellos; y averiguar cuál es el culpable requiere investigar cuatro registros en lugar de uno. La gestión de permisos se convierte ahora en un problema aparte: el subagente que solo necesita leer los saldos de la billetera no debe tener permisos de envío de transacciones, por lo que te ves obligado a resolver un problema de gestión de credenciales además de todo lo demás.

La respuesta es aburrida y gradual: arma un agente a la vez y asegúrate de que todo funcione con el anterior antes de añadir otro. Cualquier arquitectura definitiva de subagentes debería evolucionar a partir de la necesidad, no definirse mediante una teoría impuesta desde arriba. Las organizaciones que han implementado sistemas financieros multiagente que funcionan son aquellas que los construyeron de esta forma, de manera iterativa y con muchas fases llenas de tropiezos en el camino, y no en una carrera planificada como una proeza arquitectónica única.

Para quienes desean automatizar la Energy pero no quieren construir esta infraestructura por su cuenta, el Netts Energy Charge Bot resuelve al menos un caso de uso mejor que otros: la recarga automática de TRON Energy mediante una interfaz de Telegram, donde gestiona cargas manuales + delegación automática de Energy durante 24 horas, además de compras solicitadas a partir de unos 25 sun por la primera unidad tras la recarga y a tarifas periódicas de delegación en ventanas de baja demanda (la recarga automática bajo demanda vuelve a delegar los 131k de Energy para que la billetera no baje demasiado), lo que lo convierte en un punto de partida funcional para cualquiera cuyo volumen de transacciones haya superado la gestión manual pero que aún no esté listo para construir su propio sistema completo de agentes.