В первых двух статьях мы прошли путь от идеи до инженерной реалити:
«Домик для ИИ: как завод пришёл к идее AI ready для бизнеса» — о том, почему корпоративному ИИ нужна специальная инфраструктура.
«AI ready: почему дата-центр для ИИ сложнее обычного модульного ЦОДа» — об инженерных вызовах и развертывании базы (AI Base).
В них мы подробно разобрали концепцию локального контура и его физический фундамент. Сначала история развивалась в плоскости инженерии, от идеи собственного AI ready модуля до конкретных расчетов плотности вычислений и охлаждения.
Но чем глубже мы заходили в тему, тем яснее становилось, что корпоративный AI упирается не только в серверы, GPU и модели. Он упирается в вопрос, который появляется раньше промышленной эксплуатации: кто отвечает за данные, доступы, логи и результат.
На одном из обсуждений с потенциальным заказчиком директор по информационной безопасности сформулировал позицию предельно честно: «Моя задача — чтобы здесь ничего не внедрили. Я у вас точно ничего покупать не собираюсь».
Это неприятно слышать компании, которая приходит с новым продуктом. В то же время для нас эта фраза оказалась крайне полезной. Она подсветила системную проблему, где конфликт вызывает не сам ИБ-директор, а скорее реактивный подход к безопасности. Когда бизнес хочет ускорения, IT хочет пробовать, а AI-команда показывает неконтролируемое демо «в облаке», то у ИБ просто не остаётся другого выбора, кроме как встать в глухую оборону. Запрет становится единственным способом защитить периметр, когда ему не предлагают альтернативной управляемой архитектуры.
Мы не считаем, что ИБ должна быть врагом AI. Но считаем, что запрет AI под флагом безопасности является тупиком. Не потому, что рисков нет. Риски есть. Именно поэтому AI нельзя внедрять как игрушку, внешний чат или неконтролируемый сервис. Его надо поселить в управляемый контур.
Две плохие крайности
В корпоративной среде вокруг AI быстро возникла странная развилка.
С одной стороны — быстрые эксперименты. Подключить внешнюю модель, загрузить документы, собрать RAG-пилот, показать красивый интерфейс. Это удобно и часто действительно помогает быстро понять потенциал технологии. Тем не менее, для чувствительных корпоративных данных, производственной документации, договоров, персональных данных, внутренних переписок и технологических процессов такой метод не всегда подходит.
С другой стороны — защитная реакция, что если есть риски, значит проще не внедрять. Не выносить данные, не давать доступ, не запускать пилоты, не использовать AI в рабочих процессах.
Всё-таки запрет не является стратегией. Он становится паузой, которая быстро превращается в отставание.
Бизнес всё равно будет искать инструменты, которые ускоряют работу. Сотрудники всё равно будут пробовать внешние AI-сервисы. Подразделения всё равно будут запускать неформальные пилоты. Если у компании нет управляемого AI-контура, то вместо безопасности она получает теневое использование AI без правил, журналов, ролей и ответственности.
Правильной альтернативой прямо сейчас становится введение временного управляемого регламента. Компания утверждает перечень доступных внешних сервисов для открытых задач, заводит корпоративные аккаунты с отключенным обучением моделей и вводит запрет на загрузку конфиденциальных данных, ПДн и исходного кода. Это позволяет сотрудникам безопасно освоить промптинг и проверить сценарии пользы. Пока команда адаптируется к технологии, компания параллельно проектирует и разворачивает собственный защищенный контур. А после его запуска переводит сотрудников из публичных сервисов в изолированную корпоративную среду.
Поэтому вопрос не в том, использовать AI или не использовать. Вопрос в том, где и как его использовать.
Корпоративный AI — это цифровой сотрудник с доступом
Ошибка многих AI-проектов в том, что к ним относятся как к очередному приложению. На самом деле корпоративный AI быстро становится чем-то ближе к цифровому сотруднику.
Он читает документы. Получает вопросы от пользователей. Ищет по базе знаний. Работает с договорами, техническими файлами, обращениями, регламентами, изображениями, видео, производственной и эксплуатационной документацией. Может быть встроен в CRM, ERP, ECM, Service Desk, MES или внутренние порталы.
Значит, к нему нельзя относиться как к внешнему чат-боту. Если AI получает доступ к корпоративному знанию, у него должны быть понятные роли, границы, журналы, правила работы с данными и ответственность за результат.
Пока у AI нет периметра, ролей, логов и понятной эксплуатации, это не промышленный инструмент. Это демо.
Что на самом деле надо защищать
В AI-проекте защищать нужно не только исходные документы. Часто именно это недооценивают.
В контуре появляются пользовательские запросы, ответы модели, embeddings и индексы, история диалогов, метаданные, логи, права пользователей, интеграции с корпоративными системами, файлы, изображения и видео. В некоторых сценариях чувствительным, помимо самого документа, становится и вопрос пользователя к этому документу. Иногда даже факт запроса уже является корпоративной информацией.
Поэтому вопрос информационной безопасности в AI становится частью архитектуры контура с первого дня.
Нужно понимать: где лежат данные, где создаются индексы, какая модель используется, есть ли выход во внешний интернет, кто видит запросы, где хранятся ответы, как разграничиваются права, что пишется в журнал, как удаляются данные и кто отвечает за ошибку модели.
Если на эти вопросы нет ответа, промышленной эксплуатации не будет. Будет пилот, презентация и дальнейший спор между бизнесом, IT и ИБ.
Локальный AI-контур как третий путь
Позиция ПСМ простая — ИБ не должна убивать AI. ИБ должна задавать контур, в котором AI можно безопасно применять.
Локальный AI-контур — это управляемая среда, где данные, модели и сервисы остаются внутри периметра компании. Важно понимать, что сам по себе физический запуск локального контура не гарантирует безопасность автоматически. Он лишь создает условия, в которых ИБ получает полный контроль. Поэтому контур дополняется целевыми механиками: интеграцией с IAM/SSO, ролевым доступом, шифрованием векторных баз, управлением секретами и защитой от prompt injection.
Такой контур нужен не всем и не всегда. Облако нормально работает для быстрых экспериментов, некритичных задач и сценариев, где данные можно обрабатывать во внешней среде. Однако есть задачи, где заказчик не хочет или не может выносить данные наружу. Для них локальный контур становится важным условием внедрения.
Именно здесь появляется альтернатива запрету. Вместо «ничего не внедрять» и «пустить всё в публичный AI» — построить среду, в которой AI работает внутри понятных правил.
Почему это не просто софт
На рынке много команд, которые умеют делать AI-пилот. RAG, ассистент, чат, обработка документов, поиск по базе знаний — всё это уже стало рынком. И мы не делаем вид, что заходим в пустое поле.
Но корпоративному заказчику всё чаще нужен контур. Кто отвечает за данные? Где живёт модель? Как разграничиваются права? Где хранятся логи? На каких вычислениях это работает? Как система будет эксплуатироваться после демо? Что делать, если нагрузка растёт? Как это подключено к инфраструктуре заказчика?
Здесь у ПСМ появляется своя логика. Мы пришли в AI не как классический софтверный стартап. ПСМ — промышленная инженерная компания, а ПСМ UNLIM вырос из внутренних задач завода: ERP, MES, SCADA, мониторинг, предиктивная аналитика, работа с производственными и эксплуатационными данными.
Поэтому для нас AI с самого начала уже часть промышленной среды. При этом мы не призываем заказчика сразу строить масштабный дата-центр ради одной гипотезы. Наш подход гибкий: пилот или локальный сервис можно запустить в формате AI Factory-light на существующей виртуальной инфраструктуре клиента. Главное сразу правильно построить архитектуру ИБ и доступов, а выделенное оборудование подключать только по мере роста реальной нагрузки.
Три слоя локального AI-контура
Мы описываем локальный AI-контур через три слоя.
AI Factory — прикладной и модельный слой: модели, RAG, OCR, AI-ассистенты, агенты, видеоаналитика, интеграции с корпоративными системами, интерфейсы, метрики качества и сценарии использования.
AI Cluster — вычислительный слой: GPU/CPU-серверы, хранение, сеть, среда запуска AI-сервисов, базовый мониторинг вычислительного контура.
AI Base — инженерная база: питание, охлаждение, резервирование, пожаротушение, физическая безопасность, SCADA/мониторинг и готовность площадки к AI-нагрузке.
Не каждому заказчику нужен сразу полный стек из трех слоев. Если у компании уже есть свои вычислительные мощности, мы разворачиваем прикладной слой AI Factory прямо в её периметре. Отдельный вычислительный AI Cluster и физическая инженерная база AI Base подключаются только тогда, когда у бизнеса появляется реальная потребность в high-density вычислениях и масштабировании. Здесь становится ключевым предварительно согласованный периметр безопасности.
Как мы сами к этому пришли
ПСМ не рассуждает об этом только теоретически. Мы начали внедрять AI внутри компании и быстро увидели, где заканчивается красивое демо.
Attention-боты помогают мониторить входящие обращения и риски реакции. AI-помощники работают с текстовыми запросами и файлами в контексте корпоративной базы знаний. RAG-сценарии применяются к качеству и эксплуатационной документации. Юридические AI-сценарии помогают ускорять работу с договорами. Видеоаналитика внедряется как инструмент контроля производства.
Каждый такой сценарий задаёт одни и те же неудобные вопросы: какие данные видит система, кто имеет доступ к результату, где хранится история, можно ли использовать внешний сервис, кто отвечает за качество ответа, как это будет жить после пилота.
Именно поэтому мы смотрим на AI как на контур, который должен быть управляемым с первого дня. Однако на рынке до сих пор преобладает обратный подход.
Почему контур строится до пилота, а не после
Классический путь AI-проекта в корпорации часто выглядит так: быстро показать бизнесу ценность («магию AI»), где пилот собирают на коленке, на синтетических данных или во внешнем облаке в обход строгих ИБ-процедур. Как только встает вопрос перехода от красивого демо к реальной работе с внутренними данными, проект мгновенно упирается в глухую стену ИБ.
В чём проблема такого подхода? Без предварительно согласованного периметра, безопасность блокирует проверку гипотез. Чтобы пилот дал честный результат и не споткнулся об ИБ, мы разделяем его на два понятных этапа:
Технический pre-pilot: отладка RAG-маршрутов, моделей и интерфейсов проходит на синтетических датасетах, открытых регламентах или глубоко обезличенных данных. Это позволяет доказать работоспособность архитектуры без касания коммерческой тайны.
Бизнес-пилот: проверка реального эффекта на процессах выполняется на ограниченном сэмпле внутренних документов, но строго внутри изолированного и согласованного с ИБ контура.
Что гарантирует архитектурный контур еще до старта пилота:
Определены границы и периметр: сразу понятно, какие данные используются, где они хранятся и выходит ли поток за пределы компании;
Разграничены права и роли: система видит только то, что положено пользователю по его профилю;
Настроена политика аудита и логирования: фиксируются факты обращения, действия моделей и вызовы API, а сами тексты запросов и ответов маскируются и хранятся строго по правилам ИБ компании, чтобы логи не превращались в еще одну незащищенную базу данных.
Назначен владелец и процесс: выбирается один понятный сценарий, один ответственный и конкретные метрики качества.
Когда пилот разворачивается внутри готового контура, он перестает быть неконтролируемым риском или бесконечной дискуссией с ИБ. Он становится предсказуемым инженерным экспериментом, который заканчивается управленческим решением: масштабировать, дорабатывать или закрывать.
Путь к корпоративной архитектуре
Конкретный трек внедрения всегда зависит от исходной инфраструктуры заказчика. Кто-то стартует на текущих виртуальных мощностях в формате AI Factory-light, а кто-то сразу закладывает выделенный инженерный контур. Однако системный подход обязательно начинается с архитектуры безопасности и периметра, который делится на 4 шага:
Архитектура ИБ и правила периметра. До запуска первых вычислений закладываются фундамент и правила: разграничение доступов (IAM/SSO), шифрование векторных баз, политика аудита действий моделей, маскирование данных и ролевая модель.
Инфраструктурный базис под задачу. Выделяются вычислительные мощности под текущую задачу — от запуска AI Factory-light на имеющейся виртуализации клиента до развертывания узлов AI Cluster и инженерной базы AI Base по мере роста нагрузки.
Интеграция модельного слоя. Настраивается прикладной слой (AI Factory) и его бесшовная связка с ключевыми системами компании: ERP, MES, SCADA, CRM и ECM.
Безопасная обкатка целевых сценариев. Внутри уже защищенного и согласованного контура запускаются прикладные бизнес-задачи (обработка договоров, видеоаналитика, базы знаний).
В таком подходе пилот перестает быть временной конструкцией «на выброс». Это первое безопасное прикладное применение уже готовой корпоративной платформы.
Что дальше
Мы считаем, что компании, которые просто запретят AI, не станут безопаснее. Они станут медленнее. Компании, которые пустят AI без контура, получат риски и теневое использование. Выиграют те, кто построит управляемую среду, где AI можно использовать промышленно.
Для ПСМ локальный AI-контур становится новой инфраструктурной категорией на стыке инженерии, вычислений, данных, ИБ и прикладного AI.
В этой статье мы говорили про «щит данных» — периметр, роли, логи и управляемость. Всё же у локального AI-контура есть и живая сторона. Даже самая продуманная архитектура и защищенный контур так и остаются схемой на слайде, если их некому внедрять.
Об этом будет следующий эпизод: «От промышленной автоматизации к AI: как мы собирали команду и почему "нейросетчики" для неё не подошли».
Granulex
Контур решает вопрос, где живут данные. Второй же, который вы сами назвали, остаётся открытым: кто отвечает за результат. Добавлю момент из практики: как только ИИ переезжает внутрь доверенного периметра, к его ответам начинают относиться как к "своим" – раз модель на наших серверах, значит, ей можно верить. Так безопасность данных незаметно подменяет собой проверку правильности, и через полгода ИБ-директору придётся защищать периметр уже не от утечки, а от избыточного доверия к цифровому сотруднику.