El presidente de la CFTC, Michael S. Selig, utilizó un foro celebrado el 28 de octubre de 2026 para plantear un problema práctico de las finanzas autónomas: cuando un software identifica oportunidades y ejecuta operaciones por alguien, ¿qué personas o empresas asumen las responsabilidades regulatorias? Sus preguntas abarcaron el registro de desarrolladores, la responsabilidad cuando un agente se comporta de manera indebida y la identificación de la parte a la que representa. Sus declaraciones abrieron un debate normativo; no atribuyeron todas las pérdidas relacionadas con la IA a una parte concreta.
El cambio importante es el permiso para actuar
En sus declaraciones en el Frontier Forum, Selig afirmó que el enfoque debería considerar las funciones desempeñadas, el control ejercido y la realidad económica de una transacción. También indicó que sus opiniones no representaban necesariamente a la Comisión. Su propuesta de pregunta “conoce a tu agente”, o KYA, no era un régimen de identificación anunciado.
Esta distinción es importante porque “trading con IA” describe varios tipos de acuerdos. Un asistente de investigación que lee precios públicos no tiene la misma autoridad que un servicio que selecciona posiciones y envía órdenes sin aprobación individual. Una interfaz de chat puede hacer que esos acuerdos parezcan similares, aunque los permisos subyacentes sean muy diferentes.
| Acuerdo | Lo que puede hacer el software | Qué se debe examinar |
|---|---|---|
| Análisis | Leer y resumir información | Calidad de los datos y límites de acceso |
| Recomendación | Sugerir una orden para su aprobación humana | Quién revisa la propuesta |
| Ejecución delegada | Enviar órdenes dentro de una autorización | Alcance, límites y revocación |
Por lo tanto, la cuestión práctica es qué se permite hacer a un sistema, quién concede esa autoridad y quién puede detenerlo. El nombre o la aparente inteligencia del modelo no responde a ninguna de esas preguntas.
El registro y la compensación son cuestiones diferentes
El registro se refiere a si una actividad incluye a una persona o empresa dentro de una categoría regulatoria. La compensación se refiere a si alguien tiene una reclamación legal por una pérdida y contra quién. Una cuestión de registro no determina por sí misma una reclamación por daños; del mismo modo, una operación con pérdidas no demuestra una conducta indebida.
Consideremos un usuario hipotético que autoriza una orden máxima de 1.000 $, pero un agente envía una de 10.000 $. Una investigación tendría que reconstruir las instrucciones, los límites configurados, los mensajes de la orden y la ejecución. ¿Nunca se implementó el límite, lo modificó un operador, lo eludió un defecto del software o el usuario lo entendió mal? Esas alternativas describen hechos diferentes, no un único evento llamado “fallo de la IA”.
El desarrollador del modelo, el operador de la aplicación, el titular de la cuenta y el proveedor de ejecución pueden ser partes distintas. Habría que examinar las obligaciones pertinentes, las condiciones contractuales, la conducta real y la legislación aplicable. Este es un marco analítico, no una resolución que establezca que todas esas partes comparten responsabilidad o que una de ellas necesariamente debe pagar una compensación.
Esto también explica por qué publicar software general y operar un servicio de trading continuo no deberían tratarse automáticamente como el mismo negocio. El papel real del servicio requiere más atención que su etiqueta de marketing.
Identificar al agente es solo la mitad de la tarea
Un agente puede tener un nombre, una dirección de billetera o un identificador de software sin revelar de quién son los fondos que utiliza o quién autorizó sus acciones. La cuestión de identificación de Selig se refiere a la parte representada, incluidas las situaciones en las que participan varios agentes.
Un registro operativo útil conectaría la cuenta, la autorización y la acción. Si un agente delega una tarea a otro, la cadena debería seguir siendo comprensible: quién estableció el mandato, qué permisos se transmitieron y si el segundo sistema podía ampliarlos. Estas son consideraciones prácticas de diseño; el discurso no estableció un formulario KYA obligatorio ni un estándar técnico universal.
La explicación de KTX sobre Catalyst y la ejecución de agentes de IA explora por qué una instrucción del usuario, la firma delegada y una transacción real son partes distintas de un flujo de trabajo. Conectarlas resulta útil para revisar incidentes incluso antes de que una disputa llegue a un regulador o a un tribunal.
Un registro completo de trading es más informativo que una explicación convincente generada posteriormente. Los mensajes sobre las acciones previstas deberían compararse con las órdenes aceptadas, canceladas y ejecutadas.
Las empresas reguladas existentes siguen teniendo obligaciones
Ya existe un punto de partida distinto para las entidades reguladas por la CFTC. El aviso del personal sobre el uso de la IA de diciembre de 2024 de la agencia recuerda a las entidades registradas y a los registrantes que deben cumplir los requisitos aplicables cuando utilizan IA directamente o a través de proveedores externos. Aborda áreas como la supervisión, las salvaguardas de los sistemas, el mantenimiento de registros y la gestión de riesgos.
El aviso es una declaración del personal sobre requisitos existentes, no una nueva norma vinculante sobre IA. No establece una asignación universal de responsabilidad entre todos los desarrolladores y traders. Por lo tanto, las obligaciones continuas de una institución regulada y el tratamiento aún no resuelto de un nuevo servicio de agentes deben considerarse cuestiones diferentes.
Desde el punto de vista operativo, comprar un modelo no sustituye las decisiones sobre su implementación. Alguien debe definir las acciones aceptables, supervisar si el sistema las cumple y responder a las excepciones. Los registros deberían distinguir entre la instrucción prevista y la acción realmente realizada, en lugar de tratar un resumen generado por IA como el historial completo.
¿Qué cambia para los traders y los desarrolladores de productos?
Antes de delegar la ejecución, hay que entender a qué mercados, cuentas y acciones se puede acceder. Un diseño sensato puede separar la observación del trading, limitar el tamaño de las órdenes y la exposición, y proporcionar un método claro para suspender nuevas actividades. Los controles adecuados dependen del producto; estos ejemplos no constituyen una lista de verificación de cumplimiento de la CFTC.
Los desarrolladores que evalúan integraciones pueden consultar KTX Skills. Su descripción del producto distingue entre los datos públicos de mercado, disponibles sin una clave de API, y las capacidades privadas de trading y de cuenta, que requieren una. Esto convierte el alcance del acceso en una decisión concreta, en lugar de una suposición oculta tras la expresión “asistente de IA”.
La automatización tampoco altera la economía del instrumento subyacente. La guía de futuros perpetuos de KTX explica la financiación y el apalancamiento: un sistema que ejecuta rápidamente también puede acumular costes de financiación o alcanzar umbrales de liquidación. Que el software funcione correctamente no equivale a que la inversión tenga éxito.
Los próximos avances normativos importantes serían propuestas concretas o directrices que aclaren el alcance, la identificación y la responsabilidad. Hasta entonces, la evaluación del producto debería centrarse en una autoridad documentada, un comportamiento observable y una respuesta viable cuando el trading real se desvíe del mandato.
Preguntas frecuentes
¿Una prueba retrospectiva rentable demuestra el cumplimiento legal?
No. El rendimiento histórico de una estrategia no demuestra que el servicio tenga los registros, permisos o acuerdos operativos necesarios para sus actividades.
¿El acceso de solo lectura elimina todos los riesgos?
Limita la autoridad de trading directa, pero los análisis inexactos, el acceso inadecuado a los datos y la confianza equivocada también pueden ser relevantes. Hay que revisar a qué información puede acceder la herramienta.
¿Apagar un agente cancela sus órdenes existentes?
No hay que darlo por hecho. Hay que confirmar por separado el estado de las órdenes y posiciones pendientes. Impedir nuevas instrucciones es diferente de cancelar órdenes aceptadas o cerrar la exposición.
¿Un registro en una cadena de bloques garantiza la recuperación después de un error?
No. Un registro de transacciones puede ayudar a establecer lo ocurrido; la recuperación depende del activo, la transacción, las contrapartes y los recursos legales o técnicos disponibles.
Este artículo explica un debate normativo y no constituye asesoramiento legal ni de inversión. Los sistemas de IA, la ejecución automatizada y los productos apalancados implican riesgos operativos y financieros.