Аудит ИИ и 152-ФЗ: какие события логировать и как строить hash-chain журнал

Когда AI-агент — Cursor, Claude Code или Copilot — читает репозиторий с персональными данными (ПДн), отправляет их в LLM и получает назад инструкцию модифицировать запись в базе, именно в этот момент начинается обработка ПДн в смысле 152-ФЗ. И именно в этот момент у оператора возникает обязанность вести аудит логирование: кто, когда, к каким данным и на каком правовом основании обращался. Между «у нас есть логи в stdout» и «журнал, который пройдёт проверку Роскомнадзора и ФСТЭК» — дистанция размером с tamper-evident hash chain, retention-политику и географическую привязку хранилища.

Эта статья — technical compliance-гайд для платформ governance AI. В ней нет общих слов про «важность безопасности»: только конкретные события, поля, сроки хранения и реализация hash-chain журнала на Rust, которую можно скопировать в production.

Что вы узнаете:

• Какие именно нормативные акты (152-ФЗ, ФЗ-149, приказы ФСТЭК №17 и №21) накладывают требования к журналированию и где в них «спрятан» ИИ.
• Таблица из 12 обязательных классов событий с полями, источником сбора и сроком retention.
• Как построить tamper-evident hash-chain журнал на HMAC-SHA256 с anchoring и верификацией.
• Retention-конфиг hot/warm/cold с WORM-хранением и географической привязкой к РФ.
• Чек-лист из 15 пунктов для прохождения аудита соответствия.

Нормативная база: 152-ФЗ и ФЗ-149

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

Федеральный закон №152-ФЗ «О персональных данных» требует от оператора принимать «необходимые правовые, организационные и технические меры». Конкретика расшифрована в приказе ФСТЭК №21 («Об утверждении состава и содержания организационных и технических мер»): пункт 6.1 прямо предписывает «учёт и хранение» действий по доступу к ПДн, а пункт 6.2 — регистрацию событий безопасности. Уровень защищённости (УЗ-1…УЗ-4) определяет глубину: для УЗ-1 и УЗ-2 требуется фиксация каждого доступа с возможностью восстановления хронологии.

Федеральный закон №149-ФЗ «Об информации, ИТ и о защите информации» — это каркас. Статья 16 устанавливает обязанность владельца ИС защищать обрабатываемую информацию, а развитие ИИ-направления — Указ Президента №490 «О Стратегии развития ИИ» и сопутствующие методические рекомендации — прямо указывает на необходимость контроля за решениями, принимаемыми ИИ-системами. Иными словами, ФЗ-149 и ИИ уже связаны: система, которая автономно обращается к данным, должна быть включена в контур защиты и аудита наравне с человеком-оператором.

Где именно AI-агент создаёт новые обязательства? В трёх точках, которых нет у классического веб-приложения:

• Трансграничная передача ПДн — запрос к api.openai.com или api.anthropic.com физически переносит ПДн за пределы РФ. Это действие подлежит отдельному учёту (ст. 18.5 152-ФЗ).
• Автономное решение — если агент сам решил прочитать файл с ПДн, в журнале должна быть не только запись «файл прочитан», но и причина: какая prompt-инструкция, какой tool-call, какая модель.
• Цепочка делегирования — человек одобрил план → агент вызвал MCP-сервер → MCP-сервер обратился к БД. Все три звена — отдельные события, связанные единым trace_id.

Что обязательно логировать

«Логировать всё» — это не требование, это путь к журналу в 40 ГБ/сутки, который невозможно проверить. Приказы ФСТЭК и практика проверок Роскомнадзора выделяют конкретные классы событий. Ниже — таблица, которую мы используем как baseline при настройке compliance AI контура в FlowLink.

Каждое событие должно содержать минимальный набор сквозных полей: ts (RFC3339, UTC — с синхронизацией по NTP, иначе хронология «поплывёт»), trace_id (для связи цепочки вызовов), actor (идентификатор агента или пользователя), decision(allow/deny) и prev_hash (ссылка на предыдущую запись — основа tamper-evidence). Подробно о том, как эти события превращаются в метрики и алерты, — в статье про мониторинг активности AI-агентов; здесь же мы фокусируемся на immutable-стороне журнала.

Hash-chain журнал: реализация

Обычный лог-файл бесполезен для аудита: администратор с правом root может отредактировать или удалить любую строку, и никто не заметит. Приказы ФСТЭК требуют «целостности и доступности» записей — технически это достигается tamper-evident журналом, где каждая запись криптографически связана с предыдущей. Это и есть hash chain.

Идея проста: каждая запись Eₙ содержит хеш H(Eₙ₋₁ ‖ payloadₙ ‖ nonce). Изменить любую прошлую запись, не сломав цепочку, невозможно — нарушится хеш в следующей. Для усиления используется HMAC с секретным ключом (аутентифицированный хеш) и периодический anchoring — фиксация текущего «головного» хеша во внешнем хранилище, недоступном для агентов.

1// Core хеширующего аппендера (Rust, crate: sha2 + hmac)
2use sha2::Sha256;
3use hmac::{Hmac, Mac};
4type HmacSha256 = Hmac<Sha256>;
5​
6#[derive(serde::Serialize, serde::Deserialize, Clone)]
7pub struct AuditEntry {
8    pub seq: u64,              // монотонный номер, never reused
9    pub ts: String,            // RFC3339, UTC
10    pub actor: String,         // agent_id или user sub
11    pub event: String,         // "pd_access" | "llm_call" | ...
12    pub resource: String,      // canonical resource uri
13    pub decision: String,      // "allow" | "deny"
14    pub trace_id: String,
15    pub prev_hash: String,     // this_hash предыдущей записи
16    pub this_hash: String,     // вычисляется в seal()
17}
18​
19impl AuditEntry {
20    /// payload под хеш: все поля, кроме this_hash, в фиксированном порядке
21    fn signed_payload(&self) -> Vec<u8> {
22        let mut v = self.seq.to_le_bytes().to_vec();
23        for f in [&self.ts, &self.actor, &self.event, &self.resource,
24                  &self.decision, &self.trace_id, &self.prev_hash] {
25            v.extend_from_slice(f.as_bytes());
26        }
27        v
28    }
29​
30    pub fn seal(&mut self, chain_key: &[u8]) {
31        let mut mac = HmacSha256::new_from_slice(chain_key).expect("hmac key");
32        mac.update(&self.signed_payload());
33        self.this_hash = hex::encode(mac.finalize().into_bytes());
34    }
35}
36​
37/// Аппендер: берёт хвост цепи, ставит prev_hash, печатает this_hash
38pub fn append(
39    tail_hash: &str,         // this_hash последней записи (или genesis)
40    chain_key: &[u8],        // ключ из KMS, не на диске агента
41    mut entry: AuditEntry,
42) -> AuditEntry {
43    entry.prev_hash = tail_hash.to_string();
44    entry.seal(chain_key);
45    entry
46}

Несколько тонкостей, без которых журнал «не пройдёт»:

• Ключ chain_key хранится в KMS (Yandex KMS, HashiCorp Vault transit, AWS KMS), а не рядом с агентом. Агент только «слепит» запись; ключ ему не отдаётся.
• seq монотонный и без пропусков. Пропущенный номер = красный флаг для аудитора. Контролируется отдельным счётчиком в БД с advisory-lock.
• Anchoring каждые N минут. Текущий this_hash фиксируется во внешнем хранилище (например, записью в отдельной WORM-колонке или транзакцией в публичном источнике). Если позже кто-то подменит хвост цепи, anchor перестанет совпадать.
• Batch verification через Merkle tree. Для проверки целого месяца записей не нужно хешировать каждую: строится дерево, и проверяется корневой хеш против anchored-значения.

Верификатор цепи (используется на ежесуточном джобе и по запросу аудитора):

1# Python-верификатор: проходит по записям, проверяет связь и HMAC
2import hmac, hashlib, sys
3​
4CHAIN_KEY = kms_fetch("audit/chain-key")  # из KMS, не из конфига
5​
6def verify(entries, anchored_head_hash):
7    prev = "0" * 64  # genesis
8    for e in entries:
9        if e["prev_hash"] != prev:
10            raise SystemExit(f"BROKEN chain at seq={e['seq']}: prev_hash mismatch")
11        payload = b"".join([
12            e["seq"].to_bytes(8, "little"),
13            e["ts"].encode(), e["actor"].encode(), e["event"].encode(),
14            e["resource"].encode(), e["decision"].encode(),
15            e["trace_id"].encode(), e["prev_hash"].encode(),
16        ])
17        expected = hmac.new(CHAIN_KEY, payload, hashlib.sha256).hexdigest()
18        if not hmac.compare_digest(expected, e["this_hash"]):
19            raise SystemExit(f"TAMPERED entry seq={e['seq']}: HMAC mismatch")
20        prev = e["this_hash"]
21    if prev != anchored_head_hash:
22        raise SystemExit("HEAD mismatch vs anchor — tail was rewritten")
23    print(f"OK: {len(entries)} entries, chain intact")
24​
25if __name__ == "__main__":
26    verify(load_entries(sys.argv[1]), load_anchor("today"))

Если верификатор падает на TAMPERED entry — запись подделана; наHEAD mismatch — подменён хвост. Оба случая — автоматический алерт и инцидент в рамках реакции на события ИБ.

Хранение и retention

Сроки хранения диктуются нормативом: для ИСПДн уровня УЗ-1/УЗ-2 — не менее 1 года (приказ ФСТЭК №21), для журналов доступа к ПДн на практике мы закладываем 5 лет с запасом — срок исковой давности по 152-ФЗ. Хранилище должно быть только для добавления(WORM — write once, read many) и находиться географически в РФ, потому что вывоз ПДн за пределы страны без отдельного основания (ст. 18.5) — самостоятельное нарушение.

Типичный hot/warm/cold пайплайн (конфиг FlowLink):

1# /etc/flowlink/audit-retention.yaml
2retention:
3  hot:                           # быстрый поиск, до 90 дней
4    backend: postgresql
5    table: audit_events_hot
6    partition: weekly            # авто-truncate партиций
7    duration: 90d
8    encryption: aes-256-gcm      # at-rest, ключи в KMS
9  warm:                          # аналитика, 90д–1год
10    backend: clickhouse
11    duration: 1y
12    compression: lz4
13  cold:                          # архив для проверок, 1–5 лет
14    backend: s3-compatible
15    bucket: flowlink-audit-cold
16    worm:                        # S3 Object Lock, compliance mode
17      mode: COMPLIANCE
18      retain_until: "now + 5y"
19    encryption: aws:kms          # серверсайд, ключ в ru-central1
20    geo:
21      region: ru-central1        # запрет replication за пределы РФ
22      cross_region_replication: false
23​
24integrity:
25  chain_key_kms_ref: "kms/audit/chain-key"
26  anchor:
27    interval: 5m                 # фиксация head-hash во WORM-колонке
28    target: audit_anchors        # отдельная COMPLIANCE-locked таблица
29  verify_job:
30    schedule: "0 3 * * *"        # ежесуточно в 03:00
31    alert_on_fail: pagerduty

Географическая привязка и запрет на вынос ПДн за пределы РФ контролируются не «доверием к конфигу», а политикой, которая проверяется на каждом запросе. В FlowLink это Rego-правило в OPA, которое блокирует любую попытку репликации или экспорта audit-данных в неразрешённый регион:

1# audit_geo_fence.rego — запрещает запись ПДн-логов вне РФ
2package flowlink.audit
3​
4import rego.v1
5​
6default allow := false
7​
8# Разрешённые локации хранения журналов с ПДн
9allowed_regions := {"ru-central1", "ru-central1-a", "ru-central1-b"}
10​
11allow if {
12    input.action == "audit_write"
13    input.store.region in allowed_regions
14    not input.store.cross_region_replication
15    input.store.encryption != null
16}
17​
18# Жёсткий запрет: экспорт ПДн-события за границу
19deny[msg] if {
20    input.action == "audit_export"
21    input.dest.country != "RU"
22    input.has_pdn == true
23    msg := sprintf(
24      "BLOCKED: ПДн-аудит нельзя вывозить в %v (ст. 18.5 152-ФЗ)",
25      [input.dest.country],
26    )
27}
28​
29# Запрет на удаление записи младше retention
30deny[msg] if {
31    input.action == "audit_delete"
32    input.entry_age_days < 1825
33    msg := sprintf(
34      "BLOCKED: запись младше 5 лет (age=%v дн.)",
35      [input.entry_age_days],
36    )
37}

Заметьте: правило не «рекомендует», а возвращает allow = false по умолчанию и явно deny — то есть MCP-gateway и policy engine физически не пропустят операцию. Это и есть compliance as code: вместо регламента на бумаге — исполняемая политика, чьи решения сами попадают в тот же hash-chain журнал.

Сами секреты, к которым обращаются агенты, — отдельная зона риска: доступ к credential vault тоже входит в обязательный журнал (строка 5 таблицы выше). Как сделать так, чтобы секреты не утекли ещё до того, как попадут в лог, — разбиралось в материале пропредотвращение утечек учётных данных через MCP.

Чек-лист соответствия

Сведём всё в пошаговый список. Если по каждому пункту есть «да» с артефактом (конфиг, запись в журнале, KMS-ключ) — контур готов к проверке Роскомнадзора или внутреннему compliance-аудиту.

Compliance для AI-агентов — это не «дополнительная галочка», а продолжение тех же требований 152-ФЗ и ФЗ-149, перенесённое на новую модель исполнения. Агент, который сам принимает решения и сам обращается к данным, требует более строгого, а не менее строгого журналирования. Hash-chain журнал с anchoring, WORM-retention и geo-fencing — это тот минимум, при котором фраза «у нас ведётся аудит логирование» соответствует не только внутреннему убеждению, но и нормативу.