At a mid-market insurance company with eight thousand employees, the Chief Data Officer and the Chief Technology Officer had fundamentally different views on how AI should be adopted. The CDO believed AI should be built on the existing data platform, governed by data quality standards, and deployed through centralized data pipelines. The CTO believed AI should be embedded in application teams, owned by engineering, and deployed through the existing CI/CD infrastructure. Both were right about the parts they understood. Both were wrong about the parts they did not.
The disagreement was not academic. It was blocking three AI initiatives that the CEO had approved. A claims triage model was stalled because the CDO wanted it built in the data warehouse and the CTO wanted it built as a microservice. A customer segmentation model was deployed by the CTO’s team but used data that the CDO’s team had not certified, which triggered a compliance flag. An internal chatbot was built by the data team but could not be integrated into the company’s application stack because the CTO’s team did not support the deployment environment.
The CEO asked us to resolve the disagreement. Not to pick a winner — to find the operating model that would let both leaders contribute their strengths without blocking each other.
The Real Disagreement
The surface disagreement was about technology choices: warehouse versus microservice, SQL versus Python, batch versus real-time. The real disagreement was about ownership. Who owns the AI output when it fails?
The CDO’s position was that AI outputs are data products. A claims triage model produces a score. That score is a data element that flows into downstream systems. The data team owns data quality, data governance, and data lineage. Therefore, the data team should own the model that produces the score.
The CTO’s position was that AI outputs are application features. A claims triage model is a service that the claims application calls. The engineering team owns application reliability, API contracts, and deployment. Therefore, the engineering team should own the model that provides the service.
Both positions were internally consistent. The conflict arose because an AI model is simultaneously a data product and an application feature. It consumes data (the CDO’s domain) and serves predictions (the CTO’s domain). No single team could own it entirely because no single team had full competence across both domains.
The Split That Worked
The resolution was a split ownership model with explicit boundaries. The model lifecycle was divided into three phases, each with a clear owner.
The first phase — data preparation, feature engineering, model training, and evaluation — was owned by the CDO’s team. This phase was a data pipeline. It consumed raw data, applied transformations, trained models, and produced evaluation metrics. The CDO’s team had the expertise, the tooling, and the governance framework for this work.
The second phase — model packaging, API development, deployment, and monitoring — was owned by the CTO’s team. This phase was an application service. It took a trained model artifact, wrapped it in an API, deployed it to production infrastructure, and monitored latency, throughput, and error rates. The CTO’s team had the expertise, the infrastructure, and the operational framework for this work.
The third phase — business logic integration, user-facing behavior, and outcome tracking — was owned by the business unit that consumed the model. The claims department owned the decision about how the triage score was used, what threshold triggered human review, and how the model’s impact on claims processing time was measured.
This diagram requires JavaScript.
Enable JavaScript in your browser to use this feature.
The handoff between phases was the critical design element. The handoff was not a meeting or an email. It was a contract — a machine-readable specification that defined what the producing team delivered and what the consuming team required.
The handoff from the CDO team to the CTO team included the trained model artifact, the feature pipeline specification, the evaluation metrics against a predefined test set, and the data dependency manifest listing every input feature and its source. The CTO team could not accept the model if the evaluation metrics did not meet the agreed thresholds. The CTO team could not deploy the model if the data dependencies were not available in production.
The handoff from the CTO team to the business unit included the deployed API endpoint, the latency and availability SLA, the monitoring dashboard, and the cost-per-prediction metric. The business unit could not use the model if the latency exceeded their application’s requirements. The business unit could not scale usage beyond the agreed volume without a capacity review.
The Governance Layer
A governance board was established with one representative from each team: data, engineering, and the consuming business unit. The board met biweekly for the first three months, then monthly. Its function was not to make technical decisions. Its function was to resolve ownership disputes before they became escalations.
The board had three rules. First, every AI initiative required a documented ownership assignment before work began. The assignment specified which team owned each phase and what the handoff contracts contained. No work started without this document.
Second, a model could not move between phases without passing the quality gate. The CDO team could not hand off a model with evaluation metrics below the threshold. The CTO team could not hand off a deployment that did not meet the latency SLA. The gates were automated — the handoff system checked the metrics against the contract and rejected non-compliant handoffs without human intervention.
Third, outcome data flowed back to the CDO team. When a model was in production, the business unit tracked its impact — claims processing time, customer satisfaction, cost per decision — and fed the metrics back to the data team. This closed the loop. The data team could see whether their model improvements actually changed business outcomes, which informed their investment decisions.
What Each Side Lost
The split model required both leaders to give up something they wanted.
The CDO lost direct control of deployment. The claims triage model was trained by the data team but deployed by the engineering team. If the deployment had a bug — incorrect API response format, missing error handling — the data team could not fix it directly. They filed a ticket with the engineering team and waited. For a team accustomed to controlling the full pipeline, this was uncomfortable.
The CTO lost the ability to build models independently. The engineering team had data scientists who could train models. Under the new model, all training went through the CDO’s team to ensure data governance compliance. The engineering team’s data scientists were reassigned to the CDO’s team, which reduced the CTO’s headcount by four and created an organizational grievance that took two months to resolve.
Both losses were real. Both were necessary. A model trained without data governance creates compliance risk. A model deployed without engineering standards creates operational risk. The split model accepted both costs to avoid both risks.
The Unplanned Benefit
The most valuable outcome was not the resolution of the ownership conflict. It was the handoff contracts. Before the split model, the data team delivered models as notebooks. The engineering team converted notebooks to services through a manual process that took three to six weeks per model. The handoff contracts standardized the interface between teams, which reduced the conversion time to one week.
Standardization also reduced errors. The manual conversion process introduced bugs — feature transformations that were implemented differently in the notebook and the service, date formats that were parsed differently, null handling that was inconsistent. The handoff contract specified the exact feature transformation logic, the expected input and output formats, and the error handling behavior. When the engineering team implemented the service, they implemented it against the contract rather than reverse-engineering the notebook.
Over twelve months, the company deployed seven AI models using the split ownership model. The average time from model training to production deployment was three weeks, compared to eight weeks under the previous ad hoc process. The number of production incidents caused by model-to-service integration errors dropped from four per quarter to zero.
A Rule for AI Governance
If your organization has separate data and engineering leadership, do not try to consolidate AI ownership under one leader. The competency gap is real. Data teams understand feature engineering but not production operations. Engineering teams understand deployment but not data quality. Forcing one team to own the full lifecycle creates a competence bottleneck.
Instead, split the lifecycle at the point where the work changes character. Model training is a data activity. Model serving is an engineering activity. The handoff between them is a contract, not a conversation. Automate the quality gates. Make the contract machine-readable. Let each team do what it is good at and stop pretending that a single team can do everything well.
The governance board exists to enforce the contract, not to make technical decisions. If the board is making technical decisions, the ownership model is wrong. The board should be resolving disputes about who owns what, not deciding how things should be built. Keep the board out of implementation details and keep it focused on the boundaries between teams.
