Роман с Data Science. Как монетизировать большие данные - читать онлайн книгу. Автор: Роман Зыков cтр.№ 54

Под утечкой данных я понимаю выход каких-либо персональных данных за периметр безопасности внутри компании. Причем сама утечка может произойти и внутри компании, когда доступ к данным получают сотрудники, у которых его быть не должно. Посмотрим, как это получается. При проектировании хранилища данных контакты (телефон и email) и имя клиента часто хранятся в виде обычного текста. Чтобы минимизировать риски, эти данные должны быть зашифрованы, например хэш-функцией. Тогда не будет проблем с утечкой персональных данных из хранилища. Если же технической поддержке потребуется узнать причины проблемы по какому-либо из клиентов с известным email, им потребуется захешировать его, и тогда можно будет работать с хранилищем напрямую, используя этот хеш. Конечно, это очень неудобно – например, при составлении списка клиентов для рассылки придется предусмотреть отдельную операцию восстановления email. Но безопасность того стоит.

В нашу эпоху тотальной цифровизации проблема безопасности данных очень актуальна. Современный взломщик больше не ломает двери и не взрывает сейфы – ему нужно получить несанкционированный доступ и незаметно скопировать нужные данные. Причем необязательно это будут адреса, имена, пароли и явки – это могут быть простые тексты. Например, сообщение или письмо, содержащее информацию о человеке, и даже часть аудиозаписи из голосового помощника. Например, в статье «The Dark Side of Our Voice Assistants» [98] поднимается вопрос, что часть аудио, которое не было распознано автоматически, отправляется людям (сервис наподобие Яндекс. Толока) на расшифровку. Записи им вроде бы передаются в анонимизированном виде, но там можно встретить информацию, которую клиенты точно не хотели бы раскрывать. Обычно голосовые помощники активируются только после определенных слов (wake-word) и лишь после этого начинают транслировать ваш голос через интернет для распознавания. Чтобы проверить это, исследователи сделали проект и написали статью «LeakyPick: IoT Audio Spy Detector» [99]. Проект LickyPick детектировал отправку даже зашифрованных аудиосообщений от голосовых помощников, его авторам удалось обнаружить еще 89 «ошибочно» активирующих слов для колонки Amazon.

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

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

Экс-аналитик Amazon Андреас Вейгенд (Andreas Weigend) написал книгу «Data for the People», посвященную данным. Вот что он говорит о конфиденциальности данных пользователей:

Это цитата из интервью Андреаса 2005 года [100] – прошло полтора десятка лет, а воз и ныне там.

По сути между компаниями и их клиентами есть негласный договор на использование данных, пункты которого становятся все яснее со взрослением рынка и образованием клиентов, – я согласен с Андреасом, что обучение необходимо. На мой взгляд, основы безопасности данных пора преподавать в школах. Законы о персональных данных заставляют компании выводить соглашения о конфиденциальности (privacy policy) на сайтах. Уже небезызвестный нам «Privacy project» провел исследование таких соглашений «Мы прочитали 150 соглашений конфиденциальности. Это непостижимая катастрофа» (We Read 150 Privacy Policies. They Were an Incomprehensible Disaster) [101]. Они проанализировали размер и читабельность соглашений о конфиденциальности 150 сайтов и приложений. Каковы были результаты этого исследования – ясно уже из заголовка статьи. Самое понятное соглашение оказалось у BBC – чтобы разобраться с ним, достаточно школьного образования и 15 минут времени. А вот соглашение, которое предлагает Airbnb, требует юридического образования и 35 минут на чтение. Сами соглашения стали читабельнее после введения закона GDPR в ЕС, но в целом «написаны юристами для юристов. Они не создавались как инструмент для пользователя» [101]. И часто в них есть техническая информация про сбор данных, но нет ни слова о передачи их третьей стороне, что напрямую затрагивает пользователя. Рекомендую ознакомиться с этой статьей, там отличная инфографика и анимация.

У аналитиков данных и ML-специалистов тоже есть свои негласные этические нормы. Самое первое из них – никогда не использовать данные для получения личной пользы или удовлетворения собственного любопытства. Единственная ситуация, в которой можно работать с конкретными персоналиями, – это техническая поддержка. Мы (аналитики данных) имеем довольно серьезный доступ к конфиденциальным данным клиентов, не составляет большого труда найти какую-то персону и поднять всю ее историю в данных. Есть такой термин «LOVEINT» (love intelligence) – он возник, когда разразился скандал с сотрудниками NSA (Агентства Национальной Безопасности США) в 2013 году [102]. Выяснилось, что они использовали шпионские технологии для слежения за своими близкими или бывшими близкими. Так вот, никогда и ни при каких обстоятельствах так делать нельзя. Любые запреты и ограничения доступа к данным можно обойти, поэтому хорошо, когда есть внутренний этический запрет.

Кроме того, недопустимо халатное отношение к персональным данным. Это значит – нельзя передавать и хранить их внутри компании вне периметра безопасности, например, через публичные email-сервисы. Соблюдение этого правила сильно уменьшит вероятность непреднамеренной утечки.

И, конечно, не следует вносить в модели спорные фичи, такие как пол, расу, признаки тяжелых болезней, возраст и другие. В России эта повестка пока не полыхает так, как в Америке, но после Black Lives Matter и Time’s Up специалисты, занимающиеся искусственным интеллектом, не могут ее обойти. На одном из семинаров Эндрю Ына рабочие группы тоже пытались сформулировать этические нормы [103]. Потому что причиной смещенности датасета часто оказываются предрассудки в обществе – интересный материал на эту тему был опубликован в Harvard Business Review «What Do We Do About the Biases in AI?» [104]. Там описан такой случай: в 1988 году Британская комиссия по расовому равенству обнаружила дискриминацию в высшем медицинском учебном заведении. Компьютерная программа, которая определяла, каких заявителей пригласить на интервью, пессимизировала женщин и людей с неевропейскими именами. При этом ее точность после обучения достигала 90–95 %. Проблема не в программе, а в датасете, который создали люди, раньше принимавшие решения, а машина просто обнаружила и повторила закономерность. Бороться с этим смещением не так просто, но возможно. Например, добиваться диверсификации в собственной команде. В российских реалиях как минимум создавать равные условия при найме мужчинам и женщинам.