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

В «Первой Форме» ИИ-агент помогает в контуре разработки: работает с кодом, инструментами и ревью. Состав моделей в этом контуре мы регулярно пересматриваем. За последние недели мы обновили Muse Spark с версии 1.2 до 1.3, добавили Gemini 3.8 Flash и подготовили для него быстрый откат на предыдущую модель. Расскажем, как устроен этот процесс.

Представьте обычную рабочую ситуацию. В задаче на согласование нужно быстро понять, прошла ли конкретная оплата. Не «какой объём оплат был в этом месяце», а именно: поступили ли деньги по этому счёту, на какую сумму, когда это отражено в 1С и нет ли расхождения с тем, что указано в процессе.

На дашборде такого ответа может не быть. Он показывает заранее выбранные метрики, а новый виджет ради одной проверки никто не станет проектировать, согласовывать и поддерживать. Можно открыть 1С, найти документ, сверить реквизиты, потом вернуться в рабочее место. Если вопрос возникает редко, этот путь кажется терпимым — пока таких редких вопросов не становится много.

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

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

Компании всё чаще пересматривают расходы на ИИ-инструменты. Например, Uber в 2026 году ввела лимит в $1 500 в месяц на сотрудника для каждого агентного инструмента кодинга: по данным Bloomberg, годовой бюджет на ИИ был израсходован за четыре месяца.

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

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

ИИ-агент может за минуты подготовить изменение, на которое у разработчика прежде уходил час. Но ускорение написания кода создаёт другую проблему: растёт нагрузка на проверку. Нужно изучить diff, понять предположения агента, проверить затронутые компоненты и убедиться, что решение соответствует задаче, а не просто проходит формальные проверки.

Почему агент выбрал этот модуль? Какие связанные части системы изучил? Какие варианты отбросил? На какие требования и результаты проверок опирался? Если этот контекст остаётся в закрытой сессии, следующему участнику процесса приходится собирать его заново.

В 2026 году эту проблему сформулировал Томас Домке, бывший CEO GitHub и основатель Entire. Она звучит так: «Узкое место при выпуске кода — это ревью кода, созданного агентами». Мы в «Первой Форме» к похожему выводу пришли через собственную практику. У нас ИИ-агенты работают внутри управляемого конвейера: задача получает проверяемые критерии, агенты действуют по ролям, результаты фиксируются в артефактах, а человек сохраняет за собой продуктовые решения, финальное ревью и мёрж. Расскажем подробнее.

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

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

Полтора года назад мы запустили AI-ассистента внутри «Первой Формы», чтобы он помогал сотрудникам компании выполнять рабочие процессы. Сегодня он отвечает на вопросы по регламентам, ищет документы, подсказывает по задачам, даже запускает проверку контрагентов и формирует КП. Всё это работает через большую языковую модель, а точнее — через набор моделей, потому что разные задачи требуют разного подхода: для быстрой классификации входящего запроса нужна одна, для развёрнутой генерации ответа — другая, для работы с длинным контекстом — третья. 

Модели живут в облаке, и это даёт свободу выбора. Инструменты, которыми агент пользуется, тоже ходят в интернет: поиск по документации обращается к облачным моделям векторизации текста, проверка контрагентов — к внешним сервисам вроде Контур.Фокуса и так далее. Агент обновляется из GitLab, CI/CD развозит изменения по стендам автоматически, мониторинг стекается в один дашборд. Нас это устраивало.

Недавно заказчик из промышленного сектора обратился к нам с задачей: «У нас закрытый контур, интернета нет и доступа к облачным API — тоже. Единственное, что у нас есть — это сервер с локальной моделью и наша внутренняя инфраструктура. Хотим такого же ассистента, как у вас». В статье рассказываем, как мы с этим справились. Спойлер: не без приключений.

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

Когда мы начали встраивать AI-агента в BPM-платформу, перед нами встала знакомая enterprise-задача: десятки клиентов, у каждого своя онтология, словарь, роли и ограничения безопасности. В одной компании «заявка на покупку» — это «реестр заявок», в другой — «карточкой закупки». Один клиент работает на изолированном контуре с локальной моделью, другой не даёт ассистенту доступ к почте и репозиториям. 

Традиционный ответ — форк репозитория под каждого клиента — при масштабировании превращается в ад поддержки: багфиксы не попадают автоматически, стоимость растёт экспоненциально, качество падает. Мы решили эту проблему иначе: per-tenant overlay позволяет кастомизировать поведение агента без изменения кода.

Вы знаете, сколько стоит сервер. У вас есть договор с хостинг-провайдером, инвойс от вендора, строка в ИТ-бюджете. А вот сколько стоят процесс согласования договора с клиентом, сопровождение в месяц, один цикл согласования заявки на закупку и другие процессы — сходу ответить сложно.

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

Проблема не в том, что никто не пытался посчитать, а в том, что получившаяся цифра не имеет отношения к реальности. McKinsey в исследовании Global Survey on AI фиксирует типичную ситуацию: около 60% организаций не видят EBIT-импакта от AI-проектов не потому, что технология не работает, а потому что никто не договорился, как именно измерять результат. Нет так называемого evidence pack — пакета подтверждённых данных, на который можно опереться при принятии решений. Без него пилот выглядит успешным на демо, но при масштабировании выясняется, что атрибуция была некорректной, а стоимость посчитана по-разному на разных этапах.

Это касается не только AI. Любой проект автоматизации страдает от той же проблемы: вы запускаете систему, тратите бюджет, получаете отчёт о выполнении — и не можете сказать, сколько всё это стоило в пересчёте на единицу работы, сравнить два процесса по стоимости владения или оценить, окупилась ли автоматизация. Вы управляете процессом, но не знаете его реальную цену.

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

Мы в «Первой Форме» развиваем BPM-систему на базе low-code для автоматизации бизнес-процессов: документооборота, CRM, HR, PM и Service Desk. Мы работаем с B2B-клиентами, у которых платформа живет внутри реальных процессов компании: согласований, заявок, договоров, кадровых маршрутов, сервисных сценариев и внутренних регламентов. В такой модели у нас постоянно появляется поток запросов на доработку системы.

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

Чтобы подготовить КП по сложному инженерному проекту, одного менеджера недостаточно. Нужно собрать расчёты от нескольких специалистов, а после согласования решения проверить наличие сотен позиций на складе и докупить недостающее. Когда это ведут в разных системах, растёт доля ручных операций и риск ошибок. Рассказываем, как собрали единый цифровой контур для управления сложными продажами и закупками в on-prem BPMS на Linux и PostgreSQL.

В последние два года разговор об AI-агентах почти везде начинается одинаково. Берётся большая языковая модель, к ней подключаются инструменты — поиск, CRM, почта, база знаний, API — и дальше предполагается, что модель сможет сама выбрать нужный инструмент, вызвать его и на этом решить задачу.

На демо это часто выглядит убедительно. Пользователь задаёт вопрос, модель делает один-два вызова, получает данные и формирует ответ. Кажется, что этого уже достаточно, чтобы говорить об agentic-сценариях. Но как только AI попадает не в лабораторную среду, а в реальный корпоративный контур, довольно быстро выясняется, что одного вызова инструмента по MCP недостаточно.

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

Иными словами, между «модель умеет вызвать инструмент» и «получился надёжный корпоративный агент» лежит отдельный инженерный слой. 

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, почему tool calling сам по себе не делает ИИ корпоративным агентом, как эту проблему решает наш подход Agent Loop и как этот цикл устроен в реальной enterprise-среде.

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

В этой статье расскажем, как мы в «Первой Форме» реализовали это с помощью Python. Мы встроили его в контур платформы так, чтобы получить его сильные стороны для AI- и ресурсоёмких сценариев обработки данных, но не исполнять произвольный Python-код внутри бэкенда. Для нас это была не задача в духе «поддержать ещё один язык», мы хотели расширить платформу, не размывая границы безопасности и устойчивости ядра. 

Когда в компании говорят о модели подразделения, обычно имеют в виду что-то вполне привычное: положение об отделе, регламент, SLA, список ролей и зон ответственности. Формально этого достаточно: подразделение описано, обязанности зафиксированы, сроки обозначены.

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

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

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

Меня зовут Денис Селезнёв, я генеральный директор компании «Первая Форма». Мы занимаемся автоматизацией бизнес-процессов уже более 20 лет. В последнее время мы активно развиваем новый подход к оцифровке бизнесов — Организация как код, о нём я рассказывал вот в этой статье. В рамках OaC мы решили взять живую конфигурацию, извлечь из неё формальную модель подразделения и сравнить её с тем, что написано в регламенте. Эта статья — о том, что получилось.

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

Но как только возникает практический вопрос — что именно это подразделение обязано делать, по каким правилам, с каким SLA, где проходят границы его ответственности и как проверить исполнение, — оказывается, что в явном виде ответа нет.

Знания хранится в регламентах, в BPM-системе, в локальных договорённостях, в головах сотрудников. Пока команда стабильна, это ещё может работать. Но при росте нагрузки, смене руководителя, цифровизации или попытке встроить в контур AI всё начинает рассыпаться. Новый руководитель читает документы, которые не совпадают с реальностью. Аналитик восстанавливает процесс по кускам. Автоматизация покрывает отдельные сценарии, но не даёт целостной модели того, что именно подразделение обязано гарантировать организации.

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, почему привычное описание подразделений перестало работать как управленческий инструмент, как мы подошли к этому через концепцию Организация как Код (OaC) и почему начали описывать подразделения не как функции на оргсхеме, а как исполняемые сервисные контракты. 

В прошлой статье я рассказывал, как мы в «Первой Форме» пришли к навигации по корпоративным данным и почему одной языковой модели недостаточно, чтобы получать полезные ответы внутри компании. Тогда речь шла о самой идее картографирования данных — о слое, который связывает разрозненные системы, знает смысл терминов и помогает находить путь от вопроса к проверяемому ответу.

Но довольно быстро выяснилось, что построить карту один раз недостаточно.

Компания меняется постоянно. Меняются процессы, документы, код, настройки, роли, рабочие привычки. То, что ещё недавно было правильным маршрутом к ответу, через некоторое время начинает вести только к части ответа или вовсе в неправильную сторону. Это уже опасно: если у компании нет карты, она честно признаёт, что ответа быстро не получить, но если карта устарела, она начинает отвечать уверенно — и именно поэтому ей легче поверить.

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы». В этой статье я расскажу, как работать с картой дальше, чтобы она не превращалась в красивый, но мёртвый артефакт. 

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

По данным Gartner, не менее 30% проектов в области генеративного ИИ будут заброшены сразу после проверки концепта к концу 2025 года. IBM фиксирует, что только 25% ИИ-инициатив дали ожидаемый возврат инвестиций. McKinsey сообщает: лишь треть компаний масштабируют ИИ-программы на уровне всей организации, и большинство из тех, кто видит эффект, оценивают его как «менее 5% операционной прибыли (EBIT)». Это не приговор технологии — это диагноз подходу: ИИ внедряют ради самого ИИ, не ответив заранее на вопрос, какой конкретный эффект он должен принести.

Мы в «Первой Форме» шли иначе: внедряли ИИ точечно, под конкретные задачи, каждый раз отвечая на вопрос о том, какой измеримый результат хотим получить. Постепенно этот подход привёл нас к следующему шагу: мы создали в нашей BPM-платформе семантический слой — набор маршрутов, словарь терминов и правила резолвинга сущностей. Он связывает разрозненные системы и позволяет с помощью ИИ получать ответы на управленческие вопросы, опираясь на реальные данные.

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы» — российской BPM-платформы для автоматизации бизнес-процессов в крупных компаниях. В этой статье я расскажу, как мы пришли к построению Картографа, как он устроен и что показала первая неделя его работы.

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