B2B SaaS з корпоративними клієнтами: SOC 2 + AI-агенти

Чому SOC 2 тепер охоплює AI-агентів

Критерії послуг довіри AICPA підтримують оцінку контролів безпеки, доступності, цілісності обробки, конфіденційності або приватності. Перевірка SOC 2 має визначену систему й обрані критерії; вона не охоплює автоматично кожну систему та кожну категорію.

Оцініть, чи входить кожна AI-функція до описаної системи сервісу та чи впливає на його зобов'язання або цілі контролів. Доступ до даних клієнтів і зовнішні дії — підстави перевірити межі, а не заміна їх документування.

Аудитори визначають область охоплення на основі систем, релевантних для зобов’язань сервісної організації перед клієнтами. Якщо ви взяли на себе зобов’язання перед корпоративними клієнтами щодо захисту їхніх даних, доступності вашої системи та точності обробки — ваші AI-агенти, що торкаються цих даних та обробки, перебувають у сфері охоплення.

П’ять TSC, зіставлених з AI-агентами

1. Безпека (CC6, CC7, CC8)

Засоби контролю безпеки SOC 2 вимагають, щоб ваша система була захищена від несанкціонованого доступу. Для AI-агентів:

CC6 — Логічний та фізичний контроль доступу

• AI-агенти повинні мати мінімальний доступ до даних клієнтів — лише те, що вимагається для конкретного завдання
• Доступ, наданий AI-агентам, повинен журналюватись та підлягати перевірці
• Облікові дані AI-агентів (API-ключі, службові облікові записи) повинні управлятись з тією самою ретельністю, що й облікові дані людини: ротація, моніторинг, можливість відкликання

CC7 — Моніторинг системи

• Активність AI-агентів повинна відстежуватись на предмет аномальної поведінки
• Сповіщення про незвичні паттерни викликів інструментів, неочікуваний обсяг доступу до даних або активність у неробочий час
• Покриття моніторингом повинно включати AI-агентів, а не лише сеанси користувачів-людей

CC8 — Управління змінами

• Оновлення моделей є змінами у виробничій системі і повинні проходити через управління змінами
• Це означає: задокументована зміна, протестована в невиробничому середовищі, перевірена, затверджена до розгортання
• Багато команд розглядають оновлення моделей як зміни конфігурації, а не зміни коду — аудитори SOC 2 розглядають їх як зміни виробничої системи

2. Доступність (A1)

Засоби контролю доступності вирішують, чи є ваша система доступною відповідно до взятих зобов’язань. Для AI-агентів:

• Якщо ваш AI-агент є частиною послуги, на яку покладаються ваші клієнти, його доступність є частиною вашого SLA доступності
• Режими збоїв та коректна деградація повинні бути спроектовані — що відбувається, коли API моделі недоступний, коли шар управління не працює, коли зовнішній інструмент недосяжний?
• Моніторинг доступності повинен охоплювати залежності AI-агентів, а не лише вашу власну інфраструктуру

3. Цілісність обробки (PI1)

Це найскладніший критерій для AI. Цілісність обробки означає, що ваша система обробляє дані «повно, точно, своєчасно та авторизовано». Для AI-агентів «точно» є викликом.

Що запитують аудитори:

• Яка частота точності вихідних даних вашого AI-агента?
• Як ви це знаєте? Яка ваша методологія вимірювання?
• Що відбувається, коли AI виробляє неправильний результат?
• Який ваш процес виправлення помилок?
• Чи обробляє AI-агент усі вхідні дані, які він повинен обробляти, і лише ті, які він повинен?

Як виглядає відповідна цілісність обробки AI:

• Визначені показники точності, що вимірюються безперервно, з задокументованими прийнятними діапазонами
• Журналювання помилок та робочі процеси виправлення
• Вибіркова перевірка та перегляд результатів AI людиною за регулярним графіком
• Задокументована область: які вхідні дані обробляє агент і що він не обробляє

4. Конфіденційність (C1)

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

• Дані клієнтів, що обробляються AI-агентами, повинні оброблятись з тими самими засобами контролю конфіденційності, що й дані клієнтів, що обробляються іншими системами
• Промпти AI-агентів та відповіді викликів інструментів, що містять дані клієнтів, повинні бути захищені під час передачі та зберігання
• До використання даних клієнтів для навчання перевірте договірні дозволи, сумісність мети та застосовну правову підставу; згода — одна з можливих підстав, а не універсальна вимога SOC 2
• Зберігання історії розмов AI-агентів повинно відповідати вашим зобов’язанням щодо зберігання даних

5. Приватність (P1–P8)

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

• Персональна інформація, що обробляється AI-агентами, повинна мати задокументовану законну підставу
• Мінімізація даних: AI-агент повинен мати доступ лише до персональної інформації, необхідної для завдання
• Права суб’єктів даних (доступ, видалення, переносимість) повинні бути реалізовані для даних, що обробляються AI-агентами
• Треті сторони, що отримують персональні дані через виклики інструментів AI-агента, повинні бути охоплені вашою програмою управління постачальниками

Що тепер запитують анкети корпоративної безпеки

Підготуйтеся до питань про доступ, управління змінами, моніторинг та обробку даних AI-функції. Нижче — практичні питання для перевірки, а не підтверджене опитування корпоративних анкет:

1. «Чи включає ваш продукт функції AI або ML? Якщо так, опишіть дані, що використовуються для їх навчання.»
2. «Чи має ваша AI-система доступ до даних клієнтів? Опишіть засоби контролю доступу.»
3. «Як ви відстежуєте вашу AI-систему на предмет точності та упередженості?»
4. «Які засоби контролю запобігають розкриттю вашою AI-системою даних одного клієнта іншим клієнтам?»
5. «Як ви обробляєте збої AI-системи? Яка поведінка при деградації?»
6. «Чи приймає ваша AI-система автоматизовані рішення щодо клієнтів? Якщо так, чи мають клієнти право на перегляд або оскарження?»

Якщо управління вашим AI-агентом не задокументовано, ці питання вимагають імпровізованих відповідей. Якщо ваша архітектура управління спроектована та задокументована, вони відповідаються з вашої існуючої документації.

Пакет доказів SOC 2 для AI-агентів

Будуйте пакет доказів навколо контролів перевірки, звітного періоду та запитів аудитора. Залежно від меж корисні записи можуть включати:

Докази контролю доступу:

• Документація прав доступу AI-агентів (до чого він може отримати доступ)
• Записи перевірки доступу (періодична перевірка дозволів AI-агентів)
• Записи ротації облікових даних

Докази управління змінами:

• Заявки на зміни для оновлень моделей та змін правил управління
• Докази тестування змін AI-агентів
• Записи затвердження виробничих змін

Докази моніторингу:

• Журнали активності AI-агентів
• Історія сповіщень виявлення аномалій
• Записи моніторингу доступності AI-агентів

Докази цілісності обробки:

• Методологія вимірювання точності
• Результати точності за аудиторський проміжок (щомісяця або щоквартально)
• Журнал помилок та записи вирішення
• Записи вибіркових перевірок людиною

Записи інцидентів:

• Інциденти AI-агентів, їхній вплив та вирішення
• Документація першопричини
• Докази коригувальних дій

Часті запитання

П: Наша AI-функція використовує сторонній API моделі (Claude, GPT-4). Хто відповідає за відповідність SOC 2?

Ви. Звіт SOC 2 провайдера моделі охоплює їхню інфраструктуру. Ваш звіт SOC 2 охоплює вашу послугу. Ваша AI-функція — спосіб використання моделі, які дані ви передаєте їй, як ви обробляєте результати — є вашою відповідальністю. Отримайте звіти SOC 2 від провайдерів моделей, яких ви використовуєте, та включіть їх до вашої програми управління постачальниками, але розумійте, що їхній звіт охоплює їхню область, а не вашу.

П: Чи вимагають оновлення моделей процес управління змінами SOC 2?

Так, якщо модель є частиною вашої виробничої системи і оновлення може вплинути на поведінку вашої системи. Це включає: оновлення моделей від провайдера (нова версія Claude, оновлення GPT-4o), зміни конфігурації системних промптів, зміни правил управління, що регулюють агента, та зміни доступу до інструментів або інтеграцій. Включіть оновлення моделей до вашого робочого процесу управління змінами.

П: Наш AI-агент — це бета-функція. Чи все одно потрібні засоби контролю SOC 2?

Якщо бета-користувачі є корпоративними клієнтами, чиї дані охоплені вашими зобов’язаннями щодо послуг — так. «Бета» є позначенням продукту, а не звільненням від відповідності. Дані є реальними, а зобов’язання SOC 2 застосовуються. Проектуйте бету із засобами контролю або виключіть бета-користувачів з системного кордону SOC 2 (що може обмежити доступність бети для корпоративних клієнтів).

П: Що означає «цілісність обробки» для агента на базі LLM?

Якщо цілісність обробки входить до меж перевірки, визначте передбачену обробку, метрики помилок і реакцію на збої. Поєднуйте тести, моніторинг і методи перевірки відповідно до функції; вибіркова перевірка людьми — один варіант, а не універсальний основний метод.

П: Як нам обробляти наслідки SOC 2 AI-агента, що викликає зовнішні API?

Зовнішні API, що викликає ваш AI-агент, є постачальниками у вашій програмі управління постачальниками. Оцінюйте їх щодо позиції безпеки, отримуйте їхні звіти SOC 2, де доступні, та документуйте прийняття ризику там, де звіти недоступні. Дані, що передаються зовнішнім API від імені клієнтів, повинні бути охоплені відповідними договорами (DPA для персональних даних, угоди про конфіденційність для конфіденційної інформації).

Микола Ковтун, засновник Infracortex AI Studio. Cortex генерує пакет доказів SOC 2 для розгортань AI-агентів — журнали доступу, записи змін, докази цілісності обробки та документацію інцидентів — як побічний продукт runtime-управління. Забронюйте дзвінок для обговорення покриття SOC 2 вашого AI-агента.

Дивіться також: Управління AI-агентами для фінтех: практичний чеклист | Прихована вартість немоніторованих викликів інструментів AI-агентів | Чому runtime — це commodity, а управління — це рів (EN)