Экономика надёжности,
в мировом масштабе
CAST Intelligence Unit представил результаты масштабного исследования технического долга, основанного на анализе 10 миллиардов строк кода из 47 000 приложений в 17 странах, совокупно представляющих 51 % мирового ВВП.
Исследование переводит понятие технического долга в измеримый показатель - человеко-дни
Общий объем работ по исправлению накопившегося технического долга оценивается в 611 миллиардов человеко‑дней — консервативная оценка, учитывающая лишь выявленные дефекты.
Если бы все 25 миллионов разработчиков мира сосредоточились исключительно на рефакторинге, работа была бы завершена лишь к 2034 году. Это подчеркивает масштаб зависимости бизнеса от систем, находящихся в состоянии критического износа.
Страны, ранее лидировавшие в цифровизации, сегодня несут наибольшую нагрузку по техническому долгу.
Топ‑3 страны по затратам на исправление 1 000 строк кода:
- США — 2,07 дня;
- Италия — 1,99 дня;
- Франция — 1,98 дня;
Развивающиеся экономики (например, Перу — 1,40 дня, Эквадор — 1,45 дня) демонстрируют существенно меньший уровень технического долга.
Это создает потенциал для «технологического рывка»: внедряя ИИ и современные платформы на относительно чистом коде, компании из развивающихся стран могут обойти страны, вынужденные поддерживать устаревшие системы.
Отчет опровергает предположение, что генеративные ИИ (LLM) могут автоматически устранять технический долг. Вероятностная природа нейросетей эффективна для создания нового кода, но малоприменима для исправления сложных, устаревших систем.
При этом менее 10 % технического долга носит критический характер, однако именно он причиняет основной ущерб.
Для снижения рисков предлагается (да по сути ничего нового и не предлагается, но перечислим ):
1. Интегрировать метрики технического долга в KPI IT‑подразделений.
2. Сегментировать портфель систем, выделив критически важные с низкой устойчивостью.
3. Внедрить автоматический контроль состава ПО для управления рисками
4. Проводить глубокий анализ кода перед миграциями или внедрением ИИ‑решений.
Источник: The State of Global Technical Debt 2025 (CAST Intelligence Unit, 2025)
@Simple_Reliability
в мировом масштабе
CAST Intelligence Unit представил результаты масштабного исследования технического долга, основанного на анализе 10 миллиардов строк кода из 47 000 приложений в 17 странах, совокупно представляющих 51 % мирового ВВП.
Исследование переводит понятие технического долга в измеримый показатель - человеко-дни
Общий объем работ по исправлению накопившегося технического долга оценивается в 611 миллиардов человеко‑дней — консервативная оценка, учитывающая лишь выявленные дефекты.
Если бы все 25 миллионов разработчиков мира сосредоточились исключительно на рефакторинге, работа была бы завершена лишь к 2034 году. Это подчеркивает масштаб зависимости бизнеса от систем, находящихся в состоянии критического износа.
Страны, ранее лидировавшие в цифровизации, сегодня несут наибольшую нагрузку по техническому долгу.
Топ‑3 страны по затратам на исправление 1 000 строк кода:
- США — 2,07 дня;
- Италия — 1,99 дня;
- Франция — 1,98 дня;
Развивающиеся экономики (например, Перу — 1,40 дня, Эквадор — 1,45 дня) демонстрируют существенно меньший уровень технического долга.
Это создает потенциал для «технологического рывка»: внедряя ИИ и современные платформы на относительно чистом коде, компании из развивающихся стран могут обойти страны, вынужденные поддерживать устаревшие системы.
Отчет опровергает предположение, что генеративные ИИ (LLM) могут автоматически устранять технический долг. Вероятностная природа нейросетей эффективна для создания нового кода, но малоприменима для исправления сложных, устаревших систем.
При этом менее 10 % технического долга носит критический характер, однако именно он причиняет основной ущерб.
Для снижения рисков предлагается (
1. Интегрировать метрики технического долга в KPI IT‑подразделений.
2. Сегментировать портфель систем, выделив критически важные с низкой устойчивостью.
3. Внедрить автоматический контроль состава ПО для управления рисками
4. Проводить глубокий анализ кода перед миграциями или внедрением ИИ‑решений.
Источник: The State of Global Technical Debt 2025 (CAST Intelligence Unit, 2025)
@Simple_Reliability
👍4
В начале февраля вышло очередное исследование от Harvard Business Review: AI Doesn’t Reduce Work — It Intensifies It.
200+ интервьюеров опровергает гипотезу о том, что генеративный ИИ разгружает команды. Напротив, добровольное использование ИИ приводит к систематической интенсификации (попросту говоря,увеличению количества) труда.
Внедрение ИИ запускает самоподдерживающийся механизм, который, в конечном итоге, приводит к перегрузкам:
Сотрудники, увлеченные возможностями ИИ, активно берут на себя дополнительные задачи, воспринимая это как профессиональный вызов.
Однако, такая «добровольная» интенсификация труда имеет отложенные последствия, в том числе и для надёжности (канал же про надёжность=))): накапливается усталость, растет число ошибок, снижается качество решений.
В итоге эксперты HBR делают такие выводы/советы:
@Simple_Reliability
200+ интервьюеров опровергает гипотезу о том, что генеративный ИИ разгружает команды. Напротив, добровольное использование ИИ приводит к систематической интенсификации (попросту говоря,увеличению количества) труда.
Внедрение ИИ запускает самоподдерживающийся механизм, который, в конечном итоге, приводит к перегрузкам:
Ускорение задач → Рост ожиданий скорости → Зависимость от ИИ → Расширение функционала → Увеличение плотности работы → Когнитивное истощение
Сотрудники, увлеченные возможностями ИИ, активно берут на себя дополнительные задачи, воспринимая это как профессиональный вызов.
Однако, такая «добровольная» интенсификация труда имеет отложенные последствия, в том числе и для надёжности (канал же про надёжность=))): накапливается усталость, растет число ошибок, снижается качество решений.
В итоге эксперты HBR делают такие выводы/советы:
ИИ сам по себе не снижает нагрузку, а позволяет делать больше.
Чтобы это не привело к выгоранию и снижению качества, организациям нужно активно формировать такие практики:
- Проведение аудита ролей: проверить, какие новые задачи взяли на себя сотрудники благодаря ИИ, и оценить реальную нагрузку, в том числе неучтенную
- Проведение тренингов по осознанному использованию ИИ: как ставить границы, как распределять задачи между собой и ИИ, как избегать мультизадачности
- Введение намеренных пауз, регулярных остановок для сверки с целями: перед принятием ключевого решения нужно привести контраргумент и обосновать связь со стратегией компании
- Четкая последовательность. Вместо мгновенной реакции — сбор и групповая обработка результатов работы ИИ в отведенные временные слоты. Это освобождает ресурсы для глубокой фокусировки
- Человеческое общение!... Выделение времени для живого общения: в отличие от ответов ИИ, диалог с коллегами возвращает контекст и выявляет неочевидные нюансы.
@Simple_Reliability
❤3👍1🙏1
Что если использовать LLM по его прямому назначению: попросить предугадать. Придумать, что может пойти не так, что может стать гипотетической причиной сбоя при внедрении.
Получается не post-mortem, а pre-mortem анализ.
Чем не идея для улучшения производительности службы сопровождения и повышения надёжности?
Типичный Pre-mortem начинается после того, как все готово к запуску. Команде/AI-агентам ставится задача «Проект провалился, вам необходимо сформулировать причины провала».
Что хорошо, живые люди в такой ситуации смогут сформулировать «потенциальные» проблемы, которые они обычно не стали бы упоминать, опасаясь показаться «недипломатичными».
AI-агенты смогут потратить еще n-ое количество токенов на очень важное дело=))
@Simple_Reliablity
Получается не post-mortem, а pre-mortem анализ.
Чем не идея для улучшения производительности службы сопровождения и повышения надёжности?
Pre-mortem — это гипотетическая противоположность посмертного анализа (postmortem). В медицине вскрытие позволяет медикам и родственникам узнать, что стало причиной смерти пациента.
Выгоду получают все, кроме, разумеется, самого пациента. Pre-mortem в IT/Бизнесе проводится в начале проекта, чтобы его можно было улучшить, а не «вскрывать».
В отличие от типичных сессий критики, где членов команды/AI-агентов спрашивают, что может пойти не так, Pre-mortem исходит из предположения, что «пациент» умер, и задает вопрос: что именно пошло не так?
Задача команды/AI-агентов — придумать правдоподобные причины провала проекта/внедрения.
Типичный Pre-mortem начинается после того, как все готово к запуску. Команде/AI-агентам ставится задача «Проект провалился, вам необходимо сформулировать причины провала».
Что хорошо, живые люди в такой ситуации смогут сформулировать «потенциальные» проблемы, которые они обычно не стали бы упоминать, опасаясь показаться «недипломатичными».
AI-агенты смогут потратить еще n-ое количество токенов на очень важное дело=))
@Simple_Reliablity
❤5👍2🔥1
Forwarded from Avito SREда
Media is too big
VIEW IN TELEGRAM
Работает быстро, но не всегда туда. О чём мы? Об AI 😀
В новом выпуске размышляем на самые спорные темы и выясняем:
➡️ какие рутинные задачи в SRE ему уже можно отдать;
➡️ в каких случаях AI — коллега, а в каких — инструмент;
➡️ почему эта тема стала так актуальна для SRE именно сейчас;
➡️ где мы в Авито уже внедрили AI, а где соблюдаем осторожность.
❤️, если обе новости — правда
👀, если 1 новость — фейк
👾, если 2 новость — фейк
😱, если обе новости — фейки
Правильные ответы ищите в выпуске!
📺 YouTube
🔵 VK
💻 Rutube
🛫 Любая удобная платформа
#sre
В новом выпуске размышляем на самые спорные темы и выясняем:
А пока вы не успели перейти по ссылке на выпуск, попробуйте угадать, фейки следующие новости или нет:1️⃣ — DeepSeek обогнала OpenAI по эффективности обучения, тренируя модели за миллионы вместо миллиардов2️⃣ — Model Drift уничтожил систему обнаружения мошенничества — никто не замечал две недели
❤️, если обе новости — правда
👀, если 1 новость — фейк
👾, если 2 новость — фейк
😱, если обе новости — фейки
Правильные ответы ищите в выпуске!
#sre
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10❤5👾1
Forwarded from Мишка на сервере (Mikhail Savin)
Надежность — это не продукт SRE, или почему мы всё понимали не так?
Привет,
На самом деле, надежность — это не "продукт", который SRE-команда может произвести в вакууме и отдать бизнесу. Это совместная ответственность всей организации. А вот SRE выступает как архитектор и катализатор целой экосистемы обеспечения надежности.
Давай разберем, из чего состоит эта экосистема:
- Инженерные практики: SLI/SLO, Error Budgets и автоматизация. Важно понимать, что 100% аптайма — это почти всегда неправильная цель. Требуемый уровень надежности — это продуктовый вопрос, а не технический.
- Культура и процессы: Blameless postmortems и устранение "стен" между командами. SRE не может единолично "внедрить" правильную культуру, но выступает ее драйвером. Исследования DORA подтверждают: культура доверия без поиска виноватых напрямую повышает эффективность всего бизнеса.
- Инструменты надежности: Системы мониторинга, алертинга и автоматизации реакций на инциденты. И тут кроется важное отличие от смежных ролей: создание удобной внутренней платформы разработки (IDP) — это задача Platform Engineering. SRE же фокусируется именно на инструментах стабильности, а упрощение жизни разработчиков — это скорее приятный побочный эффект.
Если SRE начинает восприниматься как единственный владелец надежности, это ломает концепцию shared responsibility и приводит к антипаттерну "перебрасывания ответственности через стену". Разработчики должны сами владеть своим сервисом и отвечать за его доступность, а SRE лишь помогает им достигать нужных показателей.
Краткие выводы:
- Надежность — это фича самого продукта, а не изолированный результат работы SRE-команды.
- SRE является архитектором экосистемы надежности, но отвечает за стабильность весь бизнес сообща.
- Фокус SRE — инструменты стабильности (Reliability Tooling), тогда как удобство разработчиков (Developer Experience) — это профильный домен Platform Engineering.
Делись опытом в комментариях! Как у тебя в компании разделена ответственность за надежность между SRE, разработчиками и продуктологами? Сталкивался ли с ситуацией, когда стабильность полностью перевешивали на SRE? И где, по-твоему, проходит грань между SRE и Platform Engineering в реальной работе?
#SRE #DevOps #Observability #incidents #ErrorBudget #Postmortem #OnCall #SiteReliabilityEngineering #Monitoring
Привет,
%username%! Недавно мы обсуждали, что является главным продуктом SRE. Кажется логичным сказать, что это надежность или внутренние инструменты для разработчиков. Но если опираться на свежее исследование, базирующееся на опыте Google и отчетах DORA, открывается совсем другая картина.На самом деле, надежность — это не "продукт", который SRE-команда может произвести в вакууме и отдать бизнесу. Это совместная ответственность всей организации. А вот SRE выступает как архитектор и катализатор целой экосистемы обеспечения надежности.
Давай разберем, из чего состоит эта экосистема:
- Инженерные практики: SLI/SLO, Error Budgets и автоматизация. Важно понимать, что 100% аптайма — это почти всегда неправильная цель. Требуемый уровень надежности — это продуктовый вопрос, а не технический.
- Культура и процессы: Blameless postmortems и устранение "стен" между командами. SRE не может единолично "внедрить" правильную культуру, но выступает ее драйвером. Исследования DORA подтверждают: культура доверия без поиска виноватых напрямую повышает эффективность всего бизнеса.
- Инструменты надежности: Системы мониторинга, алертинга и автоматизации реакций на инциденты. И тут кроется важное отличие от смежных ролей: создание удобной внутренней платформы разработки (IDP) — это задача Platform Engineering. SRE же фокусируется именно на инструментах стабильности, а упрощение жизни разработчиков — это скорее приятный побочный эффект.
Если SRE начинает восприниматься как единственный владелец надежности, это ломает концепцию shared responsibility и приводит к антипаттерну "перебрасывания ответственности через стену". Разработчики должны сами владеть своим сервисом и отвечать за его доступность, а SRE лишь помогает им достигать нужных показателей.
Краткие выводы:
- Надежность — это фича самого продукта, а не изолированный результат работы SRE-команды.
- SRE является архитектором экосистемы надежности, но отвечает за стабильность весь бизнес сообща.
- Фокус SRE — инструменты стабильности (Reliability Tooling), тогда как удобство разработчиков (Developer Experience) — это профильный домен Platform Engineering.
Делись опытом в комментариях! Как у тебя в компании разделена ответственность за надежность между SRE, разработчиками и продуктологами? Сталкивался ли с ситуацией, когда стабильность полностью перевешивали на SRE? И где, по-твоему, проходит грань между SRE и Platform Engineering в реальной работе?
#SRE #DevOps #Observability #incidents #ErrorBudget #Postmortem #OnCall #SiteReliabilityEngineering #Monitoring
❤3👍1🔥1
10-11 апреля можем встретиться на XV IT-конференции «Стачка» в Ульяновске.
Обсудить проблемы надёжности, связанные с внедрением ИИ и все остальное.
Есть промокод и бесплатный билет, пишите
@Simple_Reliability
Обсудить проблемы надёжности, связанные с внедрением ИИ и все остальное.
Здесь соберутся более 2000 участников (и онлайн-зрителей): разработчики, специалисты по контенту и коммуникациям, HR, а также руководители и собственники IT-компаний.
В течение двух дней – мощный IT-буст:
- 200+ докладов от лидеров индустрии из ВКонтакте, Авито, Яндекса, Сбера, Wildberries & Russ, Ozon, Газпром ИД, Альфа-Банка и т.д.
- 30+ секций по четырём направлениям: Разработка, Управление, Дизайн и Контент, Digital-маркетинг.
- мастермайнды, панельные дискуссии, мастер-классы, экспертные зоны, нетворкинг-события, афтепати в завершении первого дня.
Есть промокод и бесплатный билет, пишите
@Simple_Reliability
🔥6
Forwarded from DUMP Ekb 2026
Секция DevOps & SRE — про изменения, которые происходят прямо сейчас в индустрии.
Делимся одним из докладов⤵️
Вячеслав Кудряшов, «От DevOps к EvalOps (или как мы трансформируем функцию OPS/SRE в связи с внедрением GenAI)»
Как меняется роль OPS и SRE с приходом генеративного ИИ? Что такое EvalOps и зачем он нужен?
В докладе разберём, как трансформируются функции сопровождения, как управлять инфраструктурой, где значительную часть процессов уже выполняют ИИ-агенты, и какие компетенции важно развивать уже сейчас.
Если хотите понять, куда движется DevOps и какие навыки будут востребованы завтра — обязательно загляните ☺️
Делимся одним из докладов
Вячеслав Кудряшов, «От DevOps к EvalOps (или как мы трансформируем функцию OPS/SRE в связи с внедрением GenAI)»
Как меняется роль OPS и SRE с приходом генеративного ИИ? Что такое EvalOps и зачем он нужен?
В докладе разберём, как трансформируются функции сопровождения, как управлять инфраструктурой, где значительную часть процессов уже выполняют ИИ-агенты, и какие компетенции важно развивать уже сейчас.
Если хотите понять, куда движется DevOps и какие навыки будут востребованы завтра — обязательно загляните ☺️
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👍2
Forwarded from ДевФест
От DevOps к EvalOps
или как мы трансформируем функцию OPS/SRE в связи с внедрением GenAI🤖
При массовом внедрении GenAI в ИТ-ландшафт, крупные организации сталкиваются с новыми вызовами:
– GenAI-системы недетерминированы по своей природе. Классические метрики (uptime, latency) не отражают их реальное качество и надежность.
– Появляются новые классы инцидентов: «галлюцинации», дрейф качества, промпт-инжекты требуют новых подходов к мониторингу и реагированию.
В докладе Вячеслав Кудряшов, исполнительный директор, МСС, СБЕР, расскажет о том, как меняются функции сопровождения, что такое EvalOPS. Рассмотрим конкретные примеры, как управлять инфраструктурой, в которой большую часть бизнес-процессов обслуживают ИИ-агенты, и какие компетенции нужно растить уже сейчас🧠
Если это для вас, ждём вас на ДевФесте🖱
или как мы трансформируем функцию OPS/SRE в связи с внедрением GenAI
При массовом внедрении GenAI в ИТ-ландшафт, крупные организации сталкиваются с новыми вызовами:
– GenAI-системы недетерминированы по своей природе. Классические метрики (uptime, latency) не отражают их реальное качество и надежность.
– Появляются новые классы инцидентов: «галлюцинации», дрейф качества, промпт-инжекты требуют новых подходов к мониторингу и реагированию.
В докладе Вячеслав Кудряшов, исполнительный директор, МСС, СБЕР, расскажет о том, как меняются функции сопровождения, что такое EvalOPS. Рассмотрим конкретные примеры, как управлять инфраструктурой, в которой большую часть бизнес-процессов обслуживают ИИ-агенты, и какие компетенции нужно растить уже сейчас
Если это для вас, ждём вас на ДевФесте
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5
- Знаете, что такое Harness?
- Нет.
- Дословный перевод – сбруя. На самом деле это и есть сбруя, только не для лошади, а для ИИ-агентов. Так понятнее?
- Да… но… что такое сбруя?
Harness состоит из двух компонентов:
1. Платформа – базовый инструмент для агентной разработки. Примеры: Claude Code, OpenAI Codex, OpenCode, Cursor... Он дает технические возможности для работы с кодом;
2. Правила и настройки – то, что делает платформу «умной» именно для компании: стандарты написания кода; архитектурные ограничения; автоматические проверки (требований надежности); механизмы исправления ошибок прямо в процессе генерации.
Основной принцип в том, что инфраструктура выстраивает «рамки» для ИИ‑агента:
- Перед работой система загружает в модель все нужные правила и контекст проекта
- В процессе специальные механизмы сразу блокируют ошибки и заставляют ИИ исправлять их
- После генерации код проходит автоматическую проверку: тесты, сборку, сканирование безопасности. Пока проверка не пройдена, код не попадает в проект
Без такой системы контроля:
- в коде накапливается больше ошибок, чем при ручной разработке;
- разработчики тратят на проверку ИИ‑кода больше времени, чем на написание его с нуля;
- доверие к ИИ падает, и команды возвращаются к ручному ревью: теряется весь выигрыш в скорости.
Оригинал: For Agentic SDLC, the AI Coding Harness Matters More Than the Coding Model (Gartner, March 2026)
@Simple_Reliability
- Нет.
- Дословный перевод – сбруя. На самом деле это и есть сбруя, только не для лошади, а для ИИ-агентов. Так понятнее?
- Да… но… что такое сбруя?
Harness состоит из двух компонентов:
1. Платформа – базовый инструмент для агентной разработки. Примеры: Claude Code, OpenAI Codex, OpenCode, Cursor... Он дает технические возможности для работы с кодом;
2. Правила и настройки – то, что делает платформу «умной» именно для компании: стандарты написания кода; архитектурные ограничения; автоматические проверки (требований надежности); механизмы исправления ошибок прямо в процессе генерации.
Основной принцип в том, что инфраструктура выстраивает «рамки» для ИИ‑агента:
- Перед работой система загружает в модель все нужные правила и контекст проекта
- В процессе специальные механизмы сразу блокируют ошибки и заставляют ИИ исправлять их
- После генерации код проходит автоматическую проверку: тесты, сборку, сканирование безопасности. Пока проверка не пройдена, код не попадает в проект
Без такой системы контроля:
- в коде накапливается больше ошибок, чем при ручной разработке;
- разработчики тратят на проверку ИИ‑кода больше времени, чем на написание его с нуля;
- доверие к ИИ падает, и команды возвращаются к ручному ревью: теряется весь выигрыш в скорости.
Оригинал: For Agentic SDLC, the AI Coding Harness Matters More Than the Coding Model (Gartner, March 2026)
- К 2028 году компании с грамотно настроенным harness будут иметь на 60% меньше дефектов после запуска продукта
- Правильная инфраструктура повышает успешность генерации кода с 53,8% до 81,8%
- Разница между топовыми моделями ИИ при этом невелика - всего 1–3%.
@Simple_Reliability
🔥6⚡2
В психологии есть принцип принятия решений - Pre-Mortem
В ИТ мы чаще всего пользуемся другим принципом - Post-Mortem. Для чего он нужен, кажется, все понятно, а отказаться от него мы сможем только когда у нас не будет инцидентов…т.е. примерно никогда.
А что если перенять и переиспользовать Pre-Mortem для смещения влево оценки надежности при новых внедрениях…
@Simple_Reliability
Когда вы собираетесь что-то сделать — запустить проект, нанять сотрудника, подписать контракт, — вместо вопроса «что может пойти не так?» скажите себе: «прошло полгода, все провалилось, что случилось?». Этот прием анализа решений придумал психолог Гэри Кляйн. Он заметил: если описать провал как уже свершившийся факт, человек оценивает свои планы объективнее.
В ИТ мы чаще всего пользуемся другим принципом - Post-Mortem. Для чего он нужен, кажется, все понятно, а отказаться от него мы сможем только когда у нас не будет инцидентов…
А что если перенять и переиспользовать Pre-Mortem для смещения влево оценки надежности при новых внедрениях…
Берлинский разработчик Амин Боргеи создал на основе этой техники готовый скилл Premortem для Claude. Он собирает контекст из чатов и файлов, реконструирует сценарии провала, поручает сгенерированным «следователям» проанализировать каждый из них и выдает чеклист на 3–5 пунктов — что
надо было проверить до запуска
ссылка
@Simple_Reliability
🔥6❤4👏1
Forwarded from Технологии Сбера Самара
Сообщество инженеров сопровождения Сбера продолжает агентизировать города
📆 13 августа Сбер собирает OPS, DevOps и SRE-инженеров Самары в необычном формате и только офлайн.
🏦 Сбер курсирует по Волге на двух теплоходах, где в формате барных стендапов и дискуссий инженеры обсудят, что умеют агенты в OPS, а что пока нет, как в Сбере строят надёжность, как реагируют на инциденты, куда ведёт агентизация и что с этим делать.
13 августа, 18:30
Самара, Теплоходы "Вояж" и "Спутник"
➡️ Регистрация тут
Количество очных мест ограничено
13 августа, 18:30
Самара, Теплоходы "Вояж" и "Спутник"
Количество очных мест ограничено
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👍1
Forwarded from Архитектура ИТ-решений
10 open-source сканеров безопасности агентских навыков
Хочу поделиться ссылкой на статью с таким заголовком и еще парой ссылок по теме:
- В январском исследование SkillScan говорится, что среди 31 132 общедоступных навыков agent skills удалось выявило 26,1% потенциально опасных, и 5,2% заведомо опасных навыка.
- В конце июля организовался Open Secure AI Alliance (см. пресс-релиз в блоге Nvidia)
В общем, сканируйте ваши, а тем более чужие навыки. Мало ли что
Хочу поделиться ссылкой на статью с таким заголовком и еще парой ссылок по теме:
- В январском исследование SkillScan говорится, что среди 31 132 общедоступных навыков agent skills удалось выявило 26,1% потенциально опасных, и 5,2% заведомо опасных навыка.
- В конце июля организовался Open Secure AI Alliance (см. пресс-релиз в блоге Nvidia)
В общем, сканируйте ваши, а тем более чужие навыки. Мало ли что
Generativeprogrammer
10 Open-Source Projects Securing AI Agent Skills
A practical map of scanners, supply-chain controls, sandboxes, and runtime governance.