Фреймворк ИИ-ответственности, призванный прояснить, кто за что отвечает в обеспечении безопасности ИИ-систем, по аналогии с моделью "shared responsibility" в облаках. В нём даётся карта ответственности (responsibility matrix) между провайдером и заказчиком (или разработчиком), охватывающая разные модели развёртывания AI и разные домены безопасности. Проект охватывает 8 моделей развёртывания AI и 16 доменов безопасности (традиционные + специфичные для AI).

8 моделей развертывания ИИ:
6⃣ Публичная LLM-платформа → ChatGPT, Gemini, Claude
2⃣ Публичная LLM-платформа с API-интеграцией → API-доступ к GPT, Anthropic, Cohere
3⃣ SaaS-продукт с AI-функциями → Notion AI, GitHub Copilot
4⃣ Вендорская модель, размещённая в облаке клиента (Managed AI) → Azure OpenAI, Bedrock, Vertex AI
5⃣ Самостоятельно развёрнутая LLM (on-prem / частное облако) → Llama 3, Mistral, Falcon на своих серверах
6⃣ Встроенный AI-модуль в программный продукт → ERP с ML-анализом или рекомендациями
7⃣ Специализированное AI-решение под конкретный домен → AI для SOC, антифрод, медицинская диагностика
8⃣ Разработка собственной модели с нуля / fine-tuning → внутренние R&D-команды

16 доменов ИБ:
6⃣ Управление идентификацией и доступом (IAM)
2⃣ Управление данными и приватностью
3⃣ Шифрование данных "на лету" и "на хранении"
4⃣ Регистрация событий/промптов и аудит обращений к модели
5⃣ Управление уязвимостями и патчами
6⃣ Безопасность кода и зависимостей
7⃣ Управление жизненным циклом модели (ModelOps)
8⃣ Управление обучающими данными
9⃣ Мониторинг дрейфа модели и метрик
6⃣1⃣ Обнаружение атак на модель (poisoning, inversion, extraction)
6⃣6⃣ Безопасность API и оконечных устройств
6⃣2⃣ Соответствие нормативным требованиям (compliance, GDPR, ИИ-акты и т.п.)
6⃣3⃣ Этические и репутационные риски
6⃣4⃣ Непрерывность бизнеса и отказоустойчивость ИИ-сервисов
6⃣5⃣ Реагирование на инциденты и реагирование на утечки / атаки
6⃣6⃣ Поверхность атаки и тестирование безопасности (red teaming / оценка защищенности).

⚡️ Microsoft представила новый стандарт оценки ИИ для кибербезопасности - ExCyTIn-Bench

Microsoft запустила ExCyTIn-Bench - открытую платформу, которая тестирует, как ИИ справляется с реальными инцидентами безопасности, а не просто отвечает на теоретические вопросы.

Что делает ExCyTIn-Bench

- Имитация настоящего SOC (Security Operations Center) с логами, инцидентами и хаосом реальных атак.
- Проверяет не только ответы, но и логику рассуждений ИИ: шаги, объяснения, приоритизацию угроз.
- Включает 57 таблиц логов из Microsoft Sentinel — максимально приближено к практике.
- Поддерживает сравнение разных моделей и метрик, включая reasoning-оценку (пошаговое мышление).

Зачем это нужно

Обычные тесты “вопрос-ответ” не отражают реальную сложность киберугроз.
ExCyTIn-Bench поднимает планку: теперь модели должны мыслить как аналитики SOC.

Microsoft уже использует этот бенчмарк для проверки своих продуктов — Security Copilot, Defender и Sentinel.
Первые результаты показывают, что продвинутые LLM вроде GPT-5 уже уверенно анализируют инциденты и выстраивают цепочку атак.

🔗 Подробнее: https://www.microsoft.com/en-us/security/blog/2025/10/14/microsoft-raises-the-bar-a-smarter-way-to-measure-ai-for-cybersecurity/


#Microsoft #CyberSecurity #AI #SecurityCopilot

AgentScope — агентно-ориентированное программирование для создания приложений на основе LLM

Просто для новичков, мощно для экспертов.

🐱 GitHub

Сagent — позволяет создавать и запускать интеллектуальных ИИ-агентов, каждый из которых обладает специальными знаниями, инструментами и возможностями.

Представьте, что это позволяет вам быстро создавать, объединять и управлять командой виртуальных экспертов, которые совместно решают сложные задачи.

И он очень прост в использовании!

🐱 GitHub

Disciplined-AI-Software-Development — эта методология представляет собой структурированный подход к совместной работе с системами искусственного интеллекта над проектами по разработке программного обеспечения.

Она позволяет решать распространённые проблемы, такие как раздувание кода, изменение архитектуры и размывание контекста, с помощью систематических ограничений и контрольных точек проверки.

🐱 GitHub

Schema-Guided Reasoning

В профильных LLM-каналах начал набирать популярность термин SGR (Schema-Guided Reasoning), но по какой-то причине народ не всегда понимает, что он обозначает, и зачем нужен. Никакого секрета нет, главное запомнить одно уравнение:

SGR = SO + COT

Из чего складывается Schema-Guided Reasoning:

1️⃣Во-первых, нам нужна модель, которая поддерживает Stuctured Output (SO) - возможность управлять результатом работы LLM, "зануляя" вероятности токенов, не подходящих под описанную нами грамматику, прямо во время выполнения.

2️⃣Во-вторых, нам нужно определить структуру желаемого ответа так, чтобы она "помогала" модели мыслить (тот самый Chain-Of-Thought).
Мы как бы «заставляем» модель пройти определенные этапы размышления перед тем как дать ответ, чтобы в результате вероятность корректных токенов ответа была выше.

Отличным примером использования такой техники является бот для дип-ресерча на открытых модельках sgr-deep-research, разработанный автором канала @neuraldeep:

🟢Сначала (скриншот 1 в комментах) мы определяем несколько классов, которые описывают шаги размышления модели. Например, когда модель хочет сгенерировать список уточняющих вопросов - она должна сначала описать себе причину, зачем ей это уточнение потребовалось, далее перечислить список терминов, которые она не поняла, предположить что они обозначают, и только после этого сгенерировать вопросы пользователя

🟢Одновременно с этим, для описания шагов размышления мы используем Pydantic-классы. Зачем? Чтобы можно было их отправить в LLM в качестве грамматики, ограничивающей результат. Теперь, если LLM решит выполнить шаг «Уточнение вопроса», она обязательно должна будет пройти указанные выше шаги, и это ограничение будет завернуто прямо в движок ее инференса. Модель просто физически не сможет отойти от схемы и начать генерировать что-то нерелевантное (почти всегда, но об этом позже)

Далее, эти шаги объединяются в цепочку (скриншот 2), которая представляет собой финальный ответ, и структура которой будет отправлена в LLM в качестве промпта.

И вот на этом этапе, становится понятно, зачем понадобился вообще SGR, и в чем его преимущество относительно других методов. Для того, чтобы сгенерировать следующий шаг в размышлениях, LLM обязательно сгенерирует:
🟢1-4 предложения, как она видит текущую ситуацию;
🟢статус выполнения плана исследования, закончен ли он, сколько еще шагов нужно пройти
🟢сколько еще шагов поиска она может сделать
🟢достаточно ли ей данных для отчета
🟢и только после этого, она сможет выбрать инструмент, который будет запускать (или доуточнение, или веб-поиск, или генерация ответа).

Для больших моделей, такой подход часто избыточен - они и так достаточно умные, чтобы рассуждать прямо "из коробки", и всегда следовать нужной инструкции.
Но если ваша модель относительно небольшая, и может легко отклоняться от инструкций, или она недостаточно хорошо их выполняет, то такие вот "рельсы" в виде Structured Output + зашитый в ответ процесс размышлений в стиле Chain-Of-Thought могут дать значительный прирост качества на ряде задач.

Конечно, у такого подхода есть и минусы, и его тоже нужно правильно готовить, но об этом как-нибудь в другой раз

@korneychukov

WaterCrawl — это мощное веб-приложение, использующее Python, Django, Scrapy и Celery для сканирования веб-страниц и извлечения необходимых данных.

Особенности:
— Расширенное веб-сканирование и парсинг — сканирование веб-сайтов с широкими возможностями настройки глубины, скорости и таргетинга на конкретный контент
— Мощная поисковая система — находите нужный контент в интернете с помощью различных уровней поиска (базовый, расширенный, максимальный)
— Поддержка нескольких языков — поиск и сканирование контента на разных языках с учётом особенностей страны

🐱 GitHub