RAG — новая точка входа для тёмных паттернов.
Retrieval-Augmented Generation (RAG) — это подход, где языковая модель сначала делает запрос в базу знаний (retrieval), а затем формирует текст на основе извлечённых данных (generation).
Это гибкий аналог fine-tuning, где вместо статического обучения модели на конкретной выборке, система подставляет нужные документы в рантайме (времени выполнения программы).
Что это меняет:
- Раньше тёмные UX-паттерны жили в интерфейсах: тени, кнопки, таймеры.
- RAG убирает интерфейс как слой. Тексты, действия и тон меняются автоматически, в зависимости от запроса и поведенческого профиля.
- Манипуляция становится невидимой: пользователь думает, что получает ответ, но на самом деле — персонализированную инструкцию, выведенную из векторного профиля и подобранных документов.
- Вся адаптация происходит не в UI, а на уровне:
1. источников retrieval (приоритетность документов),
2. генеративного ответа (нейтральный vs выгодный тон),
3. и логики подстановки (какие данные считаются «релевантными»).
Технически: RAG заменяет код-ветвления (если человек нажал кнопку — покажи X, если не нажал — покажи Y.) и A/B-тесты (когда разным группам пользователей показывают разные части интерфейса) на real-time семантический адаптер.То есть RAG система в реальном времени подтягивает куски текста из разных источников, чтобы создать "на лету" ответ или интерфейс. Это как если бы интерфейс читал сотни документов и сразу решал, что именно вам показать — но вы не видите, что именно осталось за кадром.
Это удобно для разработчиков — но плохо c точки зрения прозрачности, так как:
— модель покажет, из каких документов взяты фразы;
— но никто не покажет, почему выбраны именно эти документы, и что осталось за кадром.
По сути, RAG — это новый скрытый слой между вами и интерфейсом. Он может менять суть происходящего, но при этом быть невидимым.
И если раньше интерфейс можно было разобрать и сказать: вот где нас убедили купить, — теперь воздействие может произойти глубже, на уровне подобранного контекста.
Подробнее:
IBM про RAG
Fine-tuning vs RAG
AI Design Patterns
Картинка
#BehindTheMachine
Retrieval-Augmented Generation (RAG) — это подход, где языковая модель сначала делает запрос в базу знаний (retrieval), а затем формирует текст на основе извлечённых данных (generation).
Это гибкий аналог fine-tuning, где вместо статического обучения модели на конкретной выборке, система подставляет нужные документы в рантайме (времени выполнения программы).
Что это меняет:
- Раньше тёмные UX-паттерны жили в интерфейсах: тени, кнопки, таймеры.
- RAG убирает интерфейс как слой. Тексты, действия и тон меняются автоматически, в зависимости от запроса и поведенческого профиля.
- Манипуляция становится невидимой: пользователь думает, что получает ответ, но на самом деле — персонализированную инструкцию, выведенную из векторного профиля и подобранных документов.
- Вся адаптация происходит не в UI, а на уровне:
1. источников retrieval (приоритетность документов),
2. генеративного ответа (нейтральный vs выгодный тон),
3. и логики подстановки (какие данные считаются «релевантными»).
Технически: RAG заменяет код-ветвления (если человек нажал кнопку — покажи X, если не нажал — покажи Y.) и A/B-тесты (когда разным группам пользователей показывают разные части интерфейса) на real-time семантический адаптер.То есть RAG система в реальном времени подтягивает куски текста из разных источников, чтобы создать "на лету" ответ или интерфейс. Это как если бы интерфейс читал сотни документов и сразу решал, что именно вам показать — но вы не видите, что именно осталось за кадром.
Это удобно для разработчиков — но плохо c точки зрения прозрачности, так как:
— модель покажет, из каких документов взяты фразы;
— но никто не покажет, почему выбраны именно эти документы, и что осталось за кадром.
По сути, RAG — это новый скрытый слой между вами и интерфейсом. Он может менять суть происходящего, но при этом быть невидимым.
И если раньше интерфейс можно было разобрать и сказать: вот где нас убедили купить, — теперь воздействие может произойти глубже, на уровне подобранного контекста.
Подробнее:
IBM про RAG
Fine-tuning vs RAG
AI Design Patterns
Картинка
#BehindTheMachine
🔥2
Петля развития для моделей
В продолжение к теме галлюцинаций моделей и деградации тренировочных данных из предыдущего поста.
Есть мнение, что, в связи с увеличением роста использования AI агентов и пропорциональным снижением трафика на площадках для обсуждения кода (Stack Overflow), нейронки "замкнутся" в своем обучении. Под этим можно понимать момент, когда тренировочной базой для моделей станут уже не человеческий контент, а такие же сгенерированные результаты.
Если обратить внимание на недавний пейпер от Yale исследователей, к моменту, когда ии будет учиться на сгенерированном контенте (а скорее всего еще раньше), без должного набора ошибок (или алгоритма их определения) модель не может научиться отличать истину от лжи, так как ей не с чем сравнивать -> это неизбежно отразится на качестве ответов.
Невозможно выучить структуру языка, видя только его корректные примеры, а для модели все к тому моменту может стать "корректным".
Решение - обратная связь от человека (RLHF) - маркировка ответов на правильные и неправильные. Но из за реактивного поведения моделей (способности галлюцинировать на лету), о масштабировании такой ручной маркировки не может быть и речи, так как это не может покрыть всю бесконечную область возможных запросов и ответов.
Вывод можно сделать такой - ИИ не может отличить ложь от правды, если никто не говорит, где ошибка. А если такие данные начнут “саморазмножаться ”— ошибки станут нормой.
#BehindTheMachine
В продолжение к теме галлюцинаций моделей и деградации тренировочных данных из предыдущего поста.
Есть мнение, что, в связи с увеличением роста использования AI агентов и пропорциональным снижением трафика на площадках для обсуждения кода (Stack Overflow), нейронки "замкнутся" в своем обучении. Под этим можно понимать момент, когда тренировочной базой для моделей станут уже не человеческий контент, а такие же сгенерированные результаты.
Если обратить внимание на недавний пейпер от Yale исследователей, к моменту, когда ии будет учиться на сгенерированном контенте (а скорее всего еще раньше), без должного набора ошибок (или алгоритма их определения) модель не может научиться отличать истину от лжи, так как ей не с чем сравнивать -> это неизбежно отразится на качестве ответов.
Невозможно выучить структуру языка, видя только его корректные примеры, а для модели все к тому моменту может стать "корректным".
Решение - обратная связь от человека (RLHF) - маркировка ответов на правильные и неправильные. Но из за реактивного поведения моделей (способности галлюцинировать на лету), о масштабировании такой ручной маркировки не может быть и речи, так как это не может покрыть всю бесконечную область возможных запросов и ответов.
Вывод можно сделать такой - ИИ не может отличить ложь от правды, если никто не говорит, где ошибка. А если такие данные начнут “саморазмножаться ”— ошибки станут нормой.
#BehindTheMachine
Linkedin
LLMs can't detect hallucinations without errors | Denis O. posted on the topic | LinkedIn
There was a paper published in April 2025 by Yale researchers that says hallucination detection in LLMs is fundamentally impossible if the model is only trained on correct outputs. No matter how advanced the model is, without explicit examples of errors,…
🔥3
Безопасное взаимодействие между агентами: рекомендации Google A2A и LangChain
Тему AI-агентов начнём разбирать с приземленного и критичного вопроса: безопасность при интеграции в существующие системы. Особенно важно для тех, кто уже использует/планирует использовать фреймворки вроде BeeAI, LangChain или же проектирует agentic AI системы.
Один из примеров — протокол Agent2Agent (A2A) от Google, который предлагает унифицированный и безопасный способ коммуникации между агентами. Его ключевое преимущество — он учитывает привычные требования корпоративной безопасности, а не переизобретает стандарты.
Основные рекомендации по безопасности при использовании A2A:
1. Шифрование (TLS)
Вся коммуникация должна идти только через HTTPS с использованием современных версий TLS и проверкой TLS-сертификатов. Это защита от атак типа man-in-the-middle.
2. Аутентификация и авторизация
В A2A всё строится на стандартных HTTP-механизмах. Сервер-агент публикует в AgentCard, какие схемы авторизации поддерживаются (OAuth2, Bearer, API Key и т.д.). Клиент обязан получить нужные токены вне A2A (OAuth flow, JWT, ключи) и передавать их в HTTP-заголовках.
В целом в доке LangChain базово описали - стоит придерживаться принципа наименьших привилегий: только минимально необходимый доступ к данным, только те endpoints, которые безопасны.
3. Мониторинг, трассировка, аудит
Так как A2A работает поверх HTTP, его легко интегрировать с уже существующими системами мониторинга: OpenTelemetry, Jaeger, Zipkin. Передавайте trace-id, span-id и контекст в заголовках (traceparent, tracestate) — это даст полную картину: откуда пришёл запрос, как проходил через агентов и где сломалось, если что-то пошло не так.
Плюс: логируйте taskId, sessionId, correlationId — для полноценного аудита и расследования инцидентов.
Эти шаги критичны, если вы работаете с чувствительными данными (PII, финансовые операции, доступ к внутренним сервисам) и хотите допустить агентов к ним.
Source картинки
@pattern_ai
#BehindTheMachine
Тему AI-агентов начнём разбирать с приземленного и критичного вопроса: безопасность при интеграции в существующие системы. Особенно важно для тех, кто уже использует/планирует использовать фреймворки вроде BeeAI, LangChain или же проектирует agentic AI системы.
Один из примеров — протокол Agent2Agent (A2A) от Google, который предлагает унифицированный и безопасный способ коммуникации между агентами. Его ключевое преимущество — он учитывает привычные требования корпоративной безопасности, а не переизобретает стандарты.
Основные рекомендации по безопасности при использовании A2A:
1. Шифрование (TLS)
Вся коммуникация должна идти только через HTTPS с использованием современных версий TLS и проверкой TLS-сертификатов. Это защита от атак типа man-in-the-middle.
2. Аутентификация и авторизация
В A2A всё строится на стандартных HTTP-механизмах. Сервер-агент публикует в AgentCard, какие схемы авторизации поддерживаются (OAuth2, Bearer, API Key и т.д.). Клиент обязан получить нужные токены вне A2A (OAuth flow, JWT, ключи) и передавать их в HTTP-заголовках.
В целом в доке LangChain базово описали - стоит придерживаться принципа наименьших привилегий: только минимально необходимый доступ к данным, только те endpoints, которые безопасны.
3. Мониторинг, трассировка, аудит
Так как A2A работает поверх HTTP, его легко интегрировать с уже существующими системами мониторинга: OpenTelemetry, Jaeger, Zipkin. Передавайте trace-id, span-id и контекст в заголовках (traceparent, tracestate) — это даст полную картину: откуда пришёл запрос, как проходил через агентов и где сломалось, если что-то пошло не так.
Плюс: логируйте taskId, sessionId, correlationId — для полноценного аудита и расследования инцидентов.
Эти шаги критичны, если вы работаете с чувствительными данными (PII, финансовые операции, доступ к внутренним сервисам) и хотите допустить агентов к ним.
Source картинки
@pattern_ai
#BehindTheMachine
Сравнительный анализ LLM: как часто языковые модели генерируют тёмные паттерны
Исследование "Hidden Darkness in LLM-Generated Designs: Exploring Dark Patterns in Ecommerce Web Components Generated by LLMs" (arXiv:2502.13499) предлагает один из первых системных взглядов на то, как крупные языковые модели (GPT, Claude, Gemini и CodeLlama) могут непреднамеренно внедрять манипулятивные UX-практики — т.н. dark patterns — при генерации интерфейсов для e-commerce.
Авторы построили эксперимент по трём осям: во-первых, тестировались 13 компонентов e-commerce платформ, из которых 7 были связаны с прямым завершением покупки (поиск, карточка товара, корзина, отслеживание заказа и т.д.), а 6 — с user engagement (промо, подписки, баннеры и прочие элементы удержания внимания). Во-вторых, перед генерацией промпты формулировались с разным приоритетом: либо подчёркивались интересы бизнеса (например, «увеличьте конверсию»), либо интересы пользователя («обеспечь user autonomy»), либо вообще не указывались — так называемый baseline. И в-третьих, все модели генерировали HTML+CSS компоненты под идентичные условия с требованиями по реализму, размерам и встроенным шаблоном.
В общей сложности было создано 312 интерфейсных компонентов. Из них 115, то есть 37%, содержали хотя бы один тёмный паттерн. Исследователи выявили все ключевые типы dark patterns — от скрытых кнопок и принудительных сценариев до паттернов навязчивого оформления. Интересно, что модель CodeLlama показала наименьшую склонность к генерации манипуляций, тогда как остальные модели чаще включали такие элементы, особенно когда в промпте явно задавался приоритет интересов компании.
Параллельно с этим исследованием стоит обратить внимание на проект DarkBench — первый масштабный бенчмарк для оценки тёмных паттернов в выводах LLM (датасет, статья, обсуждение). Он включает 660 промптов в шести ключевых категориях манипуляций: предпочтение бренда, удержание пользователя, лесть, очеловечивание модели, вредный контент и скрытые действия. Анализ моделей от OpenAI, Anthropic, Meta, Google и Mistral показал, что даже крупнейшие LLM не защищены от манипулятивных наклонностей — будь то продвижение собственных продуктов или подстройка ответов под ожидания пользователя в ущерб правде.
Эти исследования показывают: генеративные ИИ-системы уже сейчас могут неосознанно масштабировать вредные UX-практики. Это ставит перед разработчиками острый вопрос — как встроить этические фильтры на уровне промптов, output-проверки и генерации дизайна. Тем более что в большинстве случаев сами пользователи таких моделей даже не осознают наличие манипулятивных паттернов в сгенерированном интерфейсе.
Почему это важно?
- Пока LLM активно внедряются в генерацию интерфейсов и цифрового UX, неэтичное поведение может масштабироваться на миллионы пользователей. Разработчикам стоит уже сейчас:
- Внедрять авто-аудит и фильтрацию dark-паттернов
- Работать на транспарентность и user-first подход
- Поддерживать инициативы вроде DarkBench как часть CI/CD
Подробнее про DarkBench хорошо описал этот автор - https://xn--r1a.website/tales_from_it/112
Source картинки
#BehindTheMachine
Исследование "Hidden Darkness in LLM-Generated Designs: Exploring Dark Patterns in Ecommerce Web Components Generated by LLMs" (arXiv:2502.13499) предлагает один из первых системных взглядов на то, как крупные языковые модели (GPT, Claude, Gemini и CodeLlama) могут непреднамеренно внедрять манипулятивные UX-практики — т.н. dark patterns — при генерации интерфейсов для e-commerce.
Авторы построили эксперимент по трём осям: во-первых, тестировались 13 компонентов e-commerce платформ, из которых 7 были связаны с прямым завершением покупки (поиск, карточка товара, корзина, отслеживание заказа и т.д.), а 6 — с user engagement (промо, подписки, баннеры и прочие элементы удержания внимания). Во-вторых, перед генерацией промпты формулировались с разным приоритетом: либо подчёркивались интересы бизнеса (например, «увеличьте конверсию»), либо интересы пользователя («обеспечь user autonomy»), либо вообще не указывались — так называемый baseline. И в-третьих, все модели генерировали HTML+CSS компоненты под идентичные условия с требованиями по реализму, размерам и встроенным шаблоном.
В общей сложности было создано 312 интерфейсных компонентов. Из них 115, то есть 37%, содержали хотя бы один тёмный паттерн. Исследователи выявили все ключевые типы dark patterns — от скрытых кнопок и принудительных сценариев до паттернов навязчивого оформления. Интересно, что модель CodeLlama показала наименьшую склонность к генерации манипуляций, тогда как остальные модели чаще включали такие элементы, особенно когда в промпте явно задавался приоритет интересов компании.
Параллельно с этим исследованием стоит обратить внимание на проект DarkBench — первый масштабный бенчмарк для оценки тёмных паттернов в выводах LLM (датасет, статья, обсуждение). Он включает 660 промптов в шести ключевых категориях манипуляций: предпочтение бренда, удержание пользователя, лесть, очеловечивание модели, вредный контент и скрытые действия. Анализ моделей от OpenAI, Anthropic, Meta, Google и Mistral показал, что даже крупнейшие LLM не защищены от манипулятивных наклонностей — будь то продвижение собственных продуктов или подстройка ответов под ожидания пользователя в ущерб правде.
Эти исследования показывают: генеративные ИИ-системы уже сейчас могут неосознанно масштабировать вредные UX-практики. Это ставит перед разработчиками острый вопрос — как встроить этические фильтры на уровне промптов, output-проверки и генерации дизайна. Тем более что в большинстве случаев сами пользователи таких моделей даже не осознают наличие манипулятивных паттернов в сгенерированном интерфейсе.
Почему это важно?
- Пока LLM активно внедряются в генерацию интерфейсов и цифрового UX, неэтичное поведение может масштабироваться на миллионы пользователей. Разработчикам стоит уже сейчас:
- Внедрять авто-аудит и фильтрацию dark-паттернов
- Работать на транспарентность и user-first подход
- Поддерживать инициативы вроде DarkBench как часть CI/CD
Подробнее про DarkBench хорошо описал этот автор - https://xn--r1a.website/tales_from_it/112
Source картинки
#BehindTheMachine
🔥2
Новый подход к контролю чувствительных данных в LLM
Авторы "Trustworthy AI: Securing Sensitive Data in Large Language Models" предлагают комплексный фреймворк для динамического управления раскрытием ПД в LLM. Основная идея - внедрение доверительных механизмов (через RBAC и ABAC), которые позволяют LLM адаптировать свои ответы в зависимости от уровня доверия пользователя, тем самым обеспечивая безопасное и контролируемое поведение модели при работе с чувствительными данными. Особенно актуально для таких доменов, как healthcare, legal, finance.
Какие проблемы осветили:
Black-box-природа LLM: Пользователи и разработчики не имеют достаточного контроля над тем, какие данные может раскрыть модель, так как внутренние механизмы обучения непрозрачны.
Утечки через обучение: LLM могут запоминать части тренировочных данных (включая PII), и воспроизводить их при определённых запросах.
Эксплойты через промпты: Злоумышленники могут использовать специально сконструированные запросы для извлечения чувствительной информации.
Недостатки текущих методов защиты:
Подходы не учитывают уровень доверия пользователя.
Средства, такие как фильтрация по словам, неэффективны против семантических вариаций и требуют значительных вычислительных ресурсов.
Универсальные политики доступа приводят либо к переоткрытию, либо к избыточному ограничению.
Кратко про существующие методы:
Data Sanitization: Удаление конфиденциальных данных из обучающего корпуса. Плюс: Прямое исключение чувствительной информации. Минус: Трудно масштабировать, автоматизация не справляется с контекстом, ручной анализ невозможен для миллиардов токенов.
Differential Privacy: Добавление шума в процессе обучения, чтобы скрыть детали отдельных данных. Плюс: Теоретически защищает от атак на приватность. Минус: Снижает точность модели, требует больших ресурсов, сложно применимо к LLM в реальности.
Output Filtering: Постобработка с целью фильтрации чувствительной информации в ответах модели. Плюс: Последняя линия защиты перед пользователем. Минус: Высокая вероятность ложных срабатываний, легко обойти продвинутыми запросами, не различает уровни доверия пользователей.
Предлагаемые решения: Авторы предлагают внедрение динамического фреймворка доверия, основанного на двух концепциях:
RBAC (Role-Based Access Control): Доступ к данным регулируется на основе ролей (например, врач, юрист, студент).
ABAC (Attribute-Based Access Control): Учитываются дополнительные параметры — контекст запроса, устройство, временные метки, политика компании и др.
Фреймворк включает три модуля:
User Trust Profiling: Определяет доверие к пользователю.
Information Sensitivity Detection: Обнаруживает чувствительные данные в выходе модели.
Adaptive Output Control: Настраивает ответ модели в зависимости от доверия.
Таким образом модель может динамически адаптировать свое поведение.
#BehindTheMachine #AIShelf
Авторы "Trustworthy AI: Securing Sensitive Data in Large Language Models" предлагают комплексный фреймворк для динамического управления раскрытием ПД в LLM. Основная идея - внедрение доверительных механизмов (через RBAC и ABAC), которые позволяют LLM адаптировать свои ответы в зависимости от уровня доверия пользователя, тем самым обеспечивая безопасное и контролируемое поведение модели при работе с чувствительными данными. Особенно актуально для таких доменов, как healthcare, legal, finance.
Какие проблемы осветили:
Black-box-природа LLM: Пользователи и разработчики не имеют достаточного контроля над тем, какие данные может раскрыть модель, так как внутренние механизмы обучения непрозрачны.
Утечки через обучение: LLM могут запоминать части тренировочных данных (включая PII), и воспроизводить их при определённых запросах.
Эксплойты через промпты: Злоумышленники могут использовать специально сконструированные запросы для извлечения чувствительной информации.
Недостатки текущих методов защиты:
Подходы не учитывают уровень доверия пользователя.
Средства, такие как фильтрация по словам, неэффективны против семантических вариаций и требуют значительных вычислительных ресурсов.
Универсальные политики доступа приводят либо к переоткрытию, либо к избыточному ограничению.
Кратко про существующие методы:
Data Sanitization: Удаление конфиденциальных данных из обучающего корпуса. Плюс: Прямое исключение чувствительной информации. Минус: Трудно масштабировать, автоматизация не справляется с контекстом, ручной анализ невозможен для миллиардов токенов.
Differential Privacy: Добавление шума в процессе обучения, чтобы скрыть детали отдельных данных. Плюс: Теоретически защищает от атак на приватность. Минус: Снижает точность модели, требует больших ресурсов, сложно применимо к LLM в реальности.
Output Filtering: Постобработка с целью фильтрации чувствительной информации в ответах модели. Плюс: Последняя линия защиты перед пользователем. Минус: Высокая вероятность ложных срабатываний, легко обойти продвинутыми запросами, не различает уровни доверия пользователей.
Предлагаемые решения: Авторы предлагают внедрение динамического фреймворка доверия, основанного на двух концепциях:
RBAC (Role-Based Access Control): Доступ к данным регулируется на основе ролей (например, врач, юрист, студент).
ABAC (Attribute-Based Access Control): Учитываются дополнительные параметры — контекст запроса, устройство, временные метки, политика компании и др.
Фреймворк включает три модуля:
User Trust Profiling: Определяет доверие к пользователю.
Information Sensitivity Detection: Обнаруживает чувствительные данные в выходе модели.
Adaptive Output Control: Настраивает ответ модели в зависимости от доверия.
Таким образом модель может динамически адаптировать свое поведение.
#BehindTheMachine #AIShelf
arXiv.org
Trustworthy AI: Securing Sensitive Data in Large Language Models
Large Language Models (LLMs) have transformed natural language processing (NLP) by enabling robust text generation and understanding. However, their deployment in sensitive domains like...
🔥1
Обучающие курсы EDPB по ИИ и защите данных
Европейский совет по защите данных (EDPB) выпустил два мощных учебных пособия для разработчиков, специалистов по безопасности и защите данных. Идеальный материал, чтобы усилить команду:
1. Law & Compliance in AI Security & Data Protection
Основные темы:
▪️Основы ИИ и их влияние на защиту персональных данных;
▪️Правовые риски на протяжении всего жизненного цикла ИИ: проектирование -> развертывание -> вывод из эксплуатации;
▪️Практические примеры, иллюстрирующие проблемы соответствия GDPR и Закону об ИИ;
2. Fundamentals of Secure AI Systems with Personal Data
Основные темы:
▪️Жизненный цикл ИИ: от сбора данных до вывода из эксплуатации;
▪️Разработка системы ИИ с учетом надлежащих практик кодирования, использование безопасных песочниц, тестирования безопасности разрабатываемых систем ИИ;
▪️Методы разработки и развертывания;
▪️Как проводить аудит: техническая, юридическая, этическая оценка;
В следующем посте разберём, как эти знания применяются на практике:
- Как проверять уязвимости в ML-библиотеках
- Как защититься от опасных моделей и supply chain-атак
- И какие инструменты использовать прямо сейчас
#BehindTheMachine
@pattern_ai
Европейский совет по защите данных (EDPB) выпустил два мощных учебных пособия для разработчиков, специалистов по безопасности и защите данных. Идеальный материал, чтобы усилить команду:
1. Law & Compliance in AI Security & Data Protection
Основные темы:
▪️Основы ИИ и их влияние на защиту персональных данных;
▪️Правовые риски на протяжении всего жизненного цикла ИИ: проектирование -> развертывание -> вывод из эксплуатации;
▪️Практические примеры, иллюстрирующие проблемы соответствия GDPR и Закону об ИИ;
2. Fundamentals of Secure AI Systems with Personal Data
Основные темы:
▪️Жизненный цикл ИИ: от сбора данных до вывода из эксплуатации;
▪️Разработка системы ИИ с учетом надлежащих практик кодирования, использование безопасных песочниц, тестирования безопасности разрабатываемых систем ИИ;
▪️Методы разработки и развертывания;
▪️Как проводить аудит: техническая, юридическая, этическая оценка;
В следующем посте разберём, как эти знания применяются на практике:
- Как проверять уязвимости в ML-библиотеках
- Как защититься от опасных моделей и supply chain-атак
- И какие инструменты использовать прямо сейчас
#BehindTheMachine
@pattern_ai
❤1
Часть 2: Анализ уязвимостей в ИИ и практики безопасной разработки - cмотрим, как проверить уязвимости при использованиие библиотек с открытым исходным кодом
Ни одна библиотека не застрахована от уязвимостей, особенно в сложных экосистемах с десятками транзитивных зависимостей и частыми обновлениями.
Анализ и рекомендации ниже основаны на разделе 6.4 обучающего курса “Fundamentals of Secure AI Systems with Personal Data” из программы Support Pool of Experts, подготовленного по заказу (EDPB).
1. Используйте надежные источники:
Всегда устанавливайте библиотеки из официальных репозиториев (PyPI, Conda, GitHub orgs).
Проверяйте целостность с помощью контрольных сумм или цифровых подписей, если они доступны.
2. Отслеживайте CVE (распространенные уязвимости и риски) через:
Snyk, OSV.dev, pip-audit
3. Проводите анализ зависимостей:
Конвейеры машинного обучения часто включают десятки косвенных зависимостей.
Используйте такие инструменты, как pipdeptree (для сопоставления и анализа деревьев пакетов)
pip-audit (для проверки на известные уязвимости), Dependency-Check
5. Мониторинг сетевого трафика:
Некоторые библиотеки машинного обучения могут автоматически загружать наборы данных или данные телеметрии.
Используйте
6. Обучение модели:
- Предварительная обработка данных вывода
- Изолируйте среду машинного обучения
- Используйте контейнеризацию или виртуальные среды Docker, Singularity или через настройку виртуальных окружений с
Преимущества: ограничение ущерба в случае компрометации, лучшая зависимость и контроль версий, более простой аудит и воспроизводимость.
Помним, что ни одна модель не безопасна по умолчанию. Из распространенных угроз:
▪️Бэкдоры - в модель встроена вредоносная логика. Активируется только при определенных входных данных (например, определенных шаблонах изображений).
▪️Отравление чистой меткой. Данные кажутся правильно помеченными, но вызывают вредоносное поведение после обучения.
▪️ Эксплойты переноса обучения. Отравленные шаблоны выдерживают тонкую настройку и распространяются на последующие задачи.
▪️ Неизвестное происхождение. Если данные или процесс обучения непрозрачны, они могут вносить предвзятости, уязвимости, необнаруживаемые манипуляции, поддельные файлы
Загруженные модели могут быть напрямую изменены вредоносными полезными нагрузками.
#BehindTheMachine
@pattern_ai
Ни одна библиотека не застрахована от уязвимостей, особенно в сложных экосистемах с десятками транзитивных зависимостей и частыми обновлениями.
Анализ и рекомендации ниже основаны на разделе 6.4 обучающего курса “Fundamentals of Secure AI Systems with Personal Data” из программы Support Pool of Experts, подготовленного по заказу (EDPB).
1. Используйте надежные источники:
Всегда устанавливайте библиотеки из официальных репозиториев (PyPI, Conda, GitHub orgs).
Проверяйте целостность с помощью контрольных сумм или цифровых подписей, если они доступны.
2. Отслеживайте CVE (распространенные уязвимости и риски) через:
Snyk, OSV.dev, pip-audit
3. Проводите анализ зависимостей:
Конвейеры машинного обучения часто включают десятки косвенных зависимостей.
Используйте такие инструменты, как pipdeptree (для сопоставления и анализа деревьев пакетов)
pip-audit (для проверки на известные уязвимости), Dependency-Check
5. Мониторинг сетевого трафика:
Некоторые библиотеки машинного обучения могут автоматически загружать наборы данных или данные телеметрии.
Используйте
netstat, tcpdump или брандмауэры для мониторинга исходящего трафика во время:6. Обучение модели:
- Предварительная обработка данных вывода
- Изолируйте среду машинного обучения
- Используйте контейнеризацию или виртуальные среды Docker, Singularity или через настройку виртуальных окружений с
venvПреимущества: ограничение ущерба в случае компрометации, лучшая зависимость и контроль версий, более простой аудит и воспроизводимость.
Помним, что ни одна модель не безопасна по умолчанию. Из распространенных угроз:
▪️Бэкдоры - в модель встроена вредоносная логика. Активируется только при определенных входных данных (например, определенных шаблонах изображений).
▪️Отравление чистой меткой. Данные кажутся правильно помеченными, но вызывают вредоносное поведение после обучения.
▪️ Эксплойты переноса обучения. Отравленные шаблоны выдерживают тонкую настройку и распространяются на последующие задачи.
▪️ Неизвестное происхождение. Если данные или процесс обучения непрозрачны, они могут вносить предвзятости, уязвимости, необнаруживаемые манипуляции, поддельные файлы
Загруженные модели могут быть напрямую изменены вредоносными полезными нагрузками.
#BehindTheMachine
@pattern_ai
Подборка по ключевым рубрикам:
🔹Что делать бизнесу в постоянно меняющемся регуляторном ландшафте?
🔹Что говорит закон про регулирование темных паттернов и как избежать миллионных штрафов?
🔹Баланс между AI-First и правами сотрудников;
🔹Регуляторный подход к Emotion AI и как продукту соблюсти комплаенс;
🔹Примерный чек-лист по соблюдению законодательства для продуктов с Emotion AI;
🔹AI-ассистент и AI-агент: где заканчивается автоматизация и начинается правовая ответственность?
🔹AI и финансовый сектор;
🔹Использование чувствительных данных гос.сектором для обучения ИИ: пример ICDC и не только;
🔹AI powered dark patterns: как ИИ учится управлять вашими решениями;
🔹Искажение выбора: как AI-оценка сбивает с пути в компанию мечты;
🔹Emotion AI превратит ваши эмоции в + 20 CTR для компании;
🔹Флирт с чат-ботом: от простой игры до манипуляции вами один шаг;
🔹НейроUX в банках против ваших интересов;
🔹Neuralink и риски цифрового принуждения;
🔹ИИ помогает людям формировать свои привычки;
🔹Как владельцам контента в ЕС отказаться от использования их данных для обучения ИИ?
🔹RAG — новая точка входа для тёмных паттернов;
🔹Петля развития для моделей;
🔹Безопасное взаимодействие между агентами: рекомендации Google A2A и LangChain;
🔹Сравнительный анализ LLM: как часто языковые модели генерируют тёмные паттерны;
🔹Новый подход к контролю чувствительных данных в LLM;
🔹Анализ уязвимостей в ИИ и практики безопасной разработки - cмотрим, как проверить уязвимости при использованиие библиотек с открытым исходным кодом.
🔹Как писать промпты для ИИ и нужно ли быть вежливым?
🔹Как сделать озвучку с помощью ИИ;
🔹Презентации за пару кликов;
🔹ИИ генерация видео;
🔹Сервисы и промты: от повседневных привычек до изменения мышления.
📚 #AIShelf
🔹Список бесплатных курсов по AI;
🔹Cognizant—Banking Process Transformation 2024 RadarView;
🔹NeuroUX в банковской сфере;
🔹Обучающие курсы EDPB по ИИ и защите данных;
🔹Список курсов по AI Literacy и соответствию AI Act (EU).
Читайте, пересылайте, возвращайтесь к важному.
————
@pattern_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Agentic AI Red Teaming Guide.pdf
2.5 MB
Cloud Security Alliance выпустил руководство по Agentic AI Red Teaming.
По мере интеграции агентов в корпоративную и критически важную инфраструктуру, проактивное Red Teaming должно стать непрерывной функцией. Службам безопасности необходимо тестировать поведение изолированных моделей, полные рабочие процессы агентов, межагентские зависимости и реальные режимы сбоев.
Угрозы в гайде разбиты на 12 категорий, каждая из которых подробно описана:
🔹Захват авторизации и контроля агента;
🔹Сбои "Checker-Out-of-the-Loop";
🔹Взаимодействие агента с критически важными системами;
🔹Манипуляции с целями и инструкциями;
🔹Эксплуатация галлюцинаций агента;
🔹Риски каскадных сбоев и попытки ограничить радиус поражения при нарушениях.
🔹Отравление базы знаний агента;
🔹Манипуляции с памятью и контекстом агента;
🔹Уязвимости во внутриагентной связи, доверии и координации;
🔹Истощение ресурсов и услуг;
🔹Атаки на цепочки поставок и зависимости (риски в инструментах разработки, внешних библиотеках и API) ;
🔹Неотслеживаемость агента.
Каждый раздел руководства включает:
- практические шаги по тестированию;
- примеры сценариев и подсказок;
- результаты, которые можно немедленно применить в рабочем процессе "безопасность по умолчанию" (secure-by-design).
#BehindTheMachine #AIShelf
————
@pattern_ai
По мере интеграции агентов в корпоративную и критически важную инфраструктуру, проактивное Red Teaming должно стать непрерывной функцией. Службам безопасности необходимо тестировать поведение изолированных моделей, полные рабочие процессы агентов, межагентские зависимости и реальные режимы сбоев.
Угрозы в гайде разбиты на 12 категорий, каждая из которых подробно описана:
🔹Захват авторизации и контроля агента;
🔹Сбои "Checker-Out-of-the-Loop";
🔹Взаимодействие агента с критически важными системами;
🔹Манипуляции с целями и инструкциями;
🔹Эксплуатация галлюцинаций агента;
🔹Риски каскадных сбоев и попытки ограничить радиус поражения при нарушениях.
🔹Отравление базы знаний агента;
🔹Манипуляции с памятью и контекстом агента;
🔹Уязвимости во внутриагентной связи, доверии и координации;
🔹Истощение ресурсов и услуг;
🔹Атаки на цепочки поставок и зависимости (риски в инструментах разработки, внешних библиотеках и API) ;
🔹Неотслеживаемость агента.
Каждый раздел руководства включает:
- практические шаги по тестированию;
- примеры сценариев и подсказок;
- результаты, которые можно немедленно применить в рабочем процессе "безопасность по умолчанию" (secure-by-design).
#BehindTheMachine #AIShelf
————
@pattern_ai
Как внедрить проактивное управление рисками ИИ: кейс Telus Digital (G7 HAIP Transparency Report)
Если вы отвечаете за внедрение ИИ в продукт — обязательно изучите, как это делают зрелые компании. Telus Digital поделились своим подходом в отчёте Transparency G7 Hiroshima AI Process (HAIP). Вот что можно взять на вооружение прямо сейчас:
🔹 Управление ИИ-рисками встроено в корпоративные процессы и зоны ответственности.
Есть политика и стандарты по управлению рисками ИИ. Прописана цепочка ответственности — кто за что отвечает на каждом этапе.
🔹Классификация уязвимостей и система оценки рисков.
Уязвимости делят по уровню риска: критический, высокий, средний и низкий.
Используются количественные и качественные метрики оценки ИИ-систем.
🔹 Прозрачные каналы для репортов.
Онлайн-форма и отдельная почта для инцидентов от сотрудников.
Каналы для отчётов от внешних сторон.
Связь напрямую с DPO.
Контракты с подрядчиками обязывают сразу сообщать о нарушениях.
🔹Аудит со стороны и ориентир на стандарты (ISO, NIST и др.)
Используют международные фреймворки: ISO 27001/27002, NIST 800-53, SSAE-18 Type II, AICPA SysTrust и др.
Плюс ежегодные аудиты и консультации с независимыми экспертами.
🔹Обеспечение безопасности на всех этапах жизненного цикла ИИ.
Контроль версий, стандарты кодирования, ревью кода, RBAC.
Тестирование на всех этапах: модульное, сквозное, стресс-тесты и др.
Тестирование безопасности:
- обработка I/O;
- безопасная аутентификация;
- патч-менеджмент с QA перед продом;
Жёсткое разделение: dev ≠ prod, прод-данные вне теста.
Управление изменениями: blue-green deployment , rollback, post-mortem.
Постоянный vulnerability scanning и мониторинг угроз.
🔹Privacy by design и data hygiene.
Только нужные данные, по возможности — анонимизация.
Регулярная проверка точности и актуальности.
🔹Система классификация информации и защита IP.
Маркировка по чувствительности (ограниченная, приватная и т.д.)
RBAC — доступ строго по необходимости.
Чтобы ИИ работал в проде безопасно и ответственно, нужен системный подход и поддержка на уровне всей организации.
#BehindTheMachine
————
@pattern_ai
Если вы отвечаете за внедрение ИИ в продукт — обязательно изучите, как это делают зрелые компании. Telus Digital поделились своим подходом в отчёте Transparency G7 Hiroshima AI Process (HAIP). Вот что можно взять на вооружение прямо сейчас:
🔹 Управление ИИ-рисками встроено в корпоративные процессы и зоны ответственности.
Есть политика и стандарты по управлению рисками ИИ. Прописана цепочка ответственности — кто за что отвечает на каждом этапе.
🔹Классификация уязвимостей и система оценки рисков.
Уязвимости делят по уровню риска: критический, высокий, средний и низкий.
Используются количественные и качественные метрики оценки ИИ-систем.
🔹 Прозрачные каналы для репортов.
Онлайн-форма и отдельная почта для инцидентов от сотрудников.
Каналы для отчётов от внешних сторон.
Связь напрямую с DPO.
Контракты с подрядчиками обязывают сразу сообщать о нарушениях.
🔹Аудит со стороны и ориентир на стандарты (ISO, NIST и др.)
Используют международные фреймворки: ISO 27001/27002, NIST 800-53, SSAE-18 Type II, AICPA SysTrust и др.
Плюс ежегодные аудиты и консультации с независимыми экспертами.
🔹Обеспечение безопасности на всех этапах жизненного цикла ИИ.
Контроль версий, стандарты кодирования, ревью кода, RBAC.
Тестирование на всех этапах: модульное, сквозное, стресс-тесты и др.
Тестирование безопасности:
- обработка I/O;
- безопасная аутентификация;
- патч-менеджмент с QA перед продом;
Жёсткое разделение: dev ≠ prod, прод-данные вне теста.
Управление изменениями: blue-green deployment , rollback, post-mortem.
Постоянный vulnerability scanning и мониторинг угроз.
🔹Privacy by design и data hygiene.
Только нужные данные, по возможности — анонимизация.
Регулярная проверка точности и актуальности.
🔹Система классификация информации и защита IP.
Маркировка по чувствительности (ограниченная, приватная и т.д.)
RBAC — доступ строго по необходимости.
Чтобы ИИ работал в проде безопасно и ответственно, нужен системный подход и поддержка на уровне всей организации.
#BehindTheMachine
————
@pattern_ai
Таксономия рисков ИИ от MIT и как использовать их методологию в своей работе
Исследователи из MIT собрали 831 меру снижения рисков, связанных с ИИ из 13 фреймворков и разложили их по таксономии в гайде Mapping AI Risk Mitigations. Но это не вся польза от гайда, в нем подробно расписана методология создания, которую можно адаптировать для своих целей.
🔹 MIT использовали Claude 4 Sonnet, Opus и ChatGPT o3 для извлечения мер из документов, классификации по заранее заданной структуре, стандартизации описаний, проверки “edge cases”. При анализе выяснили, что некоторые важные меры почти не встречаются в документах (например, Model Alignment — <1%).
Такой же подход подойдёт, если вы строите внутреннюю базу знаний, документацию по управлению рисками или разрабатываете compliance-процессы. НО автоматизация = быстро, поэтому важна обязательная ручная проверка, т.к. LLM путаются, объединяют несколько мер в одну или "придумывают" несуществующее.
🔹У них получилось 4 категории + 23 подкласса:
- Governance (например, защита информаторов, конфликт интересов);
- Security (модельная безопасность, RLHF, watermarking);
- Operations (тестирование, staged deployment, monitoring);
- Transparency (логирование, раскрытие рисков, права пользователя).
Главный вывод, смотря на таблицу, что ИИ развивается быстрее, чем успевают адаптироваться фреймворки и таксономия, например, тестирование входит сразу в несколько направлений. Жёсткая таксономия малоэффективна.
Поэтому не бойтесь, если внутренняя классификация будет неидеальна, лучше “живой список мер” под необходимый стек, чем академическая схема.
Описания мер и примеры подойдут для составления своей базы мер, чек-листов, планов аудита и т.п.
Интерактивная версия базы и карта
🔹Собран список из 13 ключевых фреймворков (NIST AI RM, EU AI Act, FLI Index, Unified Control Framework и т.д.).
Можно использовать как справочник, чтобы определиться с необходимым фреймворком, составить свою политику управления рисками ИИ.
🔹Приведен пример короткого промпта:
Варианты адаптации:
taxonomy = структура (даже простая табличка);
mitigation = описание инцидентов, мер, требований или задач из Jira, Notion или CSV.
MIT проделали большую работу, используйте в своих процессах.
#TalkPrompty #BehindTheMachine
————
@pattern_ai
Исследователи из MIT собрали 831 меру снижения рисков, связанных с ИИ из 13 фреймворков и разложили их по таксономии в гайде Mapping AI Risk Mitigations. Но это не вся польза от гайда, в нем подробно расписана методология создания, которую можно адаптировать для своих целей.
🔹 MIT использовали Claude 4 Sonnet, Opus и ChatGPT o3 для извлечения мер из документов, классификации по заранее заданной структуре, стандартизации описаний, проверки “edge cases”. При анализе выяснили, что некоторые важные меры почти не встречаются в документах (например, Model Alignment — <1%).
Такой же подход подойдёт, если вы строите внутреннюю базу знаний, документацию по управлению рисками или разрабатываете compliance-процессы. НО автоматизация = быстро, поэтому важна обязательная ручная проверка, т.к. LLM путаются, объединяют несколько мер в одну или "придумывают" несуществующее.
🔹У них получилось 4 категории + 23 подкласса:
- Governance (например, защита информаторов, конфликт интересов);
- Security (модельная безопасность, RLHF, watermarking);
- Operations (тестирование, staged deployment, monitoring);
- Transparency (логирование, раскрытие рисков, права пользователя).
Главный вывод, смотря на таблицу, что ИИ развивается быстрее, чем успевают адаптироваться фреймворки и таксономия, например, тестирование входит сразу в несколько направлений. Жёсткая таксономия малоэффективна.
Поэтому не бойтесь, если внутренняя классификация будет неидеальна, лучше “живой список мер” под необходимый стек, чем академическая схема.
Описания мер и примеры подойдут для составления своей базы мер, чек-листов, планов аудита и т.п.
Интерактивная версия базы и карта
🔹Собран список из 13 ключевых фреймворков (NIST AI RM, EU AI Act, FLI Index, Unified Control Framework и т.д.).
Можно использовать как справочник, чтобы определиться с необходимым фреймворком, составить свою политику управления рисками ИИ.
🔹Приведен пример короткого промпта:
I am working with the following taxonomy of AI risk controls {draft taxonomy in XML format}. For each mitigation {mitigation name and description}, assign the best-fit category with a confidence score and
justification. If no category fits, say so. List secondary categories if applicable.
Варианты адаптации:
taxonomy = структура (даже простая табличка);
mitigation = описание инцидентов, мер, требований или задач из Jira, Notion или CSV.
MIT проделали большую работу, используйте в своих процессах.
#TalkPrompty #BehindTheMachine
————
@pattern_ai
Подборка по ключевым рубрикам:
🔹 Легальный веб-скраппинг для обучения ИИ возможен?
🔹Best practices по легальному веб-скраппингу;
🔹ИИ и защита ПД: рекомендации немецких DPA;
🔹Рекомендации CNIL по соблюдению GDPR и чек-лист для проверки;
🔹GPAI Code of Practice опубликован Еврокомиссией. Для чего он нужен?
🔹Гайдлайн для поставщиков GPAI от Еврокомиссии;
🔹Как провести аудит системы ИИ;
🔹Чек-лист. Пост-маркет мониторинг ИИ и отчётность;
🔹Планы Китая и США по ИИ: один - про безопасность, другой - про скорость;
🔹ИИ в зале суда: правила игры;
🔹ИИ в продакшне: почему пост-маркет мониторинг экономит миллионы и репутацию;
🔹ИИ и дети: что нужно знать родителям?;
🔹«Барби, храни мои секреты»: почему это опасный промпт?;
🔹"Красота по алгоритму" или как кейс Vogue запустил новую волну дебатов в индустрии моды;
🔹GenAI и юристы: кто, где и как использует ИИ в 2025 году;
🔹Когда ИИ подводит юристов: реальные судебные "триллеры";
🔹Как Netflix работает с ИИ: 5 принципов для продуктовых команд;
🔹18+ ИИ-компаньоны и человекоподобные сервисы. Где проходят границы нормы?
🔹Как внедрить проактивное управление рисками ИИ: кейс Telus Digital (G7 HAIP Transparency Report);
🔹Таксономия рисков ИИ от MIT и как использовать их методологию в своей работе;
🔹Руководство по Agentic AI Red Teaming| Cloud Security Alliance;
🔹Пример промта для проверки соответствия сайта требованиям законодательства о защите данных (cookie consent);
🔹Пример промпта для проверки ИИ-продукта на соответствие законам и выявление рисков;
🔹Подборка инструментов для генерации и улучшения промптов;
📚 #AIShelf
🔹Примерный чек-лист для составления/проверки контрактов и примеры ИИ-инструментов;
🔹AI Model Clauses: универсальные шаблоны для госструктур и частных компаний;
🔹Шаблоны AI-политик, которые можно забрать в работу;
🔹Примерный чек-лист по созданию AI-продуктов для детей;
🔹Обучающие курсы и ресурсы для юристов по ИИ;
🔹Автоматизация для юристов: какие инструменты уже есть на рынке;
🔹Как юристу внедрить ИИ и не потеряться в инструментах;
🔹Legal AI Use Case Radar 2025 Report;
🔹GovTech или проекты по использованию ИИ в законотворчестве, судах и госуслугах;
🔹Salesforce’s Global AI Readiness Index;
🔹Generative AI and Copyright: Training, Creation, Regulation/ STUDY, requested by the JURI Committee;
🔹The AI Act of the European Union and its implications for global technology regulation|Artificial Intelligence and Fundamental Rights| TRIER STUDIES ON DIGITAL LAW;
Читайте, пересылайте, возвращайтесь к важному.
————
@pattern_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
🙏2
Как злоумышленники используют ИИ в 2025 году
Google Threat Intelligence Group (GTIG) опубликовала исследование о применении ИИ в кибератаках. И пока в соц.сетях шумят новости, про то, что Лувр использовал пароль "Louvre" в своих системах видеонаблюдения, где-то начинается эпоха “умного” вредоносного кода.
🔍 Ключевые наблюдения:
🔹Первое появление “just-in-time” ИИ в вредоносных программах.
Выявлены семейства вредоносных программ (PROMPTFLUX и PROMPTSTEAL), которые используют LLM во время выполнения, которые обращаются к LLM во время выполнения, чтобы динамически генерировать скрипты и функции, обфусцировать код и подстраиваться под окружение. Вместо заранее прописанного набора команд часть поведения создаётся «на лету».
🔹Переход от генерации к динамической адаптации поведения.
GTIG фиксирует, что вредоносные программы начинают не просто генерировать код, но и изменять своё поведение в процессе исполнения на основе ответов моделей. Это означает, что ИИ используется для принятия решений внутри атаки: выбор следующего шага, изменение цепочек команд, адаптация к защите цели. Пока это эксперименты, но тенденция очевидна: злоумышленники уходят от “технического ассистента” к настоящим адаптивным ИИ-агентам, способным принимать решения внутри заражённой системы.
🔹“Социальная инженерия” против защитных барьеров.
Хакеры учатся обходить встроенные в ИИ фильтры. Они пишут промпты с легендами вроде:
Так они убеждают модель (например, Gemini) выдать код или инструкции, которые иначе были бы заблокированы.
🔹Созревший теневой рынок ИИ-инструментов.
В даркнете уже продаются готовые многофункциональные инструменты для фишинга, разработки malware и поиска уязвимостей.
ИИ стал “ассистентом по подписке” даже для тех, кто не умеет кодить, значит порог входа в киберпреступность снизился.
🔹Акторы, спонсируемые государством, тоже в игре.
GTIG отмечает активное использование Gemini группами, связанными с КНДР, Ираном и КНР на всех этапах атак: от разведки и создания фишинговых приманок до создания C2-серверов и эксфильтрации данных.
ИИ превращается в многофункциональный инструмент разведки и управления атаками.
❗️ 📝Что это значит на практике::
▪️Растут операционные риски. ИИ перестаёт быть вспомогательным инструментом и становится частью архитектуры кибератак. Противостоять этому можно только симметрично, развивая защитные системы, тоже основанные на ИИ.
▪️Организации, использующие генеративный ИИ, должны учитывать возможные сценарии злоупотребления при проведении оценок воздействия и в рамках своих систем управления рисками ИИ (AI risk management frameworks). В ЕС и Великобритании регуляторы уже ожидают, что компании будут описывать такие риски в отчётности.
▪️Возникают новые вопросы относительно страхового покрытия инцидентов, связанных с использованием AI-компонентов, а также распределения ответственности между API- и облачными провайдерами в рамках SLA и договорных отношений.
#AIShelf #BehindTheMachine
————
@pattern_ai
Google Threat Intelligence Group (GTIG) опубликовала исследование о применении ИИ в кибератаках. И пока в соц.сетях шумят новости, про то, что Лувр использовал пароль "Louvre" в своих системах видеонаблюдения, где-то начинается эпоха “умного” вредоносного кода.
🔹Первое появление “just-in-time” ИИ в вредоносных программах.
Выявлены семейства вредоносных программ (PROMPTFLUX и PROMPTSTEAL), которые используют LLM во время выполнения, которые обращаются к LLM во время выполнения, чтобы динамически генерировать скрипты и функции, обфусцировать код и подстраиваться под окружение. Вместо заранее прописанного набора команд часть поведения создаётся «на лету».
🔹Переход от генерации к динамической адаптации поведения.
GTIG фиксирует, что вредоносные программы начинают не просто генерировать код, но и изменять своё поведение в процессе исполнения на основе ответов моделей. Это означает, что ИИ используется для принятия решений внутри атаки: выбор следующего шага, изменение цепочек команд, адаптация к защите цели. Пока это эксперименты, но тенденция очевидна: злоумышленники уходят от “технического ассистента” к настоящим адаптивным ИИ-агентам, способным принимать решения внутри заражённой системы.
🔹“Социальная инженерия” против защитных барьеров.
Хакеры учатся обходить встроенные в ИИ фильтры. Они пишут промпты с легендами вроде:
“Я студент, участвую в CTF-соревновании”
или “Я исследователь кибербезопасности”
Так они убеждают модель (например, Gemini) выдать код или инструкции, которые иначе были бы заблокированы.
🔹Созревший теневой рынок ИИ-инструментов.
В даркнете уже продаются готовые многофункциональные инструменты для фишинга, разработки malware и поиска уязвимостей.
ИИ стал “ассистентом по подписке” даже для тех, кто не умеет кодить, значит порог входа в киберпреступность снизился.
🔹Акторы, спонсируемые государством, тоже в игре.
GTIG отмечает активное использование Gemini группами, связанными с КНДР, Ираном и КНР на всех этапах атак: от разведки и создания фишинговых приманок до создания C2-серверов и эксфильтрации данных.
ИИ превращается в многофункциональный инструмент разведки и управления атаками.
▪️Растут операционные риски. ИИ перестаёт быть вспомогательным инструментом и становится частью архитектуры кибератак. Противостоять этому можно только симметрично, развивая защитные системы, тоже основанные на ИИ.
▪️Организации, использующие генеративный ИИ, должны учитывать возможные сценарии злоупотребления при проведении оценок воздействия и в рамках своих систем управления рисками ИИ (AI risk management frameworks). В ЕС и Великобритании регуляторы уже ожидают, что компании будут описывать такие риски в отчётности.
▪️Возникают новые вопросы относительно страхового покрытия инцидентов, связанных с использованием AI-компонентов, а также распределения ответственности между API- и облачными провайдерами в рамках SLA и договорных отношений.
#AIShelf #BehindTheMachine
————
@pattern_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1
Первая атака, проведённая ИИ-агентом
Anthropic сообщила о первой документированной кибершпионской кампании, почти полностью проведённой ИИ.
👀 Группа злоумышленников, связанная с Китаем, использовала Claude Code как автономного оператора: провели джейлбрейк и убедили модель, что она работает в “легитимной компании”, проводящей тестирование безопасности.
Далее ИИ провёл разведку, нашёл уязвимости, написал эксплоиты, установил бекдоры и собрал учётные данные. Вся кампания состояла из десятков отдельных этапов, но 80–90% работы выполняла модель, а человек вмешивался только в нескольких точках.
Claude действовал как полноценный агент: обрабатывал результаты собственных действий, корректировал стратегию, генерировал код, создавал отчёты и поддерживал непрерывный цикл атаки. Модель работала с огромной скоростью, обрабатывая тысячи запросов, часто по несколько в секунду. При этом наблюдались и “галлюцинации” ( ошибки в интерпретации данных, вымышленные креды).
Anthropic блокировала атаку, усилила фильтры и начала делиться сигналами с партнёрами. Полный отчет здесь.
❗️Почему это важно?
Кейс показывает, что угрозы, связанные с agentic AI, перестали быть теорией.
Командам разработки необходимо переосмыслить процессы безопасности, чтобы предотвращать опасные действия агента на этапе намерения, а не в момент инцидента, например:
▪️ Создавать для агента ограниченную среду (sandbox), выдавать минимально необходимые инструменты и запрещать прямой доступ к продовым сервисам.
▪️ Прослойка между моделью и внешними системами должна фильтровать вредоносные запросы, ограничивать действия агента и мониторить инструменты, которыми он может пользоваться.
▪️Проверять устойчивость модели к попыткам обмана, скрытых команд и цепочек действий, которые могут привести к несанкционированным операциям.
▪️Отслеживать аномальные паттерны активности агента: бурст-трафик, нетипичные цепочки действий, попытки обойти политики. Реагирование должно быть автоматическим — с мгновенной блокировкой ключей и инструментов.
▪️Прописать регламенты для сотрудников (уровни доступа, контроль над внешними AI-сервисами, запрет на ввод чувствительных данных и т.д.)
📌 Почитать:
▪️Руководство по Agentic AI Red Teaming |Cloud Security Alliance;
▪️Как злоумышленники используют ИИ в 2025 году;
#BehindTheMachine
————
@pattern_ai
Anthropic сообщила о первой документированной кибершпионской кампании, почти полностью проведённой ИИ.
Далее ИИ провёл разведку, нашёл уязвимости, написал эксплоиты, установил бекдоры и собрал учётные данные. Вся кампания состояла из десятков отдельных этапов, но 80–90% работы выполняла модель, а человек вмешивался только в нескольких точках.
Claude действовал как полноценный агент: обрабатывал результаты собственных действий, корректировал стратегию, генерировал код, создавал отчёты и поддерживал непрерывный цикл атаки. Модель работала с огромной скоростью, обрабатывая тысячи запросов, часто по несколько в секунду. При этом наблюдались и “галлюцинации” ( ошибки в интерпретации данных, вымышленные креды).
Anthropic блокировала атаку, усилила фильтры и начала делиться сигналами с партнёрами. Полный отчет здесь.
❗️Почему это важно?
Кейс показывает, что угрозы, связанные с agentic AI, перестали быть теорией.
Командам разработки необходимо переосмыслить процессы безопасности, чтобы предотвращать опасные действия агента на этапе намерения, а не в момент инцидента, например:
▪️ Создавать для агента ограниченную среду (sandbox), выдавать минимально необходимые инструменты и запрещать прямой доступ к продовым сервисам.
▪️ Прослойка между моделью и внешними системами должна фильтровать вредоносные запросы, ограничивать действия агента и мониторить инструменты, которыми он может пользоваться.
▪️Проверять устойчивость модели к попыткам обмана, скрытых команд и цепочек действий, которые могут привести к несанкционированным операциям.
▪️Отслеживать аномальные паттерны активности агента: бурст-трафик, нетипичные цепочки действий, попытки обойти политики. Реагирование должно быть автоматическим — с мгновенной блокировкой ключей и инструментов.
▪️Прописать регламенты для сотрудников (уровни доступа, контроль над внешними AI-сервисами, запрет на ввод чувствительных данных и т.д.)
▪️Руководство по Agentic AI Red Teaming |Cloud Security Alliance;
▪️Как злоумышленники используют ИИ в 2025 году;
#BehindTheMachine
————
@pattern_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
OWASP AI Testing Guide v1
OWASP выпустила первый открытый стандарт AI Testing Guide v1 для надежности ИИ-систем и LLM.
Повторяемые тестовые случаи, которые оценивают риски в следующих областях:
🔹AI Data layer ( проверка качества данных, data-poisoning (отравление), приватности, устойчивости к дрейфу данных).
🔹AI Model layer ( robustness / adversarial testing: устойчивость к adversarial-вводам, проверка на backdoor, model-stealing, model-inversion, оценка стабильности модели, проверка explainability/interpretability).
🔹AI Application / API layer (тесты для сервисов: fuzzing / injection, валидация вводов, проверка авторизаций, ограничений, устойчивости к неправильно сформированным или злонамеренным запросам).
🔹AI Infrastructure / MLOps / Deployment layer ( безопасность пайплайнов: CI/CD, хранение секретов, управление зависимостями, контейнеризацией, мониторинг, логирование, безопасное развёртывание и обновления).
🔹Continuous testing & governance ( регулярные тесты, мониторинг дрифтов (данных и модели), проверка изменений, отчётность, контроль качества и соответствие требованиям безопасности / этики на протяжении всего жизненного цикла системы).
#AIShelf #BehindTheMachine
————
@pattern_ai
OWASP выпустила первый открытый стандарт AI Testing Guide v1 для надежности ИИ-систем и LLM.
Повторяемые тестовые случаи, которые оценивают риски в следующих областях:
🔹AI Data layer ( проверка качества данных, data-poisoning (отравление), приватности, устойчивости к дрейфу данных).
🔹AI Model layer ( robustness / adversarial testing: устойчивость к adversarial-вводам, проверка на backdoor, model-stealing, model-inversion, оценка стабильности модели, проверка explainability/interpretability).
🔹AI Application / API layer (тесты для сервисов: fuzzing / injection, валидация вводов, проверка авторизаций, ограничений, устойчивости к неправильно сформированным или злонамеренным запросам).
🔹AI Infrastructure / MLOps / Deployment layer ( безопасность пайплайнов: CI/CD, хранение секретов, управление зависимостями, контейнеризацией, мониторинг, логирование, безопасное развёртывание и обновления).
🔹Continuous testing & governance ( регулярные тесты, мониторинг дрифтов (данных и модели), проверка изменений, отчётность, контроль качества и соответствие требованиям безопасности / этики на протяжении всего жизненного цикла системы).
#AIShelf #BehindTheMachine
————
@pattern_ai
Утечка Mixpanel/OpenAI или как аналитика снова подвела
OpenAI подтвердила инцидент утечки у стороннего провайдера аналитики Mixpanel.
Mixpanel обнаружил несанкционированный доступ 9 ноября 2025 года, уведомила OpenAI 25 ноября.
Затронутые данные (только API-продукты OpenAI):
- имя, которое было предоставлено в учетной записи API;
- адрес электронной почты, связанный с учетной записью API;
- примерное местоположение на основе API браузера пользователя (город, штат, страна);
- OC и браузер, используемые для доступа к учетной записи API;
- ссылающиеся сайты;
- идентификаторы организаций или пользователей, связанные с учетной записью API.
Нет полной информации о том, как долго был доступ, сколько пользователей затронуто, ограничилась ли утечка объявленными полями.
OpenAI немедленно удалила Mixpanel и начала проверку всех сторонних поставщиков.
👀 В чем риск для пользователей?
Эта комбинация данных точно подтверждает, что вы являетесь клиентом OpenAI API = отличная база для персонализированного фишинга и попыток выманить API-ключи.
Если пользователь использовал то же имя пользователя (email) и простой пароль на другом сайте = риск взлома.
Что сделать пользователям OpenAI API:
▪️ включите MFA/2FA (+ на почте, связанной с аккаунтом и на всех корпоративных учетных записях, связанных с API);
▪️проявите высокую бдительность к фишингу ( не переходите по ссылкам в подозрительных письмах, не вводите пароли или ключи API в ответ на email/смс/чат, проверяйте домен отправителя);
▪️ротация ключей API ( сгенерировать новые ключи API и отозвать старые, особенно если вы беспокоитесь о том, что ключи могли быть случайно зарегистрированы в аналитических событиях).
▪️ограничьте права ключей и используйте scoped keys;
▪️убедитесь, что все разработчики и администраторы вашей организации, использующие API, проинформированы о риске фишинга.
✏️ Уроки, которые необходимо извлечь на будущее:
🔹Минимизация данных. Вы действительно отправляете email в сторонние аналитические системы? В 95% случаев нет необходимости. Cобирайте только те данные, которые абсолютно необходимы для выполнения задачи.
🔹Карта потоков данных. У вас должна быть точная карта того, какие PII передаются каждому сервису.
Если вы не знаете, то это главный риск.
🔹Аудит поставщиков. Есть ли у них MFA для всех сотрудников? Какой план реагирования на инциденты согласован с вашим? Посмотрите на примере Mixpanel.
🔹Сегментация и изоляция сред. Обеспечивает ли архитектура систем полную изоляцию данных? Если взламывают систему аналитики, гарантирует ли это, что никакие данные, кроме аналитических, не могут быть скомпрометированы (например, ключи API, пароли)?
🔹Скорость реакции на инцидент. В этом кейсе прошло 16 дней.....У вас должен быть план на случай утечки: отзыв ключей, уведомление пользователей, восстановление доступа, ограничение дальнейших рисков.
#UXWatch #BehindTheMachine
————
@pattern_ai
OpenAI подтвердила инцидент утечки у стороннего провайдера аналитики Mixpanel.
Mixpanel обнаружил несанкционированный доступ 9 ноября 2025 года, уведомила OpenAI 25 ноября.
Затронутые данные (только API-продукты OpenAI):
- имя, которое было предоставлено в учетной записи API;
- адрес электронной почты, связанный с учетной записью API;
- примерное местоположение на основе API браузера пользователя (город, штат, страна);
- OC и браузер, используемые для доступа к учетной записи API;
- ссылающиеся сайты;
- идентификаторы организаций или пользователей, связанные с учетной записью API.
Нет полной информации о том, как долго был доступ, сколько пользователей затронуто, ограничилась ли утечка объявленными полями.
OpenAI немедленно удалила Mixpanel и начала проверку всех сторонних поставщиков.
Эта комбинация данных точно подтверждает, что вы являетесь клиентом OpenAI API = отличная база для персонализированного фишинга и попыток выманить API-ключи.
Если пользователь использовал то же имя пользователя (email) и простой пароль на другом сайте = риск взлома.
Что сделать пользователям OpenAI API:
▪️ включите MFA/2FA (+ на почте, связанной с аккаунтом и на всех корпоративных учетных записях, связанных с API);
▪️проявите высокую бдительность к фишингу ( не переходите по ссылкам в подозрительных письмах, не вводите пароли или ключи API в ответ на email/смс/чат, проверяйте домен отправителя);
▪️ротация ключей API ( сгенерировать новые ключи API и отозвать старые, особенно если вы беспокоитесь о том, что ключи могли быть случайно зарегистрированы в аналитических событиях).
▪️ограничьте права ключей и используйте scoped keys;
▪️убедитесь, что все разработчики и администраторы вашей организации, использующие API, проинформированы о риске фишинга.
Инцидент подтверждает, что сторонние поставщики аналитики являются одними из самых слабых звеньев.
✏️ Уроки, которые необходимо извлечь на будущее:
🔹Минимизация данных. Вы действительно отправляете email в сторонние аналитические системы? В 95% случаев нет необходимости. Cобирайте только те данные, которые абсолютно необходимы для выполнения задачи.
🔹Карта потоков данных. У вас должна быть точная карта того, какие PII передаются каждому сервису.
Если вы не знаете, то это главный риск.
🔹Аудит поставщиков. Есть ли у них MFA для всех сотрудников? Какой план реагирования на инциденты согласован с вашим? Посмотрите на примере Mixpanel.
🔹Сегментация и изоляция сред. Обеспечивает ли архитектура систем полную изоляцию данных? Если взламывают систему аналитики, гарантирует ли это, что никакие данные, кроме аналитических, не могут быть скомпрометированы (например, ключи API, пароли)?
🔹Скорость реакции на инцидент. В этом кейсе прошло 16 дней.....У вас должен быть план на случай утечки: отзыв ключей, уведомление пользователей, восстановление доступа, ограничение дальнейших рисков.
#UXWatch #BehindTheMachine
————
@pattern_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
👏2
Подборка по ключевым рубрикам:
🔹Может ли ИИ быть автором, что говорят законы сегодня;
🔹Как использовать ИИ в играх легально;
🔹Как использовать ИИ в рекламе и не нарушить закон;
🔹Как запустить ИИ- блогера и не нарушить закон;
🔹Попытки платформ обеспечить прозрачность ИИ-контента;
🔹Чек-лист по этическим и юридическим стандартам для операторов ИИ-блогеров и ИИ-контента;
🔹Новые законы в США по регулированию ИИ-компаньонов;
🔹Нидерланды упростили EU AI Act до гайда в 21 страницу ;
🔹EU AI Act: Еврокомиссия предлагает важные изменения;
🔹ЕС требует новых правил для защиты детей, в том числе от ИИ;
🔹Италия первой в ЕС вводит уголовную ответственность за преступления с использованием ИИ;
🔹Обновлены рекомендации EDPS по генеративному ИИ;
🔹Как превратить европейскую отчётность в инструмент доверия и качества;
🔹Маркировка ИИ контента в Китае стала обязательной;
🔹Почему нам стоит посмотреть на опыт Египта в AI-регулировании;
🔹У вас есть юзеры из Южной Кореи? Готовьтесь к требованиям Закона "О развитии ИИ";
🔹Ваши пользователи из Индии? Смотрим новые AI Guidelines;
🔹AI Governance в Африке;
🔹AI Regulation Global Guide или правила игры в 12 юрисдикциях;
🔹Кейс GEMA vs OpenAI или как ИИ выучил песни слишком хорошо;
🔹Deepfake в суде (дело Mendones v. Cushman & Wakefield);
🔹Как адаптировать ИИ-сервис для нового рынка;
🔹18+ или ChatGPT скоро “повзрослеет” и это не совсем безопасно;
🔹Риски использования ChatGPT Atlas;
🔹Троянский конь Meta Camera Roll;
🔹Эмоциональная зависимость от ChatGPT;
🔹Как ИИ меняет поведение людей и наоборот;
🔹Как тёмные паттерны обманывают LLM-веб-агентов;
🔹Катастрофические риски ИИ;
🔹Когда промпт становится уликой;
🔹ИИ в медицине: между потенциалом и реальностью;
🔹ИИ в школах: урок Ирландии по безопасному внедрению;
🔹ИИ и инклюзивное образование;
🔹Чистые наборов данных или как OECD формирует доверие к ИИ на практике ;
🔹Автоматизация исследовательской работы от Deutsche Bank;
🔹Насколько опасен ИИ в юриспруденции;
🔹10 минут вместо 10 часов, а как честно биллинговать работу с ИИ, например юристам?
🔹Утечка Mixpanel/OpenAI или как аналитика снова подвела;
🔹Как получить реальный ROI от ИИ: отчет и советы от Google;
🔹Первая «законопослушная» AI-модель Европы;
🔹Покупка ИИ-инструментов: на что обратить внимание перед подписанием контракта;
🔹Как превратить Office в умный редактор;
🔹AI Leadership Blueprint: чек-листы, метрики и готовые шаблоны для компаний и гос.оранов от Университета Юты;
🔹Как на самом деле используют ChatGPT;
🔹AI in Courts - Insights from South Korea, Australia, and Singapore;
🔹Как ЕС учиться измерять мощность и риски GPAI;
🔹Инструмент проверки соответствия AI Act от Еврокомиссии;
🔹Шаблон политики в области ИИ от Австралийского правительства;
🔹Как разработчики ИИ управляют рисками: первый сводный отчёт по Хиросимскому процессу;
🔹Исследование Microsoft: как используется ИИ;
🔹The Annual AI Governance Report 2025: Steering the Future of AI;
🔹Как злоумышленники используют ИИ в 2025 году;
🔹Отчет "GenAI, Fake Law & Fallout";
🔹Новое Руководство по управлению рисками систем ИИ от EDPS;
🔹65 сценариев использования ИИ-агентов от Stack AI;
🔹Лекции Гарварда про ИИ бесплатные;
🔹Первая атака, проведённая ИИ-агентом;
🔹OWASP AI Testing Guide v1;
📚#TalkPrompty
🔹Промпт для проверки DPA от DataGrail;
🔹Sora 2 и как создавать своих ИИ-блогеров;
🔹Библиотеки промптов;
🔹Обучающие гайды по ИИ от Google, Perplexity и OpenAI;
Читайте, пересылайте, возвращайтесь к важному.
————
@pattern_ai
Please open Telegram to view this post
VIEW IN TELEGRAM
👍3
Ошибки Eurostar AI: когда чат-бот «сошел с рельсов»
Исследователи Pen Test Partners проанализировали чат-бот Eurostar и показали, что даже при использовании языковой модели и защитных ограничений система может быть уязвимой из-за ошибок в архитектуре и процессе разработки.
👀 Обнаруженные проблемы:
▪️ Обход защитных ограничений ( проверки применялись только к последнему сообщению, а не ко всему контексту диалога, что позволяло изменять предыдущие сообщения и внедрять вредоносные инструкции)
▪️ Prompt injection (манипуляции с входными данными позволяли модели раскрывать служебную информацию (настройки, тип модели).
▪️HTML / self-XSS ( ответы бота отображались как HTML без экранирования, что позволяло внедрять скрипты в интерфейс чата).
▪️Отсутствие серверной проверки идентификаторов (идентификаторы сообщений и диалогов не проверялись на сервере, что позволяло подменять или повторно использовать контекст).
Там же и рекомендации для разработчиков чат-ботов:
▪️системные подсказки и ограничения использовать как механизм безопасности, а не как настройку поведения модели.
▪️чётко определять роли модели (что она может делать и какие действия запрещены).
▪️разделять инструкции и данные (любой пользовательский ввод, а также контент с сайтов и документов следует считать потенциально небезопасным и а не как дополнительную системную подсказку).
▪️применять принцип минимальных привилегий (предоставлять модели только те инструменты, данные и действия, которые ей действительно необходимы для конкретного сценария).
▪️проверять и очищать все входные данные (текст, идентификаторы, закодированные параметры, внешний контент), как при работе с любым API.
▪️не отображать вывод модели напрямую как HTML ( по умолчанию использовать обычный текст, а расширенный формат только через строго разрешённый список элементов без скриптов и обработчиков событий).
▪️контроль и проверку реализовывать только на сервере ( идентификатор сообщения, идентификатор диалога, содержимое сообщения и результат проверки должны объединяться в криптографически проверяемую подпись, которую сервер проверяет при каждом запросе). Идентификаторы сообщений и диалогов должны создаваться на сервере, быть привязаны к конкретной сессии, а любые попытки повторного использования или смешивания истории из разных чатов должны отклоняться.
▪️после развертывания вести журнал событий и мониторинг ( фиксировать все взаимодействия с моделью, решения механизмов защиты и использование функций, настраивать оповещения о подозрительной активности и иметь аварийный выключатель для быстрого отключения бота или его инструментов).
#BehindTheMachine
————
@pattern_ai
Исследователи Pen Test Partners проанализировали чат-бот Eurostar и показали, что даже при использовании языковой модели и защитных ограничений система может быть уязвимой из-за ошибок в архитектуре и процессе разработки.
▪️ Обход защитных ограничений ( проверки применялись только к последнему сообщению, а не ко всему контексту диалога, что позволяло изменять предыдущие сообщения и внедрять вредоносные инструкции)
▪️ Prompt injection (манипуляции с входными данными позволяли модели раскрывать служебную информацию (настройки, тип модели).
▪️HTML / self-XSS ( ответы бота отображались как HTML без экранирования, что позволяло внедрять скрипты в интерфейс чата).
▪️Отсутствие серверной проверки идентификаторов (идентификаторы сообщений и диалогов не проверялись на сервере, что позволяло подменять или повторно использовать контекст).
Там же и рекомендации для разработчиков чат-ботов:
▪️системные подсказки и ограничения использовать как механизм безопасности, а не как настройку поведения модели.
▪️чётко определять роли модели (что она может делать и какие действия запрещены).
▪️разделять инструкции и данные (любой пользовательский ввод, а также контент с сайтов и документов следует считать потенциально небезопасным и а не как дополнительную системную подсказку).
▪️применять принцип минимальных привилегий (предоставлять модели только те инструменты, данные и действия, которые ей действительно необходимы для конкретного сценария).
▪️проверять и очищать все входные данные (текст, идентификаторы, закодированные параметры, внешний контент), как при работе с любым API.
▪️не отображать вывод модели напрямую как HTML ( по умолчанию использовать обычный текст, а расширенный формат только через строго разрешённый список элементов без скриптов и обработчиков событий).
▪️контроль и проверку реализовывать только на сервере ( идентификатор сообщения, идентификатор диалога, содержимое сообщения и результат проверки должны объединяться в криптографически проверяемую подпись, которую сервер проверяет при каждом запросе). Идентификаторы сообщений и диалогов должны создаваться на сервере, быть привязаны к конкретной сессии, а любые попытки повторного использования или смешивания истории из разных чатов должны отклоняться.
▪️после развертывания вести журнал событий и мониторинг ( фиксировать все взаимодействия с моделью, решения механизмов защиты и использование функций, настраивать оповещения о подозрительной активности и иметь аварийный выключатель для быстрого отключения бота или его инструментов).
#BehindTheMachine
————
@pattern_ai
Please open Telegram to view this post
VIEW IN TELEGRAM