Короткий ответ
#Решение, принятое за десять минут
Разговор занимает десять минут и выглядит убедительно. Юрист беспокоится про персональные данные, технический директор предлагает поднять модель у себя, все соглашаются, что так безопаснее. В протоколе появляется строка: переходим на собственную модель.
Через месяц у компании есть локальная модель. У неё есть административный токен к внутреннему API, доступ в интернет без ограничений, права на запись в базу и инструмент отправки писем. Персональные данные действительно не уходят к внешнему провайдеру. Всё остальное, что могло случиться, по-прежнему может.
Я не спорю с решением. Локальный запуск бывает правильным выбором, и часто он единственно возможный. Спорю с выводом, который делают вместе с ним: что вопрос безопасности этим закрыт. Тут произошла подмена: решили вопрос границы данных и поставили галочку напротив вопроса ущерба.
#Два разных вопроса
Про любую систему с ИИ нужно отвечать на два независимых вопроса, и место запуска отвечает только на первый.
-
Куда попадают данные и кто владеет инфраструктурой
Какие данные модель видит, где они обрабатываются, кто ещё имеет к ним доступ, что записывается в журналы, сколько это хранится, по какому договору и в какой юрисдикции.
Вот на этот вопрос выбор облака или своего сервера действительно влияет.
-
Что агент может сделать
Какие инструменты подключены, какие у них права, есть ли потолок на объём, что происходит без подтверждения, что нельзя откатить, через сколько минут человек узнает о проблеме.
На этот вопрос место запуска не влияет никак. Ответ на него целиком лежит в архитектуре вашего приложения.
Второй вопрос определяет размер ущерба. Первый определяет, кому вы доверяете данные. Их путают потому, что оба называют одним словом «безопасность», и потому что первый решается покупкой или переездом, а второй только работой.
#Что действительно меняется
Это не аргумент против локального запуска. У него есть настоящие преимущества, и их стоит называть точно, чтобы не приписывать ему лишнего.
Меняются две верхние строки. Три нижние, те самые, которые решают размер ущерба, в обоих столбцах одинаковы.
- Граница данных. При локальном запуске содержимое запросов не покидает вашу инфраструктуру. Это реальное и проверяемое свойство, и для некоторых классов данных оно решающее.
- Договорные и юридические ограничения. Есть требования, которые невозможно выполнить формулировкой в политике конфиденциальности поставщика. Если ваш контракт или регулятор требует обработки внутри определённого периметра, вопрос закрыт до начала обсуждения.
- Предсказуемость поведения. Облачная модель обновляется тогда, когда решит поставщик, и ответ на тот же запрос может измениться. Своя модель меняется, когда вы её меняете. Цена за это в том, что и улучшения вы получаете тогда, когда сами их принесёте.
- Кто отвечает за эксплуатацию. Это преимущество, которое легко принять за недостаток, и наоборот. В облаке патчи, изоляция и доступность не ваша работа. У себя это ваша работа целиком: обновления, мониторинг, доступы, дежурство, сегментация сети.
Последний пункт стоит посчитать заранее. Локальный запуск переносит на вашу команду новый предмет эксплуатации. Если некому обновлять и некому смотреть на графики ночью, вы обменяли известный риск поставщика на собственный неизвестный.
#Что остаётся ровно таким же
Дальше главное. Ни одно из перечисленного не меняется от переезда модели, и именно это определяет, насколько дорого обходится ошибка.
Проверить это можно на одном мысленном действии. Представьте, что модель уже внутри вашей сети, а всё остальное осталось как есть: те же инструменты, те же токены, те же лимиты. Теперь пройдите по списку неприятностей, которых вы боитесь, и отметьте, какие из них стали невозможны. Обычно в этом списке обнуляется один пункт, утечка содержимого запросов внешнему поставщику, а остальные остаются на месте до буквы.
| Риск | Меняется ли от места запуска | Что его действительно ограничивает |
|---|---|---|
| Инструкция, пришедшая внутри данных | Нет. Локальная модель так же воспринимает текст как смысл. | Отделение данных от инструкций, права инструментов, подтверждение необратимого. |
| Слишком широкие права | Нет. Административный токен остаётся административным токеном. | Права на объект, срок разрешения, отдельные учётные данные на агент. |
| Опасные инструменты | Нет. Возможность отправить письмо или удалить строку не зависит от того, где считается модель. | Перечень инструментов, лимит на объём, отдельный путь для массовых операций. |
| Утечка через вывод | Частично. Провайдер не увидит, а получатель письма увидит. | Правила того, что агент может отправлять и куда, и проверка перед отправкой. |
| Журналы и хранение | Да, но не сам собой. Свои журналы тоже содержат данные и тоже кем-то читаются. | Политика хранения, доступы к журналам, обезличивание. |
| Ошибка в цепочке шагов | Нет. Каскад строится на архитектуре, а не на модели. | Ограничение глубины, идемпотентность, перепроверка перед необратимым шагом. |
#Как выбирать
Решение про место запуска стоит принимать четырьмя вопросами в этом порядке. Первые два обычно закрывают тему, а до четвёртого доходят редко.
Компания подключила ИИ к переписке с клиентами. В запрос к модели уходит весь профиль клиента целиком, потому что так было проще написать: один объект, одна строка кода. Модели из этого профиля нужны два поля, тариф и дата окончания. Остальное, включая адрес, телефон и историю платежей, уезжает вместе с ними при каждом обращении.
Пока обсуждают, переносить ли модель внутрь, самая чувствительная часть проблемы решается одной правкой на стороне приложения. Это типичный случай: вопрос «где запускать» приходит раньше, чем вопрос «а что мы вообще отправляем».
-
Опишите классы данных, а не «данные»
Разделите то, что попадает в запросы, на группы: публичное, внутреннее, персональные данные, платёжные сведения, врачебное или иное особое. Дальше решение принимается по самой чувствительной группе, которая реально нужна модели.
Часто выясняется, что модели нужна одна группа, а отправляется ей другая. Это и есть самая дешёвая правка за весь проект.
-
Выпишите требования, которые вы обязаны выполнить
Договор с корпоративным клиентом, отраслевое регулирование, обещание в собственной политике конфиденциальности. Требование либо есть, либо нет, и оно не обсуждается с точки зрения удобства.
Если требование есть, дальше можно не читать: место запуска выбрано за вас.
-
Оцените свою способность это эксплуатировать
Кто обновляет, кто смотрит на нагрузку, кто отвечает ночью, кто управляет доступами, что происходит при отказе одной машины. Честный ответ «никто» встречается чаще, чем кажется.
Локальный запуск без эксплуатации хуже облака с плохим договором, потому что второе хотя бы кто-то поддерживает.
-
Спроектируйте ограничения агента отдельно
Права, лимиты, подтверждения, откат, журналы. Эта работа делается одинаково в обоих случаях, и именно она определяет ущерб. Её нельзя отложить на потом, потому что на неё почти всегда не остаётся времени.
Если вы сделаете только этот шаг и не поменяете место запуска, вы уменьшите ущерб. Если только поменяете место запуска, не уменьшите.
#Наш собственный ответ
1ADK устроен так, что этот выбор остаётся за вами. Анализ выполняет агент на вашей стороне, тот, которым вы и так пользуетесь, а в сервис приходят структурированные сведения и доказательства. 1ADK не требует доступа к вашему репозиторию и не требует загружать в него исходный код. Архитектура не привязана к одному поставщику модели.
Чего мы при этом не говорим
Мы не утверждаем, что при таком устройстве кода вообще никто не видит. Облачный агент читает ваш код по условиям своего поставщика, и это отдельное решение, которое принимаете вы. Наша граница означает другое: чего не может сделать 1ADK. Разница между этими двумя утверждениями и есть то, что стоит требовать от любого поставщика.
#Что обычно путают
Данные не уходят с нашего сервера, значит, мы в безопасности.
Вместо этого Это утверждение о конфиденциальности, а не о безопасности. Оно ничего не говорит о том, что агент может сделать с вашей базой, вашими деньгами и вашей почтой.
Локальная модель дешевле, потому что нет оплаты за токены.
Вместо этого Считайте полную стоимость: оборудование, обновления, мониторинг, дежурство, простои и время инженеров. Иногда локальный запуск дешевле, но это результат расчёта, а не свойство подхода.
Раз модель наша, инъекция нам не грозит.
Вместо этого Инъекция это свойство того, как модель обрабатывает текст, а не того, где стоит сервер. Защита строится на разделении данных и инструкций и на правах инструментов.
Мы решим это одним выбором поставщика.
Вместо этого Выбор поставщика закрывает вопрос границы данных. Вопрос ущерба закрывается отдельной работой над правами, лимитами и подтверждениями, и её объём от поставщика не зависит.
#Чего эта статья не утверждает
Чего это не делает
- Она не утверждает, что облако безопаснее. Для части данных и требований оно просто неприменимо.
- Она не утверждает, что локальный запуск безопаснее. Он переносит ответственность, а не снимает её.
- Она не оценивает качество моделей и не советует конкретного поставщика.
- Она не заменяет юридическую оценку: какие данные куда можно отправлять, решается договором и регулированием, а не архитектурой.
- Она не покрывает обучение на ваших данных. Это отдельный вопрос, который решается условиями поставщика и настройками, а не местом запуска.
Возьмите свою самую заметную автоматизацию с ИИ и ответьте на один вопрос: если завтра перенести модель внутрь, какой из рисков в таблице выше изменится? Если ответ «ни один из трёх нижних», значит, работа, которая действительно уменьшает ущерб, ещё не начиналась.