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=235623 Fri, 25 Sep 2026 10:12:58 +0300 <p><em>Разница между двумя системами бесперебойного питания (ИБП) проявляется не только в счёте за электроэнергию. Она определяет, сколько мощности дойдёт до серверов, какой запас останется для роста и во что обойдётся незакрытый сценарий отказа.</em></p> <p>В закупке более дешёвый ИБП легко выигрывает таблицу сравнения. Но ЦОД покупает не просто шкаф с оборудованием. Он фактически покупает долю входной мощности, которая дойдёт до IT-нагрузки и сможет работать на бизнес.</p> <p>На объекте с IT-нагрузкой 1 МВт разница всего в один процентный пункт КПД — между 96,5 и 97,5% — означает примерно 10,6 кВт входной мощности. За год непрерывной работы это около 93 МВт·ч. Для коммерческого ЦОДа проценты из паспорта оборудования превращаются в вполне материальные киловатты и деньги.</p> <h3>Десять киловатт, которых не видно в цене закупки</h3> <p>Для примера возьмём две системы ИБП, работающие в одинаковом режиме и при сопоставимой нагрузке. IT-оборудованию нужно получить 1 МВт.</p> <ul> <li> при КПД 96,5% на входе потребуется 1000/0,965 = 1036,3 кВт;</li> <li> при КПД 97,5% — 1000/0,975 = 1025,6 кВт;</li> <li> разница — около 10,6 кВт.</li> </ul> <p>Если нагрузка остаётся постоянной весь год:</p> <p><em>10,6 кВт × 8760 часов ≈ 93 МВт·ч.</em></p> <p>Это результат только по цепочке электропитания. Дополнительный эффект от снижения тепловыделения и нагрузки на охлаждение нужно считать отдельно.</p> <p>Экономический смысл этих 10,6 кВт зависит от ограничений конкретного объекта.</p> <table> <tbody> <tr> <th> Ситуация</th> <th> Что даёт более высокий КПД</th> </tr> <tr> <td> На вводе есть запас, IT-нагрузка одинакова</td> <td> Снижение потребления электроэнергии и тепловыделения</td> </tr> <tr> <td> Мощность на вводе ограничена, есть спрос и резерв по остальной инфраструктуре</td> <td> Дополнительная мощность для IT-нагрузки</td> </tr> <tr> <td> Объект работает далеко от проектной загрузки</td> <td> Результат определяет реальная кривая КПД, а не паспортный максимум</td> </tr> </tbody> </table> <p>В первом сценарии денежный эффект можно оценить так:</p> <p><em>Экономия за год = разница потерь, кВт × часы работы × тариф.</em></p> <p>Во втором сценарии используется другая формула:</p> <p><em>Потенциальный годовой эффект = высвобождённая мощность, кВт × маржинальный доход с 1 кВт в месяц × 12.</em></p> <p>Эти эффекты нельзя автоматически складывать: это разные сценарии использования мощности. Чтобы не подменять расчёт красивой цифрой, оператор должен подставить собственные тарифы, загрузку и экономику продажи мощности.</p> <p>Например, при маржинальном доходе 16 тыс. рублей с 1 кВт в месяц потенциальный эффект от 10,6 кВт составит около 2 млн. рублей в год. Это не рыночный норматив и не обещание дохода, а иллюстрация формулы. Она работает только при наличии спроса и при условии, что охлаждение, распределение и площадь позволяют разместить дополнительную нагрузку.</p> <p>Один из вопросов, который я предлагаю задать проектной команде ещё до сравнения коммерческих предложений: сколько киловатт из оплаченной мощности в итоге действительно доберётся до серверов?</p> <h3>Максимальный КПД в каталоге может ничего не сказать о вашем объекте</h3> <p>Цифра «до 97,5%» выглядит убедительно, пока не уточнены условия измерения. Речь идёт об одном силовом модуле или обо всей системе? При какой загрузке получен результат? В штатной схеме N, при N+1 или в иной конфигурации? В онлайн-режиме или в режиме повышенной эффективности?</p> <p>Даже границы слова «система» могут отличаться. В расчёт иногда включают только ИБП, а иногда — ещё трансформаторы, распределение и собственное потребление вспомогательного оборудования. Поэтому сравнивать можно лишь значения, полученные при одинаковых границах измерения, нагрузке и режиме работы.</p> <p>Особенно осторожно следует относиться к экономичным режимам. В <a href="https://www.se.com/us/en/faqs/FAQ000244169/">классическом онлайн-режиме</a> энергия проходит через двойное преобразование, а инвертор постоянно формирует выходное напряжение. В <a href="https://www.se.com/us/en/faqs/FAQ000244169/">традиционном ECO-режиме</a> нагрузка обычно питается через статический байпас, пока параметры сети находятся в допустимом диапазоне. При отклонении система должна переключиться на инвертор.</p> <p>Поэтому вместе с КПД нужно проверять допустимый диапазон напряжения и частоты, время перехода, совместимость с нагрузкой и способность блоков питания пережить этот интервал. У разных архитектур высокоэффективного режима эти параметры отличаются; одного слова ECO в спецификации недостаточно.</p> <p>Для технического сравнения я бы запросила у поставщика четыре вещи:</p> <ol> <li> кривую КПД всей системы при 25, 50, 75 и 100% нагрузки;</li> <li> режим и конфигурацию резервирования, для которых получены значения;</li> <li> границы измерения и условия испытаний;</li> <li> параметры перехода и защиты в экономичном режиме.</li> </ol> <h3>Высокий КПД не компенсирует слабую архитектуру</h3> <p>Можно иметь резервный силовой модуль и всё равно сохранить единственную точку отказа. Вопрос не только в том, есть ли запасной модуль, а в том, насколько независимы ввод, статический байпас, управление, распределение и весь путь питания нагрузки.</p> <p>Для каждого отказа нужно проверить две вещи: сохранится ли питание критической нагрузки и как быстро система вернётся к исходному уровню резервирования.</p> <p>Параметры модуля также влияют на совокупную стоимость решения. Допустим, расчётная нагрузка составляет 480 кВт. При модулях по 60 кВт для штатной работы нужны восемь модулей, а девятый даёт схему N+1. При модулях по 50 кВт для покрытия нагрузки потребуются десять модулей: установленная мощность составит 500 кВт, но запас до номинала — только 20 кВт. Для N+1 нужен ещё один модуль.</p> <p>Это влияет на количество аппаратных единиц, размер шасси, шаг расширения, объём оплачиваемого резерва и требования к размещению. Но и здесь нет правила «чем мощнее модуль, тем лучше»: вместе с номиналом модуля растёт объём мощности, который система теряет при его отказе.</p> <h3>Один отказ способен обнулить экономию за несколько лет</h3> <p>Экономика ЦОДа не заканчивается после подсчёта дополнительных киловатт. Один серьёзный инцидент способен перекрыть эффект, который объект накапливал годами.</p> <p>По данным <a href="https://intelligence.uptimeinstitute.com/index.php/resource/annual-outage-analysis-2026">Uptime Institute</a>, 57% участников опроса 2025 года оценили стоимость своего последнего крупного сбоя более чем в 100 тыс. долл., а каждый пятый — более чем в 1 млн. долл. В том же исследовании проблемы электропитания названы ведущей причиной значимых отказов; среди основных источников указаны ИБП, автоматические переключатели и генераторы. Эти цифры нельзя напрямую переносить на российский объект, но они показывают порядок риска и объясняют, почему эффективность нельзя оценивать отдельно от устойчивости.</p> <p>Отказоустойчивость не заканчивается поставкой оборудования. Она зависит от архитектуры, мониторинга, доступности запасных частей и готовности людей действовать по заранее проверенному сценарию.</p> <h3>В 03:17 должен работать план, а не поиск контактов</h3> <p>В отчёте <a href="https://intelligence.uptimeinstitute.com/resource/annual-outage-analysis-2024">Uptime Institute за 2024 год</a> четыре из пяти респондентов, отвечавших о своём последнем серьёзном инциденте, считали, что его можно было предотвратить благодаря более качественному управлению, процессам или конфигурации.</p> <p>Даже идеально выбранный ИБП не поможет, если ночью дежурная смена впервые выясняет, кто имеет право на переключение, где находится запасной модуль и кому звонить после сигнала аварии.</p> <p>Рабочий план должен заранее отвечать как минимум на пять вопросов:</p> <ol> <li> Как система обнаружит развитие аварии до полного отказа?</li> <li> Что оператор делает немедленно, а какие действия требуют согласования?</li> <li> Кто доступен ночью и сколько времени займёт прибытие специалиста?</li> <li> Какие запасные модули и компоненты находятся на объекте или ближайшем складе?</li> <li> Как после ремонта проверить систему и восстановить исходное резервирование?</li> </ol> <p>Если ответы приходится искать уже во время аварии, простой начался задолго до первого сигнала тревоги.</p> <h3>Что проверить до закупки</h3> <p>Перед сравнением цен проектной команде стоит зафиксировать пять исходных условий.</p> <ol> <li><strong>Сколько мощности должна получить IT-нагрузка?</strong> Номинал ИБП ещё не показывает, сколько энергии дойдёт до серверов.</li> <li><strong>В каком диапазоне загрузки будет работать объект?</strong> Нужна кривая КПД, а не только максимальное значение.</li> <li> <strong>Какой отказ система должна пережить без остановки нагрузки?</strong> Резервирование модулей не устраняет общие точки отказа автоматически.</li> <li><strong>Что произойдёт при обслуживании?</strong> Следует заранее определить, сохранится ли резерв и допустим ли переход на байпас.</li> <li><strong>Как команда восстановит систему после отказа?</strong> Регламент, мониторинг, запасные части и порядок эскалации должны быть готовы до запуска.</li> </ol> <h3> Цена ИБП — только первая строка расчёта </h3> <p>Сравнивать системы бесперебойного питания только по CAPEX — всё равно что сравнивать автомобили по цене, не учитывая расход топлива, грузоподъёмность и вероятность простоя.</p> <p>Корректный вопрос звучит иначе: сколько полезной мощности останется у ЦОДа, какой отказ выдержит вся цепочка и как быстро команда восстановит резервирование?</p> <p>Именно эти ответы показывают реальную стоимость решения. Один процент КПД может оказаться незначительной строкой в спецификации — или превратиться в миллионы рублей. Разница возникает не в рекламном буклете, а в расчёте конкретного объекта.</p> <p>#IMAGE_235624#</p> Разница между двумя системами бесперебойного питания (ИБП) проявляется не только в счёте за электроэнергию. Она … article Юлия Камалдинова, руководитель проектов ГК “Темпесто” https://www.itweek.ru/themes/detail.php?ID=235622 Fri, 25 Sep 2026 09:58:00 +0300 <p><em>Анализ 623 млн. изменений кода, проведенный компанией GitClear, подтверждает реальность прироста производительности кодирования при использовании искусственного интеллекта, но также показывает, что он несопоставим с сопутствующими затратами на последующее сопровождение кода, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Стив Фентон, специалист по работе с сообществом Octopus Deploy.</em></p> <p>Значительная часть индустрии разработки ПО возлагает на ИИ-инструменты — от ранних чат-интерфейсов до современных систем, использующих рои автономных агентов — большие надежды с момента их появления. Однако в последние недели настроения изменились: например, поставщик HR-ПО Rippling добавил в свою систему панель мониторинга расходов на ИИ, позволяющую финансовым и техническим директорам контролировать затраты, а вице-председатель IBM Гэри Кон недавно заявил, что окупаемость инвестиций оказалась «далеко не такой высокой, как многие полагали». И пока в Северное полушарие приходит осенняя прохлада, для бюджетов на ИИ-инструменты, похоже, наступает зима.</p> <p>По мере того как организации будут приводить в порядок свои финансовые показатели, команды начнут ощущать давление в отношении бюджетов на использование таких инструментов, как Claude Code и Cursor. Это может обернуться либо ужесточением лимитов на использование там, где отдача неочевидна, либо нехваткой средств для поддержания текущих объемов работы.</p> <p>Организации, научившиеся измерять влияние ИИ, все чаще осознают: высокая скорость генерации кода не гарантирует улучшения ключевых показателей эффективности. Если оценивать продуктивность по количеству строк кода, числу запросов на изменения (pull requests) или даже по количеству реализованных функций, четкой связи с реальной ценностью продукта не прослеживается. Далеко не каждая строка кода или функция одинаково важны для бизнеса или клиентов; разброс в их значимости может быть колоссальным.</p> <p>Даже на уровне непосредственных результатов многие организации так и не поняли, как превратить локальные улучшения в комплексный рост эффективности всего процесса. Прирост скорости написания кода либо поглощается новыми задачами, порождаемыми самим же ИИ, либо нивелируется изменениями на последующих этапах разработки. Если вы не разобрались в особенностях потоков создания ценности до внедрения ИИ, попытки оценить окупаемость инвестиций могут стать для вас болезненным уроком.</p> <p>Если бы проблема сводилась лишь к сопоставлению затрат на ИИ-инструменты с конечной ценностью продукта, это уже было бы серьезно. Но происходит нечто гораздо более тревожное.</p> <h3>Продуктивность с точки зрения получаемых результатов</h3> <p>Давайте взглянем на данные, собранные и проанализированные GitClear для опубликованного в июне <a href="https://www.gitclear.com/the_ai_code_quality_maintainability_gap">отчета</a> «Maintainability Gap». В нем представлен анализ 623 млн. изменений, внесенных в период с 2023 по 2026 гг. По мере того как команды активно внедряют среды разработки с поддержкой ИИ и такие инструменты, как Cursor и Claude Code, база данных GitClear, отслеживающая операции с кодом, позволяет им выявлять и классифицировать дублирование кода, «горячие точки» (проблемные участки), а также признаки удачного или неудачного структурирования кода.</p> <p>Согласно отчету, активные пользователи ИИ увеличили собственную скорость работы на 25% по сравнению с предыдущими показателями — это далеко от заявлений о десятикратном росте. То же исследование показывает, что эти активные пользователи превосходят тех, кто не применяет ИИ, по объему выработки в <nobr>4-10 раз;</nobr> это может показаться противоречием, пока не вникнешь в суть того, кто именно эти люди. Команды, продемонстрировавшие более высокую продуктивность, показывали такие результаты еще до появления инструментов на базе ИИ. И не стоит забывать: нет никаких гарантий, что этот объем работы внесет реальный вклад в создание ценности для организации или ее клиентов.</p> <p>Первый этап расчета ROI — определение, оправдывают ли полученные результаты затраченные средства. Сильно удивлюсь, если для многих организаций ответ окажется утвердительным.</p> <p>Возможно, из-за того, что в дискуссиях об ИИ-инструментах упор делался преимущественно на скорость, другие факторы остались без должного внимания. Индустрия разработки ПО могла бы извлечь иную выгоду, если бы рассматривала эти инструменты не как гоночный болид, а как вилочный погрузчик: ведь скорость движения по прямой здесь не так уж впечатляет. Зато они способны выполнять тяжелую работу, сложную для нас, простых людей, — например, масштабные изменения в кодовой базе, такие как замена устаревшей, неподдерживаемой библиотеки на актуальный аналог.</p> <p>Для тех, кто успешно прошел этот первый этап, можно рассмотреть следующий фактор.</p> <h3>Продуктивность с точки зрения качества кода</h3> <p>Переход к использованию ИИ привел к кардинальным изменениям в поведении специалистов индустрии разработки ПО. На протяжении десятилетий постоянно подчеркивалась важность удобства сопровождения кода. Более половины книг по программированию на моей полке посвящены архитектуре, проектированию кода, связности компонентов и чистоте кода. Во многих из этих изданий затрагивается тема рефакторинга, подкрепленного автоматизированными тестами.</p> <p>Однако данные, полученные GitClear, свидетельствуют о совершенно иной тенденции: возврате к эпохе разработки по принципу «пиши и исправляй» («code-and-fix»). Согласно исследованию, за период с 2023 г. частота дублирования блоков кода выросла на 81% — с 40,3 до 73,0 случаев на миллион измененных строк. Множественные реализации одной и той же идеи начинают расходиться, порождая трудноуловимые ошибки, которые возникают вновь и вновь (подобно игре «Ударь крота»). Доля перемещенного кода — характерного признака рефакторинга — снизилась с 21% от общего объема измененных строк в 2022 г. до 3,8% в <nobr>2026-м;</nobr> это означает, что код становится сложнее для понимания, и с этой проблемой неизбежно столкнутся специалисты по сопровождению — независимо от того, используется ли ИИ.</p> <p>Внося подобные изменения, поначалу вы не ощущаете негативных последствий, так как находитесь на раннем этапе кривой затрат на сопровождение. Однако со временем растущие расходы станут непосильными. Увеличится доля задач по переделке кода, отнимающих время у разработки новых функций. На выявление и устранение даже незначительных проблем будет уходить слишком много времени, а многие из них просто станут частью системы, поскольку их исправление окажется экономически невыгодным. Накопление тесно связанных и запутанных фрагментов кода приведет к тому, что ПО утратит свою ценность.</p> <p>Мы пытались подтвердить заявления о десятикратном росте продуктивности благодаря ИИ-помощникам по кодированию. Данные свидетельствуют об обратном. До появления ИИ разработчики предпочитали рефакторинг копированию (copy-and-paste) кода в соотношении примерно два к одному. Теперь же они прибегают к копипасту кода примерно в пять раз чаще.</p> <h3>Технические практики — основная задача, а не второстепенное дело</h3> <p>Выступая на конференциях и встречах профессиональных сообществ с рассказами о том, как должен выглядеть качественный выпуск ПО, я упоминаю, в частности, автоматизацию тестирования и рефакторинг. В ходе последующей сессии вопросов и ответов неизбежно звучит вопрос: «Как получить разрешение руководства на внедрение этих практик?».</p> <p>Разработчиков жестко подгоняют, требуя быстрых результатов, поэтому они приучаются избегать всего, что кажется им второстепенным. Стремясь повысить производительность, они упрощают процесс написания кода, не оставляя времени на тесты или улучшение архитектуры, так как это замедлило бы выпуск новой функции. В конечном счете это приводит к значительному замедлению разработки любого функционала в долгосрочной перспективе.</p> <p>Преимущество облегченных процессов выпуска ПО заключается в опоре на технические практики, позволяющие контролировать затраты на сопровождение системы с течением времени. Идея состоит в том, что более взвешенный подход к работе сегодня позволит сохранять высокий темп внесения изменений в будущем. Если же пренебрегать этими практиками, любые изменения будут даваться все труднее и обходиться все дороже.</p> <p>Такие технические практики, как автоматизация тестирования и рефакторинг, — это не «побочные квесты», а сама суть работы. Техническая дисциплина — фундаментальное требование при выпуске коммерческого ПО, и эти практики уже давно перестали быть необязательными.</p> <p>Меня ставят в тупик просьбы подсказать способы убедить руководство разрешить применение этих практик. Я никогда не спрашивал разрешения делать то, что правильно для меня, для программного продукта, его пользователей и организации. Здесь не может быть компромиссов, поскольку отказ от технических практик вредит всем участникам процесса.</p> <p>Во многих организациях так и не удалось преодолеть отношение к этим мерам как к «побочным квестам», а внедрение ИИ лишь усугубило ситуацию. Когда команды получают инструменты на базе ИИ, от них ожидают высокой отдачи. Однако на деле они наблюдают лишь 25%-ный рост скорости внесения изменений, в то время как в отрасли бытует ошибочное мнение о десятикратном ускорении; в результате давление с требованием результатов только возрастает.</p> <p>В таких нездоровых условиях неудивительно, что те, кто считает качественные практики чем-то второстепенным, пропускают критически важные этапы работы.</p> <h3>Признаки высокой эффективности хорошо известны</h3> <p>Высокоэффективные команды осознали, что набор практик по выпуску ПО — это обязательное условие, а не опция по выбору. Они пришли к этому выводу, поскольку занимались масштабированием задолго до появления новых инструментов.</p> <p>Когда речь идет о важном ПО — продуктах, от которых зависят люди и которые должны оставаться актуальными через год, пять лет и дольше, — мы уходим от прежнего подхода «выбирай что хочешь». Теперь к профессиональной разработке и выпуску ПО предъявляются новые, более высокие требования.</p> <p>И все же есть проблеск надежды. Команды, успешно использующие ИИ, — это те же самые коллективы, которые опережали конкурентов еще до появления этой технологии. Они придерживаются строгой технической дисциплины, отслеживают показатели качества кода и уделяют первостепенное внимание мастерству создания кода, пригодного для долгосрочного сопровождения.</p> Анализ 623 млн. изменений кода, проведенный компанией GitClear, подтверждает реальность прироста производительности … article https://www.itweek.ru/themes/detail.php?ID=235620 Thu, 24 Sep 2026 15:05:11 +0300 <p>Разработчик экосистемы инфраструктурного ПО Orion soft представил zVirt Containers 2.0 — обновленную версию модуля платформы виртуализации zVirt для интеграции с Kubernetes-решением Nova Container Platform.</p> <p>По данным Strategy Partners, объем российского рынка решений для контейнеризации по итогам 2025 года достиг 5,4 млрд рублей, увеличившись на 26% год к году. Все больше корпоративных приложений используют микросервисную архитектуру, однако виртуальные машины продолжают составлять основу ИТ-инфраструктуры крупных компаний. В результате растет запрос бизнеса на управляемый способ добавить Kubernetes в инфраструктуру.</p> <p>zVirt Containers позволяет внедрить Kubernetes в существующую инфраструктуру виртуализации и связать работу администраторов zVirt и DevOps-команд в единый процесс. Интеграция контейнеров и виртуализации, сбор данных и компонентов — происходят автоматически. С модулем переход к Kubernetes реализуется за 1 час, а бизнес при этом экономит до 60 млн рублей в год на эксплуатации решения.</p> <p>В обновленном решении вендор также реализовал интеграцию с инфраструктурными компонентами Nova: Cluster Manager и Universe. Благодаря этому администраторы Kubernetes могут разворачивать, масштабировать и обновлять Kubernetes-кластеры, не привлекая специалистов по виртуализации. Шаблоны, сети и другие компоненты для создания кластеров из виртуализации zVirt можно выбирать в интерфейсе Cluster Manager. При этом серверы управления доступны для взаимодействия через zVirt. Для улучшения пользовательского опыта вендор также обновил интерфейсы — все это создает единый удобный слой управления инфраструктурой.</p> <p>zVirt Containers 2.0 — основа бесшовной интеграции основных продуктов экосистемы Orion soft. Вендор разработал и использовал в решении универсальный API, с помощью которого в дальнейшем планируется связывать продукты экосистемы: GitOps-платформу Hyperdrive, CMP-решение CloudLink, а также сторонние системы.</p> <p>«Для заказчиков, которые уже используют zVirt, Kubernetes становится логичным расширением существующей инфраструктуры. zVirt Containers 2.0 превращает zVirt из основы для виртуализации в платформу для разных типов приложений. Бизнес может сохранить существующие виртуальные машины, добавить Kubernetes для контейнерных нагрузок и при необходимости расширить свою инфраструктуру под ИИ. Для нас это важный шаг к единой экосистеме инфраструктурных продуктов Orion soft», — поделился Владимир Болвачев, лидер продукта Nova Container Platform в Orion soft.</p> Разработчик экосистемы инфраструктурного ПО Orion soft представил zVirt Containers 2.0 — обновленную версию модуля … message https://www.itweek.ru/themes/detail.php?ID=235619 Thu, 24 Sep 2026 15:03:35 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил распространение и использование технологий искусственного интеллекта в организациях, за исключением субъектов малого предпринимательства. Анализ основан на данных сплошных обследований крупных и средних организаций, проведенных Росстатом в <nobr>2025–2026 гг.</nobr></p> <p>В 2025 г. в крупных и средних организациях выросла востребованность технологий ИИ. Об этом свидетельствуют увеличение числа организаций, сообщивших об их применении, и рост затрат на внедрение таких технологий. В среднем технологии ИИ используют порядка 5,2% крупных и средних организаций, что на 0,4 п. п. больше, чем в 2024 г.</p> <p>Уровень распространения ИИ существенно зависит от размера организации. Так, в компаниях с численностью работников более 500 человек доля пользователей ИИ достигает 17%, в то время как в организациях, в которых заняты менее 100 человек (это самая многочисленная группа), — 4,3%.</p> <p>Наиболее востребованы среди ИИ-технологий решения для обработки визуальных данных и текста: к ним обращаются около двух третей организаций, применяющих ИИ, причем спрос на технологии обработки текста вырос по сравнению с 2024 г. почти вдвое. Наименее распространены технологии повышения эффективности ИИ.</p> <p>Организации применяют ИИ во всех основных бизнес-процессах: примерно каждая вторая — в маркетинге и продажах, управлении персоналом и производстве продукции, каждая четвертая — в управлении организацией.</p> <p>Чаще всего компании внедряют готовое коммерческое ПО (этот вариант выбрали 56% пользователей ИИ) или модифицированное сторонними организациями (51,8%). Собственными силами ПО разрабатывают или дорабатывают лишь <nobr>10–15%</nobr> организаций. За год существенно выросла доля компаний, использующих бесплатные ИИ-решения.</p> <p>Среди главных эффектов внедрения ИИ почти две трети (62,7%) организаций выделили повышение качества и эффективности бизнес-процессов. Свыше половины (51,1%) отметили улучшение качества и эффективности производственных процессов, 41,4% — рост доходов (в том числе за счет совершенствования продукции и услуг, более эффективного маркетинга и расширения клиентской базы), каждая четвертая (24,1%) — рост производительности труда. О снижении численности работников в результате внедрения ИИ сообщили 9,1% организаций-пользователей ИИ.</p> <p>Дальнейшему распространению технологий ИИ будет способствовать преодоление таких сдерживающих факторов, как высокие затраты (отметили 54% респондентов), недостаточность и невысокое качество массивов данных (34%), необходимость привлечения квалифицированных кадров (33%) и развитие ИКТ-инфраструктуры организации (32%). </p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил распространение и использование … message https://www.itweek.ru/themes/detail.php?ID=235618 Thu, 24 Sep 2026 15:00:37 +0300 <p>«МойОфис», российская продуктовая ИТ-компания, представила релиз 26.3 для нескольких ключевых продуктов компании. В новой версии решений «Документы Настольные», «МойОфис для дома» и «МойОфис Образование» редакторам стала доступна технология автоматического подбора и замены отсутствующих шрифтов «на лету» без искажения структуры документов на любых операционных системах. Также обновление существенно расширяет математический аппарат табличного редактора функциями прогнозирования и содержит дополнения для более комфортной работы с текстом и таблицами.</p> <p>Главным технологическим новшеством релиза стала встроенная система автоматической замены отсутствующих шрифтов «на лету» при открытии текстовых файлов, таблиц и презентаций. Редакторы «Мой Текст», «Моя Таблица» и «Моя Презентация» теперь корректно отображают документы, созданные в сторонних офисных программах, даже при отсутствии оригинальных гарнитур в операционной системе пользователя. Данное решение предотвращает искажение разметки и доступно на всех поддерживаемых платформах.</p> <p>Для дополнительного удобства пользователей реализовано сохранение масштаба документов при повторном открытии файлов в редакторах «Мой Текст» и «Моя Таблица». Также в редакторах появилась возможность поиска и замены непечатаемых символов, а для операционных систем macOS и Linux стала доступна темная тема оформления интерфейса. Дополнительно в текстовом редакторе была усовершенствована проверка орфографии, позволяя задавать конкретный язык проверки для выделенного фрагмента или всего текста целиком. В целях улучшения навигации в редакторы МойОфис добавлена функция быстрого доступа к каталогу рабочих документов, отображающая открытые файлы и пути к ним непосредственно в главном меню с возможностью быстрой очистки списка просмотра.</p> <p>В редакторе «Моя Таблица» реализована поддержка функций прогнозирования TREND (ТЕНДЕНЦИЯ) для вычисления линейных значений на базе накопленной информации, а также формул FORECAST.LINEAR (ПРЕДСКАЗ.ЛИНЕЙН) и FORECAST (ПРЕДСКАЗ) — это гарантирует совместимость с расчетными моделями из сторонних приложений. На боковую панель инструментов добавлены новые математические и тригонометрические функции, включая формулы ВРЕМЯ, ОСТАТ, ОТБР, ОКРВВЕРХ и COS. Для комфортной работы с примечаниями пользователи теперь могут управлять видимостью заметок — скрывать или показывать как отдельные комментарии, так и все заметки в документе одновременно. Также можно скрывать или отображать сетку рабочей области таблицы, а новое сочетание клавиш Ctrl+Shift со стрелками направления упрощает выделение заполненных диапазонов данных от курсора до первой или последней записи строки или столбца.</p> <p>Значительно улучшен интерфейс прикладного программирования Document API для платформ Python, C++, C# и макрокоманд LUA. Разработчики получили возможность программно переносить форматирование или чистые значения между ячейками таблиц, вставлять разрывы страниц с помощью макрокоманд, а также динамически запрашивать индекс активного листа и общее число вкладок в документе.</p> <p>В релизе 26.3 для редакторов «МойОфис для дома» и «МойОфис Образование» теперь также стали доступны новые функциональные возможности: просмотр детальной статистики документа в редакторе «Мой Текст»; темная тема для пользователей ОС macOS и Linux; работа с условным форматированием таблиц на панели редактора и операции над группой листов; поддержка работы с файловой системой в VBA; улучшенная проверка орфографии для выделенного фрагмента текста или всего документа при установке языков проверки; поддержка файлов формата HTML.</p> «МойОфис», российская продуктовая ИТ-компания, представила релиз 26.3 для нескольких ключевых продуктов компании. В новой … message https://www.itweek.ru/themes/detail.php?ID=235617 Thu, 24 Sep 2026 14:59:29 +0300 <p>В гонке кибервооружений на базе ИИ тактическое преимущество пока удерживает ИИ-защищающийся. При этом интеграция ИИ в системы защиты уже стала условием выживания. К таким выводам пришли специалисты экспертно-аналитического центра (ЭАЦ) ГК InfoWatch в исследовании «Искусственный интеллект в сетевой кибербезопасности». Отчет подготовлен по результатам изучения мировых тенденций влияния ИИ на безопасность сетевой инфраструктуры.</p> <p>Эксперты ЭАЦ ГК InfoWatch отмечают, что в настоящее время преимущество находится на стороне киберзащиты с применением ИИ. Однако использование ИИ в кибератаках сокращает разрыв за счет децентрализации и генеративных технологий. Так, уже примерно каждый шестой инцидент и успешный взлом сетей в мире (16%) осуществляется с применением ИИ-инструментов. Что касается фишинговых атак, то использование ИИ в них фиксируется почти повсеместно (86%).</p> <p>«Гонка кибервооружений на базе ИИ — это цифровая война на истощение. Пока что тактическое преимущество удерживает ИИ-защищающийся. У него есть три преимущества: полный, легитимный и непрерывный доступ к терабайтам „чистых“ внутренних данных для защиты, аппаратное превосходство благодаря ASIC и локальным ЦОД, а также технология киберобмана. Так, защитный ИИ контролирует сетевой ландшафт и может за миллисекунды перестроить топологию или подсунуть атакующему ИИ тысячи ловушек. Но атакующие быстро учатся — они используют коммерческие модели и модели на open source, взламывают их ограничения, а это делает ИИ-атаки дешевыми и массовыми. Эффективно противостоять ИИ-атаке можно только с помощью ИИ-защиты», — отметил главный аналитик ЭАЦ InfoWatch Сергей Слепцов.</p> <p>Аналитики ЭАЦ отмечают взрывной рост активности автономных ИИ-агентов, которые сканируют сети в поисках уязвимостей. Объем трафика, генерируемого вредоносными ИИ-ботами и агентами-разведчиками, за год вырос на 187%, а трафик от автономных ИИ-агентов («агентских браузеров») — почти в 80 раз. ИИ позволяет злоумышленникам находить уязвимости нулевого дня на 70% эффективнее. Кроме того, атакующий ИИ научился маскировать свой трафик под легитимный и мимикрировать под обычную активность пользователя. Это существенно затрудняет обнаружение вторжений.</p> <p>При этом ИИ-защита демонстрирует не менее впечатляющие результаты. ИИ-расширения систем обнаружения угроз (NDR/XDR) выявляют аномалии и продвинутые постоянные угрозы (APT-атаки) вдвое быстрее обычных систем — вместо нескольких дней на реакцию уходят минуты. ИИ-фильтрация на почтовых шлюзах блокирует до 94% фишинговых писем. ИИ-системы, которые анализируют поведение пользователей в ИТ-инфраструктуре, снижают риски внутренних угроз и кражи учетных данных на 45%. Благодаря ИИ-ассистентам, которые берут на себя часть рутины, нагрузка на аналитиков центров мониторинга по первичной сортировке и разбору сетевых предупреждений снижается на 60%.</p> <p> «Ключевым полем битвы в ближайшие годы станет устойчивость самих ИИ-моделей к отравлению данных и уклонение от атак. А на объектах, которые до сих пор полагаются на классические сигнатурные антивирусы, ИИ-атакующий пройдет незамеченным и победит в 100% случаев. Интеграция ИИ во все уровни мониторинга — от межсетевых экранов нового поколения (NGFW) до систем обнаружения аномалий в промышленных сетях — становится не конкурентным преимуществом, а условием выживания», — резюмировал Сергей Слепцов.</p> В гонке кибервооружений на базе ИИ тактическое преимущество пока удерживает ИИ-защищающийся. При этом … message https://www.itweek.ru/themes/detail.php?ID=235616 Thu, 24 Sep 2026 14:58:09 +0300 <p>На платформе SourceCraft появилась возможность подключать и настраивать автономных ИИ-агентов — например, для разработки и проверки безопасности кода, или создавать агентов с собственными специализациями под ключ. Разработчик поручает агенту работу прямо в обсуждении задачи в GitLab, где команда ведёт разработку. Также обратиться к агенту можно через мессенджеры, веб-интерфейс SourceCraft, редактор кода VSCode и командную строку.</p> <p>Агент работает под собственной учётной записью как самостоятельный участник команды, выполняет поручение и передаёт результат на проверку. Если ему не хватает данных или требуется согласование, он сам обращается к команде. Например, разработчик замечает ошибку в работе сервиса, создаёт задачу на её исправление и назначает ИИ-разработчика исполнителем. Агент сам готовит рабочее окружение, исправляет код, запускает тесты и отправляет изменения на проверку. Ссылка на исправление появляется в исходной задаче. Разработчик может принять результат или оставить замечания, тогда агент доработает код.</p> <p>Совместная работа разработчиков и ИИ-агентов помогает быстрее проверять продуктовые гипотезы, запускать новые сервисы и развивать существующие. По данным McKinsey, компании, которые встроили автономных ИИ-агентов в процесс разработки, более чем вдвое чаще добивались роста производительности свыше 20% по сравнению с теми, кто просто добавил ИИ-инструменты в существующие процессы. В среднем автономные агенты сокращают время на задачи разработки на 11,2%, а объём повторной работы — на 6,8%.</p> <p>«По мере развития ИИ меняется и масштаб автоматизации в разработке: от отдельных действий идёт переход к целым потокам постоянно возникающих задач. Одних только возможностей модели для этого недостаточно — нужна инфраструктура, которая позволяет бесшовно масштабировать существующие процессы разработки с помощью ИИ, а не перестраивать их заново под каждого нового агента. Именно в этом направлении мы развиваем SourceCraft», — рассказал Иван Пузыревский, технический директор Yandex Cloud.</p> <p>Яндекс, включая команду SourceCraft, уже применяет такой подход: 73% разработчиков компании регулярно используют ИИ, а более половины нового кода создаётся с помощью генеративных моделей. В рамках программы75/75/75 к концу года ИИ должны регулярно использовать не менее 75% разработчиков; он должен участвовать как минимум в 75% изменений и генерировать не менее 75% кода в каждом из них. </p> <p>В дальнейшем Yandex B2B Tech планирует объединить управление своими ИИ-ресурсами. Для этого она запустит единую подписку, которая позволит работать с SourceCraft, Алисой AI Про для бизнеса и другими ИИ-сервисами, а также использовать модели Yandex AI Studio. Это позволит компаниям централизованно распределять ИИ-ресурсы между разработчиками, агентами и работающими продуктами — и видеть полную стоимость использования ИИ, а не только затраты на разработку.</p> На платформе SourceCraft появилась возможность подключать и настраивать автономных ИИ-агентов — например, для … message https://www.itweek.ru/themes/detail.php?ID=235615 Thu, 24 Sep 2026 14:57:10 +0300 <p>Yandex B2B Tech анонсировала DataLens Platform — платформу, которая объединяет все этапы работы с данными: от загрузки и хранения до визуализации и ИИ-аналитики. DataLens Platform позволяет работать с данными компании в одном месте, быстро находить их источники и получать инсайты с помощью ИИ-агента. Сервис сокращает совокупные затраты на аналитику до 30%, а подготовку отчётов и дашбордов ускоряет в <nobr>3–5 раз.</nobr> Общедоступный релиз запланирован на начало 2027 года, сейчас можно оставить заявку на ранний доступ.</p> <p>70% аналитических команд используют от 5 до 10 инструментов для работы с данными: одни — для загрузки и хранения, другие — для обработки аналитики. ИТ-специалистам приходится вручную переносить данные между системами, настраивать интеграции и разбираться в каждом источнике информации: сопоставлять поля и идентификаторы, согласовать расхождения в данных и решать другие проблемы совместимости.</p> <p>В DataLens Platform компаниям больше не придётся собирать аналитику из десятка разрозненных инструментов и настраивать обмен данными между ними. На платформе уже объединены хранилище данных, инструменты для обработки информации и создания отчётов, а также ИИ-помощник, которому можно задавать вопросы на обычном языке. Пользователь сможет работать с данными и получать готовые показатели в единой системе — без огромного количества прослоек из межсистемных интеграций. </p> <p>«Уникальность DataLens Platform в том, что разные инструменты для работы с данными объединены в одной системе. Это сильно упрощает инфраструктуру: чем больше отдельных систем использует компания, тем больше интеграций между ними приходится поддерживать. Для пяти систем их может быть до 10, а для десяти — уже до 45. При этом хранение данных и вычислительные мощности в DataLens Platform масштабируются независимо: если растёт объём данных, можно расширить хранилище, а если нагрузка на расчёты и отчёты — добавить вычислительные мощности», — рассказал Иван Пузыревский, технический директор Yandex Cloud.</p> <p>Например, торговая сеть с помощью DataLens Platform сможет объединить данные о продажах, остатках и программе лояльности и спросить ИИ-помощника, какие популярные у постоянных покупателей товары заканчиваются в конкретных магазинах. Производственная компания — сопоставить выпуск продукции, простои оборудования и показатели качества, чтобы увидеть, на какой линии и в какой смене выросла доля брака. </p> <p>Сначала DataLens Platform будет доступна в Yandex Cloud. Позднее Yandex B2B Tech планирует выпустить версии продукта для размещения в собственной инфраструктуре компании и для гибридного сценария. </p> Yandex B2B Tech анонсировала DataLens Platform — платформу, которая объединяет все этапы работы с данными … message https://www.itweek.ru/themes/detail.php?ID=235614 Thu, 24 Sep 2026 14:55:53 +0300 <p>Yandex B2B Tech запускает новое ИБ-направление — Yandex Security. Компания сосредоточится не только на защите облачной инфраструктуры клиентов, но и будет развивать решения для гибридной, локальной и мультиоблачной безопасности. Также Yandex B2B Tech усилила свой продуктовый портфель новыми продуктами, среди них инструменты для беспарольной авторизации и поиска избыточных прав доступа в системе.</p> <p>Сервисы Yandex Security позволяют защищать инфраструктуру, размещённую у разных облачных провайдеров. Клиентам доступен мониторинг безопасности мультиоблачной архитектуры в едином интерфейсе. В нём автоматически собираются все данные о защите инфраструктуры: мониторинг доступов к системе, анализ рисков и ошибок в конфигурации и многое другое. Всё это позволяет устранить «слепые зоны» и видеть полную картину безопасности в едином интерфейсе независимо от того, в каком облаке размещены ресурсы. Интеграция с Security Deck занимает несколько минут. До конца года у компании появится несколько ведущих облачных провайдеров-партнеров. </p> <p>«Yandex Security предоставит бизнесу принципиально новый подход к информационной безопасности в эпоху ИИ. Наши технологии позволяют значительно повысить скорость внедрения ИБ-инструментов и при этом построены на экспертизе в защите больших и распределённых инфраструктур уровня Яндекса. Мы объединили наши ИБ‑решения, включая разработки с SolidLab, чтобы обеспечить защиту любых инфраструктур — от гибридных до мультиоблачных — с бесшовным внедрением и централизованной безопасностью», — прокомментировал директор по информационной безопасности Yandex Сloud Евгений Сидоров.</p> <p>Yandex Security запустит в сервисе Identity Hub беспарольную авторизацию для организаций на базе технологий WebAuthn/FIDO2. Теперь сотрудники компании смогут подтвердить вход в корпоративные системы по лицу, отпечатку пальца или с помощью аппаратного ключа. Администратор сможет гибко управлять доступом к беспарольной авторизации: от многофакторной аутентификации до полного запрета паролей. Это снижает риск компрометации учётных данных: пользователям не придётся вводить пароли, которые можно подобрать или похитить с помощью фишинга.</p> <p>В сервисе Yandex Smart Web Security появился новый тип проверки посетителей сайта от ботов — JS-Challenge. В отличие от привычной капчи, отсеивание вредоносного трафика происходит в фоновом режиме. Ключевая особенность — адаптивная защита: система динамически оценивает уровень риска каждого запроса. При стандартной активности пользователя проверка проходит незаметно, а капча показывается только при наиболее подозрительных запросах — это снижает нагрузку на посетителей и одновременно повышает эффективность фильтрации ботов.</p> <p>В составе Yandex Security Deck появился отдельный модуль Access Analyzer для контроля доступов в системе. В соответствии с принципом минимальных полномочий модуль может отслеживать использование ролей и предлагать их замену на более гранулярные, а также найти избыточные доступы и удалить неиспользуемые сервисные аккаунты.</p> Yandex B2B Tech запускает новое ИБ-направление — Yandex Security. Компания сосредоточится не только на защите … message https://www.itweek.ru/themes/detail.php?ID=235613 Thu, 24 Sep 2026 14:54:27 +0300 <p>Yandex B2B Tech представила Алису AI Про для бизнеса. Это расширенная версия корпоративного ИИ-ассистента Яндекса — она подойдёт банкам, ритейлерам, промышленным корпорациям и другим компаниям с особыми требованиями к хранению и обработке данных. Её можно развернуть на собственной инфраструктуре и гибко настроить под свои задачи — к примеру, самостоятельно выбрать модель «под капотом» или создать узкоспециализированные навыки. Новая версия уже доступна по подписке всем клиентам Yandex Cloud.</p> <p>Алиса AI Про — это универсальный ИИ-агент, способный решать сложные многосоставные задачи. Её можно использовать практически в любом отделе, от дизайна и маркетинга до бухгалтерии, HR и юридического департамента. Достаточно сформулировать поручение простым языком, и помощник выполнит его, используя те же приложения, которыми обычно пользуется сам сотрудник — например, CRM-системы или сервисы для работы с документами и бухучёта. Для решения задач Алиса AI Про сама создаёт себе команду специализированных ИИ-агентов. Пока они собирают информацию и работают с документами и корпоративными системами, ИИ-помощник координирует их работу, проверяет и объединяет результаты.</p> <p>«Сотрудники компаний каждый день используют огромное количество сервисов и приложений. С запуском Алисы AI Про у них появляется единый ИИ-интерфейс для решения большинства задач. Помощник сам поставит задачу в Трекере, отправит письмо по почте или соберёт встречу команды — достаточно предоставить ему доступ к нужным приложениям. Подобные универсальные ИИ-агенты — новый этап проникновения ИИ в бизнес», — отметил руководитель Yandex AI Studio Артур Самигуллин.</p> <p>Алиса AI Про уже предлагает более 120 навыков — готовых инструкций по решению рабочих задач — для сотрудников с разными профессиями: дизайнеров, аналитиков, юристов, финансистов, специалистов по закупкам и многих других. Можно не только использовать готовые навыки, но и создавать собственные. Умение писать код для этого не требуется.</p> <p>Для подключения к внешним приложениям и сервисам используются плагины — их уже более 20. Например, плагин Phygital+ поможет сгенерировать изображения и видео для маркетинговых материалов, а AvangardAI превратит помощника в тренажёр для специалиста по продажам. Число плагинов будет расти — их могут создавать как крупные и хорошо известные сервисы, так и стартапы. У компаний, которые работают с Алисой AI Про, также есть возможность подключить внешние или внутренние сервисы по MCP-протоколу.</p> <p>Нового ИИ-помощника уже тестируют крупные компании, например «Норникель». Его специалисты помогали сформировать сценарии использования Алисы AI Про в промышленности — от нормоконтроля документов до классификации затрат и интеллектуального поиска по внутренним нормативным документам. Эти сценарии будут востребованы и у других компаний.</p> <p>С запуском Алисы AI Про компании смогут выбирать между двумя версиями ассистента. Алиса AI для бизнеса, которую Яндекс представил в начале сентября, пригодится тем, кому нужно готовое решение. Алиса AI Про также подойдет тем, у кого есть потребность гибко настроить агента под себя.</p> Yandex B2B Tech представила Алису AI Про для бизнеса. Это расширенная версия корпоративного ИИ-ассистента Яндекса — она … message https://www.itweek.ru/themes/detail.php?ID=235612 Thu, 24 Sep 2026 14:48:42 +0300 <p><nobr>7–8</nobr> октября на крупнейшем мероприятии для профессионалов розничной торговли эксперты BSS продемонстрируют, как ИИ помогает создавать более персонализированный клиентский опыт и предотвращать проблемы покупателей.</p> <p><nobr>7–8</nobr> октября на Коннектед Ритейл Форуме около 2 000 представителей ритейла, e-commerce и FMCG-брендов обсудят, какие бизнес-модели позволяют выделиться в 2026 и за счет чего привлекать и удерживать покупателей. </p> <p>Эксперты BSS покажут, какие конкурентные преимущества можно получить при помощи ИИ на секции «ИИ (AI) студия: ИИ „под капотом“ клиентских процессов» 8 октября в 15:00. </p> <p>Заместитель генерального директора BSS Василий Жилов выступит со-модератором секции и вместе с участниками обсудит, как внедрять ИИ так, чтобы технологии работали на бизнес и клиента, а не заставляли человека подстраиваться под логику алгоритмов. </p> <p>В центре дискуссии — практические кейсы использования ИИ в ритейле: навигация и персонализированные предложения, ИИ-амбассадоры и ИИ-аналитика. Эксперты разберут, как ИИ-инструменты уже помогают повышать конверсию и удерживать покупателей, и какие возможности могут открыть дальше. </p> <p>Руководитель направления по развитию голосовых цифровых технологий BSS Валерия Учайкина расскажет, как с помощью ИИ находить скрытые сигналы в обращениях клиентов и превращать их в конкретные действия, и в конечном счете — в выручку. </p> <p>Речь пойдет о <nobr>CX-платформе,</nobr> которая собирает разрозненные данные о клиенте и связывает их с действиями на всем клиентском пути. Например, платформа фиксирует, что постоянный клиент реже совершает покупки. Недавно он несколько раз заходил на страницу привычного товара, но не оформлял заказ, при этом в чате сравнивал цену с другими магазинами. Сигналы складываются в единую картину, и система сигнализирует о риске оттока. А затем рекомендует действие — например, предложить персональную скидку или бонусы на следующую покупку.</p> <p>Актуальная информация о секции «ИИ (AI) студия: ИИ „под капотом“ клиентских процессов» — в программе.</p> <p>Эксперты BSS будут ждать гостей и на собственном стенде — здесь можно будет вживую посмотреть, как работает <nobr>CX-платформа</nobr> и ее отдельные компоненты: речевая аналитика, виртуальные помощники, ИИ-портал и другие инструменты. </p> 7–8 октября на крупнейшем мероприятии для профессионалов розничной торговли эксперты BSS продемонстрируют, как ИИ … message https://www.itweek.ru/themes/detail.php?ID=235610 Thu, 24 Sep 2026 11:21:18 +0300 <p>Open source, или компоненты с открытым исходным кодом сегодня лежат в основе значительной части корпоративного ПО и государственных ИС. По некоторым <a href="https://www.forbes.ru/tekhnologii/555582-politika-otkrytyh-dverej-kakie-ugrozy-tait-v-sebe-primenenie-opensource-koda">оценкам</a>, около 90% российских компаний используют открытый исходный код в своей ИТ-инфраструктуре. Готовые библиотеки и фреймворки позволяют не разрабатывать базовый функционал с нуля, а строить приложения их готовых строительных блоков, что позволяет существенно сокращать сроки и стоимость создания продуктов. Однако вместе с преимуществами бизнес получает новую зону риска: приложения начинают зависеть от компонентов, разработчиков, репозиториев и инструментов, которые не контролируются напрямую. Это связано с тем, что нет возможности проконтролировать весь процесс сборки от исходного кода библиотек и до конечного артефакта. Чаще всего разработчики скачивают готовые компоненты — артефакты в уже скомпилированном виде, как правило, из зарубежных источников. Чем больше таких элементов в ПО, тем выше риск атак: злоумышленники могут попытаться использовать любой из элементов цепочки и скомпрометировать его, используя уязвимости или «закладки», что позволит использовать эту ситуацию как точку входа в корпоративную инфраструктуру с целью остановки ключевых процессов, повреждения или кражи данных.</p> <h3>Что скрывается за цепочкой поставки ПО</h3> <p>Цепочка поставки ПО давно вышла за пределы исходного кода конкретной библиотеки. В нее входят публичные репозитории, пакетные менеджеры, транзитивные зависимости, SDK и плагины, CI/CD-компоненты, контейнерные образы и механизмы доставки обновлений. С каждым годом число атак на цепочки поставок растет, по <a href="https://www.kaspersky.ru/about/press-releases/cepnaya-reakciya-samoj-chastoj-kiberugrozoj-dlya-kompanij-v-2025-godu-stali-ataki-cherez-komprometaciyu-vendorov-po">данным</a> «Лаборатории Касперского», в 2025 году с такими атаками столкнулись 31% компаний в мире и 35% в России. А по <a href="https://www.anti-malware.ru/news/2025-12-29-114534/48600">данным</a> компании CodeScoring, за 2025 год количество вредоносных компонентов выросло на 1000%. Такой тренд имеет экспоненциальную динамику, по отношению к трем годам ранее, где рост составил около 700%. Атакующему не обязательно искать уязвимость непосредственно в инфраструктуре компании. Иногда достаточно скомпрометировать один из компонентов, которому она доверяет. Все чаще целью становятся разработчики, репозитории и системы сборки, ведь через них можно незаметно внедрить вредоносный код в легитимное ПО.</p> <p>Компоненты с открытым исходным кодом — это не только исходный код, который разработчик может изучить и изменить. Часто компания использует уже готовые артефакты, опубликованные в публичных репозиториях, которые, как правило, находятся на ресурсах за пределами РФ. В этом случае разработчик не контролирует весь процесс их формирования и не может самостоятельно гарантировать полное соответствие конечного артефакта исходному коду. В артефакт могли быть внесены вредоносные изменения — как на этапе разработки, так и в процессе сборки. Поэтому защищать нужно не только собственный код, но и всю цепочку поставки ПО.</p> <h3>Где возникает основной риск</h3> <p>Риски могут возникать почти на любом этапе, начиная от разработки и публикации исходного кода до сборки и доставки готового продукта. Один из очевидных сценариев: компрометация аккаунта разработчика или мейнтейнера в случаях отсутствия регистрации домена. Зарегистрировав домен на себя, злоумышленник получает доступ к репозиторию и может изменить исходный код или выпустить новую версию уже известного пакета и его артефактов. При автоматическом обновлении такой компонент способен попасть в корпоративную среду, а проверка средствами композиционного анализа покажет его как безопасный.</p> <p>Злоумышленник может взломать аккаунт разработчика или намеренно войти в сообщество и действовать изнутри. Например, в 2024 году обнаружился бэкдор в XZ Utils, который создал участник проекта. В течение двух лет он активно участвовал в развитии проекта, помогал исправлять ошибки, позже ему дали статус со-мейнтейнера с правом менять код. Получив доверие сообщества, он начал внедрять вредоносный код в набор утилит.</p> <p>Неподдерживаемая библиотека — это еще одна зона риска. Важно понимать, поддерживается ли сам проект, насколько активно развивается и есть ли команда, способная оперативно выпускать исправления. Если библиотека фактически заброшена, новая уязвимость может остаться без патча.</p> <p>Отдельный риск связан с системой сборки и CI/CD, такие средства, как Maven и Gradle, являются источниками риска. Они связывает исходный код, зависимости и готовый продукт и при этом часто имеют доступ к инфраструктуре. Если скомпрометирована система сборки или ее компоненты, злоумышленник может изменить конечный артефакт еще на этапе его формирования.</p> <p>Потенциальная угроза для продукта может скрываться и во фреймворках, которые используются в разработке. Например, Spring — это один из популярных фреймворков среди российских Java-разработчиков. По информации из <a href="https://jokerconf.com/research/state-of-java/2026/report.html">опроса </a>«State of Java» компании JUG Ru Group, Spring используется в более чем 80% проектов. И устаревшая версия фреймворка может затронуть сразу большое количество систем, поскольку теперь сообщество устраняет уязвимости только в актуальных версиях Spring. Отделу ИБ и разработчикам важно смотреть не только на наличие известных уязвимостей, но и контролировать статус поддержки версий сообществом разработчиков. Особенно это актуально сейчас, когда после выпуска обновлений бесплатная поддержка истекших версий для разработчиков прекращается и рекомендуется переход на коммерческую поддержку, которая недоступна в России.</p> <h3>ИИ тоже имеет значение</h3> <p>Генеративный ИИ уже стал неотъемлемой частью процесса разработки: он помогает писать код, подбирает необходимые библиотеки или фреймворки. При этом возникает дополнительный риск: модель может предложить внешний компонент, не учитывая, есть ли в нем известные уязвимости, насколько актуальна используемая версия и применима ли поддержка на территории России. Конечно, многое зависит от конкретной ИИ-модели и ее источников данных. Одни модели работают на основе ранее известных примеров кода, другие уже умеют обращаться к внешним ресурсам и получать более актуальную информацию. При этом сам факт рекомендации библиотеки не означает, что она прошла проверку безопасности. ИИ ориентируется прежде всего на то, работает ли предложенный код, но не проверяет зависимости.</p> <p>Для проверки можно использовать композиционный анализ. Он позволяет определить версии подключенных библиотек и проверить их на наличие известных уязвимостей через базы БДУ ФСТЭК, NIST и др. Еще один подход — настроить ИИ на использование доверенных библиотек из внутреннего репозитория, а не произвольных компонентов из публичных источников. В таком случае модель будет работать только с тем набором компонентов, который уже прошел необходимые проверки.</p> <h3>Безопасность цепочки поставок — общая ответственность поставщика и разработчика</h3> <p>Сегодня вопрос контроля ИБ-рисков особенно актуален. Проверка компонентов, актуальности версии, контроль сборки в защищенной среде и быстрого устранения уязвимостей — не всегда задача только службы ИБ. Безопасность цепочки поставок требует совместной работы нескольких команд и компаний, которые постоянно взаимодействуют с целью повышения уровня защиты ПО.</p> <p>Отдел ИБ определяет правила использования доверенных компонентов, закрепляет политики, по которым нужно использовать определенное ПО из соответствующих доверенных источников, и контролирует их соблюдение. Далее к работе подключается команда архитекторов и разработчиков, а также платформенная команда (DevOps), которая должна обеспечивать безопасные среды запуска и платформу. В ее задачи должна входить реализация ИТ-инфраструктуры на надежных и доверенных компонентах, которые будут соответствовать требованиям российского законодательства в части безопасности. Разработка, в свою очередь, несет ответственность за работу продукта. Для этого вся команда разработки должна быть погружена в продукт и разбираться в том числе и в аспектах безопасности.</p> <p>Конечный продукт должен отвечать всем требованиям, как с точки зрения ИБ, так и с точки зрения функционала.</p> <h3>Как строить защиту цепочки поставок через компоненты с открытым исходным кодом</h3> <p>Исследовательская компания Gartner в своем отчете «Leader’s Guide to Software Supply Chain Security» 2024 года предложила выстраивать защиту цепочки поставок в три этапа: Curate, Create и Operate (управление, создание, эксплуатация). Такой подход позволяет контролировать происхождение программного продукта и снижать риски на каждом этапе цепочки.</p> <p>Первый этап — выбор доверенных компонентов: библиотек, фреймворков, компиляторов, интерпретаторов и средств проверки. Важно заранее понимать происхождение компонентов и использовать те, безопасность которых можно контролировать.</p> <p>Второй этап — безопасная разработка и анализ кода. Здесь необходимо контролировать весь процесс создания ПО — от исходного кода до готового артефакта, используя инструменты анализа и практики SSDLC (Secure Software Development Life Cycle) в соответствии с требованиями ГОСТ Р <nobr>56939-2024.</nobr> Это позволяет выявлять проблемы в подключаемых компонентах.</p> <p>Третий этап — контроль эксплуатации. Даже безопасный программный продукт может оказаться под угрозой, если его развернуть на уязвимой инфраструктуре. Поэтому необходимо контролировать и среду, в которой ПО запускается.</p> <p>Такой подход позволяет встроить безопасность непосредственно в процесс разработки. Кроме того, если используемые компоненты, их версии и требования к инфраструктуре заранее определены и документированы, аудит становится проще: не нужно каждый раз заново проверять весь технологический стек.</p> <p>Чем больше внешних компонентов используется в продукте, тем сложнее контролировать их происхождение, изменение и состояние. Поэтому при оценке безопасности цепочки для противодействия атак важно рассматривать весь путь, который проходит код до промышленной эксплуатации. Часть рисков и нагрузки с команд разработки можно снять за счет работы с проверенным поставщиком, который обеспечивает контроль безопасности и целостности компонентов на всех этапах их жизненного цикла.</p> <p>При выборе поставщика ПО необходимо учитывать не только функциональность решения, но и происхождение решений. Предпочтение следует отдавать российским поставщикам ПО, которые контролируют весь исходный код компонент и обеспечивают безопасный процесс и сборки на основе ГОСТ Р <nobr>56939-2024.</nobr> Разработка ПО должна вестись в соответствии с приказом № 117 ФСТЭК России от 11.04.2025 и другими нормативно-правовыми актами, связанными с безопасной разработкой ПО.</p> <p>Функциональным заказчикам рекомендуется включать в требования к ПО пункты соблюдения правил контроля и проверки кода и использования доверенных компонентов, что можно реализовать путем создания доверенных источников компонент для подрядных организаций на уровне компаний или индустрий.</p> <p>#IMAGE_235611#</p> Open source, или компоненты с открытым исходным кодом сегодня лежат в основе значительной части корпоративного ПО … article Алексей Захаров, директор по техническому консалтингу Axiom JDK https://www.itweek.ru/themes/detail.php?ID=235608 Thu, 24 Sep 2026 11:08:19 +0300 <p>До недавних пор концепция «нулевого доверия» (Zero Trust Architecture, ZTA) считалась избыточной. Многофакторная контекстная аутентификация, короткоживущие ключи, централизованная авторизация и мониторинг аномалий — всё это означало дополнительные затраты в проектировании и повышенное потребление ресурсов в эксплуатации. И как следствие, внедрение ZTA признавалось нецелесообразным.</p> <p>Но ситуация изменилась. Новые технологии на базе искусственного интеллекта и прочих интеллектуальных инструментов в разы увеличили скорость атак и сделали их проще в реализации. Темп обнаружения и эксплуатации уязвимостей уверенно превзошёл скорость патч-менеджмента. А сами атаки стали комплексными и «обходными». Они реализуются через цепочки поставок и подрядчиков.</p> <p>Эту тенденцию подтверждают и мировые, и российские исследования. Согласно Verizon Data Breach Investigations Report 2025, доля инцидентов, связанных с третьими сторонами, выросла с 15 до 30% всего за один год. Иными словами, почти каждый третий расследованный инцидент связан с подрядчиками, поставщиками сервисов, ИТ-аутсорсингом и другими участниками цепочки поставок. Средний <a href="https://www.ibm.com/reports/data-breach">ущерб</a> от таких атак, по данным IBM Cost of Data Breach Report 2026, составляет $4,91 млн.</p> <p>Аналогичные данные приводит RED Security по России: доля инцидентов, связанных с третьими сторонами, в 2025 году также достигла 30%, а годом ранее она не превышала 10%. При этом 80% инцидентов начинаются с компрометации учётных записей, а порядок обнаружения уязвимостей с часов упал до минут.</p> <p>Гибридный и удалённый форматы работы стали нормой, и информационные системы должны быть доступны через интернет. В 2025 году гибридный режим стал самым распространённым в России. По данным исследования консалтинговой компании get experts, 51% сотрудников работают в гибридном формате, 41% — в офисе и только 8% — полностью удалённо. Четверть компаний в России за последний год изменили формат работы сотрудников в сторону гибрида.</p> <p>Это означает, что классический сетевой периметр как граница защиты фактически перестал существовать. Корпоративные ресурсы доступны извне, а значит, модель «доверяй всему, что внутри сети» больше не работает. И последним рубежом защиты становится архитектура нулевого доверия.</p> <h3>Архитектура ZTA</h3> <p>Архитектура Zero Trust строится на трёх взаимосвязанных принципах, каждый из которых закрывает определённый класс угроз.</p> <ol> <li> <strong>Аутентификация.</strong> В модели ZTA аутентификация не ограничивается вводом пароля при входе в систему. В ней используются короткоживущие ключи и учитывается весь доступный контекст: устройство, с которого выполняется запрос, сетевое и географическое местоположение, время обращения, поведенческие шаблоны пользователя. Это означает, что даже перехваченные учётные данные не дадут злоумышленнику устойчивого доступа, поскольку контекст не совпадёт.</li> <li><strong> Авторизация.</strong> Права доступа выдаются по принципу минимально необходимых и могут быть отозваны мгновенно. Пользователь или сервис получают доступ только к тем ресурсам, которые нужны для конкретной задачи, и только на время её выполнения. При изменении контекста или выявлении аномалии доступ прекращается без участия администратора.</li> <li><strong> Телеметрия.</strong> Непрерывный сбор и анализ событий безопасности позволяет выявлять аномалии в реальном времени. Триггеры аномальной активности используются не только для оповещений, но и для управления авторизацией: при срабатывании триггера система может заблокировать доступ, запросить повторную аутентификацию или перевести информационную систему в экстремально защищённый режим вплоть до полной изоляции.</li> </ol> <p>Следуя этим принципам, можно построить защиту, для преодоления которой злоумышленнику потребуется проходить расширенную аутентификацию на каждом шаге развивающейся атаки. Вечных «ключей» здесь нет, а доступ ограничен узкими разрешёнными рамками, в которые входят хронологическое окно, знакомое устройство, известное сетевое и географическое местоположение. При этом триггеры аномальной активности в реальном времени не позволят развить атаку вглубь.</p> <h3>Пути внедрения ZTA</h3> <p>Существует два принципиальных пути внедрения ZTA. Первый — «сверху вниз», через одновременную перестройку всей инфраструктуры. Трансформация инфраструктуры, долго и сложно эволюционировавшей внутри сложившихся бизнес-процессов, — дело непростое. Исходные коды и первоначальные разработчики могут быть недоступны, масштабные инфраструктурные изменения способны нарушить непрерывность бизнес-процессов, а вложения в системы, которые уже работают, не всегда экономически оправданы. По данным Gartner, до 40% проектов цифровой трансформации не достигают заявленных целей, а средняя стоимость простоя критичных бизнес-систем для крупных компаний оценивается в сотни тысяч долларов в час.</p> <p>Второй путь — «снизу вверх», от конечного устройства к ядру инфраструктуры. Этот путь делает процесс постепенным, последовательным и управляемым. Поэтому он подходит большинству организаций и включает три части.</p> <p>Первый этап — защита конечных точек доступа. На этом уровне ZTA внедряется как наложенное средство, дублирующее существующую модель безопасности на стадии внедрения и обеспечивающее бесшовный переход после её завершения. Понятие периметра возвращается на новом уровне. Не в виде замка на шлюзах, а в форме контролируемого доступа с учётом контекста. И доступ предоставляется только к разрешённым ресурсам и только при совпадении контекста.</p> <p>Второй этап — сетевая безопасность. Сегментация, маршрутизация, IEEE 802.1x представляют собой более инвазивные задачи, но их решение также относится к классу наложенных средств. ZTA здесь реализуется стандартными методами: фильтры и маршрутизаторы, RADIUS-серверы, контроль сетевых потоков. Работа выполняется силами сетевых инженеров и не требует ресурсов разработки.</p> <p>Третий этап — самая важная и самая трудоёмкая задача. На этой стадии два предыдущих шага уже пройдены, интеграционные требования к доработке систем уже сформулированы и готовы и вопрос сводится к оценке целесообразности. Если доработки слишком дороги, уже внедрённых элементов ZTA на первых двух уровнях будет достаточно для большинства сценариев. Если же требования к защищённости высоки — системы ГИС, КИИ, ПДн — и цена неприемлемого риска превышает стоимость ZTA-трансформации, необходимо идти до конца.</p> <h3>Когда пора внедрять ZTA</h3> <ol> <li> Доля инцидентов, связанных с третьими сторонами и цепочками поставок, растёт в вашей отрасли.</li> <li> Более трети сотрудников работают в гибридном или удалённом формате.</li> <li> Критичные системы доступны извне или через подрядчиков.</li> <li> Существующая модель безопасности построена на доверии к сетевому периметру.</li> <li> Организация подпадает под требования регуляторов по защите КИИ, ГИС или ПДн.</li> </ol> <h3>Как внедрять ZTA</h3> <ol> <li> Проведите аудит и выявите системы, доступные извне или через третьих лиц.</li> <li> Внедрите защиту «последней мили»: контекстную аутентификацию и контроль доступа на уровне конечных устройств.</li> <li> Выполните сетевую сегментацию и внедрите контроль сетевых потоков (IEEE 802.1x, RADIUS, микросегментация).</li> <li> Настройте телеметрию и триггеры аномальной активности с автоматическим отзывом доступа.</li> <li> Оцените целесообразность глубокой трансформации прикладных систем с учётом регуляторных требований и стоимости риска.</li> </ol> <p>Сегодня Zero Trust перестал быть опцией для организаций с повышенными требованиями к безопасности. Рост атак через цепочки поставок, массовый переход на гибридный формат работы и исчезновение классического сетевого периметра делают ZTA базовым требованием для любой инфраструктуры, где есть внешние подключения или доступ подрядчиков. Практический путь внедрения выстраивается последовательно, «снизу вверх», и ведёт от защиты конечных точек через сегментацию к оценке целесообразности глубокой трансформации. Организациям, работающим с КИИ, ГИС или ПДн, переход на модель нулевого доверия следует рассматривать как обязательный элемент стратегии защиты, который требует реализации в текущем горизонте планирования.</p> <p>#IMAGE_235609#</p> До недавних пор концепция «нулевого доверия» (Zero Trust Architecture, ZTA) считалась избыточной. Многофакторная контекстная … article Султан Салпагаров, архитектор по информационной безопасности Getmobit https://www.itweek.ru/themes/detail.php?ID=235607 Thu, 24 Sep 2026 10:53:13 +0300 <p><em>Результативность систем искусственного интеллекта зависит от того, насколько предсказуемо и безопасно данные перемещаются между центрами обработки данных, облачными средами и периферией. При проектировании систем теперь столь же важно учитывать показатели задержки, отказоустойчивость и видимость сети, как и вычислительные мощности, пишет на портале </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>Крис Альбердинг, директор по продуктам компании BCN.</em></p> <p>Дискуссии об инфраструктуре для ИИ стали весьма предсказуемыми. Почти все они сводятся к обсуждению графических процессоров (GPU), специализированных чипов, энергообеспечения и гонки по созданию все более крупных кластеров ИИ. Эти инвестиции необходимы, однако они упускают из виду не менее важный вопрос: насколько эффективно ИИ может перемещать данные туда, где требуются интеллектуальные вычисления?</p> <p>Вычислительные мощности создают интеллект. Сети обеспечивают его доставку.</p> <p>За последний год я провел множество бесед с ИТ-руководителями крупных предприятий из различных отраслей, сталкивающимися с реалиями внедрения ИИ. Сперва обсуждения почти всегда касаются моделей, вычислительных мощностей или облачной стратегии. Но уже к третьей беседе речь обычно заходит о сетевой инфраструктуре. И такой сдвиг вполне закономерен.</p> <p>Первая волна внедрения ИИ в корпоративном секторе принесла успех тем организациям, которые имели доступ к вычислительным мощностям. Следующая волна принесет успех тем, кто сможет эффективно, безопасно и предсказуемо перемещать данные в условиях все более распределенных сред. Это совершенно иная задача с точки зрения инфраструктуры.</p> <h3>Перемещение данных становится стратегической задачей</h3> <p>Традиционные корпоративные приложения генерировали довольно предсказуемый трафик. Пользователи подключались к централизованным системам, а сети проектировались для обеспечения надежного соединения между различными локациями. ИИ работает иначе.</p> <p>Один-единственный запрос к системе ИИ может потребовать извлечения данных из корпоративного хранилища и информации из векторной базы данных, обращения к большой языковой модели (LLM), работающей в другой среде, применения политик безопасности и возврата ответа пользователю — и все это за считанные секунды. Ни один из этих этапов не происходит изолированно, и все они невозможны без участия сети.</p> <p>Именно поэтому расходы на инфраструктуру для ИИ продолжают стремительно расти. По прогнозам Gartner, в 2026 г. мировые расходы на ИИ достигнут 2,59 трлн. долл., причем почти половина этой суммы придется на инфраструктуру, поскольку организации расширяют системы, необходимые для масштабного внедрения ИИ. Однако одни лишь затраты на инфраструктуру не гарантируют успеха.</p> <p>Одно из главных изменений, привносимых ИИ, заключается в том, что перемещение данных превращается из операционной задачи в стратегическую. Обучение модели — это лишь часть уравнения. Настоящая сложность заключается в обеспечении стабильной доставки интеллектуальных возможностей между дата-центрами, облачными платформами, филиалами, периферийными узлами и растущим числом приложений, зависящих от ИИ. Для этого требуется инфраструктура, ориентированная на эффективную передачу данных, а не просто на обеспечение высокой пропускной способности. Производительность сети всегда имела значение, но внедрение ИИ выводит этот вопрос на новый уровень важности.</p> <h3>Задержка передачи данных становится бизнес-показателем</h3> <p>Специалисты по инфраструктуре часто уделяют основное внимание таким параметрам, как загрузка GPU, производительность систем хранения данных или точность моделей. Однако конечные пользователи не сталкиваются с этими показателями напрямую. Они оценивают скорость отклика ИИ-помощника, мгновенность появления рекомендаций и плавность работы автоматизированных процессов. Для многих приложений на базе ИИ задержка перестает быть сугубо сетевой характеристикой и становится важным бизнес-показателем.</p> <h3>Инференс смещается на периферию</h3> <p>Именно задачи инференса во многом стимулируют эти изменения. Если обучение моделей по-прежнему сосредоточено в крупных облачных средах и гипермасштабируемых центрах обработки данных, то инференс все чаще происходит непосредственно в местах выполнения рабочих задач: в больницах, на заводах, в розничных магазинах, финансовых учреждениях, кампусах и филиалах компаний. По прогнозам IDC, в ближайшие несколько лет почти половина предприятий внедрит системы ИИ-инференса на периферии, что снизит зависимость от централизованной обработки данных, но одновременно повысит требования к распределенной инфраструктуре.</p> <h3>Проектирование с упором на предсказуемость, а не только на пропускную способность</h3> <p>За свою карьеру я участвовал в нескольких масштабных этапах трансформации инфраструктуры: от перехода к клиент-серверным архитектурам и виртуализации до внедрения облачных вычислений. Ситуация с ИИ отличается тем, что изменения затрагивают не какой-то один уровень инфраструктуры, а все уровни одновременно, включая сетевой.</p> <p>Речь идет не столько об увеличении пропускной способности сети, сколько о создании сетей, работа которых остается предсказуемой при изменении характера рабочих нагрузок, росте числа пользователей и интеграции ИИ в повседневные бизнес-процессы. Когда ИИ становится неотъемлемой частью деятельности компании, критически важными становятся такие аспекты, как видимость сети, отказоустойчивая маршрутизация, разнообразие каналов связи, комплексная безопасность и интеллектуальное управление трафиком. Новое звучание приобретает и понятие надежности.</p> <p>Когда ИИ задействован в обслуживании клиентов, обеспечении кибербезопасности, производственных процессах или принятии финансовых решений, сбой в работе сети перестает быть просто технической проблемой связи. Он может привести к остановке бизнес-процессов, все сильнее зависящих от аналитики реального времени.</p> <h3>Безопасность должна следовать за данными</h3> <p>В сфере безопасности действуют те же принципы. Системы ИИ взаимодействуют с конфиденциальными корпоративными данными, распределенными по различным средам. Для безопасного перемещения этой информации необходима слаженная работа сетевых и защитных систем, опирающаяся на такие принципы, как модель Zero Trust, сегментация, контроль доступа с учетом идентификационных данных и непрерывный мониторинг.</p> <h3>Подключение данных к интеллектуальным системам</h3> <p>Все это ничуть не умаляет важности вычислительных мощностей. GPU, ускорители и передовые процессоры по-прежнему будут определять возможности ИИ. Однако подход к формированию инфраструктуры должен стать более комплексным.</p> <p>Организации, извлекающие максимальную пользу из ИИ, не просто внедряют более крупные модели. Они создают среду, в которой данные, приложения, пользователи и интеллектуальные системы могут беспрепятственно взаимодействовать друг с другом. Это требует уделения внимания сетевой инфраструктуре на гораздо более ранних этапах проектирования, чем это делалось во многих организациях ранее.</p> <p>На протяжении десятилетий сети обеспечивали связь между людьми и приложениями. Сегодня они все чаще связывают данные с интеллектуальными системами. Я считаю, что это один из важнейших сдвигов в инфраструктуре корпоративных ИТ. Организации, которые осознают это на раннем этапе, возможно, и не создадут самые масштабные системы ИИ, но они будут лучше подготовлены к их масштабированию, адаптации к будущим изменениям и получению реальной бизнес-отдачи от инвестиций в технологии ИИ.</p> Результативность систем искусственного интеллекта зависит от того, насколько предсказуемо и безопасно данные … article https://www.itweek.ru/themes/detail.php?ID=235606 Wed, 23 Sep 2026 16:21:01 +0300 <p>Сбер объявил о запуске нового функционала SaaS-версии ИИ-ассистента разработчика GigaCode для корпоративных клиентов. Теперь бизнесу доступен GigaCode Desktop — инструмент, объединяющий множество агентов, которые упрощают выполнение типовых задач: от поиска информации и анализа документов до подготовки отчетов и презентаций. Об этом рассказал старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка Андрей Белевцев в преддверии конференции ГигаКонф для бизнеса.</p> <p>GigaCode Desktop не ограничивается только лишь работой с кодом. Инструмент может быть востребован в самых разных подразделениях компании, но в первую очередь — у аналитиков, продакт-менеджеров, руководителей проектов и сотрудников со смежными ролями. Благодаря GigaCode Desktop они могут сосредоточиться на нестандартных, креативных задачах, передав рутинные процессы искусственному интеллекту.</p> <p>Ранее GigaCode был протестирован на внутренних бизнес-процессах Сбера. Пилотный проект подтвердил высокую эффективность решения. Он помог повысить производительность команд управления продуктами и бэк-офиса. </p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «Мы видим высокий интерес к продукту со стороны компаний, где велика роль внутренней разработки и множество процессов завязано на оформление документации, аналитику и маркетинг. В частности, запросы поступают от девелоперов, инжиниринговых компаний и телеком-сектора. Запуск GigaCode Desktop — наглядный пример нашего подхода к созданию технологических решений: сначала мы внедряем продукт в собственные процессы, оттачиваем его на реальных задачах и добиваемся максимальной эффективности, а уже затем предлагаем проверенный инструмент рынку. Мы убеждены, что именно такая практика позволяет нам гарантировать высокое качество и реальную бизнес-ценность для клиентов каждого продукта».</p> <p>Всем действующим клиентам функциональность GigaCode Desktop будет доступна после планового обновления ИИ-ассистента GigaCode. Новые пользователи смогут протестировать возможности как самого GigaCode, так и нового расширения Desktop в рамках бесплатного периода. Чтобы получить доступ к продукту, достаточно оставить заявку на сайте.</p> Сбер объявил о запуске нового функционала SaaS-версии ИИ-ассистента разработчика GigaCode для корпоративных клиентов. Теперь … message https://www.itweek.ru/themes/detail.php?ID=235605 Wed, 23 Sep 2026 16:19:14 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил вклад инноваций промышленных предприятий в обеспечение технологического суверенитета России. Анализ базируется на данных статистики за <nobr>2022–2025 гг. по видам</nobr> экономической деятельности.</p> <p>Одним из индикаторов технологического суверенитета является динамика объемов инновационных товаров, работ, услуг, которая отражает расширение производства продукции на основе технологических изменений. В 2025 г. объем такой продукции в промышленности составил 9,3 трлн руб. (в целом по экономике — 12,6 трлн руб.), показав не наблюдавшиеся ранее темпы прироста: +22,8% к уровню 2024 г. и +51,6% в сравнении с 2022 г. (в постоянных ценах). Положительная динамика характерна для подавляющего большинства отраслей.</p> <p>Тренд на ускорение инновационных процессов задают обрабатывающие отрасли: в производстве машин и оборудования, электрооборудования объем инновационной продукции за период <nobr>2022–2025 гг.</nobr> вырос в 3,5 раза — до 715,1 и 411,5 млрд руб. соответственно; в авиастроении — в 2,8 раза (927,6 млрд руб.), в производстве компьютеров, электронных и оптических изделий — в 2 раза (892,2 млрд руб.); железнодорожных локомотивов и подвижного состава — в 1,8 раза (129,3 млрд руб.) и др. Среди отраслей легкой промышленности заметно выделяются производители одежды, увеличившие выпуск инновационной продукции более чем втрое.</p> <p>Технологическая независимость во многом строится на продукции высокого уровня новизны. За период <nobr>2022–2025 гг.</nobr> объем вновь внедренных или подвергавшихся значительным технологическим изменениям товаров (работ, услуг) вырос на 65% (в постоянных ценах) и достиг 5,7 трлн руб. В основном это заслуга организаций высоко- и среднетехнологичных отраслей: в производстве готовых металлических изделий ее выпуск составил 1,1 трлн руб. (рост в 4,1 раза по сравнению с 2022 г.), летательных и космических аппаратов — 750,8 млрд руб. (в 3,4 раза), компьютеров, электронных и оптических изделий — 649,1 млрд руб. (в 2,2 раза), машин и оборудования — 526,2 млрд руб. (в 6,7 раза), автотранспортных средств — 393,4 млрд руб. (в 2,4 раза), электрооборудования — 361,4 млрд руб. (в 4,8 раза).</p> <p>Рост производства инновационной продукции сопровождается высокими объемами инвестиций в инновационную деятельность. Затраты на инновации в промышленном производстве достигли 2,2 трлн руб., что на 23,6% больше, чем в 2022 г. Во многом этому способствовало усиление государственной поддержки: объем средств федерального бюджета на инновационную деятельность составил 282,7 млрд руб.</p> <p>Перспективы развития инновационной деятельности складываются в пользу продуктовых инноваций, ускоряющих обновление выпускаемой продукции и создающих основу для достижения технологического суверенитета страны. Затраты на продуктовые инновации в промышленности достигли 1,4 трлн руб. (+55% к уровню 2022 г. в постоянных ценах). Максимальный рост — в производстве электрооборудования, химических веществ и продуктов, компьютеров, машин и оборудования.</p> <p>Инновационная деятельность промышленного производства демонстрирует значительный вклад в обеспечение технологического суверенитета страны. Очевидна ориентация предприятий на увеличение объемов инновационной продукции, особенно высокой степени новизны, которая обеспечивает обновление номенклатуры товаров и услуг на базе новых технологий. В период <nobr>2022–2025 г.</nobr> этот тренд установился в промышленности в целом и — особенно — в таких значимых секторах, как машиностроение, включая транспортное, радиоэлектронику, производство электрического оборудования. Высокие темпы инновационного развития демонстрирует также легкая промышленность.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучил вклад инноваций промышленных предприятий … message https://www.itweek.ru/themes/detail.php?ID=235604 Wed, 23 Sep 2026 16:16:29 +0300 <p>В первом полугодии 2026 года число вакансий, где требуется умение работать с искусственным интеллектом, выросло на 37% по сравнению с тем же периодом прошлого года. Исследование «Авито Работы» и маркетплейса нейросетей chad показало, что ИИ-компетенции становятся ощутимым фактором роста доходов: оклады в таких вакансиях растут быстрее среднерыночных, а в отдельных профессиональных сферах разрыв в зарплатных предложениях достигает почти двух раз.</p> <p>Наиболее заметная финансовая разница зафиксирована в сфере маркетинга, рекламы и PR, где соискателям со знанием нейросетей работодатели готовы предложить в среднем 105 917 рублей в месяц против 60 258 рублей без этих навыков. Ощутимый аванс за владение ИИ наблюдается и в юриспруденции, где оклады для специалистов с ИИ-компетенциями достигают 80 000 рублей против 60 538 рублей без них. В сфере страхования эта надбавка составляет около 20%, формируя уровень предложений в 70 000 рублей против 58 321 рубля.</p> <p>В digital-секторе спрос на ИИ-компетенции не просто растет, а становится максимально прикладным. Быстрее всего работодатели увеличивают требования к умению работать с нейросетями для графических дизайнеров (+104%), менеджеров по работе с маркетплейсами (+84%), контент-менеджеров (+43%) и SMM-специалистов (+42%).</p> <p>Эта тенденция работодателей полностью совпадает с изменением реального пользовательского поведения. По данным маркетплейса нейросетей chad, пользователи перешли от абстрактных запросов к точечным рабочим задачам. Доля операций по созданию изображений за год выросла с 2,8% до 20,8%, а по подготовке презентаций и документов — с 8,7% до 12,7%.</p> <p>Параллельно спрос на ИИ-навыки выходит за рамки традиционного digital-сектора. Это соответствует результатам июньского опроса: о встречающихся требованиях к ИИ-навыкам сообщили 31% работников сферы услуг и сельского хозяйства, 30% представителей транспорта и логистики, 28% специалистов торговли, продаж и клиентского сервиса, а также 23% работников промышленности. </p> <p>Вместе с этим расширяется и география применения новых требований. С необходимостью уметь работать с нейросетями при трудоустройстве чаще всего сталкиваются жители Уфы (45%) и Казани (42%). В столицах и крупнейших региональных центрах показатель также держится на высоком уровне: в Москве, Краснодаре и Воронеже об этом заявляют по 38% респондентов, а в Санкт-Петербурге — 35% соискателей.</p> В первом полугодии 2026 года число вакансий, где требуется умение работать с искусственным интеллектом, выросло … message https://www.itweek.ru/themes/detail.php?ID=235603 Wed, 23 Sep 2026 16:13:46 +0300 <p>Сбер представил обновленную среду разработки GigaIDE Pro с повышенной производительностью. — теперь платформа потребляет меньше памяти и предлагает доработанные инструменты для бэкенд- и фронтенд-разработки. Об этом сообщил старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка Андрей Белевцев в преддверии конференции ГигаКонф для бизнеса.</p> <p>В новой версии GigaIDE Pro усилены сценарии работы с данными: пользователи могут эффективнее обрабатывать большие объемы информации, строить прогнозы и автоматизировать аналитику. В числе дополнительной функциональности — расширенная поддержка СУБД, инструментов стилизации, интеграция с очередями сообщений, удаленная разработка на Python и блокноты Jupyter (всего внедрено десять новых инструментов).</p> <p>В рамках обновления реализована поддержка именных лицензий, которые дополняют существующие конкурентные. Именная лицензия позволяет использовать Pro-функциональность без постоянного подключения к локальному серверу лицензирования. </p> <p>Андрей Белевцев, старший вице-президент, руководитель блока «Технологическое развитие» Сбербанка, отметил: «На высококонкурентном рынке инструментов разработки выигрывают решения, которые точно отвечают бизнес-задачам. Широкая функциональность и гибкая модель лицензирования GigaIDE помогают компаниям выбрать оптимальный формат работы и сократить затраты. Кроме того, для пользователей, работающих вне корпоративного контура, не требуется регулярное подключение к серверу. Это упрощает работу в зонах с нестабильным интернетом».</p> <p>Чтобы воспользоваться GigaIDE, достаточно зарегистрироваться в GitVerse, скачать дистрибутив GigaIDE 2026.1 и активировать подписку.</p> Сбер представил обновленную среду разработки GigaIDE Pro с повышенной производительностью. — теперь платформа … message https://www.itweek.ru/themes/detail.php?ID=235598 Wed, 23 Sep 2026 10:39:24 +0300 <p>Пятница, 18:00. Через два часа запланирован релиз, основной регресс почти завершён, но разработчики только что исправили дефект в авторизации. Само исправление проверили, однако пройти все связанные с ним сценарии команда уже не успевает.</p> <p>Блокирующих ошибок нет, перенос релиза потребует дополнительных ресурсов и затронет планы нескольких команд. На первый взгляд ситуация знакомая и вполне рабочая, однако именно в такие моменты возникает один из самых сложных вопросов релизного цикла: достаточно ли мы знаем о состоянии продукта, чтобы выпускать его в продакшен?</p> <p>Ответ пытаются найти в цифрах: регресс пройден на 90%, критических дефектов нет, большая часть сценариев завершилась успешно — формально всё выглядит достаточно уверенно. Но эти показатели мало говорят о реальном риске, пока неизвестно, что именно скрывается в оставшихся 10%.</p> <p>Рассмотрим три ситуации, которые внешне похожи: тестирование не закончено, время до релиза ограничено. Решения при этом могут оказаться совершенно разными.</p> <h3>Ситуация 1. Не успели проверить второстепенную функцию</h3> <p>Предположим, команда не завершила проверку изменений в разделе настроек, которым пользуется небольшая часть аудитории. Функция изолирована, критические бизнес-процессы от неё не зависят, а возможный дефект останется внутри ограниченного пользовательского сценария.</p> <p>В этом случае область неопределённости понятна: команда знает, что именно осталось без полной проверки, кого потенциально затронет проблема и насколько серьёзными будут последствия. При стабильной остальной части продукта такой риск вполне может быть приемлемым для релиза.</p> <p>Ситуация меняется, когда последнее исправление находится в компоненте, от которого зависит значительная часть системы.</p> <h3>Ситуация 2. Перед релизом исправили авторизацию</h3> <p>За несколько часов до запуска разработчики обнаружили проблему в авторизации и внесли исправление. Повторная проверка подтверждает, что исходный дефект устранён, изменение затрагивает общий сервис авторизации, от которого зависят веб-приложение, мобильное приложение и интеграционные сценарии.</p> <p>В релизном отчёте картина по-прежнему выглядит благополучно: основной регресс завершён, блокирующих дефектов нет, последнее исправление работает. Однако уровень неопределённости вырос, поскольку небольшое изменение оказалось в точке, через которую проходят сразу несколько частей продукта.</p> <p>Именно поэтому после поздних исправлений важно понимать область их влияния. Вопрос «Работает ли фикс?» даёт лишь часть информации. Гораздо важнее выяснить, какие компоненты используют изменённый код, какие пользовательские сценарии через него проходят и где ещё могут проявиться последствия.</p> <p>Иногда один такой вопрос даёт для решения о релизе больше, чем десятки дополнительных тест-кейсов.</p> <h3>Ситуация 3. Изменили платёжный API</h3> <p>Команда изменила платёжный API, проверила проведение оплаты и получила успешный результат. Формально критическая операция работает, однако в продукте платёж не существует сам по себе. Обычно за ним следует целая цепочка: оплата → изменение статуса заказа → передача данных в смежные системы → складские операции → возврат.</p> <p>После изменения API команда успела проверить начало этой цепочки, но пройти её полностью до релиза уже не сможет. В такой ситуации успешная оплата ещё ничего не говорит о том, корректно ли создастся заказ, получит ли склад необходимые данные, появится ли информация в CRM и сможет ли пользователь впоследствии оформить возврат.</p> <p>Особенность подобных ошибок заключается в том, что релиз может выглядеть успешным. Пользователи оплачивают покупки, сервис отвечает, мониторинг не показывает очевидного падения, а проблема тем временем возникает дальше по цепочке и обнаруживается спустя несколько часов.</p> <p>Поэтому отсутствие критических дефектов само по себе ещё не делает релиз безопасным. Найденные ошибки описывают то, что команда уже увидела; релизный риск во многом определяется тем, чего она могла не увидеть.</p> <p>В практике QA-сопровождения мы регулярно сталкиваемся с ситуациями, когда решение о выпуске приходится принимать при незавершённом регрессе или после изменений, внесённых незадолго до релиза.</p> <p> <strong>Красные флаги перед релизом: </strong></p> <ul> <li> <strong>последние изменения затрагивают авторизацию, платежи, данные или ключевые интеграции</strong>, а времени на проверку связанных сценариев уже нет;</li> <li> <strong>область влияния изменения остаётся неясной</strong>: команда понимает, что исправили, но не может уверенно сказать, какие компоненты и процессы зависят от этого участка системы;</li> <li> <strong>проблему после запуска будет сложно быстро заметить</strong> — критические операции недостаточно покрыты мониторингом, а последствия могут накапливаться постепенно;</li> <li> <strong>последствия трудно локализовать или безопасно откатить</strong>: даже после возврата предыдущей версии уже выполненные операции, изменённые данные или отправленные события потребуют отдельного восстановления.</li> </ul> <p>Каждый из этих признаков ещё не означает, что релиз нужно отменять. Но сочетание нескольких красных флагов заметно повышает цену ошибки и требует гораздо более веских оснований для решения о выпуске.</p> <h3>Что делать, если ошибка обнаружится уже после релиза</h3> <p>Даже тщательно проведённое тестирование не исключает проблем в продакшене, поэтому качество релизного решения зависит ещё и от способности команды быстро увидеть отклонение и ограничить его последствия.</p> <p>Перед запуском стоит понимать, какие сигналы покажут проблему, есть ли мониторинг критических операций, насколько быстро можно определить источник сбоя и возможен ли безопасный откат. Для некоторых систем важен и следующий вопрос: сколько операций успеет пройти до того момента, когда команда заметит ошибку.</p> <p>Если отклонение обнаруживается за несколько минут, а изменение можно быстро откатить без потери данных, команда получает больше пространства для принятия риска. Когда сбой способен часами оставаться незаметным и постепенно затрагивать пользователей, заказы или финансовые операции, требования к уверенности перед релизом становятся значительно выше.</p> <p>Два технически похожих релиза могут требовать разных решений даже при одинаковом объёме тестирования.</p> <h3>Пять вопросов перед Go/No-Go</h3> <p>Когда до запуска остаётся несколько часов, длинный отчёт с количеством тестов и дефектов уже не всегда помогает увидеть главное. Для решения о выпуске полезнее последовательно ответить на пять вопросов:</p> <ol> <li> Какие критические пользовательские и бизнес-сценарии действительно проверены?</li> <li> Какие изменения появились после последней стабильной проверки?</li> <li> Какие системы, интеграции и процессы зависят от этих изменений?</li> <li> Какими будут последствия, если ошибка находится именно в непроверенной области?</li> <li> Насколько быстро команда сможет обнаружить проблему, ограничить её влияние и при необходимости откатить релиз?</li> </ol> <p>Ценность этих вопросов в том, что они переводят разговор с количества выполненных тестов на качество понимания риска.</p> <h3>Так выпускать или переносить? Кто должен сказать последнее слово</h3> <p>В спорной ситуации от QA иногда ждут простого ответа: выпускать или переносить. Но решение о релизе выходит за рамки качества кода и результатов тестирования. У него есть техническая, продуктовая и бизнес-цена.</p> <p>Задача QA в этот момент — сделать риск видимым: показать, что проверено, где остались пробелы, какие компоненты могут быть затронуты и насколько серьёзными окажутся последствия. Дальше у владельца релиза появляется основание для решения: принять этот риск, сократить объём выпуска или перенести запуск.</p> <p>Хороший Go/No-Go заканчивается не фразой «QA разрешил релиз», а общим пониманием команды: какой риск мы принимаем и почему считаем его допустимым.</p> <p>#IMAGE_235599#</p> Пятница, 18:00. Через два часа запланирован релиз, основной регресс почти завершён, но разработчики только что исправили … article Денис Кульчавый, заместитель генерального директора компании “Точка качества” https://www.itweek.ru/themes/detail.php?ID=235597 Wed, 23 Sep 2026 10:19:03 +0300 <p><em>Мы уже много лет называем современные автомобили «компьютерами на колесах». Большинство людей согласно кивают и идут дальше. Однако это определение становится все более важным — гораздо более важным, чем многие осознают. Руководителям служб информационной безопасности необходимо обратить внимание на этот возникающий риск, пишет в корпоративном блоге Пэдди Харрингтон, старший аналитик </em><em>Forrester</em><em>.</em></p> <p>Недавние исследования выявили вредоносное ПО, созданное специально для атаки на информационно-развлекательные системы автомобилей под управлением Android. Это знаменует собой важный этап в эволюции угроз для «подключенных» автомобилей (connected vehicles). Вполне естественно, что основное внимание уделяется последствиям для автопроизводителей и потребителей, но руководителям в области корпоративной безопасности также следует принять это к сведению. Ведь суть не в том, что автомобили внезапно стали уязвимыми — мы уже давно знаем, что подключенные автомобили несут в себе риски кибербезопасности. Важно то, что злоумышленники начинают рассматривать автомобильные платформы просто как очередное вычислительное устройство, которое можно атаковать.</p> <h3>Модель угроз для подключенных автомобилей меняется</h3> <p>Исторически сложилось так, что многие атаки на подключенные автомобили были направлены на смежные системы. Исследователи демонстрировали, как уязвимости в клиентских приложениях, API и облачных сервисах позволяют злоумышленникам отправлять команды автомобилям, тогда как для других атак требовались физическая близость и специализированные инструменты для получения доступа к функциям автомобиля. Эти инциденты подчеркивали риски, связанные с подключенными автомобилями, но редко затрагивали вредоносное ПО, разработанное непосредственно для самого автомобиля.</p> <p>Последние исследования свидетельствуют о значительных переменах. Вместо того чтобы атаковать платформы управления автомобилем или подключенные сервисы, злоумышленники создали вредоносное ПО для самой информационно-развлекательной системы. Это означает, что целью становится одна из самых заметных и функционально мощных вычислительных сред автомобиля.</p> <p>Нынешняя кампания, по-видимому, сосредоточена на активности ботнетов; цели будущих атак могут быть иными, но руководителям служб безопасности следует обращать внимание на саму тенденцию, а не на конкретный образец вредоносного ПО.</p> <h3>У ваших сотрудников есть автомобили. Подключены ли к ним мобильные устройства вашей компании?</h3> <p>Многие организации по-прежнему считают, что безопасность подключенных автомобилей касается прежде всего автопроизводителей. Однако такой подход упускает из виду сотрудников, которые подключают свои мобильные устройства к автомобилям через Bluetooth, USB, мобильные приложения и облачные сервисы. Операторы автопарков, сервисные и коммунальные службы, транспортные компании и предприятия, чья деятельность зависит от использования автомобилей, все активнее внедряют технологии подключенных транспортных средств. В результате формируется экосистема, в которой автомобили, мобильные устройства, приложения и корпоративные данные тесно взаимосвязаны.</p> <p>Когда в эту экосистему добавляется очередное подключенное устройство, руководителям служб безопасности стоит задаться вопросами:</p> <ul> <li> Что произойдет, если устройство будет скомпрометировано?</li> <li> Как мы сможем обнаружить вредоносную активность?</li> <li> Может ли вредоносное ПО перемещаться между подключенными системами?</li> <li> Насколько хороша видимость этого устройства и связанных с ним рисков?</li> </ul> <p>Это типичные вопросы при обсуждении ноутбуков, смартфонов, устройств Интернета вещей (IoT) и операционных технологий (OT). Теперь такого же внимания требуют и подключенные к сети автомобили.</p> <h3>Главная проблема — не сам автомобиль</h3> <p>Непосредственная угроза, связанная с этим вредоносным ПО, заключается не столько в том, что злоумышленники могут получить полный контроль над автомобилями (хотя это, безусловно, важно для безопасности сотрудников), сколько в другом. Подключенные автомобили все чаще работают под управлением встроенных операционных систем, имеющих общие черты с технологическими платформами, которые специалистам по безопасности и так сложно защищать (например, IoT- или OT-устройствами). Кроме того, в данном случае автомобили напоминают системы сторонних организаций (подрядчиков, автопроизводителей, поставщиков): они подключены к корпоративной сети, но у аналитиков по безопасности нет средств для контроля над ними.</p> <p>Вредоносное ПО для Android — не новость. Специалисты по безопасности годами борются с угрозами, нацеленными на мобильные ОС. Появление вредоносных программ для автомобильных систем на базе Android говорит о том, что злоумышленники все чаще рассматривают автомобили как еще один элемент экосистемы подключенных технологий, а не как отдельную категорию устройств.</p> <p>Это ставит перед аналитиками по безопасности новые вопросы:</p> <ul> <li> Может ли вредоносное ПО, находящееся в системе подключенного автомобиля, попытаться взаимодействовать с мобильным устройством, сопряженным через Bluetooth или USB?</li> <li> Смогут ли организации обнаружить такую ​​активность?</li> <li> Достаточно ли развиты средства обеспечения мобильной безопасности, чтобы выявлять подозрительное поведение, исходящее от нестандартных конечных точек?</li> </ul> <p>Сегодня эти вопросы носят преимущественно теоретический характер, поскольку мы еще не сталкивались с подобными атаками, распространяющимися между системами. Однако руководителям служб безопасности не стоит сбрасывать этот сценарий со счетов: отрасль уже не раз видела, как злоумышленники, закрепившись на одной платформе, переходят на смежные системы. Кто из вас до <nobr>2025-го</nobr> мог предположить, что через веб-камеру можно обойти защиту EDR и атаковать рабочие станции программами-вымогателями?</p> <h3>Без паники! Но, пожалуйста, пересмотрите свои риски</h3> <p>Организациям не нужно кардинально пересматривать свои программы обеспечения безопасности лишь из-за появления еще одного семейства вредоносного ПО. Однако им следует принять три положения:</p> <ol> <li> Включать подключенные автомобили в процессы моделирования угроз там, где это уместно — особенно организациям, имеющим собственный автопарк или сотрудников, часто подключающих корпоративные устройства к автомобилям (в том числе тех, кто пользуется услугами аренды транспорта во время командировок).</li> <li> Обеспечить возможность выявления вредоносного ПО и подозрительной активности на корпоративных и личных (BYOD) мобильных устройствах до того, как угроза затронет корпоративные приложения, данные или облачные сервисы.</li> <li> Рассматривать подключенные автомобили как часть более широкой экосистемы бизнес-технологий, а не как изолированные активы.</li> </ol> Появление этого нового вредоносного ПО для Android свидетельствует о том, что вопросы безопасности подключенных автомобилей переходят из плоскости теоретических обсуждений в сферу практического управления Мы уже много лет называем современные автомобили «компьютерами на колесах». Большинство людей согласно кивают … article https://www.itweek.ru/themes/detail.php?ID=235595 Wed, 23 Sep 2026 10:01:57 +0300 <p>Искусственный интеллект ускоряет разработку, но вместе со скоростью растёт цена неверно поставленной задачи. Чем быстрее команда превращает требования в код, тем важнее заранее проверить бизнес-логику, ограничения и критерии результата.</p> <h2>Код действительно становится дешевле — но не весь проект</h2> <p>Мы уже видим, что ИИ снижает трудоёмкость части разработки. Разработчик тратит меньше времени на разбор существующего кода, типовые фрагменты реализации, подготовку тестов и черновой документации. Часть задач удаётся выполнять быстрее и меньшим составом.</p> <p>Когда мы говорим, что код становится дешевле, речь именно об этом: на его производство и связанные с ним рутинные операции требуется меньше человеко-часов. Но это не значит, что вместе с кодом так же заметно дешевеет весь проект.</p> <p>Архитектуру всё равно нужно продумать, интеграции — спроектировать и проверить, права доступа — определить, данные — перенести без потерь. В сложных корпоративных системах остаётся большой объём работы, который нельзя свести к генерации кода.</p> <p>У коллег по отрасли есть более заметные примеры: задачи, для которых раньше требовалась команда примерно из десяти человек и несколько месяцев работы, сейчас в отдельных случаях выполняют втроём и примерно вдвое быстрее. У нас динамика та же: ИИ снимает часть рутинной нагрузки, но не заменяет решения, от которых зависит устройство системы.</p> <h2>Узкое место смещается к постановке задачи и проектированию</h2> <p>На наших проектах это уже хорошо заметно. Код можно получить быстрее, а вот понять, какой именно код нужен быстрее получается далеко не всегда. До реализации всё равно приходится разобраться в бизнес-процессе, снять противоречия и принять решения, которые модель не может принять за заказчика.</p> <p>Допустим, компания хочет автоматизировать согласование заявки. Собрать форму и базовый сценарий сегодня несложно. Но сначала нужно определить, откуда система берёт исходные данные, кто имеет право их менять, что происходит при сбое внешней системы, какие действия нужно сохранять для аудита и где проходит граница ответственности между несколькими системами.</p> <p>ИИ может предложить вполне разумный вариант. Разработчик тоже может сделать логичное предположение. Но ни то ни другое не гарантирует, что предположение соответствует реальному процессу компании. Если такой вопрос не прояснить, неверная логика довольно быстро попадёт не только в код, но и в тесты, интеграции и документацию.</p> <h2>ИИ может быстро оформить требования, но не может сформировать их за бизнес</h2> <p>Меняются и границы ролей внутри команды. Разработчик с помощью ИИ может сам быстрее разобрать исходные материалы, подготовить прототип, черновик требований, описание API или документацию. Меньше времени уходит на рутину и на пересказ одной и той же задачи от одного специалиста другому.</p> <p>Но между оформить требования и сформировать их есть принципиальная разница. Инструменты искусственного интеллекта хорошо структурируют уже имеющуюся информацию. Они могут превратить заметки встречи в список требований, пользовательские сценарии или критерии приёмки. Они же способны заметить противоречия и предложить варианты решения. Но выбрать вариант за бизнес они не могут.</p> <p>Если два подразделения по-разному понимают один процесс, сначала нужно договориться между собой. Если одни и те же данные хранятся в нескольких системах, кто-то должен решить, какая из них считается основной. Если не определено, кто вправе отменить операцию после проведения платежа, более подробная спецификация сама по себе проблему не устранит.</p> <p>Поэтому ИИ снижает трудоёмкость оформления требований, но не снижает автоматически трудоёмкость понимания задачи. На фоне ускорившейся реализации эта разница становится особенно заметной.</p> <h2>Почему быстрый прототип иногда вводит в заблуждение</h2> <p>Заказчики тоже начинают активно использовать ИИ и самостоятельно собирать прототипы: формы, личные кабинеты, небольшие внутренние сервисы. Для проверки гипотез это полезно — рабочий сценарий можно получить быстро и без больших затрат.</p> <p>Но вместе с этим меняется и восприятие самой разработки. Если представитель компании за вечер собрал работающий прототип, у него закономерно возникает вопрос: почему подрядчику на полноценную систему нужны месяцы работы и совсем другой бюджет?</p> <p>Коллеги по рынку уже сталкиваются с такими ситуациями. Топ-менеджер крупной компании самостоятельно собирает прототип личного кабинета, а затем использует этот опыт в переговорах с подрядчиком: если первый результат появился за вечер, что именно занимает столько времени в промышленной разработке? Иногда это становится и аргументом для снижения цены.</p> <p>Проблема в том, что сравниваются разные объёмы работы. В прототипе достаточно показать основной сценарий. В промышленной системе нужно ещё решить, как хранить данные, разграничивать доступ, переживать сбои интеграций, работать под реальной нагрузкой и сопровождать решение после запуска.</p> <p>Поэтому быстрый прототип — не доказательство того, что весь проект прост. Это способ дёшево проверить гипотезу до того, как команда начнёт строить вокруг неё полноценную систему.</p> <h2>Когда ошибка в требованиях действительно становится дороже</h2> <p>Сама по себе высокая скорость разработки не делает ошибку дороже. Иногда всё происходит наоборот: прототип помогает быстро понять, что гипотеза неверна, и отказаться от неё до серьёзных затрат. Риск появляется тогда, когда непроверенное предположение принимают за подтверждённое требование и используют как основу для следующих этапов.</p> <p>Представим, что при автоматизации расчёта неверно определили одно бизнес-правило. На его основе подготовили спецификацию и написали код. Если тесты тоже строятся на той же спецификации, они могут успешно проходить: реализация делает именно то, что в них заложено. Затем та же логика попадает в интеграцию и документацию.</p> <p>При сверке с реальным бизнес-процессом может выясниться, что само исходное правило было неверным. И тогда исправлять приходится уже не одну формулировку в ТЗ, а связанные сценарии, код, тесты, интеграции, а иногда и данные.</p> <p>В этом и заключается новый риск: ИИ способен быстро масштабировать не только правильное решение, но и ошибочное исходное предположение. Цена такой ошибки зависит от того, когда её обнаружили и сколько частей системы уже построено вокруг неверной логики.</p> <h2>Что нужно выяснить до того, как ускорять реализацию</h2> <p>Не всю неопределённость нужно устранять заранее. Расположение элементов интерфейса, тексты, навигацию или отдельные UX-гипотезы часто выгоднее проверить на прототипе.</p> <p>Но есть вопросы, которые не стоит оставлять модели или разработчику на усмотрение. Перед реализацией мы бы рекомендовали проверили пять вещей.</p> <h3>1. Что должно измениться после запуска?</h3> <p>Не просто «нужен личный кабинет», а конкретный результат: например, клиент сможет самостоятельно выполнить операцию, ради которой сейчас обращается к менеджеру.</p> <h3>2. Какие бизнес-правила нельзя трактовать по-разному?</h3> <p>Особенно это касается расчётов, денег, обязательств, прав доступа, согласований и исключений из основного сценария. Команда должна понимать, где она может принять рабочее решение сама, а где любое предположение нужно согласовать.</p> <h3>3. Откуда берутся данные, и кто за них отвечает?</h3> <p>Если одна и та же информация находится в нескольких системах, нужно заранее решить, какая из них считается основной и откуда должны приходить изменения.</p> <h3>4. Где проходят границы системы и какие ограничения влияют на архитектуру?</h3> <p>Важно понимать, что делает новый компонент, а что остаётся на стороне CRM, ERP или других сервисов. Здесь же нужно зафиксировать критичные требования к нагрузке, безопасности, доступности, восстановлению и аудиту.</p> <h3>5. Как будет проверяться результат?</h3> <p>Нужны два уровня проверки. Первый — критерии приёмки: система делает именно то, о чём договорились. Второй — эффект для бизнеса: например, сократилось время операции, исчезла ручная работа или снизилось количество ошибок.</p> <p>Если ответы на эти вопросы остаются неопределёнными, ИИ не устраняет проблему. Он просто помогает быстрее зафиксировать непроверенные предположения в реализации.</p> <h2>Чем быстрее появляется код, тем важнее решения до него</h2> <p>Ускорение разработки меняет не только работу программиста, но и требования к управлению проектом. Чем меньше времени занимает производство очередной версии решения, тем важнее понимать, какие вопросы можно проверить экспериментом, а какие нельзя отдавать в реализацию без однозначного ответа.</p> <p>Для сложной корпоративной системы ценность всё меньше определяется количеством написанного кода. Гораздо важнее вовремя найти противоречие, определить источник данных, договориться о бизнес-правиле или увидеть архитектурное ограничение до того, как вокруг ошибочного решения появятся код, тесты и интеграции.</p> <p>Поэтому главный вопрос для заказчика теперь звучит не только так: как быстро команда сможет реализовать задачу? Не менее важно другое: достаточно ли хорошо мы понимаем задачу, чтобы действительно выигрывать от этой скорости?</p> <p>#IMAGE_235596#</p> Искусственный интеллект ускоряет разработку, но вместе со скоростью растёт цена неверно поставленной задачи. Чем … article Надежда Кадырлеева, исполнительный директор DIGITAL SECTOR https://www.itweek.ru/themes/detail.php?ID=235594 Tue, 22 Sep 2026 16:47:13 +0300 <p>За последние несколько лет российский ИТ-рынок прошёл через глобальные изменения. В новых условиях производители и партнёры — интеграторы, ретейлеры, сервис-провайдеры — ожидают от дистрибьюторов не только услуг по логистике и продажам. Согласно исследованию OCS, самыми востребованными сервисами становятся финансовые услуги, сервисная поддержка и технологическая экспертиза.</p> <p>Аналитики отметили, что наибольший интерес рынок проявляет к финансовым сервисам. Более 22% партнёров и 12% вендоров рассчитывают на расширение услуг в этом направлении. Это связано со спецификой ИТ-отрасли: заказчики нуждаются в сложных технологических решениях, но их разработка требует от производителей значительных вложений с длительным сроком окупаемости. Исследование OCS показало, что каждый четвёртый вендор считает финансовый вопрос главным риском в перспективе ближайших нескольких лет. Ключевая ставка остаётся высокой, а кредиты не доступны для широкого канала. Крупные дистрибьюторы, со своей стороны, предоставляют помощь в проведении расчётов и оформлении коммерческих кредитов для реализации проектов — и спрос на такую поддержку только растёт. </p> <p>Сервисное обслуживание — второе направление, которое становится приоритетным для рынка. По наблюдениям аналитиков, из дополнительной услуги техническая поддержка превратилась в решающий фактор для всех игроков. На наличие такой услуги у дистрибьюторов обращает внимание каждый четвёртый партнёр, а каждый пятый вендор заинтересован в сервисе и обучении по своим продуктам. И производители, и многие партнёры имеют собственные сервисные подразделения, однако ключевой сложностью для рынка остаётся доступность запчастей и обслуживание географически распределённых объектов. Вендоры активно выходят на региональные рынки: по данным OCS, такие планы озвучивает почти четверть российских компаний. Организовать оперативный сервис в разных регионах, поддерживать наличие ЗИП и быстро доставить их в случае необходимости — эти задачи часто берут на себя федеральные интеграторы и ИТ-дистрибьюторы.</p> <p>Потребность в мультивендорной экспертизе также растёт. Сегодня ИТ-инфраструктура заказчиков состоит из множества решений: отечественных, китайских, мировых А-брендов. Импортозамещение набирает темп, однако пока охватывает не все сегменты рынка равномерно. Например, только у 9% компаний российское сетевое оборудование составляет более половины парка. Схожая картина и в направлении серверов и СХД: только половина компаний нарастила долю отечественных решений до 25%. Масштабирование инфраструктуры, обновление и обслуживание оборудования требуют наличия инженерной сертификации по решениям различных производителей. Дистрибьюторы, объединяющие под своим крылом широкий спектр брендов, помогают интегрировать новые продукты в текущую инфраструктуру и заранее протестировать их на совместимость. 63% партнёров и 37% вендоров отметили роль дистрибьюторов в технологических партнёрствах.</p> <p>«Развитие ИТ-рынка сегодня — это симбиоз всех участников. После нескольких лет быстрого роста он достиг определённых пределов: на дальнейшем пути стоит дефицит кадров, ресурсов и технологий. Залогом успеха становится не только скорость принятия решений, но и умение выстраивать надёжные партнёрства. Мы видим, что дистрибьюторы всё чаще играют важную роль в их формировании. Это говорит об уровне доверия со стороны рынка — как к компаниям, так и к их сервисам», — прокомментировала Анна Чернякова, вице-президент OCS. </p> <p>Роль дистрибьюторов давно вышла за рамки стандартных услуг по логистике и продвижению товаров. «Базовые» сервисы всё так же важны: партнёры заинтересованы в вариативных каналах поставок, производители нуждаются в поддержке для освоения новых рынков. Однако требования и запросы рынка растут, и дистрибьюторы отвечают на них, предлагая сервисы, которые помогают игрокам справляться с актуальными вызовами.</p> <p>Интерес к таким услугам, как сервис, финансы и технологическая экспертиза, отражает текущие проблемы производителей и партнёров. Спрос на кредитную поддержку может меняться в зависимости от экономической ситуации. Но потребность в мультивендорной экспертизе и обслуживании комплексных систем в ближайшие несколько лет может стать только острее. В таких сегментах, как сетевое и вычислительное оборудование, доля иностранных решений всё ещё очень высока — и компаниям нужна поддержка для проектирования, аудита и сопровождения инфраструктур. Дистрибьюторы закрывают эти запросы с помощью гибкой экосистемы сервисов и способствуют реализации сложных проектов даже в условиях нестабильности рынка. </p> За последние несколько лет российский ИТ-рынок прошёл через глобальные изменения. В новых условиях производители … message https://www.itweek.ru/themes/detail.php?ID=235592 Tue, 22 Sep 2026 10:25:48 +0300 <p><em>Anthropic утверждает, что написание кода больше не является узким местом. И это так, однако процесс выявления ошибок, допущенных агентом искусственного интеллекта, не может быть универсальным для любых изменений, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Анирудх Раманатхан, технический директор компании Signadot.</em></p> <p>Anthropic недавно опубликовала «плейбук» (стандартизированный сценарий действий) по жизненному разработки ПО (SDLC), ориентированному на ИИ (AI-Native SDLC Playbook). Его ключевой тезис гласит: «Написание кода больше не является узким местом». Когда агенты способны реализовать задачу за считанные минуты, ограничения смещаются на этапы, сопутствующие сборке: планирование, проверку (ревью), верификацию, развертывание и управление процессами.</p> <p>Если организации выстроят работу неверно, возникнет риск появления в десять раз большего числа изменений при прежнем (или даже худшем) качестве каждого из них, причем без возможности выявить неудачные решения. Традиционный подход предполагает, что каждое изменение проверяет человек, но именно этот метод перестает работать при таких объемах.</p> <p>В плейбуке верно определены базовые принципы. Однако упущена важная деталь: процессы в организации имеют свои нюансы. На самом деле это не единый поток, через который проходят все изменения, а совокупность различных процессов, зависящих от конкретной задачи.</p> <h3>Волна инструментов разработки на основе спецификаций</h3> <p>Этот плейбук — часть более широкой волны инструментов разработки, опирающихся на спецификации (например, Amazon Kiro и GitHub Spec Kit). Все они имеют схожую структуру. В основе лежат текстовые артефакты: документ с описанием замысла трансформируется в спецификацию, план, diff (разница в коде) и результаты проверки — и всё это фиксируется в системе контроля версий. Соблюдение правил обеспечивается детерминированными механизмами (например, хуками), а не просто инструкциями в промпте. Агенты сами проверяют свою работу, прежде чем ее увидит человек. При этом окончательное решение об утверждении остается за людьми.</p> <p>Однако каждый из этих инструментов навязывает определенный процесс: фиксированную последовательность этапов и артефактов, через которые проходит любое изменение. Внедрение инструмента означает и принятие соответствующего процесса.</p> <h3>В одной организации выполняется множество процессов</h3> <p>Ни одна реальная организация не работает по единственному процессу. Выбор подходящего процесса зависит от рисков, связанных с изменением, и требуемого уровня ответственности. Исправление документации, обновление зависимостей и миграция схемы данных в платежном сервисе не должны проходить по одному и тому же пути. Для них требуются разные уровни проверки, разные ответственные за утверждение и разные формы отчетности. В регулируемых отраслях сам процесс является частью обязательств по соблюдению нормативных требований: аудиторы требуют наличия записей о том, кто утвердил каждое изменение и на основании каких данных. Состав фиксируемой информации зависит от типа изменения.</p> <p>Если инструмент навязывает единственный вариант процесса, команды находят способы обойти его при внесении изменений, которые не вписываются в заданные рамки. Это худший сценарий, поскольку реальный процесс становится невидимым. Либо же поставщик продолжает усложнять настройки, превращая инструмент в движок рабочих процессов, в котором никто не может разобраться до конца.</p> <p>Инструмент не должен навязывать процесс. Он должен предоставлять организации возможность определить собственный процесс.</p> <h3>Процессы как автоматы состояний</h3> <p>Более удачная модель — определение каждого процесса как автомата состояний (state machine). Состояния отражают факты, касающиеся изменения: например, «проверено», «проверено на соответствие зависимостям», «одобрено для внедрения в продакшен». Эти факты хранятся в различных системах, не принадлежащих какому-то одному инструменту: в репозитории, системе CI, кластере или системе отслеживания задач. Следовательно, процесс не может быть программой, последовательно выполняющей шаги. Это набор правил, реагирующих на информацию, поступающую из указанных систем. Каждое правило определяет:</p> <ol> <li> Факты, необходимые для срабатывания правила.</li> <li> Условие перехода (гейт): автоматическое срабатывание или ожидание одобрения человеком.</li> <li> Разрешение, предоставляемое при срабатывании (например, на слияние веток или развертывание).</li> </ol> <p>Определение процесса представляет собой набор таких правил, хранящихся в виде данных и проходящих ревью подобно программному коду. Организация использует множество небольших автоматов — по одному на каждый класс рисков.</p> <p>В процессе выполнения такая система работает совсем не так, как классический движок рабочих процессов. Ни один компонент не отслеживает текущий этап (например, «мы на четвертом шаге»): процесс продвигается вперед, когда в соответствующей системе появляется новый факт, на который реагируют правила. События, поступившие с опозданием, дублирующиеся или пришедшие после перезапуска системы, обрабатываются так же, как и любые другие, поскольку правила реагируют только на текущее состояние. Гейт является одним из условий правила, поэтому можно приостановить выполнение (например, во время инцидента или заморозки релизов), не меняя при этом само определение процесса.</p> <p>Условия перехода требуют принудительного соблюдения. Если гейт реализован лишь как инструкция, его выполнение зависит от того, будут ли ей следовать. Агентная обвязка может обеспечить детерминизм, необходимый для работы автомата состояний и соблюдения условий перехода, приостанавливая выполнение действий до получения подтверждения, в то время как инфраструктура обеспечивает соблюдение остальных требований.</p> <h3>Процесс адаптируется к изменениям</h3> <p>Одного фиксированного определения процесса для репозитория недостаточно: в этом случае любое изменение проходило бы по одному и тому же пути, независимо от уровня риска. Маршрут изменения должен зависеть от его сути; выбор маршрута определяется классификацией изменения, а не решением автора. Организация выстраивает классификацию на основе имеющихся данных: затронутых путей в коде, репозитория, в котором находится изменение, меток в задаче (issue) и т. д.</p> <p>Сами определения процессов также должны со временем меняться, причем безопасно. Поскольку определение процесса — это данные, его редактирование само по себе является изменением и проходит через собственный регламентированный процесс проверки. Смягчение требований к утверждению этапа выпуска (релиза) рассматривается так же, как миграция схемы данных, а не просто редактируется как файл конфигурации.</p> <p> #IMAGE_235593#</p> <p>Рассмотрим для примера три изменения в одном и том же сервисе:</p> <ul> <li> <strong>Исправление документации</strong> классифицируется на основе затронутых путей. Процесс включает два этапа: успешная сборка и слияние. Участие человека не требуется.</li> <li><strong> Обновление зависимостей</strong> не требует проверки архитектурного решения, но процесс предусматривает подтверждение совместимости: обновленный сервис проходит интеграционные тесты с реальными зависимостями. При переходе на мажорную версию добавляется этап утверждения, отсутствующий при обновлении патч-версии.</li> <li><strong> Миграция схемы данных в платежном сервисе</strong> классифицируется по затронутому компоненту, независимо от того, как заявлено само изменение. Процесс включает дополнительные этапы, отсутствующие в других случаях: проверку владельцем платежного сервиса, валидацию на данных, имитирующих реальную рабочую среду (production-shaped data), и утверждение выпуска ответственным за данную область специалистом.</li> </ul> <p>Каждый переход на любом из маршрутов фиксируется в журнале с указанием того, кто его утвердил и на основании каких данных.</p> <h3>Принципы</h3> <p>Процессы должны строиться на следующих принципах:</p> <ul> <li><strong> Автономия предоставляется для конкретных действий и возрастает со временем.</strong> Для каждого перехода настраиваются автоматическое выполнение, необходимость утверждения или режим ожидания. По мере того как агенты доказывают свою надежность в работе с определенным классом изменений, требования смягчаются; таким образом, процесс адаптируется к улучшениям в работе агентов без необходимости перепроектирования.</li> <li><strong> Внимание человека требуется только там, где необходимо принятие решения, основанное на суждении.</strong> Затраты на работу агентов снижаются, а затраты времени на контроль — нет. Человек подключается к процессу только тогда, когда решение требует экспертной оценки, и получает всю необходимую информацию для быстрого принятия решения.</li> <li><strong> Подтверждающие данные поступают извне, а не от самого агента.</strong> Отчет, сформированный самим агентом, никогда не служит основанием для продвижения изменения на следующий этап. Переходы инициируются на основе фактов, поступающих из систем, в которые агент не может вносить записи (например, результаты тестирования или данные валидации в реальных условиях эксплуатации).</li> <li><strong> Записи о процессе служат журналом аудита.</strong> Описание процесса представляет собой зафиксированный регламент, а журнал переходов фиксирует, кто и на основании каких данных утвердил каждый этап, а также какая версия регламента при этом применялась.</li> </ul> <h3>Обеспечение качества в масштабе</h3> <p>Использование плейбуков и аналогичных инструментов закладывает надежный фундамент. Однако организации также необходима возможность самостоятельно определять процессы, варьировать их в зависимости от уровня риска конкретного изменения и безопасно их совершенствовать. Цель состоит не в том, чтобы исключить человека из процесса принятия решений. Задача — задействовать человеческое суждение лишь там, где это действительно необходимо, опираясь на факты, которые агенты не могут сгенерировать самостоятельно; это позволяет поддерживать высокое качество при многократном росте пропускной способности.</p> Anthropic утверждает, что написание кода больше не является узким местом. И это так, однако процесс выявления ошибок … article https://www.itweek.ru/themes/detail.php?ID=235590 Tue, 22 Sep 2026 10:07:09 +0300 <p>Сегодня каждая вторая дорожная карта ИТ-директора содержит пункт о внедрении ИИ-инструментов для разработки. Ожидания завышены, поскольку аналитики сулят рост производительности на 40%, мгновенное сокращение времени на рутину, выход команд на новый уровень. Однако на практике мы видим иную картину, где пилотные проекты завершены, инструменты закуплены, сделаны большие инвестиции в инфраструктуру, а взрывной трансформации не произошло. Разработчики используют нейросети, но релизы не ускоряются, архитектурные решения не становятся элегантнее, а технический долг не испаряется мгновенно.</p> <p>Заявленные 40% — это миф, но с оговоркой. Да, на отдельной операции по написанию кода ИИ способен дать такое ускорение. Однако программист тратит на написание кода лишь около 30% своего времени. Поэтому общий прирост продуктивности отдельного специалиста редко превышает 10%. Компании ошибочно подменяют системную трансформацию процессов точечной автоматизацией задач, забывая про остальные 70% рабочего времени и контекст enterprise-разработки. Производительность — свойство системы, а не сумма индивидуальных эффективностей.</p> <h2>Ловушка ложных метрик</h2> <p>Первая и фундаментальная ошибка — отсутствие целеполагания и, как следствие, измерение успеха не теми показателями. Сначала нужно определить цель внедрения ИИ в разработку, и уже она должна задавать метрики. Если цель —просто адаптация технологий и соответствие модным веяниям, тогда метрика — процент кода, написанного при помощи ИИ, и количество разработчиков, которые этим пользуются. Но такие метрики ничего не говорят об экономической эффективности и, скорее всего, порождают дополнительные расходы. Если метрика — time-to-market, то при подходе, когда разработчик лишь немного использует ИИ как ассистента, общий time-to-market не улучшается, потому что оптимизация происходит на уровне тех самых 30% написания кода. Даже если ускорить их на 20%, это даст около 6% общего выигрыша — эффект на уровне погрешности. Если речь про экономику, то есть про общую стоимость владения командой разработки, то при таком подходе она, будучи правильно посчитанной, не улучшится: <nobr>5-10%</nobr> эффективности разработчика будут покрыты стоимостью платформы, инфраструктуры, токенов, обучения и дополнительной команды, которая создалась сбоку, чтобы поддерживать разработчиков.</p> <p>Если же говорить о повышении качества кода и удовлетворенности клиентов, то прямой корреляции с использованием ИИ нет. Соответственно, при такой логике — как плагин к старым процессам или примочка к имеющемуся разработчику — эффект в основном получит сам разработчик: ему станет веселее, комфортнее, он получит новую компетенцию. Компания же в целом на своем SDLC-цикле не сможет наблюдать эффект на уровне общеорганизационных показателей.</p> <p>Фокус на активности, а не на результате создает искаженную реальность. У разработчика нет плана по сгенерированному коду — у него план по функциональности. Проблема не в том, что ИИ оставляет шаблонные артефакты как таковые. При внедрении ИИ как плагина к старым процессам эффективность на уровне индивида может вырасти, а пропускная способность команды — остаться прежней или даже упасть. Происходит это потому, что ИИ внедряется как плагин к старым процессам и не является значимым поводом их пересмотреть.</p> <h2>Провал контекста</h2> <p>Вторая причина — фундаментальный разрыв между универсальностью публичных языковых моделей и уникальным контекстом enterprise-разработки. Мощный ИИ, обученный на открытых репозиториях, прекрасно справляется с типовыми задачами и созданием готовых решений с нуля. Но интеграция ИИ в уже существующий ландшафт и имеющиеся процессы, где современные новые системы сочетаются с legacy-архитектурой, спроектированной и созданной <nobr>15-20</nobr> лет назад, крайне затратна.</p> <p>С учетом разнообразия систем и инструментария единообразно внедрить ИИ во все процессы разработки на всех языках и технологиях, которые использует компания, не получится: бэкенд — это один стек, фронтенд — другой, учет и бухгалтерия — третий. Условно пятипроцентный эффект в скорости будет заметен только там, где очень много людей работает на одной и той же технологии, в одном стеке, одной системе — когда их количество измеряется тысячами. Если же на монотехнологии сидят десятки или до сотен человек, достижимый эффект незначителен, а расходы на интеграцию в разные технологические стыки и их связь между собой огромны.</p> <p>Без тотальной перестройки процессов разработки и, возможно, перегенерации целых модулей и даже систем с нуля нужного эффекта не достичь. Это снова смена процесса: мы не даем айтишнику окошко с чатом, где он генерирует себе кусочки кода, а перестраиваем процесс целиком.</p> <h2>Теневая ИИ-экономика разработчиков: симптом системной проблемы</h2> <p>Парадоксально, но на фоне неудач корпоративных программ внедрения процветает теневая ИИ-экономика. Практически все разработчики сегодня в личном порядке используют ChatGPT, Copilot или аналоги для решения рутинных рабочих задач, например объяснения чужого кода, поиска ошибок или мозгового штурма. Со стороны руководства это часто воспринимается как угроза безопасности. И справедливо. Однако борьба с этим явлением запретами стратегически ведет в тупик.</p> <p>Стихийное использование ИИ — четкий сигнал о наличии спроса, который официальные корпоративные инструменты не удовлетворяют. Они оказываются недостаточно интегрированными в рабочий контур (тот же pipeline CI/CD), не адаптированными под внутренние практики или просто неудобными. Запрещая теневые инструменты, компания не решает проблему, а загоняет ее вглубь, теряя контроль над данными и упуская возможность направить энергию команды в управляемое русло. Это классический пример тактики страуса, которую мы уже проходили с облачными сервисами десять лет назад.</p> <h2>Стратегия прорыва</h2> <p>Чтобы изменить эту сомнительную практику, необходим переход от логики внедрения ИИ к логике инжиниринга процессов с ИИ. Это требует трех последовательных действий, основанных на принципе стратегического соучастия, а не запрета.</p> <p>Важно разделять два сценария. Первый — ИИ как персональный ассистент разработчика. Это дает локальный 5-10%-ный эффект, но не меняет систему. Второй — создание автономных ИИ-фабрик, где агенты последовательно проходят весь SDLC-цикл: от анализа требований до приемки. В этом случае меняется ролевая модель команды: люди становятся оркестраторами и архитекторами. Именно второй путь ведет к взрывному росту, но требует перестройки не кода, а процессов. Ниже шаги, которые работают в обоих сценариях.</p> <h3>Шаг 1. Легализация и безопасный канал</h3> <p>Важно сперва признать реальность и создать для разработчиков безопасную, контролируемую среду для экспериментов. Технически это реализуется через корпоративный «гибридный шлюз», единую точку входа для всех ИИ-запросов. Его задача заключается в интеллектуальной маршрутизации: публичные, некритичные запросы идут в одобренные внешние модели, а работа с чувствительным кодом, архитектурой или данными перенаправляется в изолированные, внутренние sandbox-среды. Это немедленно снимает остроту рисков ИБ и, что важнее, дает руководству беспрецедентную видимость того, какие задачи команды пытаются решить с помощью ИИ, где лежат их главные боли.</p> <h3>Шаг 2. Инвестиции в контекст, а не в генерацию</h3> <p>Вместо покупки лицензий на универсальные модели ресурсы должны направляться на создание специализированных ИИ-агентов, встроенных в жизненный цикл разработки. Речь о постепенном внедрении ИИ-агентов в SDLC-процессы — точечных помощников, обученных на вашей собственной кодовой базе, документации и истории, — с последовательным рефакторингом всего процесса SDLC и приучением разработчиков и инженеров к тому, что ИИ-агенты появляются на всех этапах жизненного цикла разработки программного обеспечения.</p> <p>Альтернативным вариантом может быть дизайн SDLC с нуля и постепенный перевод на него отдельных команд и технологий, наиболее пригодных и готовых к внедрению ИИ-агентов в разработку:</p> <ul> <li> Агент для анализа и рефакторинга legacy-кода, понимающий вашу специфику.</li> <li> Интеллектуальный ревьюер, знающий внутренние стандарты и типовые уязвимости домена.</li> <li> Контекстный помощник по архитектуре, способный предлагать решения в рамках утвержденных паттернов.</li> </ul> <p>Именно такие агенты дают измеримый эффект, сокращая время на анализ, снижая количество дефектов и повышая согласованность кода. Их ключевое свойство — обучаемость на основе обратной связи команды.</p> <h3>Шаг 3. Верификация системы измерений, исходя из целеполагания компании</h3> <p>Финансирование и оценка успеха должны быть жестко привязаны не к фиксированному набору метрик, а к целеполаганию компании.</p> <p>Сначала формулируется цель, под нее определяются метрики. Кто-то говорит: «Меня устраивает time-to-market, надо, чтобы все было так же, но дешевле». Кто-то готов тратить в два раза больше, но ускорить вывод продуктов в 10 раз, потому что по бизнесу это позволит зарабатывать гораздо больше и обгонять конкурентов. У кого-то ключевой критерий — трансформация командной разработки и ее реализация, и это считается самостоятельной ценностью; тогда параметры — объем использования и т. п. Поэтому эффективность ИИ должна доказываться влиянием на эти показатели, а не на объем сгенерированного текста.</p> <h2>Производительность как инженерная дисциплина</h2> <p>Миф о 40% развеивается простым, но неудобным выводом: производительность нельзя купить как коробочный продукт. Генеративный ИИ — не волшебная таблетка, а сложный и требовательный компонент, который работает только при перестройке процессов, инвестициях во внутренние компетенции и зрелой культуре данных. Взрывного роста не будет: настоящая эффективность — результат системной инженерной работы, а не единичного внедрения.</p> <p>Будущим технологическим лидерам предстоит не «внедрить ИИ в разработку», а перепроектировать сам процесс разработки, где ИИ становится одним из ключевых инженерных приемов. И здесь критически важно не совершить стратегическую ошибку — не отказаться от джуниоров в пользу ИИ. Молодые специалисты — это инвестиция в кадровый резерв. Их роль меняется: они учатся не столько писать шаблонный код, сколько управлять агентами и контролировать их работу. Трансформация SDLC не отменяет необходимости выращивать собственную экспертизу.</p> <p>Более того, молодые специалисты без большого опыта разработки и доработки систем быстрее схватывают саму идею генерации готовых систем и функциональных блоков с нуля. У них нет груза прежних привычек или он невелик, поэтому они легче принимают мысль, что готовые решения можно генерировать. Разумеется, речь не о больших бизнес-критичных системах. Но внутренняя автоматизация, порталы, борды и другие задачи, на которые раньше не хватало ресурсов или которые оставались недоинвестированными — например, красивый портал проектного управления, — сегодня могут решаться молодыми специалистами гораздо эффективнее. Опытному программисту, привыкшему много писать код, задача генерации внутренних готовых решений часто неинтересна, а молодежь уже создает работающие системы внутренней автоматизации и внутренней эффективности. Реальных примеров много, и поэтому недооценивать джунов в задачах внедрения ИИ в разработку нельзя.</p> <p>Путь к реальному росту производительности лежит не в покупке инструментов, а в соединении инженерной дисциплины, зрелых процессов и ставки на новое поколение специалистов.</p> <p>#IMAGE_235591#</p> Сегодня каждая вторая дорожная карта ИТ-директора содержит пункт о внедрении ИИ-инструментов для разработки. Ожидания … article Сергей Путятинский, эксперт по стратегии, операционной эффективности и технологическим инновациям https://www.itweek.ru/themes/detail.php?ID=235589 Mon, 21 Sep 2026 14:05:09 +0300 <p>«Яндекс» выложил в опенсорс Alice AI Foundation LLM — претрейн-версию своей новой большой языковой модели, обученной полностью с нуля. Модель показывает высокие результаты в программировании и способности к рассуждениям, а по качеству ответов на русском языке превосходит многие мировые аналоги — особенно в задачах на знание фактов, интересных русскоязычной аудитории. Она обгоняет в том числе более крупные опенсорс-модели, не требуя при этом больших вычислительных мощностей для инференса. Разработчики могут использовать её как в исследовательских, так и в коммерческих проектах благодаря свободной лицензии Apache 2.0.</p> <p>Новая модель — это экспериментальная версия, на которой Яндекс тестирует архитектурные решения для своей будущей единой рассуждающей модели (ЕРМ). Рассуждающая модель ляжет в основу агентных возможностей Алисы AI, благодаря которым пользователи смогут поручать ей выполнение конкретных действий. </p> <p>Alice AI Foundation LLM работает на архитектуре MoE (Mixture of Experts) и включает 80 миллиардов параметров, из которых в моменте активны только 3 миллиарда — это обеспечивает исключительную скорость и экономичность её работы.</p> <p>В модель заложены способности к рассуждению и работе в агентных сценариях. За счёт этого она показывает высокую эффективность в сложных логических заданиях и в программировании. Например, на олимпиадных задачах по математике она делит лидерство с Qwen3.5-35B-A3B-Base, решая подавляющее большинство заданий. А в тестах на написание кода превосходит модель компании NVIDIA Nemotron-3-Super-120B-Base — несмотря на то, что использует в четыре раза меньше активных параметров. Качество в ризонинге и программировании — необходимый навык для эффективной работы агентов, способных выполнять действия по поручению пользователя.</p> <p>При компактном размере и меньшей требовательности к вычислительным мощностям новая модель обходит на задачах, где нужны широкие фактические знания, и более крупные открытые модели — например, DeepSeek-V4-Flash-Base с 284 млрд параметров и 13 млрд активных. Бенчмарки для оценки знания фактов показывают, что новая модель отвечает на уровне предыдущей закрытой модели Яндекса Alice AI LLM, у которой в три раза больше параметров и в семь раз больше активных. </p> <p>Для оценки знаний модели, актуальных для русскоязычных пользователей, Яндекс разработал два собственных бенчмарка — WikiWebFacts и HardMultiQA. Первый состоит из пар «короткий вопрос — короткий ответ» и проверяет знание дат, определений, событий и персоналий на основе материалов онлайн-энциклопедий и частотных агрегированных поисковых запросов. Второй, HardMultiQA, построен на основе анонимизированного потока запросов к Алисе AI и охватывает более редкие области знаний: от медицины и права до IT и искусства. В этих задачах недостаточно вспомнить один факт: модель должна выбрать несколько верных вариантов из списка, перечислить сразу несколько фактов, подходящих под условие вопроса, или найти фактическую ошибку в тексте.</p> <p>Новые бенчмарки создавались для оценки русскоязычных знаний модели, так как англоязычные бенчмарки не позволяют оценить их объективно. Оба бенчмарка компания выложила в открытый доступ вместе с моделью, чтобы разработчики и исследователи могли сами воспроизвести результаты и сравнивать между собой любые модели. Вместе с наборами задач компания публикует эталонные ответы и полный протокол оценки.</p> <p>При обучении модели разработчики Яндекса улучшили работу оптимизатора — программы, управляющей процессом обучения. Они перестроили его так, чтобы пересылка данных между видеокартами шла параллельно с вычислениями. Это позволило ускорить шаги оптимизации примерно в два раза.</p> <p>Яндекс также оптимизировал подготовку качественных обучающих данных — для их отбора требовалось оценивать документы с помощью ресурсоёмкой модели. Её запуск на всём корпусе потребовал бы более 200 тысяч часов работы видеокарт. Теперь перед такой оценкой документы проходят через каскад классификаторов. На каждом этапе более сложная и вычислительно затратная модель работает с меньшим количеством документов. Это позволило в десятки раз сократить количество вычислений и при этом сохранить около 95% полезных документов. Кроме того, инженеры значительно обогатили базу знаний модели в области права, медицины и математики. </p> <p>Новая модель предоставляется под лицензией Apache 2.0, что позволяет свободно использовать её в коммерческих и исследовательских целях. Она уже прошла основной этап обучения, от которого зависят ее эрудированность, способности и потенциал. Это позволяет использовать её как основу для создания собственных проектов. </p> «Яндекс» выложил в опенсорс Alice AI Foundation LLM — претрейн-версию своей новой большой языковой модели … message https://www.itweek.ru/themes/detail.php?ID=235588 Mon, 21 Sep 2026 14:03:41 +0300 <p>Портфель российских ИБП Сайбер Электро расширился за счет нового направления оборудования для критической инфраструктуры. Под торговым знаком CyberData бренд представляет специализированные решения для ЦОД. Первой серией новой линейки стала CyberData Prime — трехфазные модульные источники бесперебойного питания с двойным преобразованием энергии мощностью 600, 800 и 1000 кВА.</p> <p>CyberData Prime предназначена для дата-центров, где надежность электроснабжения напрямую влияет на непрерывность работы ИТ-систем и инженерной инфраструктуры. Серия рассчитана на применение на объектах с высокой концентрацией критических нагрузок и повышенными требованиями к отказоустойчивости энергоснабжения.</p> <p>Модульная архитектура позволяет масштабировать систему в соответствии с требованиями объекта и создавать резервированные конфигурации. ИБП поддерживают параллельную работу до восьми устройств и построение систем по схеме N+1, что позволяет повысить надежность электроснабжения при сохранении возможности дальнейшего наращивания мощности.</p> <p>Оборудование поддерживает совместную работу с дизель-генераторными установками, в том числе благодаря алгоритму плавного увеличения входной мощности, снижающему нагрузку на генератор при подключении ИБП. Несколько ИБП могут работать от общего аккумуляторного массива.</p> <p>Серия включает модели CDP-600-K, CDP-800-K и CDP-1000-K, ИБП строятся на модулях номинальной мощностью от 100 кВА. Среди ключевых характеристик — выходной коэффициент мощности 1,0, КПД до 96% и THDi ≤3% при 100% линейной нагрузке.</p> <p>Запуск CyberData Prime становится первым этапом формирования специализированного направления Сайбер Электро для дата-центров.</p> <p>Развитие направления оборудования для ЦОД — стратегический шаг в расширении продуктового портфеля Сайбер Электро. Новый торговый знак объединит решения, рассчитанные на объекты с повышенными требованиями к надежности, масштабируемости и качеству электроснабжения. В дальнейшем под брендом CyberData планируется представить и другие категории оборудования для инфраструктуры дата-центров.</p> <p>Выделение специализированного направления призвано в том числе упростить работу партнеров с продуктовым портфелем. CyberData позволит быстрее ориентироваться в решениях Сайбер Электро, предназначенных именно для ЦОД и других объектов критической инфраструктуры, и формировать на их основе комплексные предложения для заказчиков.</p> <p>«Появление CyberData — это следующий этап развития портфеля Сайбер Электро. Мы видим потребность рынка в специализированных решениях для дата-центров и последовательно расширяем предложение в этом сегменте. Для партнеров важно не только наличие необходимого оборудования, но и понятная структура портфеля, поэтому решения для критической инфраструктуры будут объединены под отдельным торговым знаком», — прокомментировала директор по маркетингу Татьяна Проворова.</p> Портфель российских ИБП Сайбер Электро расширился за счет нового направления оборудования для критической инфраструктуры … message https://www.itweek.ru/themes/detail.php?ID=235587 Mon, 21 Sep 2026 10:21:27 +0300 <p><em>Искусственный интеллект не переписывает правила кибербезопасности — он значительно усиливает привычные атаки. Эдер Рибейро, директор по реагированию на инциденты компании TransUnion, объясняет на портале </em><em>InformationWeek</em><em>, какие угрозы, связанные с ИИ, заслуживают внимания и какие риски по-прежнему доминируют в сфере реагирования на инциденты.</em></p> <p>С учетом того, что ИИ доминирует в заголовках новостей о кибербезопасности (и большинстве других областей), кажется, что он переписал ландшафт угроз. Дипфейки, инъекции промптов, атаки на большие языковые модели и автономные взломы с использованием ИИ говорят о том, что мы, возможно, переживаем важный переломный момент в кибербезопасности.</p> <p>Некоторые из этих угроз реальны, особенно для организаций, активно использующих агентов ИИ. Но этот нарратив часто затмевает более важную реальность: самые большие угрозы, с которыми сталкивается большинство предприятий, исходят не от злоумышленников, взламывающих защиту с помощью новых атак на основе ИИ. Судя по тому, что я вижу в области глобального реагирования на киберинциденты, успешные атаки по-прежнему основаны на знакомых, проверенных тактиках.</p> <p>Наиболее эффективными инструментами в арсенале злоумышленников остаются фишинг, кража учетных данных, выдача себя за другое лицо и социальная инженерия. Отличие заключается в том, что ИИ помогает осуществлять эти атаки быстрее, в бóльших масштабах и с таким уровнем мастерства, которого раньше было сложнее достичь.</p> <p>Понимание разницы между преувеличенными рисками ИИ и угрозами, с которыми команды безопасности сталкиваются каждый день, имеет решающее значение для практического подхода к кибербезопасности.</p> <h3>Отделение реальности от шумихи вокруг ИИ</h3> <p>Несмотря на опасения, что ИИ устранит технические барьеры для киберпреступности, успешные атаки по-прежнему требуют значительных экспертных знаний. Возьмем, например, широко обсуждаемые атаки с инъекцией промптов. Эти атаки включают в себя манипулирование системой ИИ для раскрытия информации или использование вредоносных промптов, чтобы заставить ее выполнять действия, которые она не должна выполнять. Хотя исследователи безопасности продемонстрировали успешные подобные атаки — и организации, внедряющие инструменты ИИ, должны понимать и защищаться от таких рисков — такие атаки не так просты и легки, как может показаться.</p> <p>Манипулирование корпоративными системами ИИ, которые использует большинство организаций, требует времени, доступа к целевой среде и технического уровня, которыми многие злоумышленники не обладают. Организации, применяющие зрелые передовые модели ИИ, получают выгоду от существенных встроенных средств контроля безопасности, предназначенных для ограничения злоупотреблений.</p> <p>Недавние события, такие как июльский инцидент безопасности, связанный с оценочными моделями OpenAI и Hugging Face, демонстрируют, что продвинутые атаки с использованием ИИ не являются чисто теоретическими. Однако сегодня они остаются исключением.</p> <p>Организациям следует бороться с инъекцией промптов без отвлечения внимания от уязвимостей в системе идентификации и доступа, лежащих в основе большинства успешных инцидентов.</p> <h3>Те же угрозы, но усиленные</h3> <p>Новые методы атак с использованием ИИ, такие как инъекция промптов, привлекают внимание, потому что они новые и тревожные. По сравнению с ними программы-вымогатели кажутся чем-то из прошлого. Тем не менее, несмотря на более чем 15 лет борьбы с ними, программы-вымогатели остаются одной из самых разрушительных и дорогостоящих киберугроз, с которыми сталкиваются организации.</p> <p>Малые и средние предприятия остаются частыми целями программ-вымогателей, потому что их режимы резервного копирования данных часто менее частые или менее тщательные. Хотя некоторые злоумышленники могут хвастаться использованием ИИ — часто в качестве психологической тактики — основные методы эффективных атак с использованием программ-вымогателей хорошо известны: фишинг, кража учетных данных или социальная инженерия, сбор учетных данных, латеральное перемещение и запуск вредоносного ПО.</p> <p>Программы-вымогатели могут считаться чем-то устаревшим, но их атаки по-прежнему наносят ущерб организациям.</p> <p>Аналогично, по-прежнему распространена компрометация корпоративной электронной почты. Доступные инструменты, такие как фишинговые наборы, позволяют даже начинающим злоумышленникам присылать убедительные фишинговые письма, которые направляют получателей на поддельные страницы входа, предназначенные для кражи учетных данных. Оказавшись внутри, они могут отслеживать активность, ожидая подходящего момента для перехвата управления и получения выгоды.</p> <p>ИИ доказал свою исключительную ценность как инструмент для ускорения, масштабирования и значительного повышения убедительности традиционных атак.</p> <h3>Где ИИ создает реальные широкомасштабные проблемы</h3> <p>Если и есть область, где ИИ явно меняет ландшафт угроз, то это социальная инженерия. Человеческий фактор остается одной из наиболее уязвимых аспектов системы безопасности организации.</p> <p>ИИ способен создавать практически нераспознаваемые фишинговые электронные письма и мошеннические веб-сайты. Агенты ИИ могут генерировать реалистичные поддельные документы и персонализированные сообщения с минимальными усилиями, позволяя злоумышленникам быстро адаптировать сообщения для конкретных отраслей или целей. Если злоумышленники уже взломали систему электронной почты, они будут знать, когда отправить идеально рассчитанный мошеннический запрос на оплату.</p> <p>Технология дипфейков еще больше расширила эти возможности, поскольку сообщения, которые выглядят и звучат аутентично, убедительно имитируют руководителей, сотрудников и деловых партнеров.</p> <p>Организациям следует развивать свои программы повышения осведомленности, выходя за рамки традиционных тревожных сигналов, таких как подозрительный язык или несоответствие доменов отправителей. Им необходимо следовать установленным процедурам утверждения, особенно для финансовых транзакций.</p> <h3>Угроза ИИ не ограничивается атакой</h3> <p>Еще одна возникающая проблема — это роль, которую ИИ играет после того, как злоумышленник получает легитимный доступ к сети, часто с помощью украденных учетных данных. Все чаще корпоративные агенты ИИ предоставляют злоумышленникам потенциальный путь к системам знаний, которые агрегируют информацию по всей организации.</p> <p>Злоумышленники, использующие доверенных ИИ-агентов («<strong>Living‑off‑the‑Agent», LoTA)</strong>, могут взаимодействовать с агентами корпоративной платформы ИИ в качестве авторизованного пользователя, задавая вопросы и находя конфиденциальные данные. Такие атаки особенно сложны, поскольку их действия часто неотличимы от легитимного поведения пользователя. Злоумышленник не использует уязвимость в платформе ИИ; он использует уже имеющийся доступ.</p> <h3>Риски, связанные с использованием ИИ сотрудниками</h3> <p>Наконец, особую обеспокоенность вызывает несанкционированное использование ИИ сотрудниками. В этом году 63% из 2000 респондентов <a href="https://www.blackfog.com/blackfog-research-shadow-ai-threat-grows/">опроса</a> BlackFog о теневом ИИ сообщили, что считают допустимым использование инструментов ИИ без одобрения работодателя, если нет санкционированного компанией варианта, при этом 58% используют менее безопасные бесплатные версии.</p> <p>Проблема в том, что организации не могут контролировать инструменты ИИ, о которых они не знают.</p> <p>Когда сотрудники вводят конфиденциальную внутреннюю информацию или бизнес-данные в несанкционированные платформы ИИ, они непреднамеренно создают новые точки уязвимости. Из-за широкого распространения теневой ИИ представляет собой более непосредственный и практический риск, чем любая сложная эксплойт-атака на основе ИИ.</p> <p>Четкое определение политики использования ИИ сотрудниками и поддержание видимости ИИ в масштабах всей организации должны быть частью любой стратегии управления ИИ.</p> <h3>Сосредоточьтесь на том, что действительно важно</h3> <p>ИИ трансформирует ландшафт кибербезопасности. Но для большинства организаций наибольшие риски не связаны с тем, что привлекает внимание руководителей или попадает в заголовки отраслевых новостей.</p> <p>Большинство успешных инцидентов по-прежнему начинаются с компрометации личных данных, фишинговых кампаний, слабого контроля доступа и человеческой ошибки.</p> <p>Организации по-прежнему могут повысить свою устойчивость, укрепляя безопасность идентификационных данных, внедряя надежную многофакторную аутентификацию, повышая устойчивость к фишингу и осознанно подходя к развертыванию ИИ. Будущее кибербезопасности будет связано с ИИ, но устранение рисков, которые злоумышленники используют сегодня, остается основой надежной стратегии безопасности.</p> Искусственный интеллект не переписывает правила кибербезопасности — он значительно усиливает привычные атаки. Эдер … article https://www.itweek.ru/themes/detail.php?ID=235585 Mon, 21 Sep 2026 10:09:58 +0300 <p><em>Рассмотрим пять элементов расчета, без которых ROI ИИ остается догадкой.</em></p> <p>Компания, которая покупает новый станок, считает срок его окупаемости до подписания контракта. Она знает стоимость станка, сколько единиц продукции он даст в месяц и через сколько месяцев вложение вернется. Компания, которая нанимает сотрудника, считает его стоимость в год и ожидаемый вклад в выручку заранее, до оффера. С ИИ так происходит редко. Решение принимается по демонстрации, по обещанию прироста производительности, по примеру конкурента, и уже потом, через год, кто-то пытается понять, окупилось это или нет.</p> <p>Инвестиция в ИИ отличается от инвестиции в станок по своей природе: станок не меняет поведение после установки, а модель дрейфует и требует переобучения. Но требования к расчету окупаемости у них должны быть одинаковыми. Дисциплина расчета, которую применяют к активу, определяет результат сильнее, чем сам актив. Если применить к ИИ ту же процедуру, что и к любому капитальному вложению, часть решений о внедрении просто не пройдет. Это тоже правильный результат.</p> <p>Расчет начинается с базовой операции. Нужно зафиксировать состояние процесса до внедрения: какой именно процесс меняется, в каких единицах измеряется его выпуск, сколько он стоит компании сейчас. Без этой точки отсчета любой процент прироста после внедрения превращается в цифру, которую невозможно проверить. Компания может отчитаться о росте производительности на треть, но если никто не зафиксировал производительность до старта, эта треть взята из воздуха.</p> <p>Дальше идет стоимость внедрения. Ее часто считают неверно, если путают два разных вида затрат. Капитальные затраты включают интеграцию, настройку процессов и обучение команды. Операционные затраты включают лицензии, вычислительные мощности и сопровождение. Горизонт возврата у них разный. Компании часто принимают стоимость пилота за ориентир для всего портфеля процессов, и это ошибка. Пилот на одной команде почти всегда дешевле на человека, чем тиражирование на пятьдесят команд, потому что поддержка, лицензирование и обучение растут не пропорционально числу пользователей.</p> <p>Срок эффекта редко считают верно. Именно этот показатель чаще всего подделывают ради красивого ROI: по моему опыту, инвестиционному комитету показывают цифры адаптационного периода вместо стационарного, потому что они выглядят эффектнее в презентации. У периода внедрения и стационарного периода разная экономика. В период внедрения производительность может даже просесть: команда осваивает инструмент, перестраивает привычные операции, тратит время на ошибки. Устойчивый эффект появляется позже, в стационарном периоде, когда практика уже закреплена. Именно он и имеет экономический смысл.</p> <p>У рисков простое правило: прирост засчитывается, только если качество не ухудшилось против базового уровня. Ускорение процесса ценой роста ошибок, возвратов в работу или потери контроля просто переносит издержки на более поздний срок. Отдельная опасность: пилот без развилки живет годами и не дает компании ничего, кроме привычки к пилоту. У любого пилота должен быть срок, после которого принимается одно из двух решений: масштабировать или закрыть.</p> <p>Масштабирование почти никогда не работает по прямой: предел эффективности у каждого процесса определяют именно его слабые места. Плохие данные в одной команде тормозят автоматизацию раньше, чем возможности модели. В другой команде тормозит сопротивление людей новому порядку работы, и эффект теряется на этапе внедрения раньше, чем дело доходит до модели. В третьей команде объем операций в разы меньше, чем у пилотной группы, и фиксированная часть затрат просто съедает большую долю эффекта. Если просто перенести цифры одного успешного пилота на весь портфель без поправки на эти различия, результат окажется завышен заранее.</p> <p>Приведу условный пример: пилот по автоматической сверке первичных документов в закупках дал заметное ускорение обработки заявок, но одновременно вырос процент ручных исправлений после автосверки, и по факту чистого эффекта не набралось. Не раз останавливал похожие ИИ-пилоты, которые всем нравились, но не проходили этот расчет. И наоборот, доводил до масштабирования на портфель инициативы, где результат на пилоте выглядел скромно, а расчет на стационарном периоде показывал устойчивый эффект.</p> <p>Свести все элементы вместе должен тот же орган, который утверждает любую капитальную инвестицию: инвестиционный комитет или его аналог. У него уже есть форма для станка и форма для найма команды. У капитальной инвестиции есть еще один элемент, который для ИИ обычно выпадает: план-факт контроль после сделки и ответственность за отклонение. Если через год факт разошелся с расчетом, который лег в основу решения, кто-то должен объяснить разрыв на том же комитете, где утверждали инвестицию, вместо того чтобы тихо закрыть проект новой инициативой. Без этой части весь расчет до сделки превращается в красивую формальность.</p> <p>#IMAGE_235586#</p> Рассмотрим пять элементов расчета, без которых ROI ИИ остается догадкой. Компания, которая покупает новый станок, считает … article Станислав Ежов, директор по развитию ИИ, ПАО “Группа Астра” https://www.itweek.ru/themes/detail.php?ID=235580 Fri, 18 Sep 2026 14:05:12 +0300 <p>Компания «Флант» объявила о крупнейшем обновлении продуктовой линейки: Deckhouse Kubernetes Platform, Deckhouse Virtualization Platform и Deckhouse Commander объединены в единый продукт — Deckhouse Platform. Новая платформа предназначена для построения гибридной инфраструктуры и единого управления любыми нагрузками — контейнерами, виртуальными машинами, ИИ-сервисами и данными — на любом сочетании облачных и локальных ресурсов.</p> <p>Deckhouse Kubernetes Platform (DKP) известна рынку с 2017 года, однако за это время она перестала быть платформой только для контейнеров. Вопреки ожиданиям начала <nobr>2020-х,</nobr> контейнеризация не вытеснила виртуализацию — обе технологии остались в production-ландшафтах, и управление ими из одного оркестратора превратилось из эксперимента в отраслевой стандарт. Именно это определило вектор развития: DKP выросла в продукт нового поколения, рассчитанный на гибридные ландшафты, где контейнеры, виртуальные машины, ИИ-сервисы и данные управляются из одной точки. </p> <p>Deckhouse Platform — это принципиально новый продукт, объединивший три самостоятельных решения: платформу для контейнеров, платформу для виртуализации и систему управления мультикластерной инфраструктурой. Единый control plane, общая система безопасности и наблюдаемости — формула нового продукта: «Любые нагрузки. Любая инфраструктура. Одна платформа».</p> <p>«Современные компании вынуждены постоянно выбирать: виртуальные машины или контейнеры, облако или on-prem, Open Source или готовая платформа, Infrastructure as Code или ИИ, скорость или безопасность, — и каждый такой компромисс стоит времени и денег. Нам в Deckhouse удалось объединить виртуальные машины и контейнеры, облака и on-prem, инфраструктуру как код и ИИ-агентов, а также управляемые сервисы, сети и storage, обеспечив стандартизацию, безопасность, надёжность и очень большую гибкость, а значит — дать компаниям возможность развиваться быстрее и быть первыми», — подчеркнул Давид Мэгтон, технический директор и соучредитель компании «Флант».</p> <p>Платформа предлагает семь готовых сценариев использования, которые охватывают основные задачи современных технологических ландшафтов.</p> <p>Первые три сценария закрывают базовые потребности в вычислительной инфраструктуре. Для контейнеров — кластер за считаные минуты, а не месяцы, SLA выше 99,99 % и встроенное соответствие требованиям регуляторов. Для виртуализации — простое управление ВМ-инфраструктурой и миграция с зарубежных продуктов, включая сертификацию ФСТЭК России. Для комбинированных нагрузок — контейнеры и виртуальные машины под одним control plane с единым пакетом документов ФСТЭК России на всю среду.</p> <p>Следующие сценарии расширяют платформу на работу с данными, ИИ и облачными моделями потребления. Для ИИ — GPU как ещё один ресурс в общем пуле рядом с CPU и памятью, запуск ИИ-сервиса за часы, а не кварталы, данные внутри контура компании и до 30 % экономии на оборудовании за счёт оптимизации GPU. Для данных — единый слой хранения, интеграция с внешними СХД и управляемые сервисы по запросу: PostgreSQL, ClickHouse, Airflow, брокеры сообщений, кеши. Для частного облака — ресурсы по кнопке, а не по тикету и прозрачная экономика по проектам и продуктам: квоты, потребление, стоимость.</p> <p>Наконец, Deckhouse Platform для распределённой гибридной инфраструктуры, усиленная ИИ, собирает весь ландшафт — собственный ЦОД, арендованную площадку, публичное облако, edge — в одну систему с единым control plane на все площадки для создания ресурсов, поиска аномалий и устранения ошибок.</p> <p>Все семь решений формируются из ядра Deckhouse Platform Core — минимальной неделимой основы для запуска контейнеров и виртуальных машин — и 14 совместимых расширений: по работе с данными, управлению гибридной инфраструктурой, информационной безопасностью, сетевыми возможностями и ресурсами ML/AI. Заказчик покупает только то, что нужно сейчас, и расширяет платформу по мере роста — вместо нескольких стеков и команд на ВМ и контейнеры компания получает одну ответственность вендора и единый SLA на весь контур.</p> <p>Deckhouse Platform сохраняет приверженность открытому коду — пользователям доступна бесплатная редакция Deckhouse Platform Open для самостоятельного развёртывания. Сегодня инженеры «Фланта» занимают первое место в России по объёму контрибуций в международные проекты CNCF.</p> <p>«Любая бизнес-задача живёт в условиях ограничений — времени, ресурсов, денег, масштаба. Крупное технологическое обновление в первую очередь о том, что теперь можно решать задачу иначе, выходить из этих ограничений. В Deckhouse Platform функциональность накапливается от обновления к обновлению — за прошлый год вышло больше 10 версий платформы, и компании могут использовать новые функции и сценарии, сохраняя уже сделанные инвестиции, при этом обновление будет бесшовным. Это модель непрерывного накопления ценности: без лишних затрат на пересборку среды, с управляемым и прозрачным TCO», — отметил Александр Титов, генеральный директор компании «Флант».</p> <p>Помимо Deckhouse Platform, компания развивает линейку совместимых продуктов. Deckhouse Observability обеспечивает централизованную наблюдаемость всей инфраструктуры и приложений, Deckhouse Development Portal позволяет управлять всеми этапами разработки новых сервисов и продуктов, Deckhouse Stronghold отвечает за безопасное управление жизненным циклом секретов, а Deckhouse Code — за непрерывную разработку и управление жизненным циклом ПО. Все продукты интегрированы между собой и с платформой — не нужно тестировать совместимость и тратить ресурсы на подключение сторонних решений.</p> <p>«Многие сталкивались с ситуацией, когда команда разработки создаёт цифровой продукт за пару месяцев, а клиенты получают к нему доступ лишь спустя год. Эту разницу во времени съедает инфраструктура: долгие согласования, ручная настройка кластеров и бесконечные обновления. За это время конкуренты успевают занять рынок. Deckhouse Platform возвращает это время: кластер поднимается за считаные минуты, а команды могут выпускать релизы в день написания кода. Платформа берёт на себя автоматическое масштабирование под любые пики нагрузки, обеспечивает SLA выше 99,99 % и уже „из коробки“ закрывает все ключевые требования регуляторов и информационной безопасности», — считает Карапет Манасян, директор продуктовых направлений Deckhouse, «Флант».</p> <p>Дорожная карта развития Deckhouse Platform включает развитие маркетплейса приложений с установкой в один клик, новые управляемые сервисы для хранения и обработки данных, углубление ИИ в процессы — от развёртывания инфраструктуры до создания модулей — развитие системы хранения с гибридным размещением и автоматическим распределением данных между уровнями, а также сертификацию ФСТЭК России для новых возможностей платформы.</p> <p>Сегодня под управлением платформы находится более 1300 кластеров, которые эксплуатируют свыше 260 компаний. Кластер Kubernetes поднимается в среднем за 15 минут, время вывода продукта на рынок сокращается на 23 %, а TCO за пять лет оказывается ниже на 27 % по сравнению с самостоятельно собранной платформой. На опыте реальных внедрений подтверждено, что двух инженеров достаточно для обслуживания 170+ кластеров и 1000+ виртуальных машин. Продукт имеет сертификат ФСТЭК России № 4860 от 04.10.2024 и запись в реестре российского ПО № 12338. Платформу уже эксплуатируют такие компании, как «Газпром нефть», «Лемана ПРО», ОТП Банк, «ЭР-Телеком Холдинг», «Альфа-Лизинг», Mindbox, а также Казначейство России, Банк России, ФГБУ «Росгеолфонд».</p> Компания «Флант» объявила о крупнейшем обновлении продуктовой линейки: Deckhouse Kubernetes Platform, Deckhouse … message https://www.itweek.ru/themes/detail.php?ID=235579 Fri, 18 Sep 2026 14:02:50 +0300 <p>Компания «Лаборатория Виртуализации» выпустила версию 3.0.0 платформы Inscale — российского решения для серверной виртуализации и инфраструктуры виртуальных рабочих столов (VDI). Релиз развивает платформу в трёх направлениях: централизованное управление доступом, эксплуатация распределённой инфраструктуры и качество пользовательских сессий. Продукт включён в Единый реестр российских программ Минцифры (запись № 28671).</p> <p>Главное изменение версии — новая модель распределения ресурсов на основе групп доставки (Delivery Groups). Раньше права и параметры назначались на уровне отдельных пользователей и пулов, и с ростом инфраструктуры конфигурацию становилось сложнее сопровождать и проверять. Теперь группа доставки объединяет в одной точке пользователей, доступные им рабочие столы и пулы, политики безопасности и профили подключения. При назначении пользователю рабочего стола или пула нужные параметры применяются автоматически.</p> <p>Расширена интеграция с каталогами Active Directory и LDAP: администратор может задавать дополнительные атрибуты поиска — например, табельный номер или адрес электронной почты — и назначать права доступа к VDI заранее, до появления учётной записи в системе. После синхронизации каталога назначения применяются автоматически, что сокращает ручные операции при подключении новых сотрудников. Добавлена блокировка локальных учётных записей без их удаления — для временной приостановки доступа или реагирования на инцидент.</p> <p>Для эксплуатации появилась единая панель мониторинга со сводными данными по кластерам в реальном времени. Через систему управления теперь можно удалённо перезапускать сервисы платформы, получать их журналы и автоматически собирать диагностические данные для технической поддержки. Групповые операции позволяют за одно действие изменить уровень журналирования на всех узлах кластера.</p> <p>В настройках виртуальных машин стал доступен выбор шины и типа виртуального диска, а шифрование дисков при создании образа сделано опциональным — для инфраструктур, где данные уже защищены на уровне системы хранения. Обновлён клиент подключения: пользователь видит понятные индикаторы состояния сессии при потере сети и повторном подключении. Улучшены алгоритмы сжатия протокола доставки рабочего стола, повышена надёжность работы с хранилищами по iSCSI и обработка недоступных шлюзов в профилях подключения.</p> <p>Отдельный блок релиза посвящён отказоустойчивости: устранены проблемы с неактивными участниками во внутренних кластерах баз данных, автоматическая очистка хранилища продолжает работать при недоступности одного из серверов кластера, статус виртуальной машины после принудительного выключения обновляется сразу.</p> Компания «Лаборатория Виртуализации» выпустила версию 3.0.0 платформы Inscale — российского решения для серверной … message https://www.itweek.ru/themes/detail.php?ID=235578 Fri, 18 Sep 2026 14:01:04 +0300 <p>Технологическая компания YADRO (входит в ИКС Холдинг) представила обновленную конфигурацию ИИ-сервера G4208P G3 для корпоративных проектов. Новая версия поддерживает до восьми GPU мощностью до 600 Вт каждый и вдвое увеличивает плотность вычислений. Сервер рассчитан на ресурсоемкие задачи обучения, дообучения и инференса современных ИИ-моделей.</p> <p>Рост производительности современных GPU повышает требования ко всей серверной платформе и условиям ее эксплуатации. В обновленном G4208P G3 усилены подсистемы питания и охлаждения, благодаря чему полная конфигурация может работать при температуре входящего воздуха до 30 °C. Для заказчиков это расширяет возможности размещения ИИ-оборудования в существующей инфраструктуре ЦОД и снижает объем дополнительных требований к подготовке площадки. </p> <p>G4208P G3 поддерживает ускорители разных классов и производителей. Конфигурацию можно подбирать с учетом модели, программного стека, профиля нагрузки и бюджета проекта. Одна платформа подходит для разных ИИ-сценариев и позволяет наращивать вычислительные ресурсы по мере роста нагрузки. </p> <p>YADRO также проводит прикладные исследования и тестирование на реальных ИИ-нагрузках, публикуя результаты измерений с описанием конфигураций, методик и условий тестирования. Заказчики могут заранее сравнивать варианты по производительности, задержкам и стоимости вычислений и быстрее переходить к проверке конфигурации на своей нагрузке. </p> <p>«Корпоративные ИИ-проекты становятся масштабнее, и вместе с ними растут требования к вычислительной инфраструктуре. При развитии G4208P G3 мы ориентировались на реальные условия эксплуатации в ЦОД, возможность выбирать конфигурацию под конкретную нагрузку и дальнейшее масштабирование инфраструктуры по мере роста задач», — отметил Михаил Михеев, директор по серверным продуктам YADRO.</p> <p>Обновленная конфигурация расширяет возможности компаний по развитию собственной ИИ-инфраструктуры — от отдельных вычислительных узлов до GPU-кластеров.</p> Технологическая компания YADRO (входит в ИКС Холдинг) представила обновленную конфигурацию ИИ-сервера G4208P G3 для … message https://www.itweek.ru/themes/detail.php?ID=235577 Fri, 18 Sep 2026 13:56:43 +0300 <p>Компания Avanpost, разработчик решений для безопасности идентификационных данных и управления доступом, обновила Avanpost SmartPAM, продукт для управления привилегированным доступном, до версии 1.4. В новой версии добавлена библиотека из 60 сигнатур, структурированных по категориям матрицы техник атак MITRE ATT&CK для обнаружения и реакции на угрозы внутри привилегированных сессий. Библиотека доступна заказчикам по подписке и будет регулярно пополняться. До конца 2026 года подписка на библиотеку бесплатна.</p> <p>«Обновление поддерживает выбранный Avanpost вектор развития SmartPAM: от защиты доступа к непрерывному и многоуровневому анализу действий привилегированных пользователей, выявлению и своевременному реагированию на угрозы. При росте масштабов компрометации учетных данных, инсайдерских рисков, человеческих ошибок недостаточно лишь контроля входа и фиксации действий. Объектом контроля становится не только идентичность, но и каждое действие, совершаемое с ее полномочиями», — отметил Сергей Померанцев, владелец продукта Avanpost SmartPAM. </p> <p>Avanpost SmartPAM стала первой PAM-системой с библиотекой сигнатур по матрице MITRE ATT&CK. Сигнатура — это правило или совокупность правил, которые позволяют PAM-системе идентифицировать известную угрозу. Готовые сигнатуры используются движком сигнатурного анализа Avanpost SmartPAM. Он обрабатывает, нормализует и анализирует события привилегированной сессии и при необходимости формирует ответную реакцию: блокировку команды или пользователя, разрыв сессии, отправку уведомления в SIEM и тд. </p> <p>Библиотека сигнатур по матрице MITRE ATT&CK охватывает разные тактики и техники атак, включая получение учетных данных, закрепление в системе, горизонтальное перемещение, уклонение от обнаружения и другие. В частности, новые сигнатуры идентифицируют отключение служб аудита операционной системы, антивирусной защиты или межсетевого экрана , очистку системных журналов, маскирование команд. Компании могут сочетать готовые сигнатуры с собственными правилами и настраивать политики безопасности с учетом своих ИБ-приоритетов и особенностей инфраструктуры.</p> Компания Avanpost, разработчик решений для безопасности идентификационных данных и управления доступом, обновила Avanpost … message https://www.itweek.ru/themes/detail.php?ID=235576 Fri, 18 Sep 2026 10:48:39 +0300 <p><em>Искусственный интеллект уже работает в вашем бизнесе — зачастую незаметно. Прежде чем вы сможете им управлять, вам нужно увидеть, где он работает. Видимость — на первом месте, пишет на портале </em><em>InformationWeek</em> <em>Дуг Пикл, президент Global Data Systems.</em></p> <p>Я провожу много времени в залах, полных генеральных директоров, и мне нравится задавать простой вопрос: «Работает ли ИИ внутри вашей организации?» Почти все поднимают руки.</p> <p>Затем я задаю следующий вопрос: «Где?» И в зале воцаряется тишина.</p> <p>Этот разрыв между знанием о наличии ИИ и знанием о том, где он работает, — одна из самых дорогостоящих слепых зон, которые я вижу в современном бизнесе.</p> <p>Большинство руководящих команд считают, что разговор об ИИ начинается и заканчивается инструментами, которые их сотрудники сознательно внедрили: ChatGPT, открытый во вкладке браузера, пилотный проект Copilot для одной команды. Реальная уязвимость редко проявляется именно там. Реальный риск исходит от скрытого ИИ — систем, уже встроенных в вашу инфраструктуру.</p> <p>ИИ уже интегрирован в инфраструктуру, платформы повышения производительности и совместной работы, приложения CRM, стек безопасности и бизнес-приложения, которые вы используете уже много лет. Это проявляется в обновлениях от поставщиков, внедрении новых функций и настройках по умолчанию. В большинстве компаний никто это не одобрял.</p> <h3>Скрытый ИИ начинается с одного человека</h3> <p>В большинстве компаний внедрение ИИ уже опережает политику, призванную его регулировать. Этот скрытый ИИ используется сотрудниками для обобщения документов, анализа электронных таблиц и автоматизации задач, потому что это упрощает работу. Руководство предполагает, что внедрение происходит в рамках утвержденных проектов. Это не так. Оно начинается с одного человека, задолго до того, как достигнет какой-либо панели управления или инициирует пересмотр какой-либо политики.</p> <p>Именно здесь формируется реальный риск. Технологические риски, такие как безотказность, установка обновлений и контроль доступа, хорошо известны. ИИ — это другое дело. Он может влиять на решения, генерировать контент, получать доступ к конфиденциальной информации и автоматизировать процессы быстрее, чем любой человек может это контролировать. Если вы не знаете, где работает ИИ, вы не можете контролировать то, что он производит. Если оставить это без внимания, этот пробел превращается в риск нарушения нормативных требований, риск нарушения интеллектуальной собственности, и в конечном итоге возникает вопрос: когда процесс, управляемый ИИ, вызывает проблему, кому он принадлежит? Компании, которые ответят на этот вопрос до того, как он будет задан, будут двигаться быстрее и с меньшим риском, чем те, кто разбирается в этом постфактум.</p> <h3>Ни один отдел не может полностью отвечать за управление ИИ</h3> <p>Управление ИИ не является прерогативой одной функции. Чем больше вы пытаетесь передать это одному подразделению, тем меньше это работает. Служба безопасности должна знать, где находится риск. ИТ-отдел должен знать, к каким системам теперь прикасается ИИ. Руководители отделов данных и соответствия нормативным требованиям отвечают за управление информацией. Финансовый отдел должен знать, сколько средств тратится и что из этого окупается. Решения в области технологий раньше удобно принимались внутри ИТ-отдела, но ИИ перерос эту модель. Организации, добивающиеся реального прогресса, рассматривают управление как общую ответственность руководства, а не как проблему одного руководителя.</p> <p>Хорошее управление обеспечивает три вещи: видимость того, где используется ИИ, ответственность за результаты, которые он производит, и возможность действовать на основе и того, и другого. Руководство знает, где работает ИИ. Сотрудники знают, что допустимо, им это объяснили простым языком. Конфиденциальная информация защищена уже на этапе проектирования, доступ осуществляется целенаправленно, а результаты измеряются, а не предполагаются.</p> <p>Помните: управление не направлено на замедление внедрения. При правильном подходе оно позволяет ускорить внедрение с уверенностью. Команды работают быстрее, когда ограничения понятны, а не когда они гадают, где проходит граница.</p> <h3>Начните с видимости ИИ, а не со стратегии</h3> <p>Когда я обмениваюсь мнениями с другими руководителями высшего звена, обсуждение почти всегда начинается с технологий. Речь идет о том, какие инструменты внедрять, какие платформы оценивать. В конце содержательного разговора мы обсуждаем операционные модели, права принятия решений, ответственность и управление изменениями. Вопрос смещается с «Какой ИИ нам следует внедрить?» на «Как подготовить организацию к эффективному использованию ИИ?».</p> <p>Именно здесь начинается настоящая работа, и именно к этому большинство компаний наименее готовы, потому что это требует, чтобы инфраструктура, управление и операции работали как единая система, а не как набор отдельных решений.</p> <p>Если вы генеральный директор и задаетесь вопросом, с чего начать, первый шаг — это не обсуждение бюджета или составление дорожной карты. Вам нужен ответ на один прямой вопрос: где ИИ уже работает внутри нашей организации сегодня? Не куда его планируется внедрить, не что указано в дорожной карте на следующий год. Речь идет о том, что происходит прямо сейчас, во всех системах, с которыми взаимодействуют ваши сотрудники.</p> <p>Большинство команд, которые честно задают этот вопрос, обнаруживают, что масштабы воздействия оказались больше, чем они ожидали. Скрытый ИИ накапливался годами. Прежде чем вы сможете управлять ИИ, обеспечивать его безопасность или масштабировать его целенаправленно, вам необходимо получить честное представление о том, где вы уже находитесь. ИИ — это не будущая инициатива; он уже работает внутри вашего бизнеса и внутри инструментов, на которые ваши сотрудники полагаются каждый день, независимо от того, составили вы карту его использования или нет.</p> <p>Организации, которые целенаправленно создают видимость, управление и инфраструктуру для управления ИИ, превратят его в измеримое преимущество. Те, кто этого не делает, потратят следующие несколько лет на то, чтобы на собственном горьком опыте узнать, где он все это время работал.</p> Искусственный интеллект уже работает в вашем бизнесе — зачастую незаметно. Прежде чем вы сможете … article https://www.itweek.ru/themes/detail.php?ID=235574 Fri, 18 Sep 2026 10:40:15 +0300 <p>Ошибка при работе с реальным объектом может привести к простою линии, перегрузке сети, дополнительным расходам или дорогостоящему пересмотру уже принятого решения. Цифровой двойник позволяет сначала протестировать сценарий на данных и только потом переносить его в физический мир. Однако такой подход работает только при условии, что модель получает актуальные, полные и согласованные данные. Разберёмся, что корректно называть цифровым двойником, в каких задачах технология уже даёт практический эффект и почему такие проекты чаще упираются не в математику, а в данные.</p> <h3>Что считать цифровым двойником</h3> <p>Термин «цифровой двойник» за последние годы заметно расплылся. Им называют и BIM-модель (Building Information Modeling, цифровое представление сооружения, в котором каждый элемент обладает не только геометрией, но и набором данных) здания, и экран мониторинга станка, и симулятор технологического процесса. Но в строгом смысле цифровой двойник — это динамическая цифровая модель физического объекта, системы или процесса, которая регулярно получает данные о его реальном состоянии и позволяет рассчитывать, как он поведёт себя при изменении условий. Именно эта связь с актуальным состоянием реальной системы и возможность проверять сценарии отличают двойник от статичной 3D-модели, дашборда и обычного мониторинга. Если модель обновляется вручную, это скорее цифровая модель, если автоматически получает данные от объекта, но работает в одностороннем режиме, — цифровая тень. В наиболее полном варианте цифровой двойник поддерживает постоянную связь с объектом и используется не только для наблюдения, но и для расчёта сценариев.</p> <p>Например, для простого мониторинга температуры электродвигателя достаточно датчика и панели. Но чтобы понять причину перегрева и спрогнозировать отказ, уже нужны данные о вибрации подшипников, скорости вращения ротора, нагрузке, режиме работы, внешней температуре и истории ремонтов. Для офисного или промышленного здания набор будет другим: состояние вентиляции, отопления и электроснабжения, расход энергии инженерными системами, фактическая загрузка помещений, режим эксплуатации и графики обслуживания. В медицине один снимок или анализ тоже мало что говорит без динамики показателей, терапии и анамнеза.</p> <p>Граница между обычным мониторингом и цифровым двойником проходит по их функционалу. Если система только показывает текущие показатели, это мониторинг. Если она связана с актуальным состоянием объекта и позволяет на обновляемых данных ответить на вопрос «что произойдёт, если изменить условия?», она становится инструментом моделирования и поддержки решений, то есть выполняет главную функцию цифрового двойника.</p> <h3>Где двойники уже прижились</h3> <p>Цифровые двойники быстрее всего приживаются там, где ошибка, простой или физический эксперимент стоят особенно дорого. Поэтому самые заметные российские кейсы сегодня реализованы в промышленности и ТЭК. Например, в «Газпром нефти» цифровыми двойниками <a href="https://www.interfax.ru/business/1090112">покрыто</a> около 80% цепочки создания стоимости компании — от геологоразведки до реализации нефтепродуктов.</p> <p>Но массовой эта практика пока не стала. <a href="https://ctt.spbstu.ru/news/9205">По данным</a> Росстата, в 2024 году цифровые двойники использовали только 1,36% организаций. В добыче, обрабатывающих производствах, строительстве, транспортировке и хранении, а также в профессиональной, научной и технической деятельности доля была выше — 2,46%. При этом интерес компаний шире текущего числа внедрений.</p> <p>У «Росатома» цифровые двойники <a href="https://rosatomnewsletter.com/ru/2025/11/26/the-power-of-digital-solutions/">используются</a> в проектировании и инжиниринге атомных станций, а также при разработке новых материалов, включая ядерное топливо и композиты. Здесь выгода вполне земная: часть испытаний можно провести в вычислительной среде, сократить число дорогих физических экспериментов и раньше отсеять неудачные инженерные решения.</p> <p>В городе цифровой двойник работает уже не с отдельным оборудованием, а с пространственными и инфраструктурными данными. Так цифровой двойник Москвы <a href="https://www.tadviser.ru/index.php/Статья:Владислав_Шишмарев,_ДИТ_Москвы:_Главное_—_умение_работать_с_данными_и_превращать_результат_в_конкретные_управленческие_решения">содержит</a> более 9 тыс. слоёв данных по всем сферам, которые используются при планировании инфраструктурного развития и тарифном регулировании. Для городской модели это особенно важно, так как одной геометрии зданий недостаточно, нужно регулярно сводить и обновлять данные транспорта, инженерных сетей, строительства и коммунальной инфраструктуры, а результат использовать не как красивую визуализацию, а как основание для конкретного решения.</p> <p>В медицине требования к актуальности и качеству данных ещё жёстче. Полноценный цифровой двойник пациента должен уточняться по мере изменения физического объекта — человека: с учётом новых обследований, терапии, показателей устройств мониторинга и клинической динамики. Поэтому многие нынешние решения корректнее называть «цифровыми тенями»: данные идут от пациента к модели, но обратного контура управления нет. Чем сложнее и изменчивее объект, тем труднее удерживать его цифровое описание в актуальном состоянии.</p> <p>Различия между отраслями прежде всего в цене ошибки и требуемой скорости обновления данных. Для части задач в энергетике критичны секунды и минуты, для логистики — минуты и часы, а городской инфраструктуре в части задач достаточно более редкого пересчёта. Поэтому «реальное время» не означает универсальную гонку за минимальной задержкой. Важно, чтобы данные пришли и были обработаны раньше, чем решение на их основе потеряет смысл.</p> <h3>Опаснее всего данные, которые верны по отдельности</h3> <p>Есть неприятный тип ошибки в данных, который почти не бросается в глаза. Допустим, загруженность дороги измерена пять минут назад, информация о ремонте обновлялась утром, а расписание транспорта — вчера. Все три источника могут быть корректными. Но вместе они описывают город, которого сейчас уже нет.</p> <p>На производстве, в энергетике и логистике происходит то же самое. Если показатели относятся к разным моментам времени, цифровой двойник начинает рассчитывать будущее из плохо собранного настоящего. При ручной аналитике странность ещё можно заметить. При автоматическом управлении ошибка уходит в реальный процесс почти без паузы.</p> <p>Поэтому для двойника мало знать само значение. Нужно понимать, откуда оно появилось, когда обновилось, какие преобразования прошло, были ли пропуски в данных и какой версией модели использовалось. А в идеале система управления данными должна позволять проследить весь путь назад: от итоговой рекомендации до первичного источника.</p> <p>Эту задачу решают управление метаданными и Data Lineage — прослеживаемость происхождения и преобразований данных. Если система советует изменить режим оборудования, перераспределить ресурсы или пересчитать инфраструктурный проект, важно иметь возможность объяснить, на каких данных и правилах основан этот вывод. Особенно если после рекомендации действие запускается автоматически.</p> <p>ИИ хорошо дополняет цифровые двойники: ищет аномалии в потоках сигналов, помогает строить прогнозы, быстрее перебирает сценарии. Но некорректные исходные данные он не исправляет. Скорее делает их последствия менее заметными до тех пор, пока что-то не пойдёт не так. Объекты постоянно меняются, оборудование модернизируют, технологические режимы пересматривают, у логистической сети появляются новые поставщики, в городе строятся новые развязки и кварталы. Исторические данные неизбежно начинают отставать от реальности. Поэтому идея «добавим машинное обучение и станет точнее» работает только тогда, когда сама модель объекта остаётся актуальной.</p> <p>Поэтому вопрос не в том, нужен ли двойнику ИИ. Во многих задачах он уже даёт заметный эффект. Важно то, насколько компания контролирует данные, на которых этот ИИ работает. Чем больше решений принимается автоматически, тем меньше шансов поймать ошибку вручную и тем выше её цена.</p> <h3>Начинать со «всего предприятия» — плохая идея</h3> <p>Построить цифровой двойник предприятия, города, больницы или всей логистической сети — всё это звучит амбициозно. На практике такая постановка легко превращается в бесконечную интеграционную стройку, где число систем и зависимостей растёт быстрее, чем появляется измеримый результат.</p> <p>Рабочий путь обычно намного скромнее. Сначала выбирают один вопрос, на который бизнес действительно хочет получить ответ, и уже под него собирают минимально достаточный набор данных. Далее начинается проверка, где эти данные лежат, кто за них отвечает, как часто они обновляются и можно ли дойти до первичного источника.</p> <p>Поэтому цифровой двойник вряд ли стоит воспринимать как отдельный программный продукт, который можно просто купить и внедрить. Это верхний слой над всей системой работы с данными. Математика может быть отличной, интерфейс — впечатляющим, инфраструктура — мощной, но точнее своих исходных данных двойник всё равно не станет.</p> <p>Нефтяное месторождение, энергосистема, город и пациент слишком разные, чтобы для них существовал один универсальный рецепт. Но бизнес-смысл технологии везде похож: собрать максимально близкое к реальности цифровое состояние объекта и проверить несколько вариантов действий до того, как один из них придётся оплачивать в физическом мире. Поэтому смотреть стоит не на то, насколько эффектно вращается 3D-модель и сколько к ней подключено источников. Гораздо важнее, умеет ли организация связать эти источники между собой, поддерживать данные в актуальном состоянии и объяснить, откуда взялся результат расчёта. В этом и есть практический смысл цифрового двойника для бизнеса. Не построить виртуальную копию ради самой копии, а получить место, где можно сначала проверить решение и только потом платить за его последствия.</p> <p> #IMAGE_235575#</p> Ошибка при работе с реальным объектом может привести к простою линии, перегрузке сети, дополнительным расходам или … article Максим Власюк, директор по работе с корпоративным сектором группы Arenadata https://www.itweek.ru/themes/detail.php?ID=235572 Thu, 17 Sep 2026 14:45:04 +0300 <p>Компания «АйТи Юниверс», российский аккредитованный разработчик программного обеспечения для государственных и корпоративных заказчиков, выпустила Filestone MFT 3.0, третье поколение cистемы контролируемого обмена файлами из Реестра российского ПО. Смена поколений обусловлена новой стратегией интеграций с лучшими сторонними ИТ- и ИБ-инструментами.</p> <p>Главной задачей Filestone MFT версий 3.х является обеспечение совместимости с популярными продуктами, которые формируют информационные контуры с защитой от уязвимостей и угроз разных типов, от человеческих ошибок до целенаправленных высокотехнологичных атак. </p> <p>Как и прежде, продукт предоставляет средства гибкого обмена файлами с развитыми настройками для отделов информационных технологий и информационной безопасности. Новое поколение облегчает работу всех пользователей и устраняет ряд вопросов с внедрением на объекты критической информационной инфраструктуры.</p> <p>Обновление модернизирует программный интерфейс для передачи данных о пользователях, действиях и инцидентах в стороннее ПО российского происхождения. В версии 3.0 это корпоративные антивирусы и SIEM. Реализована интеграция с Kaspersky Scan Engine (KSE), а также отправка логов в MaxPatrol SIEM от Positive Technologies. </p> <p>В дальнейших планах команды Filestone MFT интеграции с дополнительными антивирусами, SIEM и продуктами других классов, таких как DLP, песочницы, системы многофакторной аутентификации, службы каталогов. Приоритет отдан продуктам, запрос на которые поступил от клиентов.</p> <p>О конкретных интеграциях будет объявлено в сообщениях о следующих релизах и партнёрских отношениях.</p> <p>Администратор системы получил возможность полностью отключить локальную авторизацию по электронной почте. После этого вход в Filestone MFT возможен только через корпоративную службу каталогов.</p> <p>Внешние пользователи теперь могут давать согласия на обработку персональных данных, а администраторы — отзывать согласия и анонимизировать персональные данные. Для части пользователей можно ввести исключения в проверке передаваемых архивов на наличие пароля. </p> <p>Информационные панели получили возможность отображать статистические данные по отдельным сотрудникам службы информационной безопасности. А они могут опционально получать на проверку файлы, которые пользователи отправляют сами себе. </p> <p>В настройках появилась ротация логов: сроки и периодичность очистки журнала событий для соблюдения корпоративных правил и во избежание переполнения хранилища.</p> <p>Модернизация Filestone MFT затронула бэкенд для реализации возможностей API: разработку типов данных, их классификации и сбора для отправки в сторонние системы. Пользовательский интерфейс теперь отражает интеграции и новые входящие данные. </p> <p>Помимо этого команда продукта внесла оптимизации и исправила ряд ошибок, а также дополнила документацию. </p> Компания «АйТи Юниверс», российский аккредитованный разработчик программного обеспечения для государственных и корпоративных … message https://www.itweek.ru/themes/detail.php?ID=235571 Thu, 17 Sep 2026 14:43:24 +0300 <p>Компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового уровня, впервые представила vitiscale — горизонтально масштабируемую СХД, созданную для обработки больших объемов информации. vitiscale уже доступна для российских заказчиков, совместима с отечественными ОС и включена в реестр российского ПО и ПАК Минцифры. Гости мероприятия узнали больше об архитектуре нового решения, процессе создания продукта, преимуществах vitiscale в новых реалиях и сценариях применения высокопроизводительной СХД.</p> <p>«Наша система создана с нуля, не является доработкой или надстройкой open-source продуктов, — рассказал Сергей Мазниченко, генеральный директор datagarden. — Мы делаем прорывные системы хранения данных, за которые нам не стыдно. У нас получилось сформировать в компании инженерную культуру, которая позволяет создавать продукты на уровне последних мировых разработок в сфере технологий хранения данных». </p> <p>Отдельный блок мероприятия эксперты datagarden посвятили тому, как меняется роль хранилища. За последние десятилетия появилось множество задач, для решения которых требуется горизонтально масштабируемая СХД с линейным ростом производительности, не ограниченная двумя контроллерами. Линейный рост производительности при наращивании узлов СХД требует максимально полного использования всех компонентов СХД и становится необходимым условием экономической эффективности решения в целом. Так появляется новый класс систем хранения данных, работающих с задержкой менее миллисекунды при пропускной способности в сотни гигабайт в секунду.</p> <p>«СХД перестала быть просто хранилищем данных, — рассказывает Филипп Комиссаров, руководитель пресейла datagarden. — Она становится неотъемлемой частью архитектуры решения. Чем быстрее СХД, тем больше отдачи от уже купленного GPU. К тому же, в условиях подорожания ИТ-оборудования, можно приобретать меньше вычислительных мощностей, так как быстрый сторадж быстро читает сохраненные токены там, где медленный заставляет систему пересчитывать токены снова и снова, требуя более производительных GPU».</p> <p>Специалисты детально рассмотрели блочный и объектный доступ vitiscale и сценарии их применения. Блочный доступ на базе современных протоколов NVMe/RDMA, NVMe/TCP, NVME/FC, а также iSCSI и Fibre Channel рассчитан на среды с минимальными задержками. Это отраслевой стандарт для финансового сектора, крупного ритейла и критически важных государственных систем: блочный доступ обеспечивает высокую производительность транзакционных СУБД, ИИ-комплексов и средств резервного копирования.</p> <p>Объектный доступ (S3) реализует масштабируемое хранение неструктурированных данных через стандартный API и востребован в банках, телекоммуникационной, нефтегазовой отраслях и госкорпорациях — для надежной и производительной обработки аналитических данных, создания резервных копий и обеспечения эффективной работы систем искусственного интеллекта.</p> <p>На демонстрационном стенде, развернутом в рамках конференции и состоящем из шести узлов платформы vitiscale, были получены следующие результаты:</p> <ul> <li>~29 миллионов операций в секунду при случайном чтении блоков размером 4 КБ при работе по NVMe/RDMA протоколу;</li> <li>~290 000 операций в секунду при случайном чтении объектов 4КБ при работе через S3 API.</li> </ul> <p>Время отклика — менее 1 миллисекунды — означает, что система способна обрабатывать огромный поток запросов с минимальными задержками, а, значит, приложения, базы данных и сервисы будут максимально полно использовать оборудование, на котором работают, даже при пиковых нагрузках. Такие характеристики vitiscale, как высокая производительность, простота эксплуатации, линейная масштабируемость и поддержка современных протоколов доступа, гарантируют адаптивность ИТ-инфраструктуры к новым вызовам и операционную устойчивость коммерческих организаций и госпредприятий.</p> Компания datagarden, российский разработчик высокопроизводительных систем хранения данных мирового уровня, впервые представила … message https://www.itweek.ru/themes/detail.php?ID=235570 Thu, 17 Sep 2026 14:40:54 +0300 <p>MWS AI (входит в МТС Web Services) объявила об обновлении платформы для создания ИИ-агентов без программирования MWS AI Agents Platform. Агенты научились выполнять программный код, который пишут сами, в изолированной песочнице, запускаться по расписанию без команды пользователя и запоминать факты о собеседнике между сессиями. Отдельно в платформе появился конструктор интерфейсов, который даёт агенту собственный экран под конкретную задачу вместо окна чата. Вместе эти функции позволяют собирать на платформе виртуальных сотрудников, то есть связки агентов, которые ведут задачу от начала до конца без участия оператора. Песочница, запуск по расписанию и долгосрочная память уже доступны заказчикам, к конструктору интерфейсов открыт ранний доступ, в промышленную эксплуатацию он выйдет до конца 2026 года.</p> <p>Для сверки данных, расчёта показателей или подготовки отчётности агент может самостоятельно написать программу. Чтобы её выполнение не затронуло рабочие системы компании, платформа запускает такой код в песочнице — изолированной среде с собственными файлами и вычислительными ресурсами. Ограничения доступа обеспечивает программная среда: она блокирует запрещённые обращения независимо от того, какую команду сформировал агент.</p> <p>Песочница создаётся под конкретную задачу и существует только на время её выполнения. Пользователь задаёт разрешённые действия, включая запуск команд, чтение и запись файлов. На вычислительные ресурсы и продолжительность работы установлены лимиты. У агента нет доступа к внутренним системам компании, их паролям и ключам, а внешние подключения к песочнице заблокированы.</p> <p>Например, агент в финансовой организации получает выгрузку из учётной системы, пишет и запускает код для сверки данных, рассчитывает показатели и собирает отчёт. При этом он работает с переданной выгрузкой, не внося изменений в саму систему.</p> <p>Песочница разворачивается вместе с платформой внутри контура заказчика. Код исполняется на инфраструктуре компании: обрабатываемые данные и вычисления не выносятся во внешний сервис.</p> <p>Конструктор интерфейсов даёт агенту собственный экран с кнопками, формами, карточками, таблицами и графиками под конкретную задачу, причём один и тот же агент может по-разному выглядеть для клиента, сотрудника и руководителя. Например, агент авиакомпании при переносе рейса показывает на одном экране текущий билет, подходящие рейсы, стоимость обмена и кнопку подтверждения, а после выбора выполняет действия в подключённых системах. По той же логике собираются интерфейсы для продаж с карточкой клиента и историей общения, для аналитики с дашбордом и выводами, для работы с документами с текстом договора и найденными рисками, для клиентского сервиса с перепиской, данными о заказе и возвратом в одном окне.</p> <p>Агент может работать по расписанию, без команды человека. Пользователь настраивает его один раз и задаёт, когда он запускается с точностью до минуты, в каком часовом поясе и какая версия сценария при этом исполняется. Результат приходит по заданному адресу, а если несколько запусков подряд завершились неудачей, платформа сама приостановит задание и не будет копить ошибки. Запуск можно в любой момент выполнить вручную, приостановить или посмотреть историю выполнений. Таким образом агент каждое утро может собирать свежие данные, анализировать их и обновлять дашборд для руководителя, а другому агенту можно поручить фоновую обработку данных или рассылку напоминаний.</p> <p>Долгосрочная память позволяет агенту запоминать факты о пользователе и возвращаться к ним в следующих разговорах. Пользователь настраивает, какие факты агент сохраняет, и дальше он либо получает их вместе с очередным вопросом пользователя, либо сам решает, когда обратиться к памяти.</p> <p>«К базе знаний агент теперь обращается сам, когда считает нужным. Раньше место обращения к базе разработчик размечал в сценарии заранее, отдельным шагом с поиском по индексу: он решал, в какой точке разговора агент пойдёт в базу и что именно будет искать. Теперь поиск по базе знаний подключается к агенту как инструмент, наравне с остальными, и агент сам решает, когда его применить, сам формулирует запрос и разбирает результат. Базы знаний подключаются напрямую к корпоративным страницам Confluence, а большие наборы документов загружаются одним архивом вместо добавления каждого файла отдельно. Так агент внутренней поддержки отвечает сотрудникам на основе корпоративной базы знаний, опираясь на действующие инструкции и регламенты», — подчеркнул директор по продукту MWS AI Agents Platform Пётр Новиков.</p> <p>Платформа автоматически задаёт агенту набор контрольных вопросов, сравнивает ответы с ожидаемыми и показывает ошибки. Вопросы и ожидаемые ответы заранее готовит пользователь. При необходимости можно посмотреть, что происходило на каждом шаге. Раньше такие диалоги приходилось проверять вручную.</p> <p>«Мы развиваем платформу в сторону универсальных рабочих агентов, которым человек может поручить задачу целиком, задав цель и требования к результату. Такой агент самостоятельно составляет план, запускает других агентов для отдельных этапов и корректирует дальнейшую работу по результатам проверки. Например, поручает одному агенту анализ данных, другому — проверку расчётов, а затем объединяет результаты в отчёт. Для этого агентам нужна общая рабочая среда, где можно выполнять код, пользоваться инструментами и сохранять удачные способы решения для следующих запусков. Обновление платформы создаёт основу для таких систем. При этом заказчик определяет, какие действия агенты выполняют самостоятельно, как оценивается качество и в какой момент к работе подключается человек», — отметил технологический директор MWS AI Agents Platform Андрей Цивына.</p> MWS AI (входит в МТС Web Services) объявила об обновлении платформы для создания ИИ-агентов без программирования … message https://www.itweek.ru/themes/detail.php?ID=235568 Thu, 17 Sep 2026 10:27:24 +0300 <p><em>Согласно данным Gartner, сегодня многие компании сталкиваются с парадоксальной ситуацией: ИТ-бюджеты растут, но доверие к CIO падает. Бизнес перестал слушать «айтишников» не потому, что те плохо разбираются в технологиях. Основная проблема — несогласованность целей. Пока ИТ-директор концентрируется на работе серверов, собственник подсчитывает, насколько прибыльным будет техническое нововведение. Рассмотрим фатальные ошибки, которые совершают даже сильные ИТ-директора в коммуникации с бизнесом.</em></p> <h2>Девять наиболее частых ошибок ИТ-директоров</h2> <p>Перечислим наиболее частые ошибки, которые совершают ИТ-директора в процессе коммуникации с собственниками бизнеса.</p> <h3>1. Выстраивание ИТ-стратегии без настоящей интеграции с бизнесом</h3> <p>Треть ИТ-директоров не чувствуют себя компетентными в вопросах встраивания ИТ-стратегии в корпоративную. Опытные лидеры часто упускают возможность кардинально переформулировать ее вокруг бизнес-результатов. В итоге получается технически безупречная стратегия, которую собственник компании не понимает и не ценит.</p> <h3>2. Общение на технологическом языке</h3> <p>CIO часто готовят ИТ-стратегии и оформляют документацию на языке, понятном только коллегам по цеху. Но для руководителей других отделов терминология ИТ чаще всего звучит как «китайская грамота». Естественно, ни поддержки, ни сотрудничества не возникает, поскольку отсутствует взаимопонимание.</p> <h3>3. Неумение выстраивать кросс-функциональные отношения на ранних этапах</h3> <p>Опытные CIO часто забывают выстраивать отношения с руководителями других подразделений, из-за чего создают неверные стратегические предположения и не успевают за переменами в бизнесе. Без постоянного контакта собственники видят в ИТ лишь подрядчика, а не партнера.</p> <h3>4. Опора на опыт как на замену адаптированной коммуникации</h3> <p>Многие сильные ИТ-директора полагают, что их навыков сторителлинга и коммуникации достаточно для общения со стейкхолдерами. На деле у разных бизнес-лидеров (CEO, CFO, COO, руководители бизнес-подразделений) различные приоритеты и стили принятия решений, поэтому универсальная коммуникация не работает. Только 43% членов советов директоров говорят о том, что ИТ-директора предоставляют полезную информацию для контроля акционерной стоимости. Это сигнал недоверия, который упускают даже сильные лидеры.</p> <h3>5. Позиционирование ИТ-бюджетов как защиты расходов, а не стратегических нарративов</h3> <p>CIO часто подают бюджет как обычную смету расходов, но не показывают, какой доход или выгоду принесут вложения в ИТ. В результате бизнес видит в технологиях только «дыру в бюджете», а не инструмент для развития.</p> <h3>6. Позднее вовлечение в технологические решения</h3> <p>Почти две трети компаний жалеют о купленном ПО. Главная причина — ИТ-специалистов подключают слишком поздно, когда основные решения уже приняты. Это ведет к сбоям, задержкам и разочарованию. При этом даже опытные ИТ‑директора порой не успевают задать правильное направление стратегии.</p> <h3>7. Предположение, что видение без исполнения будет воспринято</h3> <p>Стратегия без исполнения — это провал. Даже опытные ИТ-директора иногда создают убедительные концепции, которые не превращаются в практические направления и измеримые метрики. Команды не имеют четкого видения результата, исполнение хромает, а доверие к руководству падает.</p> <h3>8. Пренебрежение развитием бизнес-проницательности</h3> <p>ИТ-директора часто выступают в роли хранителей данных, а не интерпретаторов бизнес-задач. Без понимания экономических драйверов, поведения клиентов, конкурентной динамики и рычагов эффективности они не могут убедительно расставлять приоритеты инвестиций или вносить значимый вклад в стратегические обсуждения. Технического мастерства больше недостаточно для участия в бизнес-диалогах.</p> <h3>9. Отсутствие социального интеллекта</h3> <p>ИТ-директора, которые не умеют считывать межличностную и организационную динамику, управлять напряженными разговорами или строить подлинные отношения с коллегами-руководителями, рискуют оказаться в изоляции. Умение интерпретировать поведение, управлять отношениями и адаптировать стиль общения крайне важно и часто упускается даже сильными, технически ориентированными лидерами.</p> <p>Чтобы собственник начал слышать CIO, ИТ-директору нужно быть не только техническим экспертом, но и бизнес-стратегом. Каждую инициативу придется формулировать на языке прибыли, рисков и клиентского опыта и вовлекать CFO и COO в обсуждение ИТ-стратегии уже на старте. Главное — научиться доносить сложные вещи простым языком и ставить технологии на службу бизнесу.</p> <p>#IMAGE_235569#</p> Согласно данным Gartner, сегодня многие компании сталкиваются с парадоксальной ситуацией: ИТ-бюджеты растут, но доверие … article Саян Доржиев, эксперт по корпоративным технологиям, ИИ и стратегической трансформации бизнеса (ex-Gartner) https://www.itweek.ru/themes/detail.php?ID=235566 Thu, 17 Sep 2026 10:15:17 +0300 <p>Искусственный интеллект сделал код дешевым настолько, что старое правило «проще поправить, чем переделывать целиком» теперь работает не всегда. Однако возникла проблема: техническая возможность переписать продукт еще не означает, что это действительно необходимо.</p> <p>По данным июньского <a href="https://about.gitlab.com/press/releases/2026-06-23-gitlab-research-reveals-organizations-are-generating-ai-code-faster-than-they-can-control-it/">исследования</a> GitLab и The Harris Poll, 85% опрошенных считают, что ИИ уже перенес основное узкое место разработки с написания кода на его проверку и подтверждение качества. Еще 78% говорят, что разработчики стали отдавать код гораздо быстрее.</p> <p>Это хорошо описывает изменение самой экономики разработки. Обсудим, когда правда разумнее собрать продукт заново, почему старый код становится источником требований — и как не превратить переписывание в новую разновидность техдолга.</p> <h3>Код больше не самое дорогое место разработки</h3> <p>Условно можно сказать, что этап написания кода внутри жизненного цикла разработки стал обходиться «почти бесплатно». Не буквально, конечно — модели, инфраструктура и специалисты по-прежнему стоят денег. Просто количество созданного кода все слабее связано с количеством человеко-часов.</p> <p>В качестве примера возьмем задачу переноса мобильного приложения в веб. Агентная система воплощала эту идею в жизнь около 20 часов. Инженер в это время занимался другими тикетами и созвонами — но периодически возвращался к агентам и проверял работу, корректируя результат. По сути он скорее дирижировал системой, нежели писал что-то сам.</p> <p>Здесь хорошо видно, почему ускорение написания кода не означает, что вся разработка тоже ускоряется. Новый продукт все равно нужно придумать: поговорить с владельцем, собрать требования, устранить противоречия, определить ограничения. И этот разговор по-прежнему занимает полтора часа. Его можно сделать предметнее с помощью прототипа — однако кратно ускорить получение бизнес-контекста гораздо сложнее.</p> <p>Да, ИИ резко удешевил один участок процесса. Но не нужно думать, что это произошло с остальными его участками.</p> <h3>У старого продукта есть преимущество: он уже объясняет, что нужно построить</h3> <p>Тут переписывание существующего продукта оказывается в крайне выгодной позиции. И вот почему: если система работает много лет, требования к ней уже где-то зафиксированы.</p> <p>При идеальном раскладе сохранились документация, задачи и описания процессов. Но, даже если ничего этого нет, остается кодовая база. Современный агент может использовать ее как источник фактических требований: он разберется, какие сценарии существуют, какие компоненты связаны, что происходит после конкретного действия и какие предусмотрены исключения.</p> <p>То есть старый продукт — это своеобразный архив собственных требований.</p> <p>При разработке с нуля обязательно нужно спросить специалиста: «Как это должно работать?» При переписывании можно сначала задать существующей системе вопрос: «Как ты работаешь сейчас?» — и только после этого определять, что поменять, а что сохранить.</p> <h3>Когда переписывание имеет смысл</h3> <p>У программистов есть нерушимое правило: «работает — не трогай». Искусственный интеллект сделал обход этого правила дешевле.</p> <p>Снижение стоимости нового кода влияет на границу между рефакторингом и полной переработкой, но здравого смысла не отменяет. Причина для переписывания должна отвечать на простой вопрос: «Чтобы что?»</p> <p>Например:</p> <ul> <li> система перестала выдерживать нужную нагрузку;</li> <li> существующая архитектура не масштабируется;</li> <li> продукт радикально меняет назначение;</li> <li> новый функционал невозможно нормально встроить в исходную конструкцию;</li> <li> развитие старой системы обходится дороже, чем замена проблемной части.</li> </ul> <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> <p>Именно поэтому переписывание с нуля порой куда опаснее, чем переписывание по фактическому поведению старой системы.</p> <h3>Старый продукт можно превратить в исполняемую спецификацию</h3> <p>До большого переписывания существующий продукт можно максимально покрыть автоматическими тестами: пользовательскими, интеграционными, сквозными. Причем сами тесты тоже помогают готовить агенты.</p> <p>Дальше старая реализация становится эталоном поведения. Команда создает новую версию и запускает на ней те же проверки. Схема получается такой: «существующий код — восстановленные требования — автоматические тесты — новая реализация — те же тесты». Если проверка падает, возникает конкретный вопрос: это новая система что-то сломала, или старая работала не так, как думала команда?</p> <p>По сути, здесь соединяются принципы SDD (разработки от спецификации) и TDD (разработки через тесты). Сначала команда восстанавливает из существующей системы спецификацию — что продукт должен делать, какие сценарии и рамки сохранять. Затем это поведение фиксируется автотестами, которые становятся проверяемыми требованиями к новой реализации.</p> <p>Получается двойная страховка: спецификация объясняет, что нужно сохранить, а тесты позволяют проверить: правда ли новое решение это сохранило.</p> <h3>Тесты могут рассказать о продукте больше, чем документация</h3> <p>Особенно интересны упавшие проверки. Они способны обнаружить скрытое поведение, исключения и исторические решения, о которых команда уже не помнит. Иногда даже выясняется, что годами система работала не так, как предполагали владельцы продукта.</p> <p>Причем не каждое отличие новой версии нужно автоматически исправлять. Если тест обнаружил неожиданное поведение старой системы, стоит сначала выяснить, действительно ли его надо воспроизводить. Возможно, команда просто впервые увидела старое ограничение или ошибку — и переписывание дает возможность осознанно от них отказаться.</p> <p>В этом смысле падающий тест становится и сигналом «мы что-то сломали», и источником нового знания о собственном продукте.</p> <p>Так переписывание превращается не просто в техническую операцию. Можно улучшить не только архитектуру и другие нефункциональные характеристики, но иногда и саму функциональность — если стало понятно, что прежнее поведение больше не имеет смысла.</p> <h3>Прежде чем все переписать: памятка</h3> <p>Искусственный интеллект сделал полное переписывание доступнее — и именно поэтому решение о нем надо принимать строже. Перед стартом полезно пройти несколько шагов:</p> <ol> <li> <strong>Ответить на вопрос: «Чтобы что?» </strong>Зафиксировать конкретную проблему: скорость, нагрузку, архитектурное ограничение, стоимость изменений или смену назначения продукта.</li> <li><strong>До начала переписывания максимально покрыть существующую систему автоматическими тестами. </strong>С помощью ИИ можно быстрее подготовить пользовательские, сквозные, интеграционные и другие проверки. Важно, чтобы они проходили на старом продукте и фиксировали его фактическое поведение.</li> <li><strong>Попросить агентов разобрать существующую систему и восстановить спецификацию</strong><strong>:</strong> компоненты, зависимости, сценарии и скрытые функции, которые могли не попасть в документы. Причина переписывания тоже должна стать частью требований к новой версии.</li> <li><strong>Разделить то, что обязательно нужно сохранить, и то, что команда намеренно хочет изменить.</strong> Новая реализация должна воспроизвести нужное поведение, но не обязана копировать старую архитектуру и ее ограничения.</li> <li><strong>Собрать новую версию и запускать на ней тот же набор тестов. </strong>Продолжать до тех пор, пока обязательные проверки не перестанут падать, а каждое оставшееся расхождение не будет объяснено.</li> <li><strong>Не исправлять отклонения автоматически. </strong>Падение теста может означать как ошибку новой версии, так и неожиданное или уже ненужное поведение старой системы.</li> <li><strong>Только после этого выключать старую реализацию. </strong>Генерация новой версии может занять часы, тогда как последствия потерянной зависимости способны проявиться через месяцы.</li> </ol> <h3>Что в итоге</h3> <p>ИИ действительно меняет старый выбор между рефакторингом и переписыванием. Там, где цена полной переработки прежде останавливала команду, технический барьер стал значительно ниже.</p> <p>Однако это не меняет стоимости неправильного решения. Новый код можно сгенерировать очень быстро — гораздо сложнее восстановить десятилетие бизнес-логики, скрытые зависимости и поведение, к которому привыкли пользователи.</p> <p>Главный эффект ИИ здесь в том, что старую систему теперь можно быстрее разобрать, превратить ее поведение в спецификацию и осознанно собрать новую — только там, где это правда имеет смысл.</p> <p> #IMAGE_235567#</p> Искусственный интеллект сделал код дешевым настолько, что старое правило «проще поправить, чем переделывать целиком» теперь … article Константин Попандопуло, технический директор Umbrella IT https://www.itweek.ru/themes/detail.php?ID=235565 Thu, 17 Sep 2026 10:04:09 +0300 <p><em>Некоторые эксперты по сетям предполагают, что ИИ возьмет на себя бóльшую часть работы по управлению сетью с минимальным участием человека. Но сделает ли это саму сеть более интеллектуальной — или просто сделает инструменты, используемые для ее управления, более интеллектуальными — это спорный вопрос, отмечают опрошенные порталом </em><em>InformationWeek</em> <em>эксперты.</em></p> <p>Сети уже давно рассматриваются как основа критически важной корпоративной ИТ-инфраструктуры, которая соединяет системы и перемещает данные. ИИ меняет подход к управлению этой инфраструктурой. Системы управления сетями теперь могут сопоставлять разрозненные сигналы, помогая ИТ-командам выявлять наиболее критические проблемы, и, в некоторых случаях, автоматически их решать.</p> <p>В какой степени ИИ в конечном итоге сможет управлять сетями — это открытый вопрос. Для CIO он заключается в том, сможет ли сеть в какой-то момент превратиться из инфраструктуры, управляемой ИТ, в инфраструктуру, которая помогает управлять самими ИТ.</p> <p>«Сеть — это не мозг; это нервная система, — говорит Паоло Канале, руководитель сектора телекоммуникаций EY в Северной и Южной Америке. — Это децентрализованный интеллект, в котором заинтересованы все сетевые операторы».</p> <p>По его словам, ИИ «оживляет сеть», имитируя работу нервной системы. При этом ИИ может анализировать данные и оповещения, поступающие из разных сегментов сети, чтобы приоритизировать проблемы и автоматизировать некоторые действия.</p> <p>Канале отмечает, что сеть также все больше объединяет интеллектуальные области, включая периферийную инфраструктуру, облачные платформы и приложения ИИ.</p> <p>Однако Роз Роузборо, старший главный аналитик исследовательской компании Omdia, утверждает, что большая часть изменений происходит в инструментах, используемых для управления сетями, а не в самой сети.</p> <p>«Возможно, это придирки, но я не уверена, что меняется сама сеть, — говорит она. — Меняются инструменты, которые поставщики услуг связи используют для управления сетью. Точно меняются OSS (системы поддержки операций). У людей, которые управляют сетью, теперь есть более интеллектуальные инструменты».</p> <p>Канале указывает на еще одно изменение: ИИ может сопоставлять информацию из разных систем мониторинга сети, которые исторически работали изолированно. «Разница в том, что теперь сеть получила возможность собирать все эти сигналы, устанавливать корреляции и определять, в чем реальная проблема. И, что более важно, как это повлияет на клиента, как это повлияет на бизнес», — поясняет он.</p> <h3>Более интеллектуальное и быстрое управление сетью</h3> <p>Способность ИИ использовать информацию из разных сетевых систем также делает управление сетью более оперативным. Сеть по-прежнему похожа на коммунальную службу, перемещающую данные из точки А в точку Б, но с ИИ она становится «более оперативной, чем раньше, потому что может обрабатывать больше информации, чем прежде», — говорит Роузборо.</p> <p>Агенты ИИ могут идентифицировать и получать доступ к данным в разрозненных системах, таких как системы биллинга и системы обслуживания, чтобы, например, найти информацию об использовании маршрутизатора.</p> <p>«Теперь инвентаризация становится чем-то вроде системы учета, и все зависит от того, может ли она выполнить то, о чем вы ее запросили. И сделать это в режиме реального времени, — говорит Роузборо. — Это позволяет делать вещи быстрее и в бóльших масштабах. Вы можете просто сказать агенту: „Вперед, сделай это“, и он сможет это осуществить».</p> <p>Некоторые из базовых технологий сетевого интеллекта не новы. Брайан Уошберн, главный аналитик Omdia, указывает на такие технологии, как Cisco NetFlow и Juniper JFlow, которые уже давно предоставляют аналитику сетевых событий. По его словам, ИИ может ускорить объединение информации из разрозненных систем управления сетью.</p> <p>Технологии сетевого интеллекта и наблюдаемости — это «части, которые, можно сказать, ведут себя как отдельные нервные системы. Теперь, благодаря волшебству ИИ, мы можем начать объединять некоторые из них, что особенно важно для предприятий, которые приобрели десяток различных систем управления сетью», — отмечает Уошберн.</p> <p>По его словам, ИИ также может упростить взаимодействие ИТ-специалистов с сетевыми системами. Например, ИТ-команды могут использовать обработку естественного языка (NLP) и агентов ИИ для запроса ценового предложения на новое оптоволоконное подключение в офисе, вместо того чтобы размещать заказ через представителя-человека.</p> <p>Роузборо отмечает, что NLP также позволяет CIO и ИТ-командам «задавать вопросы относительно сети и сопоставлять больше типов информации, чем раньше, а затем стратегически использовать эту информацию. Предприятие может получить инсайты, которые оно сможет использовать для развития своих услуг».</p> <h3>Технологии, поддерживающие более интеллектуальное управление сетью</h3> <p>Несколько технологий помогают сделать управление сетью более интеллектуальным и автоматизированным:</p> <p><strong>Цифровые двойники.</strong> Это одна из технологий, поддерживающих более интеллектуальное управление сетью. Согласно данным McKinsey, цифровые двойники сетевых сред могут использоваться в качестве испытательных полигонов и сред обучения для генеративного ИИ (GenAI), а GenAI — анализировать результаты работы цифровых двойников.</p> <p>Например, AT&T использует свою GenAI-систему GEO Modeler, которая виртуально зеркалирует сеть, помогая выявлять и сопоставлять сбои. Система может моделировать и прогнозировать покрытие сети, чтобы подготовиться к инцидентам, которые могут повлиять на доступность сети, — например, к отключению вышки сотовой связи во время бури.</p> <p><strong>Возможности самостоятельных действий (Self-X).</strong> Они выводят эту эволюцию на новый уровень, позволяя сетевым функциям работать с меньшим участием человека. Self-X включает «семейство возможностей, таких как самоконтроль, самовосстановление, самооптимизация и, в конечном итоге, самопланирование», — поясняет Канале.</p> <p>В настоящее время многие сети могут обнаруживать аномалии, определять вероятную первопричину проблемы, рекомендовать решение или предпринимать действия по устранению неполадок с помощью «заранее определенных корректирующих действий», добавляет он. Например, если базовая станция сотовой связи перегружена, сеть может автоматически перенаправить трафик или скорректировать конфигурации для поддержания уровня качества обслуживания.</p> <p>«Мы ожидаем, что со временем сети перестанут просто реагировать на проблемы. Вместо того чтобы ждать их возникновения, они будут прогнозировать всплески спроса, предвидеть сбои до того, как они произойдут, пересматривать планы пропускной способности и постоянно оптимизировать свою работу с минимальным участием человека. Конечная цель — сеть, которая учится на каждом событии, постоянно совершенствуется и управляет большей частью своей работы самостоятельно», — говорит Канале.</p> <p>Связанная с этим концепция Zero-X Experience описывает, что может означать бóльшая автономность сети для клиентов: обеспечение работы сети и предоставление услуг, требующие минимального или нулевого вмешательства с их стороны. Для клиентов сервис-провайдеров — включая CIO и ИТ-команды предприятий — внедрение ИИ может означать сети, которые функционируют без необходимости создания тикетов, эскалации или устранения неполадок, поясняет Канале.</p> <p>Он приводит пример розничного продавца, готовящегося к «черной пятнице». Традиционно ИТ-команде приходилось вручную запрашивать дополнительную пропускную способность, отслеживать производительность сети и реагировать на любые проблемы, возникающие во время распродажи.</p> <p>«Согласно концепции Zero-X сеть распознает предстоящий спрос, заблаговременно выделяет дополнительные мощности, непрерывно оптимизирует производительность во время события и возвращает ресурсы после его окончания без участия человека, — говорит Канале. — Клиент никогда не открывает тикет, не ждет подтверждения и может даже не осознавать, что оптимизация произошла».</p> <p>По его словам, ИИ также объединяет части сетевых операций, которые традиционно были изолированы, включая системы поддержки бизнеса (BSS) и OSS. «Там, где появляется ИИ, он действительно разрушает все эти барьеры и создает открытую экосистему, которая может напрямую быстро подключать BSS к OSS», — отмечает Канале.</p> <h3>Насколько далеко может зайти автономия сети?</h3> <p>По мере того, как ИИ берет на себя все больше функций управления сетью, возникает вопрос, какая часть этой работы в конечном итоге может выполняться без вмешательства человека. Канале считает, что ИИ делает сеть более интеллектуальной, в то время как сеть поддерживает эволюцию ИИ.</p> <p>«Это почти как двусторонняя трансформация, — говорит он. — С одной стороны, ИИ, безусловно, делает сети более предсказуемыми, адаптивными и все более автономными. Но в то же время ИИ предъявляет к сети новые требования. Значительно возрастают требования к задержке, передаче данных, безопасности, отказоустойчивости, стоимости и т. д.».</p> <p>При этом Канале отмечает, что хотя управление сетью станет в значительной степени автономным, оно не будет автономным в каждой ситуации. «Рутинные операционные действия, такие как мониторинг, обнаружение неисправностей, управление конфигурацией, оптимизация производительности и прогнозирование пропускной способности, являются отличными кандидатами для автономной работы, — говорит он. — Эти действия основаны на больших объемах данных и повторяющихся шаблонах принятия решений, где ИИ показывает себя исключительно хорошо».</p> <p>Роузборо поддерживает прогноз Канале о том, что сеть никогда не будет полностью автономной, поскольку это было бы «слишком рискованно». По ее словам, поставщики услуг связи стремятся к автоматизации <nobr>4-го</nobr> уровня для большинства сетевых процессов. Отраслевая телекоммуникационная организация TMForum представила таксономию уровней автономной сети — от 0 до 5, где уровень 0 означает «ручное управление и техническое обслуживание», а уровень 4 — «высокую автономность», обеспечивающую «замкнутое управление сетями, ориентированными на обслуживание и клиентский опыт, посредством ИИ-моделирования и непрерывного обучения».</p> <p>По словам Канале, ИИ будет принимать решения, которые являются «частыми, основанными на данных и оперативными по своему характеру», в том числе:</p> <ul> <li> Выявление и устранение сетевых инцидентов.</li> <li> Динамическая корректировка сетевых конфигураций.</li> <li> Оптимизация маршрутизации и потоков трафика.</li> <li> Прогнозирование сбоев оборудования.</li> <li> Предоставление услуг.</li> <li> Управление стандартными мерами безопасности.</li> <li> Прогнозирование спроса и рекомендации по изменению пропускной способности.</li> </ul> <p>К областям, которые по-прежнему будут требовать участия человека, относятся «важные архитектурные решения, стратегические инвестиции, нормативные соображения и бизнес-компромиссы, — считает он. — Полезный принцип заключается в том, что ИИ должен все чаще принимать оперативные решения, в то время как люди остаются ответственными за стратегические решения».</p> <p>Канале также отмечает, что люди будут продолжать руководить решениями по управлению сетью, касающимися доверия клиентов, соответствия нормативным требованиям и долгосрочной стратегии, выбора сетевой архитектуры, управления безопасностью и выбора поставщиков. Роузборо поясняет, что любые изменения в сети, которые могут привести к перебоям в предоставлении услуг клиенту, скорее всего, всегда будут подтверждаться или утверждаться человеком.</p> <p>По мере того как сети будут становиться все более автономными, роль CIO будет приобретать более стратегический характер, они будут уделять больше внимания клиентскому опыту и цифровым бизнес-моделям, добавляет Канале. По его словам, ИТ-командам потребуется повысить квалификацию в области управления ИИ и контроля за системами ИИ, управления качеством данных, а также сосредоточить внимание на управлении результатами для бизнеса.</p> <p>Канале сравнивает эту трансформацию с внедрением автопилота в авиации. Человек-пилот не был упразднен, но его «роль эволюционировала от непрерывного управления самолетом к контролю за все более сложными системами и вмешательству при необходимости. Сетевые технологии движутся в очень похожем направлении: все меньше людей управляют отдельными устройствами, и все больше людей оркестрируют интеллектуальные системы, которые управляют собой сами».</p> Некоторые эксперты по сетям предполагают, что ИИ возьмет на себя бóльшую часть работы по управлению сетью … article https://www.itweek.ru/themes/detail.php?ID=235560 Wed, 16 Sep 2026 19:03:06 +0300 <p>После нескольких лет аномально высокого спроса российский рынок труда в ИТ-сфере возвращается к более сбалансированному состоянию: острый кадровый дефицит уходит на второй план, а требования к кандидатам ужесточаются. Насколько навыки ИТ-специалистов соответствуют потребностям работодателей? Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ изучает этот вопрос на примере разработчиков ПО и специалистов по ИТ-инфраструктуре.</p> <p>В 2025 г. в России насчитывалось 944,1 тыс. разработчиков ПО и 432,4 тыс. специалистов по ИТ-инфраструктуре. К первой группе (код 251 по Общероссийскому классификатору занятий) относятся специалисты, участвующие в создании и внедрении ИТ-продуктов: разработчики приложений и программ, программисты, аналитики и архитекторы данных и ПО, тестировщики. Специалисты по ИТ-инфраструктуре (код 252) — сетевые инженеры, специалисты по информационной безопасности и администраторы баз данных — обеспечивают функционирование и безопасность сетей и баз данных.</p> <p>По классификатору занятий обе группы относятся к специалистам высшего уровня квалификации, для которых диплом вуза считается стандартным требованием. На практике, особенно при кадровом дефиците, работодатели готовы рассматривать и кандидатов без высшего образования. Среди разработчиков доля выпускников вузов выше, чем среди специалистов по ИТ-инфраструктуре: 79% против 73%. Среднее профессиональное образование имеют соответственно 19% и 24% работников, общее среднее — 2% и 3%.</p> <p>Отдельно оценивалось соответствие профиля обучения содержанию текущей работы. Оно у разработчиков также выражено сильнее: разработчики ПО чаще работают по полученной специальности (91,5% против 84% специалистов по ИТ-инфраструктуре). При этом такое соответствие может определяться не только формальным совпадением диплома и профессии: достойную ИТ-подготовку могут давать также физические и технические направления.</p> <p>Подавляющее большинство ИТ-специалистов (89,5% разработчиков и 90,2% специалистов по ИТ-инфраструктуре) считают свои навыки полностью соответствующими требованиям текущей работы. Еще <nobr>7–8%</nobr> полагают, что способны решать более сложные задачи. В целом требования к разработчикам по большинству видов компетенций выше, чем к специалистам по ИТ-инфраструктуре, хотя общий профиль требований к обеим группам близок.</p> <p>Профессиональные компетенции (их респонденты оценивали применительно к своей конкретной деятельности) и навыки работы с компьютером востребованы у всех опрошенных и составляют основу требований к ИТ-специалистам. Потребность в продвинутом уровне этих навыков отмечают <nobr>48–57%</nobr> респондентов. Порядка трети для их работы достаточно среднего уровня, а для <nobr>12–15% —</nobr> и вовсе базового. Математические навыки и навыки работы с текстом востребованы у <nobr>74–88%</nobr> ИТ-специалистов (чаще нужны на среднем или базовом уровне).</p> <p>Навыки работы с ИИ необходимы 49% разработчиков и 39% специалистов по ИТ-инфраструктуре, причем их продвинутый уровень, предполагающий разработку и внедрение ИИ-решений, востребован лишь у <nobr>15–16%</nobr> работников этих групп, то есть остается нишевой компетенцией даже среди ИТ-специалистов.</p> <p>Иностранный язык используют 35% разработчиков и 26% специалистов по ИТ-инфраструктуре и, по их оценкам, достаточно его знать на среднем уровне, что может быть связано с невысокой вовлеченностью этой категории работников в международные проекты.</p> <p>Мягкие навыки ИТ-специалисты отмечают как необходимые значительно реже: по отдельным компетенциям от 57% до 79% работников сообщают об отсутствии потребности в них.</p> <p>Топ-3 наиболее востребованных мягких навыков у разработчиков составляют решение проблем (43%), работа в команде (42%) и способность к обучению (41%). У специалистов по ИТ-инфраструктуре лидируют решение проблем и работа в команде (по 38%), далее идут способность к обучению и работа с клиентами (по 33%). В целом разработчики отмечают более высокие требования к мягким навыкам, особенно когнитивным, а специалисты по инфраструктуре — к социальным, что, видимо, коррелирует с их более частым взаимодействием с внутренними заказчиками и урегулированием инцидентов.</p> <p>По всем рассматриваемым типам навыков большинство респондентов, которым они необходимы, считают свой уровень соответствующим требованиям текущей работы <nobr>(74–91%).</nobr> Это может свидетельствовать об эффективности механизмов подбора и адаптации кадров в ИТ-сфере. В отношении профессиональных навыков, математики, работы с компьютером и текстом примерно каждый пятый-шестой респондент в обеих группах оценивает свой уровень выше требуемого, что указывает на потенциал повышения производительности.</p> <p>Наиболее заметный дефицит наблюдается в навыках работы с ИИ и знании иностранных языков: недостаточный уровень отмечают соответственно <nobr>10–11%</nobr> и <nobr>8–12%</nobr> работников, которым эти навыки необходимы. Для мягких навыков характерна другая ситуация: среди тех, кому они нужны (а востребованными их считают менее половины работников), <nobr>84–91%</nobr> считают свой уровень соответствующим требованиям, а лишь <nobr>2–5%</nobr> признают его недостаточным. Возможно, работники, чьи профессиональные роли требуют мягких навыков, действительно хорошо подготовлены. Вместе с тем нельзя исключать, что ИТ-специалисты не воспринимают мягкие навыки как отдельную категорию профессиональных компетенций.</p> <p>Результаты анализа ИСИЭЗ НИУ ВШЭ показали, что большинство ИТ-специалистов (около 90%) считают свои навыки соответствующими требованиям текущей работы, что может отражать как реальный уровень подготовки, так и ограниченную сложность задач в части компаний. При этом <nobr>16–21%</nobr> работников оценивают профессиональные, компьютерные, текстовые и математические навыки выше требуемого уровня. Для дальнейшего технологического развития важны более полное использование имеющихся компетенций и устранение дефицита навыков работы с ИИ и иностранных языков.</p> После нескольких лет аномально высокого спроса российский рынок труда в ИТ-сфере возвращается к более сбалансированному … message https://www.itweek.ru/themes/detail.php?ID=235559 Wed, 16 Sep 2026 19:00:15 +0300 <p>Компания Pantum, производитель печатного оборудования, объявила о выходе новых струйных МФУ — MT300W и MT302W. Это первые устройства в портфеле компании, которые используют технологию струйной печати. Новинки поддерживают цветную печать A4 и станут универсальным решением для дома или небольшого офиса, а также станут незаменимыми помощниками во время учёбы.</p> <p>Одной из ключевых особенностей МФУ стала встроенная система непрерывной подачи чернил (СНПЧ), которая позволяет сократить расходы на печать. Удобная система заправки обеспечивает быстрое и аккуратное пополнение чернил, а прозрачные резервуары позволяют в любой момент контролировать их уровень. Чернила идут в комплекте. Для стабильной работы обе новинки оснащены системой автоматического смачивания печатающей головки. Эта технология предотвращает засыхание чернил в соплах даже при длительных паузах в печати. Интеллектуальная многоступенчатая система очистки печатающей головки помогает поддерживать высокое качество печати и снижает затраты на обслуживание.</p> <p>Скорость печати составляет до 5 стр./мин. в цветном режиме и до 8.5 стр./мин. в чёрно-белом, что соответствует средним показателям устройств мировых производителей в данной категории МФУ. Лоток подачи вмещает 100 листов. Высокое разрешение печати и сканирования гарантирует чёткие документы и детализированные изображения, а функция печати без полей позволяет получать яркие фотографии высокого качества. </p> <p>Управление осуществляется через дисплей. Новинки также поддерживают беспроводное подключение по Wi-Fi и работу с мобильными устройствами через AirPrint, Mopria и приложение Pantum. Компактный корпус позволяет разместить устройства даже в небольшом пространстве, стильный дизайн легко впишется в любой интерьер.</p> <p>«Pantum — признанный лидер в сфере лазерных принтеров и МФУ, наши решения востребованы на рынке России, миллионы пользователей доверяют Pantum. Мы вложили весь свой опыт в разработку доступных и эргономичных струйных решений для печати, которые подойдут как для дома, так и для небольшого офиса. Струйные печатающие устройства представляют важный шаг в развитии компании, выход в качественно новый для нас сегмент и, что самое главное, возможность предложить пользователям и партнерам новый продукт. В данный момент в России нет других производителей струйных МФУ, которые бы продавали свою продукцию официально, предлагая пользователям сервис, гарантию, обеспечивали непрерывное наличие. Pantum предлагает надежное и доступное устройство», — отметил Александр Кукин, генеральный директор Российского представительства Pantum.</p> <p>Струйные МФУ от Pantum станут отличным решением для ежедневной работы с документами и фотографиями. MT302W в белом цвете доступно к покупке в сети DNS, рекомендуемая розничная цена — 12 999 р. MT300W в тёмно-сером цвете поступит в продажу позднее. </p> Компания Pantum, производитель печатного оборудования, объявила о выходе новых струйных МФУ — MT300W и MT302W. Это … message https://www.itweek.ru/themes/detail.php?ID=235558 Wed, 16 Sep 2026 18:58:47 +0300 <p>Компания «Базис» объявила о выпуске новой версии своей флагманской платформы серверной виртуализации Basis Dynamix Enterprise 4.7. Релиз сосредоточен на четырех направлениях: экономии дискового пространства, автоматизации развертывания и эксплуатации платформы, контроле распределения вычислительных ресурсов и аудите событий. Всего в новую версию платформы вошло более 120 улучшений и исправлений, которые упрощают для администратора часть рутинных обязанностей и дают ему больше контроля над распределением вычислительных ресурсов.</p> <p>В предыдущей версии Basis Dynamix Enterprise тонкие диски и связанные клоны были реализованы для дисков, использующих для хранения емкость вычислительных узлов (Local SEP). В релизе 4.7 эта модель была распространена на общие хранилища Shared SEP. Теперь физическое пространство под диск не резервируется при создании, а выделяется по мере записи данных и расширяется автоматически, без остановки виртуальной машины, что позволяет администратору использовать это пространство более эффективно. Связанные клоны хранят только изменения относительно базового эталонного образа — это заметно сокращает расход емкости дисков при массовом развертывании однотипных машин из общего образа, в том числе в сценариях VDI. Размещение снапшотов больше не требует постоянного участия пользователя: пул для моментальных снимков задается в конфигурации пула хранения, и платформа применяет его автоматически.</p> <p>Чтобы выделение тонких дисков не приводило к неожиданному исчерпанию емкости, платформа контролирует фактическое заполнение пула: при исчерпании более 75% администратор получает предупреждение, при 90% и выше — платформа уведомляет администратора и блокирует создание и увеличение дисков.</p> <p>Подключение нового узла к платформе было значительно упрощено, теперь это одно действие — вызов API или заполнение формы в портале. Далее платформа сама выполняет полный цикл регистрации и установки. Инсталлятор дополняет конфигурацию недостающей секцией с системой авторизации, а маршрутизация консольного доступа к виртуальным машинам обновляется динамически при добавлении узлов и изменении их статуса. Все перечисленное значительно упрощает работу администратора Basis Dynamix Enterprise 4.7 и снимает с него часть рутинной нагрузки.</p> <p>Для работы в совмещенном режиме, когда на одном физическом узле одновременно работают виртуальные машины и программно-определяемая система хранения, в Basis Dynamix Enterprise 4.7 появилась возможность резервировать процессорные ядра и оперативную память — на уровне ЦОДа, зоны или отдельного физического узла. Это дает предсказуемое распределение мощностей, так как часть ресурсов гарантированно остается доступной для программно-определяемых СХД, а не расходуется под виртуальные машины. Изменение настроек безопасно для работающей нагрузки, и увеличение резерва не приводит к остановке или перезапуску уже работающих машин. Дополнительно платформа следит за потреблением ресурсов на узлах и предупреждает администратора при достижении 80% и 90% потребления.</p> <p>Подключение PCI-устройств к виртуальным машинам в Basis Dynamix Enterprise 4.7 перенесено в интерфейс платформы. Теперь администратор видит на странице вычислительного узла список доступных для подключения устройств — платформа автоматически формирует его и поддерживает в актуальном состоянии. Устройство можно подключить к ресурсной группе или сразу привязать к конкретной машине, а переключение драйвера выполняется из портала или через API, без ручной правки конфигурации на узле. При подключении устройства доступны два режима: безопасный, применяемый после перезагрузки узла, и горячий, применяемый без перезагрузки, но способный нарушить работоспособность узла (платформа явно обозначает этот режим как рискованный). Возврат к системному драйверу выполняется только в безопасном режиме.</p> <p>Разные поколения процессоров на узлах одной площадки традиционно ограничивают миграцию виртуальных машин. Basis Dynamix Enterprise 4.7 помогает администратору снять это ограничение: платформа определяет поколение процессора каждого узла и позволяет администратору задать профиль выравнивания для группы вычислительных узлов (зоны). Профиль balanced дает возможность совместного использования процессоров разных поколений в рамках одной зоны — это помогает миграции ВМ между узлами, поддерживающими выбранное поколение виртуальных процессоров. Профиль compatible помогает осуществлять миграцию между всеми узлами одной зоны за счет автоматического выбора для этих узлов одного поколения CPU с минимальным набором инструкций (даже если физический узел поддерживает более современные поколения). Профиль выбирается при создании виртуальной машины.</p> <p>Собственный гипервизор является важной частью экосистемы «Базиса», и в релизе Basis Dynamix Enterprise 4.7 была реализована поддержка новейшего Basis vCore 2.1. В актуальной версии гипервизора были обновлены ядро и ключевые системные библиотеки, добавлены механизмы контроля целостности файловой системы (IMA) и реализована поддержка основных сервисов, обеспечивающих комплексную защиту и контроль сред контейнеризации. Кроме того, были расширены сетевые функции и поддержка программно-определяемых систем хранения, внедрены новые возможности управления пользователями, парольной политикой, SSH-доступом, а также оптимизирована работа установщика и конфигуратора.</p> <p>Аудиторские сообщения Basis Dynamix Enterprise 4.7 теперь передаются во внешние системы сбора и хранения журналов по протоколу Syslog в стандартном для передачи событий формате RFC 5424. Благодаря этому внешние системы, например, SIEM, могут автоматически обрабатывать сообщения от платформы и выдавать администратору более структурированную и понятную информацию об инциденте. Сообщения платформы могут передаваться в том числе в решение для защиты информации в среде виртуализации Basis Virtual Security с целью создания единого журнала событий. Одновременно реализована маскировка чувствительных данных: значения ключей и паролей автоматически скрываются как в параметрах, так и в результатах API-вызовов.</p> <p>Расширены сетевые возможности платформы — от управления группами доступа SDN и применения групп безопасности на уровне сетей до новых сценариев работы с сетями PRIVATE и мониторинга DPDK-инфраструктуры узла. Диски получили режим «только чтение» и управление обработкой команд TRIM/UNMAP на уровне пула и отдельного диска, уточнен учет больших страниц памяти.</p> <p>Длительные операции (клонирование, работа со снапшотами, резервное копирование и восстановление дисков) переведены на асинхронную обработку. В портале появились массовые действия над объектами и физическими узлами, обновлен ряд страниц и разделов, обновлен графический интерфейс планировщика ресурсов DRS.</p> <p>«Когда мы говорим о развитии платформы Basis Dynamix Enterprise, речь не только о ее функциональности. Не менее важная задача — сделать работу с ней более простой и удобной. В новом релизе 4.7 мы автоматизировали ряд сложных операций, которые раньше администратор выполнял вручную, как при развертывании, так и в повседневной эксплуатации. Платформа стала эффективнее распоряжаться дисковым пространством и вычислительными ресурсами, а администратор получил больше контроля над их распределением. Чем крупнее инсталляция у нашего заказчика, тем сильнее он почувствует эффект от новых возможностей платформы», — прокомментировал Дмитрий Сорокин, технический директор компании «Базис».</p> Компания «Базис» объявила о выпуске новой версии своей флагманской платформы серверной виртуализации Basis Dynamix … message https://www.itweek.ru/themes/detail.php?ID=235557 Wed, 16 Sep 2026 18:57:03 +0300 <p>Разработчик экосистемы инфраструктурного ПО Orion soft провел исследование готовности ИТ-инфраструктуры бизнеса к растущим темпам скорости разработки. Вендор опросил 107 респондентов-представителей крупного и среднего бизнеса из отраслей: нефтегазовая и химическая промышленность, финансы, металлургия, госсектор, торговля, энергетика и машиностроение.</p> <p>ИИ-ассистенты сегодня уже помогают писать код, генерировать тесты и готовить документацию значительно быстрее. Gartner прогнозирует, что к 2028 году 90% крупных компаний-разработчиков ПО будут использовать в работе искусственный интеллект по сравнению с 14% в 2024. При этом, исследование Orion soft показывает, что вывод продуктов на рынок (Time-To-Market) не ускоряется в соответствии с ростом темпов разработки — в двух из трех случаях его тормозит инфраструктура. 65% респондентов назвали главными факторами задержки задачи, не связанные с разработкой: согласование ИБ, ручная настройка, тестирование, ожидание окружения или ресурсов.</p> <p>Почти половина всех препятствий связана с информационной безопасностью — фактор назвали 47% опрошенных. Отсутствие стандартизации, согласованных шаблонов и описанных конкретных правил действий для разработчиков приводит к увеличению Time-To-Market. Другая важная проблема — ожидание ресурсов. 78% респондентов ожидают среду для разработки более одного рабочего дня после запроса. За это время разработчики могли бы сделать бОльшую часть работы с помощью ИИ-ассистентов и быстрее реализовать проект.</p> <p>Результаты исследования демонстрируют эволюционный разрыв между разработкой и ИТ-инфраструктурой. Финансовый масштаб этого разрыва особенно заметен на фоне инвестиций в цифровизацию. По данным ИСИЭЗ НИУ ВШЭ, подготовленным на базе сплошного обследования Росстата, в 2025 году крупные и средние российские организации направили на внедрение и использование цифровых технологий почти 5,9 трлн рублей. 37% этой суммы — около 2,2 трлн рублей — пришлось на программное обеспечение: лицензии, SaaS, разработку, доработку и адаптацию. При этом 86,6% расходов компании профинансировали собственными средствами. Поэтому ожидание инфраструктуры, ручная настройка и повторные согласования ИБ снижают отдачу не от абстрактного «ИТ-бюджета», а от уже оплаченных бизнесом инструментов и компетенций.</p> <p>В ответ на эту тенденцию на международном ИТ-рынке растет популярность платформенного инжиниринга — подход, которые помогает автоматизировать и стандартизировать процессы в инфраструктуре. Gartner также прогнозирует, что к текущему году 80% крупнейших мировых разработчиков ПО создадут отдельные команды для управления платформами, которые возьмут на себя сервисную функцию поставщиков инструментов для разработки. Быстрая выдача нужных ресурсов, готовые шаблоны, согласованные с политиками безопасности ресурсы и доступы — все это в совокупности с ИИ-ассистентами позволяет получить бизнесу конкурентное преимущество с ускорением Time-To-Market.</p> <p>«Платформенный инжиниринг — это не очередная попытка внедрить еще один инструмент. Это способ вернуть управляемость там, где инфраструктура, DevOps-процессы, требования ИБ и скорость бизнеса уже стали слишком сложными для ручного управления. Наши выводы подтверждают, что все больше крупных компаний нуждаются в IDP-подходе. Его главная ценность — скорость изменений становится не результатом героизма отдельных специалистов, а свойством всей инженерной системы», — отметил Павел Лавров, лидер продукта HyperDrive в Orion soft.</p> Разработчик экосистемы инфраструктурного ПО Orion soft провел исследование готовности ИТ-инфраструктуры бизнеса … message https://www.itweek.ru/themes/detail.php?ID=235549 Wed, 16 Sep 2026 10:07:03 +0300 <p><em>Как и мы, вы, вероятно, заметили, что за последние два года большинство дискуссий об искусственном интеллекте в промышленном производстве были сосредоточены на том, что большие языковые модели (LLM) могут сделать для инженеров, планировщиков и других специалистов умственного труда, пишут в корпоративном блоге вице-президенты, главные аналитики </em><em>Forrester</em> <em>Джордж Лоури и Мишель Пелино.</em></p> <p>Поставщики демонстрировали «вторых пилотов», которые обобщают документы, отвечают на вопросы и генерируют контент. Эти возможности важны, но, возможно, именно они в конечном итоге не обеспечат наибольшего влияния на бизнес производителей.</p> <p>В предыдущих исследованиях мы изучали важность для операционной устойчивости анализа с низкой задержкой и быстрого реагирования. Но теперь у нас есть новые цифровые промышленные платформы и развертывания ИИ, сочетающие промышленную автоматизацию, агентный ИИ и архитектуры, учитывающие особенности периферии.</p> <p>Наше текущее исследование передовых технологий ИИ в производстве начинается с простой гипотезы: производители создадут больше ценности, если ИИ будет непосредственно участвовать в циклах принятия оперативных решений, чем когда он будет использоваться в основном для поиска информации и генерации контента. Сами по себе модели не создают результатов. Реальная ценность заключается в рабочих процессах, управлении и возможностях выполнения, которые они обеспечивают. Для достижения этих результатов в масштабе производителям необходимы платформы, которые связывают ИИ с выполнением операционных задач.</p> <h3>Следующее поле битвы — гемба: почему промышленный ИИ должен сместиться на периферию</h3> <p>Специалисты по бережливому производству используют термин «гемба» для описания места, где создается ценность. Для производителей это означает производственные линии или ячейки, склады, ремонтные мастерские, логистические центры и сервисные центры. Именно здесь производители диагностируют отказы оборудования, сокращают риски или исключения, связанные с качеством, безопасностью и соответствием нормативным требованиям, корректируют производственные графики, определяют приоритеты технического обслуживания, управляют перебоями в поставках и координируют действия сервисных служб. Они принимают эти решения постоянно и в условиях нехватки времени. Специалист по техническому обслуживанию, устраняющий неполадки в критически важном оборудовании, руководитель, реагирующий на проблему качества, или планировщик, управляющий сбоем в производстве, не всегда могут позволить себе задержки в облаке, зависимости от подключения или длительные циклы обработки. Для них скорость, контекст, отказоустойчивость и доверие часто важнее масштаба модели.</p> <h3>Бóльшие модели не всегда лучше: переход от периферийной аналитики к периферийному интеллекту</h3> <p>В индустрии ИИ обращают много внимания на мощные передовые модели. Однако в производственных сценариях основное внимание часто уделяется переменным, которые модели упускают из виду, — таким факторам, как предсказуемое время отклика, операционная устойчивость или экономическая эффективность. Именно поэтому производители, как правило, внедряют передовые модели ИИ в рамках более широкой архитектуры, а не рассматривают их как универсальное решение. </p> <p>#IMAGE_235550#</p> <p>Формирующийся шаблон напоминает иерархию интеллекта:</p> <ul> <li> Передовые модели обеспечивают рассуждения, планирование и координацию.</li> <li> Специализированные промышленные модели предоставляют экспертные знания в области производства.</li> <li> Более мелкие модели, работающие на периферии, обеспечивают быструю локальную поддержку принятия решений (например, в вопросах технического обслуживания и безопасности).</li> <li> Механизмы оптимизации обеспечивают соблюдение инженерных, операционных и бизнес-ограничений.</li> </ul> <p>Фабрика будущего будет полагаться на множество форм интеллекта, работающих вместе, а не на одну доминирующую модель ИИ.</p> Как и мы, вы, вероятно, заметили, что за последние два года большинство дискуссий об искусственном интеллекте … article https://www.itweek.ru/themes/detail.php?ID=235546 Wed, 16 Sep 2026 09:56:46 +0300 <p><em>Кроссплатформенная разработка привлекает прежде всего скоростью запуска и экономией на старте. Через год-два те же проекты нередко требуют серьёзной переработки архитектуры. Рассмотрим, где закладывается технический долг в проектах на Flutter и KMP, по каким признакам понять, что проект теряет выгоду от кроссплатформенности, и как оценить риски до начала разработки.</em></p> <h3>Почему технический долг появляется не сразу</h3> <p>Проекты на Flutter и KMP часто выглядят успешно на старте: единая кодовая база, быстрые итерации, предсказуемая стоимость разработки. Архитектурные проблемы проявляются, как правило, позже — когда продукт начинает развиваться за рамками первоначального замысла.</p> <p>Именно тогда становится видна реальная структура расходов. Основные затраты возникают не во время разработки MVP, а в процессе развития приложения в течение нескольких лет. Добавление новых функций требует всё больше времени, количество платформенных исключений растёт, а изменения приходится вносить сразу в несколько частей системы. Именно поэтому оценивать выбор технологии только по стоимости запуска — значит не видеть большую часть картины.</p> <h3>Где возникает технический долг во Flutter-проектах</h3> <p>В проектах на Flutter технический долг обычно появляется там, где команда недооценила будущие платформенные интеграции. Пока приложение развивается в рамках заранее продуманной архитектуры, Flutter остаётся устойчивым решением. Проблемы начинаются, когда объём платформенной логики начинает расти быстрее, чем предполагалось на старте.</p> <p>Типичный сценарий: продукт запускается с простой архитектурой, потому что на старте это выглядит достаточным. Через год появляются сложные интеграции с нативными сервисами — камерой, геолокацией, биометрией, платёжными системами. Каждая такая интеграция добавляет платформенный слой, который нужно поддерживать отдельно. В итоге команда платит и за кроссплатформенную сложность, и за нативную сложность одновременно — то есть теряет главное преимущество Flutter.</p> <p>Вторая распространённая ошибка — строить архитектуру как временную, хотя продукт планируется развивать годами. «Сейчас сделаем быстро, потом перепишем» — это решение, которое почти никогда не реализуется. На быструю архитектуру начинают опираться другие части системы, и стоимость её переработки со временем только растёт.</p> <h3>Где возникает технический долг в KMP-проектах</h3> <p>В проектах на Kotlin Multiplatform основным источником технического долга обычно становятся неверно определённые границы между общей и платформенной логикой. Чем раньше допущена такая ошибка, тем дороже обходится исправление.</p> <p>Выглядит она почти всегда одинаково: команда стремится вынести в общий код максимально возможный объём логики. На старте это выглядит разумно — высокая доля переиспользования, меньше дублирования. По мере развития продукта начинают появляться платформенные особенности и исключения, которые не укладываются в эту схему. Каждое такое исключение добавляет сложность в общий модуль, и через некоторое время поддержка кроссплатформенной архитектуры становится дороже, чем выгода от неё.</p> <p>Избежать этого помогает один простой вопрос при проектировании каждого модуля: зависит ли эта логика от особенностей конкретной платформы? Если нет — кандидат на перенос в общий код. Если да — лучше оставить на платформенном уровне. Попытка перенести то, что по своей природе платформенное, неизбежно ведёт к усложнению системы.</p> <h3>Три сигнала, что проект теряет выгоду от кроссплатформенности</h3> <p>Первый сигнал — количество платформенных исключений начинает расти быстрее, чем объём общего кода. Команда всё чаще пишет отдельные реализации для iOS и Android, а общий слой перестаёт давать прежнюю экономию. Если раньше новая функция появлялась в общем модуле один раз, теперь приходится писать версию для каждой платформы отдельно.</p> <p>Второй сигнал — появление отдельных веток поведения для разных платформ. Формально приложение остаётся кроссплатформенным, но фактически развивается как два независимых продукта с общим именем. Это самый явный признак того, что первоначальный архитектурный выбор перестал соответствовать реальной структуре продукта.</p> <p>Третий сигнал — снижение скорости разработки. Если каждая новая функция требует всё больше согласований между слоями системы и всё чаще затрагивает платформенные особенности — первоначальная выгода от общего кода начинает сокращаться. Команда тратит больше времени на координацию, чем экономит на переиспользовании.</p> <h3>Как оценить риски до начала разработки</h3> <p>Технический долг закладывается в момент выбора архитектуры. Команда, которая изначально правильно определила границы применения технологии, получает меньше долга — вне зависимости от того, Flutter это или KMP.</p> <p>До начала разработки стоит ответить на несколько вопросов. Как часто будет меняться бизнес-логика? Чем выше частота изменений, тем важнее, чтобы архитектура позволяла вносить их быстро. Насколько отличаются сценарии между платформами? Чем сильнее различия, тем меньше смысла в общем коде. Какие интеграции появятся через год-два? Сложные нативные интеграции на старте не видны, но именно они чаще всего становятся источником технического долга.</p> <p>Подводя итог, можно отметить следующее: кроссплатформенный подход меняет структуру затрат, но не отменяет архитектурную сложность. Подготовленный на старте анализ жизненного цикла продукта позволяет увидеть большую часть будущих проблем — и заложить в архитектуру решение заранее, а не разбираться с ним после релиза.</p> <p>#IMAGE_235547#</p> Кроссплатформенная разработка привлекает прежде всего скоростью запуска и экономией на старте. Через год-два те же … article Алексей Артамонов, директор Nord Clan https://www.itweek.ru/themes/detail.php?ID=235544 Wed, 16 Sep 2026 09:50:45 +0300 <p><em>За последние четыре года многие российские компании перевели часть ИТ-инфраструктуры на отечественное оборудование и программное обеспечение. Но значительный объём зарубежных решений по-прежнему остаётся в эксплуатации. Их поддержка становится сложнее и дороже: всё большее значение приобретают доступность запасных частей, логистика и инженерная экспертиза сервисных команд. Главный вопрос теперь не в том, сколько лет системе, а в том, можно ли обеспечить её дальнейшую эксплуатацию без участия производителя. Рассмотрим, где проходит эта граница и что может стать для рынка точкой невозврата.</em></p> <h3>Возраст не проблема: что действительно волнует бизнес</h3> <p>За последние годы возраст оборудования перестал быть ключевым фактором для бизнеса. Срок эксплуатации зарубежных ИТ-решений у заказчиков вырос и в среднем составляет более 5 лет. Высокотехнологичное оборудование может работать в парке организаций даже десятилетиями — такая практика постепенно становится новой нормой. Для многих компаний такие системы остаются критически важными: они глубоко интегрированы в инфраструктуру, а их замена требует значительных инвестиций и сложной миграции. При формировании бюджетов специалисты учитывают срок гарантии оборудования, историю инцидентов и совокупную стоимость технической поддержки.</p> <p>При продолжительной эксплуатации зарубежного оборудования компаниям необходимо заранее оценивать доступность запасных частей и потенциальные расходы в случае критических отказов. Современные системы мониторинга позволяют отслеживать состояние инфраструктуры, выявлять её узкие места и своевременно реагировать на признаки неисправностей. Поэтому главным ограничением становится уже не обслуживание зарубежных решений как таковое, а наличие сервисных организаций с необходимой технической экспертизой.</p> <h3>Комплексный подход: как и с кем работает бизнес</h3> <p>Отдавать критически важную инфраструктуру на обслуживание одной организации готовы далеко не все. Как правило, крупные компании распределяют задачи между собственной службой поддержки и несколькими внешними подрядчиками. В исследовании OCS 80% участников отметили, что имеют собственную службу поддержки, однако её возможностей зачастую недостаточно для решения всех сервисных задач.</p> <p>Одновременно меняются и модели взаимодействия с внешними исполнителями. Вместо фиксированной оплаты по договору компании проявляют интерес к более гибким вариантам: 34% респондентов рассматривают платежи за конкретный кейс, а 44% склоняются к смешанной модели работы. Опрос показал, что требования к сервисным партнёрам возросли и в отдельных случаях оказываются строже, чем требования к сервису ушедших мировых производителей. Компании стремятся снизить возможные риски ещё на этапе выбора подрядчика. Одним из критериев становится наличие и состав склада ЗИП: его аудит всё чаще включают в техническое задание. Далеко не все запчасти для технологически сложных решений можно оперативно доставить в Россию, а их отсутствие в критический момент приводит к простоям и убыткам.</p> <p>Не менее важен региональный охват сервисной компании. Для оперативного реагирования на инциденты по всей России подрядчику необходима территориально распределённая команда, способная обеспечить требуемые сроки обслуживания в разных регионах. Региональный охват и склады ЗИП входят в число важнейших факторов при выборе сервисной организации для 60% компаний. При этом главным критерием остаётся инженерная экспертиза. Для каждой четвёртой компании опыт и квалификация подрядчика приоритетнее цены на его услуги.</p> <h3>Компетенции: риски и перспективы</h3> <p>Квалификация сервисных специалистов — один из важнейших факторов устойчивости отрасли. Раньше ведущие мировые производители регулярно проводили для российских инженеров обучение по своим решениям, но после 2022 года такие программы существенно сократились. В результате развитие инженерных компетенций всё больше зависит от ресурсов самих участников рынка. Даже если штат укомплектован специалистами, новые сотрудники могут потребоваться для расширения сервисной сети в условиях растущего спроса. Запчасти можно закупить и оперативно разместить на складе, а подготовка специалистов с необходимой квалификацией занимает годы. Дополнительную сложность создаёт быстрое развитие технологий: на мировом рынке появляются новые поколения оборудования, тогда как доступ российских инженеров к обучению по зарубежным решениям остаётся ограниченным.</p> <p>Значительная часть задач по сохранению и развитию технической экспертизы постепенно переходит к крупным дистрибьюторам, интеграторам и сервисным компаниям. Такие игроки десятилетиями развивали технические команды и собственные базы знаний. Обладая большим опытом работы с зарубежным оборудованием, они могут передавать накопленную экспертизу партнёрам и использовать её при работе — в том числе с российскими решениями. При этом подготовка нового поколения инженеров остаётся долгосрочной задачей для всей отрасли. Без системной передачи знаний рынок со временем может столкнуться с дефицитом специалистов, способных обслуживать высокотехнологичное оборудование. Именно кадровый фактор в перспективе может стать главным ограничением для поддержки зарубежных решений.</p> <h3>Главный ресурс рынка</h3> <p>За последние годы российский рынок сервисного обслуживания адаптировался к работе без прямой поддержки части зарубежных производителей. Компании заранее планируют бюджеты на обслуживание, ответственнее выбирают подрядчиков, оценивают наличие запасных частей и используют системы мониторинга для контроля состояния инфраструктуры.</p> <p>Однако дальнейшая устойчивость рынка зависит не только от доступности оборудования и комплектующих. Ключевым ресурсом становится инженерная экспертиза и способность отрасли сохранять и передавать накопленные знания. Если рынок сможет обеспечить воспроизводство этих компетенций, обслуживание зарубежной ИТ-инфраструктуры ещё долго останется технически выполнимой задачей. Поэтому главным активом сервисных компаний сегодня становятся не только склады запасных частей и отлаженные процессы, но прежде всего специалисты и накопленная ими экспертиза.</p> <p>#IMAGE_235545#</p> За последние четыре года многие российские компании перевели часть ИТ-инфраструктуры на отечественное оборудование … article Никита Кузнецов, руководитель отдела сервиса профессиональных систем OCS https://www.itweek.ru/themes/detail.php?ID=235543 Tue, 15 Sep 2026 13:38:49 +0300 <p>Компания IT_ONE создала собственную методологию для выбора ИИ-инструментов и управления ими на всех этапах жизненного цикла разработки ПО (SDLC, Software Development Life Cycle). Решение позволяет систематизировать использование ИИ-моделей и повысить производительность команды разработки на <nobr>30-40%.</nobr></p> <p>Внедрение ИИ-инструментов в процессы разработки в большинстве компаний происходит стихийно: либо инициативу проявляют отдельные специалисты, либо решение централизованно «спускается сверху» и используется сотрудниками с разной степенью успешности. Чтобы выйти на принципиально новый уровень применения ИИ на всех этапах SDLC, специалисты IT_ONE создали комплексный фреймворк.</p> <p>Методология включает в себя пять ключевых этапов: декомпозицию SDLC на этапы (аналитика, разработка, тестирование, развертывание, стабилизация) и активности внутри этих этапов, оценку применимости ИИ для каждой задачи, описание системы навыков ИИ (скиллов), валидаций и ограничений, измерение эффективности, создание стандартизированных инструкций.</p> <p>Таким образом, фреймворк дает команде разработки полное и четкое представление о том, как применять ИИ в рамках той или иной активности и позволяет спрогнозировать результат действия модели и ее эффективность.</p> <p>«Мы проанализировали публичные методологии и гайды вендоров и не нашли готового решения такого типа — связующего слоя, который для каждой активности SDLC определяет, какой ИИ-инструмент применять, как валидировать результат, как контролировать риски и сколько это экономит трудозатрат. Поэтому мы построили такой фреймворк сами — как воспроизводимую методологию, а не закрытый внутренний регламент», — прокомментировал Кирилл Хрушков, CIO компании IT_ONE.</p> <p>Одно из главных преимуществ фреймворка — воспроизводимость. Он спроектирован как онбординг-инструмент: новый сотрудник проходит по гайду, получает предсказуемый результат и ожидаемый уровень эффективности.</p> <p>Внедрение фреймворка позволило компании IT_ONE повысить производительность команды разработки на <nobr>30-40 %.</nobr> Кроме того, методология способствует сохранению высокого качества кода при ускорении его создания и упрощению адаптации новых сотрудников.</p> <p>Применение фреймворка не зависит от конкретных вендоров ИИ-моделей и предусматривает подбор наиболее подходящих ИИ-инструментов с учетом выхода новых версий.</p> Компания IT_ONE создала собственную методологию для выбора ИИ-инструментов и управления ими на всех этапах жизненного … message https://www.itweek.ru/themes/detail.php?ID=235542 Tue, 15 Sep 2026 09:45:16 +0300 <p><em>Рекурсивное самосовершенствование (</em><em>recursive</em> <em>self</em><em>-</em><em>improvement</em><em>, </em><em>RSI</em><em>) </em><em>позиционируется как следующая важная веха в развитии искусственного интеллекта. Если оно когда-либо будет достигнуто, его влияние будет ощущаться во всей индустрии центров обработки данных и далеко за её пределами, считают опрошенные порталом </em><em>Data</em> <em>Center</em> <em>Knowledge</em> <em>эксперты.</em></p> <p>RSI описывает системы ИИ, которые могут проектировать, кодировать и развертывать своих преемников с минимальным участием человека. В случае его достижения улучшения могут быстро накапливаться, поскольку более интеллектуальные модели порождают ещё более интеллектуальные поколения — потенциально ускоряясь за пределы человеческого понимания и, что вызывает беспокойство, контроля. Для операторов дата-центров RSI будет иметь последствия в плане электропитания, охлаждения, оркестрации, управления и сертификации.</p> <h3>Что такое RSI и куда оно движется</h3> <p>Хотя RSI имеет расплывчатое определение, как и общий искусственный интеллект (AGI), есть признаки того, что оно приближается к реальности. Достижение RSI зависит от быстрого прогресса в кодировании с помощью ИИ, который, по словам лабораторий, уже наблюдается. Например, компания Anthropic, занимающаяся разработкой передовых моделей ИИ, в своем <a href="https://www.anthropic.com/institute/recursive-self-improvement">отчете</a> под названием «When AI Builds Itself» утверждает, что ее модель Claude теперь сама пишет значительную часть своего кода: «По состоянию на май 2026 г. более 80% кода, который мы объединяем с кодовой базой Anthropic, был написан Claude. До запуска Claude Code в режиме предварительного тестирования в феврале 2025 г. эта цифра составляла несколько процентов». Если такая поддержка сохранится, это станет шагом к созданию систем, способных к самосовершенствованию.</p> <p>Что касается аппаратной части, то такие прорывы, как квантовые вычисления, могут катализировать кардинальные изменения в RSI или AGI. «В мире рекурсивного ИИ это, по сути, задача оптимизации. Какой ИИ является лучшим? Какая нейронная сеть для моделей ИИ станет лучшей в будущем? Квантовые вычисления могут помочь в этом, — говорит Джей Гилмарт, ведущий менеджер по продуктам компании Q-CTRL. — Существует алгоритм, называемый алгоритмом Гровера, который очень хорошо справляется с поиском в пространствах с большим количеством параметров. Он может поддерживать рекурсивные операции, чтобы помочь системе работать лучше и быстрее выбирать наилучший вариант».</p> <p>Если ИИ сможет на постоянной основе создавать улучшенные версии самого себя, последствия для физической инфраструктуры будут немедленны. Что это означает для жизненных циклов ИТ-оборудования, энергопотребления, управления рабочими нагрузками и того, как мы проектируем и эксплуатируем дата-центры?</p> <p>«Сама по себе основная концепция самосовершенствующихся систем не нова, — говорит Джон О’Брайен, старший аналитик Uptime Institute. — Сейчас ситуация отличается тем, что... достижения в моделях и инфраструктуре ИИ позволяют предположить, что мы достигли точки, когда некоторые из этих теоретических рассуждений становятся технически осуществимыми — или скоро станут таковыми».</p> <p>Практический подход к RSI отличает системы, которые действительно создают и развертывают новый код, от тех, которые постоянно самооптимизируются, не переписывая себя. Последние уже появляются в дата-центрах, часто с использованием обучения с подкреплением (RL). «Успешные приложения ИИ в центрах обработки данных сегодня часто применяют RL, хорошо зарекомендовавшую себя технику машинного обучения, которая использует штрафы и вознаграждения на основе обратной связи от окружающей среды, — говорит О’Брайен. — Это может хорошо работать в замкнутых системах, где параметры определены, например, охлаждение дата-центра, ИТ и электропитание».</p> <p>Системы, способные к самосовершенствованию на месте, уже появляются. «Стартапы Emerald AI и Phaidra совершают прорывы в ранних пилотных проектах и ​​демонстрациях, показывая потенциал динамических самосовершенствующихся систем», — добавляет О’Брайен.</p> <p>Автономные улучшения, особенно в энергопотреблении, являются целью новой волны программных платформ для управления дата-центрами, соглашается старший аналитик 451 Research Зои Рот. «Такие игроки, как Phaidra, etalytics и Vigilent, уже доказывают, что ИИ с замкнутым контуром может непрерывно оптимизировать физические параметры объекта в режиме реального времени, — говорит она. — Современные ИИ-механизмы, такие как Phaidra, выступают в качестве автономных уровней управления поверх существующих систем охлаждения (системы управления зданием, BMS) и электропитания (системы управления электропитанием, EPMS). Они не переписывают собственный код, но переобучают и обновляют нейронные сети на основе телеметрии датчиков реального времени».</p> <h3>Влияние на центры обработки данных</h3> <p>Для операторов ЦОДов самооптимизация обещает ощутимые преимущества в мониторинге и техническом обслуживании. «Сегодня для технического обслуживания на основе состояния требуется значительный исторический набор данных, прежде чем можно будет с уверенностью определить риск возникновения неисправностей, — говорит Алекс Кордовил, директор по исследованиям Dell’Oro. — Система, которая улучшает свой собственный опыт работы, может обеспечить это гораздо быстрее и эффективнее, с реальным увеличением времени безотказной работы и производительности».</p> <p>Но это поднимает сложный вопрос: как сертифицировать ПО, которое постоянно меняется? «Я не понимаю, как сертифицировать программный пакет или агент ИИ, который признан способным выполнять обязанности по управлению дата-центром и который вы должны контролировать», — говорит Кордовил. На практике это может потребовать постоянного повторного утверждения моделей или непрерывного мониторинга и контроля отката, при котором в процесс вовлечены люди, что снижает некоторые преимущества в плане эффективности.</p> <p>Самосовершенствующийся ИИ, переключающийся между обучением и инференсом, может также усугубить и без того значительные колебания энергопотребления в дата-центрах, обслуживающих ИИ-нагрузки. «Постоянное синхронное обучение совершенно не похоже на инференс: большие парки устройств синхронно колеблются между почти холостым и почти пиковым режимами, потребляя от десятков до сотен мегаватт с частотой в доли герца», — отмечает Кордовил. — Постоянным требованием при проектировании станет парк, который одновременно занимается обучением и инференсом, а не проблема кластеров для обучения«.</p> <h3>Стратегические перспективы и влияние на отрасль</h3> <p>Помимо краткосрочных проектных решений, RSI может изменить динамику отрасли. «Системы, которые могут программировать и проектировать своих преемников, будут иметь огромные последствия для тех, кто проектирует, строит и производит инфраструктуру дата-центров, — считает О’Брайен. — Захотят ли они автоматизировать половину своей рабочей силы? Как это повлияет на их бизнес?»</p> <p>Пока что концепция RSI остается на начальной стадии развития. Но если она когда-нибудь будет реализована, последствия — как положительные, так и отрицательные — выйдут далеко за рамки самих моделей, изменив весь стек ИИ и оказав влияние на общество. Один из правдоподобных сценариев предполагает, что ИИ не только будет создавать более мощных преемников, но и проектировать и даже изготавливать дата-центры, которые будут их размещать. В этом случае самооптимизирующиеся и самовоспроизводящиеся центры обработки данных для ИИ столкнутся с трудностями в регулировании, сертификации, обеспечении безопасности и общественном признании. Расширение ИИ уже сейчас кажется слишком быстрым для многих сообществ; RSI может еще больше ускорить этот процесс.</p> Рекурсивное самосовершенствование (recursive self-improvement, RSI) позиционируется как следующая важная веха в развитии … article https://www.itweek.ru/themes/detail.php?ID=235539 Tue, 15 Sep 2026 00:00:00 +0300 <p>Вступление в силу приказа ФСТЭК России № 117 весной 2026 года ознаменовало тихую революцию в требованиях к защите государственных информационных систем (ГИС), ресурсов органов государственной власти и всех субъектов, подпадающих под регулирование ФСТЭК. Ведомство изменило концепцию контроля подключения пользователя, на которой строилась безопасность в госсекторе последние двадцать лет. Привычная модель, где защищенный канал и контроль сетевого подключения считались основой доверия, теперь признана недостаточной. Сетевой адрес при этом остается одним из параметров контроля, но сам по себе не позволяет достоверно установить физическое местоположение пользователя.</p> <p>И это лишь половина проблемы. Оператор ГИС обязан не только устанавливать реальное местоположение того, кто подключается, но и лично отвечать за реализацию всех мер защиты. Переложить эту обязанность на аутсорсера, прописать в договоре с удаленным сотрудником или передать подрядчику невозможно. Ответственность неделима и остается на владельце системы. Для ИБ-директоров госструктур и операторов ГИС это означает, что привычная связка VPN и терминального сервера больше не закрывает риски регулятора и бизнеса.</p> <h3>Архитектурный тупик: почему классическая защита больше не работает</h3> <p>До сих пор защита удаленного периметра в государственных учреждениях создавалась по классической схеме: построить шифрованный VPN-туннель, запросить второй фактор (2FA) и проверить IP-адрес подсети. Если трафик идет из условного пула российских провайдеров, то система считает точку подключения доверенной.</p> <p>Приказ № 117 разрушает эту цепочку. Требование осуществлять удаленный доступ к государственным информационным системам через сети связи, расположенные на территории РФ, с использованием выделенных оператором программно-аппаратных средств и защищенных каналов передачи данных высветило главную уязвимость сетевого уровня. Это — ограниченная достоверность GeoIP-идентификации для допуска к работе.</p> <p>В современных реалиях IP-адрес может указывать физическое местонахождение пользователя лишь косвенно и с большим количеством допущений. Коммерческие и частные VPN-сервисы легко пробрасывают трафик из любой точки мира через точки присутствия внутри РФ. Промежуточные терминальные узлы и VPS/VDS позволяют развернуть прокси-сервер на российском хостинге за 15 минут, маскируя работу из зарубежных юрисдикций.</p> <p>В результате ИБ-служба ведомства видит легитимный IP-адрес провайдера, тогда как фактически сессия администратора или подрядчика может быть инициирована где-то в другой стране или незащищенной публичной Wi-Fi-сети. В сегментах с информацией ограниченного распространения, включая сведения «Для служебного пользования» (ДСП), подобная слепая зона превращается в прямую угрозу безопасности и критический регуляторный риск.</p> <p>Но этим проблема не исчерпывается. Операторы ГИС фактически встают перед архитектурной дилеммой. Первый путь — строить полноценный узел связи и доступа к ГИС, разворачивая контролируемую зону с собственной инфраструктурой геоконтроля, что неизбежно ведет к кратному росту капитальных и эксплуатационных затрат. Второй — оснастить контроллерами рабочее место каждого удаленного сотрудника, создавая распределенную систему контроля физического местоположения. Оба варианта требуют серьезных финансовых вложений, организационной перестройки процессов и пересмотра всей логики построения защищенного удаленного доступа. При этом выбрать какой-то один из них, не имея четких методических рекомендаций регулятора, — рискованно, а не выбрать вообще — невозможно.</p> <h3>От защиты канала к защите конечной точки</h3> <p>Попытки выстроить гео-контроль на стороне ведомственной сети являются борьбой с последствиями, а не причиной. Рабочий способ достоверно выполнить нормативные акты ФСТЭК России — это перенести вектор контроля непосредственно на конечное устройство доступа.</p> <p>Новая модель безопасности перераспределяет доверие. Если раньше проверялся канал, то теперь проверяется контекст среды:</p> <ol> <li> <strong>Где физически находится устройство?</strong> Использование комбинированных аппаратных и программных механизмов определения местоположения устройства позволяет получать дополнительные данные о фактической точке подключения и сопоставлять их с сетевыми параметрами соединения. Это снижает зависимость контроля местоположения от одного только IP-адреса и связанных с ним механизмов GeoIP.</li> <li> <strong>Что это за устройство?</strong> Переход к модели доверенного цифрового рабочего места исключает использование несанкционированных личных ноутбуков и рабочих станций для доступа к защищаемым ресурсам. Устройство, с которого устанавливается соединение, должно соответствовать установленным требованиям защиты и контролироваться оператором информационной системы.</li> <li> <strong>Не изменены ли настройки безопасности?</strong> Непрерывный мониторинг целостности прошивки, операционной системы и сетевого окружения осуществляется прямо во время сессии.</li> </ol> <h3>Проблема внешнего контура: почему сторонний ноутбук может быть опасен</h3> <p>Развитие крупных федеральных ИТ-проектов создало сложные экосистемы, которые объединяют интеграторов, разработчиков ПО, сервисные организации и специализированных подрядчиков. Выдача традиционного VPN-доступа к ГИС на сторонний ноутбук создает неуправляемый вектор атаки по нескольким причинам.</p> <p>Во-первых, использование портативного компьютера подрядчика для удаленного доступа требует согласно приказу ФСТЭК № 117 соблюдения установленных требований к защите конечного устройства, включая наличие антивирусной защиты. При этом после установления защищенного туннеля такое устройство получает доступ во внутренний контур государственного ведомства, что повышает требования к контролю состояния и защищенности конечной точки.</p> <p>Во-вторых, ИБ-служба госоргана не обладает административными полномочиями на устройстве подрядчика. Она не может форсировать установку обновлений операционной системы, контролировать наличие агентов EDR, блокировать стороннее ПО или запрещать использование отчуждаемых носителей.</p> <p>В-третьих, стороннее устройство может одновременно поддерживать активный туннель в государственную информационную систему и иметь открытый доступ в незащищенный интернет или локальную сеть подрядчика.</p> <p>Масштаб этой угрозы подтверждают данные центра исследования киберинцидентов <a href="https://bi.zone/news/pochti-tret-atak-s-shifrovaniem-proiskhodit-iz-za-nezashchishchennykh-podryadchikov/" target="_blank">BI.ZONE DFIR</a>. В 2025 году доля атак с компрометацией инфраструктуры или уничтожением данных через неконтролируемых подрядчиков и цепочки поставок выросла вдвое — с 15% до почти 30% от всех зафиксированных расследований. А согласно исследованию <a href="https://ptsecurity.com/research/analytics/russia-cyberthreat-landscape-2026/" target="_blank">Positive Technologies</a>, компрометация доверенных отношений между организациями и подрядчиками стала главным драйвером атак на критическую инфраструктуру и госсектор.</p> <p>Решением этой коллизии для государственных структур становится переход к другому формату доступа. На смену попыткам изолировать программное обеспечение на чужом ПК приходят аппаратно-программные комплексы на базе специализированных тонких клиентов с преднастроенной и неизменяемой средой. Это дает возможность жестко зафиксировать конфигурацию аппаратного обеспечения, заблокировать попытки манипуляции сетевым стеком и снимать телеметрию геопозиционирования, не фальсифицируемую на уровне устройства доступа. В этой схеме подрядчик получает полностью изолированную от его локальной сети рабочую среду, а оператор ГИС и регулятор — 100%-ную прозрачность действий любого внешнего пользователя.</p> <h3>Что делать операторам ГИС?</h3> <p>Приказ ФСТЭК России № 117 — это не временная формальность, а отражение долгосрочного тренда на построение архитектуры «нулевого доверия» (Zero Trust) для всех государственных структур, ведомств и организаций, подпадающих под требования регулятора. Чтобы привести системы в соответствие с новыми нормами без остановки операционных процессов, операторам ГИС рекомендуется сделать три шага:</p> <ol> <li><strong>Провести аудит схем подключения внешних пользователей</strong>. Оценить реальную долю терминальных серверов и VPN-подключений, где идентификация строится только по IP-адресу.</li> <li><strong>Пересмотреть требования к рабочим местам подрядчиков</strong>. Включить в контракты обязательные условия по использованию доверенных устройств с контролируемым геопозиционированием.</li> <li><strong>Перейти на экосистемный подход к управлению конечными точками.</strong> Внедрять специализированные российские решения (тонкие клиенты, платформы централизованного управления), способные непрерывно подтверждать доверенность устройства и его локацию без усложнения администрирования.</li> </ol> <p>Эра, когда безопасность ГИС и государственной инфраструктуры гарантировалась защищенным соединением между двумя IP-адресами, прошла. Победу в новой реальности одержат те, кто первым научится контролировать не просто факт подключения, а конкретную физическую точку, в которой инициирован доступ к системе.</p> <p>#IMAGE_235540#</p> Вступление в силу приказа ФСТЭК России № 117 весной 2026 года ознаменовало тихую революцию в требованиях … article Василий Шубин, директор по управлению продуктовым портфелем компании Getmobit