← All posts

Code-Level AI Governance · Part 2

Your SOC 2 dashboard is green and still cannot answer the AI question

By Mike Carroll ·
Your SOC 2 dashboard is green and still cannot answer the AI question

You passed SOC 2 Type II. Your Vanta dashboard is green across the board. Your Drata evidence collection is humming.

Then your biggest prospect sends a security questionnaire with a brand new section: AI Governance. Model inventory. Data flows through AI providers. Framework alignment to NIST AI RMF or ISO 42001. A dozen questions.

You open Vanta. Nothing. You check Drata. Nothing there either. That is not a bug. It is a gap, and the buyer already knows it is there.

I am not here to trash these tools

I have spent thirty years in IT and security, and I remember when SOC 2 meant binders of screenshots and spreadsheets that took months to assemble. Vanta and Drata changed that completely. They are very good at what they were built for: continuous monitoring of cloud configuration against SOC 2, ISO 27001, HIPAA, and PCI DSS, policy templates, evidence collection, audit workflow. If you need SOC 2 or ISO 27001, they earn their price.

They were built for a world where the hardest compliance question was “how do you handle customer data in your infrastructure.” That question has moved.

What they do not do

SOC 2 was built for traditional software: access control, encryption, change management, incident response. It governs your infrastructure and the processes around it. It does not address AI-specific risk, so no SOC 2 tool can generate evidence for a question the framework never asked.

Here is what is missing.

No codebase scanning for AI. Vanta connects to your cloud provider. It does not connect to GitHub and read your code for AI SDK usage. It cannot tell you your team is importing anthropic, openai, and langchain across fourteen files, because it is not looking at the files.

No AI inventory. SOC 2 has no concept of a model registry. No control says “maintain a list of every AI model in your product,” so the tools do not track one. When a buyer asks which models you use, the dashboard has no answer.

No AI data flow mapping. Where does customer data go when it hits an AI API? Does the provider retain prompts? SOC 2 documents data handling for your systems. It does not extend to third-party AI provider flows.

No framework mapping for AI standards. NIST AI RMF, ISO 42001, the EU AI Act. These are the frameworks in enterprise questionnaires right now, and a SOC 2 tool maps to none of them because they are outside its scope.

I have watched SaaS companies with beautiful SOC 2 dashboards who could not tell me which AI SDKs lived in their own repo. Meanwhile a scrappy startup with no formal policy sometimes had tighter control over model usage than the enterprise asking the question.

”We’re SOC 2 compliant” answers a different question

When a buyer asks how you govern your AI, they are not asking about infrastructure controls. They are asking: what AI are you actually using, where does our data go when it touches those models, who approved them for production, and what happens when a provider changes its terms or its behavior.

Try answering any of that with a SOC 2 report. You cannot. It is like handing someone your driver’s license when they asked for your passport. Valid document, wrong question. And the security teams at large enterprises are not confused about what SOC 2 covers. When they add an AI section, they already know your stack will not cover it. They are testing whether you know it too.

Why AI governance is structurally different

This is not “we need a few more controls.” It is a different shape of problem.

It is code-level, not infrastructure-level. Traditional compliance reads your cloud config from the outside. AI governance needs to know what is inside the codebase: which imports, which SDK calls, which model versions, which endpoints. You cannot detect from openai import OpenAI by scanning an AWS config.

It is model-specific. A private model endpoint on a cloud provider has a different data profile than a direct call to a public API. Your posture has to reflect the difference, which means knowing the difference.

It moves fast. SOC 2 criteria change slowly. AI regulation does not. The EU AI Act timeline has milestones every few months through 2027, NIST AI RMF is moving into federal procurement, and state-level AI laws keep passing. A six-month-old snapshot is already stale.

And it requires scanning, not just policy. You can write an AI governance policy all day. If nobody has scanned the repos to confirm what AI is actually running, that policy is fiction. Real governance starts with an inventory, and an inventory means reading code, not asking engineers what they remember.

The layer you still need

If Vanta and Drata are your infrastructure compliance layer, you need an AI-specific layer above it: codebase scanning that finds AI SDK usage automatically, a current inventory of every model and provider, risk classification on what the scanner actually found, framework mapping to NIST AI RMF and ISO 42001 and the EU AI Act, and a focused brief you can hand a buyer instead of a 200-page binder. It does not replace SOC 2 tooling. It fills the hole SOC 2 was never built to fill.

So next time a questionnaire arrives with an AI section, do not burn cycles stretching SOC 2 evidence to cover it. That is a different question and it needs a different answer.

If you have watched compliance cycles as long as I have, you know how this plays out. AI governance is a differentiator today and a baseline requirement soon. Which side of that line is your evidence on right now?

Part 2 of a three-part series. Part 1 is you cannot secure the AI you never inventoried. Part 3, the EU AI Act applies to you through your buyers, is the forcing function behind all of it.

Sources

AI governanceSOC 2VantaDratacomplianceAI inventory