Delfen
All articlesAI in Practice

Who owns AI governance? The team already running your security

A regulator's own enforcement order named a data breach and an AI-governance failure in the same document — because they were the same failure. Most organizations still staff, budget, and report on AI governance and security governance as if they were unrelated.

Jacques Domenie·20 July 2026·6 min read

On 20 March 2023, a bug in an open-source library caused ChatGPT's servers to briefly show some users other users' conversation titles, and for roughly 1.2% of ChatGPT Plus subscribers, another subscriber's billing details — name, email, payment address, card type, last four digits, expiry date. OpenAI disclosed it as a data breach. Eleven days later, Italy's data protection authority, the Garante, announced a provisional order blocking ChatGPT in Italy entirely, folding in findings that went well beyond the breach itself: no legal basis for using scraped personal data to train the model, no age verification, no transparency to users, no guarantee the training data was even accurate. The case closed in December 2024 with a €15 million fine, still citing the same underlying failures together. One incident, one regulatory order, one fine — governance failures that most organizations still staff, budget, and report on as if security and AI governance were unrelated.

Whoever already owns your security governance

Search "who owns AI governance" and you'll find a real, unresolved argument — CISOs, legal, a newly created Chief AI Officer, a cross-functional committee, all staking a claim. The most detailed answers, like Airia's own framework for defining AI accountability, treat it almost entirely as a RACI question: who sits on the committee, who signs off on a model going into production. Almost none of them ask the more useful question: who already owns the infrastructure this needs — the audit calendar, the control catalog, the incident-response process, the risk register, the vendor-review cadence? For most mid-sized organizations, that infrastructure already has an owner, and it isn't a new AI governance function. It's whoever runs the ISMS.

The same skeleton, on purpose

This isn't a stretch of the standards. ISO/IEC 42001 (AI management systems) and ISO/IEC 27001 (information security management systems) are both built on ISO's Harmonized Structure — the same ten-clause skeleton every modern ISO management standard uses for context, leadership, planning, and operation. Certification bodies say so directly: DNV tells clients already certified to ISO 27001 that adding 42001 "will go easier"; SGS notes both standards "follow the same harmonized structure." NIST's two flagship documents make the equivalent point in their own text — the AI Risk Management Framework names the Cybersecurity Framework directly as applicable guidance for securing AI systems, and CSF 2.0 in turn describes the AI RMF as addressing risks the CSF was never built to cover alone.

Some organizations are proving this in practice, not just in theory. When collaboration platform Miro earned ISO 42001 certification in August 2025, its own announcement was explicit: the AI management system "builds on Miro's existing security and risk management certifications, including SOC 2 Type II and ISO 27001." Vanta and ISMS.online both sell directly into this — cross-mapping ISO 42001 controls against whatever you're already certified to, so the second certification reuses evidence instead of duplicating an audit from zero. My honest caveat: this is a shortcut on top of infrastructure you already run, not a reason to buy a GRC platform for AI governance alone — if you're not already using one for security compliance, the case for one starts with security, and AI governance rides along.

What Brussels actually connected — and what it didn't

Precision matters here, because the EU AI Act gets cited constantly and usually wrong. Article 15 requires high-risk AI systems to be accurate, robust, and resilient against attacks like data poisoning and model manipulation — but Article 15 itself names no other framework. The actual legal bridge sits in Article 42(2): a high-risk system already certified under the EU Cybersecurity Act (Regulation 2019/881) is presumed to meet Article 15's cybersecurity requirement. That's a different law than NIS2 — a mix-up worth not making out loud in front of a regulator. NIS2 Article 21 sets organizational cybersecurity risk-management obligations; the Cybersecurity Act runs product and system certification schemes, and it's the second one the AI Act actually leans on. As for a formal NIS2 bridge: ENISA's own advisory group said in mid-2025 that ENISA "should work on the interplay between the NIS2 and the AI Act" — the polite regulatory way of confirming that bridge doesn't officially exist yet. Anyone telling you it does is ahead of Brussels, not behind it.

When nobody owns the seam

In June 2023, security firm Wiz found that Microsoft's own AI research team had, in 2020, published a GitHub link to open-source training data using an Azure SAS token misconfigured to grant access to an entire storage account instead of the intended folder — with an expiration date pushed out to 2051. The account held 38 terabytes beyond what anyone meant to share: employee workstation backups, secrets, private keys, and over 30,000 internal Teams messages. Nothing exotic went wrong. A credential wasn't scoped and didn't expire — the same failure mode a mature security-governance program exists to catch, sitting inside an AI team's workflow that no security-governance program was watching.

Extend, don't duplicate: the first 30 days

Don't wait for a steering committee to resolve ownership before doing anything. In the first 30 days: add "AI system" as an asset type in whatever tool already runs your risk register; route every AI-vendor security review through the same process a new SaaS vendor already goes through; add one AI-specific question to your existing incident-response runbook — could this involve a model, training data, or an AI vendor; and put your first AI-inventory review, stage two of a real operating model, on the same calendar as your next ISMS internal audit, not a separate one. None of this needs new headcount or a new platform purchase. It needs a decision that AI governance is a scope extension, not a new department.

One caution worth taking seriously: Steve Durbin, CEO of the Information Security Forum, makes a more careful case than a flat "merge on day one" — test AI governance standalone against the risks that are actually pressing, then incrementally fold proven controls into the existing security structure once they've earned it. He's not wrong that AI-specific expertise — model risk, algorithmic fairness, training-data provenance — doesn't come pre-installed on a security team. Synthesia, the AI video company, shows sequencing isn't fixed either way: it earned ISO 42001 in September 2024, nearly a year before it earned ISO 27001 in September 2025 — the reverse order of Miro's. The point isn't that every organization must extend the ISMS first. It's that whoever owns AI governance should be asking what already exists before building a second version of it from nothing.

Here's the falsifiable test I'd apply: ask whoever owns your AI governance program to name the date of the last ISMS internal audit and whether AI systems were in scope. If the honest answer is "I don't know what the ISMS covers," you have two governance programs where you need one — and the seam between them is exactly where the next Wiz-style finding shows up.

Building an AI governance program that shares infrastructure with security instead of duplicating it is a conversation worth having before an audit finds the gap. Delfen advises on exactly this junction.

Sources & further reading

Continue reading

Get the next article in your inbox.

One deep-dive per week. Free. No pitch. Unsubscribe anytime.

Subscribe to the Delfen Briefing →
← Back to all articles