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.

Це не дрібниця. Для впровадження ШІ та нормальної закупівлі моделі різниця між «є офіційний звіт» і «хтось послався на звіт без деталей» величезна.

Що я знайшов по фактах: NIST та CAISI справді публікували оцінки інших моделей DeepSeek, зокрема R1, R1-0528 та V3.1. І картина там не про «все відповідає стандартам безпеки», а радше про помітні проблеми з jailbreak, перехопленням агента (agent hijacking) та виконанням шкідливих інструкцій.

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

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

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

Для корпоративної інтеграції ШІ висновок простий: не можна писати в архітектурному рішенні, що модель «перевірена NIST», якщо у вас немає конкретного звіту. Інакше юридичний, закупівельний та ІБ-відділи влаштують вам дуже дорогу розмову.

Друга річ ще практичніша. Якщо модель схильна до hijacking та jailbreak, то будь-яка автоматизація з ШІ, де агент має доступ до CRM, пошти, файлів чи внутрішніх API, стає зоною підвищеного ризику. Особливо якщо хтось вирішив заощадити на системах захисту (guardrails) та політиці прав доступу.

Виграють тут команди, які перевіряють першоджерела та будують архітектуру ШІ з ізоляцією, аудитом дій агента та людським підтвердженням на критичних етапах. Програють ті, хто купує красиву тезу замість реальної оцінки.

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

Забезпечення безпеки великих мовних моделей є складним завданням, що часто вимагає суворих методологій тестування. Раніше ми розглядали Augustus, автоматизований сканер Red Teaming, призначений для виявлення таких вразливостей, як jailbreak та prompt injection в LLM, що підкреслює критичну потребу в проактивних оцінках безпеки при розробці ШІ.

Поділитися статтею