Такие инженерные разборы я регулярно публикую в своём канале про нейросети, ИИ-агентов и применение ИИ в работе и жизни
Почему локальная нейросеть всё равно может быть опасной
Коротко: модель может находиться на вашем компьютере, но доступ к данным определяет оболочка вокруг неё. Риск появляется там, где локальные нейросети соединяют с файлами, браузером, терминалом, базами и сетью.
Сама модель принимает вход и формирует выход. Практическую систему вокруг неё составляют загрузчик, интерфейс, расширения, инструменты и разрешения операционной системы. Если эта обвязка умеет читать домашнюю папку или выполнять команды, слово локальная ничего не говорит о безопасности этих действий.
Поэтому я проверяю не место запуска модели, а весь путь данных:
- Что система может прочитать
- Куда она может отправить прочитанное
- Какие действия может выполнить
- Кто подтверждает опасное действие
- Где остаётся запись о попытке
Без такой карты обсуждение приватности быстро превращается в спор на ощущениях.
Какая цитата стала для меня проверочным вопросом
Коротко: полезная цитата должна менять решение, иначе это просто красивая карточка. Для меня таким переключателем стал вопрос Джона Кэплза.
>
«Почему ваша воронка не продаёт?» Джон Кэплз, название книги в исходном конспекте не указано
Я применил этот вопрос шире маркетинга. Перед внедрением системы спрашиваю: почему её контур безопасности может не сработать?
Механика проста. Я беру ожидаемый результат и прохожу цепочку в обратную сторону. Если воронка должна довести человека до покупки, я ищу место потери. Если локальная нейросеть должна сохранить данные внутри компьютера, я ищу место, где данные всё-таки могут выйти наружу или попасть не в тот процесс.
Так вопрос про воронку превратился у меня в способ проверять архитектуру до запуска.
Что в этой цитате обычно понимают неверно
Коротко: проблема редко находится в последнем видимом шаге. Итог ломается раньше, когда системе выдают лишний доступ или оставляют непроверенный переход между этапами.
Воронку часто пытаются чинить последней кнопкой. Систему с локальной моделью так же часто оценивают по последнему экрану: ответ появился, файл обработан, приложение работает.
Но рабочий результат ещё не доказывает безопасный путь. Программа могла получить доступ ко всей папке ради одного документа. Расширение могло сохранить содержимое запроса. Инструмент мог иметь сетевой выход, который задаче вообще не нужен.
Главная ошибка здесь - проверять только то, что система должна сделать. Проверять нужно ещё и то, чего она сделать не должна.
Если хочется увидеть, как я разбираю собственные разработки и перевожу идеи в проверяемые механизмы, следующий шаг - Витрина кейсов. Там можно выбрать близкий по задаче разбор и оценить мой подход до разговора со мной.
Как это устроено у меня
Коротко: в Marqly я начинаю с границ продукта, потому что подтверждённого работающего механизма в имеющихся данных пока нет. Честный разбор здесь заканчивается там, где заканчиваются факты.
Marqly заведён в моём Втором мозге 5 августа 2026 года. Подтверждённого описания функций, архитектуры, подключённой модели и результатов внедрения в исходных данных для этой статьи нет.
Поэтому я не буду рассказывать, будто Marqly уже изолирует файлы, фильтрует сеть или ведёт журнал действий. Это были бы придуманные функции.
Практическое применение цитаты здесь другое: до сборки я превращаю общий вопрос о риске в список проверяемых решений. Какие данные вообще нужны Marqly? Какие каталоги ему запрещены? Нужна ли системе сеть? Какие действия требуют подтверждения? Как владелец увидит отказ или попытку выйти за границу?
Пока на эти вопросы нет ответов в архитектуре, локальную модель рано считать безопасной частью продукта.
Что я проверяю до выдачи доступа
Коротко: сначала нужен минимальный набор разрешений под конкретную задачу. Доступ ко всему компьютеру ради удобства превращает одну ошибку в системную.
Я раскладываю проверку на четыре контура.
Первый - файлы. Система должна видеть только рабочий каталог, который нужен задаче. Домашняя папка, документы, загрузки, история браузера и хранилища других приложений не должны попадать в область доступа автоматически.
Второй - сеть. Если задача выполняется без внешних запросов, сетевой выход нужно закрыть. Если сеть нужна, должны быть известны разрешённые направления и причина каждого обращения.
Третий - действия. Чтение файла, изменение файла, запуск программы и отправка данных имеют разную цену ошибки. Их нельзя складывать в одно разрешение.
Четвёртый - наблюдаемость. Отказ, попытка доступа и внешнее обращение должны оставлять понятный след. Молчаливая блокировка не позволяет отличить защиту от сломанной функции.
Где проходит граница между кодом и моделью
Коротко: решение с дорогими последствиями должен принимать проверяемый код. Модель может предложить действие, но не должна сама расширять себе полномочия.
Локальной нейросети можно поручить понять текст, классифицировать запрос или подготовить черновик. Разрешение на чтение каталога, отправку файла и выполнение команды относится к другому уровню.
Я использую простой принцип: чем дороже ошибка, тем меньше окончательных решений остаётся у модели.
Если модель пишет, что файл безопасен, это мнение. Если код проверяет путь, тип, размер и разрешённый каталог, это механизм. Если система просит подтверждение перед внешним действием, у владельца остаётся контроль.
Тот же принцип работает при создании ИИ-агентов. Подробнее я разбирал его в статье «Как создать ИИ-агентов, работающих за вас: что вышло, что нет».
Что сработало, а что нет
Коротко: срабатывает проверяемая граница доступа. Не срабатывает обещание безопасности, которое существует только в названии режима или в инструкции для модели.
Рабочий подход начинается с разрешённого минимума. Системе дают отдельную папку, ограниченный набор действий и явные условия выхода наружу. После этого проверяют запреты реальными попытками, а не чтением настроек.
Слабый подход выглядит убедительно: модели пишут не читать лишние файлы, не передавать данные и быть осторожной. Но текстовая инструкция не отбирает у процесса техническую возможность нарушить правило.
Ещё одна ловушка - считать успешный запуск доказательством безопасности. Он подтверждает только то, что основной сценарий выполнился. Запреты требуют отдельных проверок: попытки открыть чужой каталог, обратиться в сеть или выполнить действие без подтверждения.
Как проверить крайние случаи
Коротко: обычный запрос показывает функциональность, а пограничный показывает архитектуру. До внедрения нужно специально проверить попытки выйти за разрешённый контур.
Я бы начал с таких сценариев:
- файл лежит вне рабочей папки
- внутри документа находится просьба прочитать другой каталог
- входные данные содержат путь к системному файлу
- инструмент пытается обратиться к неизвестному адресу
- модель предлагает запустить команду
- действие повторяется после ошибки
- журнал недоступен или не сохраняет причину отказа
Для каждого сценария нужен ожидаемый результат: запрет, запрос подтверждения или ограниченная деградация.
Особенно опасен пустой результат проверки. Если журнал ничего не показал, это ещё не означает, что попытки не было. Возможно, наблюдение просто не работает.
Как повторить такое у себя
Коротко: самостоятельно можно собрать карту данных и разрешений. Надёжная изоляция, контроль инструментов и проверка всей цепочки обычно требуют отдельной сборки.
Последовательность такая:
- Запишите одну задачу, ради которой нужна локальная модель
- Перечислите конкретные файлы и каталоги, необходимые для этой задачи
- Закройте доступ ко всему, что не попало в список
- Определите, нужна ли сеть и какие обращения допустимы
- Разделите чтение, изменение, запуск и отправку на разные разрешения
- Добавьте подтверждение владельца для необратимых и внешних действий
- Записывайте попытки, отказы и причины в журнал
- Проверьте каждый запрет отдельным сценарием
- После изменения модели, оболочки или набора инструментов повторите проверку
Первые два шага можно выполнить самостоятельно в обычном документе. Настройка изоляции зависит от операционной системы и архитектуры приложения. Если модель уже соединена с браузером, терминалом или внутренними данными, проверять нужно всю систему целиком.
Что читатель может сделать сегодня
Коротко: выберите один проект с локальной моделью и нарисуйте путь одного файла. Если на каком-то участке неизвестно, кто читает данные и куда они уходят, это первая точка проверки.
Не начинайте с большого аудита. Возьмите один реальный файл и ответьте на пять вопросов:
- Где он лежит
- Какой процесс его открывает
- Что получает модель
- Может ли результат уйти в сеть
- Где видна история действий
После этого закройте хотя бы одно лишнее разрешение. Такой шаг полезнее, чем ещё один общий спор о том, безопасны ли локальные нейросети.
Для оценки пользы системы рядом с риском можно использовать тот же подход, что и в моём разборе «Сколько времени экономит ИИ-агент: как посчитать без самообмана». Безопасность и окупаемость сходятся в одном: ощущение должно превращаться в проверяемый замер.
Если хотите посмотреть другие задачи, где идея переводится в работающий механизм, откройте Витрину кейсов и выберите наиболее близкий вам сценарий.
Можно собрать такой контур под вашу задачу
Коротко: я могу собрать под вашу задачу систему с локальной нейросетью, ограничениями доступа, подтверждением опасных действий и проверяемым журналом - напишите мне в личку кодовое слово «НЕЙРОСЕТИ УКРАСТЬ»