IBM’s planned OpenAI consulting practice could leave regulated customers with two connected accountability chains: IBM for implementation decisions and OpenAI for part of the model’s behavior. Banks considering the offering should decide before deployment who investigates, contains and reports a failed AI decision across that boundary.
The plan includes training for tens of thousands of IBM consultants and industry-specific offerings for financial services, government, telecommunications and retail. That scale matters. It could put OpenAI models inside systems shaped by IBM consultants, customer policies, internal data and sector-specific controls.
The announcement establishes the commercial direction. It does not, from the information available, establish how responsibility will be divided when a deployed system produces a harmful, discriminatory or otherwise non-compliant result.
One AI decision can have several causes
A failed AI decision rarely points to one component by inspection. The model may have generated an unreliable output. The implementation may have supplied incomplete context, allowed an unsuitable use case or routed the output into a consequential workflow without adequate review.
Configuration adds another layer. System instructions, retrieval sources, access permissions, thresholds and human approval rules can all affect the result. So can later changes to the model or the surrounding application.
That creates a difficult first question for a bank’s compliance team: which organization owns the incident before anyone knows its cause?
IBM may govern the consulting engagement and implementation. OpenAI may govern relevant aspects of model development and behavior. The bank still owns its regulatory duties and the decision to deploy the system. A contract can allocate commercial liability, but it cannot make the technical dependencies disappear.
This is the accountability split. Each party can accurately describe its area of control while the customer remains responsible for assembling the complete incident record.
Contracts need an operational chain of custody
A list of responsible parties offers limited protection if an incident team cannot move evidence between them. Banks need a chain of custody for prompts, retrieved records, model outputs, configuration versions, approval events and model identifiers.
That record should answer practical questions. Which model version produced the output? What information did the implementation provide? Which controls ran? Did a person review the result? What changed after the last validation? Who can preserve each piece of evidence?
The answers may sit across three environments: the bank’s systems, an IBM-led implementation and OpenAI-controlled model infrastructure. An incident process should specify how those records are joined, how quickly each party must respond and what happens when one party cannot disclose material the others request.
This deserves attention before procurement closes. The same applies when a model appears inside a renewal or another vendor package, as examined in Copilot Appeared on the Renewal. Product branding can make a dependency look like one service even when investigation requires several organizations.
Governance must follow control, dependency and duty
A useful responsibility map separates three concepts.
Control identifies who can change a component. IBM may control parts of the implementation, while OpenAI controls parts of the underlying model. The bank controls its policies, deployment choices, internal data and use of the resulting output.
Dependency identifies what each party needs from another to explain an incident. IBM may need model information from OpenAI. The bank may need implementation records from IBM. OpenAI may need the exact input and surrounding context preserved by the customer or implementer.
Duty identifies who must act regardless of technical cause. A regulated institution may have obligations to customers, supervisors or internal risk committees even while vendors investigate. Waiting for the vendors to agree on root cause could consume time the bank does not have.
These categories should appear in the incident plan, not remain buried in architecture diagrams. Every consequential AI workflow needs a named owner for containment, evidence preservation, customer remediation, vendor escalation and regulatory assessment.
What buyers should require before deployment
The immediate procurement question is concrete: can the proposed operating model support an investigation under deadline?
Buyers should require a joint incident procedure covering IBM, OpenAI and the customer. It should define notification paths, evidence fields, response times, model-change records and the authority to suspend the affected workflow.
They should also test the procedure with a specific failure mode. Pick one consequential output, trace every system that shapes it and ask each party what evidence it can provide. Gaps found during that exercise belong on the launch blocker list.
The bank should keep one internal incident owner throughout. Vendor boundaries may explain why evidence arrives from different places. They should never determine whether containment begins.
The same discipline applies to automated systems that fail before teams have agreed on ownership, a pattern explored in The Automation Broke Before Stand-Up. By the time a disputed output reaches compliance, the useful question is no longer whose logo appeared on the proposal. It is who can stop the workflow, preserve the record and account for every decision that shaped the result.
Comments
No comments yet.