AI compliance: The practical guide for founders and GRC teams

A late-stage enterprise deal is moving forward smoothly until a familiar question appears in the security review: “Do you use AI in your product? If yes, share your governance model and controls.” What should be a routine step becomes a bottleneck.

The product team knows AI is already embedded across workflows. The security team assumes controls exist somewhere. The compliance team starts searching for documentation that was never formally created. There is no clear owner, no structured documentation, and no evidence anyone can share with confidence.

This is the governance gap many organizations are facing today. As Sandip Wadje, Managing Director - Global Head of Emerging Technology Operational Risks & Intelligence, BNP Paribas, pointed out in an episode of Risk Grustlers, “Businesses see AI as an opportunity to move faster, while control functions need to ensure the right guardrails are in place.” 

The gap is not in adoption. It is in proof. AI compliance is not a future regulation problem. It is a current revenue problem.

What does AI compliance actually mean?

AI compliance is often described as adhering to laws, ethical principles, or responsible AI guidelines. Those definitions are accurate, but they rarely help teams actively building and shipping AI.

Start by defining the context: what the system is for, what data it touches, and where it is deployed. That context drives every downstream question.

In practice, AI compliance means your organization can answer five questions without guesswork:

1. Where are we using AI? 

You need a reliable inventory of models, AI-enabled features, third-party AI services, internal copilots, and the business processes that depend on them.

2. What data and decisions are involved? 

Know what data flows in, whether it is personal, confidential, or regulated, and whether the output influences user decisions, customer-facing content, or internal operations.

3. Who owns the risk?

 Every material AI use case needs a business owner, a technical owner, and a review path. If ownership is fuzzy, compliance fails during reviews because nobody can answer decisively.

4. What controls are in place? 

This includes access control, change management, testing, human review, vendor oversight, and incident response, plus tracking model performance and surfacing drift over time.

5. What evidence can we show? 

The final test is whether you can produce records proving those controls are real, current, and operating as intended.

If you cannot answer these five questions in a buyer security review, the deal stalls. That is why these questions sit at the heart of every AI compliance effort, and why the NIST AI Risk Management Framework starts from governance and context before it gets to controls.

Why AI compliance is impacting deals today

AI compliance is no longer a distant concern tied to future regulation. It shows up in immediate, high-impact moments across sales, audits, and internal operations. The pattern is consistent: you are not failing because of risk. You are failing because you cannot prove control.

1. Buyer due diligence is getting sharper

Security questionnaires now include AI-specific questions. Teams are asked where AI is used, how models are governed, what guardrails exist, how outputs are validated, and how risks are monitored. When answers are unclear or inconsistent, deals slow down. 

Practitioners working with enterprise buyers repeatedly see the same outcome: smaller vendors that cannot demonstrate AI governance are screened out early, before the technical evaluation begins.

See how AllCloud turned week-long security questionnaire responses into same-day answers.

2. Audits are expanding into AI systems

Most companies do not face a separate AI-specific audit first. AI shows up inside vendor risk reviews, SOC 2 gap analyses, ISO 27001 control discussions, GDPR assessments, and board-level risk conversations. 

The question is no longer whether your frameworks mention AI by name. It is whether your existing controls still hold once AI enters the workflow. Auditors now ask practical questions like “How do you validate AI-generated outputs?” and “Do you maintain version control and documentation for your models?”

3. Internal velocity is outpacing governance

AI features ship quickly, often without a matching increase in governance. Consider a team that ships an LLM-powered feature to production without a prompt change management policy. A change management policy says model updates require sign-off, but prompt changes deploy through the same pipeline as code, with no separate log. 

Months later, an auditor asks which prompt version produced a given output and when it last changed, and nobody can answer. This is exactly the data classification and access gap practitioners describe after rolling out tools like Microsoft Copilot, where systems suddenly surface information the organization never properly tracked.

4. Agentic AI raises the stakes

As AI systems move from producing outputs to taking action, the governance gap grows faster. An autonomous agent that chains tasks and triggers workflows can act before any human reviews the result. 

That changes both the speed at which a control failure propagates and the difficulty of reconstructing what happened afterward. Buyers and auditors are beginning to ask specifically about autonomous use cases, and most vendors do not yet have a clean answer.

Where AI compliance breaks down in practice

Most teams believe their AI compliance posture is reasonable until someone asks for proof. The gap is rarely about intent. It is about operationalization. The same failure modes recur regardless of company size or security program maturity. The first four are structural and process failures. The next four are information and classification failures.

Gap 1: No ownership

AI systems span engineering, data, and security teams, but ownership rarely follows. Engineering builds and deploys models, data teams manage inputs, and security oversees risk. 

Yet no single owner is accountable for end-to-end AI compliance. The people who build the model are not the people who manage access controls, who are not the people who handle data privacy. Without an explicit ownership model, every compliance question triggers a cross-functional scramble.

AI adoption has scaled faster than accountability structures. According to McKinsey’s State of AI 2025 report, 88% of organizations now use AI in at least one business function. The responsibility for governing it frequently lands on security and GRC teams 

Gap 2: Controls are not mapped to the AI lifecycle

Even when controls exist, usable evidence often does not. A change management policy says model updates require sign-off, but prompt changes deploy through the same pipeline as code, with no separate log. 

There are no structured records of model decisions, no audit trail of prompt or model changes, no human-review checkpoints, no rollback procedures, and no centralized record of how outputs are validated.

Gap 3: Existing frameworks are not extended to cover AI

Most organizations have invested heavily in SOC 2, ISO 27001, or GDPR, and assume these frameworks already cover AI. In practice, they cover the infrastructure AI runs on, not the AI itself. 

Model versioning, prompt change management, output validation, and human review checkpoints are not addressed by existing controls unless teams explicitly extend them. The gap is not in the frameworks. It is in the failure to map AI-specific risks to controls that already exist.

Gap 4: Compliance does not fit engineering workflows

Engineering teams think in pipelines, deployments, and access controls. Compliance teams think in policies and documentation. The result is a disconnect: controls exist on paper but are not embedded into how systems run, so AI compliance feels like an external layer.

In March 2023, OpenAI temporarily took ChatGPT offline after a bug in an open-source library exposed some users’ chat history titles and, for a small subset of ChatGPT Plus subscribers, payment-related information, including the last four digits of a credit card and billing address. The root cause was a technical bug, but it exposed a deeper pattern: systems operating at scale while controls around data isolation lagged behind product behavior.

Gap 5: No AI inventory

You cannot govern what you cannot see. Most organizations cannot answer basic questions about where AI is running. Which models are in production. Which third-party services are embedded. Which internal copilots individual teams quietly deployed last quarter.

Without a current inventory, every other compliance effort is built on guesswork. When a customer asks "Where do you use AI?" the answer should not require a cross-functional investigation.

Gap 6: No data lineage for training and inference

AI systems are only as trustworthy as the data flowing through them. Yet most organizations cannot answer basic questions about where training data came from, how it was collected, whether it contains personal or regulated information, or how inference data is handled in production. 

This is a real exposure. Employees routinely input privacy data subject to regulatory or contractual obligations into AI tools, and that data can resurface to other users. The regulatory diagnostic is simple: where did this data come from, and were we allowed to use it this way?

Gap 7: AI use cases are not classified by risk

Not every AI use case carries the same risk. A copy assistant for internal marketing is fundamentally different from a model influencing credit decisions or customer-facing recommendations. 

Without risk classification, everything gets treated the same, which means high-stakes use cases get the same attention as a marketing copy assistant. Risk classification is what determines which controls, reviews, and evidence requirements actually apply.

Gap 8: Manual processes scale badly, and shadow AI fills the gap

In the absence of integrated systems, teams fall back on spreadsheets, scattered documents, and approvals over Slack. This creates friction and makes AI compliance hard to scale. It is also where shadow AI emerges: when controls are not enforced through systems, employees adopt AI tools independently, outside approved workflows, and without visibility.

Reco’s 2025 State of Shadow AI Report found that 71% of knowledge workers use AI tools without IT approval, highlighting how quickly AI usage can move beyond formal governance processes.

Security teams consistently report discovering unsanctioned AI tools only after they are already embedded in workflows, by which point unwinding them requires more disruption than the tools originally caused.

Scrut Teammates is built to close exactly this gap, automating security questionnaire responses, assessing vendor risk, and verifying audit evidence without manual digging.

The minimal AI compliance system you actually need

AI compliance can feel overwhelming. In practice, most organizations do not fail because they lack controls. They fail because they cannot demonstrate what already exists in a structured, verifiable way. You do not need a full AI governance program to start. You need the minimum system that unblocks deals and holds up during security reviews.

The goal is not a perfect system. It is a defensible one. Security is rarely the problem. Evidence is.

As Sandip Wadje put it: “Do not get controls for the sake of controls. They are really asking: what is your control, do you follow it, and where is the evidence?”

Layer 1: Inventory and classification

Identify where AI is used: internally developed models, third-party tools, and specific use cases such as customer support, recommendations, or internal automation. For each, capture business purpose, system owner, technical owner, data categories, user impact, vendor dependencies, and risk tier. A copy assistant for internal marketing is not the same as a feature influencing customer decisions, and the depth of control should reflect that.

As Walter Haydock, Founder of StackAware, has noted, “If your policy is ‘don't use it,’ employees will use it anyway, outside your visibility. Inventory is what makes a workable policy possible.”

Layer 2: Ownership and approvals

Once inventory exists, assign clear ownership. Every system needs two humans attached to it: one who owns operation, one who owns oversight. Define who approves a new use case and who signs off on material changes. A lightweight RACI per system is enough. What matters is that neither name is blank.

Without ownership, governance fragments and responses to customer or auditor queries become inconsistent.

Layer 3: Controls

Controls should map to the use case tier. For a low-risk internal tool, such as a marketing copy assistant, basic access control and versioning may be sufficient. 

For a high-risk customer-facing model, you add human review before outputs reach users, documented testing before release, and explicit constraints on what data the model can touch. 

If you use a third-party model, your controls should cover the integration and data flow, not the vendor's marketing claims.

Layer 4: Monitoring and review

Monitoring provides visibility into how AI systems behave over time. At a minimum, log inputs and outputs so decisions can be traced. Track model performance and introduce basic anomaly detection to catch drift or unexpected behavior. 

For higher-risk use cases, review output quality and safety on a schedule rather than waiting for a customer complaint.

Layer 5: Evidence and response readiness

Your evidence package should be fast to assemble. System logs, approval records, design notes, testing results, policy references, vendor documentation, and exception decisions should be easy to retrieve and explain.

If it takes two weeks and three teams to answer a buyer’s question, the system is too manual.

Close the evidence gap with automation: See how Athenium gained faster clarity in their SOC 2 journey using Scrut Teammates.

How AI compliance actually works in practice

AI compliance becomes manageable when treated as a system rather than a collection of disconnected activities. At its core, it follows a simple but powerful flow: Controls, then Signals, then Evidence, then Decisions.

Without this structure, teams fall into reactive patterns, adding tools without alignment. As Nicholas Muy, CISO at Scrut Automation, framed it on an episode of Risk Gruslters: “Compliance should not be a random activity. It needs structure, so every control ties to real system behavior, every signal produces usable evidence, and every decision rests on verifiable data.”

Controls define expected behavior: who can modify a model, what data the model cannot touch, and what monitoring runs before any output reaches a user. They answer one question: what should happen.

Signals are the data systems generate during operation, such as logs of inputs and outputs, access activity, configuration changes, and performance metrics. Signals show what is actually happening.

Evidence is what you get when signals are structured and mapped to controls. Raw logs become organized, audit-ready records that show whether controls are working or not.

Decisions come before any audit. Designated owners across security, GRC, privacy, and AI systems assess what the evidence shows, whether controls are working, whether exceptions have surfaced, and what needs remediation before anything is escalated. 

This human-in-the-loop step is not a formality. It is what separates a defensible compliance posture from one that simply looks good on paper. When this review layer functions, audits become faster, approvals become easier, and risk decisions rest on verified evidence rather than assumptions.

This flow matters even more for agentic AI. When a system produces an output, a human can review it before it reaches a decision. When an autonomous agent takes an action, the Signals layer often becomes the only place a control failure surfaces, because the system may act before any human is in the loop. 

The practical implication for autonomous use cases is that evidence collection must happen in real time, not retrospectively.

Agentic AI and what it means for your compliance program

Agentic AI refers to systems that take autonomous actions, chain tasks, and make decisions without requiring a human trigger at each step. 

That autonomy changes the compliance problem in a specific way: the Signals layer becomes critical, because the system acts before a human reviews the output. Evidence has to be collected in real time, not reconstructed after the fact.

Three control requirements deserve particular attention for agentic systems:

1. Action logging

Every autonomous action the agent takes must be logged with its inputs, outputs, and context. Without this, a post-incident investigation has no starting point, and you are left trying to reconstruct what an autonomous system did from memory.

2. Scope boundaries

The agent must be constrained to a defined set of permissible actions. Broad access to APIs or databases increases risk because agents may have more access than the workflow requires. The goal is to limit permissions to exactly what the task needs, nothing more.

3. Rollback and override

There must be a defined human escalation path when the agent encounters an out-of-scope decision. As Iftach Ian Amit, CEO of Gomboc.ai,  pointed out in our webinar, “The question of who is responsible for an autonomous action becomes unavoidable the moment the system executes rather than recommends.”

The EU AI Act's high-risk category language is particularly relevant here. If an agent influences hiring, credit, or customer-facing decisions, high-risk obligations apply regardless of how autonomous the workflow is. If you are evaluating these use cases, our webinar on the rise of agentic GRC walks through how this plays out operationally.

AI compliance regulations and frameworks that actually matter

AI compliance is often presented as a long list of laws. In practice, most organizations do not need to track everything at once. What matters is understanding which regulations affect your product, your customers, and your ability to close deals.

EU AI Act

The EU AI Act is the most comprehensive AI regulatory framework today. It follows a risk-based model, classifying systems as minimal, limited, or high risk. If your system falls into a higher-risk category, you are expected to demonstrate controls around data quality, transparency, human oversight, and monitoring. 

It applies if you serve EU customers, even if you are not based in Europe. Practitioners tracking enforcement note that the EU is furthest ahead in actually enacting and enforcing AI regulation. Enforcement timelines are phased: prohibited-use provisions applied in August 2024, with high-risk obligations taking effect in August 2026. You can map your obligations against EU AI Act compliance requirements as part of your existing program.

U.S. landscape

The United States has no single unified AI law. Expectations evolve through frameworks and enforcement:

• NIST AI Risk Management Framework (AI RMF): A widely referenced standard for governance, risk measurement, and continuous monitoring of AI systems.

• NIST Secure Software Development Framework (SSDF): While not AI-specific, the SSDF governs secure software development practices that apply directly to model deployment and the AI development lifecycle.

• Federal Trade Commission (FTC): Enforces consumer protection laws in the AI context, shaping expectations around fairness, transparency, and accountability.

• HIPAA: Applies to AI systems that process protected health information.

• Financial regulations (SEC, FINRA, CFPB): Sector-specific obligations, including model risk management and explainability requirements.

• State-level laws: California, Colorado, and Illinois have introduced or enacted AI-specific legislation that may apply depending on where you operate.

At the federal level, the current administration's posture favors light-touch regulation aimed at maintaining American AI leadership, directing agencies through instruments such as OMB Memorandum M-25-21 (OMB, February 2025). The practical effect for enterprise readers is a widening gap between light federal guidance and more prescriptive state-level legislation, which means U.S. regulatory risk increasingly depends on which states you operate in.

Global standards

• ISO/IEC 42001: The first international standard specifically for AI management systems. It helps organizations establish governance, define accountability, and demonstrate responsible AI across the lifecycle.

• ISO/IEC 23894: Dedicated guidance on AI risk management.

• ISO/IEC 27001: Supports the information security controls underpinning AI systems.

• ISO/IEC 27701: Extends ISO 27001 into privacy management for personal data used in AI systems.

• ISO/IEC 42005: Guidance on AI system impact assessments. This standard helps organizations evaluate the broader organizational and societal effects of deploying AI, which is relevant when assessing high-risk use cases before launch.

Beyond Europe and the U.S., organizations with any Asia-Pacific presence should note China's Interim Measures for the Management of Generative AI Services (Cyberspace Administration of China, effective 15 August 2023), which place obligations on providers of generative AI services to the public in China, including training data and content requirements. Identifying which statutory requirements apply per operating geography is the practical first step before mapping controls.

How AI compliance fits into SOC 2, ISO 27001, and GDPR

The short answer to SOC 2 and ISO 27001: they cover the infrastructure on which AI runs, not the AI itself.

These frameworks, along with GDPR, were not designed with AI systems in mind. They address data processing, access controls, and the infrastructure underneath, not what makes AI uniquely risky: how models are trained, how outputs are validated, how bias is detected, how behavior changes over time, and how AI decisions can be explained and challenged. 

This is the gap AI-specific frameworks like ISO 42001 and the EU AI Act are designed to address.

What existing frameworks do not cover:

• Risk classification of AI use cases by impact and likelihood

• Model versioning, drift detection, and performance monitoring

• Explainability and transparency of AI-generated decisions

• Human oversight requirements for high-risk AI outputs

• Bias identification and mitigation across the model lifecycle

• Data lineage for training and inference data

ISO 42001 fills the governance gap with a certifiable management system built for AI. It gives organizations a structured way to document use cases, assign ownership, implement controls, and produce evidence, none of which SOC 2 or ISO 27001 require at the AI level. 

The EU AI Act goes further by creating legal obligations based on risk. If your system is high-risk, influencing hiring, credit, healthcare, or law enforcement, you must demonstrate conformity with specific technical and governance requirements regardless of other certifications.

The practical takeaway: SOC 2 and ISO 27001 get you part of the way there. They provide the security and operational foundation. But if you deploy AI in customer-facing or high-stakes contexts, or sell to enterprise buyers asking AI-specific governance questions, you need to go further. 

You can extend your existing SOC 2 control mapping and ISO 27001 access management controls to cover AI. ISO 42001 gives you the structure. The EU AI Act sets the legal floor.

Why explainability unlocks enterprise deals

In an enterprise security review, the question often arrives in plain language: "How does your model arrive at this output?" 

If you cannot answer clearly, the deal hesitates. Explainability in AI compliance means being able to explain how your system produces its outputs. It is not about exposing algorithms. It is about making decisions understandable to customers, auditors, and internal stakeholders.

Consider a buyer's security team asking how a recommendation model reaches its output. A defensible answer is not a description of the algorithm. It is a walk through the documentation that records how the model was trained and what data it used, the audit trail that traces a specific output back to the model version that produced it, and the human review checkpoint that captured who reviewed the recommendation and when. 

That is the difference between a black box and a system you can stand behind in a procurement conversation.

As Iftach Ian Amit, CEO of Gomboc.ai, stated in our webinar, the question of what responsibility you carry for an AI-generated result is unavoidable once that output is used in a decision. 

The moment an output influences a real-world action, someone owns the consequence, and explainability is how you demonstrate that the output was guided by defined logic and a reviewed process rather than chance.

This connects directly to the EU AI Act. For high-risk systems, the Act sets transparency and human-oversight requirements that make explainability a regulatory obligation, not just a sales advantage. 

Getting there does not require complex tooling. It requires clear documentation of how models are trained and used, traceability of inputs and outputs so decisions can be followed to their source, and records of model and prompt changes so outputs can be explained over time.

Moving from AI risk to AI readiness

AI compliance is already shaping how customers evaluate your product and how auditors assess your controls. You are no longer asked whether you use AI. You are asked to prove it is governed, monitored, and controlled. 

Many teams hit friction here, not because they lack capability, but because they lack structured evidence.

If you have read this far, you do not need more convincing. You need a starting point. Here are four things you can do this week:

1. Run a 30-minute AI inventory session with your engineering leads

Ask one question: "Where are we using AI, built, bought, or embedded, that touches customer data or influences decisions?" Write down every answer. This list is your scope. Most teams discover two to three systems they did not know about.

2. Pick your highest-risk AI system and answer five questions about it. 

Who owns it? Who can modify it? What data does it access? Are changes logged? Can you produce evidence of any of this?

3. Pull your last three security questionnaires and search for "AI." 

Look at the questions and the answers you gave. Were they consistent? Were they backed by evidence?

4. Schedule a conversation with your engineering lead about agentic AI deployments. 

Ask whether any autonomous agents are in production or planned, what actions they can take, and whether those actions are logged and scoped.

‍

For founders and GRC managers: Apply for a Live Compliance Review to get real-time feedback on your AI compliance gaps before a buyer or auditor does.

For teams already using Scrut: Take a Scrut Teammates tour to see how Scrut operationalizes AI compliance with continuous monitoring, control mapping, and audit-ready evidence.

‍

‍