Введение

T+3M в SwiftRide. Baseline-реестр из 24 CDE опубликован. Председатель Audit Committee задаёт вопрос, определяющий зрелость программы: «Когда мы пересматриваем этот список? Что заставит нас изменить реестр между ежегодными ревью?»

Реестр без каденса обновления — это snapshot, который устаревает в первый день после публикации. Расширение SwiftCapital 3 → 8 стран в Q3 — это жёсткий триггер. EU AI Act 2 Aug 2026 — это жёсткий триггер. Запуск SwiftPay в новой стране — жёсткий триггер. Инцидент в стиле SwiftPay 2024 — жёсткий триггер. Без каденса каждый из них — отдельная ad-hoc-паника; с каденсом — предсказуемый ритуал governance.

Этот урок — фиксация каденса обновления + триггеров изменений + прогрессии зрелости от ad-hoc к встроенному SDLC (мост к M8). Выход — операционный governance-ритуал для цикла SwiftRide Y+1.

Два режима обновления

Режим A — ежегодное ревью (обязательный baseline)

Каденс: один раз в год. Calendar-driven.

Скоуп: полный sweep — все записи CDE ревьюются; полный sweep top-down (M4.2) + bottom-up (M4.3) обновление.

Выход:

• Обновлённые записи в change_history.
• Новые CDE добавлены (обновление обнаружения нашло новых кандидатов).
• Уходящие CDE отмечены (датасеты декомиссионированы, deprecated бизнес-процессы).
• Аудит методологии — независимый вызов Internal Audit.
• Ежегодный отчёт о программе → Audit Committee + Board Risk Committee.

Требуемые участники: Data Council (председатель + голосующие члены); CDO Office; Domain Leads; Internal Audit; ключевые Business Owners.

Timeline: обычно 6-8 недель (меньше, чем первичный инвентарь, потому что инкрементально).

Почему ежегодное обязательно: параграфы PCAOB AS 2201 требуют периодической переоценки ICFR; BCBS 239 подразумевает ежегодное ревью для архитектуры риск-данных; ECB RDARR Guide требует непрерывного соответствия, что обычно операционализируется через ежегодный цикл + ad-hoc обновления.

Режим B — обновление по триггеру изменения

Каденс: event-driven. Триггеры — конкретные организационные изменения.

Скоуп: узкий — только затронутые CDE ревьюются.

Выход: обновлённые затронутые записи; оценка воздействия; кросс-ссылки повторно валидированы.

Таксономия триггеров:

Примеры триггеров — конкретно для SwiftRide

Триггер: расширение SwiftCapital 3 → 8 стран (Q3)

План: пилот SwiftCapital работает в Мексике + Бразилии + Колумбии (3 страны) T0. Q3 расширение +5 стран (Чили, Индонезия, Филиппины, Вьетнам, Таиланд). Каждая страна — другая лицензия кредитора + другое consumer-credit-законодательство + другая GDPR-эквивалентная приватность + другие country-specific корректировки IFRS 9 ECL-модели.

Обновление до расширения (T-1M):

1. CDO Office издаёт уведомление об обновлении; Risk Officer SwiftCapital + лид Compliance уведомлены.
2. Узкое обновление обнаружения: новые страны → новые продуктовые CDE.
3. Новые кандидаты CDE: swiftcapital_loan_portfolio_country_{XX} на новую страну; country_specific_macro_factors; local_credit_bureau_feeds; country_specific_pd_overlay.
4. Существующие CDE обновлены: business definition swiftcapital_loan_portfolio обновлено (многострановой скоуп); критичность пересчитана (мульти-регуляторный мультипликатор увеличивает D2).
5. Одобрение: сессия Data Council, сфокусированная на расширении SwiftCapital; одобренные записи опубликованы до запуска Q3.

Без триггера: SwiftCapital запускает новые страны; список CDE устарел; инцидент Q3 на борде: «нам не знали, что эти данные кредитов были в скоупе» — material weakness.

Триггер: EU AI Act phase 2 (статутная дата 2 Aug 2026)

План: обязательства EU AI Act Annex III для high-risk effective 2 Aug 2026 (push Digital Omnibus на 2 Dec 2027 неопределён — предполагаем статутную дату).

Обновление до effective (T-6M, T-3M, T-0M):

1. T-6M (Q4 2025): команда Legal идентифицирует high-risk AI-системы SwiftRide: ECL-кредитный скоринг SwiftCapital (Annex III пункт 5(b)); биометрическое совпадение (если 1:N); pricing-движок — кандидат.
2. CDO Office триггерит обновление — затронутые CDE: swiftcapital_loan_portfolio (обучающие данные Article 10); kyc_biometric_match (Annex III биометрия); pricing_engine_features (потенциально Annex III).
3. Возможно потребуются новые CDE: governance Article 10 — отдельный CDE для обучающих наборов, выходов проверки на bias, данных post-market monitoring.
4. Обновление кросс-ссылок: массив applicable_regulations добавляет EU AI Act Annex III + Article 10 на затронутый CDE.
5. Forward-ссылка на контроли (M5): bias-examination контроли; governance документации Annex IV.
6. T-3M: walkthrough Internal Audit; предпросмотр готовности Big 4.
7. T-0M: версия реестра обновлена; контроли Article 10 операционны; регистрация Annex VIII подана.

Триггер: инцидент в стиле SwiftPay 2024 (гипотетическое повторение)

План: инцидент детектирован T+9M: 0.5% дельта сверки в расчёте комиссии; мульти-страна; оценочно $3M недоплачено водителям.

Обновление после инцидента (в течение 30 дней):

1. Триггерится реагирование на инцидент (M8 forward); Big 4 предупреждены (анализ post-IPO 8-K material event).
2. CDO Office издаёт обновление реестра — затронутые CDE: driver_earnings_ledger; commission_rate_per_country; потенциально pricing_engine_features.
3. Поле incident history обновлено в записи реестра; корневая причина связана с задачами ремедиации.
4. Порог материальности повторно валидирован — $3M / pre-tax income — материально по качественному анализу SAB 99 (M1.2).
5. Пробел контролей выявлен (forward к M5); инцидент показывает, что контроль не поймал — требуется переработка контроля.
6. Lineage повторно валидирована — где точка отказа в цепочке trip → earnings → commission → payout.
7. Cross-CDE воздействие: инцидент может сигнализировать аналогичную слабость в других CDE (pricing engine; ad attribution); более широкий sweep, если паттерн повторяется.

Структура ежегодного ревью

Поставки:

• Обновлённый реестр с записями change_history на изменение.
• Ежегодный отчёт о программе (15-20 страниц).
• Дельта методологии — что отличается от прошлого года.
• Письмо независимой оценки Internal Audit.
• Тренды метрик — размер реестра; покрытие; DQ-скоры; завершение аттестации (M7).

Модель зрелости — ad-hoc → planned → встроенный SDLC

Программа CDE созревает через стадии:

Уровень 1 — ad-hoc (Y+1 baseline)

Симптомы: реестр существует; обновление «когда что-то случится»; нет календаря; реактивно.

Риски: быстро устаревает; крупные изменения (новый продукт, M&A) пропускают реестр; material weakness аудита по актуальности.

SwiftRide T+3M — этот уровень.

Уровень 2 — planned (Y+1 — Y+2)

Симптомы: ежегодное ревью в календаре; обновление по триггерам кодифицировано; команда SwiftRide имеет playbook на тип триггера.

Операционно: квартальный цикл Data Council; CDO Office отслеживает календарь.

Цель SwiftRide T+9M.

Уровень 3 — встроенный в SDLC (Y+2 — Y+3, мост M8)

Симптомы: SDLC-шлюзы — новый датасет / новый пайплайн / новый бизнес-процесс требуют проверки кандидатуры CDE на стадии дизайна; обновление реестра CDE — часть «definition of done» для релизов.

Операционно: автоматизированная проверка в PR; pipeline registry hook на создание Airflow DAG; onboarding нового клиента / нового продукта включает checkpoint CDE-impact-review.

Цель SwiftRide T+15M (детали в M8).

Уровень 4 — непрерывный (зрелый — post-IPO Y+2+)

Симптомы: реестр + DQ-запуски + lineage-события питают real-time governance-дашборд; аномалии (отказ DQ / разрыв lineage / устаревший ownership) триггерят автоматизированный workflow.

Операционно: governance-by-default; новые отказы детектируются автоматически; задачи ремедиации отслеживаются в стандартном тикетинге.

Детектирование устаревших CDE

Качество реестра эродировано через устаревание. Сигналы детектирования:

Workflow детектирования:

# scheduled job — еженедельно
stale_cde_check:
  schedule: "0 9 * * 1"  # понедельник 9 утра
  steps:
    - query: "записи реестра со status=maintained"
    - per_entry:
        - check_signals: ["dq_run_recency", "attestation_recency", "owner_alive", "lineage_event_recency", "metadata_recency"]
        - if signals_failed >= 2:
            status_change: "under_review" 
            notification: ["business_owner", "data_steward", "cdo_office"]
            ticket: "registry-staleness-{cde_id}"
    - report: 
        recipients: ["cdo", "data_council"]
        summary: "{n_stale} записей помечены"

Цель SwiftRide T+9M: автоматизированное детектирование устаревших, запускаемое еженедельно; ревью на находку через T+1 неделю; ремедиация на тип сигнала.

Предпросмотр интеграции в SDLC (мост к M8)

M4.7 — каденс обновления операционен. M8 (operating model) строит глубину на интеграции SDLC:

• Шлюз дизайна: новый датасет / новый пайплайн RFC требует проверки кандидатуры CDE.
• Pre-merge проверка: PR, добавляющий source-of-truth пайплайн, триггерит задачу обновления реестра CDE.
• Pre-launch шлюз: чек-лист запуска продукта включает верификацию воздействия на реестр.
• Decommission шлюз: retiring системы триггерит workflow retirement CDE.

M4.7 устанавливает каденс; M8 встраивает его в процесс поставки.

Антипаттерны

”Ежегодного достаточно”

Симптом: программа полагается только на ежегодное ревью; нет change-триггеров.

Почему плохо: расширение SwiftCapital происходит между ревью — реестр устаревает на 6 месяцев; новые продукты запускаются вслепую.

Исправление: ежегодное baseline + триггеры параллельно.

”Триггеры без ежегодного”

Симптом: программа только реактивна; нет календарного ревью.

Почему плохо: дрейф накапливается; нет полного sweep; методология никогда не валидируется повторно.

Исправление: ежегодное + триггеры — оба режима.

”Обновление = обнаружение с нуля”

Симптом: ежегодное ревью повторяет усилие первичного инвентаря полностью.

Почему плохо: выгорание; disengagement команды.

Исправление: ежегодное ревью — инкрементально на baseline; полный пересмотр когда триггер оправдывает.

”Детектирование устаревших без действия”

Симптом: дашборд показывает 5 устаревших CDE; никто не расследует.

Исправление: детектирование устаревших — first-class workflow; тикеты создаются автоматически; SLA на сигнал.

”Обновление по аудиту”

Симптом: обновление только когда Big 4 просит.

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

Исправление: каденс во владении менеджмента; вход аудитора — один сигнал среди многих.

”Забыли про retirement”

Симптом: реестр растёт монотонно; нет записей в retire, даже когда датасеты декомиссионированы.

Исправление: детектирование устаревших + decommission-триггеры + workflow статуса retiring по M4.5.

Календарь каденса SwiftRide Y+1

Итоги

• Два режима обновления: ежегодное ревью (обязательный baseline, calendar-driven, 6-8 недель) + по триггеру (event-driven, узкий скоуп).
• Таксономия триггеров: новый продукт · M&A · регуляторное изменение · инцидент · изменение тулинга · организационное изменение · обновление методологии · аудиторская находка.
• Триггер Q3 SwiftRide: расширение SwiftCapital 3→8 стран — обновление до запуска T-1M.
• Триггер Q2 SwiftRide: EU AI Act Annex III phase 2 Aug 2026 — волны T-6M, T-3M, T-0M.
• Прогрессия зрелости: Level 1 ad-hoc (T+3M baseline) → Level 2 planned (цель T+9M) → Level 3 встроенный SDLC (T+15M, мост M8) → Level 4 непрерывный (зрелый post-IPO Y+2+).
• Детектирование устаревших CDE: сигналы (нет DQ / нет аттестации / мёртвый владелец / нет lineage / нет touches каталога / отказы DQ / только-экспорт доступ); пороги; автоматизированная еженедельная проверка.
• Предпросмотр интеграции SDLC — детали в M8; шлюз дизайна + PR check + pre-launch шлюз + decommission шлюз.
• Антипаттерны: только-ежегодное; только-триггеры; обновление = обнаружение с нуля; детектирование устаревших без действия; каденс по аудиту; забывание retirement.
• Календарь SwiftRide Y+1 — Q1 ежегодное + Q2 AI Act + Q3 SwiftCapital + Q4 pre-audit + ad-hoc.
• Следующий урок (M4.8): Лаба — построить mini-CDE registry в OpenMetadata для 5 CDE SwiftRide с регуляторным маппингом + кросс-ссылками.