Custom GPT vs ChatGPT app: що створювати для свого сценарію

Починайте з custom GPT, якщо ваш account або managed workspace зараз дозволяє створення GPT і цінність переважно задають instructions, conversation starters, невеликий керований корпус knowledge та стандартні можливості ChatGPT. Станом на перевірку 25 серпня 2026 року OpenAI не дозволяє створювати або публікувати нові GPT у personal Free, Go, Plus і Pro accounts; у Business, Enterprise та Edu це залежить від workspace settings і permissions. Перевіряйте eligibility у своєму інтерфейсі перед проєктуванням. Для доступного account GPT є швидким способом оформити повторювану роль без окремого frontend. За потреби він може використовувати apps або визначений вами API через actions, але поточний контракт OpenAI не дозволяє одному GPT одночасно використовувати apps і actions.

Починайте з ChatGPT app, якщо потрібні власна інтерактивна UI, backend state, авторизація користувача, MCP tools, повторне використання сервісу поза одним налаштованим асистентом або публікація в app directory. Apps SDK розширює MCP логікою та інтерфейсом усередині розмови. Це більша інженерна й операційна поверхня: сервер, OAuth, privacy policy, tool contracts, monitoring і review стають частиною продукту.

• Eligible managed workspace, instructions, knowledge і готові prompts → спочатку custom GPT.
• Власний UI, backend workflow або MCP service → спочатку ChatGPT app.
• Один внутрішній API без UI → перевірте GPT action до побудови app.
• Нечіткий сценарій → проведіть manual concierge pilot і не автоматизуйте зарано.

Instructions визначають спосіб відповіді, knowledge дає довідковий корпус, tool виконує typed operation, а UI допомагає людині побачити й змінити структурований стан. Custom GPT добре упаковує перші два шари та може підключити tool через app або action. ChatGPT app стає виправданим, коли tool і UI є самостійною цінністю: наприклад, користувач фільтрує каталог на карті, редагує план або підтверджує набір точних параметрів.

Не переносіть authoritative business state у prompt, uploaded knowledge чи component state. Замовлення, ticket, entitlement і policy revision повинні залишатися у system of record. GPT або app отримує мінімальний контекст, показує provenance і повертає підтверджений результат. Так архітектуру можна замінити без втрати рішень, а модельна відповідь не стає неявною базою даних.

У builder зафіксуйте одну роботу, цільового користувача, формат результату, заборонені твердження, escalation і кілька реальних conversation starters. Knowledge-файли версіонуйте поза GPT, бо завантаження не доводить freshness або правильний retrieval. Preview має перевіряти не лише tone, а й конфліктні instructions, відсутній факт, застарілий документ, prompt injection у файлі та коректну відмову.

Actions доречні для вузького API contract, який можна описати OpenAPI schema та окремою authentication policy. Назва operation, параметри й response повинні бути однозначними для моделі та reviewer. Для публічного GPT з action потрібна чинна privacy policy; workspace allowlist може повністю заборонити action domain. Якщо схема розростається, потрібні rich controls або один backend має обслуговувати кілька клієнтів, це сигнал оцінити app/MCP boundary.

App описує tools через MCP і за потреби повертає interactive component у чаті. Tool result має лишатися семантично корисним без UI: модель і доступний fallback повинні розуміти сутність, статус і наступні дозволені дії. Component не має самостійно вигадувати authorization; backend повторно перевіряє identity, object scope, policy та idempotency для кожної операції.

Developer Mode підходить для тестування custom app, але не є production approval. Для managed workspace потрібні owner, review, дозволені користувачі, OAuth redirect і scopes, data-flow inventory, log retention та revoke procedure. Поточні можливості різняться за plan, region і admin configuration, а beta/preview semantics можуть змінюватися. Фіксуйте дату й перевірену конфігурацію замість загальної заяви «ChatGPT підтримує write».

• Tool schema описує мінімальну атомарну дію, а не довільну команду.
• UI показує object, source, pending change і confirmation state.
• Backend перевіряє authorization незалежно від model або component.
• Semantic fallback дозволяє завершити або відхилити задачу без widget.

Custom GPT можна залишити приватним, поширити посиланням, дозволити workspace або подати до GPT Store відповідно до plan і policy. ChatGPT app можна розгорнути як custom app у workspace або подати до app directory. Наявність публічної поверхні не гарантує discovery, ranking, revenue чи придатність для enterprise; ми не використовуємо такі припущення як business case.

Перед публікацією визначте legal owner, support channel, privacy disclosure, data deletion, abuse handling, incident contact і change review. Для внутрішнього сценарію перевірте, хто може створювати GPT, вмикати apps, публікувати custom app та змінювати доступ. Direct link або directory listing не повинні обходити entitlement у вашому backend.

Зберіть permission matrix: user identity, workspace role, connected account, OAuth scopes, tool, object scope, read/write effect і confirmation rule. Connection prompt повідомляє про передачу даних, але не замінює least privilege. Людина повинна бачити точний об’єкт, одержувача, суму або іншу наслідкову зміну безпосередньо перед виконанням.

У negative tests додайте revoked user, expired token, чужий object ID, changed price, duplicate request, malicious tool output і інструкцію з зовнішнього документа розширити scope. Expected result задайте наперед: deny, abstain, reconnect або human approval. Після timeout спочатку reconcile authoritative state, а потім retry з idempotency key; інакше коректна перша дія може повторитися.

Візьміть один recurring job, наприклад підготовку support escalation. Варіант GPT отримує versioned playbook, conversation starters і, якщо потрібно, read-only action. Варіант app використовує той самий backend contract та додає структуровану картку ticket. Обидва проходять однакові task cases, knowledge revisions, access failures і acceptance criteria; app не отримує бонус лише за складніший UI.

Вимірюйте verified task success, unsupported claims, completion time, correction effort, prohibited actions, accessibility, setup burden, support incidents і повну cost per accepted outcome. Окремо оцініть maintenance: оновити instruction, замінити knowledge, змінити schema, ротувати secret, revoke user і відкотити release. Обирайте GPT, якщо він проходить критичні cases без зайвої системи; обирайте app, коли UI або reusable integration дає перевірювану різницю.

Зберігайте поза продуктом source instructions, test set, knowledge manifest, OpenAPI або MCP schemas, tool policies, privacy text і decision log. Тоді GPT action можна перенести в MCP service, а app — замінити іншим client без реконструкції контракту з chat history. Не обіцяйте автоматичну сумісність: migration перевіряє auth, schema semantics, confirmations, UI fallback і authoritative state окремо.

Rollback для GPT вимикає sharing або action, повертає попередню версію configuration та відкликає credentials. Для app він додатково unpublishes або disables integration, блокує нові writes, завершує reconciliation незакритих operations і повертає користувачів до manual workflow. Growth цієї сторінки не змінює production/indexing gates AI Magister і не є доказом доступності конкретної функції у вашому account.

До порівняння функцій поставте eligibility gate. За документацією OpenAI, перевіреною 25 серпня 2026 року, personal Free, Go, Plus і Pro accounts не можуть створювати або публікувати нові GPT, хоча наявні GPT залишаються доступними, а можливість редагування залежить від subscription і permissions. Створення, редагування та публікація нових GPT продовжуються у Business, Enterprise й Edu, якщо це дозволяють workspace settings та роль. Тому відсутність кнопки builder — не аргумент на користь складнішого app: зафіксуйте account type, role, admin policy і показані eligibility controls, а потім окремо вирішуйте, чи custom GPT взагалі є доступним кандидатом.

Для managed workspace призначте service owner і backup owner, збережіть source instructions, knowledge manifest, action schema, auth mode, test set та live version ID поза editor. OpenAI документує draft-to-update publication і version history з можливістю restore, але після відновлення старої версії з actions authentication може потребувати повторної конфігурації. Отже rollback runbook має не завершуватися натисканням restore: він повторно перевіряє secret або OAuth configuration, domain allowlist, privacy-policy URL, negative authorization cases і лише потім повертає sharing. Для app аналогічний release manifest охоплює MCP server, component bundle, OAuth client, tool schemas і deployment revision.

• Eligibility evidence → account/workspace type, role, admin policy, checked-at і доступні builder controls.
• Promotion evidence → draft version, acceptance suite, reviewer, audience, action/app permissions і live version.
• Rollback evidence → restored revision, authentication recheck, denied negative probes, smoke test і reconciliation.
• Ownership evidence → named owner, backup, offboarding trigger, reassignment verdict і credential rotation.

Моделюйте щонайменше три GPT permissions окремо: `Can chat` дозволяє використання, `Can view settings` також відкриває configuration і дозволяє duplication, а `Can edit` дає право змінювати live product через draft/update flow. Не розкривайте instructions, knowledge design або action configuration ширшій аудиторії лише заради usage. Public link і GPT Store не підтримують view-settings permission, а конкретні sharing levels залежать від plan та workspace policy. Для app так само розділяйте directory discovery, app enablement, OAuth connection і backend object authorization: listing не видає entitlement, connection не дозволяє кожну дію, а tool call не обходить object-level check.

Offboarding перевіряйте до pilot. OpenAI документує, що під час звичайного видалення учасника з managed workspace його GPT переходить workspace owner і позначається unassigned для review або reassignment; це continuity mechanism, а не завершений контроль. Runbook має знайти orphaned ownership, призначити accountable owner, перевірити sharing, apps/actions, зовнішні credentials і privacy contact, після чого rotate або revoke owner-bound dependencies. Для ChatGPT app dependency map додатково охоплює cloud account, domain, OAuth client, signing secrets, MCP deployment, logs і support channel. Якщо будь-який обов'язковий ресурс не передається, stop-new-use і manual fallback мають спрацювати до видалення людини.

• Quarterly access review: owner, editors, chat users, public/workspace visibility та approved domains.
• Leaver event: inventory → stop changes → reassign → rotate → retest → approve або disable.
• Не вважайте automatic ownership reassignment доказом передачі зовнішнього OAuth account чи secret.
• Зберігайте audit packet без chat content, якщо для контролю достатньо revision, actor, verdict і hashes.