Привет, Хабр. Меня многие знают по Доброделу, ДИТ Москвы и Monq, но эта статья не про биографию. Она про архитектурную развилку, на которой сейчас окажется почти каждый вендор корпоративного ПО. Я много лет провёл в больших корпоративных ИТ-контурах. Помню время, когда CSS на сайте уже казался инновацией. Поэтому нынешний хайп вокруг LLM я воспринимаю не как спор «какая модель лучше - Gemini или Claude», а как начало нового класса корпоративного ПО.
Главная мысль этой статьи простая: не надо встраивать ИИ в каждую корпоративную систему как отдельный самостоятельный AI-контур. Пользователь должен видеть ИИ там, где работает: в CRM, СЭД, ITSM, мониторинге, портале или корпоративном чате. Но ИИ-процессы, модели, GPU, gateway, лимиты, аудит, политики доступа и ответственность должны жить в отдельном корпоративном слое.
ИИ должен быть доступен из каждой корпоративной системы, но не должен принадлежать ни одной из них.
Как бухгалтер работает и в 1С, и в почте, и на корпоративном портале, так и корпоративный ИИ должен уметь работать с разными системами, не превращаясь в модуль одной из них.
Самый простой способ увидеть абсурд AI Inside - посмотреть не на интерфейс, а на инфраструктуру. Компания не будет покупать отдельный GPU-сервер для ERP, отдельный GPU-сервер для CRM, отдельный GPU-сервер для СЭД, отдельный GPU-сервер для ITSM и отдельный GPU-сервер для мониторинга. Модель тоже не должна жить отдельно в каждой системе. Если GPU общий, модели общие, gateway общий, лимиты общие и аудит общий, значит корпоративный ИИ уже стал отдельным слоем. Здесь я ещё не говорю даже о знаниях. Осталось признать это архитектурно.
Как мы почти встроили ИИ в Monq
Мы с командой развиваем Monq, этот продукт уже обслуживает более 5 млн объектов ИТ-инфраструктуры более чем в 50 организациях. Продукт просто создан для того, чтобы к нему подключили ИИ. Ещё в начале прошлого года у нас на столе лежало очень простое продуктовое решение: встроить LLM в Monq и сделать копилот инженера. Сделать умный разбор инцидентов, интеллектуальный RCA, прикрутить смарт-корреляции, добавить чат по документации, научить систему писать постмортемы, разбирать инциденты и назвать это AIOps-системой нового поколения. Потом, конечно, показать на конференции красивое демо.
Честно: это было бы логично. И, скорее всего, продавалось бы. Когда ты много лет строишь enterprise-продукт, очень трудно устоять перед соблазном сказать: «ну вот, теперь и мы добавим ИИ в наш продукт». Тем более рынок вокруг уже похож на гирлянду из копилотов: у каждой системы свой «умный помощник», у каждого вендора свой AI inside, у каждой кнопки свой маленький пророк. Но сколькими из них вы реально пользуетесь?
Но чем дальше мы это обсуждали, тем яснее становилось: если мы просто встроим ИИ в Monq, мы сделаем красивую фичу — и промахнёмся мимо главного.
К этой мысли нас подтолкнула не только теория. Мы уже видим, как крупные клиенты используют ИИ рядом с Monq: в ритейле, банке и производственной компании. Архитектурно сценарии похожи: ИИ развёрнут отдельным корпоративным контуром, получает доступ к нужным данным через управляемые интерфейсы, забирает контекст инцидента, смотрит связанные события, изменения, документы или историю, анализирует всё это и возвращает результат обратно в рабочий процесс - в карточку инцидента, комментарий, черновик анализа или подсказку инженеру.
То есть ИИ ведёт себя не как модуль системы мониторинга, а как новый участник процесса. Примерно как человек: зашёл в систему, посмотрел инцидент, открыл связанные данные, сопоставил факты, сделал вывод и внёс запись. Только быстрее, стабильнее и лучше переваривая большой объём контекста.
Для нас это стало важным сигналом. Если ИИ всё равно работает поверх нескольких систем, странно зашивать весь этот контур внутрь одного продукта. Продукт должен дать ИИ нормальный управляемый интерфейс. Но сам корпоративный ИИ должен принадлежать компании, а не отдельному продукту или системе мониторинга.
И вот здесь я поймал себя на неприятной мысли. Рынок сейчас поощряет простое решение: добавить AI-слой внутрь продукта, красиво назвать, показать на конференции и получить восторженные комментарии. Но через год у клиента будет десять таких помощников, и никто не будет понимать, кто куда ходит, что логирует, какую модель вызывает и где проходит граница ответственности.
Если каждая корпоративная система начнёт рожать собственного маленького копилота, мы получим не трансформацию, а новый корпоративный зоопарк:
копилот в мониторинге;
копилот в документообороте;
копилот в продажах;
копилот в Service Desk;
RAG на коленке у юристов;
бот в закупках;
личные агенты у сильных сотрудников;
запретительный циркуляр от ИБ.
И ни одного общего ответа на вопросы: кто имеет доступ к данным, что логируется, какая модель вызывается, сколько это стоит, где человек должен подтвердить действие и кто отвечает за ошибку.
Самый страшный AI-инцидент начинается не с галлюцинации модели, а с фразы: «а кто ему вообще дал доступ к этой папке?»
Простая вещь: Ассистент – отвечает. Агент – делает. Это всем понятно. Но кто же за всем этим следит и управляет? – Операционный слой.
Если в компании есть один ассистент — это эксперимент.
Если десять агентов — это уже новая производственная система.
Если сто агентов без общего управления — это не цифровая трансформация, а цех, где каждому выдали инструмент, но забыли технику безопасности.
По сути, корпоративный ИИ становится третьим слоем между людьми и информационными системами. С одной стороны, он похож на человека: читает документы, ищет информацию, сравнивает версии, классифицирует обращения, объясняет инциденты и предлагает действия. С другой - остаётся машинным исполнителем: ему нужны права доступа, контекст, инструменты, лимиты, журналы, тесты, правила остановки и владелец ответственности. Поэтому это уже не кнопка. Это новый участник корпоративного процесса.
Monq научил нас не путать инструмент и слой управления
Monq появился не потому, что миру не хватало ещё одного мониторинга. Мониторингов как раз было много. И у нас на Хабре есть статья на этот счёт.
Zabbix видел одно. Prometheus — другое. APM — третье. Service Desk — четвёртое. Логи жили отдельно. Сетевые системы отдельно. Таблицы и ручные регламенты отдельно. А руководитель эксплуатации всё равно спрашивал: «так что у нас с сервисом?»
Когда инструментов становится слишком много, рынку нужен не ещё один инструмент, а слой управления над ними.
В крупных внедрениях Monq мы уже проходили похожую историю: десятки внешних систем, миллионы конфигурационных единиц, сотни сценариев автоматизации, миллионы метрик и событий в день. Ценность была не в том, чтобы заменить всё разом, а в том, чтобы собрать разрозненный ИТ-ландшафт в управляемую картину здоровья реальных объектов бизнеса под одним зонтиком.
С ИИ сейчас происходит то же самое. Моделей много. Чатов много. Агентов будет ещё больше. Но много моделей ещё не означает корпоративный ИИ, так же как много мониторингов не означает управляемость.
В какой-то момент меня окончательно добил не технический вопрос, а простой клиентский сценарий: «хорошо, Monq сможет объяснить инцидент. А этот же помощник сможет посмотреть изменения в ITSM, договор в СЭД на поставку новых серверов, заявку в 1С и протокол последнего совещания?»
Мне очень нравится сравнение, которое я привожу на встречах. Представьте, вы управляете большой строительной компанией. У вас сотни машин, в которые вы уже вложили миллиарды рублей. Можно встроить беспилотный модуль в каждый экскаватор. А можно сделать оператора, который умеет садиться за разные машины и работать с уже существующим интерфейсом.
Представьте, для экскаватора свой модуль управления, для погрузчика свой, для фуры свой, или проще сделать антропоморфного робота с навыками управления каждой машиной? В робототехнике похожая логика тоже видна: иногда проще научить нового исполнителя работать с уже существующей инфраструктурой, чем переделывать всю инфраструктуру под каждый новый механизм.
Бизнесу нужны не модели, а внедрения
У рынка сейчас странный перекос восприятия. Кажется, будто главный вопрос корпоративного ИИ звучит так: «какая модель лучше?»
Это важный вопрос, но точно не первый.
Сильные модели критически важны. Без них всё остальное бессмысленно. Но модель — это ещё не внедрение.
Модель — это двигатель. Без двигателя машина не поедет. Но если вы строите автопарк, вам нужны ещё диспетчеризация, маршруты, допуски, техобслуживание, контроль топлива, журналы, ответственность и правила, кто имеет право куда ехать.
С LLM то же самое. Можно взять хорошую модель. Можно развернуть локальную. Можно купить доступ к API. Можно поднять RAG на документах. Можно собрать агентный сценарий на n8n, Dify, LangChain или своём Python-коде.
Для первой проверки гипотезы это нормально.
Но как только прототип начинает жить дольше презентации, появляются вопросы, которые модель сама не решает:
кто имеет доступ к каким документам;
можно ли передавать эти данные конкретной модели;
где журнал запросов, ответов, источников и действий;
как ограничить стоимость токенов и GPU-времени;
где человек должен подтвердить действие;
кто отвечает за ошибку;
как перенести успешный сценарий из одного отдела в другой.
В какой-то момент «давайте просто подключим нейросеть» превращается в «а где у нас журнал действий за прошлую пятницу?»
Вот здесь и начинается корпоративный ИИ. Не там, где появилась первая красивая нейросетевая кнопка, а там, где компания столкнулась с доступами, ответственностью, стоимостью, аудитом и масштабированием.
Почему AI-агент сложнее обычной интеграции
Да, часть задач похожа на ESB, BPM, iPaaS, MDM или ITSM. Но AI-слой управляет не только интеграциями. Он управляет вероятностными исполнителями: моделями, контекстом, агентами, инструментами, источниками, валидацией человеком и стоимостью инференса.
Обычная интеграция обычно делает то, что ей сказали. AI-агент сначала «понимает», что ему сказали, потом решает, какой инструмент вызвать, потом ещё уверенно объясняет, почему так и надо было. Это мощно. И именно поэтому опасно.
У корпоративного AI-агента есть своя модель угроз: prompt injection через документы, утечка данных через контекст, неверные вызовы тулзов, несанкционированный доступ к источникам, выполнение действия без подтверждения, отравление базы знаний, некорректное цитирование источников и рост стоимости из-за циклов агента (уверен, эти кейсы вам знакомы).
Модель может быть вероятностной, но контур вокруг неё должен быть максимально детерминированным: кто имеет доступ, какие источники разрешены, какие инструменты можно вызвать, какие действия требуют подтверждения, где лежит журнал и как воспроизвести цепочку принятия решения. Именно этот детерминированный контур вокруг вероятностного ядра отличает промышленный AI-сценарий от красивого демо.
В продакшене недостаточно сказать «на демо отвечает хорошо». Нужны доверенные наборы: типовые вопросы, плохие вопросы, устаревшие документы, конфликтующие источники, проверки на отказ, проверки на доступы, проверки цитируемости и регрессионные тесты после изменения модели, промпта или индекса.
До подключения агента к данным нужно понимать классы данных: публичные, внутренние, конфиденциальные, персональные, коммерческая тайна, КИИ или режимный контур. Один и тот же агент не должен одинаково работать с инструкцией для сотрудников и с документом, который нельзя выносить за периметр.
Принцип минимальных привилегий должен применяться не только к людям и сервисным аккаунтам, но и к агентам: агенту выдаётся минимальный набор данных и действий под конкретный сценарий, а не «доступ ко всему, потому что он умный». У агента должны быть не только права на данные, но и права на действия: читать, создавать черновик, изменять, запускать runbook, отправлять, удалять. И эти права не должны быть одним булевым правилом agent_enabled=true.
Отдельная тема — память. Что агент помнит? Где это хранится? Кто может удалить память? Что попадает в следующий запрос? Как отличить рабочий контекст от аудита? Как не смешать контекст разных клиентов, ролей или подразделений? Без ответов на эти вопросы «умный помощник» очень быстро становится источником неявных утечек.
И ещё одна вещь, близкая мне в Monq: у AI-агентов тоже нужна наблюдаемость. Latency, стоимость, ошибки вызова, доля отказов, жалобы на галлюцинации, качество ответа, покрытие eval-наборов, дрифт после обновления модели или индекса — всё это такие же эксплуатационные сигналы, как метрики сервиса. Eval-наборы — это тестовые сценарии для качества и безопасности: типовые вопросы, плохие вопросы, конфликтующие документы, проверки отказа, проверки прав доступа и корректности ссылок на источники.
Теневой ИИ уже внутри компаний
Есть ещё одна неприятная вещь. Корпоративный ИИ уже внедрён во многих ваших организациях. Только часто он внедрён не приказом, не проектом, не через ИТ и не через службу безопасности. Он внедрён через личные телефоны сотрудников, домашние ноутбуки, внешние сервисы и личные аккаунты.
Люди пользуются ИИ, потому что он даёт личную продуктивность. Человек один раз увидел, что за десять минут можно сделать то, что раньше занимало два часа, и обратно он уже не хочет.
Можно написать запрет. Можно закрыть доступ к внешним сервисам с рабочих машин. Можно провести инструктаж. Всё это нужно, но не решает проблему полностью. У сотрудника остаётся телефон, личный аккаунт и дедлайн на завтра утром. Даже на режимном объекте. Примеров хватает: сотрудник фотографирует внутренний документ на личный телефон, телефон синхронизирует фото в облако, а человек даже не считает это ИБ-инцидентом.
Запрет без удобной альтернативы создаёт не безопасность, а теневой ИИ.
Для регулируемых отраслей это особенно болезненно. Персональные данные, коммерческая тайна, банковская тайна, режимные документы, КИИ, внутренние политики ИБ, 152-ФЗ и прочие ограничения не исчезают только потому, что модель «очень умная».
Важно быть точным: 152-ФЗ сам по себе не говорит «держите LLM только on-prem». 242-ФЗ про локализацию баз персональных данных российских граждан тоже не превращает каждый AI-сценарий в обязательный on-prem-проект. Но вместе эти требования заставляют оператора понимать, какие данные обрабатываются, где они хранятся, кому передаются, кто имеет доступ и какие меры защиты применяются.
А теперь попробуйте честно ответить на эти вопросы, если сотрудник отправил кусок договора или протокола во внешний чат, что с ним происходит дальше?
Поэтому вопрос уже не в том, появится ли ИИ в промышленности, банках, госсекторе, ОПК, медицине, юридических службах, поддержке и ИТ-эксплуатации. Он уже появился.
Вопрос другой: он будет теневым или управляемым?
Закрытый контур — это не «сервер с чатом»
В российских корпоративных продажах есть фраза, которую иногда произносят как заклинание: «нужно в закрытом контуре».
Часть рынка относится к этому скептически: опять всё усложняют, опять нельзя просто взять облако, опять безопасники тормозят прогресс. Я понимаю это раздражение. Но в реальных больших контурах закрытый контур часто не каприз, а нормальная модель риска и угроз.
Если вы работаете с судебными материалами, медицинскими документами, банковскими данными, обращениями граждан, закупками, технической документацией, промышленными регламентами или коммерческой тайной, вопрос «можно ли отправить это во внешний сервис?» перестаёт быть философским.
Часто ответ: нельзя.
Но закрытый контур — это не «купили сервер с GPU и поставили чат».
Это четыре слоя:
вычисления;
модели;
операционный слой;
люди и процессы.
Без первого нечему считать. Без второго нечему думать. Без третьего некому управлять. Без четвёртого никто не будет пользоваться.
GPU без очередей, лимитов и владельцев — это не инфраструктура, а очень дорогой способ греть воздух.
Для крупных организаций вопрос не сводится к «облако или on-prem». Нужна модель деплоймента под класс данных: что остаётся внутри периметра, что может идти через шлюз, какие модели разрешены, где хранятся эмбендинги, кто управляет ключами, как журналы попадают в контур ИБ и как сценарий отключается при инциденте.
В большом контуре операционный слой ИИ не может жить отдельно от ИБ: идентификация, роли, журналы, секреты, интеграция с SIEM/SOC, сегментация контуров, контроль действий и модель отключения должны проектироваться сразу, а не «после успешного пилота».
Самое сложное, кстати, почти всегда не железо и не модель. Самое сложное — люди. Не в смысле «они тормозят». А в смысле, что хороший ИИ-пилот меняет поведение организации. Люди перестают искать руками. Перестают копировать куски из старых документов. Перестают помнить по памяти то, что можно надёжно вытянуть из контекста. Перестают терпеть рутину, если один раз увидели, что можно быстрее.
Главная проблема — не запуск, а масштабирование
MVP сегодня собирается быстро. Иногда даже слишком быстро.
Один сильный инженер и один бизнес-заказчик могут за пару недель показать работающий сценарий: поиск по регламентам, черновик ответа, протокол встречи, сверка документов, анализ тикетов, классификация обращений.
На демо всё выглядит убедительно.
Но дальше начинается взрослая часть:
данные нужно регулярно обновлять;
права доступа нужно подтянуть из реальных корпоративных систем;
качество нужно измерять не на трёх красивых примерах, а на сотнях операций;
результат нужно встроить в рабочее место сотрудника;
ИБ должна понимать модель угроз;
бизнес должен видеть экономику;
ИТ должно понимать эксплуатацию;
владелец процесса должен быть готов поменять регламент.
Именно поэтому на ЦИПР-2026 уже открыто говорили: проблема бизнеса не в запуске AI-пилотов, а в масштабировании.
Мировая статистика говорит о том же. В McKinsey State of AI 2025 почти девять из десяти респондентов говорят, что их организации регулярно используют AI, но переход от пилотов к масштабному влиянию на бизнес остаётся незавершённым у большинства. Эффект получают не те, кто просто подключил модель, а те, кто перестраивает процессы, вводит правила, метрики, обучение, верификацию человеком и включают ответственность руководителей.
Для меня пилот заканчивается не тогда, когда демо понравилось руководителю, а когда есть владелец процесса, набор тестов, метрики качества, правила доступа, журнал действий, экономика операции и решение: масштабируем, дорабатываем или закрываем.
Экономику AI-сценария надо считать не “стоимость платформы против зарплаты сотрудника”, а стоимость операции до/после: время человека, стоимость модели или GPU, доля ручной проверки, процент ошибок, стоимость инцидента и стоимость сопровождения.
Один агент экономит часы. Сто агентов без управления экономят вам сон. Но польза от ИИ начинается на масштабе. Масштаб без операционного слоя превращается в хаос.
Что такое Unica AI технически
Если совсем приземлить, Unica AI — это не LLM и не “чат с документами”. Это слой исполнения и управления корпоративными AI-сценариями: между людьми, бизнес-приложениями, знаниями, агентами, моделями и правилами безопасности.
Первый контур — интерфейсы. У него две стороны. Первая — интерфейс для человека: рабочее место, где сотрудник общается с ассистентами и агентами, задаёт вопросы, запускает сценарии, получает ответы, черновики, протоколы, извлечённые данные, задачи и ссылки на источники. Вторая — интерфейс для бизнес-приложений: API, события, коннекторы, очереди, webhooks, MCP-инструменты. Через него AI-слой подключается к 1С, СЭД, ERP, CRM, ITSM, Monq, BI, телефонии и внутренним порталам. Смысл не в том, чтобы встроить отдельный ИИ в каждую систему, а в том, чтобы дать всем системам доступ к единому управляемому AI-слою.
Второй контур — знания. Здесь живут markdown-хранилище, файловое хранилище и RAG-контур. Markdown удобен для структурированной памяти: инструкций, регламентов, промптов, карточек сценариев, заметок агентов. Файловое хранилище нужно для PDF, DOCX, XLSX, презентаций, сканов, аудио, вложений и рабочих артефактов. А RAG — это уже не “папка с файлами”, а pipeline: принять документ, распарсить, разбить на чанки, построить embeddings, связать с источником, обновлять, удалять, версионировать и учитывать права доступа. Упрощая: файлы и markdown — это память и сырьё, RAG — способ безопасно достать из этой памяти нужный контекст. Для ассистентов RAG критичен, потому что они должны отвечать с источниками. Для агентов важны ещё и рабочие файлы как состояние задачи, промежуточные результаты и управляемая память сценария.
Третий контур — агентный runtime: workflow, правила базового агента-исполнителя, tools, skills, MCP, системные инструкции, промпты, approval-логика и жизненный цикл сценариев. Ассистент в основном отвечает: нашёл, объяснил, сослался на источник. Агент делает: классифицирует обращение, проверяет комплект документов, сравнивает версии договора, готовит черновик, создаёт задачу, вызывает разрешённый инструмент, запускает workflow. И здесь агент уже не должен быть “скриптом с фантазией”. У него должны быть права, ограничения, владелец, журнал действий, sandbox/dry-run, правила остановки и жизненный цикл: draft → test → pilot → production → disabled → archived.
Четвёртый контур — модели и AI Gateway. В корпоративном ИИ почти никогда не будет одной модели на всё. Одна LLM лучше подходит для быстрых ответов, другая — для анализа документов, третья — для кода, отдельно нужны OCR, ASR, TTS, embeddings, rerankers, локальные on-prem модели и иногда внешние API. AI Gateway нужен как единая точка управления: маршрутизация, приоритеты, fallback, ключи, лимиты, токены, биллинг, квоты по пользователям и сценариям, разрешённые модели для разных классов данных. Это слой, который отвечает на неприятные, но важные вопросы: какая модель была вызвана, почему именно она, сколько это стоило, можно ли было отправлять туда эти данные и кто сжёг бюджет.
Пятый контур — безопасность и эксплуатация. Здесь живут пользователи, роли, права, пространства, политики доступа, аудит, журнал запросов и действий, мониторинг безопасности, мониторинг работоспособности, аналитика использования, eval-наборы, контроль качества, алерты, разбор инцидентов и “пульс внедрения”: кто реально пользуется системой, какие сценарии взлетели, где стоимость растёт, где качество падает, какие ассистенты надо доработать или выключить. Без этого корпоративный ИИ остаётся красивой демкой, которую все хвалят, но никто не решается пустить в промышленную эксплуатацию.
Важно: всё это можно собрать на open source. Хороший пример — статья Sminex о корпоративной LLM-платформе: Open WebUI как единое окно для сотрудников, LiteLLM как AI Gateway, Langflow и MCP для сценариев и инструментов, vLLM/Ollama для inference, RAGFlow и собственные RAG-pipeline для знаний, Prometheus/Grafana и Langfuse для наблюдаемости. Их главный вывод мне близок: open source ускоряет старт, но боль проявляется на стыках — версии, совместимость, auth, обновления, отладка, лимиты, наблюдаемость и эксплуатация.
Но если собрать всё это самому, вы фактически начинаете строить внутренний AI-продукт. Его надо проектировать, обновлять, защищать, мониторить, документировать, обучать пользователей и поддерживать на стыках. А в российских enterprise-контурах добавляются ещё юридические вопросы с лицензиями, ответственность за работу и поддержку, санкционные риски, закрытые репозитории, требования ИБ, 152-ФЗ, реестр ПО, импортонезависимость и многое другое. Поэтому open source — отличный способ доказать архитектуру. Но промышленному контуру нужен собранный, проверенный и поддерживаемый операционный слой, желательно с вендором на том конце провода, который поможет вам снизить риски.
Если схематично, то это выглядит так:
В этой схеме Monq не теряет роль. Наоборот, становится одним из важнейших источников оперативного контекста для обработки инцидентов и средством контроля и observability ИИ-платформы. Но ИИ остаётся отдельным классом, потому что управляет не только инцидентами, а цифровым трудом компании.
Такой же паттерн возникает в банке, ритейле или госсекторе. Агенту мало «ответить по базе знаний». Ему нужно проверить документы, сходить в несколько систем, учесть роль пользователя, не показать лишнего, сослаться на источник, запросить подтверждение перед действием и оставить журнал.
Это уже не чат. Это управляемый процесс.
Почему мы решили, что базовый контур должен быть открытым
У Monq есть бесплатная версия. Она помогла рынку потрогать продукт, но бесплатность сама по себе не делает стандарт. С Unica AI мы решили пойти дальше.
Базовый контур должен быть открытым, потому что слой, который работает с корпоративными данными, моделями, агентами и аудитом, не должен быть чёрным ящиком. Из такого ящика может выпасть что угодно: утечка ключей, странный вызов внешней модели, небезопасный prompt или зависимость, которую никто не проверял.
Проблема такого черного ящика решается высоким уровнем доверия потребителя. Его можно либо заслужить открытым ядром, либо принадлежностью к пантеону ИТ-брендов, которые “уж точно сделают все правильно” (но я бы этому не доверял). Нам осталось открыть ядро.
Его должны иметь возможность поднять, посмотреть, покритиковать, сломать, починить и встроить в свой контур.
Открытое ядро - это не открытие данных заказчика. И оно не гарантирует отсутствия уязвимостей. Но оно даёт возможность их искать, обсуждать и исправлять, а не верить на слово закрытой коробке.
Я не считаю open core бездумным маркетингом. Это компромисс: базовый слой должен быть проверяемым и полезным, а промышленная эксплуатация, SLA, SSO, лимиты, аудит и поддержка — всё то, что нужно уже для крупного бизнеса и больших федеральных внедрений, может быть коммерческой историей.
Рынок корпоративного ИИ только формируется и ему нужен понятный инженерный стандарт нижнего слоя.
Ошибки корпоративного внедрения ИИ
Если коротко, я бы не советовал компаниям делать пять вещей.
Первая — начинать с выбора модели. Модель важна, но начинать нужно с процесса, данных, владельца и метрики эффекта.
Вторая — делать один большой «ИИ-проект». Лучше 3–5 коротких сценариев с понятной экономикой, чем годовая программа без результата.
Третья — путать MVP и промышленный контур. MVP может работать на ручной выгрузке. Продуктив требует ролей, логов, интеграций, мониторинга и ответственности.
Четвёртая — плодить ассистентов без управления. Через полгода никто не понимает, какие данные куда ушли, какая модель используется, кто платит за токены и почему два ассистента дают разные ответы.
Пятая — не готовить людей. Если сотрудник не понимает, где ИИ помогает, где ошибается и как проверять результат, внедрение будет либо саботироваться, либо использоваться опасно.
В критичных контурах я бы начинал не с автономных действий, а с read-only и draft-only сценариев: найти, объяснить, сравнить, подготовить черновик, показать источник, сформировать отчёт. Только потом — действия с подтверждением. И только после этого — ограниченная автоматизация там, где есть регламент, права и откат.
Я не считаю AI-агента сотрудником в юридическом или человеческом смысле. Но как эксплуатационная единица он всё больше похож на цифрового исполнителя: у него есть задача, доступы, инструменты, журнал действий, стоимость и владелец.
Рынок ИИ только формируется
Я не думаю, что у нас уже есть все ответы. Рынок только формирует язык: где заканчивается RAG, где начинается агент, где нужен BPM, где достаточно скрипта, как измерить качество, кто владеет агентом — ИТ или бизнес, и кто отвечает за ошибку в процессе, где решение предложила модель, а подтвердил человек.
Но именно поэтому, на мой взгляд, этот слой должен быть открытым для инженерного обсуждения. Сейчас опаснее всего не ошибиться в названии категории. Опаснее закрыть всё в коробки, пока рынок ещё не договорился о нормальной архитектуре.
Мы запускаем Unica AI не потому, что рынку не хватает ещё одного AI-продукта. Их уже хватает. Мы запускаем её потому, что вижу тот же момент, который когда-то увидел в мониторинге: систем много, сигналов много, людей много, а слоя управления не хватает.
Моделей будет много. Агентов будет много. Ассистентов будет много. Встроенных копилотов будет много. И если не появится общий управляемый контур, компании получат не искусственный интеллект, а искусственный хаос.
Я хочу, чтобы у корпоративного ИИ появился нормальный операционный слой: с ролями, источниками, лимитами, аудитом, открытым ядром, закрытым контуром и уважением к человеку, который остаётся ответственным за результат.
Monq для меня был историей про управление сложной ИТ-инфраструктурой.
Unica AI — попытка сделать следующий слой: управление цифровым трудом. Детали архитектуры и open-source редакции я разберу отдельно, если будет интерес в комментариях.
Буду рад инженерной критике: где, по-вашему, заканчивается «мы собрали полезного ассистента» и начинается «мы строим корпоративную AI-платформу»?