«Просто пришлите выгрузку»: что уходит, что обезличивается, что остаётся внутри

Просьба звучит буднично, и в этом вся сложность:

«Коллеги, добрый день. Скиньте, пожалуйста, сырые данные по сентябрьскому исследованию — нужно для отчёта. Хорошо бы сегодня, в понедельник уже презентация».

Отправитель — человек из соседнего подразделения. Не злоумышленник, не посторонний, вполне себе коллега с понятной задачей. Просьба звучит как мелочь: выгрузить таблицу и прикрепить файлом, минут пять работы.

Сложность в том, что слово «просто» здесь неверное. И в том, что до понедельника надо успеть объяснить почему — так, чтобы человек не решил, что от него что-то скрывают.

Слово «сырые» каждый понимает по-своему

Прежде чем обсуждать границы, стоит разобраться с формулировкой запроса. Она почти всегда врёт — не нарочно, а по устройству.

Для лаборанта «сырые данные» — это то, что вышло из прибора до всякой обработки: файл с показаниями, в котором ещё нет ни нормализации, ни отбраковки.

Для аналитика — это построчная таблица: одна строка на участника, все поля на месте, считать можно как угодно.

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

Три разных запроса одной фразой. И они требуют трёх разных ответов, из которых только один связан с персональными данными вообще.

Поэтому первый ход в таком разговоре — не про доступ. Он про то, что человек собирается с этими данными делать. Не из вежливости и не ради проверки: без ответа на этот вопрос вы будете обсуждать границы для выгрузки, которая, возможно, никому не нужна.

«Это конфиденциально» — не ответ

Первое, что приходит в голову, — сослаться на конфиденциальность. Одно слово, звучит весомо, закрывает разговор.

Оно действительно закрывает разговор. Дальше происходит одно из трёх, и все три плохие.

Человек решает, что его подозревают в чём-то нехорошем, и обижается. Отношения между отделами становятся чуть хуже, и в следующий раз, когда вам понадобится что-то от него, вы это почувствуете.

Или он идёт в обход. Спрашивает у другого сотрудника, который не в курсе переписки, формулирует помягче — «мне буквально пару цифр посмотреть» — и получает файл. Ваша граница при этом никуда не делась, просто данные прошли мимо неё.

Или он приносит задачу наверх: «мне не дают данные, из-за этого срывается отчёт». И там разговор пойдёт уже не про защиту данных, а про то, почему подразделение мешает работать.

Причина всех трёх исходов одна. «Конфиденциально» — это не граница, а стоп-слово. Граница объясняет, где именно проходит линия и что можно по эту сторону. Стоп-слово объясняет только то, что дальше нельзя, — и провоцирует поискать другую дверь.

Границ на самом деле три, они разные и отвечают на разные вопросы.

Граница первая: кто спрашивает и на каком основании

Не «кто он по должности». Должность не даёт прав на данные: руководитель соседнего отдела не имеет автоматического доступа к персональным данным клиентов только потому, что он руководитель.

Вопрос в основании. Их немного, и они хорошо различимы.

Внутренняя рабочая задача. Человек делает работу, которая требует этих данных, и его доступ предусмотрен ролью. Здесь вопрос сводится к тому, входят ли конкретные поля в его роль — и часто выясняется, что входит половина.

Обязательство по договору. Партнёр, заказчик исследования, подрядчик. Тут есть документ, и в документе написано, какие данные и в каком виде передаются. Читать его неприятно, но это единственный способ не спорить потом.

Внешний запрос. Всё остальное: журналист, исследователь из другой организации, бывший сотрудник, любопытный знакомый. По умолчанию — нет, и это нормальное «нет», не требующее оправданий.

Практический приём: вместо «зачем вам это» спросить «для какой задачи и в каком виде результат должен попасть в отчёт». Формулировка звучит как помощь, а не как проверка, и даёт больше — из ответа обычно видно, что человеку нужны не сырые данные вовсе.

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

Граница вторая: что именно лежит в этих данных

«Сырые данные» — это не один объект. Это несколько слоёв, у которых разная чувствительность, и складывать их в одну корзину — главная ошибка.

Прямые идентификаторы. ФИО, телефон, электронная почта, номер полиса, номер договора. Тут всё очевидно, их убирают первыми, и именно этот шаг большинство считает обезличиванием.

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

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

Служебные поля. Кто выполнял, на каком оборудовании, какая версия методики, комментарии лаборанта. Эти поля почти никогда не нужны внешнему адресату, зато регулярно уезжают вместе с выгрузкой просто потому, что были в таблице.

Разложив запрос по слоям, обычно обнаруживаешь простую вещь: человеку нужен третий слой, а просил он все четыре — потому что не знал, что их четыре.

Граница третья: в каком виде и куда

Третья граница самая скучная и при этом самая часто нарушаемая. Она про транспорт и срок жизни.

Один и тот же набор данных, отправленный по-разному, — это разные риски. Файл в рабочем чате останется в этом чате навсегда, и через год его увидит человек, которого добавят в группу. Ссылка на облачное хранилище с доступом «по ссылке» разойдётся по почте. Архив на флешке переживёт всех.

Поэтому к выгрузке прилагаются четыре решения, а не одно.

Канал — через что уходит. Срок — сколько живёт доступ, и кто его закроет. Пометка — есть ли в файле явное указание, что это за данные и кому их нельзя пересылать. И след — записано ли где-то, что такого-то числа такой-то набор ушёл такому-то человеку.

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

Почему вычеркнуть фамилии — ещё не обезличивание

Это место, где ошибаются чаще всего, и ошибаются искренне.

Удалили колонку с ФИО, удалили телефон — кажется, данные стали безличными. На деле осталась таблица, в которой каждая строка — это по-прежнему конкретный человек, просто без подписи. Восстановить подпись иногда можно за одну минуту.

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

Редкие значения. Если в выгрузке есть исследование, которое за месяц делали четыре раза, и известен филиал, — круг сужается мгновенно. Редкость сама по себе является идентификатором. Это касается не только диагнозов: редкая профессия, редкий возраст для этой процедуры, нетипичное время визита.

Время. Дата и время с точностью до минуты — почти уникальный ключ. Человек, который знает, что его коллега был в лаборатории в среду утром, найдёт его строку без всякой фамилии.

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

Что с этим делают на практике — приёмы простые и работают.

Даты огрубляют: вместо точной даты рождения — год, вместо года — возрастная группа. Вместо времени визита — день. Географию поднимают на уровень выше: не индекс, а город или район. Редкие значения объединяют в категорию «прочее» или вовсе исключают. И главное — проверяют результат обратным вопросом: сколько человек в этой таблице описываются ровно одной строкой, отличимой от всех остальных? Если такие есть, обезличивание не закончено.

Здесь есть неприятный компромисс, который надо проговаривать вслух: чем сильнее огрубление, тем меньше пользы. Таблица, обезличенная до полной безопасности, иногда перестаёт отвечать на тот вопрос, ради которого её просили. Об этом лучше сказать сразу и спросить, какая точность действительно нужна, — а не отдать бесполезное и считать задачу закрытой.

Проверка на одну строку

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

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

Если в какой-то группе оказалась одна строка — этот человек в выгрузке уникален. Тот, кто знает про него эти четыре обычные вещи, узнает про него и всё остальное: результат, повторные визиты, что там написано в комментарии.

Если в группах по две-три строки — уже лучше, но всё ещё близко к определению: третий лишний мало что скрывает, особенно если известно что-то ещё.

Дальше начинается ремесло. Огрубить возраст до пятилетних интервалов. Свести район к городу. Дату визита — к неделе. После каждого шага пересчитывать группы. Обычно два-три огрубления убирают все одиночные строки, и это видно на цифрах, а не на ощущениях.

Полезная привычка: делать эту проверку не на своих данных, а на своих данных глазами того, кто получит файл. Что он и так знает о людях в этой таблице? Внутренний коллега знает больше, чем внешний исследователь, — и для него безопасная выгрузка выглядит иначе.

Разбор: пятница, 17:50

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

Запрос пришёл в общий чат. Помощник, который там дежурит, не решает, отдавать или нет, — он собирает состав запроса и показывает его тому, кто решает. Вот как выглядела переписка.

17:50, Андрей (маркетинг): «Коллеги, добрый день. Скиньте, пожалуйста, сырые данные по сентябрьскому исследованию — нужно для отчёта. Хорошо бы сегодня, в понедельник презентация».

17:51, помощник: «Добрый вечер, Андрей. Соберу. Чтобы не гонять туда-сюда, уточню два момента.

Первый: что должно оказаться в презентации — распределение по показателям, динамика по неделям, что-то ещё? От этого зависит, в каком разрезе выгружать.

Второй: презентация остаётся внутри или показывается заказчику?»

17:56, Андрей: «Показываю заказчику. Нужна динамика по неделям и разбивка по филиалам, чтобы видно было, где выборка набралась быстрее».

17:57, помощник: «Понял, спасибо. Тогда так.

Динамика по неделям и по филиалам — это агрегированные данные, их отдаю сразу, готовлю за полчаса. Таблица будет: неделя, филиал, количество, средние значения по трём показателям.

Построчную выгрузку в этот набор не включаю. В ней есть дата рождения, пол, индекс и время визита — по такой комбинации участники определяются, а по договору с заказчиком мы передаём только агрегат. Если построчные данные действительно нужны для встречи, скажите — запрос пойдёт через Ирину Сергеевну, она отвечает за передачу по этому договору. Это не долго, но за пятницу вечером не успеем.

Отдельно: в исходной таблице есть поле с комментариями лаборантов, там встречаются бытовые подробности про людей. Его не будет ни в одной выгрузке, даже во внутренней.

Файл пришлю в рабочее хранилище, доступ открою вам на две недели. Так пойдёт?»

18:03, Андрей: «Агрегата хватит, построчные не нужны были, я просто по привычке попросил всё. Спасибо, что разложил».

В понедельник презентация состоялась. Никто никуда не ходил в обход, и никто не обиделся.

Что здесь сработало. Помощник не сказал «нельзя» — он сказал, что можно, и что нужно сделать, чтобы стало можно большее. Он назвал конкретную причину — комбинация полей, а не абстрактную «защиту данных». Он назвал имя человека, который принимает решение о большем, — и тем самым не оставил запрос в тупике. И он сделал видимым то, о чём Андрей не подозревал: поле с комментариями лаборантов.

Последнее, кстати, самое ценное. Андрей не собирался получать бытовые подробности о пациентах. Он просто попросил «сырые данные» — и получил бы их вместе со всем остальным.

Формула отказа, после которого остаются в хороших отношениях

Если отдать нельзя, отказ состоит из четырёх частей. Пропуск любой из них портит остальные три.

Что именно нельзя. Не «данные», а конкретно: построчную выгрузку с датами рождения. Человек должен понимать границу, а не её тень.

Почему. Одной фразой, по делу. «По договору передаём только агрегированные показатели». Или: «По этой комбинации полей участники определяются». Причина без ссылки на документ звучит как каприз, ссылка без причины — как отписка.

Что можно вместо. Самая важная часть. Отказ без альтернативы читается как «уходи», и именно после него идут в обход.

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

«Нужно сегодня» как отдельный аргумент

Про срочность стоит сказать отдельно, потому что она ломает границы надёжнее любых уговоров.

Механика простая. Когда времени нет, любая проверка выглядит препятствием, а не работой. Человек, который просит данные к понедельнику, не спорит с вашими принципами — он просто спрашивает, нельзя ли в этот раз побыстрее. И «в этот раз» звучит разумно, потому что случай действительно частный.

Дальше срабатывает эффект, знакомый всем: тот, кто отказывает под давлением срока, чувствует себя виноватым. Не потому, что не прав, а потому что из-за него у коллеги проблема. И начинает искать компромисс там, где компромисса быть не должно.

Помогает одна перестановка. Не обсуждать, отдавать или нет, под давлением срока — а сначала назвать, что можно отдать прямо сейчас, без всяких согласований. Почти всегда что-то такое есть: агрегат, срез, выборка по разрешённым полям. Когда у человека на руках появляется хоть что-то, срочность спадает, и остальное обсуждается спокойно.

И обратная сторона, о которой неприятно думать. Если у вас регулярно просят данные в пятницу в 17:50, дело не в неорганизованности коллег. Дело в том, что обычный путь получения данных настолько долгий, что им никто не пользуется. Границы, которые обходят из-за срока, — это чаще всего границы без нормальной двери.

Кто здесь что решает

Стоит проговорить разделение ролей, потому что его часто понимают неправильно.

Помощник в этой схеме не решает, отдавать данные или нет. Он не имеет для этого ни полномочий, ни оснований — решение о передаче персональных данных принимает человек, который за это отвечает.

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

Это звучит скромно, но снимает основную часть проблемы. Потому что в реальности данные утекают не после сознательного решения, а по невнимательности: выгрузили «как есть», не посмотрели, какие поля в таблице, отправили файлом в чат, забыли. Между «злой умысел» и «утечка» почти всегда лежит обычная пятница в 17:50.

Данные, которые не отдают и обезличенными

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

Когда данных мало. Обезличивание работает на объёме. Если в выгрузке сорок строк, любое огрубление либо не спасает от определения людей, либо убивает смысл данных. В маленьких наборах честный ответ часто — «обезличить нельзя, можно только агрегат», и это не отговорка, а арифметика.

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

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

И самое частое. Всё описанное бесполезно, если в организации нет ответа на вопрос, кто отвечает за передачу данных по этому конкретному договору. Тогда любая граница держится на бдительности того, кто в этот момент оказался у клавиатуры, — а бдительность в пятницу вечером работает хуже, чем в понедельник утром.

Три вопроса вместо одного слова

Если свести всё к практике, при любом запросе на данные имеет смысл задать себе три вопроса подряд.

Кто спрашивает и на каком основании. Что именно лежит в этих полях, кроме того, что видно в заголовках. И в каком виде это уйдёт — через что, насколько, с какой пометкой.

Ни на один из них слово «конфиденциально» не отвечает.

И последнее наблюдение, довольно приземлённое. Почти все выгрузки, из-за которых потом возникают неприятности, отправлялись не после спора и не в обход правил. Они отправлялись быстро, из лучших побуждений и с формулировкой «да не вопрос, сейчас скину».

Там, где есть кому задать эти три вопроса до отправки, обычно нечего разбирать после.