AI Governance for Security Leaders: The Policy Framework Your Organization Needs Before the Regulators Ask for It
AI Governance for Security Leaders: The Policy Framework Your Organization Needs Before the Regulators Ask for It
How to build a practical AI governance program before regulatory pressure forces a rushed response
| Bola Mabawonku · Senior GRC Manager & Cloud Security Architect · August 2026 · 8 min read |
There is a pattern I have seen play out consistently in organizations that are serious about security governance. A new capability emerges, moves fast, gets adopted broadly across the business, and only then does the governance conversation begin. This is usually because something went wrong or a regulator started asking questions. I watched it happen with cloud adoption. I am watching it happen right now with artificial intelligence. The difference this time is the scale and speed of deployment. Large language models, copilot tools, AI-assisted code generation, automated customer service platforms – these capabilities are landing inside organizations simultaneously, often without formal procurement processes, security reviews, or any coherent policy framework. The gap between what is being deployed and what is being governed is wider than anything I have seen in my career.
This article is not about the future of AI or about theoretical risk. It is about what security leaders need to build right now, with the tools and frameworks that exist today, to govern the AI capabilities that are already operating inside their organizations.
The Regulatory Landscape Is Moving Faster Than Most Organizations Realize
Security leaders who are waiting for regulatory clarity before acting are making a strategic error. The regulatory direction is clear even if the final details of every jurisdiction are still being resolved.
The EU AI Act, which entered into force in August 2024 and begins applying its substantive requirements from August 2026, categorizes AI systems by risk and imposes obligations accordingly. High-risk AI systems, which include AI used in critical infrastructure, credit scoring, insurance underwriting, and employment decisions, face significant compliance obligations including conformity assessments, technical documentation, transparency requirements, and human oversight mechanisms. Financial institutions deploying AI for credit decisions or fraud detection are almost certainly operating high-risk systems as defined by the Act. The NIST AI Risk Management Framework (AI RMF 1.0), published in January 2023, provides a voluntary but increasingly referenced framework covering four core functions: Govern, Map, Measure, and Manage. Regulators in the United States and Canada, including the OCC, FDIC, and OSFI are beginning to reference the AI RMF in their supervisory guidance. For financial institutions already subject to model risk management requirements under SR 11-7, AI governance is not a new concept but the scope of what constitutes a ‘model’ is expanding rapidly.
ISO/IEC 42001:2023, the international standard for AI management systems, provides a certification pathway for organizations wanting to demonstrate structured AI governance to clients, regulators, and partners. It is not yet widely adopted, but it is the direction the market is moving.
| The question security leaders should be asking is not whether AI governance will be required. It will. The question is whether your organization builds the capability now, on its own terms, or responds reactively when a regulator asks to see your AI inventory during an examination. |
What an AI Governance Framework Actually Looks Like
I want to be specific here because the term ‘AI governance framework’ has become diluted by vendor marketing. What I am describing is not a purchased product. It is a set of policies, processes, and controls that your organization designs, owns, and operates. The foundation is an AI inventory. You cannot govern what you do not know exists. Most organizations that have conducted a serious AI inventory have been surprised by what they found AI tools embedded in SaaS platforms, AI-assisted features enabled by default in productivity software, and AI models developed informally by business units without security or legal involvement. The inventory should capture the AI system name and vendor, the use case and business function it supports, the categories of data it processes, the risk classification under applicable frameworks, the model owner, and the date of last review.
The second element is a risk classification process. Not all AI systems pose the same risk, and applying the same governance overhead to a grammar-checking tool as to a credit-scoring model is neither practical nor necessary. Classify AI systems based on the sensitivity of data they process, the nature of decisions they inform or make, the potential for harm to individuals or the organization, and the regulatory context. Use the EU AI Act risk tiers as a starting framework. Tiers could span prohibited, high-risk, limited-risk, and minimal-risk and map your inventory against those categories. The third element is a policy framework. At minimum, you need an AI use policy that covers acceptable and prohibited use cases, data handling requirements for AI tools, obligations around training data and model inputs, disclosure requirements for AI-assisted decisions, and the approval process for deploying new AI capabilities. This does not need to be a hundred-page document. It needs to be clear, proportionate, and actively enforced.
The Controls That Actually Matter
Beyond policy, there are specific technical and operational controls that materially reduce AI risk. I want to highlight the ones that I think are most important and most commonly overlooked. Prompt injection controls matter enormously. Large language models can be manipulated through carefully crafted inputs to behave in unintended ways, including revealing sensitive information, bypassing restrictions, or executing unauthorized actions. If your organization is deploying LLMs in customer-facing applications or internal productivity tools, prompt injection testing should be part of your pre-deployment security review, not an afterthought. Data minimization at the model interface is critical for regulatory compliance and for containing blast radius. Every piece of sensitive data sent to an external AI provider customer names, account numbers, health information, proprietary business data is a data transfer with associated risk. AI use policies should define clearly what categories of data may and may not be submitted to external AI tools, and technical controls should enforce those restrictions where possible.
In addition, human oversight requirements for high-risk decisions are essential. AI systems that inform significant decisions about individuals credit approvals, fraud classifications, insurance underwriting require meaningful human review before those decisions are finalized. ‘Meaningful’ here means a reviewer who has sufficient information, time, and authority to override the AI recommendation. A compliance process where a human rubber-stamps AI outputs without genuine review does not satisfy this requirement under the EU AI Act or under sound governance principles. Model monitoring is an ongoing operational requirement, not a one-time deployment activity. AI models drift over time as the data they encounter diverges from their training data. Monitoring should track output quality, accuracy against ground truth where available, and indicators of bias or drift. Without monitoring, you will not know when a model that was performing well at deployment has degraded and neither will your regulators, until something goes wrong.
| The security leaders who will navigate AI governance successfully are not the ones waiting for a perfect regulatory framework. They are the ones building defensible, documented, proportionate governance now so that when regulators ask, the answer is ready. |
The Conversation With Your Board
AI governance is a board-level topic, and security leaders need to be able to communicate it at that level. The framing I have found most effective is not ‘AI is dangerous’ – that generates defensiveness. The effective framing is ‘AI creates new categories of risk that require the same governance discipline we apply to other material risks, and the regulatory expectations are crystallizing now.’ Boards respond to three things: regulatory obligation, reputational exposure, and competitive risk. For AI governance, all three are present. The regulatory obligation is arriving whether or not your organization is ready. The reputational exposure from an AI-related incident such as discriminatory outputs, data leakage through an AI tool, an AI-assisted fraud that was not caught is significant and increasingly publicized. And the competitive risk of moving too slowly on AI adoption, without governance, is now being explicitly called out by financial regulators who want institutions to innovate responsibly, not to avoid innovation. Your board needs to understand what AI capabilities are currently deployed, what the material risks are, what governance is in place, and what investment is required to close the gap. That conversation requires preparation. It also requires the kind of business-risk framing that moves governance from a compliance burden to a strategic capability.
AI governance is not a constraint on AI adoption. Done well, it is the reason adoption survives contact with a regulator.
References
- European Parliament & Council of the European Union. (2024). Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (EU AI Act). Official Journal of the European Union. https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32024R1689
- National Institute of Standards and Technology. (2023). AI risk management framework (AI RMF 1.0). U.S. Department of Commerce. https://doi.org/10.6028/NIST.AI.100-1
- International Organization for Standardization. (2023). ISO/IEC 42001:2023 — Information technology: Artificial intelligence — Management system. https://www.iso.org/standard/81230.html
- Board of Governors of the Federal Reserve System, Federal Deposit Insurance Corporation, & Office of the Comptroller of the Currency. (2023). Interagency guidance on third-party relationships: Risk management. https://www.occ.gov/news-issuances/news-releases/2023/nr-occ-2023-73a.pdf
- Board of Governors of the Federal Reserve System. (2011). Guidance on model risk management (SR 11-7). https://www.federalreserve.gov/supervisionreg/srletters/sr1107.htm
- Financial Stability Board. (2024). Artificial intelligence in financial services: Market developments and key issues. https://www.fsb.org/2024/11/artificial-intelligence-in-financial-services-market-developments-and-key-issues
- MITRE Corporation. (2024). MITRE ATLAS — Adversarial threat landscape for artificial intelligence systems. https://atlas.mitre.org
- Organisation for Economic Co-operation and Development. (2023). OECD principles on AI. https://oecd.ai/en/ai-principles
- Laux, J., Wachter, S., & Mittelstadt, B. (2024). Trustworthy artificial intelligence and the European Union AI Act: On the conflation of trustworthiness and conformity with human rights standards. Social & Legal Studies, 33(1), 3–36. https://doi.org/10.1177/09646639231195513
| About the author
Bola Mabawonku is a Senior GRC Manager and Cloud Security Architect with over five years of experience delivering cybersecurity programs across financial services, healthcare, and technology sectors. He holds the CISM, CRISC, CISSP, and CCSP certifications and has built and led enterprise security programs from the ground up, including an 18-month greenfield program build as Chief Information Security Officer at a financial institution regulated by the CBN. His work spans governance, risk, cloud security architecture, compliance automation, and detection engineering. Portfolio: bolamabawonku.com · LinkedIn: linkedin.com/in/bolarinwa-mabawonku |
No Comments