Блог

Два AI-сервиса за две недели: чем они отличаются и почему оба ждут интеграции с 1С

Два реальных AI-проекта: персонализированные КП и закупочная номенклатура. Что можно сделать за две недели и почему полный MVP требует интеграции с 1С.

18.07.2026 · 6 min read

Владимир Филипьев · Генеральный директор f(AI) Studio

#AI-пилот##интеграция#средний бизнес

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

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

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

А текущий статус одинаковый: логика сервисов работает, JSON API согласован, ответы уже отлаживаются. Полный MVP в обоих проектах ждёт интеграции с 1С.

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

Проект №1. Сделать за 2–3 месяца то, что собирались делать год

У заказчика уже шёл внутренний проект создания идеального коммерческого предложения. Не очередного шаблона с заменой названия компании, а действительно персонализированного документа:

  • с учётом данных конкретного клиента;
  • с результатами бесплатного периода обслуживания — тест-драйва;
  • с аргументами, подходящими именно этой компании;
  • с логикой, которая превращает собранную информацию в осмысленное предложение.

Внутренний план проекта был рассчитан примерно на год.

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

Плановый горизонт проекта сократился до 2–3 месяцев.

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

Проект мы делаем на Yandex AI Studio. f(AI) Studio — официальный партнёр Yandex Cloud.

Первую неделю заняли согласование проекта в партнёрском контуре Yandex Cloud, настройка среды и развёртывание первого релиза.

Бюрократия немного удивила: около десяти человек со стороны Яндекса участвовали в согласовании в течение месяца — и в итоге один наконец стартовавший проект. AI обещает ускорить почти всё — кроме согласования AI-проекта.

За следующую неделю мы реализовали логику сервиса и согласованный API-контракт для интеграции с 1С. Сейчас проверяем ответы на синтетических данных и донастраиваем качество.

Проект №2. Клиент просил найти дубли. Но проблема оказалась не в дублях

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

Это понятная задача. Только сама по себе она почти ничего не говорит о том, зачем бизнесу AI.

Во время глубокого интервью появилась честная боль. Например, резистор закупили по 2,3 рубля, хотя подходящий аналог можно было купить по 1,8 рубля. Разница — полрубля на единице, или почти 28%. При многомиллиардном объёме закупок даже небольшая доля нерациональных решений превращается в заметные деньги.

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

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

И здесь возник парадокс: первый важный этап AI-проекта может вообще не требовать AI.

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

Первую неделю мы разворачивали среду на VPS, а затем тестовый контур на сервере заказчика. За вторую — реализовали сервисную логику и API.

Сейчас тестируем запросы через GUI-заглушку и настраиваем качество ответа.

Что в действительности готово за две недели

Мы не запустили два законченных бизнес-продукта за две недели. Мы сделали две сервисные части будущих MVP:

  • реализовали логику согласно техническому заданию;
  • согласовали JSON API-контракты;
  • получили рабочие ответы на тестовых сценариях;
  • начали настройку алгоритмов и качества.

Полным MVP мы считаем первый сквозной прогон:

действие пользователя в 1С → запрос в AI-сервис → обработка → ответ в 1С → результат в рабочем интерфейсе.

Для этого со стороны 1С нужны две вещи:

  1. Интеграция по согласованному JSON API.
  2. Доработка пользовательского интерфейса для вызова нужной функции и обработки результата.

Пока этого нет, мы можем доказать работоспособность сервисной логики, но не бизнес-функции целиком.

Почему мы не стали ждать

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

Поэтому мы разделили задачи:

  • всё, что зависит от итогового интерфейса и реальных данных, ждёт интеграции;
  • всё, что можно сделать без риска последующей переделки, запустили сразу;
  • границу между системами заранее закрепили в API-контракте.

Именно контракт позволяет двум командам двигаться параллельно. AI-сервис уже умеет принимать и возвращать согласованную структуру. 1С-команда может реализовать свою часть, не ожидая завершения настройки всех алгоритмов.

Для владельца бизнеса это, пожалуй, главный вывод всей истории: быстрый AI-пилот начинается не с выбора модели. Он начинается с правильного разделения работ и согласования границ систем.

Реактивный самолёт в серверной

У одного из заказчиков есть собственный сервер с GPU. По меркам нашего текущего проекта — реактивный самолёт.

Самое интересное, что самолёт почти не летает. Наш сервис загрузит лишь небольшую часть его ресурсов.

Поэтому мы предложили использовать инфраструктуру шире: построить AI-powered контур разработки вокруг одного или нескольких разработчиков 1С, а затем проверить подход и на других внутренних командах.

Не просто выдать программисту AI-помощника, а связать в управляемый процесс:

  • декомпозицию и оценку задач;
  • подготовку технических решений и чернового кода;
  • автоматизированное code review;
  • генерацию тестовых сценариев;
  • документацию, сборку и выпуск изменений;
  • накопление базы знаний по конфигурации и доработкам.

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

Что важно подготовить до старта AI-пилота или проекта внедрения

  1. Честную бизнес-боль. «Найти дубли» — задача. «Мы переплачиваем и не можем объяснить выбор поставщика» — бизнес-боль.
  2. Границу AI-функции. Что делает AI-сервис, как сохранить привычный интерфейс для пользователя (например, 1С) и какое решение принимает человек.
  3. API-контракт до завершения разработки. Какие данные приходят, что возвращается и как выглядит ошибка. Это даёт командам возможность работать параллельно.
  4. Сквозное определение MVP. Не красивый ответ модели, а законченный путь внутри рабочего интерфейса.
  5. Владельца интеграции и критерии результата. Кто замыкает процесс, кто принимает спорный ответ и что будем измерять после запуска.

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

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

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

Источники и disclosure

  • Yandex AI Studio.
  • Механизмы интеграции 1С.
  • Автоматизированное тестирование 1С.
  • Статус партнёра Yandex Cloud подтверждён письмом ООО «Яндекс.Облако» от 27.05.2026. Скан не публикуется, поскольку содержит договорные и юридические реквизиты.
  • Материал основан на двух текущих обезличенных проектах f(AI) Studio. Названия заказчиков и внутренние данные не раскрываются.
  • AI использовался для исследования, структурирования и редакционной подготовки; факты и выводы проверены автором.

Продолжение истории

Следующие материалы разберут оба проекта по отдельности — без агрессивной продажи и неподтверждённых результатов.

Следить за продолжением в Telegram