https://www.itweek.ru Издание itWeek (до 2018 года — PC Week) на портале и на страницах бумажного номера информирует читателей об актуальных информационных и коммуникационных технологиях, продуктах и решениях и опыте развития цифровой экономики и цифровой трансформации предприятий и организаций всех масштабов и отраслей. Издание рассказывает о важнейших событиях отечественного и мирового рынка ИКТ и анализирует тенденции развития ИКТ-индустрии. https://www.itweek.ru/images/itweek/logo-100x40.gif https://www.itweek.ru https://www.itweek.ru/themes/detail.php?ID=235328 Wed, 12 Aug 2026 09:29:19 +0300 <p>Недавно была опубликована спецификация Agent Plugins 1.0.0 — проекта открытого стандарта для упаковки навыков ИИ-агентов и конфигураций подключения к внешним системам. Сейчас документ имеет статус Working Draft: спецификация ещё находится в разработке и может меняться.</p> <p>Новость сразу привлекла внимание ИТ-сообщества. Это закономерно: проект развивается открыто, а в первоначальный состав технического управляющего комитета вошли представители Amazon, Cursor, Microsoft, OpenAI и Vercel. В число совместимых ИИ-инструментов уже вошли ChatGPT, Codex, Cursor, GitHub Copilot, Kiro и VS Code.</p> <p>Единый формат Agent Plugins 1.0 позволяет упаковывать инструкции, интеграции и накопленную экспертизу в повторно используемые компоненты. Если формат получит широкое распространение, компании смогут применять одни и те же компоненты в разных совместимых ИИ-инструментах, упрощая распространение решений и сокращая объём повторной работы.</p> <h2>От разрозненных интеграций к тиражируемым решениям на базе ИИ-агентов</h2> <p>Появление ИИ-агентов стало важным этапом в развитии автоматизации: они научились не только формировать ответы, но и выполнять последовательности действий. При этом их устройство пока неоднородно, поскольку технология находится на раннем этапе развития. Первые решения оставались изолированными, зависели от конкретных платформ и требовали отдельной настройки интеграций.</p> <p>Сначала модели подключали к отдельным функциям и API: один вызов получал данные, другой отправлял сообщение, третий создавал задачу. Такие интеграции работали, но обычно были тесно связаны с конкретным приложением, SDK и способом описания инструментов.</p> <p>Следующим шагом стал Model Context Protocol, или MCP. Он задал общий способ подключения ИИ-клиентов к данным, инструментам и внешним системам. Благодаря MCP ИИ-агент может не только сформировать ответ, но и получить информацию из корпоративной базы, обратиться к сервису или выполнить разрешённое действие. При этом сам протокол не описывает, как ИИ-агент должен вести весь рабочий процесс: какие проверки выполнить, в какой последовательности действовать и что считать приемлемым результатом.</p> <p>Эту часть рабочего сценария описывают Agent Skills. Навык хранит инструкции, справочные материалы, шаблоны и при необходимости скрипты. По сути, это переносимое описание того, как выполнять определённую работу. Но навык и MCP-сервер до сих пор нередко приходилось по-разному размещать и настраивать в разных клиентах для работы с ИИ-агентами.</p> <p>Agent Plugins 1.0 добавляет ещё один уровень — стандартную упаковку и обнаружение компонентов. В корне плагина находится манифест plugin.json, навыки размещаются в папке skills, а конфигурация MCP-серверов — в mcp.json. Стандарт не заменяет MCP и Agent Skills и не добавляет агентам новых возможностей. Он объединяет существующие компоненты в общий переносимый пакет, который совместимый клиент может проверить, обнаружить и загрузить.</p> <p>Для бизнеса это означает возможность тиражирования: один раз собранный для конкретного рабочего сценария плагин не нужно заново упаковывать под каждый совместимый ИИ-инструмент. Его можно передавать другим пользователям и подключать в разных рабочих средах. Инструкции и базовая структура интеграций при этом сохраняются, однако доступы, установка и функции конкретного инструмента требуют отдельной проверки.</p> <h2>От личного ИИ-помощника до сложного корпоративного процесса</h2> <p>Agent Plugins 1.0 не ограничен определённым типом задач. В формате плагина можно упаковать как простой сценарий, связанный с одним сервисом, так и многоэтапный процесс, в котором ИИ-агент обращается к нескольким корпоративным системам. Сам стандарт не содержит готовых бизнес-сценариев, но включает примеры и подробное описание компонентов, из которых можно собрать плагин.</p> <h3>Простой сценарий: организация встречи</h3> <p>Пользователь просит ИИ-агента подобрать время для встречи с несколькими коллегами на следующей неделе. В навыке можно зафиксировать правила и порядок действий: продолжительность встречи, допустимое время, обязательных участников и их роли, часовые пояса и другие ограничения.</p> <p>Через MCP-сервер агент получает доступ к календарям, сравнивает свободные интервалы и предлагает подходящие варианты. После подтверждения пользователя агент может создать встречу, добавить участников, описание и ссылку для подключения.</p> <p>В результате в плагине сохраняется не только конфигурация подключения к календарю, но и весь порядок действий: какие данные проверить, как выбрать время и в какой момент запросить подтверждение.</p> <h3>Сложный сценарий: обработка клиентского обращения</h3> <p>Более сложный плагин может сопровождать обращение клиента от поступления до передачи в работу. ИИ-агент определяет суть запроса, проверяет наличие необходимых данных, находит информацию о клиенте и договоре в CRM, изучает предыдущие обращения в сервисной системе и сверяется с корпоративной базой знаний.</p> <p>Навык задаёт последовательность проверки, правила распределения обращений, требования к ответу и случаи, когда необходимо участие специалиста. Через MCP-серверы агент получает данные из корпоративных систем и выполняет разрешённые действия: например, готовит проект ответа, создаёт задачу для ответственного подразделения или предлагает изменить статус обращения. Отправка сообщения клиенту и другие значимые действия выполняются только после подтверждения сотрудника.</p> <p>Такой плагин объединяет уже не одну инструкцию, а целый рабочий процесс с несколькими источниками данных, правилами доступа, точками контроля и шаблонами результата.</p> <p>Принцип в обоих сценариях остаётся одинаковым: навык определяет, как выполнять работу, а MCP-серверы предоставляют необходимые данные и разрешённые действия. Поэтому плагин подходит и для небольшой повседневной задачи, и для сложного процесса, связанного с несколькими корпоративными системами.</p> <h2>Что важно учесть при подключении плагина в разных ИИ-инструментах</h2> <p>Agent Plugins 1.0 позволяет использовать один и тот же пакет в разных совместимых клиентах — то есть ИИ-инструментах, которые поддерживают этот формат. Вместе с пакетом переносятся инструкции, шаблоны, справочные материалы и конфигурация MCP-подключений. При этом права доступа, установка и функции конкретного инструмента остаются на стороне клиента.</p> <p>Перед распространением плагин необходимо протестировать во всех целевых рабочих средах и указать, в каких ИИ-инструментах его работа была проверена.</p> <p>При подключении плагина к другому ИИ-инструменту потребуется отдельно проверить и настроить:</p> <p>· Доступ к корпоративным системам. Пользователям может потребоваться повторная авторизация, а компании — настройка прав, учётных данных и сетевых ограничений.</p> <p>· Возможности конкретного ИИ-инструмента. Например, ChatGPT, Codex, Cursor, GitHub Copilot, Kiro и VS Code могут различаться по поддержке отдельных функций и способам их реализации. Если сценарий зависит от функции конкретного инструмента, в другом она может быть недоступна или работать иначе. Поэтому при разработке плагина лучше по возможности избегать функций, привязанных к конкретному ИИ-инструменту.</p> <p>· Выполнение рабочего сценария. Из-за различий между моделями, системными настройками и механизмами подтверждения действий один и тот же плагин может давать разные результаты. При этом ИИ-инструмент и модель ИИ — разные компоненты. Например, ChatGPT — ИИ-инструмент, а GPT — семейство моделей, которые он может использовать. Поэтому тестировать необходимо связку конкретного инструмента и выбранной модели.</p> <p>· Установку и распространение. Каждый ИИ-инструмент по-своему организует подключение плагинов, выдачу доступа пользователям и установку обновлений.</p> <p>Таким образом, новый стандарт позволяет не собирать сам плагин заново, но не отменяет настройку доступов, проверку интеграций и тестирование. Чем больше в решении внешних систем и функций, зависящих от конкретного ИИ-инструмента, тем больше дополнительных работ потребуется при его использовании в другом клиенте.</p> <h2>Где новый стандарт можно использовать уже сейчас</h2> <p>Хотя спецификация пока продолжает развиваться, её уже можно использовать, если решение планируется распространять как целостный пакет. Единая структура может упростить подключение и распространение плагина.</p> <p>Особенно это актуально для систем, которые в дальнейшем планируется развивать, подключать к новым корпоративным сервисам или использовать в разных ИИ-инструментах.</p> <p>Это не означает, что существующие решения необходимо срочно переводить на Agent Plugins 1.0. Но при проектировании можно сразу разделять инструкции агента, справочные материалы, конфигурации подключений и компоненты, зависящие от конкретного ИИ-инструмента. Предыдущие наработки также можно постепенно адаптировать под новый формат.</p> <h2>Какие выводы можно сделать</h2> <p>Главная ценность Agent Plugins 1.0 — возможность отделить описание рабочего сценария, инструкции, накопленную экспертизу и конфигурацию интеграций от конкретного ИИ-инструмента.</p> <p>Независимо от конкретной технологии, инженерный принцип прост: если для задачи уже существует подходящий стандарт и его можно использовать, лучше опираться на него, а не создавать собственный формат. Это сокращает объём повторной работы, упрощает развитие решения и снижает зависимость от конкретного инструмента.</p> <p>Применительно к Agent Plugins 1.0 это означает, что формат стоит учитывать уже сейчас в проектах, для которых важны переносимость, повторное использование компонентов и подключение к разным ИИ-инструментам.</p> <p>При этом формат не делает модель умнее и не заменяет проектирование самого процесса. Чтобы воспользоваться его преимуществами, компания должна понимать, какие данные использует агент, по каким правилам действует и когда передаёт решение человеку. Поэтому готовность к применению стандарта зависит не только от ИТ-инфраструктуры, но и от зрелости бизнес-процессов.</p> <p>Если рабочая логика формализована, созданные сценарии смогут сохранять ценность даже при смене ИИ-инструментов. Спецификация пока новая и будет развиваться, поэтому важно следить за её изменениями и поддержкой со стороны разных клиентов. По нашему мнению, Agent Plugins 1.0 — важный шаг к более управляемому и повторно используемому применению ИИ в корпоративных системах.</p> <p>#IMAGE_235329#</p> Недавно была опубликована спецификация Agent Plugins 1.0.0 — проекта открытого стандарта для упаковки навыков … article Эдуард Забоев, технический директор DIGITAL SECTOR https://www.itweek.ru/themes/detail.php?ID=235326 Wed, 12 Aug 2026 09:20:35 +0300 <p>Интерес российского бизнеса к CRM- и ERP-системам с интеграцией искусственного интеллекта за последний год вырос в<a href="https://corp.cnews.ru/news/line/2025-07-10_interes_rossijskih_kompanij" title="https://corp.cnews.ru/news/line/2025-07-10_interes_rossijskih_kompanij"> два-три раза</a>. Количество поисковых запросов «Битрикс24 ИИ» увеличилось на 600%, «CRM с нейросетью» — на 550%, «ИИ в 1С» — на 85%. При этом, <a href="https://corp.cnews.ru/news/line/2026-01-22_39_rossijskih_kompanij_v" title="https://corp.cnews.ru/news/line/2026-01-22_39_rossijskih_kompanij_v">по данным</a> исследования «СберАналитики» и «Сбер Бизнес Софт», 39% российских организаций уже используют ИИ-агентов и ассистентов для автоматизации документооборота, финансов и HR. Однако в ERP-системы ИИ только начинает проникать. Чаще всего это пока отдельные подсистемы-сателлиты, которые интегрированы с ERP. Почему так происходит и как правильно встраивать интеллектуальные модули в уже работающие корпоративные приложения?</p> <h3>Рынок созрел, но внедрения с ИИ точечные</h3> <p>Объем российского рынка ERP-систем по итогам 2025 года <a href="https://sarnovosti.ru/news/sber-sozdaet-erp-budushchego-/?erid=2Vfnxy9PNyp" title="https://sarnovosti.ru/news/sber-sozdaet-erp-budushchego-/?erid=2Vfnxy9PNyp">оценивается</a> примерно в 100 млрд. рублей и продолжает плавно расти. При этом интерес к использованию встроенных ИИ-инструментов в корпоративных системах огромный. Но пока еще процент компаний, реально применяющих ИИ в ERP, остается небольшим. Сейчас начинают появляться ИИ-сервисы, которые могут встраиваться по API в ERP-системы.</p> <p>Но прежде чем браться за внедрение, компаниям предстоит ответить на несколько принципиальных вопросов.</p> <h3>Где ИИ действительно полезен</h3> <p>Искусственный интеллект эффективен там, где есть большие объемы данных или текста, много рутины, необходимы прогнозы, поиск аномалий или важен интерфейс для сотрудников на естественном языке. В корпоративных системах таких точек множество. Распознавание и обработка первичных документов — сканов и фотографий счетов, накладных, актов. ИИ позволяет заводить их в систему с автоматическим формированием документов. Сегодня такие проекты могут быть реализованы буквально в течение месяца.</p> <p>Еще один вектор — прогнозирование спроса, закупок, производства и движения денежных средств на основе исторических данных. Контроль качества данных: выявление дублей, ошибок ввода, выбросов и аномалий. Копилоты и запросы к данным на естественном языке — например, в формате: «Покажи маржу по региону за квартал».</p> <p>Также ИИ хорошо разгружает направление ИТ-поддержки и развития ERP-систем. Может заниматься классификацией и маршрутизацией обращений, next-best-action в CRM, автоподготовка проектов ответов в Service Desk. Успешно справляется с генерацией драфтов писем, коммерческих предложений, документации. И, наконец, это помощь разработчикам и эксплуатационным командам: ассистенты кода, разбор логов, ИИ ServiceDesk.</p> <h3>Три уровня встраивания ИИ: над, внутри и под</h3> <p>Встраивать ИИ в существующие системы можно тремя способами, и каждый имеет свою логику.</p> <p>Слой над системой — копилоты, запросы на естественном языке, аналитика. Этот подход не затрагивает ядро системы, внедряется быстро и безопасно, поэтому считается отличной точкой старта ИИ-трансформации.</p> <p>Сервисы внутри или рядом с системой — распознавание, прогнозирование, классификация. Подключаются через вызовы API и расширения. Именно здесь ИИ встраивается непосредственно в прикладные модули ERP, CRM, MES, Workflow.</p> <p>Слой под системой — данные, СУБД, инфраструктура. Эффективен для разбора логов, мониторинга и контроля качества данных. Например, ИИ может за считанные минуты написать скрипт парсинга сотен гигабайт технологических логов и выявить причины сбоев и медленных запросов. За день интенсивной работы можно получить 100 Гб текста в формате логов. Даже профильный специалист будет разбирать такой объем вручную несколько дней, а ИИ выдает результат для оценки эксперта за минуты.</p> <h3>Заменять или достраивать — и когда все-таки заменять?</h3> <p>У многих компаний возникает соблазн: не мучиться с интеграцией, а просто заменить старую систему на AI-native решение следующего поколения. Однако опыт показывает, что это самый дорогой, долгий и рискованный путь.</p> <p>При таком подходе «выбрасываются» годы настройки процессов, интеграции, накопленные данные и доверие пользователей. Сам по себе ИИ почти никогда не оправдывает полную замену. В коробочных решениях он как правило, универсален и не заточен под данные и процессы конкретного предприятия. Данные все равно придется мигрировать, процессы настраивать, а людей — переучивать. Полная замена оправданна лишь в нескольких ситуациях: система зашла в тупик по развитию, вендор ушел с рынка, а технологический стек нежизнеспособен. Во всех остальных случаях разумнее достраивать — дополнять текущую систему зрелыми проверенными компонентами, например сервисами «1С», GigaChat, YandexGPT, и настраивать их под контекст конкретного бизнеса.</p> <h3>Главный принцип: не навреди</h3> <p>Ключевое правило встраивания ИИ в традиционные бизнес-приложения — подключение интеллектуальных модулей как изолированного сервиса. Отказ или деградация модели не должны влиять на действующую основную систему. Обязательны резервный сценарий на случай отказа ИИ, сотрудник в контуре для критичных действий. Особенно это важно там, где ИИ касается цифр. Генеративные модели вероятностны и могут ошибаться правдоподобно. В черновике письма или в кратком пересказе такая ошибка стоит недорого и легко правится человеком, а в проводке или налоговом регистре — это уже последствия для отчетности перед ФНС и СФР. Именно поэтому в регламентированном контуре ИИ остается ассистентом: он распознает, предлагает, заполняет черновик, но официальную учетную запись формирует проверенный механизм системы, а критичное действие подтверждает человек. Каждое действие модели должно быть прослеживаемым — какая версия, на каких данных, кто подтвердил результат, — иначе аудитор не восстановит происхождение цифры. ИИ готовит цифру, но отвечает за нее система и человек.</p> <p>Еще один важный аспект — безопасность данных. После 2022 года большинство крупных заказчиков стремятся развертывать ИИ-модели внутри собственного контура. Клиенты не готовы отдавать данные за пределы компании. Поэтому стараются делать так называемые ПАКи. Оборудование, операционная система и модель ставятся внутрь компании, и к ним через API добавляются необходимые ИИ-сервисы.</p> <h3>С чего начать: рекомендации для ИT-директоров</h3> <p>Первое и самое важное — посчитать экономику. Внедрение ИИ должно быть дешевле, чем решение задачи силами сотрудников, или приносить измеримый бизнес-эффект. Второе — выбрать пилотный проект с быстрой окупаемостью. Лучшие кандидаты для первых экспериментов — распознавание первичных документов, копилот для отчетности, ИИ Service Desk для первой линии поддержки. Третье — обеспечить изоляцию ИИ-сервиса от критического ядра системы. Четвертое — подготовить резервные сценарии: если ИИ не справляется, процесс должен продолжаться в ручном режиме. И пятое — не пытаться внедрить ИИ повсеместно. В системе нужно найти место, где ИИ применим и экономически обоснован, а также бизнес готов к его внедрению. Это поможет добиться первых побед для выделения инвестиций на новые кейсы.</p> <p>Искусственный интеллект в ERP — это не хайп, а инструмент, который уже сегодня помогает снижать стоимость владения системами, ускорять разработку и эксплуатацию, а главное — создавать новую ценность для бизнеса. Но как и любой инструмент, он требует вдумчивого подхода. Начинать стоит с малого: копилоты, распознавание документов, прогнозирование. Постепенно наращивать компетенции и масштабировать успешные практики. И главное — помнить: ИИ должен работать на бизнес, а не бизнес — на ИИ.</p> <p>#IMAGE_235327#</p> Интерес российского бизнеса к CRM- и ERP-системам с интеграцией искусственного интеллекта за последний год … article Илья Бычков, директор направления разработки практики “1С” компании “Рексофт” https://www.itweek.ru/themes/detail.php?ID=235325 Wed, 12 Aug 2026 09:12:21 +0300 <p><em>Согласно Gartner, до конца 2028 г. ни одна масштабная корпоративная рабочая нагрузка искусственного интеллекта не будет выполняться на квантовом оборудовании, а классический ускоренный ИИ будет доминировать во всех производственных бенчмарках, сообщает портал </em><em>HPCwire</em><em>.</em></p> <p>Квантовый ИИ (Quantum AI) относится к методам ИИ или машинного обучения, которые требуют выполнения на квантовом оборудовании для достижения заявленного преимущества в производительности, стоимости или возможностях по сравнению с классическими вычислениями.</p> <p>«Для достижения отказоустойчивых квантовых вычислений в масштабе, необходимом для получения измеримых преимуществ в производительности или снижении затрат на ИИ, требуются достижения в четырех областях: аппаратное обеспечение, коррекция ошибок, промежуточное ПО и алгоритмы», — говорит Чираг Декате, вице-президент-аналитик Gartner.</p> <p>Настоящий квантовый ИИ отличается от трех часто путаемых категорий:</p> <p><strong>• Классический ИИ:</strong> модели ИИ, такие как глубокое обучение, трансформеры и обучение с подкреплением, которые работают исключительно на CPU, GPU или TPU и обеспечивают измеримую окупаемость инвестиций для предприятий уже сегодня.</p> <p><strong>• ИИ, дополненный квантовыми методами (</strong><strong>Quantum</strong><strong>-</strong><strong>inspired</strong> <strong>AI</strong><strong>):</strong> классические алгоритмы, заимствующие идеи из квантовой механики, такие как отжиг, тензорные сети и амплитудное кодирование, но работающие на обычном оборудовании. Эти методы уже приносят пользу в задачах оптимизации, моделирования и выборки и не зависят от квантового оборудования.</p> <p><strong>• Гибридные квантово-классические методы:</strong> экспериментальные рабочие процессы, в которых небольшие квантовые схемы используются совместно с классическим ИИ или высокопроизводительными вычислительными системами (HPC). Эти подходы используются для исследований и пилотных проектов с поддержкой поставщиков, а не для производственного ИИ.</p> <p>«Когда поставщики заявляют о предоставлении „квантового ИИ“, они обычно имеют в виду гибридные или дополненные квантовыми технологиями методы, а не нативно-квантовый ИИ, работающий в масштабах предприятия, — отмечает Декате. — Настоящие квантовые вычисления не готовы ни к одной производственной ИИ-нагрузке и, скорее всего, не будут готовы до конца этого десятилетия. Более того, ни один рецензированный результат не демонстрирует квантового преимущества в производственных ИИ-нагрузках».</p> <p>Формирование пула поставщиков, ориентированных на конвергенцию квантовых технологий и ИИ, ускоряется, и советы директоров, находящиеся под давлением необходимости «не упустить квантовые технологии», будут склонны перенаправлять ИИ-бюджеты на НИОКР, которые не смогут принести пользу в этом десятилетии. Поэтому Gartner прогнозирует, что отказоустойчивые квантовые вычисления для ИИ до конца 2030 г. останутся на стадии НИОКР, с недостаточным масштабом логических кубитов для поддержки экономически жизнеспособных сквозных алгоритмов ИИ.</p> <h3>Разделите квантовый бюджет и ИИ-бюджет</h3> <p>Квантовые НИОКР и производственная инфраструктура ИИ имеют несовместимые временные горизонты, юнит-экономики и потребности в управлении. Генеративный ИИ приносит измеримую отдачу по показателям скорости выполнения, точности и автоматизации в течение <nobr>12-18 месяцев.</nobr> Между тем, квантовый ИИ никогда еще не приносил измеримой ценности ни в одной производственной рабочей нагрузке и вряд ли сделает это в обозримом будущем.</p> <p>«Смешивание двух бюджетов искажает подотчетность обоих и позволяет квантовой опциональности вытеснять производственные возможности ИИ, — говорит Декате. — CIO на постоянной основе включают генеративный ИИ, агентный ИИ, кибербезопасность и облачные технологии в категории основных расходов. Квантовые технологии не фигурируют в списках приоритетных инвестиций. CIO, которые финансируют квантовые технологии, делают это по значительно более низким ставкам, чем генеративный ИИ, и не требуют краткосрочной окупаемости инвестиций».</p> <p>Чтобы получить максимальную отдачу от квантовых решений, предприятиям следует:</p> <p><strong>• Внедрять классические методы, дополненные квантовыми технологиями, в существующий стек ИИ.</strong> Организациям следует отдавать приоритет алгоритмам, дополненными квантовыми методами, работающим на современной инфраструктуре GPU, а не развитию квантового оборудования. В таких областях, как оптимизация, генеративный ИИ, линейная алгебра, анализ графов и обучение с подкреплением, классические подходы обеспечивают аналогичные преимущества без затрат, сложности или незрелости квантовых систем.</p> <p><strong>• Определить критерии прекращения пилотного проекта и не вестись на показуху со стороны поставщиков.</strong> Каждый пилотный квантовый проект должен начинаться с предварительного определения показателей успеха, четкого классического эталона и явных условий прекращения. Это предотвращает чрезмерное расходование бюджета на бесконтрольные эксперименты без получения измеримой ценности.</p> <p><strong>• Отслеживать значимый квантовый прогресс.</strong> Наиболее важным показателем прогресса является не количество физических кубитов, а доступность логических кубитов, работающих с приемлемым уровнем ошибок. Достижения в области коррекции ошибок, калибровки с помощью ИИ и квантового управления более важны для получения бизнес-ценности, чем громкие заявления о более крупных квантовых процессорах.</p> Согласно Gartner, до конца 2028 г. ни одна масштабная корпоративная рабочая нагрузка искусственного … article https://www.itweek.ru/themes/detail.php?ID=235324 Tue, 11 Aug 2026 13:14:15 +0300 <p>Компания «ИТ-Экспертиза» представила версию программного комплекса информационной безопасности (ПК ИБ) САКУРА 3.3. Среди ключевых изменений — многофакторная аутентификация, интеграция с OpenVPN и почтовым сервером, безопасный доступ и управление секретами с поддержкой HashiCorp Vault.</p> <p>Обновление направлено на усиление контроля доступа, расширение возможностей интеграции и улучшение пользовательского опыта.</p> <p>Реализованная в САКУРА 3.3 многофакторная аутентификация и подтверждение через мобильное приложение усиливает безопасный доступ к ИТ-инфраструктуре. Система включает профили MFA (многофакторной аутентификации), команды сценариев и интеграцию с разными LDAP-каталогами. Также добавлено безопасное управление секретами с поддержкой HashiCorp Vault и возможностью переключения между провайдерами хранения. Эта функциональность обеспечивает дополнительный уровень защиты критически важных данных и учётных записей.</p> <p>В данной версии реализована интеграция с популярным VPN-решением OpenVPN, что расширяет возможности контроля сетевого доступа. Добавлен новый тип внешней системы — почтовый сервер для отправки событий и уведомлений. Также улучшена обработка ответов в интеграции с SCCM и расширены способы сбора информации в интеграции с КриптоПро NGate. Эти обновления позволяют организациям более гибко настраивать инфраструктуру безопасности и автоматизировать уведомления.</p> <p>Улучшена производительность агентов для Windows, что особенно важно при работе на устройствах с ограниченными ресурсами. Добавлены алгоритмы автоматического определения домена при входе в систему, что упрощает администрирование в распределенных сетях.</p> <p>В ПК ИБ САКУРА 3.3 добавлена палитра команд (CommandPalette) с поддержкой быстрого доступа, истории и избранного, а также расширен набор горячих клавиш для удобства администраторов системы. В редакторе ролей реализован режим «Только для чтения» для снижения риска случайных изменений конфигурации.</p> <p>«В версии 3.3 мы сосредоточились на трёх ключевых направлениях: усиление безопасности через MFA и управление секретами, расширение экосистемы интеграций и улучшение пользовательского опыта. Эти изменения отражают потребности наших заказчиков в гибкой и удобной системе контроля и управления удаленными рабочими местами», — отметил Максим Ефремов, заместитель генерального директора по ИБ компании «ИТ-Экспертиза».</p> Компания «ИТ-Экспертиза» представила версию программного комплекса информационной безопасности (ПК ИБ) САКУРА 3.3. Среди … message https://www.itweek.ru/themes/detail.php?ID=235323 Tue, 11 Aug 2026 13:07:45 +0300 <p>Компания VolgaBlob обновила платформу Smart Monitor, предназначенную для аналитики, ИТ-мониторинга и построения SOC/SIEM. В релизе 6.1 акцент сделан на модули для работы с ИИ-инфраструктурой, также значительные обновления получило ядро платформы.</p> <p>Одним из ключевых изменений релиза стал потоковый коррелятор в Core — базовом модуле платформы. Ранее здесь использовалась ретроспективная корреляция, основанная на анализе накопленных исторических данных. Теперь оба подхода объединены: в интерфейсе появилась отдельная вкладка с правилами, позволяющими обрабатывать данные в момент их поступления.</p> <p>Потоковый коррелятор поддерживает полный цикл активных действий: создание инцидентов, запись в базу данных, работу с активными списками. Сочетание исторической и потоковой корреляции в рамках единой платформы — редкость на рынке, появление этой возможности в Smart Monitor существенно расширило сценарии применения системы.</p> <p>По мере того, как организации все активнее разворачивают ИИ-модели на локальных мощностях, растет потребность в специализированных инструментах контроля. Однако обычный инфраструктурный мониторинг не учитывает специфику ИИ: он не отслеживает использование GPU-памяти, стоимость запроса, трассировки ИИ-агентов, доступность ИИ-сервисов. Новая версия Smart Monitor закрывает этот пробел.</p> <p>В состав платформы вошел новый модуль AI Observability, который собирает телеметрию ИИ-контура из нескольких источников, нормализует ее в единый набор данных и предоставляет готовый коробочный контент. Он обеспечивает мониторинг ИИ-инфраструктуры: отслеживает состояние GPU, прокси- и инференс-серверов, контролирует производительность, доступность ресурсов, потребление токенов. В результате бизнес может видеть состояние, расходы и производительность инфраструктуры в едином окне и выявлять причины сбоев и перерасхода раньше, чем они скажутся на пользователях и бюджете.</p> <p>Собранные данные также используются в работе модуля AI Security, предназначенного для обнаружения угроз, связанных с ИИ-инструментами организации. Он анализирует действия локальных ИИ-агентов, запросы и ответы LLM, снимки конфигураций разрешений, регистрируя инциденты безопасности на их основе. В обновленной версии модуля добавлены новые правила безопасности, согласованные с конфигурациями сбора данных и разработанные в соответствии со стандартом OWASP Top 10 для AI. Правила охватывают сценарии компрометации ИИ-инфраструктуры, выявление угроз и инъекций, позволяя выстроить комплексную защиту корпоративных ИИ-систем.</p> <p>Также важно отметить, что в новой версии появился специальный фреймворк, предназначенный для задач машинного обучения — <nobr>«ML-студия».</nobr> Он реализован непосредственно внутри платформы и позволяет использовать готовую модель прогнозирования. Благодаря этому аналитики и инженеры теперь могут решать <nobr>ML-задачи</nobr> непосредственно в Smart Monitor. В наличии библиотека дефолтных алгоритмов с возможностью добавления собственных.</p> <p>Модуль поведенческой аналитики (UBA) получил новый оркестратор задач, через который теперь проходят все расчеты политик профилирования и обработка объектов. Ключевое техническое улучшение — переход на кластерную обработку: каждая нода берет объекты из очереди и обрабатывает их параллельно, что обеспечивает значительный прирост скорости. В интерфейсе появилось управление задачами: их можно останавливать, перезапускать или точечно запускать упавшие задачи.</p> <p>Модуль МАЯК, предназначенный для мониторинга сразу на нескольких уровнях (инфраструктура, сервисы, приложения) и позволяющий автоматически находить первопричины сбоев, получил Maintenance Mode — режим обслуживания. Если раньше объекты инфраструктуры, на которых проводились плановые технические работы, могли создавать ложные тревоги, то теперь их можно перевести в режим обслуживания — разово или с указанием временного интервала. Пока окно обслуживания активно, объекты не учитываются в модели здоровья, а в интерфейсе метрик отображается бейдж «технический перерыв».</p> <p>Инцидент-менеджер получил поддержку политик SLA. Теперь для инцидентов можно настраивать правила по рабочим процессам и статусам: время до назначения ответственного, время взятия в работу, время полного решения. При этом счетчик не сбрасывается при смене статуса — система сохраняет информацию о том, насколько заблаговременно был выполнен SLA.</p> <p>В планировщике задач внедрено распределение запусков по времени: система анализирует расписание всех актуальных заданий и предлагает оптимизацию. Это устраняет проблему одновременного старта сотен задач и пиковых нагрузок. Добавлен график нагрузки по запускам за сутки, введена многоуровневая система статусов ошибок — с отдельными индикациями ошибок поискового запроса и активного действия.</p> <p>«Новый релиз — логичный шаг в развитии Smart Monitor как единой платформы для observability, безопасности и анализа данных, которая закрывает новые потребности бизнеса в контроле над всей инфраструктурой, включая ИИ-контур», — прокомментировал Максим Кириенко, коммерческий директор VolgaBlob.</p> Компания VolgaBlob обновила платформу Smart Monitor, предназначенную для аналитики, ИТ-мониторинга и построения SOC/SIEM … message https://www.itweek.ru/themes/detail.php?ID=235322 Tue, 11 Aug 2026 13:06:39 +0300 <p>Специалисты компании «Информзащита» выявили, что 34% систем управления инженерной инфраструктурой ЦОД работают на устаревших прошивках. В выборке из 66 395 систем управления зданиями и инженерными процессами BMS более чем у трети устройств использовались неактуальные версии программного обеспечения. Одновременно 84% BMS обмениваются данными по небезопасным протоколам, а 800 устройств содержат известные эксплуатируемые уязвимости из категории KEV. Годом ранее исследование BMS в 529 организациях показывало другую сторону той же проблемы: 72% компаний эксплуатировали BMS с KEV, у 66% организаций присутствовали уязвимости, которые ранее использовались в ransomware-атаках, а у 48% такие уязвимости сочетались с небезопасным подключением к сети. Устаревшая прошивка опасна именно в сочетании с открытым протоколом и доступом из соседнего сегмента сети — а именно так выглядит типичная BMS.</p> <p>Причина такой ситуации во многом связана с жизненным циклом инженерного оборудования. В реальности за медленным патчингом чаще стоит более простая причина — у BMS просто нет владельца с точки зрения безопасности. Для корпоративной рабочей станции установка обновления может укладываться в стандартное окно обслуживания. С контроллером BMS, системой мониторинга электропитания или устройством, участвующим в управлении охлаждением, процедура устроена иначе. Перед обновлением необходимо проверить совместимость новой версии с контроллерами, датчиками, шлюзами и программным обеспечением диспетчеризации, согласовать работы с эксплуатационной службой и убедиться, что изменение прошивки не повлияет на технологический процесс. В дата-центре цена ошибки особенно высока, так как некорректная работа BMS способна затронуть охлаждение, энергоснабжение, резервные генераторы, пожарную автоматику и другие системы, работа которых связана с непрерывностью сервиса. Поэтому обновление нередко откладывается до следующего регламентного окна, а временное решение постепенно превращается в постоянное. </p> <p>Кроме того, значительная часть оборудования проектировалась в расчете на закрытую технологическую сеть, где основным требованием была стабильность обмена данными. Отсюда широкое распространение BACnet, MODBUS и других протоколов, в базовых реализациях которых отсутствуют привычные для IT-среды механизмы аутентификации и шифрования. 84% BMS используют небезопасные протоколы, причем BACnet применяется примерно на 42% таких систем. Это значит, что даже свежая прошивка не решает проблему целиком: обновление закрывает уязвимости в коде, но не меняет архитектуру протокола без аутентификации. Для систем мониторинга электропитания доля небезопасных протоколов составляет 82%, для UPS — 86%, для OT-контроллеров — 85%. В результате проблема старой прошивки редко существует изолированно. Одно устройство может одновременно иметь неподдерживаемую версию ПО, доступную для эксплуатации уязвимость и возможность принимать команды по протоколу, который изначально не предусматривает полноценной проверки отправителя.</p> <p>Разбивка по векторам атак показывает, что прямое подключение BMS к интернету представляет лишь один из сценариев. Из 66 395 исследованных BMS напрямую доступны из внешней сети 369 устройств, то есть менее 1%. Вместе с этим, реальный сценарий атаки — не сканирование интернета, а один шаг lateral movement из уже скомпрометированного IT-сегмента. Гораздо существеннее риск перемещения злоумышленника из уже скомпрометированного сегмента. В отдельной выборке инфраструктуры ЦОД 5 410 из 39 335 BMS, или 14%, находились всего в одном сетевом переходе от системы, связанной с интернетом. Для PDU этот показатель достигает 41%, для HVAC — около трети. Поэтому первым вектором остается компрометация смежного IT-, IoT- или сетевого узла с последующим lateral movement в технологический сегмент. Второй вектор связан с эксплуатацией известных уязвимостей в старых версиях прошивок. Третий — с воздействием непосредственно на технологический обмен через BACnet, MODBUS и другие протоколы без достаточной аутентификации. Еще один сценарий формируют средства удаленного администрирования и подрядчики, которым требуется доступ к BMS для обслуживания оборудования. Исследование BMS 2025 года отдельно относит неуправляемый сторонний удаленный доступ, открытые сетевые порты, слабую аутентификацию и неподдерживаемые версии ПО к характерным проблемам таких сред.</p> <p>Ситуацию осложняет организационное устройство эксплуатации ЦОД. Инженерная инфраструктура нередко находится в зоне ответственности служб, для которых приоритетами служат доступность, температурный режим, энергопотребление и выполнение SLA. ИБ-подразделение при этом может видеть серверы, сетевое оборудование и корпоративные системы, но не иметь такой же полноты данных о версиях прошивок контроллеров, шлюзов и BMS. Часть устройств устанавливается интеграторами или поставщиками инженерных систем и годами работает без пересмотра исходной конфигурации. Это создает сложный парк оборудования разных поколений, где одномоментное обновление невозможно. Наличие резервного оборудования само по себе проблему не закрывает: основной и резервный контроллеры могут иметь одинаковую версию прошивки и один набор уязвимостей. Если атакующий эксплуатирует эту уязвимость, откажут оба контроллера одновременно, резервирование страхует от отказа оборудования, но не от кибератаки. Именно поэтому наличие физического резервирования нельзя автоматически считать защитой от киберинцидента, связанного с эксплуатацией программной ошибки.</p> <p>Самая высокая доля устаревших прошивок обнаружена в системах мониторинга электропитания — 59%. Далее идут OT-системы управления с 48%, BMS с 40%, IoT и интеллектуальные датчики с 37% и UPS с 23%. Для операторов коммерческих и colocation-ЦОД особенно чувствительны BMS, PDU и охлаждение, поскольку нарушение их работы затрагивает одновременно инфраструктуру нескольких клиентов. Для облачных площадок и центров обработки данных с высокой плотностью вычислений возрастает зависимость от охлаждения и управления питанием. В корпоративных ЦОД тот же риск дополняется длительным сроком эксплуатации инженерного оборудования, которое зачастую обновляется значительно реже серверной части.</p> <p>Приоритетом для владельца ЦОД должна стать инвентаризация инженерных активов с привязкой к версии прошивки, модели устройства, статусу поддержки производителя и роли в технологическом процессе. Простого перечня IP-адресов здесь недостаточно: необходимо понимать, какие BMS управляют охлаждением, какие контроллеры участвуют в энергоснабжении, какие системы связаны с генераторами и пожарной автоматикой и по каким сетевым маршрутам к ним можно добраться. Обновления следует планировать исходя из эксплуатационной критичности и наличия реально используемых уязвимостей, в первую очередь закрывая KEV и устройства, доступные из смежных сегментов. Там, где установка новой прошивки невозможна, нужны компенсирующие меры: изоляция BMS от корпоративной сети, микросегментация, отказ от прямого интернет-доступа, контроль подрядчиков и выделенные механизмы удаленного подключения. Для BACnet, MODBUS и других технологических протоколов необходим мониторинг команд и отклонений от штатного поведения. Такая схема позволяет работать с устаревшим оборудованием без иллюзии, что закрытый внешний периметр автоматически делает инженерную инфраструктуру недоступной для атакующего.</p> Специалисты компании «Информзащита» выявили, что 34% систем управления инженерной инфраструктурой ЦОД работают … message https://www.itweek.ru/themes/detail.php?ID=235320 Tue, 11 Aug 2026 09:57:18 +0300 <p><em>Центры обработки данных сталкиваются с растущими рисками со стороны киберфизических систем (КФС). Безопасность операционных технологий (ОТ) имеет решающее значение для предотвращения сбоев и обеспечения операционной устойчивости, пишет на портале </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>Шон Тафтс, технический директор Claroty.</em></p> <p>Устойчивость дата-центров выходит на первый план, и безопасность является ключевой частью этой истории. К ЦОДам все чаще относятся как к критической инфраструктуре, поскольку от них зависит значительная доля экономического роста и операций по обеспечению безопасности.</p> <p>Но слишком часто защита ограничивается периметром. Внутри ограждения накапливается отдельный и недостаточно изученный риск: ОТ и КФС, которые обеспечивают работу этих объектов. К источникам бесперебойного питания (ИБП), блокам распределения питания, системам охлаждения, датчикам окружающей среды и платформам управления зданиями теперь регулярно подключаются, часто через инструменты удаленного доступа и устаревшие протоколы, которые никогда не были разработаны для современного ландшафта угроз.</p> <p>Это не ИТ-системы, и большинство организаций не управляют ими как таковыми. Когда этот уровень скомпрометирован, это часто выглядит не как взлом, а как сбой. По мере того, как спрос, обусловленный искусственным интеллектом, ускоряет зависимость от подключенной операционной инфраструктуры, масштаб того, что зависит от этих систем, также меняется. Объекты, которые обучают и запускают модели ИИ, теперь являются стратегическими активами, и стоимость отключения масштабируется в зависимости от всего, что теперь от них зависит.</p> <h3>Дата-центр — это киберфизическая экосистема</h3> <p>Большинство операторов интуитивно понимают физическую структуру дата-центра: «белая» зона, где находится ИТ-нагрузка, и «серая» зона, где находятся электропитание и системы отопления, вентиляции и кондиционирования (ОВиК). Проблема в том, что организационные структуры не развиваются так быстро, как технологии. Команды по эксплуатации говорят на языке электрического напряжения и охлаждения. Команды по безопасности говорят на языке пакетов и уязвимостей.</p> <p>Традиционные системы безопасности не были созданы для этой среды, и ни одна из сторон не имеет инструментов для преобразования рисков другой стороны в оперативные действия. В результате возникает разрыв в ответственности, прозрачности и приоритизации. Именно в этом разрыве и рождаются сбои.</p> <p>Также меняется то, как выглядит инцидент. Корпоративная ИТ-безопасность в значительной степени строится вокруг конфиденциальности. Для ЦОДа основным последствием часто является сбой. Это может проявляться в неожиданном отключении, ложных показаниях и задержке срабатывания сигнализации, а также в ухудшении работы системы охлаждения, вызывающем термическое дросселирование. В худшем случае локальный сбой, например, отключение питания на уровне стойки, может привести к каскадному распространению сбоев в вышестоящих системах объекта.</p> <p>Понимание этого различия должно изменить подход руководителей к оценке результатов обеспечения безопасности. Вопрос не только в том, «предотвращаем ли мы вторжения?», но и в том, «можем ли мы поддерживать безопасную работу во время вторжения?». В этом и заключается суть устойчивости.</p> <h3>Ставки выше, чем осознает большинство людей</h3> <p>Одна из причин, по которой обсуждение этой темы затягивается, заключается в том, что мы не в полной мере осознали последствия последовательных сбоев.</p> <p>Когда выходит из строя один критически важный сектор, другие быстро деградируют. Например, больница зависит не только от врачей и зданий. Ей необходимы медицинские карты, транспорт, хранение лекарств в условиях холодовой цепи и стабильное электропитание для поддержания необходимых условий окружающей среды. Когда эти вспомогательные системы выходят из строя, оказание медицинской помощи часто продолжается, но становится ручным, более медленным и рискованным.</p> <p>Теперь рассмотрим под этим углом дата-центры. Поскольку ИИ становится неотъемлемой частью работы предприятий, функционирования цепочек поставок и анализа и действий систем национальной безопасности, бесперебойная работа дата-центров становится вопросом экономической безопасности и общественной безопасности, а не просто вопросом доступности услуг.</p> <p>Проблема не только в увеличении количества ЦОДов. Дело в том, что они проектируются, строятся и вводятся в эксплуатацию быстрее, чем когда-либо прежде, что создает условия, в которых управление, проверка безопасности и операционная зрелость с трудом успевают за этими темпами.</p> <h3>Сверхбыстрый рост создает новые риски</h3> <p>Сверхбыстрый рост означает, что система управления с трудом успевает за темпами освоения новых площадок, быстрого развертывания устройств и сокращения сроков развертывания. Когда организации начинают строительство нового дата-центра каждые три месяца, скорость создает проблемы для всей цепочки поставок и качества работы.</p> <ul> <li><strong>Цепочка поставок.</strong> Технологии, обеспечивающие энергоснабжение и охлаждение современных дата-центров, быстро развиваются. Многие новые поставщики, включая стартапы и компании из регионов с частичным доверием, могут не иметь зрелых циклов безопасной разработки ПО и производственных процессов. По мере того, как эти технологии внедряются в критическую инфраструктуру, становятся необходимыми отказоустойчивые программы КФЗ для управления рисками со стороны третьих лиц.</li> <li><strong>Качество.</strong> Рынок вознаграждает скорость, и огромные деньги могут зависеть от соблюдения жестких сроков развертывания. Поскольку подрядчики, сторонние организации и внутренние команды работают быстрее, чем когда-либо, ошибки, связанные со скоростью, становятся все более распространенными. Примеры из реальной жизни включают неправильную настройку сегментации сети, открытые порты и неизмененные учетные данные по умолчанию.</li> </ul> <p>Скорость стала конкурентным преимуществом, но также и угрозой безопасности. Без надлежащего уровня управления организации рискуют строить критическую инфраструктуру будущего, используя сегодняшние слепые операционные зоны.</p> <h3>Что говорят исследования</h3> <p>Недавние исследования показывают, насколько напрямую эти уязвимости могут приводить к сбоям в работе. В недавнем <a href="https://claroty.com/team82/research/attacking-ups-network-cards-to-take-down-data-centers">отчете</a> Team82 «Attacking UPS Network Cards to Take Down Data Centers» были обнаружены уязвимости почти максимального уровня серьезности в сетевых интерфейсах, используемых для управления системами ИБП. Обход аутентификатора в сочетании с условием удаленного выполнения кода в худшем случае может позволить злоумышленнику обойти средства управления входом в систему и выдавать команды, которые прерывают подачу питания на защищенные нагрузки. В дата-центре это не просто неудобство. Потенциально это событие, способное привести к масштабному отключению.</p> <p>Результаты другого <a href="https://claroty.com/team82/research/turning-up-the-heat-hacking-trane-hvac-controllers">исследования</a> Team82 «Turning Up the Heat: Hacking Trane HVAC Controllers» выявили цепочку уязвимостей в широко используемом контроллере ОВиК, включая путь к удаленному доступу на уровне root без аутентификации и утечку конфиденциальных данных объекта. В совокупности такая цепочка может дать злоумышленнику влияние на системы охлаждения, которые напрямую определяют, остаются ли стабильными рабочие нагрузки высокой плотности. Охлаждение — это не фоновая система. От нее зависит время безотказной работы, и по мере увеличения плотности размещения оборудования в стойках запас по тепловому режиму уменьшается.</p> <p>Закономерность важнее отдельных инцидентов. В обоих случаях оборудование, о котором большинство команд ИТ-безопасности редко задумываются, оказалось именно тем оборудованием, которое определяет, останется ли объект в рабочем состоянии.</p> <h3>Устранение пробелов</h3> <p>Многие киберфизические устройства были разработаны для обеспечения безотказной работы и ремонтопригодности в эпоху ограниченных возможностей подключения и совершенно иной модели угроз. Сегодня подключенность является требованием бизнеса; удаленное обслуживание стало обычным явлением, и эти системы часто полностью выходят за рамки традиционного управления ИТ-уязвимостями. Команды по эксплуатации объектов располагают отношениями с поставщиками, но им не хватает рабочего процесса для отслеживания рисков, связанных со встроенным ПО. Команды безопасности знают, как операционализировать управление уязвимостями, но не контролируют активы.</p> <p>Начните с обеспечения видимости активов как в «серой», так и в «белой» зонах, чтобы знать, что имеется, где оно находится, с чем оно взаимодействует и какие протоколы и версии прошивки оно использует. Сопоставьте эти активы с операционными целями, чтобы ремедиационные и компенсационные меры отдавали приоритет тому, что наиболее важно для безотказной работы. Далее, сегментация должна стать первоклассным инструментом контроля бесперебойной работы, ограничивая обмен данными только необходимыми ресурсами, разрешая управляющий трафик только авторизованным каналам и разделяя сети управления и бизнес-сети, чтобы компрометация не приводила к масштабным проблемам на всем предприятии. Примените тот же подход к удаленному доступу, обеспечив надежную аутентификацию, принцип минимальных привилегий и возможность аудита сеансов для поставщиков и подрядчиков.</p> <p>Наконец, рассматривайте обнаружение и реагирование как киберфизические дисциплины, сопоставляя события безопасности с операционными аномалиями и обеспечивая, чтобы сценарии реагирования предвидели манипуляции с системами мониторинга и управления, с целью предотвращения превращения инцидентов в простои.</p> <h3>Почему это важный вопрос для руководства</h3> <p>Страховщики все чаще ожидают наличия проверяемых доказательств киберфизических мер контроля, обеспечивающих операционную устойчивость. Это означает прозрачность в отношении КФС-активов, сегментацию, ограничивающую радиус поражения, регулируемый удаленный доступ и отчетность, показывающую прогресс во времени. Эти ожидания все больше соответствуют строгим требованиям, предъявляемым к другим секторам критической инфраструктуры.</p> <p>Это переводит безопасность ОТ из технической в бизнес-тему. Если бесперебойная работа — это продукт, то киберфизическая устойчивость — это часть качества продукта.</p> <p>В отрасли справедливо уделяют основное внимание физическим угрозам и безопасности периметра. Но системы, обеспечивающие бесперебойную работу, охлаждение серверов и электроснабжение, заслуживают не меньшего внимания. Потому что, когда этот уровень выходит из строя, в новостях редко появляется сообщение «нарушение безопасности». Вместо этого появляется сообщение «сбой».</p> Центры обработки данных сталкиваются с растущими рисками со стороны киберфизических систем (КФС). Безопасность … article https://www.itweek.ru/themes/detail.php?ID=235318 Tue, 11 Aug 2026 09:41:54 +0300 <p><em>ИИ-агенты становятся полноценными участниками рабочих процессов. Для бизнеса это естественное продолжение автоматизации: если low-code позволяет оперативнее создавать приложения и сценарии, то ИИ-агенты быстрее выполняют действия внутри них. При этом ИИ-агент в корпоративной среде должен управляться через те же инструменты, что и сотрудник — роли, права, ограничения, ответственность и цифровой след.</em></p> <h3>Почему ИИ-агент — больше, чем помощник</h3> <p>На первом этапе корпоративный ИИ часто воспринимался как интеллектуальный ассистент: подготовить текст, найти информацию, кратко пересказать документ, помочь с письмом, предложить структуру презентации или сформулировать ответ. В такой модели риск ограничен: ассистент помогает человеку думать и готовить материалы, но финальное действие остается за сотрудником.</p> <p>Модель меняется. ИИ-агенты начинают подключаться к корпоративным системам и выполнять действия: создать карточку в системе управления взаимоотношениями с клиентами (CRM), обновить статус сделки, завести заявку, подготовить договор, назначить встречу, сформировать задачу в проектной системе, проверить соответствие данных, запустить рабочий процесс. Это другой уровень ответственности.</p> <p>Пока ИИ только предлагает текст, за ошибку несет ответственность человек. Когда агент меняет данные, инициирует процессы или выполняет действия, его ошибка может стать частью корпоративной системы. Поэтому к ИИ-агентам стоит относиться как к новому типу цифрового исполнителя.</p> <h3>Аналогия с человеком-ассистентом</h3> <p>Самый доступный способ объяснить принцип управления ИИ-агентом — сравнить его с человеком-ассистентом. Руководитель не предоставляет новому ассистенту полный доступ к почте, календарю, договорам, CRM, финансам, кадровым документам и коммерческим условиям. Сначала определяется роль: что человек должен делать, какие данные ему нужны, какие действия он может выполнять самостоятельно, а какие — только после согласования.</p> <p>Ассистент готовит письма, собирает материалы, создает черновики, вносит данные, но отправляет, утверждает и меняет условия только руководитель. С ИИ-агентом должна работать та же логика.</p> <p>Агенту нельзя давать доступ к данным, которые недоступны человеку на аналогичной роли. Если человеку нельзя самостоятельно выполнять критичное действие, то и агент не может иметь такую возможность. В корпоративной среде доверие должно подтверждаться не обещаниями, а настройками прав, журналом действий и контролем данных.</p> <h3>Какие действия могут выполнять ИИ-агенты</h3> <p>ИИ-агенты могут быть полезны в разных корпоративных сценариях.</p> <p>В продажах они могут готовить резюме по клиенту, обновлять карточку сделки, формировать план действия после встречи, предлагать следующий шаг, собирать материалы для предпродажной подготовки.</p> <p>В клиентском сервисе — классифицировать обращения, предлагать ответы, создавать заявки, проверять статус выполнения, передавать сложные случаи ответственным сотрудникам.</p> <p>В HR — готовить описания вакансий, собирать данные по кандидатам, формировать черновики писем, помогать с адаптационными маршрутами.</p> <p>В закупках и договорной работе — проверять комплектность документов, готовить черновики запросов, сверять условия, напоминать о сроках согласования.</p> <p>В ИТ и эксплуатации — создавать заявки, анализировать инциденты, предлагать решения, обновлять статусы, собирать информацию из мониторинга и базы знаний.</p> <p>Во всех этих сценариях ценность ИИ-агента возникает благодаря способности сокращать ручные операции и помогать сотруднику быстрее проходить процесс.</p> <p>Чем ближе агент к данным, деньгам, обязательствам и клиентам — тем строже правила.</p> <h3>Три уровня автономности</h3> <p>На практике рекомендуется разделять ИИ-агентов по уровню автономности.</p> <p>Первый уровень — агент предлагает. Он анализирует информацию, готовит черновик, рекомендует действие, подсвечивает риск или собирает данные, но ничего не меняет в системе без участия человека. Это самый безопасный сценарий, подходящий для первых внедрений, так как у сотрудника сохраняется контроль над ИИ.</p> <p>Второй уровень — агент готовит действие к утверждению. Он может сформировать заявку, подготовить изменение в CRM, собрать пакет документов, создать черновик письма или предложить изменение статуса, но финальное подтверждение делает человек. Такой уровень подходит для процессов, где важно ускорить подготовку, но нельзя полностью автоматизировать ответственность.</p> <p>Третий уровень — агент выполняет действие автоматически. Он может самостоятельно создавать задачи, обновлять статусы, отправлять уведомления, запускать стандартные процессы, переносить данные между системами. Этот уровень допустим только для качественно описанных, низкорисковых и контролируемых сценариев.</p> <p>Критичные операции — платежи, изменение коммерческих условий, юридически значимые действия, доступ к чувствительным данным, массовые рассылки, изменение прав пользователей — должны оставаться под контролем человека.</p> <h3>Какие риски нужно учитывать</h3> <p>Риск ИИ-агента заключается в том, что неправильное действие может быть выполнено быстро, с доступом к реальным данным и системам.</p> <ul> <li><strong>Избыточные права.</strong> Если агенту дали доступ ко всем данным «на всякий случай», он может использовать ненужную для конкретной задачи информацию. Это повышает риски утечек, нарушений политики доступа и некорректного использования данных.</li> <li><strong> Избыточная автономность.</strong> Возможность агента выполнять действия без подтверждения требует от компании уверенности в стабильности сценария и отсутствии критичных последствий.</li> <li> <strong>Непрозрачность действий.</strong> Отсутствие информации об инициаторе действия, запросе, использовании данных и внесенных изменениях лишает компанию управляемости.</li> <li><strong> Ошибочная интерпретация задачи.</strong> ИИ-агент может неверно понять контекст, выбрать неподходящие данные, перепутать приоритет, не учесть исключение или выполнить формально правильное действие в неправильной ситуации.</li> <li> <strong>Размытая ответственность.</strong> Если агент ошибся, кто отвечает? Пользователь, который дал запрос? Владелец процесса? ИТ? Команда, которая настроила агента? Поставщик платформы? Эти вопросы важно решать до запуска, а не после инцидента.</li> </ul> <h3>Что должно быть в модели управления ИИ-агентами</h3> <p>Для промышленного применения ИИ-агентов необходима понятная управленческая модель.</p> <ul> <li><strong>Роль агента. </strong>У каждого агента должно быть назначение: какую задачу он решает, в каком процессе работает, кому помогает, какие действия выполняет и кто является владельцем сценария.</li> <li><strong>Ограничение прав. </strong>Агент должен иметь доступ только к тем данным и действиям, которые нужны для его роли, а не ко всей системе, документам и клиентам.</li> <li><strong>Перечень допустимых действий. </strong>Необходимо заранее определить и зафиксировать: что агент может делать сам, что — только подготовить, а что запрещено.</li> <li><strong>Подтверждение человеком для критичных операций</strong>. Если действие влияет на деньги, юридические обязательства, клиентов, права доступа, персональные данные или критичный процесс — агент готовит, человек утверждает.</li> <li><strong>Цифровой след. </strong>Компания должна видеть, кто инициировал действие, какой агент его выполнил, какие данные использовались, что было изменено, когда это произошло и кто подтвердил результат.</li> <li><strong>Мониторинг и возможность остановки. </strong>У агента должен быть владелец, а у компании — возможность быстро отключить сценарий, ограничить права, остановить автоматическое действие или пересмотреть правила.</li> <li><strong>Регулярная проверка. </strong>ИИ-сценарии не должны запускаться и забываться. Их необходимо пересматривать: меняются процессы, данные, системы, требования ИБ, регуляторика и поведение пользователей.</li> </ul> <h3>Почему это связано с low-code</h3> <p>Low-code и ИИ-агенты усиливают друг друга. Low-code дает среду для быстрого создания приложений, интерфейсов, рабочего процесса и интеграций. ИИ-агенты добавляют интеллектуальный слой: помогают принимать решения, готовить действия, обрабатывать данные и взаимодействовать с системами.</p> <p>Вместе они могут значительно ускорить корпоративные изменения, но при этом повышают требования к управлению. Если low-code без правил ведет к зоопарку приложений, то ИИ + low-code без правил — к зоопарку действий: автоматических, некачественно описанных, с разными правами, уровнем контроля и размытой ответственностью.</p> <p>ИИ-агенты должны быть встроены в ту же модель системы управления, что и low-code-контур: роли, права, архитектурные ограничения, ИБ, реестр, сопровождение, мониторинг и экономика.</p> <h3>Практический чек-лист перед запуском ИИ-агента</h3> <p>Перед запуском ИИ-агента в корпоративный процесс стоит ответить на вопросы:</p> <ol> <li> Какую конкретную задачу решает агент?</li> <li> Кто владелец процесса и агента?</li> <li> Какие данные агенту действительно нужны?</li> <li> Какие действия он может выполнять самостоятельно?</li> <li> Какие действия требуют подтверждения человеком?</li> <li> Какие действия агенту запрещены?</li> <li> Где фиксируется цифровой след?</li> <li> Как пользователь понимает, что действие выполнил агент?</li> <li> Кто разбирает ошибочные действия?</li> <li> Как агент отключается или ограничивается при инциденте?</li> <li> Как часто пересматриваются его права и сценарии?</li> <li> Как оценивается эффект: скорость, качество, снижение ручного труда, риски?</li> </ol> <p>Без ответов на эти вопросы запускать агента в промышленный процесс рано. Его можно тестировать, использовать в ограниченном контуре, проверять гипотезу, но не наделять полномочиями, влияющими на критичные операции.</p> <h3>Роль интегратора</h3> <p>В корпоративной среде внедрение ИИ-агентов — не только настройка модели или подключение инструмента к внутренней системе. Это проектирование управляемого цифрового участника процесса. Интегратор помогает определить применимые сценарии, описать роли и права агентов, встроить их в существующие процессы, связать с low-code-платформами, настроить контроль данных, журналирование, подтверждение человеком и сопровождение.</p> <p>Крупному бизнесу нужны не быстрые приложения и умные помощники, а управляемая система изменений, где каждый участник — человек, приложение или ИИ-агент — действует в обозначенных границах. Задача интегратора: помочь компании запустить безопасный, поддерживаемый и промышленно применимый ИИ + low-code сценарий.</p> <h3>Практический вывод</h3> <p>ИИ-агенты становятся частью корпоративных процессов, поэтому к ним следует относиться как к части операционной модели.</p> <p>Каждый агент должен иметь роль с четкими правами, права — с ограничениями, действия — с цифровым следом, критичные операции — с подтверждением человеком, а весь сценарий — с назначенным владельцем. Только в такой модели ИИ-агенты смогут предлагать бизнесу скорость без потери контроля.</p> <p>В корпоративной среде доверие к ИИ строится не на том, насколько убедительно он отвечает, а на том, насколько управляемо он действует.</p> <p>#IMAGE_235319#</p> ИИ-агенты становятся полноценными участниками рабочих процессов. Для бизнеса это естественное продолжение автоматизации: если … article Михаил Миронов, директор отделения low-code-решений группы компаний IBS https://www.itweek.ru/themes/detail.php?ID=235317 Mon, 10 Aug 2026 18:21:18 +0300 <p>Системный интегратор DCLogic и разработчик российской observability платформы GMONIT приступили к совместной интеграции платформ INFRABASE и GMONIT. Меморандум о технологическом и стратегическом партнерстве компании подписали на ежегодной конференции GMONIT Observability Day 2026.</p> <p>DCLogic развивает платформу INFRABASE для управления ИТ-инфраструктурой и автоматизации жизненного цикла виртуальных машин. GMONIT — одноименную observability платформу, обеспечивающую комплексную наблюдаемость цифрового контура. Интеграция позволит объединить данные о состоянии цифровых сервисов и ИТ-инфраструктуры с инструментами управления ресурсами, планирования вычислительных мощностей и FinOps.</p> <p>Двусторонний обмен данными между платформами объединит возможности GMONIT в области наблюдаемости цифрового контура и инструменты INFRABASE для управления ИТ-инфраструктурой. GMONIT будет предоставлять INFRABASE данные о работе приложений, инфраструктуры и цифровых сервисов для анализа загрузки ресурсов, прогнозирования потребности в вычислительных мощностях и подготовки рекомендаций по оптимизации инфраструктуры. В свою очередь, результаты анализа и рекомендации, сформированные в INFRABASE, смогут использоваться в GMONIT для дальнейшей оценки состояния цифровых сервисов и планирования развития ИТ-инфраструктуры.</p> <p>В настоящее время специалисты компаний ведут проектирование интеграции, разрабатывают архитектуру взаимодействия платформ, проводят нагрузочное тестирование и валидацию совместного решения. После завершения испытаний оно станет доступно для коммерческого внедрения.</p> <p>«Современные инструменты по наблюдаемости, учету и прогнозированию инфраструктуры должны не только показывать состояние информационных систем, но и помогать принимать решения по развитию инфраструктуры. Интеграция платформ INFRABASE и GMONIT позволит перейти от мониторинга к интеллектуальному управлению вычислительными ресурсами. Для заказчиков это означает более точное планирование мощностей, повышение эффективности использования инфраструктуры и снижение эксплуатационных затрат», — отметил генеральный директор DCLogic Евгений Шелестюк.</p> <p>«Сегодня observability выходит далеко за рамки мониторинга, превращая данные наблюдаемости в стратегический актив для принятия решений о развитии ИТ-инфраструктуры. Для многих ИТ-директоров одной из ключевых задач становится обоснованная оптимизация затрат на ИТ-инфраструктуру на основе объективных данных. Именно этому запросу отвечает совместный проект GMONIT и DCLogic, открывая новый сценарий использования данных наблюдаемости и превращая их из инструмента контроля в основу для управления инфраструктурой — от мониторинга и анализа до планирования ее развития. Именно в этом мы видим следующий этап развития observability: когда данные не просто показывают, что происходит в ИТ, а помогают определять, какой должна быть ИТ-инфраструктура завтра», — подчеркнул генеральный директор GMONIT Игорь Пустоветов.</p> <p>Совместный проект станет еще одним шагом в развитии отечественной экосистемы инфраструктурного программного обеспечения. Решение ориентировано прежде всего на крупные компании с распределенной или быстро растущей ИТ-инфраструктурой, которым необходимо одновременно обеспечивать стабильность цифровых сервисов, контролировать потребление ресурсов и планировать развитие вычислительных мощностей.</p> Системный интегратор DCLogic и разработчик российской observability платформы GMONIT приступили к совместной интеграции … message https://www.itweek.ru/themes/detail.php?ID=235316 Mon, 10 Aug 2026 18:19:31 +0300 <p>Компания BSS представила мажорное обновление 2.15 «Речевой аналитики». Ключевой вектор релиза — эволюция встроенного искусственного интеллекта из инструмента реактивной обработки запросов в полноценного проактивного ИИ-агента, способного самостоятельно управлять качеством клиентского сервиса.</p> <p>Главной инновацией версии 2.15 стала трансформация инсайт-режима в автономного Инсайт-агента. Теперь ИИ не требует постоянного участия пользователя: по заданному расписанию он самостоятельно анализирует коллекции записей, выявляет паттерны и аномалии, формирует инсайты и автоматически рассылает отчеты заинтересованным лицам, включая смежные подразделения, которые не являются прямыми пользователями системы. </p> <p>Внедрение технологии RAG (Retrieval-Augmented Generation) в автоматические оценочные карты позволяет бизнесу получать семантический контроль качества на основе корпоративных баз знаний или загруженных регламентов без необходимости сложной интеграции.</p> <p>Для подразделений контроля качества (КК) релиз принес существенное повышение эффективности. В модуле Контактного центра усовершенствован механизм семплинга: теперь в одной задаче можно зафиксировать множественные условия отбора за разные периоды, что оптимизирует время при работе в системе. Внедрен интерактивный виджет «Дерево маркеров» для наглядной визуализации тематик и подтематик с возможностью глубокой фильтрации, а также новый отчет «Распределение оценок» для трекинга нагрузки контролеров. Для экономии времени сотрудников контроля качества добавлены «Справочники» — предустановленные варианты обратной связи и тематизации.</p> <p>Значительные обновления получил Агент-Тренер. ИИ-собеседник теперь поддерживает выбор языка общения, а система оценивания стала многоуровневой (включая критические цели, мгновенно прекращающие симуляцию). Важнейшее нововведение — ИИ начал предоставлять подробное обоснование для каждой цели: почему она зачтена, не зачтена или выполнена частично. Результаты обучения теперь агрегируются в новом «Дашборде ученика».</p> <p>Зрелость платформы также подчеркивает масштабный UX/UI-рефакторинг: внедрен современный компонент с расширенной фильтрацией во всех списках, адаптивный виджет со статистикой диалогов, улучшен Конструктор отчетов и реализована транскрибация аудио-сообщений в текстовых чатах.</p> <p>«В версии 2.15 мы фактически стерли грань между аналитическим инструментом и цифровым сотрудником. Объединив обновленный инсайт-режим и возможность автономной работы, мы вывели на рынок полноценного ИИ-агента. Он не просто ждет запроса от аналитика, а самостоятельно мониторит массивы коммуникаций, находит скрытые взаимосвязи и проактивно доставляет инсайты бизнесу. Наша цель — дать компаниям технологию, которая работает на опережение, беря на себя рутину и позволяя людям фокусироваться на принятии стратегических решений», — прокомментировала Анна Ивлева, владелец продукта «Речевая Аналитика» департамента голосовых цифровых технологий компании BSS.</p> <p>Выход релиза 2.15 подтверждает экспертизу BSS как одного из безусловных лидеров отечественного рынка в области разработки и внедрения речевых технологий и искусственного интеллекта. Многогранный опыт компании в сфере цифровизации клиентского сервиса позволяет BSS предлагать рынку <nobr>CX-платформу</nobr> нового уровня для интеллектуального управления клиентским опытом. Она объединяет данные, инструменты автоматизации и аналитику для персонализированного и предиктивного сервиса, повышения эффективности и доходности бизнеса.</p> Компания BSS представила мажорное обновление 2.15 «Речевой аналитики». Ключевой вектор релиза — эволюция встроенного … message https://www.itweek.ru/themes/detail.php?ID=235315 Mon, 10 Aug 2026 13:01:08 +0300 <p>Российский разработчик АО «СБК» выпустил продуктовый релиз платформы унифицированных коммуникаций CommuniGate Pro 6.5.6. Новая версия существенно расширяет возможности веб-интерфейса, улучшает MAPI-коннектор для корпоративных пользователей Windows и продолжает работу по повышению стабильности календарей.</p> <p>Веб-интерфейс получил ряд новых функций, ориентированных на повседневные задачи пользователей. Теперь пользователи могут создавать календарное событие непосредственно из письма, что ускоряет планирование. При добавлении адресатов в письмо или событие система автоматически подтягивает контакты, в том числе из внешних справочников. Релиз включает полноценную функцию предоставления доступа к календарю, включая публичный доступ по уникальной ссылке. Пользователи могут изменять язык интерфейса, настраивать уведомления о доставке и прочтении писем, а также создавать собственные почтовые правила для автоматической обработки входящих сообщений. Интерфейс позволяет изменять ширину сайдбара, а при наведении на папку система отображает ее полное имя и размер. Релиз добавляет на страницу авторизации QR-код и ссылку для TOTP, что упрощает первичную настройку двухфакторной аутентификации (2FA).</p> <p>Для администраторов и ИТ-специалистов релиз 6.5.6 значительно дорабатывает MAPI-коннектор. Разработчики подготовили MSI-инсталлятор для <nobr>64-разрядных</nobr> версий Windows, что позволяет устанавливать коннектор централизованно через групповые политики сразу для всех пользователей. Также пользователи могут отзывать отправленные сообщения, а платформа группирует письма в беседы, упрощая работу с перепиской.</p> <p>В бэкенд-части команда разработчиков продолжила улучшать работу с календарями и сериями повторяющихся событий, начатую в предыдущем релизе.</p> <p>«Новый релиз CommuniGate Pro 6.5.6 делает платформу еще более удобной и гибкой для конечных пользователей и администраторов. Мы расширили функциональность веб-интерфейса, упростили интеграцию с внешними справочниками и добавили важные инструменты для централизованного управления, такие как MSI-установка MAPI-коннектора. Продолжая работу над стабильностью календарей, мы следуем запросам наших клиентов и укрепляем позиции CommuniGate Pro как надежного решения для корпоративной коммуникации», — прокомментировал Борис Моисеев, директор департамента разработки CommuniGate Pro.</p> <p>Пользователи уже могут скачать обновление CommuniGate Pro 6.5.6 на официальном сайте компании.</p> Российский разработчик АО «СБК» выпустил продуктовый релиз платформы унифицированных коммуникаций CommuniGate … message https://www.itweek.ru/themes/detail.php?ID=235313 Mon, 10 Aug 2026 11:32:06 +0300 <p><em>Системы безопасности все чаще объединяются в единую информационную среду, где данные от видеонаблюдения, СКУД, инженерных и корпоративных ИТ-систем используются для анализа и автоматического реагирования. Разбираемся, как меняется подход к безопасности предприятий и какую роль в этом играет искусственный интеллект.</em></p> <p>Сегодня под конвергенцией систем безопасности обычно понимают объединение ранее обособленных сегментов безопасности, физической и информационной, в единую систему. Она обеспечивает сбор разнообразных данных, их аналитику и структурирование, автоматизированное реагирование на инциденты и управление инженерным оборудованием.</p> <p>Если раньше различные инженерные системы работали автономно, за некоторыми исключениями, которые предписывались сводами правил, то сегодня все чаще данные с них сводятся в единую информационную систему. Причем не просто для фиксации состояния или регистрации инцидентов. Речь идет о комплексном мониторинге, аналитике и управлении оборудованием по различным сценариям и алгоритмам. Делать это можно как при помощи диспетчера, так и полностью автоматически.</p> <p>Причин, которые привели к объединению систем, несколько. Основная, пожалуй, это бурное развитие информационных технологий и систем искусственного интеллекта. Причем дело не только в том, что объект защиты получил возможность внедрять более интеллектуальные системы. Злоумышленники тоже получили доступ к новым технологиям, и угрозы становятся все более изощренными. Защищаться теперь все больше нужно не от «головореза» с топором, а от «очкарика» с ноутбуком. Он будет не штурмовать турникет, а способен воздействовать комплексно: открыть турникет, отключить камеры видеонаблюдения, запустить пожарную тревогу или даже обесточить здание целиком.</p> <p>Есть и другая важная причина, экономическая. Эффективно налаженная система комплексной безопасности позволяет снизить расходы на содержание персонала, обслуживание разнородных систем и дублирование различных функций. Но экономия не ограничивается эксплуатационными затратами. Такая система в целом снижает вероятность инцидентов, которые могут привести к значительному ущербу, поскольку позволяет вовремя реагировать на проблему и устранять причины ее возникновения.</p> <p>Здесь большую роль сыграла видеоаналитика на базе искусственного интеллекта. Она стала одним из ключевых факторов, которые позволили превратить системы простой фиксации событий в инструмент предотвращения противоправных действий в режиме реального времени. Раньше данные можно было поднять и проанализировать уже после того, как инцидент произошел. Теперь система способна сразу распознать определенное событие и запустить необходимый механизм реагирования.</p> <p>Хороший пример связан с несанкционированным доступом на защищаемый объект. Раньше можно было передать карту доступа другому человеку или провести по одной карте двух людей. Теперь «пропуском» служат уникальные биометрические характеристики лица человека, а нарушение установленного алгоритма прохода система способна сразу зафиксировать и предотвратить.</p> <h3>Безопасность становится частью корпоративной ИТ-среды</h3> <p>Интеграция систем физической и информационной безопасности сегодня становится одним из ключевых направлений цифровой трансформации предприятий. Физические системы безопасности при этом можно интегрировать практически с любой информационной системой предприятия, если учитывать его специфику и конкретные задачи.</p> <p>Например, связка с HRM и ERP позволяет настроить доступ сотрудника только в те помещения, которые ему положено посещать в силу его должностных обязанностей и графика работы. Одновременно можно закрыть доступ в помещения, которые с его деятельностью никак не связаны. Если сотрудника переводят на другую должность, его права доступа могут измениться автоматически.</p> <p>Интеграция может работать и на производственные задачи. Можно автоматически подтверждать завершение цикла какой-то производственной операции, чтобы запустить следующую, или фиксировать этапы перемещения сырья и готовой продукции.</p> <p>А связка с CRM дает возможность гораздо глубже понимать предпочтения клиентов и одновременно заранее предупреждать персонал о появлении конкретного человека, выводя на экран всю историю взаимодействия. К примеру, клиент вашего отдела только появился на пороге торгового центра, а у менеджера, который работает третий день и этого клиента никогда в глаза не видел, на планшете уже появились все данные о предпочтениях, размерах, последних покупках и даже кличке любимой собачки.</p> <p>В результате система безопасности перестает быть отдельным контуром и становится частью общей информационной среды предприятия. Но сам по себе факт объединения систем еще ничего не дает. Важнее то, какие практические задачи это объединение позволяет решать.</p> <h3>От единого интерфейса к автоматическому реагированию</h3> <p>Наибольший эффект от объединения видеоаналитики, СКУД и корпоративных ИТ-систем достигается тогда, когда данные от разных источников не просто собираются в одном программном интерфейсе. Гораздо важнее, чтобы система анализировала их в реальном времени и на основании этой аналитики сама принимала решения о реагировании в соответствии с заранее прописанными сценариями и алгоритмами.</p> <p>При определенных сценариях это позволяет, например, свести к минимуму процент брака на производстве. Часть контроля можно переложить на видеоаналитику, исключив человеческий фактор там, где он становится источником ошибок. То же самое касается техники безопасности. Если система мгновенно фиксирует нарушение и сразу принимает меры к его устранению, вероятность несчастного случая можно существенно снизить.</p> <p>Конкретный набор сценариев и алгоритмов реагирования при этом должен разрабатываться для каждого предприятия отдельно, с учетом специфики его производства. То, что эффективно работает на одном объекте, совершенно не обязательно подойдет другому.</p> <h3>Что мешает объединению систем</h3> <p>Интеграция систем безопасности разных производителей может значительно повысить эффективность управления безопасностью объекта. Но чем больше различных подсистем объединяется в единую макросистему, тем выше требования к их взаимной координации и тем больше потенциальных проблем приходится решать.</p> <p>Одна из них связана с протоколами взаимодействия. Открытые протоколы существуют и поддерживаются многими производителями, но зачастую весь необходимый функционал реализован именно через проприетарные протоколы. На открытые стандарты при этом приходится лишь небольшая часть возможностей системы. Еще одна проблема связана с форматами данных. Разные подсистемы могут использовать разные форматы, поэтому для их унификации приходится дополнительно прописывать механизмы распознавания и обмена. Есть и менее очевидный, но не менее важный барьер. Он возникает уже внутри самого предприятия, между разными подразделениями. У них часто разные цели и задачи, а решать их они привыкли совершенно разными инструментами.</p> <p>Поэтому для успешной реализации интеграционных процессов разумно внедрить надструктуру, которая адаптировала бы процессы отдельных подразделений под глобальные цели предприятия. Иначе технически объединить системы можно, но полноценной конвергенции на уровне организации не произойдет.</p> <h3>Что ждет системы безопасности в ближайшие годы</h3> <p>В ближайшие <nobr>3-5 лет,</nobr> на мой взгляд, конвергенция систем безопасности перейдет от интеграции отдельных подсистем к формированию единой интеллектуальной системы комплексного управления безопасностью. Она будет объединять инженерные системы, системы физической безопасности и информационные системы предприятия.</p> <p>Роль искусственного интеллекта при этом тоже изменится. Он перестанет быть дополнительным инструментом, который помогает разобраться в уже произошедшем инциденте. ИИ станет основным актором, способным не только анализировать массив данных, но и в режиме реального времени вырабатывать команды периферийным системам. Это позволит предотвращать инциденты или как минимум снижать их негативные последствия. Кроме того, ИИ сможет обрабатывать огромный массив данных, готовить аналитику и формировать рекомендации для обслуживающего персонала. На основании этих рекомендаций можно будет адаптировать бизнес-процессы и внутренние регламенты предприятия, чтобы не допускать ситуаций, способных спровоцировать инцидент.</p> <p>В целом системы безопасности будут развиваться в сторону интеллектуализации и принятия решений на основе глубокого изучения данных. Искусственный интеллект станет связующим звеном между видеонаблюдением, СКУД, инженерными системами, информационными системами предприятия и единым диспетчерским персоналом. Это позволит реагировать на события практически мгновенно, причем как совместно с ИИ, так и автономно от него.</p> <p>При этом в ближайшие годы ИИ все-таки останется прежде всего мощнейшим инструментом для сбора и анализа огромного массива данных по заданным критериям. Ключевым фактором остается компетенция персонала. Именно люди на основе полученной аналитики формируют сценарии и алгоритмы взаимодействия различных подсистем и системы в целом. Поэтому конвергенция систем безопасности не сводится к тому, чтобы соединить видеонаблюдение, СКУД, инженерные и информационные системы в одной точке. В конечном счете речь идет о создании среды, в которой данные от разных систем помогают не только увидеть уже произошедшее, но и вовремя распознать потенциально опасную ситуацию, принять решение и предотвратить инцидент.</p> <p>#IMAGE_235314#</p> Системы безопасности все чаще объединяются в единую информационную среду, где данные от видеонаблюдения, СКУД … article Михаил Шестаков, эксперт в области систем безопасности, противопожарной защиты, связи и видеоаналитики https://www.itweek.ru/themes/detail.php?ID=235311 Mon, 10 Aug 2026 08:40:13 +0300 <p><em>В условиях, когда искусственный интеллект переходит от экспериментов к внедрению в масштабах предприятий, вопросы суверенитета теперь затрагивают каждый уровень стека ИИ, пишет в корпоративном блоге Дарио Маисто, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Организации больше не оценивают ИИ, основываясь исключительно на производительности моделей, скорости инноваций или стоимости. Они все чаще задаются вопросом, могут ли они контролировать то, как системы ИИ создаются, управляются, эксплуатируются и развиваются. Этот сдвиг превращает суверенный ИИ из нишевой проблемы в основное требование бизнеса. Организации, которые не решают проблемы суверенитета, могут столкнуться с регуляторными барьерами, чрезмерной зависимостью от поставщиков или ограничениями на будущие инновации.</p> <h3>Главные темы нового исследования Forrester</h3> <p>Вот наиболее важные выводы из нового отчета Forrester «The Top 10 Trends In Sovereign AI, 2026» о главных тенденциях в области суверенного ИИ:</p> <ul> <li><strong> Суверенитет стал критерием покупки.</strong> Во всех отраслях аспект суверенитета все чаще переходит из обсуждения вопросов комплаенса в требование к закупкам. Организации, запускающие новые инициативы в области ИИ, определяют требования к суверенитету с самого начала, а не рассматривают их как второстепенный вопрос. Это включает в себя такие аспекты, как владение данными, защита интеллектуальной собственности, оперативный контроль и юрисдикционные риски. В разговорах с технологическими лидерами выявляется общая тема: многие организации не хотят повторять раннюю модель внедрения облачных технологий, при которой гибкость и контроль обменивались на зависимость от внешних поставщиков. Суверенитет стал способом сохранения стратегических возможностей в условиях неопределенной геополитической обстановки.</li> <li><strong> Суверенитет данных — это только начало.</strong> Одно из самых больших заблуждений относительно суверенного ИИ заключается в том, что его можно обеспечить, просто храня данные в конкретной стране. Организации обнаруживают, что истинный суверенитет простирается далеко за пределы местоположения данных. Вопросы о том, кто управляет ключами шифрования, кто имеет оперативный доступ, где обучаются модели и какие правовые юрисдикции применяются, становятся одинаково важными. Оперативный контроль, управление и безопасность теперь являются фундаментальными компонентами стратегий суверенитета. Это особенно важно, поскольку требования к суверенному ИИ значительно различаются в зависимости от региона. Универсального подхода не существует. Организации должны разрабатывать архитектуры, учитывающие местные правила, геополитические реалии и зрелость экосистемы, одновременно поддерживая глобальные бизнес-операции.</li> <li><strong> Контроль важнее изоляции.</strong> Многие организации изначально рассматривали суверенитет через призму локализации и самодостаточности. Однако этот подход меняется. Технологические лидеры все чаще признают, что полная изоляция может ограничивать инновации, увеличивать затраты и снижать доступ к новым возможностям. Вместо этого они стремятся к архитектурам, которые максимизируют контроль, сохраняя при этом гибкость и свободу выбора. Это объясняет растущий интерес к моделям с открытым исходным кодом и открытыми весами, а также к архитектурным подходам, которые разделяют управление и исполнение. Организации хотят иметь возможность выбирать, где будут выполняться рабочие нагрузки, какие модели они будут использовать и как они будут интегрировать ИИ в бизнес-процессы, не создавая ненужных зависимостей. Суверенитет все меньше связан с ограничением возможностей и все больше с их сохранением.</li> </ul> <h3>Четыре новых поля битвы за суверенитет</h3> <p>Некоторые события меняют ландшафт суверенного ИИ:</p> <ul> <li><strong> Организации требуют систем ИИ, которые отражают местные языки, культуры и правила.</strong> Это стимулирует инвестиции в региональные модели, локализованную тонкую настройку и экосистемы ИИ, специфичные для каждой страны.</li> <li><strong> Безопасность становится критически важным фактором дифференциации.</strong> Одного лишь юрисдикционного контроля уже недостаточно. Покупатели все чаще тщательно изучают уровень зрелости безопасности, отказоустойчивость, экосистему интеграции и возможности реагирования на инциденты у поставщиков суверенного ИИ.</li> <li><strong> Происходит конвергенция дизайна инфраструктуры вокруг общих операционных уровней.</strong> Kubernetes быстро становится платформой оркестрации и обеспечения соблюдения политик для сред ИИ, помогая организациям стандартизировать операции при сохранении контроля.</li> <li><strong> Доступность энергии становится вопросом суверенитета.</strong> Доступ к электроэнергии, мощность электросети и инфраструктура центров обработки данных все чаще определяет, где организации могут реально развертывать и масштабировать суверенные ИИ-сервисы.</li> </ul> <h3>Вопрос о суверенном ИИ не в том, будет ли он, а в том, каким он будет</h3> <p>Дебаты о суверенном ИИ часто рассматриваются как обсуждение выбора между глобальными инновациями и локальным контролем. Наиболее успешные организации будут стремиться к балансу между ними. Технологическая изоляция не является целью. Цель заключается в создании архитектур ИИ, которые являются отказоустойчивыми, адаптируемыми и соответствуют бизнес-, регуляторным и геополитическим реалиям. По мере того, как ИИ становится ключевой бизнес-возможностью, один вопрос становится все труднее обойти: сколько контроля вы готовы отдать? Организации, которые смогут ответить на этот вопрос сегодня, будут лучше подготовлены к преодолению завтрашних изменений в законодательстве, конкурентного давления и геополитической неопределенности.</p> В условиях, когда искусственный интеллект переходит от экспериментов к внедрению в масштабах предприятий … article https://www.itweek.ru/themes/detail.php?ID=235310 Fri, 07 Aug 2026 13:32:20 +0300 <p>В совместном исследовании DDoS-Guard и FirstVDS проанализировали более 7,5 млн атак за три года, провели опрос более 200 владельцев бизнеса и выявили новые тренды: смещение фокуса злоумышленников на игровую индустрию (+310%) и рост распределенности атак на 480%.</p> <p>«Раньше DDoS требовал ресурсов и подготовки — сегодня он покупается как сервис: достаточно указать адрес, остальное делает автоматика. Порог входа почти нулевой. Отсюда и смещение рисков. — считает директор по продукту FirstVDS, Никита Попов. — Под ударом те, у кого простой мгновенно конвертируется в деньги, — игровые сервисы традиционно, интернет-магазины, SaaS-платформы. И отдельно те, где атака работает как инструмент давления: госсектор, телеком, финансы. Пока на стороне атакующего автоматизация и DDoS как услуга, а на стороне бизнеса — сутки простоя и разбирательства с клиентами, спорить о целесообразности защиты бессмысленно. Считать надо не вероятность атаки, а стоимость часа недоступности. У большинства проектов эта цифра выше, чем стоимость годовой защиты».</p> <p>«Мы видим несколько устойчивых трендов: растет распределенность вредоносного трафика, все чаще применяется тактика Pulse Wave, которая дезориентирует автоматические системы защиты. Злоумышленники круглосуточно сканируют интернет в поисках свежих адресов — это делает новые проекты особенно уязвимыми в первые месяцы после запуска. В таких условиях классические фаерволы и геоблокировки малоэффективны, требуется фильтрация L7-трафика с поведенческим анализом», — отметил Казбек Мамакаев, тимлид команды разработки защиты на уровне веб-приложений DDoS-Guard.</p> <p>Основные факты:</p> <ul> <li>игровые сервисы — лидеры по приросту числа атак: за год показатель вырос на 310%. В топе также госсектор (+249,6%), телеком (+80,8%) и финансовый сектор (+45,4%);</li> <li>40% атак приходятся на первые два месяца после запуска сервера — новый проект автоматически становится целью для ботнетов;</li> <li>каждая третья атака длится более суток. Раньше DDoS считался краткосрочным ударом, теперь это затяжной прессинг;</li> <li>за два года число уникальных IP-адресов в одной атаке выросло с 353 тыс. до более чем 2 млн, а в первом квартале 2026 года зафиксирована атака с 3,1 млн источников;</li> <li>атаки приводят к критичным последствиям — почти половина опрошенных (48,62%) пережили полные простои сервисов. 44,6% считают, что риск DDoS-атак для их отрасли вырос;</li> <li>основные источники атак — Россия, США, страны Латинской Америки и Юго-Восточной Азии. В 2026 году к списку добавился Бангладеш.</li> </ul> В совместном исследовании DDoS-Guard и FirstVDS проанализировали более 7,5 млн атак за три года, провели опрос … message https://www.itweek.ru/themes/detail.php?ID=235308 Fri, 07 Aug 2026 09:48:56 +0300 <p>Менять подрядчика у работающей веб-системы — не то же самое, что передавать новый проект. Пока команды разбираются с кодом и доступами, через систему продолжают идти заказы, заявки, платежи и документы. Поставить её на паузу на неделю, чтобы новая команда освоилась, бизнес не может.</p> <p>Код при этом можно передать за день. Настоящие проблемы обнаруживаются позже: во время первого сбоя, срочной доработки, продления сертификата или восстановления базы данных. Если без прежнего подрядчика новая команда не может собрать релиз, найти причину ошибки и вернуть систему в рабочее состояние, передача существует только на бумаге.</p> <h3>Начинать нужно с критичных процессов</h3> <p>В одной веб-системе могут одновременно работать оформление заказов, личный кабинет, внутренние справочники и отчётность. Но последствия сбоя у них разные. Если перестали оформляться заказы, компания сразу теряет выручку. Обновление внутреннего отчёта во многих случаях может подождать несколько часов или дней.</p> <p>Поэтому до передачи определяют, какие пользовательские действия нельзя останавливать и какие модули, интеграции, фоновые задания и внешние сервисы обеспечивают их работу. Заодно договариваются, сколько может продлиться простой и какой объём данных допустимо потерять. В ИТ-документации эти ограничения обычно обозначают как RTO (время восстановления) и RPO (допустимый период потери данных).</p> <p>Назначать одно значение для всей системы не верно. Заказы, платежи и уведомления могут требовать восстановления за минуты, а внутренняя статистика — за часы. Такая расстановка приоритетов особенно важна в первые недели: при сбое новая команда сразу понимает, какой процесс возвращать в работу первым.</p> <h3>Как выбрать сценарий передачи</h3> <ul> <li><strong>Параллельная работа команд</strong> — самый надёжный вариант для критичной системы. На первом этапе новая команда наблюдает, как выпускаются обновления и разбираются инциденты, затем делает это сама под контролем прежней. Здесь важно заранее разделить ответственность. У каждого релиза и инцидента должен быть один владелец, иначе обе команды будут ждать действий друг от друга.</li> <li><strong>Поэтапная передача</strong> подходит, если систему можно разделить на относительно самостоятельные части. Например, сначала передать личный кабинет, затем интеграционный модуль и административную панель. Вместе с каждым модулем передают его зависимости, мониторинг и порядок поддержки. Один только код не поможет, если новая команда не видит, как модуль обменивается данными с соседними системами.</li> <li><strong>Экстренный переход</strong> приходится проводить, когда прежний подрядчик недоступен или есть риск потерять контроль над инфраструктурой. В этом случае сначала получают административные доступы, фиксируют текущее состояние системы, подключают мониторинг и проверяют резервные копии. Новые функции временно отходят на второй план: главная задача — вернуть систему под контроль.</li> </ul> <p>Если в этот момент уже произошёл сбой, порядок ещё жёстче: сначала тушат пожар — локализуют проблему, восстанавливают критичный процесс и ограничивают ущерб. Полное обследование архитектуры и разбор причин проводят после стабилизации. Иначе время, потраченное на изучение системы, превращается в прямой убыток для заказчика.</p> <p>При любом сценарии нужен отдельный план перехода. Дата окончания договора сама по себе ничего не говорит о готовности новой команды.</p> <h3>Вернуть заказчику контроль над системой</h3> <p>Самые неприятные сюрпризы часто находятся не в репозитории. Домен может быть зарегистрирован на сотрудника подрядчика, уведомления об ошибках — приходить только в его мессенджер, а сборка приложения — зависеть от файла на ноутбуке конкретного разработчика. Формально код уже у заказчика, но управлять системой без прежней команды он всё ещё не может.</p> <p>Чтобы увидеть такие зависимости, составляют общий список ресурсов, от которых зависит система. В него входят репозитории, серверы и облачные аккаунты, домены и настройки DNS, базы данных, хранилища, сертификаты, лицензии, почтовые и СМС-сервисы. Для каждого ресурса указывают владельца, администраторов, способ восстановления доступа и срок оплаты или действия сертификата. Это может быть обычная таблица — сложная система учёта здесь не нужна.</p> <p>Отдельно проверяют технические доступы: SSH-ключи, токены системы автоматической сборки и развёртывания (CI/CD), API-ключи и доступы к внешним сервисам. Новой команде выдают собственные права и проверяют, что они работают. Только после этого доступы прежнего подрядчика отзывают, а известные ему пароли, токены и ключи заменяют. Обратный порядок опасен: можно остановить интеграцию или лишиться единственного рабочего способа развернуть приложение.</p> <p>Сам по себе список доступов ещё ничего не гарантирует. Новая команда должна собрать приложение в чистом окружении, развернуть тестовую версию, выпустить небольшое обновление и при необходимости вернуться к предыдущей версии. Такая проверка быстро находит то, чего нет в инструкциях: локальные файлы, закрытые библиотеки, ручные операции и пропущенные настройки.</p> <p>То же относится к мониторингу и резервным копиям. Оповещения должны приходить новой команде. И команда должна уметь в них видеть не только техническую ошибку, но и её последствие: перестали создаваться заказы, не формируются документы, не обновляются статусы доставки. Резервной копии тоже нельзя доверять, пока данные из неё не восстановили в отдельной среде и не проверили. Заодно становится понятно реальное время восстановления, а не цифра из регламента.</p> <h3>Документацию нужно проверять в работе</h3> <p>Схема архитектуры и подробная инструкция полезны, но сами по себе ничего не доказывают. Документ может быть устаревшим, а важная операция — держаться на памяти одного специалиста. Поэтому знания передают через конкретные действия: новая команда пытается совершить действие и в случае проблем обращается к предыдущей.</p> <p>Минимальная практическая проверка — разобраться со сбоем интеграции по логам, выпустить небольшое изменение, выполнить откат и восстановить данные из резервной копии. После каждого действия корректируют рабочую инструкцию: где начинать диагностику, какие показатели смотреть, кому сообщать о проблеме и когда принимать решение об откате.</p> <p>Если прежний подрядчик в передаче не участвует, устройство системы приходится восстанавливать по истории изменений и задач, настройкам CI/CD, тестам, логам и прошлым инцидентам. До принятия обычных обязательств по поддержке новая команда проводит обследование и честно фиксирует, за что уже может отвечать, а где пока остаются неизвестные зависимости.</p> <p>Но речь идёт о плановом переходе. Если критичная ситуация уже случилась, нельзя откладывать восстановление до момента полного понимания устройства системы. Сначала решают проблему, фиксирую предпринятые для восстановления шаги. Причину сбоя и устройство затронутых компонентов подробно разбирают уже после того, как ситуация перестала приносить бизнесу убытки.</p> <h3>Первый релиз новой команды</h3> <p>После обследования почти всегда появляется длинный список накопившихся проблем: устаревшие зависимости, ручные операции, нехватка тестов, пробелы в документации. Возникает желание сразу всё исправить. Для переходного периода это плохая стратегия: чем больше изменений вносится одновременно, тем труднее понять причину нового сбоя.</p> <p>Сначала устраняют то, что угрожает данным и непрерывности работы: активные уязвимости, отсутствие резервного копирования, невозможность собрать или развернуть систему, отсутствие мониторинга и рабочего плана отката. Рефакторинг и архитектурные улучшения можно запланировать после стабилизации.</p> <p>Первый релиз лучше сделать небольшим, но полноценным. Команда меняет код, проводит тестирование, выпускает обновление, проверяет его в рабочей среде и при необходимости откатывает. При этом задача не должна быть крупной, чтобы возможная ошибка не повлияла на работу всей системы.</p> <h3>Где переход чаще всего срывается</h3> <p>Чаще всего проблемы возникают из-за спешки. Договор с прежней командой уже завершён, а новая ещё не успела проверить, как система ведёт себя в работе. На переходном этапе новой команде не стоит сразу перестраивать систему и обещать прежний уровень поддержки. Крупные изменения усложнят поиск причин возможных сбоев, а гарантировать прежний уровень сервиса можно только после проверки всех процессов.</p> <p>Поэтому передачу ответственности лучше отделить от больших изменений и предусмотреть время на стабилизацию. Это не означает, что развитие системы нужно полностью остановить. На переходном этапе можно выпускать небольшие изменения. Но крупные доработки, перестройку архитектуры и обновление ключевых компонентов лучше отложить. Если после них возникнет сбой, новой команде будет сложнее понять, связан он со старой проблемой или с внесёнными изменениями.</p> <p>Нередко проблемы случаются из-за отсутствия плана и четкой фиксации детальных фактов передачи. Здесь новая команда может говорить, что она уже все приняла и эксплуатирует, а на деле оказывается, что некоторые компоненты системы не были должным образом приняты: артефакты по ним не были получены, детали не были уточнены и выяснены. Бизнес может не понимать, что для стабильной работы системы и снижения рисков требуется потратить достаточно времени и уделить достаточно внимания процессу передачи. Желание бизнеса поскорее поставить точку может обернуться спешкой на уровне технической эксплуатации и невнимательностью, что в итоге создает риски.</p> <h3>Когда переход действительно завершён</h3> <p>Окончание договора и фактическая передача системы редко совпадают день в день. Для критичной системы ориентироваться лучше не на дату в календаре, а на несколько проверяемых признаков:</p> <ul> <li> компания контролирует код, инфраструктуру, домены, данные и внешние сервисы;</li> <li> новая команда получает оповещения и может самостоятельно найти причину сбоя;</li> <li> проверены сборка, выпуск обновления и откат;</li> <li> данные успешно восстановлены из резервной копии, а время восстановления измерено;</li> <li> критичные пользовательские сценарии и интеграции работают;</li> <li> известные риски, временные ограничения и ответственные за них зафиксированы.</li> </ul> <p>Если для диагностики, релиза или восстановления по-прежнему нужен специалист прежнего подрядчика, переход ещё не закончен. Подписанный акт этого не меняет.</p> <p>Передача заканчивается не в момент получения архива с кодом и документацией. Она заканчивается тогда, когда новая команда может самостоятельно поддерживать систему, а бизнес больше не зависит от знаний, доступов и решений прежнего подрядчика.</p> <p>#IMAGE_235309#</p> Менять подрядчика у работающей веб-системы — не то же самое, что передавать новый проект. Пока команды … article Надежда Кадырлеева, исполнительный директор DIGITAL SECTOR https://www.itweek.ru/themes/detail.php?ID=235286 Fri, 07 Aug 2026 00:00:00 +0300 <p><em>Сейчас в каждой отраслевой дискуссии об искусственном интеллекте, кажется, повторяется одно и то же предупреждение: ИИ будет выполнять бóльшую часть рутинной работы, доходы от услуг сократятся, а бизнес-модели, основанные на численности персонала, должны измениться, чтобы оставаться конкурентоспособными, пишут в корпоративном блоге Шилпи Ханда, заместитель директора IDC по исследованиям (регион META), и Шари Лава, вице-президент группы IDC по ИИ, данным и автоматизации.</em></p> <p>Это предупреждение не ошибочно. Но это лишь половина истории. Оно описывает только то, что ИИ может отнять у рынка по мере трансформации бизнеса. Почти никто не говорит о том, что ИИ создает одновременно: большой, устойчивый, пока невостребованный спрос на специфическую функцию проверки правильности выполнения работы ИИ.</p> <p>Существует исследование <nobr>40-летней</nobr> давности из области, не имеющей ничего общего с ПО, которое точно предсказало то, что происходит сейчас. В 1983 г. когнитивный психолог Лизанн Бейнбридж опубликовала короткую статью под названием «Ирония автоматизации», основанную на многолетнем изучении диспетчерских пунктов промышленных процессов. Ее вывод был таков: чем более комплексно вы автоматизируете систему, тем более, а не менее, востребованной становится роль человека. Почему? Потому что людям приходится выполнять именно те задачи, которые никто не смог автоматизировать, плюс совершенно новую работу, к которой их никто не готовил: контролировать систему, сбои в которой они больше не видят достаточно часто, чтобы их распознавать. Навыки, которые остаются без практики, ухудшаются. Опытный оператор, который проводит свои дни, наблюдая за работой автоматизации, вместо того, чтобы выполнять работу самому, незаметно превращается в неопытного оператора, даже не замечая этого перехода. Автоматизация же обычно работает правильно до того дня, когда перестает работать.</p> <p>Авиационная отрасль продемонстрировала реальную значимость этой идеи. В 1987 г. самолет Northwest Airlines разбился при взлете из Детройта, погибли 154 из 155 человек на борту. Экипаж привык к автоматизированной системе, которая проверяла правильность настройки закрылков и предкрылков для взлета. В тот день автоматическая проверка была отключена из-за сработавшего выключателя. Экипаж, привыкший к тому, что машина обнаруживает эту ошибку, не стал проверять её вручную. Самолёт пытался взлететь без настройки и не смог. В тот день ничего необычного не произошло: просто ординарная, очень человеческая ошибка — нежелание провести проверку, которую автоматизация незаметно сделала ненужной.</p> <p>Это закономерность. И она снова проявляется прямо сейчас во всех областях, где широко используются ИИ-помощники, и люди уже сталкиваются с этим. Молодые юристы перекладывают на ИИ юридические исследования и первые черновики — именно те упражнения, которые раньше формировали способность к юридическому суждению, — и фирмы открыто обеспокоены тем, что их новые сотрудники вообще не развивают способность оценивать результаты работы ИИ.</p> <p>Несколько отраслевых исследований 2026 г. в области разработки ПО указывают на аналогичную проблему: младшие разработчики, не имеющие базовых знаний в области архитектуры и безопасности, не могут надёжно судить о качестве кода, написанного ИИ, и по умолчанию доверяют ИИ больше, чем своим собственным инстинктам, которые так и не развились. На отраслевых мероприятиях по безопасности об этом было сказано более прямо: начинающие инженеры, выросшие на программировании с использованием ИИ, все чаще испытывают недостаток базовых знаний в области сетей и протоколов, до такой степени, что командам трудно даже объяснить внутреннюю угрозу безопасности, не говоря уже о ее выявлении.</p> <p>Итак, вопрос, который задают люди, но на который очень немногие дают ответ: да, рутинные, повторяющиеся задачи будут автоматизированы, эта часть истории верна и не вызывает сомнений, но у кого будут навыки проверки того, что сгенерировал ИИ? Кто сможет, взглянув на результат работы автономной системы, понять, правилен ли он, опираясь на реальный практический опыт? И когда что-то пойдет не так, когда ИИ нужно будет остановить, исправить или перезапустить посреди задачи, у кого еще останется мышечная память для этого? Все стремятся создать автоматизацию. А кто создаст возможности для ее проверки?</p> <h3>Версия этой проблемы, связанная с кибербезопасностью</h3> <p>Кибербезопасность — это наиболее острая версия этой проблемы на данный момент, потому что автоматизация в области кибербезопасности не просто на очереди, она уже здесь, работает без контроля, в производственной среде.</p> <p>Каждая крупная платформа SOC переходит от «второго пилота» (ИИ отвечает на вопросы, человек действует) к «агентному ИИ» (ИИ действует, человек получает уведомление после этого). Автономные агенты сортировки теперь самостоятельно закрывают оповещения о низком риске и запускают действия по локализации с высокой, по их собственным оценкам, точностью, измеряемой, естественно, поставщиком, разработавшим систему, на основе собственных размеченных данных этого поставщика. В настоящее время нет независимой стороны, проверяющей эти данные. И среди специалистов явно существуют разногласия относительно того, насколько им можно доверять: сейчас часто можно услышать, как команды безопасности признаются, что они игнорируют рекомендации, сгенерированные ИИ, вместо того, чтобы действовать в соответствии с ними, потому что результат звучит уверенно, даже когда он иногда оказывается неверным. ИИ обучается на основе научных статей, поэтому в нем заложена предвзятость в сторону уверенности.</p> <p>Та же картина наблюдается и в тестировании. Автономные ИИ-агенты тестирования теперь находят и сообщают о реальных уязвимостях быстрее, чем это могла бы сделать любая человеческая команда. Это настоящее достижение. Но это уже нарушило конвейер обнаружения уязвимостей: по крайней мере, одна крупная платформа по поиску ошибок приостановила давно действующую программу поощрений и сократила выплаты после того, как исследования с помощью ИИ увеличили объем заявок далеко за пределы того, что могли обрабатывать сопровождающие, а несколько Open Source-проектов приостановили свои программы вознаграждений из-за потока правдоподобно звучащих, низкокачественных отчетов, созданных ИИ. Ограничения в наступательной безопасности заметно сместились с поиска проблем на их проверку, но почти никто не продает услуги проверки.</p> <p>Это, совершенно точно, пробел, и в сфере кибербезопасности для него пока нет названия. Итак, давайте дадим ему два.</p> <ul> <li><strong>AVaaS (</strong><strong>AI Validation-as-a-Service</strong><strong>): </strong><strong>валидация</strong> <strong>ИИ</strong> <strong>как</strong> <strong>услуга</strong><strong>. </strong>Название позаимствовано по аналогии с PTaaS (пентест как услуга) и MDR (управляемое обнаружение и реагирование), которые уже привычны для покупателей услуг в области безопасности, и применено к категории, у которой пока нет названия. Задача независимой стороны — сверить то, что на самом деле решил ваш ИИ, с тем, что, по его словам, он решил. Это означает, что автономные действия SOC будут сравниваться с эталонными данными, которые не создавались ИИ. Это означает, что результаты автономного пентеста будут проверяться так же, как старший тестировщик со скепсисом относится к отчёту младшего: не только на предмет того, попал ли он в цель, но и на предмет того, был ли путь к цели верным. Это не оценка и не использование большой языковой модели в качестве судьи под новым названием. AVaaS — это независимая и подотчётная проверка, проводимая человеком. Это именно то, что требуется регулятору, совету директоров или клиенту, и именно то, для чего никогда не предназначалась оценка.</li> <li><strong>AJQ (</strong><strong>AI</strong> <strong>Judgment</strong> <strong>Quotient</strong><strong>)</strong><strong>: оценка суждений ИИ.</strong> Индивидуальная версия той же идеи: способ обозначить конкретный навык, который можно развить, — умение понимать, когда стоит доверять выводам ИИ, а когда — оспаривать их, отдельно от умения правильно формулировать запросы к ИИ, которым сейчас все одержимы. Умение формулировать промпты позволяет получить более качественный и быстрый ответ, как если бы вы задали вопрос человеку. AJQ — это то, что позволяет понять, правильный ли получен ответ. Пока никто не нанимает людей с таким навыком. Но это ненадолго.</li> </ul> <h3>Попутный аспект комплаенса, который почти никто не учитывает</h3> <p>Есть также регуляторный аспект, и его стоит уточнить, поскольку обобщенная версия этого аргумента его преувеличивает. Большинство повседневных применений ИИ в сфере кибербезопасности, например, «второй пилот» SOC, занимающийся сортировкой фишинга, или агент пентестинга, сканирующий SaaS-приложение, автоматически не подпадают под правила высокого риска Закона ЕС об ИИ. Но одна категория в рамках этого закона напрямую относится к кибербезопасности. Это системы ИИ, используемые в качестве компонента безопасности при управлении и эксплуатации критической цифровой инфраструктуры: коммунальные предприятия, операционные технологии и системы управления промышленными процессами, где сбой системы безопасности или обнаружения аномалий может иметь физические последствия. По умолчанию это системы высокого риска, и закон требует реального, работающего человеческого контроля: человека, который может отслеживать, понимать, отключать и останавливать систему на практике, причем эта возможность должна быть продемонстрирована, а не предполагаться.</p> <p>Регуляторы не будут удовлетворены политикой, которая гласит, что существует аварийный выключатель. Они будут спрашивать, пытался ли кто-нибудь его активировать под давлением и подтвердил ли он его работоспособность. Это конкретное, проверяемое утверждение, и его легко продать. Крайний срок просто перенесли на декабрь 2027 г. Эта более поздняя дата дает запас времени, чтобы стать очевидным, заслуживающим доверия и подтвержденным поставщиком в этой области, прежде чем каждая консалтинговая фирма в мире начнет демонстрировать тот же самый слайд.</p> <p>Это реальная ниша. Оригинальная рыночная категория, без существующих игроков, созданная на основе трех вещей, которые, независимо друг от друга, проверяемо верны прямо сейчас: ИИ уже принимает неконтролируемые решения по безопасности в производственной среде; люди, которые исторически могли выявлять его ошибки, — это те же самые люди, чьи базовые навыки незаметно разрушаются из-за бездействия; и регулятор вот-вот начнет письменно спрашивать, проверял ли кто-нибудь это на самом деле. Итак, посмотрим, кто создаст этот рынок первым.</p> Сейчас в каждой отраслевой дискуссии об искусственном интеллекте, кажется, повторяется одно и то же … article https://www.itweek.ru/themes/detail.php?ID=235304 Thu, 06 Aug 2026 16:31:10 +0300 <p>Весной 2026 года правоохранительные органы США, Канады и Германии провели скоординированную <a href="https://www.securityweek.com/aisuru-and-kimwolf-ddos-botnets-disrupted-in-international-operation/">операцию</a> против инфраструктуры нескольких крупных DDoS-ботнетов, включая Aisuru и KimWolf. Примерно в тот же период на инфраструктуре CURATOR было отмечено заметное сокращение размера крупнейшего ботнета, зафиксированного при нейтрализации L7-атак в сети CURATOR: с рекордных 13,5 млн. устройств в первом квартале 2026 года до 2,09 млн. во втором — почти в шесть с половиной раз меньше. На первый взгляд, это выглядит как безусловная победа правоохранителей. Но у экспертов по сетевой инфраструктуре есть все основания считать её временной.</p> <h3>Одна операция не решает проблему</h3> <p>Резонно предположить, что снижение размера ботнета — прямое следствие операции правоохранителей. Отчасти это действительно так. Но это лишь одна из причин, и, вероятно, не главная. Значительная часть заражённых устройств сосредоточена в развивающихся регионах — Латинской Америке и Юго-Восточной Азии, где массово используются уязвимые Android-приставки для стриминга. Плановая замена оборудования интернет-провайдерами, обновления прошивок и изменения сетевых политик сами по себе постепенно вымывают часть заражённых хостов из ботнета — вне всякой связи с конкретной правоохранительной операцией. Так что говорить, что зачистка «выключила» ботнет, было бы упрощением: снижение его размера — результат наложения нескольких процессов, один из которых — резонанс вокруг операции, заставивший вендоров, провайдеров и CERT-группы активнее заниматься ремедиацией уязвимых устройств.</p> <p>Крупные правоохранительные операции, безусловно, приносят пользу, но они едва ли способны дать долгосрочное решение проблемы киберпреступности в принципе. Причина — в самой архитектуре интернета.</p> <p>Фундаментальная сложность заключается в том, что интернет децентрализован, а киберпреступность представляет собой глобальную проблему, тогда как полномочия правоохранительных органов по-прежнему ограничены национальными юрисдикциями. Кибератаки давно перестали считаться с государственными границами, а вот расследования и судебные процессы — нет.</p> <p>Свою роль играет и политический фактор: в ряде стран определённые группы действуют в интересах государственных или иных политических структур, они получают финансирование, накапливают экспертизу, разрабатывают новые инструменты и техники атак. Со временем эти наработки выходят за пределы первоначального контекста и расходятся по теневым площадкам, закрытым сообществам и криминальным экосистемам — так продвинутые возможности становятся доступны гораздо более широкому кругу злоумышленников.</p> <p>Ещё одна системная сложность — в том, что жертва, атакующая инфраструктура и сам оператор атаки нередко находятся в разных юрисдикциях. Организацию атакуют в одной стране, инфраструктура для атаки размещена в другой, а операторы — в третьей. Сбор доказательств, координация расследования и последующее привлечение виновных к ответственности превращаются в крайне сложную международную процедуру.</p> <h3>Технологии меняют баланс сил</h3> <p>Проблему усугубляет то, что новые технологии всё сильнее смещают баланс сил в пользу атакующих. Современные блокчейн-платформы, например, технически позволяют использовать зашифрованные смарт-контракты и другие децентрализованные механизмы для распространения команд и координации ботнетов. Эти подходы пока только формируются, но уже способны сделать вредоносную инфраструктуру значительно более устойчивой и куда менее уязвимой для выявления и атрибуции — в отличие от классических C2-серверов, которые можно относительно легко обнаружить и отключить.</p> <p>Параллельно ИИ заметно упрощает и ускоряет сам процесс поиска и компрометации уязвимых устройств: автоматизированная разведка, обнаружение уязвимостей и приоритизация целей позволяют злоумышленникам восполнять пул заражённых устройств быстрее, чем раньше.</p> <p>Здесь, пожалуй, уместна аналогия из физического мира: появился принципиально новый тип угрозы, под который существующие механизмы обнаружения и реагирования изначально не проектировались. Технологии развиваются заметно быстрее, чем регуляторная база и возможности правоприменения — из-за этого разрыва между атакующими и защитниками неизбежно возникает период асимметрии, и текущий момент — как раз такой период.</p> <h3>Расслабляться не стоит</h3> <p>Разовая, пусть и крупная, правоохранительная операция снижает размер конкретного ботнета, но не меняет структурных предпосылок его появления: дешёвые уязвимые устройства, растущая доступность ИИ-инструментов для автоматизации атак и переход операторов к более устойчивым и децентрализованным схемам управления. Именно поэтому мы не ожидаем долгосрочного эффекта от подобных зачисток. Конкретный ботнет может и не восстановиться в прежнем виде, однако на его месте будут появляться новые сети — потенциально быстрее, чем раньше, и с более устойчивой архитектурой управления. </p> <p>Для бизнеса вывод из этой ситуации достаточно прост: уменьшение одного крупного ботнета нельзя воспринимать как общее снижение потенциального риска. Компаниям необходимо исходить не из размеров конкретной обнаруженной сети, а из того, что инструменты создания и восстановления атакующей инфраструктуры становятся доступнее. Защита от DDoS должна рассматриваться не как реакция на отдельные инциденты, а как постоянная часть управления операционной устойчивостью — с регулярным тестированием инфраструктуры, пересмотром сценариев атак и оценкой способности провайдера защиты справляться не только с ростом интенсивности, но и с изменением самих методов атак.</p> <p>В конечном счёте разговор стоит вести не в логике «полиция против хакеров», а в логике безопасности всей экосистемы. Долгосрочный прогресс будет зависеть не только от того, насколько успешно ботнеты демонтируют уже после их появления, но и от того, удастся ли сократить число уязвимых устройств, подключённых к интернету, повысить базовые требования к безопасности у производителей, укрепить сотрудничество между вендорами, интернет-провайдерами, компаниями из сферы кибербезопасности и правоохранительными органами. Главный показатель успеха — не количество уничтоженных ботнетов, а то, насколько сложно и дорого злоумышленникам становится создавать новые.</p> <p>#IMAGE_235305#</p> Весной 2026 года правоохранительные органы США, Канады и Германии провели скоординированную операцию против инфраструктуры … article Дмитрий Ткачёв, генеральный директор CURATOR https://www.itweek.ru/themes/detail.php?ID=235303 Thu, 06 Aug 2026 16:26:27 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) открыла прием заказов на новую, старшую модель в линейке специализированных систем резервного копирования — TATLIN.BACKUP.L. Новая модель отличается увеличенным объемом полезной емкости более 1 Пб и двумя контроллерами хранения для дополнительной отказоустойчивости. Решение разработано специально для крупных корпоративных сред с повышенными требованиями к доступности данных и объему их хранения.</p> <p>Выход модели TATLIN.BACKUP.L приурочен к релизу масштабного обновления ПО v1.5 для всей линейки систем хранения резервных копий. В дополнение к технологиям дедупликации и компрессии данных, в системе появилась асинхронная репликация на уровне виртуальных файловых систем. Технология позволяет регулярно передавать данные на удаленную площадку для гарантированного восстановления в случае аварии на основном ЦОД. Также упростилась процедура самостоятельной замены дисков (CRU). Кроме того, был расширен комплекс мер безопасности, улучшен аудит логов при подключении по протоколу T-BOOST и обновлены инструменты мониторинга и управления системой. Это обеспечивает надежное и эффективное хранение огромных массивов информации и упрощает администрирование.</p> <p>Помимо новых функциональных возможностей, с выходом обновления v1.5 заказчикам стали доступны оптимизированные конфигурации систем TATLIN.BACKUP, оснащенные контроллерами хранения с 1,5 Тб оперативной памяти. Благодаря программным доработкам производительность системы сопоставима с конфигурациями с 2 Тб оперативной памяти в малых инсталляциях полезной емкостью до 380 Тб. При дальнейшем росте объемов данных и расширении ИТ-сценариев рекомендуется использовать максимальную конфигурацию с 2 Тб оперативной памяти.</p> <p>«Обновление 1.5 — один из самых масштабных и значимых релизов в истории TATLIN.BACKUP. Старшая модель TATLIN.BACKUP.L создавалась специально для крупнейших ИТ-инфраструктур с бескомпромиссными требованиями к доступности данных. В то же время новые конфигурации TATLIN.BACKUP оптимизируют стоимость владения решением без компромиссов в производительности, что особенно важно в условиях роста цен на электронные компоненты. Отдельное ключевое направление этого релиза — репликация. Она повышает сетевую эффективность, безопасность и киберустойчивость системы, а также формирует технологическую основу для режима „Бункер“, который мы реализуем в следующей версии 1.6», — отметил Владислав Леонтьев, старший менеджер продукта TATLIN.BACKUP компании YADRO.</p> <p>В дальнейших планах YADRO — развитие интеграций репликации с решениями технологических партнеров в сегменте программного обеспечения для резервного копирования. Кроме того, в будущих обновлениях инженерная команда продолжит развивать механизмы защиты резервных копий, включая поддержку неизменяемых резервных копий WORM и режим «Бункер».</p> <p>Новая старшая модель TATLIN.BACKUP.L уже доступна для демонстрационного тестирования. Подать заявку, ознакомиться с техническими характеристиками и получить консультацию экспертов можно на странице линейки TATLIN.BACKUP на сайте YADRO.</p> Технологическая компания YADRO (входит в ИКС Холдинг) открыла прием заказов на новую, старшую модель в линейке … message https://www.itweek.ru/themes/detail.php?ID=235302 Thu, 06 Aug 2026 16:20:34 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе опросов ученых и руководителей организаций сферы науки изучил, какую роль они отводят государству в поддержке ИИ и какую именно помощь ожидают.</p> <p>Более двух третей опрошенных ученых (67%) и руководителей организаций сферы науки (72%) считают, что государство должно прежде всего создавать благоприятные условия для применения ИИ в исследованиях.</p> <p>Столь же согласованны позиции респондентов в отношении жестких мер, таких как ограничения на использование ИИ в науке, введение целевых показателей в данной сфере и мониторинг их достижения. Эти меры не поддерживают около 70% ученых и 60% руководителей организаций.</p> <p>Относительно допустимых форм госрегулирования ИИ в науке у академического сообщества нет единой позиции. Невмешательство государства в выбор технологий и способы их применения поддерживают 58% ученых и 36% руководителей организаций. В то же время около 40% опрошенных в обеих группах выступают за более активное участие государства, в том числе за контроль в этой сфере. Расхождение может отражать сохраняющуюся неопределенность относительно оптимальных механизмов госучастия в отсутствие единой стратегии ИИ-трансформации науки.</p> <p>В целом респонденты в обеих группах ожидают положительного эффекта от перспективных мер поддержки, прежде всего направленных на расширение ресурсных возможностей научных организаций. Более 80% респондентов позитивно оценивают: централизованный доступ к вычислительным мощностям и целевое финансирование закупок оборудования для их расширения; поддержку междисциплинарных команд, объединяющих специалистов по ИИ и исследователей-предметников; оплату подписок на ИИ-сервисы для государственных вузов и НИИ; долгосрочное финансирование проектов с применением ИИ; создание репозиториев датасетов и ИИ-моделей.</p> <p>Несколько сдержаннее респонденты оценивают институциональные меры — разработку единых стандартов качества датасетов и официальных рекомендаций по ответственному и корректному использованию ИИ. Тем не менее около 70% опрошенных ожидают, что и эти инициативы улучшат условия проведения исследований.</p> <p>Неоднозначную реакцию вызывает только предложение создать систему оценки эффективности использования ИИ в научных исследованиях. Положительного эффекта от нее ожидают менее половины ученых и руководителей организаций. В то же время 29% ученых и 22% руководителей считают, что такая система, напротив, ухудшит условия выполнения исследований и разработок.</p> <p>Опросы ИСИЭЗ НИУ ВШЭ показали, что академическое сообщество ожидает от государства прежде всего доступа к инфраструктуре, финансированию, сервисам и данным, но не жесткого контроля, ограничений и директивных показателей. Такая поддерживающая модель соответствует подходам стран — научных лидеров, принявших национальные стратегии ИИ-трансформации науки. Активное применение ИИ для повышения качества и эффективности исследований и разработок относится к приоритетам, закрепленным в Стратегии научно-технологического развития РФ.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ на основе опросов ученых и руководителей … message https://www.itweek.ru/themes/detail.php?ID=235301 Thu, 06 Aug 2026 16:19:07 +0300 <p>В 2026 году бизнес стал активнее выносить ИИ-нагрузки в облако, чтобы не строить собственный GPU-кластер, а использовать мощности провайдера по запросу. Глобальный рынок GPU-as-a-Service достиг $6,07 млрд в 2025 году и растет темпами 44% ежегодно, по оценкам Fortune Business Insights, но параллельно растет и объем финансовых потерь — по данным аналитиков M1Cloud, до трети всех облачных расходов могут быть потрачены неэффективно на неиспользуемые или неоптимально сконфигурированные ресурсы. Для GPU-инфраструктуры, где стоимость одного часа вычислений в разы выше обычных серверов, цена ошибки пропорционально больше. Владимир Лебедев, директор по развитию бизнеса M1Cloud, рассказал, что для облачной ИИ-инфраструктуры требуются зрелые практики управления облачными затратами.</p> <p>На российском рынке доступ к новейшим GPU ограничен логистическими сложностями, а стоимость собственного оборудования включает существенную наценку за поставку. Компания, решившая построить собственный GPU-кластер, сталкивается не только с капитальными затратами, но и с риском технологического устаревания: цикл смены поколений GPU сократился до 18 месяцев, и кластер, закупленный сегодня, через полтора года будет уступать по производительности на затраченную единицу энергии. Облачный провайдер аккумулирует GPU-ресурсы и обеспечивает их высокую утилизацию за счет мультитенантности.</p> <p>Когда компания запускает ИИ-проект, основное внимание обычно сосредоточено на обучении модели — и именно под эту задачу планируется бюджет на облако. Но обучение — это конечный этап: недели или месяцы интенсивных вычислений, после которых модель готова к работе. А дальше начинается инференс — обработка реальных запросов пользователей, которая длится годами и может составить от 80 до 90% совокупных затрат на ИИ-систему за весь ее жизненный цикл. По данным Polaris Market Research, глобальный рынок ИИ-инференса оценивался в $106 млрд в 2025 году, с темпом роста в среднем на 19,4%. Для облачного провайдера это означает, что основной спрос на GPU-мощности генерируется не разработчиками моделей, а бизнесом, который эксплуатирует ИИ в продакшене — и именно этот бизнес нуждается в совершенно иной модели потребления облачных ресурсов.</p> <p>Обучение модели — это предсказуемая нагрузка: команда знает объем данных и тип GPU. Под такую задачу легко зарезервировать ресурсы и спрогнозировать бюджет. Нагрузка инференса зависит от числа пользователей, времени суток, сезонности, маркетинговых кампаний. Утром чат-бот обрабатывает 500 запросов в минуту, в обед — 5000, ночью — 50. Облачная инфраструктура должна обеспечивать масштабирование, чтобы бизнес не платил за простаивающие GPU в часы минимальной нагрузки и не терял клиентов из-за нехватки мощностей в пиковые моменты. Именно здесь проявляется ключевое преимущество облачной модели перед собственной инфраструктурой: провайдер распределяет пиковые нагрузки множества заказчиков по общему пулу ресурсов, обеспечивая каждому эластичность, которую практически невозможно получить на собственном оборудовании.</p> <p>По данным FinOps Foundation, в 2026 году 98% компаний управляют не только облачными затратами, но и ИИ-расходами — против 31% всего два года назад. Этот взрывной рост отражает масштаб проблемы: средняя утилизация GPU-инстансов в корпоративных средах составляет порядка <nobr>20-30%,</nobr> что означает, что компании арендуют в облаке втрое больше мощностей, чем реально используют, потому что зачастую разработчики резервируют GPU с запасом, забытые тестовые среды продолжают потреблять ресурсы, отсутствует автоматическое выключение инстансов после завершения задач.</p> <p>Зрелые провайдеры проводят аудит ресурсов и дают рекомендации по оптимизации (переход на меньший инстанс, использование spot-мощностей для некритичных задач, снижение требований к GPU). Фактически провайдер берет на себя роль FinOps-консультанта, помогая заказчику оптимизировать облачные ресурсы.</p> <p>Помимо этого, опытный провайдер помогает правильно выбрать конфигурацию облачной инфраструктуры под конкретный тип ИИ-нагрузки и под разные сценарии. Обучение крупной модели требует кластера с высокоскоростным интерконнектом между GPU и большим объемом видеопамяти. Инференс, напротив, чаще всего работает на одиночных GPU или даже на специализированных ускорителях с меньшей памятью, но более высокой пропускной способностью.</p> <p>Модели в продакшене генерируют логи, метрики, результаты инференса, которые необходимо хранить для мониторинга качества и дообучения. Объем этих данных растет пропорционально числу запросов, и через несколько месяцев эксплуатации затраты на хранение могут сравняться с затратами на сами вычисления. Провайдер, предлагающий интегрированную экосистему — GPU-вычисления, хранилище, инструменты мониторинга в рамках единого биллинга — избавляет заказчика от необходимости собирать инфраструктуру из разрозненных сервисов и контролировать затраты в нескольких системах одновременно.</p> <p>Сегодня облачная инфраструктура для ИИ — это комплексная услуга, включающая эластичное масштабирование под непредсказуемые инференс-нагрузки, подбор оптимальных конфигураций под тип задачи, инструменты финансового управления затратами, экспертизу в оптимизации потребления и защиту от рисков технологического устаревания. Провайдер, который выстраивает эту экосистему, становится для заказчика не поставщиком ресурсов, а стратегическим партнером в построении экономически устойчивой ИИ-стратегии.</p> В 2026 году бизнес стал активнее выносить ИИ-нагрузки в облако, чтобы не строить собственный GPU-кластер … message https://www.itweek.ru/themes/detail.php?ID=235300 Thu, 06 Aug 2026 16:13:26 +0300 <p>Компания Innostage существенно обновила Innostage TDIR — решение для интеллектуальной автоматизации деятельности центров мониторинга и реагирования на инциденты информационной безопасности (SOC). Версия 1.0.0 получила множество улучшений, касающихся интеграции с SOAR, генерации запросов в SIEM, проверки инцидентов и рекомендациям по реагированию, взаимодействия с ИИ-чатом и другие.</p> <p>Innostage TDIR — решение, разработанное на базе искусственного интеллекта, которое развертывается On-Premise и работает в связке с SIEM и SOAR-системами организации, усиливая их эффективность за счет снижения количества ложноположительных срабатываний и исторической корреляции событий.</p> <p>Расширены возможности автоматизированной обработки инцидентов информационной безопасности, включая интеграцию с SOAR-системами: скорректирована логика обработки поля DeviceAddress из TSV-файла, реализован парсинг дополнительных полей и их использование при обработке инцидентов. Улучшен механизм определения геолокации IP-адресов при обогащении объектов, а в интерфейсе теперь отображается объект, для которого было выполнено обогащение. Кроме того, доработана логика отображения блока «Исходные события», его содержимое теперь зависит от фактического количества событий.</p> <p>Помимо этого, модернизированы процессы автоматизированной генерации запросов в SIEM: скорректирован алгоритм запросов для инцидентов «Спам-рассылка» и для случая множественных вхождений объектов, исправлена ошибка при формировании запросов по превентивным мерам. </p> <p>Улучшены функции интеллектуальной проверки инцидентов: фильтрации ложноположительных срабатываний (AntiFP), рекомендаций по реагированию. Усовершенствованы размышления LLM по индикаторам компрометации (IoC/POSH). В части работы с базой знаний MITRE ATT&CK — обновлены справочники по теме разделения митигаций и техник, улучшено предоставление ответов ИИ-ассистента. </p> <p>Взаимодействие пользователей с ИИ-чатом для поиска информации в области ИБ стало удобнее: реализована отмена генерации ответа по кнопке, исправлена ошибка «OpenTIP request timed out» при редиректе. В версии 1.0.0 обновлена большая языковая модель (LLM): осуществлен переход с Qwen 2.5 на Qwen 3.x. </p> <p>Кроме того, реализован ряд доработок интерфейса: исключен блок «Аналитический отчет», который дублировал информацию отчета по инциденту, улучшен внешний вид раздела «Накопленная база правил», скорректировано визуальное отображение тегов на инцидентах, улучшен механизм переключения темы (темная, светлая, системная). </p> <p>Новая версия решения уже внедрена и успешно функционирует в контуре заказчика — крупном российском предприятии химической отрасли. </p> <p>«Innostage TDIR — решение, которое объединяет в себе функциональность по усилению существующих SIEM/SOAR-систем и интеллектуальную аналитику. Благодаря этому оно повышает эффективность работы специалистов SOC по выявлению и предотвращению актуальных угроз, а также значительно снижает нагрузку на команду, позволяя компаниям масштабировать процессы кибербезопасности», — прокомментировал Искандер Тиморшин, владелец продукта Innostage TDIR.</p> <p>«Применение Innostage TDIR напрямую влияет на ключевые операционные показатели SOC-команд: аналитики избавляются от большого объема рутины, тем самым снижается риск профессионального выгорания. Процессы становятся более оперативными и упорядоченными, внутри команд формируется и быстро накапливается экспертиза, что является надежной базой для дальнейших расследований», — добавил Никита Радионов, заместитель директора по развитию продуктов Innostage.</p> Компания Innostage существенно обновила Innostage TDIR — решение для интеллектуальной автоматизации деятельности центров … message https://www.itweek.ru/themes/detail.php?ID=235299 Thu, 06 Aug 2026 16:10:02 +0300 <p>Система защиты от утечек информации (DLP) «СёрчИнформ КИБ» расширила возможности ИИ-Ассистента: теперь умный модуль позволяет ИБ-специалистам самостоятельно создавать промпты для поиска инцидентов. Это поможет адаптировать инструмент под индивидуальные задачи заказчиков.</p> <p>Пользовательские промпты пишутся в интерфейсе КИБ на естественном языке без кода и регулярных выражений. В системе есть пример наиболее эффективной структуры, содержания и объема промпта. Запрос для нейросети будет работать как ИИ-политика безопасности: автоматически проверять коммуникации сотрудников и уведомлять службу ИБ о нарушениях. Функция дополняет набор преднастроенных ИИ-политик в КИБ: по поиску утечек, корпоративного мошенничества и контролю групп риска.</p> <p>«Кастомизация запросов к ИИ-Ассистенту в КИБ помогает решить нестандартные задачи и делает инструмент гибче. Если нужно найти обсуждения тем, характерных для конкретной отрасли, выявить подозрительные манипуляции с данными при их пересылке и так далее. Готовые ИИ-политики „отрабатывают“ темы, актуальные для любой компании. А с помощью пользовательских промптов можно будет сузить фокус для персонализированных расследований, — объяснил начальник отдела безопасности „СёрчИнформ“ Алексей Дрозд. — Промпт может быть любым, дальше все зависит от мощности оборудования и объема данных, которые попадут под проверку ИИ. Создать свой промпт просто, если воспользоваться встроенными в интерфейс рекомендациями».</p> <p>Задать фокус для ИИ-политик можно с помощью фильтров. В обновлении появилась возможность выбирать, в каких мессенджерах и соцсетях нужно анализировать чаты, а также исключать из проверки информационные каналы. Похожая логика работает для почты: теперь ИБ-специалисты могут указать, какие почтовые ящики проверять или не проверять по ИИ-политикам.</p> <p>ИИ-Ассистент появился в КИБ в начале 2026 года. Это встраиваемый компонент на основе большой языковой модели (LLM), который бесшовно интегрируется в систему и работает в ее интерфейсе. Инструмент позволяет обнаруживать скрытые и замаскированные инциденты безопасности, которые невозможно найти классическими алгоритмами. Также ИИ-Ассистент составляет краткие резюме цепочек писем, чатов и документов, которыми обмениваются пользователи, и в реальном времени переводит со 120 языков. Инструмент разворачивается локально, так что корпоративные данные не покидают корпоративный периметр.</p> Система защиты от утечек информации (DLP) «СёрчИнформ КИБ» расширила возможности ИИ-Ассистента: теперь умный модуль … message https://www.itweek.ru/themes/detail.php?ID=235284 Thu, 06 Aug 2026 00:00:00 +0300 <p><em>Искусственный интеллект больше не является функцией будущего в области безопасности приложений (AppSec); он быстро становится основной частью того, как AppSec-инструменты выявляют, приоритизируют и устраняют риски. Тем не менее, несмотря на активные инвестиции поставщиков, внедрение по-прежнему сдерживается опасениями по поводу доверия, вопросами ценности и неопределенностью в отношении моделей ценообразования, пишут в корпоративном блоге Джанет Уортингтон, старший аналитик </em><em>Forrester</em><em>, Сэнди Кариелли, вице-президент и главный аналитик </em><em>Forrester</em><em>, и Элли Меллен, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>В новом отчете Forrester «The State Of Artificial Intelligence In Security Tools: Application Security» мы проанализировали ответы 31 поставщика решений в области безопасности приложений, чтобы понять, где ИИ приносит пользу сегодня и куда движется рынок.</p> <p>Вот три ключевых вывода.</p> <h3>1. Отсутствие доверия остается самым большим препятствием для внедрения</h3> <p>Рынок безопасности приложений находится в необычном положении. Поставщики стремятся внедрить возможности ИИ в свои продукты, в то время как многие покупатели по-прежнему скептически относятся к результатам.</p> <p>Команды AppSec проявляют особую осторожность, поскольку многие функции, использующие ИИ, требуют доступа к конфиденциальному проприетарному коду или должны давать рекомендации, которые могут повлиять на производственные системы. Хотя организации стремятся повысить эффективность и сократить трудозатраты, они также балансируют между вопросами точности, конфиденциальности, управления и объяснимости. В результате доверие по-прежнему важнее технических возможностей как основной фактор, определяющий внедрение.</p> <p>Задача для поставщиков больше не состоит в том, чтобы доказать, что ИИ может генерировать результаты. Задача состоит в том, чтобы доказать, что пользователи могут полагаться на эти результаты.</p> <h3>2. Ценность ИИ сосредоточена в практических улучшениях на уровне рабочих процессов</h3> <p>Несмотря на ажиотаж вокруг автономных систем, наиболее успешные сегодня функции ИИ отличаются исключительной практичностью.</p> <p>Наше исследование показало, что поставщики видят наибольшее внедрение клиентами таких возможностей, как анализ данных, обобщение информации, рекомендации по правилам и рекомендации по реагированию. Эти функции помогают командам безопасности и разработки разобраться в огромных массивах данных по безопасности и сократить трудозатраты на выполнение рутинных задач.</p> <p>Приведенная ниже диаграмма иллюстрирует важную динамику, указывая на возможность для поставщиков, которые сегодня этого не делают, использовать ИИ для предоставления рекомендуемых ответов или правил и добавлять эти функции в свои предложения для повышения ценности для клиентов.</p> <p>#IMAGE_235285#</p> <p>Победителями в сфере ИИ для безопасности приложений не обязательно станут поставщики с наибольшим количеством функций. Это будут поставщики, которые помогут командам принимать более эффективные решения быстрее.</p> <h3>3. Ценообразование становится конкурентным дифференциатором</h3> <p>Один из наиболее неожиданных выводов исследования касается подхода поставщиков к монетизации.</p> <p>Многие поставщики решений в области безопасности приложений в настоящее время включают возможности ИИ в свои существующие предложения, а не взимают за них отдельную плату. Другие экспериментируют с гибридными подходами, моделями дополнений и ценообразованием на основе потребления для более продвинутых возможностей, таких как автоматическое устранение неполадок, анализ с интенсивным рассуждением или агентные рабочие процессы.</p> <p>Конкретные варианты ценообразования разнообразны, но общий вывод очевиден: рынок еще не определился с единой стратегией монетизации. Руководителям служб безопасности, оценивающим AppSec-продукты с использованием ИИ, следует смотреть дальше заявленной функциональности и тщательно оценивать, насколько цена соответствует ожидаемому использованию, ценности и операционным результатам.</p> <h3>Что дальше?</h3> <p>Сегодня возможности ИИ в области безопасности приложений в основном носят вспомогательный характер. Но поставщики уже смотрят дальше обобщения и рекомендаций в сторону агентных рабочих процессов, автоматизации и, в конечном итоге, автономных операций по обеспечению безопасности.</p> <p>Ключевой вопрос для руководителей служб безопасности больше не в том, станет ли ИИ частью программ обеспечения безопасности приложений. Вопрос в том, какие возможности обеспечивают значимую коммерческую ценность сегодня, а какие остаются нереализованными.</p> Искусственный интеллект больше не является функцией будущего в области безопасности приложений (AppSec); он быстро … article https://www.itweek.ru/themes/detail.php?ID=235297 Wed, 05 Aug 2026 16:45:27 +0300 <p>Компании АТОЛ и «Актив» подтвердили совместимость кассового программного обеспечения SIGMA Касса с активными ключевыми устройствами из линейки Рутокен ЭЦП 3.0. Тестирование производилось на смарт-терминалах: АТОЛ SIGMA 7, SIGMA 10, АТОЛ СТБ 5 и СТБ 6.</p> <p>Совместимость подтверждена для ПО SIGMA Касса версии 3.34.0.0 с модулем «Маркировка» на ОС АТОЛ ОС 7 и АТОЛ ОС 13 на базе Android 7 и 13. </p> <p>Что это дает пользователям:</p> <ul> <li>устройства Рутокен подписывают УПД (универсальный передаточный документ) при обмене данными с системой «Честный знак», что критично для торговли товарами, подлежащими обязательной маркировке;</li> <li>подписание и шифрование документов происходит с использованием неизвлекаемых ключей на сертифицированных носителях Рутокен, что исключает риски компрометации данных;</li> <li>использование Рутокен для входа в сервисы АТОЛ и для работы с API «Честного знака» упрощает администрирование и повышает уровень контроля доступа;</li> <li>интеграция работает «из коробки» на всех устройствах SIGMA с версией ПО 3.34.0.0 и не требует установки дополнительных драйверов или модулей.</li> </ul> <p>Таким образом, пользователи SIGMA Касса получают удобные средства подписания и шифрования документов, а также надежный способ аутентификации без усложнения ИТ-инфраструктуры и дополнительных затрат. </p> <p>Игорь Вааг, заместитель генерального директора АТОЛ, отметил: «Рутокен — надежный инструмент для криптографических операций, который мы используем в наших устройствах уже давно. Получение сертификата совместимости подтверждает высокий уровень интеграции и дает нашим клиентам уверенность в том, что работа с электронной подписью, маркировкой и ЭДО на устройствах АТОЛ SIGMA полностью соответствует требованиям безопасности и законодательства».</p> <p>Павел Анфимов, заместитель директора по управлению продуктами компании «Актив», отметил: «Сотрудничество с АТОЛ — яркий пример того, как современные криптографические решения применяются в бизнес-системах для широкого круга бизнес-пользователей. Подтверждение совместимости Рутокен с линейкой смарт-терминалов SIGMA — это закономерный итог нашей совместной работы. Мы рады, что наши устройства помогают обеспечивать безопасность при работе с маркировкой, электронным документооборотом и авторизацией в сервисах. Для нас важно, чтобы наши общие заказчики получали надежный и сертифицированный инструмент защиты ключевых бизнес-процессов без дополнительных сложностей при внедрении».</p> Компании АТОЛ и «Актив» подтвердили совместимость кассового программного обеспечения SIGMA Касса с активными ключевыми … message https://www.itweek.ru/themes/detail.php?ID=235294 Wed, 05 Aug 2026 13:44:10 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ по данным Роспатента проанализировал динамику государственной регистрации программ для ЭВМ, баз данных и топологий интегральных микросхем за последнее десятилетие, а также основные направления цифровых разработок и состав правообладателей.</p> <p>На программы для ЭВМ приходится более четырех из пяти регистраций по трем рассматриваемым видам объектов. В 2025 г. в Роспатент поступило 38,6 тыс. заявок на их регистрацию, зарегистрировано 38,1 тыс. программ. За год число зарегистрированных программ увеличилось на 17,5%, а по сравнению с 2015 г. — в 2,8 раза.</p> <p>Почти все заявки (свыше 99,9%) на регистрацию программ для ЭВМ в 2025 г. подали отечественные разработчики. Среди регистрируемых решений представлены системы автоматизированного проектирования (САПР) и инженерного моделирования, технологии искусственного интеллекта и машинного обучения, системы управления технологическими процессами, медицинские информационные системы, ПО для энергетики и нефтегазового комплекса, образовательные платформы и финансово-аналитические продукты.</p> <p>Масштабы регистрации баз данных значительно ниже, чем программ для ЭВМ, однако в последнее десятилетие эти показатели в целом устойчиво росли. В 2015 г. в России было подано порядка 1,7 тыс. заявок на регистрацию баз данных, в 2025 г. — уже 6,7 тыс., то есть почти в 4 раза больше. Число зарегистрированных баз данных за этот период выросло более чем в 3,6 раза — с 1,8 тыс. в 2015 г. до 6,6 тыс. в 2025 г.</p> <p>Почти все зарегистрированные базы данных также принадлежат российским правообладателям. Значительную часть баз составляют наборы данных, накопленные в ходе медицинских и биологических исследований: регистры пациентов, результаты диагностики, геномные и микробиологические коллекции. Широко представлены образовательные и экологические ресурсы, геопространственные и статистические данные. Присутствуют также размеченные датасеты для задач машинного обучения.</p> <p>Самый заметный рост в 2025 г. отмечен в сегменте топологий интегральных микросхем (ИМС)— наиболее редких среди рассматриваемых объектов: по сравнению с 2024 г. число заявок увеличилось с 324 до 478, а регистраций — с 286 до 452. По сравнению с 2015 г. оба показателя выросли более чем втрое.</p> <p>Доля иностранных решений в данной категории тоже ограничена, но чуть выше, чем в программах для ЭВМ и базах данных: порядка 4% заявок в среднем в течение всего рассматриваемого периода. Многие разработки ориентированы на импортозамещение компонентной базы. Большинство регистрируемых топологий относится к силовой и аналоговой, сверхвысокочастотной электронике, цифровым и смешанным схемам. Отдельные направления — сенсорные, оптоэлектронные, радиационно-стойкие микросхемы.</p> <p>За период <nobr>2015–2025 гг.</nobr> существенно выросла активность российских правообладателей в отношении регистрации программ для ЭВМ, баз данных и топологий ИМС. Особенно заметный рост начался после 2020 г., когда на фоне пандемии COVID-19 усилился спрос на цифровые решения. Санкционное давление дополнительно стимулировало развитие отечественной микроэлектроники. При этом три сегмента различаются по составу наиболее активных правообладателей. Программы для ЭВМ часто регистрируют государственные структуры и компании с госучастием, базы данных — университеты и научные организации, топологии микросхем — специализированные предприятия микроэлектроники. В последнем случае важную роль играет государство как заказчик НИОКР, за которым нередко закрепляются права на полученные результаты.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ по данным Роспатента проанализировал динамику … message https://www.itweek.ru/themes/detail.php?ID=235293 Wed, 05 Aug 2026 13:41:38 +0300 <p>Компания «Блазар» продолжает реализовывать стратегию развития системы контроля сетевого доступа Blazar NAC, ориентируясь на потребности крупных корпоративных клиентов. В версии Blazar NAC 3.0 осуществлена возможность развёртывания системы в территориально распределённой инфраструктуре с помощью создания федерации из независимых равноправных узлов. Такое решение учитывает архитектуру сети предприятия, позволяет оперативно реагировать на её изменения и обеспечивает технологическую основу для централизованного управления сетевым доступом в геораспределённой корпоративной сети.</p> <p>Контроль соответствия рабочих станций, работающих под управлением операционной системы MacOS, установленным в организации внутренним правилам ИБ расширяет функциональные возможности Blazar NAC 3.0.</p> <p>Реализованный в системе централизованный сбор структурированных логов предоставляет администратору единую точку контроля и структурированные данные для быстрой аналитики, упрощения диагностики и расследования инцидентов.</p> <p>Расположение становится новым критерием и позволяет учитывать локацию подключения пользователя и устройства как один из факторов при принятии решения о предоставлении доступа.</p> <p>«Мы развиваем наш продукт с учетом запросов корпоративных клиентов. Новая версия Blazar NAC 3.0 заметно расширяет возможности управления доступом в сложных распределённых средах, — отметил генеральный директор АО „Блазар“ Александр Черных. — Реализованные обновления — это инструменты под реальные задачи бизнеса: они учитывают особенности работы в территориально разнесённой инфраструктуре, разнородную среду и разные сценарии эксплуатации, обеспечивая при этом прозрачность для команд ИБ».</p> Компания «Блазар» продолжает реализовывать стратегию развития системы контроля сетевого доступа Blazar NAC, ориентируясь … message https://www.itweek.ru/themes/detail.php?ID=235287 Wed, 05 Aug 2026 00:00:00 +0300 <p><em>Интерактивные виджеты в iOS появились ещё в 2023 году, но компании до сих пор регулярно сталкиваются с одними и теми же проблемами при их разработке: кнопка не реагирует, данные показывают не то, что есть на самом деле, действия дублируются. Рассмотрим, почему причина этих проблем почти никогда не кроется в самом интерфейсе.</em></p> <h3>Виджет живёт отдельно от приложения</h3> <p>WidgetKit работает в отдельном процессе и не имеет прямого доступа к основному приложению. Это первое, что нужно понимать про архитектуру виджета: он не часть приложения в техническом смысле, а отдельная программа, которая время от времени получает данные со стороны. После нажатия кнопки сначала запускается обработчик действия (AppIntent), затем выполняется бизнес-логика, после чего поставщик временной шкалы (TimelineProvider) формирует новое состояние виджета (TimelineEntry). Только после этого WidgetKit может обновить интерфейс. Между этими этапами нет прямой синхронизации — каждый выполняется независимо.</p> <p>Команды часто проектируют виджет так, будто он может напрямую использовать состояние приложения. На практике же получается иначе: приложение хранит данные в одном месте, виджет использует другое хранилище, а сервер работает уже с третьей версией состояния. Пока пользователь работает только с приложением, это разделение незаметно — все три части обновляются последовательно, без видимых противоречий.</p> <h3>Разделение становится проблемой только с появлением кнопки</h3> <p>Всё меняется, когда у пользователя появляется возможность что-то нажать прямо в виджете. Пользователь выполняет действие через виджет, сервер обрабатывает запрос, приложение получает новое состояние — а сам виджет ещё некоторое время продолжает показывать старые данные. Технически операция выполнена корректно, но пользователь видит это как сбой. Он происходит потому, что изменение данных и обновление самого виджета — два независимых процесса. Даже если данные уже изменились, пользователь может ещё некоторое время видеть предыдущее состояние интерфейса.</p> <p>Здесь и кроется главная ошибка в восприятии задачи: интерактивный виджет часто проектируют как статический, к которому просто добавили кнопку. Но как только пользователь получает возможность совершить действие, виджет перестаёт быть просто экраном с данными и становится частью бизнес-процесса — с теми же рисками, что и любой другой шаг в цепочке обработки операции.</p> <h3>Почему действие может выполниться дважды</h3> <p>Раз виджет, приложение и сервер хранят свои версии состояния отдельно, между ними неизбежно возникают гонки: обновления приходят в разном порядке, случаются повторные вызовы одного и того же действия, происходит частичная запись данных. Приложение уже получило новую информацию, а виджет ещё работает со старой версией.</p> <p>По сути, интерактивный виджет — это распределённая система с несколькими участниками: пользователь, WidgetKit, приложение, серверная часть и механизмы синхронизации между ними. Если архитектура не защищает от повторных операций и рассинхронизации данных, продукт начинает вести себя непредсказуемо — независимо от того, насколько хорошо написан код самой кнопки. Именно поэтому действие может выполняться дважды.</p> <h3>У WidgetKit есть два разных ограничения</h3> <p>К рассинхронизации данных добавляются ограничения самой платформы. Обычно о них говорят как об одной проблеме — «Apple ограничивает обновления виджетов». На самом деле речь идёт о двух разных механизмах.</p> <p>Первый влияет на выполнение действия. После нажатия кнопки запускается AppIntent. Он работает в отдельном процессе, которому система выделяет ограниченные ресурсы. Из-за этого выполнение бизнес-логики или сетевого запроса может занять больше времени, чем ожидает пользователь.</p> <p>Второй механизм влияет на обновление интерфейса. Даже если операция уже завершилась и новое состояние готово, разработчик не может заставить WidgetKit сразу перестроить виджет. Можно лишь отправить запрос на обновление. Когда именно система его выполнит, решает уже iOS. Она же ограничивает количество обновлений, доступных виджету.</p> <p>Путать эти ограничения нельзя. Одно определяет, когда завершится операция, второе — когда пользователь увидит её результат. Поэтому после успешного выполнения действия виджет ещё некоторое время может отображать старые данные.</p> <p>Попытка обновлять интерфейс после каждого действия проблему не решает. Виджет — не обычный экран приложения, которым разработчик управляет напрямую. Лишние запросы только увеличивают нагрузку и не гарантируют, что пользователь быстрее увидит изменения.</p> <p>Рабочий подход другой. Данные готовят заранее, а виджет получает уже сформированный снимок состояния от TimelineProvider. Запрос на обновление отправляется сразу после изменения данных, но момент, когда пользователь увидит новую информацию, всё равно определяет система. Поэтому основную бизнес-логику выносят за пределы виджета, оставляя внутри только отображение уже подготовленного состояния.</p> <h3>Чем выше цена ошибки, тем строже правила</h3> <p>Эта же логика подтверждённых состояний становится критичной, когда виджет показывает баланс счёта, статус заказа или показатели мониторинга. Частая ситуация: виджет показывает результат операции раньше, чем система получила окончательное подтверждение. Пользователь видит успешный статус, а через несколько секунд операция завершается ошибкой.</p> <p>Для пользователя это выглядит как недостоверность данных, для бизнеса — как рост обращений в поддержку и потеря доверия к продукту. Поэтому в таких сценариях виджет не должен показывать информацию, которая ещё находится в процессе согласования: если операция выполняется, пользователь видит промежуточный статус, а при отсутствии подтверждения — последнее подтверждённое состояние с указанием времени его обновления. В итоге, можно избежать ситуации, когда устаревшие данные выглядят актуальными. Пользователь понимает, что операция ещё не завершена, а не воспринимает задержку как ошибку системы.</p> <h3>Лёгкий виджет ведёт себя стабильнее</h3> <p>Та же проблема — перенос логики приложения внутрь виджета — встречается и на уровне производительности. Если внутри виджета остаются сложные вычисления, подготовка данных и обращения к серверу, со временем накапливаются задержки обновления и нестабильная работа интерактивных сценариев, даже если изначально всё работало корректно.</p> <p>Решение то же самое, что и для синхронизации состояний: подготовка данных переносится заранее — в приложение или на сервер, — а сам виджет получает уже готовый снимок и выполняет минимум собственной логики. TimelineProvider строит интерфейс уже по подготовленной модели данных, а не выполняет тяжёлые вычисления в момент обновления. Чем меньше работы виджет делает самостоятельно, тем стабильнее он ведёт себя в реальных условиях эксплуатации.</p> <h3>Почему к виджету предъявляют более высокие требования</h3> <p>Все перечисленные сложности соединяются в одном простом факте: виджет находится на первом экране взаимодействия с продуктом, а не открывается после запуска и авторизации, как основное приложение. Он постоянно находится перед глазами пользователя и должен корректно работать в любой момент времени.</p> <p>Если внутри приложения произойдёт сбой, пользователь часто может повторить действие или обновить экран — и не заметит проблему как системную. Если же некорректно ведёт себя виджет, это видно сразу и напрямую влияет на восприятие всего продукта. Именно поэтому распределённую природу виджета нельзя игнорировать на этапе проектирования: кнопка на экране — лишь видимая часть процесса, а всё остальное нужно строить как систему с несколькими источниками данных, а не как элемент дизайна.</p> <p>#IMAGE_235288#</p> Интерактивные виджеты в iOS появились ещё в 2023 году, но компании до сих пор регулярно сталкиваются … article Алексей Артамонов, директор Nord Clan https://www.itweek.ru/themes/detail.php?ID=235283 Wed, 05 Aug 2026 00:00:00 +0300 <p><em>Тим Янг, директор по маркетингу Vespa.ai, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как оптимизация оркестровки рабочих процессов обеспечивает контекст, необходимый автономным агентам.</em></p> <p>Публичные ИИ-помощники стали настолько распространены, что поставщики ПО все чаще добавляют в свои приложения поиск с использованием искусственного интеллекта, диалоговые возможности и ИИ-агентов. От электронной коммерции и поддержки клиентов до корпоративного ПО, ИИ быстро становится основным интерфейсом для многих приложений.</p> <p>Компании, которые создают продукты на основе собственной информации, особенно хорошо подготовлены к тому, чтобы извлечь выгоду из этого сдвига. Независимо от того, предоставляют ли они финансовую аналитику, аналитику рынка, юридические исследования, научные публикации или деловую информацию, их продукты помогают профессионалам принимать более обоснованные решения, преобразуя достоверную информацию в действенные инсайты.</p> <p>ИИ позволяет этим организациям предоставлять эту экспертизу благодаря совершенно новым пользовательским интерфейсам. Все чаще они конкурируют не только по качеству своей собственной информации, но и по тому, насколько интеллектуально они ее извлекают, понимают и преобразуют в ценность для клиента.</p> <p>Появляется новое поле конкурентной борьбы. Поскольку ИИ становится основным интерфейсом для доступа к корпоративным знаниям, способность извлекать, проверять, ранжировать и собирать информацию становится почти столь же важной, как и сама корпоративная информация.</p> <p>Значительная часть внимания отрасли сосредоточена на все более совершенных языковых моделях, но эффективность этих моделей зависит от контекста, который они получают. Разработка рабочих процессов извлечения, которые постоянно предоставляют достоверную, релевантную и актуальную информацию, быстро становится одной из определяющих инженерных задач для ИИ-нативных приложений.</p> <h3>Инженерия извлечения информации: оптимизация рабочего процесса</h3> <p>На протяжении десятилетий инженерия извлечения информации была сосредоточена на том, чтобы помочь людям найти нужную информацию. Будь то поиск на веб-сайте, в юридической базе данных или на платформе финансовых исследований, задача заключалась в том, чтобы получить наиболее релевантные результаты, балансируя при этом конкурирующие приоритеты, такие как релевантность, задержка, масштабируемость и стоимость. Задача поисковой системы заключалась в извлечении релевантной информации. Задача человека заключалась в ее оценке.</p> <p>ИИ коренным образом меняет роль поисковой системы.</p> <p>Вместо того чтобы извлекать информацию для оценки людьми, системы поиска все чаще собирают контекст, который большие языковые модели и агенты ИИ используют для исследований, рассуждений и действий. Каждое решение об извлечении информации теперь становится частью автоматизированного рабочего процесса, в котором релевантность, актуальность, задержка и доверие напрямую влияют на конечный ответ.</p> <p>Это смещает инженерную задачу с отдельных технологий на сам рабочий процесс извлечения. Цель больше не состоит в простом поиске релевантных документов, а заключается в оркестрации поиска, ранжирования, фильтрации, инференса и обновлений в реальном времени, чтобы они эффективно работали вместе. Мы считаем, что эта новая дисциплина заслуживает собственного названия: инжиниринг извлечения информации (Retrieval Engineering). Промпт-инижиниринг влияет на то, как языковая модель рассуждает. Инжиниринг извлечения информации определяет, о чем ей нужно рассуждать. Оба аспекта важны, но по мере того, как приложения ИИ становятся все более автономными, качество извлечения все больше определяет качество результата.</p> <p>По мере того, как приложения ИИ развиваются от разговорных помощников до систем глубокого исследования и автономных агентов, оптимизация рабочих процессов, а не отдельных компонентов, становится все более важной. Один запрос пользователя может запустить десятки — или даже сотни — операций извлечения, прежде чем будет сгенерирован ответ.</p> <h3>Проблема не в векторном поиске</h3> <p>Векторные базы данных решили важную проблему, сделав семантический поиск практичным в масштабе. Но это лишь один этап гораздо более масштабного рабочего процесса.</p> <p>В производственных приложениях ИИ все чаще сочетается векторное сходство с поиском по ключевым словам, структурированной фильтрацией, бизнес-правилами, персонализацией, ранжированием на основе машинного обучения и инференсом в реальном времени для формирования контекста, от которого зависят языковые модели. Инженерная задача больше не заключается в выборе лучшей технологии извлечения — она заключается в оркестрации все более сложных рабочих процессов извлечения, которые остаются точными, отзывчивыми и экономически эффективными.</p> <p>Многие организации решают эту проблему, комбинируя специализированные технологии. Векторная база данных обеспечивает семантический поиск. Поисковая система обрабатывает лексическое соответствие. Дополнительные сервисы обеспечивают переранжирование, персонализацию и инференс. Вначале это работает хорошо, но каждый дополнительный компонент добавляет еще один сетевой узел, еще одну операционную зависимость и еще один источник задержки. Проблема больше не в векторном поиске. Она заключается в разработке эффективной архитектуры извлечения.</p> <h3>От компонентов к платформам</h3> <p>Этот сдвиг меняет подход к проектированию инфраструктуры извлечения информации. Вместо оптимизации отдельных компонентов в отрыве от контекста, инженерным командам все чаще необходимо оптимизировать рабочий процесс извлечения как целостную систему — балансируя качество извлечения, задержку, актуальность, масштабируемость и стоимость инфраструктуры.</p> <p>Именно поэтому появляются платформы поиска на основе ИИ. Вместо того чтобы объединять извлечение, ранжирование, инференс и обслуживание из нескольких независимых сервисов, они выполняют рабочий процесс в рамках единой распределенной архитектуры. Проблема оптимизации смещается от интеграции компонентов к проектированию самого рабочего процесса.</p> <p>ИИ трансформировал пользовательский интерфейс. Теперь он трансформирует и инфраструктуру извлечения информации, лежащую в его основе. Для организаций, создающих приложения на основе собственных знаний, следующее конкурентное преимущество будет заключаться не только в более крупных языковых моделях или лучших векторных вложениях. Оно будет заключаться в создании рабочих процессов извлечения, которые последовательно предоставляют достоверный, релевантный и своевременный контекст в масштабе.</p> <p>Инженерия извлечения информации стремительно становится одной из дисциплин, определяющих следующее поколение ИИ-нативных приложений.</p> Тим Янг, директор по маркетингу Vespa.ai, рассказывает на портале The New Stack о том, как оптимизация оркестровки … article https://www.itweek.ru/themes/detail.php?ID=235292 Tue, 04 Aug 2026 14:00:12 +0300 <p>Компания «СиСофт Девелопмент» выпустила масштабное обновление линейки Model Studio CS и CADLib Модель и Архив. Новая версия стала очередным этапом развития отечественной платформы технологий информационного моделирования (ТИМ), ориентированной на управление инженерными данными на всех этапах жизненного цикла объекта — от проектирования и согласования до строительства и эксплуатации.</p> <p>Продукт совершенствуется не как набор отдельных функций, а как единая цифровая среда для промышленного и гражданского проектирования и строительства. Если еще недавно одной из главных задач было обеспечить технологическую независимость российских предприятий и заменить зарубежные САПР, то сегодня акцент смещается на повышение эффективности работы инженеров, интеграцию данных и сокращение ручного труда. </p> <p>Такой подход отражен и в долгосрочной дорожной карте развития продуктов. На протяжении последних нескольких лет последовательно расширяются возможности совместной работы, обмена инженерными данными, автоматизации проектирования и поддержки различных инженерных дисциплин. Сегодня в центре внимания находится реализация подхода, при котором информационная модель становится единым источником достоверных сведений для всех участников проекта. Это позволяет не только повысить качество проектирования, но и выстроить непрерывный процесс передачи информации между всеми стадиями жизненного цикла объекта.</p> <p>Очередной релиз развивает сразу несколько ключевых направлений, связанных с постепенным переходом от отдельных функций к единой цифровой среде. В частности, заметно расширены возможности CADLib как среды общих данных: улучшены механизмы управления доступом и ролями пользователей, появились новые инструменты ручной проверки моделей, расширены возможности публикации и обмена данными. Дальнейшее развитие получили средства коллективной работы с информационной моделью. Пользователям стали доступны дополнительные механизмы контроля изменений, управления параметрами проекта, проверки моделей и подготовки данных для разных участников жизненного цикла объекта.</p> <p>Существенные изменения коснулись программных продуктов линейки Model Studio CS. Главная цель этих обновлений — избавить инженера от ручного труда, повысить точность и ускорить проектирование. Так, в Model Studio CS Генплан появились новые средства формирования цифровых геологических моделей (скважины, коридоры, грунты). Расширен блок проектирования автодорог: автоматизировано создание сложных пересечений, водоотводных лотков, нанесение разметки, расстановка знаков и даже учет путей миграции животных.</p> <p>В Model Studio CS Строительные решения обновлены инструменты моделирования металлоконструкций, многослойных стен, витражных систем и отделки. Доработки в генерации строительной документации (например, автоматический подсчет объемов профилей и оптимизация сварных швов) позволяют свести к минимуму объем ручных корректировок на чертежах.</p> <p>В Model Studio CS Трубопроводы значительно улучшен блок генерации изометрических схем. Автоматическая разбивка таблиц, нумерация и фильтры ускоряют выпуск рабочей документации. В Model Studio CS Отопление и вентиляция усовершенствованы встроенные расчеты и доработан подбор прямоугольных тройников по миникаталогу.</p> <p>Для инфраструктурных и энергетических объектов реализованы уникальные расчетные функции. Так, в программном комплексе Model Studio CS ЛЭП автоматизирован подсчет площадей отвода земли и вырубки насаждений, а в Model Studio CS Кабельное хозяйство добавлена генерация кабельных траншей и интеллектуальная раскладка с учетом двухфакторного резервирования. В Model Studio CS Электрика значительно расширен функционал по расчетам в рамках команды Расчет освещения точечным методом, а также добавлены новые элементы для генерации однолинейной схемы.</p> <p>В приложении Model Studio CS ОПС реализована автоматическая расстановка пожарных извещателей и расчет 3D-зон обзора камер видеонаблюдения.</p> <p>Во многих инженерных разделах были расширены средства автоматизации проектирования, формирования спецификаций, проверки на коллизии и подготовки исполнительной документации. Существенно обновлен и общий функционал системы: улучшены инструменты работы с проекциями, импортом/экспортом IFC, редактором оборудования, средствами оформления документации; появилась поддержка новой графической платформы nanoCAD 26. Также добавлена поддержка импорта облаков точек в форматах E57 и LAS, что упрощает использование результатов лазерного сканирования при реконструкции и сопровождении объектов.</p> <p>Большинство изменений новой версии основано на запросах проектных организаций и промышленных предприятий, использующих продукты «СиСофт Девелопмент» в реальных проектах. Такой подход помогает выстраивать продукт не путем механического наращивания функциональности, а последовательно совершенствовать инженерные процессы, опираясь на реальные сценарии применения и запросы отрасли.</p> <p>Новая версия отражает общую эволюцию российских ТИМ-решений. Если несколько лет назад основной задачей было импортозамещение зарубежных САПР, то сегодня развитие идет уже в направлении построения единой среды управления инженерными данными на протяжении всего жизненного цикла объекта. В «СиСофт Девелопмент» отмечают, что архитектура системы изначально проектируется так, чтобы одинаково эффективно работать и в крупных промышленных холдингах, и в небольших проектных организациях.</p> <p>С подробной информацией о функциональных возможностях программных продуктов линейки Model Studio CS можно ознакомиться в описаниях к ним на сайте компании.</p> Компания «СиСофт Девелопмент» выпустила масштабное обновление линейки Model Studio CS и CADLib Модель и Архив … message https://www.itweek.ru/themes/detail.php?ID=235291 Tue, 04 Aug 2026 13:56:38 +0300 <p>Разработчик экосистемы ПО для инфраструктуры Orion soft представил обновление GitOps-платформы Hyperdrive 1.5. В новой версии решения вендор добавил функционал внутреннего портала разработчика (Internal Developer Platform, IDP).</p> <p>Скорость разработки за последний год значительно выросла с распространением ИИ-инструментов. Прогнозы аналитиков говорят о том, что к 2027 году более половины разработчиков ПО будет применять искусственный интеллект или машинное обучение в работе. При этом, другие процессы в инфраструктуре, например, предоставление доступов, настройка DNS и выдача сертификатов развиваются не так быстро. Скорость запуска новых продуктов растет значительно медленнее, чем темпы создания кода. </p> <p>В новой версии GitOps-платформы Hyperdrive реализован функционал IDP. Решение помогает сократить этот разрыв, автоматизировать инфраструктуру и ускорить инфраструктурные процессы. Каталог инструментов самообслуживания помогает командам разработки самостоятельно выстроить прозрачный процесс запуска новых продуктов и получить необходимые ресурсы и доступы. В свою очередь, команда инфраструктуры, ИБ- и DevOps-специалисты концентрируются на своих процессах и развитии систем. Таким образом, бизнес может значительно сократить Time-to-Market.</p> <p>Обновленная GitOps-платформа позволяет создать «золотой путь» процесса вывода новых продуктов на рынок с помощью стандартизации и автоматизации рутинных операций. Благодаря этому Hyperdrive объединяет разрозненные ИТ-команды: каждый отдел получает готовые шаблоны и сервисы для своей работы. Полученные результаты объединяются в конечном продукте. Кроме того, все пользователи платформы могут отслеживать состояние своих проектов с помощью метрик и логов. </p> <p>Версия 1.5 теперь также поддерживает полный цикл управления компонентами Kubernetes-платформы Nova. Появился единый центр инфраструктурного мониторинга для контейнеров Nova, виртуализации zVirt и балансировщиков нагрузки. Реализовано централизованное управление кластерами и доступом, а также добавлена поддержка разделяемых кластеров. Это особенно востребовано для больших инсталляций, где риск ошибки и сложность ручных операций растет.</p> <p>«IDP — востребованный класс решений на международном ИТ-рынке. Крупный современный бизнес активно развивается в этом направлении, и мы уже видим первые успешные кейсы с промышленности и финансах. Мы разрабатываем GitOps-платформу Hyperdrive на основе лучших мировых практик, чтобы предоставить российским заказчикам передовое решение для эволюции ИТ-инфраструктуры», — отметил Павел Лавров, лидер продукта Hyperdrive в Orion soft.</p> <p>В планах вендора развитие инструментов для безопасной разработки в концепции DevSecOps. Это позволит внедрять Hyperdrive как инфраструктурную основу для организации процессов безопасной разработки и соблюдения требований российских регуляторов.</p> Разработчик экосистемы ПО для инфраструктуры Orion soft представил обновление GitOps-платформы Hyperdrive 1.5 … message https://www.itweek.ru/themes/detail.php?ID=235290 Tue, 04 Aug 2026 13:54:54 +0300 <p>Сбер выпустил семейство генеративных моделей Kandinsky WM 1.0. Они обучены генерировать видео, более точно соответствующие законам физики и пригодные для обучения систем Physical AI. В основе моделей нейросеть Kandinsky 5.0 Video Lite, дополнительно обученная на видео с камер роботов, беспилотных автомобилей и записях промышленных процессов. Особенно ценны модели будут там, где реальные съёмки невозможны или сильно затруднены: они могут генерировать видео редких, сложных или опасных сценариев для тренировки роботов и беспилотного транспорта. Код и веса нейросетей опубликованы под лицензией MIT — и доступны всем разработчикам мира бесплатно.</p> <p>Physical AI или физический ИИ — класс систем искусственного интеллекта, которые способны воспринимать физический мир, понимают его динамику и могут управлять реальными устройствами. В отличие от языковых моделей, для физического ИИ просто нет открытых обучающих данных в достаточном масштабе. Собирать такие данные очень сложно и дорого: нужны устройства, датчики, операторы, контролируемая среда. Автомобиль с камерами и датчиками накапливает порядка 5000 часов записей в год, тогда как современным моделям нужны миллионы часов. А многие редкие и сложные сценарии, например, ДТП, экстремальную погоду, отказы оборудования — вообще нельзя воспроизвести вживую.</p> <p>По оценке Яна Лекуна, лауреата премии Тьюринга и одного из «отцов» глубокого обучения, четырёхлетний ребёнок только через зрение получает больше информации, чем содержится во всех текстах, на которых обучены крупнейшие языковые модели. Поэтому следующий рубеж физического ИИ — обучение на видео, а синтетические данные становятся ключевым способом закрыть разрыв в объёмах.</p> <p>Создаваемые моделями Kandinsky WM видео длятся около 5 секунд и отражают отдельные действия: манипуляции с предметами (взял, положил, разрезал), дорожные ситуации (перестроение, проезд перекрёстка), этапы производственных процессов — базовые «кирпичики», из которых складывается обучение автономных систем. Это первое поколение нейросетей на пути к полноценным моделям мира — системам, способным моделировать развитие сцены во времени и служить симуляторами для обучения и тестирования роботов. Кроме генерации данных, такие нейросети могут выступать основой для систем управления: выученная при генерации видео физическая интуиция, переносится в модели действий роботов.</p> <p>Базовые модели генерации видео иногда нарушают простые физические законы: объекты деформируются, перспектива искажается, движения выглядят неестественно. Чтобы повысить физическую достоверность, команда дообучила Kandinsky 5.0 Video Lite на нескольких миллионах реальных видеосцен — автомобили, роботы, промышленные процессы, сложные движения объектов. Отдельные направления, например автомобильные сцены, дополнительно улучшили с помощью обучения с подкреплением: специальные модели оценивали ролики на предмет сохранения формы объектов, геометрии и естественности движения. На основе этой обратной связи Kandinsky учился создавать более физически правдоподобные видео. Подробности о разработке команда написала в статье на Хабре.</p> <p>Kandinsky WM 1.0 — первое открытое семейство российских моделей для генерации физически достоверных данных. В мире таких систем единицы. Модели пригодятся разработчикам беспилотного транспорта, от легковых автомобилей до грузовиков и роботакси, компаниям в сфере промышленной автоматизации: производителям манипуляторов, промышленных, сервисных и антропоморфных роботов, командам, внедряющим компьютерное зрение на производствах и складах. Не меньше они полезны исследователям, университетам и стартапам, которых важно экономить ресурсы при сборе обучающих данных.</p> <p>Модели уже применяет Центр робототехники Сбера для обучения собственных роботов, а также институт AIRI в своем дорожном симуляторе.</p> <p>Денис Димитров, CTO Kandinsky, управляющий директор по исследованию данных Сбера, отметил: «Стремясь понять устройство нашего мира, лучшие умы человечества тысячелетиями открывали физические законы. Но знать нужное уравнение и уметь предсказать реальное событие — это совершенно разные вещи. Чтобы просчитать, как поведёт себя коробка на мокром конвейере, нужно знать огромное количество параметров, которых у нас нет. Есть кейсы, которые вообще не описывается уравнениями, например, поведение пешехода перед беспилотным автомобилем. Человек решает эту задачу не вычислением, а интуицией, накопленной из опыта. Наши модели учатся так же — на видео реального мира — и позволяют „прожить“ виртуально даже те сценарии, которые опасно или невозможно воспроизвести. Это шаг к моделям мира — системам, которые понимают физическую реальность, предсказывают, что произойдёт дальше, и могут действовать в ней самостоятельно».</p> Сбер выпустил семейство генеративных моделей Kandinsky WM 1.0. Они обучены генерировать видео, более точно соответствующие … message https://www.itweek.ru/themes/detail.php?ID=235289 Tue, 04 Aug 2026 13:52:36 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил факторы, которые препятствуют более активному использованию технологий искусственного интеллекта (ИИ) в академической сфере.</p> <p>Несмотря на высокий интерес академического сообщества к ИИ (более 90% ученых, применяющих генеративный ИИ, считают, что он уже приносит пользу для развития их научной области), распространение данной технологии в российской науке пока не стало повсеместным. Ключевые барьеры различаются на уровне организаций и отдельных исследователей.</p> <p>Среди государственных вузов и НИИ более четверти (28%) не используют ИИ. Почти половина из них (45%) объясняют это опасениями получить неверные результаты. К числу наиболее значимых барьеров также относятся нехватка квалифицированных кадров (36%), вычислительных мощностей (33%) и высокие затраты на внедрение технологий (31%). Почти четверть организаций в ИИ не видят потребности (24%) либо не сталкиваются с задачами, которые можно было бы решать с помощью ИИ (23%).</p> <p>Среди ученых, не использующих генеративный ИИ (16% опрошенных), более половины (55%) не считают технологию необходимой для их работы. Еще по 23% называют ее бесполезной либо объясняют отказ от использования отсутствием необходимых навыков. Технические ограничения играют значительно меньшую роль: лишь 9% не применяют генеративный ИИ из-за отсутствия доступа к необходимым сервисам, столько же считают их использование небезопасным. Показательно, что среди тех, кто пока не работает с генеративным ИИ, освоить эти сервисы хотел бы лишь каждый второй (49%), тогда как среди уже использующих их 80% стремятся расширить практику применения.</p> <p>Набор барьеров зависит и от типа ИИ. Для более активного использования генеративного ИИ ключевыми ограничениями становятся недостаток навыков (48%) и времени на освоение технологий (34%). Существенное влияние также оказывают сложности с оплатой (39%) и высокая стоимость подписок на зарубежные ИИ-сервисы (37%), правовая неопределенность их применения в исследованиях (32%), а также опасения, связанные с загружаемыми в ИИ данными и работой с чувствительной информацией (по 29%).</p> <p>Почти треть ученых используют специализированные ИИ-решения: собственные или адаптированные модели, методы и алгоритмы. При этом каждый второй из них (51%) хотел бы расширить их применение. Главными препятствиями остаются нехватка навыков (57%) и времени на освоение технологий (50%), ограниченный доступ к необходимым инструментам (39%), недостаток оборудования (25%) и вычислительных мощностей (20%). Ситуацию усугубляют проблемы, связанные с данными, включая их недостаточный объем (19%), качество (18%) и высокие затраты на сбор и обработку (19%); недостаточное финансирование научных проектов с применением ИИ (25%); а также правовые ограничения на обмен данными между организациями и странами (19%).</p> <p>Проведенные ИСИЭЗ НИУ ВШЭ опросы показали, что и научные организации, и сами исследователи заинтересованы в более широком применении ИИ, однако сталкиваются с теми или иными барьерами. На институциональном уровне основными ограничениями остаются опасения относительно надежности результатов и дефицит ресурсов, тогда как на уровне ученых ключевую роль играют нехватка компетенций и времени на освоение технологий. Преодоление этих барьеров станет важным условием перехода от отдельных практик использования ИИ к его системному внедрению в российской науке.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил факторы, которые препятствуют более активному … message https://www.itweek.ru/themes/detail.php?ID=235282 Tue, 04 Aug 2026 00:00:00 +0300 <p><em>Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как с помощью пяти практических шагов реализовать сервисную архитектуру, повысить операционную устойчивость, оптимизировать управление инцидентами и усилить ИИ-триаж (использование искусственного интеллекта для сортировки, оценки и приоритизации разных задач или инцидентов).</em></p> <p>Когда операционные группы получают оповещение, прежде чем предпринимать какие-либо действия, им необходимо получить ответы на три вопроса:</p> <ol> <li> Что сломалось?</li> <li> Что от этого зависит?</li> <li> Кто за это отвечает?</li> </ol> <p>Без четкой карты взаимосвязей бизнес- и технических сервисов поиск ответов на эти вопросы может превратиться в часы проб и ошибок, разочарование клиентов и даже потерю дохода.</p> <p>Картирование сервисов и проектирование сервисной архитектуры имеют решающее значение для минимизации сбоев в работе сервисов и ускорения восстановления после инцидентов, поскольку они позволяют быстрее и точнее мобилизовать ресурсы и более эффективно проводить анализ первопричин.</p> <p>По мере того, как все больше работы по триажу переходит от людей к автоматизированным и управляемым ИИ системам, становится еще более очевидным, что эти системы хороши настолько, насколько хороша карта сервисов, на основе которой они строят рассуждения.</p> <p>Грамотно спроектированная сервисная архитектура начинается с четкого понимания того, что такое сервис — самодостаточная единица функциональности с одной командой-владельцем. Также важно различать технические и бизнес-сервисы:</p> <ul> <li> Технические сервисы: API, базы данных, системы аутентификации и микросервисы, обеспечивающие работу цифровых операций.</li> <li> Бизнес-сервисы: возможности, ориентированные на клиента и построенные на основе технических сервисов.</li> </ul> <p>Короче говоря, технические сервисы показывают, как все работает «под капотом», а бизнес-сервисы показывают, что фактически испытывает клиент.</p> <p>Для функционирования одного бизнес-сервиса может потребоваться несколько базовых технических сервисов, в то время как один технический сервис может обеспечивать работу нескольких бизнес-сервисов. Именно эта сложность замедляет управление инцидентами, но ее можно устранить с помощью правильного сопоставления сервисов.</p> <h2>Пять шагов для проектирования сервисной архитектуры</h2> <p>Организации могут предпринять следующие шаги для структурирования своих бизнес- и технических сервисов с помощью четкого архитектурного проекта:</p> <h3>1. Начните с бизнес-сервисов, ориентированных на клиента</h3> <p>Начните с сервисов, которые наиболее важны для клиентов, а не рискуйте увязнуть в сложной сети базовых технических компонентов. Это может быть система онлайн-оформления заказов поставщика услуг электронной коммерции или функция обработки страховых случаев в страховой компании. Суть в том, что это то, что клиенты получают и на что они полагаются. В первую очередь команды должны определить эти сервисы и составить их карту, поскольку это поможет инженерам и операционным группам — а также любым автоматизированным системам, работающим от их имени, — определить и приоритизировать базовые технические сервисы, если что-то пойдет не так.</p> <h3>2. Составьте карту поддерживающих технических сервисов</h3> <p>Следующий шаг — понимание того, какие базовые компоненты составляют каждый бизнес-сервис. Без четкого представления об этих зависимостях управление инцидентами становится вопросом догадок, что затягивает сбои, подрывает лояльность клиентов и негативно влияет на доходы в долгосрочной перспективе.</p> <p>Точная карта, связывающая бизнес-сервисы с техническими, предоставляет инженерам и командам цифровых операций мощный аналитический инструмент, позволяющий отсеять лишнюю информацию из оповещений и сузить круг причин сбоя сервиса.</p> <p>Например, сервис банковских переводов может поддерживаться несколькими техническими сервисами, включая сервис авторизации транзакций, API обнаружения мошенничества, сервис платежного шлюза, сервис уведомлений и т. д. Если операционные группы (и автоматизированные системы, призванные им помогать) не видят последствий сбоя в работе сервиса денежных переводов, они рискуют действовать вслепую.</p> <p>Регуляторы по всему миру все чаще формализуют это требование. Например, от финансовых компаний в Евроcоюзе теперь требуется продемонстрировать способность идентифицировать критически важные сервисы и их зависимости, а также восстанавливать их в пределах заданных допусков.</p> <p>Это означает, что хорошая сервисная архитектура становится обязательной для соблюдения нормативных требований в некоторых отраслях.</p> <h3>3. Четко распределите ответственности</h3> <p>Каждый сервис должен иметь одну ответственную команду. Назначьте по одной команде каждой бизнес-функции, чтобы инциденты имели определенный путь реагирования, и обеспечьте наличие одного ответственного для каждого технического сервиса.</p> <p>Это не означает, что команда не может «владеть» несколькими сервисами, но это означает, что если что-то пойдет не так, сразу будет ясно, кого нужно мобилизовать. Такая конкретика снижает операционные затраты на каждый инцидент и уменьшает ненужные привлечения экспертов в предметной области, которые могут быть не в состоянии помочь.</p> <p>Команды, не обладающие такой ясностью, несут как операционные, так и человеческие издержки: сотрудники, неоднократно получающие уведомления об одной и той же нерешенной проблеме, гораздо более подвержены выгоранию.</p> <h3>4. Используйте циклы развертывания в качестве ориентира</h3> <p>Если что-то развертывается независимо, команды должны рассматривать это как автономный сервис и использовать это эмпирическое правило, когда границы технических сервисов не очевидны.</p> <p>Разделение технических компонентов на отдельные сервисы обеспечивает более точное понимание операционных процессов. Благодаря этому при возникновении проблемы легче определить причину и соответствующую команду. Если сервис слишком широк, то сбой остается скрытым.</p> <h3>5. Соедините операционные данные</h3> <p>Последний шаг — объединить операционные данные в единый надежный источник достоверной информации. Интеграции должны объединять сигналы мониторинга, а каталог сервисов должен быть синхронизирован с порталом разработчиков, чтобы сервисная архитектура, графики дежурств и данные об инцидентах находились в одном месте. Кроме того, подключите существующие данные управления конфигурацией к уже существующим источникам данных о сервисах и зависимостях.</p> <p>Цель — единая, постоянно обновляемая система, которая связывает инженеров, операционные группы и любые слои ИИ или автоматизации с необходимыми данными.</p> <h2>Начните с малого, чтобы добиться постепенных успехов</h2> <p>Если все это кажется значительной дополнительной нагрузкой к повседневной работе, лучше разбить задачу на небольшие части. Выберите один из наиболее важных бизнес-сервисов организации и составьте карту его базовых технических сервисов. Определите ответственных, установите политики эскалации и подключите инструменты мониторинга. Затем повторите на другом сервисе.</p> <p>После завершения создания сервисной архитектуры она предоставляет командам цифровых операций контекст, позволяющий оценить масштаб последствий инцидента и определить, какие команды следует мобилизовать. Стоимость каждого последующего инцидента снижается, и создается более прочная основа для операционной устойчивости. По мере автоматизации процесса реагирования на инциденты, именно это сопоставление предоставляет инструментам на основе ИИ необходимый контекст для корректной работы, делая сервисную архитектуру не только решением сегодняшних проблем, но и фундаментом для будущего операционной деятельности.</p> Дебора Камбе, менеджер по маркетингу продуктов компании PagerDuty, рассказывает на портале The New Stack о том … article https://www.itweek.ru/themes/detail.php?ID=235281 Mon, 03 Aug 2026 14:28:33 +0300 <p>AppSec Solutions, российский разработчик решений в области кибербезопасности, объявила о выходе крупного обновления платформы управления безопасной разработкой AppSec.Hub. Релиз направлен на повышение эффективности взаимодействия с инструментами анализа безопасности и предоставление пользователям большей гибкости при настройке процессов DevSecOps.</p> <p>Ключевая задача AppSec.Hub — устранять противоречия между скоростью выпуска цифровых продуктов и требованиями кибербезопасности. Обновленная версия приложения заметно расширяет экосистему интеграций и оптимизирует механизмы контроля качества кода. Команда платформы сфокусировалась на поддержке современных релизов инструментов сканирования и повышении качества данных, поступающих в AppSec.Hub.</p> <p>«Обновление делает AppSec.Hub еще более мощным инструментом для оркестрации DevSecOps-процессов. Мы стремимся к тому, чтобы наши пользователи могли бесшовно интегрировать лучшие решения по ИБ в свой CI/CD, не замедляя при этом цикл разработки и сохраняя полный контроль над безопасностью своих продуктов», — отметили в команде разработки AppSec.Hub.</p> <p>В обновлении расширена совместимость AppSec.Hub с наиболее востребованными инструментами анализа кода: обновлена интеграция с Solar appScreener до версии 3.16 с поддержкой ИИ-модуля для автоматизации триажа уязвимостей, добавлена функция исключения файлов и папок через формат .gitignore в PT Application Inspector, обеспечена поддержка актуальной версии PT BlackBox 3.2. Кроме того, улучшена работа с Aqua Security (автоматическое использование CVSS v2 при отсутствии CVSS v3 от сканера) и YouTrack (ускоренная синхронизация дефектов и автоматическая активация новых конфигураций).</p> <p>В новой версии оптимизирована работа внутренних продуктов экосистемы AppSec.Track и AppSec.Wave — обновлены интеграции, ускорен импорт данных и добавлена выгрузка отчётов по отдельным веткам и проектам. В частности, выбор режимов «информирование» и «блокирование» теперь доступен на всех уровнях иерархии, от компании до конкретного пайплайна, что позволяет точечно настраивать политики безопасности без остановки разработки. Добавлен фильтр по автору изменения статуса и сняты ограничения на смену триажа для уязвимостей, поступающих из внешних инструментов. Внедрили и интуитивный онбординг: подключение организаций теперь выполняется по названию, а карточки сканов дополнены прямыми ссылками на отчеты инструментов анализа.</p> <p>Обновление позволяет существенно сократить время и затраты на внедрение DevSecOps, а управление безопасной разработкой делает более прогнозируемым.</p> AppSec Solutions, российский разработчик решений в области кибербезопасности, объявила о выходе крупного обновления … message https://www.itweek.ru/themes/detail.php?ID=235280 Mon, 03 Aug 2026 14:26:48 +0300 <p>VK и JUG Ru Group провели опрос среди Java-разработчиков. ИИ-инструменты используют 95% разработчиков, 53% обращаются к ним ежедневно.</p> <p>Чаще всего разработчики применяют ИИ для поиска информации — так ответили 74% участников опроса. Для 73% он стал заменой крупнейшей в мире платформы вопросов и ответов Stack Overflow. Также специалисты используют ИИ для написания и проверки кода и генерации тестов. </p> <p>При этом сокращается количество IT-специалистов, участвующих в open-source проектах (проекты с открытым исходным кодом) для обмена опытом. 70% опрошенных не участвуют в таких проектах. В свободное время ими занимаются 16% разработчиков, в рамках рабочих задач — 6%.</p> <p>«ИИ перестал быть для разработчиков экспериментальным инструментом и стал частью ежедневной работы. Более половины респондентов ежедневно используют ИИ для поиска информации и решения технических задач. Для VK важно следить за тем, как меняются подходы Java-сообщества, поскольку этот язык используется в разработке наших высоконагруженных продуктов», — отметил технический директор VK Сергей Ляджин.</p> <p>«95% — это точка, после которой спор о том, войдёт ли ИИ в профессию разработчика, уже закончен. Теперь вопрос в другом: что происходит с инженерной работой, когда агенту можно передать целую задачу — от исследования и планирования до реализации и проверки результата? Кто формулирует намерение, даёт контекст, устанавливает критерии и принимает ответственность? Именно этот разговор станет центральным на нашей осенней Java-конференции 2026», — отметил продюсер JUG Ru Group Алексей Федоров.</p> <p>В исследовании State of Java Insights 2026 приняли участие более 700 Java-разработчиков из разных компаний страны.</p> VK и JUG Ru Group провели опрос среди Java-разработчиков. ИИ-инструменты используют 95% разработчиков, 53% … message https://www.itweek.ru/themes/detail.php?ID=235279 Mon, 03 Aug 2026 14:25:08 +0300 <p>Команда ученых Центра практического искусственного интеллекта Сбербанка опубликовала в открытом доступе библиотеку SIRIN (Semantic Inconsistency Recognition and Inspection Nexus, «Обнаружение и анализ семантических несоответствий»). Она помогает делать ИИ-агентов и языковые модели надежнее: находить в их ответах вымышленные или не подтвержденные исходными данными факты.</p> <p>SIRIN объединяет в одном инструменте разные методы проверки ответов. Разработчики могут сравнивать их, комбинировать и выбирать подходящий вариант для своей задачи. Библиотека умеет проверять как весь ответ целиком, так и отдельные фрагменты текста, показывая, где именно модель могла ошибиться. Кроме того, SIRIN может заранее определить, достаточно ли у ИИ-агента информации для ответа. Это позволяет не только находить ошибки, но и предотвращать их — например, попросить дополнительные данные или отказаться от неподтвержденного ответа.</p> <p>В основе библиотеки лежат исследования Сбера в области детекции галлюцинаций. В частности, учёные из команды исполнительного директора по исследованию данных Центра практического ИИ Сбербанка Максима Макаренко разработали метамодели, которые позволяют повысить точность обнаружения ошибок почти на 30%, используя для обучения всего 250 примеров.</p> <p>Сергей Рябов, старший управляющий директор, директор по AI-трансформации Сбербанка, отметил: «Мы внедряем ИИ на системном уровне и уже обладаем одной из самых сильных экспертиз на рынке благодаря масштабу наших решений. Для повышения надёжности работы моделей мы представили библиотеку SIRIN, которая анализирует обоснованность их ответов. Этот подход уже показал свою эффективность внутри компании в сервисах для работы с клиентами. Мы приняли решение открыть SIRIN для всех компаний, чтобы способствовать развитию рынка. Библиотека доступна всем желающим для использования в своих проектах».</p> <p>Любой разработчик может встроить SIRIN в своего ассистента за несколько минут. Инструмент будет полезен бизнесу, который внедряет большие языковые модели и хочет следить за качеством диалогов с пользователем. Также он пригодится разработчикам ИИ-ассистентов, RAG-систем и ИИ-агентов. Исследователи найдут здесь базу для тестирования новых алгоритмов.</p> <p>Библиотека доступна на российской платформе GitVerse, а также на GitHub. На Hugging Face опубликовано веб-демо.</p> Команда ученых Центра практического искусственного интеллекта Сбербанка опубликовала в открытом доступе библиотеку SIRIN … message https://www.itweek.ru/themes/detail.php?ID=235278 Mon, 03 Aug 2026 09:31:22 +0300 <p><em>Выпуск компанией Moonshot AI модели Kimi K3 возобновил споры о том, кто имеет право создавать продвинутый искусственный интеллект и может ли несанкционированная дистилляция дать правительству США основания для ограничения использования моделей с открытыми весами. Арнал Даяратна, вице-президент </em><em>IDC</em> <em>по исследованиям в области разработки ПО, приводит в корпоративном блоге доводы в пользу того, что открытые веса в сочетании с открытой инфраструктурой для пост-обучения — это основа для более масштабной экосистемы разработки ИИ, а не угроза для неё.</em></p> <p>Выпуск модели Kimi K3 усилил споры об открытых моделях и регулировании в сфере передового ИИ, вызвав новую волну критики в связи с сообщениями о том, что OpenAI и Anthropic обратились к правительству США с просьбой ограничить выпуск открытых моделей, которые связывают с несанкционированной дистилляцией. Возможность того, что правительство США может ограничить или запретить использование таких моделей, вызвала бурную реакцию в отрасли. Коалиция, в которую вошли NVIDIA, Microsoft, IBM, Dell Technologies, Palantir, Hugging Face, Mistral, Mozilla и другие технологические компании, подписала письмо, в котором призвала политиков избегать преждевременных ограничений в отношении моделей с открытыми весами и отличать законную дистилляцию от неправомерного использования. Решение о том, стоит ли запрещать использование открытых моделей, таких как Kimi K3, определит, останется ли разработка продвинутого ИИ прерогативой небольшого числа лабораторий или станет доступной для более широкой экосистемы разработчиков.</p> <p>Более перспективная возможность — создать будущее, в котором возможности ИИ станут доступными, дешевыми, многовариантными и разнородными. Такое будущее зависит от расширения участия в разработке за пределами узкого круга передовых лабораторий и предоставления большему числу организаций возможности развивать ИИ на своих условиях. Открытые веса моделей — это основа, а открытая инфраструктура для пост-обучения — путь от простого доступа к инновациям. Ограничения на публикацию открытых моделей послужат сохранению дефицита в то время, когда начинают формироваться технические основы для создания более широкой и генеративной экосистемы.</p> <h3>Ограничения на использование открытых моделей защитят существующие компании от конкуренции</h3> <p>Запросы от OpenAI и Anthropic представляют дистилляцию как проблему, требующую вмешательства на государственном уровне для ограничения распространения моделей, разработанных другими организациями. Дистилляция — это практика использования результатов работы более мощной модели для обучения или улучшения менее мощной модели. Субъект, который активно обращается к передовой модели в течение многих сеансов, может использовать эти взаимодействия для создания второй модели, которая будет обладать некоторыми возможностями исходной системы. Эта вторая модель будет работать вне поля зрения, контроля доступа и системы безопасности исходного поставщика. OpenAI и Anthropic утверждают, что несанкционированная дистилляция их систем является кражей интеллектуальной собственности и что доступ к открытым моделям, созданным в результате такого копирования, должен быть запрещен.</p> <p>Однако провайдеры закрытых моделей уже контролируют доступ к системам, из которых происходит предполагаемая дистилляция. Они определяют, кто может использовать их модели, какой уровень доступа предоставляется пользователям, какие интерфейсы доступны, какие условия прописаны в договоре и какие виды автоматизированной деятельности влекут за собой принудительные меры. Провайдеры, считающие дистилляцию существенной угрозой, могут усилить аутентификацию, ввести ограничения на количество запросов, выявлять необычные шаблоны запросов, приостанавливать действие аккаунтов, ограничивать автоматическое извлечение данных и менять дизайн интерфейсов, чтобы скрыть особо ценные обучающие сигналы. Они также могут применять договорные права в отношении пользователей, нарушающих четко прописанные условия предоставления услуг. Вопрос о том, почему эти компании добиваются защиты со стороны регулирующих органов в отношении проблемы, которую они в состоянии решить с помощью собственной инфраструктуры, заслуживает пристального внимания.</p> <p>OpenAI и Anthropic добиваются вмешательства регулирующих органов в связи с тем, что модели общего назначения становятся все более доступными. Разрыв в возможностях между передовыми и открытыми моделями сокращается во все большем количестве областей, и предприятиям становится все проще заменять одну систему на другую. Открытые модели позволяют предприятиям размещать их у себя и адаптировать под свои нужды, а в перспективе — создавать специализированные системы для решения задач, для которых провайдеры закрытых моделей не разрабатывали свои продукты. </p> <p>Провайдеры закрытых моделей имеют больше возможностей для установления цен, поскольку немногие другие системы могут обеспечить сопоставимые результаты. Этот авторитет снижается, когда предприятия могут выбирать между несколькими проприетарными сервисами или использовать открытую модель, которую они могут модифицировать и применять в своей инфраструктуре. Даже если организация никогда не внедряла открытую модель, такая модель, оказывает конкурентное давление: сам факт ее существования дает клиентам альтернативу постоянной зависимости от одного поставщика.</p> <p>Не стоит считать, что открытая модель является результатом несанкционированной дистилляции только из-за того, что она открыта. Эффективная открытая модель может быть результатом государственных исследований, независимых экспериментов, использования синтетических и открытых наборов данных, повышения эффективности обучения или совокупной работы более широкого технического сообщества. Схожесть моделей сама по себе не является доказательством неправомерного заимствования. Регулирование, при котором схожесть возможностей рассматривается как доказательство кражи, позволит действующим поставщикам заявлять о своих исключительных правах на различные формы поведения моделей и общий технический прогресс. Государство не должно превращать опасения закрытых провайдеров по поводу контроля доступа в ограничения для открытой конкуренции.</p> <h3>Открытые модели обеспечивают конкуренцию и возможность создавать</h3> <p>Открытые модели дают организациям прямой доступ к системам ИИ, позволяющий проверять и адаптировать их, а затем использовать их там, где это необходимо. Если организация владеет весами модели, она может оценивать ее поведение напрямую, не полагаясь на доступ, предоставляемый небольшим числом частных лабораторий. Такой прямой доступ обеспечивает возможность кастомизации, локального развертывания, воспроизводимости, независимой проверки безопасности, а также организационный контроль над данными и управлением. Участие в разработке ИИ расширяется, когда все больше организаций могут создавать и тестировать системы, а затем совершенствовать их в соответствии со своими требованиями, а не в рамках ограничений, установленных поставщиком.</p> <p>Ни один управляемый сервис не может обеспечить такой же уровень контроля, как открытые модели. Государственные и регулируемые организации получают возможность контролировать условия развертывания, границы доступа к данным и соблюдение нормативных требований в рамках используемой ими инфраструктуры. Исследователи получают возможность изучать поведение моделей, тестировать их на безопасность и публиковать результаты без необходимости получать разрешение от разработчика системы. Независимые разработчики получают возможность развивать технические направления, представляющие значительную ценность в конкретной области или сообществе, даже если они не представляют особого коммерческого интереса для передовой лаборатории. Эти возможности зависят от того, кто владеет весами, а не от доступа к интерфейсу поставщика.</p> <p>Передовой API предоставляет организации доступ к возможностям на условиях, определяемых поставщиком: доступная модель, разрешенные формы использования, ценообразование, ограничения по скорости, политика хранения данных, меры безопасности и сроки внесения будущих изменений. Открытые модели дают другой уровень полномочий. Они позволяют организации проверять модель, использовать ее в рамках подконтрольной ей инфраструктуры, изменять процесс ее обучения, проводить собственные оценки и развивать направления, которые не были предусмотрены первоначальным поставщиком. Разница заключается в том, что в первом случае мы просто потребляем возможности, а во втором — обладаем средствами для их дальнейшего развития. Открытые модели превращают потребителей интеллектуальных технологий в их создателей.</p> <h3>Одних открытых весов недостаточно: пост-обучение тоже должен быть открытым</h3> <p>Пост-обучение — это этап, на котором передовые лаборатории обретают большую часть своего практического преимущества. Без открытой инфраструктуры для пост-обучения открытые веса остаются статичными артефактами. Организация, которая загружает открытую модель, но не имеет инструментов, сред, оценок и воспроизводимых методов, необходимых для ее пост-обучения, может использовать модель в том виде, в котором она была выпущена, но не может изменить ее функциональные возможности. На практике OpenAI, Anthropic и Google, похоже, удерживают свои позиции не столько за счет масштабов предварительного обучения или весов модели, сколько за счет того, что происходит после: масштабируемое обучение с подкреплением, обусловливание использования инструментов, восстановление после сбоев в многоэтапных рабочих процессах, моделирование вознаграждений и накопленный опыт, необходимый для превращения базовой модели в систему, которая надежно работает в производственной среде. Что отличает передовые лаборатории, так это полный набор средств разработки, связанных с этими опубликованными методами: качество обучающих данных, дизайн среды выполнения задач, точность оценок, формирование сигналов вознаграждения и решения команд, которые провели тысячи экспериментов и извлекли уроки из каждой неудачи.</p> <p>Таким образом, экосистема открытой модели должна включать не только загружаемые контрольные точки. Она должна включать инструменты, среду, оценки и воспроизводимые практики, необходимые для проведения полноценного пост-обучения. Без этих компонентов разрыв между использованием модели и развитием на ее основе специализированных возможностей для большинства организаций остается непомерно большим.</p> <p>Эта инфраструктура начинает обретать форму. Открытый проект NeMo RL от NVIDIA предоставляет масштабируемую инфраструктуру для обучения с подкреплением и пост-обучения, а NeMo Gym — среды, которые объединяют наборы данных, средства управления агентами, верификаторы и состояния для обучения и оценки. TRL от Hugging Face поддерживает контролируемую тонкую настройку, обучение с подкреплением, оптимизацию предпочтений и моделирование вознаграждений. OpenEnv предоставляет стандартизированные среды для выполнения агентных задач. Open-R1 предлагает общие обучающие скрипты, наборы данных, инструменты оценки, конвейеры для работы с синтетическими данными и методики разработки, которые другие команды могут воспроизвести и адаптировать под свои нужды. В совокупности эти проекты показывают, что открытое пост-обучение — это уже не просто идея. Многие из его составляющих уже существуют, хотя им ещё предстоит объединиться в единый, широко распространённый и воспроизводимый стек разработки.</p> <p>Сейчас приоритетной задачей является расширение доступности полноценных проектов пост-обучения, которые объединяют модели, наборы данных, среды, функции вознаграждения, инструменты оценки и экспериментальные данные в воспроизводимой форме. Такие проекты позволяют другим командам изучать процесс разработки, воспроизводить его результаты и адаптировать методы под другую модель или область. ПО с открытым исходным кодом стало базовой инфраструктурой именно благодаря такому накопительному эффекту. </p> <p>Открытое пост-обучение не сделает разработку продвинутых моделей лёгкой. Организациям по-прежнему будут требоваться значительные вычислительные мощности, высококачественные данные, эксперты-оценщики, специализированные среды и технические знания для диагностики неудачных запусков обучения. Важность этого подхода заключается в том, что он позволяет разорвать замкнутый круг, в котором знания, необходимые для создания продвинутого ИИ, сосредоточены в небольшом количестве лабораторий.</p> <h3>Экосистема открытых моделей позволяет развиваться множеству видов ИИ</h3> <p>Открытые модели и анализ открытого пост-обучения раскрывают важную истину, которую часто скрывает нынешняя структура рынка: у ИИ нет единого направления развития. Передовые модели от OpenAI, Anthropic и Google представляют собой особую и коммерчески выгодную концепцию развития ИИ, в которой упор делается на программирование, математические и научные методы, широкий охват знаний и гибкую работу в различных областях. Эта концепция занимает важное место в более широком поле исследований в области ИИ. Но возможности, которым отдают приоритет несколько передовых лабораторий, не должны становиться универсальным стандартом, по которому оцениваются все ИИ-достижения.</p> <p>Различные виды ИИ — это разные конфигурации знаний, восприятия, суждений и практических навыков, которые соответствуют разным стандартам совершенства. Научный ИИ выявляет закономерности в структуре белков или определяет перспективные направления в сложной области исследований. Инженерный ИИ учитывает физические ограничения, требования безопасности, эффективность и технологичность. Другие виды ИИ придают большее значение эстетическому суждению, внимательности, культурной компетентности, педагогике, вкусу или практической мудрости. Дизайнерский ИИ создает дом, отражающий воспоминания, потребности и повседневные ритмы людей, которые в нем живут. Культурный ИИ организует витрину книжного магазина, которая вызывает неожиданные ассоциации и приглашает к открытиям. Развивающий ИИ помогает семье выбрать медиа, подходящие для конкретного ребенка. Практический, или реляционный ИИ формирует семейный отдых, в котором сбалансированы финансовые аспекты, энергозатраты, доступность, конкурирующие интересы и впечатления, которые запомнятся разным людям.</p> <p>Каждый из этих видов ИИ предполагает различное сочетание фактических знаний, восприятия, эмпатии, понимания контекста, технической компетентности и здравого смысла. Некоторые формы ИИ отдают предпочтение математической правильности, научной обоснованности или инженерной точности. Другие отдают предпочтение красоте, согласованности, заботе, приспособленности, доверию, удовольствию или пониманию того, что будет работать у конкретных людей в конкретных условиях. Система может превосходно соответствовать одному набору стандартов и оставаться непримечательной по сравнению с другим, даже если она демонстрирует высокие результаты по широкому кругу критериев.</p> <p>Уважение к множественному ИИ остается совместимым со строгими стандартами достоверности, доказательности, компетентности, последовательности и совершенства. Различные точки зрения не стирают различия между правдой и ложью. Каждая форма ИИ должна соответствовать стандартам, соответствующим ее заявлениям и целям. Достоверный ИИ может принимать различные формы, служить различным целям и не поддаваться сведению к единой иерархии, определяемой эффективностью модели общего назначения.</p> <p>Таким образом, рынок ИИ с многообразной структурой будет иметь множество научных, технических, культурных, коммерческих и практических аспектов. Поставщики услуг общего назначения будут продолжать конкурировать за широкий кругозор, надежность и качество управляемых услуг. Специализированные разработчики, учреждения и сообщества могли бы создавать возможности, основанные на знании предметной области, эстетических суждениях, культурных знаниях, практическом опыте и различных концепциях успеха. Экосистема открытых моделей дает этим формам ИИ возможность развиваться, проходить испытания и доказывать свою ценность — процветая или нет, на их собственных условиях.</p> <h3>Выбор между дефицитом и изобилием</h3> <p>По мере того как уровень моделей становится все более доступным, а разрыв в возможностях сокращается, передовые разработки будут все больше отличаться по эксплуатационным качествам, которые требуются предприятиям: предсказуемость, задержка, время безотказной работы, региональная доступность, безопасность и соответствие нормативным требованиям — все это зависит от уровня управления, которое может обеспечить только поставщик с хорошими ресурсами. Эти характеристики оправдывают масштабные корпоративные закупки и зависят от объема капиталовложений, доступа к вычислительным ресурсам и инвестиций в инфраструктуру, для поддержки которых у передовых лабораторий есть уникальные возможности. Открытые модели и многовалентные формы ИИ расширяют рынок, предоставляя возможность развивать дифференцированный потенциал более широкому кругу организаций, в то время как передовые поставщики конкурируют за предоставление надежных, управляемых систем общего назначения корпоративного масштаба. В результате возникает экономика ИИ с бóльшим количеством разработчиков, новыми формами интеллекта и усилением конкурентного давления на всех уровнях.</p> <p>Споры об открытых моделях — это нечто большее, чем дискуссии о дистилляции или разногласия по поводу политики доступа. Они касаются того, останется ли возможность разрабатывать продвинутый ИИ в руках узкого круга поставщиков или же она станет более доступной, дешевой и будет охватывать весь спектр областей и организаций, которые в ней нуждаются. Запрет на открытые релизы сохранят дефицит в тот момент, когда начинают складываться условия для изобилия. Открытые модели — это основа. Открытое пост-обучение — это путь развития. От того, какое решение будет принято сейчас, зависит, какое будущее нас ждет.</p> Выпуск компанией Moonshot AI модели Kimi K3 возобновил споры о том, кто имеет право создавать продвинутый … article https://www.itweek.ru/themes/detail.php?ID=235276 Mon, 03 Aug 2026 09:11:07 +0300 <p><em>Более 70% крупных российских компаний используют искусственный интеллект в рабочих процессах. Публичные ИИ-сервисы изначально не предназначены для работы с корпоративными и персональными данными, поэтому бесконтрольное внедрение технологии создает для бизнеса скрытые угрозы.</em></p> <p><em>Рассмотрим главные риски и способы их снизить.</em></p> <h3>Утечки конфиденциальных данных</h3> <p>Сотрудники регулярно загружают в открытые ИИ-сервисы рабочие документы: договоры, финансовые отчеты, планы запусков. Информация попадает в среду, которую компания не контролирует. Техника промпт-инъекций позволяет злоумышленникам извлекать из моделей чужие конфиденциальные данные: достаточно сформировать набор специальных запросов, и нейросеть с определенной вероятностью выдаст сведения, которые ранее по невнимательности загрузил другой пользователь.</p> <p>Риск возрастает, когда компания бесконтрольно подключает ИИ-агента к бизнес-процессам и потокам корпоративных данных. В этом случае утечка может произойти через самого агента: он получает широкий доступ к внутренним системам, действия его при этом почти никто не отслеживает.</p> <h3>Советы без учета контекста</h3> <p>Нейросеть не знает внутренних процессов конкретной компании. Она опирается на обобщенные данные из открытых источников, поэтому ее рекомендации могут оказаться нерелевантными. Например, модель способна предложить исключить необходимый технологический процесс или подтолкнуть к неэффективным инвестициям, поскольку не погружена в нюансы устройства бизнеса.</p> <p>Любой совет, стратегию или документ, сгенерированный ИИ, нужно верифицировать с учетом реальной ситуации в бизнесе. Модель выдает правдоподобный текст, однако полная ответственность за решение всегда остается на сотруднике.</p> <h3>Юридические и репутационные риски</h3> <p>Контент, созданный нейросетями, не имеет исчерпывающей правовой защиты и может нарушать авторские права третьих лиц. Помимо проверки качества контента, перед использованием таких материалов также необходимо проверять информацию на соответствие законодательству и уточнять ее юридический статус.</p> <p>Отдельная зона риска связана с репутацией. ИИ может предлагать маркетинговые стратегии, которые нарушают этические нормы или опираются на стереотипы, неприменимые к целевой аудитории. Публикация подобных материалов оборачивается для бренда репутационными потерями. Валидировать информацию от ИИ должен человек, который понимает ценности компании и особенности ее клиентов.</p> <h3>Как снизить риски</h3> <p>Безопаснее всего использовать ИИ-инструменты, размещенные в контуре компании или у доверенного сервис-провайдера: бизнес либо самостоятельно управляет моделью, либо контролируемо делегирует ИИ-функции третьей стороне с защищенной обработкой данных.</p> <p>Снизить угрозы помогает набор базовых правил:</p> <ul> <li> определить, какие данные запрещено загружать в публичные ИИ-сервисы, и закрепить это в регламенте;</li> <li> использовать корпоративные ИИ-решения с защищенной обработкой данных без их сохранения и использования для обучения моделей;</li> <li> ограничить доступ ИИ-агентов к внутренним системам и логировать их действия;</li> <li> верифицировать сгенерированный контент: проверять факты, юридический статус и соответствие ценностям бренда;</li> <li> обучать сотрудников правилам работы с нейросетями и разбирать реальные инциденты.</li> </ul> <p>Искусственный интеллект стоит воспринимать как мощный инструмент, требующий тех же правил гигиены, что и любая корпоративная система. При работе с ней необходимо выстроить иерархию доступов, регламенты работы с данными, обучение сотрудников. Тогда технология будет приносить пользу без скрытых издержек.</p> <p>#IMAGE_235277#</p> Более 70% крупных российских компаний используют искусственный интеллект в рабочих процессах. Публичные ИИ-сервисы … article Леонид Плетнев, бизнес-партнер по информационной безопасности “1С-Битрикс” https://www.itweek.ru/themes/detail.php?ID=235274 Fri, 31 Jul 2026 12:39:15 +0300 <p>Аналитическая компания Apple Hills Digital опубликовала отчёт «Рынок IaaS в России: прогноз до 2030 года и позиционирование лидеров» и впервые — карту ключевых игроков. В фокус исследования вошли восемь крупнейших провайдеров публичной облачной инфраструктуры: Cloud.ru, K2 Cloud, MWS, РТК ЦОД / Турбо Облако, Selectel, T1 Cloud, VK Cloud, Yandex Cloud.</p> <p>Рынок продолжает расти на фоне цифровизации и импортозамещения. Объём рынка публичного IaaS в России в 2025 году составил 96 млрд рублей.</p> <p>При среднегодовом темпе роста около 20% объем рынка к 2030 году более чем удвоится и достигнет 241 млрд рублей. Рост поддерживают цифровизация отраслей, потребность в гибком доступе к вычислительным ресурсам без капитальных вложений и импортозамещение. Среди сдерживающих факторов — высокая совокупная стоимость владения и низкая зрелость Developer Experience (удобство и скорость работы инженерных команд с облачной платформой — от развёртывания «из коробки» до готовых инструментов интеграции).</p> <p>AI/ML и гибридная инфраструктура — новые поля конкуренции.</p> <p>Исследование выявило ключевые тенденции рынка:</p> <ul> <li>надёжность остаётся приоритетом № 1. 72% заказчиков называют надёжность и стабильность инфраструктуры главным критерием выбора провайдера. Безопасность и соответствие стандартам ставят на второе место 54% респондентов;</li> <li>конкуренция смещается в сторону AI. Свыше 80% компаний отмечают влияние AI/ML на потребление ресурсов, а 24% фиксируют резкий рост использования GPU-инстансов. Среди тех, кто планирует увеличить бюджет на IaaS, 42% закладывают в него именно AI/ML-нагрузки;</li> <li>гибрид и cloud-native становятся нормой. 52% компаний используют гибридную инфраструктуру, а Managed Kubernetes, инфраструктура как код (IaC) и self-service вошли в базовый набор инструментов для пользователей облака. Популярность гибридной инфраструктуры растёт на фоне потребности бизнеса в гибком доступе к вычислительным ресурсам без крупных капитальных вложений в собственную инфраструктуру. Дополнительный фактор — требования к локализации данных на территории РФ;</li> <li>контроль затрат — узкое место рынка. 75% компаний пока не автоматизируют контроль облачных расходов, и это одна из главных точек роста для всего рынка. Так, среди компаний, планирующих увеличить бюджет на IaaS, 34% отдельно закладывают в приоритеты аудит и оптимизацию расходов. Не последнюю роль играет и зрелость инструментов самих провайдеров — прозрачность биллинга и удобство тегирования расходов пока не везде реализованы на достаточном уровне.</li> </ul> <p>Отчёт рассматривает восемь ключевых провайдеров IaaS на одной позиционной карте рынка по двум независимым осям: горизонтальная «Стратегия, инновации и надёжность» и «Технологические возможности». Критерии оценки были взвешены в соответствии с результатами опроса корпоративных заказчиков по приоритетным требованиям к провайдеру IaaS. </p> <p>Исследование основано на трёх источниках: детализированных данных, предоставленных провайдерами для целей исследования, интервью с руководством провайдеров, количественном опросе корпоративных пользователей облачной инфраструктуры и экспертной оценке аналитиков AHD.</p> <p>«По мере повышения зрелости рынка конкуренция между лидерами принимает более многоплановую форму. Исследование показало, что цена уже не является главным фактором выбора провайдера: компании переносят в облако все более серьезные нагрузки и чувствительные данные, и применяют широкий набор критериев выбора, отдавая приоритет надёжности, безопасности и удобства интеграции облачного сегмента в свой ИТ-ландшафт», — отметил Василий Пименов, руководитель программы исследований российского рынка Apple Hills Digital</p> <p> </p> Аналитическая компания Apple Hills Digital опубликовала отчёт «Рынок IaaS в России: прогноз до 2030 года … message https://www.itweek.ru/themes/detail.php?ID=235271 Fri, 31 Jul 2026 11:39:23 +0300 <p><em>Low-code снижает нагрузку на ИТ-команды и ускоряет решение задач. Однако без правильного управления изменениями с этой платформой бизнес получает «зоопарк» приложений и постепенно теряет контроль над собственным цифровым контуром. Рассмотрим, почему портфель low-code может превратиться в технический долг и как этого избежать.</em></p> <h3>Обратная сторона быстрых изменений</h3> <p>Технологию low-code часто начинают внедрять с рациональной управленческой мотивацией: бизнесу нужно быстрее запускать изменения, проверять гипотезы, автоматизировать локальные процессы и снижать нагрузку на традиционные ИТ-команды. На уровне отдельных проектов положительный эффект такого подхода очевиден: приложения выпускаются быстрее, и бизнес раньше получает результат. Однако у повышенной скорости есть обратная сторона.</p> <p>Low-code ускоряет не только создание решений, но и накопление изменений в компании. Если ими не управлять, через некоторое время вместо гибкого цифрового контура можно получить «зоопарк» приложений: множество локальных решений с разными владельцами, правами доступа, интеграциями, версиями, правилами сопровождения и уровнями качества.</p> <p>Такая ситуация складывается не из-за проблем в каждом конкретном приложении. По отдельности решения могут успешно выполнять полезные функции — например, управлять согласованием, обрабатывать заявки, автоматизировать отчетность или связывать несколько внутренних систем. Риски возникают на уровне совокупности.</p> <p>Когда на базе low-code появляются десятки или сотни приложений, компания должна понимать, где они находятся, какие данные обрабатывают, кто ими владеет, какие процессы от них зависят, кто имеет доступ к решениям, как они обновляются и что будет происходить при сбоях. В противном случае low-code постепенно превращается в технический долг, причем это может происходить не только из-за некачественного кода.</p> <h3>Механизм накопления технического долга</h3> <p>Технический долг появляется везде, где в бизнес-процесс входит low-code-решение без полноценного жизненного цикла. Это значит, что приложение создали, запустили, начали использовать, но не включили в реестр, не назначили владельца, не описали интеграции, не согласовали правила доступа, не определили порядок поддержки и вывода из эксплуатации.</p> <p>На ранней стадии это почти незаметно: приложение работает, пользователи довольны, а бизнес-заказчик быстро получает нужные результаты. Но совсем скоро могут появиться серьезные трудности, если изменится процесс, уйдет сотрудник, который понимает логику решения, обновится платформа, появится новое требование безопасности или перестроится интеграция со смежной системой. В таком случае критичный участок процесса будет зависеть от приложения, которое никто не будет полноценно сопровождать.</p> <p>Для крупных компаний это особенно чувствительно. В них даже небольшое локальное решение может быть связано с клиентскими данными, финансовыми операциями, договорным контуром, внутренними согласованиями или требованиями регуляторов. Если таких решений много и они не описаны, поверхность риска особенно велика, но руководители могут ее не замечать.</p> <p>Агенты на базе искусственного интеллекта усиливают потенциал развития негативных факторов на фоне пробелов в управлении изменениями. Если low-code ускоряет создание приложений и автоматизацию процессов, то ИИ-инструменты позволяют быстрее формировать сценарии действий в корпоративных системах. Это может быть полезно, только если компания понимает, какие действия выполняются, от чьего имени, с какими правами и цифровым следом. Без такого контроля скорость начинает работать против управляемости.</p> <h3>Пять признаков неуправляемости</h3> <p> Можно выделить пять основных признаков неуправляемого «зоопарка» low-code-решений:</p> <ul> <li> <strong>Дублирование функций</strong><strong>.</strong> Например, оно возникает, если разные подразделения создают похожие приложения для заявок, отчетности, согласований или контроля задач. Каждое из них решает локальную проблему, но вместе они усложняют архитектуру, размывают стандарты и мешают масштабировать эксплуатацию компонентов.</li> <li> <strong>Неизвестные владельцы</strong><strong>.</strong> Бывает так, что приложение используется, но непонятно, кто отвечает за его развитие, поддержку, данные и принятие решений при изменении процесса. В результате ИТ-команда становится заложником уже работающего решения: бизнес требует стабильности, но формальной ответственности и ресурсов на сопровождение нет.</li> <li> <strong>Неописанные интеграции</strong><strong>.</strong> Low-code-решения могут быть связаны с CRM (системой управления взаимоотношениями с клиентами), ERP (системой планирования ресурсов предприятия), документооборотом, хранилищем данных, почтой, календарями или внешними сервисами. Если эти связи не зафиксированы, любое изменение в смежной системе может привести к сбою, который сложно быстро диагностировать.</li> <li> <strong>Разная зрелость доступа и безопасности</strong><strong>.</strong> Например, такая проблема возникает, если в одном приложении права настраивают оптимально, в другом их выдают слишком широко, а в третьем используют временные учетные записи, которые становятся постоянными. Пока решений мало, можно вручную обеспечивать безопасность в подобных ситуациях. Когда приложений становится много, ручной контроль перестает работать.</li> <li> <strong>Отсутствие правил вывода из эксплуатации</strong><strong>.</strong> В компаниях часто описывают процедуры запуска новых решений, но гораздо реже — регламенты их закрытия. В результате старые приложения продолжают работать, хранить данные, применять права доступа и зависеть от платформы — даже после изменения бизнес-потребности.</li> </ul> <h3>Пять составляющих управляемого контура</h3> <p>Зрелый подход к low-code начинается не с запретов и попыток вернуть все изменения в зону классической разработки. Это было бы неправильно: компаниям действительно нужна скорость, просто ее необходимо встроить в управляемый контур. Он формируется из пяти основных составляющих:</p> <ul> <li> <strong>Единый реестр low-code-приложений</strong><strong>.</strong> Бизнес должен владеть информацией не только о крупных системах, но и обо всех прикладных решениях, которые создаются на платформах low-code. Должны быть доступны сведения о назначении, владельцах, пользователях, подключенных данных, интеграциях, критичности, статусе, версиях и правилах поддержки приложений.</li> <li> <strong>Модель владельцев</strong><strong>.</strong> У каждого решения должен быть бизнес-владелец, отвечающий за цель, процесс и эффект. Также необходимо описывать технический контур ответственности для всех low-code-приложений: кто их сопровождает, обновляет, проверяет безопасность и принимает решения при изменениях.</li> <li> <strong>Архитектурные ограничения</strong><strong>.</strong> Не все задачи подходят для исполнения на базе low-code. В одних случаях эта платформа дает быстрый и качественный результат, а в других решения лучше реализовывать иначе. Провести такую границу помогут заранее разработанные критерии применимости. Они должны отвечать на вопросы, какие процессы можно автоматизировать в контуре low-code, какие данные допустимо обрабатывать, какие интеграции разрешены и какие сценарии требуют участия архитектора или службы безопасности.</li> <li> <strong>Правила сопровождения</strong><strong>.</strong> Работа над приложением не заканчивается в момент запуска. Его нужно обновлять, тестировать, поддерживать, контролировать доступ, отслеживать инциденты и стоимость владения. Без этих составляющих можно оценить только скорость разработки без учета всех факторов, влияющих на цену решения.</li> <li> <strong>Управление портфелем</strong><strong>.</strong> Low-code-приложения нужно рассматривать не как набор разрозненных инициатив, а как портфель изменений. В нем видны повторяющиеся сценарии, потенциальные типовые компоненты, решения с высоким риском, устаревшие приложения и зоны, в которых нужен не локальный инструмент, а системная автоматизация.</li> </ul> <h3>От количества к качеству</h3> <p>В повышении управляемости портфеля low-code важную роль играет центр компетенций. Его задача совсем не в том, чтобы оттянуть на себя все процессы разработки и превратиться в бюрократический фильтр. Он должен задавать правила, помогать бизнесу выбирать правильные сценарии, поддерживать каталог решений, развивать типовые шаблоны, контролировать качество и снижать риски масштабирования.</p> <p>Зрелая работа с low-code в крупной корпорации требует комплексного подхода и при вовлечении системного интегратора. Его участие не сводится к внедрению платформы или сборке первых приложений. Он должен выступать как партнер, который помогает выстроить управляемую систему: от обследования и создания архитектурных правил до разработки ролевой модели, интеграций, сопровождения и развития портфеля решений.</p> <p>Low-code действительно может ускорить изменения в компании, но если у приложений нет владельцев, реестра, правил обновления, архитектурных ограничений и понятного места в ИТ-ландшафте, эта платформа станет не драйвером цифровизации, а скорее источником будущих инцидентов. Поэтому главный вопрос не в том, сколько приложений компания может быстро создать на базе low-code, а в том, сколько из них она сможет безопасно сопровождать, развивать и контролировать через год, два или три. Именно это отделяет эксперимент с технологией от реализации полноценной системы корпоративных изменений.</p> <p>#IMAGE_235272#</p> Low-code снижает нагрузку на ИТ-команды и ускоряет решение задач. Однако без правильного управления изменениями … article Михаил Миронов, директор отделения low-code-решений группы компаний IBS https://www.itweek.ru/themes/detail.php?ID=235264 Fri, 31 Jul 2026 00:00:00 +0300 <p><em>Автономный бизнес будущего вовсю строится. Определенные навыки уже пользуются высоким спросом — и они могут помочь вам выделиться, рассказывают опрошенные порталом </em><em>ZDNet</em> <em>эксперты.</em></p> <p>Искусственный интеллект поддерживает развитие автономного бизнеса, где некоторые роли, которые мы сегодня считаем само собой разумеющимися — от базовых операционных задач до принятия решений — выполняются агентами, способными обнаруживать, вести переговоры и совершать сделки.</p> <p>Широко распространены опасения, что эта эпоха автономии будет означать меньше работы для профессионалов, особенно в ИТ-отделах. Однако, как постепенно становится ясно, будущее работы потребует тщательного сочетания человеческого опыта и возможностей ИИ, когда профессионалы будут эффективно и продуктивно работать со своими коллегами-агентами.</p> <p>Итак, какие навыки помогут вам преуспеть на агентном рабочем месте будущего? Эксперты предполагают, что лучшие перспективы будут иметь три типа профессионалов: технически подкованные специалисты по поддержке, корректировщики курса агентов и ориентированные на результат сотрудники.</p> <h3>1. Технологически подкованные специалисты по поддержке</h3> <p>Хотя сегодня основное внимание уделяется автономной работе агентов, для максимального использования возможностей ИИ необходимы сильные внутренние технические возможности, считает Алекс Рид, старший менеджер по корпоративным продуктам в области данных энергетической компании EDF UK.</p> <p>Его команда по работе с данными помогает более чем 1000 пользователям использовать агентный ИИ в масштабах всей компании. Эта команда находится в центре федеративной модели «хаб-узлы» (hub-and-spoke), где специалисты по данным и цифровым технологиям сосредоточены на технологической поддержке, а бизнес-подразделения — на создании ценности.</p> <p>«Контекст — это главное для ИИ, — говорит Рид. — Нашим инженерам в работе с агентными и ИИ-ориентированными сервисами необходима высокая квалификация для создания вспомогательных возможностей, взаимодействующих с этими сервисами».</p> <p>Его команда использует технологии Snowflake, такие как Semantic Tables и Horizon Data Catalogs, для определения ресурсов данных и обеспечения их понятности для агентов ИИ. Затем команда создает возможности, используя агент по кодированию Snowflake CoCo на основе платформы данных этой компании.</p> <p>Один из примеров — инструмент, помогающий сотрудникам сервисного центра обрабатывать запросы клиентов. Команда Рида разработала с использованием CoCo агента, который извлекает информацию из платформы данных Snowflake и предоставляет аналитические данные в пользовательском интерфейсе Slack для сотрудников. «Инженер берет то, что производит такой инструмент, как CoCo, и немного улучшает это или, возможно, адаптирует для повышения точности», — рассказывает он.</p> <p>Самир Вуйюру, директор по ИИ и продуктам компании Capita, — еще один лидер в цифровой сфере, изучающий, как его организация может использовать агентные технологии, и квалифицированные специалисты также играют в этом процессе особую роль.</p> <p>Capita создала стек AI Catalyst, который фокусируется на наблюдаемости процессов и показывает, как автоматизация рабочих процессов может повысить операционную эффективность.</p> <p>По словам Вуйюру, эти исследования привели его к выводу о необходимости оттачивать свои технические навыки уже сейчас и искать способы сочетать свой опыт с агентными инструментами для создания сервисов нового поколения, приносящих бизнесу ценность. «Начните работать с ИИ каждый день, — советует он. — Мы сделали значительные инвестиции в предоставление каждому из тысяч наших сотрудников доступа к инструментам ИИ. И те, кто освоил ИИ, а это подавляющее большинство, к моему удивлению, в восторге от него и используют ежедневно».</p> <h3>2. Корректировщики курса агентов</h3> <p>Однако, хотя профессионалы могут повысить свою производительность, используя новые технологии, агентный ИИ не может работать в полной изоляции.</p> <p>Рид отмечает, что лучшие ИТ-специалисты работают с экспертами в предметной области, обладающими глубокими знаниями бизнеса, чтобы обеспечить эффективную работу агентов.</p> <p>«Хотя я с восторгом говорю о таких инструментах, как CoCo и Semantic Tables, мы по-прежнему полагаемся на ведущих экспертов, обладающих 20-30-летним опытом работы в энергетической отрасли, — говорит он. — Успех невозможен без применения этих экспертных знаний, чтобы помочь агентам ИИ быть более продуктивными и точными. Кроме того, когда возникают технические проблемы или, возможно, неточности, вам нужен кто-то, кто понимает технические и предметные возможности для корректировки курса».</p> <p>Это мнение разделяет и Стивен Вуд, операционный директор Rathbones Asset Management, который считает, что профессионалам в эпоху агентов — будь то в ИТ-отделе или в бизнес-функциях — необходимо перейти к новому способу работы.</p> <p>Хаотичные, импровизированные структуры традиционного офиса, где люди работают над задачами и стремятся к достижению целей проекта, уходят в прошлое. На смену им приходит новая система взаимоотношений, в которой профессионалы контролируют своих коллег-агентов.</p> <p>Отмечая сложную природу процессов совместной работы, Рид говорит, что «сейчас нам действительно нужны эксперты, которые знают свое дело, участвуют в процессе и осуществляют окончательный контроль и ставят галочку».</p> <p>По словам Вуда, подобный контроль является естественным элементом в его строго регламентированном и ориентированном на процессы бизнесе. Однако он признает, что трансформация рабочего места в основанное на агентном взаимодействии создаст значительные проблемы для всех. «Это будет совершенно другой способ ведения дел, — сказал он. — Поэтому возникнет некоторое трение, верно? Но успех будет сопутствовать тем компаниям и те людям, которые примут агентный ИИ, поймут его и захотят вывести его на новый уровень».</p> <h3>3. Сотрудники, ориентированные на результат</h3> <p>Признание потенциальной мощи ИИ — это только отправная точка. Четкое понимание долгосрочной бизнес-цели имеет решающее значение для внедрения агентов. По словам Дэна Чероубриера, технического директора Formula E, преуспевать будут профессионалы с таким подходом. Люди, обладающие этими навыками, помогут своим организациям получать экономическую выгоду от ИИ</p> <p>«Неудачниками окажутся те компании, которые берут свои существующие процессы, построенные вокруг людей, отделов и разрозненных структур, и пытаются создавать агентов для этих процессов, а не для достижения желаемых бизнес-результатов», — говорит Чероубриер.</p> <p>Он приводит пример разработки ПО, в которой агентный ИИ трансформирует традиционные методы. Талантливые инженеры концентрируют свои экспертизу на начале процесса разработки, чтобы направить агентов в нужное русло, не ожидая более поздних этапов.</p> <p>«Если говорить о результате при написании приложения, то раньше экспертные знания подключались в последнюю очередь — кодирование в конце и тестирование в некоторой степени, — говорит Чероубриер. — Теперь, с агентами, эти знания должны применяться на начальном этапе, при определении требований. Если вы с самого начала не понимаете, что вам нужно сделать, то, я думаю, у вас возникнут трудности».</p> <p>Мурали Сваминатан, технический директор компании Freshworks, также подчеркивает важность четкого определения бизнес-целей. Он считает, что квалифицированные специалисты должны сначала убедиться, что агенты обеспечивают правильные результаты, прежде чем применять технологию к бизнес-процессам. «Удостоверьтесь, что всё действительно работает, воспроизводимо, а затем включите технологию, — говорит он. — Вместо того чтобы попытаться включить всё сразу и столкнуться с тоем, что это не работает, следует попробовать несколько вариантов, добиться успеха, укрепить уверенность и доверие, а затем внедрить сервис для всех».</p> <p>Таким образом, агентам потребуется тщательное руководство. И хорошая новость для профессионалов, по словам Луизы Ньюбери-Смит, руководителя подразделения Zoom в Великобритании и Ирландии, заключается в том, что успешное достижение целей с помощью агентных технологий будет в значительной степени человекоцентричным процессом.</p> <p>«Вы должны лично вкладываться в любую деятельность, которую вы выполняете, и в цели, которых вы стремитесь достичь. Речь идёт о том, чтобы ИИ расширял возможности человека, а не заменял его. Именно такой подход позволяет всем оставаться востребованными и создавать будущее», — говорит она.</p> Автономный бизнес будущего вовсю строится. Определенные навыки уже пользуются высоким спросом — и они могут помочь вам … article https://www.itweek.ru/themes/detail.php?ID=235270 Thu, 30 Jul 2026 14:14:02 +0300 <p>После анализа индивидуальных практик использования искусственного интеллекта российскими учеными Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ впервые оценил, насколько эти технологии интегрированы в деятельность государственных организаций сферы науки — вузов и НИИ.</p> <p>ИИ находит широкое применение в деятельности организаций сферы науки, оптимизируя их бизнес-процессы и практики. ИИ-решения используются в 72% государственных вузов и НИИ, чаще всего — для проведения научных исследований (62% организаций).</p> <p>Вузы внедряют ИИ-решения в целом несколько активнее, чем НИИ (75% против 67%). Наиболее заметны различия в административных и коммуникационных процессах. Так, ИИ используют для внешних коммуникаций, включая продвижение результатов исследований, 40% вузов и лишь 18% НИИ, для управления организацией — 24% и 10% соответственно, для управления персоналом — 12% и 2%. При этом непосредственно в научных исследованиях различия практически отсутствуют: ИИ применяют 60% вузов и 64% НИИ.</p> <p>Чем крупнее организация, тем активнее она внедряет ИИ. Во внутренних процессах эти технологии используют 63% организаций с численностью до 500 сотрудников; 73% организаций, где работают <nobr>501–1000 человек;</nobr> 82% организаций с численностью <nobr>1001–2000 сотрудников;</nobr> и 92% крупнейших организаций (2000+ сотрудников). Во многом это связано с состоянием цифровой инфраструктуры. Крупные организации значительно чаще располагают облачными сервисами (69% против 49% среди остальных), серверными кластерами (73% против 35%), собственными центрами обработки данных (37% против 11%) и суперкомпьютерами (37% против 5%).</p> <p>Индивидуальное использование ИИ заметно опережает институциональное. По оценкам руководителей, ученые используют ИИ уже в 94% организаций, однако в большинстве случаев — на уровне отдельных исследователей. Только 4% руководителей считают, что ИИ используют большинство сотрудников их организации, еще в 27% — значительная часть коллектива, в 63% — лишь некоторые исследователи.</p> <p>ИИ пока остается прежде всего вспомогательным инструментом. В 43% организаций, сотрудники которых применяют ИИ в научных исследованиях, к нему обращаются главным образом для подготовки текстов, перевода, поиска литературы и других сопутствующих задач. В 22% ИИ используется как инструмент для анализа данных, моделирования и решения научных задач. Для четверти организаций (26%) обе функции одинаково значимы. Лишь 2% руководителей считают, что в их организациях ИИ является неотъемлемой частью научного процесса.</p> <p>В организациях, где исследователи используют ИИ, значительно чаще применяют готовые решения, российские — в 81% организаций, зарубежные — в 71%. Дообученные или адаптированные модели применяют 22% организаций, примерно столько же разрабатывают собственные модели; и сосредоточены такие проекты главным образом в естественных (68%) и технических (41%) науках, тогда как в гуманитарных они пока единичны (5%).</p> <p>Руководители ожидают дальнейшего распространения ИИ. По их оценкам, через пять лет почти в половине организаций (46%) ИИ будут использовать все или большинство исследователей, еще в 38% — их значительная часть. Лишь 16% считают, что ИИ останется инструментом отдельных исследователей, а 1% полагают, что его не будут использовать вовсе.</p> <p>Результаты двух опросов ИСИЭЗ НИУ ВШЭ показывают, что ИИ уже широко используется в российской науке как отдельными исследователями, так и организациями. Институциональное внедрение отстает от индивидуального использования, однако руководители государственных вузов и НИИ ожидают, что в ближайшие годы этот разрыв будет сокращаться, а ИИ станет привычным элементом исследовательской и организационной деятельности.</p> После анализа индивидуальных практик использования искусственного интеллекта российскими учеными Институт статистических … message https://www.itweek.ru/themes/detail.php?ID=235269 Thu, 30 Jul 2026 14:11:56 +0300 <p>По данным опроса Nexign, СУБД от отечественных вендоров доминируют в инфраструктуре российских компаний — об их использовании сообщили 66% респондентов. 54% опрошенных применяют решения с открытым исходным кодом, 40% продолжают эксплуатировать зарубежные системы, еще 6% затруднились с ответом.</p> <p>Такие результаты отражают переходный характер текущего этапа развития ИТ-ландшафта в России. Существенная доля зарубежных решений объясняется значительным объемом устаревшей инфраструктуры в слое прикладных корпоративных систем. Многие бизнес-критичные приложения исторически разрабатывались и внедрялись в тесной связке с конкретными СУБД. Пока прикладной слой не модернизирован или не заменен, полная миграция баз данных зачастую оказывается либо технически сложной, либо экономически неоправданной.</p> <p>По данным исследования, компании в среднем используют более одного типа СУБД, комбинируя вендорские продукты и системы с открытым исходным кодом. Такой подход продиктован несколькими важными факторами. Во-первых, бизнес стремится снизить риски зависимости от вендора. Во-вторых, значительная часть существующих систем не может быть быстро выведена из эксплуатации без ущерба для бизнес-процессов. В-третьих, использование различных СУБД позволяет компаниям балансировать между стоимостью владения, доступностью квалифицированной поддержки и надежностью решения. Также наличие открытого кода дает необходимую гибкость и свободу в настройке, в то время как вендорские решения обеспечивают формальные гарантии и SLA.</p> <p>Однако гибридный подход несет и определенные риски. Главный из них — возрастающая сложность администрирования и поддержки разнородной инфраструктуры. Кроме того, усложняется мониторинг и обеспечение безопасности: при неграмотном использовании открытого кода в системе могут образовываться серьезные уязвимости. Существует также риск непредсказуемого роста совокупной стоимости владения при недостаточно продуманной архитектуре.</p> <p>Если говорить о критериях, на которые заказчики обращают внимание при выборе СУБД, то для 68% опрошенных компаний ключевыми требованиями являются отказоустойчивость, поддержка кластеризации и возможность быстрого восстановления после сбоев. Для 66% важны поддержка высокой нагрузки и масштабируемость, включая горизонтальное масштабирование и репликацию. Соответствие требованиям ФСТЭК и Роскомнадзора, а также наличие сертификации по защите данных указывают своим приоритетом 38% опрошенных. Это говорит о том, что для заказчиков становятся важны не только функциональность СУБД, но и технические характеристики, которым ранее уделялось меньше внимания. Компаниям сейчас не нужен «комбайн» со множеством новых функций. Прежде всего они ждут, что СУБД легко впишется в текущий ИТ-ландшафт и обеспечит безболезненный перенос данных. </p> <p>«Российский бизнес демонстрирует прагматичный подход к трансформации СУБД-ландшафта, строя гибридные инфраструктуры, которые позволяют сочетать надежность, гибкость и экономическую эффективность. Оптимальная стратегия сейчас — сегментировать системы и данные по критичности, определить, какие из них можно мигрировать быстро, и выстроить дорожную карту перехода к единой отечественной СУБД. Поэтапный и стратегически выверенный подход позволит компаниям снизить риски, сохранить устойчивость ИТ-инфраструктуры и обеспечить технологический суверенитет в долгосрочной перспективе», — считает Максим Нартов, директор по развитию бизнеса Nexign.</p> По данным опроса Nexign, СУБД от отечественных вендоров доминируют в инфраструктуре российских компаний — … message https://www.itweek.ru/themes/detail.php?ID=235268 Thu, 30 Jul 2026 14:10:48 +0300 <p>Компания Postgres Professional представила новую версию платформы для управления и мониторинга баз данных Postgres Pro Enterprise Manager (PPEM) 2.8. В релиз вошли новые инструменты для управления отказоустойчивыми кластерами, централизованной настройки инфраструктуры и оптимизации запросов СУБД.</p> <p>Одним из ключевых нововведений стала поддержка настройки кворумной синхронной репликации для BiHA-кластеров через графический интерфейс. Новый механизм позволяет гибко выбирать баланс между скоростью обработки транзакций и защитой данных, упрощая построение отказоустойчивой инфраструктуры без ручной настройки.</p> <p>В новой версии также расширены возможности централизованного управления конфигурацией. Администраторы могут просматривать и изменять параметры кластеров и отдельных узлов через веб-интерфейс, в том числе задавать различные настройки для разных серверов в рамках одной операции.</p> <p>PPEM 2.8 получил поддержку Adaptive Query Optimization (AQO) — технологии адаптивной оптимизации запросов, которая помогает автоматически исправлять планы запросов основываясь на статистике предыдущего выполнения и таким образом повышать производительность высоконагруженных систем.</p> <p>Кроме того, в платформе появились средства управления параметрами сбора метрик и журналов для pgpro-otel-collector, раздел для работы с пользовательскими профилями и активными сессиями, новые возможности мониторинга, а также ряд улучшений интерфейса и механизмов обслуживания репозитория.</p> <p>Postgres Pro Enterprise Manager входит в состав всех редакций СУБД Postgres Pro и предоставляет единый веб-интерфейс для мониторинга, администрирования и диагностики баз данных.</p> Компания Postgres Professional представила новую версию платформы для управления и мониторинга баз данных Postgres Pro … message https://www.itweek.ru/themes/detail.php?ID=235263 Thu, 30 Jul 2026 00:00:00 +0300 <p><em>Поскольку агенты искусственного интеллекта берут на себя выполнение задач, человеческая роль становится ключевой. Ману Нараян, </em><em>CIO</em> <em>компании GitLab, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, как преуспеть в условиях перехода к нелинейному росту производительности.</em></p> <p>Более десяти лет лидеры используют термин «будущее работы», чтобы описать, как технологии трансформируют бизнес. SaaS заменил локальное ПО. Облако заменило физическую инфраструктуру. Инструменты для совместной работы заменили офис как место, где мы выполняем задачи.</p> <p>Технологии переживают очередной период революционных изменений. На этот раз темпы этих изменений еще выше, чем в предыдущие периоды. Например, возможности ИИ по решению все более сложных задач в разработке ПО <a href="https://arxiv.org/abs/2503.14499">удваиваются</a> примерно каждые семь месяцев. Мы вот-вот станем свидетелями значительного сдвига в сторону нелинейного роста производительности, когда ИИ переосмыслит саму работу. Это порождает новые вопросы о том, кто или что выполняет работу.</p> <h3>Пришло время для работы, ориентированной на цель</h3> <p>ИИ-трансформация требует от нас нового подхода. Нынешний способ организации работы, измерения производительности и развития талантов предполагает, что человек, который производит больше всех, работает быстрее всех и знает больше всех, является лучшим сотрудником. Это предположение никуда не денется, но одного его уже недостаточно.</p> <p>Генеральный директор NVIDIA Дженсен Хуанг четко изложил, как переосмыслить нашу работу с ИИ, <a href="https://www.youtube.com/watch?v=k-xtmISBCNE&t=543s">противопоставив</a> задачи и цель. В каждой работе есть задачи. Для инженера-программиста кодирование — это задача. Но цель разработки ПО заключается в том, чтобы решать проблемы с помощью технологий и находить новые задачи, которые стоит решать. В этом новом мире ИИ, когда задач для человека становится все меньше, цель становится для него все более важной.</p> <p>Короче говоря, задачи инженера, аналитика или даже рекрутера все чаще могут выполняться агентами ИИ. Но цель, стоящая за каждой из этих ролей, остается, потому что цель коренится в ценности, которую мы придаем работе, а не в ее выполнении. Это различие можно обобщить на любую бизнес-функцию. Вопрос больше не в том, «как мне сделать это лучше?». Вместо этого работникам нужно задать себе вопрос: «Как мне руководить командой агентов, чтобы они справились с этим, чтобы я мог сосредоточиться на реальной ценности своей роли?».</p> <p>В новой модели взаимодействия человека и агента мы определяем цель. Каждый становится менеджером, задавая намерения, определяя результаты, делегируя выполнение агентам, оценивая результаты и корректируя курс с помощью суждений, которые ни одна модель не может воспроизвести.</p> <h3>Как на самом деле выглядит нелинейная производительность</h3> <p>Нам также пора переосмыслить наше понимание производительности, основанной на ИИ. Мне нравится думать об этом так: Томас Эдисон не стал решать проблему тусклого света свечи, создав лучшие свечи. Он изобрел лампочки. Точно так же речь идет не о 5% или 10% повышения производительности, а скорее об изменении качества; это как переход от света свечи к электричеству, а не от тусклой свечи к яркой.</p> <p>Рассмотрим инженера-программиста, готовящегося к выпуску новой функции. Сегодня они переключаются между трекером проекта для требований, вики для архитектурных решений, репозиторием кода для последних изменений и чатами для открытых вопросов от продуктовой команды. Только на переключения может уходить несколько часов, и это повторяется в каждом спринте.</p> <p>Теперь представьте себе команду агентов, выполняющих эти задачи параллельно: сбор требований, выявление архитектурных конфликтов, обобщение последних изменений, сканирование на наличие уязвимостей и составление первоначального плана реализации. Инженер проверяет и сразу приступает к работе.</p> <p>Примените ту же логику к другим задачам:</p> <p>• Команда поддержки сокращает время решения проблем на 50%, потому что агенты собирают контекст и составляют ответы до того, как человек коснется заявки.</p> <p>• Юридическая команда проверяет контракт за минуты вместо дней, при этом агент-исследователь собирает прецеденты, агент по соблюдению нормативных требований выявляет пункты, касающиеся рисков, а агент по составлению документов предлагает правки, оставляя юристу возможность сосредоточиться на стратегии переговоров и принятии решений, требующих экспертных знаний.</p> <h3>Это не учебная практика</h3> <p>Этот сдвиг уже происходит. EY недавно <a href="https://www.ey.com/en_us/newsroom/2025/12/ai-driven-productivity-is-fueling-reinvestment-over-workforce-reductions">объявила</a>, что почти все опрошенные ею крупные организации сообщили о повышении производительности за счет ИИ, причем около половины заявили о значительном росте, и что эти достижения были реинвестированы в развитие, а не в сокращение штата. Этот импульс реален, но он также повышает ставки: самый большой риск в настоящее время при внедрении ИИ — это слишком медленный темп.</p> <p>ИИ-нативные компании уже выпускают продукты быстрее и без тех накладных расходов, которые присущи большинству корпоративных организаций. Для стартапов часть этого преимущества обусловлена ​​размером. Но значительная часть носит структурный характер: они по необходимости создают продукты с ИИ в их основе, а не как дополнительный слой. Им не пришлось ничего перестраивать, потому что ИИ был партнером с самого начала.</p> <p>Это означает, что операционная задержка, которая ставит многие крупные организации в невыгодное положение, становится на порядок хуже.</p> <p>Организации, которые вырвутся вперед, создадут базовую структуру, которая позволит агентам действовать быстро и безопасно. Это включает в себя четкое распределение ответственности за решения ИИ, общий контекст и масштабируемые механизмы защиты. Без этого внедрение раздробится на отдельные подразделения и вовлечет людей в эксперименты, отвлекающие от действительно важной работы.</p> <h3>Забудьте о том, что вы, как вам кажется, знаете о работе</h3> <p>Чтобы правильно ориентироваться в этом вопросе, нам нужно отказаться от многих предвзятых представлений о работе. Для корпоративных организаций это будет гораздо сложнее, учитывая темпы развития ИИ.</p> <p>Окно возможностей закрывается, но мы не можем просто двигаться быстрее; нам нужно двигаться по-другому. В условиях, когда цель становится все более важной, рассудительность и интуиция, которые делают нас всех людьми, никогда не были так ценны. Чтобы извлечь выгоду из нелинейных преимуществ, которые обещает ИИ, нам всем нужно будет понимать цель работы лучше, чем когда-либо прежде.</p> Поскольку агенты искусственного интеллекта берут на себя выполнение задач, человеческая роль становится ключевой. Ману … article https://www.itweek.ru/themes/detail.php?ID=235267 Wed, 29 Jul 2026 17:42:09 +0300 <p>SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила обновление одноименной Low-code платформы версии 1.34.0. Новая функциональность позволяет закрыть такие задачи бизнеса, как сокращение времени реакции на критичные события, снижение риска недопонимания между подразделениями, а также безопасное проведение аудитов без угрозы несанкционированных изменений в системе.</p> <p>В версии 1.34.0 SimpleOne добавила в платформу поддержку нативных браузерных пуш-уведомлений. Теперь пользователь может получать оповещения о критичных событиях на разных устройствах и в поддерживаемых браузерах, без необходимости следить за почтой или мессенджерами. При этом доставка пуш-уведомлений изолирована от основной платформы: ее сбои или рост нагрузки не влияют на работу системы.</p> <p>Дополнительно была переработана Лента активности: вместо обычного текстового поля теперь работает визуальный редактор форматирования (WYSIWYG). Исполнители и бизнес-пользователи могут форматировать сообщения — добавлять полужирный и курсивный текст, списки, цитаты, гиперссылки и изображения прямо в карточке заявки. Ранее созданные текстовые сообщения платформа отображает без изменений, обратная совместимость сохранена. При этом форматирование доступно не только в ленте активности, администратор может преобразовать существующие колонки типа Text в тип WYSIWYG с сохранением данных — например, текст в описании задачи или пользовательском поле. Свойства колонки при этом не меняются, не нужно создавать новое поле и переносить значения вручную.</p> <p>Третье изменение касается администрирования: в систему добавлена роль «Аудитор». Она открывает доступ на чтение ко всем таблицам системы, в том же объеме, что у администратора, но без права изменений. Это позволяет проводить проверки и расследования, не нарушая принцип разделения обязанностей.</p> <p>«Мы последовательно закрываем те точки, где промедление и непрозрачность обходятся бизнесу дороже всего. В 1.34 это два прямых ответа: критичное событие доходит до исполнителя сразу, а не когда он откроет почту, а проверяющий получает доступ на чтение ко всем данным без права что-либо изменить — раньше ради этого приходилось выдавать избыточные права», — рассказал Илья Радченко, директор по платформенным продуктам SimpleOne, корпорация ITG.</p> <p>Новая версия платформы доступна текущим пользователям SimpleOne по запросу.</p> SimpleOne (направление прикладных бизнес-систем корпорации ITG) выпустила обновление одноименной Low-code платформы версии … message https://www.itweek.ru/themes/detail.php?ID=235266 Wed, 29 Jul 2026 17:40:11 +0300 <p>Российский ИТ-бренд Nerpa модернизировал линейку ленточных библиотек начального и среднего уровня NERPA TL. Оборудование предназначено для безопасного и экономичного хранения данных в компаниях любого масштаба: от малого и среднего бизнеса до крупных организаций. Все решения поставляются через официального дистрибьютора бренда — компанию OCS.</p> <p>Обновление затронуло базовые платформы для автозагрузчиков NERPA TL AL1U и NERPA TL AL2U и повысило надёжность, безопасность и эффективность решений. Встроенные возможности библиотек по управлению и обслуживанию были модернизированы, в том числе — расширена функциональность для защиты данных. Старшая модель линейки, ленточная библиотека NERPA TL AL707, теперь поддерживает работу с новым поколением картриджей LTO-10 с нативной ёмкостью хранения 40 ТБ.</p> <p>Обновлённая линейка ленточных библиотек поможет компаниям быстро разворачивать ресурсы для хранения большого объёма данных в условиях их постоянного роста. Также оборудование подойдёт для создания автономных и защищённых хранилищ данных, которые соответствуют требованиям регуляторов. Решения Nerpa имеют сертификаты совместимости с отечественным программным обеспечением для резервного копирования, включённым в реестр российского ПО: «Кибер Бэкап» и RuBackup.</p> <p>Ленточные библиотеки Nerpa представлены широкой линейкой оборудования: от доступных стримеров и автозагрузчиков до продуктов уровня предприятий. Все решения проходят обязательное тестирование, а их техническая поддержка осуществляется с учётом специфики и требований индустрии ленточных библиотек. В программу сервисной поддержки оборудования включён гибкий выбор регламентов обслуживания.</p> <p>«Спрос на автозагрузчики и ленточные библиотеки растёт у компаний из разных отраслей. В условиях роста цен на СХД этот сегмент становится всё более востребованным для долгосрочного хранения данных. Технологические возможности таких решений активно развиваются — обновление линеек даст нашим партнёрам доступ к современным и актуальным продуктам. Автозагрузчики и универсальные ленточные библиотеки Nerpa помогут компаниям безопасно управлять данными и соблюдать регуляторные требования к хранению информации. А расширенная экспертиза в поддержке проектов и программы сервисного обслуживания сделают работу с решениями ещё более комфортной для наших партнёров», — отметил Алексей Мосин, руководитель направления развития продукции Nerpa.</p> <p>Автозагрузчики и ленточные библиотеки Nerpa в наличии на складе OCS, также решения доступны под заказ. На оборудование распространяется стандартная гарантия сроком на один год с возможностью расширения до трёх лет.</p> Российский ИТ-бренд Nerpa модернизировал линейку ленточных библиотек начального и среднего уровня NERPA TL. Оборудование … message https://www.itweek.ru/themes/detail.php?ID=235265 Wed, 29 Jul 2026 17:36:14 +0300 <p>Рейтинговое агентство RAEX представило результаты ежегодного рэнкинга крупнейших ИТ-компаний России, зафиксировав первое за 12 лет сокращение роста отечественного ИТ-рынка.</p> <p>На фоне общеотраслевого замедления и жесткой оптимизации бюджетов заказчиков компания BSS продемонстрировала устойчивость, сохранив за собой <nobr>24-е</nobr> место в сводном Топ-25. Удержание высоких позиций во всех ключевых сегментах — от разработки ПО до дистрибуции — стало прямым следствием зрелости бизнес-модели BSS и высокого доверия со стороны корпоративных клиентов. Эти результаты подчеркивают стратегическую силу компании и ее серьезный потенциал для дальнейшего роста в любых макроэкономических условиях. </p> <p>Опубликованная детализация рэнкинга показывает, что минувший год стал для отрасли периодом жесткой бюджетной политики заказчиков, переноса сроков реализации крупных проектов и влияния накопленного технологического долга. Номинальный рост суммарных доходов участников рынка замедлился до исторических минимумов. На этом фоне сбалансированное присутствие BSS сразу в нескольких специализированных списках RAEX доказывает: в условиях неопределенности рынок делает выбор в пользу проверенных партнеров, способных гарантировать бесперебойный результат.</p> <p>Помимо общего рэнкинга, RAEX формирует специализированные списки по ключевым направлениям ИТ-деятельности. Компания BSS демонстрирует уверенное и стабильное присутствие во всех основных сегментах:</p> <ul> <li>в разработке программного обеспечения BSS стабильно удерживает <nobr>12-е</nobr> место (2025 год — <nobr>12-е</nobr> место), подтверждая статус одного из ведущих технологических архитекторов страны;</li> <li>в предоставлении ИТ-услуг BSS занимает <nobr>22-е</nobr> место (2025 год — <nobr>21-е</nobr> место), сохраняя высокие объемы экспертного сопровождения и успешного внедрения сложных инфраструктурных решений;</li> <li>в дистрибуции BSS уверенно удерживает <nobr>4-е</nobr> место (2025 год — <nobr>4-е</nobr> место), демонстрируя одну из лучших в классе эффективность логистических, интеграционных и партнерских процессов.</li> </ul> <p>На протяжении многих лет BSS входит в топ рейтингов от RAEX, что подтверждает эффективность и инвестиционную привлекательность компании на ИТ-рынке. Подчеркивает ее технологический суверенитет и серьезный потенциал для дальнейшего роста. Компания продолжает оставаться надежным стратегическим партнером для крупнейших предприятий финансового, телекоммуникационного и государственного секторов, предлагая проверенные решения для цифровой трансформации.</p> <p>Приоритетным направлением является создание и развитие инновационных решений для цифровизации бизнеса, включая платформы на базе речевых технологий, искусственного интеллекта и LLM. В центре — <nobr>CX-платформа</nobr> для системного управления клиентским опытом. Она охватывает ключевые бизнес-задачи: от автоматизации сервиса до проактивного удержания, поддержки продаж и развития команд. Это даёт возможность работать на опережение — предвидеть желания клиентов, предотвращать отток, повышать конверсию и масштабировать успешные практики.</p> Рейтинговое агентство RAEX представило результаты ежегодного рэнкинга крупнейших ИТ-компаний России, зафиксировав первое … message https://www.itweek.ru/themes/detail.php?ID=235262 Wed, 29 Jul 2026 09:26:30 +0300 <p><em>По мере развития искусственного интеллекта меняется и подход организаций к обеспечению безопасности корпоративных данных, пишет на портале </em><em>Information</em> <em>Age</em> <em>Стюарт Ханвик, технический директор Dell Technologies по платформам и решениям для хранения данных.</em></p> <p>ИИ оказывает на корпоративные данные давление нового типа. В тот самый момент, когда организации пытаются извлечь больше пользы из своих данных, они также концентрируют все больше этих данных в общих хранилищах, базах знаний и конвейерах ИИ.</p> <p>По мере перехода ИИ от экспериментов к производству, наборы данных, которые ранее были разделены по бизнес-функциям, уровню конфиденциальности или операционному использованию, все чаще объединяются для обучения моделей и поддержки принятия решений в режиме реального времени.</p> <p>Этот сдвиг меняет подход организаций к своей инфраструктуре данных. То, что когда-то было в основном платформой для хранения и восстановления информации, все чаще становится точкой консолидации, управления и доступа к данным ИИ, что влечет за собой новые вопросы отказоустойчивости, соответствия нормативным требованиям и безопасности.</p> <p>Большая часть дискуссий об инфраструктуре ИИ по-прежнему сосредоточена на моделях и вычислениях. Это важные соображения, но они могут заслонить более фундаментальный вопрос: насколько хорошо подготовлена основа данных, которая их поддерживает?</p> <p>Вот пять способов, которыми ИИ меняет безопасность корпоративных хранилищ.</p> <h3>1. ИИ объединяет данные новыми способами</h3> <p>Обучение базовой модели или ее тонкая настройка обычно означает объединение интеллектуальной собственности, регулируемых данных клиентов, внутренних знаний и контента, такого как текст, документы, фотографии, аудио и видео, в единое хранилище, открытое для запросов. Это именно тот тип концентрированной цели, который позволяет злоумышленникам быстро повышать градус, как только они получат к ней доступ. Контроль этого риска начинается еще до того, как данные будут сохранены. Сегментация обучающих данных и анонимизация или удаление конфиденциальных входных данных, где это возможно, ограничивают уязвимость, создаваемую таким агрегированием, а блокировка наборов данных с помощью неизменяемых версий снижает риск скрытого вмешательства.</p> <h3>2. Генерация с расширенными возможностями извлечения (RAG) делает хранилище активным участником, а не пассивным архивом</h3> <p>Подключите большую языковую модель к корпоративной базе знаний, и хранилище перестанет быть чем-то, к чему пользователи получают прямой доступ. Это становится частью каждого взаимодействия системы ИИ. Неправильно настроенный контроль доступа к индексу RAG может раскрыть конфиденциальную информацию через совершенно корректный запрос, что делает аудит крайне важным. Регистрация того, к каким данным осуществляется доступ и какие данные отображаются, поддерживает расследование и соблюдение нормативных требований, но, что более важно, предотвращает структурные уязвимости, которые легко пропустить, пока они не будут раскрыты.</p> <h3>3. Рабочие нагрузки инференса создают проблему скорости, которую ручной контроль не может решить</h3> <p>Производственные системы, такие как агенты ИИ или системы обнаружения мошенничества, зависят от непрерывного доступа к данным с низкой задержкой. Конвейеры, обеспечивающие это, работают с такой скоростью, что ручной мониторинг становится нецелесообразным, подобно тому, как горизонтальное перемещение по сети может оставаться незамеченным в течение нескольких дней, если не установлены соответствующие средства контроля. Защита этих систем требует обеспечения безопасности данных при передаче, применения контроля доступа во время выполнения и обеспечения достаточной устойчивости систем хранения данных, чтобы инцидент безопасности не перерос в операционный инцидент.</p> <h3>4. Отсутствие видимости — это пробел, который не устранен в большинстве организаций</h3> <p>Исследование Dell Technologies «Innovation Catalyst» показало, что 82% лиц, принимающих решения в сфере ИТ, признают данные ключевым фактором интеграции ИИ и считают, что их необходимо защищать соответствующим образом. Однако только каждый третий утверждает, что может преобразовать эти данные в инсайты реального времени. Большая часть этого пробела связана с уровнем хранения данных, и от этого может зависеть, удастся ли быстро локализовать проблему или она останется нерешенной на несколько дней. Без устранения этого пробела системы управления и политики контроля работают на основе неполной информации, как бы хорошо они ни были разработаны на бумаге.</p> <h3>5. Восстановление необходимо перестраивать с учетом зависимостей ИИ</h3> <p>Организации должны задать себе вопрос: могут ли их системы ИИ быстро возобновить доверенную работу? Это означает восстановление правильных наборов данных и версий моделей, перестройку конвейеров обработки данных и тестирование восстановления на реальных рабочих нагрузках, а не на стандартных резервных копиях системы. Технически успешное восстановление, в результате которого возвращается не та версия модели или нарушается работа конвейера, все равно является сбоем во всех важных для бизнеса аспектах.</p> <h3>Практические последствия</h3> <p>Хранение данных стало основным уровнем контроля рисков, связанных с ИИ. Основы хорошей безопасности, видимости, неизменяемости, сегментации, концепции нулевого доверия и устойчивого восстановления не изменились. Изменилось лишь то, где и как именно их необходимо применять. Например, британские регуляторы все чаще ожидают именно такой специфичности: решение правительства добавить «сбой цифровой устойчивости» в Национальный реестр рисков в июле 2026 г. свидетельствует о том, насколько серьезно к этому относятся на национальном уровне.</p> <p>Организации, которые понимают потоки данных ИИ, обеспечивают надлежащую защиту хранилищ и согласовывают механизмы контроля с рабочими нагрузками ИИ, будут лучше подготовлены к снижению рисков, выполнению требований регулирующих органов и укреплению обоснованного доверия к своим системам ИИ по мере расширения их внедрения.</p> По мере развития искусственного интеллекта меняется и подход организаций к обеспечению безопасности корпоративных … article https://www.itweek.ru/themes/detail.php?ID=235260 Wed, 29 Jul 2026 09:11:43 +0300 <p>Искусственный интеллект становится новой инфраструктурой высшего образования. Нейросети уже меняют подходы к обучению, подготовке учебных материалов, научной работе и взаимодействию университетов с работодателями. По данным исследования ИТМО, «Яндекс Образования» и Yandex Cloud, 66% преподавателей и исследователей российских вузов используют генеративный искусственный интеллект в работе, а 84% отмечают, что технологии помогают ускорять исследовательские задачи. При этом, по данным исследования Высшей школы экономики, использование генеративного ИИ среди студентов уже стало массовой практикой: значительная часть обучающихся применяет такие инструменты для подготовки учебных материалов, поиска информации и решения практических задач.</p> <p>Нейросети перестали быть экспериментом — они становятся частью образовательного процесса. Вместе с новыми возможностями появляется и новый риск — неравный доступ университетов к современным технологиям.</p> <p>Этот риск можно обозначить как «ИИ-феодализм». Речь идет о ситуации, когда доступ к мощным языковым моделям, качественным данным, вычислительным ресурсам и экспертным компетенциям распределяется крайне неравномерно. В результате преимущества получают университеты, которые уже обладают развитой цифровой инфраструктурой и возможностями для внедрения ИИ, тогда как остальные рискуют оказаться в роли догоняющих.</p> <p>Проблема заключается не только в финансировании. Технологический разрыв складывается из нескольких факторов: доступа к современным моделям искусственного интеллекта, наличия специалистов, способных внедрять новые решения, готовности преподавателей использовать инструменты ИИ и способности университетов быстро обновлять образовательные программы.</p> <p>Сегодня этот вопрос выходит далеко за пределы образовательной сферы. По оценкам экспертов, к 2030 году большинство профессий будут в той или иной степени связаны с использованием технологий искусственного интеллекта. По данным исследования «Future of Jobs» Всемирного экономического форума, около 40% ключевых навыков работников изменятся в ближайшие годы из-за развития технологий, а способность эффективно использовать ИИ станет одной из базовых компетенций на рынке труда.</p> <p>Для России этот вопрос напрямую связан с подготовкой кадров для технологического развития. Согласно целям национального проекта «Экономика данных», стране необходимо обеспечить массовое внедрение цифровых технологий и подготовку специалистов, способных работать с ними. Однако без равномерного развития ИИ-компетенций в университетах существует риск, что новые возможности будут концентрироваться только в ведущих образовательных центрах.</p> <p>Уже сегодня можно наблюдать разные скорости адаптации вузов. Одни университеты создают собственные лаборатории, внедряют ИИ-ассистентов, развивают программы подготовки специалистов в области искусственного интеллекта и выстраивают партнерства с технологическими компаниями. Другие находятся только на этапе формирования базовой цифровой инфраструктуры. В перспективе этот разрыв может стать одним из факторов, определяющих качество подготовки выпускников.</p> <p>Особенность текущего этапа заключается в том, что искусственный интеллект меняет не только инструменты обучения, но и саму модель высшего образования. Университет больше не является единственным источником знаний: студент получает доступ к огромному объему информации через цифровые системы. Поэтому ценность преподавателя постепенно смещается от передачи информации к наставничеству, развитию критического мышления и формированию способности работать со знаниями.</p> <p>Одновременно меняется система оценки компетенций. Письменные экзамены, эссе, курсовые работы и другие традиционные форматы контроля все чаще не позволяют объективно оценить уровень подготовки студента, поскольку значительную часть таких задач способны выполнять генеративные модели. Университетам предстоит переходить от оценки конечного результата к оценке способности человека анализировать информацию, объяснять ход рассуждений, принимать решения и эффективно использовать искусственный интеллект как профессиональный инструмент.</p> <p>Эти изменения напрямую связаны с рынком труда. Работодатели все чаще ожидают от выпускников не только фундаментальных знаний, но и способности повышать собственную эффективность с помощью ИИ. Владение такими инструментами постепенно превращается в базовую компетенцию — аналогично тому, как ранее обязательными стали навыки работы с компьютером и цифровыми сервисами.</p> <p>При этом без системной политики технологический разрыв между университетами может только увеличиваться. Для его сокращения необходим комплекс мер: развитие региональных программ внедрения ИИ, поддержка вузов в создании цифровой инфраструктуры, подготовка преподавателей и формирование ИИ-грамотности на всех уровнях образования — от школы до университета.</p> <p>Одновременно важно избежать другой крайности — избыточного регулирования. Искусственный интеллект развивается быстрее, чем традиционные механизмы управления успевают адаптироваться к изменениям. Ограничительные меры без понимания природы технологии могут не снизить риски, а наоборот — замедлить внедрение решений, которые становятся частью образовательной и профессиональной среды.</p> <p>В ближайшие годы конкурентоспособность университетов будет определяться не только качеством преподавания и научными достижениями, но и способностью эффективно использовать искусственный интеллект. Главный вызов заключается не в том, чтобы внедрить отдельные цифровые инструменты, а в том, чтобы обеспечить равный доступ к возможностям новой технологической эпохи. В противном случае образовательное неравенство может перерасти в кадровое — и стать фактором, влияющим на конкурентоспособность экономики.</p> <p>#IMAGE_235261#</p> Искусственный интеллект становится новой инфраструктурой высшего образования. Нейросети уже меняют подходы к обучению … article Эдуард Хисюков, руководитель агентства “ЭдуТрек”, старший преподаватель кафедры инженерной кибернетики НИТУ МИСИС