Cybersecurity in the Era of AI · Part 1 — AI Governance: An Operating Model, Inventory & Risk Classification

This is Part 1 of Cybersecurity in the Era of AI, and it is deliberately the least technical part — because the first failure of AI security is not a clever attack, it is the absence of anyone who owns the problem. Organizations adopt AI department by department, tool by tool, model by model, and unless someone is accountable for the aggregate risk, no one is. AI governance is the discipline that fixes that: it gives AI risk an owner, creates a shared picture of what AI the organization actually runs, classifies that AI so attention goes where the risk is, and establishes the policies and lifecycle controls that turn "we should use AI responsibly" into something teams actually do. Every later part of this program — the AI Act compliance work, the ISO 42001 management system, the shadow-AI discovery, the secure-development practices — depends on this foundation. You cannot comply with a regulation for systems you have not inventoried, and you cannot secure AI whose existence you have not acknowledged. Governance first, for the same reason a building needs foundations before walls.

The good news is that you are not inventing this from scratch. AI governance has converged on a small set of well-regarded frameworks, chief among them the NIST AI Risk Management Framework — organized around four functions, Govern, Map, Measure, Manage — which gives this part its spine. Govern establishes the culture and accountability; Map builds the understanding of context and risk; Measure assesses and tracks; Manage acts on what you find. This part turns those functions into a concrete operating model you can stand up in weeks, not years.

Scope of this phase

Every part of this program is scope-bounded so you know exactly when you are done.

• In scope: the AI governance operating model (who owns AI risk and how decisions are made); the AI system inventory (a living register of every AI system and significant AI use); risk classification (a scheme that sorts AI use by risk so effort is proportionate); the AI policy foundation (acceptable use, development standards, procurement); and the lifecycle controls that govern AI from idea to retirement.
• Explicitly out of scope (later parts): the detailed obligations of the EU AI Act (Part 2) and the ISO/IEC 42001 management system that formalizes this governance (Part 3); discovering unsanctioned AI (Part 4); and the technical controls for secure AI development and deployment (Parts 5–6). This part builds the governance frame; the later parts fill it.
• Definition of done: the exit checklist at the end of this part. When every box is ticked, AI risk has an owner, you have a classified inventory of your AI, and the policies and lifecycle gates are in force — the base every later part builds on.

The four building blocks — an operating model, an inventory, a risk-classification scheme, and a policy-and-lifecycle foundation — are what turn AI from an ungoverned sprawl into a managed practice. Build them roughly in order; the inventory in particular is the artifact the rest of the program consumes.

Building block 1 — The AI governance operating model

The first question is ownership: who is accountable for AI risk, and how are AI decisions made? In most organizations the honest answer at the outset is "no one, and ad hoc," which is exactly the gap to close. The operating model does not require a large new bureaucracy — in fact heavy AI governance boards that must approve every use case become the bottleneck that drives AI underground (the shadow-AI problem of Part 4). What you need is clear accountability and a light, tiered decision process.

The durable pattern is a small AI governance function — often a cross-functional committee or working group rather than a new department — with representation from security, legal/privacy, data, engineering and the business, chaired by a named owner (increasingly a Head of AI, or the CISO or DPO where that role does not yet exist). Its job is not to make every AI decision but to set the rules, own the inventory and risk framework, and adjudicate the hard cases. Around it sits a tiered process: low-risk AI use follows a self-service path against clear policy, medium-risk use gets a lightweight review, and only high-risk or novel use comes to the committee. This mirrors the enabling-function model that works for security generally — set the paved road, delegate the routine, reserve central attention for the genuinely hard. Crucially, the operating model must connect AI governance to the structures that already exist: AI risk is reported into enterprise risk, AI privacy questions route to the DPO, AI security issues into the security function. AI governance is not a silo; it is a coordinating layer over disciplines you already have.

Building block 2 — The AI system inventory

You cannot govern what you cannot see, and the single most valuable artifact this part produces is a living inventory of every AI system and significant AI use in the organization. This is harder than it sounds because AI enters through many doors: models you build, AI features inside SaaS you buy, foundation-model APIs your developers call, and AI tools individuals adopt. The inventory has to span all of them, and it has to stay current, which means it needs an owner and a process, not a one-time spreadsheet.

For each AI system, capture the facts that later decisions depend on — enough to classify its risk, assess its compliance obligations, and secure it, without so much detail that nobody maintains it:

- id: AI-017
  name: "Support ticket auto-classifier"
  owner: team-support-platform
  purpose: "Routes and prioritizes inbound tickets"
  type: built            # built | embedded-in-saas | foundation-api | individual-tool
  model: "internal fine-tune of open-weight LLM"
  data_in: ["customer ticket text (may contain PII)"]
  data_retention: "30 days"
  decisions: "advisory"  # advisory | automated-with-review | fully-automated
  users_affected: "customers + support agents"
  risk_tier: high        # set in building block 3
  ai_act_role: provider  # provider | deployer | out-of-scope
  status: production

The inventory is the backbone of the whole program: Part 2 uses it to determine AI Act obligations per system, Part 3 makes it a controlled record in the management system, Part 4 reconciles it against what discovery finds (the gap is your shadow AI), and Parts 5–6 secure the systems it lists. Start it now, populate it through a combination of self-declaration (teams register their AI) and active discovery (procurement records, cloud API usage, code scanning for model calls), and treat keeping it current as an ongoing governance duty. An inventory that is 80% complete and maintained beats a perfect one that is instantly stale.

Building block 3 — Risk classification

Not all AI is equally risky, and treating a spam filter with the same rigour as a system that makes hiring decisions wastes effort and credibility. A risk-classification scheme sorts your AI so governance is proportionate — light-touch for low-risk, thorough for high-risk. Your scheme should be simple enough that teams can self-classify with confidence and should align deliberately with the EU AI Act's tiers (Part 2), because that alignment saves you from running two parallel classification systems.

A workable scheme rates each AI system on a few axes that drive real consequences: impact on people (does it affect someone's rights, safety, access to services, or livelihood?), autonomy (is it advisory, or does it act without human review?), data sensitivity (does it process personal, special-category, or confidential data?), and exposure (internal-only, or customer- and public-facing?). The combination yields a tier — minimal, limited, high, or unacceptable — that determines what governance the system needs and previews its AI Act classification. The classification is not academic: a high-risk tier triggers a fuller impact assessment, human-oversight requirements, and the technical controls of the later parts, while a minimal-risk tier follows the self-service path. Getting this scheme right is what keeps the whole program proportionate — effort concentrated where AI can actually harm someone, not sprayed evenly across every chatbot.

Building block 4 — Policy & lifecycle controls

Ownership, inventory and classification tell you what you have and how risky it is; policy and lifecycle controls define what teams must do about it. The policy foundation is a small set of clear documents — restraint matters here as much as anywhere, because a fifty-page AI policy nobody reads governs nothing. Three policies carry most of the weight: an acceptable-use policy for AI (what employees may and may not do with AI tools and data — the frontline defence against shadow AI), an AI development standard (what teams building AI must do — impact assessment, data governance, security review, human oversight), and an AI procurement standard (the due diligence required before buying AI or AI-enabled tools). These connect to the classification: what a policy requires scales with the system's risk tier.

Lifecycle controls make the policy real by attaching governance to the points where decisions are made — the AI analogue of a security-aware definition of done. A new AI system is classified and registered at inception; a high-risk system gets an AI impact assessment before build (the assessment of effects on people and rights that both good practice and the AI Act require, and which ISO 42001 formalizes); data governance and human-oversight design are reviewed before deployment; and every AI system is periodically re-reviewed, because a model's behaviour and its context drift over time. The governing principle is that AI is managed across its whole life — from idea through retirement — not approved once and forgotten. This lifecycle view is precisely what ISO/IEC 42001 (Part 3) turns into a certifiable management system, which is why this part is its natural precursor.

Definition of done — AI governance exit checklist

You are ready for Part 2 when every one of these is true:

• Operating model: AI risk has a named owner and a cross-functional governance function; a tiered decision process routes routine AI use to self-service and reserves central review for high-risk/novel cases; AI governance connects to enterprise risk, privacy and security.
• Inventory: a living inventory captures every AI system and significant AI use across all four entry doors (built, embedded-in-SaaS, foundation-API, individual tools), with an owner and a maintenance process; it is materially complete and current.
• Risk classification: a simple, documented scheme classifies each AI system by impact, autonomy, data sensitivity and exposure into tiers aligned with the EU AI Act; teams can self-classify routine cases.
• Policy foundation: acceptable-use, AI development and AI procurement standards are published, proportionate, and tied to the risk tiers.
• Lifecycle controls: governance is attached to lifecycle points — classification and registration at inception, impact assessment for high-risk systems before build, human-oversight and data-governance review before deployment, and periodic re-review.
• Grounding: the model maps recognizably onto a recognized framework (NIST AI RMF Govern/Map/Measure/Manage or equivalent), so it is defensible and extensible.

Tick every box and AI risk in your organization has an owner, a map, a proportionate rulebook, and gates at the moments that matter. Skip the inventory in particular and everything downstream is built on sand — you will be trying to comply, secure and govern a population of AI systems you cannot enumerate.

What's next

Part 2 — The EU AI Act takes the inventory and classification you have just built and holds them up against the regulation that now sets the legal floor for AI in the EU market. With a classified inventory in hand, determining your AI Act obligations becomes tractable: each system's risk tier and your role (provider or deployer) point directly at what the Act requires. Part 2 covers the Act's risk-based tiers, the specific obligations on high-risk systems and general-purpose models, the compliance timeline through 2027, and how to turn your governance foundation into demonstrable regulatory compliance. It ships next month.

If you would like experienced hands to stand up AI governance — establish the operating model, build the inventory, design the risk-classification scheme and author the policies — that is exactly what Axelia's consultants do, and ISMShed turns the resulting inventory, classifications and assessments into continuous, framework-mapped evidence across ISO/IEC 42001, the EU AI Act, ISO 27001, NIS2, DORA and GDPR. Build the foundation now, and the compliance and security work in the parts that follow becomes a matter of execution rather than archaeology.