Data and AI leaders should create a shared operating model that brings business, IT, data, legal, and analytics teams into the same planning cycle. The goal is not just coordination, but a common view of priorities, governance, and delivery. When these groups align early, organisations can move from isolated experiments to faster, more trusted AI use cases with clearer business value.
Shared planning is the fastest way to remove AI delivery bottlenecks
Silios usually persist because teams optimise for different outcomes: business teams want use cases, data teams want quality and access, IT wants stability, legal wants risk control, and analytics wants model performance. A shared operating model makes those trade-offs visible in one planning cycle, so prioritisation, ownership, and delivery decisions happen once instead of being renegotiated at every handoff.
That matters because AI programmes slow down when discovery, data readiness, approval, and deployment are treated as separate tracks. When the groups align early, the work shifts from isolated pilots to a pipeline of use cases that can move through governance, build, and release with fewer late-stage reversals.
For leaders, the practical question is not whether collaboration exists, but whether it is decision-making collaboration. A useful operating model defines who approves data access, who owns model risk decisions, who funds remediation, and what evidence is required before a use case moves forward.
What a cross-functional AI operating model needs to cover
At minimum, the model should connect use-case intake, data access, architecture review, legal and privacy review, delivery sequencing, and post-launch monitoring. Without those links, each team can remain efficient inside its own function while the programme as a whole stays slow.
The strongest operating models also make dependencies explicit. If a use case cannot proceed until data quality issues are fixed or a policy exception is approved, that dependency should be visible at intake, not discovered after design work is complete. That reduces rework and prevents teams from treating governance as a final gate rather than part of delivery.
Leaders should also separate coordination from standardisation. Coordination gets teams aligned on the same priority; standardisation gives them repeatable patterns for data onboarding, model approval, release checks, and change control. The second is what turns one successful pilot into repeatable speed.
- Use a single intake path for AI demand so business value, feasibility, and control requirements are assessed together.
- Set clear decision owners for data, legal, architecture, and deployment approvals.
- Track shared milestones, not function-specific milestones only.
- Standardise reusable patterns for approved data sources, model validation, and release checks.
Risk and Threat Considerations
When AI teams move fast without breaking down silos, the main risk is not just inefficiency, it is ungoverned acceleration. Fragmented decisions can produce duplicated models, inconsistent data use, unclear accountability, and weak approval trails, which makes both delivery and oversight harder.
Failure mechanism: Separate teams make partial decisions in sequence, so business urgency outruns data governance, legal review, and technical control checks. That can lead to unreliable outputs, unapproved data use, or a model being launched without clear ownership for remediation.
Impact: The programme may ship faster in the short term, but it accumulates rework, trust issues, and compliance exposure. Over time, those gaps slow adoption because leaders cannot confidently say which use cases are approved, who owns them, or what controls were applied.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST CSF 2.0 and CIS Controls v8 set the technical controls, while ISO/IEC 42001:2023 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| ISO/IEC 42001:2023 | 4 — Context of the organization | Aligns business, data, legal and IT around AI programme context and priorities. |
| 5 — Leadership | Shared operating models need accountable leadership and clear cross-functional ownership. | |
| 8 — Operation | Covers operational planning, controlled delivery and repeatable AI execution across teams. | |
| Recommendation — Define AI programme context and stakeholder needs before approving delivery priorities. Assign leadership accountability for cross-functional AI governance and delivery decisions. Operationalize repeatable AI delivery controls and approval steps across functions. | ||
| NIST AI RMF | GOVERN — Govern | AI governance requires organisational coordination, roles and accountability across stakeholders. |
| MAP — Map | Use-case mapping depends on understanding business value, data needs and risk context together. | |
| MANAGE — Manage | Cross-functional delivery needs ongoing management of risks, controls and implementation trade-offs. | |
| Recommendation — Establish governance roles and accountability across AI programme stakeholders. Map each AI use case to business value, data needs and risk conditions before delivery. Manage AI risks and controls continuously as use cases move toward production. | ||
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | Shared AI operating models depend on a common view of mission, stakeholders and priorities. |
| GV.RR-01 — Roles, Responsibilities, and Authorities | Breaking silos requires clear decision rights across business, IT, data and legal teams. | |
| GV.SC-01 — Cyber Supply Chain Risk Management | AI programmes often depend on third parties, data sources and platform partners across teams. | |
| Recommendation — Align AI work to organizational context and stakeholder priorities. Define and assign roles, responsibilities, and authorities for AI delivery and governance. Coordinate supplier and dependency decisions across the AI programme lifecycle. | ||
| CIS Controls v8 | 6 — Access Control Management | AI delivery often stalls at data and system access approvals that need consistent ownership. |
| Recommendation — Standardize access approval ownership for AI datasets and platforms. | ||
Practitioner Guidance
What to prioritise: Start with the decision points that repeatedly cause delay, usually use-case intake, data access approval, and launch readiness. Those are the places where silos create the most avoidable friction.
What to verify: Make sure every AI use case has a named business owner, a data owner, a technical owner, and a clear escalation path for legal or risk exceptions. If any of those are missing, the model is not yet operating as a shared system.
What good looks like: Teams can move from idea to approved pilot through a repeatable path, with fewer ad hoc approvals and less late-stage redesign. The sign of maturity is not just speed, but predictable speed.
Practitioner takeaway: Faster AI impact comes from reducing decision latency across functions, not from asking one team to work harder inside its own silo.
Related resources from NHI Mgmt Group
- Why do agentic AI programmes break down when data, events, and API access are governed separately?
- Why do tightly coupled storage and governance models break down as more teams and AI agents depend on the same data?
- Why do traditional privacy and consent processes break down in AI-driven data environments?
- Who is accountable when AI governance and data compliance break down in cloud environments?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 23, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
