Искусственный Интеллект (дайджест): всё об ИИ и нейросетях 

Хотим порекомендовать канал наших коллег — Искусственный Интеллект (дайджест). В канале собрано самое важное про ИИ: от исследований крупнейших технологических компаний до прикладных инструментов для продаж, дизайна и контента. 

Основные направления:

◻️ Аналитика и законопроекты: разбор регулирования западных ИИ-сервисов, переход на отечественные нейросети и изменения на рынке технологий.

◻️ Практические гайды и промпты: инструкции для генерации портретов, техники объединения разных нейросетей, приёмы для создания эстетичных изображений и анимации.

◻️ Обзоры релизов и кейсов: запуски новых версий моделей с улучшенным качеством, истории применения ИИ в медицине и других сферах.

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

Будьте в курсе главного об ИИ — присоединяйтесь к каналу Искусственный Интеллект (дайджест) и повышайте уровень экспертизы в работе с нейросетями.

Госсектор и бизнес: как выстраивать эффективную коммуникацию

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

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

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

Особенности взаимодействия:
🔷 Все договоренности и изменения фиксируются письменно через официальные каналы или СЭД, любое принятое решение должно остаться в протоколе;
🔷 В госпроектах согласование любых изменений проходит длительный путь до центра принятия решений;
🔷 Отклонения от сроков реализации крайне нежелательны и влекут за собой санкции, должны иметь веские основания и обосновываться документально;
🔷 Часто в проекте участвуют две стороны: функциональный заказчик (кому нужна система) и технический (кто отвечает за архитектуру и стандарты). Умение найти компромисс в этой ситуации — ключевой навык команды.

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

Особенности взаимодействия:
🔷 Ключевые решения могут приниматься быстрее, так как центр принятия решений со стороны заказчика находится ближе;
🔷 Корректировка сроков или состава работ проходит более гибко в сравнении с госсектором, но и здесь существуют необходимые формальные процедуры;
🔷 В отличие от госсектора, где задача чаще всего очерчена рамками ТЗ, коммерческий заказчик не всегда приходит с конкретными требованиями к системе. Здесь важна роль вендора при выявлении потребности в решении и поиске технологического решения;
🔷 коммуникация проходит менее формально, однако официальные письма и работа с документацией по-прежнему присутствует.

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

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

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

Как DevOps-команда адаптирует решения под инфраструктуру заказчика

В реальных проектах набор инструментов, с которым работают DevOps-инженеры не всегда доступны из-за ограничений со стороны заказчика, а также со стороны регуляторов. Он определяет допустимые технологии, выдвигает требования или настаивает на развертывании на своих серверах с особыми условиями. За каждым таким ограничением стоят объективные причины: политика безопасности, регуляторные нормы или внутренние стандарты.

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

📍 Почему возникают ограничения?
У заказчика могут быть свои требования к инфраструктуре и инструментам:
🔷 утвержденный список разрешенного ПО;
🔷 собственные системы контроля и управления;
🔷 закрытая инфраструктура, в которой данные хранятся только на серверах заказчика;
🔷 ограничение доступа к публичным репозиториям и хранилищам артефактов.

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

📍 Как подстроиться под инфраструктуру заказчика?
Процесс адаптации начинается с этапа оценки, когда допустимые инструменты и подходы определяются заблаговременно. Можно выделить несколько ключевых подходов:

🔷 Замена инструментов. Если нельзя использовать привычные решения, разворачивается то, что разрешено. В случае, когда у заказчика своя система — пайплайны пишутся под неё.
🔷 Настройка безопасности. Усиливается сканирование образов, добавляются дополнительные проверки, если этого требует заказчик.
🔷 Адаптация процессов. Меняется подход к доставке кода в том случае, если заказчик требует ручных согласований или не позволяет автоматизировать часть этапов.

📍 Развертывание в инфраструктуре заказчика
В ряде проектов заказчик отказывается от использования облачных решений и требует развернуть систему на собственных серверах в своем центре обработки данных. В такой ситуации DevOps-инженеры:

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

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

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

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

Подборка полезных и интересных материалов 

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

Статьи: 
📎 «Ведомости» сравнили подходы к регулированию ИИ в России и Казахстане и разобрали, чем отличаются стратегии двух стран. 
📎 «РБК Тренды» с экспертами «ОБИТ»: почему поэтапная реализация ИТ-проектов снижает затраты на 15-20%. 
📎 Статья «Коммерсантъ», в которой исследователь AIRI рассказывает о памяти ИИ: модели не умеют переводить кратковременную память в долговременную, что мешает им непрерывно обучаться.

Заметки в блогах: 
✍️ Заметка на Habr о том, как синтетические данные помогают обучать ИИ, и где начинается граница между эффективным обучением и деградацией модели. 
✍️ Материал на vc.ru об исследовании Apple: почему LLM подбирают паттерны, а не мыслят логически.

Книги:
📚 «Совместный интеллект. Жизнь и работа с ИИ», Итан Моллик — книга о том, как эффективно взаимодействовать с нейросетями в работе и жизни. 
📚 «Глубокое обучение», Гудфеллоу, Бенджио, Курвилль — всё о машинном обучении: от математических основ до реализации сверточных сетей.

Подкасты:
🎤  Подкаст ГНИВЦ: применение искусственного интеллекта в государственном секторе, включая повседневные задачи и корпоративные экспериментальные среды.
🎤 Подкаст Алексея Голубева: сооснователь amoCRM рассуждает об изменениях, которые ИИ приносит в карьеру и бизнес.

Как мы строим процессы: взгляд на разработку от команды Embedika

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

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

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

Аутсорсинговые компании привлекательны относительно низким порогом входа. Бизнес таких компаний строится на предоставлении ресурсов клиентам, поэтому они почти постоянно находятся в поиске специалистов и часто готовы обучать их под стек конкретного проекта. Финансовая модель здесь прозрачна: уровень заработка напрямую связан с количеством затраченного времени и числом проектов, которые специалист ведет параллельно. При этом у такого формата есть свои ограничения: работа ведется строго по техническому заданию, а консалтинг либо не предоставляется, либо выносится в отдельную услугу. Из-за готовности браться за проекты с разнообразной спецификой, у таких компаний редко накапливается глубокая отраслевая экспертиза.

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

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

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

В следующих материалах покажем, как эти принципы реализуются в конкретных инструментах и практиках фронтенд-команды Embedika.

Влияние фронтенд-разработчиков на проект: от постановки задачи до интерфейсных решений

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

Фронтенд-разработчики подключаются к проекту сразу на старте разработки: создают основу приложения и приступают к реализации первых пользовательских сценариев. Ведущий специалист включается в работу еще раньше. Он помогает оценить объем задач и времязатраты по ключевым требованиям. Вместе с тем опытные разработчики могут привлекаться еще до старта проекта для консультаций по выбору технологий и реализуемости функционала.

Какие задачи поступают фронтенд-команде, кто их ставит и где проходит граница ответственности разработчика — разбираемся ниже.

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

1️⃣ Бизнес-постановки: это полноценные пользовательские сценарии, которые человек видит в интерфейсе и с которыми взаимодействует. Постановщиками здесь выступают бизнес- и системные аналитики. На вход команда получает макеты и описание логики с точки зрения пользователя: основной сценарий и краевые случаи. Задача фронтенд-разработчика — превратить это описание в работающий и понятный интерфейс.

2️⃣ Баги и доработки: несоответствия изначальной бизнес-постановке, которые обнаруживаются на этапе тестирования или уже в ходе эксплуатации системы. Такие задачи может заводить любой член команды, но чаще всего этим занимаются тестировщики. Формат постановки обычно включает скриншоты или видеозаписи проблемы и описание ожидаемого поведения системы.

3️⃣ Технические задачи: инициаторами здесь выступают сами разработчики — как фронтенд, так и бэкенд. Макеты в таких задачах отсутствуют, а изменения касаются внутреннего устройства проекта: рефакторинг кода, улучшение инфраструктуры, корректировка взаимодействия с API и другие улучшения, которые напрямую не влияют на интерфейс, но делают систему более устойчивой и повышают удобство работы с ней для самой команды.

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

Такое распределение задач и зон ответственности позволяет фронтенд-команде осмысленно влиять на проект на всех этапах его создания — от проработки пользовательских сценариев до обеспечения стабильности и удобства итогового решения.

Первый квартал 2026-го: регулирование, агенты и оценка реальных результатов от инвестиций в ИИ

Проанализировали и собрали для «РБК Трендов» ключевые события первых трех месяцев этого года.

🔗 Полная версия доступна на сайте РБК Тренды

Как фронтенд влияет на проект и как выстроены процессы в команде Embedika

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

Процесс работы фронтенд-разработчика над задачей состоит из нескольких этапов:

1️⃣ Обсуждение и оценка задачи. Проходит в формате созвона с участием тимлида, аналитиков, фронтендеров и тестировщиков. Цель — выявить непонятные моменты в постановке и оценить время на реализацию и тестирование.

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

3️⃣ Код-ревью. Обязательный этап перед попаданием кода в общее хранилище. Один-два фронтендера проверяют корректность решения, отмечают возможные проблемы и следят за соблюдением принятых в команде правил оформления кода.

4️⃣ Передача в тестирование. Если тестировщики выявляют проблемы, задача возвращается на доработку. Если замечаний нет — переходит в статус готовности к релизу.

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

Agent ready — новый стандарт или необходимость для онлайн-торговли?

Коллеги из канала Будни Digital CTO подготовили подробный разбор того, как ИИ-агенты меняют ритейл и почему привычные витрины перестают работать.

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

В 2026 году ИИ платформы продолжают становиться полноценным каналом продаж, а не просто поиском с чатом. EMarketer прогнозирует, что только в США объем ecom продаж через ИИ платформы превысит 20 млрд долларов в 2026 и вырастет до 144 млрд к 2029 году. В прошлом году индустрия начала договариваться об общем языке для агентов: появляются открытые протоколы вроде Universal Commerce Protocol и Agentic Commerce Protocol, которые стандартизируют, как агенту посмотреть каталог, собрать корзину, посчитать налоги, оформить оплату и отследить доставку.

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

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

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

Чтобы не отстать в этой новой гонке стоит посмотреть на свой сайт и ответить на вопросы:
▪️ Можем ли мы описать наш каталог, стоки, цены и доставку в виде чистых, стабильных API, понятных любому внешнему агенту?
▪️ Можем ли мы отдавать бизнес правила (скидки, промо, ограничения по регионам) в четком и понятном виде?
▪️ Есть ли в дорожной карте отдельный пункт — быть agent ready?
▪️ Готова ли команда жить в мире, где JSON становится главным интерфейсом к вашему магазину?

Больше интересных новостей об ИИ, рителе, екоме и маркетплейсах 👉 Подписаться на канал

Принципы построения интерфейсов и негативные практики фронтенд-разработки

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

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

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

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

🔹 Общепринятые пользовательские паттерны
Интерфейс, который игнорирует привычные пользователю сценарии, перестает быть интуитивным. Классический пример — удаление данных без подтверждения. Хорошей практикой считается запрос подтверждения или возможность отмены действия в течение короткого времени. Следование устоявшимся паттернам делает систему предсказуемой и снижает тревожность пользователя.

🔹 Оптимизация работы с сервером
Если в рамках одного раздела уходит несколько одинаковых запросов, а при старте приложения загружаются все модули разом, это приводит к задержкам отрисовки и лишней нагрузке на сервер. Грамотное решение — ленивая загрузка модулей, которые не нужны пользователю сразу, и минимизация дублирующихся запросов.

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

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

Как фронтенд-разработчик взаимодействует с командой и участвует в создании интерфейса

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

Взаимодействие с аналитиками и тестировщиками

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

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

Работа с дизайнерами и влияние на финальный интерфейс

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

Как происходит передача результатов работы

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

Если замечаний нет — задача переходит в статус «Готово» и ожидает выпуска релиза для передачи конечному заказчику. Если проблемы обнаружены — задача возвращается на доработку и проходит весь цикл заново.

Дайджест событий в области искусственного интеллекта

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

В России:
☁️ Сбербанк создаст группу компаний «Сбер2В»: под новым брендом объединят нефинансовые ИТ-продукты, включая облачные и ИИ-решения для корпоративных клиентов.
📊 Правительство РФ установило для ведомств KPI по внедрению ИИ, теперь у госорганов есть конкретные нормативы, стимулирующие использование нейросетей в работе.
🧠 «Сбер» и НИУ ВШЭ представили метрику Persistence: новая технология позволяет оценивать качество эмбеддингов без участия человека и предразмеченных датасетов, помогая точнее выбирать архитектуру модели и момент остановки обучения.
🚀 «Ростелеком» запустил акселератор ИИ-решений: программа нацелена на поиск и поддержку перспективных российских стартапов.

В мире:
💬 OpenAI анонсировала Workspace Agents в ChatGPT: функция позволяет командам создавать общих ИИ-агентов для совместной работы прямо в интерфейсе чата.
🦾 Siemens представил Eigen Engineering Agent — специализированного ИИ-агента для решения задач промышленной автоматизации.
📋 DeepSeek регистрирует товарный знак в России: китайский вендор планирует официально продавать ПО и предоставлять услуги анализа данных на российском рынке.
📓 Google добавила в Gemini инструмент Notebooks, он позволяет формировать и структурировать базу знаний на основе истории взаимодействий с моделью.

Аналитика:
📈 Servicepipe фиксирует троекратный рост спроса на ИИ-агентов. По итогам первого квартала 2026 года обращения бизнеса на услуги настройки агентов выросли в 3 раза.
💰 HeadHunter и ГК «Солар» выяснили, что использование больших языковых моделей в закрытом контуре сокращает годовой ФОТ команд AppSec на 20–50% в зависимости от масштаба разработки.

#дайджест