Як TCS масштабує Claude в regulated industries: claims, lending, Diligenta і engineering

TCS і Anthropic у червні 2026 року оголосили partnership, орієнтований на financial services, healthcare, public services та інші regulated industries. TCS планує дати Claude 50 000 власних працівників у 56 країнах і використати internal experience як customer-zero learning loop. Паралельно компанія створює dedicated practice та industry offerings, зокрема claims processing/adjudication для insurers і lending advisory для banks.

Цінність кейсу — у domain packaging. Модель сама по собі не знає, чи має конкретний claim право на автоматичне рішення, чи кредитна рекомендація потребує regulated disclosure, чи external document можна вважати authoritative. Production system має обгорнути Claude identity, policy, evidence, tool scopes, approvals і outcome verification. Інакше «регульований агент» — звичайний chatbot у дорогому костюмі.

Claims flow стартує з нового claim або зміни case state. Input: claimant identity, policy version, coverage rules, submitted evidence, fraud/risk signals і case history. Claude stage: classify documents, summarize facts, match evidence to policy, detect missing information і propose next action. Integrations: policy admin/claims system, document store, fraud/risk service, workflow queue. Output — evidence-backed recommendation, request for missing evidence або bounded tool request.

Lending-advisory flow стартує з customer/advisor request або application milestone. Input: customer context, approved product/risk rules, financial data та up-to-date disclosures. AI stage retrieves relevant rules, explains options and prepares recommendation evidence. Diligenta customer-service variant additionally needs identity verification, account permissions, conversation trace і safe escalation. Engineering teams using Claude Code operate in a separate code/tool authority plane.

• Trigger → claim, lending task, service request або engineering ticket.
• Input → verified identity + policy/product context + case evidence + allowed tools.
• AI → retrieve, classify, reason, propose; no implicit right to execute regulated decision.
• Integrations → claims/core banking/service platform, documents, risk tools, workflow, CI/dev tools.
• Output → citable recommendation, missing-evidence request, staged action або escalation.

Claims reproduction flow: `claim event → identity/case match → policy-version resolution → evidence eligibility → Claude analysis → deterministic coverage/rule checks → confidence/material-gap gate → adjuster review or bounded next action → authoritative claim-state verification`. Lending: `request → customer/role check → product eligibility → allowed retrieval → recommendation + disclosures → policy checks → advisor/credit authority → system-of-record outcome`.

Autonomy A3 доречна: агент може виконувати multi-step analysis і підготувати operational action, але claims settlement, credit decision, payment, binding advice або production change не повинні бути прямим наслідком prompt. High-risk action проходить deterministic eligibility та визначений authority owner. Review концентрується на material exceptions, а low-risk work можна автоматизувати сильніше.

TCS/Anthropic повідомляють про internal rollout Claude для 50 000 працівників у 56 країнах. Diligenta, яка планує використовувати Claude для customer experience, обслуговує понад 22 млн policyholders. TCS iON проводить понад 75 млн assessments щороку. Усі три цифри показують potential operating scale і серйозність integration surface, але жодна не є показником Claude accuracy, safety, automation rate або ROI.

Власний pilot повинен мати outcome metrics: claims evidence completeness, unsupported-claim rate, correct policy-version rate, adjuster correction rate, time-to-resolution, unsafe settlement attempts; для lending — eligibility accuracy, disclosure completeness, advice escalation rate, adverse-action traceability; для customer service — verified task completion і false account-match rate. Без цього 50k rollout лишається rollout, а не доказом value.

Критичні failures: неправильна policy version; stale lending rule; forged/poisoned document; prompt injection у claim attachment; mismatched customer identity; missing consent; tool timeout після partial write; duplicate action; contradictory sources; model upgrade regression. Система має вміти abstain, запросити evidence, quarantine untrusted source, escalate та reconcile state. Сліпий retry для payment/claim/update — особливо погана ідея.

Controls: tenant/identity check до retrieval; source provenance; policy-effective-date validation; role-based tool scopes; separate analysis/action stages; exact-action approval для consequential writes; immutable action ID; idempotency; audit log; retention/minimization; versioned model/prompt/policy fingerprint; canary і rollback. Для customer interactions потрібна AI disclosure і швидкий human exit там, де workflow це вимагає.

Claims і service requests — high-volume event-driven workloads; lending advisory — request-driven з піками; engineering — task/project-driven. Масштабування вимагає queueing, prioritization, document preprocessing, caching stable policy text із version keys, context compaction і model routing за task risk. Long documents та external search можуть домінувати в cost сильніше, ніж final response.

Total cost = inference + retrieval/document processing + integrations + secure execution + observability/evals + reviewer/adjuster/advisor time + incident reserve. Для claims KPI — `cost per verified resolved claim-step`; для lending — `cost per compliant reviewed recommendation`; для support — `cost per verified completed task`. Token cost без verification cost — бухгалтерія для красивих, але безкорисних дашбордів.

Eval suite включає standard і adversarial claims: covered/not-covered, ambiguous clauses, missing evidence, duplicate claims, stale policies, conflicting documents, injected text, identity mismatch, partial write; lending — borderline eligibility, stale rate, required disclosure, incomplete financial data, protected attributes, no-answer. Deterministic graders перевіряють IDs, rules, schemas, allowed tools і postconditions; domain reviewers оцінюють material judgment.

Для long workflows оцінюється trajectory: які джерела взяті, чи правильно обраний policy version, чи не пропущено mandatory step, чи action request відповідає approved scope. Release gate — не average helpfulness, а critical-slice thresholds: zero unauthorized high-impact actions, bounded false-negative rate, tested escalation і rollback.

Rollout: `read-only policy/evidence assistant → shadow recommendations → draft with human review → bounded reversible actions → narrow autonomous low-risk steps`. Кожна наступна стадія має власні acceptance criteria. Перед масштабуванням на новий country/product/claim type потрібен regression replay, бо rules і data boundaries можуть відрізнятися сильніше, ніж UI.

Для повторення виберіть один claim/advisory workflow із високим volume і чітким authoritative state. Зберіть historical cases, зафіксуйте policy versions і outcomes, зробіть retrieval+evidence layer, побудуйте deterministic pre/postconditions, запускайте shadow. Лише після виміряного correct-action rate додавайте tool writes. Так ви будуєте систему, а не презентацію про систему.