ИИ и корпоративная безопасность. Часть 4.

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

Есть четыре базовых варианта.

1. Облачный ИИ-сервис по API. Модель живёт у внешнего вендора, а вы просто обращаетесь к ней через интернет. Типичный пример: модели OpenAI, Anthropic, Google и других поставщиков. Вы не арендуете сервер, вы покупаете доступ к сервису.

2. Публичное облако. Вы арендуете вычислительные ресурсы в большой облачной платформе – вроде AWS, Microsoft Azure, Google Cloud и им подобных. Здесь вы берете чужую, например, open source/weights модель и ваше ИИ-приложение уже может жить не «у вендора как сервис», а на арендованных вами мощностях. То есть это уже не «чужой готовый мозг по API», а «чужое железо, арендованное под ваши мозги».
Вы даже можете открыть публичный доступ к модели под своим брендом и отчитаться о прорыве в сфере ИИ.

3. Частное облако. Некий специализированный подрядчик/провайдер поднимает для вас выделенный облачный контур: отдельные серверы, отдельное хранение, отдельные правила доступа, обслуживание, мониторинг и прочее хозяйство. Формально это тоже не ваши серверы. Но это уже вами контролируемая «территория».
Это нужно, когда обычный облачный сервис уже рискован, а тащить всё к себе – ещё дорого, рано или некому.

4. Свои серверы. Всё стоит на вашем железе – серверы ваши, доступы ваши, эксплуатация ваша, головная боль и счета за электроэнергию – тоже ваши.

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

Вот тут и начинаются нюансы. Да, вы можете скачать монстра на 600–700B параметров. Никто не запрещает. Проблема в том, что «скачать» не значит «нормально поднять». Между этими двумя понятиями лежат очень бодрые расходы на графические ускорители, видеопамять, внутренние соединения, охлаждение, отказоустойчивость и... электричество. То есть бизнес хотел решить вопрос с безопасностью, а в итоге внезапно открыл дорогостоящий клуб вычислительного мазохизма.

Поэтому реальный выбор обычно такой:
– API облачного вендора – когда вам нужны лучшие возможности модели и скорость запуска. Но с применением специальных мер для чувствительных данных.
– Публичное облако – когда вы хотите сами управлять приложением и инфраструктурой, но не покупать железо.
– Частное облако – когда уже нужен более жёсткий контур и договорный контроль.
– Свои серверы – когда цена утечки уже слишком высока.

Теперь главный практический совет – вы можете миксовать все четыре подхода. Да, правильно, это про оркестрацию.

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

Что можно делать на практике?

Во-первых, маскировать конкретику: заменять имена людей, названия компаний, адреса, номера договоров, реквизиты, цены, внутренние коды на обезличенные, типа, «Клиент В» или «Сумма_Х_9».

Во-вторых, отправлять не весь документ, а только нужный кусок – один фрагмент, один спорный пункт, один абзац, а не весь архив за пять лет.

В-третьих, оставлять снаружи только смысл задачи, а не её «паспортные данные»: модель должна понимать, что нужно сделать, но не знать, с кем именно вы это делаете.

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

То есть вопрос не в том, любите ли вы облако, а в том, что именно вы туда отправляете, зачем и чем это потом может закончиться. Вот это и есть взрослый разговор. А всё остальное – либо маркетинг, либо героические фантазии людей, которые никогда не видели счёт за GPU-сервер.

К ИИ мы обязательно вернемся. Позже. А сейчас всё же хочется поговорить о производительности!

#ИИ #корпоративнаябезопасность