Почему AI-агенту нельзя сразу доверять торговые ордера

TL;DR: ИИ может собрать данные, предложить сценарий и подготовить заявку, но право самостоятельно нажать Buy или Sell превращает обычную ошибку модели в реальный финансовый убыток. Мой безопасный вариант — разделить анализ и исполнение: AI формирует строго структурированное предложение, код проверяет лимиты, человек подтверждает конкретный ордер, а отдельный модуль отправляет его брокеру или бирже.

Ключевые факты

Факт	Что это значит для трейдера	Источник
NIST рекомендует заранее определять, оценивать и документировать процессы человеческого надзора за AI-системой.	Кнопка подтверждения — не декоративная формальность: нужно определить, кто, что и на основании каких данных проверяет.	NIST AI RMF Core, MAP 3.5
OWASP называет избыточную функциональность, избыточные разрешения и избыточную автономию корневыми причинами риска Excessive Agency.	Агенту для анализа рынка не нужны ключи с правом вывода средств, удаления данных или изменения настроек аккаунта.	OWASP LLM06:2025 Excessive Agency
OpenAI рекомендует ставить human-in-the-loop approval перед действиями с побочными эффектами и отдельно проверять аргументы вызова инструмента.	Подтверждать нужно не абстрактную идею «купить BTC», а точные поля заявки: инструмент, направление, объём, тип, цену и защитные условия.	OpenAI: Guardrails and human review
NIST Playbook советует вести историю и аудит-логи, чтобы разбирать ошибки и уязвимости.	Нужно сохранять входные данные, предложение модели, результат проверок, решение человека и ответ торгового API.	NIST AI RMF Playbook: Measure

Где заканчивается помощник и начинается опасный автопилот

Фраза «AI-агент торгует за меня» звучит эффектно, но скрывает несколько разных задач. Одно дело — прочитать календарь, свести новости, посчитать размер позиции по заданной формуле и подготовить черновик торгового плана. Другое — получить API-ключ и самостоятельно отправлять заявки. Между этими режимами лежит граница реального финансового действия.

Большая языковая модель не становится торговой системой только потому, что умеет вызвать API. Она может неверно понять текст, перепутать единицы, использовать устаревшую цену, повторить запрос после тайм-аута или принять инструкцию из недоверенного веб-контента за команду. Даже правильный рыночный тезис не гарантирует правильный ордер: «риск 0,5%» легко испортить ошибкой в размере контракта, валюте счёта или расстоянии до стопа.

Поэтому я бы не давал модели прямой универсальный инструмент вроде execute_trade(anything). Чем шире функция и права ключа, тем дороже одна ошибка. Для исследовательского агента достаточно чтения котировок и истории. Если нужен контур исполнения, его следует вынести в отдельный узкий сервис с собственными правилами.

Практическая схема human-in-the-loop

1. AI готовит только структурированное предложение

На выходе модели должен быть не свободный текст, а объект с фиксированными полями: инструмент, направление, тип заявки, цена или условие входа, стоп, тейк, срок действия и краткое обоснование. Если обязательное поле отсутствует или формат неверен, заявка не идёт дальше. Важно: структурированный формат снижает число случайных ошибок, но сам по себе не доказывает, что идея верна.

2. Детерминированный код проверяет жёсткие ограничения

Лимиты лучше считать обычным кодом, а не просить модель «ещё раз всё проверить». Проверка должна отклонять неизвестный символ, нулевой или отрицательный объём, превышение допустимого риска, слишком далёкий стоп, заявку вне разрешённого списка рынков и повтор с тем же идентификатором. Максимальный размер позиции и дневной лимит убытка должны храниться вне промпта: модель не должна уметь переписать их своим ответом.

3. Человек видит точный итог перед подтверждением

Экран подтверждения обязан показывать не только «идею», но и фактические параметры: что покупается или продаётся, каким объёмом, по какому типу ордера, какой ориентировочный риск в деньгах, где стоп и насколько свежая котировка. После любого изменения параметров старое подтверждение должно аннулироваться. Иначе человек одобрит одну заявку, а система отправит уже другую.

4. Исполнитель имеет минимальные права

Ключ для торговли не должен иметь право вывода средств. Если биржа или брокер позволяют ограничить ключ по IP, рынкам и операциям, эти ограничения стоит использовать. Секрет нельзя помещать в промпт, историю чата или журнал модели. Модель предлагает действие, но подписывает и отправляет запрос отдельный компонент.

5. После отправки остаётся проверяемый след

Я бы сохранял идентификатор предложения, версию правил, хэш подтверждённых параметров, время решения, ответ API и итоговый статус ордера. Это помогает отличить ошибку модели от ошибки интеграции. Отдельно нужна защита от повторов: сетевой тайм-аут не означает, что первая заявка не дошла, поэтому слепой повтор способен удвоить позицию.

Минимальный рабочий маршрут: данные только для чтения → AI-предложение → проверка схемы → расчёт риска обычным кодом → ручное подтверждение → узкий торговый API → сверка результата → неизменяемый журнал. Для первых тестов я бы использовал демо-счёт или режим, который вообще не отправляет заявки, а только сравнивает предложения с последующим движением рынка.

Частые вопросы (FAQ)

Можно ли полностью автоматизировать торговлю без ИИ?

Да, алгоритмические стратегии существовали задолго до LLM. Но это не отменяет тестирования, лимитов, мониторинга и аварийного отключения. Главное различие в том, что классический алгоритм обычно выполняет заранее описанные правила, а языковая модель интерпретирует контекст и поэтому добавляет новый класс неопределённости.

Достаточно ли попросить модель всегда спрашивать подтверждение?

Нет. Критическое ограничение нельзя оставлять только в промпте. Остановка перед ордером должна быть реализована на уровне приложения: исполнитель физически не принимает заявку без отдельного действующего подтверждения и повторной серверной проверки параметров.

Какие права API-ключа допустимы?

Только минимально необходимые. Для аналитики — чтение. Для отдельного исполнительного сервиса — торговые операции без вывода средств, а также дополнительные ограничения платформы, если они доступны. Конкретные настройки зависят от брокера или биржи, поэтому их нужно проверять в официальной документации выбранной площадки.

Нужно ли подтверждать каждый ордер?

Для прототипа и системы на базе языковой модели — это разумная стартовая точка. Позже можно автоматизировать узкий, хорошо протестированный класс действий, но только с независимыми лимитами, мониторингом, журналом и механизмом немедленной остановки. Рост автономии должен следовать за доказанной надёжностью, а не за красивой демонстрацией.

Human-in-the-loop гарантирует отсутствие убытков?

Нет. Человек тоже ошибается, а правильное исполнение не делает торговую идею прибыльной. Этот контур уменьшает операционный риск: случайный или манипулированный ответ модели не должен автоматически превращаться в позицию на реальном счёте.

Итог

Я использую ИИ там, где он действительно силён: собрать контекст, подготовить варианты и убрать рутину. Но финансовое действие должно проходить через технические ограничения и понятную точку ответственности. Если AI-агент может одной ошибкой открыть позицию, увеличить объём или повторить заявку, проблема не в «плохом промпте», а в архитектуре. Начинать стоит с режима только для чтения и черновиков ордеров; доступ к исполнению — последний, а не первый этап автоматизации.

Материал носит информационный характер и не является индивидуальной инвестиционной рекомендацией или торговым сигналом.

---

Автор: Denis | Дата: 14.11.2026 | Обновлено: 14.11.2026
Denis — трейдер с 10+ летним опытом на форексе и крипторынках