Пилот успешно отработал, демо впечатлило коллег и руководство, бюджет на развитие направления выделен — ситуация, знакомая всем, кто так или иначе касался внедрения искусственного интеллекта в корпоративную среду. Затем наступает момент, когда отдел информационной безопасности накладывает запрет на передачу клиентских данных во внешние API, финансовый директор предъявляет счет от облачного провайдера, который незаметно вырос вдвое, а юристы в очередной раз напоминают, что контракты с NDA не имеют никакого права покидать корпоративный периметр.
ИИ-инициатива в корпорации — это история про инфраструктуру, которая является основой для запуска ИИ-моделей. Без правильно спроектированной инфраструктуры даже самая совершенная нейросеть, если в нее вложить миллионы так и не станет рабочим инструментом. О том, почему и как тут может помочь ПАК (программно-аппаратный комплекс), — в статье.
Ситуация, которую мы описали выше, возникает из-за системного разрыва между условиями пилотного проекта и требованиями реальной эксплуатации. Например, на пилоте будет 10 пользователей и тщательно «причесанные» данные, а в проде — тысяча сотрудников и поток документов, среди которых попадаются паспортные данные, номера телефонов, условия договоров и прочая чувствительная информация.
На пилоте можно пренебречь безопасностью, детальным мониторингом и учетом затрат, потому что масштаб позволяет закрыть на это глаза. В реальной среде такая роскошь недоступна.
Рассмотрим ключевые проблемы, которые возникают при переходе от пилота к эксплуатации и которые чаще всего можно наблюдать в ИИ-проектах:
- Отсутствие фильтра персональных данных. Служба безопасности не пропускает проект, и это решение сложно оспорить, не предложив работающего механизма обезличивания данных.
- Отсутствие системы квот и лимитов. Финансовый директор не видит, кто и сколько тратит, а без этой информации управлять бюджетом ИИ-проекта невозможно.
- Одна модель на все задачи. Попытка закрыть потребности всех отделов одной LLM приводит к перерасходу бюджета и нарушению требований безопасности.
Разберем основные причины, по которым ИИ-проекты умирают на пути в прод, и рассмотрим связку, которая устраняет их на этапе проектирования. Редакция выбрала ПАК, готовую AI-архитектуру, состоящую из:
- ITPOD — GPU-серверы для локального ИИ в закрытом контуре.
- Ainergy — on‑premise платформа управления генеративным ИИ, которая в связке с GPU-сервером создает безопасный и управляемый корпоративный ИИ.
- ITGLOBAL.COM — интегратор, обеспечивающий бесшовную сборку, внедрение и круглосуточную поддержку.
Причина 1. Фильтр персональных данных
Что делать, когда служба безопасности говорит «нет»
При подключении сотрудников к облачным LLM (будь то ChatGPT, Claude, Gemini или любой другой популярный сервис) естественным образом возникает вопрос о том, как быть с персональными данными, которые неизбежно попадают в запросы. ФИО сотрудников и клиентов, номера телефонов, реквизиты договоров и паспортные данные не должны покидать корпоративный контур. Это требование законодательства, внутренних политик безопасности и, что немаловажно, здравого смысла.
В такой ситуации служба безопасности отвечает отказом. И она совершенно права, потому что без встроенного механизма обезличивания ИИ-проект в регулируемых отраслях (финансы, ритейл, промышленность, госсектор) запускать нельзя. Пилот этот фактор не выявляет, так как на маленькой выборке и тестовых данных можно делать вид, что проблемы не существует. В production она становится непреодолимым барьером.
Как тут может помочь ПАК
On-premise платформа Ainergy — сервис фильтрации персональных данных (PII-фильтр), который обрабатывает каждый запрос до того, как тот отправится в облачную модель. Сервис работает в трех режимах, которые настраивает админ платформы в зависимости от требований конкретного проекта:
- Блокировка — запрос, содержащий персональные данные, не уходит в облачную модель вовсе. Самый жесткий сценарий для максимально чувствительных данных.
- Маскирование — чувствительные данные перед отправкой во внешнюю LLM подменяются на маски-плейсхолдеры, внешняя LLM получает обезличенный текст, а при возврате ответа сервис возвращает данные на место плейсхолдеров. Сотрудник работает в обычном режиме и не замечает подмены. Модель обработала весь контекст без реальных персональных данных.
- Перенаправление на локальную LLM — защищенный сценарий, когда после детекции ПДн запрос направляется не в облачный сервис, а маршрутизируется на модель, развернутую на сервере ITPOD внутри корпоративного периметра. Все данные остаются на территории заказчика.
В свою очередь в этой связке ITPOD предоставляет вычислительные ресурсы для локального развертывания моделей внутри периметра. ITPOD обеспечивает физическую изоляцию и достаточную вычислительную мощность для работы локальных LLM с задержками, неотличимыми от облачных сервисов.
В результате служба безопасности согласовывает проект, потому что получает работающий инструмент контроля. Чувствительные данные не покидают периметр. Сотрудник продолжает работать в привычном интерфейсе, не меняя своих привычек.
Причина №2. Квоты и лимиты. Логи и аудит
Что делать, когда возникают вопросы от финансового директора
Примерно через полгода после запуска облачного ИИ-сервиса финансовый директор получает счет от провайдера. Сумма оказывается в 2–3 раза выше той, что закладывалась в бюджет. Начинаются выяснения, а кто же использовал столько токенов? Маркетинг ссылается на разработку, разработка — на HR, а HR — на аналитический отдел. Каждый уверен, что перерасход случился не по его вине.
Ситуация возникает из-за отсутствия прозрачного учета потребления. На пилоте, где работает несколько человек, можно отслеживать затраты «на глаз». В проде, где моделями пользуются сотни сотрудников из разных отделов, без автоматизированного биллинга управлять бюджетом становится невозможно.
Как тут может помочь ПАК
Ainergy содержит встроенную систему квот и лимитов, которая в реальном времени собирает данные о потреблении по каждому пользователю и каждому подразделению. Дашборды и отчеты опираются на логи.
ITPOD обеспечивает стабильную вычислительную базу с предсказуемой стоимостью владения, то есть никаких внезапных скачков счетов.
В результате, когда финансовый директор задает вопрос о расходах, ответ уже готов и представлен в виде дашборда с точными цифрами. Споры о бюджете либо не возникают, либо разрешаются на основе данных, а не эмоций.
Причина №3. Одна модель на все задачи
Одна крупная мультимодальная LLM на все задачи компании — дорого и нецелесообразно
Есть распространенный сценарий, в котором компания покупает доступ к одной мощной облачной LLM и предоставляет ее всем отделам без ограничений. Зачастую кажется, что это простое и экономичное решение, ведь есть один договор, один интеграционный шлюз, а все пользуются одним и тем же инструментом.
В реальности такой подход порождает более глубокие проблемы:
- Проблема первая — безопасность. Юридический отдел, отдел по работе с контрактами и финансы не могут выгружать в облако документы, содержащие коммерческую тайну и персональные данные. Для них использование облачной LLM закрыто по определению. Им нужна локальная модель в закрытом контуре.
- Проблема вторая — экономика. Разработчикам действительно требуются мощные модели для решения сложных задач по генерации кода и архитектурного анализа. Но менеджерам, которым нужно написать письмо, сделать выжимку из документа или перевести абзац текста, вполне достаточно легкой локальной модели.
Как тут может помочь ПАК
Ainergy выступает единым шлюзом доступа к ИИ-моделям, распределяя права и ресурсы в соответствии с ролями пользователей. Например, сотрудник финансового отдела не сможет отправить запрос во внешний облачный сервис, если такая возможность не предусмотрена его уровнем доступа.
Для разработчиков, напротив, можно настроить повышенные лимиты и отдельные квоты, чтобы работа с моделями не прерывалась в критические моменты тестирования или отладки. Руководители проектов при этом получают централизованную картину использования ИИ-инструментов: какие модели задействуются, насколько активно они используются и какие подразделения обращаются к ним чаще всего.
Кроме того, Ainergy поддерживает гибридную маршрутизацию запросов. Простые и массовые задачи могут автоматически обрабатываться локальными моделями, что снижает затраты на инференс, тогда как ресурсоемкие запросы перенаправляются в облачные модели с более широкими возможностями. Такая логика настраивается на уровне платформы и не требует изменений в существующих интеграциях или прикладном коде.
В свою очередь, ITPOD в этой архитектуре обеспечивает локальное размещение вычислительных ресурсов, что позволяет сохранять контроль над конфиденциальными данными и делает расходы на инференс более предсказуемыми по сравнению с полностью облачным подходом.
Зачем в этой связке интегратор ITGLOBAL.COM
Все перечисленные сценарии требуют не только программной платформы, но и полноценной инфраструктурной подготовки. Серверы необходимо разместить в стойках, подключить к сетевой и инженерной инфраструктуре, настроить системы хранения данных и охлаждения. Саму платформу управления нужно развернуть, интегрировать с корпоративными сервисами и адаптировать под требования конкретной организации.
Отдельной задачей становится проектирование политик доступа, квотирования и учета потребления ресурсов с учетом существующей структуры подразделений и бизнес-процессов.
В этой части ITGLOBAL.COM выступает в роли интегратора, обеспечивая внедрение решения на всех этапах — от проектирования архитектуры до дальнейшей эксплуатации. Компания помогает подобрать вычислительные ресурсы под задачи заказчика, развернуть платформу Ainergy в локальном контуре и обеспечить ее совместимость с уже используемыми системами.
В состав работ интегратора обычно входят:
- архитектурный аудит и проектирование решения;
- поставка и монтаж серверного оборудования ITPOD в ЦОД заказчика;
- развертывание и настройка on-premise платформы Ainergy;
- интеграция с корпоративными системами, включая CRM, ITSM, HRM и BI-платформы;
- обучение сотрудников;
- последующая техническая поддержка в рамках согласованного SLA.
Что в итоге
Переход от пилотных проектов к промышленной эксплуатации ИИ-систем связан не столько с масштабированием моделей, сколько с созданием полноценной инфраструктурной среды для их использования. На этом этапе становится недостаточно точечно дорабатывать отдельные системы. Требуется платформенный подход, при котором вопросы безопасности данных, разграничения доступа, маршрутизации запросов и контроля потребления ресурсов учитываются на уровне архитектуры с самого начала.
Практика показывает, что самостоятельная сборка такой среды из отдельных открытых компонентов требует значительных временных затрат и часто сопровождается сложностями при интеграции и сопровождении. Использование готового программно-аппаратного комплекса, объединяющего вычислительную инфраструктуру, средства управления нейросетями и интеграционную экспертизу, позволяет сократить сроки внедрения, планировать бюджет с высокой точностью, контролировать затраты и снизить количество технических рисков.
Требования к инфраструктуре напрямую зависят от задач, для которых внедряют ИИ-технологии: обработка обращений клиентов, анализ документов, автоматизация технической поддержки, управление документооборотом, юридическая экспертиза или генерация контента. Универсальной конфигурации, одинаково подходящей для всех сценариев, не существует — архитектура решения всегда определяется характером нагрузки, масштабом использования и требованиями организации к безопасности и контролю данных.