AI Governance & Risk

AI governance that survives contact with engineering.

Most AI policy is written to be filed. I build governance the way I build systems: an inventory that's actually complete, controls mapped to the frameworks your customers ask about, and review gates in the pipeline so shipping safely is the path of least resistance.

Written by the person who implements itISO/IEC 42001NIST AI RMFEU AI ActSOC 2 · ISO 27001OWASP LLM Top 10
Oshri Cohen, AI governance and risk
Oshri CohenFractional & Interim CAIO
The short answer

What AI governance actually means.

AI governance is the set of decisions, controls and records that let a company say, with evidence, what AI it runs, what each system is allowed to do, who approved it, and what happens when it's wrong. It answers the four questions that arrive together: the customer security questionnaire, the auditor's model-risk request, the regulator's classification test, and your own board asking whether anyone is watching.

It gets built badly most of the time for a predictable reason. Policy is drafted by people who don't ship, so it describes controls engineering can't implement, and engineering routes around it. Nine months later the inventory is stale and the policy is a document nobody has opened since the offsite.

I build it from the other direction. The inventory comes first, because every framework depends on it and almost nobody has one that's complete. Then the classification, then the controls, then the review gates inside the delivery pipeline where the work already happens. This is the governance half of the Chief AI Officer job, and companies often buy it on its own first. You get me for it rather than an audit team: the same person writes the controls, sits with your engineers while they implement them, and answers for whether they hold.

Also known as: AI risk management, responsible AI program, AI compliance readiness, AI management system (AIMS), model risk governance.

What prompts the call

You can't answer a question you can't inventory.

Four situations, and each one ends with the same discovery: nobody knows the full list.

Shadow AI

Employees are using tools nobody approved, often with customer data. IBM has put the average cost of a shadow-AI-related breach at roughly $4.6M, well above a standard one. Banning the tools just moves them to personal accounts.

The questionnaire

An enterprise prospect sends a forty-question AI addendum before signing. Legal forwards it to engineering, engineering forwards it back, and the deal sits there.

Agents with real permissions

The moment an AI system can write to a database, spend money or email a customer, the old review process is the wrong shape. Nobody has scoped what it may do when it's confidently wrong.

The regulatory clock

The EU AI Act's transparency duties are live, its high-risk obligations are dated, and US state rules keep arriving. If your systems aren't classified, you don't yet know which apply to you.

The frameworks

Three references, one control set.

These get treated as competing standards. They aren't. One structures the risk work, one certifies the management system, one is law. Build the controls once, map them three ways, and fold them into the SOC 2, ISO 27001, HIPAA, GDPR and PCI DSS obligations you already carry.

01

NIST AI RMF

The US risk framework, voluntary and sensible. Its four functions give the program its skeleton, and Govern is the one everyone skips and then has to redo.

  • Govern: accountability, roles, policy, and the review body that decides
  • Map: the inventory, context and intended use of every system
  • Measure: evaluation, bias testing, drift and quality metrics you actually track
  • Manage: prioritized response, incident handling and decommissioning
02

ISO/IEC 42001

The certifiable AI management system standard. This is the one that turns a program into something an external auditor can sign, which is increasingly what enterprise procurement wants to see.

  • AI management system scoped, documented and internally audited
  • Impact assessments and supplier controls for third-party models
  • Clean interlock with your existing SOC 2, ISO 27001 or HITRUST program
  • Evidence collected as a by-product of the work, not reassembled before the audit
03

EU AI Act

Law, not guidance, and it reaches US companies whose systems touch the EU market. The dates have moved once already, so the practical answer is to classify now and stage the work.

  • Prohibited-practice screen across the inventory, first and non-negotiable
  • Risk classification per system: prohibited, high-risk, transparency, minimal
  • Article 50 transparency duties, applicable since August 2026: disclosure, content marking, deepfake labelling
  • High-risk obligations for stand-alone Annex III systems now dated December 2027, so sequence rather than panic
The engagement

Inventory. Classify. Wire it in.

Roughly eight to twelve weeks for a mid-market company, run as a fixed scope or inside a fractional CAIO engagement.

Weeks 1–3

The complete inventory

  • Every model, vendor, API, agent and embedded AI feature, including the ones in SaaS tools you didn't buy for AI
  • Shadow-AI discovery through expense data, network telemetry and honest conversations
  • Data flows: what each system reads, retains and sends beyond your boundary
  • Owner assigned per system, because an unowned entry is a finding waiting to happen
Weeks 4–7

Classification and controls

  • Risk classification per system against the EU AI Act tiers and your own materiality
  • Prohibited-practice screen and high-risk determination, documented with reasoning
  • One control set mapped simultaneously to the NIST AI RMF, ISO/IEC 42001 and your SOC 2 or ISO 27001 program
  • LLM-specific threats covered against OWASP's Top 10 for LLM Applications: prompt injection, data leakage, insecure output handling, excessive agency
  • Acceptable-use policy written for the people who'll actually follow it
  • Governance charter: the review body, its remit, and what can't ship without it
Weeks 8–12

Into the pipeline

  • Review gates in CI so classification and evaluation are enforced rather than requested
  • Evaluation harness and drift monitoring on the systems that matter most
  • Incident runbook for AI failures, including the ones that are confidently wrong rather than down
  • A sanctioned toolset good enough that shadow AI stops being worth the effort
  • Evidence pack for customer questionnaires and audits, kept current by the pipeline
  • An owner who can run all of it without me: recruited if you need one, trained if you have one
The difference

Paper governance vs load-bearing governance.

Paper governance

Written to be filed

  • , A policy PDF and a spreadsheet that went stale in a month
  • , Controls engineering can't implement, so engineering ignores them
  • , Inventory assembled by asking people to remember
  • , Evidence reconstructed in a panic before each audit
  • , Shadow AI driven underground rather than replaced
Load-bearing governance

Built into how work ships

  • Inventory maintained by the pipeline that deploys the systems
  • Controls written by someone who has shipped production AI
  • Review gates in CI, triggered by classification
  • Evidence produced continuously as a side effect of delivery
  • A sanctioned path better than the unsanctioned one

Governance fails when it's written by people who never ship. Every control I put in place is one I'd be willing to implement myself, because usually I do.

Oshri Cohen
Common questions

What legal, security & the board ask.

What is AI governance?

AI governance is the set of decisions, controls and records that let a company state with evidence what AI systems it runs, what each is permitted to do, who approved it, and how failures are handled. In practice it means an auditable inventory, risk classification per system, an acceptable-use policy, a review body with real authority, evaluation and drift monitoring, and an incident process.

Which frameworks does this cover?

On the AI side: ISO/IEC 42001, the NIST AI RMF, the EU AI Act, and OWASP's Top 10 for LLM Applications for the threats specific to language models. Underneath that sit the security and privacy regimes a company already carries: SOC 2 Type I and II, ISO 27001, HIPAA, GDPR, CCPA and PCI DSS, plus sector rules like HITRUST in healthcare, FERPA and COPPA in education, and SOX or GLBA in finance. They are not alternatives to each other. NIST structures the risk work, ISO/IEC 42001 certifies the management system, the EU AI Act is law, and the rest govern the data and infrastructure the AI runs on. Build one control set and map it across all of them, because most of the underlying work is shared.

Does the EU AI Act apply to a US company?

It can. The Act reaches providers and deployers whose AI systems are placed on the EU market or whose output is used in the EU, regardless of where the company sits. The practical first step is classification: run the prohibited-practice screen and the high-risk determination across your inventory, because until systems are classified you don't know which obligations you're inside.

What are the current EU AI Act deadlines?

The dates have shifted. Article 50 transparency obligations apply from August 2026: disclosing that a user is interacting with AI, marking AI-generated content, labelling deepfakes. That lands alongside the Commission's enforcement powers over general-purpose AI models. Under the Digital Omnibus adopted in July 2026, obligations for stand-alone high-risk systems under Annex III moved to December 2027, and AI embedded in regulated products under Annex I to August 2028. Classification work is still the immediate task, since it determines everything downstream.

How do you deal with shadow AI without banning everything?

Banning tools moves them to personal accounts, where you have no visibility at all. I find what's actually in use through expense data, network telemetry and candid conversations, then stand up a sanctioned toolset that's genuinely better than the unsanctioned one, with a policy people can follow without asking a lawyer. Enforcement handles the remainder; it can't carry the whole job.

How long does this take, and how is it priced?

Eight to twelve weeks for a mid-market company, quoted as a fixed scope once the estate is understood, or delivered inside a fractional CAIO engagement at $18,000 a month. The AI Diagnostic from $20,000 is a common first step, since it produces the inventory and the shadow-AI audit that the rest of the work depends on.

Who runs the governance layer after you leave?

Someone at your company, which is the point of building it into the pipeline rather than into a document. If the role needs a person you don't have, I recruit them and interview every candidate myself. If you already have the right people in security, legal or engineering, I train them until the review board and the classification work run without me. I stay reachable afterwards for the genuinely hard calls, the ones where a system sits on the edge of a risk tier.

Can you work with our existing SOC 2 or ISO 27001 program?

Yes, and it's the efficient route. I've taken HealthTech, InsureTech and e-commerce companies through SOC 2 Type I and II and run offshore teams under HIPAA protocols, so the AI control set gets mapped into your existing framework and evidence collection rather than run as a parallel program with its own calendar.

How it ends

Four ways out,
all of them yours.

Governance only counts if it runs without its author. The register, the policies and the review board are built to be operated by your people, whichever exit you pick and whenever you pick it. You are never stuck with me.

Route one

Hand it to your team

The governance layer transfers whole: the system inventory, the risk register, the review board's operating rhythm and the policies, documented as they were built rather than reconstructed at the end.

Route two

I recruit the owner

If the risk surface justifies a permanent owner, I scope the role against your actual register rather than a template, interview the candidates myself, and overlap through their first full review cycle.

Route three

I train the person you already have

Compliance, legal and operations people take to this work well. I train yours to run the reviews and the vendor assessments, and stay reachable for the judgment calls.

Route four

I stay on the review board

Some companies keep me as the independent voice on the board I built. Lighter than the full seat, and useful for exactly as long as it is.

Can you list every
AI system you run?

If the honest answer is no, that's the whole problem, and it's a fixable one. Start with the inventory.