AI-платформа для закрытого контура: агенты, данные, LLM — в одном стеке

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

Для быстрой сборки агентов в закрытом контуре мы разработали решение — AI Platform. Это три платформы в одном стеке, которые работают самостоятельно и предоставляют API соседним слоям.

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

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

LLM-платформа. Единый OpenAI-совместимый шлюз для on-premise моделей, российских облаков и внешних SOTA. Входит в реестр российского ПО и соответствует 152-ФЗ. Есть учёт расходов в реальном времени, разделение GPU-ресурсов между несколькими LLM на одной карте, наблюдаемость и аудит требований безопасности.

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

Подробнее о том, как работает платформа, рассказали на сайте

Корпоративное ПО в эпоху AI

8 месяцев назад мы с коллегами обсуждали выбор ПО для автоматизации части внутренних процессов. Были в классической ситуации, которую помогаем решать нашим клиентам: каждый отдел использует свои инструменты разного уровня автоматизации, от экселек с аппскриптами до специализированного ПО под конкретные задачи. Типичная «лоскутная автоматизация». Мастер-данные при этом не хранятся в единой системе: сотрудники в 1С, клиенты в CRM, финансы в агрегаторе, отчетность в таблицах, ДО и КЭДО в отдельных сервисах, управление проектами в трекере. Все это помазано сверху самописными сервисами, которые перекладывают данные между системами.

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

Тем временем вышел opus4.5, я смог достаточно качественно «кодить» в перерывах между звонками по 5-10 минут. Моя самописная система разрасталась и уже покрывала несколько важных процессов. Затем прошел этап внедрения. Часть администраторов проектов стали работать в моей системе. Постепенно к созданию системы подключились и другие разработчики. За несколько месяцев довели продукт до продакшн-уровня, заместили часть текущих систем, выработали подходы к работе и документации для еще более быстрой разработки. Даже дали менеджерам делать простые инструменты (не затрагивающие кор-функционал) под себя самостоятельно через согласование спецификаций.

Это дало кратный буст и уже значительно сказалось на бизнесе: от прямой экономии ФОТ (проще всего посчитать в экономике) до онлайн-мониторинга показателей и сокращения времени принятия управленческих решений. Всего за несколько месяцев я увидел, как капитализировалась большая часть нашего опыта, данных, процессов, живущая до этого в головах, документах и разрозненных системах.

Более того, благодаря подключению «нетехнарей» получилось сократить цикл создания ценности в продукте: бизнес-пользователи лучше всего знают свои процессы и теперь они могут не рассказывать аналитикам, а что же нужно сделать, чтобы те написали ТЗ, передали в разработку и т.д. Теперь они сами часто пишут ТЗ, согласуют его и реализуют нужный им функционал. (Для скептиков: не пугайтесь, есть гардрейлы и централизованная архитектура, а эффект от распараллеливания кратно превосходит риски).

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

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

#сергей_чернобровкин

Как запускать AI-агентов в закрытом контуре за пару часов

Мы уже рассказывали об AI Platform — это три связанные платформы в одном стеке. Сегодня подробнее разберём верхний слой — агентскую платформу, которая кратно ускоряет запуск AI-решений.

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

Агентская платформа сокращает этот цикл до нескольких часов. Что внутри:

▪️ шаблоны под основные классы задач, деплой по коммиту через GitLab CI
▪️ поддержка полноценных агентских сценариев: human in the loop, остановка и возобновление работы агента, ретраи при сбоях инфраструктуры
▪️ мультиагентное взаимодействие, оркестрация каскадов и подключение оператора для подтверждения
▪️ трассировка всей цепочки: промпты, инструменты, стоимость, латентность по каждому шагу
▪️ регрессионные прогоны и сравнение метрик между промптами и моделями перед релизом

«Кроме базового инфраструктурного слоя, сейчас тестируем новый SDLC разработки: агенты разрабатываются кодинг-агентом, а платформа визуализирует потоки данных. Так мы реализуем возможность создавать агентов нетехническими специалистами, как это предполагает no-code-подход. При этом сохраняются все преимущества и надежность классической разработки», — Александр Опрышко, управляющий партнёр KTS

Оцените, как AI Platform работает на ваших данных. Запишитесь на демо, сравните качество и стоимость, чтобы принять решение о пилоте

Спецификации на пути к автономной разработке

В прошлых постах рассуждал про инженеров будущего и про автономный цикл создания ПО.

Мы работаем над инструментами для такого AI SDLC (как сейчас модно говорить), и масштаб компании даёт как преимущества, так и создаёт проблемы. С одной стороны, мы видим очень много разных проектов. Это даёт возможность проанализировать их и найти общие паттерны, выработать общие подходы к разработке, стараться автоматизировать их. С другой стороны, внутренние инструменты, которые мы создаём, должны отвечать требованиям очень разных команд. Нет возможности срезать углы и закастомить под конкретную команду — всегда должно быть общее решение.

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

Это значит, что первая задача на пути к автономному созданию ПО — максимально «сблизить» данные, которыми оперируют разные специалисты и агенты. И в первую очередь все собирают бизнес-требования. Spec driven development уже давно звучит из каждого утюга. Но проблема в том, что конечный стейкхолдер выдаёт требования обычно обрывочно и неструктурированно. Их нужно собирать с заказчика, анализировать и на основе этих данных синтезировать спецификацию. А потом согласовывать. И обычно этот процесс ведется в удобных инструментах типа гугл-доков или конфлюенсов, где можно оставить комментарии, предложить изменения и т.д.

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

В целом, работать через mcp с теми же гугл-доками можно. И мы так и делали в первых итерациях. Проблема в том, что «мостиком» между агентом и документацией тогда является человек, который работает с ними. Он должен указать документ, изменить его (например, автоматически обработать комментарии заказчика), а через MCP часто бывает неудобно (перетирается весь док, нельзя включить режим предложений). А обновить документацию уже потом в процессе разработки — отдельный шаг, который точно кто-нибудь забудет. Мы даже разработали плагин к гугл-докам, который умеет обрабатывать комментарии и вносить правки в режиме предложений. Но этого все ещё недостаточно, потому что кодинговый агент, живущий в репозитории, лучше всего работает с артефактами из этого репозитория.

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

Поэтому нам пришлось разработать сервис для просмотра и согласования документации, которая лежит в репозитории. Сервис позволяет комментировать (через комменты к мерж-реквестам) и редактировать (через коммиты) документы прямо онлайн, полностью имитируя процесс гугл-доков. Теперь большинство аналитиков согласуют с заказчиками документацию в нашем сервисе и она автоматически попадает в репозиторий, где её же использует агент. А комменты от заказчиков можно обрабатывать автоматически. Затем разработчики используют документацию уже для программирования и в процессе разработки могут автоматически (агентом) проапдейтить документацию, если было изменение в процессе реализации.

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

Вуаля, и вот мы сделали маленький, но важный шажок на пути к автономному AI SDLC.

#сергей_чернобровкин

🏆 Ворвались в Рейтинг Рунета 2026

В этом году KTS впервые участвовал в AI-направлении Рейтинга Рунета 2026 — и сразу попал в топ-20, заняв 12 место в номинации «Разработка и внедрение искусственного интеллекта».

Участников рейтинга оценивали по проектам, услугам, отраслевой экспертизе и достижениям за 2025–2026 годы.
Попадание в топ-20 — подтверждение, что наш опыт в AI уже заметен на рынке.

Для нас это важный результат: AI-направление в KTS быстро растёт, а проекты становятся все более прикладными — от внедрения LLM и RAG до AI-агентов и внутренних инструментов для бизнеса.

Благодарим ключевых партнеров: Альфа-Банк, Гигачат, Столото и других лидеров рынка за доверие!

Работаем дальше: усиливаем экспертизу, развиваем AI-решения и двигаемся выше.

👀 Новые модели в Agent Platform

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

Новые модели Anthropic:
— anthropic/claude-fable-5 нашумевшая fable-5
— anthropic/claude-sonnet-5 для задач, где важны качество ответа, работа с контекстом и сложными инструкциями.

Новые опенсорсные модели, которые показывают хорошие результаты в кодировании, с хостингом в РФ у нашего партнера Cloud.ru:
— cloudru/MiniMaxAI/MiniMax-M3
— cloudru/zai-org/GLM-5.2

Новая модель для работы с изображениями:
— google/gemini-3.1-flash-lite-image

Заходите в Agent Platform протестировать

Безопасно ли запускать AI-агента на корпоративных данных?

Продолжаем разбирать AI Platform для закрытого контура. В прошлый раз рассказали, как агентская платформа ускоряет создание агентов в десятки раз. Сегодня поговорим о работе с базами знаний.

Корпоративные данные — один из основных барьеров внедрения AI в enterprise. Компании хотят их контролировать, поэтому требуют создавать контуры индексации на базе собственной инфраструктуры. Для этого нужны готовые решения по работе с структурированными (базами, таблицами) и неструктурированными данными (PDF-документами).

Платформа данных устраняет этот барьер. Мы встроили в неё 6 инструментов для разных типов запросов с проверкой на качество и безопасность данных:

▪️ Парсинг PDF с таблицами, схемами и сложными структурами, поддержка работы с DOCX, PPTX, XLS.
▪️ Классический RAG — гибридный поиск: BM25 + векторный. Подходит для быстрого семантического поиска по большим массивам информации.
▪️ Графовый RAG — поиск по многосвязанным данным, где важны связи между фактами, а не отдельные фрагменты.
▪️ Табличный доступ — SQL, API, CSV, DWH подключаются как инструменты через MCP.
▪️ Валидация данных — подсветка конфликтов и дублей в документах. Позволяет найти конфликты, устранить их и таким образом значительно снизить галлюцинации решений.
▪️ Сквозной RBAC — ролевая модель из корпоративной AD/Keycloak на каждом запросе. Агент видит только ту информацию, которая доступна конкретному пользователю.

Чувствительные данные не попадают в LLM и внешние контуры. Запрос проходит через маскировку и гардрейлы по правилам безопасности.

В наших проектах запуск AI-агентов на корпоративных данных даёт измеримый результат: поиск информации ускоряется на 50-80%, а обработка документов — на 70-90%. Как это работает, показали в кейсе с Альфа-Банком.

Монорепы на пути к AI SDLC

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

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

Классическая картинка выглядит так: есть репа с бекендом, есть с фронтендом, и еще несколько вспомогательных реп на какие-то смежные сервисы.

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

Это очевидная точка оптимизации на пути к AI SDLC. Если я могу (утрированно) сгенерить код фронта за час, но мне нужно ждать целый день, чтобы его передать следующему спецу, который сделает бек, а потом это все сливать в стейдж, чтобы отдельно интеграционно потестит, то я теряю уйму времени на передаче контекста и отслеживание статусов атомарных задачек и контроля их синхронизации. Никаким кратным ускорением не пахнет.

Соответственно, возможность, которую хочется использовать в AI SDLC — атомарной задачей должна стать сама фича, а не ее кусочки. А для этого мне нужно в одном месте собирать все артефакты: от бизнес-требований (см предыдущий пост) до автотестов. Это место — в идеале монорепа. Тогда я смогу одним коммитом вмержить целый блок функционала: и актуальные бизнес-требования, и техническую спецификацию, и реализацию, и автотесты.

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

Идеальный процесс тогда может выглядеть так:

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

– Опционально аналитик может даже сгенерировать прототип в реальном коде на основе своих же бизнес-требований и показать клиенту (автоматический деплой из фича-ветки, такая вот нативная интеграция наших услуг)

– Менеджер / тимлид в этой же ветке может загрумить задачки, поразгоняв с агентом. И сразу же завести их в трекере по mcp, если нужно. Автоматически приложив в задачу ссылку на документацию в нашем же сервисе.

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

– Ветка проходит ревью у тимлида целиком.

– Тестировщик тестит эту же ветку (снова нативная интеграция фича-стендов) в изолированном окружении и дописывает автотесты.

Фича стала набором связанных артефактов и они все одной транзакцией попали в основную ветку при мерже.

Я специально на каждом шаге в примере приводил разных специалистов, хотя уже видно, что следующие шаги на пути к AI SDLC — это скиллы, которые позволяют с должным уровнем качества делать эти шаги с помощью агентов. А потом какие-то шаги делать автономно. Про это буду писать в следующих постах по мере реализации на практике.

#сергей_чернобровкин

Как управлять LLM в закрытом контуре и не потерять контроль над безопасностью и бюджетом

Завершаем обзор AI Platform. Сегодня разберём фундамент всего стека — LLM-платформу.

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

LLM-платформа позволяет контролировать безопасность и бюджет на уровне инфраструктуры. Это единый OpenAI-совместимый шлюз, который входит в реестр российского ПО.

Встроенный ПДн-роутер распределяет запросы на основании содержимого и политик безопасности заказчика:

▪️ локальная инфраструктура — персональные и конфиденциальные данные, чувствительные задачи
▪️ в российские облака — YandexGPT, GigaChat, Cloud.ru — если важна юрисдикция и нужно масштабирование без собственных GPU
▪️ к мировым SOTA-моделям — OpenAI, Anthropic, Google, DeepSeek — только запросы без ПДн, где критично качество ответа

Функциональность платформы позволяет отслеживать токены, стоимость, латентность по каждому запросу и контролировать лимиты и расходы в реальном времени.

Локальные модели разворачивается по запросу из админки, поддерживается разделение GPU для эффективной утилизации ресурсов.

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

Проверьте, как AI Platform работает на ваших данных. Запишитесь на демо

ИИ вне разработки

В прошлых постах много писал про разработку. А что поменялось в процессах других команд?

Сегодня поговорим про эволюцию отдела продаж. За последние несколько месяцев попробовали много инструментов.

Начиналось всё, думаю, как и у всех, с того, что сейлзы начали использовать нейро-инструменты. Например, пробовали обсуждать с ChatGPT свои сделки.
Сами лиды при этом лежат в CRM, сметы считаются в таблицах, КП готовится в Фигме, а процесс выработки решения довольно сложный и состоит из встреч с партнёрами, клиентом, технической командой и т. д.

Когда сейлзы начали использовать ИИ-инструменты, это, как и в случае с разработкой, ускорило работу и сделало её местами более качественной за единицу времени. Но это всё ещё не кратное ускорение / улучшение.

Мы смогли продвинуться чуть дальше. Но сначала нужно понять классические проблемы отдела продаж (не только наших). Изучение кейсов и продуктов компании обычно занимает пару месяцев, адаптация сейлза к процессу сбора КП, синхронизация с командой — всё это приводит к продолжительному онбордингу, на который накладывается ещё и длинный цикл сделки. В итоге сейлз может начать что-то приносить через полгода. При этом капитализация отдела продаж в основном в:

▫️ контактах в CRM
▫️ отработанных лидах и кейсах (которые часто неструктурированы и разбросаны по системам)
▫️ всяческих шаблонах и готовых упаковках
▫️ опыте конкретных людей

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

— накопление знаний: чёткая структура, быстрый и простой доступ
— типовые кросс-командные решения

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

Но этого было недостаточно. Во-первых, оба инструмента находятся в нашей внутренней системе. Получается, сейлз работает в CRM, сидит в чатах и почте, звонит по телефону, готовит КП вместе с GPT и ещё кучу всего делает. И тут ему ещё одну вспомогательную систему дали. Мотивации туда заходить не так много. Новые инструменты добавляются централизованно, а значит долго, и не извлекают экспертизу и знания конкретного сейлза в общие практики. Артефакты подготовки конкретного КП всё также передаются в гугл-папках, CRM, чатах и т. д.

И тут становится понятно, что эти проблемы давно решены в разработке:

▫️ экспертиза, знания и правила — это скиллы для ИИ-агентов
▫️ общее хранилище данных — репозитории, где работают все инженеры (вместе с ИИ-агентами) в одном контексте
▫️ генерация артефактов с кодинговыми агентами работает лучше всяких чатов с GPT

Поэтому решение стало очевидным: сейлзы должны начать накапливать знания о своих пресейлах и генерить решения вместе с техническими командами так же, как это делают разработчики. Мы сделали один общий git-репозиторий для продаж. Он содержит: схему данных о клиентах и их заявках для накопления всех артефактов, MCP CRM, набор скиллов для работы с кодинговыми агентами.

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