Урок 1: Аудит-след решений и требования регуляторов

Чему вы научитесь

• Понимать, зачем логировать каждое решение агента, включая «не торговать»
• Видеть, как устроена tamper-proof аудит-цепочка на SHA-256
• Соотносить практику с MiFID II (ст. 17) и EU AI Act (ст. 12 и 14)
• Понимать российскую специфику регулирования инвестсоветников и ИИР
• Готовить документируемость заранее, а не постфактум

Зачем аудит-след

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

TradeMemory Protocol строит для этого tamper-proof аудит-цепочку: каждое решение записывается с хэшем SHA-256, связывающим записи в неизменяемую последовательность (источник: README TradeMemory Protocol). Логируется в том числе решение «не торговать» — оно тоже часть истории.

flowchart LR
    D1[Решение 1] --> H1[hash 1]
    H1 --> D2[Решение 2 + hash 1]
    D2 --> H2[hash 2]
    H2 --> D3[Решение 3 + hash 2]
    D3 --> H3[hash 3]

Что требуют регуляторы

Требования к документированию алгоритмических решений существуют не первый год. Для тех, кто строит что-то близкое к продукту, это ориентир.

Эти нормы относятся к ЕС, но задают общий стандарт мышления: лог, объяснимость, надзор человека. Те же принципы мы уже встроили в предыдущих модулях через подтверждение человеком и guard-проверки.

Российская специфика

В РФ деятельность инвестиционных советников регулируется, а программы для предоставления ИИР подлежат аккредитации Банка России. Учебный агент не должен позиционироваться как инвестсоветник.

Практический вывод: аудит-след полезен не только для ЕС-норм, но и для российской рамки — он фиксирует, что система занималась анализом и документированием, а не раздачей адресных советов. Актуальную редакцию стандартов проверяйте на дату работы (источник: Банк России).

Следующий урок

Урок 2: Капстоун — личный ресёрч-агент — собираем всё в один безопасный проект без live-торговли.