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=234811 Wed, 13 May 2026 16:28:14 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ выпустил в серии «Будущее науки» новый аналитический доклад, который обобщает результаты первого этапа проекта, посвященного комплексному изучению ИИ-трансформации российской науки.</p> <p>Контекст и задачи исследования: согласно международным опросам, ИИ в научных исследованиях уже используют <nobr>76–78%</nobr> ученых, чаще всего — для поиска литературы и ее обобщения, редактирования собственных текстов, сбора и анализа данных, генерации идей. Помимо представления о масштабах применения ИИ учеными, важно понимать, что ими движет, когда они выбирают (или не выбирают) ИИ для работы, какие именно технологии и решения и как именно они используют, какие позитивные эффекты и риски фиксируют. Эмпирической базой исследования, результаты которого представлены в докладе, послужили материалы глубинных интервью с ведущими учеными — лидерами в различных областях науки по показателям публикационной активности и цитируемости, руководителями крупных научных коллективов (N=30, июнь — октябрь 2025).</p> <p>Применение ИИ в российской науке пока неоднородно. По оценкам респондентов, интенсивность использования ИИ существенно варьирует по областям науки: активнее всего с такими технологиями работают представители естественных и медицинских наук. Также уровень использования зависит от возраста ученых (более характерно для молодежи) и их роли в исследовательском процессе — чаще ИИ применяют те, кто задачи выполняют, а не ставят, что связано со спецификой решаемых при помощи ИИ задач.</p> <p>Ведущие российские ученые следят за новыми цифровыми инструментами для науки и стараются осваивать по мере их появления. Большинство респондентов обратились к технологиям ИИ <nobr>1–3</nobr> года назад, как только они стали доступными для пользователей. Все опрошенные ученые начали применять ИИ по собственному желанию, без какого-либо внешнего принуждения. Среди мотивов можно выделить три главных — прагматику (желание сэкономить время, потребность оптимизировать решение исследовательских задач и др.), личный интерес (любопытство, стремление к новым знаниям и опыту) и следование социальным трендам, желание не отстать от других.</p> <p>Универсальные ИИ-сервисы (GigaChat, AliceGPT (ранее — YandexGPT), ChatGPT, DeepSeek, др.) облегчают ученым работу с текстом (генерация драфтов разделов публикаций или отчетов, редактирование, перевод), информацией (поиск, систематизация, анализ данных) и кодом (генерация кода для анализа данных, создания визуализаций). Такие сервисы, по мнению респондентов, востребованы примерно в равной степени во всех областях науки и применяются в том числе для решения административных задач. А вот специализированные ИИ-инструменты и архитектуры активнее используют в естественных и медицинских науках (например, для каталогизации галактик, тестирования лекарств, создания собственных прогностических моделей).</p> <p>Главный позитивный эффект от применения ИИ — экономия времени благодаря делегированию ИИ-сервисам технических, «несутевых» задач. К другим значимым эффектам респонденты отнесли сокращение расходов, рост качества научных текстов на английском языке и, как следствие, повышение шансов на публикацию в высокорейтинговых зарубежных журналах, а также новые возможности для анализа данных.</p> <p>Риски использования ИИ в науке пока носят гипотетический характер. Опрошенные выделили среди главных опасений возможность утраты критического мышления и других исследовательских компетенций; рост потока низкокачественных научных публикаций, который ведет к увеличению нагрузки на ученых, в том числе из-за необходимости их рецензирования; нарушения научной этики; усиление неравенства между организациями с разным уровнем ресурсной обеспеченности.</p> <p>Препятствовать дальнейшему распространению ИИ в российской науке могут, по мнению респондентов, барьеры, которые можно отнести к пяти типам: 1) технические (качество и функциональность доступных ИИ-сервисов, нехватка вычислительных мощностей и оборудования); 2) ограниченность объема и качества данных для обучения новых моделей; 3) состав научного коллектива (нехватка компетенций, отсутствие медиаторов между учеными-предметниками и разработчиками ИИ); 4) факторы научной среды (короткий цикл и дробный характер финансирования, избыточная отчетность, отсутствие налаженного диалога между наукой и бизнесом); 5) личностные факторы (технологическая апатия, предубеждения, желание сохранить контроль над научным процессом).</p> <p>Минимизировать действие указанных барьеров может в том числе участие государства. Респонденты выделили три направления, в которых оно было бы продуктивным: 1) правовое (урегулирование вопросов интеллектуальной собственности и др.); 2) образовательное (организация обучающих лекций, семинаров и др.); 3) финансовое (обеспечение долгосрочного финансирования научных коллективов, оплата подписок на ИИ-сервисы, др.). Основной запрос — на поддерживающие, а не контролирующие меры. При этом ученые единодушно отвергают как принуждение к использованию ИИ, так и прямые запреты. По их мнению, нормы применения ИИ в науке должны быть выработаны самим научным сообществом в ходе профессионального обсуждения.</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ выпустил в серии «Будущее науки» новый … message https://www.itweek.ru/themes/detail.php?ID=234810 Wed, 13 May 2026 16:20:52 +0300 <p>Компания «Индид» представила Indeed ITDR 2.1 (Indeed Identity Threat Detection and Response) — продукт для своевременного выявления и реагирования на угрозы, связанные с компрометацией айдентити. Ключевые обновления новой версии направлены на повышение устойчивости корпоративной инфраструктуры и расширение сценариев защиты учетных данных.</p> <p>Indeed ITDR — решение класса Identity Threat Detection and Response, которое обеспечивает непрерывный мониторинг использования учетных данных на уровне сетевых протоколов аутентификации, выявляет аномалии и позволяет оперативно реагировать на подозрительную активность.</p> <p>Одним из ключевых обновлений Indeed ITDR стала поддержка геораспределенных инфраструктур. Разработчик реализовал механизм сегментации, при котором узлы обнаружения и контроллеры домена логически связываются внутри заданных сегментов. Это помогает избежать нежелательных маршрутов с высокой задержкой и обеспечивает стабильную обработку трафика в распределенной среде. По умолчанию сегментация строится с помощью механизма Active Directory Sites, что упрощает внедрение продукта в существующий ИТ-ландшафт организации. При этом администратор может самостоятельно задавать сегменты под нестандартные требования инфраструктуры, сохраняя гибкость настройки и контроль над схемой взаимодействия компонентов. В результате повышается отказоустойчивость и предсказуемость работы системы без усложнения ее внедрения.</p> <p>В новой версии 2.1 компания «Индид» расширила возможности контроля доступа за счет обработки LDAPS-трафика — защищенного варианта протокола LDAP, при котором обмен данными выполняется через зашифрованный TLS-туннель. Поддержка протокола LDAPS соответствует обязательным требованиям к безопасности и снижает риск компрометации учетных данных. Анализ выполняется через TLS terminating proxy: на узле обнаружения трафик расшифровывается, проверяется и затем повторно шифруется при передаче на контроллер домена. Для активации достаточно установить TLS-сертификат на узел управления и обновить скрипт на контроллерах домена. Это помогает устранить «слепые зоны» в мониторинге запросов аутентификации, позволяет выявлять использование незашифрованного LDAP и ограничивать небезопасные сценарии работы с учетными данными.</p> <p>Еще одно важное обновление — интеграция Indeed ITDR с системой Indeed Access Manager (Indeed AM) для централизованного управления доступом и многофакторной аутентификацией (MFA). Если в организации уже используется Indeed AM, новые сценарии MFA на базе Indeed ITDR можно внедрять быстрее: система задействует ранее зарегистрированные аутентификаторы и не требует повторной настройки для пользователей.</p> <p>В версии Indeed ITDR 2.1 все запросы на подтверждение дополнительного фактора автоматически направляются в Indeed AM. Это позволяет расширять покрытие MFA без лишней нагрузки на пользователей и администраторов, используя уже настроенные механизмы подтверждения. Интеграция поддерживает версии Indeed AM 8.X и 9.X, а подтверждение выполняется через push-уведомления в приложении Indeed Key.</p> <p>Дополнительные улучшения продукта направлены на повышение удобства эксплуатации и эффективности работы Indeed ITDR. Улучшена производительность консоли управления, расширены возможности настройки аутентификации, упрощены процессы обновления и переустановки решения. Также доработаны алгоритмы обнаружения атак, включая распространенные сценарии, такие как Kerberoasting, AS-REP Roasting и Password Spraying. Система стала точнее выявлять повторяющиеся подозрительные события и фиксировать попытки использования небезопасных протоколов, что позволяет быстрее реагировать на потенциальные угрозы.</p> <p>«Мы развиваем Indeed ITDR так, чтобы продукт можно было органично внедрять в разные инфраструктуры независимо от их масштаба, распределенности и уровня зрелости. Indeed ITDR уже интегрируется без установки агентов на рабочие станции и без изменения сетевой топологии, а новый функционал в версии 2.1 делает этот процесс еще гибче. На практике это означает более быстрый запуск сценариев защиты айдентити, меньше изменений в привычных процессах и предсказуемую работу даже в сложных архитектурах. Такой подход помогает организациям последовательно усиливать Identity Security и выстраивать комплексную защиту учетных данных без лишнего усложнения инфраструктуры», — отметил Лев Овчинников, руководитель продукта Indeed ITDR в компании «Индид». </p> Компания «Индид» представила Indeed ITDR 2.1 (Indeed Identity Threat Detection and Response) — продукт для своевременного … message https://www.itweek.ru/themes/detail.php?ID=234809 Wed, 13 May 2026 15:59:55 +0300 <p>В рамках ежегодного исследования уровня информационной безопасности (ИБ) в компаниях России эксперты «СёрчИнформ» выяснили, как за год изменилась ситуация с ИБ-кадрами в российских компаниях. Ужесточение законов о защите ПДн и ответственности за ИБ-инциденты усиливает потребность организаций не только в защитном ПО, но и в высококвалифицированных сотрудниках.</p> <p>Дефицит кадров в сфере ИБ остается актуальной проблемой, в 2024 году в России c нехваткой ИБ-специалистов сталкивались 74% компаний. В 2025 году дефицит ИБ-кадров в разной степени фиксировали 71% опрошенных организаций: 55% сталкиваются с привычной нехваткой, 12% ответили, что дефицит усилился по сравнению с предыдущими годами, 4% отметили, что кадровый голод ослаб по сравнению с прошлым годом, но проблема с наймом и поиском специалистов все еще сохраняется. Лишь 23% опрошенных организаций не испытывали сложности с наймом ИБ-специалистов, 6% ответили, что на рынке достаточно кандидатов. </p> <p>«Дефицит высококвалифицированных кадров — одна из ключевых проблем российской ИБ-отрасли. В 2024 году ее в разной степени ощущали 74% российских компаний, в 2025 году ситуация не изменилась. Мы понимаем всю серьезность ситуации, поэтому активно участвуем в решении проблемы. Сотрудничаем с вузами: бесплатно предоставляем лицензии на наше ПО и обучающую программу с актуальной теорией и практикой. Проводим мероприятия по повышению квалификации ИБ-специалистов: очно в нашем учебном центре и в формате вебинаров. Только так возможно повысить защищенность российских организаций», — прокомментировал Алексей Дрозд, начальник отдела безопасности «СёрчИнформ».</p> <p>Особо остро проблема с ИБ-кадрами ощущается в госсекторе — 78% государственных организаций сталкиваются с нехваткой кадров, что превышает показатель в частных компаниях, где о проблеме сообщили 67% опрошенных.</p> <p>Вопросы кадрового голода опрошенные компании закрывают по-разному. По данным исследования, больше половины государственных организации (57%) решают проблему дефицита кадров через профпереподготовку своих сотрудников, в том время как частные компании лишь в 45% случаев прибегают к этому варианту. Государственные компании также чаще, чем частные, готовы принимать на работу студентов и выпускников, чтобы закрыть вопросы нехватки ИБ-специалистов. </p> <p>Для части компаний ситуация с нехваткой кадров усугубляется тем, что оснащенность ПО, которое помогло бы решить некоторые ИБ-задачи, остается недостаточной. Это особенно критично в сфере малого и среднего бизнеса, который не может конкурировать за кадры по уровню зарплат. Компаниям МСБ решить проблему нехватки кадров можно с помощью аутсорсинга информационной безопасности. В 2025 году 14% компаний уже используют эту услугу, а 27% были заинтересованы в аутсорсинге информационной безопасности, 7% опрошенных планировали внедрить услугу в ближайшее время. </p> <p>Действующие заказчики аутсорсинга информационной безопасности среди ключевых преимуществ услуги выделяют: снижение финансовых издержек (35%), снижение трудозатрат (33%), отсутствие необходимости установки серверного оборудования и ПО (30%), высокую квалификацию и качество услуг ИБ-провайдера (30%).</p> В рамках ежегодного исследования уровня информационной безопасности (ИБ) в компаниях России эксперты «СёрчИнформ» … message https://www.itweek.ru/themes/detail.php?ID=234808 Wed, 13 May 2026 10:31:07 +0300 <p><em>Все говорят о повышении производительности с помощью инструментов искусственного интеллекта. Опрошенные порталом </em><em>ZDNet</em> <em>эксперты рассказывают, как добиться от ИИ реальной пользы.</em></p> <p>Доказать ценность ИИ сложнее, чем кажется. По словам одного CIO, недавно он с гордостью сообщил своему CEO, что внедрение Microsoft Copilot в организации сэкономило сотрудникам в среднем по 30 минут в день. Ответ CEO был кратким: «И что? Как сотрудники используют это время для создания чего-то ценного для компании?».</p> <p>CIO признался, что был несколько озадачен. Урок, по его словам, заключается в том, что все специалисты, которые хотят использовать ИИ, должны продемонстрировать, как его внедрение приносит реальные, ощутимые выгоды, а не просто сокращение времени, необходимого для выполнения задач.</p> <p>Итак, как специалисты могут превратить стремление к извлечению ценности из ИИ в реальное повышение производительности? Вот пять способов.</p> <h3>1. Сосредоточьтесь на результатах для бизнеса</h3> <p>По словам Бернхарда Зайзера, вице-президента AOP Health по цифровым технологиям, данным и ИТ, его организация внедрила Copilot и ChatGPT год назад и установила ключевые показатели эффективности (KPI) для измерения успеха.</p> <p>«Первым, конечно, был уровень внедрения. OpenAI сообщила нам, что уровень внедрения в нашей организации высок, поэтому ИИ активно используется, — рассказывает он. — Но сам факт использования мало что говорит. В конце концов, это может быть просто написание электронных писем — успех должен быть связан с результатом и влиянием ваших действий на ваши продукты и взаимодействие с клиентами».</p> <p>Зайзер отмечает, что именно здесь вступает в игру второй KPI: совместная работа с остальными подразделениями компании для определения списка задач и оценки преимуществ, которые ИИ приносит для каждого сценария использования. «Я думаю, это более точный показатель, чем просто анализ темпов внедрения», — говорит он.</p> <p>Теперь, по словам Зейзера, он хочет создать ориентированный на повышение производительности подход для сотрудников всей организации. «Я думаю, это станет еще важнее, когда мы проанализируем сценарии использования и проведем тщательное исследование того, насколько ИИ полезен для решения конкретных задач, потому что тогда мы сможем гораздо лучше увидите его влияние на бизнес», — поясняет он.</p> <h3>2. Определение операционных преимуществ</h3> <p>Джон-Дэвид Лавлок, заслуженный вице-президент-аналитик Gartner, считает, что важно скептически относиться к предполагаемым преимуществам повышения производительности благодаря ИИ. «Я призываю людей лучше объяснять, что они имеют в виду, когда говорят о производительности, потому что, по большей части, люди говорят: „Эй, производительность вырастет. Производительность — это замечательно“. Никто никогда не определяет, что такое производительность», — говорит он.</p> <p>По словам Лавлока, проведенный Gartner около двух лет назад опрос показал, что чем меньше компания способна измерить производительность, достигнутую благодаря ее ИИ-проекту, тем больше вероятность того, что она заявит о высокой производительности, достигнутой благодаря этой инициативе.</p> <p>Лавлок отмечает, что успешные специалисты в начале проекта определяют, как технология повысит эффективность работы. «В качестве примера я обычно привожу электронную почту, — говорит он, имея в виду внедрение инструментов генеративного ИИ в административные сферы. — Если кто-то отправляет 100 писем в день и считается очень продуктивным сотрудником, то будет ли он продуктивнее, если отправит 125 писем, или если отправит 80 писем, которые не вводят людей в заблуждение, или 40 писем, которые не превращают всю компанию в ад email-переписки?».</p> <h3>3. Тесное сотрудничество с другими</h3> <p>Эва Зборовска, директор IDC по исследованиям, считает, что тесное сотрудничество между ИТ-отделом и бизнес-подразделениями имеет решающее значение для достижения целей, приносящих ценность.</p> <p>«Вам так или иначе придется финансировать ИИ, и бюджеты часто будут распределяться между всеми, — говорит она. — В отношении определенных решений будет существовать совместное владение, поэтому важно убедиться, что вы работаете вместе, понимаете друг друга и имеете KPI, которые помогут вам понять, разумно ли вы тратите деньги».</p> <p>До сих пор, по словам Зборовски, компании часто направляли расходы на ИИ в области, связанные с технологиями, такие как кибербезопасность и разработка ПО, где уже налажены процессы и имеется большой объем данных, готовых для ИИ-проектов. Теперь ИИ все чаще применяется в операционной деятельности, обслуживании клиентов, маркетинге и бэк-офисных функциях: «Почти во всех областях, как сообщают организации, инвестиции часто будут удваиваться в течение следующего года», — отмечает она.</p> <p>Исследование, проведенное IDC совместно с Lenovo, показало, что до 94% европейских CIO ожидают положительной рентабельности инвестиций от своих ИИ-инициатив, и прочные партнерские отношения будут иметь решающее значение для успеха. «Наши углубленные персональные интервью с CIO подтвердили, что подход изменился, и это повлияло на то, как цифровые лидеры воспринимаются внутри компании, потому что ИТ-специалисты теперь рассматриваются как партнеры бизнеса, а не просто как люди, которые следят за тем, чтобы серверы работали и электронная почта была в порядке», — говорит Зборовска.</p> <h3>4. Позвольте людям рассказывать блестящие истории</h3> <p>Ричард Корбридж, CIO компании Segro, специализирующейся на недвижимости, рассказывает, что его организация оценивает корпоративные ИИ-решения в матричной схеме, где проекты оцениваются и приоритизируются на основе вероятных затрат и потенциальной экономии средств и времени.</p> <p>По его словам, важным элементом этого процесса является предоставление возможности протестировать инструменты. «Пусть люди, желающие попробовать ИИ, получат к нему доступ, чтобы они могли начать изучать его возможности и стать его самыми большими поклонниками, которые уже опробовали его и могут рассказать другим о своем опыте, — говорит он. — Удивительно, что когда вы собираете в одной комнате группу профессионалов, и есть те, кто уже попробовал ИИ и считает его замечательным, и те, кто все еще немного боится его, — у последних быстро возникает страх упустить что-то важное (FOMO) из-за тех, кто уже попробовал и извлек из этого пользу, а не наоборот».</p> <p>Корбридж считает, что профессионалы, которые извлекают выгоду из ИИ, могут помочь показать его ценность другим. «Как только у вас появляется ИИ, и люди видят его ценность, трудно его отнять у них, — говорит он. — Поэтому давайте распространять блестящие истории, чтобы другие люди могли увидеть, что это может принести».</p> <h3>5. Не упустите возможность пообщаться у кулера</h3> <p>Как и другие отраслевые эксперты, Лавлок считает, что ИИ может сэкономить людям время немного в течение дня — и это не обязательно плохо. «Самые простые преимущества в плане производительности, вероятно, будут связаны с „временем выпить чашку латте“, — говорит он. — Да, вы сэкономите время и силы, а ценность для компании заключается в том, что у вас теперь будет время, чтобы сходить за латте».</p> <p>Хотя упомянутый ранее CIO столкнулся с CEO, который требовал четких, измеримых преимуществ от внедрения ИИ, Лавлок отмечает, что руководители, которые не видят ценности дополнительного времени отдыха, могут упускать важный момент. «Когда люди восемь часов работают за компьютером, у вас нет корпоративной культуры. Люди близки к выгоранию. Если вы дадите им полчаса, в течение которых они смогут выпить латте и насладиться общением с коллегами, в этом есть ценность, — говорит он. — Возможно, вас спрашивают: „Как измерить успех ИИ?“ И вы можете ответить: „Мы вернули людям полчаса в день“. Это уже будет мерилом: ИИ снижает стресс и тревогу. Короче говоря, ценность этого получаса различна для каждой организации».</p> Все говорят о повышении производительности с помощью инструментов искусственного интеллекта. Опрошенные порталом ZDNet … article https://www.itweek.ru/themes/detail.php?ID=234807 Wed, 13 May 2026 10:05:57 +0300 <p><em>Простота создания приложений с помощью нескольких текстовых промптов превращается в растущую проблему кибербезопасности. Исследователи предупреждают, что те же инструменты искусственного интеллекта, которые помогают людям создавать ПО за считанные минуты, также раскрывают в общедоступном Интернете конфиденциальную корпоративную и личную информацию, сообщает портал </em><em>eWeek</em><em>.</em></p> <p>Новое расследование израильской компании по кибербезопасности <a name="OLE_LINK21">Red Access </a>выявило утечки данных из тысяч веб-приложений, созданных с помощью ИИ, начиная от медицинских записей и заканчивая внутренними деловыми документами. Эти результаты усиливают опасения по поводу вайб-кодинга — быстрорастущей тенденции, в рамках которой пользователи активно используют инструменты ИИ для создания и развертывания ПО, имея минимальный или нулевой опыт традиционного программирования.</p> <p>Расследование выявило около 380 тыс. общедоступных ресурсов, созданных с помощью инструментов программирования на базе ИИ, таких как Lovable, Replit, Netlify и Base44. По данным исследователей, около 5 тыс. из этих приложений раскрывали потенциально конфиденциальную информацию.</p> <p>Результаты исследования, опубликованные Axios, показывают, что многие пользователи публикуют внутренние инструменты онлайн, не подозревая, что они находятся в открытом доступе. Дор Цви, генеральный директор Red Access, заявил, что компания обнаружила эти приложения во время исследования «теневого ИИ» (когда сотрудники используют инструменты ИИ без официального разрешения своих организаций).</p> <p>«Сама концепция создания чего-то настолько простого и использования этого в производственной среде... от имени своей компании без получения какого-либо разрешения — это беспредел», — заявил он.</p> <p>Цви также предупредил, что многие нетехнические пользователи могут даже не задумываться о настройках безопасности перед запуском приложений онлайн. «Я не думаю, что возможно обучить весь мир вопросам безопасности, — отметил Цви. — Моя мама занимается вайб-кодингом с помощью Lovable, и без обид, но я не думаю, что она задумывается о доступе на основе ролей».</p> <h3>Сообщается об утечках медицинских, финансовых и корпоративных данных</h3> <p>Было обнаружено, что утечки включали медицинские записи, финансовые документы, диалоги с чат-ботами, расписания и внутренние деловые материалы.</p> <p>Axios сообщила, что было независимо проверено несколько приложений, подвергшихся утечке, включая приложение судоходной компании, отображающее расписание судов, платформу здравоохранения, подробно описывающую клинические испытания в Великобритании, и переписку с клиентами поставщика мебели.</p> <p>Согласно WIRED, некоторые из утечек из приложений, по-видимому, содержали рабочие задания больниц, записи о продажах, презентации маркетинговых стратегий, финансовую информацию и журналы чат-ботов с именами и контактными данными клиентов.</p> <p>Исследователи также заявили, что обнаружили приложения, содержащие утечки разговоров с пациентами, записи школьных уроков и внутренние расписания персонала. По данным WIRED, около 40% утечек приложений, по-видимому, содержали конфиденциальные данные.</p> <p>«В итоге организации фактически раскрывают личные данные через приложения, созданные методом вайб-кодинга, — заявил Цви. — Это один из крупнейших случаев в истории, когда люди раскрывают корпоративную или другую конфиденциальную информацию кому угодно во внешнем мире».</p> <h3>Платформы опровергают заявления исследователей</h3> <p>Компании, стоящие за инструментами программирования на основе ИИ, оспорили часть выводов исследователей, утверждая, что видимость общедоступных приложений в сети не означает автоматически, что произошло нарушение безопасности. Генеральный директор Replit Амджад Масад заявил, что пользователи могут сами решать, будут ли приложения общедоступными или частными. По его словам, доступность приложений в Интернете — это ожидаемое поведение, а настройки конфиденциальности можно изменить в любое время одним щелчком мыши.</p> <p>Представитель Lovable заявил, что компания расследует утверждения исследователей, и подчеркнул, что разработчики сами несут ответственность за конфигурацию своих приложений.</p> <p>Base44 также выступила в защиту свою платформу, заявив, что пользователям предоставляются инструменты для самостоятельной настройки параметров безопасности.</p> <p>Ожидается, что масштабы этой проблемы будут расти. По отраслевым данным, к концу этого года 60% всего нового кода будет генерироваться с помощью ИИ. Хотя эти инструменты демократизируют процесс создания, они также обходят традиционные проверки безопасности, используемые профессиональными инженерными командами.</p> Простота создания приложений с помощью нескольких текстовых промптов превращается в растущую проблему … article https://www.itweek.ru/themes/detail.php?ID=234805 Wed, 13 May 2026 09:50:22 +0300 <p>На рынке корпоративного ПО по-прежнему сильна вера в тезис «функционал решает». Достаточно выбрать сильное решение, внедрить его, а дальше клиент начнет получать эффект. Для простых инструментов это иногда работает. Но в системах, где требуется не только установка, а глубокая настройка под процессы и встраивание в операционное управление (например, ERP-системы для управления ресурсами компании, MES — для управления производством, CRM — для работы с клиентской базой, SCM — для управления цепочками поставок, Process Mining — для анализа фактического выполнения процессов), само по себе внедрение ничего не гарантирует.</p> <h3>Внедрение не равно использование</h3> <p>Ключевая проблема в том, что внедрение и освоение — это два разных этапа.</p> <ul> <li> внедрение — про инфраструктуру, интеграции, проверки и запуск;</li> <li> освоение — про то, как система начинает использоваться в реальной работе.</li> </ul> <p>Если второй этап не выстроен, продукт остается на уровне пилотного проекта или ограниченного набора сценариев.</p> <p>На практике компании сталкиваются с повторяющимися проблемами:</p> <ul> <li> <strong>Нет понятного маршрута. </strong>Пользователь получает доступ к системе, но не понимает, с чего начать, как действовать и как перейти к прикладным задачам. Использование фрагментарное и может не отхватывать всего функционала решения, из-за чего невозможно дальнейшее масштабирование в рамках компании.</li> <li> <strong>Разрыв между теорией и практикой. </strong>Обучение работе в системе ограничено демо-показами и документацией. Без самостоятельной работы и выполнения практических задач в системе знания быстро устаревают и теряют ценность.</li> <li><strong>Отсутствие внутренней экспертизы. </strong>Если внутри команды нет людей, способных эскалировать использование системы, любые изменения — от настройки новых сценариев использования до масштабирования на другие процессы — начинают тормозиться.</li> </ul> <h3>Какие подходы работают</h3> <p>На рынке, по моим наблюдениям, сформировалось несколько устойчивых и наиболее полезных практик обучения продукту:</p> <ul> <li> <strong>Прикладные маршруты вместо общего обучения.</strong> Обзорный курс — это всегда по верхам и без глубокого погружения. Эффективнее работают последовательные сценарии, привязанные к задачам: от подготовки данных до интерпретации результатов. При этом обучение должно разделяться по ролям — бизнес, аналитика, ИТ.</li> <li><strong>Практика как обязательный элемент. </strong>Обучение должно строиться вокруг выполнения задач в системе, а не просмотра материалов. Доступ к тестовой среде и возможность пройти сценарий «руками» критичны для закрепления.</li> <li><strong>Сопровождение на старте. </strong>Даже при наличии материалов пользователям требуется поддержка: разбор ошибок, ответы на вопросы, помощь в первых кейсах. Людям нужно понять, нужно научиться.</li> <li><strong>Постоянная актуализация. </strong>По мере развития продукта меняется логика работы. Если обучение не обновляется, часть функциональности остается невостребованной или даже неизвестной бизнес-пользователям.</li> </ul> <h3>Преимущества для клиентов</h3> <p>Самое очевидное — это способ быстрее перевести внедрение из статуса «Новое» в статус «Рабочий инструмент» и начать получать понятный измеримый эффект.</p> <ul> <li><strong>Быстрее достигается прикладной результат</strong>: пользователи переходят от знакомства с интерфейсом «методом тыка» к решению конкретных задач — настройке отчетности, анализу отклонений, поиску узких мест и т. д. За счет этого первые эффекты появляются раньше.</li> <li> <strong>Снижается зависимость от подрядчиков:</strong> внутренняя команда может самостоятельно дорабатывать сценарии, настраивать отчеты и адаптировать систему под новые задачи без постоянного привлечения внешних специалистов. Это ускоряет любые изменения и снижает стоимость владения.</li> <li> <strong>Упрощается масштабирование:</strong> когда базовые сценарии отработаны и понятны, расширение на новые процессы, подразделения и роли не требует повторного «входа в систему» и идет по знакомой отработанной модели.</li> <li><strong>Снижаются операционные риски:</strong> пользователи лучше понимают логику работы системы, корректно интерпретируют данные и реже допускают ошибки, которые могут влиять на управленческие решения.</li> </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>Я уверен, что в ближайшие годы конкуренция на рынке корпоративных технологий будет идти не только по линии функционала. Просто сильного B2B-продукта сейчас стало недостаточно. Выигрывать будут те, которые умеют не просто разработать мощное ПО, но и провести клиента через первые ключевые этапы его освоения: дать понятный маршрут, обеспечить практику, вовремя подключить экспертов и помочь встроить технологию в реальную операционную жизнь компании.</p> <p> #IMAGE_234806#</p> На рынке корпоративного ПО по-прежнему сильна вера в тезис «функционал решает». Достаточно выбрать сильное … article Александр Бочкин, генеральный директор “Инфомаксимум” https://www.itweek.ru/themes/detail.php?ID=234802 Tue, 12 May 2026 17:17:01 +0300 <p>Компания «ДоксВижн» выпустила обновлённый сервис интеллектуальной обработки документов Docsvision AI. В Docsvision AI версии 3.0 появились опция маскировки чувствительных данных, логирование запросов к большим языковым моделям (LLM), программный интерфейс (API) и другие возможности.</p> <p>Опция маскировки позволяет перед отправкой запроса в облачную <nobr>LLM-модель</nobr> заменять чувствительные для бизнеса данные на технические плейсхолдеры. Получив от ИИ ответ, сервис восстанавливает исходные значения. Таким образом, процессы защиты данных становятся «невидимыми» для пользователей и не влияют на удобство работы.</p> <p>Правила маскировки данных настраиваются под различные виды документов и требования ИБ в конкретной организации при помощи low-code инструментов платформы Docsvision. Маскировку можно задавать по регулярным выражениям (например, реквизитам, паспортным данным), по типам сущностей (адреса, организации, имена) и по спискам слов (с учётом лексем).</p> <p>«Внедрение корпоративного ИИ нередко сдерживают такие факторы, как высокая стоимость инфраструктуры при работе с локальной <nobr>LLM-моделью</nobr> и вопросы информационной безопасности при использовании облачных <nobr>LLM-моделей.</nobr> Маскировка данных способна решить обе эти проблемы: можно работать с облачной моделью и при этом не выводить за контур организации чувствительную для бизнеса информацию», — отметил Алексей Рождественский, эксперт по продукту «ДоксВижн».</p> <p>Новая версия Docsvision AI сохраняет в карточке документа историю запросов к <nobr>LLM-моделям,</nobr> что расширяет возможности для контроля и защиты корпоративной ИТ-инфраструктуры.</p> <p>Программный интерфейс, реализованный в Docsvision AI 3.0, позволяет использовать ИИ-функции не только из карточки документа, но и внутри прикладных сценариев, маршрутов согласования, интеграций с другими корпоративными приложениями. При помощи API можно встраивать обработку текстов и файлов в бизнес-процессы, передавать параметры запросов, управлять логикой обращения к <nobr>LLM-моделям.</nobr></p> <p>Кроме того, расширена пользовательская функциональность сервиса. Теперь Docsvision AI даёт возможность сравнивать несколько версий одного файла, сохранять ответы нейросети в карточке документа, оценивать качество ответов при помощи «лайков» и «дизлайков».</p> <p>Сервис Docsvision AI был впервые представлен в 2025 году. Он позволяет использовать возможности генеративного искусственного интеллекта в решениях на платформе Docsvision. Сегодня в Docsvision AI реализованы 10 сценариев применения ИИ, ускоряющих управление договорами, работу с задачами, организацию совещаний и делопроизводства. Сервис поддерживает различные варианты развёртывания <nobr>LLM-моделей,</nobr> в том числе в локальной сети заказчика (on-premise) и облачное в российском контуре.</p> Компания «ДоксВижн» выпустила обновлённый сервис интеллектуальной обработки документов Docsvision AI. В Docsvision … message https://www.itweek.ru/themes/detail.php?ID=234801 Tue, 12 May 2026 17:15:17 +0300 <p>Компания «Юниверс Дата», разработчик решений в области управления данными, выпустила крупный релиз 6.15 продукта по работе с основными данными Юниверс MDM (НСИ), в который вошли востребованные улучшения функциональности и безопасности работы системы.</p> <p>В частности, в системе появились новые возможности сквозного поиска, которые позволяют искать одновременно по нескольким реестрам, справочникам, связям и классификациям. Таким образом, не нужно заранее знать, где именно лежат данные.</p> <p>Новая функция мультичерновиков объединяет изменения по множеству записей в один логический пакет. Теперь такие изменения можно проводить через согласование как единую операцию.</p> <p>В версии 6.15 улучшены возможности импорта данных — организована поддержка потокового режима, который позволяет увеличить производительность импорта и снизить нагрузку на инфраструктуру.</p> <p>Кроме того, новая версия получила улучшения с точки зрения безопасности и интеграции: поддержка мультидоменности LDAPS и современных протоколов шифрования, маскирование паролей, дополнительные настройки OAuth 2.0, функции API для мониторинга внешними инструментами.</p> <p>«Роль управления основными данными в эпоху развития технологий ИИ и самообслуживания в аналитике становится все более важной для обеспечения достоверности информации. Новый релиз Юниверс MDM позволяет достичь необходимых уровней надежности и безопасности работы с мастер-данными и НСИ при высокой масштабируемости процессов», — сказал Дмитрий Финк, генеральный директор компании «Юниверс Дата».</p> <p>Решение Юниверс MDM представлено в Реестре российского ПО в нескольких редакциях (стандартная редакция MDM SE, управление корпоративными мастер-данными MDM EE, высоконагруженная версия MDM HPE). DIS Group является мастер-дистрибьютором решений «Юниверс Дата» на российском рынке.</p> Компания «Юниверс Дата», разработчик решений в области управления данными, выпустила крупный релиз 6.15 продукта … message https://www.itweek.ru/themes/detail.php?ID=234800 Tue, 12 May 2026 17:10:51 +0300 <p>По данным экспертов компании «Системный софт», объем российского рынка систем резервного копирования (СРК) по итогам 2025 года оценивается в 10,5 млрд рублей. Относительно 2024 года рост составил умеренные 17%, что отражает замедление по сравнению с восстановительным ростом <nobr>2023–2024 годов.</nobr> Ключевыми драйверами развития рынка остаются импортозамещение, рост киберугроз и увеличение объемов данных.</p> <p>По оценке «Системного софта», доля отечественных СРК на российском рынке по итогам 2025 года превысила 50%. Иностранные решения при этом, хотя суммарно и занимают менее половины рынка, сохраняют значимое присутствие в инфраструктурах заказчиков. Рынок находится в переходной фазе: компании все чаще используют гибридные сценарии, одновременно эксплуатируя российские и зарубежные продукты для снижения рисков миграции.</p> <p>В 2025 году спрос на российские системы резервного копирования формировался под воздействием нескольких взаимосвязанных факторов.</p> <p>Базовым аспектом стало импортозамещение: заказчики переводили инфраструктуру на отечественные решения, чтобы снизить зависимость от зарубежных вендоров и сохранить контроль над критичными ИТ-функциями. Это напрямую увеличивало число пилотов, закупок и миграционных проектов.</p> <p>Этот процесс усиливало санкционное давление, ограничивая доступ к обновлениям, поддержке и долгосрочному использованию зарубежного ПО. В результате многие организации ускоряли переход на российские СРК, чтобы снизить технологические и операционные риски. Особенно заметным это было в компаниях, для которых простой или потеря данных критичны для бизнеса.</p> <p>Значимую роль играло законодательство. Требования к объектам КИИ и государственным структурам закрепляли необходимость перехода на отечественное ПО, что создавало гарантированный спрос на российские системы резервного копирования. Для регулируемых отраслей это означало не просто рекомендацию, а фактическую обязанность миграции.</p> <p>Государственные программы поддержки также подталкивали рынок. Субсидии, гранты и иные меры помощи снижали стоимость разработки и внедрения российских решений, а также облегчали заказчикам переход на них. Это помогало отечественным вендорам быстрее дорабатывать продукты и наращивать присутствие в корпоративном и государственном сегментах.</p> <p>Отдельным драйвером стал рост киберрисков. Резервное копирование все чаще воспринимается как элемент киберустойчивости. Это повышает значимость СРК при формировании ИТ-бюджетов и усиливает требования к их функционалу.</p> <p>Наконец, важным фактором стала зрелость российских продуктов. По мере развития отечественные СРК начали восприниматься как полноценная альтернатива западным системам. Это увеличило спрос со стороны государства и коммерческих заказчиков.</p> <p>Российские решения уже закрывают ключевые корпоративные сценарии: резервное копирование виртуальных сред, файловых и прикладных систем, работу с ленточными библиотеками, горизонтальную масштабируемость, отказоустойчивость, шифрование и интеграцию с отечественными ОС.</p> <p>«Для многих заказчиков важны не только функции, но и соответствие требованиям регуляторов, локальная поддержка и возможность быстро дорабатывать продукт под конкретную инфраструктуру и здесь отечественные решения часто выглядят особенно сильными, — отметил Сергей Василенко, руководитель направления резервного копирования компании „Системный софт“. — Российский сегмент систем резервного копирования растет устойчиво благодаря спросу на системное ПО и требованиям регуляторов. Доля отечественных решений превысила 50% и может достичь 90% через <nobr>5–6</nobr> лет по мере истечения лицензий западных продуктов».</p> По данным экспертов компании «Системный софт», объем российского рынка систем резервного копирования (СРК) по итогам … message https://www.itweek.ru/themes/detail.php?ID=234799 Tue, 12 May 2026 17:08:38 +0300 <p>Selectel объявила о запуске линейки VDS с упрощенным процессом развертывания и стоимостью от 200 рублей в месяц. Новое решение ориентировано на индивидуальных разработчиков, фрилансеров и представителей малого бизнеса, которым важно быстро запускать серверную инфраструктуру без сложной настройки. Сервис уже доступен в панели управления Selectel.</p> <p>VDS (Virtual Dedicated Server) — это виртуальный выделенный сервер, который позволяет размещать сайты, запускать приложения и разворачивать сервисы без необходимости управлять физическим оборудованием. Сервер можно создать за несколько минут, выбрав одну из готовых конфигураций, и сразу приступить к работе.</p> <p>Среди ключевых преимуществ VDS Selectel — простой и быстрый запуск, доступная стоимость и возможность подобрать конфигурацию под базовые задачи без необходимости глубокого погружения в инфраструктурные настройки. К тому же, по мере роста своих проектов, пользователи могут подключать другие облачные продукты Selectel для развития своей IT-инфраструктуры.</p> <p>«Мы наблюдаем растущий спрос на доступную IT-инфраструктуру для небольших проектов. На фоне общего роста стоимости решений на рынке виртуальных серверов пользователи всё чаще сталкиваются с необходимостью оптимизировать расходы на вычислительные ресурсы. Новый продукт Selectel позволяет снизить эти затраты и при этом сохранить доступ к надежной облачной платформе. Стоимость VDS в Selectel остается одной из самых доступных на рынке, при этом пользователи получают инфраструктуру с предсказуемой производительностью и стабильной работой сервисов», — отметил Владимир Тычина, менеджер продукта в Selectel.</p> <p>Решение подойдет для широкого круга задач: размещения сайтов и интернет-магазинов, запуска dev-окружений и тестовых сред, хранения и обработки данных. Благодаря выделенным ресурсам пользователи получат стабильную производительность и полный контроль над окружением сервера.</p> <p>VDS-серверы работают на базе облачной платформы Selectel в дата-центрах уровня Tier III и используют KVM-виртуализацию с полной изоляцией ресурсов. Каждая виртуальная машина получает оперативную память и дисковое пространство, а управление серверами доступно через панель управления Selectel, API и Terraform.</p> Selectel объявила о запуске линейки VDS с упрощенным процессом развертывания и стоимостью от 200 рублей … message https://www.itweek.ru/themes/detail.php?ID=234797 Tue, 12 May 2026 12:13:06 +0300 <p><em>В течение трех десятилетий индустрия ИТ- и бизнес-услуг работала по знакомой формуле: увеличение численности персонала с целью масштабирования бизнеса, повышение эффективности использования ресурсов, ценообразование по времени и материалам. Эта модель создала индустрию стоимостью 1,6 трлн. долл. Но она уходит в прошлое, пишет в корпоративном блоге Дина Капелле, старший аналитик-исследователь платформ агентного искусственного интеллекта для сервис-провайдеров.</em></p> <p>Агентный ИИ меняет экономику, контракты и контрольные точки на рынке услуг. Сервис-провайдеры, которые вовремя осознают этот сдвиг, смогут перестроить свои портфели, ориентируясь на платформы, продуктивную интеллектуальную собственность и измеримые результаты. Те, кто опоздает, окажутся в ситуации, когда им придется конкурировать по цене за работу, которая быстро автоматизируется, превращается в продукт или поглощается поставщиками ПО и ИИ-нативными конкурентами.</p> <p>Речь идет не просто о более эффективном выполнении той же работы. Это фундаментальный сдвиг в том, как создаются, продаются и предоставляются услуги.</p> <h3>Три волны и почему следующая будет отличаться</h3> <p>Индустрия услуг прошла через различные волны создания ценности.</p> <ul> <li><strong> Аутсорсинг и системная интеграция</strong> создавали ценность за счет практики использования различий в стоимости труда между разными географическими регионами.</li> <li><strong> Управляемые сервисы и миграция в облако</strong> создавали ценность за счет операционной эффективности.</li> <li><strong> Цифровая трансформация</strong> создавала ценность за счет бизнес-инноваций.</li> </ul> <p>Следующая волна сломает эту модель. Предоставление услуг с помощью агентов создает ценность за счет автоматизации, интеллекта и измеримых результатов, и это переписывает уравнение ценности сразу по трем осям. Покупатели переходят от времени и материалов к результатам и влиянию, от доступа к экспертизе к инсайтам и расширению возможностей и от реализации проектов к действиям на основе платформы. То, что остается человеческим, перемещается вверх по иерархии: отношения, стратегическое суждение и контекстное понимание.</p> <p>#IMAGE_234798#</p> <p>Данные IDC подтверждают это. Ожидается, что к 2029 г. 30% всех договорных отношений с поставщиками услуг будут ориентированы на результат, а 30% ИТ-услуг будут предоставляться в виде модульных продуктов на основе платформы.</p> <h3>Что такое SPAAP и почему это важно</h3> <p>Этот сдвиг создает новый класс активов. IDC называет их платформами агентного ИИ для поставщиков услуг (Service Provider Agentic AI Platform, SPAAP). Это проприетарные платформы, созданные, управляемые и поддерживаемые компаниями, основной деятельностью которых являются услуги, а не ПО. SPAAP — это ИИ-нативное воплощение модели «услуги как продукт» (Services as a Product), и эти платформы быстро становятся стратегическим ядром масштабирования современной сервисной компании.</p> <p>Эти платформы служат двум целям, часто одновременно. Они могут функционировать как внутренние платформы доставки, которые индустриализируют процесс проектирования и предоставления услуг сервис-провайдеров в масштабе. Они также могут быть платформами, ориентированными на клиента, которые дополняют или заменяют бизнес- и технические процессы внутри клиентской среды, сохраняя свою работу после завершения сотрудничества.</p> <h3>Отрасль разделяется и разрыв быстро увеличивается</h3> <p>Сервисная индустрия разделяется на два лагеря. Победители перестраивают свои бизнес-модели, ориентируясь на результаты для клиентов. Все остальные защищают устаревшие структуры.</p> <p>Победители управляют продуктовыми портфелями, соответствующими отраслям, предметным областям и портретам покупателей. Они инвестируют в проприетарные модульные платформы с оркестрацией, управлением, наблюдаемостью и совместимостью. Они создают небольшие, но высокоэффективные команды из людей и агентов. Они устанавливают цены, исходя из результатов, с четким пониманием прав интеллектуальной собственности и данных, а также структурой распределения рисков. Они завоевывают доверие благодаря прозрачности и возможности аудита.</p> <p>Проигрышная ситуация выглядит иначе: широкий спектр общих возможностей, фрагментированные инструменты предоставления услуг, пирамидальные модели управления талантами и ценообразование на основе времени и материалов. Решения типа «черный ящик». Перекладывание ответственности.</p> <p>Разрыв между двумя группами быстро увеличивается.</p> <h3>На арену выходят два новых типа конкурентов</h3> <p>Поставщики услуг сталкиваются с двумя различными новыми категориями конкурентов.</p> <p>ИИ-нативные компании обещают автоматизацию от 60 до 80% традиционной работы по техническому заданию с ценообразованием, основанным на результатах. Они не пытаются воспроизвести модель полного спектра услуг. Они устраняют посредников в выполнении конкретных высокоэффективных рабочих процессов, часто тех, которые ранее выполнялись аутсорсерами бизнес-услуг и системными интеграторами более низкого уровня.</p> <p>Платформенные игроки движутся по-другому. Они объединяют ПО, токены и привлеченных инженеров в предложения, ориентированные на результат. Контракт не просто конкурирует по цене. Он структурно перепроектирован вокруг продукта.</p> <p>Выполнение услуг больше не является стратегическим полем битвы. Им становится уровень рабочих процессов и результатов, и тот, кто владеет этим уровнем, владеет отношениями с клиентом.</p> <h3>Где устоявшиеся поставщики услуг имеют структурное преимущество</h3> <p>Может показаться, что гиперскейлеры, независимые поставщики ПО и ИИ-нативные компании просто поглотят рынок услуг. Но этого не произойдет. Поставщики услуг обладают реальным структурным преимуществом на трех уровнях агентного стека: создание и развертывание, управление и эксплуатация, а также оркестрация.</p> <ul> <li><strong>Переносимость — наиболее очевидный аспект.</strong> Ни одно предприятие не хочет быть привязанным к одной базовой модели, одному гиперскейлеру или одному агентному фреймворку. Покупатели хотят свободы менять модели по мере их совершенствования, перемещать рабочие нагрузки в соответствии с экономическими изменениями и интегрировать агентов на уже имеющихся у них платформах. Сервис-провайдеры — единственная категория поставщиков, чья бизнес-модель поощряет открытость в этих вопросах, сохраняя при этом ответственность за результат.</li> <li><strong>Управление — более устойчивый аспект.</strong> Агентная реализация повышает ставки в отношении идентификации, наблюдаемости, возможности аудита и контроля рисков. Предприятиям необходимо объяснимое поведение, подтверждающие данные для регулирующих органов и четкая человеческая ответственность, когда агент действует автономно. Сервис-провайдеры находятся ближе всего к процессам клиента, людям, участвующим в процессе, и договорной ответственности за результат — именно здесь должно происходить управление агентами. Управление, заявленное в спецификации продукта, и управление, реализованное в среде клиента, — это две разные вещи.</li> <li><strong>Оркестрация — вот где преимущество суммируется.</strong> Корпоративная работа охватывает ERP, CRM, ITSM, платформы данных, пользовательские приложения и облачные рабочие нагрузки. Агентная реализация требует координации между всеми этими системами, часто с агентами, построенными на разных платформах и управляемыми разными командами. Межсистемная и межвендорная интеграция — это то, чем сервис-провайдеры занимаются профессионально. Расширение этого подхода на оркестрацию нескольких агентов, A2A- и MCP-интероперабельность, а также на уровень рабочих процессов, связывающий внутренних агентов с агентами на стороне клиента, является естественным продолжением, а не изменением их бизнеса.</li> </ul> <p>В основе всех трех уровней лежит то, что гиперскейлеры и горизонтальные независимые поставщики ПО с трудом могут воспроизвести: глубина отраслевой специфики. Рабочие процессы, правила, KPI и определение хорошего бизнес-результата резко различаются в банковском секторе, здравоохранении, производстве, розничной торговле и государственном секторе. Сервис-провайдеры десятилетиями внедряли этот контекст в команды доставки. Теперь они кодируют его в агентные платформы с помощью вертикальных сценариев, доменных онтологий и целевых наборов агентных решений. Такую основу можно создать быстро. Именно отраслевой контекст превращает деятельность агентов в измеримые бизнес-результаты.</p> <h3>Три приоритета для руководителей сервисных компаний</h3> <p>Три шага должны быть в повестке дня каждого руководителя сервисной компании прямо сейчас.</p> <ul> <li><strong>Продуктивизация доставки.</strong> Рассматривайте свою агентную платформу как продукт, а не как внутренний акселератор. Разработайте для нее дорожную карту, обеспечьте выделенную инженерную поддержку, укрепите безопасность, прозрачное ценообразование и четкие условия владения интеллектуальной собственностью и данными. Покупатели уже спрашивают, будут ли поставщики поддерживать собственные платформы так же, как это делают разработчики ПО. Продажи увеличиваются, когда ответ положительный.</li> <li><strong>Модернизация коммерческой модели.</strong> Ценообразование, основанное на результатах, фиксированная плата и оплата за потребление должны рассматриваться наряду с оплатой по времени и материалам как первоклассные варианты. Создайте инструменты, KPI и отчетность, которые сделают результаты убедительными для покупателей. Реинвестируйте сэкономленные благодаря автоматизации средства в следующий этап исследований и разработок платформы.</li> <li><strong>Выход за рамки основной платформы.</strong> По мере того, как агентные инструменты становятся товаром массового потребления, передовые разработки смещаются к вертикальным сценариям действий, акселераторам, специфичным для независимых поставщиков ПО, доменным пакетам и пакетам агентов, ориентированным на определенные персоны. Здесь наиболее глубоко закодированы бизнес-контекст, логика рабочих процессов и глубина соответствия требованиям — и универсальным платформам будет непросто это учесть.</li> </ul> <p>Агентный ИИ переписывает экономику, контракты и контрольные точки индустрии услуг. Поставщики, которые преуспеют в следующие десять лет, реализуют продуктивизацию услуг на основе проприетарных агентных платформ, они будут рассматривать управление и совместимость как конкурентные преимущества и устанавливать цены, исходя из результатов для клиентов.</p> В течение трех десятилетий индустрия ИТ- и бизнес-услуг работала по знакомой формуле: увеличение численности … article https://www.itweek.ru/themes/detail.php?ID=234794 Tue, 12 May 2026 10:38:42 +0300 <p><em>Предсказанного резкого падения рынка смартфонов в 2026 году не произошло. </em><em>Apple</em> <em>и </em><em>Samsung</em> <em>увеличили долю, потеснив трех других вендоров из топ-5. В России продажи активно наращивает кроссбордер. Рассмотрим, что происходит на мировом рынке смартфонов, наступили ли уже «сложные времена» и при чем тут «мемфляция».</em></p> <h3>Мем, определяющий динамику</h3> <p>Обсуждая итоги 2025 года, аналитики сулили мировому рынку смартфонов падение в 2026 году. Первоначальные прогнозы в декабре-январе были достаточно консервативные, «минус <nobr>2-3%».</nobr> Однако в феврале IDC выдала шокирующие 12,9%. Вслед за ними аналитики Omdia предсказали падение «всего» на 7%, но тут же оговорились, что рост цен и геополитическая нестабильность могут довести до падения и на все 15%.</p> <p>Причина — «мемфляция», термин которым в Gartner назвали продолжающийся быстрый рост цен на память и накопители. Она будет длиться минимум до конца 2027 года, с соответствующими последствиями в виде роста устройства, в которых они используются.</p> <p>Рынку ПК тоже предрекали падение, но он в первом квартале года неожиданно вырос. Скептики из IDC полагают, что всего на 1%, в Omdia видят рост 3,2%, а в Gartner — целых 4%. Причина роста — клиенты закупались ударными темпами впрок, ожидая долгосрочного роста цен на комплектующие.</p> <h3>Оценки разделились </h3> <p>По итогам первого квартала 2026 года оценки мирового рынка смартфонов разделились. По данным Omdia, рынок вырос, хотя и всего на 1%, на ожидании дальнейшего подорожания. Повышение цен на комплектующие пока еще не в полной мере отразилось на розничном рынке. В первом квартале 2026 года оно составило 90% по отношению к четвертому кварталу <nobr>2025-го,</nobr> а во втором квартале цены, как ожидается, вырастут еще на 30%.</p> <p><strong>Продажи смартфонов в первых кварталах 2025 и 2026 годов (млн. штук) </strong></p> <table> <tbody> <tr> <th> Вендор</th> <th> Продажи в первом квартале 2026 г.</th> <th> Доля рынка в первом квартале 2026 г.</th> <th> Продажи в первом квартале 2025 г.</th> <th> Доля рынка в первом квартале 2025 г.</th> <th> Рост 2026/2025</th> </tr> <tr> <td> Samsung</td> <td> 65,4</td> <td> 22%</td> <td> 60,5</td> <td> 20%</td> <td> 8%</td> </tr> <tr> <td> Apple</td> <td> 60,4</td> <td> 20%</td> <td> 55,0</td> <td> 19%</td> <td> 10%</td> </tr> <tr> <td> Xiaomi</td> <td> 33,8</td> <td> 11%</td> <td> 41,8</td> <td> 14%</td> <td> −19%</td> </tr> <tr> <td> Oppo</td> <td> 30,7</td> <td> 10%</td> <td> 32,8</td> <td> 11%</td> <td> −6%</td> </tr> <tr> <td> vivo</td> <td> 21,3</td> <td> 7%</td> <td> 22,9</td> <td> 8%</td> <td> −7%</td> </tr> <tr> <td> Другие</td> <td> 86,8</td> <td> 29%</td> <td> 83,9</td> <td> 28%</td> <td> 3%</td> </tr> <tr> <td> <strong>Всего</strong></td> <td> <strong>298,5</strong></td> <td> <strong>100%</strong></td> <td> <strong>296,9</strong></td> <td> <strong>100%</strong></td> <td> <strong>1%</strong></td> </tr> </tbody> </table> <p><em>Источник: Omdia. </em></p> <p><em>В IDC же полагают, что сложные времена уже наступили. По оценке аналитиков, продажи в первом квартале упали «год к году» на 4,1% ― до 289,7 млн. ​​штук, причем это падение названо лишь небольшим предвестником того, что ждет рынок в 2026 году. </em></p> <p><strong>Продажи смартфонов в первых кварталах 2025 и 2026 годов (млн. штук)</strong></p> <table> <tbody> <tr> <th> Вендор</th> <th> Продажи в первом квартале 2026 г.</th> <th> Доля рынка в первом квартале 2026 г.</th> <th> Продажи в первом квартале 2025 г.</th> <th> Доля рынка в первом квартале 2025 г.</th> <th> Рост 2026/2025</th> </tr> <tr> <td> Samsung</td> <td> 62,8</td> <td> 21,7%</td> <td> 60,6</td> <td> 20,1%</td> <td> 3,6%</td> </tr> <tr> <td> Apple</td> <td> 61,1</td> <td> 21,1%</td> <td> 59,1</td> <td> 19,6%</td> <td> 3,3%</td> </tr> <tr> <td> Xiaomi</td> <td> 33,8</td> <td> 11,7%</td> <td> 41,8</td> <td> 13,8%</td> <td> −19,1%</td> </tr> <tr> <td> Oppo</td> <td> 30,7</td> <td> 10,6%</td> <td> 34,1</td> <td> 11,3%</td> <td> −9,9%</td> </tr> <tr> <td> vivo</td> <td> 21,2</td> <td> 7,3%</td> <td> 22,7</td> <td> 7,5%</td> <td> −6,8%</td> </tr> <tr> <td> Другие</td> <td> 80,1</td> <td> 27,6%</td> <td> 83,6</td> <td> 27,7%</td> <td> −4,2%</td> </tr> <tr> <td> <strong>Всего</strong></td> <td> <strong>289,7</strong></td> <td> <strong>100,0%</strong></td> <td> <strong>302</strong></td> <td> <strong>100,0%</strong></td> <td> −4,1%</td> </tr> </tbody> </table> <p><em>Источник: IDC. </em></p> <p><em>Аналитики обеих компаний сходятся на том, что продажи Apple и Samsung растут, по версии Omdia — гораздо более высокими темпами, но зато по версии IDC — на падающем рынке. По динамике остальных трех компаний из топ-5 существенных расхождений агентства не продемонстрировали.</em></p> <p>«Другие» по версии Omdia тоже немного нарастили продажи. Это, казалось бы, противоречит часто встречающемуся утверждению о неизбежной насильственной премиализации рынка за счет вымывания бюджетных смартфонов. Но среди «других» — такие известные компании, как Honor и Huawei. Первая, по версии IDC, нарастила продажи на целых 24% в количественном измерении, это самый высокий результат среди компаний из первой десятки. Получен этот рост во многом за счет переориентации Honor на зарубежные рынки, тогда как в самом Китае рынок смартфонов уменьшился на 1%.</p> <h3>Что в Китае</h3> <p>На рынке Китая, крупнейшем из страновых (почти 70 млн. проданных устройств), в первом квартале наблюдается «эпоха больших перемен». Apple прибавила 42%, Xiaomi потеряла 35% и упала с первого места по итогам первого квартала 2025 года на пятое. Потерял 1% и Азиатско-Тихоокеанский регион (без Китая). Прибавили Европа, Латинская Америка и Африка.</p> <p>#IMAGE_234795#</p> <p>Динамика продаж вендоров в Китае и мире в целом соответствует прогнозу — в наибольшей степени страдают производители недорогих устройств. А премиальные бренды, такие как Apple и Samsung (в Китае место последнего занимает Huawei) от мемфляции выиграют. У них и доля комплектующих в стоимости меньше, и потребитель богаче, и ценой они могут, при необходимости маневрировать, сохраняя доходность. Прогнозируемому падению продаж субфлагманов тоже можно найти объяснение. Те, кому по карману флагман, купят его, остальные перейдут на модели попроще или останутся с прошлогодней моделью.</p> <p>#IMAGE_234796#</p> <p>Дальнейший рост стоимости комплектующих, как полагают в Omdia, приведет к годовому падению продаж в Китае на 10%. Впрочем, это не самый плохой результат: глобальный рынок, считают в компании, в 2026 году уменьшится на 15%. Предыдущий «самый плохой» прогноз принадлежал IDC (минус 12,9%), а аналитики Omdia <a href="https://merlion.com/press-center/news/analiticheskiy-obzor-somneniya-v-buducshem-mirovogo-rynka-smartfonov-ischezli-no-ne-tak-kak-hotelos-by">надеялись</a>, что падение составит 7%, хотя и допускали, что оно может быть и 15%. Теперь 15% — это «база».</p> <h3>AMOLED в бюджетные модели</h3> <p>Ожидается, что производство AMOLED-экранов (Active Matrix Organic Light-Emitting Diode, современная технология дисплеев, где каждый пиксель состоит из органических светодиодов, управляемых активной матрицей транзисторов, TFT) упадет незначительно. По прогнозу Omdia, в 2026 году их продажи снизятся на 7%, до 778 млн. штук. Для сравнения, в <nobr>2024-м</nobr> они выросли на 29%, в <nobr>2025-м —</nobr> еще на 5%.</p> <p>С одной стороны, ослабнет спрос на AMOLED со стороны китайских производителей смартфонов, с другой — китайские же производители экранов прибегнут к «более агрессивным ценовым стратегиям», чтобы поддержать загрузку своих мощностей.</p> <p>И если рынок смартфонов упадет на <nobr>12-15%,</nobr> а продажи AMOLED-экранов для них — всего на 7%, то это означает, что такие экраны получит бóльшая доля устройств, чем ранее. Если посмотреть на разбивку продаж по ценовым категориям, то чтобы продать почти 800 млн. AMOLED-экранов, их надо ставить даже в устройства категории <nobr>200-299 долл.</nobr> То есть на фоне общей «шринкфляции» (падение характеристик при одновременном росте цены) смартфонов есть шанс получить устройство с самым современным экраном.</p> <h3>Что в России</h3> <p>Оценки состояния и динамики отечественного рынка расходятся куда более значительно, чем данные зарубежных исследователей. Рынок смартфонов в 2025 году сократился, по разным оценкам, на <nobr>19-25%</nobr> в годовом выражении, заявили «Ведомости» на основе данных двух игроков рынка. Отмечается, что за год в России было продано 24,2 млн. устройств на общую сумму 588 млрд. рублей, в то время как за 2024 год — 29,8 млн. устройств на 720 млрд. рублей.</p> <p>Если исходить из приведенных абсолютных цифр, падение в штуках составило 22%, а в деньгах — 23%. При этом стоит отметить, что компании, анализируя рынок, порой экстраполируют свои результаты на ситуацию в целом или что-то не учитывают.</p> <p>Другую оценку дают в Data Insight. По их данным, весь рынок смартфонов сократился по числу проданных устройств на 5% и продолжит падение в 2026 году.</p> <p><strong>Динамика продаж смартфонов в России, <nobr>2023-2026 годы.</nobr></strong></p> <table> <tbody> <tr> <th> <br/> </th> <th> 2023</th> <th> 2024</th> <th> 2025</th> <th> 2026</th> </tr> <tr> <td> Продажи, млн. штук</td> <td> 30,7</td> <td> 29,8</td> <td> 26,5</td> <td> 23,5</td> </tr> <tr> <td> Продажи, млрд. руб.</td> <td> 681</td> <td> 725</td> <td> 708</td> <td> 670</td> </tr> <tr> <td> Средняя цена, руб.</td> <td> 22200</td> <td> 24300</td> <td> 26700</td> <td> 28500</td> </tr> <tr> <td> Кроссбордер, млрд. руб.</td> <td> 20</td> <td> 45</td> <td> 100</td> <td> 180</td> </tr> <tr> <td> Всего, млрд. руб.</td> <td> 700</td> <td> 770</td> <td> 808</td> <td> 850</td> </tr> </tbody> </table> <p><em>Источник: Data Insight (данные за 2025 и 2026 годы — оценочные).</em></p> <p>Данные за 2024 год в обоих случаях практически одинаковые, а вот по 2025 году имеется радикальное расхождение за счет более чем удвоившегося объема «кроссбордера» — покупок напрямую в иностранных магазинах. В этом году, по Data Insight, объем таких покупок почти удвоится. В результате кроссбордер составит немногим менее 20% всех продаж в рублях.</p> <p>В целом же российские тенденции, как по объемам продаж, так и по ценам, будут следовать мировым. Российский рынок в 2026 году поддержат кроссбордерные продажи, а также отсутствие излишне строгих требований к устройствам, подобных тем, которые были введены летом 2025 года в ЕС. Среди них требования к ремонтопригодности, сроку жизни и поддержке со стороны вендора.</p> <h3>Что в итоге</h3> <p>Продажи мирового рынка смартфонов в первом квартале 2026 года держатся на уровне прошлого года, ожидавшегося резкого падения не произошло. Мемфляция определила быстрый рост цен на память и накопители. Клиенты закупаются впрок, уменьшая тем самым потенциальный спрос в остальных кварталах года.</p> <p>Аналитики предсказывают увеличение доли дорогих устройств, в частности Apple и Samsung, наряду с шринкфляцией ― ухудшением характеристик смартфонов при росте цен на них. При этом не исключено неожиданное проникновение высокотехнологичных AMOLED-экранов в сегмент бюджетных устройств.</p> <p>Российский рынок в 2026 году поддержат кроссбордерные продажи, а также отсутствие излишне строгих требований к гарантийному сопровождению устройств.</p> Предсказанного резкого падения рынка смартфонов в 2026 году не произошло. Apple и Samsung увеличили долю, потеснив … article Дмитрий Гапотченко, аналитик Merlion https://www.itweek.ru/themes/detail.php?ID=234792 Tue, 12 May 2026 10:16:01 +0300 <p>Юридическая работа переживает тихий сдвиг: поиск норм и практики перестаёт быть центром профессии, уступая место анализу, интерпретации и управлению рисками. На фоне перегрузки юристов это становится особенно заметно: 63% специалистов, по данным исследования PRAVO TECH и платформы «Понимаю», связывают выгорание со слишком большим объёмом работы и нехваткой времени, а 17% — с отсутствием технологических решений для автоматизации рутинных задач.</p> <p>В 2026 году ИИ берёт на себя часть первичной навигации и систематизации, возвращая юристу время для главного: выстраивания позиции, оценки последствий и принятия решений.</p> <p>Рассмотрим, как меняется роль юриста и какие задачи уже сегодня закрывают ИИ-инструменты.</p> <h3>Что меняется в работе юриста при использовании ИИ</h3> <p>Раньше типовая цепочка юридической работы выглядела так: поиск ­­ проверка — анализ — вывод. Юрист тратил значительную часть времени на первые два этапа: найти релевантную норму, подобрать судебную практику, проверить изменения, сопоставить несколько источников.</p> <p>ИИ меняет не саму суть юридической работы, а распределение времени внутри этого процесса. Его главная ценность в праве не в том, что он быстрее пишет юридические тексты, его задача — сократить путь от разрозненных документов к структурированной основе для анализа, с которой уже работает юрист. При этом система не принимает решение за юриста. Наоборот, роль человека становится более ответственной: не принять машинный ответ как есть, а проверить, действительно ли найденные источники применимы к конкретной ситуации.</p> <h3>Почему юридический ИИ — это не просто чат-бот</h3> <p>Для аудитории важно разделять две вещи: обычную языковую модель и полноценный юридический ИИ-инструмент.</p> <p>Обычная модель может сгенерировать убедительный текст. Но в праве, как и в иных сложных доменах, таких как медицина, этого недостаточно. Юридический ответ должен быть проверяемым: с понятными источниками, актуальными нормами, применимой практикой и указанием зон неопределённости.</p> <p>С точки зрения разработки качественная legal AI-система должна уметь не столько отвечать на вопрос, сколько:</p> <ul> <li> искать по проверенной и постоянно обновляемой базе документов;</li> <li> отличать нормативные акты от судебной практики и экспертных комментариев;</li> <li> показывать источники и конкретные фрагменты текста, на которых основан вывод;</li> <li> не галлюцинировать при нехватке данных, а прямо сообщать, что релевантные источники не найдены;</li> <li> готовить ответ не в свободной форме, а используя один из понятных юристу шаблонов, где шаблон — не форма для заполнения, а стиль размышлений;</li> <li> работать с конфиденциальными данными (при их наличии) в безопасном контуре.</li> </ul> <p>Иначе мы получаем не юридический инструмент, а генератор правдоподобных текстов. Для права это опасная разница.</p> <p>Технически эта задача чаще всего решается через RAG — retrieval-augmented generation, то есть генерацию с опорой на найденные документы.</p> <p>Логика здесь простая: мы не предполагаем, что LLM сама по себе, только за счёт знаний, полученных при обучении, корректно ответит на сложный юридический вопрос. Но если сначала найти релевантные фрагменты законодательства, судебной практики или разъяснений, а затем передать их модели как основу для ответа, задача становится гораздо более управляемой. Модель уже не «вспоминает право из головы», а отвечает на вопрос с опорой на конкретные источники.</p> <p>При этом даже наличие релевантных документов не гарантирует правильный вывод. В сложных кейсах вопрос приходится декомпозировать на более простые подвопросы, отдельно выстраивать логику анализа и контролировать, как модель переходит от источников к заключению. Но базовый принцип остаётся тем же: юридический ИИ должен начинаться не с генерации текста, а с поиска качественных источников.</p> <p>Основная техническая работа в RAG — это не промпт-инжиниринг, как может показаться со стороны, а построение локальной поисковой системы. Юридические документы нужно разбить на небольшие смысловые фрагменты, проиндексировать и настроить поиск так, чтобы по вопросу пользователя в верхние позиции выдачи попадали действительно релевантные нормы, судебные акты и разъяснения.</p> <p>Даже если взять всего несколько популярных областей — например, семейное право, банкротство физических лиц, налоговое законодательство, законодательство о недвижимости и защите прав потребителей, — база быстро превращается в сотни тысяч фрагментов. Для такой системы критично, чтобы необходимые источники с высокой вероятностью попадали хотя бы в топ-10 или топ-100 поисковой выдачи. Если поиск не находит нужные фрагменты, дальнейшая генерация теряет смысл.</p> <p>Здесь работает базовый для AI-продуктов принцип: «garbage in — garbage out», или «мусор на входе — мусор на выходе». Если модель получает нерелевантные документы, она может сформулировать связный и уверенный, но юридически неправильный ответ.</p> <p>У юридического RAG есть и своя специфика. Недостаточно просто найти похожие по тексту нормы. Нужно ещё отфильтровать источники, которые формально близки к вопросу, но не применимы к конкретной ситуации. Иначе модель может принять нерелевантную норму за значимую и построить на ней ошибочный вывод. Поэтому качество юридического ИИ во многом определяется не только самой LLM, но и тем, насколько точно работает поиск, фильтрация и подготовка источников перед генерацией ответа.</p> <h3>Ключевое преимущество ИИ: работа с контекстом</h3> <p>Юридический вопрос редко решается одной нормой. Даже если в законе есть понятное общее правило, в реальной задаче почти всегда важны дополнительные обстоятельства: факты дела, документы, переписка сторон, судебная практика, исключения из общего правила и цель, с которой клиент обращается к юристу.</p> <p>ИИ особенно полезен там, где нужно быстро собрать эти слои в одну структуру: найти базовую норму, показать связанные положения, подсветить судебную практику и указать, какие факты нужно уточнить перед выводом. Но именно здесь возникает и главный риск: если система найдёт только самое очевидное правило, она может дать формально правильный, но практически неполный ответ.</p> <p>Для юридического ИИ недостаточно просто найти похожий фрагмент текста. Важно понять, является ли он основным правилом, есть ли рядом специальные нормы, исключения или практика, которые меняют вывод. Иначе модель может уверенно построить ответ на одном источнике, хотя для реальной консультации нужно несколько уровней анализа.</p> <p>В таких ситуациях задача юриста — проверять не только сами источники, но и логику перехода от источников к выводу: почему система выбрала именно эти нормы, какие факты она считает значимыми и не пропустила ли условия, при которых общее правило применяется иначе.</p> <p>Хороший пример — споры об алиментах. Если смотреть только на общую норму, вывод кажется простым: на одного ребёнка взыскивается четверть дохода родителя, на двух — треть, на трёх и более — половина. ИИ, который найдёт только эту норму, может механически предложить расчёт в процентах от заработка.</p> <p>Но в реальной задаче этого часто недостаточно. Если у родителя нерегулярный доход или он получает деньги в натуре, суд может определить алименты в твёрдой денежной сумме или совместить долю от дохода с фиксированной суммой. Кроме того, суд учитывает материальное и семейное положение сторон и старается сохранить ребёнку прежний уровень обеспечения.</p> <p>Для юридического ИИ это хороший пример того, почему недостаточно найти одну похожую норму. Система должна увидеть не только базовую формулу, но и исключения, практику их применения и факты, которые нужно уточнить с учетом контекста. Иначе ответ будет формально похож на юридический, но непригоден для реальной консультации.</p> <h3>Где ИИ уже применяют в юридической работе</h3> <p>ИИ в праве лучше всего раскрывается не в абстрактных рассуждениях о «замене юриста», а в конкретных рабочих сценариях. На практике такие системы чаще всего закрывают задачи, где есть большой объём документов, повторяемые процессы, необходимость быстро собрать контекст и передать юристу проверяемую основу для дальнейшего анализа.</p> <p><strong>1. Юридический диалоговый ассистент</strong><strong>. </strong>Первый сценарий — диалоговый правовой ассистент. Например, юрист может задать вопрос обычным языком: «Поставщик нарушил срок поставки, но ссылается на форс-мажор. Какие нормы, документы и судебную практику нужно проверить перед подготовкой претензии?».</p> <p>Хороший ассистент в такой ситуации не должен просто выдать готовый текст претензии. Он должен разложить задачу: какие условия договора проверить, какие уведомления направлял контрагент, есть ли подтверждение чрезвычайных обстоятельств, какие нормы применимы и какая судебная практика показывает, когда ссылка на форс-мажор действительно работает, а когда нет.</p> <p>Такой ответ остаётся рабочим черновиком. Его нужно проверять: открывать ссылки, сверять актуальность норм, смотреть, насколько судебная практика применима к конкретным обстоятельствам. Но для юриста это уже не пустой лист, а структурированная основа для дальнейшей работы.</p> <p><strong>2. Автоматическая проверка договоров и документов</strong><strong>. </strong>Второй сценарий — предварительная проверка входящих документов. Здесь ИИ работает как скрининг-система: он не принимает решение за юриста, но помогает быстрее увидеть потенциально опасные зоны. При этом перед системой не стоит задача все сделать идеально: при разработке ее учат определять 80% самых популярных рисков, и это уже снимает значимую часть рутины с юриста.</p> <p>Например, при проверке договора система может подсветить:</p> <ul> <li> невыгодную договорную подсудность;</li> <li>одностороннее ограничение ответственности;</li> <li> нестандартные штрафные санкции;</li> <li> размытые сроки оплаты или поставки;</li> <li> рискованные условия приёмки;</li> <li> несбалансированный порядок расторжения;</li> <li> положения о персональных данных;</li> <li> условия об интеллектуальных правах;</li> <li> противоречия между разными разделами договора.</li> </ul> <p>Ценность такого инструмента не в том, что он проверил договор вместо юриста. Ценность в другом: юрист не тратит одинаковое количество времени на все разделы документа, а быстрее переходит к пунктам, которые действительно требуют оценки и доработки.</p> <p>Это особенно полезно там, где через юридическую функцию проходит большой поток однотипных документов: договоры поставки, подряда, аренды, NDA, лицензионные соглашения, дополнительные соглашения, акты и претензии.</p> <p><strong>3. Интеллектуальный поиск и классификация источников</strong><strong>. </strong>Третий сценарий — интеллектуальный поиск юридических документов. В отличие от обычного поиска, ИИ может не просто выдать список ссылок, а помочь распределить источники по типам:</p> <ul> <li> нормативные правовые акты;</li> <li> судебная практика;</li> <li> обзоры Верховного суда;</li> <li> письма и разъяснения ведомств;</li> <li> локальные документы компании;</li> <li> научные комментарии;</li> <li> экспертные позиции.</li> </ul> <p>Для юриста это важно, потому что правовой вывод зависит не только от наличия источника, но и от его веса. Закон, постановление Пленума, письмо ведомства, статья эксперта и внутренний регламент компании имеют разную юридическую силу.</p> <p>С инженерной точки зрения это одна из важных задач юридического ИИ. Система должна не просто найти похожий текст, а помочь юристу понять, насколько источник действительно применим: относится ли он к нужной отрасли права, действует ли сейчас, не противоречит ли более сильному источнику и не вырван ли из другого правового контекста.</p> <p>Для юридического ИИ ошибка в иерархии источников опаснее обычной ошибки поиска. Система может найти похожий документ и на его основе сформулировать убедительный ответ, но если этот документ не имеет нужной юридической силы или относится к другому контексту, вывод будет выглядеть профессионально, оставаясь неверным по существу.</p> <p><strong>4. Уточнение ситуации клиента перед работой юриста</strong><strong>. </strong>Четвёртый сценарий — уточнение ситуации клиента. Это отдельная задача, которую часто недооценивают: прежде чем юрист начнёт анализировать право, нужно правильно собрать факты.</p> <p>В реальной практике клиент нередко описывает проблему неполно: пропускает даты, не прикладывает документы, не различает юридически значимые обстоятельства и эмоциональные детали, не понимает, какие вопросы важны для квалификации ситуации. Из-за этого юристу приходится тратить время не только на правовой анализ, но и на первичное интервью.</p> <p>ИИ может помочь на этом этапе. Если система настроена правильно, она не даёт клиенту готовую консультацию, а задаёт уточняющие вопросы: что произошло, когда, между кем, какие документы есть, какие действия уже предпринимались, какие сроки истекают, чего клиент хочет добиться.</p> <p>Результатом становится не юридическое заключение, а структурированное описание ситуации для юриста: факты, документы, хронология, недостающие сведения и предварительные вопросы для проверки. Это снижает риск того, что юрист начнёт анализ с неполной или искажённой картины.</p> <p>Например, частый сценарий — клиент обращается к юристу с формулировкой: «У меня арестовали карту» или «банк списал деньги, но я не понимаю за что». На этом этапе клиент обычно смешивает несколько разных ситуаций: арест счёта, взыскание денег, судебный приказ, исполнительное производство, штраф, кредитную задолженность. ИИ-ассистент в таком случае не должен сразу давать совет «как снять арест». Его задача — провести первичное интервью и собрать факты, без которых юристу сложно оценить ситуацию. Система может в произвольном порядке уточнить:</p> <ul> <li> когда клиент узнал о списании или аресте денежных средств;</li> <li> какая сумма была списана или заблокирована на счёте;</li> <li> известно ли клиенту, с чем может быть связано взыскание: кредит, микрозайм, алименты, коммунальные платежи, штрафы, налоговая задолженность, долг перед физическим лицом или иное обязательство;</li> <li> если речь может идти о кредите или займе — в какой банк или микрофинансовую организацию клиент обращался, когда возникла задолженность, какой была первоначальная сумма кредита и какой размер долга указан сейчас;</li> <li> есть ли у клиента информация о судебном акте: решении суда или судебном приказе о взыскании задолженности;</li> <li> получал ли клиент копию судебного акта и когда именно;</li> <li> иные вопросы.</li> </ul> <p>На выходе юрист получает не хаотичное описание «у меня сняли деньги», а структурированную картину: когда клиент узнал о списании или аресте, какая сумма была списана или заблокирована, с каким обязательством может быть связано взыскание, кто является кредитором или взыскателем, есть ли судебный акт, получал ли клиент его копию, согласен ли он с суммой и основанием взыскания, возбуждено ли исполнительное производство и какие документы уже есть на руках.</p> <p>После этого юрист может быстрее понять, с чем он работает: нужно ли проверять судебный приказ или решение суда, сроки для подачи возражений или жалобы, корректность суммы взыскания, законность действий пристава или банка, основания для снятия ареста, ограничения по размеру удержаний и перечень документов, которые нужно дополнительно запросить у клиента.</p> <p>Такой сценарий хорошо показывает ценность ИИ именно на входе в юридическую работу. Ассистент не заменяет консультацию и не решает, законно ли списание. Он помогает собрать фактуру так, чтобы юрист начал работу не с расшифровки эмоционального рассказа клиента, а с понятной структуры дела.</p> <p><strong>5. Внутренние ассистенты для юридических департаментов</strong><strong>. </strong>Отдельный прикладной сценарий — внутренние ИИ-ассистенты для компаний. Они работают не с абстрактным интернетом, а с корпоративной базой знаний: типовыми договорами, регламентами, шаблонами претензий, архивом заключений, политиками и согласованными позициями юридического отдела.</p> <p>Такие системы помогают быстрее закрывать повторяющиеся кейсы. Например, внутренний клиент может спросить, какой шаблон договора использовать, какие документы нужны для согласования сделки, какие условия нельзя менять без участия юрдепартамента или какие риски обычно возникают в конкретном типе договора.</p> <p>Для компании это удобная точка входа в legal AI, потому что источники контролируемы, процессы повторяемы, а качество ответа можно проверять. Иногда компании могут сходу начать ориентироваться на решение сложных задач, но это неверный подход: начинать внедрение обычно разумнее с задач, где много повторяемости и понятен контур риска: FAQ для бизнеса, база знаний юрдепартамента, первичный анализ входящих договоров, проверка комплектности документов.</p> <p><strong>6. Автоматизация типовых обращений</strong><strong>. </strong>Ещё один сценарий — автоматизация повторяющихся юридических обращений. Такие решения уже внедряют региональные органы юстиции и Госуслуги: там особенно много однотипных вопросов, где пользователю нужно не полноценное правовое заключение, а понятная первичная навигация.</p> <p>В таких случаях ИИ может объяснить порядок действий, подсказать, какие документы нужны, какие сроки важно не пропустить, куда обращаться дальше и какие стандартные причины отказа или удовлетворения требования существуют. Это может быть полезно, например, при обращениях по исполнительным производствам, семейным вопросам, защите прав потребителей, социальным выплатам или административным процедурам.</p> <h3>Чек-лист для контроля юридического ИИ</h3> <p>На практике ответ ИИ нужно оценивать не по тому, насколько уверенно и гладко он написан. Для юридической работы важнее другое: понял ли он вопрос, дал ли ответ по существу, достаточно ли полно раскрыл ситуацию, сослался ли на действующие нормы и можно ли из его ответа сделать практический вывод.</p> <p>Поэтому проверка AI-ответа юристом должна идти минимум <strong>по пяти направлениям</strong>.</p> <ol> <li> <strong>Первое — соответствие вопросу.</strong> Система могла формально написать много полезного текста, но ответить не на тот вопрос. Например, пользователь спрашивает, как действовать в конкретной ситуации, а модель начинает объяснять общее понятие договора, алиментов или исполнительного производства.</li> <li> <strong>Второе — полнота.</strong> Ответ должен позволять сделать вывод: можно или нельзя, какие условия важны, какие действия нужно предпринять, какие исключения есть. Поверхностный ответ может быть не ошибочным, но всё равно бесполезным, если из него нельзя понять порядок действий или условия применения нормы.</li> <li> <strong>Третье — достоверность.</strong> Это главный критерий. Юрист должен проверить, соответствует ли ответ действующему законодательству и судебной практике, нет ли критической ошибки, устаревшей нормы, неверного вывода или пропущенного важного условия.</li> <li> <strong>Четвёртое — ссылки.</strong> Для юридического ИИ недостаточно написать «согласно закону». Нужно указать конкретный нормативный акт и статью, а при необходимости — судебную практику или разъяснения. При этом важно не только наличие ссылки, но и её качество: тот ли это закон, та ли статья, все ли базовые нормы учтены, не подменён ли основной источник вторичным комментарием.</li> <li> <strong>Пятое — структура и логика.</strong> Хороший юридический ответ должен идти от общего к частному, не противоречить сам себе, не смешивать разные правовые режимы и не нарушать последовательность действий. Если сначала предлагается идти в суд, а потом направлять обязательную претензию, это уже не просто проблема текста, а ошибка в логике юридического действия.</li> </ol> <p>Отдельно нужно проверять не только итоговый ответ, но и то, какие источники система получила на вход. В RAG-системах качество ответа напрямую зависит от качества найденных фрагментов. Если в выдачу попали не те нормы, устаревшая редакция закона, вторичные источники вместо базовой статьи или нерелевантные сегменты, модель может построить на них уверенный, но неправильный вывод.</p> <p>Поэтому профессиональный контроль юридического ИИ — это не ручная перепроверка «на всякий случай», а обязательная часть процесса. Система может ускорить поиск, структурировать источники и предложить первичный вывод, но юрист должен проверить, что ответ соответствует вопросу, полон, достоверен, основан на правильных источниках и логически пригоден для применения в конкретной ситуации.</p> <h3>Конфиденциальность и архитектура решения</h3> <p>Отдельный вопрос — конфиденциальность. Не все документы можно загружать в публичные ИИ-сервисы. Договоры, материалы судебных споров, персональные данные, коммерческие условия, внутренние политики, переписка по сделкам и документы клиентов могут содержать чувствительную информацию.</p> <p>Поэтому для юридической функции часто недостаточно просто подключить внешний AI-сервис. Компании приходится думать об архитектуре: где хранятся документы, кто имеет к ним доступ, используются ли данные для обучения модели, можно ли восстановить историю запросов и понять, на каких источниках был основан ответ.</p> <p>Стоит понимать, что защищенная архитектура требует инфраструктурных затрат. Только затраты на вычислительные ресурсы могут потребовать десятков миллионов рублей капитальных вложений.</p> <p>Если система не может показать источники ответа, восстановить логику обработки запроса и обеспечить контроль над чувствительной информацией, её нельзя безопасно встраивать в юридический процесс.</p> <h3>Как меняется роль юриста</h3> <p>ИИ может найти норму, подобрать практику, подсветить риск и предложить структуру ответа. Но он не может взять на себя профессиональную ответственность за правовую позицию.</p> <p>В ближайшие годы для юриста важными станут не только навыки работы с правом, но и умение правильно ставить задачу ИИ, проверять источники, понимать ограничения модели и отличать убедительно написанный текст от юридически пригодного ответа.</p> <p>Главный навык юриста в эпоху ИИ — не получить красивую формулировку от модели, а быстро понять, где эта формулировка может быть неполной, устаревшей или юридически слабой.</p> <h3>Вывод</h3> <p>Мы входим в этап, когда ИИ становится неотъемлемой частью инфраструктуры для автоматизации рутины в сложных профессиональных областях — праве, медицине, финансах, комплаенсе и других сферах, где цена ошибки высока.</p> <p>В таких областях ценность ИИ не в том, что он сам принимает решения или действует полностью автономно, а в том, что он смещает фокус работы туда, где машина не может заменить человека: к экспертизе конкретного юриста, врача или другого специалиста, его профессиональному суждению и ответственности за итоговое решение.</p> <p>#IMAGE_234793#</p> Юридическая работа переживает тихий сдвиг: поиск норм и практики перестаёт быть центром профессии, уступая место анализу … article Владимир Воробьев, генеральный директор АО “Экспертные платформы” https://www.itweek.ru/themes/detail.php?ID=234791 Fri, 08 May 2026 13:37:31 +0300 <p>Эксперты компании «Информзащита» выявили, что 78% атак на киберфизические системы связаны с использованием удаленного доступа к открытым интернет-ресурсам без применения сложных техник взлома. В основе большинства инцидентов лежат простые сценарии подключения к доступным устройствам, а не эксплуатация уязвимостей или сложные цепочки атак. Зафиксировано смещение в сторону массовых, малозатратных по времени и ресурсам атак, где ключевым условием становится наличие открытого доступа и слабой или отсутствующей аутентификации.</p> <p>Ключевыми факторами, определяющими текущую ситуацию, выступают особенности самих киберфизических систем. Значительная часть используемых протоколов, таких как Modbus, изначально не содержит встроенных механизмов защиты и предполагает работу в изолированных средах. При подключении к интернету такие системы становятся уязвимыми по умолчанию. Дополнительным фактором выступает использование протоколов удаленного доступа, в частности VNC, которые нередко остаются доступными без должной аутентификации или с использованием стандартных учетных данных. В совокупности это формирует среду, в которой подключение к устройству становится технически простой задачей.</p> <p>Специалисты отмечают, что организации традиционно концентрируются на устранении уязвимостей и обновлении систем, однако в рассматриваемых инцидентах эти меры не оказывают решающего влияния. Большинство атак не требует эксплуатации уязвимостей, так как доступ к системам уже открыт через небезопасные протоколы или некорректно настроенные механизмы удаленного управления. В результате даже при формальном снижении числа уязвимостей фактический риск компрометации остается высоким.</p> <p>Сценарий развития таких атак, как правило, укладывается в повторяемую последовательность действий. Сначала злоумышленник определяет тип устройства или протокола, представляющий интерес, после чего с помощью открытых сервисов сканирования ищет доступные из интернета системы с нужными характеристиками. На следующем этапе происходит подключение: либо через протоколы удаленного доступа, либо через небезопасные коммуникационные интерфейсы. Если аутентификация отсутствует или используются типовые учетные данные, доступ получается без дополнительных усилий. Далее выполняется базовая разведка — просмотр параметров, регистров или конфигураций. Завершается атака изменением значений или настроек, что приводит к сбоям в работе оборудования или нарушению управляемых процессов. В ряде случаев злоумышленники фиксируют свои действия, чтобы затем опубликовать их и подтвердить факт вмешательства.</p> <p>Статистический разрез по типам атак подтверждает доминирование удаленного доступа как основного вектора. Еще 7% атак приходились на взаимодействие через HTTP, а 6% — на использование специализированного программного обеспечения производителей. При этом около 56% всех инцидентов были связаны с компрометацией систем HMI и SCADA, управляющих промышленными процессами в реальном времени. Среди других целей выделяются программируемые логические контроллеры и подключенные устройства, включая системы видеонаблюдения.</p> <p>Наибольшая концентрация инцидентов приходится на отрасли, где киберфизические системы напрямую связаны с непрерывными производственными процессами. Производственный сектор формирует 21% всех зафиксированных атак, водоснабжение и водоотведение — 16%, энергетика — 13%, агропромышленный комплекс — 11%, нефтегазовая отрасль — 10%. Остальные 29% распределяются между транспортной инфраструктурой, медицинскими учреждениями и коммерческими объектами с элементами автоматизации. В этих сегментах доля атак через удаленный доступ превышает 75%, что выше среднего значения по выборке.</p> <p>Снижение рисков в текущих условиях связано с базовыми мерами контроля доступа и конфигурации. Практика показывает, что наибольший эффект дает инвентаризация всех активов с внешним доступом и их сегментация с ограничением прямого выхода в интернет. Перевод удаленного управления в защищенные контуры с обязательной многофакторной аутентификацией снижает вероятность несанкционированного подключения. Дополнительный результат дает отказ от использования стандартных учетных данных и контроль конфигураций на уровне устройств. Организациям также необходимо внедрять мониторинг активности в OT-сегменте, поскольку классические средства обнаружения угроз в IT-инфраструктуре не фиксируют подобные сценарии.</p> <p>По оценке экспертов, в течение 2026 года доля атак через удаленный доступ может вырасти до <nobr>80-82%,</nobr> если текущая практика эксплуатации устройств сохранится. Сдерживающим фактором может стать только системное ограничение доступности киберфизических активов из внешних сетей и переход к централизованному управлению доступом. В противном случае рынок продолжит сталкиваться с инцидентами, в которых сложность атаки минимальна, а ущерб остается высоким.</p> Эксперты компании «Информзащита» выявили, что 78% атак на киберфизические системы связаны с использованием … message https://www.itweek.ru/themes/detail.php?ID=234790 Fri, 08 May 2026 13:34:50 +0300 <p>Компания BSS снизила нагрузку на операторов внутренней линии техподдержки для сотрудников Газпромбанка. Теперь там работает голосовой бот Тома: отвечает на справочные вопросы, рекомендует, как решить ошибки ПО, сам заводит и решает обращения в ServiceDesk.</p> <p>Над проектом работало 15 специалистов со стороны Газпромбанка и BSS. На первом этапе команда разработала 25 сценариев для обработки обращений в ServiceDesk и ответов на справочные вопросы. </p> <p>Далее добавили еще около 30 сценариев с интеграцией с системой учетных записей: теперь через бота можно, например, сбросить пароль или запросить дату приема на работу сотрудника. </p> <p>Позже команда создала текстового бота для обработки входящих обращений во внутренней системе ServiceDesk. Он автоматически принимает заявки, обновляет данные во внутренних системах и отправляет подтверждения.</p> <p>В результате заказчик получил голосового бота с 60+ сценариями. С момента внедрения система обработала более 75 000 звонков со средним процентом автоматизации 22% — то есть бот решил каждый пятый вопрос без помощи оператора. Качество моделей распознавания достигло 91 % — в большинстве случаев система уверенно распознает тематику обращений. </p> <p>Решение построено на речевых технологиях BSS. Dialogue Composer позволяет самостоятельно настроить, какие запросы бот может обработать. С помощью модуля ASR бот распознает речь говорящего, а с помощью NLU выделяет в ней намерение: на какую тему вопрос. Речевая аналитика помогает оценить качество ответов и улучшить работу бота. Все компоненты развернуты в контуре банка и интегрированы с его системами: телефонией, АСУП (ServiceDesk), системой управления учетными записями (IDM) и другими автоматизированными системами Банка.</p> <p>Компания BSS уже много лет сотрудничает с Газпромбанком: например, в 2022 году мы совместно внедрили бота для обслуживания юридических лиц. </p> <p>О дальнейших планах на «Тому» рассказал заместитель директора по продажам компании BSS Александр Маховский: «В ходе проекта команда успешно справилась с рядом сложных задач, включая работу с большим объемом специализированной лексики и повышение качества распознавания речи. При этом проект не завершился внедрением — он продолжает активно развиваться: уже ведется создание новых ботов с использованием AI-агентов и RAG. Также идет интенсивная работа команды Банка по расширению текущих сценариев и добавлению новых, что позволяет наращивать уровень автоматизации и эффективности коммуникаций».</p> <p>Начальник Управления информационной и технологической поддержки Газпромбанка Юрий Мельников подробнее рассказал о проделанной работе и планах на будущее: «Газпромбанк активно внедряет сервисы с использованием технологий ИИ. Совместно с компанией БСС развернута многомодульная платформа автоматизации внутренних сервисов в части поддержки пользователей и решения задач технической поддержки 2 линии. Также в рамках проекта была обучена команда наших сотрудников, дальнейшее развитие внедренных сервисов осуществляется внутри Банка. Важной вехой в развитии процессов автоматизации внутренних сервисов Банка станет также внедрение технологии ИИ-агентов, которая обеспечит новый уровень эффективности, повысив потенциальный объем автоматизации при значительном ускорении процессов».</p> Компания BSS снизила нагрузку на операторов внутренней линии техподдержки для сотрудников Газпромбанка. Теперь там работает … message https://www.itweek.ru/themes/detail.php?ID=234789 Fri, 08 May 2026 10:18:22 +0300 <p><em>Компании стремятся к многократному увеличению прибыли за счет искусственного интеллекта, но многие проекты быстро терпят неудачу. ИТ-аналитик Дэвид Гевирц </em><em>разбирает на </em><em>портале </em><em>ZDNet</em><em> реальные риски и показывает, как с помощью агентного ИИ получать надежные и прибыльные результаты.</em></p> <p>Представьте, что вы — генеральный директор. Ваша рабочая группа по стратегии в области ИИ только что представила вам два варианта.</p> <p>Первый — безопасный. Вы можете использовать агентный ИИ для сокращения накладных расходов и экономии 10% от общих затрат на человеческий капитал.</p> <p>Второй вариант — смелый. Вы можете увеличить рост в десять раз, используя агентный ИИ для трансформации деятельности вашей компании.</p> <p>Первый вариант практически не изменит ситуацию, но поможет инициативе в области ИИ окупиться. Второй вариант может значительно улучшить ваши финансовые показатели и сделать вас легендой в глазах совета директоров. Но также может привести к увольнению.</p> <p>Превосходные оценки ИИ зашкаливают. Согласно KPMG, агентный ИИ позволит получить ежегодный прирост производительности на 3 трлн. долл. Accenture утверждает, что агентный ИИ — это «не что иное, как новый тип капитала» и «знаменует собой сдвиг в экономической истории». Прошлой осенью Gartner заявила: «У организаций есть решающий период от трех до шести месяцев для определения своей стратегии развития агентного ИИ, поскольку отрасль находится на переломном этапе».</p> <p>Итак, что же делать?</p> <h3>Факторы риска</h3> <p>Gartner может посоветовать вам действовать прямо сейчас. Accenture советует стремиться к десятикратному росту, а не к 10%-ной экономии затрат. Однако сохраняйте спокойствие. Хотя инициативы в области агентного ИИ, несомненно, имеют огромный потенциал, начинание без четкой стратегии может привести к провалу.</p> <p>Как оказалось, у Gartner есть статистика и на этот счет. В ее исследовании говорится: «Более 40% проектов по агентному ИИ будут отменены к концу 2027 г. из-за растущих затрат, неясной бизнес-ценности или неадекватного контроля рисков».</p> <p>Есть и другие причины этих неудач. Gartner заявила, что большинство проектов на ранних стадиях — это эксперименты или проверка концепции, и так и должно быть. Но подобные тесты — это всего лишь тесты. Тесты не гарантируют успеха. В этом и суть.</p> <p><strong>1. Введение в заблуждение . </strong>С другой стороны, организации часто вводятся в заблуждение своими поставщиками. Многие поставщики, поддавшись ажиотажу вокруг ИИ, занимаются тем, что Gartner назвала «AI-washing». Нет, это не Джеймс Бонд в душе. Это термин, заимствованный из «гринвошинга» — практики ложного представления продуктов как экологически чистых.</p> <p>Gartner подсчитала, что менее 13% из тысяч поставщиков «агентного» ИИ выпускают действительно «агентные» продукты. Большинство компаний переименовывают существующие продукты — от ИИ-помощников и роботизатизации процессов до сервисов на основе скриптов и чат-ботов — в «агентные». Предположение о том, что эти инструменты могут выполнять автономные задачи, ошибочно, что приводит к пилотным проектам на основе этих продуктов, которые обречены на провал.</p> <p><strong>2. Неконтролируемые затраты. </strong>Еще один подвох — это затраты. Большинство реализаций ИИ полагаются для когнитивной обработки данных на внешние большие языковые модели, предоставляемые крупными сервис-провайдерами. Эти сервисы связываются с вашими приложениями через API.</p> <p>Представьте API как розетку в вашей стене. Вы подключаете кофеварку к этой розетке и получаете энергию для приготовления этого коричневого эликсира. Розетка и вилка — это стандартизированные интерфейсы (как и API). Ваша кофеварка — это ваше приложение. Облачный сервис — это энергоснабжающая компания, которой вы платите за использование.</p> <p>ИИ-компании измеряют потребление на основе показателя, называемого «токенами». Генеративный ИИ использует токены довольно экономно. Они расходуются, когда задается вопрос, и все. Как и в случае с кофеваркой, которая готовит чашку кофе, потребление энергии/токенов минимально.</p> <p>Теперь сравним потребление энергии кофеваркой с потреблением энергии серверной стойкой. Серверы потребляют больше энергии и используют ее постоянно, 24/7. Счет за электроэнергию для серверной стойки будет значительно выше, чем для кофеварки (даже часто используемой).</p> <p>То же самое происходит и с агентным ИИ, который работает практически постоянно, с множеством одновременно действующих агентов, потребляющих токены с невероятной скоростью. По мере того, как компании расширяют использование агентного ИИ, они обнаруживают, что их счета за облачные услуги стремительно растут. Неслучайно OpenAI поднялась от нулевой выручки в конце 2022 г. до более чем 20 млрд. долл. в <nobr>2025-м.</nobr></p> <p><strong>3. Непредсказуемые результаты. </strong>Еще одна ловушка заключается в том, что проекты ИИ являются «недетерминированными», то есть одни и те же входные данные могут давать разные выходные данные при разных запусках, поскольку ИИ учитывает вероятность, случайность и контекстную чувствительность, а не следует фиксированному, повторяемому пути выполнения.</p> <p>Эта непредсказуемость может быть очень опасна при создании и тестировании решений, отладке сбоев, проверке результатов, обеспечении соответствия нормативным требованиям и поддержании согласованного поведения при обновлениях и развертываниях.</p> <p>«Раньше ПО было исключительно детерминированным: одинаковые входные данные — одинаковые выходные данные, легко доверять. ИИ-агенты нарушают эту модель, поскольку одни и те же входные данные дают разные результаты. Это требует гибридного подхода. Контекст, контроль и управление нельзя просто добавить после развертывания. Компании, добивающиеся успеха, проектируют эти уровни с самого первого дня», — поясняет Мадхав Таттай, исполнительный вице-президент и генеральный менеджер Agentforce в Salesforce.</p> <p><strong>4. Несанкционированные агенты. </strong>Представьте себе, что может произойти, когда доверенный сотрудник начнет действовать ненадлежащим образом. То же самое может произойти и с агентами, за исключением того, что агенты намного быстрее любого сотрудника. Непреднамеренное действие, совершенное в больших масштабах, может распространиться по всей организации со скоростью света.</p> <p>Мамы могут хотеть от детей делать то, что они имеют в виду, а не что говорят. Они ожидают, что при правильном воспитании дети должны понимать, чего от них требуется, независимо от того, правильно ли это сформулировано.</p> <p>Несоответствие целей может стать реальной проблемой, если сотрудник неправильно вводит команду агенту. Хотя, вероятно, можно создать систему контроля и сдержек для агентов, более вероятная реальность такова, что если вы неправильно введете команду агенту, он не поймет вашего намерения. Он просто пронесется по вашей сети, оставляя за собой обломки.</p> <p>Если в вашей логической цепочке где-то есть неправильно проинструктированные агенты, эти ошибки будут каскадно распространяться на другие агенты, создавая эффект домино, который может заставить вас пожалеть, что вы не можете спрятаться в юрте в лесу на следующие два года.</p> <p><strong>5. Риск нарушения безопасности и конфиденциальности данных. </strong>Безопасность и конфиденциальность — еще одна проблема. Почти все глубокие развертывания ИИ-агентов предполагают использование LLM вне локальной сети. Это означает, что ваши данные должны быть отправлены ИИ где-то в облаке.</p> <p>Крупные ИИ-компании обещают, что не будут использовать ваши корпоративные данные для обучения, но факт остается фактом: вы все равно отправляете данные в систему, которую не контролируете. Это может вызвать множество проблем, связанных с конфиденциальностью, регулированием и управлением. Прежде чем принимать какие-либо окончательные решения о внедрении, обязательно тщательно изучите этот вопрос.</p> <p>Можно долго рассказывать о факторах риска. Существуют пугающие истории. McDonald’s потеряла сотни долларов на заказах макнаггетс, а также добавляла бекон в мороженое. Онкологический центр UT MD Anderson потерял 62 млн. долл. на внедрении Watson.</p> <p>Речь не о том, чтобы отпугнуть вас от агентного ИИ. Важно, чтобы вы понимали, что внедрение сопряжено с риском. Вам нужно очень стратегически и обдуманно подходить к этому. Это не новая блестящая игрушка. Это риск и возможность, от которых зависит судьба вашей компании.</p> <h3>Стратегии получения выгоды</h3> <p>Вы наверняка знаете поговорку: «Без риска нет вознаграждения». Выше мы обсудили риски, поэтому давайте теперь посмотрим, как получить выгоду от внедрения агентного ИИ.</p> <p>Accenture определила многоуровневый подход к ИИ-проектам:</p> <ul> <li> <strong>Уровень 1 — агентная автоматизация:</strong> это базовый уровень внедрения ИИ. Здесь Accenture говорит о точечных решениях или о том, что она называет «простой заменой человека». Это означает, что вы можете дополнить техническую поддержку чат-ботом, обученным по предметной области, или поручить агенту обработку определенных форм или входных данных.</li> <li><strong> Уровень 2 — минимальные ставки:</strong> это термин Accenture для переосмысления сквозных процессов, призванного раскрыть ценность. Идея заключается в том, что вы можете значительно сэкономить и увеличить общую производительность, но при этом не выделить свой бизнес среди конкурентов.</li> <li><strong> Уровень 3 — стратегические ставки:</strong> Accenture продвигает идею о том, что, если вы пойдёте на большой риск, вы можете получить большую прибыль, используя их <nobr>10-кратный</nobr> показатель. По сути, это переосмысление вашего бизнеса на основе возможностей ИИ.</li> </ul> <p>Практичен ли или достижим ли такой подход? Конечно. Возможно. Наверное, в большей степени, чем что-либо ещё.</p> <p>Вероятно эта модель так называемого «стратегического» анализа возможностей ИИ призвана скорее вызвать ажиотаж, чем добиться ощутимых результатов. Даже в Accenture заявили (и это прямая цитата): «Если программа компании по внедрению агентного ИИ не вдохновляет инвесторов, значит, амбиции недостаточно высоки».</p> <p><strong>1. Начните с реальности, а не с амбиций. </strong>Давайте немного притормозим, хорошо? Резкий старт с полной скоростью, скорее всего, приведет к заносу. Вместо этого проявите осторожность и осмотрительность. Вы все еще можете получить выгоду. Просто делайте это таким образом, чтобы повысить шансы на общий успех.</p> <p>Начните с анализа ваших текущих бизнес-процессов. Почти у всех компаний есть процессы, которые занимают слишком много времени, недостаточно оперативны, слишком дороги, постоянно ломаются или иным образом доставляют головную боль. Вам даже не нужно проводить углубленный анализ всей компании. Эти проблемные области очевидны уже давно.</p> <p><strong>2. Выберите правильные отправные точки. </strong>Будьте избирательны при выборе вариантов для внедрения агентного ИИ. Ищите внутренние процессы, которые затратны в эксплуатации, происходят часто и следуют достаточно предсказуемым закономерностям. Особенно перспективными кандидатами являются рабочие процессы, которые приводят к потере дохода, создают узкие места или зависят от повторяющихся ручных операций.</p> <p>Осторожно используйте агентные решения для замены ручного труда. Не стоит пугать сотрудников угрозой увольнения. Вместо этого нужно дать сотрудникам возможность вносить более значимый вклад, освободив их от утомительной рутинной работы. Начните с некритичных систем, где ошибки управляемы и не будут распространяться по всему бизнесу.</p> <p>Рассматривайте агентные решения как легкодоступные достижения. Некоторые проблемы можно исправить с помощью агентов, ориентированных на конкретные задачи. Другие можно смягчить, используя несколько агентов, работающих вместе в одной среде данных. Третьи же можно решить с помощью простых алгоритмических процессов, которые вообще не требуют ИИ.</p> <p>Избегайте областей, полных частных случаев, неоднозначности или постоянно меняющихся правил. Агентам гораздо сложнее надежно справляться с такими ситуациями, и они с большей вероятностью создадут проблемы, чем принесут пользу.</p> <p><strong>3. Установите ограничения. </strong>При переходе от тестирования к развертыванию в производственной среде установите ограничения. Обязательно продумайте и внедрите эти ограничения до масштабирования.</p> <p>Держите людей в курсе событий уже на ранних этапах, особенно в вопросах согласования и обработки исключений, чтобы агенты не работали без контроля. Это может оказаться сложнее, чем обещают ИИ-компании. Когда Claude Code внезапно начал распределять работу между агентами, обнаружилось, что они работали гораздо быстрее, чем их можно было отслеживать, часто застревали и создавали другие проблемы. Решением стало устранение одновременно работающих агентов, по крайней мере, до тех пор, пока не получилось лучше ими управлять.</p> <p>Постепенно увеличивайте автономность по мере того, как вы будете уверены в производительности. Не спешите сразу же включать полную агентную автоматизацию. Это может потребовать от вас сопротивления давлению инвесторов и других ключевых заинтересованных сторон, но стойте на своем. Вы же не захотите передать свою производственную линию импульсивному племяннику-неудачнику вашего крупнейшего инвестора. Аналогично, не следует передавать свой рабочий процесс агентам ИИ до тех пор, пока они не будут готовы к полноценному использованию.</p> <p>«Организациям необходимо адаптивное управление, которое развивается по мере развития ИИ. Хотя человеческий контроль по-прежнему важен сегодня, структуры управления должны предусматривать большую автономию ИИ и включать четкие, перспективные меры защиты, — считает Мудит Гарг, генеральный директор и соучредитель компании Qventus, занимающейся разработкой ПО для больниц на основе ИИ. — Многие системы здравоохранения, разработавшие структуры управления ИИ пару лет назад, уже вынуждены перестраивать их, чтобы соответствовать современным возможностям ИИ».</p> <p>Обязательно постоянно отслеживайте как поведение, так и затраты, потому что в случае с агентным ИИ небольшие проблемы могут быстро накапливаться, если их оставить без внимания. Из этого следует, что если вы не можете что-то отслеживать или еще не придумали, как это сделать, подождите, пока не сможете, прежде чем запускать агентный ИИ.</p> <p>«Компании объединяют агентов, используя различные модели, поставщиков и инструменты. Управление должно быть достаточно открытым и гибким, чтобы соответствовать этим требованиям. Но открытость без контроля — это просто бессистемность, — отмечает Таттай. — Агенты должны строиться на основе стандартов с жестким управлением, постоянной прозрачностью и мониторингом на протяжении всего жизненного цикла агента. Доверие — это непреложный принцип».</p> <p><strong>4. Масштабируйте то, что действительно работает.</strong> После того, как вы определили жизнеспособный сценарий использования, ограничьте первоначальный проект. Начните с одного рабочего процесса. Убедитесь, что вы можете продемонстрировать четкую, измеримую окупаемость инвестиций. Затем расширяйте проект на тесно связанные процессы, где шаблоны и данные схожи.</p> <p>Прежде чем пытаться масштабировать его в масштабах всей организации, подождите, пока не докажете, что можете надежно выполнять сразу несколько проектов.</p> <p><strong>5. Измерьте реальную отдачу. </strong>Как понять, что это работает? Во-первых, поговорите со своими сотрудниками. Они скажут вам, нравятся им новые системы или нет. После того, как вы получите оценку настроения сотрудников, посмотрите на другие показатели, которые могут измерить успех в четких, операционных терминах. Ищите снижение стоимости выполнения задач, сокращение времени цикла, уменьшение количества ошибок и измеримую выручку, полученную или возвращенную.</p> <p>«Самая большая проблема — доказать окупаемость инвестиций в масштабе. Во многих системах здравоохранения отсутствуют четкие показатели эффективности, и они сталкиваются с длительными сроками внедрения, усугубляемыми зависимостью от устаревших систем электронных медицинских карт», — отмечает Гарг.</p> <p>Помните, что если вы не можете связать процесс с ощутимым, измеримым результатом, вы не сможете доказать, что принесли пользу.</p> <p>«Успех требует определения измеримых результатов на раннем этапе и приоритетного внимания к небольшому числу высокоэффективных сценариев использования, перехода от 80%-ной к 95%-ной точности, а не распыления по 1000 поверхностных приложений», — говорит Гарг.</p> <p>И чего не следует делать.</p> <p>Также помните о следующих предостережениях. Не начинайте с попытки полной трансформации. Не развертывайте изменения сразу на нескольких системах. Не предполагайте, что то, что вам говорит поставщик, он действительно может сделать. Не позволяйте никому заставлять вас двигаться быстрее, чем ваша организация может эффективно это осуществить.</p> <h3>Путь к вознаграждению</h3> <p>В начале этой статьи вам был предложен выбор. Но на самом деле нет смысла выбирать между безопасным повышением эффективности на 10% и рискованной <nobr>10-кратной</nobr> трансформацией. Компании, которые добиваются успеха с помощью агентного ИИ, внедряют решения в тех контекстах, где они будут эффективны, иногда получая постепенную экономию затрат, а иногда добиваясь оглушительных результатов.</p> <p>Начните с целенаправленных улучшений. Если все пойдет хорошо, они просто окупятся. Изучите, что работает, что ломается и что масштабируется. Затем, со временем, распространите эти достижения на более широкие системы, которые изменят то, как работает ваш бизнес.</p> <p>Агентный ИИ — это мощный инструмент. Он может кардинально изменить траекторию развития бизнеса. Это может быть как к лучшему, так и к худшему. ИИ усиливает сильные стороны высокоэффективных организаций и дисфункции проблемных.</p> <p>Итак, что же делать?</p> <p>Действовать надо осторожно, чтобы не запустить в свою бизнес-модель неуправляемого зверя. Начните с пилотных проектов, развивайте их и постепенно масштабируйте со временем. По мере этого вы можете обнаружить возможности, которые позволят вам вывести свой бизнес на новый уровень или даже за его пределы.</p> Компании стремятся к многократному увеличению прибыли за счет искусственного интеллекта, но многие проекты быстро … article https://www.itweek.ru/themes/detail.php?ID=234787 Fri, 08 May 2026 09:52:54 +0300 <p>Более 80% ИИ-пилотов не переходят в промышленную эксплуатацию. Проекты зависают, бюджеты иссякают, команды расходятся. Провал редко связан с технологией — ломается все вокруг нее.</p> <p>В этой статье разберем критерии, по которым принимается решение о масштабировании ИИ-систем в сфере безопасности — видеоаналитики, систем контроля доступа, поведенческого анализа, детекции аномалий.</p> <p>Разберем, где именно срывается переход от первого пилота до промышленной системы, и как его избежать.</p> <h2>Пилотный проект: структура</h2> <p>Обычно пилот охватывает один объект и небольшое число камер и/или датчиков и, как правило, имеет фиксированные временные рамки, а также реализуется в режиме мониторинга: система может фиксировать события и выдавать оповещения оператору, но при этом она не встроена в общую систему безопасности.</p> <p>Расширенный пилот, охватывающий два-три разнотипных объекта, позволяет проверить, как модель ведет себя в разных условиях, в том числе проверяется интеграция с инфраструктурой заказчика. Именно здесь выявляются скрытые проблемы с совместимостью оборудования, которые невозможно обнаружить при тестировании одного объекта.</p> <p>Ограниченное внедрение — следующий шаг, при котором система охватывает уже большую часть целевого периметра по сравнению с расширенным пилотом и переводится из режима мониторинга в режим реагирования на оповещения. Этот этап важен для оценки организационной готовности, а бизнес может оценить первый эффект от автоматизации. Успешное прохождение ограниченного внедрения дает основания для принятия решения о развертывании системы на все предприятие.</p> <h2>Техническая готовность</h2> <p>Техническая готовность — фундамент масштабирования. Без оценки производительности, устойчивости и инфраструктурных ограничений переход к промышленной эксплуатации не приведет к желаемому результату.</p> <p>Ключевые параметры, которые необходимо проверить до перехода к масштабированию, включают четыре основных блока.</p> <p><strong>Точность на разнородных данных.</strong> Показатели FAR (False Acceptance Rate — коэффициент ложного принятия) и FRR (False Rejection Rate — коэффициент ложного отказа) нужно измерять на выборке, отражающей разнообразие условий.</p> <p><strong>Нагрузочное тестирование.</strong> Система, обрабатывающая 10 камер с задержкой 200 мс, может деградировать при 200 камерах. Тестировать нужно пиковую нагрузку.</p> <p><strong>Деградация модели.</strong> Нужно понять заранее, как быстро падает точность, есть ли процесс дообучения, сколько он стоит.</p> <p><strong>Инфраструктура.</strong> Масштабирование с 10 камер до 500 меняет архитектуру хранения, требования к сети и вычислительным мощностям. Облако не всегда применимо из-за требований к локализации данных.</p> <p>Техническая готовность — необходимое, но не достаточное условие. Система не работает без людей и процессов.</p> <h2>Организационная готовность</h2> <p>Любое внедрение обречено на провал, если персонал не знает, как работать с новой системой, а зоны ответственности не распределены. Организационная готовность — это способность компании встроить новый инструмент в рабочие процессы.</p> <p>Чтобы обеспечить такую готовность, требуется проработать три обязательные составляющие.</p> <p><strong>Регламенты реагирования </strong>должны включать информацию, кто получает алерт, в какие сроки ответственный сотрудник должен отреагировать, порядок действий при ложном срабатывании, кто принимает финальное решение.</p> <p><strong>Ответственность ИБ и ИТ.</strong> Матрица RACI (Responsible, Accountable, Consulted, Informed — распределение ролей: исполнитель, ответственный, консультант, информируемый) должна быть готова до запуска. Отсутствие четкого распределения зон ответственности может привести к тому, что инциденты окажутся на стыке зон ответственности ИТ и ИБ. Вследствие этого задачи, направленные на устранение этого инцидента, либо не будут исполняться вообще, либо будут исполняться с нарушением запланированных сроков.</p> <p><strong>Обучение операторов.</strong> Оператор обычной системы видеонаблюдения (CCTV) и оператор ИИ-системы — разные роли. Для сотрудников, ответственных за работу системы, следует провести обучение по функционалу внедряемого решения.</p> <p>Когда организационный каркас определен, нужно посчитать деньги и оценить риски.</p> <h2>Финансовые и риск-ориентированные критерии</h2> <p>Экономическая эффективность — ключевой аргумент при принятии решения о внедрении решения. Для этого нужна прозрачная финансовая модель и понятный подход к оценке рисков масштабирования системы.</p> <p>TCO (Total Cost of Ownership — совокупная стоимость владения).</p> <p>TCO = CapEx (Capital Expenditure — капитальные затраты: лицензии, железо, интеграция) + OpEx (Operational Expenditure — операционные расходы: поддержка, дообучение, персонал).</p> <p>ROI (Return on Investment — возврат инвестиций) может быть оценен с помощью расчета ущерба за определенный период, который понесла компания из-за предыдущих инцидентов.</p> <h3>Матрица рисков</h3> <table> <tbody> <tr> <td> <p><strong>Категория</strong></p> </td> <td> <p><strong>Примеры</strong></p> </td> <td> <p><strong>Градация</strong></p> </td> </tr> <tr> <td> <p>Технические</p> </td> <td> <p>Деградация модели, отказ инфраструктуры</p> </td> <td> <p>Средний-высокий</p> </td> </tr> <tr> <td> <p>Регуляторные</p> </td> <td> <p>Несоответствие законодательству</p> </td> <td> <p>Высокий</p> </td> </tr> <tr> <td> <p>Операционные</p> </td> <td> <p>Перегрузка операторов, игнорирование алертов</p> </td> <td> <p>Средний</p> </td> </tr> <tr> <td> <p>Репутационные</p> </td> <td> <p>Публичный инцидент с ложным обвинением</p> </td> <td> <p>Высокий</p> </td> </tr> </tbody> </table> <p>Риски с градацией «высокий» — стоп-факторы.</p> <p>Параллельно с финансовым анализом необходимо урегулировать вопросы соответствия законодательству.</p> <h3>Регуляторные критерии</h3> <p><strong>№</strong><strong> <nobr>152-ФЗ.</nobr></strong> Системы с распознаванием лиц обрабатывают персональные данные. Промышленная эксплуатация требует письменного согласия субъектов, отдельных политик обработки и хранения данных только на территории РФ.</p> <p>С 1 июня 2023 года вступили в силу основные положения Федерального закона №<strong> <nobr>572-ФЗ</nobr></strong>, регулирующего правила обработки биометрических данных в коммерческом секторе. Теперь использование биометрии (лица и голоса) допускается только через Единую биометрическую систему (ЕБС), а самостоятельный сбор таких данных бизнесом запрещен под угрозой административной и уголовной ответственности. При этом сохраняется возможность применения систем видеоаналитики и поведенческого анализа, не осуществляющих идентификацию конкретных лиц.</p> <p><strong>ФСТЭК и ФСБ.</strong> При интеграции с объектами КИИ ИИ-компоненты должны сертифицироваться, если они классифицируются как средства защиты информации (СЗИ) или функционируют в составе значимых объектов КИИ (ЗОКИИ).</p> <p>Когда все критерии собраны, их нужно свести в рабочий инструмент.</p> <h2>Методология принятия решения</h2> <p>Практическим инструментом для такой оценки может служить чек-лист готовности, охватывающий пять ключевых направлений.</p> <p>● <strong>Техническое:</strong> точность на разнородных данных подтверждена; нагрузочное тестирование пройдено; процесс дообучения описан; интеграции протестированы.</p> <p>● <strong>Организационное:</strong> регламенты утверждены; RACI согласована; операторы обучены.</p> <p>● <strong>Финансовое:</strong> проведены расчеты TCO и ROI; бюджет утвержден.</p> <p>● <strong>Регуляторное: </strong>правовая экспертиза пройдена, соответствие отраслевым нормам и обязательным требованиям подтверждено.</p> <p>● <strong>Риск-ориентированное:</strong> матрица рисков составлена; риски с градацией «высокий» закрыты.</p> <p><strong>Поэтапное масштабирование:</strong> пилот → расширенный пилот <nobr>(2-3 объекта)</nobr> → ограниченное внедрение <nobr>(20-30%</nobr> охвата) → полный охват.</p> <p><strong>Стоп-факторы:</strong> не закрыты регуляторные риски; точность не достигает установленных пороговых значений; операционные регламенты не утверждены; бюджет масштабирования.</p> <p>Даже при положительном решении о масштабировании результат во многом определяет выбор подрядчика.</p> <h2>Требования к подрядчику</h2> <p>При выборе подрядной организации (сервисной ИТ-компании/интегратора) для проекта следует проверить четыре признака:</p> <p>· наличие в портфолио схожих проектов сопоставимого масштаба;</p> <p>· прозрачность архитектуры;</p> <p>· SLA (Service Level Agreement — соглашение об уровне услуг);</p> <p>· опыт работы с регуляторами: ФСТЭК, ФСБ.</p> <p>Модели взаимодействия различаются по степени зависимости заказчика от разработчика. При полном аутсорсинге компания берет эксплуатацию на себя — это удобно, но создает зависимость от разработчика.</p> <p>Аутстаффинг предполагает, что разработчики работают внутри команды заказчика и постепенно передают экспертизу.</p> <p>Выделенная команда подходит для крупных долгосрочных проектов: фиксированный состав, понятные KPI, отдельный бюджет. При передаче компетенций ИТ-компания обучает внутреннюю команду и выходит из проекта.</p> <h2>Вывод</h2> <p>Масштабирование — самостоятельный проект со своим уставом, бюджетом и критериями успеха.</p> <p>Компания готова к промышленному ИИ, если внутри есть понимание ограничений технологии, процессы адаптированы, распределены зоны ответственности за систему, выделен и распланирован бюджет на разработку, внедрение и поддержку системы.</p> <p> #IMAGE_234788#</p> Более 80% ИИ-пилотов не переходят в промышленную эксплуатацию. Проекты зависают, бюджеты иссякают, команды … article Дмитрий Медведев, директор департамента прикладных решений ЛАНИТ-ТЕРКОМ (входит в группу компаний ЛАНИТ) https://www.itweek.ru/themes/detail.php?ID=234785 Thu, 07 May 2026 16:04:58 +0300 <p>Компания VolgaBlob обновила флагманскую платформу Smart Monitor, предназначенную для анализа бизнес-процессов, ИТ-мониторинга и построения SOC/SIEM. Среди ключевых изменений — модуль МАЯК с автоматическим поиском первопричин сбоев, а также интеграция искусственного интеллекта: AI-агентов для визуализаций, семантического ИИ-поиска и модуля AI Security, который мониторит ИИ, работающий в корпоративном контуре клиентов. За последний год производительность интерфейса системы выросла на <nobr>30–50%,</nobr> а скорость работы поискового движка — до 10 раз в отдельных сценариях.</p> <p>Прежде всего, в Smart Monitor 6.0 появился модуль МАЯК, предназначенный для мониторинга сразу на трех уровнях: инфраструктурном, сервисном и на уровне приложений. Модуль позволяет не только фиксировать инциденты, но и автоматически находить первопричины сбоев, выявлять аномалии и тренды деградации сервисов и сокращать время восстановления. МАЯК расширяет функциональность Smart Monitor до обеспечения полной осознанности, включая уровень observability.</p> <p>Это коррелирует с общим направлением развития платформы. Чтобы у администраторов было больше инструментов контроля, один из наиболее востребованных модулей платформы — Менеджер инцидентов — в одном из последних релизов получил новую карточку инцидента. Появились три структурированных блока с разделением метаданных и деталей события, возможность ручного связывания инцидентов друг с другом, настраиваемые через веб-интерфейс справочники ответственных и уровни критичности. Реализовано прикрепление файлов к инцидентам с хранением на файловых share или в S3.</p> <p>В модуле Менеджер Инцидентов также появилось разделение по типам и представлениям карточек: каждый инцидент может иметь свой тип с индивидуальным набором полей, собственным представлением и правилами доступа. Вывод результатов исполняемых скриптов теперь отображается прямо в интерфейсе — в виде истории и таймлайна. Это встроенная альтернатива внешним SOAR для типовых сценариев реагирования.</p> <p>В последних релизах Smart Monitor основной акцент сделан на производительность. Страницы интерфейса теперь открываются на <nobr>30–50%</nobr> быстрее при одновременном снижении объема загружаемых в браузер данных.</p> <p>Заметный прирост скорости обеспечило обновление хранилищ OpenSearch и ClickHouse: агрегации cardinality, histogram и stats теперь выполняются до 40% быстрее, а в некоторых случаях статистические функции ускоряются до 30 раз. Общая скорость запросов к хранилищам увеличилась на <nobr>11-14%.</nobr></p> <p>Развивается функциональность гибридного хранилища (Multi-Storage), механизм переливки данных между несколькими хранилищами OpenSearch и ClickHouse. Покрытие специфичных команд ClickHouse достигло 86% — это почти все реальные сценарии, за исключением редких. Пользователи теперь работают с ClickHouse так же, как с OpenSearch, не замечая разницы.</p> <p>Усовершенствовали в новом релизе и поисковой движок. Скорость обработки запросов в среднем увеличилась на 20%, причем в некоторых сценариях прирост производительности достигает <nobr>5-10 раз.</nobr> Так, команда transaction теперь отрабатывает до 10 раз быстрее. Кроме того, в движке появились три новые команды, функции времени для работы с часовыми поясами, фоновые запросы, возможность сравнивать поля и расширенный поиск. </p> <p>Наконец, поисковой механизм Smart Monitor расширили возможностями искусственного интеллекта. Появилась функциональность семантического поиска с помощью ИИ, а также AI-обработки (анализа поверх результатов). В рамках одного запроса теперь можно перейти от телеметрии или событий безопасности к сводке, причинам и рекомендуемым мерам защиты. </p> <p>В части визуализации обновлен дизайн, появилась поддержка иконок и строковых диапазонов. Добавился ряд новых визуализаций: Trace Timeline (путь запроса через микросервисы), Service Map (зависимости между сервисами, ресурсами и трассировками). Обновилась визуализация Single Value (ключевая метрика с трендом). Кроме того, значительно расширены возможности работы с дашбордами: сетка стала гибкой, а саму визуализацию теперь можно растянуть на несколько рядов. А благодаря ролевому контролю навигации можно настроить режим «чистого просмотра», когда аналитик видит только один нужный дашборд без лишних элементов интерфейса.</p> <p>SDK визуализаций полностью переработан с учетом обновлений платформы за год и актуального технологического стека. Более того, SDK теперь представляет собой независимый модуль от основной системы, что позволяет использовать его и разрабатывать визуализации без установки Smart Monitor.</p> <p>Прорывом Smart Monitor 6.0 стала поддержка AI-агентов для разработки визуализаций. VolgaBlob создала специальные файлы-скиллы — единый стандарт описания промптов и инструкций для агентов. Подключив внутреннюю или внешнюю модель, разработчик или аналитик может за несколько минут получить готовую нестандартную визуализацию без написания кода.</p> <p>Например, по промпту «Сделай diff-визуализацию, которая покажет разницу конфигураций» система генерирует готовую визуализацию, которую можно сразу использовать на дашборде. Это особенно полезно для нетиповых задач: сравнения конфигураций оборудования, файловых серверов и других.</p> <p>«За последний год в архитектуру платформы было внесено 461 изменение — улучшения, доработки и совершенно новая функциональность. Причем примерно 30% нашей дорожной карты сформировано при непосредственном участии клиентов и партнеров — тем самым удалось закрыть 84% текущих клиентских запросов. Мы прислушиваемся к рынку, и это помогает нам создавать по-настоящему востребованный и клиентоориентированный продукт, который решает реальные задачи бизнеса в условиях высокой сложности и динамики современных ИТ-ландшафтов», — отметил Максим Кириенко, коммерческий директор VolgaBlob.</p> Компания VolgaBlob обновила флагманскую платформу Smart Monitor, предназначенную для анализа бизнес-процессов, ИТ-мониторинга … message https://www.itweek.ru/themes/detail.php?ID=234784 Thu, 07 May 2026 16:02:38 +0300 <p>Российская компания «СофтМедиаЛаб» представила «КиберАгентРевью» — систему безопасности и контроля ИИ-агентов в реальном времени. Актуальность таких решений подтверждает Gartner, назвавший безопасность ИИ-агентов одним из ключевых трендов кибербезопасности 2026 года. Решение позволит компаниям выявлять отклонения в действиях агентов, предотвращать утечки и расследовать аномалии, обеспечивая безопасное внедрение ИИ в корпоративной среде.</p> <p>КиберАгентРевью (CyberAgentReview) — система безопасности и контроля ИИ-агентов в реальном времени. В основе — мониторинг и аудит действий агентов с учетом контекста их работы. Это позволяет обеспечивать безопасность ИИ в корпоративной среде: выявлять отклонения от поставленных целей, предотвращать утечки данных и расследовать аномалии в сценариях.</p> <p>Технически решение реализовано в виде локального прокси-сервиса на рабочих станциях и выступает единым шлюзом к большим языковым моделям (LLM), обеспечивая защиту LLM без изменения пользовательских инструментов. В централизованном дашборде можно полностью отследить: какой агент, какие данные и куда отправил. Также доступны функции автоматического обнаружения утечек, контроля аномалий и настройки оповещений.</p> <p>В планах развития — расширение механизмов поведенческого анализа и защиты ИИ-агентов. Система будет сопоставлять вызовы инструментов с исходной задачей и уточнениями пользователя, выявлять отклонения (в том числе вызванные промпт-инъекциями) и обеспечивать защиту от промпт-инъекций за счет автоматического прерывания выполнения операций, не допуская распространения вреда в случае сбоя. </p> <p>Актуальность таких решений подтверждают аналитики. В 2026 году Gartner назвал безопасность ИИ-агентов и контроль над ними одним из ключевых трендов кибербезопасности. При этом отмечается критическая проблема: традиционные системы управления доступом (IAM) оказались не готовы к появлению новых видов угроз от ИИ-агентов. </p> <p>Автономные системы не только генерируют текст, но и выполняют действия: обращаются к API, изменяют данные, запускают процессы. Они внедряются в бизнес быстрее, чем выстраиваются меры защиты.</p> <p>Особая угроза ИИ-агенты, которые одновременно имеют доступ к приватным данным, внешнему контенту и инструментам передачи информации. В таких сценариях злоумышленник может внедрить скрытые команды в документ или письмо, после чего агент самостоятельно соберет и отправит конфиденциальные данные.</p> <p>Максим Горшков, технический директор «СофтМедиаЛаб», отметил: «Традиционные средства безопасности не предотвращают атаки, при которых легитимный ИИ-агент начинает действовать с измененной целью. КиберАгентРевью позволяет компаниям выстраивать практику обеспечения безопасности ИИ, выявлять такие отклонения и снижать риски при использовании автономных систем, обеспечивая контроль их действий и соответствие регуляторным требованиям, включая защиту персональных данных и объектов критической информационной инфраструктуры».</p> Российская компания «СофтМедиаЛаб» представила «КиберАгентРевью» — систему безопасности и контроля ИИ-агентов … message https://www.itweek.ru/themes/detail.php?ID=234783 Thu, 07 May 2026 15:57:06 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал итоги 2025 года об инвестициях крупных и средних организаций в ИКТ, включая затраты на ИКТ-оборудование, ПО и базы данных. Рассмотрены данные по 18 крупным отраслям экономики.</p> <p>Объем инвестиций в ИКТ крупных и средних организаций в 2025 г. достиг 2,4 трлн руб., превысив уровень 2024 г. на 3,3%, а показатель 2021 г. — вдвое. Рост расходов «на цифру» зафиксирован в 12 из 18 отраслей экономики.</p> <p>Положительная динамика инвестиций в ИКТ стала следствием продолжающегося значительного роста объема вложений в ПО и базы данных (+24,8% к 2024 г.), который компенсировал сокращение объема инвестиций в ИКТ-оборудование (-13,7%).</p> <p>Рост вложений в ПО и базы данных в 2025 г. более чем вдвое опережал динамику инвестиций в основной капитал по экономике в целом (+9,7% к 2024 г.).</p> <p>На снижение расходов на ИКТ-оборудование повлияли два фактора. Первый — эффект высокой базы 2024 г., в основном из-за резкого увеличения вложений ИТ-компаний в вычислительные мощности в тот период. В 2025 г. их инвестиционная активность стабилизировалась. Второй фактор — удешевление импортного ИКТ-оборудования в связи со снижением курса доллара (-9% в среднем за 2025 г.).</p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал итоги 2025 года об инвестициях … message https://www.itweek.ru/themes/detail.php?ID=234777 Thu, 07 May 2026 00:00:00 +0300 <p><em>Облачные хранилища сегодня напоминают опечатанную квартиру, где забыли закрыть балкон. Разработчик закоммитил ключ в GitHub, системный администратор оставил тестовый бакет с открытым доступом, а бывший сотрудник все еще имеет права суперадминистратора — любой из этих сценариев может стать входными воротами для хакера. Причем злоумышленник теперь даже не взламывает, он просто заходит под легитимной учетной записью и спокойно копирует базы. Старые методы защиты — регламенты, рассылки и обучение — перестали работать, потому что люди остаются людьми и ошибаются. Решение — перейти к модели технической невозможности: спроектировать облачную инфраструктуру так, чтобы разработчик физически не мог оставить дыру. </em><em>Рассмотрим</em><em>, как построить защиту, которая работает даже тогда, когда кто-то ошибся<strong>.</strong></em></p> <h3>От красной кнопки до сетевой изоляции</h3> <p>Угроз в облаке хватает: внешний хакер, который ищет открытые бакеты или украденные ключи, недобросовестный инсайдер с избыточными правами, ошибка разработчика, случайно открывшего публичный доступ или закоммитившего ключ в GitHub, компрометация учетных данных через фишинг, и, конечно, программа-вымогатель, шифрующая данные с требованием выкупа.</p> <p>Чтобы безопасность стала свойством архитектуры, необходимо сделать шаг от модели «обучили и написали правила» к модели «технически не получится ошибиться». Иными словами: даже если разработчик захочет натворить дел, он физически не сможет этого сделать. Для объектных хранилищ (S3 и аналоги) существует четыре уровня защиты — их можно собрать в своего рода матрешку.</p> <p>Глобальный запрет на публичный доступ — это красная кнопка, которая блокирует любые настройки отдельных бакетов или списков доступа. Даже если разработчик прямо пропишет параметр public read, запрос отклоняется на уровне платформы, а не на уровне бакета.</p> <p>Второй уровень — политики организации, Service Control Policies. Они работают на всем облачном фундаменте, а их приоритет выше, чем права администратора проекта. Такие политики запрещают опасные API-вызовы, которые могут ослабить защиту, и перекрывают случайные или умышленные изменения настроек безопасности.</p> <p>Третий уровень — инъекция политик через инфраструктуру как код. Это страховка на случай, если глобальный запрет (первый уровень) по какой-то причине отключили или он не поддерживается. Инфраструктура разворачивается с помощью Terraform или CloudFormation, в CI/CD-пайплайн встраиваются инструменты анализа кода, например, Checkov. Проверка срабатывает автоматически. Если в описании бакета нет маркера enforcement public access block true, сборка не проходит. Два уровня дублируют друг друга специально: безопасность не должна зависеть от одной настройки. Многие провайдеры сегодня предлагают такие инструменты «из коробки».</p> <p>Четвертый уровень — сетевая изоляция, физическое ограничение видимости хранилища. Бакет настраивают так, чтобы он принимал запросы только через private link (внутренний интерфейс внутри сети компании). В итоге весь трафик из Интернета блокируется на сетевом уровне, и никакие права доступа уже не имеют значения.</p> <h3>Как не сойти с ума, внедряя минимальные права</h3> <p>В облаке с сотнями микросервисов и интеграций внедрить вручную принцип наименьших привилегий невозможно. Это прямой путь к массе ошибок и выгоранию сотрудников. Решение только одно: автоматизация на базе анализа использования. Берем инструмент, подключаем к логам облака (AWS CloudTrail, Azure Monitor и др.), он сравнивает выданные разрешения с реальными и сам генерирует политику, оставляя только то, что реально используется. Период анализа компания настраивает под себя: 30, 90 или 180 дней. Не «обучили принципу наименьших привилегий», а сделали так, что другие права технически невозможно выдать.</p> <p>Такие средства уже встроены в облачные сервисы. Например, AWS Access Analyzer (анализирует логи и предлагает готовые политики) или специализированные CIEM-решения вроде AI Metrics от Tenable, которые строят визуальный граф взаимодействий сервисов как карту скрытых связей.</p> <p>Дополнительный подход — «политика как код». В отличие от анализа логов, здесь опасные действия запрещаются на этапе разработки. Алгоритм внедрения выглядит так: сначала запускается сканер (Access Analyzer или аналог), чтобы увидеть реальный масштаб проблем. Затем проводится группировка. Настраивать каждый микросервис отдельно при их огромном количестве нецелесообразно, поэтому создают шаблоны ролей для типичных задач, например, только для чтения. Далее следует автоматическое урезание прав: рекомендации сначала применяют к стейджингу и, если за неделю ничего не сломалось, переносят на продакшн. Последнее, устанавливают жесткие политики, запрещающие опасные действия на уровне всего облачного аккаунта.</p> <h3>Где хранить ключи, чтобы их не украли</h3> <p>Если злоумышленник украл ключи, шифрование бесполезно. Это все равно что поставить бронированную дверь и ключ положить под коврик. Ключи должны всегда храниться отдельно от данных. Для этого существуют аппаратные модули безопасности, Hardware Security Modules, то есть физические устройства типа флешек или токенов. Ключ в таком модуле генерируется и хранится внутри устройства, все операции происходят там же. По каналам передачи ключ не гуляет, так он защищен от перехвата.</p> <p>Параллельно подключаются сервисы управления ключами (Key Management Services) — облачные или локальные. Например, у AWS есть AWS KMS. Доступ к ключам в таких системах регулируется политиками и обязательно логируется. Также есть технология TPM, Trusted Platform Module, — чип на материнской плате сервера, который привязывает возможность расшифровки к конкретному железу и состоянию системы. И классический подход: смарт-карты и USB-токены у суперадминистратора, которые подключаются только на момент авторизации.</p> <h3>Как на самом деле работают бэкапы в облаке</h3> <p>Самое распространенное заблуждение о бэкапах, что облако само по себе уже резервная копия или что провайдер отвечает за сохранность данных. Спойлер: это не так.</p> <p>Многие путают архив с резервным копированием. Архивное хранение для комплаенса предназначено для долгого сохранения данных. При этом задача бэкапа заключается в быстром восстановлении за минуты или часы, тогда как архивные хранилища обычно оптимизированы под низкую стоимость, а не под скорость доступа. В экстренной ситуации ждать восстановления из архива целые сутки слишком дорого.</p> <p>Еще одно распространенное заблуждение связано с моделью коллективной ответственности. Провайдер отвечает за доступность предоставленных мощностей, включая хранение, процессор, память и питание серверов. За защиту от угроз и за сохранность самих файлов отвечает только клиент. Это можно сравнить с арендой квартиры: стены и крыша принадлежат собственнику, а за сохранность вещей отвечает тот, кто пользуется помещением.</p> <p>Синхронизацию данных тоже нельзя считать бэкапом. Если вирус-шифровальщик зашифрует файлы на компьютере, облачный клиент синхронизирует и эти изменения. В результате здоровые файлы будут заменены зашифрованными, и восстанавливать окажется нечего.</p> <p>Надежный метод защиты резервных копий от удаления или шифрования, даже если злоумышленник получил доступ к инфраструктуре, — неизменяемость. На практике это работает через политику Object Lock. Она запрещает удаление или изменение файлов на заданный период (30, 60, 90 дней). Изменить или удалить такие файлы не сможет даже суперадминистратор.</p> <p>Обязательно разделение учетных данных: для бэкапа использовать выделенный отдельный облачный аккаунт, никак не связанный с другими, контролируемый и логируемый. Также необходимо применять принцип минимальных привилегий. Хорошая практика: настроить многофакторную аутентификацию на операцию удаления, чтобы любое действие с бэкапными бакетами подтверждалось через МФА.</p> <p>И классический стандарт резервного копирования: правило «3-2-1»: три копии данных, два разных типа носителей, одна копия на удаленной площадке (офсайт), не связанной с основной инфраструктурой.</p> <h3>Цифры, которые проверяем каждую неделю</h3> <p>Чтобы директор видел реальную картину состояния безопасности в облаке, достаточно трех ключевых показателей, которые можно проверять еженедельно.</p> <p>Первый контроль — доля привилегированных аккаунтов без многофакторной аутентификации. Речь про административные или сервисные учетные записи с высокими правами, у которых не включена МФА. Если есть хотя бы один такой аккаунт, человеческий или сервисный, с избыточными правами и без МФА, — это практически открытая дверь для злоумышленника.</p> <p>Также важно оценить количество сервисов и ресурсов с публичным доступом. Сюда входят хранилища и репозитории с данными, открытые порты баз данных, снимки состояния RDS, публичные API-ключи. В идеале количество таких ресурсов стремится к нулю.</p> <p>Самый красноречивый сигнал — аномальные объемы передачи данных. Злоумышленники всегда стараются выгрузить много информации и за короткое время. Поэтому необходимо отслеживать всплески исходящего трафика за пределы инфраструктуры. Особое внимание на необычное время, например, 3 или 4 часа утра, и на нехарактерные географические направления. Если данные никогда не отправлялись в Японию, а последней ночью туда ушел огромный объем, это повод насторожиться. А если за три-четыре дня из какого-то защищенного сегмента ушло на 60% больше данных, чем обычно, — это сигнал, что кражу ведут успешно.</p> <h3>Если утечка уже случилась</h3> <p>При подтвержденной или даже подозреваемой утечке первая задача не анализ и не поиск виноватых, а локализация. Сначала останавливают кровотечение, потом разбираются в причинах.</p> <p>Стандартное действие — смена ключей. Это закрывает доступ злоумышленникам. Следующий шаг: закрыть любой доступ, заблокировать все публичные активы. Параллельно необходимо проверить, было ли включено логирование до инцидента. Часто бывает, что оно не включено, и это большой пробел — восстановить хронологию атаки будет сложно, но нужно зафиксировать этот факт для отчета. Чтобы следующая атака не застала врасплох, запустить логирование важно немедленно.</p> <p>При этом нельзя останавливать бизнес. Ограничения должны быть точечными. Можно ввести фильтр по IP-адресам: оставить доступ только из доверенного списка (своя инфраструктура или офис). Для внешних пользователей (если сервис b2c) такой способ не подойдет, тогда выборочно отключают подозрительные функции или переводят в режим read-only. Если есть подозрение, что данные меняют или подменяют (например, при атаке вымогателя), необходимо перевести бакет в read-only. Тогда приложения и сотрудники могут читать данные и работать с ними, а злоумышленники или вредоносный код нет.</p> <p>Важна и командная работа. Следует открыть канал коммуникации в режиме тишины: выделенный чат для ИТ-отдела, чтобы обсуждать меры в продуктивном ключе, а не слухи. И обязательно уведомить руководителя компании: если информация утечет наружу, он должен заранее продумать ответы.</p> <p>Когда пожар потушен, наступает этап постмортема и работы с регуляторами. Начинается анализ. ИТ-директор должен обеспечить сбор всех логов и дампов за период предполагаемой компрометации в изолированное хранилище, сформировать хронологию: когда и через что вошли, какие данные затронуты. Дальше, юридические уведомления: если утекли персональные данные, нужно уведомить Роскомнадзор в течение 24 часов согласно <nobr>152-ФЗ.</nobr></p> <p>Также необходимо провести внутреннее расследование не для наказания, а чтобы убрать корневую причину. Часто это не злой умысел, а отсутствие автоматизации. И внедрить корректирующие меры: те защитные механизмы, которые ранее пропустили.</p> <h3>Заключение. Когда безопасность становится свойством архитектуры</h3> <p>Безопасность облачных данных перестает быть историей про регламенты и рассылки с напоминаниями. Она становится свойством архитектуры — технической невозможностью сделать небезопасно. Глобальные запреты, автоматическое урезание прав, шифрование с отдельным хранением ключей и неизменяемые бэкапы работают там, где любые инструкции и обучения дают сбой. А три простых KPI — МФА на всех привилегированных аккаунтах, ноль публичных ресурсов и контроль аномальных исходящих трафиков — позволяют держать руку на пульсе без погружения в операционную рутину. Потому что данные теперь стоят дороже, чем работоспособность систем. И значит, защищать их нужно соответственно.</p> <p>#IMAGE_234778#</p> Облачные хранилища сегодня напоминают опечатанную квартиру, где забыли закрыть балкон. Разработчик закоммитил ключ в GitHub … article Антон Грецкий, директор по информационной безопасности ActiveCloud https://www.itweek.ru/themes/detail.php?ID=234774 Thu, 07 May 2026 00:00:00 +0300 <p><em>Я больше не верю в организации, которые внедряют ИИ для ускорения разработки ПО, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Стив Фентон, специалист по работе с сообществом Octopus Deploy.</em></p> <p>В юности у меня был метис лабрадора и уиппета по кличке Баркли. Мы делали почти всё вместе. Если я копал яму в саду, он тут же начинал её обнюхивать. Если я читал книгу, он ложился мне на колени, пока у меня не начинало неметь всё тело. Когда мы с семьёй гуляли в лесу, он разведывал местность и мчался обратно, чтобы проверить нас, в возбуждении пробегая в десять раз большее расстояние, чем мы проходили.</p> <p>Одно из лучших качеств собак — это то, что с ними можно поговорить, когда тяжело. Они отличные слушатели и понимают вас, когда никто другой не понимает.</p> <p>Если бы я завёл ещё одну собаку, главной причиной была бы ее роль компаньона. Есть много других причин завести собаку, но для меня это главная.</p> <p>Теперь представьте, что я пришел в приют для животных и попросил показать мне их собак, а они захотели, чтобы я забрал домой гепарда, потому что он намного быстрее собаки. Вот что я слышу, когда организация заявляет о внедрении ИИ с близоруким упором на скорость.</p> <h3>Скорость — не цель и никогда ею не была</h3> <p>Мы уже проходили это. Нам всем следует сожалеть о том, что от движения Agile осталась лишь сухая шелуха, предлагающая только «скорость». Скорость никогда не была целью. Главная причина повышения производительности — получение обратной связи как можно раньше.</p> <p>Когда вы обнаруживаете, что ваша потрясающая новая функция не вызывает восторга у пользователей, вы можете сразу же прекратить работу над ней. Вы потратите гораздо меньше ресурсов, если сможете остановить плохую идею на ранней стадии и сразу же перейти к лучшей идее. Никому не стоит пытаться создавать ПО с наибольшим количеством функций и самой быстрой скоростью изменений. Когда у вас слишком много функций, и все постоянно меняется, чтобы соответствовать постоянно расширяющемуся списку того, что делает ваше ПО, люди начинают ненавидеть то, что вы создали.</p> <p>Microsoft Word — самый мощный и многофункциональный текстовый редактор на сегодняшний день, но им уже мало кто пользуется. Вместо него используют Google Docs, у которого гораздо меньше функций. Это означает, что выбранные Google функции оказались более привлекательными или же меньшее количество функций делает ПО проще в использовании. В действительности, все определяет сочетание множества мелких факторов, подобных этим. Иногда одна действительно привлекательная функция затмевает все остальные, и простота совместной работы над документом Google Docs в веб-браузере, возможно, была именно такой.</p> <p>Если бы вы спросили кого-нибудь двадцать лет назад, вам бы сказали, что Microsoft Word является неоспоримым лидером в своей категории, но сейчас, по данным 6sense, его доля на рынке составляет 3,9%, по сравнению с 9,6% у Google Docs. Если вы считаете, что этот сдвиг на рынке — исключительно вопрос ценообразования, вы, вероятно, работаете в организации, которая стремится только к высокой скорости, потому что вы уже перестали верить в идею создания ПО, которое ценят пользователи.</p> <h3>Внедрение ИИ для ускорения не внушает доверия</h3> <p>У лидеров в сфере разработки ПО накоплен немалый опыт, и это следует учитывать, когда они заявляют о внедрении ИИ для ускорения работы. Очень часто за последние десять-двадцать лет они объявляли о трансформации в сторону Agile для ускорения работы, внедряли DevOps для ускорения работы и запускали инициативы по созданию платформ для ускорения работы.</p> <p>Тот факт, что они исчерпали все эти инициативы, не добившись значительных результатов, является убедительным свидетельством того, что скорость им не так уж и нужна, как они утверждают. Конечно, они хотят добавить в свою послужную запись титул «DORA Elite Performance». Тем не менее, у них нет реальной причины работать быстрее, потому что они не заинтересованы в таком фундаментальном результате более частых поставок, как обратная связь.</p> <p>Любой руководитель, который столько раз подвергал свои команды испытаниям во имя скорости и теперь заявляет, что ИИ наконец-то принесет ее, заблуждается.</p> <h3>Метроном обратной связи</h3> <p>Когда обратная связь важна для вас больше, чем скорость, вы позволяете циклу обратной связи задавать темп всего процесса разработки ПО. Настройка этого темпа дает вам необходимое пространство для обработки обратной связи и выполнения того, чего требует от вас Agile, — быстрого изменения направления.</p> <p>Организации и команды, которые используют обратную связь в качестве метронома, задающего ритм всему оркестру, скорее всего, будут искать и устранять работу, нарушающую ритм. Они создают команды для выполнения работы с минимальными (и хорошо продуманными) зависимостями. Они упрощают процедуру утверждения изменений. Они следят за тем, чтобы команды могли решать, когда нажать на кнопку для развертывания их ПО, и чтобы они могли наблюдать за тем, что происходит, когда они это делают.</p> <p>Модель DORA с ее генеративной культурой, трансформационным лидерством, бережливым управлением продуктом и процессом непрерывной доставки не была создана случайно. Это результат десятилетий работы. Команды, применяющие эти концепции, обладают скоростью, но не поэтому они принимают эту культуру и практики. Им нужна частая высококачественная обратная связь, чтобы они могли обнаруживать, что действительно нужно создавать.</p> <h3>Практический пример</h3> <p>В одной крупной медицинской компании была сильная команда разработчиков ПО. Организация предоставляла ПО для управления пациентами и экстренной сортировки. В критически важных с точки зрения безопасности отраслях результат работы этого ПО действительно мог означать жизнь или смерть.</p> <p>Они выпускали свою систему управления пациентами раз в шесть месяцев, а цикл тестирования их системы поддержки принятия решений составлял две недели, плюс еще две недели, если обнаруживалась проблема. И так до тех пор, пока версия не проходила проверку!</p> <p>Несмотря на эту историю, в этой компании удалось в течение шести месяцев развернуть программу работы, которая создавала развертываемую версию ПО каждые три часа. Развертывание следовало набору очень строгих технических практик, но то, что было удалено, вероятно, было важнее того, что было добавлено. При этом удалось достичь баланса, реализовав подход к определению требований к ПО, при котором требования формулируются через конкретные примеры, а затем преобразуются в исполняемые спецификации и автоматизированные тесты, и устранив бюрократические этапы проверки, которые были медленными и малоэффективными.</p> <p>Если ваша организация не пересмотрит путь к внедрению в производство и не внесет аналогичные изменения, ничто не обеспечит желаемой скорости. Вы внедрите ИИ, как и Scrum, DevOps и Platform Engineering, и это не принесет никаких результатов, как и прежде.</p> <p>Самое важное, что вы можете сделать прямо сейчас, — это составить карту потока создания ценности, особенно от фиксации кода до развертывания в производственной среде, и начать исправлять неисправные части. Нет никакого секрета в том, что нужно изменить. Дейв Фарли и Джез Хамбл раскрыли его в своей книге «Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation».</p> <h3>Зачем вы внедряете ИИ?</h3> <p>Возможно, вы думаете, что внедряете ИИ, чтобы ускорить процесс. Если вы всерьез занимаетесь разработкой ПО, я надеюсь, вы скорректируете свой ответ и дадите понять окружающим, что частая обратная связь и гибкость принятия решений занимают важное место в вашем списке приоритетов.</p> <p>Команды, которые уже решили проблему компромисса между производительностью и стабильностью с помощью таких практик, как непрерывная доставка, будут меньше тяготеть к скорости. Они с большей вероятностью будут искать более ценные возможности. В заключение я хотел бы предложить пару таких моментов.</p> <p>Небольшие команды лучше. Мы идем на компромисс в этом вопросе, потому что нам нужно все быстрее, чем может справиться очень маленькая команда. Мы можем удвоить размер команды, даже зная, что это не сократит время вдвое. В модели COCOMO (COnstructive COst MOdel) есть сложный расчет этого убывающего эффекта, хотя Фред Брукс выразил это более запоминающимся образом: добавление людей в опаздывающий проект отдаляет срок его завершения.</p> <p>В результате большинство команд разработчиков ПО, которые понимают сложность коммуникации и координации, попадают в диапазон <nobr>6-12 человек.</nobr> Вспомните знаменитую команду «двух пицц». Но это не идеальный размер команды; он слишком велик. Это просто прагматичный способ сбалансировать несколько факторов. В случае с ИИ нам следует рассматривать команды, которые довольствуются одной пиццей, и даже пиццей поменьше.</p> <p>Небольшие команды с высокой степенью автономии, работающие над слабо связанным компонентом, могут стать мощным инструментом для раскрытия ценности разработки ПО с помощью ИИ.</p> <p>Мое последнее заключение состоит в том, что вместо того, чтобы создавать то же самое ПО быстрее, ИИ может позволить вашим командам создавать более амбициозные программы. Вы могли бы заняться той работой по глобализации, которую всегда не решались начать. У вас может быть идея функции, которую всегда было невозможно достаточно четко определить, и прототип ИИ позволит провести исследование, которое вы не могли предпринять раньше.</p> <p>В любом случае, начните с более агрессивного улучшения процесса разработки ПО и конвейеров развертывания. Убедитесь, что вы подключили обратную связь и используете ее как метроном для установки ритма. После того, как вы это сделаете, вы будете стремиться к чему-то более креативному, чем «скорость» благодаря внедрения ИИ.</p> Я больше не верю в организации, которые внедряют ИИ для ускорения разработки ПО, пишет на портале … article https://www.itweek.ru/themes/detail.php?ID=234782 Wed, 06 May 2026 18:01:26 +0300 <p>Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал итоги деятельности организаций сектора ИКТ и его сегментов — ИТ-отрасли, телекоммуникаций, производства ИКТ-оборудования, оптовой торговли ИКТ-товарами — за 2025 г.</p> <p>Объем реализации товаров, работ, услуг сектора ИКТ составил 9,4 трлн руб. (+12,6% к 2024 г.). Темпы прироста показателя в семь раз превысили значение поэкономике в целом (+1,8%). Доля сектора ИКТ в объеме реализации товаров, работ, услуг крупных и средних организаций всех видов экономической деятельности в 2025 г. достигла 5,4% (против 4,9% в 2024 г.).</p> <p>Положительная годовая динамика показателя зафиксирована во всех сегментах, в частности в таких крупных, как ИТ-отрасль (+14% к 2024 г.) и производство ИКТ-оборудования (+12,8%). Более низкий темп традиционно характерен для телекоммуникаций (+8,1%).</p> <p>Среднесписочная численность работников сектора ИКТ в 2025 г. выросла на 102,1 тыс. человек к уровню 2024 г. (+6,5%) и составила 1,7 млн человек. Основной вклад в это внесла ИТ-отрасль, в которой заняты каждые два из трех работников сектора. Вместе с тем во втором полугодии появились признаки охлаждения на рынке труда в секторе ИКТ.</p> <p>Объем инвестиций в основной капитал в секторе ИКТ в 2025 г. составил 1,6 трлн руб., сохранившись практически на уровне 2024 г. (-0,8%). Такую динамику показателя во многом определил высокий результат 2024 г., в <nobr>1,5–2,3</nobr> раза превысивший годовые объемы вложений в <nobr>2021–2023 гг.</nobr></p> Институт статистических исследований и экономики знаний (ИСИЭЗ) НИУ ВШЭ проанализировал итоги деятельности организаций … message https://www.itweek.ru/themes/detail.php?ID=234781 Wed, 06 May 2026 17:58:08 +0300 <p>Облачный провайдер Linx Cloud совместно с сообществом ИТ-лидеров Global CIO провели исследование отказоустойчивости крупного и среднего российского бизнеса. Цель исследования — понять текущую зрелость инфраструктуры, реальную степень отказоустойчивости и используемые технологии и подходы в крупном и среднем бизнесе в России.</p> <p>Специалисты Linx Cloud и Global CIO провели опрос более 100 ИТ-руководителей из 27 городов России и стран СНГ, представляющих 15 отраслей. Его результаты показали, что при высокой осведомленности о рисках и почти повсеместном наличии базовых практик резервного копирования, стратегическая глубина и регулярная проверка планов восстановления остаются слабыми местами компаний.</p> <p>Согласно исследованию, формализованная стратегия Disaster Recovery (DR), которая регулярно тестируется (как правило, раз или два в год), есть лишь у 20% респондентов. Еще 38% имеют базовые документы, но не проверяют их на практике, что означает невозможность гарантировать работоспособность плана «Б» в критический момент, а 42% компаний не имеют плана DR вовсе, что создает экзистенциальные риски для бизнеса в случае масштабной аварии. </p> <p>Многие компании защищены от случайного удаления файлов или локальных сбоев, но остаются уязвимыми перед масштабными авариями (например, выходом из строя всей основной ИТ-инфраструктуры). Существенный разрыв наблюдается и в соблюдении базовых принципов защиты данных: строго следовать правилу резервного копирования «3-2-1» (три копии данных на двух разных носителях, одна из которых за пределами основной площадки) готовы только 17%, хотя осведомлены о нём 88% опрошенных.</p> <p>Критическим недостатком является отсутствие регулярных проверок. 41% организаций никогда не тестировали планы восстановления на практике, а 31% компаний делает это раз в год. Это означает предсказуемо низкую эффективность DR-процедур в реальной аварии. Уязвимость усугубляется неоптимальным выбором решений и ошибками в организации процесса резервного копирования. К примеру, неизменяемое хранение (immutable/WORM), критичное для защиты от атак шифровальщиков, используют менее половины компаний (39%), а почти треть респондентов (29%) хранят резервные копии на основной площадке, концентрируя риск потери данных в одном здании. </p> <p>При этом 85% компаний уже сталкивались с необходимостью восстановления из бэкапов, но успешным и быстрым восстановление было только в 65% случаев — в 35% ситуаций фиксировались длительные простои, потеря данных или полный провал.</p> <p>Наблюдается противоречие между заявленными целями и реальными инвестициями в отказоустойчивость. Бизнес заявляет, что ценит минимизацию потерь данных (RPO, так ответили 84%) и простоев (RTO, 79% ответов), однако ключевым фактором выбора решений для резервного копирования становится стоимость (69% ответов). Многие компании экономят на тестировании и современных архитектурах, предпочитая нести скрытые риски дорогостоящих простоев вместо регулярных затрат на надежную защиту. </p> <p>Облако как площадка для DR применяется пока редко (8%), а 40% компаний даже не рассматривают этот вариант из-за политики ИБ (46%) и наличия собственной геораспределенной инфраструктуры (47%). Тем не менее, тренд на гибридизацию набирает силу: 29% респондентов планируют наряду с on-premise использовать облако с целью резервирования и DR в ближайшие <nobr>1–2 года.</nobr> При этом облако рассматривается в первую очередь как инструмент снижения совокупной стоимости владения ИТ-инфраструктурой (TCO).</p> <p>«Результаты исследования показывают разрыв между осознанием важности отказоустойчивости и реальными действиями бизнеса. Компании готовы платить за „железо“, но не за тестирование и современные подходы, такие как immutable-бэкапы или облачная DR-площадка. Между тем, именно эти „невидимые“ инвестиции напрямую определяют, переживет ли бизнес атаку шифровальщика или пожар в ЦОДе. Мы видим запрос на гибридные модели, где облако становится экономически эффективной резервной площадкой, и готовы предлагать решения, которые закрывают этот пробел без многократного увеличения бюджета», — отметил Евгений Макарьин, руководитель продуктового направления DR Linx Cloud.</p> <p>«Исследование показало, что знание современных принципов защиты данных, к сожалению, не равно готовности к инциденту. Большинство компаний находится в зоне иллюзорной безопасности, делая бэкапы ежедневно. Ввиду этого мы видим нашу задачу как ИТ-сообщества в тиражировании успешных практик и содействии ИТ-директорам в аргументированном донесении до руководства реальных рисков, связанных с недофинансированием и отсутствием проверок планов восстановления», — заявила Екатерина Ляско, генеральный директор Global CIO.</p> Облачный провайдер Linx Cloud совместно с сообществом ИТ-лидеров Global CIO провели исследование отказоустойчивости крупного … message https://www.itweek.ru/themes/detail.php?ID=234780 Wed, 06 May 2026 17:56:53 +0300 <p>Технологическая компания «Рексофт» вывела на рынок Reksoft DAM 2.0 — новое поколение собственной платформы управления цифровым контентом. Продукт, созданный на основе практического опыта enterprise-внедрений, интеграций и реальных сценариев управления контентом, стал более гибкой версией Reksoft DAM. Он проще в запуске и сопровождении, быстрее адаптируется под процессы заказчика и требует меньше затрат на внедрение и развитие.</p> <p>DAM-системы (Digital Asset Management) решают задачу централизованного хранения и управления медиаконтентом — изображениями, видео, документами. Продукт нужен, когда рост объемов контента и каналов коммуникации делает ручную обработку и поиск неэффективными. Первая версия Reksoft DAM создавалась как мощная enterprise-платформа для крупных и сложных контуров. Так, внедренная в рамках проекта с торговой сетью METRO, она позволяет управлять более 500 тыс. изображений товаров от поставщиков. Reksoft DAM 2.0 делает этот класс решений ближе к более широкому кругу компаний. </p> <p>Reksoft DAM 2.0 обогащает загруженные файлы метаданными в соответствии с заданными категориями. Таким образом они превращаются в управляемые цифровые активы, которые легко находить, фильтровать и использовать в работе — как специалистам по контенту, дизайнерам и маркетологам, так и юристам для проверки материалов перед публикацией. Ключевые отличия новой платформы — быстрое развертывание, преднастроенность под типовые сценарии и высокая адаптивность к процессам заказчика. Благодаря современному стеку — .NET 10, Blazor, PostgreSQL и Minio — и адаптивной архитектуре продукт легко кастомизируется под задачи компании. Система позволяет настраивать статусы работы с единицей контента, процессы его движения (workflow) и права доступа через пользовательский интерфейс без участия разработчиков, что снижает совокупную стоимость владения. </p> <p>Платформа поставляется в нескольких вариантах: от установщика с инструкцией для быстрого старта до полноценного внедрения с командой Рексофт с адаптацией, интеграцией и сопровождением. Возможна также поставка с NuGet-пакетами для самостоятельной доработки модулей заказчиком.</p> <p>Роман Соколов, директор департамента «Оптовая и розничная торговля», «Рексофт», отметил: «Reksoft DAM 2.0 вырос из реального опыта развития нашей первой платформы и практических задач заказчиков. Мы отталкивались от потребностей: рынку нужен не просто еще один DAM, а более легкий, быстрый и прагматичный продукт — современный технологический, удобный для внедрения и при этом достаточно гибкий, чтобы учитывать специфику конкретного бизнеса. В дальнейших планах — расширение набора отраслевых сценариев, развитие интеграционных возможностей и наращивание функциональности управления товарной информацией (PIM), чтобы покрывать больше задач заказчиков».</p> Технологическая компания «Рексофт» вывела на рынок Reksoft DAM 2.0 — новое поколение собственной платформы управления … message https://www.itweek.ru/themes/detail.php?ID=234779 Wed, 06 May 2026 17:47:32 +0300 <p>Компания «Технологии Доверия» (ТеДо), ранее известная как российская практика PwC, в недавнем исследовании «Созвездие ЦР» провела комплексный анализ российского рынка технологических решений для подключения к Платформе цифрового рубля.</p> <p>В первой части речь идет о ключевых трендах и вызовах цифрового рубля, его месте в национальной платёжной инфраструктуре, целевой архитектуре, регуляторных требованиях Банка России и ключевых пользовательских сценариях. Эксперты ТеДо подчёркивают, что цифровой рубль формирует новую модель взаимодействия государства, банков и бизнеса.</p> <p>Во второй части детально рассматриваются вендоры по трем периметрам подключения: ДБО, криптография, адаптеры. В исследовании решения сгруппированы по этим направлениям: к периметру ДБО отнесены BSS, iSimpleLab и Abanking; в сегмент удостоверяющих центров включена SDK Systems; периметр интеграционных адаптеров представлен решениями Diasoft, «Информационные системы» и R-Style SoftLab.</p> <p>Особое место в исследовании занимает компания BSS. Согласно данным ТеДо, решение BSS для работы с цифровым рублём уже внедрено в 17 финансовых организациях, что делает компанию безусловным лидером рынка: показатель почти в 2,5 раза превышает результаты ближайшего конкурента в сегменте ДБО.</p> <p>«Коробочный» модуль BSS построен на флагманской платформе Digital2Go и интегрируется в существующие системы дистанционного обслуживания. Полностью соответствует требованиям Банка России, поддерживает все необходимые сценарии, является готовой интеграционной моделью, быстро масштабируется и легко тиражируется в банках разного размера без потери управляемости.</p> <p>Для физических лиц решение обеспечивает открытие счёта цифрового рубля, обмен безналичных средств на цифровые и обратно, управление сертификатами, историю операций и автопереводы. Для юридических лиц — регистрацию на Платформе, пополнение и вывод средств, оплату по QR-коду, работу со смарт-контрактами и интеграцию с учётными системами.</p> <p>«Опыт компании BSS показывает, что успех внедрения зависит не только от технологической готовности, но и от способности выстроить гибкую, масштабируемую архитектуру, которая позволит банку быстро адаптироваться к новым регуляторным требованиям и пользовательским сценариям», — прокомментировал Станислав Шилов, директор по развитию продуктов Центра цифровых решений для бизнеса компании BSS.</p> <p>По его словам, ключевой вызов для банков сегодня — не просто выполнить формальные требования регулятора, а превратить цифровой рубль в источник конкурентного преимущества: создать на его базе инновационные продукты, улучшить клиентский опыт и укрепить позиции в борьбе за новых клиентов.</p> <p>В условиях, когда массовое внедрение цифрового рубля запланировано на сентябрь 2026 года, наличие готового, протестированного и масштабируемого решения становится критическим фактором для банков, стремящихся минимизировать риски и издержки перехода на новую платёжную инфраструктуру.</p> Компания «Технологии Доверия» (ТеДо), ранее известная как российская практика PwC, в недавнем исследовании … message https://www.itweek.ru/themes/detail.php?ID=234773 Wed, 06 May 2026 09:28:04 +0300 <p><em>Джейсон Блумберг, основатель и управляющий директор аналитической компании Intellyx, специализирующейся на цифровой трансформации, рассказывает на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том как Open Mainframe Project (OMP) и Zowe превращают мэйнфреймы в двигатели инноваций для искусственного интеллекта, облачных вычислений и модернизации предприятий.</em></p> <p>По мере того, как старое поколение специалистов по мэйнфреймам уступает место молодому поколению профессионалов, эта новая группа привносит современные способы мышления, которые неизбежно приводят к культурным изменениям и инициативам по модернизации мэйнфреймов.</p> <p>И это как нельзя кстати. Модернизация мэйнфреймов, в конце концов, это не «желательное дополнение». Она необходима для конкурентоспособности любого предприятия, зависящего от этой платформы.</p> <p>По мере того, как цифровая трансформация уступает место ИИ-революции, сегодняшние бизнес-императивы, основанные на технологиях, требуют от всех частей ИТ-организации поддержки комплексных усилий по модернизации.</p> <p>Учитывая важность данных на мэйнфреймах для этой революции, культурные изменения, необходимые для модернизации мэйнфреймов, становятся ключом к успеху в области ИИ, а следовательно, и к модернизации самого предприятия.</p> <h3>Почему модернизация предприятия останавливается на мэйнфрейме</h3> <p>По мере того, как предприятия все чаще обращаются к ИИ для получения ценности для бизнеса, становится ясно, что данные организации являются ключом к успеху.</p> <p>А где же находятся корпоративные данные? Большая их часть — самые важные данные — хранятся на мэйнфрейме. Сегодняшние мэйнфреймы содержат наиболее точные, полные и достоверные данные для любой организации, которая зависит от этой платформы.</p> <p>Однако без успешной модернизации доступ к данным мэйнфрейма в режиме реального времени может быть затруднен. Они могут быть скрыты за проприетарными интерфейсами и устаревшими технологиями интеграции.</p> <p>Более того, в некоторых организациях, где культурная инерция сдерживает усилия предприятия по модернизации бизнеса, «закрытая» экосистема изолирует данные мэйнфрейма.</p> <h3>Разрушение культурной изоляции вокруг данных мэйнфреймов</h3> <p>Хорошая новость: в мире мэйнфреймов существует устоявшееся движение, направленное на преодоление этой культурной инерции — изменение подхода организаций к инновациям, основанным на технологиях, с целью интеграции мэйнфреймов в корпоративную среду, а не их игнорирования.</p> <p>Это движение: Open Mainframe Project и его флагманский проект Zowe. OMP — это инициатива Linux Foundation, ведущей мировой Open Source-организации.</p> <p>OMP был основан в 2015 г. консорциум поставщиков, партнеров и академических учреждений, включая платиновых членов IBM, ADP, CA Technologies (теперь Broadcom) и SUSE, чтобы поощрять использование Linux и других Open Source-технологий на мэйнфреймах.</p> <p>Помимо технологических преимуществ, наиболее важным аспектом видения OMP является роль, которую мэйнфрейм должен играть на современном предприятии. Он должен быть активной, хорошо интегрированной и неотъемлемой частью ИТ-инфраструктуры любой организации, использующей мэйнфреймы.</p> <p>Фактически, Open Source-миссия OMP касается не только доступности исходного кода и аспектов свободного использования ПО с открытым исходным кодом. Что еще важнее, OMP использует <a name="OLE_LINK17">коллаборативную</a> природу сообщества Open Source-разработчиков, что стимулирует инновации на мэйнфреймах.</p> <p>Используя коллаборативную силу Open Source, предприятия могут устранить привязку мэйнфрейма к поставщику, превратив его в совместимую, управляемую сообществом платформу — важнейшие характеристики любой облачной инициативы.</p> <h3>Zowe: сердце OMP</h3> <p>В основе OMP лежит Zowe, Open Source-фреймворк, который предоставляет техническую основу и соответствующие инструменты как для разработчиков, так и для персонала, занимающегося эксплуатацией мэйнфреймов, для создания и использования ПО с открытым исходным кодом на мэйнфрейме.</p> <p>В то время как OMP поддерживает Open Source-сообщество и экосистему для мэйнфреймов, Zowe обеспечивает технический мост, который воплощает в жизнь концепцию OMP.</p> <p>Внедрение Zowe позволяет организациям снизить риски, связанные с модернизацией мэйнфреймов, расширить круг сотрудников, комфортно работающих на этой платформе, и использовать мэйнфреймы для модернизации своих предприятий.</p> <p>Фактически, многие компании, использующие мэйнфреймы и внедрившие Zowe, сообщают о более быстрой адаптации разработчиков, ускоренном доступе к основным бизнес-данным и улучшенном сотрудничестве между командами, работающими с мэйнфреймами, и более широкой организации распределенных вычислений.</p> <p>В результате организации, использующие мэйнфреймы, могут преодолеть культурные барьеры на пути к модернизации, становясь более инновационными и динамичными, используя данные и приложения на мэйнфрейме для модернизации своего бизнеса.</p> <h3>Мнение Intellyx</h3> <p>Легко утверждать, что растущая зрелость OMP и Zowe способствует успеху и снижает риски модернизации мэйнфреймов. Но можем ли мы выдвинуть более широкое утверждение о том, что OMP способствует модернизации всего предприятия?</p> <p>Такая модернизация выходит за рамки технологий и охватывает то, как люди работают, взаимодействуют с клиентами и воспринимают роль технологий в своих организациях.</p> <p>С OMP мэйнфрейм превращается из ограничивающего фактора для инноваций в стратегическую платформу для них. Будь то инициативы в области ИИ или другие стратегические цифровые проекты, мэйнфрейм теперь может играть центральную вспомогательную роль для всех таких видов деятельности.</p> <p>Одним из результатов этого культурного сдвига является высвобождение ресурсов, которые ранее были труднодоступны. Инициативы по модернизации, независимо от их конкретной направленности, теперь могут рассчитывать на поддержку мэйнфрейма.</p> <p>Модернизация, осуществляемая с помощью OMP, приносит многочисленные преимущества для бизнеса предприятия:</p> <ul> <li> изменения на уровне предприятия происходят быстрее и безопаснее;</li> <li> современные технологические решения, включая ИИ и нативные облачные вычисления, теперь могут опираться на мэйнфрейм;</li> <li> модернизация предприятия может в полной мере использовать непревзойденную безопасность и отказоустойчивость этой платформы;</li> <li> более тесное сотрудничество внутри ИТ-организации, а также между бизнес-подразделениями и техническими специалистами способствует культурным изменениям;</li> <li> мэйнфрейм останется актуальным по мере развития инноваций.</li> </ul> <p>Больше не предлагая дихотомию «мы vs. они» или «медленно vs. быстро», мэйнфрейм является мощным, отказоустойчивым и безопасным участником современных усилий по модернизации предприятия.</p> <p>Если вашей организации все еще сложно позиционировать мэйнфрейм как двигатель инноваций на уровне всего предприятия, не отчаивайтесь: OMP может показать вам, как поставить мэйнфрейм в центр модернизации предприятия, где он трансформируется из системы учета в систему инноваций.</p> Джейсон Блумберг, основатель и управляющий директор аналитической компании Intellyx, специализирующейся на цифровой … article https://www.itweek.ru/themes/detail.php?ID=234771 Tue, 05 May 2026 16:09:31 +0300 <p>«МойОфис», российская продуктовая ИТ-компания, представила новый релиз продукта «МойОфис для дома». В версии 26.1 расширены возможности табличного редактора, реализована темная тема оформления для Windows, а также добавлена поддержка интерпретатора макросов VBA — функции, которая ранее была доступна только корпоративным клиентам.</p> <p>В «МойОфис Таблица» добавлена поддержка интерпретатора VBA — языка программирования, на котором в Excel пишутся макрокоманды. Пользователи, чьи рабочие процессы исторически были выстроены в табличном редакторе Microsoft, могут открывать файлы с макросами и запускать привычные сценарии автоматизации. Система конвертирует VBA-макрос в Lua — внутренний язык программирования, на котором табличный редактор МойОфис понимает макрокоманды. При этом исходный VBA-код не меняется, а для пользователя этот процесс остается незаметным. Функциональность позволяет сохранить накопленные расчеты, формы отчетности и сложные финансовые модели. В текущей версии реализована поддержка базового синтаксиса VBA и ключевых объектов — Application, Workbook, Worksheet и Range. Этого достаточно для корректной работы многих типовых макросов, используемых бухгалтерией, финансистами и аналитиками.</p> <p>Темная тема теперь доступна для Windows в приложениях «МойОфис Текст», «МойОфис Таблица» и «МойОфис Презентация». Она снижает нагрузку на зрение при длительной работе и адаптирует интерфейс под условия низкой освещенности. Пользователям доступны три режима: системный, светлый и темный. По умолчанию активен системный режим, который автоматически подстраивает цветовую гамму редакторов под настройки операционной системы. При включении темной темы затемняются панели инструментов, меню и служебные области, а рабочая зона (лист документа, таблицы или слайд) сохраняет привычный белый цвет. Это обеспечивает корректное визуальное восприятие контента, который будет выглядеть точно так же, как на других устройствах или при печати.</p> <p>В «МойОфис Таблица» добавлены функции для извлечения данных из сводных таблиц, расчета чистой приведенной стоимости и разницы между датами, а также введены новые сокращения для быстрого ввода формул. Фильтрация стала более гибкой благодаря настраиваемому фильтру с двумя условиями и логическими операторами "И"/"ИЛИ«. Текстовые фильтры теперь автоматически распознают тип данных и предлагают подходящие условия: «начинается с», «заканчивается», «содержит» и другие. Сортировка дополнена поддержкой значков условного форматирования, учетом регистра, сортировкой по строкам и пользовательским спискам — например, по приоритету задач или этапам проекта.</p> <p>Кроме того, в релиз 26.1 вошли функция «Текст по столбцам», условное форматирование по цветовой шкале и значкам, подсветка активной строки и столбца, отображение размера выделенного диапазона, перенос листов между книгами, настройка цвета вкладок, а также возможность свернуть группы одним действием.</p> <p>«Каждое из изменений нового релиза „МойОфис для дома“ продиктовано реальными потребностями тех, кто ежедневно работает с нашими продуктами. Мы планомерно переносим в домашнюю версию технологии, уже реализованные в корпоративных решениях, чтобы профессиональные инструменты для работы были доступны каждому пользователю», — отметил генеральный директор «МойОфис» Вячеслав Закоржевский.</p> «МойОфис», российская продуктовая ИТ-компания, представила новый релиз продукта «МойОфис для дома». В версии 26.1 расширены … message https://www.itweek.ru/themes/detail.php?ID=234770 Tue, 05 May 2026 16:07:19 +0300 <p>Компания RooX объявила о выпуске продукта RooX UIDM CIAM++ — решения для управления аутентификацией и авторизацией внешних пользователей, ориентированного на построение единого клиентского ID и централизованного контроля доступа в цифровых сервисах.</p> <p>RooX UIDM CIAM++ позволяет компаниям создать единый идентификатор пользователя — клиентский ID — который объединяет доступ к различным сервисам, приложениям и каналам взаимодействия. Это дает бизнесу возможность управлять клиентским опытом и безопасностью в едином контуре — от первого входа до сложных сценариев работы с API и партнерскими интеграциями.</p> <p>В основе RooX UIDM CIAM++ — сервер аутентификации, который защищает веб-приложения и API. Продукт поддерживает современные протоколы (OIDC, OAuth 2.0, SAML), многофакторную аутентификацию и интеграцию с внешними провайдерами, позволяя выстраивать гибкие и безопасные пользовательские сценарии.</p> <p>Второй важной частью продукта является сервис авторизации. В продукт входит Access Gateway — встроенный шлюз, который позволяет управлять авторизацией и доступом к приложениям и API. Это дает возможность контролировать не только вход пользователя, но и его действия внутри цифровых сервисов.</p> <p>Архитектура RooX UIDM CIAM++ построена по принципу API-first и ориентирована на разработчиков. Продукт легко встраивается в существующие сервисы с помощью SDK и SPI, позволяя интегрировать функции аутентификации и авторизации без ограничений по технологическому стеку и архитектуре.</p> <p>Отдельное внимание уделено пользовательскому опыту: заказчики могут использовать готовые интерфейсы, адаптировать их под свои задачи или полностью управлять внешним видом через API, сохраняя контроль над UX своих цифровых сервисов.</p> <p>Продукт также обеспечивает централизованный аудит, контроль сессий и жизненного цикла учетных записей, что позволяет интегрировать его в ИБ-контур.</p> <p>RooX UIDM CIAM++ разворачивается в периметре заказчика — на локальной инфраструктуре или в защищённом приватном облаке. Продукт является полностью российской разработкой, входит в реестр отечественного ПО, отвечает требованиям ФСТЭК и совместим с отечественным технологическим стеком.</p> <p>«RooX UIDM CIAM++ — это модуль аутентификации и авторизации, который можно встроить в любой цифровой сервис. Команда разработки получает готовый, гибкий и управляемый модуль доступа и может сосредоточиться на развитии бизнес-функций», — прокомментировал генеральный директор RooX Алексей Хмельницкий.</p> Компания RooX объявила о выпуске продукта RooX UIDM CIAM++ — решения для управления аутентификацией … message https://www.itweek.ru/themes/detail.php?ID=234769 Tue, 05 May 2026 16:03:04 +0300 <p>AppSec Solutions интегрировала свой инструмент для статического анализа AppSec.Wave с MCP-сервером, чтобы обеспечить легкое взаимодействие с Claude Code, Cursor и другими решениями для анализа уязвимостей в коде на самых ранних этапах разработки приложений. Разработчики, пишущие код с помощью ИИ-сред, смогут проводить проверку сгенерированного ПО на уязвимости автоматически.</p> <p>Ранее компания расширила для вайб-кодеров возможности своего анализатора open-source компонентов AppSec.Track для поиска несуществующих или вредоносных сторонних пакетов.</p> <p>Интеграция с MCP-сервером, уверены инженеры AppSec Solutions, позволит проверять защищенность сгенерированного кода на ранних этапах разработки и кратно увеличит качество и безопасность ПО. Инструмент позволяет просканировать и обнаружить критические уязвимости, допущенные ИИ в частях кода до их выхода в прод. Для компаний это даст возможность разгрузить ИБ-инженеров, сегодня вынужденных разбирать на уязвимости тысячи строк в уже готовых приложениях.</p> <p>AppSec.Wave — инструмент статического анализа кода, который поддерживает множество языков программирования, включая JavaScript, Python, Go, C++, Java, PHP, Ruby, C#. В 2026 году к этому списку намерены добавить и российский язык 1С, которым активно пользуются отечественные разработчики.</p> <p>«Основной тренд последних полутора лет — активное внедрение в разработку генерируемого ИИ-кода. По данным из открытых источников, до 80% ПО пишется с помощью ИИ. Даже маленькие стартапы имеют десятки репозиториев с машинописным кодом. Массовое распространение вайб-кодинга требует серьезного ускорения и усиления кибербезопасности. Пока задача для разработчиков упрощается, у инженеров по кибербезопасности становится больше работы. Приведу пример: неопытные стажеры, пользуясь ИИ, зачастую загружают в нейросети значительные объемы данных непосредственно из среды разработки, не удаляя при этом конфиденциальную информацию, включая пароли. В результате эти сведения без предварительной фильтрации попадают в открытые базы данных для обучения и исследований, что создает серьезные риски безопасности», — рассказал руководитель продукта AppSec.Wave компании AppSec Solutions Антон Прусак.</p> <p>AppSec.Wave уже интегрирован с платформой AppSec.Hub, что дает разработчикам возможность управлять всем циклом безопасной разработки из одной точки. Доработки позволят бизнесу увеличить скорость безопасной разработки в несколько раз.</p> AppSec Solutions интегрировала свой инструмент для статического анализа AppSec.Wave с MCP-сервером, чтобы обеспечить легкое … message https://www.itweek.ru/themes/detail.php?ID=234768 Tue, 05 May 2026 15:58:29 +0300 <p>Российский разработчик экосистемы продуктов для ИТ-инфраструктуры Orion soft выпустил новый релиз платформы виртуализации рабочих столов и приложений Termit 2.5. Масштабное обновление повышает безопасность, улучшает пользовательский опыт и расширяет функциональность решения.</p> <p>В обновлении Termit 2.5 большое внимание уделено информационной безопасности. Появилась поддержка ГОСТ-шифрования трафика — эта функциональность востребована у компаний, которым необходимо соблюдать законодательство в сфере защиты данных и государственных информационных систем. Новая версия платформы также совместима с сертифицированной ФСТЭК серверной виртуализацией zVirt Max 1.2. Организации могут использовать комплекс решений от Orion soft в инфраструктуре, которая должна соответствовать требованиям приказа ФСТЭК № 117 о защите ГИС, <nobr>187-ФЗ</nobr> о безопасности КИИ, <nobr>152-ФЗ</nobr> о защите персональных данных и других нормативных актов.</p> <p>Новая версия повышает стабильность работы платформы. С помощью обновленных механизмов балансировки сессий и настройки шлюзов внешнего доступа администраторы могут более гибко управлять нагрузкой на инфраструктуру и снизить риски сбоев. А улучшенный мониторинг помогает следить за возникающими инцидентами и быстро реагировать на них.</p> <p>Termit 2.5 помогает компаниям обеспечить сотрудников с гибридным, удаленным и полевым режимом работы надежным и удобным виртуальным рабочим окружением. Например, у работников появилась возможность подключаться к физическим рабочим станциям (АРМ) — то есть продолжить работу с домашнего компьютера, подключившись к корпоративному устройству. Новая функциональность менеджер пользовательских сессий позволяет сотрудникам самостоятельно управлять своими подключениями. Это снижает нагрузку на техническую поддержку и позволяет быстрее восстановить подключение в случае кратковременных сбоев. Также добавлена поддержка веб-клиента для Linux — работники могут подключиться к виртуальному рабочему месту на базе этой ОС с любого устройства, включая мобильные. </p> <p>«Масштабное обновление 2.5 выводит платформу Termit на новый уровень зрелости решения, которое полностью соответствует запросам enterprise-компаний. Мы развиваем наш продукт, исходя из обратной связи всех, кто работает с платформой: руководителей, сотрудников, администраторов. Поэтому в новом релизе мы стремились добавить новые важные функциональности и вместе с этим не усложнить пользовательский опыт. Отзывы заказчиков, которые уже познакомились с Termit 2.5, подтверждает, что нам это удалось», — поделился Константин Прокопьев, лидер продукта Termit, Orion soft.</p> <p>Следующим крупным обновлением платформы станет Termit 2.6, которое запланировано на третий квартал 2026 года. В этом релизе разработчики представят собственный протокол доставки рабочих столов и приложений — Termit Pulsar.</p> Российский разработчик экосистемы продуктов для ИТ-инфраструктуры Orion soft выпустил новый релиз платформы виртуализации рабочих … message https://www.itweek.ru/themes/detail.php?ID=234766 Tue, 05 May 2026 10:38:11 +0300 <p><em>Инвестиции в искусственный интеллект растут быстрее, чем уверенность предприятий в их окупаемости. Советы директоров хотят ясности, финансовые директора — цифр, которые они могут обосновать, а технологические лидеры хотят масштабировать то, что работает. Тем не менее, многие разговоры об ИИ по-прежнему заканчиваются одинаково: «Мы знаем, что это ценно — мы просто не можем это доказать», пишут в корпоративном блоге Брайан Хопкинс, вице-президент </em><a name="OLE_LINK14"><em>Forrester</em></a> <em>по портфелю новых технологий, и Лиза Сингер, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Этот разрыв вызван не слабыми моделями или незрелыми платформами. Он вызван устаревшими способами измерения ценности. Проблема рентабельности инвестиций (ROI) в ИИ — это не технологическая проблема, это проблема измерения.</p> <h3>Почему проблема ROI кажется сложнее, чем должна быть</h3> <p>Использование ИИ в целом быстро перешло от экспериментов к внедрению в производство в маркетинге, продажах, обслуживании, разработке продуктов и операциях. Но большинство организаций по-прежнему оценивают ИИ, используя бизнес-кейсы, разработанные для автоматизации или аналитики: изолированные KPI, разрозненные панели мониторинга и завышенные ожидания по окупаемости.</p> <p>Этот подход не работает, потому что ценность ИИ должна оцениваться не только по традиционным финансовым показателям, но и по средствам и срокам предоставления этой ценности. ИИ обладает потенциалом изменить ваших клиентов, ваш бизнес и мир в большей степени, чем облачные технологии, мобильные приложения или большие данные в прошлом,. Но эти изменения не произойдут мгновенно. Когда руководители ожидают, что все инвестиции в ИИ быстро принесут прибыль, разочарование неизбежно. Именно это мы наблюдаем сейчас.</p> <h3>Реальная проблема: нет общего языка для оценки ценности ИИ</h3> <p>Организации не могут масштабировать влияние ИИ, потому что им не хватает последовательного способа описывать, сравнивать и измерять результаты в различных сценариях использования и функциях. Финансовый отдел ищет сигналы о доходах, затратах и ​​рисках. Бизнес-лидеры ищут опыт и рост. Технологические лидеры ищут возможности и повторное использование.</p> <p>Без общего языка бизнес-кейсы теряют доверие, портфели ИИ фрагментируются на пилотные проекты, а обсуждения ROI становятся политическими, а не аналитическими. Пока руководители не придут к согласию относительно того, <em>какого рода ценность</em> должен приносить ИИ, дебаты о ROI будут продолжаться независимо от эффективности модели.</p> <p> #IMAGE_234767#</p> <p>Призванная помочь клиентам решить проблему определения ценности ИИ, наша недавно опубликованная структура матрицы ценности описывает девять аспектов ценности по двум осям:</p> <ul> <li><strong> Финансовые результаты:</strong> где проявляется влияние ИИ (например, создание дохода, снижение затрат и повышение эффективности, снижение рисков).</li> <li><strong> Механизмы создания ценности:</strong> как ИИ создает это влияние (включая, например, производительность, вовлеченность, стратегию).</li> </ul> <p>Такое разделение важно, потому что оно отделяет то, где ценность проявляется, от того, как она создается. Ценность, обусловленная производительностью, возникает быстро и становится видимой. Ценность, обусловленная вовлеченностью, требует больше времени и веры в то, что ИИ действительно приводит к лучшим результатам для клиентов. А стратегическая ценность — такая как перепозиционирование на рынке или адаптивное реагирование на конкуренцию — возникает медленнее и ее еще сложнее определить, но она более устойчива. Именно отношение ко всем трем показателям как к одинаковым по срокам окупаемости инвестиций приводит к тому, что результаты использования ИИ кажутся непоследовательными.</p> <h3>Упростите обсуждение ROI с помощью матрицы ценности ИИ</h3> <p>Соединяя три финансовых результата с тремя механизмами получения ценности, матрица ценности ИИ от Forrester определяет девять различных способов, которыми ИИ создает ценность. Это добавляет три вещи, которых не хватало большинству организаций:</p> <ol> <li><strong> Матрица позволяет сопоставлять ценность ИИ.</strong> Руководители могут оценивать совершенно разные инициативы в области ИИ, используя одну и ту же структуру, вместо того чтобы спорить о несовместимых показателях.</li> <li><strong> Матрица устанавливает реалистичные ожидания.</strong> Команды знают, предназначена ли инвестиция для быстрого повышения производительности, улучшения вовлеченности или долгосрочного стратегического преимущества — и могут соответствующим образом измерять успех.</li> <li><strong> Матрица улучшает инвестиционную дисциплину.</strong> Портфели могут целенаправленно балансировать краткосрочную окупаемость с растущей стратегической ценностью, вместо того чтобы по умолчанию выбирать самый легкий путь к успеху.</li> </ol> <p>Что наиболее важно, матрица заменяет повествование структурой. Рентабельность инвестиций в ИИ перестает быть чем-то, что руководители защищают постфактум, и становится тем, что они планируют заранее.</p> <h3>Что должны делать руководители дальше</h3> <p>ИИ больше не эксперимент. Но для его ответственного масштабирования необходимо отказаться от универсального подхода к оценке ROI.</p> <p>Руководителям следует:</p> <ul> <li>Определять успех ИИ по типу ценности, а не только по финансовому результату.</li> <li> Устанавливать различные цели и сроки для производительности, вовлеченности и стратегии.</li> <li> Использовать единую структуру, подобную нашей, для согласования бизнес-кейсов, управления и измерения.</li> </ul> <p>При таком подходе ROI становится ориентиром для принятия более разумных инвестиционных решений, а не просто инструментом для обоснования постфактум. Именно так ценность ИИ переходит от разрозненности к подотчетности.</p> Инвестиции в искусственный интеллект растут быстрее, чем уверенность предприятий в их окупаемости. Советы … article https://www.itweek.ru/themes/detail.php?ID=234764 Tue, 05 May 2026 10:26:24 +0300 <p><em>Как CISO отстоять бюджет перед менеджментом, сколько экономит автоматизация, почему регулярные фишинговые рассылки на 30 человек эффективнее, чем на всю компанию? В этой колонке сведен в практические советы опыт CISO, представленный в рамках дискуссии на конференции FIS-2026.</em></p> <h3>Как быть, когда при 30%-ном росте инцидентов бюджеты на ИБ сокращаются?</h3> <p>С сокращением бюджетов на информационную безопасность сталкивается немалая часть компаний. И это при 30%-ном росте количества инцидентов, который нам спрогнозировали эксперты Positive Technologies на 2026 год. В ситуации объявленной кибервойны, когда кибератаки эволюционизируют и усложняются, а ИБ-специалистов по-прежнему не хватает.</p> <p>Если денег на ИБ выделяется меньше, то возникает больше рисков для компаний. Так как CISO держат оборону в новых реалиях?</p> <p>Этой теме был посвящен круглый стол на ежегодно проводимой ARinteg конференции FIS-2026 («Future of Information Security: тренды, практики, решения»). В нем приняли участие руководители по ИБ из разных отраслей; вышел всесторонний и полезный разговор, который позволил шире взглянуть на ситуацию и переосмыслить происходящее. Поделюсь отдельными интересными моментами.</p> <h3>Развенчиваем мифы: SIEM — не Mercedes, ИБ — не автопарк</h3> <p>Немалому числу CISO сейчас приходится вести сложные переговоры с бизнесом, наглядно показывая, какую пользу принесет реализация тех или иных проектов: апеллировать к регуляторике (на такие-то штрафы не попадем, риски минимизируем) и реальным деньгам (сколько сэкономим и каких опасностей избежим). Доходчиво объяснять, чем может обернуться мнимая экономия средств на информационную безопасность, и развенчивать мифы про ИБ.</p> <p>Приведу пример: у нас любят проводить аналогии и одну из сложных систем информационной безопасности, допустим, SIEM, могут сравнить с автомобилем высокого класса и потом предложить выбрать более бюджетную модель: «Зачем нам этот Mercedes, мы же можем и на „Ладе“ покататься?». Но в реальности это так не работает.</p> <p>Нельзя тот или иной инструмент в ИБ рассматривать как отдельный автомобиль (аналогия с машиной скорее уместна для всей системы информационной защиты компании). «Да, мы можем постараться сэкономить на том или ином инструменте, но тогда надо считать всю совокупную стоимость владения, а это все расходы, связанные с переходом на новую систему: от пилотирования до дальнейшего обслуживания, когда ИБ-службе, возможно, потребуется нанять уже не 1<strong>-</strong>2 аналитиков для работы с более доступной SIEM, а целых пять. И в итоге можем получить мнимую экономию. Поскольку таких тонкостей немало, к сожалению, то все это нам приходится подолгу обстоятельно и не раз объяснять», — поделился один из CISO.</p> <h3>Оттачиваем харденинг и практикуем киберучения</h3> <p>Но как говорится, нет худа без добра: компании из сфер, в меньшей степени подверженных регуляторике, в ситуации оптимизации расходов на ИБ начинают больше внимания уделять харденингу инфраструктуры, тщательнее разбираться с правами и настройками и стремятся делать все для того, чтобы уменьшать поверхность возможной кибератаки.</p> <p>В практику входит проведение регулярных киберучений, на которых оттачивается способность быстро восстанавливаться, после чего вопросы из разряда: «Что вы сделаете, если у вас зашифрован компьютер?», — уже не ставят никого в тупик, а пароли от бекапов не оказываются внутри самих бекапов.</p> <p>Хорошо показывают себя и тренировочные таргетированные фишинговые рассылки, которые отправляются уже не на всю компанию, а выборочно человек на 30. Они результативнее, их легче обрабатывать. В итоге сотрудники держатся в тонусе, а с теми, кто на них попадается — проводится обучение.</p> <h3>На ИИ нет запрета, тогда как вы это контролируете?</h3> <p><strong>«</strong>Сотрудники так или иначе „юзают“ ИИ внутри компании, а раз так, то этот вопрос надо регламентировать, люди должны понимать, как грамотно взаимодействовать с нейросетями. Им стоит объяснять их риски и ответственность, поскольку и по <nobr>152-ФЗ</nobr> можно попасть, и по коммерческой тайне», — такое мнение прозвучало на дискуссии, и с ним не могу не согласиться. Уже трудно представить компанию, в которой сотрудники не знакомы с нейросетями. Специалисты по ИБ тоже учатся правильно взаимодействовать с языковыми моделями, чтобы оперативно решать свои повседневные задачи, допустим, те же журналы анализировать быстрее.</p> <p>Насколько и в чем нейросети помогут сократить наши расходы в ИБ — надо смотреть и тестировать. Где-то это может занять немало времени, и под это порой может потребоваться отдельный штат. Поэтому когда речь идет о замене ИИ функционала <nobr>4-5 человек,</nobr> то такой проект, скорее всего, окажется нерентабельным, а вот если предполагаем замену функционала <nobr>20-30 сотрудников,</nobr> то об этом, возможно, стоит подумать.</p> <h3>Автоматизация в приоритете</h3> <p>Затронули и вопрос кадров в ИБ, которых на все не хватает: кто и как работает с людьми, повышает их экспертизу, что автоматизирует, кого и на что нанимает. Вопрос, как вы понимаете, при экономии и сокращении бюджетов актуальный.</p> <p>В условиях, когда задач больше, чем специалистов по ИБ, компании предпочитают растить «своих спецов», а потому стараются вкладываться в молодых, которые реально хотят развиваться, но у них ещё нет опыта. Берут на практику, смотрят, как человек проявит там себя, и предлагают оффер тем, кто им в большей степени подходит. Оказалось, что немало компаний находят возможности для развития кадров: оплачивают обучение, стараются заинтересовать участием в интересных, нетривиальных проектах.</p> <p>Выяснили, что автоматизация, бесспорно, выручает.</p> <h3>Три выкупа и угроза увольнения: история одного инсайдера</h3> <p>Приведу историю одного из CISO про роль человеческого фактора. Одну из компаний стали одолевать шифровальщики: огромный массив данных зашифровали и потребовали выкуп. Руководство один раз заплатило выкуп, другой, а на третий поставило перед ИБ вопрос ребром: «Если в этот раз станем платить, то зарплаты у вас уже не будет. Делайте, что хотите, но причину надо искоренить».</p> <p>И это оказалось решением проблемы. Коллектив каким-то образом нашел того, кто внутри компании этим занимался, тот человек имел какие-то личные счеты с руководством и, таким образом, старался компенсировать свой негатив.</p> <p>Этот пример — наглядное свидетельство того, что защите от инсайдеров нельзя не уделять внимание. Проблема может быть и не настолько сложна, но нельзя недооценивать в ИБ роль человеческого фактора.</p> <h3>Как недельные посты про мошенников сделали безопасников друзьями компании</h3> <p>И в заключение приведу историю проекта в одной из организаций, который шел не один месяц и со временем позволил изменить представление сотрудников об информационной безопасности.</p> <p>Там начали с того, что стали каждую неделю в постах рассказывать истории про то, как защитить себя и близких от разного рода уловок мошенников, какие те используют методы, что сейчас в тренде, на чем те могут поймать, обмануть и так далее, и как всему этому противостоять. С основным посылом: «в любой непонятной ситуации обращайтесь в ИБ, всегда поможем».</p> <p>Просто начали с людьми разговаривать, это несложно. И это сработало: сотрудникам истории понравились, они стали приходить в подразделение ИБ, советоваться, понимая, что их здесь поддержат и придут на выручку. Вот такой результат оказался у проекта по повешению киберграмотности в одной из компаний.</p> <p>Полагаю, что в 2026 году CISO все чаще будут работать не только с угрозами, а еще и с убеждениями. Надо уметь убедить бизнес не экономить на главном, убедить сотрудников не бояться обращаться в ИБ за советом и помощью, убедить себя, что автоматизация — не слабость, а способ выживания при сокращающихся бюджетах.</p> <p>Дискуссия на FIS-2026 мне также ясно показала, что кибербезопасность — это еще и про искусство диалога. И, судя по приведенным кейсам, тот, кто овладеет им в совершенстве — будет крепко держать оборону.</p> <p>#IMAGE_234765#</p> Как CISO отстоять бюджет перед менеджментом, сколько экономит автоматизация, почему регулярные фишинговые рассылки … article Дмитрий Слободенюк, коммерческий директор ARinteg https://www.itweek.ru/themes/detail.php?ID=234762 Mon, 04 May 2026 16:39:22 +0300 <p>По данным исследования компании «Информзащита», 92% организаций, столкнувшихся с серьезными инцидентами информационной безопасности за первые четыре месяца 2026 года, фиксировали попытки или подтвержденные эпизоды перехода нарушителя с одного узла на другой внутри своей инфраструктуры. В аналогичном периоде прошлого года этот показатель составлял 84%. Одновременно сократилась и пауза между первоначальным проникновением и началом дальнейшего продвижения: если в 2025 году среднее время до первой попытки перехода на соседнюю систему составляло 1 час 18 минут, то в 2026 году оно снизилось до 52 минут. Средняя продолжительность простоя критичных бизнес-сервисов после таких инцидентов выросла с 5,9 до 7,3 часа, а доля случаев, в которых злоумышленники успевали добраться до критически важных систем, поднялась с 41% до 57%.</p> <p>За последний год корпоративные среды стали еще плотнее связаны между собой. Удаленный доступ, облачные площадки, смешанные вычислительные среды, связи между внутренними и внешними сервисами, служебные учетные записи, интеграционные программные интерфейсы и подключения подрядчиков заметно расширили число внутренних маршрутов, которыми можно воспользоваться после первого успешного входа. На практике нарушителю уже недостаточно просто оказаться внутри сети. Намного важнее быстро понять, где сосредоточены повышенные права, какие участки инфраструктуры слабо отделены друг от друга, где применяются одинаковые пароли, какие узлы доверяют друг другу по умолчанию и какие учетные записи не пересматривались годами. Чем теснее связана среда и чем меньше в ней реальных ограничителей, тем быстрее локальный инцидент превращается в цепочку последовательных компрометаций. </p> <p>Отдельную роль сыграло изменение самого поведения атакующих. По наблюдениям экспертов, злоумышленники стали действовать тише в первые минуты после входа. Вместо этого они почти сразу переходят к изучению внутренних связей, проверке прав доступа, поиску учетных записей с расширенными полномочиями и обходу межсетевых ограничений. В 63% расследованных инцидентов продвижение внутри инфраструктуры начиналось через штатные средства администрирования или стандартные механизмы операционной системы — удаленное исполнение команд, встроенные оболочки, механизмы управления рабочими станциями и серверами, стандартные протоколы удаленного доступа, что заметно осложняло раннее выявление. Еще в 48% случаев нарушители использовали уже существующие доверенные каналы обмена между системами и повторно применяли уже имеющиеся в инфраструктуре учетные данные и билеты аутентификации, обходясь без разворачивания отдельного вредоносного кода на каждом следующем шаге. Внешне активность долго выглядит допустимой, а внутренняя передача данных не вызывает тревоги до тех пор, пока атака не доходит до контроллеров домена, серверов виртуализации, систем резервного копирования или почтовой системы. </p> <p>Отдельного внимания заслуживают системы резервного копирования. За последние два года они превратились в одну из приоритетных целей: компрометация контура резервных копий лишает компанию возможности быстрого восстановления и многократно увеличивает переговорную позицию операторов программ-вымогателей. </p> <p>Глубинная причина в том, что многие компании по-прежнему выстраивают защиту внешнего периметра заметно строже, чем защиту внутренних связей. Исследование показало, что в 58% организаций, где были подтверждены переходы злоумышленников между системами, сеть оставалась частично плоской либо разделенной только на бумаге. В 54% случаев у пользователей и служебных учетных записей сохранялись избыточные полномочия, накопленные в ходе переноса систем, внедрения новых решений или смены ролей сотрудников. В 46% инцидентов существенную роль сыграли устаревшие правила удаленного сетевого доступа и чрезмерно широкий доступ для сотрудников и подрядчиков. Еще один важный фактор связан с нехваткой времени у внутренних команд. В 61% обследованных организаций проверка прав доступа и правил обмена между сегментами проводилась нерегулярно, а в 44% случаев события события низкой и средней критичности, связанные с необычными входами в систему и непривычными внутренними соединениями, разбирались с задержкой более суток. В такой среде злоумышленник получает именно то, что ему нужно для развития атаки: время, незаметность и предсказуемые маршруты.</p> <p>Наиболее уязвимыми оказались отрасли, где сочетаются сложное устройство информационной среды, высокая цена простоя и большое число взаимосвязанных систем. На финансовый сектор пришлось 22% инцидентов с подтвержденным перемещением злоумышленников между внутренними узлами, на промышленность — 19%, на розничную торговлю — 16%, на сферу связи и вычислительных услуг — 14%, на транспорт и перевозки — 11%, на здравоохранение — 9%, на государственные и окологосударственные организации — 9%. </p> <p>«Наиболее опасен не сам факт первоначального проникновения, а то, насколько быстро инфраструктура начинает помогать нарушителю двигаться дальше. Главная сложность заключается в том, что заказчик часто готовится отражать отдельную атаку, а на деле сталкивается с целой цепочкой внутренних переходов. Пока компания считает, что защищает только точки входа, нарушитель работает с полной картой доверия, которую ему оставили внутри инфраструктуры», — объяснил Анатолий Песковский, руководитель отдела анализа защищенности Центра мониторинга и противодействия кибератакам IZ:SOC «Информзащиты».</p> <p>Для минимизации рисков эксперты рекомендуют рассматривать инцидент как последовательность перемещений внутри инфраструктуры, а не как единичный взлом. Практика показывает, что наибольший эффект дают не разрозненные закупки, а наведение порядка в базовых механизмах внутренней защиты. Сегментация сети должна проверяться не по схеме согласования, а по реальной достижимости систем между сегментами. Расширенные полномочия необходимо пересматривать регулярно, а не после происшествия — по принципу наименьших привилегий и с разделением учетных записей для повседневной работы и административных действий. Удаленный доступ должен ограничиваться задачей сотрудника, а не удобством первоначальной настройки. Служебные учетные записи, доверенные связи между приложениями и внутренние правила обмена данными должны попадать в отдельный контур контроля с регулярной ротацией секретов и ревизией фактически используемых прав. Не менее важно сократить время реакции на внутренние аномалии: события низкой и средней критичности, , связанные с входами в необычное время, изменением групп доступа, резким ростом числа соединений между сегментами и использованием служебных средств управления, нельзя оставлять без оперативной проверки. </p> По данным исследования компании «Информзащита», 92% организаций, столкнувшихся с серьезными инцидентами информационной … message https://www.itweek.ru/themes/detail.php?ID=234761 Mon, 04 May 2026 16:37:53 +0300 <p>Deckhouse, разработчик продуктов для построения надёжной корпоративной инфраструктуры, объявил о расширении направления Managed Services. В платформе стали доступны новые управляемые сервисы для работы с данными: Trino, Hive Metastore, Kafka и Cassandra. Параллельно с этим продолжается развитие ранее реализованных сервисов — PostgreSQL, Valkey и Memcached.</p> <p>Новые компоненты закрывают ключевые сценарии для работы с данными — от потоковой обработки и распределённого хранения до аналитических запросов — и при этом не требуют отдельных операционных команд: всё управляется через единый Kubernetes-native-интерфейс платформы.</p> <p>Расширение Managed Services позволяет пользователям реализовывать архитектуру Lakehouse и event-driven-сценарии в рамках одной платформы. Trino и Hive Metastore обеспечивают слой аналитических запросов и метаданных для работы с распределёнными хранилищами, Kafka — надёжную потоковую передачу данных, а Cassandra — масштабируемое распределённое хранилище для высоконагруженных систем.</p> <p>За прошедший период существенно выросли и уже запущенные сервисы. PostgreSQL стал быстрее справляться с высокими нагрузками и получил расширенные возможности горизонтального масштабирования. Valkey и Memcached точнее встроены в платформу и работают эффективнее в связке с новыми аналитическими компонентами. </p> <p>Все новые сервисы, как и уже работающие PostgreSQL, Valkey и Memcached, будут проходить сертификацию ФСТЭК России по мере готовности.</p> <p>«Мы последовательно развиваем Managed Services как единый слой для работы с данными в Kubernetes. В конце 2025 года мы вышли на рынок баз данных — это был первый шаг. Сейчас, добавив Trino, Kafka, Cassandra и Hive Metastore, мы закрываем ключевые сценарии: от потоковой обработки до аналитики. Теперь компании могут строить полноценные data-платформы в рамках одного решения — с декларативным управлением, отказоустойчивостью и сертификацией, которая критична для регулируемых отраслей», — отметил Александр Виноградов, директор направления «Данные» Deckhouse.</p> <p>Расширение линейки сервисов отвечает растущему спросу на платформенные решения для работы с данными в условиях увеличения объёма информации и распространения аналитических и AI-нагрузок. Компании переходят от разрозненных внедрений отдельных технологий к унифицированным платформам, где управление жизненным циклом данных становится частью инфраструктуры.</p> Deckhouse, разработчик продуктов для построения надёжной корпоративной инфраструктуры, объявил о расширении направления … message https://www.itweek.ru/themes/detail.php?ID=234759 Mon, 04 May 2026 10:03:29 +0300 <p><em>Новый отчет Perforce OpenLogic «</em><em>2026 </em><em>State</em> <em>of</em> <em>Open</em> <em>Source</em><em>» раскрывает переход к цифровой автономии, сочетающей свободу выбора поставщика с обеспечением обслуживания и безопасности, пишет на портале </em><em>The</em> <em>New</em> <em>Stack</em> <em>Мэтью Вейер О’Финни, главный менеджер по продуктам в Perforce Zend и OpenLogic.</em></p> <p>За последние несколько лет тема цифровой автономии вышла за рамки обсуждений архитектуры и стала предметом разговоров на уровне руководства. Все больше CIO и CTO видят растущую актуальность возврата к знакомому вопросу: насколько мы на самом деле контролируем ПО, от которого зависит наш бизнес, и как быстро мы сможем адаптироваться, если условия изменятся?</p> <p>Отчет «2026 State of Open Source» четко отражает этот сдвиг. Open Source теперь играет непосредственную роль в том, как организации стремятся к большему контролю над своими технологическими средами. Результаты опроса более чем 700 респондентов из разных регионов, отраслей и организаций различных размеров показывают, что происходит, когда открытый исходный код внедряется в производственные системы и подвергается тем же ожиданиям в отношении безопасности, соответствия нормативным требованиям и долговечности, что и любая другая критическая инфраструктура.</p> <h3>Open Source код как механизм автономии</h3> <p>Одним из наиболее ярких сигналов этого года является растущая обеспокоенность по поводу привязки к поставщику. Число респондентов, которые назвали избегание вендорлока основным фактором внедрения открытого исходного кода, увеличилось на 68% в этом году по сравнению с прошлым, при этом 55% остановили свой выбор именно на Open Source. В Европе, где регуляторное давление и опасения по поводу суверенитета уже влияют на решения в области технологий, этот показатель достиг 63%.</p> <p>Эти результаты указывают на более широкие изменения в том, как руководители воспринимают контроль. Долгосрочное использование стало приоритетом в средах, где модели лицензирования, планы развития продуктов и нормативные требования могут меняться быстрее, чем корпоративные платформы. Open Source предоставляет организациям возможность большего влияния на развитие их систем и большую гибкость в реагировании на возникающие ограничения.</p> <p>С точки зрения руководителей, такое позиционирование напрямую связывает Open Source с цифровой автономией. Он создает архитектурное пространство для маневра, сохраняет вариативность и снижает зависимость от решений, принимаемых вне организации.</p> <h3>Операционная нагрузка автономии</h3> <p>Те же данные также описывают реальность, с которой сталкиваются многие команды, когда Open Source становится основной инфраструктурой: ответственность растет вместе с контролем.</p> <p>60% респондентов из крупных предприятий сообщили, что тратят не менее половины времени инженеров на техническое обслуживание и решение производственных проблем, а не на разработку новых функций. В некоторых средах баланс смещается еще сильнее. Почти треть корпоративных Java-команд выделяют менее 25% своего времени на разработку нового функционала.</p> <p>Очевидно, это вносит сложность в стратегии цифровой автономии. По мере того, как организации снижают зависимость от поставщиков, они берут на себя бóльшую внутреннюю ответственность. Этот сдвиг предъявляет постоянные требования к персоналу, экспертизе и операционной зрелости. Когда эти области не успевают за темпами развития, инновации замедляются, и накапливается технический долг.</p> <p>Эти процессы часто проявляются в виде задержек обновлений, отложенной модернизации и необходимости для команд справляться с непрерывными циклами технического обслуживания. В экосистеме Java шестимесячный ускоренный цикл выпуска OpenJDK, также принятый фреймворком Spring, требует постоянных усилий, с которыми многие команды с трудом справляются наряду с разработкой новых функций.</p> <h3>Безопасность и соответствие нормативным требованиям как структурные ограничения</h3> <p>Управление безопасностью и уязвимостями остаются наиболее актуальными проблемами, отмеченными в отчете, независимо от размера организации. Хотя внедрение Open Source достигло зрелости, практика управления и реагирования часто отстает от масштабов.</p> <p>Для руководителей, ответственных за управление рисками и готовность к аудиту, можно выделить несколько важных выводов:</p> <ul> <li> В каждой пятой организации отсутствует четко определенный процесс реагирования на уязвимости в открытом исходном коде.</li> <li> Почти 40% крупных предприятий сообщают о трудностях с соблюдением внутренних соглашений об уровне обслуживания (SLA) по устранению уязвимостей.</li> <li> Более половины организаций, не прошедших аудит на соответствие нормативным требованиям в прошлом году, использовали в производственной среде Open Source-компоненты, срок службы которых истек.</li> </ul> <p>По мере того, как Open Source становится основополагающей инфраструктурой, ответственность за риски становится более явной. Управление патчами, отслеживание зависимостей и планирование жизненного цикла переходят от ответственности поставщика к внутренним обязательствам. Когда эти действия не имеют четкого определенного ответственного лица или достаточных ресурсов, риск возрастает, даже если системы остаются технически гибкими.</p> <p>Для высшего руководства эта реальность расширяет сферу управления Open Source. Безопасность, соответствие нормативным требованиям и управление жизненным циклом должны соответствовать целям организации в области автономии, чтобы избежать их подрыва.</p> <h3>Автономия требует устойчивого управления</h3> <p>Менее 2% респондентов сообщили о сокращении использования Open Source за последний год, что подтверждает, что эта модель стала ключевым элементом корпоративной стратегии. Наиболее актуальные вопросы для CIO, CTO и старших технологических руководителей сейчас сосредоточены на устойчивости, а не на внедрении:</p> <ul> <li> Кто отвечает за долгосрочное обслуживание Open Source в производственных средах?</li> <li> Отражают ли рабочие процессы обеспечения безопасности и выявления уязвимостей фактический размер и критичность использования Open Source?</li> <li> Насколько эффективно были снижены риски, связанные с поставщиками, и где ответственность перешла внутрь организации?</li> <li> В каких областях организациям следует углублять внутреннюю экспертизу, а где партнерство приводит к лучшим результатам?</li> </ul> <p>Отчет указывает на то, что Open Source предлагает жизнеспособный путь к цифровой автономии, но только тогда, когда он рассматривается как стратегический актив, поддерживаемый четким правом собственности, операционной дисциплиной и контролем со стороны руководства. Для предприятий, сталкивающихся с давлением в областях регуляторики и безопасности, цифровая автономия — обеспечиваемая хорошо управляемым Open Source — станет основой для достижения долгосрочной организационной устойчивости.</p> Новый отчет Perforce OpenLogic «2026 State of Open Source» раскрывает переход к цифровой автономии, сочетающей свободу … article https://www.itweek.ru/themes/detail.php?ID=234758 Mon, 04 May 2026 09:54:55 +0300 <p><em>Нимиша Астхагири, консультант по данным и искусственному интеллекту компании Thoughtworks, рассказала порталу </em><em>The</em> <em>New</em> <em>Stack</em> <em>о том, почему так много компаний испытывают трудности с переходом своих ИИ-проектов от этапа проверки концепции (</em><em>PoC</em><em>) к внедрению в производство. Среди поднятых тем: разрыв между прототипом и внедрением в производство в сфере агентного ИИ, почему возвращаются фундаментальные принципы инженерии, такие как разработка через тестирование и мутационное тестирование, и провокационная идея: большая часть кода, генерируемого ИИ, возможно, вообще не должна существовать.</em></p> <h3>Разрыв между PoC и внедрением в производство</h3> <p>Gartner прогнозирует, что более 40% проектов в области агентного ИИ будут отменены к концу 2027 г., и тенденция, которую наблюдает Астхагири, совпадает с этим прогнозом. Отчасти это связано с тем, что после стремительного развития генеративного ИИ в 2022 г. компании пережили волну PoC-проектов. И многие застряли в попытках внедрить результаты этих экспериментов в производство.</p> <p>Проблему, как считает Астхагири, иллюстрирует то, о чем спрашивают руководители. «Вопрос, который мы часто слышим от руководителей и других лиц, звучит так: как нам ускорить процесс? Как нам оставаться актуальными? — говорит она. — Я думаю, что правильный или более подходящий вопрос здесь может звучать так: что мы можем создать, используя новейшие технологии, из того, что мы не могли создать раньше?».</p> <p>Вместо того чтобы просто интегрировать ИИ в существующие рабочие процессы, успешные компании переосмысливают то, что на самом деле позволяет эта технология. Это аргумент системного мышления, утверждает Астхагири.</p> <p>Проблема, по ее мнению, заключается в отсутствии системного подхода. Говоря о том, что общего у наиболее успешных компаний, она указывает не на инструменты, а на организационные инвестиции: «Успешные компании проводят тщательный анализ. Это тяжелая работа, но она связана с грамотностью и возможностями для людей внутри вашей организации».</p> <h3>Основы инженерии возвращаются</h3> <p>В последнем выпуске <a href="thoughtworks.com/radar">Thoughtworks Technology Radar</a> утверждается, что отрасли необходимо оглянуться назад, прежде чем двигаться вперед. Radar предупреждает о накоплении когнитивного долга из-за увеличения разрыва между тем, что производит ИИ, и тем, что разработчики действительно понимают о своих собственных кодовых базах.</p> <p>Астхагири входит в глобальную команду, которая готовит Radar. Точка зрения Thoughtworks такова: при таком большом количестве ИИ-инструментов и Open Source-проектов, появляющихся в сети, никто не может оценить их все. В таких обстоятельствах разумный подход заключается в том, чтобы вернуться ко многим устоявшимся методам — не из ностальгии, а в качестве необходимого противовеса скорости, с которой инструменты ИИ могут создавать сложность.</p> <p>Астхагири указывает на разработку через тестирование, мутационное тестирование, метрики DORA и архитектуру безопасности с нулевым доверием как практики, которые должны вернуться на передний план. «Многие традиционные, фундаментальные подходы к разработке сейчас действительно становятся актуальными», — говорит она.</p> <p>Поскольку автономные кодирующие агенты все чаще пишут производственный код, петли обратной связи важны как никогда. «Что представляют собой эти датчики обратной связи? В дополнение к прямой передаче контекста, который вы предоставляете своим агентам, какова обратная связь с датчиками, тестами, линтерами и многими другими распространенными практиками?», — вопрошает Астхагири.</p> <p>Та же логика применима и к безопасности. В условиях распространения агентов на рабочих станциях разработчиков, уровень идентификации теперь должен учитывать машинных агентов так же, как и человеческих. Астхагири говорит, что архитектура с нулевым доверием имеет решающее значение для «возможности узнать, кто что сделал, а также для аутентификации и авторизации выполняемой работы».</p> <p>В наши дни эти агенты часто работают в составе большой команды. Астхагири считает, что организации движутся в направлении целенаправленно разработанных мультиагентных конфигураций, в которых агенты, отвечающие за конкретные роли в бэкэнде, фронтенде и других областях, оркестрируются людьми.</p> <h3>«Тёмный код» и аргументы в пользу эфемерного ПО</h3> <p>Говоря об огромном объёме кода, сгенерированного ИИ, и о создаваемых им узких местах на последующих этапах, Астхагири отмечает, что ответом не должно быть улучшение инструментов проверки. Вместо этого организациям следует задаться вопросом, нужен ли этот код вообще.</p> <p>«Будет много тёмного кода (dark code), — говорит она, заимствуя концепцию тёмных данных (dark data) — информации, которую организации собирают, но никогда фактически не используют. — Поскольку код станет товаром, который нужно генерировать, вам не обязательно его хранить».</p> <p>Астхагири выделяет здесь две идеи. Во-первых, организациям необходимо чётко определить жизненный цикл своего кода. PoC-код должен быть задокументирован как имеющий срок действия и архитектурно изолирован, чтобы его можно было удалить, когда нужда в нем отпадет.</p> <p>Во-вторых, некоторый код должен генерироваться как эфемерный, запускаться для однократного использования, а затем удаляться. «Если у меня нет необходимых агентных навыков, и это не обязательно повторно используемая функция, то почему бы не сгенерировать её динамически для конкретного целевого применения, и на этом всё?», — вопрошает Астхагири.</p> <p>Это связано с методом, который команда Radar называет «песочницей» для кодирующих агентов, который позволяет «запускать агентов в изолированных средах с ограниченным доступом к файловой системе, контролируемым сетевым подключением и ограниченным использованием ресурсов».</p> Нимиша Астхагири, консультант по данным и искусственному интеллекту компании Thoughtworks, рассказала порталу The New … article https://www.itweek.ru/themes/detail.php?ID=234757 Thu, 30 Apr 2026 16:11:30 +0300 <p>ICT.Moscow изучил мнения российского сегмента пользователей ИИ-агентов о приоритетных аспектах работы с ними в 2026 году. В числе основных ожиданий — фокус на их применении и расширении возможностей.</p> <p>Согласно результатам опроса, проведенного ICT.Moscow в марте этого года, российское ИТ-сообщество ждет от автономных помощников реальных, понятных функций и активно нарабатывает опыт эксплуатации.</p> <p>Заметная доля ответов респондентов показывает их желание видеть локальное использование ИИ-агентов (34%) и в то же время развитие функционала (33%) таких решений. 28% считают важным, чтобы ИИ-агенты были совместимы с существующими рабочими инструментами. Еще 27% стремятся масштабировать их по вертикали и функциям, видя в этом ценность для различных бизнес-процессов.</p> <p>Одновременно наблюдается активный запрос рынка на надежность, управляемость и прозрачность. 36% участников подчеркнули возможность полагаться на ИИ-агента как на напарника в работе. Прозрачность и безопасность решений отметили 35% опрошенных. 31% выбрали важность измеряемости и понятности результатов.</p> <p>Только 14% посчитали, что ИИ-агенты — это просто ажиотажная тема. Принимая во внимание популярность ответов, касающихся аспектов практического применения автономных помощников, можно сделать предположение, что большинство все же пока находятся в процессе изучения их возможностей и потенциала. При этом на текущем этапе для пользователей пока не столь существенным кажется разнообразие самих решений и кем они создаются — российскими или зарубежными разработчиками (12%).</p> <p>Исследование мнений проводилось ICT.Moscow в марте 2026 года среди пользователей «Базы знаний об ИИ». В нем приняли участие 624 респондента, у которых была возможность выбрать несколько вариантов ответа одновременно.</p> ICT.Moscow изучил мнения российского сегмента пользователей ИИ-агентов о приоритетных аспектах работы с ними … message https://www.itweek.ru/themes/detail.php?ID=234755 Thu, 30 Apr 2026 16:09:27 +0300 <p>Российский рынок облачных технологий продемонстрирует уверенный рост в 2026 году, превышающий 30%, по прогнозам аналитиков M1Cloud, при этом внутри него одновременно развиваются две противоположные стратегии. С одной стороны, усиливается тренд на мультиклауд, предполагающий распределение нагрузок между несколькими вендорами. С другой стороны, модель единого провайдера (single-provider), консолидирующего все ИТ-сервисы у одного партнера с полным циклом сопровождения. Ни один из подходов не вытесняет другой: выбор определяется зрелостью компании, регуляторной средой, доступностью экспертизы и архитектурными задачами.</p> <p>Мультиклауд, изначально задуманный как страховка от вендор-лока и инструмент повышения гибкости, сохраняет ценность для компаний с распределенной архитектурой, высокими требованиями к отказоустойчивости или специфичными технологическими задачами. Разные провайдеры могут предлагать оптимальные условия для отдельных сценариев: от edge-вычислений до нишевых <nobr>ML-фреймворков</nobr> или географически распределенных CDN. Мультиклауд остается осознанным выбором там, где бизнес готов инвестировать в сложную оркестрацию ради стратегической независимости и точечной оптимизации ресурсов.</p> <p>Модель с единым провайдером пользуется большим спросом на фоне острого дефицита кадров и ужесточения регуляторных требований. По данным аналитиков M1Cloud, <nobr>60–70%</nobr> российских компаний испытывают сложности с подбором инженеров виртуализации, что делает самостоятельное управление разнородными облачными средами рискованным и затратным. В таких условиях консолидация у одного проверенного партнера снижает расходы на интеграцию на <nobr>30–40%,</nobr> минимизирует простои и дает единую точку ответственности.</p> <p>Усиление норм по защите данных (локализация в РФ, сертификация ФСТЭК/ФСБ, аттестация ГИС) также подталкивает бизнес к выбору единого вендора, особенно в финансах, логистике и ИТ-емких отраслях, где мультиклауд может усложнить аудит и контроль. Как отмечает Владимир Лебедев, директор по развитию бизнеса M1Cloud: «Подход с одним провайдером упрощает экосистему, позволяя заказчикам получать персонализированные решения — включая GPU-облака для ИИ и Big Data, DRaaS и BaaS — без необходимости самостоятельно стыковать технологии». Спрос на такой комплексный IaaS с полным циклом поддержки в 2026 году ожидается на уровне роста более 40%.</p> <p>Итоговое решение формируется под влиянием нескольких взаимосвязанных переменных, которые диктуют логичный вектор развития инфраструктуры.</p> <p>Наличие собственной сильной команды с опытом облачной архитектуры и DevOps-практик часто склоняет выбор в сторону мультиклауда. Компании, способные выстраивать автоматизированную оркестрацию, получают инструмент для точечной оптимизации. В то же время организации с ограниченными внутренними ресурсами логичнее выбирают модель единого провайдера, делегируя проектирование, миграцию, мониторинг и поддержку профессионалам, что снижает нагрузку на бизнес-подразделения.</p> <p>Строгие требования по информационной безопасности, быстрая потребность в прохождении аудитов и работа с чувствительными данными делают консолидированную модель более предсказуемой и управляемой. Единый провайдер берет на себя ответственность за соответствие стандартам, что критично для регулируемых отраслей. Проекты с умеренными или отраслевыми стандартами, напротив, допускают распределенную среду, где комплаенс-задачи решаются гибче.</p> <p>Если на первом месте стоят снижение операционных расходов, единая точка технической поддержки и скорость запуска сервисов, бизнес идет к одному провайдеру. Это сокращает TCO и убирает фрагментацию данных. Если же критичны гибкость закупок, страхование от блокировок, географическое распределение или возможность быстро масштабироваться за счет альтернативных площадок, аргументы в пользу мультиклауда усиливаются.</p> <p>Монолитные, высоконагруженные и требующие комплексных решений для Disaster Recovery или обработки больших данных эффективнее размещать в единой экосистеме с гарантированным SLA и отлаженными процессами. Микросервисные архитектуры, экспериментальные среды или проекты с разнородными требованиями к производительности и доступности часто выигрывают от распределения между несколькими площадками, где каждую нагрузку можно подстроить под оптимальный стек технологий.</p> <p>В заключении Владимир Лебедев, пояснил: «Российский облачный рынок в 2026 году переходит к прагматичной гибридизации. Тренд на модель единого провайдера доминирует там, где важно быстро преодолеть кадровый и регуляторный барьеры, сократить совокупную стоимость владения и сфокусироваться на бизнес-логике. Мультиклауд остается стратегическим инструментом для организаций с высокой ИТ-зрелостью и сложной архитектурой. Для провайдеров это означает эволюцию роли: от поставщика виртуальных мощностей к партнерам по цифровой трансформации, способным предложить как комплексные пакеты, так и отдельные сервисы для гибридных сред. Итоговый выбор должен диктоваться не конъюнктурой, а экономикой проекта, компетенциями команды и требованиями бизнеса к надежности и соответствию стандартам».</p> Российский рынок облачных технологий продемонстрирует уверенный рост в 2026 году, превышающий 30% … message https://www.itweek.ru/themes/detail.php?ID=234754 Thu, 30 Apr 2026 16:01:45 +0300 <p>Цифровой рубль перестал быть экспериментом — это новая финансовая реальность, в которой банки вынуждены действовать уже сегодня. «Начинать нельзя ждать», и запятая в этом уравнении успеха теперь стоит не между словами, а между банками, которые успеют адаптироваться к грядущим изменениям, и теми, кто рискует потерять конкурентное преимущество.</p> <p>На онлайн-конференции «Цифровой рубль. Весна-2026», организованной агентством iFinMedia, эксперты обсудили ключевые этапы внедрения национальной цифровой валюты. С докладом «Цифровой рубль: время перемен» выступил Павел Обрезумов, заместитель директора по развитию продуктов Центра цифровых решений для бизнеса компании BSS. </p> <p>В своём выступлении Павел Обрезумов подчеркнул, что цифровой рубль перешёл из стадии экспериментов в фазу системной интеграции. Требования Банка России к инфраструктуре устоялись, а сроки внедрения зафиксированы на законодательном уровне. Ключевые вехи по поддержке цифрового рубля уже определены:</p> <ul> <li>с 1 сентября 2026 года функционал обязаны внедрить системно значимые кредитные организации;</li> <li>с 1 сентября 2027 года — кредитные организации с универсальной лицензией;</li> <li>с 1 сентября 2028 года — прочие кредитные организации.</li> </ul> <p>«Цифровой рубль — это не просто новый платёжный инструмент, это инфраструктурный сдвиг, который меняет логику взаимодействия между банками, бизнесом и государством, — отметил Павел Обрезумов. — Успех внедрения зависит не только от технологической готовности, но и от качества планирования, наличия компетентной команды в банке и глубокого понимания регуляторных требований».</p> <p>Компания BSS с начала проведения эксперимента развивает свое решение как готовый тиражируемый продукт, уже прошедший проверку в реальных условиях. На сегодняшний день BSS является единственным вендором, реализовавшим 10+ проектов по внедрению цифрового рубля — значительно больше, чем у ближайших конкурентов. </p> <p>Ключевые показатели BSS в сегменте цифрового рубля:</p> <ul> <li>первые проекты запущены ещё в 2022 году;</li> <li>20 банков подписали договоры на внедрение решения;</li> <li>9 банков уже вышли в промышленную эксплуатацию;</li> <li>полный цикл реализации проекта, включая прохождение тестирования в Банке России и пользовательского тестирования, занимает около 12 месяцев.</li> </ul> <p>Решение BSS построено на платформе Digital2Go и включает функциональный модуль для работы с цифровым рублём, а также интеграционный контур для взаимодействия с Финансовым посредником Платформы цифрового рубля Банка России. Продукт поставляется в «коробочной» версии в составе ДБО, что ускоряет внедрение и снижает потребность в кастомизации.</p> <p>Для кредитных организаций внедрение решения от BSS означает:</p> <ul> <li>соответствие всем актуальным требованиям ЦБ РФ;</li> <li>поддержку полного набора сценариев — от регистрации клиентов до автопереводов и работы с QR-кодами;</li> <li>готовую интеграционную модель, совместимую с существующими системами (FA, ПОД/ФТ, AML и др.);</li> <li>возможность создания гибридных финансовых продуктов и развития экосистемы финтех-сервисов.</li> </ul> <p>Для конечных пользователей цифровой рубль открывает доступ к быстрым, дешёвым и безопасным платежам, а также новые возможности управления ликвидностью и взаимодействия с государственными сервисами.</p> <p>По оценкам экспертов, к 2030 году цифровой рубль может охватить <nobr>40–45%</nobr> розничных операций в России. Это создаёт предпосылки для появления новых финансовых продуктов, интеграции с платёжными системами других стран и формирования трансграничных цифровых коридоров.</p> <p>«Начинать нельзя ждать — эта дилемма сегодня актуальна как никогда, — резюмировал Павел Обрезумов. — Банки, которые уже сегодня инвестируют в инфраструктуру цифрового рубля и выбирают проверенных партнёров с реальной экспертизой, получат стратегическое преимущество в борьбе за клиента будущего».</p> Цифровой рубль перестал быть экспериментом — это новая финансовая реальность, в которой банки вынуждены действовать уже … message https://www.itweek.ru/themes/detail.php?ID=234753 Thu, 30 Apr 2026 11:00:48 +0300 <p><em>Искусственный интеллект не просто ускоряет работу — он её насыщает. Риск заключается не просто в том, что ИИ ошибается. Риск в том, что люди постепенно перестают мыслить независимо, пишут в корпоративном блоге Ким Херрингтон, старший аналитик </em><em>Forrester</em><em>, и Фиона Марк, главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Недавно Джейми Боно, старший инженер по данным и главный консультант EmergenceTek Group, упомянул новый термин «когнитивный суверенитет», который он определил как «способность сохранять независимое мышление и самостоятельность в средах, насыщенных результатами, генерируемыми ИИ». По его словам, сейчас как никогда важно, чтобы люди, участвующие в процессе, развивали и защищали его.</p> <p>Это не философский вопрос — это вопрос оперативного характера — мы должны защищать способность думать, принимать решения и вмешиваться.</p> <p>Аналогично, педагог Келси Померой недавно выпустила <a href="https://www.instagram.com/reel/DPCTlkZgUZ0">короткое видео</a>, в котором переосмысливает подход взрослых к разговорам с детьми об ИИ. Вместо того чтобы начинать с морали — «ИИ — это обман», «плагиат — это плохо» — она утверждает, что мы должны начинать с защиты функций мозга. Ее метафора простая и запоминающаяся: представьте свои когнитивные навыки как набор цветов маркеров. Когда вы учитесь, вы должны практиковаться в использовании этих цветов. Если ИИ делает эту работу за вас, вы не просто экономите время — вы теряете доступ к самим цветам. Тем временем другие продолжают развивать полную палитру — целый солнечный закат.</p> <p>Ее послание студентам прямолинейно: вы должны защищать свое видение заката любой ценой.</p> <p>Такой подход отбрасывает моральные суждения и фокусируется на возможностях. Причина, по которой мы не полагаемся на ИИ во время обучения, заключается не в том, что он «плох». А в том, что он незаметно ослабляет те самые когнитивные мышцы, на которые мы будем полагаться позже.</p> <h3>Скрытый режим неудачи при внедрении ИИ</h3> <p>Большинство ИИ-стратегий оптимизированы для скорости, масштабируемости и эффективности. Очень немногие учитывают, что происходит, когда люди начинают делегировать свои суждения:</p> <ul> <li> Когда ИИ дает вам ответ, но вы не можете объяснить лежащие в его основе предположения.</li> <li> Когда решение принимается на основе краткого изложения — без учета базовых данных, определений или крайних случаев.</li> <li> Когда «так сказала модель» становится автоматическим фактором риском.</li> </ul> <p>Со временем это подрывает когнитивный суверенитет — способность человека задавать вопросы, контекстуализировать, вмешиваться и, в конечном итоге, брать на себя ответственность за результаты. Внедрение ИИ не терпит громкого провала. Оно терпит тихий провал, когда люди перестают оспаривать результаты, которые кажутся правильными.</p> <h3>Грамотность в работе с данными — основа когнитивного суверенитета</h3> <p>Когнитивный суверенитет начинается не с промпт-инжиниринга. Он начинается с грамотности в работе с данными, которую Forrester определяет как способность распознавать, анализировать, передавать и применять данные в контексте решений и результатов. Модель ACES (awareness, comprehension, expertise, scale — осведомленность, понимание, экспертиза, масштабирование) — предоставляет практическую основу для развития этой способности в масштабах всего предприятия.</p> <p>В условиях насыщенной ИИ среды руководителям необходимо развивать:</p> <ul> <li><strong> Осведомленность: </strong>прежде чем доверять результатам, задайте себе вопрос: «Что было введено?».</li> <li><strong> Понимание: </strong>проверяйте логику с помощью быстрых тестов — ищите недостающий контекст.</li> <li><strong> Экспертизу:</strong> умейте оспаривать результаты, исправлять входные данные и оставлять след, который может проверить кто-то другой.</li> <li><strong> Масштабирование:</strong> сделайте эти действия «обычной практикой» для всех.</li> </ul> <p>Без этих возможностей ИИ не дополняет суждения — он незаметно заменяет их.</p> <h3>«Люди в цикле» защищают суждения, когда ИИ дает сбой</h3> <p>Одной лишь грамотности в работе с данными недостаточно. Организациям также необходимы целенаправленные роли людей, встроенные в рабочие процессы ИИ — то, что Forrester называет «люди в цикле» (humans in the loop, HITL).</p> <p>На практике HITL не просто одобряют результаты; они выявляют категориальные ошибки, указывают на то, чего модель не видит, и нажимают кнопку паузы, прежде чем автоматизация превратится в инцидент. Это наиболее важно, когда:</p> <ul> <li> Результат звучит уверенно — но он рушится под воздействием одного хорошего уточняющего вопроса.</li> <li> Рекомендация оптимизирует метрику, нарушая при этом правило, норму или обещание.</li> <li> Рабочий процесс достаточно быстр, чтобы опередить ответственность.</li> </ul> <p>Исследование влиянии ИИ на рабочие места подтверждает эту реальность: хотя ИИ может автоматизировать значительную часть задач, человеческое суждение, обработка исключений и ответственность не исчезают — они становятся более важными. Организации, которые не инвестируют в эти возможности, создают системы, которые эффективны, но хрупки.</p> <h3>Грамотность в работе с данными — это то, как люди становятся эффективными HITL</h3> <p>Люди не становятся волшебным образом хорошими HITL-специалистами. Они развивают эту роль, приобретая уверенность, любознательность и компетентность, чтобы оспаривать как данные, так и выводы машин. Когнитивный суверенитет возникает, когда организации ожидают, что люди будут задавать вопросы ИИ, а не подчиняться ему.</p> <p>Спросите свою команду:</p> <ul> <li> Кто отвечает за то, чтобы сказать: «Подождите — покажите мне, как мы это получили» (и когда они вмешиваются)?</li> <li> Где люди должны вмешиваться — и где они уже это делают?</li> <li> Могут ли люди объяснить, почему была сделана та или иная рекомендация, или мы просто копируем и вставляем то, что получаем?</li> <li> Развиваем ли мы независимое мышление или масштабируем принцип «Конечно, что бы ни сказал бот»?</li> </ul> <p>Если ваша стратегия в области ИИ предполагает, что люди «просто справятся», она уже уязвима.</p> Искусственный интеллект не просто ускоряет работу — он её насыщает. Риск заключается не просто … article https://www.itweek.ru/themes/detail.php?ID=234751 Thu, 30 Apr 2026 10:35:25 +0300 <p><em>В конце <nobr>2025-го —</nobr> начале 2026 года мировые выставочные площадки для систем безопасности вновь подтвердили: отрасль переживает фундаментальную трансформацию. Крупнейшие выставки — Intersec в Дубае, CPSE в Шэньчжэне, ISC West в Лас-Вегасе, SICUR в Мадриде, а также региональные мероприятия в России, Беларуси и Саудовской Аравии — стали полигоном для демонстрации технологий, которые окончательно стирают границы между физической и кибербезопасностью, превращают «железо» в программно-определяемые сервисы и выводят безопасность в разряд бизнес-инструментов.</em></p> <h2>Основные тенденции: от пассивной фиксации к активному управлению</h2> <p>Анализ экспозиций и деловой программы ведущих выставок позволяет выделить несколько сквозных направлений, которые будут определять развитие индустрии в ближайшие годы.</p> <h3>Видеонаблюдение и видеоаналитика</h3> <p>Центральным трендом стало массовое внедрение <strong>Edge AI</strong> — камер со встроенными нейросетями, способными распознавать лица, объекты, аномалии поведения без передачи данных в облако. Это снижает нагрузку на сети и задержки, одновременно повышая конфиденциальность. Производители делают акцент на гибкости: аналитические модули можно обновлять удалённо, добавляя новые сценарии — от детекции оружия и контроля средств индивидуальной защиты до выявления падений или забытых предметов.</p> <p>Видеопотоки всё теснее интегрируются с другими подсистемами — СКУД, радарами, дронами, системами кибербезопасности. Формируется единая картина угроз, где видео выступает не пассивным источником записи, а активным сенсором.</p> <p>Особый интерес вызвали тепловизионные и дальнобойные решения для периметральной охраны критической инфраструктуры: ряд представленных образцов обеспечивают обнаружение объектов на дистанциях до 46 км. Одновременно растёт спрос на <strong>бизнес-аналитику на основе видео</strong> — системы помогают не только охранять объект, но и анализировать трафик посетителей, оптимизировать логистические процессы, формировать отчётность по охране труда и ESG-показателям.</p> <blockquote> <p><em>Видеонаблюдение перестало быть «архивом на всякий случай». На смену модели «установил и забыл» приходит концепция постоянно обучаемой системы, где камеры получают новые интеллектуальные функции в течение всего жизненного цикла.</em></p> </blockquote> <h3>Контроль доступа и биометрия</h3> <p>Рынок контроля доступа движется от «устройства» к «сервису идентичности». Бесконтактная биометрия (лицо, ладонь, радужка) становится стандартом для мест с высокой проходимостью, обеспечивая гигиеничность и скорость прохода.</p> <p>Ключевая инновация — <strong>мобильные учётные данные</strong>: смартфоны с BLE/NFC заменяют традиционные карты, а права доступа выдаются динамически через облачные платформы. Это тесно связано с развитием PIAM-платформ (Physical Identity and Access Management), которые связывают HR, ИТ-системы и физический доступ в единую модель цифровой идентичности. Такая архитектура позволяет автоматизировать процесс назначения и отзыва прав, управлять гостями и подрядчиками, а также адаптивно оценивать риски (адаптивная аутентификация с учётом контекста, местоположения, поведения).</p> <blockquote> <p><em>Поставщики всё чаще предлагают не просто считыватели, а платформы управления цифровыми удостоверениями, интегрированные с HR и облачными каталогами. Это меняет финансовую модель — заказчик платит за количество управляемых идентичностей, а не за каждый контроллер.</em></p> </blockquote> <h3>Пожарная безопасность и системы оповещения</h3> <p>В области пожарной безопасности главным запросом стало <strong>снижение ложных тревог</strong>. Интеллектуальные приёмно-контрольные приборы с AI-фильтрацией и автоматической маршрутизацией событий, а также системы, коррелирующие сигналы ПС с видео, становятся обязательным элементом крупных объектов.</p> <p>Параллельно развиваются беспроводные и адресные системы с самодиагностикой — они упрощают монтаж и обслуживание, особенно на исторических или сложных в планировке объектах.</p> <p>Важнейший тренд — <strong>интеграция с эвакуационными сценариями</strong>. Системы пожарной сигнализации, контроля доступа, лифтов и голосового оповещения объединяются в единую платформу: при тревоге автоматически разблокируются эвакуационные выходы, лифты возвращаются на первый этаж, а голосовые сообщения направляют людей по безопасным маршрутам.</p> <p>Отдельное направление — <strong>киберзащищённые протоколы связи</strong> между извещателями и панелями: шифрование и аутентификация предотвращают возможность саботажа через сеть.</p> <h3>Интеграционное ПО и PSIM-платформы</h3> <p>Спрос на единые платформы безопасности (PSIM, ССОИ) продолжает расти. Заказчики хотят управлять видео, доступом, периметром и пожарными системами через единый интерфейс, а ключевым критерием выбора становится <strong>открытость</strong> — поддержка ONVIF, наличие REST API, возможность интеграции со смежными системами (BMS, ERP, WMS).</p> <p>Гибридные облачные архитектуры (on-premise + cloud) позволяют сохранить критическую обработку локально, а аналитику, отчётность и управление пользователями вынести в облако. Это даёт возможность предлагать подписочные модели и регулярно обновлять функциональность без замены оборудования.</p> <p>Наиболее продвинутые платформы используют <strong>AI-оркестрацию событий</strong>: автоматическая корреляция инцидентов из разных подсистем, приоритизация угроз и запуск предопределённых сценариев реагирования без участия оператора.</p> <blockquote> <p><em>Ценность смещается от отдельных устройств к программному слою, который объединяет их в единый «организм». Открытые API и поддержка ONVIF становятся обязательным требованием для заказчиков, которые хотят избежать вендор-локина.</em></p> </blockquote> <h3>Конвергенция физической и информационной безопасности</h3> <p>Стирание границ между ИТ- и физическими системами — один из самых ярких трендов. Кибератака на IP-камеру или контроллер доступа может стать точкой входа для компрометации всей сети предприятия, а физический взлом серверной — дать доступ к критическим данным.</p> <p>На выставках активно обсуждались решения, реализующие <strong>принципы Zero Trust для физических систем</strong>: строгая аутентификация устройств, сегментация сетей, шифрование трафика, регулярный аудит уязвимостей. Появились специализированные продукты для защиты OT-инфраструктуры (операционных технологий), где физические и киберугрозы пересекаются наиболее плотно.</p> <p>Новые европейские директивы (NIS 2, CER) и ужесточение требований к защите персональных данных (GDPR) ускоряют внедрение защищённых и аудируемых решений. Всё большее значение приобретает безопасность учётных данных: шифрование, динамические ключи, детальный аудит доступа.</p> <blockquote> <p><em>Граница между физической и информационной безопасностью окончательно стирается. Это требует единой киберфизической архитектуры, где защита камер и контроллеров рассматривается как неотъемлемая часть общей стратегии кибербезопасности.</em></p> </blockquote> <h2>Региональные особенности: спрос диктует условия</h2> <table> <thead> <tr> <th> Регион</th> <th> Специфические тренды</th> </tr> </thead> <tbody> <tr> <td> <strong>Китай</strong></td> <td> Акцент на AIoT-интеграцию, умные города, массовое производство OEM-решений и экспорт технологий. Тесная связь стартапов с экосистемами Huawei, Tencent, Alibaba Cloud.</td> </tr> <tr> <td> <strong>Ближний Восток</strong></td> <td> Фокус на защиту критической инфраструктуры, нефтегазового сектора и мега-проектов. Высокий спрос на дальние тепловизионные системы и автономные периметральные решения.</td> </tr> <tr> <td> <strong>Европа</strong></td> <td> Приоритет GDPR-совместимости, устойчивости (resilience) и соответствия новым директивам (NIS 2, CER). Сильные позиции у стартапов в области IoT-пожарной безопасности и AI для ритейла.</td> </tr> <tr> <td> <strong>США</strong></td> <td> Лидерство в AI-аналитике, облачных VMS, конвергентных решениях. Развитая образовательная программа по киберфизической безопасности, активные венчурные инвестиции в edge-AI и биометрию.</td> </tr> <tr> <td> <strong>Россия и СНГ</strong></td> <td> Импортозамещение, развитие отечественных PSIM/ССОИ-платформ, акцент на госстандарты и защиту критической инфраструктуры. Востребованы решения с автономностью и резервированием.</td> </tr> </tbody> </table> <h2>Прогноз на <nobr>2026-2027 гг.</nobr></h2> <ol> <li><strong>Доминирование software-defined security. </strong>Ценность смещается от «железа» к ПО, аналитике и подписочным моделям. Производители будут активнее предлагать функциональность, которая активируется программно, а системы безопасности станут частью единого цифрового ландшафта предприятия.</li> <li><strong>Рост edge-вычислений. </strong>Рынок edge computing в безопасности продолжит расти двузначными темпами. Обработка данных на периферии снижает задержки, экономит трафик и повышает конфиденциальность, что критически важно для объектов с ограниченной пропускной способностью и для сценариев, требующих мгновенной реакции.</li> <li><strong>Унификация идентичности. </strong>PACS (системы контроля доступа) превращаются в «операционную систему» умного здания, управляя не только доступом, но и освещением, климатом, логистикой. PIAM-платформы будут интегрироваться с HR, ИТ и бизнес-приложениями, обеспечивая единый жизненный цикл цифровой идентичности сотрудника.</li> <li><strong>Регуляторное давление. </strong>Новые стандарты (NIS 2, CER, GDPR, а также отраслевые требования в разных странах) ускорят внедрение защищённых и аудируемых решений. Производители будут обязаны доказывать соответствие требованиям кибербезопасности на уровне устройств и протоколов.</li> <li><strong>Устойчивость как KPI. </strong>Эффективность системы безопасности будет оцениваться не по количеству установленных камер, а по способности предотвращать инциденты, минимизировать ложные тревоги и быстро восстанавливаться после сбоев — будь то атака, отказ оборудования или внештатная ситуация.</li> </ol> <h2>Новые игроки: куда направляются стартапы</h2> <p>Анализ стартап-экосистемы за последние полгода позволяет выделить несколько устойчивых направлений, по которым развиваются инновационные компании в разных регионах.</p> <ul> <li><strong>В Китае</strong> основная масса молодых компаний фокусируется на глубокой интеграции AI и IoT (AIoT) для городских платформ, а также на специализированных чипах для edge-аналитики. Многие стартапы тесно связаны с крупными экосистемами (Huawei, Alibaba, Tencent), что ускоряет вывод продуктов, но ограничивает независимость. Ключевые компетенции — видеоаналитика, умные города, массовое производство OEM-решений.</li> <li><strong>В США</strong> венчурный капитал активно инвестирует в решения для детекции оружия, облачные видеоплатформы, самообучающуюся аналитику (vision-language модели) и автономные дроны для охраны периметра. Отличительная черта — сильная ориентация на подписочные бизнес-модели (SaaS) и открытые API. Также заметен интерес к биометрии с высокими показателями точности в сложных условиях.</li> <li><strong>Израильские стартапы</strong> традиционно делают ставку на dual-use технологии (гражданские и оборонные применения). В зоне их внимания — видеоаналитика поведения, беспроводные каналы связи для безопасности, Zero Trust-доступ, а также инновационные способы изоляции OT-сетей (например, физические шлюзы удалённого доступа без IP). Отдельный кластер составляют компании, управляющие рисками третьих сторон и автоматизирующие инвентаризацию уязвимостей киберфизических систем.</li> <li><strong>В Европе</strong> заметна специализация на решениях для раннего обнаружения пожаров (спутниковый мониторинг, сенсорные сети LoRaWAN), AI для ритейл-безопасности (детекция краж по жестам), а также на кибербезопасности IoT/OT-устройств. Европейские стартапы уделяют повышенное внимание соответствию GDPR и отраслевым директивам.</li> <li><strong>Общая тенденция</strong> — всё больше стартапов позиционируют себя не как производители устройств, а как разработчики программных платформ и сервисов, причём многие используют гибридную архитектуру (облако + локальная обработка) и открытые экосистемы для интеграции с оборудованием разных вендоров.</li> </ul> <h2>Дополнительные выводы по ключевым трендам развития отрасли</h2> <p>Анализ представленных выставок и стартап-активности позволяет выделить несколько глубинных изменений, которые определят развитие индустрии в ближайшие годы.</p> <ol> <li><strong> От продукта к сервису. </strong>Всё больше решений предлагается по подписочной модели, где заказчик платит не за оборудование, а за результат: количество обработанных событий, управляемых идентичностей или подключённых объектов. Это меняет финансовую модель как для интеграторов (регулярный доход вместо разовых сделок), так и для производителей (стимул постоянно улучшать ПО).</li> <li><strong> Постоянное обновление вместо фиксированной функциональности. </strong>Устройства всё чаще проектируются с возможностью «дозагрузки» новых аналитических модулей, сценариев и протоколов. Это позволяет модернизировать систему без замены «железа», продлевая жизненный цикл и снижая совокупную стоимость владения.</li> <li><strong> Данные как источник новой ценности. </strong>Видеопотоки, логи доступа, показания датчиков перестают быть только инструментом безопасности — они превращаются в источник бизнес-аналитики: оптимизация маршрутов, контроль производительности, соблюдение техники безопасности, ESG-отчётность. Безопасность начинает приносить измеримую пользу бизнесу.</li> <li><strong> Ремикс функций: одно устройство — много задач. </strong>Вместо набора специализированных датчиков появляются комбинированные устройства, заменяющие несколько традиционных систем. Это снижает стоимость внедрения, упрощает эксплуатацию и сокращает количество точек отказа.</li> <li><strong> Киберфизическая безопасность как единая дисциплина. </strong>Безопасность больше не делится на «физическую» и «кибер». Поставщики систем контроля доступа и видеонаблюдения обязаны обеспечивать защиту устройств от взлома, сегментацию сетей и соответствие стандартам управления уязвимостями. На первый план выходят архитектурные подходы, объединяющие защиту ИТ, OT и физического периметра.</li> <li><strong> Устойчивость к новым угрозам. </strong>Современные системы безопасности должны быть готовы к сценариям, выходящим за рамки традиционного воровства или хулиганства: целенаправленные кибератаки, использование БПЛА для блокирования подхода помощи, действия высокомотивированных нарушителей. Это требует встроенной автономности, резервирования каналов, физической изоляции критических компонентов и возможности работы в условиях частичной потери инфраструктуры.</li> </ol> <h2>Заключение</h2> <p>Выставки четвёртого квартала <nobr>2025-го —</nobr> первого квартала 2026 года наглядно продемонстрировали, что индустрия инженерных систем безопасности окончательно перешла от эпохи «железа» к эпохе программно-определяемых решений. Главную ценность теперь создают интеллектуальные сервисы, данные и интеграционные платформы.</p> <p>Для участников рынка это означает необходимость пересмотреть стратегии:</p> <ul> <li> <strong>Заказчики</strong> всё чаще выбирают OPEX-модели (подписки, сервисные контракты) и ожидают от поставщиков не просто оборудования, а управляемого результата — снижения ложных тревог, повышения операционной эффективности, защиты от гибридных угроз.</li> <li><strong>Производителям и интеграторам</strong> предстоит сделать ставку на открытые архитектуры, Edge AI, сервисы жизненного цикла и компетенции в области кибербезопасности, которые становятся обязательным элементом любого физического решения.</li> <li><strong>Безопасность</strong> превращается из центра затрат в источник данных для бизнеса, а её эффективность будет оцениваться по способности предотвращать инциденты, минимизировать риски и быстро адаптироваться к новым вызовам.</li> </ul> <p>В ближайшие два года наиболее успешными станут компании, способные предложить комплексные сервисные модели, гибкие программно-определяемые платформы и архитектуры, позволяющие наращивать функциональность без замены установленного оборудования. Время «вечных» проектов без обновлений уходит — на смену приходит эпоха постоянно развивающихся систем безопасности.</p> <p> #IMAGE_234752#</p> В конце 2025-го — начале 2026 года мировые выставочные площадки для систем безопасности вновь подтвердили: отрасль … article Федор Жидомиров, директор «Луис+ Учебный центр», советник генерального директора LUIS+ по техническим вопросам https://www.itweek.ru/themes/detail.php?ID=234749 Thu, 30 Apr 2026 10:24:42 +0300 <p><em>Технический долг в инфраструктуре часто воспринимается как побочный эффект роста. На практике он формируется не из-за ошибок, а как результат последовательных управленческих решений: быстрее запустить сервис, уложиться в бюджет, не затрагивать работающие компоненты. Такие решения оправданы в моменте, но редко учитывают долгосрочные последствия. В результате архитектура не пересматривается, а наращивается. Система превращается в набор взаимосвязанных компонентов, где любое изменение затрагивает сразу несколько уровней, а стоимость и сложность изменений начинают расти быстрее самой инфраструктуры. До определенного момента это не влияет на эксплуатацию, но становится критичным при развитии. Рассмотрим, как технический долг начинает ограничивать бизнес и как выстраивать модернизацию без риска для текущих сервисов<strong>.</strong></em></p> <h3>Когда стабильность вводит в заблуждение: как технический долг блокирует изменения</h3> <p>В инфраструктуре технический долг редко проявляется сразу. Долгое время система может работать стабильно, укладываться в SLA и не вызывать серьезных опасений. Проблемы становятся заметны позже — в тот момент, когда бизнес требует изменений: масштабирования, запуска новых сервисов или внедрения новых технологий. Именно тогда выясняется, что за внешней стабильностью скрываются ограничения: компоненты жестко связаны между собой, версии несовместимы, а изменение одного элемента требует доработки сразу нескольких других. В результате ИТ-функция начинает сдерживать изменения, поскольку любое вмешательство несет риск сбоев. На практике это выглядит так: попытка изменить один сервис тянет за собой доработку сразу нескольких систем — из-за связок по версиям, интеграциям и устаревшим зависимостям, которые становятся видны только в момент изменений.</p> <p>При этом даже без явных инцидентов инфраструктура может находиться в зоне повышенного риска. Это проявляется в повседневной эксплуатации: регламентные операции начинают занимать кратно больше времени — например, резервное копирование, ранее выполнявшееся за часы, растягивается на сутки и более; изменения возможны только в узкие окна обслуживания и нередко требуют полной остановки сервисов; появляются ручные сценарии и нестандартизированные процедуры восстановления; критическая экспертиза концентрируется у отдельных специалистов; даже незначительные доработки превращаются в отдельные проекты. В некоторых случаях система начинает требовать неформализованных действий — последовательности ручных операций, которые известны только отдельным специалистам. Формально система продолжает работать, но фактически теряет управляемость и устойчивость к изменениям.</p> <p>Именно в этой точке технический долг начинает влиять не только на стабильность, но и на экономику бизнеса. Рост затрат на эксплуатацию становится лишь частью проблемы. Основные потери возникают из-за снижения скорости: откладываются новые сервисы и продукты, усложняется тестирование гипотез, замедляется внедрение технологий. Любое изменение требует предварительной «расчистки» инфраструктуры — перераспределения ресурсов, освобождения мощностей, временных ограничений функциональности. Например, перед запуском нового сервиса команде приходится вручную освобождать ресурсы — переносить нагрузки, отключать часть функций или откладывать другие задачи. В результате компания начинает проигрывать конкурентам не из-за отказов, а из-за неспособности быстро меняться.</p> <h3>Приоритизация и сценарии модернизации: от выбора точек к стратегии изменений</h3> <p>Приоритизация модернизации часто строится по формальному принципу — заменять наиболее устаревшие компоненты. На практике такой подход не работает. Ключевым критерием становится не степень износа, а влияние на развитие инфраструктуры и бизнеса.</p> <p>В первую очередь внимания требуют те элементы, которые ограничивают изменения: системы, не поддерживающие современные протоколы и не позволяющие запускать новые сервисы; интеграционные решения, которые не масштабируются вместе с нагрузкой; дефицит ресурсов — например, в системах хранения, — делающий невозможным запуск новых проектов. Если приоритизация не связана с планами бизнеса, она быстро превращается в реакцию на инциденты, а не в инструмент развития.</p> <p>Выбранные приоритеты напрямую определяют и подход к модернизации.</p> <ol> <li> <strong>Поэтапная модернизация.</strong> Возможна при слабой связности компонентов. Позволяет минимизировать риски, но встречается редко.</li> <li> <strong>Параллельный контур.</strong> Создание новой инфраструктуры с последующей миграцией сервисов. Требует значительных инвестиций, но обеспечивает управляемость и снижает риски.</li> <li> <strong>Точечная модернизация.</strong> Наиболее распространенный сценарий. Предполагает замену отдельных компонентов с минимальным влиянием на систему, но часто приводит к эффекту «догоняющего обновления».</li> </ol> <h3>Основные риски проектов модернизации</h3> <p>Ключевые проблемы в проектах модернизации, как правило, проявляются уже в процессе реализации. В первую очередь это несовместимость старых и новых компонентов: при замене отдельных элементов на стыке систем возникают неожиданные эффекты, влияющие на производительность и стабильность. Ситуацию усугубляет отсутствие проработанного сценария отката — при отклонении от плана становится сложно вернуть систему в исходное состояние без последствий для сервисов.</p> <p>Дополнительный риск связан с недостаточной квалификацией команды: специалисты хорошо знают текущую инфраструктуру, но не всегда готовы к эксплуатации новых решений, что увеличивает вероятность ошибок и время восстановления. При этом модернизация нередко проводится локально, без учета системных зависимостей, из-за чего изменения на одном участке вызывают проблемы на других. Например, модернизация одной системы может привести к сбоям в смежных сервисах, которые изначально не учитывались в проекте.</p> <p>Отдельным фактором становится сопротивление эксплуатационных команд, связанное с переходом на новые технологии и процессы. В совокупности это приводит к ситуации, когда модернизация, направленная на снижение технического долга, временно повышает сложность и нестабильность инфраструктуры.</p> <h3>Роль ИТ-директора и требования к подрядчику</h3> <p>В проектах модернизации ИТ-директору приходится одновременно решать две задачи — сохранять стабильность текущих сервисов и обеспечивать готовность инфраструктуры к изменениям. Поэтому ключевая часть его работы — не столько согласование решений, сколько постановка правильных вопросов на старте проекта.</p> <p>В первую очередь речь идет о границах изменений: какую часть инфраструктуры можно модернизировать без остановки сервисов и какие технологические окна потребуются. Не менее важен вопрос готовности команды — хватит ли текущей экспертизы для перехода на новые решения и последующей эксплуатации или потребуется дополнительная подготовка специалистов. Далее оцениваются зависимости: какие системы будут затронуты и как изменения в одном компоненте повлияют на остальные. Отдельно ИТ-директор должен понимать, насколько инфраструктура устойчива во времени — что произойдет, если проект затянется, и сможет ли система в текущем состоянии проработать еще несколько месяцев или кварталов без критических последствий.</p> <p>Логично продолжает этот блок оценка самого проекта: предусмотрены ли тестовый контур и сценарий отката, что произойдет, если подрядчик не выполнит работы в срок, и есть ли альтернативные варианты действий. Именно такие вопросы позволяют увидеть не только техническую сторону модернизации, но и реальные риски для бизнеса.</p> <p>При этом значительная часть этих вопросов должна исходить не только от ИТ-директора, но и от подрядчика. Если интегратор ограничивается общими формулировками и не уточняет детали, это сигнал о слабой проработке решения. Зрелый партнер действует иначе: сам выявляет ограничения, поднимает неудобные темы, проговаривает сценарии сбоев и отката, фактически помогая заказчику увидеть те риски, которые на старте неочевидны.</p> <h3>Заключение. Чем отличаются компании с системным подходом</h3> <p>Именно на этапе ответов на такие вопросы становится заметна разница между подходами. В одних компаниях модернизация — это разовая реакция на накопленные проблемы. В других — регулярный процесс, который управляется заранее.</p> <p>Компании, работающие с техническим долгом системно, рассматривают его как отдельный показатель — наравне с доступностью сервисов или стоимостью эксплуатации. Это означает, что решения принимаются не по отдельным компонентам, а с учетом их влияния на всю инфраструктуру.</p> <p>В основе такого подхода — актуальная модель системы и зависимостей, которая не пересобирается под каждый проект, а поддерживается постоянно. Модернизация закладывается в бюджет как регулярная статья, а не зависит от остаточного финансирования. Решения принимаются на основе данных: динамики нагрузки, стоимости поддержки и влияния на изменения.</p> <p>Критический момент — экономика замены. Поддержка устаревших решений со временем начинает обходиться дороже, чем их обновление — за счет роста времени операций, ограничения изменений и накопления рисков. Это проявляется не только в прямых расходах, но и в косвенных — увеличении времени операций, усложнении изменений и росте зависимости от отдельных специалистов. Компании, которые фиксируют этот момент заранее, избегают сценария резкой и дорогостоящей модернизации.</p> <p>В итоге инфраструктура не становится проще, но остается предсказуемой: изменения можно планировать, риски — контролировать, а развитие бизнеса не упирается в технические ограничения.</p> <p> #IMAGE_234750#</p> Технический долг в инфраструктуре часто воспринимается как побочный эффект роста. На практике он формируется … article Владимир Кудряшов, директор сервисного департамента компании “ГИГАНТ Компьютерные системы” https://www.itweek.ru/themes/detail.php?ID=234748 Wed, 29 Apr 2026 16:50:50 +0300 <p>Разработчик экосистемы инфраструктурного ПО для Enterprise-бизнеса Orion soft выпустил масштабное обновление своего флагманского продукта по виртуализации zVirt 5.0. Решение перевели на новую минималистичную гипервизорную ОС собственной сборки, повысив его стабильность, производительность и безопасность. Также в zVirt добавили возможность живой миграции виртуальных машин между центрами данных, планировщик задач виртуальных машин по расписанию, усовершенствовали функциональность SDN.</p> <p>Крупнейшим обновлением в истории системы стал переход на новую гипервизорную платформу zVirt Node 2.0, специально разработанную под задачи системы виртуализации. Она собрана на базе менеджера пакетов RPM и отличается обновленным системным стеком, «облегченной» архитектурой и уменьшенным объемом кода. Новая платформа обеспечивает контроль над составом системы, версиями компонентов и процессом обновления.</p> <p>«В zVirt Node 2.0 мы оставили только те пакеты, которые необходимы непосредственно для работы виртуализации. Это легковесный гипервизор, который можно ставить прямо на „железо“, чтобы получить более стабильную и предсказуемую работу системы, адаптированную под задачи виртуализации. По такому же принципу VMware строила свой гипервизор ESXi. Кроме того, за счет уменьшенного объема кода повышается защищенность решения, так как сокращается площадь потенциальной атаки», — объяснил Максим Березин, директор по развитию бизнеса Orion soft.</p> <p>В релизе 5.0 также появилась значимая для работы крупных инфраструктур функция миграции виртуальных машин между различными центрами данных. Она работает даже в случае, когда у центров нет общего хранилища данных. Миграция доступна как в онлайн-режиме — до двух виртуальных машин одновременно, так и в офлайн-режиме — до 32 объектов одновременно. В результате этого обновления zVirt закрыла все возможные сценарии миграции виртуальных машин, которые раньше предоставляла VMware.</p> <p>В системе также доработали планировщик задач виртуальных машин по расписанию. Он позволяет автоматизировать рутинные операции, такие как запуск, выключение и перезагрузка виртуальных машин, создание и удаление снимков. Управление планированием происходит через понятный для администраторов веб-интерфейс Hosted Engine.</p> <p>В обновление 5.0 разработчик включил также дополнительные возможности SDN: балансировка трафика на уровнях L3-L4, поддержка протокола BGP для динамической маршрутизации, поддержка трансляции портов на логическом маршрутизаторе. Эти функции обеспечивают сокращение накладных расходов при обработке трафика, высокую отказоустойчивость, гибкость и доступность виртуальной сетевой инфраструктуры.</p> <p>Orion soft продолжает развивать zVirt как решение, которое закрывает комплекс инфраструктурных задач. В 2026 году у платформы появится собственный встроенный инструмент для резервного копирования и функциональность для работы с программно-определяемыми хранилищами (SDS), которая позволит строить гиперконвергентные инфраструктуры. Также разработчик выпустит zVirt Special Edition — сертифицированную ФСТЭК редакцию платформы, максимально приближенную по функциональности к коммерческой версии.</p> Разработчик экосистемы инфраструктурного ПО для Enterprise-бизнеса Orion soft выпустил масштабное обновление своего … message https://www.itweek.ru/themes/detail.php?ID=234747 Wed, 29 Apr 2026 16:47:23 +0300 <p>BSS и НТЦ АРГУС провели вебинар «Триединство технологий: Как AI-аналитика речи и WFM (система управления персоналом) создают идеальный контакт-центр нового поколения».</p> <p>Около 70 представителей контакт-центров собрались послушать, как эффективнее планировать работу с помощью ИИ-анализа и данных из системы управления персоналом. Об этом рассказали Product Owner системы Речевая Аналитика в БСС ИИ Анна Ивлева и Руководитель направления WFM CC в НТЦ АРГУС Никита Городчиков. </p> <p>НТЦ Аргус — ведущий разработчик системы управления персоналом, с которым BSS объединила технологии и создает единый комплекс оптимизации персонала.</p> <p>Эксперты обозначили новые ориентиры в клиентском сервисе и управлении персоналом — и рассказали, как связка речевой аналитики и WFM помогает их достичь. </p> <p>Так, технологии позволяют глубже понять потребности клиентов, выявить точки роста и определить, какие запросы нужно автоматизировать, а также выстроить график, который будет оптимальным и для оператора, и для контакт-центра. </p> <p>Спикеры продемонстрировали три примера, как использовать речевую аналитику и WFM-данные для повышения эффективности контакт-центра и благополучия сотрудников. </p> <p>Анализ коммуникаций покинувших компанию сотрудников показал: примерно за месяц до ухода поведение сотрудника меняется. В оценке учитываются речевые особенности — например, инсайт-режим выявил, что выгоревшие операторы чаще используют формулировки вроде «я просто оператор». Кроме того, анализируются данные WFM (график, стаж работы, опоздания) и показатели эффективности (AHT, процент тишины и другие).</p> <p>Исследование включало анализ данных WFM о формате работы и анализ речевых паттернов — например, изучались реакции оператора на негатив со стороны клиентов. Оказалось, что удаленные сотрудники более лояльны компании по сравнению с офисными коллегами.</p> <p>На основе метрик эффективности, уровня выгорания, удовлетворенности клиентов и данных WFM о графике работы сотрудника система может предсказать, сколько диалогов в месяц обработает конкретный оператор. Это помогает более точно планировать работу контакт-центра и распределять сотрудников по каналам с учетом их сильных сторон.</p> <p>При корректной постановке задачи и понимании бизнес-контекста инсайты можно получить всего за <nobr>10–15 минут.</nobr></p> <p>Участники активно обсуждали подходы к управлению персоналом и организации аналитических процессов. Так выяснилось, что одновременно речевую аналитику и WFM-систему использует лишь каждая шестая компания, а еще 40% пока планируют их внедрить. Более половины применяют хотя бы одну из систем, но при оценке выгорания многие по-прежнему опираются на HR-опросы и ручную аналитику. </p> BSS и НТЦ АРГУС провели вебинар «Триединство технологий: Как AI-аналитика речи и WFM (система управления персоналом … message https://www.itweek.ru/themes/detail.php?ID=234743 Wed, 29 Apr 2026 09:58:21 +0300 <p><em>Недавно мы опубликовали отчет «</em><em>Advocating</em> <em>For</em> <em>Revenue</em> <em>Enablement</em><em>: </em><em>A</em> <em>Practitioner</em><em>’</em><em>s</em> <em>Guide</em> <em>To</em> <em>Executive</em> <em>Communications</em><em>», основанный на знакомом разочаровании: команды по обеспечению бизнеса (</em><em>revenue</em> <em>enablement</em><em>) постоянно приносят пользу, но испытывают трудности с завоеванием устойчивого влияния на высшее руководство. Однако эта проблема не уникальна: один из ближайших функциональных партнеров уже справился с ней, пишет в корпоративном блоге Питер Остроу, вице-президент и главный аналитик </em><em>Forrester</em><em>.</em></p> <p>Десять лет назад ИТ-безопасность столкнулась с аналогичной проблемой. Эта работа была важной, глубоко оперативной и в значительной степени незаметной, если выполнялась хорошо. Команды безопасности привлекались к обсуждениям с руководством только после того, как что-то пошло не так, и это было далеко не весело. Изменилась не важность безопасности, а то, как соответствующие руководители научились отстаивать интересы этой функции на высоком ровне. Функция обеспечения бизнеса может извлечь уроки из этой эволюции.</p> <h3>Урок номер один: профилактика создает ценность, но не обеспечивает влияние</h3> <p>На ранних этапах команды безопасности фокусировались на действиях: устранение уязвимостей, мониторинг систем, предотвращение инцидентов. Все они были важны, но ни одно из них не было достаточно впечатляющим для руководителей, решающих, куда инвестировать дальше. Лидеры в области безопасности поняли, что одной лишь профилактики, хотя она и ценна, недостаточно для привлечения внимания руководства. Влияние службы безопасности проявилось только тогда, когда она начала переводить свою работу на язык, который был важен для руководителей: бизнес-риски, компромиссы и уязвимости: не «Сколько угроз было заблокировано?», а «Что произойдет, если мы не будем действовать?».</p> <p>Функция обеспечения бизнеса часто попадает в ту же ловушку. Эти команды демонстрируют реализованные программы, развернутый контент, пройденные сертификации или внедренные инструменты. Но, как показывают наши исследования, руководители не вознаграждают за объем; они реагируют на актуальность. Функция обеспечения бизнеса привлекает внимание, когда она связывает свою работу с результатами, за которые руководители уже несут ответственность, такими как продуктивность продавцов, риски выполнения, поведенческая стагнация, плохое управление изменениями и стоимость бездействия.</p> <h3>Урок номер два: зрелые функции балансируют между операционным совершенством и стратегическим прогнозированием</h3> <p>Современные лидеры в области ИТ-безопасности понимают важность баланса. Примерно 80% их усилий направлены на фундаментальные и превентивные задачи: поддержание стабильности систем, обеспечение соблюдения стандартов, снижение известных рисков. Эта работа является обязательной и необходимой. Но оставшиеся 20% — это то, что обеспечивает им место за столом переговоров. Они предвидят возникающие угрозы, консультируют по вопросам будущих инвестиций и помогают высшему руководству понимать риски, которые еще не отображаются на панели мониторинга. Влияние службы безопасности заключается не в более быстрой реакции, а в помощи бизнесу предвидеть будущие события.</p> <p>Функция обеспечения бизнеса уже преуспевает в этих фундаментальных 80%: адаптация новых сотрудников, постоянное привлечение новых сотрудников, укрепление навыков и выполнение программ. Возможность — и урок, извлеченный из опыта службы безопасности, — заключается в целенаправленном инвестировании в оставшиеся 20%. Это включает в себя прогнозирование изменений в поведении покупателей, подготовку продавцов к новым тенденциям до того, как их эффективность снизится, и консультирование руководителей о том, что потребуется для «хороших» продаж в следующем году. Функция обеспечения бизнеса не станет влиятельной, отказавшись от своей сервисной роли. Она обеспечит влияние, дополнив выполнение задач способностью к прогнозированию.</p> <h3>Урок номер три: поддержка приходит благодаря вкладу, а не благодаря видимости</h3> <p>Служба безопасности не приобрела значимость для руководителей, просто прося приглашать её на важные совещания. Она заслужила своё место, сделав руководителей более компетентными в принятии решений. Со временем CISO перешли от уведомления об инцидентах к консультированию по стратегии, помогая руководителям взвешивать скорость и риск, а также инновации и потенциальные риски.</p> <p>Функция обеспечения бизнеса сталкивается с тем же выбором. Ожидание ежеквартальных обзоров результатов или бюджетных циклов для обоснования проделанной работы редко способствует укреплению влияния. Как отмечается в нашем отчете, руководители, занимающиеся обеспечением бизнеса и вносящие свой вклад на более ранних этапах, представляя свои инсайты как исходные данные для планирования и принятия решений, переводят разговор с атрибуции на доверие. Как выразился Бен Пуртон, старший менеджер Zoom по развитию бизнеса в сфере выхода на международный рынок, «без атрибуции мы теряем прозрачность. А без прозрачности развитие бизнеса сокращается в трудные времена». Урок из сферы безопасности ясен: для продвижения нужно не просить о внимании, а быть полезными в процессе принятия решений.</p> <h3>Доверие руководства создаётся, а не запрашивается</h3> <p>Функции обеспечения бизнеса не обязательно превращаться в службу ИТ-безопасности, чтобы извлечь ее уроки. Однако эволюция безопасности предлагает мощный план действий: выйти за рамки обычной активности, сбалансировать профилактику с прогнозированием и вовлечь руководителей в обсуждение вопросов, которые им необходимо учитывать, чтобы не возникли проблемы.</p> <p>Путь вперед заключается не в усилении отчетности или расширении видимости. Он заключается в более четкой актуальности, основанной на результатах, согласованной с приоритетами руководства и ориентированной на помощь бизнесу в достижении успеха завтра, а не просто на объяснение того, что произошло вчера. Именно так зарабатываются влияние.</p> Недавно мы опубликовали отчет «Advocating For Revenue Enablement: A Practitioner’s Guide To Executive … article https://www.itweek.ru/themes/detail.php?ID=234741 Wed, 29 Apr 2026 09:49:53 +0300 <p>После ухода SAP с российского рынка перед компаниями встал вполне прагматичный вопрос: что делать с уже внедренными системами. Ожидания были понятны — быстрый переход на альтернативы, постепенный отказ от SAP. Но прошло почти четыре года, и реальность оказалась куда более сдержанной: массового перехода не случилось, и SAP по-прежнему остается ядром ключевых бизнес-процессов во многих компаниях.</p> <p>Это означает только одно — вопрос поддержки никуда не делся, более того, с каждым годом он становится все острее. Если в функциональной части специалистов на рынке еще достаточно, то в технической, базисной поддержке постепенно формируется дефицит, и именно эта часть сегодня начинает напрямую влиять на устойчивость системы.</p> <p>На первый взгляд все может выглядеть стабильно: пользователи работают, процессы идут, финансовые периоды закрываются, зарплата начисляется, товары отгружаются, закупки осуществляются — система жива. Но проблема SAP сегодня в том, что риски накапливаются не сразу, а постепенно, и часто остаются незаметными до первого серьезного сбоя. Это создает опасную иллюзию: кажется, что система работает нормально, хотя внутри уже формируется набор уязвимостей и ограничений, которые в какой-то момент проявятся одновременно.</p> <h3>Факторы, которые формируют риски</h3> <ul> <li><strong>Один из ключевых факторов — безопасность. </strong>SAP продолжает выявлять уязвимости как в HANA, так и в ABAP-коде, и даже изолированные системы не защищены полностью: внутренние утечки и атаки остаются реальной угрозой.</li> <li><strong>Второй фактор — обновления. </strong>Патчи продолжают выходить, но их получение и применение становятся отдельной нетривиальной и часто трудозатратной задачей, которую откладывают, чтобы не трогать «работающую» систему или из-за наличия более приоритетных задач. В результате в ней постепенно накапливаются слабые места.</li> <li><strong>Третий фактор — технический долг. </strong>Большинство SAP-систем развивались годами, и сегодня это сложные архитектуры с высоким уровнем интеграции и большим количеством взаимосвязей, где любое изменение может повлиять на десятки процессов и требует крайне трудозатратного тестирования.</li> </ul> <p>Отдельную нагрузку создают <strong>регулярные изменения в законодательстве</strong>. Если раньше значительную часть требований закрывал вендор, сейчас компании вынуждены самостоятельно адаптировать системы, что требует дополнительных ресурсов и повышает риск ошибок.</p> <p>На этом фоне многие компании начали оптимизировать расходы на поддержку SAP. Это выглядит логично, но на практике часто приводит к обратному эффекту: экономия увеличивает вероятность инцидентов. А любой серьезный сбой — это уже не локальная ИТ-проблема, а остановка бизнес-процессов с прямыми финансовыми последствиями.</p> <p>В этих условиях подход «и так работает» становится все более рискованным, потому что речь идет не о текущем состоянии системы, а о том, насколько она готова к следующему инциденту.</p> <p>Главный риск сегодня заключается не в том, что система перестанет работать, а в том, что она продолжит работать до момента, когда сбой окажется критическим.</p> <h3>Какие стратегии выбирают компании</h3> <p>После ухода SAP компании оказались в ситуации, где необходимо определить дальнейший путь: развивать систему, замораживать ее или постепенно заменять. Со временем стало понятно, что универсального решения нет, и каждая компания выстраивает свою стратегию в зависимости от бизнес-задач, ресурсов и уровня зрелости внутренней ИТ-организации. Тем не менее на практике сформировалось несколько типовых сценариев.</p> <ul> <li> <strong>Развитие. </strong>Несмотря на ограничения, многие компании продолжают дорабатывать систему, поскольку она глубоко интегрирована в бизнес-процессы, а полноценной замены часто нет. Однако здесь быстро возникает ограничение по ресурсам: внутренние команды перегружены, часть специалистов переключается на другие задачи, а объем работ, включая требования законодательства, только увеличивается. В результате развитие замедляется или почти останавливается, а технический долг продолжает расти.</li> <li> <strong>Удержание и оптимизация. </strong>В этом случае компании стараются не расширять систему, а максимально продлить срок ее жизни, контролируя расходы и инфраструктуру. На первый план выходят задачи, которые раньше воспринимались как второстепенные: управление объемом данных, архивирование и оптимизация производительности. При этом именно здесь часто скрывается значительный потенциал: грамотная работа с данными и использованием ресурсов позволяет снизить нагрузку на систему, сократить затраты и ускорить выполнение операций.</li> <li> <strong>Гибридная модель. </strong>Система остается ядром, но окружение постепенно заменяется: интеграционные решения, аналитика, отдельные функциональные блоки. Это позволяет снизить зависимость без резких изменений, но требует аккуратной работы с архитектурой и глубокого понимания всех взаимосвязей. При переходе к такой модели возникает ряд вопросов, не всегда очевидных на этапе планирования. Замена отдельных компонентов приводит к необходимости заново оценивать поведение всей архитектуры в условиях реальной нагрузки.</li> </ul> <p>Ключевой риск связан не столько с функциональностью новых решений, сколько с их работой в составе существующего ИТ-ландшафта. Выдержит ли новая система прежний объем операций? Как изменится время отклика? Как поведут себя смежные системы при одновременной нагрузке?</p> <p>В таких условиях снова становится актуальной практика комплексного нагрузочного и интеграционного тестирования с фокусом на сквозные процессы. Это позволяет воспроизвести реальные сценарии, оценить влияние каждого компонента и выявить узкие места до того, как они проявятся в эксплуатации.</p> <p>Отдельно стоит отметить, что независимо от выбранной стратегии, большинство компаний сталкивается с одной и той же проблемой — нехваткой опыта. Внутренние команды хорошо знают свою систему, но редко сталкиваются с большим количеством различных сценариев и инцидентов.</p> <p>При этом именно опыт и накопленная практика позволяют не только реагировать на проблемы, но и заранее выявлять их предпосылки, корректно оценивать поведение системы под нагрузкой и принимать решения без дополнительных рисков для бизнеса.</p> <p>Одна из самых распространенных ошибок — воспринимать поддержку лишь как процесс «закрытия заявок». В текущих условиях это уже полноценный инструмент управления рисками, от которого напрямую зависит стабильность бизнеса.</p> <p>Устойчивость системы определяется не столько выбранной стратегией, сколько глубиной экспертизы и способностью работать с ней в условиях постоянных изменений.</p> <h3>Когда система работает на пределе</h3> <p>Поддержка обычно воспринимается как стабильный процесс до тех пор, пока система не начинает работать на пределе. Именно в такие моменты становится видно, насколько критична способность быстро находить первопричины проблем, а не просто реагировать на их внешние проявления.</p> <p>На практике проблемы редко выглядят как классические аварии. Чаще это накопленные перегрузки, деградация производительности или сбои в отдельных бизнес-процессах, которые постепенно приводят к остановке системы.</p> <p>Несмотря на различный характер таких ситуаций — повышенное потребление ресурсов, снижение производительности или сбои в процессах, все они сводятся к одному фактору. Решающее значение имеет не тип инцидента, а способность быстро проанализировать поведение системы, выявить первопричину и устранить ее без дополнительных рисков для бизнеса.</p> <p>Именно здесь ключевую роль играет опыт работы с критическими системами, знание архитектуры и практика решения нестандартных задач в условиях ограниченного времени.</p> <h3>Поддержка как элемент устойчивости бизнеса</h3> <p>Сегодня поддержка — это уже не вспомогательный сервис, а инструмент обеспечения стабильности бизнеса на горизонте ближайших лет. Пока компании находятся в процессе выбора долгосрочной стратегии развития ИТ-ландшафта, система должна оставаться работоспособной и предсказуемой.</p> <p>Поэтому ключевой задачей становится не только реакция на инциденты, но и их предотвращение через анализ текущего состояния системы.</p> <p>#IMAGE_234742#</p> После ухода SAP с российского рынка перед компаниями встал вполне прагматичный вопрос: что делать с уже внедренными … article Артем Редьков, директор дирекции премиальных сервисов и поддержки “ТерраЛинк” https://www.itweek.ru/themes/detail.php?ID=234740 Tue, 28 Apr 2026 15:18:40 +0300 <p>Специализированный облачный провайдер mt cloud (компания Movetel) и Deckhouse, разработчик решений для enterprise-инфраструктуры, объявили о стратегическом партнерстве и запустили сервис KaaS (Kubernetes as a Service). В рамках сотрудничества клиентам становится доступна платформа Deckhouse Kubernetes Platform, развернутая на высокопроизводительной инфраструктуре провайдера по модели управляемого сервиса.</p> <p>Платформа позволяет компаниям значительно оптимизировать эксплуатацию контейнерных сред и автоматизировать ключевые процессы эксплуатации. В результате сокращается время подготовки инфраструктуры и сред разработки до 15 раз и обеспечивается целевой уровень доступности SLA 99,99%. </p> <p>Синергия технологий Deckhouse и экспертизы mt cloud направлена на переход к максимально автоматизированному управлению Kubernetes-кластерами. Решение позволяет сократить долю ручных операций и обеспечить высокий уровень автоматизации в управлении ИТ-системами.</p> <p>Новый сервис KaaS на базе Deckhouse Kubernetes Platform ориентирован на средний и крупный бизнес, которому требуется предсказуемое поведение инфраструктуры в условиях реальной эксплуатации. В отличие от типовых управляемых решений, платформа предлагает целостный подход: обновления, безопасность и администрирование автоматизированы на уровне системы. В результате внедрения у бизнеса можно снизить совокупную стоимость владения ИТ-активами более чем на 30% и автоматизировать до 80% рутинных операций по эксплуатации.</p> <p>Ключевым преимуществом партнерства является глубокая интеграция платформы с выделенной инфраструктурой mt cloud. Подобная синергия обеспечивает ряд уникальных возможностей для заказчиков:</p> <ul> <li>высокая производительность: использование NVMe-хранилищ и сети 25 Гбит/с в сочетании с программно-определяемой сетью VMware NSX-T для стабильной работы кластеров;</li> <li>георезервирование: архитектура распределена между двумя независимыми площадками Tier III, что гарантирует низкий показатель RTO и устойчивость к локальным сбоям;</li> <li>изоляция сред: возможность создания полностью обособленных контуров для устранения влияния посторонних нагрузок, что критично для высоконагруженных промышленных систем;</li> <li>гибридные сценарии: обеспечена поддержка интеграции с локальными мощностями заказчика и адаптация конфигураций под специфические задачи бизнеса.</li> </ul> <p>Применение KaaS на базе Deckhouse позволяет ускорить вывод продуктов на рынок в <nobr>2–15 раз.</nobr> Команды разработки получают возможность развернуть кластер примерно за 30 минут через инструменты самообслуживания. Для специалистов по информационной безопасности предусмотрена встроенная защита по умолчанию, включая централизованный аудит, сбор журналов событий и автоматическое применение политик. </p> <p>«Мы стремимся изменить сценарииуправления Kubernetes, переходя от ручной настройки и фрагментированного контроля к модели „автопилота“. Данное решение обеспечивает единый жизненный цикл кластера со сквозными обновлениями, что исключает конфликты компонентов. Подобный метод автоматизации позволяет командам разработки фокусироваться на написании кода приложений, а не на обслуживании системной среды. Совместно с mt cloud мы предоставляем рынку решение, где эксплуатационная сложность полностью скрыта под капотом автоматизации», — отметил Андрей Радыгин, руководитель направления «Облачное партнерство» Deckhouse компании «Флант».</p> <p>«Задача mt cloud — предоставить такую среду, в которой возможности Deckhouse раскрываются без ограничений типовых массовых облаков. За счёт экспертизы в построении инфраструктуры корпоративного уровня реализовано решение с гибкой настройкой сети, ресурсов и изоляции сред под конкретные задачи. Это позволяет использовать Kubernetes в составе сложных инфраструктурных сценариев, включая высоконагруженные системы, гибридные архитектуры и интеграцию с on-prem решениями. Такая модель даёт бизнесу управляемый Kubernetes, адаптированный под реальные требования инфраструктуры и особенности задач», — прокомментировал Тимур Чубарин, генеральный директор mt cloud.</p> Специализированный облачный провайдер mt cloud (компания Movetel) и Deckhouse, разработчик решений для … message https://www.itweek.ru/themes/detail.php?ID=234738 Tue, 28 Apr 2026 10:05:03 +0300 <p><em>Новый <a href="https://www.datadoghq.com/state-of-ai-engineering/">отчет</a> Datadog «2026</em> <em>State</em> <em>of</em> <em>AI</em> <em>Engineering</em><em>» указывает на измеримую проблему сбоев в корпоративных системах искусственного интеллекта. Примерно 1 из 20 запросов уже завершается с ошибкой в ​​производственной среде, однако системы продолжают работать и возвращать результаты, которые кажутся правильными, что затрудняет обнаружение этих сбоев. 5% сбоев в производственной среде ИИ — это, по инженерным стандартам, очень высокий показатель, сообщает портал Bigdatawire.</em></p> <p>Наряду с ростом числа сбоев, в отчете также подчеркивается растущая сложность и нестабильность производственных сред. Речь идет не о сбоях систем, а о том, что системы продолжают работать, становясь при этом менее достоверными.</p> <p>В отчете особенно бросается в глаза столкновение одновременно нескольких тенденций. Использование ИИ быстро переходит в производство, частота сбоев начинает проявляться все более отчетливо, а проектирование систем становится все более сложным, поскольку команды объединяют несколько моделей, источников данных и инструментов в единый конвейер. Datadog отмечает, что около 70% организаций уже используют три или более моделей в производственной среде, что добавляет еще один уровень координации.</p> <p>В некоторых случаях поверх добавляются рабочие процессы на основе агентов, что вносит еще большую вариативность. Каждый из этих слоев расширяет возможности, но также увеличивает вероятность того, что что-то пойдет не так, не будучи сразу видимым, и именно здесь начинает проявляться проблема «тихих сбоев».</p> <p>«ИИ начинает очень напоминать ранние дни облачных технологий, — говорит Яньбин Ли, директор Datadog по продуктам. — Облако сделало системы программируемыми, но гораздо более сложными в управлении. Теперь ИИ делает то же самое с уровнем приложений. Компании, которые добьются успеха, будут не просто создавать лучшие модели — они будут строить вокруг них операционный контроль. В эту новую эпоху наблюдаемость ИИ становится такой же важной, как наблюдаемость облачных технологий десять лет назад».</p> <p>Что делает эти выводы еще более значимыми, так это источник данных. Datadog не проводит опросы разработчиков и не собирает мнения. Компания анализирует телеметрию производственных процессов тысяч компаний, использующих системы ИИ в режиме реального времени. Это включает в себя растущее число сред на основе агентов, где модели не просто генерируют выходные данные, но и управляют многоэтапными рабочими процессами.</p> <p>В отчете указывается, что основной преградой на пути надежного масштабирования ИИ является операционная сложность, поскольку большинство организаций уже используют несколько моделей в производственной среде. По мере расширения этих систем задача состоит уже не в том, чтобы заставить их работать, а в том, чтобы сделать их понятными и управляемыми после развертывания.</p> <p>«Следующая волна сбоев агентов будет связана не с тем, что агенты не могут делать, а с тем, что команды не могут наблюдать, — говорит Гильермо Раух, генеральный директор компании Vercel, стоящей за Next.js и ведущей платформой для создания веб-приложений на основе ИИ. — Агентам необходимы те же циклы обратной связи в производственной среде, что и отличному ПО. В отличие от традиционного ПО, управление потоком данных в агентах осуществляется самой большой языковой моделью (LLM), что делает наблюдаемость не просто полезной, но и необходимой».</p> <p>Еще одна закономерность, обнаруженная исследователями, заключается в том, что многие из этих сбоев вызваны не качеством модели, а ограничениями инфраструктуры. Большая часть ошибок связана с ограничениями скорости запросов, и миллионы таких событий регистрируются в производственных системах. По мере роста использования системы все чаще достигают пределов пропускной способности провайдера, что приводит к всплескам сбоев, которые трудно предсказать. На практике надежность определяется не только тем, насколько хорошо работает модель, но и тем, как команды управляют нагрузкой, повторными попытками и параллельным выполнением задач.</p> <p>Согласно отчету Datadog, контролировать затраты и задержку становится все сложнее. Использование токенов увеличилось более чем вдвое для типичных рабочих нагрузок и еще больше для сценариев с высокой интенсивностью использования. Причиной этого роста является не только пользовательский ввод, но и расширяющийся слой системных промптов, политик и инструкций инструментов, которые многократно обрабатываются в каждом запросе. Эти фоновые токены теперь составляют значительную долю общего использования, а это значит, что затраты могут расти даже тогда, когда спрос пользователей кажется стабильным.</p> <p>Несмотря на все эти аспекты, основные преимущества в плане эффективности часто упускаются. В отчете показано, что кэширование промптов по-прежнему используется недостаточно, и большинство систем повторно обрабатывают один и тот же контекст между вызовами. Это указывает на разрыв между тем, как создаются системы ИИ, и тем, как они оптимизируются в производственной среде. По мере расширения контекстных окон и увеличения объема промптов задача смещается от насыщения модели бóльшим количеством данных к определению того, какая информация действительно имеет значение.</p> Новый отчет Datadog «2026 State of AI Engineering» указывает на измеримую проблему сбоев в корпоративных … article https://www.itweek.ru/themes/detail.php?ID=234736 Tue, 28 Apr 2026 09:45:59 +0300 <p><em>Компании вкладываются в нейросети, запускают пилоты, получают первые результаты, но вместо роста производительности — бесконечная доводка скриптов, вместо масштабирования — сломанные пайплайны и разочарованные команды. Рассмотрим, почему так происходит и как превратить ИИ из игрушки в рабочий инструмент.</em></p> <h3>Разрыв между пилотами и реальной пользой</h3> <p>Сегодня подавляющее большинство российских компаний уже <a href="https://ufa.plus.rbc.ru/news/69721e0e7a8aa9bcd48b0d54">работает</a> с ИИ, но формализованную стратегию <a href="https://www.cnews.ru/news/line/2026-03-03_97_krupnyh_rossijskih_kompanij">имеет</a> лишь четверть — разрыв между пилотными проектами и промышленным масштабированием остается ключевой сложностью. GenAI-зрелость <a href="https://www.finmarket.ru/main/article/6584687">оценивается</a> всего на 2,0 из 5, а главным барьером становится не бюджет, а сопротивление изменениям. Компании всё чаще отказываются от стратегии «собери сам» в пользу готовых инфраструктурных решений.</p> <p>Разбираемся, как превратить нейросети в работающий бизнес-инструмент и в чем могут помочь такие сервисы ИИ-платформы.</p> <h3>Почему «собери сам» — это ловушка для бизнеса</h3> <p>Когда компания решает внедрить ИИ, первое желание — взять всё под контроль и собрать решение самостоятельно. Типичный путь выглядит обнадеживающе просто: взяли мощности в аренду, подняли модель, прикрутили поиск по внутренней базе знаний. А потом всё падает под нагрузкой. Запросы начинают виснуть, модель забывает контекст после третьего сообщения, а на пике тестирования система просто умирает.</p> <p>Проблема в том, что самые сложные вопросы не видны на старте. Как управлять несколькими моделями сразу, когда одна считает быстрее, а вторая точнее? Как сохранять историю настроек, если бизнес-логика меняется каждый спринт? Как отслеживать, что ответы модели не начали «плыть», когда вчера она отвечала на вопрос «да», а сегодня — «нет» без видимых причин? И главное — как при этом не раскрыть конфиденциальные данные в процессе работы поиска по документам? На каждый такой вопрос Open Source-сообщество предлагает по три библиотеки. Однако склеить их в единую работающую систему, которая не рассыплется в первый же рабочий день — это задача для вендора или исследовательской лаборатории, а не для ИТ-отдела бизнес-компании.</p> <p>В результате продакшн-инженеры отвлекаются от своих прямых задач, подход к управлению ИИ-пайплайнами распадается на набор скриптов-героев, а документация размазана по пяти репозиториям и чату в Телеграме. Команды, которые пробуют собрать этот стек из открытых компонентов вручную, обычно заканчивают одинаково: либо через месяц бросают, либо получают конструкцию, которая работает не всегда. Это путь для тех, кто продает платформы, или для исследователей, которым интересно разбираться в этом. Для бизнеса, которому нужен предсказуемый результат, работающая система и контроль над данными, это почти всегда ловушка.</p> <h3>Что дает ИИ-платформа: от мощностей до готового программного интерфейса за один шаг</h3> <p>Хорошая платформа — это не просто «аренда железа». Это среда, где вся сложность уже упакована в готовый продукт. Вы получаете не разрозненные компоненты, которые нужно клеить руками, а единое пространство, где модели, данные и вычислительные мощности работают как часы. В такую платформу обычно входит аренда серверов с ускорителями вычислений, готовый доступ к моделям через программный интерфейс, визуальные инструменты для сборки пайплайнов без кода, а также вся сопутствующая инфраструктура: хранилища, очереди задач, конструкторы чат-ботов. Всё это позволяет не тратить месяцы на настройку и написание однотипного кода, а сосредоточиться на том, ради чего всё затевалось — на бизнес-логике и пользовательских сценариях.</p> <p>Чем платформа отличается от голой аренды вычислительных мощностей? Тем, что не нужно думать о том, как масштабировать модель при растущем потоке запросов, версионировать настройки вручную, балансировать нагрузку между несколькими экземплярами — всё это уже сделано. Вы просто загружаете данные, настраиваете сценарий в визуальном интерфейсе или через API и получаете работающее решение. Для компании с высокими требованиями к безопасности данных — это критически важно: информация никуда не уходит за пределы вашего контура. А для команды без штатных специалистов по машинному обучения — это возможность запустить проект не за квартал, а за неделю.</p> <p>И вот здесь как раз нужна не просто «аренда железа», а платформа, где всё уже собрано в одном месте. Такие платформы превращают ИИ в работающий инструмент.</p> <h3>Как перейти от пилота к продукту: три шага</h3> <p>Платформа сама по себе не решает бизнес-задачу. Она убирает технические барьеры, чтобы команда могла сосредоточиться на главном — на сценариях, которые приносят пользу. Вот как выглядит путь от идеи до работающего инструмента.</p> <p><strong>Шаг первый: выбрать сценарий, который уже работает у других.</strong> Не нужно изобретать велосипед. Поиск по внутренним документам с персональными данными, помощник для первой линии техподдержки, генерация и проверка документов по внутренним правилам — всё это задачи, которые команды уже решают с помощью ИИ. Вы выбираете то, что болит именно у вас. Например, отдел поддержки тонет в однотипных вопросах, а старшие специалисты отвлекаются от сложных задач. Значит, начинаем с автоматизации ответов на частые запросы.</p> <p><strong>Шаг второй: собрать пайплайн в визуальной среде без программирования.</strong> Вы берете готовую модель из каталога платформы — их уже настроили до вас. Подключаете внутреннее хранилище с документами: инструкциями, историями тикетов, регламентами. Настраиваете механизм поиска по этим документам через простой визуальный интерфейс — указываете, откуда брать данные, как их резать на куски, как подавать в модель. И получаете готовый программный интерфейс через пару дней.</p> <p><strong>Шаг третий: обеспечить безопасность и контроль.</strong> Данные не покидают ваш доверенный периметр — это главное требование для компаний с чувствительной информацией. Все компоненты работают внутри изолированного облачного контура, который соответствует требованиям регуляторов. Также необходимо настроить процесс поставки обновлений в продуктовую среду.</p> <p>Так, разрыв между «поиграли с промптами в ChatGPT» и «у нас работает автоматическая проверка договоров» преодолевается не магией и не наймом большого количества специалистов, а правильной инфраструктурой, где сложность уже спрятана, а бизнес-сценарий становится главным героем. ИИ-платформа — это именно такая инфраструктура.</p> <p>#IMAGE_234737#</p> Компании вкладываются в нейросети, запускают пилоты, получают первые результаты, но вместо роста … article Евгений Мартынов, директор по информационным технологиям Рег.облака