Питання, яке вам задають
Якщо ви маєте SOC 2 Type II звіт понад рік, ця розмова вже відбувається. Ваш аудитор, спираючись на оновлені рекомендації AICPA та запитальники безпеки від клієнтів, запитує: "Чи використовують ваші продакшн-системи великі мовні моделі або інші AI-компоненти, і як вони охоплені вашими контролями?" Ви відповідаєте "так". Вас просять показати контролі. Чистої відповіді у вас немає.
Ця стаття — це мапа, якою ми ведемо клієнтів, коли їм доводиться відповідати на це запитання. Вона охоплює, які Trust Service Criteria насправді стосуються AI-компонентів, які контролі додати (а не замінити), як їх підтверджувати та що йде не так. Вона орієнтована на команди, у яких уже є робоча програма SOC 2 і які повинні розширити область — не на тих, хто робить SOC 2 вперше.
Які TSC застосовуються до AI-компонентів
Звіти SOC 2 охоплюють п'ять Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality та Privacy. Security є обов'язковим; інші — опціональні. Ось як кожен співвідноситься з типовою функцією на базі LLM.
| TSC | Релевантність для LLM-систем | Пріоритет |
|---|---|---|
| Security | Контроль доступу до ендпоінтів моделі, логів промптів, тренувальних даних. Як у будь-якому сервісі. | Стандартний |
| Availability | Залежність від провайдерів OpenAI/Anthropic. SLA на аптайм, фолбеки. | Середній |
| Processing Integrity | Точність, повнота, валідність виводу. Головне для AI. | Високий |
| Confidentiality | Промпти можуть містити конфіденційні дані клієнта. Обробка даних вендором. | Високий |
| Privacy | PII у промптах, дані користувачів у навчанні. Перетин з GDPR. | Високий, якщо в області |
Більшість зрілих SOC 2 звітів включають Security, Availability та Confidentiality. Для LLM-функцій вам майже напевно доведеться або додати Processing Integrity, або задокументувати, що ваші AI-компоненти не торкаються потоків, якими керував би Processing Integrity.
Мапінг вашої AI-функції на контролі
Почніть з простої інвентаризації. Для кожної AI-функції дайте відповідь:
- Що вона робить?
- Які дані потрапляють у промпт?
- Які дані виходять?
- Хто або що може її викликати?
- Від яких вендорів вона залежить?
- Що буде, якщо вона помилиться?
Потім замапте кожну відповідь на контроль. Нижче — матриця контролів, яку ми приносимо на клієнтські проєкти. Вона не вичерпна — ви додасте специфічні для компанії контролі — але це базова лінія, з якої ми починаємо розмову з аудитором.
Матриця контролів
Security (CC6.x)
| ID контролю | Опис | Докази |
|---|---|---|
| AI-SEC-01 | Доступ до API-ключів LLM та облікових даних провайдерів обмежено авторизованими сервісами та ротується за розкладом | Політика secrets manager, логи ротації |
| AI-SEC-02 | Доступ до тренувальних даних та датасетів для fine-tuning є role-based і логується | IAM-політики, CloudTrail, access reviews |
| AI-SEC-03 | MCP/tool сервери, доступні агентам, вимагають автентифікації та авторизації на кожному виклику | Код auth middleware, інтеграційні тести, audit logs |
| AI-SEC-04 | Логи промптів/відповідей, що містять дані клієнтів, шифруються at rest із customer-managed або provider-managed ключами | Конфігурація KMS, політики S3 бакетів |
| AI-SEC-05 | AI-компоненти включені у квартальні access reviews | Worksheet access review, підпис |
Availability (A1.x)
| ID контролю | Опис | Докази |
|---|---|---|
| AI-AVL-01 | Залежності від провайдерів моделей задокументовані з фолбек-стратегіями для кожного | Архітектурний документ, конфіг LLM gateway |
| AI-AVL-02 | User journeys, які залежать від AI, мають graceful degradation, коли LLM недоступний | Конфіг feature flag, протестовані режими відмови |
| AI-AVL-03 | Runbook'и реагування на інциденти охоплюють збої LLM-провайдерів | Runbook, записи game day |
| AI-AVL-04 | Моніторинг включає SLO на latency, error rate та вартість LLM | Дашборди Grafana, правила алертів |
Processing Integrity (PI1.x)
| ID контролю | Опис | Докази |
|---|---|---|
| AI-PI-01 | Зміни моделі (оновлення базової моделі, зміни промптів, оновлення fine-tune) проходять задокументований процес change management | Записи PR, нотатки зустрічей change advisory |
| AI-PI-02 | Регресійна evaluation запускається на golden dataset перед тим, як будь-яка істотна зміна моделі потрапить у продакшн | Eval harness, CI-логи, evaluation reports |
| AI-PI-03 | Вивід, що використовується для автоматизованих рішень, валідується за схемою і відхиляється, якщо сформовано некоректно | Визначення схем, логи валідації |
| AI-PI-04 | Сигнали галюцинацій та безпеки моніторяться у продакшні з алертингом на регрес | Дашборди моніторингу, конфіг алертів |
| AI-PI-05 | Для незворотних дій, згенерованих AI-системами, потрібен людський нагляд | Визначення workflow, логи людських перевірок |
Confidentiality (C1.x)
| ID контролю | Опис | Докази |
|---|---|---|
| AI-CONF-01 | Категорії чутливих даних задокументовані; промпти скануються на секрети та PII перед відправкою | Класифікація даних, логи DLP |
| AI-CONF-02 | Data Processing Agreements з провайдерами моделей включають відповідні пункти про zero-retention, training opt-out та регіон | Підписані DPA |
| AI-CONF-03 | Логи промптів та відповідей мають визначені періоди зберігання та workflow видалення | Політика retention, lifecycle rules |
| AI-CONF-04 | Дані клієнтів ізольовані per tenant у промптах, кешах та логах | Code review, пентест |
| AI-CONF-05 | Зобов'язання щодо конфіденційності відображені у контрактах із клієнтами та внутрішніх політиках | MSA, policy docs |
Privacy (P1.x — P8.x, якщо в області)
| ID контролю | Опис | Докази |
|---|---|---|
| AI-PRIV-01 | Користувачів повідомляють, коли вони взаємодіють з AI-системою | Скріншоти UI, product requirements |
| AI-PRIV-02 | Запити користувачів на видалення або експорт даних включають AI-згенеровані записи та пов'язані логи промптів | DSAR workflow, записи виконання |
| AI-PRIV-03 | Навчання моделей (якщо є) виключає дані клієнтів, якщо не отримано згоди | Маніфест тренувальних даних, записи згод |
| AI-PRIV-04 | DPA з вендорами охоплюють транскордонну передачу даних з відповідними запобіжними заходами | SCC, transfer impact assessment |
Як виглядають хороші докази
Аудитори SOC 2 хочуть докази, які є відтворюваними, датованими та прив'язаними до конкретного контролю. Для AI-компонентів ми намагаємося автоматизувати їх якомога більше.
Докази для AI-PI-02 (Regression Eval)
Контроль каже: регресійний eval запускається перед тим, як будь-яка істотна зміна моделі потрапить у продакшн. Хороші докази виглядають так:
- Директорія
evals/у репозиторії з golden dataset та eval-скриптом. - CI-логи, що показують, що eval запускався на кожному PR, який змінював конфіг моделі або промпту.
- Файл із summary-виводом, закомічений у release artifact.
- Алерт, що спрацьовує, якщо eval впав або був пропущений.
# .github/workflows/model-eval.yaml
name: model-eval
on:
pull_request:
paths:
- "config/models/**"
- "prompts/**"
- "evals/**"
jobs:
eval:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v4
- uses: actions/setup-python@v5
with: { python-version: "3.12" }
- run: pip install -r requirements.txt
- name: Run golden dataset eval
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
python -m evals.run \
--dataset evals/golden.jsonl \
--report out/eval-report.json
- name: Fail on regression
run: python -m evals.gate --report out/eval-report.json --min-score 0.88
- uses: actions/upload-artifact@v4
with:
name: eval-report-${{ github.sha }}
path: out/eval-report.json
У день аудиту ви експортуєте список змерджених PR за період, зіставляєте його з артефактами і показуєте аудитору, що кожна релевантна зміна має відповідний eval report. Готово.
Докази для AI-CONF-01 (Prompt Scanning)
Контроль каже: промпти скануються на секрети та PII перед відправкою. Хороші докази виглядають так:
- Код сканування з тестами.
- Продакшн-логи, що показують події редагування за вибірковий період.
- Runbook для інцидентів, коли редагування не спрацьовує.
# app/llm/redact.py
import re
from dataclasses import dataclass
PATTERNS: list[tuple[re.Pattern[str], str]] = [
(re.compile(r"sk-ant-[A-Za-z0-9-]{20,}"), "[REDACTED_ANTHROPIC_KEY]"),
(re.compile(r"AKIA[0-9A-Z]{16}"), "[REDACTED_AWS_KEY]"),
(re.compile(r"\b[\w.+-]+@[\w-]+\.[\w.-]+\b"), "[REDACTED_EMAIL]"),
(re.compile(r"\b(?:\d[ -]*?){13,16}\b"), "[REDACTED_CARD]"),
]
@dataclass
class RedactionResult:
text: str
hits: dict[str, int]
def redact(raw: str) -> RedactionResult:
result = raw
hits: dict[str, int] = {}
for pattern, label in PATTERNS:
matches = pattern.findall(result)
if matches:
hits[label] = len(matches)
result = pattern.sub(label, result)
return RedactionResult(text=result, hits=hits)
У парі зі структурованим логуванням лічильників редагування (не вмісту) аудитор може перевірити, що контроль діє протягом аудиторського періоду.
Due diligence вендорів
Для цілей SOC 2 кожен провайдер моделі є sub-service organization або вендором, залежно від того, як ви визначаєте область. У будь-якому випадку аудитор хоче бачити ваш due diligence щодо них. Кожен великий провайдер публікує SOC 2 звіт під NDA і поділиться ним на запит.
Пакет доказів вендора, який ми збираємо для кожного провайдера моделі в області:
- Останній SOC 2 Type II звіт (під NDA).
- Сертифікат ISO 27001, якщо є.
- DPA з відповідними додатками.
- Умови обробки даних, специфічні для моделі (zero retention, training opt-out).
- Зобов'язання щодо сповіщення про інциденти.
- Контакт з питань безпеки.
Зберігайте це у вашій системі vendor management з датою щорічного перегляду.
Типові зауваження і як їх уникнути
На SOC 2 проєктах, які ми супроводжували, ось зауваження, які повторюються, коли AI-функції додаються до області.
Зауваження 1: Зміни моделі обходять процес change management. Fine-tuning моделі або оновлення промпту виглядає як дрібна правка конфігу. Аудитори бачать це як зміну системи, що виробляє customer-facing вивід. Вимагайте PR review та тикет змін для кожної зміни промпту та моделі.
Зауваження 2: Немає доказів регресійного тестування перед релізом. "Ми подивилися очима" — це не доказ. Збудуйте eval harness, навіть якщо у ньому лише десять тест-кейсів.
Зауваження 3: Логи промптів зберігаються нескінченно. Без lifecycle-політики S3 бакети накопичуються. Аудитори відзначають це під Confidentiality та Privacy. Застосуйте lifecycle rules та задокументуйте період зберігання.
Зауваження 4: Немає DPA з провайдером моделі. Команди реєструються з кредитною карткою, пропускають продакшн-трафік і ніколи не підписують DPA. Виправте до аудиту.
Зауваження 5: Неясне походження тренувальних даних. Якщо ви fine-tune, аудитор хоче знати, звідки взялися дані, хто їх схвалив і чи було видалено PII. Ведіть маніфест датасетів.
Зауваження 6: Немає плану реагування на інциденти для AI-специфічних проблем. "Що буде, якщо модель віддасть PII клієнта?" повинно мати задокументовану відповідь та tabletop вправу у архіві.
Зауваження 7: Контракти з клієнтами не розкривають використання AI. Зобов'язання щодо Processing Integrity та Confidentiality можуть не збігатися з поведінкою продукту. Оновіть MSA та privacy notices.
Розширення існуючого звіту
Механічні кроки розширення SOC 2 для покриття AI:
- Scope workshop з вашим аудитором. Визначте, які AI-функції входять в область і які TSC застосовуються.
- Gap assessment відносно матриці контролів вище. Помітьте кожен як in place, partial або missing.
- Remediate partials та missings. Для команди з наявною гігієною це зазвичай 4–8 тижнів.
- Збір доказів за аудиторський період. Якщо нові контролі існують лише місяць, ваш Type II атестує ефективність роботи лише за цей місяць. Плануйте відповідно.
- Walkthrough з аудитором, щоб підтвердити розуміння.
- Fieldwork — стандартне sample testing SOC 2.
- Випуск звіту.
На практиці більшість клієнтів можуть додати покриття AI до поточного аудиту не в поточному, а в наступному звітному періоді — аудитору потрібні докази, обмежені в часі, а вам — чисті шість місяців роботи.
Прагматичний короткий список
Якщо ви хочете випередити це до наступного аудиту, зробіть ці шість речей:
- Зробіть інвентаризацію кожної AI-функції та класифікуйте її за матрицею контролів.
- Збудуйте regression eval harness. Запускайте у CI.
- Додайте middleware для сканування промптів та логуйте hits.
- Підпишіть DPA з кожним провайдером моделі, якого використовуєте.
- Встановіть retention policy на логи промптів і відповідей.
- Оновіть ваш incident runbook гілкою для AI.
Шість пунктів, приблизно квартал сфокусованої роботи. Аудитор буде задоволений; ще важливіше — задоволені будуть команди безпеки ваших клієнтів.
Наступні кроки
Розширення SOC 2 на AI-компоненти — це проєкт, а не перебудова. Фундамент, який у вас уже є — change management, access control, incident response — переважно переноситься. Net-new робота — у evaluation, обробці даних та управлінні вендорами. Почніть з матриці, замапте ваші функції та поговоріть з аудитором рано. Якщо хочете допомоги з gap assessment або побудовою пайплайну збору доказів, напишіть нам.