Как говорить о безопасности и закрытом контуре

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

Если к этому разговору не готов:

• ИТ-директор легко «зарубит» инициативу фразой «нам это небезопасно»;
• безопасность будет воспринимать AI как угрозу, а не как инструмент;
• сам сотрудник будет бояться поднимать тему, чтобы не «наломать дров».

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

Что важно понять

1. Безопасность — это часть ценности, а не препятствие

Важно сместить фокус:

«Безопасность — это не „помеха для AI", а условие, при котором AI вообще возможен в вашем контуре».

Для многих клиентов:

• соблюдение требований ФЗ-152;
• ограничения по хранению и передаче данных;
• контроль доступа и действий пользователей —

не опция, а обязательное условие. Если вы это признаёте и разделяете, вы автоматически становитесь союзником ИТ и ИБ, а не «продавцом опасностей».

2. Ваша роль — не объяснять криптографию, а перевести диалог в управляемую плоскость

От вас не ждут детального объяснения DLP-систем, шифрования или архитектуры решения. От вас ждут, что вы:

• не будете предлагать заведомо небезопасные варианты;
• честно скажете, какие форматы поставки вообще существуют (в контуре клиента, в частном облаке, с ограничением данных и т. д.);
• пригласите к разговору тех, кто может детально обсудить архитектуру и риски.

Хорошая внутренняя установка:

«Моя задача — связать бизнес-потребность и требования по безопасности, а детали мы разберём вместе с нашими и их ИТ-специалистами».

Основные вопросы, которые волнуют ИТ и безопасность

Когда ИТ-директор или служба безопасности слышат «AI», у них в голове чаще всего всплывают четыре вопроса:

1. Куда уйдут данные? Будут ли они отправляться во внешний сервис? Есть ли риск, что чужие модели будут учиться на наших данных?
2. Где будет работать решение? Внутри инфраструктуры клиента (в его дата-центре, в частном облаке)? В публичном облаке? В каком именно?
3. Что именно будет обрабатываться? Есть ли там персональные данные? Коммерческая тайна, финансовая информация, критичная инфраструктура?
4. Кто контролирует доступ и действия? Как разграничиваются права пользователей? Можно ли отслеживать, кто к чему обращался и какие действия выполнял?

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

Как можно отвечать на вопросы про безопасность

1. Про место обработки и хранения данных

Если в портфеле есть варианты развёртывания в контуре клиента или в частном облаке, можно говорить так:

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

Если речь идёт о смешанной схеме (часть в облаке, часть у клиента):

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

2. Про персональные данные и ФЗ-152

Вместо общих слов «всё по закону» лучше привязаться к понятной логике:

«Мы изначально исходим из требований ФЗ-152 и внутренних политик ИБ. Варианты есть: не выносить персональные данные за пределы вашего контура; использовать маскирование или обезличивание; ограничить набор полей, которые попадают в AI-модуль. Конкретные настройки мы согласовываем с вашей службой безопасности на этапе проектирования».

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

3. Про публичные сервисы и «проброс» данных наружу

Если клиент боится, что данные «утекут» в публичные модели:

«Мы не предлагаем просто подключить публичный сервис и передавать туда ваши реальные данные. Речь идёт о корпоративном решении, где вы контролируете, какие данные в принципе доступны системе; информация не используется для обучения внешних моделей; доступ к данным и действия пользователей фиксируются и управляются».

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

4. Про ответственность и контроль

Типичный страх ИТ и ИБ — «AI будет что-то делать, а мы не будем контролировать процесс». Полезно говорить так:

«Мы не предлагаем „чёрный ящик", который сам что-то решает и меняет в ваших системах. Архитектура строится так, чтобы можно было ограничить, где AI только подсказывает, а где выполняет действия; у вас оставалась возможность контроля и отката; ключевые операции по-прежнему проходили через ваши регламенты и права доступа».

Если речь про более «сильную» автоматизацию, важно подчеркнуть, что:

• сценарии действий заранее описаны и согласованы;
• есть журналы событий и возможность мониторинга.

Как вовремя подключать ИТ и безопасность

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

• уже на стадии первого или второго разговора спросить: «С кем внутри по ИТ и безопасности нам нужно будет синхронизироваться, если пойдём дальше?»;
• предложить короткий технический/безопасностный созвон, когда есть хотя бы примерный сценарий использования и вы можете описать, какие данные будут задействованы и где они сейчас живут.

Формулировка:

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

Проверьте себя