Слепое хранилище — оператор не может прочитать клиента

Мы, оператор платформы, технически не можем прочитать переписку клиента. Не «обещаем не читать» — не можем. Разница между этими двумя фразами и есть весь смысл темы.

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

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

Журнал, который оператор не может открыть. Сервер шифрует записи открытой половиной ключа. Закрытой половины в инфраструктуре нет вовсе — она на внешнем носителе у владельца ключа, вне серверов. Расшифровать выгрузку можно только ею и только отдельной процедурой за пределами платформы. Администратор с полным доступом к серверу и базе видит зашифрованные блоки.

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

Что уходит наружу — фиксируется отдельно, байт в байт. Мы записываем не только обмен внутри контура, но и ровно те данные, которые покидают периметр: уже после маскировки персональных данных, в точном виде. На законный запрос предъявляется не пересказ, а факт: вот что уходило и когда.

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

Тайна переписки должна держаться устройством, а не характером. Это то же правило, по которому банк не хранит ваш ПИН-код: не потому, что сотрудники хорошие люди, а потому, что кода там нет.

Отсюда же правило двух ключей для регуляторного доступа. Конверт для законного запроса открывается не одним ключом, а двумя половинами вместе: одна у регулятора, вторая у нас. Ни мы в одиночку, ни он в одиночку открыть не можем — только совместная процедура по законному основанию. Формула, которую мы считаем правильной: «одним своим не можем, двумя — пожалуйста; а проще всего спросить у самого клиента, он открывает своим ключом сам».

Мы называем их сами, потому что скептик, нашедший неназванное ограничение, уходит навсегда.

1. В момент ответа помощник видит текст открытым. Иначе ему нечем думать. Гарантия здесь звучит так: открытый текст не касается диска и не покидает контур, он живёт в памяти процесса ровно на время запроса. Это инженерное свойство, а не магия, и мы не выдаём его за большее.
2. Потеряны все ключи — история потеряна. Восстановления «через поддержку» не существует, иначе не существовало бы и самой защиты. Это записывается в договор прямым текстом, а не мелким шрифтом.
3. Двухключевой замок на саму историю переписки ещё строится. Сегодня в бою работает журнал слепого оператора и маскировка исходящего. Прозрачное шифрование истории ключом заказчика — следующий шаг, и мы говорим о нём как о направлении.