За рамками комплаенса: как спроектировать системы, которым клиенты доверяют

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

1. Согласованность намерений клиента во всех системах
2. Рассмотрение конфиденциальности как проблемы распределённых систем
3. Сокращение ненужных данных
4. Проектирование с учётом отказов
5. Понимание того, как ИИ расширяет границы доверия

Ниже я подробно остановлюсь на каждом из этих пунктов и поделюсь своим опытом, объяснив, почему они важны в реальных системах. Для директоров по информационной безопасности (CISO) и других руководителей в сфере безопасности эти идеи помогут преобразовать общие цели конфиденциальности и доверия в конкретные приоритеты для архитектуры, управления, защиты данных и операционных рисков.

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

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

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

Регулирование подтолкнуло инженерию в правильном направлении. Статья 25 GDPR закрепила идею защиты данных по замыслу (privacy by design) и по умолчанию, а Принципы конфиденциальности NIST рассматривают конфиденциальность как проблему управления рисками, которую следует учитывать при построении систем. Я считаю, что оба этих подхода являются важными сдвигами, поскольку они приближают конфиденциальность к архитектурным и инженерным решениям. Но на практике программы конфиденциальности всё ещё могут сосредотачиваться на доказательстве существования контроля: получено ли согласие? Кто имеет доступ к данным? Можем ли мы обрабатывать запросы на удаление? Эти вопросы важны, но они всё ещё в основном касаются соблюдения требований. Более сложный вопрос — продолжает ли система уважать намерения клиента после того, как данные прошли через множество сервисов, уровней хранения, конвейеров и конечных потребителей. При проектировании или анализе потока данных я считаю особенно полезным один вопрос: «Если намерение клиента изменится здесь, где ещё может сохраниться старое намерение?» Он заставляет выйти за рамки обсуждения наличия контроля и перейти к тому, как система на самом деле ведёт себя.

Доверие нарушается на границах систем

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

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

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

Меры контроля конфиденциальности должны быть спроектированы с учётом отказов

Ещё один урок, который я извлёк из эксплуатации крупномасштабных систем, заключается в том, что не следует проектировать только для сценария «счастливого пути» (happy path). В инженерии надёжности мы регулярно задаёмся вопросом, что произойдёт, если зависимость выйдет из строя, сообщение задержится или сервис станет недоступен. Аналогично следует анализировать и меры контроля конфиденциальности. Что произойдёт, если система не сможет определить последнее состояние согласия? Что произойдёт, если запрос на удаление выполнен в большинстве систем, но не удался в одном нижестоящем сервисе? Что произойдёт, если старое событие придёт после того, как клиент изменил предпочтение? В масштабе такие ситуации становятся нормальными рабочими условиями, и руководителям служб безопасности необходимо знать, как система должна вести себя при их возникновении.

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

Это также означает, что конфиденциальность нуждается в собственной наблюдаемости. Мы тратим много усилий на мониторинг доступности, задержек и частоты ошибок, но я считаю, что меры контроля конфиденциальности должны иметь аналогичные операционные сигналы. Сколько времени требуется для того, чтобы изменение предпочтений дошло до нижестоящих систем? Где происходят сбои запросов на удаление? Какие системы всё ещё зависят от данных, которые уже должны были быть выведены из эксплуатации? Без такой видимости команды могут знать, что меры контроля конфиденциальности существуют, но при этом иметь очень низкую уверенность в том, как они ведут себя в производственной среде. Для CISO это важно понимать: конфиденциальность — это не только периодический аудит, но и измеримый показатель в рамках повседневного здоровья системы.

ИИ расширяет границы доверия

Я наблюдал, как эта граница доверия расширяется с течением времени. В период 2015–2020 годов системы персонализации и рекомендаций становились всё более сложными, объединяя всё больше сигналов от клиентов для повышения релевантности и качества взаимодействия. С появлением больших языковых моделей (LLM), а теперь и агентных систем, эта граница расширяется гораздо быстрее. Традиционное приложение может читать данные из известной базы данных или вызывать определённый API. Система ИИ может извлекать информацию из документов, записей клиентов, предыдущих взаимодействий или других инструментов, объединять эту информацию и, что всё чаще, совершать на её основе действия. Это делает границу доверия невероятно широкой. Для CISO, инженеров, аудиторов и команд безопасности вопрос больше не в том, «Кто может получить доступ к этим данным?», а скорее в том, «Какую информацию эта система может извлечь, объединить и на основе каких данных действовать?»

Масштаб этого сдвига уже очевиден. Исследование Cisco 2026 года по вопросам данных и конфиденциальности показало, что 90% опрошенных организаций расширили свои программы конфиденциальности из-за ИИ, а 93% планируют увеличить инвестиции в конфиденциальность и управление данными в ближайшие два года. Я вижу в этом признак того, что управление ИИ нельзя отделять от управления данными. Прежде чем руководители служб безопасности задумаются о контроле над моделями, им необходимо понять, к каким данным имеет доступ система ИИ, как этот доступ авторизован, и продолжают ли действовать те же правила конфиденциальности, когда информация извлекается, объединяется или используется для совершения действия. Риск выходит за рамки «слишком много данных»; он также в том, что клиенты могут не понимать, как их информация используется после того, как в дело вступает ИИ. Взаимодействие со службой поддержки, документ или прошлая транзакция могли быть собраны для одной цели, но система ИИ может сделать эту информацию полезной в совершенно другом контексте — и именно там доверие может быстро разрушиться. Для меня практический вопрос заключается в том, сохраняются ли первоначальные ожидания клиента, когда данные повторно используются системой ИИ. Если ответ неясен, архитектура и модель управления требуют доработки, прежде чем функция будет масштабироваться.

Превращение доверия в приоритет CISO

Я думаю, практический вывод состоит в том, чтобы сделать доверие клиентов частью процесса проверки системы, а не просто пунктом в ходе проверок на соответствие требованиям. При анализе нового потока данных, возможностей ИИ или функции, ориентированной на клиента, я бы задавал несколько базовых вопросов: какие данные клиента используются? Зачем они нужны? Насколько свежими должны быть предпочтения клиента? Куда эти данные могут перемещаться или копироваться? Классифицированы ли данные и аннотированы ли они, чтобы нижестоящие системы знали, как с ними обращаться? Что произойдёт, когда мера контроля конфиденциальности выйдет из строя? И можем ли мы наблюдать, действительно ли система ведёт себя так, как мы задумали? Один практический подход, который, как я видел, хорошо работает в крупных распределённых системах, — это прикрепление правильных метаданных безопасности и конфиденциальности к самим данным. Например, классификация может помочь идентифицировать конфиденциальные данные, метаданные о хранении могут определять, как долго их следует хранить, а политики маршрутизации могут определять, куда этой информации разрешено перемещаться. Это становится особенно полезным, когда одни и те же данные проходят через множество сервисов, поскольку контроль не полностью зависит от того, что каждая нижестоящая команда помнит первоначальное намерение.

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