Этические и правовые аспекты

LLM на проекте быстро перестают быть «экспериментом в чате»: вывод модели попадает в спецификацию, влияет на решение по кредиту или становится аргументом на аудите. Этические и правовые аспекты ИИ — это не абстрактная философия, а набор требований, которые нужно перевести в НФТ и compliance-требования, контроли и трассируемость до первого релиза. Статья отвечает на вопрос: какие риски и регуляторные обязательства закладывать в LLM-решение и какую роль системный аналитик играет между юристами, compliance и командой разработки. Общий каркас локального права РФ (152-ФЗ, локализация, отраслевые overlay вроде PCI-DSS) — в 08.06 Юридические и регуляторные требования РФ (PCI-DSS); здесь — принципы и перевод в spec без дублирования отраслевых деталей.

1. Суть темы

Этика ИИ (AI ethics) — набор принципов и практик, определяющих, какие решения алгоритм может принимать, на каких данных обучаться и как объяснять свои выводы. Правовое регулирование ИИ (AI regulation) — обязательные нормы, за нарушение которых организация несёт административную, гражданскую или уголовную ответственность.

В 2026 году оба слоя перестали быть «рекомендациями на будущее». Регуляторы перешли к конкретному правоприменению и дедлайнам соблюдения; этика превратилась в операционную рамку в SDLC — процессы, метрики и контроли, встроенные в жизненный цикл разработки. Для аналитика это означает: этика и право — часть scope в духе ISO 29148 и практик BA, а не постскриптум в ADR.

Граница темы: здесь — принципы, регуляторные рамки и практика перевода их в требования. Архитектурные паттерны развёртывания и audit logging — в 11.04 Архитектуры использования LLM в корпоративном контуре; контроль данных при интеграции с инструментами — в 11.05 Интеграция LLM с инструментами аналитика; выбор модели с учётом compliance — в 11.08 Выбор и настройка моделей для корпоративного использования.

Сдвиг ландшафта: от дискуссий к обязательствам

Аспект	Было (до 2024–2025)	Стало (2026)	Последствие для аналитика
Регулирование	Принципы и white papers	Дедлайны, штрафы, аудиты	Требования с датами внедрения — фиксируйте в backlog; смену overlay — через [[-02.05.02 Управление изменениями (Change Control Board)
Этика	Добровольные кодексы	Governance в SDLC	Этические риски — в реестре рисков проекта
Прозрачность	«Желательно объяснять»	Обязательная explainability для high-risk	НФТ на объяснимость — не опция
Данные	GDPR «и так есть»	Data sovereignty + lineage для ИИ	Трассировка данных — в спецификации pipeline
Глобальность	Локальные политики	Baseline + региональные overlay	Единая политика в ADR; regional appendix по юрисдикциям

flowchart LR
    subgraph legal [Правовой слой]
        EU[EU AI Act]
        US[US sector rules]
        RF[Локальное право РФ]
    end
    subgraph ethics [Этический слой — пять столпов]
        F[Fairness]
        T[Transparency]
        E[Explainability]
        R[Robustness]
        P[Privacy]
    end
    subgraph sa [Роль SA]
        REQ[Требования]
        NFR[НФТ и compliance]
        ADR[ADR и трассировка]
        BR[Мост legal ↔ tech]
    end
    legal --> REQ
    ethics --> REQ
    REQ --> NFR
    REQ --> ADR
    BR --> legal
    BR --> ethics

2. Ключевые понятия

Регуляторные рамки по регионам

Ландшафт фрагментирован, но транснациональные организации выстраивают единую baseline-политику с региональными overlay (отдельный appendix в BRD или ADR: какие контроли усиливаются в EU, US, РФ). Аналитик документирует не «один закон на всех», а матрицу «базовое требование → региональная надстройка → owner legal».

Регион	Подход	Что важно аналитику
ЕС	EU AI Act: классификация по уровню риска, обязанности provider / deployer / user	Классификация до проектирования; кто ведёт conformity assessment; disclosure; audit trail
США	Сектор-специфический + executive orders, state AI laws, enforcement FTC	В discovery: домен (FINRA, HIPAA, EEOC), штат развёртывания, политика White House EO на federal contractors
РФ и СНГ	152-ФЗ, локализация, отраслевые нормы	Детали — в 08.06 Юридические и регуляторные требования РФ (PCI-DSS) (общий каркас + отраслевые overlay, PCI-DSS — частный случай); в spec — ссылка на regional appendix
MENA и др.	Быстро меняющиеся рамки, ориентация на инновации	Уточняйте локальные требования при cross-border развёртывании; фиксируйте «TBD legal» с датой review

EU AI Act: роли в цепочке поставки

EU AI Act — наиболее структурированная рамка для корпоративного LLM, но обязанности зависят от роли организации:

Роль	Кто это на практике	Что закладывать в spec
Provider (поставщик)	Разработчик или вендор модели / SaaS с ИИ	Техническая документация, CE-маркировка для high-risk, post-market monitoring
Deployer (развёртывающий)	Организация, внедряющая готовую систему у себя	FRIA или DPIA (см. ниже), human oversight, logging, обучение операторов
User (пользователь)	Сотрудник под контролем deployer	Политики использования, запрет shadow AI

GPAI и дообучение foundation model — частый discovery-вопрос в корпоративном контуре. Если компания берёт готовую foundation model и fine-tune / RAG на своих данных, роль может сместиться от «чистого deployer SaaS» к provider или deployer с provider-обязанностями — в зависимости от степени модификации, брендинга и постановки на рынок. Не сводите всё к одной строке «deployer»: в spec зафиксируйте цепочку (base model vendor → ваш fine-tune → конечный use case), кто несёт conformity assessment, и action items по Annex III / GPAI Code of Practice.

Переходные периоды (на 2026): запрет на unacceptable risk действует раньше; полный набор контролей для high-risk из Annex III вводится поэтапно — не каждый deployer обязан сразу пройти полный conformity assessment. Задача аналитика в discovery: зафиксировать роль, класс риска, applicable annex и action items с owner (legal vs engineering), а не только метку «high-risk».

FRIA и DPIA: когда что в spec

Артефакт	Когда нужен	Кто инициирует	Что попадает в backlog аналитика
DPIA (Data Protection Impact Assessment)	Обработка персональных данных с высоким риском (GDPR Art. 35)	DPO / legal	NFR на data minimization, retention, DPA; ссылка на DPIA ID в ADR; контроли из DPIA → acceptance criteria
FRIA (Fundamental Rights Impact Assessment)	Deployer high-risk AI по EU AI Act	Legal / compliance	NFR на human oversight, logging, transparency; поля FRIA в реестре ИИ; дата sign-off до production

Развилка для spec: если есть и ПДн, и high-risk AI — оба артефакта, но DPIA ведёт privacy-контур, FRIA — fundamental rights и AI Act. Аналитик не пишет юридический текст, но в SRS фиксирует: «production blocked до FRIA-2024-017 sign-off (owner: Legal)» и перечень технических контролей, вытекающих из каждого assessment.

Assistive vs generative vs agentic

Один и тот же LLM несёт разную регуляторную нагрузку:

Тип сценария	Пример	Этико-правовая нагрузка
Assistive (ассистирующий)	Черновик user story, рефакторинг текста	Disclosure, IP, human review спецификации
Generative (генерирующий решение)	Рекомендация лимита кредита, ранжирование резюме	Automated decision-making, fairness, explainability, HITL
Agentic (агентный)	Автономные действия в CRM, тикетах, API	Делегирование полномочий, audit каждого action; см. 11.04 Архитектуры использования LLM в корпоративном контуре, 11.07 Практические кейсы применения LLM в анализе

Разводите сценарии в discovery: один чеклист LLM-фичи не снимает различие «помощник аналитика» vs «автоматическое решение о человеке».

Цепочка до итогового решения. Сценарий «assistive» на бумаге может переклассифицироваться в ADM или high-risk, если RAG работает по персональным/чувствительным данным, вывод модели систематически попадает в решение о человеке, а HITL формален (нет альтернатив, нет SLA на пересмотр). Классифицируйте не по UI-метке «помощник», а по фактической цепочке: данные → inference → business rule → действие над субъектом. Если последнее звено влияет на права человека — закладывайте контроли generative/ADM, даже если интерфейс называется «ассистент».

Пять столпов корпоративной этики ИИ

Отраслевые governance-рамки (NIST AI RMF, ISO/IEC 42001) сводятся к пяти измерениям — каждое переводится в конкретные требования (и отражено в диаграмме выше):

Принцип	Суть	Пример требования в спецификации
Fairness (справедливость)	Отсутствие необоснованной дискриминации по защищённым признакам	Тестирование выводов на подгруппах; пороги метрик fairness
Transparency (прозрачность)	Пользователь знает, что взаимодействует с ИИ	Маркировка AI-generated контента; политика раскрытия
Explainability (объяснимость)	Возможность обосновать вывод post hoc	RAG provenance; structured log; XAI для high-risk
Robustness (устойчивость)	Стабильность при смене данных и adversarial input	Мониторинг drift; red-team сценарии
Privacy (конфиденциальность)	Минимизация и защита персональных данных	Data minimization; запрет PII во внешние API без DPA — см. 08.07 Основы кибербезопасности для системного аналитика

Fairness Paradox (парадокс справедливости)

Fairness Paradox — ситуация, когда оптимизация одного технического определения справедливости (например, demographic parity) создаёт дисбаланс по другому (equalized odds). Единственного «правильного» коэффициента fairness не существует: выбор — бизнес- и этическое решение, которое аналитик должен зафиксировать с юристами и заинтересованными сторонами, а не делегировать data science «по умолчанию». Выбранная метрика и пороги — в ADR и в критериях приёмки: иначе trade-off не проверяем на V&V.

Automated decision-making и human oversight

Automated decision-making (ADM) — решение, существенно влияющее на человека, принятое без meaningful human involvement. Под GDPR Art. 22 и аналогами нужны: информирование, право на вмешательство, значимое человеческое участие — не формальная «галочка» после вывода модели.

Контроль	Когда часто достаточен	Когда недостаточен
HITL (human-in-the-loop)	Рекомендация + эксперт подтверждает до действия	Решение de facto автоматическое: человек не видит альтернатив, нет времени на review
Право на неавтоматизированное решение	Не применимо (нет ADM)	Кредит, найм, медицинский допуск — нужен канал эскалации к человеку и SLA
Explainability для ADM	Структурированное объяснение: факторы, источники, версия модели, возможность оспорить	Только текст «модель так решила» или промпт «объясни ответ»

Эталон acceptance criterion уровня legal (для user story / SRS по отказу в кредите на основе LLM-скоринга):

Given заявитель получил отказ по автоматизированному скорингу, When он открывает экран решения или запрашивает объяснение через API GET /decisions/{id}/explanation, Then в течение 15 секунд отображается JSON/HTML с: (1) топ-5 факторов с весами, (2) ссылками на источники данных (retrieval IDs), (3) версией модели и датой inference; And кнопка «Запросить пересмотр человеком» создаёт тикет в очереди underwriter с SLA 72 часа (рабочих, EU overlay); And audit log сохраняет запрос объяснения и ответ не менее 5 лет в регионе EU-West (или по litigation hold от legal).

Формулировка согласуется с legal до включения в критерии приёмки и трассируется до тест-кейсов (трассировка требований).

Explainable AI (XAI) и «чёрный ящик»

В высокорегулируемых секторах black-box без audit trail и documented limitations часто не проходит закупку и audit — это требование compliance и прозрачности, а не универсальный технический запрет. Многие high-risk контуры используют сложные модели с proxy-XAI и явно задокументированными ограничениями объяснимости. Explainable AI (XAI) — методы и требования, показывающие, какие факторы повлияли на вывод. Для LLM частично решается через RAG с provenance, structured logging и HITL — но при ADM и high-risk классификации нужна формальная оценка достаточности объяснения с legal, а не только инженерный log.

Intellectual property и контракт с вендором LLM

Для аналитика, чей вывод попадает в SRS и контракты, типичны три вопроса IP:

• Вход: можно ли подавать в LLM внутренние документы, код, данные клиента? — лицензия провайдера, DPA, запрет training on customer data.
• Выход: кто владеет AI-generated текстом в deliverables? — формулировка в контракте и политике компании.
• Training data провайдера: риск претензий по copyright на обучающие корпуса — для enterprise часто решается on-prem / private endpoint; фиксируйте в ADR как legal risk, не только технический выбор.

Три bullets по IP не заменяют требования к RFx/контракту — их стоит вынести в compliance appendix SRS или закупочное ТЗ:

Требование к контракту	Зачем в spec
Запрет использования customer data для обучения моделей провайдера	Data sovereignty, GDPR
Indemnity по copyright/training data и bias-инцидентам	Перенос риска; owner legal review
SLA на инциденты (утечка, downtime, bias escalation) с каналом эскалации	Операционные NFR и acceptance criteria для procurement
Право audit / subprocessors list	Due diligence; поле в реестре ИИ
Data residency и deletion upon termination	Retention NFR; см. ниже

UNESCO Recommendations on the Ethics of AI

Рекомендации ЮНЕСКО по этике ИИ — глобальный ориентир для human-centric AI. Используйте как baseline там, где локальное регулирование ещё не детализировано. При vision & scope проверьте минимум:

• Proportionality — ИИ применяется только там, где польза перевешивает риск для прав и благополучия.
• Safety and security — уязвимости и злоупотребления учтены до production.
• Transparency and explainability — пользователь понимает, что перед ним ИИ, и может оспорить значимые выводы.
• Non-discrimination — защищённые группы не получают систематически худший исход без обоснованного trade-off в ADR.

AI Governance и GRC

AI Governance — управление жизненным циклом ИИ-систем: классификация рисков, реестр моделей, политики данных, контроль изменений. GRC (Governance, Risk & Compliance) — интегрированная функция риск-менеджмента и compliance. В зрелых организациях governance ИИ не живёт отдельно от data governance и общего GRC — иначе возникает governance fragmentation (разрозненность политик и реестров). Обновление regulatory overlay при смене закона или annex — через управление изменениями и CCB с legal в составе.

Data sovereignty, lineage и retention

Data sovereignty (суверенитет данных) — хранение и обработка в юрисдикции по регулятору или контракту. Data lineage (происхождение данных) — цепочка от источника до вывода модели. Без lineage невозможно доказать compliance при аудите и расследовать инцидент дискриминации или утечки.

Record retention для audit log — отдельный NFR, не сводимый к «логируем»:

Элемент	Типовая spec-формулировка
Срок хранения inference log	Не менее N лет (legal определяет N: EU audit часто 5–10 лет)
Юрисдикция хранения	Region pinning; запрет cross-border без DPA
Litigation hold	Приостановка удаления по запросу legal; флаг в реестре ИИ
Immutable / WORM	Append-only для ADM и high-risk; owner: security

Конфликт политик: transparency vs коммерческая тайна

Типичный workshop-сценарий: EU требует раскрыть логику решения, а промпт и RAG-корпус содержат коммерческую тайну. Решение для spec: tiered disclosure — пользователю и регулятору разные уровни детализации; redacted reasoning trace; отдельный audit-only log с access control. Зафиксируйте trade-off в ADR с legal (паттерн tiered disclosure — здесь; повторять в ошибках не нужно).

3. Как применяется в работе аналитика

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

Интеграция этических рисков в жизненный цикл

Встройте этику и право в те же артефакты, что и функциональные требования:

1. Discovery — классифицируйте сценарий (assistive / generative / agentic); фактическую цепочку до решения о человеке; роль в EU AI Act (включая GPAI/fine-tune); FRIA/DPIA trigger; отраслевые нормы US/РФ.
2. Specification — добавьте НФТ на fairness, explainability, logging, retention, human oversight в шаблон NFR и 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.
3. Design — зафиксируйте решения в ADR: модель, данные, human author / approver финального текста спецификации.
4. V&V — этические тест-кейсы: подгруппы, adversarial prompts, маркировка AI-контента (02.04.01 Верификация и валидация (V&V)); рецензия по 08.04 Рецензирование и инспекции (техники Фейгана); трассировка compliance NFR до тестов (02.03.04 Трассировка требований (концепция)).
5. Operations — метрики в мониторинг LLM: bias drift, эскалации к человеку, инциденты.

Мост между legal и tech

Формулировка legal / compliance	Техническая спецификация аналитика
«Обеспечить прозрачность ИИ»	UI-маркер «Сгенерировано ИИ»; политика disclosure в user story
«High-risk AI system»	Чеклист Annex III; HITL gate; owner conformity / FRIA — по роли
«Право на объяснение» (ADM)	Факторы + источники + версия модели; SLA на выдачу; канал пересмотра — см. эталон AC выше
«Минимизация данных»	Whitelist полей в промпт; запрет upload PII в публичные API
«Суверенитет данных»	Регион модели и vector store — в [[03.01.02 Моделирование контекста системы (Context Diagram)
«Regional overlay»	Матрица baseline vs EU / US / РФ appendix в BRD
«ESG / ресурсоёмкость ИИ»	NFR: лимит токенов/вызовов на транзакцию; отчётность CO₂e в ops dashboard; выбор модели — см. 11.08 Выбор и настройка моделей для корпоративного использования
«Audit trail retention»	Срок N лет, region pinning, litigation hold — поля в NFR и реестре

Согласуйте единый глоссарий: «объяснимость» для юристов и «retrieval log / reasoning trace» для инженеров ссылаются на один acceptance criterion.

Требования к реестру и governance

Зрелые организации ведут централизованный реестр ИИ-систем вместо shadow AI. Аналитик формулирует требования к реестру (поля, NFR на регистрацию, audit export), а не выбирает вендора; детали реализации реестра, интеграция с GRC и технический audit export — в 11.04 Архитектуры использования LLM в корпоративном контуре.

Поле / контроль	Зачем
Owner (business + technical)	Эскалация и audit
Класс риска и роль (provider/deployer/GPAI chain)	Action items по AI Act
Тип сценария (assistive/generative/agentic)	Глубина контролей
FRIA / DPIA ID и дата sign-off	Production gate
Дата последнего legal review	Актуальность regional overlay
Связь с риском в GRC	Единый контур с 08.05 Управление рисками на этапе анализа
Триггеры эскалации	Новая модель, новый регион, инцидент bias
Retention policy ID	Связь log ↔ legal hold
Отчёты для audit	Экспорт lineage, log sample, статус HITL

Политики использования (что в промпт, какие модели, обязательность HITL) — зона legal/ops; в spec достаточно NFR на регистрацию каждой интеграции до production.

Ответственность за текст спецификации

Если LLM дописала SRS или user story, в артефакте должна быть трассировка: generated_by_llm, human_reviewer, approval_date. Финальную ответственность за смысл требований несёт утверждающий человек — как при управлении качеством требований. На аудите «модель так сформулировала» не снимает liability; учитывайте доверие к авторитетному тексту от LLM.

Аудит алгоритмической справедливости

Если LLM влияет на решения о людях (найм, кредит, медицина, допуск к сервису):

• До production — тестирование на демографических подгруппах; baseline метрик в acceptance criteria.
• После запуска — мониторинг bias drift (11.09 Мониторинг и оценка качества LLM-решений).
• При инциденте — audit trail: промпт, retrieved context, версия модели, reviewer.

Зафиксируйте в реестре рисков: «алгоритмическая дискриминация» — probability, impact, owner legal.

Метрики эффективности работы аналитика по этике ИИ

Метрика	Источник данных	Owner	Артефакт
% этических рисков, выявленных до production	Реестр рисков GRC + AI risk log	Risk owner / SA lead	[[08.05 Управление рисками на этапе анализа
Время от нового регуляторного требования до контроля в spec	Jira/ADO: ticket legal → NFR merged	SA + legal	Epic «Regulatory overlay»; ADR changelog
Инциденты алгоритмической дискриминации	Incident management + LLM monitoring	Compliance	Post-mortem; поле в реестре ИИ
% LLM-выводов с human review до публикации	Audit log реестра ИИ / CMS metadata	Product owner	Dashboard [[11.09 Мониторинг и оценка качества LLM-решений

Без owner и артефакта метрика не попадает в governance — это обычное измеримое требование, а не KPI «для отчёта».

Чеклист для спецификации LLM-фичи

Подмножество общего чеклиста перед стартом разработки — применяйте к каждой фиче с LLM. Пункты с [blocking для high-risk/ADM] — production gate.

• Тип сценария: assistive / generative / agentic; фактическая цепочка до решения о человеке
• [blocking] Класс риска, роль в цепочке AI Act (включая GPAI/fine-tune) / отраслевой стандарт
• Regional overlay (EU / US / РФ) или ссылка на локальное право и отраслевые overlay
• [blocking для ADM] FRIA и/или DPIA ID + дата sign-off до production
• Маркировка AI-generated контента
• [blocking для ADM] HITL или канал неавтоматизированного решения с SLA
• Data lineage от источника до вывода
• Запрет или маскирование PII во внешних API без DPA
• Регион хранения и обработки данных
• [blocking для high-risk/ADM] Audit log: промпт, context, model version, reviewer; retention N лет, region, litigation hold
• Fairness-тесты и acceptance criteria на метрики (эталон AC для ADM — см. §2)
• Human author / approver для текста в deliverables
• IP и требования к контракту/RFx (training ban, indemnity, SLA инцидентов)
• ESG: лимит вызовов/токенов; отчётность ресурсоёмкости — см. 11.08 Выбор и настройка моделей для корпоративного использования
• Owner этического риска и эскалационный путь
• [blocking] Регистрация в реестре ИИ до production

4. Типовые ошибки и ограничения

Ошибки на проекте

Ошибка	Почему опасно	Что делать
«Этику обсудим после MVP»	High-risk не retrofit без переделки	Классификация — в discovery
Делегирование fairness только data science	Парадокс справедливости — бизнес-выбор	Workshop с legal; ADR + acceptance criteria
Shadow AI без реестра	Утечки и необъяснимые решения	NFR на регистрацию; 11.04 Архитектуры использования LLM в корпоративном контуре
«GDPR покрывает всё»	ADM, bias, AI Act — отдельный слой	Блок НФТ для ИИ + regional overlay
Explainability «через промпт»	Не доказуемо при ADM	Provenance, structured log, legal sign-off
Игнор data sovereignty	Штрафы, запрет обработки	Region pinning с первого дня
Один чеклист для всех LLM-сценариев	Assistive и credit scoring — разный риск	Разводка assistive / generative / agentic; цепочка до решения
«Deployer = provider»	Неверные action items по AI Act	Явная роль + GPAI/fine-tune chain в spec
«Assistive» в UI, ADM на деле	Пропуск HITL и FRIA	Классификация по цепочке, не по метке
Log без retention	Audit fail через 2 года	NFR: срок, region, litigation hold
RFx без AI-clauses	Нет рычагов при инциденте bias/утечки	Compliance appendix в закупке

Структурные ограничения

Fairness Paradox не решается «лучшей моделью» — только trade-off в ADR, acceptance criteria и мониторинг.

Environmental costs — LLM несут след по ресурсам. Для ESG закладывайте NFR на ресурсоёмкость (лимит вызовов, отчётность, выбор модели) — детали выбора — в 11.08 Выбор и настройка моделей для корпоративного использования; в spec достаточно измеримого порога и owner ops.

Governance fragmentation — десяток несвязанных инструментов без единого реестра. Лечение — единая политика и требования к регистрации интеграций; полный compliance за один спринт не обещайте.

Black-box в procurement — в regulated sectors система без audit trail и согласованного уровня explainability часто не допускается к production; технически black-box может существовать с documented limitations — но для ADM это редко достаточно без legal оценки.

Промпт не заменяет право — «не будь предвзятым» не создаёт compliance. Промпт работает внутри governance (11.03 Промпт-инжиниринг для аналитика), а не вместо процессов и NFR.

Regulatory drift — таблицы «было/стало» и дедлайны устаревают. Фиксируйте snapshot date в ADR и пересматривайте overlay через change control при изменении annex или локального закона.

Этика и право не снимают ответственность с аналитика: модель задаёт rails, но scope, trade-off и финальное ревью — за человеком.

Связи с другими разделами базы

• Классификация этики/право как НФТ — 02.03.01 Классификация требований (БТ, ФТ, НФТ)
• Трассировка compliance NFR до тестов — 02.03.04 Трассировка требований (концепция)
• Change control при смене regulatory overlay — 02.05.02 Управление изменениями (Change Control Board)
• Локальное право РФ, отраслевые overlay (PCI-DSS и др.) — 08.06 Юридические и регуляторные требования РФ (PCI-DSS)
• Стандарты NFR и compliance в BA — 00.04 Основные стандарты и своды знаний (BABOK, SEBoK, ISO 29148)
• Контроли данных и API — 08.07 Основы кибербезопасности для системного аналитика
• Архитектурные контроли, реестр, audit logging — 11.04 Архитектуры использования LLM в корпоративном контуре
• Data lineage при интеграции с инструментами — 11.05 Интеграция LLM с инструментами аналитика
• Промпты внутри governance — 11.03 Промпт-инжиниринг для аналитика
• Свойства LLM, галлюцинации — 11.01 Введение в искусственный интеллект и LLM
• On-prem, DPA, выбор модели, ESG — 11.08 Выбор и настройка моделей для корпоративного использования
• Bias drift и production-метрики — 11.09 Мониторинг и оценка качества LLM-решений
• Прикладные кейсы — 11.07 Практические кейсы применения LLM в анализе
• Общий чеклист перед разработкой — 10.04 Чеклист аналитика перед стартом разработки
• Vision & Scope, BRD — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD)
• SDLC и этапы требований — 00.03 Жизненный цикл ПО и место аналитика (SDLC, STLC), 02.05.05 Жизненный цикл требования
• НФТ — 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 10.01.12 Шаблон нефункциональных требований (NFR)
• Риски — 08.05 Управление рисками на этапе анализа
• ADR — 10.01.13 Шаблон архитектурного решения (ADR)
• V&V, приёмка, рецензирование — 02.04.01 Верификация и валидация (V&V), 02.04.02 Критерии приёмки (Acceptance Criteria), 08.04 Рецензирование и инспекции (техники Фейгана)
• Критическое мышление при HITL — 01.07 Когнитивные искажения и критическое мышление
• Stakeholders и scope — 02.01.03 Анализ заинтересованных сторон (Stakeholder Map), 02.01.04 Определение границ решения (Scope Modelling), 03.01.02 Моделирование контекста системы (Context Diagram)

Источники и дополнительные материалы

Regulatory snapshot: август 2026. Дедлайны EU AI Act, state AI laws и локальные нормы РФ пересматривайте при change control; таблица «было/стало» в §1 — ориентир, не юридическая консультация.

Стандарты и нормативные акты

• Regulation (EU) 2024/1689 — EU AI Act — https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32024R1689
• UNESCO Recommendations on the Ethics of Artificial Intelligence — https://www.unesco.org/en/artificial-intelligence/recommendation-ethics
• NIST AI Risk Management Framework (AI RMF 1.0) — https://www.nist.gov/itl/ai-risk-management-framework
• ISO/IEC 42001 — Artificial intelligence management system (упоминается в отраслевых обзорах как пара к NIST AI RMF; текст стандарта платный)

Статьи и отраслевые обзоры

• 2026 AI Legal Forecast: From Innovation to Compliance (Baker Donelson) — https://www.bakerdonelson.com/2026-ai-legal-forecast-from-innovation-to-compliance
• AI Ethics for Enterprise 2026: A Governance Playbook (Lines & Circles) — https://linesncircles.com/Blog/Enterprise/enterprise_AI_ethics

Примеры корпоративных контролей (по материалам отчёта исследования)

• Claude for Enterprise — Enterprise-grade controls — https://claude.com/solutions/enterprise
• Salesforce Trusted AI — https://www.salesforce.com/artificial-intelligence/trusted-ai/