The Day I Realized Data Governance Was My Job (Even Though Nobody Said So)

📖 Источник: medium.com

День, когда я поняла, что управление данными — это моя работа (хотя никто мне об этом не сказал)

Краткое введение

Автор статьи — Aline Oliveira, data engineer — делится личным опытом осознания того, что в небольшой команде именно она стала ответственной за построение системы управления данными (data governance). Это произошло не по назначению сверху, а потому, что проблемы с доступом к данным, GDPR-соответствием и региональными ограничениями начали накапливаться, и некому было их решать. Статья представляет практическое руководство для data engineers и аналитиков, которые оказались в аналогичной ситуации.

Как начинается проблема

Большинство команд не начинают с готовой системы управления данными. Проблемы возникают постепенно:

Дашборд нужно расшарить большему количеству пользователей
Датасет внезапно должен пересечь региональные границы
Название компании может оказаться личным идентификатором (например, «ИП Иван Иванов» — это и название компании, и персональные данные одновременно)

Изначально команда находит временные решения. Но со временем вопросы становятся сложнее:

Почему разные регионы не видят одни и те же данные?
Аналитики не знают, что им разрешено передавать другим
Вопросы от compliance приходят не в юридический отдел, а в команду данных
Анонимизацию приходится делать в спешке перед дедлайном

Именно в этот момент приходит осознание: системы управления данными нет, и почему-то именно вы должны её построить.

Настоящая проблема не в данных

Автор изначально думала, что проблема техническая — нужны функции row-level security, анонимизации, группы доступа в Metabase. Но настоящая проблема оказалась в другом: никто никогда не определял, кто должен видеть какие данные и почему.

Это произошло не из-за халатности — просто система никогда не требовала формальных правил. Данные передавались по запросу, доступ предоставлялся «по здравому смыслу». Никто не задавал вопросы:

Пересекает ли это региональную границу?
Является ли это поле PII по GDPR?
Какое у нас обоснование, если будет аудит?

До тех пор, пока эти вопросы не стали обязательными.

Триггер: дашборд с названиями компаний

Переломный момент наступил, когда понадобилось расшарить операционные данные менеджерам из нескольких регионов. Дашборд содержал названия компаний. И здесь оказалось, что названия компаний могут быть персональными данными — если это индивидуальный предприниматель («ИП Петров» — одновременно и компания, и личный идентификатор).

Ситуация обнажила несколько проблем:

Metabase работала на open-source плане без автоматического row-level security
Сотрудники из Европы получали доступ к данным из США без документированного правового основания
Общий Google Form выполнял функции целой системы управления доступом
Система была хрупкой и становилась ещё более уязвимой по мере роста команды

Фаза перегрузки

Автор описывает, что изучение data governance оказалось сложнее, чем ожидалось. Нужно было одновременно разбираться в:

GDPR (General Data Protection Regulation)
LGPD (Lei Geral de Proteção de Dados, бразильский аналог)
CCPA (California Consumer Privacy Act)
Требованиях к трансграничной передаче данных
Standard Contractual Clauses (стандартные договорные условия)
Принципах минимизации данных
Рисках повторной идентификации
Сроках уведомления о breaches (72 часа для GDPR)

Несколько недель ушло на то, чтобы постоянно быть «одним поиском» от понимания, но так и не достичь его.

Ключевое понимание, которое помогло двигаться дальше: не нужно становиться юристом. Governance — это не пункт назначения, а набор решений, задокументированных достаточно понятно, чтобы другие могли ихFollow.

Практические шаги

1. Определение уровней доступа

Первый шаг — ответить на главный вопрос: кто actually нуждается в этих данных и зачем?

Были определены три уровня доступа:

Глобальный: сотрудники с бизнес-обоснованием для кросс-регионального доступа
Региональный: сотрудники с доступом только к данным своего региона
Функциональный: кросс-региональный доступ, но только к агрегированным данным без PII, с задокументированным use case

После создания этой структуры каждый запрос на доступ получил чёткое место для рассмотрения.

2. Принцип «no PII by default»

Вместо фильтрации чувствительных данных на уровне дашбордов (что подвержено ошибкам) автор начала создавать refined views в data warehouse, где чувствительные поля удалялись до того, как данные попадают в Metabase.

Это подход privacy by design (приватность при проектировании), а не privacy by cleanup (приватность при очистке).

3. Форма запроса доступа

Форма запроса была введена не как бюрократический инструмент, а как способ внедрить acknowledgment (подтверждение) использования данных. Форма содержала текст:

> «Вы подтверждаете, что понимаете, к каким данным получаете доступ, зачем они вам, и что вам запрещено с ними делать»

Когда пользователи явно подтверждают это, ответственность перемещается туда, где она должна быть — к человеку, который получает доступ.

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

Сложная часть: никто не празднует

Самый сложный аспект построения data governance в небольшой команде — отсутствие признания:

Нет момента запуска
Нет «выкатки фичи»
Недели уходят на написание политик, которые большинство просмотрит по диагонали
Формы ощущаются как трение
Разговоры начинаются с вопроса «нам действительно нужно это делать?»

Ответ — всегда да. Потому что альтернатива — не свобода, а уязвимость.

GDPR breach требует уведомления в течение 72 часов
Аудит не интересует, что команда была маленькой и двигалась быстро

Автор пришла к пониманию: governance строится не для замедления работы, а для защиты доверия, которое делает всю операцию возможной.

Текущее состояние и планы

Команда движется от ручного Google Form к автоматизированному pipeline:

Обязательное обучение по обработке данных
Формальное подтверждение через DocuSign
Запросы доступа через ticketing system
Каждый шаг логируется, каждое одобрение отслеживается

Governance никогда не будет «готово». Но теперь оно задокументировано, обосновано, и каждый новый сотрудник, новый дашборд, новый кросс-региональный запрос имеют чёткий путь.

Цель — не совершенство, а система, достаточно спокойная для масштабирования.

Практические выводы

Большинство команд не думают о governance, пока что-то не заставит их:

Регуляторный вопрос
Запрос от legal
Дашборд внезапно нужно расшарить 200 людям в 6 регионах

Не нужна выделенная команда compliance, чтобы начать. Нужны:

Определение того, кто должен получать доступ к каким данным и почему
Задокументированное правило о том, что считается PII в вашем контексте
Способ фиксировать acknowledgment при предоставлении доступа
Квартальная привычка проверять, что построенное всё ещё имеет смысл

Сложность придёт. Но если фундамент построен до появления давления, вы будете решать реальные проблемы вместо того, чтобы от них убегать.

Data governance — не самая захватывающая часть работы с данными. Но это, возможно, самая важная часть, которую вы ещё не делаете.

📢 Информация предоставлена телеграм-каналом: Data&AI Insights

🤖 Data&AI Insights - Ваш источник инсайтов о данных и ИИ