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=235349 Fri, 14 Aug 2026 15:23:21 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил отслеживать направления, формирующие передний край глобальной исследовательской повестки. Среди выделенных по итогам 2025 года 890 фронтиров самые высокие значения индекса значимости у тематик, связанных с решением экологических проблем, цифровой трансформацией и психическим здоровьем человека.</p> <p>Климатическая повестка выходит за рамки прогнозирования изменений температуры. Исследования также охватывают поведение людей, оценку рисков и адаптацию к новым условиям, что требует объединения естественных и общественных наук. Одновременно меняется сам подход к взаимодействию с природой: антропоцентрическая парадигма, ставящая во главу угла интересы человека, постепенно уступает место экоцентрической.</p> <p>Рост городского населения и расширение урбанизированных территорий меняют структуру землепользования, усиливают нагрузку на природные ресурсы. Важным инструментом адаптации и планирования территорий становятся геоинформационные системы. В городах формируются локальные климатические эффекты, включая острова тепла и изменение режима осадков, повышается уязвимость к экстремальным погодным явлениям. Смягчать эти эффекты могут экосистемные услуги — секвестрация углерода, фильтрация загрязнителей и регулирование гидрологического режима. Гидротермальная карбонизация органических отходов позволяет получать энергетически ценные продукты и богатые углеродом материалы, что способствует развитию экономики замкнутого цикла.</p> <p>Необходимость снизить негативное воздействие на окружающую среду стимулирует развитие возобновляемой и водородной энергетики. Дальнейшее развитие топливных элементов и электролизеров во многом зависит от создания эффективных катализаторов. Наиболее перспективными считаются наночастицы благородных металлов, а более доступными альтернативами — оксиды никеля и кобальта и карбиды железа. В солнечной энергетике разрабатываются фотоэлектрические элементы нового поколения, в частности перовскитные и тандемные структуры, а также прозрачные проводящие покрытия.</p> <p>Для решения сложных задач уже недостаточно только наращивать вычислительные мощности: требуется одновременно собирать данные, моделировать процессы и управлять ими. В 2025 году заметно усилилась синергия вычислительных и измерительных технологий.</p> <p>ИИ из инструмента анализа превращается в технологию действия. Обработка данных переносится на периферию (edge) — непосредственно в устройства, датчики и локальные модули. В основе систем периферийного ИИ лежит машинное обучение, позволяющее интерпретировать разнородные и зашумленные данные без обращения к облачным центрам.</p> <p>В интеллектуальные системы управления все чаще встраивают нейросети, например для координации групп автономных роботов или управления роботизированными манипуляторами. Широко применяется глубокое обучение, позволяющее работать с неструктурированными данными и оперативно реагировать на изменения.</p> <p>Чем сложнее модели, тем важнее регуляризация. В критических областях применения ИИ особенно высоки требования к устойчивости моделей и способности точно обрабатывать новые данные. Например, медицинские диагностические системы должны надежно работать для пациентов, чьи демографические характеристики отличаются от представленных в обучающей выборке.</p> <p>Разработки на стыке ИИ и физики сокращают путь сигнала от регистрации до его интерпретации. Усиливать и стабилизировать сигналы позволяют резонаторные технологии, применяемые в высокочувствительных радиочастотных и сенсорных устройствах. Так, фотонные «электронные носы» на основе массивов микрорезонаторов формируют уникальный «оптический отпечаток» анализируемой смеси, а локальный ИИ-интерфейс распознает его непосредственно на чипе.</p> <p>Спектроскопия, выделенная в самостоятельный фронтир, позволяет увидеть то, что прежде оставалось скрытым. В 2025 г. коллаборация BASE в ЦЕРН впервые продемонстрировала применение крайне значимой для изучения асимметрии материи и антиматерии когерентной спектроскопии квантовых переходов спина одиночного антипротона. В прикладной сфере поверхностно-усиленная рамановская спектроскопия (SERS) на наночастицах позволяет регистрировать сигналы отдельных молекул и в комбинации с ИИ-анализом спектров разрабатывать методы цитологической диагностики.</p> <p>В классических дисциплинах такой объединенный инструментарий обеспечивает переход от наблюдения к целенаправленному управлению процессами на микро- и наноуровне. В физике совершенствуются методы управления светом, электрическими сигналами, магнитными состояниями и квантовыми эффектами, которые используются в системах спутниковой связи и навигации, жидкокристаллических дисплеях, кремниевых фотонных устройствах и голографическом хранении данных. В химии сочетание измерений и моделирования поддерживает молекулярный дизайн: изучение процессов гидрогенизации и динамики адсорбции в нестационарных условиях помогает создавать материалы и катализаторы с заданными свойствами. Такие разработки способствуют миниатюризации оптических чипов, росту скорости обработки информации и плотности ее записи.</p> <p>Крупный блок ведущих фронтиров образуют исследования в области развития человеческого потенциала и связанные с поддержанием здоровья как человека, так и животных. Их общая черта — внимание к раннему выявлению рисков: от молекулярных и клеточных изменений до механизмов психических расстройств и факторов развития ребенка.</p> <p>В биомедицине и ветеринарии биомаркеры позволяют отслеживать изменения задолго до появления выраженных клинических признаков, обеспечивая переход от симптоматической к ранней, точной и персонализированной диагностике. Анализ сывороточных биомаркеров помогает выявлять воспалительные процессы, метаболические нарушения, опухоли, повреждения тканей и др. Другой фронтир связан с антиоксидантами, подавляющими свободнорадикальное окисление, которое может запускать и усиливать различные патологические процессы.</p> <p>Одна из центральных тематик этого блока — ментальное здоровье. Возрастает значение исследований, направленных на выявление биологических, психологических и средовых механизмов формирования психических расстройств, а также факторов, способствующих сохранению психологической устойчивости. Профилактика ментальных расстройств затрагивает и сферу воспитания детей, согласно результатам исследований, качество связи родителя с ребенком в раннем возрасте оказывает прямое влияние на метилирование ДНК и формирование архитектуры нейронных сетей мозга. Эта проблематика имеет не только медицинское, но и социальное, экономическое и демографическое значение, поскольку ментальное здоровье во многом определяет уровень качества жизни человека.</p> <p>Карта ведущих научных фронтиров отражает поиск системных ответов на глобальные вызовы. Сохранение планеты становится фокусом экологических исследований, работы в области биомедицины направлены на повышение качества жизни человека, фундаментальную основу новых решений обеспечивают биология, физика и химия, цифровые технологии расширяют возможности измерения и управления. Перечень фронтиров может служить ориентиром при выборе тем исследований и определении приоритетов поддержки науки и технологий.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил отслеживать направления, формирующие … message https://www.itweek.ru/themes/detail.php?ID=235347 Fri, 14 Aug 2026 10:25:07 +0300 <p><em>Облачные провайдеры растят DevOps-инженеров, которых потом переманивает BigTech. Почему компании продолжают вкладываться в людей, зная, что те уйдут, — и что это говорит о рынке IT-кадров?</em></p> <p>Хороший DevOps-инженер готовится к докладу на конференции — шлифует слайды, прогоняет демо. Он еще не знает, что через два месяца уволится. Не потому что плохо платили или надоело — просто выступил, к нему подошли, предложили больше. Это не провал HR, а нормальная механика рынка, в которой облачные провайдеры играют специфическую роль — они растят специалистов, которых потом хотят все.</p> <h3>Рынок сжался — но не для всех</h3> <p>В 2025 году вакансий для айтишников стало на 26% меньше, чем годом ранее. Казалось бы, передышка для работодателей. Но облачные провайдеры её не почувствовали: клиентская база росла, крупный бизнес ускорял переход в облако, и спрос на опытных инженеров оставался высоким. По <a href="https://www.techtarget.com/whatis/feature/Tech-job-market-statistics-and-outlook">данным </a>TechTarget, 87% технических директоров по-прежнему говорят, что не могут найти нужных специалистов.</p> <p>Проблема структурная. Технологические навыки устаревают примерно за 2,5 года, а университеты обновляют программы куда медленнее. Система подготовки кадров просто не рассчитана на такую скорость изменений — и отрасль давно научилась справляться с этим своими силами.</p> <h3>Как устроена карьерная труба</h3> <p>В провайдерской среде есть устойчивая модель, которую внутри индустрии неформально называют «трубой». Специалист приходит с минимальными навыками — в техподдержку, на дежурную смену, в администрирование. Работает на больших объемах и разнообразных задачах. Постепенно растёт. Через несколько лет из него получается инженер с реальной экспертизой.</p> <p>Если посмотреть на DevOps-инженеров в облачных командах, то 9 из 10 — те, кто проросли внутри компании, а не пришли готовыми. Это не случайность и не особенность одного провайдера. Это общая логика отрасли: в отличие от BigTech, где специалист приходит уже сформированным под конкретную задачу, провайдерская среда по природе своей многоуровневая. Здесь есть ступеньки, на которых можно учиться в процессе работы — и это работает.</p> <h3>Чем облако привлекает инженера</h3> <p>Объяснять выбор в пользу провайдера только деньгами — упрощение. Суть в характере работы.</p> <p>DevOps в корпоративном IT обслуживает одну команду, настраивает один пайплайн, работает по гайдам. Задача решена — переключается на следующую, примерно такую же. В облачном провайдере задача другая: не развернуть инфраструктуру для своей команды, а создать сервис, который потом будет предоставляться тысячам клиентов в автоматизированном режиме. Это ближе к разработке, чем к эксплуатации. Другой уровень сложности, другое мышление.</p> <p>Именно поэтому опыт из облака ценится на рынке: инженер, проработавший в провайдере, приходит в BigTech с насмотренностью и навыками, которые там сложно получить иначе. Рынок это подтверждает — по <a href="https://enigmai.ru/salary/devops/devops-salary-2026/">данным</a> Enigma Intelligence, наиболее востребованными в <nobr>2025-2026</nobr> годах стали специалисты в Platform Engineering и DevSecOps, то есть именно в том, чем занимаются облачные команды каждый день.</p> <h3>Когда специалист уходит</h3> <p>Конференции стали обязательной частью профессиональной жизни инженера. Выступить с докладом — значит показать экспертизу, прокачать личный бренд, поделиться опытом с сообществом. Всё это так. Но у этой медали есть обратная сторона: человек всё о себе рассказал, экспертизу показал, контакты на последнем слайде оставил. Хедхантерам остается только подойти после секции.</p> <p>Однажды так мы потеряли одного из сильных инженеров: выступил с докладом, познакомился с нужным человеком и через два месяца принял оффер. Обидно? Отчасти. Неожиданно? Нет. Такова механика открытого рынка — и мы сами участвуем в ней с обеих сторон.</p> <p>Переходы между провайдерами — обычная история. Специалисты идут туда, где больше объёмы, интереснее задачи, выше зарплата. Это работает в обе стороны. Главное — понимать, что удержать человека силой невозможно, а вот создать среду, из которой не хочется уходить, — вполне.</p> <p>К слову, к клиентам инженеры уходят редко — и это не случайно. В облачном провайдинге специалист не привязан к конкретному заказчику: с ним работает команда, контакты ситуативны, личного коннекта, который мог бы перерасти в оффер, почти не возникает. Это механика аутсорс-разработки, не провайдинга.</p> <h3>Рынок труда: от голода к насыщению</h3> <p>Ещё полтора года назад картина была другой. Вакансия могла висеть полгода — и ни одного подходящего кандидата, даже при конкурентной зарплате. Дефицит ощущался физически: планы запуска продуктов сдвигались, нагрузка на команды росла.</p> <p>С лета 2025 года ситуация изменилась. Крупные компании начали тихие сокращения: официальных объявлений нет, но мидлы с именитым бэкграундом появились на рынке. Параллельно в BigTech заработала механика «банки» — когда проект закрывается, команду не распускают сразу, а дают несколько месяцев на поиск места внутри. Кто не находит — выходит на рынок.</p> <p>Итог: рынок соискателя превратился в рынок работодателя. Вакансии закрываются быстрее, а зарплатная гонка утихает. 47% IT-специалистов <a href="https://www.newstaff.ru/trendy-najma-it-specialistov-v-2025-godu-chto-menyaetsya-na-rynke/">называют</a> главным фактором при выборе работы гибкий формат и возможность роста — зарплату ставят на первое место только 18%. Для провайдеров, которые исторически делают ставку на развитие сотрудников, — это сигнал в нужную сторону.</p> <h3>Что дальше</h3> <p>Рост облачного рынка в России замедляется: <nobr>35-40%</nobr> несколько лет назад, около 29% в 2024 году, прогноз на <nobr>2026-й —</nobr> порядка 24%. При таком замедлении найм тоже будет сжиматься. Компании, которые в период бума набирали людей «с запасом», сейчас пересматривают ФОТ и смотрят, что команды реально делают.</p> <p>Но структурная история с «трубой» никуда не денется — и в этом, пожалуй, главное. Провайдеры продолжат выращивать специалистов снизу, потому что иначе не работает. Готовых инженеров с нужным стеком на рынке не хватало и не будет хватать, особенно с учётом того, что автоматизация убирает начальные позиции и подпитка снизу для всей отрасли постепенно иссякает.</p> <p>На Западе это уже институализировалось: Microsoft запустила Datacenter Academy, AWS строит партнёрства с техническими школами через Workforce Accelerator — провайдеры сами пишут учебные программы, поставляют оборудование для лабораторий, финансируют стипендии. В России этот путь только начинается.</p> <p>Инженер, который вырос в провайдере и ушел к конкуренту или в BigTech, — это не только потеря. Он знает продукт изнутри, иногда рекомендует его клиентам, иногда возвращается. Это другая форма лояльности. И она тоже работает.</p> <p>#IMAGE_235348#</p> Облачные провайдеры растят DevOps-инженеров, которых потом переманивает BigTech. Почему компании продолжают вкладываться … article Сергей Рыжков, руководитель онлайн-продаж и аналитики Рег.облака https://www.itweek.ru/themes/detail.php?ID=235345 Fri, 14 Aug 2026 10:08:55 +0300 <p><em>Поставщики систем планирования ресурсов предприятия (ERP) быстро позиционируют автономные операции как следующую «платформенную» задачу, но реальным ограничением для их внедрения станет корпоративный контроль — смогут ли технологические руководители проверять действия агентов, управлять их использованием и сохранять бизнес-смысл в условиях фрагментации, пишет в корпоративном блоге Фарам Медхора, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Фрагментация — это реальность работы ERP-систем: согласно исследованию Forrester «Enterprise Applications Software Survey 2026», только 7% лиц, принимающих решения по ERP на предприятиях, используют только один экземпляр системы. В сложной многоэкземплярной инфраструктуре агенты будут наследовать региональные варианты, приобретенные системы и противоречивые определения, что выявит недостатки управления, которые технологические руководители могли терпеть во времена, когда автоматизация оставалась под контролем человека.</p> <p>Если технологические руководители хотят начать пожинать плоды агентных ERP-систем, им не стоит начинать с каталога агентов. Вместо этого им следует начать с модели управления, чтобы понять, насколько они смогут подтвердить, оценить и защитить автономность с помощью переносимости.</p> <p> #IMAGE_235346#</p> <h3>Контроль за доказательствами: верификация — это новый скоростной лимит ERP</h3> <p>Агентная ERP создает проблему контроля. Каждое действие агента требует подтверждения: кто его одобрил, какая учетная запись его выполнила, какие данные были использованы и кто несет ответственность за результаты, когда действия агента достигают этапов проводок, сверки или закрытия.</p> <p>Эта проблема контроля затрагивает наиболее уязвимые места в большинстве ERP-систем: управление данными, контроль и безопасность. Согласно нашим данным, 65% пользователей ERP оценивают точность данных как сложную проблему, и 64% говорят то же самое о безопасности и соответствии нормативным требованиям. Риски уже очевидны. Уязвимость BodySnatcher (CVE-2025-12420) показала, как некорректная аутентификация агентов может позволить осуществлять привилегированное подмену личности в ServiceNow, а дело Moffatt против Air Canada (2024) подтвердило, что компании (а не поставщик) остаются ответственными за предоставленную ИИ информацию о клиентах.</p> <p>Агентную ERP-систему следует рассматривать в первую очередь с точки зрения обеспечения контроля, а во вторую — с точки зрения автоматизации. Сегментируйте автономность по классам транзакций: расширяйте возможности консультативных агентов сейчас, требуйте полной отслеживаемости для контролируемого выполнения и откладывайте автономное выполнение до тех пор, пока команды не смогут доказать ответственность за исключения, предоставить аудиторские доказательства и возможность отката.</p> <p>Для этого вам потребуется перейти к стандартизированному ядру, которое вы откладывали, поскольку агенты будут усиливать вариативность процессов, данных и контроля. Вам также потребуется сначала провести каждого кандидата на автоматизацию через стандартизацию, и если вы не можете его стандартизировать, это означает, что вы не можете его безопасно автоматизировать.</p> <h3>Контроль за ценой: счетчик — это новый контроль объема работ</h3> <p>Ценообразование ERP-систем движется в сторону моделей, основанных на использовании, кредитных пулах и многоуровневых счетчиках. Это переносит риск с прайс-листа поставщика на ваш текущий тариф. Большинство CIO по-прежнему договариваются о продлении как о фиксированных затратах, но эта привычка устареет по мере роста использования агентов. Как только агенты начнут применяться в повседневной работе, использование может превысить бюджетные рамки. Фактически, 30% руководителей, принимающих решения в сфере корпоративного SaaS, уже отмечают непредсказуемость ценообразования на основе использования как проблему.</p> <p>Мы уже видим, как контроль дает сбой. Uber исчерпала свой бюджет на ИИ за несколько месяцев после того, как применение Claude Code широко распространилось среди инженеров. Salesforce учитывает использование Agentforce через Flex Credits с учетом превышения лимитов. Покупатели RISE with SAP колеблются, когда не могут самостоятельно отслеживать лицензирование и использование.</p> <p>Это означает, что технологические руководители никогда не должны подписывать соглашения об использовании агентной ERP без телеметрии со стороны покупателя, жестких ограничений, триггеров превышения лимитов и сценариев потребления, смоделированных финансовыми специалистами. Помните, если поставщик контролирует и счетчик, и интерпретацию показаний счетчика, вы не контролируете программу.</p> <h3>Контроль за переносимостью: следующая проблема привязки к поставщику — семантическая</h3> <p>Перенос ваших данных к новому поставщику больше не является трудной задачей. Трудность заключается в том, чтобы разобраться, как старый поставщик определял ваш бизнес. Если ваши KPI, бизнес-сущности и связи данных построены вокруг модели одного поставщика, вы остаетесь привязанными к нему даже после миграции данных. Это то, что мы называем семантической зависимостью. Открытые стандарты, такие как MCP и Agent2Agent, которые могут снизить барьеры для подключения, теперь развиваются под эгидой Linux Foundation, но этого недостаточно (даже близко) для обеспечения переносимости сути бизнеса.</p> <p>Технологическим лидерам необходимо ознакомиться с новым термином: семантическая переносимость. В дальнейшем вам нужно будет включать семантическую переносимость в каждое продление контракта. Это означает требование прав на экспорт определений KPI, моделей сущностей и связей основных данных, прежде чем вы будете добавлять больше интеллектуальных функций в контекстный слой поставщика. Это крайне важно, потому что то, что вы не можете экспортировать сегодня, завтра станет вашей стоимостью перехода.</p> <h3>Масштабируйте операционную модель до развертывания агентов</h3> <p>Наиболее эффективные CIO не будут гнаться за самым эффектным помощником. Они сначала определят ответственность: кто утверждает агентов, кто отвечает за ожидания, кто контролирует бюджеты потребления и кто управляет семантикой. Именно с этой моделью будут работать ваши финансовые директора, аудиторы и клиенты.</p> Поставщики систем планирования ресурсов предприятия (ERP) быстро позиционируют автономные операции как следующую «платформенную» … article https://www.itweek.ru/themes/detail.php?ID=235343 Fri, 14 Aug 2026 09:57:10 +0300 <p>Доменная отрасль во многих странах постепенно интегрируется с системами цифровой идентификации. Государства рассматривают доменную инфраструктуру как часть общей системы кибербезопасности, устойчивости онлайн-сервисов и управления онлайн-активами. Россия также движется в этом направлении: с сентября 2026 года для доменов в зонах .ru, .рф и .su ключевые операции будут связаны с подтверждением администратора через ЕСИА.</p> <p>Рассмотрим, как меняется регулирование доменной отрасли в разных странах, как российский подход соотносится с международной практикой и что новые требования означают для бизнеса.</p> <h3>В России меняются правила регистрации доменов</h3> <p>С 1 сентября 2026 года вступают в силу новые правила регистрации и продления доменов в зонах .ru, .рф и .su. Администраторам потребуется обязательная идентификация через ЕСИА — систему авторизации на портале «Госуслуги». Изменения закреплены федеральным <a href="https://www.consultant.ru/document/cons_doc_LAW_523115/">законом № <nobr>569-ФЗ</nobr></a>.</p> <p>Новые требования распространяются на все категории администраторов. Физическим лицам и индивидуальным предпринимателям понадобится подтвержденная учетная запись на Госуслугах. Юридическим лицам необходимо зарегистрировать организацию на портале и назначить сотрудника с подтвержденными полномочиями для управления доменами. Иностранные граждане и компании также должны будут учитывать новые требования: пройти идентификацию через ЕСИА при наличии такой возможности либо заранее выбрать иную допустимую модель управления доменом. Некоторые регистраторы предлагают решение «Доверенный администратор» (trustee-сервис), которое позволяет управлять доменом в зонах .ru, .рф и .su без идентификации через Госуслуги. Домен регистрируется на российское юрлицо с подтвержденной записью в ЕСИА, а вы сохраняете полный контроль через свой личный кабинет.</p> <p>Обязанность указывать достоверные данные при регистрации доменов существовала и раньше: администраторы должны были предоставлять регистраторам актуальные паспортные, контактные и регистрационные данные. Однако проверка этой информации в значительной степени оставалась ручной и зависела от предоставленных документов.</p> <p>Теперь система предполагает цифровое подтверждение данных через государственную инфраструктуру идентификации. Это должно повысить прозрачность доменной среды, упростить установление владельцев интернет-ресурсов и усилить меры против мошеннических и противоправных онлайн-активностей.</p> <p>Для пользователей регистрация и продление доменов в стандартных сценариях также станут проще: часть данных будет автоматически заполняться на основе информации из ЕСИА без необходимости отдельно загружать документы и подтверждения. Но для компаний с неупорядоченным доменным портфелем новые правила могут выявить старые проблемы: домены, оформленные на бывших сотрудников, подрядчиков, старые юридические лица или аккаунты, к которым давно нет доступа.</p> <h3>Почему государства стали внимательнее к доменной инфраструктуре</h3> <p>Рост внимания к доменной отрасли напрямую связан с вопросами кибербезопасности. Домены регулярно используются в фишинговых атаках, распространении вредоносного ПО, мошеннических схемах и управлении ботнетами. Для атакующих домен остается удобной точкой входа: он помогает имитировать бренд, запускать поддельные лендинги, маскировать инфраструктуру и перенаправлять пользователей на вредоносные ресурсы.</p> <p>Проблема носит глобальный характер. По данным <a href="https://interisle.net/insights/phishing-landscape-2025-an-annual-study-of-the-scope-and-distribution-of-phishing">исследования</a> американской аналитической компании Interisle Consulting Group, в 2025 году количество доменов, использованных в фишинговых атаках по всему миру, превысило 1,5 млн., а общее число зарегистрированных фишинговых кампаний приблизилось к 2 млн.</p> <p>Российский сегмент интернета также сталкивается с ростом подобных угроз. По <a href="https://domainpatrol.ru/upload/iblock/676/kq5hwn3umunbtr2b21ndavh17ptw6is1/KO_2025_rus.pdf">данным</a> проекта «Доменный патруль» Координационного центра .RU/.РФ, в 2025 году в рунете заблокировали более 42 тыс. фишинговых сайтов и свыше 10 тыс. ресурсов, распространявших вредоносное ПО.</p> <p>На этом фоне государства рассматривают доменную инфраструктуру как часть системы цифровой устойчивости и кибербезопасности. Возможность быстро установить владельца интернет-ресурса позволяет оперативнее реагировать на инциденты, снижать масштабы злоупотреблений и выстраивать взаимодействие между регистраторами, ИБ-службами и правоохранительными органами.</p> <p>Еще один фактор — повышение прозрачности цифровой среды. Для регуляторов важно понимать, кто управляет ключевыми онлайн-активами внутри национального доменного пространства. Это позволяет снизить риски анонимного использования доменов в противоправной деятельности и сделать управление цифровой инфраструктурой более предсказуемым при взаимодействии бизнеса и государства. Для бизнеса эта логика тоже важна. Домен давно перестал быть просто адресом сайта: он связан с почтой, клиентским трафиком, рекламными кампаниями, API-интеграциями, SSL/TLS-сертификатами и доверием пользователей. Потеря контроля над доменом может привести не только к недоступности сайта, но и к сбоям в сервисах, утрате почтового контура или репутационному ущербу.</p> <h3>Какие модели идентификации действуют в разных странах</h3> <p>Подходы к идентификации владельцев доменов отличаются в зависимости от страны, однако почти все крупные юрисдикции движутся в сторону более прозрачной модели регулирования.</p> <p>В Евросоюзе изменения связаны с директивой NIS2, которая требует от регистраторов и реестров обеспечивать проверку и актуальность данных владельцев доменов. Речь идет не о централизованной государственной идентификации, а о повышении прозрачности доменной среды и снижении количества анонимных или недостоверных регистраций.</p> <p>Германия стала одной из первых стран, внедривших такие требования. Владельцы доменов должны подтверждать контактные данные, а при подозрительной активности регулятор или регистратор вправе запросить дополнительную верификацию. Европейская модель в большей степени носит риск-ориентированный характер: углубленная проверка обычно применяется при выявлении подозрительных действий или жалоб. В случае отказа от подтверждения данных домен может быть ограничен в обслуживании или заблокирован.</p> <p>Азиатские страны чаще используют более формализованные механизмы проверки личности или регистрационных данных. В Китае действует система real-name verification с обязательной проверкой документов владельца домена. В Индии регулирование также движется в сторону усиления KYC/e-KYC-процедур для доменных регистраций, в том числе на фоне судебной практики и обсуждения мер против фишинга и мошеннических сайтов.</p> <p>В ряде стран регулирование доменной отрасли строится вокруг принципа локального присутствия. Например, регистрация доменов в Австралии или Сингапуре может требовать локализации бизнеса, наличия национального регистрационного номера или использования trustee-сервисов, когда формальным администратором выступает местный регистратор, а фактическое управление остается за иностранной организацией.</p> <h3>Как устроена российская модель идентификации</h3> <p>Российская система идентификации администраторов доменов строится вокруг интеграции регистраторов с ЕСИА — Единой системой идентификации и аутентификации, используемой на портале Госуслуг.</p> <p>При регистрации или продлении домена администратор должен будет авторизоваться через Госуслуги и подтвердить свою учетную запись. Для физических лиц и индивидуальных предпринимателей потребуется подтвержденный аккаунт пользователя. Юридическим лицам необходимо зарегистрировать организацию в ЕСИА и назначить сотрудника с подтвержденными полномочиями для управления доменами.</p> <p>После авторизации сведения о владельце домена будут автоматически подтверждаться через государственную систему идентификации и передаваться регистратору в рамках установленного регулирования. Это позволит отказаться от значительной части ручных проверок и отдельной загрузки документов при стандартных сценариях регистрации и продления доменов.</p> <p>Российская модель сочетает элементы нескольких международных подходов, но при этом формирует собственную систему регулирования. В отличие от европейской модели, где углубленная проверка обычно применяется в ответ на подозрительную активность или жалобы, российский подход предполагает превентивную идентификацию администратора до выполнения ключевых операций с доменом.</p> <p>При этом российская система опирается не на новую отдельную процедуру, а на уже существующую цифровую инфраструктуру ЕСИА. Для пользователей это снижает количество ручных действий, а для регистраторов и государства создает более устойчивую модель подтверждения данных администратора домена.</p> <h3>Как администраторам доменов в компаниях подготовиться к новым правилам</h3> <p>До вступления новых требований остается немного времени, поэтому компаниям стоит провести аудит доменного портфеля и проверить текущую модель управления онлайн-активами.</p> <p>Бизнесу важно:</p> <ul> <li> собрать перечень всех доменов, используемых компанией</li> <li> проверить связанные элементы инфраструктуры: DNS-записи, SSL/TLS-сертификаты, почтовые настройки, редиректы, поддомены и домены рекламных кампаний;</li> <li> проверить, на кого зарегистрированы домены и актуальны ли данные администраторов;</li> <li> убедиться, что критически важные домены оформлены на юридическое лицо компании, а не на сотрудников, подрядчиков или внешних разработчиков;</li> <li> проверить, у кого есть доступ к учетным записям, через которые осуществляется управление доменами;</li> <li> зарегистрировать организацию в ЕСИА и определить сотрудников, ответственных за администрирование доменов;</li> <li> убедиться, что у ответственных сотрудников есть подтвержденные полномочия для работы через Госуслуги.</li> </ul> <p>Особое внимание стоит уделить доменам, зарегистрированным на бывших сотрудников или сторонних исполнителей. После запуска обязательной идентификации отсутствие прямого контроля над учетной записью администратора может осложнить продление домена, подтверждение данных или восстановление доступа к онлайн-ресурсам компании.</p> <p>Также стоит определить владельца процесса внутри компании. На практике доменами могут заниматься ИТ, ИБ, юристы, маркетинг и подрядчики, но при отсутствии единого ответственного доменный портфель быстро становится непрозрачным. Минимальный набор контроля — единый реестр доменов, регламент продления, порядок выдачи доступов, резервные контакты и регулярная проверка критичных доменных операций.</p> <p>Для бизнеса новые правила управления доменами — это повод проверить, кто фактически контролирует ключевые онлайн-адреса, где находятся доступы и можно ли без задержек подтвердить права на домен. Чем раньше компания проведет аудит доменного портфеля, тем ниже риск столкнуться с проблемами при продлении, изменении DNS-настроек или восстановлении доступа к онлайн-сервисам. В итоге подготовка к ЕСИА становится частью грамотного управления цифровой инфраструктурой — так же, как контроль учетных записей, сертификатов, почты и других критичных сервисов.</p> <p>#IMAGE_235344#</p> Доменная отрасль во многих странах постепенно интегрируется с системами цифровой идентификации. Государства … article Георгий Казаров, руководитель отдела доменов Руцентра https://www.itweek.ru/themes/detail.php?ID=235342 Thu, 13 Aug 2026 16:27:50 +0300 <p>MWS Cloud, входящая в МТС Web Services (MWS), проанализировала потребление китайских больших языковых моделей российскими компаниями на основе данных платформ MWS GPT Model Hub и MWS GPT. В первом полугодии 2026 года объём потребления более чем в 11 раз превысил показатель за весь 2025 год. Наиболее востребованными стали семейства Qwen, GLM и Kimi. Рынок предоставления LLM из облака в 2026 году достигнет почти 1,5 млрд рублей.</p> <p>В 2025 году на работу с китайскими генеративными моделями российские компании израсходовали 39,1 млрд токенов. В первом полугодии 2026 года потребление превысило 400 млрд токенов, увеличившись в 11,3 раза.</p> <p>Основными пользователями платформы являются представители крупного бизнеса. Они чаще всего применяют LLM для автоматизации клиентского взаимодействия: запускают чат-ботов для круглосуточной поддержки без участия оператора, генерируют и персонализируют маркетинговый контент — от текстов рассылок и описаний товаров до рекламных объявлений, — а также автоматизируют анализ обратной связи: выявляют тональность отзывов, категоризируют запросы и формируют сводные отчёты.</p> <p>Весь рынок LLM в России в 2026 году вырастет на 35% и составит порядка 19,6 млрд рублей. Облачный сегмент рынка, включающий предоставление доступа к LLM по модели SaaS и через API, в 2026 году достигнет почти 1,5 млрд рублей.</p> <p>На фоне растущего спроса и выхода новых моделей MWS Cloud почти вдвое расширила число больших языковых моделей в сервисе MWS GPT Model Hub, доведя их количество до 17. Главными пополнениями платформы стали GLM 5.2, опенсорс LLM от компании Z.AI, которая была признана лучшей LLM в агентских задачах. MWS Cloud стала первой компанией в России, развернувшей модель у себя в облаке. Кроме того, в сервисе появились первые модели распознавания речи (ASR) и синтеза речи (TTS), а также реранкеры для повышения качества поиска и RAG-пайплайнов. Сервис доступен в рамках платформы MWS Cloud Platform.</p> <p>Среди новых LLM — GLM 5.2, Kimi K2.6, Qwen3.6, Gemma 4, GPT OSS и другие. Каталог из 17 моделей даёт разработчикам возможность подбирать модель под конкретную задачу с учётом требований к качеству, скорости и стоимости. Все модели доступны через единый OpenAI-совместимый API, что упрощает интеграцию и переключение между ними.</p> MWS Cloud, входящая в МТС Web Services (MWS), проанализировала потребление китайских больших языковых моделей российскими … message https://www.itweek.ru/themes/detail.php?ID=235340 Thu, 13 Aug 2026 09:52:19 +0300 <p>Генеративный ИИ заметно изменил работу разработчиков. Создавать новый код стало проще и быстрее, чем когда-либо раньше. При этом потенциал генеративного ИИ в разработке уже подтверждается исследованиями. В ежегодном <a href="https://www.mckinsey.de/capabilities/quantumblack/our-insights/the-state-of-ai-how-organizations-are-rewiring-to-capture-value?utm_source">отчете</a> McKinsey «The State of AI» разработка программного обеспечения названа одной из областей, где технология быстрее всего переходит от экспериментов к практическому применению. Именно поэтому сегодня внимание постепенно смещается от вопросов внедрения к вопросам долгосрочных последствий такого ускорения.</p> <p>Но вместе с этим изменились и стимулы внутри разработки: во многих случаях написать новое решение оказывается проще, чем разобраться в существующем. Именно здесь начинает формироваться новый механизм накопления технического долга.</p> <p>Проблема заключается не в качестве генерации кода. Современные модели уже доказали свою эффективность: они ускоряют разработку, помогают быстрее реализовывать новые функции и снимают с инженеров значительную часть рутинной работы. Изменения происходят глубже. Вместе с ростом производительности меняется сама экономика инженерных решений. Написать новый код стало проще, тогда как понимание архитектуры, рефакторинг и сопровождение сложных систем не стали дешевле. В результате создать новую реализацию все чаще оказывается проще, чем развивать существующую.</p> <p>Рассмотрим, почему эта тенденция постепенно становится одним из ключевых факторов роста технического долга в эпоху генеративного ИИ.</p> <h3>Главный дефицит сместился</h3> <p>Долгое время одним из основных ограничений в разработке было создание кода. Генеративные модели существенно снизили стоимость этой работы. Сегодня многие задачи, которые раньше требовали значительных затрат времени, решаются за считанные минуты.</p> <p>Но вместе с этим изменился сам характер дефицита. Если раньше главным ограничением было написание кода, то сегодня все большую ценность приобретают понимание системы, проектирование архитектуры, ревью решений и анализ зависимостей между компонентами. Проще говоря, дефицитным становится не код, а способность понимать, как устроен продукт в целом.</p> <p>Это важное изменение. Потому что именно на уровне архитектуры принимаются решения, последствия которых определяют стоимость развития системы через несколько лет.</p> <h3>Изменилась экономика инженерных решений</h3> <p>Технический долг существовал всегда. Любой развивающийся продукт со временем накапливает компромиссы, временные решения и ограничения.</p> <p>Однако раньше разработчик чаще выбирал между двумя одинаково сложными вариантами: переработать существующую логику или написать новую. Сегодня этот баланс нарушен.</p> <p>Рефакторинг по-прежнему остается сложной задачей. Чтобы качественно изменить существующий механизм, необходимо понимать значительную часть системы, учитывать взаимосвязи между модулями и прогнозировать последствия изменений. Такие задачи требуют большого объема контекста и серьезного погружения в проект.</p> <p>Создать новое локальное решение значительно проще. Если появляется очередное бизнес-требование, зачастую быстрее написать отдельную реализацию, чем разбираться в существующей архитектуре. В моменте это выглядит рационально. Задача закрыта, сроки соблюдены, система продолжает работать.</p> <p>Именно поэтому технический долг редко возникает из-за плохих решений. Намного чаще он становится следствием решений, которые были логичны в конкретный момент времени.</p> <h3>Почему становится больше дублирующей логики</h3> <p>Эту тенденцию хорошо видно на крупных продуктах с большим количеством интеграций.</p> <p>Представим систему, в которой уже существует единый механизм работы с сетевыми запросами. Он отвечает за обработку ошибок, сериализацию данных, кеширование, поддержку различных версий API и другие инфраструктурные задачи.</p> <p>Затем появляется новый сценарий, который не укладывается в существующую логику. Архитектурно правильный путь — встроить его в уже работающий механизм. Но для этого необходимо разобраться в текущей реализации, оценить последствия изменений и убедиться, что они не затронут другие части системы.</p> <p>Во многих случаях проще создать отдельное исключение. Один такой случай не создает проблем. Однако со временем исключений становится больше. Появляются несколько вариантов обработки похожих сценариев, дублируются отдельные механизмы, растет количество специальных правил.</p> <p>Каждое решение по отдельности работает. Но общая сложность системы постепенно увеличивается.</p> <h3>Почему ИИ не устраняет технический долг</h3> <p>Существует мнение, что генеративный ИИ поможет справиться с накопленной сложностью за счет ускорения разработки. На практике чаще происходит обратное.</p> <p>ИИ не заменяет инженерную дисциплину. Он усиливает существующие практики. Если команда системно занимается архитектурой, контролирует сложность продукта и регулярно инвестирует время в рефакторинг, новые инструменты позволяют делать это быстрее.</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> <h3>Какие метрики становятся важнее скорости</h3> <p>Распространение генеративного ИИ заставляет по-новому смотреть и на оценку эффективности разработки.</p> <p>Количество написанного кода постепенно теряет смысл как показатель производительности. Схожий вывод <a href="https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/?utm_source">делают</a> и исследователи GitHub. В исследовании качества кода, созданного с помощью GitHub Copilot, авторы предлагают оценивать влияние ИИ не только через скорость разработки, но и через такие характеристики, как сопровождаемость, надежность и читаемость кода. Значительная часть этого объема может представлять собой будущий технический долг.</p> <p>Поэтому все большее значение приобретают другие показатели:</p> <ul> <li> стоимость изменений;</li> <li> объем ресурсов на сопровождение;</li> <li> количество инцидентов после релизов;</li> <li> скорость адаптации новых разработчиков;</li> <li> способность команды безопасно развивать существующую архитектуру.</li> </ul> <p>Именно такие метрики позволяют понять, становится ли продукт устойчивее или просто быстрее наращивает сложность. Не менее важно отслеживать, как изменения влияют на безопасность кода: увеличение числа локальных исключений и дублирующей логики постепенно усложняет аудит, сопровождение и поиск потенциальных уязвимостей.</p> <h3>Что в итоге</h3> <p>Генеративный ИИ не создает технический долг сам по себе. Он меняет условия, в которых принимаются инженерные решения. Создание нового кода становится дешевле. Понимание системы — нет.</p> <p>Поэтому главный вызов ближайших лет связан не с качеством генерации как таковым. Намного важнее сохранить архитектурную дисциплину в условиях, когда написать новую реализацию зачастую проще, чем разобраться в существующей.</p> <p>Чем активнее компании используют ИИ в разработке, тем большее значение будет иметь способность контролировать сложность систем. Именно она определит, станет ли ускорение разработки источником долгосрочного преимущества или приведет к накоплению проблем, которые придется решать уже следующим командам.</p> <p>#IMAGE_235341#</p> Генеративный ИИ заметно изменил работу разработчиков. Создавать новый код стало проще и быстрее, чем когда-либо раньше … article Султан Рамазанов, директор по искусственному интеллекту Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235338 Thu, 13 Aug 2026 09:37:32 +0300 <p><em>Компании годами делают резервные копии, уверенные в том, что данные находятся под защитой. Когда случается инцидент и нужно срочно восстановить работу — выясняется, что копии есть, но восстановление займёт месяц или вовсе невозможно. Разберем типичные заблуждения, из-за которых бэкап превращается в имитацию защиты, и рассмотрим, как проверить систему резервного копирования, не дожидаясь инцидента.</em></p> <h3>Заблуждение первое: репликация заменяет резервное копирование</h3> <p>Репликация — это зеркало системы на текущий момент. Данные основной площадки копируются на резервную в режиме реального времени, и обе всегда синхронизированы. Есть вторая копия, всё актуально, на случай сбоя, есть куда переключиться — и репликация начинает казаться достаточной мерой защиты.</p> <p>Проблема возникает там, где реплика бессильна — например, при ошибке человека. Если данные случайно удалили или повредили на основной площадке, это мгновенно реплицируется на вторую. Обе площадки содержат уже испорченные данные, так как синхронизированы. Откатиться к состоянию до ошибки невозможно: снимка прошлого состояния нет.</p> <p>Резервная копия решает эту задачу — она фиксирует состояние данных в определённый момент времени и позволяет к нему вернуться. Репликация и резервное копирование не взаимозаменяемы: одно обеспечивает доступность, другое — возможность восстановления. Когда одно заменяют другим, защиты от потери данных нет.</p> <h3>Заблуждение второе: зелёные отчёты вместо тестового восстановления</h3> <p>Нередко компании убеждены: раз задания выполняются по расписанию и отчёты зелёные — резервные копии в порядке. Тестовое восстановление откладывается на потом, потому что всё работает и повода проверять нет.</p> <p>Цена этой уверенности выясняется в момент инцидента. При первой необходимости срочно восстановить большой объём данных оказывается, что перекачка займёт месяц: слишком большой объём, слишком медленный канал, хранилище не выдерживает нагрузку на чтение. То, что в планах должно было занимать часы, растягивается на недели. Плановый RTO расходится с реальным: никто заранее не проверил скорость восстановления.</p> <p>Зелёный статус в отчёте говорит только о том, что задание завершилось без ошибок на этапе копирования. Он ничего не говорит о том, цела ли цепочка копий и пригодны ли данные для восстановления. Блоки могут быть повреждены, цепочка инкрементов разорвана, метаданные битые — при этом процесс копирования отработал штатно. Всё это проверяется только тестовым восстановлением — пока оно не сделано, состояние копий под вопросом.</p> <h3>Заблуждение третье: изолировать бэкап — достаточно</h3> <p>Изоляция резервной копии — необходимая база, но не конечная цель. Представим: резервные копии отделены физически — например, в облаке провайдера. Сетевой доступ ограничен изолированным сегментом. Управление доступно только через отдельные учётные записи вне основной инфраструктуры, с обязательным MFA. Даже взломав основную сеть, злоумышленник не может добраться до копий.</p> <p>Но, если изоляция не сработает, следующий уровень защиты — неизменяемость копии. Реализуется это через принцип WORM: в S3-хранилищах — с помощью Object Lock, при котором система на уровне политики отказывается выполнять команду удаления до истечения заданного срока. Даже получив права администратора или root, уничтожить защищённую копию невозможно, пока не истёк заданный срок.</p> <p>На этом моменте легко поставить галочку «защищено» и закрыть вопрос. Но этой меры недостаточно, если срок хранения копии короткий. Злоумышленник, не имея возможности повредить копии, остаётся в инфраструктуре незамеченным и методично повреждает данные в основной системе. Новые бэкапы записывают уже испорченную информацию, а старые — единственные чистые — уходят за пределы глубины хранения и затираются. Когда атака обнаружена, восстанавливаться не из чего: все доступные копии содержат повреждения, а неизменяемость честно охраняла уже бесполезные файлы.</p> <p>Поэтому изоляцию и неизменяемость необходимо дополнять достаточной глубиной хранения. Облако упрощает эту задачу: ёмкость наращивается без закупки оборудования, а старые копии перемещаются в более дешёвые классы хранения.</p> <h3>Как проверить главное в системе бекапа за два часа</h3> <p>При ограниченном времени стоит сосредоточиться на трёх вопросах: изолирован ли доступ к управлению хранилищем, есть ли действительно неизменяемая резервная копия и когда с неё в последний раз проводилось восстановление.</p> <p>Если вход идёт под теми же учётными данными, что и в основной инфраструктуре, компрометация сети открывает путь и к управлению копиями. Доступ выносится в отдельные учётные записи, закрывается вторым фактором, а интерфейс управления отделяется от остальной сети.</p> <p>Следующий вопрос — настроена ли неизменяемость. Ответа «да, настроена» недостаточно. Важно понять, как именно она реализована. WORM-блокировка файловой системы или S3 Object Lock обеспечивают защиту, которую нельзя снять даже с правами администратора. Если же неизменяемость сводится к галочке в интерфейсе, которую тот же администратор может убрать, — это не защита. Отдельный вопрос — срок. Три дня блокировки копии при месячной глубине хранения не перекрывают окно обнаружения атаки. Здесь сталкиваются задачи эксплуатации и безопасности. Администраторы сокращают срок лока до <nobr>3-7 дней,</nobr> чтобы ошибочные бэкапы не тарифицировались месяцами. Специалисты ИБ требуют защиту на весь срок хранения, так как при атаке видят риск: злоумышленник дожидается снятия блокировки и затирает бэкап. Без синхронизации между командами возникает разрыв: копии хранятся месяц, но удалить их можно уже через неделю. Эти параметры нужно выставлять совместно, иначе защита остаётся открытой для атаки.</p> <p>Наконец, необходимо убедиться, что из неизменяемой копии реально можно восстановиться. Единственный способ — тестовое восстановление. Если оно проводилось давно или с тех пор менялась инфраструктура, стоит запустить его немедленно. Полноценно поднять систему за два часа нереально, но восстановить что-то небольшое — можно для диагностики механизма. Тест проверяет ключевые предположения: цепочка копий цела, каталог метаданных исправен, хранилище отдаёт данные. Ломается, как правило, сам механизм — и это выясняется только при реальной проверке.</p> <h3>Что делать, если нашли критическое нарушение</h3> <p>Критические нарушения бывают разными. Например, сервер вовсе не включён в задание резервного копирования, или полная копия не делалась больше года, а всё это время копировались только изменения.</p> <p>Первый импульс — быстро перенастроить задание и считать задачу закрытой. Добавить пропущенный сервер или принудительно запустить полную копию — необходимый первый шаг, но не финальный. Обнаружив проблему, ее нужно превратить в правило, чтобы она не повторилась. Например, регулярно сверять список серверов в задании бэкапа с тем, что реально есть в инфраструктуре, — это исключит ситуацию, когда сервер просто забыли добавить. А правило о том, что полная копия должна обновляться регулярно, не даст инкрементам накопиться до состояния, когда восстановление уже невозможно.</p> <p>После того как точечные нарушения закрыты, проверяем главное: рабочая ли копия. Убедиться в этом можно только тестовым восстановлением. Разовая проверка закрывает вопрос сегодня, но не завтра. Тестовое восстановление должно быть регулярной процедурой, закреплённой в регламенте, — иначе его снова отложат до инцидента.</p> <p>#IMAGE_235339#</p> Компании годами делают резервные копии, уверенные в том, что данные находятся под защитой. Когда случается инцидент … article Виктор Виноградов, директор по информационной безопасности mt cloud https://www.itweek.ru/themes/detail.php?ID=235337 Thu, 13 Aug 2026 09:30:08 +0300 <p><em>Агентная разработка ПО снижает барьер для создания приложений, но также поднимает более сложный вопрос для технологических лидеров: кто несет ответственность, когда ПО, созданное с помощью искусственного интеллекта, становится критически важным для бизнеса? В новом отчете </em><em>Forrester</em> <em>«</em><em>Reinventing</em> <em>Software</em> <em>Development</em> <em>Services</em> <em>For</em> <em>The</em> <em>Age</em> <em>Of</em> <em>AI</em> <em>Coding</em><em>» утверждается, что поставщики услуг по разработке ПО сталкиваются с кризисом идентичности, поскольку производство кода становится сервисом массового потребления, а клиенты ставят под сомнение рентабельность инвестиций в аутсорсинг по сравнению с разработкой собственными силами с использованием ИИ. Лучшие сервис-провайдеры перейдут от продажи инженерных возможностей к продаже доверия: отказоустойчивой архитектуры, снижению рисков, организации контекста и подотчетности, пишет в корпоративном блоге Клинтон Хергет, главный аналитик </em><em>Forrester</em><em>.</em></p> <h3>ИИ-кодирование делает доверие новой валютой в сфере ПО</h3> <p>Когда бизнес может сам превратить промпт в работающее приложение, старая концепция услуг по разработке ПО начинает давать сбой. Если создание кода собственными силами кажется простым, быстрым и дешевым, зачем платить сервис-провайдеру за его разработку?</p> <p>Этот вопрос сейчас напрямую стоит перед поставщиками услуг на этом рынке. Быстрое совершенствование обученных кодированию больших языковых моделей (LLM) снизило барьер для создания работающих приложений для любого, кто имеет доступ к таким LLM и базовые навыки работы с промптами. В результате предприятия экспериментируют с созданием ПО собственными силами (особенно «гражданскими разработчиками»), в то время как поставщики услуг пытаются объяснить, почему предлагаемая ими ценность выходит за рамки простого написания кода.</p> <p>Но реальная проблема не в том, что создание ПО стало простым, а в том, что код стал менее важным источником ценности.</p> <p>Более сложная работа переместилась в другие области: архитектуру, проектирование продуктов, безопасность, ремонтопригодность, контроль затрат, обеспечение качества, интеграцию и долгосрочную отказоустойчивость. В отчете четко обозначено это противоречие: поставщики услуг должны отказаться от предоставления инженерных возможностей как услуги и перейти к долгосрочным, учитывающим риски, основанным на ответственности партнерствам, подкрепленным глубокой человеческой экспертизой.</p> <h3>Следующее поле битвы — ответственность за ПО</h3> <p>Поставщикам услуг по разработке ПО не нужно выигрывать у ИИ соревнование по написанию кода. Им нужно обеспечить ценностное предложение, основанное на доверии. Им нужно переориентироваться на продажу гарантий как услуги (Assurance As A Service).</p> <p>ПО остается сложным. Со временем корпоративные приложения накапливают риски в виде ошибок, простоев, критических изменений API, уязвимостей безопасности, проблем с интеграцией и технического долга. Код может быть стало проще генерировать, но надежность и контроль затрат не являются общим местом.</p> <p>Текущий сдвиг порождает новое ценностное предложение для поставщиков и новый взгляд на покупку для клиентов. В отчете представлены несколько основных рекомендаций, описанных ниже.</p> <h3>Оптимизация разработки с приоритетом ИИ</h3> <p>Качество ПО, созданного ИИ, во многом зависит от того, как команды определяют, направляют, тестируют и проверяют его работу. В отчете утверждается, что поставщики услуг могут создавать ценность, освоив методы разработки с помощью ИИ, включая разработку на основе спецификаций, правильный выбор инструментов для моделей и агентов, а также эффективное использование токенов. Эти возможности наиболее важны в сложном корпоративном ПО, для которого работающий прототип — это только начало. Помогая клиентам улучшить использование ИИ, поставщики могут конкурировать за счет измеримого улучшения, а не только за счет объема доставки.</p> <h3>Дифференциация за счет архитектуры и дизайна продукта</h3> <p>ИИ может генерировать код, но люди по-прежнему принимают многие решения, которые с наибольшей вероятностью влияют на результаты бизнеса. В отчете отмечается, что почти половина организаций использует ИИ на этапе кодирования жизненного цикла разработки ПО (SDLC), по сравнению с 35% на этапах анализа и планирования. Этот разрыв имеет значение: навыки управления продуктом (например, анализ заинтересованных сторон, определение требований) плюс навыки проектирования систем (например, моделирование данных, определение микросервисов, облачная инфраструктура) остаются критически важными источниками ценности, предлагаемой поставщиками услуг. Реальная возможность для консалтинга заключается не в том, чтобы «писать код быстрее», а в том, чтобы «убедить, что мы создаем правильный продукт правильным способом».</p> <h3>Продавайте отказоустойчивость вместо скорости</h3> <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=235336 Wed, 12 Aug 2026 14:39:14 +0300 <p>Компания Security Vision представила обновление платформы SV5. Ключевой фокус релиза — развитие инструментов интеграции и оптимизация работы с данными. Платформа получила новые параметры коннекторов, дополнительные аналитические функции и более гибкие механизмы управления настройками.</p> <p>Для WMI-коннектора добавлена настройка пространства имён (namespace) для выполнения WQL-запросов по заданному адресу. В конфигурациях коннекторов также появились сжатие при передаче событий. Обновление библиотеки librdkafka обеспечивает работу Kafka-коннектора с аутентификацией SASL/SCRAM для версий 4.0.0 и выше.</p> <p>В переменные добавлено преобразование чисел между двоичной, восьмеричной и шестнадцатеричной системами счисления. Новая возможность расширяет сценарии нормализации и подготовки данных.</p> <p>В преобразовании «Формула» появились функции вычисления модуля числа и квадратного корня — abs() и sqrt().</p> <p>Для виджетов «Линейный график» и «Столбчатая диаграмма» добавлены настройки масштабирования, позволяющие точнее настраивать отображение данных.</p> <p>Выгрузка отчётов через портал переведена на асинхронный режим, что делает работу с длительными операциями формирования отчётности удобнее.</p> <p>Обновлены настройки блока «Граф» и отображение блока «История» в карточке объекта. Также скорректирован интерфейс представлений в редакторе типов объектов системы и справочников.</p> <p>В настройках модулей расширено управление иконками, а условие маппинга иконок в графе переработано в формат фильтра.</p> <p>Для Правил корреляции создан новый раздел с общим представлением и редактором. В журнале аудита изменения правил группировки теперь фиксируются раздельно для системных и пользовательских справочников, а запуск выключенных коннекторов через рабочие процессы запрещён.</p> Компания Security Vision представила обновление платформы SV5. Ключевой фокус релиза — развитие инструментов интеграции … message https://www.itweek.ru/themes/detail.php?ID=235335 Wed, 12 Aug 2026 14:37:07 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил анализ российского рынка интеллектуальной собственности и изучил на основе данных Роспатента интенсивность и ключевые тренды лицензионной деятельности в России, уделяя особое внимание динамике и структуре вовлечения исключительных прав в хозяйственный оборот.</p> <p>В 2025 г. Роспатент зарегистрировал почти 2,7 тыс. распоряжений исключительным правом на изобретения, полезные модели и промышленные образцы — на 4,6% больше, чем годом ранее. Из них 2,2 тыс. (+4%) составили коммерческие договоры о предоставлении права использования и об отчуждении исключительного права.</p> <p>Патентообладатели по-прежнему чаще предоставляют право использования по лицензии, чем полностью отчуждают исключительное право: в 2025 г. зарегистрировано почти 1,3 тыс. таких распоряжений против 944 договоров об отчуждении.</p> <p>Почти две трети зарегистрированных распоряжений (65,9%) относились к изобретениям, доля которых среди патентов, включенных в сделки, составила 43,2%. На полезные модели приходилось 20,2% распоряжений и 38,3% патентов, на промышленные образцы — 14 и 18,5% соответственно. При этом в <nobr>2020–2025 гг.</nobr> число распоряжений исключительным правом на изобретения сократилось на 18,4%, а количество патентов, включенных в такие сделки, — на 20,3%.</p> <p>На протяжении всего рассматриваемого периода наибольшее число распоряжений приходилось на патенты в области химии и нефтехимии, медицины, энергетики и электротехники. В 2025 г. их суммарная доля в общем потоке зарегистрированных распоряжений составила 39,1%.</p> <p>По сравнению с предыдущим годом наиболее заметно выросло число распоряжений правами на разработки в области легкой и пищевой промышленности (+29,9%), химии и нефтехимии (+13,2%), нефтегазодобычи (+12,6%). Положительная динамика также отмечалась в электронике, вычислительной технике и приборостроении (+3,5%), металлургии (+1,5%). Снижение наблюдалось в энергетике и электротехнике (-18,2%), машиностроении, станкостроении и производстве инструмента (-15,5%), медицине (-5,8%), строительстве и производстве строительных материалов (-4,1%).</p> <p>Основными участниками рынка интеллектуальной собственности выступают частные организации. В 2025 г. на них приходилось 62% зарегистрированных распоряжений со стороны лицензиаров (продавцов) и 88% — со стороны лицензиатов (покупателей). Доля физических лиц составляла соответственно 24 и 8%. Суммарный вклад государственных предприятий, НИИ, КБ и вузов оставался ограниченным — 14% среди лицензиаров и 4% среди лицензиатов.</p> <p>Роспатент также регистрирует распоряжения исключительными правами на объекты в сфере цифровизации — программы для ЭВМ, базы данных и топологии интегральных микросхем. В 2025 г. зарегистрировано 662 таких распоряжения — несколько меньше, чем годом ранее, но почти в полтора раза больше, чем в начале рассматриваемого периода (2020 г.). Договоры об отчуждении исключительного права составляли 89,9% их общего числа.</p> <p>По итогам 2025 г. число распоряжений исключительным правом на патенты впервые с 2021 г. выросло. Основной вклад внесла активизация сделок с полезными моделями и промышленными образцами. Рынок по-прежнему формируют преимущественно частные организации, а в цифровом сегменте доминируют сделки по отчуждению исключительных прав.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ продолжил анализ российского рынка интеллектуальной … message https://www.itweek.ru/themes/detail.php?ID=235334 Wed, 12 Aug 2026 14:32:19 +0300 <p>«СёрчИнформ» представила результаты опроса, проведенного в 2026 году среди 100 специалистов и руководителей служб ИБ коммерческих и государственных организаций. Респондентам были заданы вопросы о технической реализации средств защиты файловой инфраструктуры. В опросе приняли участие малые организации (39%) и средние и крупные компании (61%).</p> <p>Большинство опрошенных организаций используют для хранения данных файловые серверы (87%), АРМ сотрудников (80%) и базы данных (68%).</p> <p>Также аналитики «СёрчИнформ» выяснили основные причины применения мер защиты данных в организациях. На первом месте у российских компаний стоят требования властей к защите персональных данных, которые мотивируют 87% опрошенных внедрять соответствующие меры. Следующей по значимости причиной являются нормативные требования к защите информации в государственных информационных системах — 63%. Собственные локальные акты также играют важную роль в защите данных для 54% компаний. В условиях увеличения штрафов за ИБ-нарушения и актуализации требований к безопасности ИС госсектора и КИИ, защита файловой инфраструктуры становится объективной потребностью организаций любых отраслей.</p> <p>Значительную долю среди опрошенных организаций занимают меры по обеспечению защиты критической информационной инфраструктуры — 46%. Прикладные задачи организации требуют внедрения мер защиты в 28% случаев, а защита коммерческой тайны — в 24%.</p> <p>Самые распространенные проблемы при защите данных: сложности с контролем операций с данными (44%), согласование настроек для различных ИТ- и ИБ-систем (42%) и классификация содержимого файлов (38%).</p> <p>«Обработка и передача информации, в том числе конфиденциальной, — это основа критических бизнес-процессов в любой организации. Поэтому важно контролировать работу сотрудников с такой информацией, а также минимизировать риски утечек, порчи, уничтожения конфиденциальных данных. Однако большинству опрошенных компаний сложно найти баланс между обеспечением защиты и сохранением оперативности работы с данными. Первый шаг к решению этой задачи — классификация всех файлов по содержанию, чтобы определить, какие из них требуют особого контроля и защиты», — отметил Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Аналитики «СёрчИнформ» в рамках опроса выяснили, какие инструменты используют российские компании в 2026 году для защиты данных. Опрошенные активно используют штатные средства системного программного обеспечения и баз данных. Эти инструменты применяют 89% компаний. Криптографические средства защиты используют 68% организаций, прикладное ПО, не относящееся к средствам защиты — 56%. Системы аудита и защиты файловых хранилищ (DCAP) задействованы в защите данных лишь у 9% организаций.</p> <p>«Большинство компаний защищают данные сразу несколькими способами. Но чаще всего для этого используют встроенные функции информационных систем и прикладного ПО, а не специализированные средства. Такой формат защиты не позволяет организациям в полной мере реализовать задачи защиты конфиденциальных данных, более того — размывает политики безопасности до индивидуальных настроек в разных системах, не синхронизированных в единую логику. Защита при таком сценарии становится точечной, а момент передачи из системы в систему вовсе выпадает из-под контроля», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Внедрение автоматизированных решений по маркировке — важный шаг к повышению уровня информационной безопасности и соблюдению законодательства. При этом, большая часть опрошенных компаний (78%) не выполняют маркировку защищаемых электронных документов, в частности, проставление грифов «Коммерческая тайна», «Для служебного пользования».</p> <p>«Текущий уровень автоматизированной маркировки защищаемых электронных документов в организациях остается крайне низким — всего 4% компаний используют технические средства, такие как системы аудита и защиты файловых хранилищ (DCAP), для автоматической маркировки конфиденциальной информации. Большинство (78%) и вовсе не проводят такую работу. Из-за этого бизнесу будет проблематично применить меры дисциплинарной и материальной ответственности за разглашение коммерческой тайны в „цифре“, а у организаций госсектора возникает риск нарушения требований властей, в частности, постановления Правительства РФ № 1233 от 13.11.1994», — прокомментировал Дмитрий Вощуков, специалист по связям с государственными органами «СёрчИнформ».</p> <p>43% опрошенных компаний отмечают недостаток функциональности имеющихся средств для защиты данных.</p> <p>В связи с этим, невысок показатель обнаружения инцидентов с несанкционированным доступом внутренних нарушителей к защищаемой информации.</p> <p>«Штатные ИТ-средства не умеют классифицировать файлы по содержимому. Кроме того, нарушитель может обойти встроенные ограничения: достаточно переместить файл или изменить его разрешения. Поэтому для защиты данных нужны специализированные средства — криптографические и некриптографические. Например, системы аудита и защиты файлов (DCAP). Они автоматически находят и классифицируют конфиденциальные документы, применяют меры защиты только к чувствительным данным и позволяют контролировать их на всех этапах жизненного цикла», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> <p>Многофункциональность систем аудита и защиты файлов и гибкость их применения подтверждаются данными опроса. Наиболее важной функцией для компаний является защита от утечек и неправомерного доступа (86%), аудит обработки конфиденциальных данных (71%), инвентаризация информационных активов (57%) и контроль прав доступа пользователей к информации (57%).</p> <p>Системы аудита и защиты файлов — не единственный инструмент внутренней информационной безопасности. Решения этого класса интегрируются с другими средствами защиты информации, позволяя обеспечить максимально эффективную защиту от неправомерного доступа и действий с защищаемыми данными. 86% опрошенных компаний интегрируют системы аудита и защиты файловых хранилищ (DCAP) со средствами предотвращения утечек информации (DLP), 14% встраивают средства аудита и защиты файлов в инфраструктуру центров обеспечения ИБ (SOC), столько же — объединяют функции этих решений и инструментов защищенного обмена и работы с данными (VDR).</p> <p>Главные стоп-факторы, сдерживающие внедрение систем аудита и защиты файловых хранилищ (DCAP) среди российских компаний — неосведомленность о средствах этого класса (49%), высокая стоимость (43%) и нехватка кадров для работы с системой (39%).</p> <p>«Системы аудита и защиты файлов (DCAP) — все еще новое для большинства заказчиков решение. Хотя первые системы этого класса появились в конце 2010 года, рынок все еще формируется. Вопрос цены при внедрении системы аудита и защиты файлов (DCAP) возникает при выборе между их применением и использованием штатных средств ОС или прикладного ПО. При этом функций неспециализированных систем в большинстве случаев недостаточно для защиты данных. Среди специализированных средств защиты информации, решения этого класса — одни из наиболее простых в использовании и нетребовательных к аппаратным мощностям. Использование системы аудита и защиты файлов (DCAP) снижает нагрузку на ИБ-службы и позволяет высвободить время ИБ-специалистов, поскольку автоматизирует рутинные процессы аудита и разграничения доступа к файлам», — прокомментировал Алексей Парфентьев, заместитель генерального директора по инновационной деятельности «СёрчИнформ».</p> «СёрчИнформ» представила результаты опроса, проведенного в 2026 году среди 100 специалистов и руководителей … message https://www.itweek.ru/themes/detail.php?ID=235333 Wed, 12 Aug 2026 14:29:35 +0300 <p>ГигаАгент от Сбера — первый в России автономный универсальный ИИ-агент для решения повседневных задач: управления календарём, работы с документами, ведения переписки, исследования информации, создания отчётов и презентаций. ГигаАгент — это российский ответ зарубежным решениям OpenClaw, Hermes Agent, NemoClaw.</p> <p>В отличие от диалоговых интерфейсов (чатов) ГигаАгент способен лучше запоминать контекст, не нуждается в контроле каждого шага, учитывает и накапливает обратную связь, подстраивается под индивидуальный способ работы пользователя. Агент может работать автономно и в фоновом режиме, проявляет проактивность: самостоятельно задаёт уточняющие вопросы, когда этого требует ситуация, и способен параллельно решать несколько задач в едином смысловом поле.</p> <p>Три свойства принципиально выделяют ГигаАгент среди существующих решений: </p> <ul> <li>автономность. ГигаАгент взаимодействует с пользователем как самостоятельный агент 24/7 и в проактивном режиме. Если ему не хватает информации, он честно сообщает об этом, а если находит ошибку в рассуждениях, может аргументированно возразить. Такое поведение заложено в архитектуру системы и делает долгосрочное взаимодействие более последовательным и предсказуемым. ГигаАгент не просто исполнитель, а полноценный партнёр, готовый к дискуссии и обсуждению идей для реализации;</li> <li>саморазвитие. ГигаАгент способен самостоятельно совершенствовать свою работу. Он читает и переписывает собственный исходный код. Каждое изменение фиксируется как коммит во встроенном Git-репозитории. Агент ведёт список улучшений, которые используются при восстановлении в случае возникновения критических ошибок;</li> <li>непрерывность. Большинство ИИ-агентов работают только в рамках одной сессии и не сохраняют накопленный опыт. ГигаАгент, напротив, запоминает предыдущие задачи, принятые решения и историю взаимодействия. После перезапуска он продолжает работу с учётом уже накопленного контекста, что позволяет использовать его как ИИ-агента с долговременной памятью.</li> </ul> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «ГигаАгент — это новый этап взаимодействия человека с генеративным искусственным интеллектом. Если раньше ИИ лишь находил ответы, то теперь становится полноценным цифровым партнёром, который помогает достигать рабочих и личных целей. Появился новый сценарий. Вы ставите задачу — агент анализирует её сложность, планирует решение и разбивает на подзадачи, при необходимости пишет код и в итоге готовит финальный ответ пользователю. Это может быть как в целях повышения личной эффективности, так и для автоматизации бизнес-процессов, а ГигаАгент адаптируется и эволюционирует вместе с пользователем. Важно, что это полностью российская разработка, безопасная и доступная каждому».</p> <p>В основе ГигаАгента лежит проект саморазвивающегося ИИ-агента Ouroboros, разработанного командой исследователей Института AIRI. Сейчас фреймворк развивается совместно с командой Сбера и стал важным этапом в развитии технологии генеративного искусственного интеллекта. На бенчмарках агент демонстрирует высокие результаты — на лидерборде Terminal Bench 2.1 для модели Opus 5 от Anthropic качество агента составляет 86,97%.</p> <p>Для хранения и обработки данных пользователя ГигаАгент использует только отечественные платформы. Например, его можно запустить с помощью такого решения для организации работы с ИИ-агентами, как Agents Space. </p> ГигаАгент от Сбера — первый в России автономный универсальный ИИ-агент для решения повседневных задач: управления … message https://www.itweek.ru/themes/detail.php?ID=235332 Wed, 12 Aug 2026 14:20:36 +0300 <p>Аналитики компании IT_ONE проанализировали около 12 тысяч вакансий в разных направлениях разработки ПО. Почти в 35% из них в перечне требований к кандидату встречалось упоминание вайбкодинга. Работодатели всё чаще ожидают от специалистов знания популярных ИИ-инструментов и умения эффективно встраивать ИИ в процесс разработки.</p> <p>Согласно исследованию IT_ONE наиболее часто такие требования к знанию вайбкодинга предъявлялись к кандидатам на должности Data-инженера / Data-сайентиста, <nobr>ML-инженера,</nobr> системного аналитика. </p> <p>Среди языков программирования для вайбкодинга чаще всего упоминались Python (безусловный лидер) и Java. </p> <p>Ввиду того, что вайбкодинг — относительно новое явление, использование этого определения на рынке пока не носит системный характер. В большинстве вакансий для описания этого явления употреблялся термин «ИИ-разработка» или смежные термины — такие, как «ML», «промпт-инжиниринг» в контексте разработки и т. д.</p> <p>Среди типов требований по вайбкодингу встречаются знание ИИ-инструментов (GitHub Copilot, Cursor, ChatGPT, Claude) и навыки проверки и тестирования ИИ-сгенерированного кода (валидации). Владение инструментами для вайбкодинга фактически стали отраслевым стандартом. </p> <p>Со средней частотой упоминаются умение составлять эффективные промпты для автоматизированного создания кода (промпт-инжиниринг), понимание границ возможностей языковых моделей (LLM), умение встраивать ИИ в процесс разработки (workflow). </p> <p>Относительно редко работодатели требуют умение использовать ИИ для отладки кода (AI-assisted debugging), навыков ИИ-генерации unit-тестов и тест-кейсов, навыков создания и настройки ИИ-агентов для автоматизации. ИИ-агенты и автоматизация — новые тренды среди запросов.</p> <p>Дополнительно аналитики IT_ONE провели опрос руководителей компаний, для которых актуально направление внутренней разработки. </p> <p>Чаще всего в таких компаниях с помощью ИИ решают или планируют решать задачи написания и рефакторинга кода, автоматизации рутинных задач, генерации тестов и тест-кейсов, дебаггинга и поиска ошибок. Среди других задач — генерация документации и SQL-запросов, анализ требований, поиск и отбор кандидатов (HR), автоматизация код-ревью. </p> <p>Сотрудники этих компаний заинтересованы в повышении квалификации в области промпт-инжиниринга, методов обеспечения безопасности и конфиденциальности данных при взаимодействии с ИИ, оценки качества ответов ИИ, интеграции ИИ в CI/CD. Также упоминаются юридические и этические аспекты работы с нейросетями. </p> <p>При этом респонденты отметили проблемы, ограничивающие возможности специалистов. Наиболее актуальные из них — нехватка внутренних инструментов ИИ, блокировка внешних сервисов (в том числе из-за санкций), нехватка знаний в промпт-инжиниринге, невозможность оценить пользу от применения ИИ. </p> <p>На низкое качество и нерелевантность ответов моделей сотрудники жалуются довольно редко. Нехватка вычислительных мощностей также пока не является основным сдерживающим фактором для большинства компаний: это может означать, что бизнес уже подготовился к применению ИИ, или что ИИ в опрошенных компаниях используется пока в небольшом объеме, или что ставка делается на облачные модели. </p> <p>Отдельно стоит упомянуть востребованность компаний в специалистах с опытом применения ИИ в ИТ-ландшафте, построенном на российском ПО. </p> <p>«Сегодня под вайбкодингом рынок обычно понимает не умение „кодить на ощущениях“, а применение ИИ в качестве ассистента (AI-assisted / agentic coding). Разработчик должен уметь быстро получать черновой код от LLM/агентов, но при этом он сам отвечает за архитектуру этого кода, проверку, безопасность и выпуск в прод. Это означает, что рынку нужны в первую очередь опытные специалисты, которые сочетают классические навыки программирования и CI/CD с навыками вайбкодинга. ИИ-инструменты становятся для них „супер-помощниками“ для ускорения рутинных задач: генерации и оптимизации SQL и Spark-кода, автоматизации ETL, документирования, рефакторинга», — отметила Ксения Манскова, руководитель направления ресурс-менеджмента в компании IT_ONE. </p> Аналитики компании IT_ONE проанализировали около 12 тысяч вакансий в разных направлениях разработки ПО. Почти … message https://www.itweek.ru/themes/detail.php?ID=235331 Wed, 12 Aug 2026 14:19:00 +0300 <p>Компания BSS обновила разработанную для банков систему противодействия мошенничеству (FRAUD-Анализ), добавив модуль интеграции с государственной системой обмена данными о цифровом мошенничестве — ГИС Антифрод.</p> <p>Модуль позволяет банкам автоматически получать сведения от других кредитных организаций, операторов связи, ЦБ и государственных ведомств о связанных с мошенничеством лицах и телефонных номерах, выявленных попытках противоправных действий и других признаках цифрового мошенничества.</p> <p>Эти сведения становятся дополнительными сигналами при оценке операций и принятии решений. Новый модуль BSS позволяет не только технически подключиться к государственной системе, но и настроить обработку сигналов оттуда с учетом внутренних процессов банка, чтобы оперативно учитывать поступающие сведения при проведении операций. А при появлении новых типов сигналов их можно будет добавлять в систему без полной перестройки интеграции. </p> <p>«Для банков интеграция с ГИС Антифрод открывает доступ к важнейшему источнику сигналов при проверке операций, помогает защищать интересы клиентов и снижать собственные риски. С 1 марта 2027 года неисполнение требований по использованию сведений ГИС Антифрод может повлечь обязанность банка возместить клиенту сумму перевода, совершенного без его согласия», — отметил Илья Иванов, директор по развитию продуктов Центра разработки интеграционных решений и антифрод-систем компании BSS.</p> <p>Система противодействия мошенничеству от BSS (FRAUD-Анализ) обеспечивает безопасность дистанционного обслуживания как юридических, так и физических лиц и защищает от действий злоумышленников. Система успешно используется российскими банками для комплексного мониторинга и предотвращения мошенничества.</p> Компания BSS обновила разработанную для банков систему противодействия мошенничеству (FRAUD-Анализ), добавив модуль интеграции … message 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> <ul> <li> <strong>Доступ к корпоративным системам.</strong> Пользователям может потребоваться повторная авторизация, а компании — настройка прав, учётных данных и сетевых ограничений.</li> <li><strong> Возможности конкретного ИИ-инструмента.</strong> Например, ChatGPT, Codex, Cursor, GitHub Copilot, Kiro и VS Code могут различаться по поддержке отдельных функций и способам их реализации. Если сценарий зависит от функции конкретного инструмента, в другом она может быть недоступна или работать иначе. Поэтому при разработке плагина лучше по возможности избегать функций, привязанных к конкретному ИИ-инструменту.</li> <li><strong> Выполнение рабочего сценария.</strong> Из-за различий между моделями, системными настройками и механизмами подтверждения действий один и тот же плагин может давать разные результаты. При этом ИИ-инструмент и модель ИИ — разные компоненты. Например, ChatGPT — ИИ-инструмент, а GPT — семейство моделей, которые он может использовать. Поэтому тестировать необходимо связку конкретного инструмента и выбранной модели.</li> <li><strong> Установку и распространение.</strong> Каждый ИИ-инструмент по-своему организует подключение плагинов, выдачу доступа пользователям и установку обновлений.</li> </ul> <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> <ol> <li><strong>Слой над системой</strong> — копилоты, запросы на естественном языке, аналитика. Этот подход не затрагивает ядро системы, внедряется быстро и безопасно, поэтому считается отличной точкой старта ИИ-трансформации.</li> <li><strong>Сервисы внутри или рядом с системой</strong> — распознавание, прогнозирование, классификация. Подключаются через вызовы API и расширения. Именно здесь ИИ встраивается непосредственно в прикладные модули ERP, CRM, MES, Workflow.</li> <li><strong>Слой под системой</strong> — данные, СУБД, инфраструктура. Эффективен для разбора логов, мониторинга и контроля качества данных. Например, ИИ может за считанные минуты написать скрипт парсинга сотен гигабайт технологических логов и выявить причины сбоев и медленных запросов. За день интенсивной работы можно получить 100 Гб текста в формате логов. Даже профильный специалист будет разбирать такой объем вручную несколько дней, а ИИ выдает результат для оценки эксперта за минуты.</li> </ol> <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> <ul> <li><strong> Классический ИИ:</strong> модели ИИ, такие как глубокое обучение, трансформеры и обучение с подкреплением, которые работают исключительно на CPU, GPU или TPU и обеспечивают измеримую окупаемость инвестиций для предприятий уже сегодня.</li> <li><strong> ИИ, дополненный квантовыми методами (</strong><strong>Quantum</strong><strong>-</strong><strong>inspired</strong> <strong>AI</strong><strong>):</strong> классические алгоритмы, заимствующие идеи из квантовой механики, такие как отжиг, тензорные сети и амплитудное кодирование, но работающие на обычном оборудовании. Эти методы уже приносят пользу в задачах оптимизации, моделирования и выборки и не зависят от квантового оборудования.</li> <li><strong> Гибридные квантово-классические методы:</strong> экспериментальные рабочие процессы, в которых небольшие квантовые схемы используются совместно с классическим ИИ или высокопроизводительными вычислительными системами (HPC). Эти подходы используются для исследований и пилотных проектов с поддержкой поставщиков, а не для производственного ИИ.</li> </ul> <p>«Когда поставщики заявляют о предоставлении „квантового ИИ“, они обычно имеют в виду гибридные или дополненные квантовыми технологиями методы, а не нативно-квантовый ИИ, работающий в масштабах предприятия, — отмечает Декате. — Настоящие квантовые вычисления не готовы ни к одной производственной ИИ-нагрузке и, скорее всего, не будут готовы до конца этого десятилетия. Более того, ни один рецензированный результат не демонстрирует квантового преимущества в производственных ИИ-нагрузках».</p> <p>Формирование пула поставщиков, ориентированных на конвергенцию квантовых технологий и ИИ, ускоряется, и советы директоров, находящиеся под давлением необходимости «не упустить квантовые технологии», будут склонны перенаправлять ИИ-бюджеты на НИОКР, которые не смогут принести пользу в этом десятилетии. Поэтому Gartner прогнозирует, что отказоустойчивые квантовые вычисления для ИИ до конца 2030 г. останутся на стадии НИОКР, с недостаточным масштабом логических кубитов для поддержки экономически жизнеспособных сквозных алгоритмов ИИ.</p> <h3>Разделите квантовый бюджет и ИИ-бюджет</h3> <p>Квантовые НИОКР и производственная инфраструктура ИИ имеют несовместимые временные горизонты, юнит-экономики и потребности в управлении. Генеративный ИИ приносит измеримую отдачу по показателям скорости выполнения, точности и автоматизации в течение <nobr>12-18 месяцев.</nobr> Между тем, квантовый ИИ никогда еще не приносил измеримой ценности ни в одной производственной рабочей нагрузке и вряд ли сделает это в обозримом будущем.</p> <p>«Смешивание двух бюджетов искажает подотчетность обоих и позволяет квантовой опциональности вытеснять производственные возможности ИИ, — говорит Декате. — CIO на постоянной основе включают генеративный ИИ, агентный ИИ, кибербезопасность и облачные технологии в категории основных расходов. Квантовые технологии не фигурируют в списках приоритетных инвестиций. CIO, которые финансируют квантовые технологии, делают это по значительно более низким ставкам, чем генеративный ИИ, и не требуют краткосрочной окупаемости инвестиций».</p> <p>Чтобы получить максимальную отдачу от квантовых решений, предприятиям следует:</p> <ul> <li><strong> Внедрять классические методы, дополненные квантовыми технологиями, в существующий стек ИИ.</strong> Организациям следует отдавать приоритет алгоритмам, дополненными квантовыми методами, работающим на современной инфраструктуре GPU, а не развитию квантового оборудования. В таких областях, как оптимизация, генеративный ИИ, линейная алгебра, анализ графов и обучение с подкреплением, классические подходы обеспечивают аналогичные преимущества без затрат, сложности или незрелости квантовых систем.</li> <li><strong> Определить критерии прекращения пилотного проекта и не вестись на показуху со стороны поставщиков.</strong> Каждый пилотный квантовый проект должен начинаться с предварительного определения показателей успеха, четкого классического эталона и явных условий прекращения. Это предотвращает чрезмерное расходование бюджета на бесконтрольные эксперименты без получения измеримой ценности.</li> <li><strong> Отслеживать значимый квантовый прогресс.</strong> Наиболее важным показателем прогресса является не количество физических кубитов, а доступность логических кубитов, работающих с приемлемым уровнем ошибок. Достижения в области коррекции ошибок, калибровки с помощью ИИ и квантового управления более важны для получения бизнес-ценности, чем громкие заявления о более крупных квантовых процессорах.</li> </ul> Согласно 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