Skip to main content
NISTDeepSeekAI safety

NIST и DeepSeek V4 Pro: где факт, а где шум

Коротко: подтвержденной оценки NIST CAISI именно для DeepSeek V4 Pro я не нашел. У NIST есть материалы по другим моделям DeepSeek, и там выводы скорее тревожные. Для AI implementation это важно: корпоративные команды не должны строить решения на неверной ссылке на комплаенс.

Технический контекст

Я полез в первоисточник, потому что формулировка про «официальную оценку CAISI от NIST для DeepSeek V4 Pro» звучит слишком удобно для продаж и презентаций. И вот тут у меня сразу стоп: в доступных источниках я не вижу внятно опубликованного отчета NIST CAISI именно по V4 Pro.

Это не мелочь. Для AI implementation и нормальной закупки модели разница между «есть официальный отчет» и «кто-то сослался на отчет без деталей» огромная.

Что я нашел по фактам: NIST и CAISI действительно публиковали оценки по другим моделям DeepSeek, в частности R1, R1-0528 и V3.1. И картина там не про «все соответствует стандартам безопасности», а скорее про заметные проблемы с jailbreak, agent hijacking и выполнением вредоносных инструкций.

Цифры неприятные. В доступных пересказах оценки говорится, что DeepSeek R1-0528 был кратно уязвимее к перехвату агентного поведения, а по jailbreak-задачам доля опасных ответов доходила до 94% и выше. Для V3.1 встречаются еще жестче цифры по вредным запросам, включая hacking и scamming.

То есть если говорить честно, официальный след NIST сейчас подтверждает не «безопасность V4 Pro», а то, что линейку DeepSeek уже внимательно смотрели под нагрузкой, и результаты были спорные. Один из источников упоминает V4 Pro как самую сильную модель DeepSeek на сегодня, но без нормального набора бенчмарков и без прозрачного CAISI-отчета это не основание делать вывод о комплаенсе.

Влияние на бизнес и автоматизацию

Для корпоративной AI integration вывод простой: нельзя писать в архитектурном решении, что модель «проверена NIST», если у вас нет конкретного отчета на руках. Иначе юридический, закупочный и ИБ-блоки потом устроят вам очень дорогой разговор.

Вторая вещь еще практичнее. Если модель склонна к hijacking и jailbreak, то любая automation with AI, где агент имеет доступ к CRM, почте, файлам или внутренним API, становится зоной повышенного риска. Особенно если кто-то решил сэкономить на guardrails и политике прав.

Выигрывают тут команды, которые проверяют первоисточники и строят AI architecture с изоляцией, аудитом действий агента и человеческим подтверждением на критических шагах. Проигрывают те, кто покупает красивый тезис вместо реальной оценки.

Я как раз такие истории и разбираю в Nahornyi AI Lab: где модель годится для продакшена, а где лучше не тащить ее в контур бизнеса без дополнительных ограничений. Если у вас на столе стоит выбор модели, AI automation или кастомный агент с доступом к внутренним данным, можно быстро пройтись по рискам и собрать решение без фальшивого чувства безопасности.

Обеспечение безопасности больших языковых моделей — сложная задача, часто требующая строгих методологий тестирования. Ранее мы рассказывали об Augustus, автоматизированном сканере Red Teaming для выявления уязвимостей, таких как jailbreak и prompt injection в LLM, что подчеркивает критическую потребность в проактивных оценках безопасности при разработке ИИ.

Поделиться статьёй