Cómo entender la IA financiera autónoma a través del recorrido de la orden, y no de la personalidad jurídica

Un agente de IA puede observar precios, interpretar noticias y libros de órdenes, evaluar posiciones, tomar decisiones de compraventa, generar órdenes y enviarlas a una plataforma de negociación. A medida que estos agentes adquieren la capacidad de ejecutar de forma autónoma toda esta secuencia, surge una pregunta evidente: ¿es la IA responsable de las órdenes que emite?

Sin embargo, para las operaciones en los mercados financieros, esa pregunta resulta demasiado abstracta. Lo que llega al mercado no es el proceso mental de una IA, sino una orden que especifica un activo, una dirección de compraventa, un precio, una cantidad, un tipo de orden, un destino y una cuenta de negociación.

La primera cuestión, por tanto, no es si una IA puede asumir responsabilidad. Las primeras preguntas son quién seleccionó el modelo, quién suministró los datos, quién determinó los mercados e instrumentos permitidos, quién fijó los límites de posición y pérdida, quién emitió la clave API y quién autorizó la conexión con el entorno de producción. También debemos preguntar quién supervisa el sistema, quién puede detenerlo y quién puede explicar sus actuaciones posteriormente.

Incluso cuando una IA decide qué orden emitir, la responsabilidad no se transfiere a la IA. Permanece incorporada en el recorrido mediante el cual la orden llega al mercado.

La responsabilidad permanece en el recorrido de la orden

En junio de 2026 no existe un marco regulatorio universal que gobierne todos los usos de la IA en la negociación financiera. En la Unión Europea, la Ley de Inteligencia Artificial impone requisitos relacionados con los registros, la documentación técnica y la supervisión humana para los sistemas de IA de alto riesgo. Sin embargo, ESMA no clasifica actualmente la negociación algorítmica basada en IA como un uso de alto riesgo dentro de ese marco. Esto no excluye la negociación impulsada por IA de las obligaciones ya existentes para la negociación algorítmica.

MiFID II y RTS 6 consideran el desarrollo, las pruebas, el despliegue en producción, los controles previos a la negociación, la supervisión en tiempo real, la cancelación de órdenes abiertas, la gestión de cambios, la conservación de registros y la externalización de algoritmos de negociación como partes de un único sistema operativo. En Estados Unidos, la Regla 15c3-5 de la SEC exige igualmente que las entidades con acceso al mercado mantengan controles de riesgo y procedimientos de supervisión antes del envío de las órdenes. En términos generales, dichos controles deben permanecer bajo el control directo y exclusivo del intermediario financiero que proporciona ese acceso.

Las normas aplicables difieren entre la Unión Europea, Estados Unidos, el Reino Unido y Japón, según el instrumento financiero, el tipo de actividad, la estructura de negociación y la relación con los clientes. Sin embargo, la estructura subyacente de responsabilidad resulta notablemente similar. La responsabilidad no queda confinada al modelo. Se distribuye entre el acceso al mercado, la autorización, los controles previos a la negociación, la supervisión, la facultad de detener el sistema, la conservación de registros, la gestión de cambios y la supervisión de terceros.

Es probable que esta estructura sobreviva a los cambios en modelos concretos de IA y en especificaciones particulares de API. Por muy avanzada que llegue a ser una IA, seguirá necesitando una cuenta, credenciales, una conexión, un formato válido de orden y la aceptación de una plataforma de negociación antes de poder afectar al mercado.

Una orden es una cadena de autoridad, no una decisión aislada

La afirmación «la IA decidió comprar» borra la mayor parte del recorrido real de una orden. Una orden generada por una IA financiera puede atravesar la adquisición de datos, la validación de datos, la generación de variables, la inferencia del modelo, la selección de la operación, el análisis de la posición, la evaluación del riesgo, la generación de una propuesta de orden, los controles previos a la negociación, la aprobación humana, el enrutamiento, la firma mediante API, la transmisión, la aceptación por la plataforma, la ejecución, la ejecución parcial, la gestión de órdenes abiertas, la cancelación, la actualización de posiciones y saldos, la supervisión posterior, la detección de anomalías, la detención del sistema, la conservación de registros y la revisión posterior al evento.

En cada etapa deben separarse cinco preguntas: ¿quién la diseñó?, ¿quién la ejecutó?, ¿quién la supervisó?, ¿quién podía detenerla? y ¿quién podía explicarla posteriormente?

La IA puede realizar la inferencia del modelo, pero la configuración operativa determina los instrumentos permitidos. Un módulo de gestión de posiciones puede calcular el tamaño de la orden, pero un usuario o responsable de riesgos determina el tamaño máximo admisible. El software puede aplicar la firma de la API, pero el administrador de la cuenta emitió la clave API y le concedió permisos de negociación.

La parte que ejecuta una acción no es necesariamente la parte responsable de ella. Una IA ejecuta ciertas partes del recorrido de la orden, pero no es propietaria de todo ese recorrido.

Un sistema puede adquirir datos y ejecutar inferencias mediante servicios externos, utilizar un agente de IA para generar una propuesta de orden, aplicar controles previos mediante un motor de riesgos separado, firmar la solicitud dentro de un servicio de gestión de credenciales y, tras el envío, depender de una plataforma y de un sistema de gestión de órdenes. Dividir la responsabilidad únicamente entre «la IA», «el desarrollador» y «el usuario» no describiría esta realidad operativa.

El recorrido de la orden es tanto un proceso de decisión como una cadena de autoridad. Un error en una etapa todavía puede ser bloqueado por controles posteriores. A la inversa, una decisión correcta del modelo puede transformarse en una orden incorrecta debido a un error de conversión de cantidades, una confusión entre unidades monetarias, un argumento defectuoso de la API o un enrutamiento equivocado.

La responsabilidad de una IA financiera, por tanto, no se adhiere exclusivamente a la decisión de comprar o vender. Permanece distribuida por todo el recorrido que transforma una decisión en una orden y permite que esa orden entre en el mercado.

Descomponer la responsabilidad en unidades operativas

Asignar toda la responsabilidad de una IA financiera a una sola persona o a un único sistema dificulta la identificación de los controles reales. La responsabilidad existe en varios niveles diferenciados.

El modelo constituye una unidad de responsabilidad respecto del rendimiento de las inferencias, los métodos de entrenamiento, la validación y las actualizaciones. El código constituye una unidad de responsabilidad respecto de la implementación, los defectos, las revisiones y el historial de cambios. La estrategia constituye una unidad de responsabilidad respecto de los objetivos de negociación, los mercados admisibles, los periodos de mantenimiento, las pruebas y la supervisión. La orden constituye una unidad de auditoría definida por el instrumento, la dirección, el precio, la cantidad, el destino y la marca temporal.

Una sesión constituye una unidad operativa que agrupa el inicio, la detención, el estado de la configuración y el momento de los incidentes. Una clave API constituye una unidad de autorización que muestra qué facultades se han delegado a una máquina. Una cuenta de negociación constituye la unidad en la que aparecen los saldos, las posiciones, los beneficios, las pérdidas, las liquidaciones y las consecuencias fiscales. Una conexión con una plataforma o un identificador de participante de mercado constituye una unidad de acceso al mercado. Una persona física o jurídica constituye la unidad final que debe responder ante reguladores, plataformas, clientes y usuarios, y que en última instancia absorbe las pérdidas u otras consecuencias.

Para las órdenes generadas por IA, las unidades más importantes suelen ser la orden, la clave API, la cuenta de negociación y la entidad que proporciona o controla el acceso al mercado.

Una inferencia errónea del modelo no introduce por sí sola una orden en el mercado. El código debe convertir la inferencia en una orden. La orden debe superar los controles de riesgo. Una clave API con permisos de negociación debe autorizarla. Una cuenta de negociación y una conexión con la plataforma deben transmitirla.

La capacidad de afectar a un mercado no nace únicamente de la inferencia. Surge cuando el modelo, el código, la configuración, las credenciales, la cuenta y la conexión quedan vinculados.

Por tanto, la responsabilidad no debe plantearse como una elección binaria entre la IA y el ser humano. Debe descomponerse en responsabilidad del modelo, responsabilidad de implementación, responsabilidad de configuración, responsabilidad sobre las credenciales, responsabilidad sobre la cuenta, responsabilidad sobre el acceso al mercado y responsabilidad de supervisión.

«La IA tomó la decisión» no es una explicación de responsabilidad. La responsabilidad solo puede explicarse identificando qué capa controlaba cada decisión y cada facultad a lo largo del recorrido de la orden.

La autonomía es un límite de control, no libertad

Definir la autonomía de la IA únicamente como la capacidad de operar sin intervención humana reúne riesgos muy distintos en una sola categoría.

Una IA que ofrece análisis o asesoramiento no afecta directamente al mercado. Una IA que genera una señal o una propuesta de orden todavía requiere la introducción o aprobación de una persona. Una IA que envía automáticamente órdenes dentro de determinadas condiciones afecta directamente al mercado, pero únicamente dentro de límites predefinidos respecto de instrumentos, tamaño, frecuencia y exposición.

En niveles superiores de autonomía, una IA puede reequilibrar posiciones entre varios mercados, realizar arbitraje, reducir riesgos automáticamente o detenerse cuando detecta una anomalía. Estas funciones todavía pueden entenderse como autonomía de comportamiento dentro de un perímetro operativo previamente establecido.

La naturaleza de la autonomía cambia cuando la IA puede modificar su propia estrategia, modelo, límites de riesgo, fuentes de datos, plataformas de negociación o permisos de API. Ya no se trata únicamente de ejecución autónoma dentro de un rango fijo, sino de la capacidad de ampliar ese rango.

Una IA que emite órdenes dentro de un límite predeterminado no equivale a una IA que modifica ese límite. Lo primero es autonomía de comportamiento. Lo segundo es expansión autónoma de autoridad.

Una mayor autonomía no significa que cada orden individual deba someterse a una aprobación humana adicional. Lo importante es que las personas conserven el control sobre el límite exterior de la autonomía del sistema. Los mercados autorizados, los límites de pérdida, los límites de posición, el apalancamiento, los requisitos de fiabilidad de los datos, las condiciones de parada, las actualizaciones del modelo, el despliegue en producción y los cambios en los permisos de API deben contar con una autoridad claramente asignada.

La autonomía no se define únicamente por aquello que la IA puede hacer. También se define por quién establece el límite que la IA no puede cruzar y quién está autorizado para desplazarlo.

La supervisión humana no debe convertirse en un ritual de aprobación

El hecho de que una persona pulse un botón antes de que se envíe una orden no implica necesariamente que exista una supervisión humana efectiva. Las preguntas importantes son qué entiende esa persona, qué está aprobando y qué puede rechazar.

La aprobación de una orden individual es distinta de la aprobación de una estrategia. La aprobación de una estrategia es distinta de la aprobación de una actualización del modelo, un cambio en los límites de riesgo o el paso a producción. Son decisiones separadas y no deben reducirse a una autorización general para «utilizar IA».

Una supervisión humana efectiva requiere información que el revisor pueda comprender, tiempo suficiente para evaluarla, autoridad para rechazar, modificar o detener la acción y un registro fiable de lo que se revisó y aprobó.

La información puede estar técnicamente visible en una pantalla de aprobación y seguir siendo inútil porque resulte excesiva. Si se espera que una persona autorice cientos de órdenes en cuestión de segundos, una revisión sustantiva resulta imposible.

Un exceso de alertas puede producir una conducta de aprobación automática en la que se acepta todo. Si no hay ningún supervisor disponible durante la noche, los fines de semana o en una crisis de mercado, un sistema nominalmente human-in-the-loop puede funcionar en la práctica como un sistema human-out-of-the-loop. La supervisión también es débil cuando el revisor no posee autoridad directa para detener el sistema y debe contactar con otro departamento antes de intervenir.

La supervisión humana adopta varias formas. En un sistema human-in-the-loop, una persona aprueba la acción antes de que ocurra. En un sistema human-on-the-loop, la IA opera dentro de límites predefinidos mientras una persona la supervisa y conserva la capacidad de intervenir. En un sistema human-out-of-the-loop, las acciones individuales no se revisan normalmente y la seguridad depende de controles previos y de supervisión automatizada.

Existe además el concepto de human-in-command. En lugar de aprobar cada orden, las personas controlan el alcance de la autonomía, los instrumentos admisibles, los límites de riesgo, las condiciones de parada y la autoridad de modificación.

Las órdenes individuales de alta velocidad pueden gestionarse mediante supervisión human-on-the-loop, mientras que los cambios de estrategia, las actualizaciones de modelos, el paso a producción, la incorporación de nuevos instrumentos, las modificaciones de límites de riesgo y la ampliación de permisos de API permanecen como decisiones human-in-the-loop. Esta división preserva mejor una supervisión efectiva que la colocación de una aprobación humana meramente ceremonial en cada orden.

La supervisión humana no es un botón que devuelve la responsabilidad a una persona. Es una estructura de autoridad mediante la cual las personas comprenden, restringen, modifican, rechazan y detienen el comportamiento del sistema.

Los controles previos a la negociación son instrumentos de responsabilidad

Los controles previos a la negociación no están diseñados para rechazar la decisión de una IA simplemente porque proceda de una IA. Su finalidad es definir, con independencia del sistema de inferencia, la frontera entre las órdenes que pueden entrar en el mercado y las que no.

Entre los controles habituales se encuentran el tamaño máximo de la orden, los límites de desviación del precio, los límites de frecuencia, los límites de posición, los límites acumulados de pérdida, los límites de apalancamiento, las restricciones de tamaño basadas en la liquidez del mercado, las prohibiciones durante ampliaciones del diferencial, las restricciones cuando disminuye la fiabilidad de los datos, el rechazo de instrumentos no autorizados, la prevención de órdenes duplicadas, la validación de decimales y unidades y los controles relacionados con sanciones o requisitos regulatorios.

Estos controles deben operar de manera separada respecto del modelo. Aunque el modelo recomiende una compra, la orden debe rechazarse si la cantidad supera el límite permitido. Si un LLM produce un símbolo incorrecto, la orden debe fallar porque el instrumento no figura en la lista autorizada. Si una interrupción de datos se interpreta erróneamente como una perturbación del mercado, el sistema no debe negociar cuando el indicador de calidad de los datos haya descendido por debajo del umbral permitido.

Si la misma orden se invoca dos veces, un identificador de orden o un mecanismo de idempotencia debe impedir el envío duplicado. La orden debe rechazarse si su unidad de cantidad resulta anómala o si incumple el tamaño mínimo o las reglas de precisión de la plataforma.

Los controles previos pueden funcionar incluso cuando el razonamiento interno del modelo no puede comprenderse por completo. Esto los vuelve especialmente importantes al utilizar sistemas de caja negra o modelos de terceros.

Unos controles eficaces pueden limitar los daños causados por una mala decisión de la IA. Sin embargo, no eliminan la responsabilidad de la entidad que controla el acceso al mercado. La ausencia de salvaguardias frente a errores razonablemente previsibles puede constituir por sí misma un problema de responsabilidad operativa.

Los controles previos a la negociación no son mecanismos de inmunidad. Son instrumentos de responsabilidad que muestran qué riesgos se anticiparon, quién definió los límites y qué condiciones se impidió que llegaran al mercado.

La facultad de detener el sistema debe diseñarse expresamente

La detención automática por parte de la IA puede resultar útil, pero el sistema no debe depender exclusivamente de la decisión de la propia IA de detenerse. Una IA defectuosa puede continuar clasificándose a sí misma como operativa. El modelo de negociación y el modelo de supervisión también pueden verse afectados por la misma fuente de datos corrupta.

Si la IA puede modificar sus propias condiciones de parada, el mecanismo de seguridad pasa a formar parte de la autonomía de la IA.

La facultad de detener el sistema debe permanecer, por tanto, en varias capas. La IA puede detenerse automáticamente. El usuario puede desactivar el envío de órdenes. Un operador puede detener una estrategia o una sesión. Un administrador de sistemas puede interrumpir un servicio o una conexión. El personal de riesgos o cumplimiento puede suspender toda la negociación. Un intermediario o proveedor de acceso al mercado puede bloquear la conectividad. Una plataforma puede rechazar órdenes o suspender la cuenta. Un administrador de credenciales puede revocar la clave API.

Cancelar órdenes abiertas, bloquear nuevas órdenes, terminar una conexión, revocar una clave API, suspender una cuenta y detener un modelo son acciones distintas en capas diferentes. La implementación de una de ellas no crea una capacidad integral de detención.

Que un proveedor externalizado o un operador de nube pueda detener el sistema no justifica una estructura en la que la entidad que emite las órdenes no pueda detenerlo de forma independiente. Si la detención depende del consentimiento del proveedor o de esperar la respuesta de un técnico externo, el control operativo se ha transferido de hecho fuera de la organización.

La facultad de detener el sistema es poderosa y también puede utilizarse de forma incorrecta o activarse por error. Toda detención debe quedar registrada. El registro debe identificar quién detuvo qué, en qué momento y sobre qué base. También debe conservar el estado de las órdenes abiertas, las posiciones, los saldos, las comunicaciones, la calidad de los datos y las alertas en el momento de la intervención.

El sistema también debe registrar quién autorizó el reinicio. La responsabilidad no termina cuando el sistema se detiene. Una revisión posterior puede preguntar no solo por qué se detuvo en ese momento, sino también por qué no se detuvo antes.

La explicabilidad significa reconstruir la procedencia de la orden

Los debates sobre explicabilidad de la IA suelen centrarse en los pesos del modelo, la atribución de variables o los mecanismos de atención. Las órdenes financieras requieren algo más amplio.

Un sistema responsable debe poder reconstruir por qué una orden concreta se envió a un mercado determinado, con una cantidad concreta y en un momento determinado.

Para ello es necesario conservar los datos de entrada, el momento de adquisición, los indicadores de calidad, las variables, la versión del modelo, la versión del código, el prompt, el contexto externo, el resultado de la inferencia, la configuración de la estrategia y el estado de las posiciones.

También debe registrarse el recorrido de la orden, incluida la propuesta, la justificación declarada, el resultado de cada control previo, la persona que aprobó la acción cuando proceda, el momento de transmisión, la respuesta de la API, el momento de aceptación por la plataforma, el identificador de la orden, las ejecuciones, las ejecuciones parciales, las cancelaciones, los errores y los cambios resultantes en saldos y posiciones.

También deben registrarse los cambios de gobernanza. El sistema debe conservar quién modificó el modelo, el código, el prompt, las variables, los instrumentos admisibles, los límites de riesgo, los permisos de API o las condiciones de parada, quién aprobó el cambio y cuándo entró en producción.

La existencia de un registro no garantiza que la decisión pueda reconstruirse. Un registro que únicamente indique que se envió una orden de compra no revela qué entradas y configuraciones la produjeron.

La reproducibilidad exige conservar el estado existente en el momento de la decisión. Las noticias pueden editarse posteriormente. Los libros de órdenes cambian constantemente. Las API externas pueden devolver resultados distintos para una misma consulta. Los modelos de terceros pueden actualizarse sin aviso. Un LLM puede no producir la misma salida al recibir dos veces la misma entrada.

Una reproducción estricta puede requerir la conservación del texto contemporáneo de las noticias, la instantánea del libro de órdenes, la respuesta de la API externa, la salida bruta del modelo, el archivo de configuración, las condiciones de aleatoriedad, el historial de conversación y los resultados de las llamadas a herramientas.

Incluso cuando la reejecución exacta sea imposible, el sistema debe mantener una cadena probatoria que muestre qué información entró, qué controles se aplicaron y qué se transmitió finalmente al mercado.

Una explicación en lenguaje natural generada por la IA no puede sustituir esa evidencia. La IA puede producir una explicación retrospectiva que no coincida con el proceso que realmente originó la orden. Puede simplificar en exceso una decisión compleja o inventar razones de apoyo que nunca existieron.

Las explicaciones en lenguaje natural deben funcionar como un índice que ayude a las personas a navegar por los registros subyacentes. La explicación es el índice. Los registros son la evidencia.

Los registros son evidencia de supervisión, no simples datos de desarrollo

Los registros de depuración y los registros de supervisión cumplen funciones distintas. Los registros de depuración ayudan a los desarrolladores a identificar defectos. Los registros de supervisión permiten que operadores, auditores, usuarios, plataformas, reguladores y partes de una disputa determinen qué ocurrió.

Los registros de supervisión requieren integridad probatoria. Necesitan marcas temporales precisas, resistencia a la manipulación, firmas o hashes cuando proceda, controles de acceso, reglas de conservación, referencias a las versiones pertinentes del modelo y del código, vínculos con los identificadores de órdenes y cuentas y mecanismos para detectar registros ausentes.

El propio sistema de registro también debe supervisarse. Una orden puede enviarse correctamente mientras falla el almacenamiento del registro, dejando una actuación real en el mercado sin evidencia interna de supervisión.

Conservarlo todo sin estructura tampoco resuelve el problema. Un volumen excesivo de registros puede hacer imposible localizar la información importante. La conservación de datos de terceros puede implicar restricciones de licencia y redistribución. Los datos de usuarios, los registros de negociación y los historiales de conversación pueden contener información personal o secretos comerciales. Las entradas enviadas a un modelo externo pueden contener información confidencial.

La medida relevante no es, por tanto, el volumen de datos conservados, sino la capacidad de reconstruir una orden individual. La pregunta importante no es cuántos terabytes se almacenaron, sino si puede recuperarse la secuencia completa de entradas, decisiones, controles, aprobaciones, transmisiones, ejecuciones e intervenciones de cualquier orden seleccionada.

Entre los indicadores operativos útiles se encuentran el número de órdenes, el tamaño, la frecuencia, la tasa de rechazo, la tasa de cancelación, la tasa de ejecución, el deslizamiento, la tasa de errores de API, la tasa de aprobación manual, el número de anulaciones humanas, las activaciones de bloqueos duros y blandos, las activaciones del interruptor de emergencia, las actualizaciones del modelo, los cambios de configuración, la tasa de registros ausentes, la tasa de reconstrucción de órdenes y el alcance de los permisos de las claves API.

La explicabilidad no debe medirse por el porcentaje de órdenes acompañadas de un texto generado. Debe medirse por el porcentaje de órdenes respaldadas por un registro verificable y reconstruible.

Los modelos de terceros no eliminan la responsabilidad de la entidad que emite las órdenes

Un sistema financiero de IA puede depender de varios servicios externos y no de un único modelo. Los datos de precios, la clasificación de noticias, el análisis en cadena, la interpretación del lenguaje natural, la detección de anomalías, la evaluación del riesgo y el enrutamiento de órdenes pueden proceder de proveedores diferentes.

El uso de servicios externos divide la responsabilidad, pero no la hace desaparecer.

El proveedor del modelo es responsable de determinados aspectos del modelo o API que suministra, incluidas sus especificaciones, disponibilidad y obligaciones contractuales. El desarrollador de la aplicación es responsable de cómo se valida la salida y de las funciones a las que se conecta. El operador es responsable del caso de uso, los límites impuestos y las anomalías supervisadas. La entidad que controla el acceso al mercado sigue siendo responsable de determinar si esa salida puede convertirse en una orden y enviarse al mercado.

Aunque un modelo externo produzca un resultado incorrecto, es posible que el proveedor no haya decidido conectar ese modelo directamente con la facultad de emitir órdenes ni enviar su salida sin validación.

Los contratos con proveedores externos deben definir las funciones, los requisitos de supervisión, el acceso a pruebas y registros, el acceso a datos, las notificaciones de actualización del modelo, la respuesta a incidentes, la subcontratación, la continuidad del negocio, los derechos de terminación, la devolución de datos y la facultad de detención de emergencia.

Lo más importante es que la entidad que emite las órdenes pueda supervisar, detener y terminar la relación sin depender del consentimiento del proveedor. Si el servicio externo deja de estar disponible, el sistema debe contar con un comportamiento alternativo definido, modos de funcionalidad reducida y una estrategia de salida.

La externalización traslada el procesamiento fuera de la organización. No permite que la organización descarte la responsabilidad, el conocimiento, la capacidad de supervisión ni la facultad de detener el sistema.

Una clave API es autoridad de negociación, no una simple credencial

Una clave API no es únicamente una cadena larga utilizada para autenticarse. Es un mecanismo para delegar a un software una parte de la autoridad de una cuenta.

Una clave de solo lectura, una clave autorizada para negociar activos al contado, una clave autorizada para operar con derivados, una clave con permiso de retirada, una clave restringida a determinadas direcciones IP y una clave limitada a una cuenta o cartera concreta no confieren las mismas facultades.

Los permisos asociados a la clave determinan cuánta autoridad real posee la IA. Configurar una clave API no es, por tanto, una mera tarea de conectividad. Es una concesión de autoridad.

Un sistema que solo analiza precios necesita acceso de lectura. Incluso un sistema de negociación automatizada puede separar generalmente la autoridad de negociación de la autoridad de retirada. Las claves pueden separarse por plataforma, producto, instrumento y cuenta, de modo que un fallo no pueda propagarse a todos los activos. Las restricciones por IP, las fechas de caducidad, la rotación de credenciales, los registros de uso y los procedimientos de revocación hacen más clara la frontera de responsabilidad.

La clave API en bruto no debe exponerse directamente al modelo de inferencia. La IA puede producir una propuesta estructurada de orden. Una pasarela de órdenes separada puede validar el instrumento, la dirección, la cantidad, el precio, los permisos, la existencia de duplicados y los límites de riesgo. Solo una orden que supere esas comprobaciones debe firmarse dentro de un entorno protegido de gestión de credenciales.

Con este diseño, la IA no necesita leer la clave API, llamar a endpoints arbitrarios ni explorar los permisos disponibles en la cuenta.

Entregar a una IA una clave maestra no convierte el sistema en una estructura más autónoma en un sentido útil. Elimina la separación de facultades diseñada por las personas.

La responsabilidad cambia cuando el sistema pasa del entorno de pruebas a producción

El backtesting, la simulación, el paper trading, las pruebas en sandbox, las pruebas limitadas con capital real y la negociación completa en producción no son únicamente distintos niveles de precisión. Se diferencian por su capacidad para generar beneficios, pérdidas y efectos reales sobre el mercado.

El backtesting opera con datos históricos. El paper trading puede observar el mercado actual, pero no introduce órdenes. Un sandbox puede probar formatos de API, firmas y transiciones de estado, pero no puede reproducir completamente la liquidez, la latencia, las ejecuciones parciales, el deslizamiento ni las interrupciones reales de una plataforma.

Las pruebas limitadas con capital real envían órdenes efectivas al mercado. La negociación completa en producción activa todo el conjunto de permisos y límites configurados.

El paso a producción no es, por tanto, un simple despliegue técnico. Es una transferencia de responsabilidad operativa.

El sistema debe registrar quién aprobó el paso a producción, qué resultados de pruebas se revisaron, qué límites de riesgo se aplicaron, qué clave API se activó, qué plataformas e instrumentos se autorizaron, qué condiciones provocarían una detención automática y quién supervisaría el inicio de la operación real.

Un diseño en el que la mera presencia de una clave API de producción en un archivo de configuración active automáticamente la negociación real vuelve ambigua la frontera de responsabilidad. La activación en producción debe tratarse como un acto expreso de aprobación.

Una actualización del modelo puede crear una nueva autoridad de negociación

Actualizar un modelo no consiste únicamente en intentar mejorar su precisión. Una actualización puede modificar la frecuencia de las órdenes, la dirección de las operaciones, el periodo de mantenimiento, los instrumentos admisibles, el tamaño de las posiciones y las reacciones ante el riesgo.

Las actualizaciones manuales, el reentrenamiento, el aprendizaje en línea, los cambios de variables, los cambios de prompt, las modificaciones de versión de modelos externos, los cambios en límites de riesgo, la incorporación de nuevas herramientas de orden y la adición de nuevas plataformas no deben describirse simplemente como «mejoras».

La responsabilidad de una actualización debe dividirse entre quien la creó, quien la validó, quien la aprobó, quien la desplegó, quien supervisó su comportamiento posterior y quien estaba autorizado para revertirla.

Una actualización silenciosa por parte de un proveedor externo de IA no elimina la responsabilidad de supervisión de la entidad que envía las órdenes. Si el modelo externo no puede fijarse en una versión determinada, el sistema debe detectar cambios en la distribución de las salidas, los patrones de órdenes, las tasas de error y las tasas de rechazo. Los cambios significativos deben activar restricciones o la suspensión del envío de órdenes.

«El proveedor cambió el modelo» puede identificar una causa. No completa la asignación de responsabilidad.

Los agentes basados en LLM deben auditarse a través de su uso de herramientas

En un sistema convencional basado en reglas, la relación entre las condiciones y las salidas resulta relativamente clara. Los modelos estadísticos y de aprendizaje automático introducen mayor complejidad, pero la reproducibilidad suele ser posible cuando se fijan el modelo, las entradas, los parámetros y las condiciones de aleatoriedad.

Los agentes basados en LLM dependen de instrucciones en lenguaje natural, historial de conversación, resultados de búsquedas, documentos externos, contexto recuperado, definiciones de herramientas, respuestas de herramientas, parámetros de muestreo y actualizaciones del modelo. También pueden seleccionar entre varias herramientas, construir argumentos, evaluar el resultado devuelto y decidir la siguiente acción.

La respuesta final, por tanto, no constituye un registro de auditoría suficiente para un agente financiero basado en LLM. El sistema debe registrar qué herramienta se seleccionó, qué argumentos se generaron, qué permisos se utilizaron, qué devolvió la API, si se repitió la llamada, si una operación se ejecutó dos veces, cómo se interpretaron los errores y si se omitió o cumplió una condición que exigía confirmación humana.

Una instrucción en lenguaje natural para comprar una cantidad determinada de un activo todavía exige que el sistema determine el instrumento, la moneda de liquidación, el tipo de orden, la condición de precio, la plataforma, la cuenta, el redondeo de la cantidad, las comisiones y el saldo disponible.

El lenguaje natural es ambiguo. Una API de órdenes no puede serlo. Entre ambos, el sistema necesita validación estricta de esquemas, listas de activos autorizados, validación de cantidades y controles de permisos.

La cuestión central no es si debe confiarse en el juicio del LLM. La pregunta de diseño más importante es si la salida de un LLM puede convertirse en una orden firmada sin atravesar una capa independiente de validación.

En una CEX, la responsabilidad se concentra en el acceso al mercado; en DeFi, en las firmas y los permisos

En una plataforma centralizada, una orden se transmite al sistema de gestión de órdenes de la plataforma. Los puntos de control relevantes incluyen la clave API, la cuenta de negociación, el identificador de la orden, la aceptación por la plataforma, la ejecución, la cancelación y el registro contable de la cuenta. La plataforma o el intermediario puede rechazar órdenes, interrumpir la conectividad o suspender la cuenta.

La responsabilidad tiende, por tanto, a concentrarse alrededor de la cuenta y del recorrido de acceso al mercado.

DeFi funciona de otra forma. Un agente de IA interactúa con contratos inteligentes mediante una cartera. Las unidades relevantes de responsabilidad suelen ser la transacción firmada, la autorización de tokens, el límite de gasto y la llamada al contrato inteligente, más que la orden convencional.

El deslizamiento, los costes de gas, los plazos de las transacciones, los oráculos, los puentes, el MEV, las interrupciones de la cadena, las bifurcaciones y la autoridad de actualización pueden afectar al resultado.

Una orden abierta en una plataforma centralizada puede cancelarse con frecuencia. Una vez confirmada una transacción DeFi, revertirla suele resultar difícil o imposible. Por ello, el control anterior a la firma adquiere una importancia especial en DeFi.

Permitir que la IA gestione directamente la clave privada no equivale a utilizar una política de firma humana o independiente que firme únicamente transacciones validadas.

En los mercados centralizados, la cuestión principal es la responsabilidad sobre el acceso al mercado. En DeFi, las cuestiones centrales son la responsabilidad de la firma y la responsabilidad sobre los permisos.

Los fallos deben prevenirse en la capa en la que se originan

Los fallos de la negociación mediante IA no pertenecen a una sola categoría. El sistema puede seleccionar el activo equivocado, invertir la dirección de la operación, calcular mal la cantidad o la posición decimal, utilizar un apalancamiento incorrecto, repetir la misma orden, no cancelar una orden, cancelar de manera excesiva, confundir una interrupción de datos con un movimiento del mercado, reaccionar a una noticia falsa, cambiar de comportamiento tras una actualización, eludir una aprobación humana, superar los límites configurados o no conservar registros.

Estos fallos no deben resumirse como «la IA se equivocó».

Los errores de instrumento y cantidad deben bloquearse mediante esquemas de órdenes y listas de activos autorizados. Las órdenes duplicadas deben evitarse mediante controles de idempotencia e identificadores únicos. Las interrupciones de datos deben abordarse mediante indicadores de calidad y validación entre varias fuentes. El apalancamiento excesivo debe bloquearse mediante controles previos independientes. La elusión de la aprobación debe impedirse mediante separación de permisos y una arquitectura de firma adecuada. Los cambios posteriores a una actualización deben gestionarse mediante pruebas y control de cambios. La ausencia de registros debe prevenirse haciendo que el envío dependa de la generación correcta del evento de auditoría.

Los daños resultantes también van más allá de las pérdidas directas. Pueden incluir comisiones excesivas, liquidaciones, consecuencias fiscales adversas, suspensión de cuentas, infracciones de sanciones, sospechas de manipulación de mercado, pérdidas de clientes, daños a terceros, perjuicio reputacional y disputas prolongadas debido a la imposibilidad de explicar lo ocurrido.

La ausencia de registros no crea la pérdida original. Crea una segunda forma de daño: la incapacidad de determinar la causa de esa pérdida.

Las órdenes pueden parecer manipulativas aunque la IA no tenga intención maliciosa

Los mercados financieros evalúan la conducta observable de las órdenes, no únicamente la intención interna de quien las genera.

Un sistema puede enviar y cancelar grandes cantidades de órdenes en poco tiempo, colocar órdenes en varios niveles de precio, operar repetidamente consigo mismo, introducir órdenes desproporcionadas en un mercado con escasa liquidez, coordinar actividad entre varias cuentas o ejercer una influencia excesiva sobre un oráculo o un fondo de liquidez DeFi.

Estos patrones pueden parecerse al spoofing, el layering, el wash trading, las órdenes sin intención real de ejecución o la manipulación de precios.

Aunque la IA no tenga la intención de manipular el mercado, los sistemas de vigilancia observan órdenes y ejecuciones, no el estado subjetivo de la IA. Por ello, deben supervisarse los patrones de órdenes, las tasas de cancelación, las relaciones entre órdenes y operaciones ejecutadas, las tasas de autooperación, la concentración de órdenes respecto de la liquidez y las correlaciones entre cuentas.

Una conducta rentable no es necesariamente una conducta compatible con las normas.

Un modelo no necesita contener un objetivo explícito de manipulación para aprender un patrón problemático de órdenes mientras persigue beneficios. El riesgo de manipulación debe controlarse mediante el comportamiento observable, no mediante una supuesta intención.

La causalidad distribuida no elimina la responsabilidad en el comportamiento gregario de las IA

Cuando muchos sistemas de IA consumen las mismas noticias, utilizan los mismos proveedores de datos, dependen de modelos similares y operan con límites de riesgo parecidos, aumenta la probabilidad de comportamientos sincronizados.

Pueden vender ante el mismo titular, reducir posiciones cuando aumenta el mismo indicador de volatilidad, detenerse cuando falla el mismo proveedor o iniciar la misma cobertura basándose en un modelo de riesgo compartido.

Cada IA puede actuar racionalmente de forma aislada mientras, en conjunto, eliminan liquidez y amplifican los movimientos de precios. La concentración en modelos y servicios de datos de terceros puede intensificar esta homogeneidad.

Cuando el comportamiento gregario de las IA contribuye al estrés del mercado, puede resultar imposible atribuir todo el evento a un solo participante. Esto no elimina la responsabilidad individual.

Todavía puede preguntarse a cada participante si evaluó la posibilidad de conductas correlacionadas, si dependía en exceso de un único modelo o proveedor, si impuso límites de tamaño vinculados a la liquidez, si consideró el efecto de detenciones simultáneas o si mantuvo diversidad en fuentes de datos, horizontes temporales y condiciones de control.

En el comportamiento gregario de las IA, la responsabilidad no desaparece. La responsabilidad individual permanece mientras la cadena causal general se distribuye.

El uso individual, empresarial y financiero exige distintos niveles de control

Cuando una persona utiliza una IA en su propia cuenta, las pérdidas financieras recaerán principalmente sobre ella. Esto no vuelve innecesaria la gestión de claves API, la prevención de errores, los registros ni las funciones de detención.

Cuando el software se distribuye a terceros, los usuarios pueden configurar sus propias cuentas y claves API. Cuando el sistema se ofrece como servicio de pago, aparecen cuestiones adicionales relacionadas con la información al usuario, el soporte, la gestión de actualizaciones y la protección de los usuarios. A medida que el servicio se aproxima al asesoramiento de inversión, la gestión discrecional, la ejecución de órdenes de clientes o la provisión de acceso al mercado, la responsabilidad supera el ámbito de la propia cuenta del operador.

Una empresa que negocia por cuenta propia necesita una separación de funciones entre desarrollo, operaciones, riesgos, cumplimiento y dirección. Una entidad financiera que utiliza IA para órdenes de clientes o acceso al mercado también debe abordar la protección del cliente, la integridad del mercado y las explicaciones ante los supervisores.

La etiqueta «software de negociación con IA» no determina por sí sola el tratamiento regulatorio. Las preguntas relevantes son de quién son los activos, qué cuenta se utiliza, quién toma la decisión final, quién proporciona el acceso al mercado, si se recibe una remuneración, quién ejerce discreción sobre los activos y quién asume los riesgos.

Lo importante no es únicamente si se utiliza IA, sino qué actividad se realiza, para quién y bajo qué autoridad.

La IA financiera de código abierto debe separar la publicación de la autoridad para emitir órdenes reales

En una IA financiera de código abierto, el editor del código, el modificador, el usuario, el operador, quien entrena el modelo y quien administra la clave API pueden ser personas distintas. Esta separación puede volver ambigua la responsabilidad, pero también puede hacer más explícitas las fronteras si el sistema se diseña adecuadamente.

La distinción esencial se encuentra entre publicar código fuente y proporcionar un sistema operativo capaz de emitir órdenes reales.

El editor del código puede no controlar las claves API, configuraciones, modificaciones o entornos de todos los usuarios. En cambio, un operador que conserva credenciales, envía órdenes a las cuentas de los usuarios y distribuye actualizaciones remotas ocupa una posición operativa distinta de quien únicamente publica código.

Una exención de responsabilidad no crea por sí sola una división técnica de responsabilidades. Las fronteras deben incorporarse en la configuración predeterminada y en las estructuras de permisos.

El envío de órdenes debe estar desactivado por defecto. El paper trading debe constituir el modo operativo predeterminado. La activación en producción debe requerir una acción expresa. Las credenciales de prueba y de producción deben mantenerse separadas. No debe exigirse permiso de retirada. Los usuarios deben configurar sus propios límites de instrumentos, valores, frecuencia y posiciones. Los ejemplos peligrosos no deben convertirse en configuraciones predeterminadas. Deben registrarse las razones de las órdenes, los resultados de los controles, las versiones del modelo y los cambios de configuración. Las versiones oficiales y modificadas deben poder distinguirse.

Cuando los usuarios alteren el código, el modelo o los controles de riesgo, esos cambios deben registrarse. Si pueden identificarse por separado el editor, el modificador, el administrador de la clave API, quien activó la producción y el operador, un sistema de código abierto puede conservar fronteras significativas de responsabilidad.

El código abierto no significa ausencia de responsabilidad. Precisamente porque los actores responsables no están fijados de antemano, el momento en el que un sistema adquiere autoridad para emitir órdenes reales debe quedar especialmente claro.

Dónde devuelve bitBuyer la responsabilidad a las personas

Aunque bitBuyer observe los mercados, aprenda y genere decisiones de negociación, no puede afectar al mercado únicamente mediante inferencias.

Alguien crea la cuenta en la plataforma. Alguien emite la clave API. Alguien concede el permiso de negociación. Alguien define las plataformas, instrumentos, cantidades, frecuencias y límites de posición. Alguien traslada el sistema del paper trading a producción. Alguien autoriza las actualizaciones del modelo. Alguien conserva la facultad de detenerlo.

Estos son los puntos en los que bitBuyer puede definir la estructura de responsabilidad que rodea a sus órdenes.

bitBuyer no necesita devolver cada decisión de negociación a una persona. Necesita separar el juicio de la autoridad.

La IA puede observar el mercado, ejecutar inferencias y generar una propuesta de orden. Una capa independiente de riesgo puede validar el precio, la cantidad, la frecuencia, el saldo, la posición, la fiabilidad de los datos y la admisibilidad del instrumento. Una pasarela de órdenes puede firmar únicamente aquellas que superen la validación. Las claves API pueden gestionarse siguiendo el principio de privilegio mínimo.

La activación en producción, la incorporación de nuevos instrumentos, los cambios en límites de riesgo y las actualizaciones del modelo pueden exigir aprobación expresa. Las órdenes, los rechazos, las cancelaciones, las detenciones y los cambios de configuración pueden conservarse de forma que sea posible reconstruir cada orden posteriormente.

Debe diferenciarse un paquete de distribución con el envío de órdenes desactivado de una instalación en la que el usuario haya introducido sus credenciales y activado expresamente la negociación en producción. Cuando se incorporen servicios externos de IA o datos, el sistema debe registrar qué resultados se utilizaron, para qué finalidad y bajo qué condiciones de control.

Con esta arquitectura, la autonomía de bitBuyer no entra en conflicto con la continuidad de la responsabilidad de usuarios y operadores.

La autonomía no significa que la responsabilidad desaparezca. Significa que la toma de decisiones y la ejecución se delegan dentro de una frontera de responsabilidad definida de antemano.

Diseñar los lugares en los que permanece la responsabilidad

El hecho de que una IA haya generado una orden no explica quién era responsable de ella.

¿Quién seleccionó la IA? ¿Quién proporcionó los datos de mercado? ¿Quién definió el rango permitido de órdenes? ¿Quién diseñó los controles de riesgo? ¿Quién emitió la clave API? ¿Quién autorizó la conexión con producción? ¿Quién supervisó el sistema, lo detuvo, lo reinició y conservó suficientes pruebas para reconstruir la orden?

Si estas preguntas pueden responderse, la estructura de responsabilidad puede sobrevivir incluso cuando los sistemas de IA se vuelvan más capaces. Si no pueden responderse, la existencia de un botón de aprobación humana no crea una responsabilidad efectiva.

Los controles previos a la negociación no son simples funciones de seguridad. Un interruptor de emergencia no es únicamente una función para situaciones críticas. Una clave API no es una simple credencial. Un registro no es un simple dato de desarrollo.

Cada uno de estos elementos conecta las acciones de la IA con las personas, los usuarios, los operadores, las entidades jurídicas y los proveedores de acceso al mercado que conservan autoridad sobre el sistema.

El futuro de las órdenes de mercado generadas por IA no exige atribuir a la propia IA un concepto abstracto de responsabilidad. Exige conservar, fuera de la IA, la autoridad para emitir órdenes, detener el sistema, modificar sus permisos y explicar lo ocurrido.

Incluso cuando una IA decide qué orden emitir, la responsabilidad no se traslada a la IA. Permanece allí donde las personas continúan diseñando, autorizando, supervisando y controlando el recorrido de la orden.

Este artículo examina las fronteras de responsabilidad operativa y las estructuras de gestión de riesgos de los sistemas de órdenes financieras basados en IA. No constituye asesoramiento jurídico ni de inversión, ni una recomendación de ninguna estrategia de negociación, servicio de IA, plataforma de intercambio o proveedor externo en particular.