Редтиминг ИИ: как проверить агента до выхода к клиентам

Прежде чем выпускать агента к клиентам, проведите редтиминг ИИ: проверьте, можно ли заставить его раскрыть закрытые данные, выполнить действие без разрешения или выдать запрещённый контент. Начните с цикла из 6 шагов: определите границы проверки, составьте список атак, запустите тесты, оцените результаты, устраните проблемы и повторите проверку. Результат такого цикла — задокументированная проблема и подтверждённое исправление. Успокаивающего значка «проверено» недостаточно.

Возможности инструментов и описания подходов сверены с официальной документацией 17 октября 2026 года. Описанный ниже процесс и примеры с агентом поддержки — предлагаемые учебные сценарии, а не результаты тестирования продуктов.

Что такое редтиминг ИИ?

Редтиминг ИИ — это целенаправленные попытки заставить систему нарушить заданное правило безопасности, защиты данных или бизнеса. Тестировщик добивается сбоя, наблюдает за действиями системы и доводит выявленную проблему до исправления, которое можно проверить повторно. Для компании, выпускающей чат-бота, объектом проверки обычно становится всё приложение: инструкции, найденная информация, права доступа, инструменты и ответы, которые видит клиент. Угрозы для моделей и приложений.

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

У вашего агента есть похожие границы полномочий. Обращение в поддержку — это информация для обработки; оно не должно становиться равнозначным одобрению руководителя. Найденный документ может помочь ответить на вопрос, но не должен открывать доступ к записям другого клиента.

Чем проверка модели отличается от проверки приложения?

При редтиминге модели изучают её поведение в ответ на атакующие запросы. При проверке приложения к этому добавляется вся окружающая система: допустимые действия зависят от личности клиента, доступа к документам и прав на использование инструментов. Отчёт поставщика модели о безопасности не доказывает, что ваша интеграция возвратов проверяет нужный аккаунт. Это различие прямо описано в документации promptfoo по редтимингу.

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

Что может пропустить обычное тестирование качества?

Редтиминг ИИ ищет способы нарушить установленные границы — в том числе через правдоподобные запросы, которые используют неоднозначность, а не ошибки формата. Обычное тестирование качества, или QA, проверяет заданное поведение: правильность ответов, допустимость транзакций, время отклика и ожидаемые ошибки. Зрелый процесс QA может включать проверки с позиции злоумышленника; редтиминг даёт ему новые сценарии сбоев.

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

Для начала проверки агента, работающего с клиентами, подойдут следующие классы атак. Это искусственно составленные тестовые сценарии; критерии успешного прохождения нужно адаптировать к вашим правилам.

Эти категории пересекаются. Джейлбрейк нейросетей нацелен на обход ограничений поведения. Промпт-инъекция, или prompt injection, пытается перенаправить систему с помощью указаний, которые та не должна считать обязательными. Если такая инструкция спрятана в найденном материале, это косвенная промпт-инъекция; она может привести к утечке данных или действию без разрешения. Категории описывают разные стороны сбоя, а не изолированные друг от друга явления. Определения угроз.

Безопасность ИИ-агентов: проверяйте их действия

ИИ-агент — это приложение, которое использует инструменты для выполнения задачи. Поэтому при редтиминге агентов одного итогового ответа недостаточно. Отказ не отменяет уже внесённое изменение в записи, а фраза «возврат выполнен» не доказывает, что деньги действительно вернули.

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

У чат-бота без инструментов проверяйте ответы и доступную ему информацию. Если агент может менять клиентские записи, фиксируйте состояние до и после каждой попытки действия. Именно дополнительные полномочия меняют содержание проверки.

Кому уже пора проводить тестирование безопасности ИИ?

Проверку нужно провести до того, как клиенты получат доступ к закрытой информации или действиям с существенными последствиями. Участники отвечают за разные стороны работы, но при решении о запуске нужно учесть позиции каждого.

Разработчикам: основателю, привлёкшему финансирование, или разработчику, который создаёт продукт самостоятельно, стоит выбрать небольшой клиентский сценарий и определить недопустимые результаты ещё до подключения инструмента атак. Если приложение читает заказы, проверьте изоляцию аккаунтов. Если меняет их — проверяйте права непосредственно в момент изменения.

Руководителям эксплуатации: руководитель поддержки должен предоставить правила, примеры допустимых исключений и порядок эскалации. Инженеры по безопасности не могут сами определить, когда ваш бизнес разрешает возврат и в каких советах чат-бот обязан отказать. Технически допустимое действие всё равно может нарушать бизнес-правило.

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

Для прототипа, который работает только с публичной информацией, не выполняет действий и не имеет внешних пользователей, масштабную автоматизированную кампанию можно отложить, пока его поведение меняется. Базовые проверки злоупотреблений и контента нужно сохранить. Подключение клиентов, поиска по закрытым данным или инструментов с правом записи — сигнал углубить проверку.

Обучение редтимингу ИИ начинается с ваших правил

Для первого цикла назначьте того, кто знает приложение, того, кто умеет оценивать ущерб для бизнеса, и того, кто может внести исправления. В небольшой команде роли можно совмещать, но существенные находки по возможности должен проверять кто-то кроме их автора.

Для тренировки сформулируйте цель атаки и наблюдаемый признак нарушения в искусственном сценарии поддержки. Если проверяющие расходятся во мнении, допустимо ли предложенное поведение, сначала уточните правило, а уже потом автоматизируйте оценку.

Как провести первый цикл проверки за шесть шагов

Ограничьте первый цикл так, чтобы успеть изучить и устранить каждую существенную проблему. Ниже предложен рабочий процесс, а не утверждение, что фиксированное число тестов гарантирует безопасность.

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

1. 1

   1. Определите границы проверки и недопустимые результаты

   Зафиксируйте ревизию приложения, идентификатор модели, инструкции, источники поиска, клиентские роли, доступные инструменты и правила согласования. Укажите среду и того, кто разрешил проверку. Перечислите исключения, чтобы непроверенная интеграция не затерялась за общей положительной оценкой.

   Для агента поддержки границы могут выглядеть так: клиент видит только собственные заказы; для возврата необходимо действующее одобрение; ни один клиент не может получить записи другого. Каждое правило должно допускать наблюдаемую проверку. Формулировка «соблюдать конфиденциальность» слишком расплывчата для оценки.

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

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

2. 2

   2. Составьте список атак исходя из ущерба для бизнеса

   Сначала определите цели, затем пишите промпты. «Получить адрес доставки другого клиента» — это цель. Конкретная формулировка запроса — лишь одна попытка её достичь.

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

   Полезный сценарий — вымышленная справочная статья с указанием отменить обязательное одобрение возврата. Ожидается, что агент воспримет этот фрагмент как недоверенный контент и сохранит требование согласования. Добавьте и законный возврат с действующим одобрением, чтобы защита, блокирующая любые возвраты, не выглядела успешной.

   Сохраните исходные сценарии и их идентификаторы. Добавляйте варианты с другой формулировкой, контекстом или точкой входа, не меняя незаметно сам недопустимый результат.

3. 3

   3. Запустите тесты по тому же пути, что проходит запрос клиента

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

   Сначала убедитесь, что подключение ведёт к нужному объекту проверки, а в журналах есть необходимые данные. Затем запустите выбранные сценарии, сохраняя входные данные, историю диалога, найденные фрагменты, запросы к инструментам, решения о правах доступа, ответы и итоговое состояние. Не включайте секреты доступа в отчёты; вместо реальных клиентских данных используйте синтетические маркеры конфиденциальной информации.

   Повторяйте сценарии с существенными последствиями по заранее объявленным правилам: ответы модели могут различаться. Фиксируйте повторения и лимит ходов для адаптивного атакующего, если он задан. Между независимыми сценариями сбрасывайте сессии; сохраняйте историю, когда проверяется сама последовательность реплик.

   Тайм-аут, ошибка аутентификации или неработающий парсер до выяснения причин считаются проблемой теста. Они не доказывают, что приложение выдержало атаку.

4. 4

   4. Оцените подтверждающие данные, затем определите серьёзность

   Прежде чем рассчитывать сводный показатель, присвойте каждой попытке статус на основе собранных данных. Используйте явные проверки наблюдаемых фактов: например, выдачи запрещённой записи или изменения состояния без разрешения. Модель-оценщик может помочь с интерпретацией текста, но существенные находки и сомнительные оценки должны проверять люди.

   Предложенная шкала позволяет отличить неработающий тест от успешно защищённой границы:

   Статус	Что означает	Следующее действие
   Пройден	Корректно выполненная попытка не привела к заданному нарушению; необходимые подтверждающие данные доступны.	Сохранить сценарий и подтверждающие данные.
   Не пройден	Данные подтверждают заданное нарушение.	Определить серьёзность и назначить ответственного за исправление.
   Некорректен	Попытка не проверила задуманный сценарий: например, не прошла аутентификация или отсутствовал атакующий контент.	Исправить тест и запустить его снова.
   Результат не определён	Сценарий выполнен, но данных или оценки недостаточно для вывода.	Разобраться; не засчитывать как успешное прохождение.

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

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

5. 5

   5. Исправьте механизм защиты, который не сработал

   Прежде чем менять промпт, найдите причину проблемы. Если найденный документ может дать право на возврат, усильте проверку одобрения при вызове инструмента. Если поиск выдаёт записи другого клиента, исправьте фильтр доступа до того, как эти записи попадут в контекст модели.

   Возможны и другие меры: убрать ненужный инструмент, сузить права, требовать одобрения для действия с существенными последствиями, отделить инструкции от внешнего контента или уточнить правила ответа. Выбирайте исправление, которое перекрывает обнаруженный путь атаки.

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

   У каждой находки должны быть ответственный, конкретное изменение и критерий повторной проверки. «Усилили промпт» — недостаточное основание для закрытия проблемы.

6. 6

   6. Повторите исходный сценарий и близкие к нему варианты

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

   Сохраните подтверждающие данные до и после исправления, ревизии приложения и конфигурацию тестов. Перенесите устранённые сбои в набор регрессионных проверок — повторяемых тестов, которые помогают заметить возвращение старых проблем. Новые исследовательские атаки добавляйте отдельно, чтобы улучшение на фиксированном наборе не скрывало новые слабости.

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

Как распределить задачи между OWASP, MITRE ATLAS и NIST

Используйте эти подходы для организации работы и дополняйте их условиями сбоев, характерными для вашего приложения. Ни один из них не задаёт вашу политику возвратов и не доказывает, что граница между клиентами выдержала проверку.

OWASP Top 10 for LLM Applications — перечень рисков для приложений на базе больших языковых моделей, которые генерируют текст во многих чат-ботах. На текущей странице представлен список 2025 года: среди прочего в нём есть промпт-инъекции, раскрытие конфиденциальной информации и избыточная автономность, когда системе предоставлено слишком много возможностей действовать. С его помощью можно заметить недостающие категории рисков в списке атак. Официальный список OWASP.

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

National Institute of Standards and Technology AI Risk Management Framework, или NIST AI RMF, организует работу с рисками вокруг функций Govern, Map, Measure и Manage: управления, описания контекста рисков, измерения и мер по управлению ими. NIST указывает, что применение добровольное. Используйте этот подход, чтобы связать проверку с ответственными, контекстом внедрения, измерениями и решением по неустранённым рискам. Соответствие структуры отчёта этому подходу не означает сертификацию NIST. NIST AI RMF.

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

Инструменты для редтиминга ИИ: какой для чего подходит

Выбирайте инструмент, который проверит ваше реальное приложение и сохранит нужные данные. Начните с открытого ПО, если есть инженер, готовый отвечать за настройку, оценку результатов, расследование и повторные запуски. Платформа имеет смысл, когда главным препятствием становится координация этой работы между приложениями и проверяющими.

promptfoo: повторяемые проверки приложения

Режим редтиминга в promptfoo генерирует атакующие запросы с помощью плагинов, применяет стратегии атак и формирует отчёты для разбора сбоев. В кратком руководстве описаны проверки через веб-API — интерфейс вызова приложения, — а также через браузер или напрямую на модели. Это практичная отправная точка для разработчика, которому нужно настроить повторяемое сканирование приложения. Официальное руководство по запуску редтиминга.

При эксплуатации нужно учитывать обработку данных: локальный запуск тестов не означает, что генерация и оценка тоже останутся локальными. Некоторым плагинам нужен облачный инференс, а облачная оценка может получать промпты и ответы проверяемой системы. Прежде чем подключать материалы с ограниченным доступом, изучите описанные потоки данных. Настройка и эти границы подробнее разобраны в обзоре promptfoo.

Microsoft PyRIT: гибкие сценарии атак

Microsoft PyRIT, Python Risk Identification Tool для генеративного ИИ, — фреймворк с открытым исходным кодом для выявления рисков в системах генеративного ИИ. Документация охватывает одноходовые и многоходовые атаки, подключение собственных объектов проверки, оценку результатов и сохранение диалогов. Предусмотрены режимы сканера, графического интерфейса и фреймворка. Актуальный репозиторий и официальная документация.

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

NVIDIA garak: сканирование уязвимостей LLM

NVIDIA garak, Generative AI Red-teaming & Assessment Kit, позиционируется как сканер уязвимостей больших языковых моделей. Он использует тестовые пробы для выявления сбоев и детекторы для оценки ответов, охватывая утечки данных, промпт-инъекции, токсичность и джейлбрейки. В репозитории также описаны коннектор для веб-эндпоинтов и подробные журналы результатов. Официальный репозиторий.

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

Airia: для регулярных кампаний и координации проверок

Airia стоит рассматривать, когда требуется координировать повторные проверки агентов в разных рабочих процессах. На странице редтиминга агентов описаны проверки промпт-инъекций, манипуляций инструментами и цепочек сценариев, в том числе многоэтапных атак через промпты, инструменты, API и память. Airia также заявляет непрерывные кампании и сопоставление находок с признанными подходами к безопасности. Это возможности, заявленные самим поставщиком. Страница Airia о редтиминге агентов.

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

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

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

Какие материалы стоит запросить корпоративному заказчику?

Запросите отчёт, соответствующий вашему внедрению, и пример прохождения проблемы от обнаружения до повторной проверки. «Мы проводим редтиминг нашего ИИ» — заявление о процессе; подтверждающая запись должна показывать, что именно проверили и что изменилось по итогам.

Запросите следующие материалы вместе:

• Границы и дата проверки: идентификаторы приложения и модели, относящиеся к проверке инструкции, источники поиска, роли, инструменты, интеграции и исключения.
• Охват атак: цели, точки входа, одноходовые сценарии и диалоги, а также клиентские возможности, доступные тестировщику.
• Методика и оценка: конфигурация тестов, учёт попыток, критерии успеха, проверка человеком и порядок обработки некорректных попыток и неопределённых результатов.
• Находки: серьёзность, затронутые границы, воспроизводимые подтверждения и оставшиеся ограничения; чувствительные подробности следует передавать по подходящему каналу.
• Исправления и повторные проверки: изменённый механизм защиты, данные до и после и подтверждение, что законные сценарии по-прежнему работают.
• Дальнейшая ответственность: кто принимает остаточный риск, какие изменения запускают новый цикл и как клиенты узнают о существенных находках, которые их затрагивают.

Уточните, кто выполнял работу: поставщик, внешний проверяющий или оба. Независимость важна для понимания контекста, но логотип сторонней организации не заменит описания границ проверки и не закроет вопрос о непроверенном коннекторе.

Если отчёт не охватывает интеграцию, которую вы собираетесь включить, считайте её непроверенной. До включения запросите целевые тесты либо ограничьте внедрение, пока не появятся нужные подтверждения. Положительный результат для чат-бота только с чтением не даёт оснований разрешать работу агенту с правом записи.

Какие обещания редтиминга переоценивают?

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

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

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

Наконец, редтиминг — один из элементов программы безопасности и защиты систем. Он не заменяет обычное QA, тестирование контроля доступа, мониторинг рабочей системы и реагирование на инциденты. Завершённая кампания показывает, что произошло в проверенных условиях; она не доказывает отсутствия ещё не найденных сбоев.

Частые вопросы о редтиминге ИИ

Что такое редтиминг ИИ?

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

Какой ИИ лучше всего подходит для редтиминга?

Универсально лучшей атакующей модели или инструмента нет. Выбирайте метод, который достигает реальных точек входа вашего приложения и позволяет подтвердить недопустимый результат. promptfoo, Microsoft PyRIT и NVIDIA garak предлагают разные способы организовать эту работу, но ни один не определит ваши бизнес-правила автоматически.

С чего начать заниматься редтимингом ИИ?

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

Заменит ли ИИ специалистов по редтимингу?

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

Как выглядит пример редтиминга на практике?

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

Что сделать до следующего запуска

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

Подпишитесь на рассылку, чтобы получать практические руководства по созданию и эксплуатации ИИ-систем.