Справочник SENAR: Приложение по управлению и комплаенсу

Это приложение сопоставляет практики SENAR с требованиями управления, регулирования и комплаенса для организаций с AI-нативными командами разработки. Оно адресовано специалистам по нормативному соответствию, аудиторам, юристам и руководителям инженерных подразделений, которые оценивают внедрение SENAR в регулируемых средах.

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

A. Модель ответственности

A.1 Принцип подотчётности

В SENAR супервайзер несёт ответственность за весь одобренный им результат AI. Это не делегирование ответственности AI-агенту, а явное принятие ответственности человеком, который направляет, проверяет и одобряет работу.

Цепочка подотчётности следует чёткому принципу:

AI генерирует. Человек одобряет. Человек несёт ответственность.

Этот принцип встроен в SENAR через шлюзы качества. Когда супервайзер проводит задачу через QG-2 (шлюз реализации), он подтверждает:

• CI проходит, тесты проходят, типы чистые (автоматизированная верификация);
• Критерии приёмки выполнены (человеческое суждение);
• Уязвимости безопасности не обнаружены (с помощью инструментов);
• Результат пригоден для целевого назначения (профессиональное суждение).

Это подтверждение значимо для комплаенса. Оно фиксируется, снабжается временной меткой и привязано к конкретному лицу.

A.2 Ответственность по шлюзам качества

Прохождение каждого шлюза — это задокументированное решение об одобрении, принятое конкретным человеком.

A.3 Ответственность при обходе шлюза

Стандарт SENAR Section 8.6(c) требует, чтобы обходы шлюзов включали обоснование, оценку рисков, план устранения и одобрение старшего сотрудника. С точки зрения комплаенса:

• Лицо, одобрившее обход, принимает на себя риск за все последующие последствия.
• Записи об обходах шлюзов ОБЯЗАНЫ сохраняться как аудиторские свидетельства.
• Организации РЕКОМЕНДУЕТСЯ отслеживать долю обходов шлюзов (Standard 8.6(d)) как метрику здоровья комплаенса.
• Аудиторам следует рассматривать повышенную долю обходов шлюзов как индикатор процессного давления, требующего расследования.

A.4 Пути эскалации

A.5 Совместная ответственность в конфигурациях Командная+

В конфигурациях Командная+ ответственность распределена между выделенными ролями:

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

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

B. Требования к аудиторскому следу

B.1 Артефакты SENAR как аудиторские свидетельства

Структура SENAR порождает следующие артефакты, каждый из которых является аудиторским свидетельством:

B.2 Соответствие шлюзов качества аудиторским свидетельствам

B.3 Демонстрация надлежащего наблюдения

Аудитор, оценивающий, был ли AI-сгенерированный код надлежащим образом контролирован, ОБЯЗАН проверить:

1. Качество определения задачи. Применялся ли QG-0? Были ли у задачи чёткие, проверяемые критерии приёмки до начала работы AI? Хорошо определённая задача свидетельствует о целенаправленном руководстве, а не об открытой генерации AI.

2. Записи прохождения шлюзов. Был ли пройден QG-2 с задокументированным одобрением супервайзера? Были ли выполнены и зафиксированы автоматические проверки (CI, тесты, линтинг, сканирование безопасности)? Автоматизированные записи шлюзов — более надёжное свидетельство, чем ручные чеклисты.

3. Проверка, соответствующая уровню риска. Был ли уровень риска классифицирован корректно? Прошли ли высокорисковые изменения рецензирование в соответствии с требованиями Standard 8.7? Последовательное применение проверки по уровню риска — ключевой индикатор.

4. Дисциплина сессий. Были ли сессии ограничены по длительности? Выполнялись ли контрольные точки с требуемой периодичностью? Неограниченные сессии без контрольных точек свидетельствуют о недостаточном внимании.

5. Захват знаний. Были ли задокументированы решения? Были ли зафиксированы тупиковые подходы? Активный захват знаний указывает на рефлексивное наблюдение, а не пассивное принятие.

6. Тренд метрик. Стабильна или улучшается ли доля утечки дефектов (DER)? Растущий DER свидетельствует о деградации качества наблюдения.

7. Доля обходов шлюзов. Редки ли обходы и хорошо ли обоснованы? Частые обходы указывают на системные проблемы процесса.

B.4 Рекомендации по срокам хранения

C. Сопоставление с нормативными требованиями

C.1 ISO 9001:2015 — Системы менеджмента качества

C.2 SOC 2 Type II — Критерии доверительных услуг

C.3 GDPR — Рекомендации для AI-инструментов, обрабатывающих персональные данные

GDPR применяется, когда AI-инструменты для кодирования обрабатывают персональные данные. Это может происходить, когда:

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

C.4 Общие требования к аудиту ПО

C.5 EU AI Act (Regulation 2024/1689)

AI-ассистенты для кодирования, как правило, попадают в категории «ограниченный риск» или «ИИ общего назначения». Ключевые обязанности:

• Статья 50: Прозрачность — пользователи должны быть проинформированы о взаимодействии с AI. Явная маркировка AI-сгенерированной работы в SENAR удовлетворяет этому требованию.
• Статья 53: Обязанности поставщиков моделей GPAI — актуально, когда организации дообучают или развёртывают модели.
• Организациям, работающим в ЕС, РЕКОМЕНДУЕТСЯ проверять использование AI-инструментов на соответствие требованиям Акта и вести документацию мер комплаенса.

C.6 NIST AI Risk Management Framework (AI RMF 1.0)

Практики SENAR соответствуют функциям NIST AI RMF:

• Govern: Роли (Section 4), Управление (настоящее приложение)
• Map: Уровни проверки по рискам (Section 8.7), Классификация данных (D.1)
• Measure: Метрики (Section 9), Обзоры качества (Section 7.4)
• Manage: Шлюзы качества (Section 8), Реагирование на инциденты (F.1)

Организации, подпадающие под требования федерального управления AI в США, РЕКОМЕНДУЕТСЯ документировать это сопоставление.

C.7 ISO/IEC 27001:2022

Контроли SENAR сопоставляются с Приложением A ISO 27001:

• A.8.25 (Безопасный жизненный цикл разработки): Шлюзы качества, Чеклист верификации
• A.8.28 (Безопасное кодирование): Правила 10.6, 10.15, Проверка вывода AI
• A.8.9 (Управление конфигурацией): Правила 10.13, 10.14
• A.5.12 (Классификация информации): Классификация данных (D.1)
• A.8.15 (Логирование): Требования к аудиторскому следу (B.1)

Организации, претендующие на сертификацию ISO 27001, РЕКОМЕНДУЕТСЯ сопоставить артефакты SENAR со своим Заявлением о применимости.

D. Управление данными для AI-инструментов

D.1 Классификация данных для взаимодействия с AI

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

D.2 Критерии выбора AI-инструментов

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

D.3 Локальный vs облачный AI: система принятия решения

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

D.4 Сроки хранения данных взаимодействия с AI

D.5 Право на удаление

Критический вопрос для организаций, подпадающих под GDPR или аналогичные нормы конфиденциальности: если персональные данные были включены в промпт AI, можно ли устранить их влияние на модель?

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

Рекомендуемые практики:

1. Предотвращать, а не исправлять. Классификация данных и подготовка контекста QG-0 должны исключать персональные данные из промптов AI. Предотвращение надёжнее постфактумного удаления.
2. Договорные оговорки об отказе от обучения. Обеспечить, чтобы договоры с AI-инструментами явно исключали данные клиентов из обучения моделей.
3. Удаление данных промптов. Обеспечить, чтобы договоры включали обязательства по удалению данных промптов, и верифицировать исполнение.
4. Локальные модели для данных ограниченного доступа. Когда необходимы гарантии удаления, использовать локальные модели, где организация контролирует полный жизненный цикл данных.
5. Документировать ограничение. Если организация не может гарантировать удаление влияния обучения, задокументировать это как известный риск в DPIA и применить компенсирующие контроли (минимизация данных, синтетические данные).

E. Интеллектуальная собственность и лицензирование

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

E.1 Право собственности на AI-сгенерированный код

Правовой статус собственности на AI-сгенерированный код различается по юрисдикциям и во многих из них остаётся неопределённым:

Рекомендуемые практики:

1. Обновить трудовые и подрядные соглашения, явно охватив код, созданный с помощью AI и AI-сгенерированный код.
2. Проверить условия поставщика AI-инструмента для подтверждения передачи прав собственности на вывод.
3. Документировать творческий вклад человека через записи задач SENAR (цель, критерии приёмки, архитектурные решения, заметки проверки супервайзера). Эта документация укрепляет претензии на авторство.
4. Вести записи руководства супервайзера — предоставленный AI контекст, выбор и модификация вывода AI, суждения, применённые при проверке.

E.2 Риск лицензионного заражения

AI-модели, обученные на открытом исходном коде, могут генерировать вывод, воспроизводящий или близко напоминающий код под копилефт-лицензиями (GPL, AGPL, LGPL). Если такой вывод включается в проприетарное ПО без соблюдения условий, возникает риск лицензионного заражения.

Факторы риска:

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

Рекомендуемые практики:

1. Автоматизированное сканирование лицензий. Включить инструменты сканирования лицензий в конвейер CI (принудительно на QG-2). Сканировать как прямые зависимости, так и сгенерированный код на известные паттерны, обременённые лицензиями.
2. Аудит зависимостей на QG-3. Для конфигураций Командная+ включить аудит лицензий зависимостей в область верификации QG-3.
3. Покрытие обзором качества. Включить лицензионный комплаенс в область обзора качества (аудит здоровья зависимостей).
4. Выбор AI-инструмента. Оценивать политики обучающих данных поставщиков AI-инструментов и любые предлагаемые ими гарантии возмещения убытков по претензиям об ИС.
5. Документация происхождения кода. Для кода высокой ценности или высокого риска документировать, был ли он сгенерирован AI, написан человеком или является комбинацией.

E.3 Требования к документации для комплаенса ИС

Организации, стремящиеся продемонстрировать комплаенс ИС для AI-сгенерированного кода, должны вести:

F. Реагирование на инциденты с дефектами AI-сгенерированного кода

F.1 Процесс реагирования

При обнаружении продакшен-инцидента, связанного с AI-сгенерированным кодом, в дополнение к стандартному процессу реагирования организации применяется следующий процесс:

1. Сортировка и сдерживание. Стандартное реагирование на инцидент: оценка серьёзности, сдерживание воздействия, восстановление сервиса.

2. Отслеживание происхождения. Использование цепочки прослеживаемости SENAR:

   • Продакшен-инцидент → изменение кода (контроль версий);
   • Изменение кода → запись задачи (коммит ссылается на задачу);
   • Запись задачи → требование (ссылка QG-0 на требование);
   • Запись задачи → супервайзер (назначение задачи и одобрение QG-2);
   • Запись задачи → сессия (лог сессии с временными метками и контекстом).

3. Оценка эффективности шлюзов. Для каждого шлюза качества, через который прошёл дефектный код:

   • Был ли шлюз выполнен? (Проверить записи шлюзов.)
   • Прошли ли автоматические проверки? (Были ли проверки адекватны для данного типа дефекта?)
   • Была ли проведена проверка человеком? (Соответствовала ли она уровню риска согласно Standard 8.7?)
   • Был ли задействован обход шлюза? (Если да, была ли оценка рисков обхода точной?)

4. Классификация первопричины. Использование таксономии первопричин, специфичных для AI (Section F.2).

5. Устранение. Исправить непосредственный дефект. Создать задачу на любое системное улучшение.

6. Ротация учётных данных. При раскрытии учётных данных или секретов (зафиксированы в VCS, включены в контекст AI или залогированы) организация ОБЯЗАНА выполнить ротацию затронутых учётных данных в течение 24 часов и провести аудит логов доступа на предмет несанкционированного использования.

7. Пост-инцидентный разбор. Провести структурированный разбор, охватывающий:

   • Было ли наблюдение адекватным для уровня риска данного изменения?
   • Были ли шлюзы качества эффективны? Следует ли усилить критерии шлюзов?
   • Был ли контекст AI-агента достаточным? Следует ли создать записи знаний?
   • Следует ли повысить классификацию риска для данного типа изменений?

Организации РЕКОМЕНДУЕТСЯ определить сроки реагирования на AI-сгенерированные уязвимости в зависимости от серьёзности. Рекомендуется: Критический — 4 часа, Высокий — 24 часа, Средний — 72 часа, Низкий — следующий инкремент.

F.2 Таксономия первопричин, специфичных для AI

К AI-сгенерированному коду применяются стандартные категории первопричин (логическая ошибка, ошибка интеграции, проблема производительности). Следующие дополнительные категории специфичны для AI-нативной разработки:

F.3 Цепочка прослеживаемости

Полная цепочка прослеживаемости для расследования инцидентов:

Production Incident
  └─► Code Change (commit hash, diff, timestamp)
        └─► Task Record (goal, AC, work type, Supervisor)
              ├─► Requirement (Story / business requirement)
              ├─► QG-0 Record (context quality at task start)
              ├─► QG-2 Record (implementation verification)
              │     ├─► Automated check results (CI, tests, lint, security)
              │     └─► Supervisor approval (who, when)
              ├─► QG-3 Record (if applicable: review, acceptance tests)
              ├─► Session Log (when, duration, checkpoints, context)
              └─► Knowledge Entries (decisions, Dead Ends, patterns)

Эта цепочка позволяет аудиторам и расследователям инцидентов восстановить полную историю решений от бизнес-требования через реализацию до развёртывания в продакшен.

G. Что не покрывает SENAR

SENAR — это методология процесса управляемой AI-нативной разработки. Следующие области, релевантные для комплаенса, находятся за пределами области SENAR и требуют дополнительных организационных контролей:

Организации, внедряющие SENAR, должны интегрировать его в более широкую систему управления, рисков и комплаенса (GRC), а не рассматривать как самостоятельное решение для комплаенса.

G.1 Компенсирующие контроли для конфигураций Базовая/Начальная

Конфигурации SENAR Базовая (1 пара) и Начальная (1–3 пары) совмещают множество ответственностей в меньшем числе людей. Это создаёт разрыв в разделении обязанностей, который может вызвать вопросы у аудиторов:

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

H. Чеклист внедрения

Организации, внедряющие SENAR в регулируемой среде, должны решить следующие вопросы:

• Установить политику классификации данных для взаимодействия с AI-инструментами (Section D.1)
• Оценить и выбрать AI-инструменты на основе классификации данных и требований комплаенса (Section D.2)
• Заключить соглашения об обработке данных с облачными поставщиками AI-инструментов (Section D.3)
• Обновить трудовые и подрядные соглашения об ИС для AI-сгенерированного кода (Section E.1)
• Интегрировать сканирование лицензий в конвейер CI на QG-2 (Section E.2)
• Настроить автоматизацию шлюзов качества для создания записей аудиторского уровня (Section B.1)
• Установить процесс одобрения обхода шлюзов с требованиями к документации (Section A.3)
• Определить политику хранения данных для артефактов SENAR (Section B.4)
• Провести DPIA, если AI-инструменты будут обрабатывать персональные данные (Section C.3)
• Задокументировать компенсирующие контроли при работе в конфигурации Базовая/Начальная (Section G.1)
• Установить категории первопричин, специфичных для AI, в процессе управления инцидентами (Section F.2)
• Включить комплаенс AI-инструментов в область обзора качества (Section D, E)
• Обучить супервайзеров классификации данных и обязательствам комплаенса, специфичным для AI
• Интегрировать аудиторский след SENAR в существующий инструментарий и отчётность GRC