Стандарт аудита AI-продукта и AI-внедрения

Актуальность: 2 августа 2026 года.

Цель и границы

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

Стандарт применим к внутренней автоматизации, AI-функции существующего продукта и AI-стартапу. Он не заменяет юридическую, отраслевую или техническую сертификацию.

Профессиональные ориентиры:

• NIST AI Risk Management Framework и профиль для generative AI: Govern, Map, Measure и Manage;
• ISO/IEC 42001:2023 — система управления AI;
• ISO/IEC 23894:2023 — управление рисками AI;
• OWASP GenAI Security Project — практические классы угроз для LLM/GenAI-приложений.

Использование ориентиров не означает соответствие или сертификацию.

Нулевой вопрос: нужен ли AI

Сравнить не менее пяти вариантов:

1. изменить или убрать сам процесс;
2. инструкция/обучение человека;
3. правила, поиск, шаблон или обычная автоматизация;
4. готовый AI-сервис или функция существующего продукта;
5. интеграция модели либо собственная разработка/обучение.

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

Карта применения

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

Риск оценивается по конкретному use case, а не по названию модели.

Ценность и продукт

• подтвердить проблему прошлым поведением и затратами клиента;
• определить baseline человека/обычной автоматизации;
• измерить время до ценности, качество результата и изменение бизнес-метрики;
• проверить готовность изменить workflow, а не интерес к AI;
• отделить wow-эффект от повторного использования и оплаты;
• определить, кто проверяет ответ и кто отвечает за последствие;
• не продавать вероятностный результат как гарантированный факт.

Данные и права

Проверить происхождение, правовое основание, качество, полноту, смещение, актуальность и возможность удаления данных. Отдельно:

• персональные, коммерческие, клиентские и отраслево регулируемые данные;
• локализация, трансграничная передача и условия внешнего API;
• права на датасеты, код, контент, embeddings, feedback и выходы;
• лицензии модели, open source-компонентов и ограничения коммерческого применения;
• использование клиентских данных для обучения/улучшения;
• удаление, retention, резервные копии и выполнение запросов субъекта/клиента.

Российский контур проверять по RU_LEGAL_TAX.md и актуальным официальным источникам; иностранный провайдер не снимает обязанностей бизнеса.

Оценка качества

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

• метрику, порог и baseline;
• правила эталонной оценки и разногласий экспертов;
• качество по существенным сегментам, а не только среднее;
• factuality/grounding, полноту, отказ и устойчивость к изменению формулировки;
• цену разных типов ошибки;
• модель, prompt, параметры, источники и дату теста;
• деградацию после смены модели, данных или процесса.

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

Human-in-the-loop

Определить:

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

«Человек проверяет» не является контролем, если у него нет времени, данных, полномочий или способа обнаружить ошибку.

Безопасность и злоупотребления

• prompt injection и недоверенный внешний контент;
• утечка system prompt, данных, истории, ключей и результатов других клиентов;
• чрезмерные права агента и небезопасный вызов инструментов;
• отравление базы знаний/обучающих данных;
• уязвимые зависимости, модели и цепочка поставок;
• вредный контент, мошенничество, impersonation и автоматический спам;
• неконтролируемые расходы, циклы агента и denial of wallet;
• мониторинг, rate limit, разделение арендаторов, rollback и incident response.

Агенту сначала давать read-only, минимальные данные, allowlist действий и человеческое подтверждение внешнего или необратимого эффекта.

Экономика и зависимость

[TCO](core/ABBREVIATIONS.md#abbr-tco) AI = интеграция + данные + inference/лицензии + инфраструктура
       + оценка качества + человеческая проверка + поддержка
       + безопасность/соответствие + цена ошибок и простоев
ценность = дополнительный вклад + экономия подтверждённого труда
         + предотвращённый ожидаемый ущерб

Проверять чувствительность к объёму, длине контекста, повторным вызовам, курсу, цене провайдера, ручной проверке и росту поддержки. Записать переносимость: альтернативная модель, экспорт данных, смена API и режим без AI.

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

• baseline ручного процесса и вариант автоматизации без AI;
• лимит стоимости на результат и общий месячный budget cap;
• доля результатов, требующих проверки/переделки, и цена ошибки;
• тестовый экспорт данных, перечень провайдерских расширений и срок миграции;
• минимальный режим работы при недоступности модели;
• триггер повторного выбора провайдера: цена, качество, лицензия, данные или SLA.

Vendor lock-in принят осознанно только при оценённой цене выхода и владельце плана. Абстракция ради абстракции не нужна: переносимость должна окупать риск.

Этапы допуска

1. Проблема: есть наблюдаемая задача и baseline.
2. Offline evaluation: качество и опасные случаи проходят заранее заданный порог.
3. Shadow/read-only: система не влияет на клиента или данные без проверки.
4. Ограниченный пилот: малый сегмент, лимиты, мониторинг и откат.
5. Рабочий запуск: владелец, SLA, затраты, инциденты и повторная оценка.
6. Масштабирование: доказана экономика и устойчивость при объёме.

На каждом этапе заранее определены критерии допуска, остановки и возврата.

Итог аудита

• решение: без AI / готовый сервис / интеграция / разработка / отложить;
• карта ценности, данных, рисков и ответственности;
• воспроизводимая оценка качества и baseline;
• TCO, диапазон эффекта и зависимость от провайдера;
• обязательные правовые/безопасностные исправления;
• пилот с лимитом, владельцем, критериями и rollback.