# Часть 20. Российский банковский контекст

Эта глава не даёт юридических инструкций. Она показывает, как публично
известные ограничения превращаются в SDD-правила. Для агента бесполезно писать
«соблюдай закон». Ему нужны конкретные ограничения, проверяемые факты и
подтверждения человеком.

## Ограничения как спецификации

Для учебного банка важны классы ограничений:

- персональные данные и минимизация PII;
- платежные операции и риск несанкционированных действий;
- согласия на доступ к данным через Open API;
- AML и риск-флаги;
- отчётность и воспроизводимость расчётов;
- lineage до источника и версии правила.

## Как записывать в проекте

Не пишите в `AGENTS.md`: «соблюдай закон». Это непроверяемо. Пишите конкретно:

- marts не содержат прямых PII-полей;
- mart согласий разделяет активные и отозванные согласия;
- витрина риск-сигналов не удаляет операции без заметки ревьюера;
- отчётная витрина имеет проверочные факты и lineage;
- изменение grain или SLA требует подтверждения.

## Пример перевода ограничения

Слабое правило:

```markdown
Нужно учитывать персональные данные.
```

Рабочее правило:

```markdown
Прямые PII-поля (`pii_email`, `phone`, `passport_number`) могут появляться
только в staging. Marts должны проходить schema-тест по списку запрещённых прямых PII.
Ревьюер обязан проверить новые колонки mart перед релизом.
```

Второе правило не является юридической консультацией. Это инженерная защита,
которую можно выполнить и проверить.

## Подтверждение человеком

Подтверждение человеком нужно там, где агент не должен принимать решение:

- изменение политики PII;
- изменение grain;
- ломающее изменение контракта;
- новая методология риска;
- новая интерпретация согласий;
- изменение freshness/SLA.

Если изменение выглядит маленьким, но попадает в этот список, его нельзя
пропускать как «только SQL».

## Qwen-запрос

```text
Прочитай specs и marts.
Найди места, где банковский контекст должен быть выражен как проверяемое
правило: PII, согласия, риск, отчётный lineage, шлюзы утверждения.
Файлы не меняй.
```

## Минимальный выход

Запишите ограничения как технические правила:

```markdown
PII: marts не содержат прямые PII-поля.
Согласия: активные и отозванные согласия считаются отдельно.
Риск: риск-операции не агрегируются без mart уровня операции.
Отчётность: каждая отчётная метрика имеет lineage до исходной модели.
Подтверждение: grain/SLA/поля контракта не меняются без подтверждения человеком.
```

Эти правила можно перенести в `AGENTS.md`, чек-лист проверки или навык
ревьюера.

## Разбор для читателя

Российский банковский контекст в этой книге — не юридический раздел.
Его задача — показать, как внешние ограничения превращаются в инженерные
правила. Агент не может «соблюдать закон» в общем виде. Он может не добавлять
PII в mart, требовать подтверждение при смене grain, сохранять lineage, не
переопределять методологию риска без спецификации. Чем конкретнее правило, тем
лучше оно работает в SDD.

Важно не копировать нормативные тексты в спецификации как украшение. Длинная
цитата закона редко помогает агенту принять правильное решение. Лучше записать
ссылку на источник и рядом сформулировать исполнимое правило проекта. Например:
прямые идентификаторы запрещены в marts; согласие считается активным только по
описанному правилу; отчётная метрика имеет lineage до источника; изменение SLA
требует подтверждения человеком.

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

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

## Практика

Возьмите одно правовое или регуляторное слово из своего домена и переведите его
в инженерное ограничение: список запрещённых полей, обязательное ревью, факт lineage или
шлюз утверждения.

## Типичная ошибка

Вставлять в спецификации длинные цитаты законов. Агенту нужен не правовой
трактат, а проверяемые инженерные правила. Ссылки на законы и регуляторные
документы лучше держать как источники и ограничения, а не как исполняемые
инструкции.

## Контрольные вопросы

1. Почему «соблюдать 152-ФЗ» не является достаточным SDD-правилом?
2. Какие поля запрещены в marts?
3. Как согласия влияют на дата-продукт?