One Function or Many? The Case For and Against Unified AI Integrity Management

Two earlier pieces in this series have laid out the conceptual and institutional case. AI Integrity: a Critical Frontier argued that AI integrity is becoming to intelligent systems what cybersecurity became to software. The Case for AI Integrity Management as a Formal Enterprise Function mapped the landscape of existing disciplines — ethics, compliance, cybersecurity, operational reliability — and argued that the structural logic of convergence is real. This third piece asks the harder question: even if convergence is desirable, is it actually achievable? Would a unified AI Integrity Management function produce genuine operational benefits, or would it mostly be a reorganisation on paper — the same specialists doing the same work under a new letterhead?

Has this happened before?

The pattern of unifying previously siloed risk and oversight disciplines into a single function is not new, and the precedents are instructive — both as evidence that it can work and as a reminder of how long it takes.

The most directly relevant analogy is information security becoming cybersecurity. Through the 1990s, information security sat in IT departments, focused on perimeter defence and access controls. Risk management, business continuity, data governance, and legal/compliance each handled their adjacent concerns separately. The convergence into what we now call cybersecurity — with its CISO role, its cross-functional remit, and its board-level reporting line — took roughly a decade of catalysing incidents, the emergence of ISO 27001 as a unifying standard, and sustained regulatory pressure. Even now, the integration is imperfect: privacy, IT security, OT security, and cyber risk quantification frequently operate in tension within organisations that nominally have a unified security function.

A second precedent is integrated risk management (ERM). Before ERM frameworks such as COSO and ISO 31000 gained traction in the 2000s, credit risk, market risk, operational risk, and compliance risk were routinely managed by separate teams with separate methodologies and separate reporting lines. The Basel II and Sarbanes-Oxley pressures of the mid-2000s drove genuine integration in financial institutions — but the process took years, produced significant internal friction, and in many banks resulted in a Chief Risk Officer role that is genuinely cross-functional sitting alongside specialist functions that retained their depth. The integration was real, but it was federated rather than monolithic.

A third, less obvious precedent is Health, Safety, and Environment (HSE) in heavy industry. What was originally three distinct functions — occupational health, physical safety engineering, and environmental compliance — was unified into a single HSE discipline over the course of the 1980s and 1990s. The integration was driven by a recognition that the same operational decisions simultaneously affected all three domains, and that managing them in silos produced gaps in accountability when incidents crossed boundaries. The analogy to AI is closer than it might appear: AI failures, like industrial incidents, tend to be multi-causal and cross-domain, and the governance gap that HSE integration was designed to close is structurally similar to the gap that AI Integrity Management would address.

The common thread across these cases is that integration worked — where it did work — not by eliminating specialisation but by creating a coordination layer that held specialists accountable to shared outcomes. The cybersecurity architect, the GRC analyst, and the incident responder all retained their technical depth; what changed was that they reported upwards through a function with a unified mandate and shared metrics.

The collaboration challenge is structural, not just cultural

The The Integral Management Society‘s Tegrity.ai working group takes seriously the argument that AI integrity integration faces a structural challenge, not merely a cultural one. The disciplines involved are not just professionally distinct — they operate at genuinely different timescales, use different evidence standards, and optimise for different outcomes.

Consider the collision between compliance and MLOps. A compliance officer managing EU AI Act obligations works on a timescale of quarters and years, uses legal and regulatory evidence standards, and optimises for documented conformity. An MLOps engineer managing model drift works on a timescale of hours and days, uses statistical evidence standards, and optimises for system performance. These are not merely different cultures — they are genuinely different epistemic practices. Forcing them into the same reporting structure without a deliberate translation layer does not produce integration; it produces confusion about who owns what.

The data fragmentation problem compounds this. Many enterprises run AI workloads across platform-specific silos — Oracle ERP, Salesforce, ServiceNow — where each system sees only a subset of corporate data. Enforcing organisation-wide integrity controls such as consistent model versioning, unified audit trails, or enterprise-wide drift detection requires deliberate integration work that frequently falls between teams precisely because no single function owns the full stack. Research on cross-functional AI governance consistently identifies this ownership gap as the most common failure mode of AI governance programmes: the ambition is cross-functional, but the accountability remains fragmented.

The honest case against unification

Before making the case for integration, it is worth stating the sceptical position fairly, because it is not trivial.

The strongest argument against unification is the depth-breadth trade-off. Compliance experts bring deep knowledge of sector-specific regulations — CCPA, HIPAA, MiFID II, DORA — that took years to develop and cannot easily be replicated by a generalist AI integrity manager. Ethics specialists bring training in moral philosophy, stakeholder engagement methods, and societal impact assessment that are genuinely different from engineering or legal competencies. MLOps engineers understand model behaviour at a level of technical detail that is inaccessible to non-specialists. Subsuming all of these under a single AI Integrity Management remit risks producing a function that is nominally responsible for everything and genuinely expert in nothing — exactly the kind of cosmetic unification that the sceptics rightly fear.

The second serious argument is bureaucratic overhead. Every additional governance layer adds latency to AI development and deployment cycles. In organisations where AI experimentation is still a competitive differentiator, a centralised integrity function with approval authority over model deployments can become a bottleneck that drives innovation underground — producing the «shadow AI» problem where teams bypass governance precisely because it is too slow to be compatible with their working rhythm.

Third, there is the metric alignment problem. Compliance functions are typically penalised for any violation — their incentive is zero-tolerance. Business units are typically rewarded for speed and output. Engineering teams are rewarded for system performance and uptime. Ethics boards are rewarded for outcomes that are often difficult to quantify. Placing these incompatible incentive structures under a single roof does not resolve the tension; it internalises it. Unless the governance charter explicitly reconciles these goals — which requires sustained executive attention and real authority — the internal tensions re-emerge as turf battles and passive non-cooperation.

What the advantages of unification actually require

The advantages of a unified AI Integrity Management function are real, but they are conditional — they materialise only when specific organisational design conditions are met.

End-to-end accountability requires not just a single reporting line but a single owner with actual authority to halt a deployment if data-quality checks, model-validation tests, ethical reviews, and compliance sign-offs have not been completed in sequence. In most organisations, that authority does not currently exist. Creating it requires a deliberate board or CEO decision — a precondition that is not yet reliably met in most enterprises.

Faster incident response is a genuine benefit when an AI system exhibits drift, hallucination, or a security breach simultaneously. But this benefit requires the team to have been assembled and trained together before the incident — not pulled together in crisis mode. The investment in pre-incident joint exercises and shared incident-response protocols is a condition of the benefit, not a consequence of it.

Consistent metrics and reporting — organisation-wide KPIs such as integrity hallucination rate, model-version lag, or policy-violation closure time — are meaningful only if the underlying data infrastructure supports them. In most enterprises, the data required to compute these metrics sits in systems owned by different teams, in formats that are not interoperable. Building the shared observability layer is a prerequisite, and each link in the causal chain requires investment before the next becomes possible.

A federated model as the realistic path

The most credible path to genuine AI Integrity Management — as opposed to cosmetic unification — is probably not a monolithic department but a federated model that preserves specialist depth while creating genuine coordination mechanisms. This is, in fact, what the more successful precedents (cybersecurity, ERM, HSE) actually produced, even when they were nominally described as unified functions.

In practice, a federated model means: compliance, security, ethics, and operational reliability teams retain their specialist identity, methodologies, and technical depth. What changes is that they are bound by a shared governance charter, report through a common escalation pathway for cross-domain issues, use a shared model registry and monitoring platform as their common source of truth, and are evaluated against shared integrity KPIs alongside their specialist metrics. The AI Integrity Management function, in this model, is less a department and more a coordination protocol — closer to what a Chief Risk Officer does in a mature ERM framework than to what a CISO does in cybersecurity.

The mechanisms that make this work — enterprise-wide governance boards with cross-functional membership and real enforcement authority, policy-as-code platforms that apply controls across all teams simultaneously, rotating assignments and communities of practice that build shared language without eliminating specialisation, and conflict-resolution protocols for when regulatory, ethical, and operational requirements pull in different directions — are well documented. What is less documented is how frequently organisations implement these mechanisms superficially: standing up a governance committee that meets quarterly but has no enforcement authority, deploying a model registry that nobody is required to use, or creating a community of practice that produces documentation nobody reads.

Probability by organisational type

Balancing these drivers and obstacles, the Tegrity.ai working group at The Integral Management Society assesses the likelihood of genuine — not cosmetic — AI Integrity Management integration as follows:

• Heavily regulated, AI-intensive sectors (finance, healthcare, critical infrastructure, government): High probability within 3–5 years, driven by regulatory pressure (EU AI Act, DORA, sector-specific AI rules), board-level scrutiny, and the operational stakes of mission-critical deployment. The initial label will likely remain «AI governance» or «model risk management,» but the scope will expand to cover operational reliability, security, and ethics in a functionally integrated way.
• Large multinationals with mature GRC and ERM functions: Moderate-to-high probability, particularly where integrated risk platforms can be extended to cover AI-specific controls without a complete rebuild. The ERM precedent creates an institutional template that reduces political resistance to integration.
• Mid-market and lightly regulated firms: Moderate probability, contingent on the availability of affordable AI governance platforms that bundle compliance, security, and ethics modules, and on whether AI use cases become material enough to justify a dedicated function. The most likely trigger is a significant AI-related incident that forces rapid governance maturation.
• Small organisations and start-ups: Low probability of a formal function; AI integrity is likely to be handled by ad-hoc committees or outsourced to specialised consultancies until scale or regulatory exposure triggers internalisation.

The key variable across all these categories is not the availability of frameworks or tools — those exist — but the availability of leadership with both the authority and the sustained attention to enforce cross-functional accountability when it creates friction. That is, ultimately, a human and political variable more than a technical one.

What the Tegrity.ai working group can contribute

From the perspective of the Tegrity.ai working group at The Integral Management Society, the most useful contributions to this debate are not advocacy for a particular organisational design, but practical tools that make genuine integration more achievable:

• A reference operating model that maps specific integrity controls — data lineage checks, model-card validation, ethical-impact assessments, compliance sign-offs, runtime monitoring — to responsible roles and shows how they can be orchestrated through a shared governance platform, without requiring any single team to surrender its specialist identity.
• Minimal viable metrics — Authority-Stack consistency score, PRISM-style integrity hallucination rate, model-provenance latency — that are intelligible to auditors, compliance officers, and engineers simultaneously, creating a common language without flattening the technical distinctions between domains.
• Documented case studies of enterprises that have successfully integrated AI integrity controls into existing GRC or SecOps toolchains, with honest reporting on both the benefits achieved and the implementation failures encountered.
• Engagement with standards bodies — ISO/IEC JTC 1/SC 42, NIST, IEEE — to advocate for explicit integrity-management guidance that bridges the ethical-safety-governance triad, reducing the risk of fragmented interpretations that would make cross-border AI Integrity Management permanently harder.

The question of whether AI Integrity Management emerges as a genuine unified discipline or as a collection of loosely coordinated silos will be answered less by the quality of the arguments for integration and more by whether the organisations that attempt it build the coordination infrastructure before they need it — rather than assembling it in the aftermath of a failure that made the cost of fragmentation impossible to ignore.

The Tegrity.ai working group is an initiative of The Integral Management Society, a Swiss non-profit association bringing together senior specialists from adaptive systems, complex systems, artificial intelligence, mission-critical operations, and governance. This article is the third in a series examining AI Integrity Management as an emerging enterprise discipline.