Чек-ліст AI-procurement: 15 питань перед підписанням

Якщо ви власник, який наступного тижня підписує MSA з AI-вендором, єдиний найкращий передбачувач жалю через 12 місяців — це які питання ви не поставили на procurement-дзвінку. Я бачив, як засновники платили 6-значні річні контракти вендорам, які не могли відповісти на половину пунктів цього списку.

Чому AI procurement відрізняється від звичайного SaaS?

Три причини. Перша: ваші дані можуть тренувати чужу модель, якщо ви явно не відмовитесь — категорія ризику, якої не існувало у 2018-му. Друга: AI-вендори часто ланцюгом мають 3-7 sub-processors (модель, hosting, vector DB, observability, оплата) — кожен це поверхня data-flow. Третя: AI-продукти змінюються щотижня. Модель, куплена в січні, може бути іншою в квітні з іншою поведінкою, вартістю і failure modes.

Definition: AI sub-processor — будь-яка третя сторона, якій вендор передає ваші дані для надання послуги: провайдер моделі (OpenAI, Anthropic), hosting (AWS, GCP), vector store, observability тощо.

15 питань нижче — це ті, які ми бачили реально виявляли проблеми до підпису.

15 питань

Нижче робочий список. Надішліть як письмовий додаток до стандартного MSA, попросіть письмових відповідей, і ставтесь до timeline відповіді як до сигналу.

Дані та тренування (Q1-Q5)

1. Де фізично зберігаються наші дані, за регіоном і провайдером? Red-flag: "AWS, global." Ви хочете region-specific commitment (напр., "eu-central-1 only").

2. Чи використовуються наші дані для тренування ваших моделей або моделей третіх сторін? Red-flag: "Тільки aggregated / anonymized." Агрегація — це не анонімізація з юридичної точки зору. Потрібне чисте "ні" з контрактним гачком.

3. Чи можемо ми opt-out з усього тренування, включно з aggregate/telemetry? Red-flag: "Так, напишіть в підтримку." Потрібен opt-out як контрактний дефолт, не саппорт-тикет.

4. Яка ваша політика збереження даних після термінації контракту? Red-flag: "Industry standard." Потрібне конкретне вікно (напр., "60 днів, потім certified deletion з attestation").

5. Чи є у вас документований incident response для AI-специфічних ризиків (prompt logs, embedding stores)? Red-flag: "Ми відповідаємо SOC 2." SOC 2 не покриває витоки prompt-логів. Потрібні AI-specific runbooks.

Definition: Training-data opt-out — контрактне положення, що ваші входи, виходи і метадані не можуть використовуватись для перетренування чи fine-tune моделі, включно з вендорською.

Безпека та compliance (Q6-Q9)

6. Чи маєте SOC 2 Type II, і чи можемо побачити останній звіт? Red-flag: "Type I" або "audit in progress for 18 months." Type II покриває операційну ефективність у часі.

7. Яка ваша модель аутентифікації — SSO/SAML обов'язковий, MFA для admin? Red-flag: "SSO на enterprise tier." Потрібно SSO на тому tier, який ви купуєте.

8. Як ви обробляєте PII / PHI / фінансові дані в prompts та outputs? Red-flag: "Клієнти не мають це писати в prompts." Це не контроль, це побажання.

9. Надайте поточний список sub-processors з регіонами, функціями і даними, які кожен отримує. Red-flag: "Available on request." Потрібно зараз, з notification rights на зміни.

SLA та change management (Q10-Q12)

10. Який ваш uptime SLA і які service credits, якщо ви пропустите? Red-flag: "99.9% with credits at our discretion." Потрібні визначені credits і визначення "downtime", яке включає degraded performance моделі.

11. Як ви повідомляєте клієнтів, коли змінюєте базову модель (версія, провайдер, fine-tune)? Red-flag: "Зазвичай не повідомляємо." Це питання, яке ламає більшість AI-контрактів. Потрібне 30+ днів письмове повідомлення з rollback rights на material behavior changes.

12. Який ваш опублікований support SLA для production-проблем — first response і resolution? Red-flag: "Best effort." Потрібні години.

Definition: Model-change notification — контрактне зобов'язання, що вендор заздалегідь повідомляє вас (письмово), коли вони міняють модель, fine-tune або змінюють inference-параметри.

Exit і continuity (Q13-Q15)

13. Який формат експорту даних і час експорту в кінці контракту? Red-flag: "CSV через support ticket." Потрібен документований API-driven export з визначеним SLA.

14. Який exit clause, якщо вас придбають або ви відмовитесь від продукту? Red-flag: "Стандартна MSA termination." Потрібен специфічний change-of-control clause і product-discontinuation notice (90+ днів).

15. Чи пропонуєте sandbox / pilot з production-parity даними на перші 30-60 днів, no-fault exit? Red-flag: "Пілоти — це повний річний контракт." Потрібен реальний out, не знижка.

Copy/paste procurement addendum

Вставте блок нижче у свій purchase order.

AI Vendor Procurement Addendum — будь ласка, дайте письмову відповідь перед підписом.

Дані:
1. Data residency (регіон + провайдер): ____
2. Використання даних клієнта для тренування: [yes/no/limited]
3. Opt-out механізм: ____
4. Post-termination retention + deletion attestation: ____
5. AI-специфічний incident response runbook (attach): ____

Безпека:
6. SOC 2 Type II звіт attached: [yes/no]
7. SSO/SAML на нашому tier: [yes/no]
8. PII/PHI/фінансові контролі: ____
9. Sub-processor list з регіонами (attach): ____

SLAs:
10. Uptime SLA + service credits: ____
11. Model-change notification (дні, письмово, rollback): ____
12. Support SLA (first response, resolution): ____

Exit:
13. Data export формат + SLA: ____
14. Change-of-control + discontinuation notice: ____
15. No-fault pilot window (дні): ____

Owner-side counter-signature потрібен на items 2, 3, 9, 11, 14.

Ці п'ять пунктів — ті, які найімовірніше тихо змінять на vendor renewal.

Tool tip (Course for Business): Більшість SMB, з якими ми працюємо, не мають окремої procurement-функції для AI — CEO або COO підписує контракти напряму. Наша 6-week program включає procurement-literacy модуль, щоб AI Champions (1:15-20) у вашій команді ревʼюїли відповіді вендорів до того, як їх побачить legal. Augment, don't replace застосовується і до vendor evaluation: чемпіон робить чернетку порівняння, власник підписує. Дивіться curriculum: https://course.aiadvisoryboard.me/business.

Team scan (what AI champions report after week 1)

• Більшість SMB виявляють, що поточний список AI-вендорів у 2-3 рази довший, ніж executive team знала (shadow procurement)
• Найчастіше пропускається питання #11 (model-change notification)
• 40-60% вендорів відмовляються надати повний sub-processor list з першого запиту
• Чемпіони ловлять 3-5 vendor red flags на квартал, які legal би пропустив
• Перша high-leverage перемога: відхилити одне over-broad data clause у vendor MSA, тиждень 1
• Перше тертя: існуючі вендори опираються retroactive addenda — обробляти на renewal
• Типовий патерн: enterprise tiers потрібні для SSO, бюджетний сюрприз
• Перше governance-питання: "Хто власник sub-processor change-notification email?" — відповідь: COO + чемпіон
• Індикатор адаптації: procurement checklist для кожного нового вендора з місяця 2
• Економія часу: legal review на AI-вендора падає з 4 годин до 45 хвилин після стандартизації addendum

Micro-case (what changes after 7-14 days)

Компанія professional services на 90 осіб запустила цей checklist проти трьох найдорожчих AI-вендорів у тиждень 1. Виявили: один вендор використовував prompts клієнтів для тренування shared моделі (Q2/Q3 red flag), один не мав model-change notification policy (Q11), один мав у sub-processor list payments processor, який не мав справи з контентом документів (Q9). Усі три renegotiated на renewal — загальна економія близько €18K на рік і три privacy-exposure поверхні закрито. Власник почав використовувати той самий checklist на кожному новому pilot з дня 14. Жодного нового інструмента — лише письмові питання.

Note on this case: This example is illustrative — based on typical patterns we observe with companies of 30-500 employees, not a single named client. Specific numbers are rounded approximations of common ranges, not guarantees.

Tool tip (Course for Business): Shoulder-to-Shoulder hot seat у нашій 6-week program — це й те, як procurement робиться на практиці: чемпіон сидить з покупцем (зазвичай COO або CEO), проходить відповіді вендора наживо і помічає прогалини в реальному часі. Augment, don't replace тут теж: чемпіон робить технічний фільтр, власник підписує. Забронюйте 30-хв дзвінок: https://course.aiadvisoryboard.me/business.

FAQ

А EU AI Act compliance — це проблема вендора чи моя? Обидвох. Вендор має розкрити intended use, джерела training data і відомі ризики. Ви як deployer все одно несете відповідальність за deployment context — high-risk uses (HR screening, кредитний скоринг, освіта) несуть deployer obligations незалежно від vendor compliance.

Чи стосуються ці 15 питань ChatGPT Teams або Claude for Work? Великі платформи відповідають на більшість цих питань у публічних DPA і trust documentation — не потрібен custom addendum, але треба прочитати DPA. Питання критичні для другого ешелону вендорів і AI-feature SaaS.

Який реалістичний timeline procurement тепер з AI? Близько 50% довше за еквівалентний не-AI SaaS — для контракту $50-200K на рік очікуйте 3-6 тижнів повної оцінки за умови відповідального вендора.

Чи варто використовувати third-party procurement tool? Не для SMB-об'ємів. Список вище плюс shared sheet достатній, поки ви не підписуєте 15-20 AI-вендорів на рік.

Висновок

15 питань не сповільнюють procurement — вони замінюють rework, який стається 90 днів після підпису, коли модель вендора змінилась під вами і ніхто не побачив. Ставтесь до timeline письмової відповіді як до сигналу: серйозні вендори відповідають повністю за тиждень.

Виберіть наступний AI-контракт. Надішліть addendum. Відстежте, на які пункти вони опираються. Там ваш реальний ризик.

Якщо хочете, щоб кожен співробітник запустив свою першу AI-автоматизацію за п'ять днів — забронюйте 30-хв дзвінок: https://course.aiadvisoryboard.me/business.