Closing the Responsible AI Gap
Introduction
The purpose and need for Responsible AI is generally well understood and agreed upon among organizations. The struggle of moving from an ethical aspiration to an operational imperative is often attributed to the lack of appropriate methodology, governance framework, and cross-functional literacy to implement it.
Organizations typically have a methodology and a governance framework in place; the challenge is to extend them to accommodate the requirements specific to AI.
The gap is most significant across two areas — the GRC framework, which establishes the governance, risk and compliance guardrails; and the methodology, which provides the vehicle for embedding governance into AI development and deployment — both of which require AI-specific provisions, tailored to the organization’s context, to be effective.
The Methodology Gap
Organizations often use conventional approaches to develop or implement AI applications, but these approaches often prove inadequate for AI requirements. Fundamentally, conventional approaches are designed to deliver applications that are deterministic in nature, whereas AI applications are probabilistic and require a different approach.
Agile is often the default choice for managing AI because of its iterative nature. While it can partially be applied across the AI lifecycle, it is insufficient as a standalone methodology for AI development and deployment, particularly because AI applications can never meet the Definition of Done (DoD), and Agile was never designed to embed governance in the application lifecycle.
Several AI methodologies were developed before responsible AI emerged as a requirement, leaving organizations with fewer options. CPMAI stands out as a good option: building on the widely used CRISP-DM lifecycle, it addresses AI-specific requirements, and its lifecycle accommodates the integration of AI governance to support trustworthy AI.
In contrast to conventional applications, the process for implementing an AI application (as a deployer) is similar to that for developing one (as a provider). Using the CRISP-DM lifecycle as an example, deploying an AI application goes through every phase except Phase 4: Modeling. What differentiates the two are the organization’s responsibilities and accountability, notably under the EU AI Act.
The GRC Gap
Selecting the right methodology addresses only part of the challenge; the governance framework supporting it must equally be appropriate for AI. Simply put, the AI lifecycle provides the structure for Responsible AI, with placeholders to integrate governance within each phase, and GRC provides the substance to fill those placeholders.
Both are necessary, and neither can be used in isolation. The AI lifecycle without governance will only succeed at developing a technical solution, leaving the AI application exposed to risk and liability; GRC without the AI lifecycle remains a set of policies, disconnected from how AI systems are built. Unlike conventional GRC, which typically relies on periodic reviews and audits, AI GRC must be embedded into the AI lifecycle to support Responsible AI by design and continuous monitoring.
This integration provides a consistent methodology across AI applications, while accommodating different contexts through GRC provisions that depend heavily on the organization’s industry and on the purpose of the AI systems being implemented.
Cross-functional Literacy
The challenge with traditional roles in most organizations is that project managers and GRC managers require deeper cross-functional knowledge to effectively manage AI initiatives.
It would be difficult for a project manager without explicit knowledge of GRC to successfully embed GRC into the AI Lifecycle; similarly, it would be difficult for a GRC lead without explicit knowledge of the AI Lifecycle to do the same, or even perform audits.
Implementing a comprehensive AI Framework requires, at minimum, training to increase AI literacy across the organization.
AI Centre of Excellence (AI CoE)
PMOs are well established as a reliable mechanism to manage traditional projects, including risks associated with them. They have evolved over the years, adopting new methods in response to demands placed on project execution and deliverables — the adoption of Agile being a good example. While an AI lifecycle is quite different from a traditional project’s lifecycle, the fundamentals of the PMO remain necessary for AI systems development or implementation, including AI agents.
Organizations sometimes establish an AI CoE to manage the internal use of AI. It may be tasked with managing the AI infrastructure, licensing, training, GRC, and development. The establishment of an AI CoE may cause friction due to duplication and overlaps with DevOps, GRC, and the PMO.
The AI CoE may be most effective as an integrator, facilitating collaboration among GRC (AI GRC), the PMO (AI lifecycle), and DevOps (MLOps) to deliver AI systems — avoiding frictions with the three groups. This would also position the AI CoE to provide oversight for conformance to ISO/IEC 42001 and to report on the AIMS performance to top management.
The EU AI Act
While the EU AI Act is legally binding only on organizations operating within or serving the EU market, it has become a de facto reference for AI regulation worldwide.
One aspect of the EU AI Act worth highlighting is the responsibilities assigned to the various operators along the AI value chain. The Act establishes that every operator, whether designated as a provider, importer, distributor, or deployer, bears some degree of accountability, depending on the system’s risk classification. Understanding your role as an operator is essential to establishing the necessary provisions and avoiding unexpected liability.
If you deploy an AI system in your organization, you are the deployer, and deployer obligations apply. This is a significant shift from traditional systems implementation: the Act assigns explicit obligations to the organization deploying the AI system, not only to the organization that built it.
If you make a substantial modification to a provider’s high-risk AI system, you are deemed to be its provider, assuming provider responsibilities in addition to your deployer responsibilities.
Because agentic systems may act beyond their intended scope during execution, an agent initially designed for a narrow purpose may begin profiling individuals or materially influencing decisions, both of which can make an AI system high-risk under the Act, creating a compliance blind spot and potential liability.
Accountability under the EU AI Act, and likely under other AI laws, is dynamic: it shifts with behavior, modification, and use, reinforcing the need for continuous monitoring as a core component of any AI governance framework.
Conclusion
Organizations are under significant pressure to integrate AI into their operations. In attempts to fast-track implementation, they may prioritize the technical aspects of AI deployment over governance, leaving themselves exposed to liability that courts and regulators are increasingly unwilling to overlook.
Closing the Responsible AI Gap requires three interconnected elements, addressed together: the right methodology for AI development and deployment, a governance framework with AI-specific provisions, and the cross-functional literacy to bring both together. This guide has shown how the first two come together, by embedding AI GRC into each phase of the AI lifecycle, with governance gates and artifacts that provide evidence of due diligence. Addressing these gaps not only reduces risk and liability exposure but also establishes a structured approach that leads to greater efficiency, consistency, and confidence in AI delivery.