Right now, somewhere in your organization, an engineer is connecting a production workflow to an LLM they spun up last Tuesday. No security review. No risk assessment. No procurement process. Just an API key, a use case, and a deadline.

Your GRC team will find out eventually. Probably not today.

This is not a technology problem. It is not even a people problem. It is a governance problem, and the uncomfortable truth is that the GRC profession has seen this exact movie before.

We Have Been Here Before

Early in my career, the crisis was cloud. Specifically, it was engineers using corporate purchasing cards to spin up AWS instances without going through IT. No approval process. No security review. Just a credit card, a browser, and access to more compute than the data center had on premise.

Security teams found out one of two ways. The monthly bill showed up with line items nobody recognized, or something broke and the incident response team traced it back to an unmanaged instance running in an account nobody knew existed.

We gave it a name. Shadow IT. And then we did what the industry does: we wrote policies, built controls, stood up Cloud Access Security Brokers, and eventually got ahead of it.

That took years. And it cost companies real money in breach exposure, compliance failures, and unplanned remediation work before governance caught up to the technology.

That was cloud computing — a technology that had a learning curve, required infrastructure knowledge, and still took time to spread. AI tools require none of that. The barrier to deployment is a free account and an afternoon.

The Pattern Is Identical. The Stakes Are Higher.

The dynamic playing out with AI today maps almost perfectly to the early Shadow IT era.

Business pressure is high. Teams are being asked to move fast and find efficiency gains using AI. The tools are accessible. And the governance infrastructure — approved tool lists, risk assessments, data classification guidance — has not kept pace.

So teams make their own calls. They connect internal data to external models. They build workflows that process customer information through systems that have never been through a vendor risk assessment. They make reasonable decisions in the absence of clear guidance, and those decisions accumulate into risk exposure that nobody has mapped.

But the unauthorized tool problem is only half the story.

The Approved Tool Problem Nobody Talks About

Some of the worst exposure I have seen came from tools that went through every step of the process.

An enterprise LLM contract gets signed. The vendor passes third party risk review. Legal signs off. Then the tool gets handed to engineering with no guardrails and no guidance on what data classifications are safe to send through it. Nobody explains what the vendor’s retention policy actually means in practice. There is no plan for what happens when the model hallucinates in a customer-facing workflow.

Consider what this looks like in practice. A team connects a customer intake workflow to an approved LLM. The contract is signed, the vendor assessment is complete. What nobody checked was that the vendor’s default data retention was 30 days and model training was opt-out, not opt-in. Customer data is being used to train a commercial model, and nobody in the organization knew until an engineer read the fine print months later.

The assumption is that a signed contract means managed risk. It does not.

Passing a third party risk assessment means the vendor met a baseline at a point in time. It says nothing about whether your engineers know how to use the tool safely.

Governance does not end at procurement. That is where it starts.

The Frameworks Exist. That Is Not the Problem.

ISO 42001 gives you an AI management system framework. NIST AI RMF gives you a structure for categorizing and managing AI risk. These are solid starting points and worth using.

But a framework does not change behavior. It does not stop an engineer from sending customer data through an approved LLM because nobody told them not to. It does not make a product manager think to loop in the security team before a demo goes live.

Think about it this way. There are really two dimensions to this problem: whether a tool is approved or not, and whether guardrails exist or not. Most organizations are focused on catching unapproved tools. The quadrant nobody talks about is approved tools with no guardrails. That is where the real exposure lives, and it is almost invisible because it looks like compliance on paper.

Culture change does not come from a policy document buried in an internal wiki nobody has opened. It comes from designing governance so that doing the right thing is easier than working around it. AI risk questions built into the tools engineers already use. Intake processes that take hours, not weeks. Usage guidance that travels with the tool from day one. GRC teams that show up as partners in the build process, not auditors who arrive after the fact.

That design work is harder than writing a framework. It is also the only thing that actually works.

What to Do This Week

If you are a GRC or security leader reading this, here are five things you can act on right now without waiting for a formal program to exist:

1. Run an informal audit of AI tool usage across your engineering and product teams. Do not make it threatening. Frame it as a resource exercise. You need to know what is actually running before you can govern it.

2. Pull the data retention and model training terms from every approved LLM vendor contract you have. Most teams have never read them. What you find will surprise you.

3. Build a one-page data classification guide specifically for LLM use. What data is safe to send through an external model. What is not. Make it simple enough that an engineer reads it in two minutes and knows what to do.

4. Create a lightweight AI intake process. It does not need to be a full risk assessment. A short intake form that routes to the right reviewer is enough to create visibility and slow down the worst decisions.

5. Get into the engineering standup. Not to audit. To listen. You will learn more about how AI is actually being used in one hour than you will from a quarterly risk report.

GRC Is Old Enough to Know Better

GRC is not a new profession anymore. We have frameworks, experienced practitioners, and fifteen years of proof that reactive governance is expensive governance.

AI is not giving GRC teams the years of runway that cloud computing did. The window is shorter. The risk is already accumulating.

The question is not whether your organization is using AI without adequate governance. It almost certainly is. The question is whether GRC decides to get ahead of it now, or explains the gap later.

History is repeating itself. This time, we have no excuse for being surprised.