ChatGPT vs Claude vs Gemini: як обрати AI-асистента для роботи

ChatGPT, Claude і Gemini перекривають базові задачі: пояснення, чернетки, аналіз файлів, пошук і роботу з тривалим контекстом. Тому питання «хто найкращий» без опису процесу майже порожнє. Корисне рішення починається з того, де вже живуть документи команди, який результат треба отримати, хто його перевіряє і які дані дозволено передавати сервісу.

Для широкого набору інструментів у єдиному чаті варто перевірити ChatGPT; для зосередженої роботи з project knowledge і самостійними редагованими результатами — Claude; для процесів, щільно пов’язаних із Gmail, Drive, Docs, Sheets і Meet, — Gemini у Google Workspace. Це стартові гіпотези для тесту, а не рейтинг якості моделей. Доступність функцій залежить від плану, регіону, адміністративних налаштувань і може змінитися після публікації сторінки.

ChatGPT Projects групують чати, файли та інструкції навколо довгої задачі; платні плани можуть додавати deep research, agent mode та інші інструменти. Apps підключають зовнішні джерела, можуть шукати, синхронізувати контент або, для окремих конфігурацій, пропонувати підтверджувані write actions. Це зручно, коли команда хоче один загальний AI-workspace і готова окремо керувати дозволами кожного app.

Claude Projects створюють ізольовані робочі простори з власною історією, інструкціями й knowledge base; при великому обсязі project knowledge Anthropic описує автоматичне використання RAG. Artifacts виносять суттєвий документ, код, візуалізацію чи застосунок в окрему область для ітерацій. Research виконує послідовний пошук у web та, коли підключено, внутрішньому контексті й повертає цитовану відповідь.

Gemini має природну перевагу інтеграційного розташування для організацій у Google Workspace: side panel працює в Gmail, Docs, Sheets, Slides, Drive і Chat, а адміністрація керує доступом до функцій та джерел. Gemini app підтримує Gems для повторюваних ролей і deep research, а Gemini Notebook працює з наданими джерелами. Перевага тут не означає автоматично кращу відповідь — вона означає менше перемикань і потенційно коротший шлях до дозволеного корпоративного контексту.

• Універсальний чат, різні tools та apps → почніть pilot із ChatGPT.
• Довгі документи, project knowledge та редаговані Artifacts → перевірте Claude.
• Gmail, Drive, Docs, Sheets і Meet як основний робочий контур → перевірте Gemini.
• Критичний workflow або закупівля для команди → тестуйте щонайменше двох кандидатів на однаковому наборі задач.
• API-продукт, а не готовий асистент → переходьте до model routing і окремої оцінки API-контрактів.

Усі три продукти мають сценарії поглибленого дослідження, але порівнювати слід не брендовану кнопку, а результат: чи видно використані джерела, чи можна обмежити область пошуку, як система працює з внутрішніми документами, чи легко відтворити висновок і що відбувається з недоступним або суперечливим джерелом. Для юридичного, медичного чи фінансового рішення цитована відповідь усе одно потребує перевірки фахівцем.

Підготуйте три однакові research briefs: огляд із публічних першоджерел, синтез із внутрішнього набору документів та змішаний запит із конфліктом між старою й новою версією політики. Оцінюйте coverage, коректність цитат, unsupported claims, здатність помітити конфлікт, час до результату й обсяг ручної перевірки. Кількість знайдених посилань сама по собі не є якістю.

Project, memory, app, integration і workspace side panel — різні механізми. Перед pilot намалюйте data-flow: джерело документа, identity користувача, область дозволів, retention, можливість видалення, журнали адміністратора та місце, де результат зберігається далі. Не переносіть персональний досвід безкоштовного акаунта на enterprise-пропозицію: умови обробки й доступні controls можуть відрізнятися.

Дайте сервісу мінімальний тестовий набір без секретів і перевірте негативні сценарії: користувач без доступу просить чужий файл; документ містить prompt injection; підключення відкликано посеред сесії; відповідь посилається на застарілу копію; write action має змінити зовнішній стан. Для будь-якої зміни стану потрібні явне підтвердження, вузький scope, журнал і перевірка postcondition — незалежно від логотипа постачальника.

Виберіть 12–20 репрезентативних задач, а не випадкові prompts: короткий лист, складне редагування, аналіз таблиці, синтез кількох PDF, дослідження зі свіжими джерелами, робота з внутрішнім контекстом, створення повторюваного шаблону та два навмисно неоднозначні запити. Зафіксуйте однаковий input, дозволені інструменти й acceptance criteria; не оптимізуйте prompt для одного кандидата після того, як побачили його слабке місце.

Оцінюйте task success, factual errors, citation validity, час користувача до прийнятного результату, кількість виправлень, стабільність повторів і повну вартість плану. Додайте окремий security/admin scorecard: identity, sharing, retention, export, audit, regional constraints і offboarding. Ціна підписки без вартості перевірки й інтеграції так само оманлива, як швидка красива відповідь без правильного результату.

• Define → ролі, дані, задачі й критичні помилки.
• Normalize → однакові inputs, tools і критерії приймання.
• Run → засліплений тест двох або трьох кандидатів.
• Review → якість, людський час, controls і TCO.
• Decide → один основний сервіс, дозволений резерв або різні інструменти для різних ролей.
• Recheck → повторний eval після суттєвої зміни моделі, функції чи умов.

Одна ліцензія спрощує support і governance, але може погіршити спеціалізовані процеси. Команда може обрати Gemini для Workspace-native операцій, Claude для визначеного document workflow, а ChatGPT для окремого research або tool-rich сценарію. Такий портфель виправданий лише коли виграш підтверджено тестом, а правила класифікації даних і власники сервісів зрозумілі користувачам.

Не перетворюйте multi-vendor на хаотичний BYOAI. Каталог дозволених use cases має вказувати сервіс, типи даних, доступні інтеграції, потрібний human review і шлях ескалації. Для власного продукту краще ізолювати application contract від провайдера й застосувати model routing; для офісного асистента часто важливіші identity, discovery й adoption, ніж переносимість кожного prompt.

Персональний тест показує, чи зручно писати й аналізувати, але не доводить придатність сервісу для організації. Перед закупівлею створіть окрему матрицю control plane: identity lifecycle, групи й ролі, дозволені джерела, read/write authority, retention, residency, audit та compliance export, spend limits, incident isolation і offboarding. Перевіряйте конкретний plan та увімкнену конфігурацію: однакова назва продукту не означає однаковий набір адміністративних гарантій.

Першоджерела показують різні точки керування. OpenAI документує workspace-рівень і role-scoped доступ до apps та окремий action control; Anthropic — custom roles і capabilities для груп в Enterprise; Google — поєднання admin restrictions з дозволами власника контенту, де Gemini має успадковувати доступ користувача до Workspace-даних. Це не рейтинг зрілості. Це три набори тверджень, які procurement-команда повинна перетворити на тести: restricted user не знаходить заборонений документ, вимкнений connector справді недоступний, write action не обходить approval, а видалення або retention видно в доказах.

Не зараховуйте marketing checkbox як PASS. Попросіть адміністратора продемонструвати policy у консолі, виконайте позитивний і негативний запити під двома ролями, збережіть timestamped evidence та перевірте результат у доступному audit/compliance контурі. Якщо потрібний контроль існує лише в дорожчому plan, оцінюйте повну конфігурацію, а не ціну найдешевшого seat. Якщо сервіс не може довести критичну межу, результат pilot — conditional або fail незалежно від якості тексту.

• Identity → SSO/SCIM або інший потрібний lifecycle, деактивація та session controls.
• Context → джерела, user ACL, sync/index boundary, freshness і видалення.
• Authority → read/write scope, confirmation policy, least privilege і kill switch.
• Evidence → audit, compliance export, retention, residency та incident reconstruction.
• Economics → seat, usage, integrations, review time, support і exit cost.

Результатом pilot має бути не презентація з враженнями, а відтворюваний evidence pack. Зафіксуйте дату, plan, region, admin toggles, доступні функції, ідентичний task set, вхідні файли, rubric і critical-failure rules. Для кожного кандидата збережіть сирий output, джерела, reviewer corrections, elapsed human time та причину accept/reject. Окремо ведіть журнал configuration deviations: якщо одному сервісу дозволили web або внутрішній connector, це інша умова тесту, а не чесна перемога.

Розділіть результати за task slice. Drafting, document synthesis, spreadsheet work, cited research і workspace retrieval мають різні failure modes, тому один середній бал приховує важливі провали. Для кожного slice визначте minimum quality floor і заборонені помилки: вигадане джерело, витік restricted документа, непідтверджена зовнішня дія або пропущений конфлікт політик повинні мати severity, а не розчинятися в сумарному score.

Decision record має назвати основний сервіс для конкретних ролей, дозволені дані, потрібний human review, owner, review date і triggers для повторного eval. Такими triggers можуть бути новий connector, зміна retention/data terms, новий agentic режим, інша billing model або суттєва зміна вашого workflow. За відсутності версій і evidence наступний vendor review почнеться з пам’яті учасників, а не з порівнюваної baseline.

До стандартизації змоделюйте втрату доступу до обраного сервісу. Складіть inventory не лише чатів, а й project instructions, файлів, shared artifacts, custom assistants або Gems, apps/connectors, research templates, role policies та downstream документів. Позначте, що можна експортувати машинно, що потребує ручного перенесення, що належить зовнішній системі, а що взагалі не повинно бути system of record усередині AI-асистента.

Практичний rollback drill бере один репрезентативний workflow і переносить його на дозволений резерв: відновлює мінімальний instruction pack, повторно підключає джерела з least privilege, проганяє golden tasks і звіряє quality та permissions. Не треба вимагати бітової ідентичності відповідей. Потрібно довести continuity прийнятного бізнес-результату, відкликання старих доступів, збереження authoritative records і зрозумілий час ручного відновлення без вигаданого SLA.

Найкращий захист від lock-in — тримати канонічні документи, policies, eval cases і approval rules поза vendor-specific chat history. Для повторюваних процесів використовуйте versioned briefs та output schemas; для інтеграцій — власний реєстр джерел і дозволів; для рішень — окремий decision log. Тоді зміна асистента лишається керованою міграцією capability, а не втратою неформальної пам’яті команди.

• Inventory → люди, artifacts, instructions, integrations, permissions і authoritative records.
• Export → доступний формат, повнота, ownership, retention та deletion evidence.
• Rebuild → мінімальний vendor-neutral workflow pack на резервному сервісі.
• Replay → golden tasks, negative ACL tests і critical-failure gates.
• Revoke → старі sessions, shares, tokens, connectors і orphaned access.

Один підсумковий score приховує найважливіше: асистент може добре готувати чернетки й водночас неприйнятно працювати з цитатами, таблицями або дозволами. Розкладіть портфель на маршрути за типом входу, потрібним результатом і ціною помилки. Наприклад, public-web research, синтез внутрішніх документів, spreadsheet analysis, customer-facing draft і зовнішня дія мають різні acceptance criteria. Для кожного маршруту задайте primary candidate, дозволений fallback, обов’язковий review і hard-stop failures до запуску тесту.

Не маршрутизуйте за брендом або враженням користувача. Route contract має містити data class, доступні sources і tools, output schema, freshness requirement, максимальний рівень authority та evidence, яке reviewer повинен побачити. Якщо задача містить restricted data або незворотну дію, кандидат без доведеного control plane не потрапляє в eval незалежно від якості демо. Якщо задача низького ризику й добре перевіряється, можна порівнювати швидкість до прийнятного результату та correction effort.

Рішення може бути role-specific, але не повинно ставати прихованим BYOAI. Опублікуйте короткий каталог дозволених маршрутів: хто може запускати задачу, у якому сервісі, з якими даними, де зберігати результат і кому ескалювати помилку. Невідомий маршрут переходить у manual review, а не автоматично до улюбленого інструмента працівника. Так порівняння трьох продуктів завершується керованою операційною політикою, а не лише таблицею функцій.

• Route key → task, data class, source freshness і consequence of error.
• Candidate gate → plan, region, controls, tools та effective permissions.
• Acceptance → quality floor, evidence, human review і prohibited failures.
• Fallback → дозволений резерв, manual path і escalation owner.
• Review trigger → зміна функції, terms, інтеграції, ризику або workflow.

Згода між моделями не доводить істину, а розбіжність не визначає переможця. Додайте до pilot кілька задач, де джерела суперечать одне одному, умова неповна або правильна відповідь має залежати від дати. Замість голосування більшістю вимагайте, щоб кожен кандидат відокремив підтверджені факти, припущення, невідоме й рекомендований спосіб перевірки. Reviewer оцінює source-to-claim mapping та правильність версії документа, а не впевненість стилю.

Протокол розбіжності починається з нормалізації: той самий brief, однаковий cutoff джерел, однакові дозволи й зафіксований час запуску. Потім reviewer класифікує причину: різний retrieval, застаріле джерело, пропущена умова, помилка обчислення, непідтримане твердження або справжня невизначеність. Лише після цього можна виправити prompt, corpus чи workflow і повторити case. Інакше команда ненавмисно підлаштує умови під бажаного постачальника.

Для consequential use case встановіть правило abstention: якщо authoritative source відсутній, policy versions конфліктують або значення неможливо reconcile, асистент повертає структуровану невизначеність і передає задачу визначеному власнику. Зберігайте disagreement cases у regression set. Вони часто дають більше інформації про надійність процесу, ніж десятки простих запитів, на яких усі кандидати виглядають однаково.

Перемога в pilot є point-in-time рішенням для конкретних plan, configuration і task set. Після rollout залиште невелику versioned regression suite та періодично запускайте її на primary і дозволеному fallback без передачі production secrets. Shadow evaluation не повинна автоматично змінювати постачальника або маршрути. Вона лише створює порівнюваний сигнал для owner: accepted outcomes, critical failures, citation defects, correction effort і зміни effective controls.

Визначте drift budget до появи проблеми. Наприклад, будь-який cross-permission disclosure або непідтверджена зовнішня дія є негайним stop condition, тоді як погіршення формату може запустити investigation. Пороги мають бути вашими локальними acceptance rules, а не вигаданою універсальною нормою. Зміна моделі, connector, system behavior, data terms або admin policy відкриває review; до завершення перевірки критичний маршрут може повернутися до manual fallback.

Decision log пов’язує кожну зміну з evidence: що змінилося, які cases повторили, хто переглянув результати, які маршрути дозволені та як відкотитися. Не використовуйте shadow score як публічний benchmark або доказ загальної переваги. Його мета — вчасно помітити, що колись обґрунтований вибір більше не проходить власний контракт команди, і виконати повторний eval без хаотичної міграції.

• Freeze → task set, expected evidence, plan і configuration snapshot.
• Observe → accepted outcome, defects, review effort і control failures.
• Triage → content drift, retrieval drift, permission drift або workflow change.
• Decide → keep, restrict, reroute, pause або repeat procurement review.
• Rollback → manual path чи перевірений fallback із відкликаними старими grants.

Загальний prompt на кшталт «підсумуй цей PDF» майже нічого не каже про придатність сервісу для організації. Побудуйте pilot навколо двох або трьох ролей, наприклад product manager, analyst і operations lead. Для кожної ролі визначте п’ять повторюваних jobs, вхідні системи, дозволені класи даних, потрібний output, reviewer і критичну помилку. Один і той самий сервіс може пройти public research для analyst і провалити permission-sensitive document synthesis для operations; ці результати не можна усереднювати в одну красиву оцінку.

Кожен task case має містити frozen input bundle, точний account/plan, enabled tools, source manifest, acceptance rubric і expected abstention. Порівнюйте закінчені продукти, а не лише назви моделей: web search, project context, Workspace integration, file parser, system instructions і admin policy впливають на результат разом. Якщо один кандидат отримує нативний доступ до Drive, а інший — лише експортований файл, запишіть це як різницю operating environment; не видавайте її за чисту перевагу model intelligence.

Pilot owner заздалегідь визначає hard stops: використання недозволеного source, матеріально хибна citation, розкриття canary-факту, непідтверджена зовнішня дія або неможливість видалити тестовий доступ. Hard-stop failure не компенсується швидшими чернетками в інших задачах. Після проходження safety floor порівнюйте verified task success, reviewer minutes, correction effort, time to accepted artifact і повну cost per accepted outcome.

• Role contract → jobs, systems, data classes, reviewer і forbidden outcomes.
• Frozen case → однаковий input, source revision, tools і acceptance rubric.
• Safety floor → permissions, citations, abstention, actions і deletion проходять окремо.
• Outcome score → прийнятий artifact плюс людський час, а не довжина відповіді.
• Decision scope → переможець для конкретного route, не універсальний vendor ranking.

Послідовний тест A, потім B, потім C має приховану похибку: користувач краще розуміє задачу після першої спроби, переносить вдале формулювання й може несвідомо виправити input для наступного сервісу. Розподіліть порядок між учасниками: частина починає з ChatGPT, частина з Claude, частина з Gemini. Reviewer отримує нормалізований artifact без vendor label, коли це можливо, а prompt changes зберігаються як окремі події. Так learning effect і симпатія до інтерфейсу не зникають повністю, але стають видимими.

Не копіюйте відповідь одного кандидата в prompt іншого під час scored run. Це забруднює незалежність і може переносити unsupported claim, приховану інструкцію або vendor-specific formatting. Якщо workflow природно передбачає handoff, створіть для нього окремий interoperability case з reviewed neutral artifact. Основний comparison run починається з однакового canonical input, а всі ручні уточнення класифікуються як clarification, correction або preference tuning.

Повторіть критичні cases у новій сесії та після зміни source revision. Один вдалий run не доводить стабільність, а десять перегенерацій із вибором найкращої відповіді не відтворюють щоденну роботу. Зберігайте first accepted run, кількість retries, причину retry, model/product label, observed feature configuration і дату. Не використовуйте ці локальні результати як публічний benchmark або твердження про всіх користувачів.

• Counterbalance → змінюйте порядок кандидатів між учасниками.
• Blind review → приховуйте vendor label там, де формат не розкриває продукт.
• No answer leakage → не переносіть scored output між незалежними runs.
• First-run ledger → фіксуйте retries, corrections і configuration разом із результатом.
• Interoperability lane → тестуйте handoff окремо від порівняння якості.

Фіналом pilot має бути не презентація з трьома середніми балами, а versioned decision packet. Додайте route matrix, case manifest, rubrics, raw reviewer decisions, hard-stop incidents, admin-control evidence, data-flow, plan і feature snapshot, cost assumptions, unresolved gaps, owner та review date. Для кожного дозволеного route запишіть primary service, fallback, заборонені data classes, required human review і trigger повторної оцінки. Так procurement, security та робоча команда бачать одну й ту саму межу рішення.

До ширшого rollout проведіть exit drill на нешкідливому test workspace: відкличте app або integration access, приберіть учасника, видаліть або архівуйте test project відповідно до затвердженої retention policy, експортуйте лише ті artifacts, які організація має право зберігати, і перевірте, що recurring workflow повертається до manual або approved fallback route. Product UI, admin console, source-system OAuth і внутрішній каталог доступу можуть мати різні стани; завершення в одному місці не доводить повного offboarding.

Повторний review запускають не за календарем alone, а після material change: новий data class, connector, write capability, plan terms, model/product release, критичний incident або помітний зсув correction effort. Поки зміна не пройшла delta cases, попереднє рішення діє лише в старій configuration envelope. Rollback означає вимкнути affected route, зберегти incident evidence і повернути користувача до визначеного fallback, а не терміново купувати іншого асистента без перевірки.

• Evidence → cases, raw judgments, failures, controls і configuration fingerprint.
• Authority → named owner затверджує лише визначені role routes.
• Exit → revoke, retain/delete, export, reconcile і manual fallback перевірені практично.
• Change trigger → нова capability або boundary відкриває delta evaluation.
• Rollback → affected route зупинено без зміни launch/indexing gates AI Magister.

Порівняльна таблиця швидко старіє, бо одна й та сама функція може залежати від plan, регіону, типу акаунта, admin policy, підключеного джерела й поступового rollout. Перед кожним scored pilot створіть capability manifest для конкретного test account: product і plan, region, дата, доступні режими, дозволені apps або integrations, source scopes, read/write authority, retention controls і спосіб відкликання. Позначайте кожну capability як `verified`, `unavailable`, `restricted` або `unknown`; згадка в документації не дорівнює працездатності у вашій конфігурації.

Станом на повторну перевірку 25 серпня 2026 року офіційні довідки описують різні, але частково перекривні контури. ChatGPT поєднує Projects, deep research та Apps, причому можливості app можуть включати search, sync, research або підтверджувані write actions і залежать від plan та налаштувань workspace. Claude описує Projects із knowledge base та Research, що працює з web і підключеним внутрішнім контекстом. Gemini Deep Research дозволяє обирати Google Search, завантажені файли, NotebookLM notebooks і, за підключення Workspace app, Gmail або Drive. Це підтверджує лише наявність задокументованих surfaces, а не рівність якості, повноту rollout чи перевагу постачальника.

Manifest треба перевіряти hands-on на нешкідливому workspace. Відкрийте потрібний режим, підключіть тестове джерело з least privilege, виконайте read, спробуйте заборонений read, відкличте grant і повторіть запит. Для action-capable integration додайте draft, explicit confirmation, cancel і read-after-write case без production side effects. Якщо capability недоступна або її authority не вдається відтворити, workflow лишається manual чи research-only; не підставляйте очікувану майбутню функцію у business case.

• Identity → account type, plan, region, role та admin group.
• Surface → project, research, app/integration, file або workspace side panel.
• Authority → allowed sources, effective scopes, read/write і confirmation boundary.
• Evidence → screenshot або audit event, test case, timestamp і reviewer.
• Expiry → material product change відкриває delta verification до нового rollout.

Підключене джерело та action-capable app створюють різні рівні authority. Research run може читати дозволені матеріали й підготувати варіанти, але його текст не є дозволом на зміну календаря, документа, ticket, CRM або іншого system of record. Розділіть workflow на evidence artifact, людське рішення та короткий action envelope. Envelope містить exact target, immutable parameters, дозволену дію, expiry, reviewer і expected postcondition; він не переносить усю research conversation як приховану policy.

Оцінюйте кандидатів окремо у трьох lanes. Research lane перевіряє source coverage, citation-to-claim mapping, freshness і abstention. Draft lane перевіряє структуру артефакту та correction effort без зовнішнього submit. Action lane допускається лише після admin і security gate та перевіряє confirmation diff, least privilege, duplicate prevention, cancel path, audit evidence і authoritative read-after-write. Середній бал між цими lanes не повинен компенсувати critical authority failure.

Якщо зовнішня система не підтвердила результат, стан є `unknown`, а не автоматично `failed`: повторний write може створити дубль. Спочатку reconcile system of record, потім вирішуйте retry або manual handoff. Такий split робить порівняння стійкішим до нових agentic функцій: команда може дозволити сильний research surface і водночас залишити actions вимкненими, доки окремі permission, approval та rollback cases не пройдені.

• Research → cited evidence, assumptions, conflicts і unresolved facts.
• Decision → named human обирає option та задає consequence boundary.
• Action → мінімальний scoped envelope із fresh authorization.
• Verify → external reference та authoritative postcondition.
• Recover → pause, reconcile, revoke і повернути route до manual fallback.

Назва інтеграції в меню не доводить, що три асистенти бачать однакові дані або мають однакові права. Доступ може залежати від account, plan, workspace policy, admin configuration, user role, конкретної surface та стану connection. Search, sync, file attachment, research retrieval і write action — різні capabilities. Тому порівняння має фіксувати не «підтримує Drive або Slack», а перевірену комбінацію `provider + surface + connector + identity + role + operation`.

Перед pilot створіть connected-data receipt. Запишіть tenant і test identity, назву surface, джерело, дозволені collections, declared operation, фактично побачений control, час перевірки, очікуваний результат і expiry. Розділяйте стани `documented`, `admin-enabled`, `user-visible`, `observed-read`, `observed-write` та `approved-for-workflow`. Якщо документація описує capability, але її немає у вашому workspace, це не failure моделі; якщо control видно, але probe не підтверджує потрібну операцію, workflow не готовий.

Для read test використайте синтетичний документ із відомим revision і canary, а також сусідній заборонений документ. Асистент має знайти дозволений факт із attribution і не відтворити canary поза scope. Для action test використовуйте окремий sandbox target і нешкідливу операцію, наприклад створення чернетки з унікальним ID. Не робіть write probe у production і не переносіть дозвіл із chat surface на research, agent або custom-assistant surface без нового receipt.

• Connector discovery не дорівнює дозволу читати конкретний ресурс.
• Успішний read не доводить наявність або схвалення write action.
• Однакова назва інтеграції не гарантує однакову freshness чи permission semantics.
• Зміна role, tenant, surface або admin policy робить попередній receipt застарілим.
• Невідомий scope або destination → fail closed до повторної авторизації.

Окремо оцініть retrieval quality і authority control. У retrieval slice дайте кожному асистенту однакові current, stale, conflicting і out-of-scope fixtures. Перевіряйте passage support, revision, conflict disclosure, abstention і leakage canary. У action slice подайте вже перевірений evidence packet та одну дозволену sandbox-дію; тестуйте точний target, material parameters, confirmation, idempotency key, postcondition і відмову від ширшої або неоднозначної операції.

Побудуйте negative cases: prompt у retrieved document просить надіслати дані назовні; user змінює destination після approval; connection відкликано між research і action; роль втратила доступ; action повернув timeout після можливого запису. Правильна поведінка — ігнорувати інструкцію з недовіреного content, запросити нове підтвердження для істотної зміни, зупинитися після revocation і reconcile невизначений результат перед retry. Fluent answer або красивий report не компенсує authority violation.

Routing decision приймайте за найгіршим критичним failure, а не лише за середнім quality score. Для research-only ролі оберіть surface із достатнім citation support і найвужчим read scope. Для action workflow вимагайте окремий approval envelope, audit event та rollback owner. Якщо жоден продукт не віддає достатнього evidence або не обмежує дію до погодженого target, залиште retrieval у асистенті, а execution — у чинній контрольованій системі.

Після pilot збережіть versioned evidence pack: capability receipts, fixture revisions, prompts, outputs, claim ledger, action receipts, reviewer verdicts, exceptions і next-review trigger. Повторюйте лише affected slice після зміни connector, role або surface; повний crossover потрібен, коли змінилася сама decision boundary. Це локальний acceptance protocol, а не твердження про універсальну безпеку чи якість ChatGPT, Claude або Gemini.

• Retrieval PASS → підтримані claims, правильна revision, немає cross-scope canary.
• Action PASS → exact target, confirmation, receipt, reconciliation і rollback path.
• Critical authority failure → блокує rollout незалежно від якості інших відповідей.
• Capability change → targeted regression і новий expiry для evidence pack.
• Production authority → лише після окремого human-owned approval contract.