Як Univé масштабує ChatGPT Enterprise: 97% активації, 1 500 GPTs і claims preparation із людською відповідальністю

Більшість enterprise AI programs легко потрапляють у чергу: кожен department приносить use case, центральна data/IT команда оцінює, будує, інтегрує, підтримує — і через пів року має сто pilotів та один bottleneck. Univé пішла іншим шляхом: leadership, governance і employee-led building. За OpenAI, ChatGPT Enterprise поширений майже по всіх knowledge functions, а працівники створили приблизно 1,500 custom GPTs для локальних задач.

Це не аргумент за uncontrolled citizen development. Навпаки: масштаб стає можливим лише тому, що enterprise authentication, inherited connector permissions, privacy assessments, security reviews, responsible-AI principles, monitoring і human accountability є спільною рамкою. Простий доступ до builder без таких меж швидко створює 1,500 різних способів витекти даними — досить погана версія «демократизації».

У pet-insurance workflow Workspace Agent може зібрати claim file, переглянути veterinary invoices, policy conditions, missing information та anomalies і сформувати traceable recommendation до того, як claims handler почне assessment. OpenAI/Univé повідомляють, що preparation, яка раніше займала години, може бути готова за хвилини. Ключова межа в самому кейсі сформульована чітко: trained claims professional залишається повністю accountable за final decision.

Цей pattern сильніший за повністю автономний claims bot, бо розділяє evidence assembly і consequential adjudication. AI прибирає retrieval/reading/structuring overhead; людина застосовує policy interpretation, professional judgement і відповідальність. Для high-volume low-risk cases частину детермінованих checks можна автоматизувати, але denial, payout, fraud accusation або material exception мають окрему authority policy.

Trigger — новий claim або зміна case state, що вимагає preparation. Input: authenticated employee/case identity, authoritative claim metadata, policy version, veterinary invoices/attachments, approved knowledge і relevant system records. AI stage: document reading, field extraction, policy matching, missing-data detection, anomaly surfacing і evidence-backed recommendation. Output — prepared case packet із provenance, а не самостійне approve/deny.

Для underwriting trigger може бути ранковий work queue. Agent готує approved-source context, missing documents і risk indicators до входу underwriter. Integrations — claims/policy systems, enterprise document stores, identity/permissions, approved connectors і reviewer UI. Connector permission inheritance знижує ризик over-access, але application/business rules все одно мають перевіряти конкретну дію й case authority.

• Trigger → new claim, case update або scheduled queue preparation.
• Input → case identity + policy version + documents + approved enterprise sources.
• AI → extract, retrieve, compare, flag gaps/anomalies, draft recommendation.
• Integrations → systems of record, document repositories, enterprise identity/connectors.
• Output → traceable prepared case; final adjudication лишається за qualified professional.

При 97% license activation, 85% weekly activity і близько 1,500 custom GPTs проблема вже не «як змусити людей спробувати AI». Проблема — lifecycle. Хто owner кожного GPT? Який data scope? Яка модель/prompt version? Чи є duplicate? Чи має він write tools? Коли востаннє eval проходив? Хто вимкне його після policy change? Без inventory adoption успішно перетворюється на невидимий software portfolio.

Мінімальний registry: `id → owner → purpose → audience → data classes → connectors/tools → authority tier → model/config → eval suite → last review → status`. Low-risk personal helpers можуть мати lightweight review; shared GPT для claims/legal потребує stronger gates. Usage не дорівнює quality: 40 prompts per active user/week показують engagement, але не доводять correctness або ROI.

Failure modes для claims: wrong policy version, OCR/extraction error, missing invoice page, duplicated attachment, stale claim state, ambiguous exclusion, hallucinated clause, prompt injection у uploaded document, permission mismatch, timeout після system write. Safe behavior — показати evidence gap і abstain/escalate, а не компенсувати невизначеність ще впевненішим текстом.

Univé Rechtshulp на власній quality page прямо попереджає, що ChatGPT-like systems можуть давати неправильні або неповні поради; у 2025 підрозділ запустив pilot автоматичного summary incoming calls поряд із традиційними dossier reviews, audits і quality controls. Це корисний контрбаланс до adoption story: generative capability не скасовує professional quality system. Для customer-impacting outcome trace має зберігати source IDs, model/config, reviewer, decision і reason.

OpenAI case наголошує, що permissions follow underlying enterprise systems. Це правильний baseline: AI не повинен бачити SharePoint/record, до якого employee не має доступу. Але authorization для action має бути точнішим за retrieval permission. Можливість читати claim не означає право approve payout; доступ до policy не означає право змінити її; доступ до customer data не означає право передати їх external tool.

Production control plane: SSO/role context, retrieval ACL, data-classification rules, connector allowlist, strict schemas, per-action policy, exact approval для high-impact writes, idempotency, postcondition reconciliation, audit log, model/prompt versioning і kill switch. Sensitive documents не мають ставати persistent memory без explicit retention purpose. Deletion/revocation повинні поширюватися на derived indexes/cache, де це технічно застосовно.

Enterprise assistant traffic щоденний і широкий; claims/underwriting — case-driven та potentially high-volume. Масштабування потребує tiering: generic knowledge work, shared function GPT, domain workflow, consequential agent. Чим вище tier, тим більше eval/approval/observability cost. Єдиний однаковий governance process для нотаток і payout decision або душить innovation, або робить high-risk flow небезпечно легким.

Cost model: Enterprise seats/usage + model/tool execution + connectors/retrieval + document parsing + storage + evals/monitoring + GPT portfolio maintenance + reviewer time + incident/compliance reserve. Вимірюйте `cost per accepted prepared claim`, handler minutes saved, correction rate, evidence-gap rate, decision reversal, unsafe-action attempts і claimant-impact incidents. Adoption metrics корисні для enablement, але фінансовий business case потребує workflow-level unit economics.

Claims eval set: clean claims, missing docs, conflicting dates, policy exclusions, old/new policy versions, unusual veterinary invoice, duplicate claim, multilingual text, scan/OCR noise, injection text і intentional no-answer. Deterministic checks — case/policy IDs, required fields, arithmetic, permissions і side-effect postconditions; domain graders — material omission, policy-support correctness, recommendation quality й escalation appropriateness.

Rollout: `employee Q&A → personal GPTs → shared read-only GPTs → claim draft/preparation → mandatory human review → bounded reversible writes → carefully scoped proactive agents`. Promotion gate — critical-slice quality, zero unauthorized access/action, reviewer correction within threshold, trace completeness і rollback drill. Model/connector/policy update запускає regression replay. Incident із production case мінімізується й лишається permanent test.

Pattern підходить insurers, banks, utilities, large professional-services і public-service organizations із великою knowledge workforce та чіткими systems of record. Не копіюйте KPI «1,500 GPTs» як ціль: кількість builders корисна лише якщо portfolio не множить duplicates, unsupported advice і hidden data flows. Краще 100 керованих workflows із вимірюваним outcome, ніж 5,000 цифрових кактусів, які ніхто не поливає.

Pilot: дайте broad workforce safe enterprise chat + training, паралельно виберіть один claims-like preparation flow з clear human decision. Зберіть 200–500 historical cases, створіть evidence-first assistant, виміряйте preparation time/correction, введіть registry для shared GPTs і risk-based review. Лише після стабільності переходьте до proactive queue preparation та bounded writes.