Тема: Часть 20. Российский банковский контекст
Уровень сложности: Средний
Расчётное время изучения: 2–3 часа активной работы, включая практические упражнения
Предварительные требования: Базовое понимание архитектуры хранилищ данных (staging, marts, витрины)
Знакомство с принципами SDD (Specification-Driven Development)
Понимание роли файла AGENTS.md в работе агента
Общее представление о банковских процессах (KYC, AML, платежи, согласия)
Базовые навыки работы с SQL и dbt-подобными инструментами
Цели обучения: Объяснить, почему абстрактные формулировки из предметной области ('соблюдайте 152-ФЗ', 'учитывайте персональные данные') непригодны в качестве SDD-правил для агента.
Перечислить ключевые классы ограничений российского банковского контекста: PII, согласия, риск-флаги, отчётный lineage, шлюзы человеческого подтверждения.
Сформулировать проверяемое инженерное правило (с запрещёнными полями, схемотестами, ревью-чеклистами) на основе расплывчатой регуляторной нормы.
Различать зоны, в которых допустима автоматизация, и зоны, требующие обязательного подтверждения человеком (изменение grain, политики PII, методологии риска).
Применять принцип минимального выхода: переводить любое 'большое слово' домена (персональные данные, согласие, отчётность) в конкретное техническое ограничение.
Обзор: Глава «Российский банковский контекст» не является юридическим справочником. Её задача — показать, как публично известные банковские ограничения (152-ФЗ, 115-ФЗ, требования ЦБ к отчётности и рискам) превращаются в проверяемые инженерные правила, пригодные для спецификации SDD и работы агента. В книге последовательно вводятся шесть классов ограничений: персональные данные и минимизация PII, платежные операции и риск несанкционированных действий, согласия на доступ к данным через Open API, AML и риск-флаги, отчётность и воспроизводимость расчётов, lineage до источника и версии правила. Для каждого класса показано, как от слабой формулировки ('нужно учитывать персональные данные') перейти к рабочему правилу ('прямые PII-поля pii_email, phone, passport_number могут появляться только в staging; marts должны проходить schema-тест по списку запрещённых прямых PII; ревьюер обязан проверить новые колонки mart перед релизом'). Отдельно разбирается механизм подтверждения человеком: он не отменяет автоматизацию, а обозначает её границу. Глава закрепляет привычку перевода: любое «большое слово» домена должно превращаться в проверяемое инженерное правило, иначе оно остаётся открытым вопросом, а не исполняемой инструкцией.
Ключевые концепции: Ограничения как спецификации: В SDD ограничение предметной области — это не ссылка на закон, а технически проверяемое правило. Правило должно иметь форму, позволяющую агенту однозначно понять, выполнено оно или нет: список запрещённых полей, schema-тест, чек-лист ревью, факт lineage, шлюз утверждения. Если правило нельзя выполнить и проверить, оно остаётся декларацией, а не спецификацией.
Pii и минимизация: Персональные данные делятся на прямые идентификаторы (email, телефон, номер паспорта) и косвенные (пол, возраст, регион). В российском банковском контексте прямые PII допустимы только в слое staging и в защищённых PII-песочницах. На уровне marts они запрещены, и это закрепляется schema-тестом по списку запрещённых колонок. Любая новая колонка в mart должна проходить ревью на предмет появления прямых идентификаторов.
Marts vs staging: Staging — технический слой с сырыми или слабо очищенными данными, где допускается хранение PII под контролем доступа. Marts — слой, из которого читают продуктовые команды, аналитики, ML-модели и внешние партнёры. Граница 'marts не содержат прямых PII-полей' — ключевое инженерное правило, формализующее принцип минимизации данных (ст. 5 152-ФЗ).
Согласия (consents): Согласие клиента на обработку данных — это не булева переменная, а состояние с историей. Согласие может быть активным, отозванным, просроченным, ожидающим подтверждения. Mart согласий должен разделять активные и отозванные согласия, сохранять дату выдачи, дату отзыва и основание. Любая витрина, использующая данные клиента, обязана ссылаться на активное согласие нужного типа.
Open api и согласия на доступ: Открытые API Банка России и коммерческих банков обязаны передавать только те данные, на которые клиент дал согласие. В SDD это выражается правилом: 'витрина Open API возвращает только клиентов с активным согласием соответствующего типа на дату запроса'. Без такого правила агент не сможет безопасно сгенерировать фильтр.
Aml и риск-флаги: Антиотмывочные правила (115-ФЗ, требования ЦБ) и внутренние риск-модели порождают флаги подозрительных операций. Эти флаги нельзя агрегировать выше уровня операции без потери воспроизводимости. Правило: 'риск-операции не агрегируются без mart уровня операции; mart риск-сигналов не удаляет операции без заметки ревьюера'.
Отчётность и воспроизводимость: Регуляторная отчётность должна быть воспроизводимой: одна и та же метрика на одну и ту же дату должна давать одно и то же значение при пересчёте. Это требует версионирования моделей, фиксации snapshot'ов и проверочных фактов (test expectations) на каждый отчётный показатель.
Lineage до источника: Каждая отчётная метрика должна иметь lineage до исходной модели: какие источники, какие трансформации, какая версия кода. Без lineage невозможно ни расследование инцидента, ни подтверждение корректности перед регулятором. В SDD это выражается обязательным атрибутом lineage_id или аналогичным механизмом dbt-графа.
Grain (зерно) данных: Grain — это уровень детализации, на котором определена таблица или витрина (например, 'одна строка = один клиент', 'одна строка = одна операция'). Изменение grain ломает всех потребителей витрины, поэтому такое изменение нельзя делать в рамках обычной задачи — только через шлюз подтверждения человеком.
Sdd-правило: Хорошее SDD-правило: 1) однозначно понимается агентом; 2) проверяемо (есть тест, чек-лист или ревью-шаг); 3) относится к конкретному слою/таблице/полю; 4) имеет владельца (кто подтверждает изменение). Формулировка 'соблюдайте закон' не проходит ни по одному пункту.
Подтверждение человеком (human-in-the-loop): Список событий, которые агент не имеет права выполнять автономно: изменение политики PII, изменение grain, ломающее изменение контракта, новая методология риска, новая интерпретация согласий, изменение freshness/SLA. Это граница ответственности, а не отказ от автоматизации. Агент может найти проблему, предложить изменение, перечислить последствия — но решение принимает человек.
Схемотест (schema test): Автоматический тест, который проверяет, что в таблице нет колонок из запрещённого списка (например, прямых PII). В dbt это реализуется через custom tests или dbt-utils, в других фреймворках — через макросы. Схемотест превращает расплывчатое правило в исполнимое ограничение на CI.
Минимальный выход (minimal output): Принцип, согласно которому в AGENTS.md и спецификации попадают только те правила, которые исполняются и проверяются. Длинные цитаты из законов и общие декларации не включаются, чтобы не создавать у агента иллюзию покрытия. Если правило не готово как проверяемое, оно остаётся открытым вопросом со ссылкой на источник.
Важные даты: 2001-08-07 — 115-фз: Федеральный закон «О противодействии легализации (отмыванию) доходов, полученных преступным путём, и финансированию терроризма». Основа AML-требований в России; задаёт обязательства банка по мониторингу операций, идентификации клиентов, подаче сообщений в Росфинмониторинг.
2006-07-27 — 152-фз: Федеральный закон «О персональных данных». Устанавливает принципы обработки ПД, включая минимизацию, согласие, локализацию. Для SDD важен как источник правила 'marts не содержат прямых PII-полей'.
2014-07-21 — 242-фз: Поправки к 152-ФЗ, вводящие требование о хранении и обработке ПД граждан РФ на серверах, расположенных на территории России. Влияет на архитектуру staging-слоёв и кросс-граничный обмен.
2018-05-25 — gdpr (ес): Регламент ЕС по защите данных. Релевантен для российских банков, работающих с данными резидентов ЕС, и как образец структуры «правовой основы → инженерного правила».
2019-2024 — стандарты открытых api банка россии: Серия стандартов ЦБ по Open API, определяющих состав передаваемых данных и обязательства по согласиям. Для SDD — прямой источник правил фильтрации на уровне Open API витрин.
Регулярно — указания и положения цб (например, 590-п, 611-п): Нормативные документы, задающие требования к риск-менеджменту, достаточности капитала, отчётности. Используются как источники, на которые ссылаются SDD-правила, но не цитируются целиком в спецификациях.
Практические упражнения: Название: Перевод расплывчатой формулировки в проверяемое правило
Проблема: Вам дана спецификация витрины клиентов, в которой написано: 'Необходимо обеспечить защиту персональных данных клиентов в соответствии с 152-ФЗ'. Преобразуйте это предложение в проверяемое SDD-правило, пригодное для AGENTS.md. Правило должно содержать: (а) список конкретных запрещённых прямых PII-полей, (б) слой/таблицу, где ограничение действует, (в) способ проверки (тест, ревью-шаг).
Решение: Шаг 1. Выделить 'большие слова': 'защита персональных данных', '152-ФЗ'. Шаг 2. Перевести их в технические категории: прямые PII-поля (email, phone, passport_number, inn, snils), косвенные PII (пол, возраст, регион). Шаг 3. Сформулировать проверяемое правило. Пример итогового правила для AGENTS.md:
PII: marts не содержат прямые PII-поля.
Запрещённые прямые PII-поля: pii_email, phone, passport_number, inn, snils,
date_of_birth, full_name_unmasked.
Допустимые слои для прямых PII: только staging.* и защищённые pii_sandbox.*.
Проверка: каждый mart проходит schema-тест по списку запрещённых колонок
на этапе CI. Новая колонка в mart требует ревью владельца домена.Шаг 4. Убедиться, что правило можно выполнить (не добавлять прямые PII в mart) и проверить (schema-тест падает при нарушении).
Сложность: beginner
Название: Идентификация прямых PII в вымышленной витрине
Проблема: Вам дан список полей витрины dm.customer_360: customer_id, full_name, email, phone, gender, age, region, registration_date, last_transaction_amount, device_id, ip_address, hashed_email. Определите, какие поля являются прямыми PII и должны быть запрещены в mart. Объясните разницу между прямыми и косвенными идентификаторами. Сформулируйте исключения (если они есть).
Решение: Прямые PII (подлежат удалению/маскированию из mart): full_name, email, phone, ip_address, device_id (в сочетании с другими данными). Поля hashed_email и customer_id — это либо псевдонимы, либо технические ключи, но их отнесение к PII требует анализа: hashed_email — псевдоним, но при компрометации хеша становится косвенным идентификатором. Косвенные PII (допустимы при агрегации): gender, age, region. Технические поля: customer_id, registration_date, last_transaction_amount. Итоговое правило для этой витрины: 'из dm.customer_360 удалить full_name, email, phone, ip_address, device_id; оставить hashed_email как join-ключ; gender, age, region — оставить как косвенные идентификаторы'. Проверка: schema-тест по списку запрещённых колонок.
Сложность: beginner
Название: Проектирование mart согласий
Проблема: Спроектируйте mart согласий для банка. Витрина должна отвечать на вопросы: (1) Какие согласия у клиента активны на дату X? (2) Какие согласия были отозваны и когда? (3) Какие типы согласий существуют (на обработку ПД, на передачу в Open API, на маркетинг, на скоринг)? Опишите: grain, ключевые поля, разделение активных и отозванных согласий, что выносится в отдельные колонки. Сформулируйте SDD-правило.
Решение: Grain: одна строка = один факт согласия (выдача, отзыв, изменение). Рекомендуемая структура:
dm.consent_event
- client_id
- consent_type -- 'pd_processing', 'open_api_share', 'marketing', 'scoring'
- consent_state -- 'active', 'revoked', 'expired', 'pending'
- valid_from
- valid_to
- issued_at
- revoked_at
- source_system
- evidence_id -- ссылка на документ согласияПараллельная витрина для продуктового использования:
dm.consent_current
- client_id
- consent_type
- is_active -- true, если есть активная запись на дату запроса
- last_updatedSDD-правило: 'Согласия: dm.consent_event и dm.consent_current разделяют активные и отозванные согласия. Любая витрина, использующая данные клиента, обязана присоединиться к dm.consent_current и фильтровать по is_active=true. Изменение логики определения активного согласия — через шлюз подтверждения человеком.'
Сложность: intermediate
Название: Lineage для отчётной метрики
Проблема: Вам нужно описать lineage для отчётной метрики 'доля просроченных кредитов на 1 число месяца' (NPL ratio). Опишите: какие источники участвуют, какие трансформации, какие версии моделей фиксируются, какой атрибут lineage_id вы добавите, как обеспечите воспроизводимость. Сформулируйте SDD-правило.
Решение: Источники: core.loan_agreement (договоры), core.payment_schedule (график платежей), core.loan_status_history (статусы). Трансформации: stg.loan_agreement → int.loan_with_status → dm.loan_snapshot (snapshot на 1 число каждого месяца) → rep.npl_ratio. Фиксация версий: snapshot dbt-модели помечается dbt_snapshot_id; версия кода — git_sha; версия методологии — methodology_version (например, 'v2.1-2024-ЦБ'). Атрибут lineage_id формируется как hash(source_system + source_table + load_date + methodology_version). Проверка: каждая строка отчёта имеет непустой lineage_id; на CI — тест, что доля строк с lineage_id < 100%. SDD-правило: 'Отчётность: каждая отчётная метрика имеет lineage_id до исходной модели; версия методологии фиксируется в столбце methodology_version; воспроизводимость гарантируется snapshot'ом на дату расчёта. Изменение методологии — через шлюз подтверждения человеком.'
Сложность: intermediate
Название: Определение границ автоматизации и человеческого подтверждения
Проблема: Агент предлагает следующие изменения в спецификации: (1) добавить колонку email_md5 в mart dm.customer_360 для упрощения join'ов; (2) переопределить grain dm.transactions с уровня операции на уровень дня; (3) добавить фильтр по is_active=true из dm.consent_current в dm.marketing_audience; (4) обновить методологию расчёта NPL ratio с v2.1 на v2.2; (5) изменить SLA витрины с 24 на 12 часов; (6) исправить опечатку в имени столбца dt вместо date. Какие из этих изменений требуют подтверждения человеком, какие можно выполнить автономно?
Решение: Требуют подтверждения человеком (по списку главы): (2) изменение grain dm.transactions — ломающее изменение контракта; (4) обновление методологии расчёта NPL — новая методология риска; (5) изменение SLA с 24 на 12 часов — изменение freshness/SLA. Условно требуют подтверждения: (1) добавление email_md5 — новая колонка в mart, не нарушает список запрещённых PII, но требует ревью владельца домена на предмет появления идентификаторов (хотя бы как косвенных). Можно выполнить автономно: (3) добавление фильтра по dm.consent_current.is_active=true — это применение уже существующего правила 'витрина должна фильтровать по активным согласиям'; (6) исправление опечатки — косметическое изменение, не меняющее семантику. Итог: 3 изменения идут через шлюз, 1 — через ревью, 2 — автономно. Цель упражнения — закрепить, что 'маленькое' изменение (например, новая колонка) может быть опасным, а 'большое' SQL-изменение (фильтр по согласиям) — безопасным, если оно следует из уже принятого правила.
Сложность: advanced
Название: Перевод реального регуляторного требования в SDD-правило
Проблема: Возьмите одно реальное требование из вашего банковского контекста (например, статья 9 152-ФЗ о согласии субъекта, или требование 115-ФЗ об идентификации клиента, или требование стандарта Открытых API). Преобразуйте его в SDD-правило по схеме главы: (1) 'большое слово' домена, (2) техническая категория, (3) проверяемое правило, (4) способ проверки, (5) что требует подтверждения человеком. Оформите результат в виде блока для AGENTS.md.
Решение: Пример для ст. 9 152-ФЗ (согласие субъекта). (1) Большое слово: 'согласие субъекта на обработку ПД'. (2) Техническая категория: факт согласия с историей (выдача, отзыв, срок). (3) Проверяемое правило: 'Любая витрина, использующая ПД клиента, присоединяется к dm.consent_current и фильтрует по is_active=true и consent_type in (нужные типы). Согласие считается активным только при наличии записи в dm.consent_event со статусом active, у которой valid_from <= now() < valid_to.' (4) Способ проверки: dbt-тест, что доля клиентов без присоединённой записи в dm.consent_current в целевой витрине равна 0; ревью новых витрин на наличие фильтра. (5) Подтверждение человеком требуется при: изменении типов consent_type, изменении логики определения активного согласия, добавлении новых каналов сбора согласия. Готовый блок для AGENTS.md:
Согласия: dm.consent_event хранит все факты согласий (выдача, отзыв, истечение).
dm.consent_current — снимок активных согласий на текущую дату.
Любая витрина, использующая ПД клиента, обязана присоединиться к
dm.consent_current и фильтровать по is_active=true.
Изменение типов согласий, логики активности, источников согласия —
через шлюз подтверждения человеком.Сложность: advanced
Кейсы: Название: Витрина клиентов 360: переход от декларации к schema-тесту
Сценарий: Команда аналитиков крупного розничного банка построила витрину dm.customer_360, в которую попали поля email, phone и дата рождения клиента. В спецификации витрины было написано: 'Витрина обеспечивает защиту персональных данных в соответствии с требованиями 152-ФЗ'. Спецификация проходила ревью архитектора, но прямые PII продолжали появляться в mart. Запрос от продуктовой команды на использование витрины в обогащении маркетинговых кампаний поставил вопрос: можно ли передавать эти данные партнёру?
Задача: Главная проблема — формулировка про 'защиту в соответствии с 152-ФЗ' оказалась непроверяемой. Архитектор не имел объективного критерия, по которому можно было отклонить merge-запрос. Schema-теста на запрещённые колонки не существовало. Согласие клиента на передачу партнёру не проверялось. Риск — утечка прямых идентификаторов и нарушение минимизации данных (ст. 5 152-ФЗ), а также потенциальные штрафы и репутационный ущерб.
Решение: Команда перевела абстрактное требование в три проверяемых правила. Первое: список запрещённых прямых PII (email, phone, passport_number, date_of_birth, full_name_unmasked) явно зафиксирован, и введён schema-тест, который падает на CI при появлении этих колонок в любом mart. Второе: введена витрина dm.consent_current, и любой mart, использующий клиентские данные, обязан присоединиться к ней и фильтровать по is_active=true; введён тест, проверяющий, что доля клиентов без активного согласия в mart равна нулю. Третье: для передачи партнёру добавлен отдельный слой pii_partner_safe с агрегатами (только пол, возрастная группа, регион) и контрактом, фиксирующим отсутствие прямых идентификаторов. Спецификация в AGENTS.md стала содержать конкретные правила, а не общие декларации. Изменение списка запрещённых колонок или логики согласий было вынесено в шлюз подтверждения владельцем домена и DPO.
Результат: Через месяц после введения schema-теста три попытки добавить 'удобные' поля в mart (номер карты для join'а, email для коммуникаций) были автоматически отклонены на CI. Ревью стало объективным: ревьюер сверяется со списком запрещённых колонок и результатом теста, а не интерпретирует 'соответствие закону'. Продуктовая команда получила безопасный агрегат для партнёрских кампаний. Регуляторный аудит прошёл без замечаний по разделу минимизации данных. Команда зафиксировала привычку: любое 'большое слово' из 152-ФЗ (согласие, минимизация, локализация) переводится в проверяемое правило с владельцем и тестом.
Извлечённые уроки: Формулировка 'соответствует 152-ФЗ' не имеет операционного смысла без списка запрещённых полей и автоматической проверки.
Schema-тест превращает архитектурное правило в объективный критерий приёмки — это снимает нагрузку с ревьюера и ускоряет CI.
Согласие — это не булева переменная, а состояние с историей; витрина согласий должна разделять активные и отозванные.
Даже 'маленькое' добавление колонки в mart может нарушить политику PII и должно проходить ревью.
Связанные концепции: PII и минимизация
Marts vs Staging
Согласия (consents)
Схемотест (schema test)
SDD-правило
Название: Open API и согласия: как избежать утечки данных в партнёрский канал
Сценарий: Банк запускает Open API для партнёров — страховых компаний и маркетплейсов. Партнёры запрашивают профиль клиента (ФИО, контакты, история операций) для расчёта персонализированных предложений. Внутренняя команда разработки подготовила витрину, которая отдаёт 'всё, что есть о клиенте, с фильтром по наличию записи в базе'. Команда безопасности подняла тревогу: запросы от партнёров не учитывают ни тип согласия, ни факт отзыва.
Задача: Без формализации правил фильтрации агент (или junior-разработчик) при генерации Open API endpoint мог легко отдать данные клиента, отозвавшего согласие на передачу партнёрам. Кроме того, разные партнёры требуют разных наборов данных: страховой — историю операций, маркетплейсу достаточно агрегатов. Общее правило 'отдавать только то, на что есть согласие' — слишком расплывчато: какой тип согласия, какая дата актуальности, что делать с косвенными идентификаторами?
Решение: Команда ввела иерархию витрин. На нижнем уровне — dm.consent_event (все факты согласий) и dm.consent_current (активные согласия). Над ними — dm.open_api_profile, которая собирает только тех клиентов, у которых consent_type='open_api_share' и is_active=true на момент запроса, и только те поля, которые разрешены для соответствующего partner_scope (insurance, marketplace, scoring). Для каждого partner_scope зафиксирован список разрешённых полей в виде отдельной таблицы конфигурации. В AGENTS.md записано правило: 'Open API: dm.open_api_profile возвращает только клиентов с активным consent_type=open_api_share. Список полей определяется таблицей config.partner_scope_allowlist. Изменение списков полей и типов согласий — через шлюз подтверждения человеком (владелец продукта + DPO).' В dbt добавлен тест: доля строк в dm.open_api_profile без активного consent_type=open_api_share должна быть равна нулю. Дополнительно введён тест на соответствие разрешённых полей partner_scope_allowlist.
Результат: Запуск Open API прошёл без инцидентов. Попытка одного из партнёров расширить scope (получить ФИО и email) была автоматически отклонена на уровне endpoint'а. Когда клиент отозвал согласие через мобильное приложение, он исчез из dm.open_api_profile в течение часа, и партнёрский канал перестал получать его данные — без ручного вмешательства. Аудитор ЦБ отметил наличие формализованного lineage от запроса партнёра до факта согласия.
Извлечённые уроки: Согласие должно иметь типы и временную актуальность; одной отметки 'согласен' недостаточно.
Витрина для внешних потребителей — это не 'всё, что есть', а проекция с фильтром по типу согласия и scope.
Конфигурация разрешённых полей по partner_scope должна быть отдельной таблицей с владельцем, а не хардкодом в коде.
Lineage от API-запроса до факта согласия — обязательное условие для регуляторного аудита.
Связанные концепции: Согласия (consents)
Open API и согласия на доступ
Lineage до источника
Подтверждение человеком (human-in-the-loop)
Название: Анти-паттерн: цитаты из законов вместо правил
Сценарий: Команда внедряла SDD в подразделении риск-менеджмента. Аналитик-эксперт, отвечавший за спецификации, вставил в AGENTS.md полные тексты статей 6, 9 и 11 152-ФЗ, а также выдержки из Положения 590-П. Его аргумент: 'Агент должен знать закон, чтобы правильно принимать решения'. В результате AGENTS.md разросся до 40 страниц, и при запросе на генерацию SQL агент начал возвращать формулировки, цитирующие закон, но не отвечающие на задачу.
Задача: Главная проблема — длинный юридический текст не является исполняемой инструкцией. Агент не умеет 'применять' статью закона; он умеет выполнить конкретное правило или не выполнить. Спецификация превратилась в шум: ревьюер не мог найти в ней проверяемые ограничения, разработчик не понимал, какие поля запрещены, аналитик не мог сформулировать, какие mart требуют подтверждения.
Решение: Команда провела рефакторинг спецификации. Из AGENTS.md были удалены все длинные цитаты. Вместо них — короткие ссылки на источник ('см. ст. 9 152-ФЗ') и рядом проверяемое правило. Например, вместо полного текста ст. 9 появилось: 'Согласие: dm.consent_event хранит факты согласий; витрины, использующие ПД, фильтруют по is_active=true в dm.consent_current. Источник правила: ст. 9 152-ФЗ. Изменение типов согласий — через шлюз подтверждения человеком.' Вместо выдержек из 590-П — конкретные правила для mart риск-метрик: версия методологии, lineage_id, запрет на агрегацию риск-операций выше уровня операции. Источники (ссылки на нормативные документы) были вынесены в отдельный файл references.md, который не загружается в контекст агента при генерации SQL.
Результат: Объём AGENTS.md сократился с 40 до 8 страниц. Время ревью спецификации уменьшилось примерно вдвое. Агент стал давать конкретные, исполняемые предложения вместо юридических формулировок. Ревьюер получил объективные критерии (schema-тест, тест на долю клиентов с активным согласием, тест на lineage_id), а не интерпретацию закона. При аудите команда показывала и AGENTS.md (исполняемые правила), и references.md (источники), что удовлетворило и регулятора, и разработчиков.
Извлечённые уроки: Длинная цитата закона в спецификации — это украшение, а не инженерное ограничение; агенту она не помогает.
Ссылки на источник и рядом проверяемое правило — оптимальная структура: и юридическая прослеживаемость, и исполнимость.
AGENTS.md должен загружаться в контекст агента при решении задач; следовательно, он должен быть компактным и проверяемым.
Юридический отдел — владелец references.md, инженерная команда — владелец AGENTS.md; это разные артефакты с разной ответственностью.
Связанные концепции: Минимальный выход (minimal output)
SDD-правило
Подтверждение человеком (human-in-the-loop)
Lineage до источника
Название: Изменение grain как точка невозврата: урок на инциденте
Сценарий: Команда витрины транзакций решила оптимизировать производительность и предложила перейти с grain 'одна строка = одна операция' на 'одна строка = один день по счёту'. Изменение было оформлено как обычный merge-запрос с пометкой 'оптимизация производительности'. После релиза четыре продуктовые команды обнаружили, что их join'ы и ML-модели сломаны: исчезли детали операций, поменялись суммы, появились дубликаты. Возврат занял неделю.
Задача: Изменение grain — одно из событий, которые глава относит к шлюзу подтверждения человеком. В данном случае оно было проведено как 'обычный SQL-рефакторинг', и никто не увидел, что оно ломает контракт. Спецификация не содержала явного правила о том, что изменение grain запрещено без подтверждения владельца продукта и команд-потребителей.
Решение: После инцидента команда внесла в AGENTS.md и в чек-лист ревью явное правило: 'Grain: dm.transactions имеет grain = одна строка = одна операция. Изменение grain (в любую сторону) — через шлюз подтверждения человеком с уведомлением всех потребителей за 5 рабочих дней. PR с изменением grain должен содержать раздел Affected downstream с перечислением всех затрагиваемых витрин и ML-моделей.' Дополнительно в dbt-тесте зафиксировано ожидание: count(distinct operation_id) = count(*) в dm.transactions (тест на уникальность grain). При попытке агрегировать витрину выше уровня операции (например, суммировать в int-слое) тест на lineage и grain напомнит агенту о границе.
Результат: Следующая попытка оптимизации (через индексирование, партиционирование и материализованные представления) прошла без изменения grain. Производительность выросла на 40% без поломки контракта. Команда-потребитель подтвердила, что данные остались совместимыми. Аудит lineage показал, что все downstream-витрины продолжают ссылаться на корректный grain. Урок зафиксирован в онбординге для новых инженеров.
Извлечённые уроки: Изменение grain — это ломающее изменение контракта, даже если оно оформлено как 'оптимизация'.
Тест на уникальность grain — простой и надёжный способ автоматически поймать нарушение.
PR с изменением grain должен содержать раздел Affected downstream; без него изменение не должно проходить ревью.
Шлюз подтверждения — это не бюрократия, а защита от дорогостоящих откатов.
Связанные концепции: Grain (зерно) данных
Подтверждение человеком (human-in-the-loop)
Lineage до источника
SDD-правило
Советы по изучению: Всегда спрашивайте себя: 'Могу ли я написать тест, который проверит это правило?' Если ответ 'нет' — правило ещё не готово, оставьте его как открытый вопрос.
Держите в AGENTS.md только то, что исполняется и проверяется. Длинные цитаты из законов вынесите в отдельный references.md, на который ссылается правило.
Переводите каждое 'большое слово' домена (персональные данные, согласие, риск, отчётность, аудит) в конкретную техническую категорию: запрещённое поле, тест, ревью-шаг, шлюз.
Список шлюзов подтверждения (PII-политика, grain, контракт, методология риска, согласия, SLA) держите в одном месте — например, в чек-листе ревью и в начале AGENTS.md. Это сокращает число случайных нарушений.
Для каждой отчётной метрики требуйте lineage_id и methodology_version. Без них воспроизводимость не гарантируется, и регуляторный аудит становится невозможным.
Schema-тест по списку запрещённых колонок — минимальный и обязательный инструмент. Внедряйте его в первую очередь, до того как строите сложные политики.
Согласие моделируйте как состояние с историей, а не как булеву переменную. Это сразу выявляет требования к витрине согласий и к фильтрации потребителей.
Практикуйте перевод: возьмите одно реальное требование из вашего банка и оформите его в виде блока AGENTS.md. Это быстрее, чем чтение главы, и сразу выявляет пробелы в понимании.
Не путайте 'маленькое' изменение с 'безопасным'. Добавление одной колонки в mart может нарушить политику PII, а фильтр по существующему правилу — безопасен.
Помните: подтверждение человеком — это граница ответственности, а не отказ от автоматизации. Агент может найти проблему и предложить решение, но решение принимает человек.
Дополнительные ресурсы: Федеральный закон 152-фз 'о персональных данных': Основной российский закон о ПД. Использовать как источник ссылок в references.md, а не как текст для AGENTS.md.
Федеральный закон 115-фз 'о противодействии легализации доходов': Основа AML-требований. Полезен при формулировании правил для mart риск-сигналов и операций.
Положения и указания банка россии (590-п, 611-п и др.): Регуляторные документы по риск-менеджменту и достаточности капитала. Источник для правил methodology_version и lineage.
Стандарты открытых api банка россии: Источник для правил фильтрации Open API витрин и работы с типами согласий.
Dbt-utils (custom schema tests): Инструмент для реализации schema-тестов по списку запрещённых колонок и другим проверяемым ограничениям.
Dbt-snapshot: Механизм фиксации версий моделей для воспроизводимости отчётных метрик.
Внутренние политики банка по pii и рискам: Каждый банк имеет собственные политики обработки ПД, риск-модели и регламенты согласования. Они — главный источник конкретных правил вашего проекта.
Gdpr (регламент ес 2016/679): Полезен как образец структуры 'правовая основа → инженерное правило' и как источник идей для минимизации данных.
Open source: great expectations, soda core: Инструменты для описания и автоматической проверки data quality правил, в том числе по списку запрещённых PII-полей.
Книги и курсы по data contracts: Концепция data contracts близка к SDD-правилам: фиксация контракта между производителем и потребителем данных, включая ограничения PII и согласий.
Резюме: Глава «Российский банковский контекст» учит главному: агент не может «соблюдать закон» в общем виде — он может выполнить конкретное проверяемое правило. Поэтому любое большое слово домена (персональные данные, согласие, риск, отчётность, аудит) должно переводиться в инженерное ограничение: список запрещённых полей, schema-тест, ревью-шаг, факт lineage или шлюз подтверждения человеком. Шесть классов ограничений — PII, платежи и риск, согласия, AML, отчётность, lineage — образуют каркас правил для AGENTS.md. Список шлюзов подтверждения (изменение политики PII, grain, контракта, методологии риска, интерпретации согласий, SLA) задаёт границу автоматизации. Длинные цитаты законов не помогают агенту — помогают короткие ссылки на источник и рядом проверяемое правило. Минимальный выход AGENTS.md — это компактный набор исполняемых и проверяемых правил, рядом с которым лежит файл ссылок на нормативные источники. Если правило не удаётся перевести в проверяемую форму, оно остаётся открытым вопросом, а не декларацией. Цель главы — привить привычку перевода, которая делает SDD-спецификации одновременно юридически прослеживаемыми и инженерно исполнимыми.