ИИ без контура — это демо

На одной из встреч директор по информационной безопасности сформулировал позицию предельно честно: «Моя задача — чтобы здесь ничего не внедрили. Я у вас точно ничего покупать не собираюсь».

Эта фраза подсветила системную проблему. Конфликт вызывает не сам ИБ-директор, а реактивный подход к безопасности. Когда бизнес требует ускорения, IT хочет экспериментировать, а команда показывает неконтролируемое демо «в облаке», у ИБ не остается выбора, кроме как встать в глухую оборону. Запрет становится единственным способом защитить периметр, если компании не предлагают альтернативную управляемую архитектуру.

Позиция ПСМ UNLIM проста: ИБ не должна быть врагом инноваций. Но чтобы ИИ перестал быть внешней игрушкой или неконтролируемым сервисом, его необходимо поселить в управляемый контур

Две плохие крайности

В корпоративной среде вокруг внедрения искусственного интеллекта быстро сформировалась развилка из двух нерабочих сценариев:

• Быстрые эксперименты (Shadow AI). Подключить внешнюю модель, загрузить документы, собрать RAG-пилот и показать красивый интерфейс. Это удобно и помогает быстро оценить потенциал технологии, но категорически не подходит для чувствительных корпоративных данных: производственной документации, договоров, персональных данных (ПДн), внутренних переписок и технологических процессов.
• Глухой запрет. Защитная реакция по принципу «если есть риски — проще не внедрять». Ничего не выносить, не давать доступов, не запускать пилоты и не использовать ИИ в рабочих процессах.

Почему запрет — это не стратегия

Запрет не решает проблему безопасности. Он становится паузой, которая очень быстро превращается в технологическое отставание.

Бизнес всё равно будет искать инструменты, ускоряющие работу. Сотрудники всё равно будут пробовать внешние сервисы, а подразделения будут запускать неформальные пилоты. Если у компании нет своего управляемого AI-контура, вместо безопасности она получает теневое использование ИИ, где нет правил, журналов аудита, ролевой модели и ответственности.

Альтернатива прямо сейчас

Правильной альтернативой прямо сейчас становится введение временного управляемого регламента:

1. Белый список сервисов. Компания утверждает перечень доступных внешних инструментов исключительно для открытых задач.
2. Корпоративные аккаунты. Заводятся учётные записи с принудительно отключенным обучением моделей на данных пользователей.
3. Красные линии. Вводится строгий запрет на загрузку конфиденциальной информации, ПДн, производственных секретов и исходного кода.

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

Поэтому вопрос давно не в том, использовать ИИ или не использовать. Вопрос в том, где и как его использовать.

Корпоративный ИИ — это цифровой сотрудник с доступом

Во многих проектах нейросети ошибочно воспринимают как обычное прикладное ПО. На практике корпоративный ИИ гораздо ближе к полноценному цифровому сотруднику с широкими правами в системе:

• Он читает документы, получает вопросы от пользователей и ищет информацию по корпоративной базе знаний.
• Работает с договорами, техническими файлами, обращениями, регламентами, изображениями, видео, а также производственной и эксплуатационной документацией.
• Может быть глубоко встроен в ключевые корпоративные системы: CRM, ERP, ECM, Service Desk, MES или внутренние порталы.

Такому инструменту нельзя доверять по принципу обычного внешнего чат-бота. Если ИИ получает доступ к корпоративному знанию, у него должны быть понятные роли, границы, журналы, правила работы с данными и ответственность за результат.

Пока у ИИ нет периметра, ролей, логов и понятной эксплуатации — это не промышленный инструмент. Это демо.

Что на самом деле нужно защищать в AI-контуре

В AI-проектах часто недооценивают масштаб задачи, полагая, что защищать нужно только исходные документы. В действительности внутри контура возникает целый пласт новых сущностей:

• пользовательские запросы и ответы модели;
• embeddings и векторные индексы;
• история диалогов, метаданные и логи;
• права пользователей и роли;
• интеграции с корпоративными системами;
• файлы, изображения и видео.

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

Именно поэтому вопрос информационной безопасности в ИИ становится частью архитектуры контура с первого дня.

Для перехода к реальной эксплуатации система должна давать четкие ответы на базовые архитектурные вопросы:

• где лежат данные и где создаются индексы?
• какая модель используется?
• кто видит запросы и где хранятся ответы?
• как разграничиваются права и что пишется в журнал?
• как удаляются данные и кто отвечает за ошибку модели?

Если на эти вопросы нет ответа — промышленной эксплуатации не будет. Будет пилот, презентация и дальнейший спор между бизнесом, IT и ИБ.

Локальный AI-контур как третий путь

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

Локальный AI-контур представляет собой изолированную корпоративную среду, где данные, модели и сервисы остаются строго внутри инфраструктурного периметра компании. При этом само по себе локальное развертывание не гарантирует безопасность автоматически, потому что оно лишь создает фундамент, необходимый службе ИБ для полного контроля над системой.

На практике контур усиливается комплексом целевых защитных механизмов:

• интеграцией с IAM/SSO и ролевой моделью доступа;
• шифрованием векторных баз данных;
• централизованным управлением секретами;
• защитой на уровне обработки ввода от атак типа prompt injection.

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

Именно здесь возникает альтернатива глухому запрету. Вместо выбора между «полным отказом от внедрения» и «неконтролируемым использованием публичных сервисов» компания строит инфраструктурную среду, где ИИ функционирует в рамках прозрачных и проверяемых корпоративных правил.

Почему это не просто софт

Разработка прикладных AI-пилотов — RAG-систем, корпоративных ассистентов, инструментов обработки документов и поиска по базам знаний уже стала зрелым рынком, и ПСМ не заходит в пустое поле. Однако корпоративному заказчику всё чаще требуется не просто изолированное программное решение, а полноценный архитектурный контур.

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

В этом заключается логика ПСМ. Компания пришла в сферу ИИ не как классический софтверный стартап, а как промышленная инженерная компания. Направление ПСМ UNLIM выросло из практических задач заводской автоматизации — работы с ERP, MES, SCADA, системами мониторинга, предиктивной аналитикой, а также производственными и эксплуатационными данными.

Именно поэтому ИИ изначально воспринимается как органичная часть промышленной среды. При этом заказчику не предлагают строить масштабный дата-центр ради проверки одной гипотезы. Подход остается гибким: пилот или локальный сервис разворачивается в формате 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-инструменты: автоматизация проверки и ускорение согласования договорной документации.
• Производственная видеоаналитика: контроль рабочих процессов на промышленных площадках.

Развертывание каждого из этих сервисов на практике выявило одну и ту же закономерность: работающая модель — это лишь малая часть проекта. При переходе от демо к эксплуатации каждый сценарий требует решения критических инфраструктурных и организационных вопросов. Какие категории корпоративных данных допустимо передавать на вход системе? Как разграничить права доступа сотрудников к итоговым результатам генерации? Где именно хранятся логи и история запросов? Допустимо ли использование внешних облачных API или требуется полная изоляция? Кто несет ответственность за верификацию ответов и как поддерживать решение после завершения пилотной стадии?

Этот опыт подтвердил, что ИИ невозможно эффективно развивать как набор разрозненных точечных сервисов. Система должна проектироваться как единый, управляемый с первого дня локальный контур с зафиксированными правилами безопасности и архитектурными границами.

Почему контур строится до пилота, а не после

Классический путь ИИ-проекта в корпорации часто выглядит одинаково: бизнесу быстро показывают ценность технологии («магию ИИ») на пилоте, собранном на коленке, на синтетических данных или во внешнем облаке в обход строгих ИБ-процедур. Но как только встает вопрос перехода от демо к реальной работе с внутренними данными, проект мгновенно упирается в глухую стену безопасности.

Без предварительно согласованного периметра ИБ просто блокирует проверку гипотез. Чтобы пилот дал честный результат и не споткнулся о требования безопасности, мы разделяем его на два понятных этапа:

• Технический pre-pilot: отладка RAG-маршрутов, моделей и интерфейсов проходит на синтетических датасетах, открытых регламентах или глубоко обезличенных данных. Это доказывает работоспособность архитектуры без касания коммерческой тайны.
• Бизнес-пилот: проверка реального эффекта на процессах выполняется на ограниченном сэмпле внутренних документов, но строго внутри изолированного и согласованного с ИБ контура.

Что гарантирует архитектурный контур еще до старта пилота:

• Определены границы и периметр: сразу понятно, какие данные используются, где они хранятся и выходит ли поток за пределы компании.
• Разграничены права и роли: система видит только то, что положено пользователю по его профилю.
• Настроена политика аудита и логирования: фиксируются факты обращения, действия моделей и вызовы API, а сами тексты запросов и ответов маскируются и хранятся строго по правилам ИБ компании, чтобы логи не превращались в еще одну незащищенную базу данных.
• Назначен владелец и процесс: выбирается один понятный сценарий, один ответственный и конкретные метрики качества.

Когда пилот разворачивается внутри готового контура, он перестает быть неконтролируемым риском или бесконечной дискуссией с ИБ. Он становится предсказуемым инженерным экспериментом, который заканчивается управленческим решением: масштабировать, дорабатывать или закрывать.

Путь к корпоративной архитектуре

Сценарий развертывания всегда зависит от текущего IT-ландшафта компании. Кто-то начинает с легкого формата AI Factory-light на имеющихся виртуальных машинах, а кто-то сразу проектирует выделенную инфраструктуру. Однако системное внедрение неизменно начинается с безопасности и строится в четыре шага: 

1. Проектирование ИБ-периметра. До старта любых вычислений фиксируются базовые правила: настраивается ролевой доступ (IAM/SSO), шифруются векторные базы, вводится обязательное маскирование чувствительных данных и задаются политики аудита для работы моделей.
2. Подготовка вычислительного базиса. Мощности подбираются строго под реальные потребности. На старте достаточно прикладного слоя AI Factory-light в существующей среде, а тяжелые узлы AI Cluster и инженерная база AI Base подключаются по мере масштабирования задач.
3. Интеграция модельного слоя. Разворачивается прикладной слой (AI Factory) и настраивается его бесшовная связка с корпоративными учетными и производственными системами: ERP, CRM, MES, SCADA.
4. Запуск и обкатка сценариев. Только внутри защищенного и согласованного с ИБ контура запускаются целевые бизнес-задачи: интеллектуальный поиск по базе знаний, проверка договоров или производственная видеоаналитика.

В таком подходе пилот перестает быть временной конструкцией «на выброс». Это первое безопасное прикладное применение уже готовой корпоративной платформы.

Что дальше

Глухой запрет ИИ не делает компанию безопаснее. Он лишь критически замедляет бизнес. Хаотичный запуск моделей без выделенного периметра неизбежно приводит к рискам и теневому использованию сервисов. Реальное преимущество получают те, кто изначально строит управляемую среду для промышленной эксплуатации технологии.

Для ПСМ локальный AI-контур стал новой инфраструктурной категорией, объединяющей инженерию, вычислительные мощности, безопасность данных и прикладной ИИ.

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