Your AI Partnership Needs a Responsibility Map, Not Just a Statement of Work
A strong technology partnership can improve delivery. It does not automatically settle accountability.
On October 12, 2026, HCLTech announced a Global Premier Partnership with Anthropic. HCLTech said it will create a dedicated Anthropic Business Unit and Center of Excellence, build agentic AI solutions with Claude products, provide secure sandbox environments, and embed Claude into selected software and internal platforms. Reuters independently reported the partnership, dedicated unit, and planned use of Claude, Cowork, and Claude Code.
For an operating business, the useful lesson is not simply that another large AI alliance exists. It is that a model provider, an integrator, and the customer may all shape one production workflow. Unless responsibility is assigned before access is granted, important controls can sit in the gaps between them.
What changed—and what remains unproven
Documented facts: HCLTech announced the partnership, dedicated business unit, Center of Excellence, secure sandbox environments, selected product integrations, and AI Force workflows. Its release says those workflows will use policy guardrails, exception handling, and human oversight for high-impact changes. Reuters corroborated the core partnership and organizational plans.
Company claims: HCLTech and Anthropic describe the arrangement as a way to scale agentic AI safely and deliver business outcomes. Those are forward-looking statements from the participants, not independent evidence that every future deployment will achieve those results.
Unresolved questions: The public announcement does not disclose commercial terms or define customer-specific responsibility for identity and access, acceptance testing, model and configuration changes, incident notification, liability, data retention, rollback, or exit. Those details will vary by engagement. They are precisely what an operating company must make explicit.
Why the three-party operating model matters
Traditional software projects already divide work among a vendor, an implementation partner, and the customer. Agentic systems raise the stakes because the deployed workflow may interpret unstructured information, call tools, update records, create messages, or initiate transactions.
The model provider controls model behavior, service boundaries, and certain platform safeguards. The integrator designs connections, prompts, orchestration, and operating support. The customer owns the business rules, authoritative data, acceptable risk, and consequences of an action. “Shared responsibility” is accurate but incomplete unless each control has a named owner, evidence, and escalation path.
Bridge Road’s AI governance approach starts with the action: what may the workflow read, decide, draft, approve, or execute? Its systems practice adds the source-of-truth and recovery questions that integrations often leave implicit.
Build the responsibility map before the agent receives access
A useful responsibility map should name a primary owner, required evidence, and a backup owner for every production control. A practical starting point looks like this:
| Control area | Primary ownership question | Evidence to retain |
|---|---|---|
| Model and version | Who approves the model, version, settings, and permitted use? | Evaluation record, approval, version history |
| Data and source truth | Which system is authoritative, and who may expose which fields? | Data map, field allowlist, retention rule |
| Identity and permissions | Who approves credentials, scopes, environments, and expiry? | Access record, role, owner, review date |
| Workflow design | Who defines prompts, tools, routing, and prohibited actions? | Versioned configuration and change ticket |
| Deterministic validation | Which business rules must pass outside the model? | Test cases, rule results, failed-record queue |
| Human approval | Which actions require a person, and what evidence must they see? | Approval record, reviewer, timestamp, rationale |
| Monitoring | Who watches failures, drift, latency, cost, and unusual activity? | Dashboards, alerts, thresholds, review log |
| Incidents | Who declares an incident, notifies partners, and owns containment? | Severity matrix, contact tree, timestamps |
| Rollback and fallback | Who can disable the workflow, restore a prior version, or return to manual work? | Runbook, tested rollback, manual procedure |
| Vendor and model risk | Who reviews material provider, subprocessor, policy, or model changes? | Review packet, decision, conditions, renewal date |
| Exit and portability | Who preserves records, configurations, and continuity if a partner changes? | Export test, dependency list, transition plan |
The goal is not to force every task onto one party. It is to eliminate orphan controls and conflicting assumptions.
Put the controls where the workflow changes state
Use least privilege by role and environment. The development sandbox should not inherit production credentials. Separate read, draft, approve, and execute authority. Service identities need owners, expiry, and recertification just like human accounts.
Keep business acceptance with the operating company. The provider can test the model and the integrator can test the implementation, but the customer must decide whether the workflow is acceptable for its price rules, customer promises, inventory logic, quality controls, and compliance obligations.
Validate deterministically before consequential action. A model may interpret an emailed purchase order; code should still verify customer, SKU, quantity, pricing source, terms, duplicates, inventory, and required fields before an ERP write. Bridge Road’s operations practice applies that split to RFQ, PO, order, and status workflows.
Make exceptions owned work. “Human in the loop” is not enough. Name the queue, response target, backup owner, evidence package, and outcome codes. Otherwise, the control becomes an inbox no one consistently watches.
Join the audit trail. Provider telemetry, integrator orchestration logs, business-system records, approvals, and incident notes must be correlatable. A timestamped transaction ID that survives every handoff is often more useful than another dashboard.
Design incident response across organizational boundaries
A production incident should not begin with a debate about whose system failed. The operating agreement should define:
- which events require immediate notification;
- who can suspend credentials, tools, or the entire workflow;
- which logs each party must preserve and how quickly they must provide them;
- who communicates with employees, customers, suppliers, or regulators when necessary;
- how corrected records, duplicate transactions, or incorrect messages are identified and repaired; and
- when service resumes, under whose approval, and with what additional monitoring.
Rollback also needs more than a software version. It can mean disabling an agent, restoring the prior prompt and tool configuration, revoking a service identity, replaying validated records, or returning the process to a documented manual queue. The fallback must be tested while normal operations are calm.
Three examples from operating businesses
Industrial distribution: An integrator may connect an AI agent to email, a product catalog, CRM, and ERP. The model provider supports interpretation; the integrator builds orchestration; the distributor still owns approved pricing sources, margin floors, credit holds, exception reviewers, and release authority.
Manufacturing: An agent may summarize quality events or prepare maintenance actions. Engineering and operations must own authoritative specifications, change approval, work-order release, safety boundaries, and manual recovery. A vendor’s general safety claims do not replace plant-specific acceptance tests.
eCommerce: An AI workflow may draft product copy, answer service questions, or recommend promotions. Marketing and commerce leaders must own substantiation, pricing rules, inventory truth, refund authority, brand approval, and the handoff when confidence or policy checks fail.
Turn the partnership into an operating system
- Inventory every participant, platform, subprocessor, identity, and data store.
- Classify each workflow by the consequences of a wrong action.
- Assign one accountable owner for every control and exception path.
- Write deterministic acceptance tests before production access is issued.
- Document approval gates, monitoring thresholds, and incident notification times.
- Test rollback, credential revocation, and the manual fallback end to end.
- Review the map whenever the model, provider, integrator, system, or business rule changes.
Partnerships can accelerate adoption. A responsibility map makes that adoption operable. It turns “governed AI” from a promise in an announcement into a set of decisions people can verify, run, and improve.
