On-prem ИИ-платформа: 7 слоев архитектуры

2026-11-09 · Слаживание

Я начинаю проектирование on-prem ИИ-платформы с одного бизнес-процесса, а не с выбора модели. Сначала фиксирую владельца, критерии качества и стоимость принятого результата в ₽. Затем связываю задачу с семью слоями:

1. Инфраструктура - вычисления, хранение и восстановление после сбоев.
2. Модели - качество ответов, время ожидания и расход ресурсов.
3. Данные - актуальный контекст и поиск в пределах прав сотрудника.
4. Интеграции - доступ к рабочим системам и проверка действий.
5. Безопасность - защита данных, журналирование и проверка требований 152-ФЗ.
6. Управление агентами - порядок шагов, лимиты, подтверждения и остановка.
7. Прикладные сервисы - задачи отделов с владельцем и измеримым результатом.

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

Мой критерий перехода к масштабу - пройденная приемка пилота. До запуска я задаю пороги качества, сроков и затрат, а после - сравниваю результат с исходными показателями, включая время сотрудников на проверку.

Будущее ИИ - не в гигантских моделях, а в архитектуре, памяти и автономности

Слои 1–3: инфраструктура, модели и данные

Разберем требования по трем базовым слоям: вычисления, модели и данные.

Прежде чем выбирать оборудование, оцените всю нагрузку: число операций, пиковое количество одновременных запросов, допустимое время ожидания и объем данных. Помимо ответов сотрудникам, учтите фоновые задачи: извлечение фактов из документов, переписки и встреч для памяти компании [1][4].

Слой 1: вычисления, хранение и восстановление

От мощности первого слоя зависит, сможет ли платформа поддерживать целевой процесс без ручных обходов. Задайте требования к резервному копированию, репликации и срокам восстановления. Отдельно оцените нагрузку от ответов сотрудникам, обработки данных и пополнения памяти компании [1]. Заранее учитывайте время на долгое рассуждение: сложные запросы требуют больше времени [3].

Слой 2: выбор моделей и инференс

Маршрутизация моделей нужна не только для скорости, но и для качества ответов и соблюдения границ контура данных. Направляйте рутинные запросы быстрым моделям, а сложный анализ - моделям с большими вычислительными затратами. Сравнивайте качество, время ожидания и расход ресурсов на рабочих задачах. Запросы с чувствительными данными должны оставаться в разрешенном контуре [2][3].

Слой 3: потоки данных и поиск с учетом прав

Собирайте данные из операционных систем, документов и коммуникаций. Они дают платформе общий контекст для поиска и работы агента. Выделяйте из них факты и договоренности. Ограничивайте поиск правами сотрудника еще до формирования ответа, а личную переписку исключите из общей памяти [1][4].

Установите правила обновления данных и регулярной проверки на устаревшие сведения и противоречия. Без этого платформа будет быстро выдавать неактуальные ответы [4].

Дальше нужно связать данные и модели с системами и задать границы допустимых действий.

Слои 4–6: интеграции, безопасность и управление агентами

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

Слой 4: подключения к системам и контроль действий

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

При каждом вызове сохраняйте сведения об инициаторе: агент должен работать с правами пользователя, а не общей технической учетной записи [1][3]. До выполнения проверяйте параметры, права и лимиты. Отправка писем, смена этапа сделки и финансовые действия требуют подтверждения человеком: агент готовит действие, пользователь выполняет его окончательно [1][5].

Слой 5: безопасность и российские требования к данным

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

Запрет передачи данных наружу должен действовать даже при сбоях. Если локальная модель недоступна, отправлять запрос внешней модели нельзя. Защитите журналы действий от изменения, ограничьте доступ к ним и срок хранения. Не записывайте пароли, токены и лишние персональные данные [1][2][3].

Слой 6: выполнение и жизненный цикл агентов

Оркестратор управляет цепочкой действий: поиск → проверка → выполнение → эскалация. Он отслеживает статусы задач, ожидание подтверждений и ошибки. Задайте пределы числа шагов, времени и расходов. После сбоя сначала проверьте, выполнилась ли операция, и только затем решайте, нужен ли повтор. Ошибки и неоднозначные решения передавайте ответственному сотруднику [1][3].

Разрабатывайте и проверяйте агента в изолированной среде. Сохраняйте версии модели, инструкций, инструментов и политик, согласовывайте выпуск. Заранее предусмотрите откат, аварийную остановку и отзыв доступов при выводе агента из эксплуатации.

Отслеживайте успешность задач, ответы без опоры на данные, ошибки инструментов, задержку, расходы, нарушения политик и передачи задач человеку. В подходе «Слаживания» автономность повышают по результатам проверок: чем меньше правок требует агент, тем больше рутины ему можно доверить [5].

Следующий слой - прикладные сервисы для продаж, кадров и финансов.

Слой 7: прикладные сервисы и владельцы процессов

После слоев 1–6 платформа готова к запуску прикладных сервисов. Каждый процесс получает владельца, метрики и правила приемки. Так платформа превращается в сервисы отделов с измеримым результатом.

Сервис описывают через бизнес-процесс отдела, а не через модель. За результат каждого сервиса отвечает один владелец.

Задачи сервисов и критерии успеха

Для первого запуска выбирайте повторяемую задачу, для которой есть доступные данные и способ проверить результат.

Продажам подойдут квалификация лидов и сопровождение сделки, финансам - обработка первичных документов и сверка, HR - отбор резюме [2][3].

До разработки составьте паспорт сервиса. Укажите интерфейс сотрудника, событие запуска, источники контекста, разрешенные действия, точки согласования, итоговый документ или запись, SLA и владельца. SLA определяет срок получения результата и порядок передачи задачи сотруднику. Отдельно запишите, кто принимает качество ответа, а кто подтверждает изменение в учетной системе.

Замерьте исходные показатели до пилота и сравнивайте задачи одинаковой сложности. Считайте стоимость принятого результата, а не отдельного ответа модели. Включайте в расчет вычисления, поддержку и время, которое сотрудник тратит на проверку. Сэкономленные часы учитывайте отдельно: меньше рутины не всегда означает меньше расходов.

Внедрение и освоение со «Слаживанием»

«Слаживание» объединяет платформу, методологию и команду внедрения. Работа включает диагностику процессов, измеримые пилоты, перенастройку процесса и закрепление навыков сотрудников [1][3].

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

Обучение стройте вокруг рабочих задач. Сотрудник должен знать, как проверить результат, внести правку и сообщить об ошибке владельцу сервиса.

Дальше эту схему сводят в общую карту слоев и проверяют на одном пилотном процессе.

Итог: соберите схему и проверьте один пилот

Обозначьте границы платформы и приложений

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

Затем проверьте, соответствует ли схема требованиям безопасности и отказоустойчивости. Покажите безопасность сквозным слоем, который проходит через обе части. Подпишите потоки данных, интерфейсы, внешние зависимости, разрешения и точки подтверждения действий. Для каждого блока укажите ответственного по имени - одного названия отдела недостаточно.

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

Спланируйте запуск и проверьте готовность пилота

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

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

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

FAQs