Прибуток:
- Можливість оцінити постачальника штучного інтелекту за сертифікацією, зберіганням, резидентністю даних і субпроцесором
- Здатність перевіряти запевнення документами та пунктами контракту, а не покладатися на словесні слова
- Можливість прив’язати DPA та умови відмови/видалення до перевірки безпеки перед покупкою
Більшість організацій не навчають власних моделей; використовує API провайдера. Це не усуває ризик — це лише передає його комусь іншому, і ви несете відповідальність за оцінку ризику, який ви передаєте. Кожна третя сторона, до якої переходять ваші дані, є розширенням кордону вашої безпеки. У цьому розділі ви дізнаєтесь, як оцінити постачальника ШІ; Ми навчимося проводити перевірку безпеки перед покупкою через сертифікати відповідності, угоду про обробку даних (DPA), зберігання даних, місцезнаходження даних і субпроцесорів.
Чому ризик третьої сторони?
У разі перевірки або порушення захист «не ми обробляли дані, а провайдер» вас не врятує. Ви є контролером даних; Постачальник є обробником даних. KVKK і GDPR розрізняють це, але більша частина відповідальності залишається за вами. Тому вибір постачальника – це не рішення про покупку, а рішення щодо безпеки.
Увага: «Великий і відомий провайдер» не є гарантією безпеки. Гарантія випливає з підписаних умов контракту та підтверджених сертифікатів; не через репутацію бренду.
Оціночні осі
Вивчіть постачальника ШІ за семи осями:
- Сертифікати відповідності: SOC 2 Type II (незалежний аудит засобів контролю безпеки організації), ISO/IEC 27001 (стандарт управління інформаційною безпекою) і все частіше ISO/IEC 42001 (стандарт системи управління штучним інтелектом).
- Зберігання даних: Як довго зберігається підказка/відповідь? Чи пропонується ZDR (нульове збереження даних)?
- Використання в навчанні: чи використовуються ваші дані для навчання моделі? (Зазвичай «ні» на корпоративному рівні.)
- Резиденція даних: у якій країні/регіоні обробляються та зберігаються дані?
- Субпроцесори: які ще компанії використовує провайдер (хмара, моніторинг)? Вони також є частиною вашого кордону.
- Функції безпеки: шифрування (у дорозі/в спокої), контроль доступу, журнал аудиту, час сповіщення про події.
- Контракт і вихід: чи існує DPA? Чи гарантовано ваші дані буде видалено, якщо послуга припиниться? Який ризик блокування?
Крок за кроком: Огляд постачальника
- Надішліть опитування безпеки. Перетворіть наведені вище осі на список запитань.
- Вимагайте доказів. Перевірте претензії документацією (звіт SOC 2, сертифікат ISO, проект DPA).
- Відобразити потік даних. Які дані куди надходять і для якого процесу?
- Обговоріть DPA. Не починайте виробництво без підписання угоди про обробку даних (правовий текст, який визначає, як постачальник оброблятиме дані).
- Огляд субпроцесорів. Розглянемо весь ланцюжок.
- Налаштуйте графік повторної оцінки. Ризик постачальника слід перевіряти принаймні раз на рік.
Чотири шаблони, які можна копіювати
Основне дослідження безпеки постачальників:
Що потрібно запитати у провайдера:1. Які у вас є сертифікати відповідності? (SOC 2 Type II, ISO 27001/42001) Чи можете ви поділитися звітом?2. Скільки даних про запит/відповідь зберігається? Чи є варіант ZDR?3. Чи використовуються наші дані під час навчання моделей? Чи прописано це в договорі?4. У якому регіоні обробляються/зберігаються дані? Чи можемо ми вибрати регіон?5. Хто ваші субпроцесори? Як повідомити про зміни?6. Який період сповіщення у разі порушення?7. Як і коли наші дані видаляються після закінчення контракту?
Правило перевірки перевірки доказів:
Для кожного твердження «чи є докази?» перевірте:- Претензія на сертифікацію -> чи бачив я поточний номер звіту/сертифікату?- Претензія на ZDR/зберігання -> це написано в пункті контракту?- Невикористання в навчанні -> Чи є відкрите положення в DPA? Позначайте кожну претензію без доказів як «НЕ ПЕРЕВІРЕНО»; Не сприймайте словесних слів.
Підказка зіставлення потоку даних:
Витягніть потік даних для такої інтеграції: {{ сценарій }}Уточніть на кожному кроці: які дані (чи містять вони ідентифікаційну інформацію), куди вони спрямовуються (яка компанія/регіон), з якою метою, скільки зберігається. Позначте кожен крок і підпроцесори, які перетинають межі підприємства.
Система показників ризику постачальника:
Оцініть кожну вісь 0-2 (0=немає, 1=частково, 2=повно): сертифікат, ZDR/утримання, не використовувати в навчанні, резидентність даних, прозорість субпроцесора, повідомлення про порушення, вихід/видалення. Якщо загальна сума < 10 або будь-яка вісь дорівнює 0: «ВИСОКИЙ РИЗИК, запущено у виробництво».
Слабка підказка / Сильна підказка
поганий підхід
Сильний підхід
Припускаючи, що «велика компанія безпечна»
Перевірте сертифікат і DPA з документом
покладаючись на усні запевнення
Пов'язка кожної гарантії з положенням контракту
Просто перегляньте постачальника
Також розгляньте ланцюжок субпроцесора
вибери один раз і забудь
Річний календар переоцінки
Три міні-чохли
Випадок 1 — Проект, розпочатий без DPA, було зупинено. Роздрібна компанія швидко залучила помічника у виробництво; Згодом команда юристів виявила відсутність підписаного DPA з постачальником. Проект було призупинено, поки тривала обробка даних клієнтів, було узгоджено DPA та відновлено після того, як місце проживання даних було визначено в регіоні ЄС.
Випадок 2 — Ланцюжок підпроцесорів кидає сюрприз. Медична компанія затвердила основного постачальника; Однак картографування потоку даних виявило, що провайдер використовував компанію в третій країні для моніторингу. Це порушило вимогу щодо резидентності даних. Компанія додала до договору перебування в регіоні.
Випадок 3 — Система показників усунула дешеву ставку. Оцінено три пропозиції. Найдешевший постачальник отримав 0 (без SOC 2) на осі сертифікації. Правило системи показників «якщо будь-яка вісь дорівнює 0, запустіть її у виробництво» було вилучено; Було обрано на 22% дорожчого, але повністю оціненого постачальника, і рішення було задокументовано для аудиту.
Порада: ніколи не плутайте дві різні гарантії: «наші дані не зберігаються (ZDR)» і «наші дані не використовуються в навчанні» — це окремі положення. Постачальник може пропонувати одне, але не інше; Чітко вкажіть у договорі обидва.
Поширені помилки
- Враховуючи розмір/бренд постачальника як гарантію безпеки.
- Покладаючись на усну інформацію, не підтверджуючи твердження документально.
- Введення у виробництво без підписання DPA.
- Ігнорування ланцюжка субпроцесора (там пробита резиденція даних).
- Думаючи, що ZDR і гарантія «не використовується в освіті» - це одне і те ж.
- Затвердження постачальника один раз і відсутність повторної оцінки щорічно.
Підсумовуючи
- Ви є контролером даних; Вибір постачальника – це рішення про безпеку, а не про купівлю.
- Оцініть за семи осями: сертифікація, збереження/ZDR, освітнє використання, резидентність даних, субпроцесори, функції безпеки, контракт/вихід.
- Перевірте кожну гарантію документом і договірним пунктом; Бренду та устної інформації недостатньо.
- Також розгляньте ланцюжок субпроцесора; там часто проколюється місце проживання даних.
- Не починайте виробництво до підписання DPA та щорічно переглядайте постачальника.
Аплікаційне завдання
Заповніть опитування безпеки вище для постачальника ШІ, якого ви використовуєте (або оцінюєте), і запитайте «чи є докази?» за кожну відповідь. Відзначте галочкою стовпець. Потім відобразіть потік даних і позначте кожен крок, який перетинає межі підприємства. Нарешті, оцініть сім осей і створіть карту показників ризиків і запитайте: «Чи придатний він для виробництва?» Напишіть причини свого рішення.
контрольний список
- [ ] Я задокументував сертифікати відповідності постачальника (SOC 2 / ISO 27001).
- [ ] Зберігання даних, ЗДР і пункти «невикористання в освіті» прописані в договорі.
- [ ] Він відповідає моїм вимогам щодо проживання даних (KVKK/GDPR).
- [ ] Я відобразив і оцінив ланцюжок субпроцесора.
- [ ] Я не виходив на виробництво без підписаного DPA.
- [ ] Я створив щорічний календар повторної оцінки для постачальника.