ChatGPT plugins vs apps vs custom GPTs: що обрати для workflow

Plugin у поточній моделі ChatGPT і Codex — це пакет можливостей для повторюваного workflow. Він може включати skills з інструкціями, apps для доступу до даних або дій та app templates для налаштування інтеграції. App є власне підключенням до зовнішньої системи: воно може шукати, синхронізувати content, показувати interactive UI або виконувати дозволені actions. Custom GPT — налаштована версія ChatGPT із власними instructions, knowledge і capabilities для певної аудиторії.

Тому вибір не завжди взаємовиключний. Plugin може залежати від app, а custom GPT може використовувати app. Проте custom GPT із зовнішнім доступом має обрати apps або custom Actions, а не обидва механізми одночасно. Починайте не з назви surface, а з outcome: чи потрібна команді стандартизована процедура, reusable assistant persona, зовнішні дані, interactive UI або write action. Потім відокремте packaging, conversational behavior та authority.

• Повторюваний workflow для ролі або команди → plugin як пакет guidance і dependencies.
• Доступ до зовнішніх даних, UI або actions → app із власним connection та permissions.
• Налаштована поведінка, knowledge і starters → custom GPT.
• Власний OpenAPI endpoint у GPT → Action; MCP integration або richer UI → app.

OpenAI описує plugin як контейнер для workflow capabilities. Skills дають повторювані instructions і patterns, apps з'єднують продукт із системами та діями, а app template допомагає адміністратору створити потрібну workspace-specific integration. Це робить plugin зручним distribution unit: sales analyst отримує не випадковий набір tools, а узгоджений workflow із потрібними dependencies.

Інсталяція plugin не повинна мовчки розширювати доступ app. Підключення app усе одно потребує authentication, а workspace settings визначають, хто може використовувати app і які actions дозволені. Якщо plugin містить skill, що радить оновити CRM, ця інструкція не є дозволом на update. App policy, provider scope, target-level authorization і approval застосовуються під час фактичної дії.

Для governance ведіть manifest: plugin version, included skills, required apps, app-template revision, assigned roles, owner і expiry date. Оновлення plugin може змінити інструкцію або додати dependency, тому release diff має показувати не лише текст, а й нові data paths та actions. Rollback повертає попередню версію пакета й окремо відкликає app access, якщо саме інтеграція створила ризик.

App підключає ChatGPT до зовнішнього сервісу. Його capabilities можуть включати search, deep research, sync, interactive experience і write actions; конкретна доступність залежить від app, plan, region, workspace policy та rollout. Назва в directory не доводить, що всі capabilities доступні вашому account. Перед pilot зафіксуйте capability manifest у фактичному середовищі.

Розділяйте access і approval. OAuth або інше connection grant визначає, до чого app потенційно має доступ. Workspace RBAC і action control звужують доступні користувачам операції. Ask-permission setting визначає, коли ChatGPT просить підтвердження; воно не додає нових provider permissions. Навіть режим без повторного запиту не перетворює модель на власника бізнес-рішення — server має перевіряти tenant, object, state і policy на кожній consequential action.

Sync створює окремий freshness і deletion contract: indexed copy може мати інший lifecycle, ніж live search. Записуйте source revision, last sync, ACL behavior і propagation expectation. Для write action потрібні preview, exact target, effect summary, idempotency key, result receipt та reconciliation після timeout. Для read path тестуйте cross-tenant canary, revoked document, stale result і citation support.

• Connection grant → потенційний доступ app до provider.
• Workspace control → хто і які app actions може використовувати.
• Ask permission → коли потрібне user confirmation, а не новий scope.
• Runtime authorization → повторна перевірка target і state перед effect.

Custom GPT поєднує instructions, conversation starters, builder-supplied knowledge та вибрані capabilities. Це добрий surface для вузького assistant: policy explainer, onboarding guide або review companion. Knowledge є reference corpus, а не live system of record; instructions формують поведінку, але не гарантують дотримання policy. Versionуйте обидва й тестуйте зміни на frozen fixtures.

Для зовнішніх систем builder обирає apps або Actions. Apps використовують user-connected integrations і можуть давати richer platform experience. Action описує API через OpenAPI schema та налаштовує authentication для конкретного GPT. Поточна документація прямо встановлює обмеження: один GPT не використовує apps і Actions одночасно. Це architecture fork, тому міграційний план має врахувати auth model, schema, UI, workspace allowlists, sharing і rollback.

Custom GPT не замінює plugin distribution semantics. Якщо кілька ролей мають отримати спільні skills і apps, plugin краще виражає workflow package. Якщо потрібні стабільна persona, domain instructions і knowledge для розмови, GPT є природним entry point. Комбінація можлива там, де workspace дозволяє GPT використовувати approved app; permissions app при цьому лишаються окремим contract.

Для read-only довідника без зовнішньої системи почніть із custom GPT knowledge. Для live пошуку в Drive, CRM або ticketing потрібен app, навіть якщо entry point — custom GPT. Для повторюваного процесу, що має однаково працювати в ChatGPT і Codex для групи ролей, оцініть plugin із skill та approved app. Для вузького API, який уже має стабільний OpenAPI contract і потрібен лише одному GPT, Action може бути простішим за повний MCP app.

Не додавайте всі surfaces про запас. Кожен шар створює owner, permissions, version, audit і failure modes. Один app може обслуговувати кілька workflows; один plugin може упакувати кілька skills навколо нього; окремий GPT може бути потрібний лише тоді, коли conversational behavior або knowledge справді відрізняються. Дублювання однієї policy у skill, GPT instructions і knowledge породжує невизначеність версії.

Заповніть decision record: user outcome, audience, entry surface, required data, read/write effects, authentication owner, app or Action choice, required confirmations, source freshness, evidence receipt, portability й exit path. Якщо команда не може назвати system of record або owner для action, workflow ще не готовий до write capability.

• Static tailored assistant → GPT instructions і versioned knowledge.
• Live data або interactive component → app.
• Role-based repeatable procedure → plugin із мінімальними dependencies.
• Single-GPT OpenAPI integration → Action після security review.

Створіть synthetic workflow із дозволеним документом, revoked документом, двома tenant canaries, reversible draft action і забороненим final action. Plugin test перевіряє, що правильна skill version і dependencies доступні призначеній ролі. GPT test перевіряє instruction adherence, knowledge citation, конфлікт джерел і відсутність вигаданого capability. App test перевіряє identity, scope, freshness, UI payload, approval та postcondition.

Збережіть execution receipt без прихованого reasoning: workspace, user role, plugin і skill versions, GPT version, app identifier, connection account, capability manifest, input source revisions, proposed effect, approval decision, tool result і final state. Такий запис локалізує failure. Правильна відповідь із неправильного tenant є security failure; відмова від небезпечної дії не компенсує stale retrieval; успішний API response не доводить, що user бачив точний target.

Regression suite має охопити plugin upgrade, app action addition, OAuth revocation, RBAC change, GPT republish, knowledge replacement, schema incompatibility, prompt injection із synced content і ambiguous timeout. Availability та labels змінюються, тому capability snapshot є частиною evidence, а не вічною продуктовою обіцянкою.

Почніть із одного workflow та read-only data path. Призначте plugin невеликій ролі або поширте GPT контрольованій групі, підключіть окремий test account і вимкніть непотрібні actions. Після retrieval і isolation tests додайте reversible draft action із always-ask approval. Лише після review receipts розширюйте ролі або capabilities; не використовуйте fluent demo як production acceptance.

Rollback виконується по шарах. Зніміть assignment або поверніть plugin version, unpublish чи відкотіть GPT configuration, disable app, revoke OAuth grant і, за потреби, відкличте downstream credential. Для sync перевірте documented de-indexing lifecycle; для write action reconcile already-created objects. Видалення plugin не гарантує відключення underlying app, а unpublish GPT не скасовує зовнішній effect, який уже відбувся.

Після rollback повторіть negative access і action tests та збережіть incident evidence. Відновлення потребує owner approval, виправленої version, regression verdict і нового capability manifest. Це зберігає зручність композиції, не перетворюючи plugin, app або GPT на неявний master permission.

• Hard gate → cross-tenant access, hidden write або bypass confirmation policy.
• Freshness gate → source revision і sync state відтворюються.
• Change gate → новий skill, action або schema проходить regression.
• Recovery gate → зовнішні effects reconciled, credentials revoked, evidence retained.

Не починайте rollout зі скриншота Plugin Directory. Поточна документація OpenAI розділяє видимість каталогу, installation policy plugin, доступ до кожного underlying app, provider authentication, підтримувану product surface та право створювати або публікувати GPT. Каталог може бути видимим, але конкретний plugin — недоступним через plan, region, workspace, role чи app dependency. Так само статус Installed для ролі не надає OAuth grant і не розширює permissions у Google Drive, Slack, CRM або іншій системі.

Для custom GPT окремо перевіряйте use, edit, create і publish. Станом на editorial review OpenAI документує, що нове створення та публікація GPT недоступні personal ChatGPT accounts, включно з Free, Go, Plus і Pro; existing GPTs можуть залишатися доступними, а edit залежить від чинного plan і permissions. У Business, Enterprise та Edu право визначають workspace settings і roles. Не переносіть стару інструкцію з builder UI на новий account і не купуйте plan лише за неактуальним tutorial — спочатку підтвердьте entitlement у цільовому середовищі.

Збережіть eligibility receipt: product surface, account/workspace class, plan, region, role, plugin directory visibility, installation state, required apps, app enablement, connection owner, GPT use/edit/create/publish states, checkedAt і official-source revision. PASS означає, що intended user у fresh session може відкрити потрібний entry point, пройти лише дозволену authentication і виконати read-only fixture. Якщо UI label чи документація суперечаться фактичному account, зафіксуйте стан як unknown і не вмикайте write actions.

• Visible → каталог або GPT page показані, але capability ще не доведена.
• Installed → workflow package призначений; app permission не виникає автоматично.
• Connected → конкретний provider account авторизований у межах виданих scopes.
• Eligible → plan, workspace, role, region і surface допускають потрібну операцію.
• Verified → frozen fixture пройшла у fresh session із правильним tenant і receipt.

Після переходу каталогу apps до Plugin Directory plugin став discovery і packaging surface, але existing app connections зберігають власні controls. Це taxonomy migration, а не доказ нового data path. Для кожного workflow складіть ledger `old label → current plugin → included skill/app/template → connection → scopes → actions → owner`. Якщо app використовується кількома plugins або ChatGPT experiences, її disable може вплинути на всі ці маршрути; якщо disable plugin не uninstall-ить package, сам запис у списку Installed не доводить доступність app-backed capability.

Проведіть negative disable drill у test role. Спочатку зафіксуйте plugin і app inventory, потім вимкніть plugin та перевірте skill-only і app-backed paths; окремо вимкніть underlying app і повторіть read та reversible draft action у fresh session. Далі revoke provider grant і перевірте, що старий chat, cached result або visible plugin card не дозволяє новий retrieval чи write. Очікуваний результат описуйте по кожному шару, бо одна кнопка не гарантує package uninstall, de-indexing synced content, provider-side token revoke або видалення вже створеного object.

Migration із GPT Action до app також є authority change. Export OpenAPI schema, auth model, domains, scopes, user mapping, confirmation policy, rate limits, idempotency і error semantics; потім побудуйте app/MCP equivalent у read-only mode. Оскільки GPT не може використовувати apps і Actions одночасно, cutover має явні стани `Action active`, `freeze`, `app shadow`, `app active` і `Action revoked`. Rollback повертає лише останній перевірений path після повторної authorization — він не зберігає обидва write mechanisms активними про запас.

• Inventory → package, apps, skills, templates, GPTs і downstream credentials.
• Freeze → заборонити нові writes та зміни configuration під час cutover.
• Shadow → порівняти read results, identity, scopes і error behavior без effects.
• Promote → один write path, versioned policy, approval та postcondition receipt.
• Retire → revoke старий grant, reconcile effects і повторити negative access test.