Материал: Часть 20. Российский банковский контекст

Урок 1 из 5 в модуле «Часть 20. Российский банковский контекст»

Вы просматриваете урок без входа. Войдите, чтобы сохранять прогресс и проходить тесты.

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Qwen-запрос

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

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

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

PII: marts не содержат прямые PII-поля.
Согласия: активные и отозванные согласия считаются отдельно.
Риск: риск-операции не агрегируются без mart уровня операции.

Отчётность: каждая отчётная метрика имеет lineage до исходной модели.
Подтверждение: grain/SLA/поля контракта не меняются без подтверждения человеком.

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

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

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

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

Подтверждение человеком не означает отказ от автоматизации. Наоборот, оно

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

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

Практика

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

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

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