What I Learned Building an Enterprise AI Governance Framework from Scratch

I remember sitting with the enterprise risk register open, running through our standard annual review, when I noticed something that made me stop.

We were three months into deploying an AI-powered fraud detection model at a leading Bank in bangladesh. The model was live, handling decisions on real transactions, affecting real customers. And it was not in the risk register. Not a line. No owner. No controls assigned.

I asked around. Who is responsible if this model makes a wrong call? What happens if it drifts over time? Who approved the data it was trained on? The answer, in every case, was a version of "we assumed someone else handled that." Nobody had. That was early 2023, and it is what started eighteen months of building an enterprise AI governance framework from scratch.

This gap is not unique to banking. According to McKinsey's 2025 State of AI report, 88% of organisations now use AI in at least one business function. Yet Deloitte's 2025 research on AI governance in the boardroom found that while 62% of boards hold regular AI discussions, only 27% have formally added AI governance to their committee charters. The deployment curve and the governance curve are not running together. The gap is widening.

Start with what is already on fire, not with a perfect framework

The instinct when you identify a governance gap is to design a comprehensive framework before doing anything else. I understand the logic. You want a solid foundation. But in practice, by the time you finish the framework, three more AI tools have been deployed and business stakeholders have stopped waiting for you.

I started with our two highest-consequence use cases: the credit-scoring model and the fraud detection algorithm. These sat closest to regulatory scrutiny and had the most direct customer impact if something went wrong. Getting controls around these two areas first gave me credibility with leadership and gave the team a concrete artefact to work from. The broader framework came later, shaped by what we actually found during that first round of controls work.

Starting narrow and building outward is not a shortcut. It is a more honest sequencing of the work.

AI risk and information security risk are not the same discipline

This is the mistake I see most often. Organisations assume their ISO 27001-aligned ISMS will cover AI risk. It will not, not fully. The controls address different failure modes.

ISO 27001 protects your information. ISO 42001 governs how AI uses that information. You need both. They are not interchangeable.

Dimension	ISO/IEC 27001	ISO/IEC 42001
Primary focus	Protecting information assets from unauthorised access, disclosure, and loss	Governing the lifecycle, ethics, and accountability of AI systems
Risk types addressed	Breaches, phishing, insider threats, data leakage	Model bias, performance drift, opaque decision-making, data lineage failures
Typical controls	Encryption, access management, incident response, patch management	Model validation, human oversight, training data review, explainability requirements
Who it applies to	Any organisation that handles information (effectively universal)	Organisations that develop, deploy, or are materially affected by AI systems
Maturity of ecosystem	Mature: extensive guidance, large auditor pool, well-understood controls	Emerging: published December 2023, certification ecosystem still developing

In practice, at that Bank, I had to extend the existing framework to answer questions it was not designed to address: who reviews a model's outputs before and after deployment, on what cadence? What data trained this model, and does that data meet our privacy and quality standards? What triggers a model review or retirement? What happens if the model begins performing differently six months after go-live?

None of those questions had owners. Writing answers to them, getting those answers approved, and embedding them into existing change management and risk processes took the better part of a year.

Third-party AI is where most programmes have their biggest gap

Internal models are at least tractable. You can, in principle, inspect the inputs, outputs, and training logic. Third-party AI services are a different problem entirely. PwC's research on responsible AI and third-party risk management notes that many vendors have embedded AI into their products without customers' explicit awareness. The standard third-party risk questionnaire was not written to catch this.

At that Bank, we had over 90 active vendors. A handful were providing AI-enabled services. When I reviewed their vendor risk assessments, AI-specific questions were absent entirely. I built a supplementary AI vendor assessment that covered four areas:

• Data sovereignty: where does our data go, and what jurisdiction governs it once it enters the vendor's AI system?
• Model transparency: can the vendor explain how the model works and what it was trained on at a level sufficient for our regulatory obligations?
• Incident notification: if the model produces a material error or is compromised, what are the vendor's notification timelines and our contractual remedies?
• The vendor's own governance: does this vendor have an AI governance programme, and can they evidence it?

Most vendors had not seen questions like this before. A few pushed back. That resistance, in itself, was a useful risk signal.

Framing matters: governance as business risk, not technical compliance

I will be honest about something. Early on, I framed AI governance as a technical and compliance concern. The response from leadership was polite but not urgent. Things changed when I reframed it as a business and regulatory risk.

Bangladesh Bank was tightening its stance on ICT risk at the time. A model failure in lending or fraud detection could generate an adverse audit finding, which had direct consequences for our regulatory standing. Presenting the risk that way got the CRO's attention in a way that technical framing had not.

From Q2 2023, AI risk appeared as a distinct category on our board-level risk dashboard, updated quarterly. That visibility changed how seriously the team took the controls work. Governance without senior ownership is just documentation.

ISO 42001 came after, and that is fine

I obtained my ISO/IEC 42001 Lead Auditor certification after most of the framework was already in place. People sometimes interpret this as the certification being retrospective, a badge for work already done. I don't see it that way.

The standard gave me a structured methodology for auditing what we had built, a way to identify gaps we had missed, and a shared vocabulary for communicating programme maturity to external auditors. It also gives AI governance work a recognised, auditable framework in conversations with clients and regulators. That is not trivial.

ISO/IEC 42001 was published in December 2023. Certification numbers are still relatively small globally, which means organisations with genuine, audited programmes have a meaningful differentiator right now. That window will not stay open indefinitely.

Where most organisations actually sit

Based on conversations with peers and the broader research, most organisations are somewhere between "AI governance is IT's problem" and "we have a policy but no active controls." According to Deloitte, only 28% of organisations have formally defined oversight roles for AI governance. The gap between deployment and accountable governance is real and growing.

The good news is that you do not need to solve everything at once. Identify your highest-consequence AI use cases. Get controls around those first. Assign ownership. Build the broader programme from what you learn. That is how we did it, and it worked.

---