Blog

Practical Steps to Control AI Access to Regulated Data

Written by StratoKey | Jun 22, 2026 12:00:00 AM

AI tools are already inside most regulated environments. The compliance programs that govern those environments have not caught up.

That is the gap. Your existing frameworks, HIPAA, CMMC, ITAR, GDPR etc., apply to systems that touch regulated data. AI tools are systems. They inherit the same obligations. Most organizations have built access controls, encryption, and audit logging for human users. Very few have applied the same rigor to the AI tools accessing the same data.

This is not a future risk. It is a current one. If an AI tool in your environment can reach ePHI, CUI, or ITAR-controlled technical data today, your compliance program has a gap today.

What Type of AI Do You Have and What Is the Risk

Before you can close the gap, you need to know what you are dealing with. Not all AI carries the same compliance risk.

Copilots and assistants such as Microsoft 365 Copilot and Google Gemini for Workspace are AI agents embedded in productivity tools. A human initiates each interaction. The risk is scope: they can access whatever the logged-in user can access, and most organizations have not mapped what regulated data those users can reach.

SaaS AI features built into platforms like Salesforce, ServiceNow, and Workday process data already in those systems. Regulated data that was in scope for the platform is now also in scope for the AI feature, often without anyone explicitly making that decision.

Third-party AI models and APIs such as OpenAI and Google Gemini API receive data in prompts. Whatever goes into a prompt leaves your environment. If that includes regulated data, the vendor's data handling terms and authorization status determine whether you have a compliance problem.

Agentic AI is the highest-risk category. Unlike a copilot where a human initiates every interaction, agentic AI operates autonomously across multiple steps, calling APIs and executing sequences of actions without human approval at each point. It acts, then reports. It can access, process, and transmit regulated data across multiple systems before anyone reviews what it did. A misconfigured permission scope compounds across every step it takes.

What Compliance Frameworks Say About AI

AI has rolled out across industries and use cases much faster than compliance frameworks have kept up. The EU AI Act is currently one of the only comprehensive, enacted AI laws globally. Every other jurisdiction applies existing technology-neutral law to AI rather than AI-specific legislation, and most of the frameworks your organization is likely operating under fall into that category.

Conceptually, AI is another system. If it touches regulated data, it inherits the same controls that apply to any other system that does. Much in the same way that sending regulated data to a SaaS application extends your compliance boundary, connecting an AI tool to regulated data brings that tool into scope.

The table below maps the major compliance frameworks relevant to defense, government, and healthcare organizations, what each one actually says about AI in its base text, and where gaps are being addressed by supplementary guidance, proposed rulemaking, or not at all.


Framework Is AI explicitly mentioned in the base text? How AI is handled 
CMMC / NIST SP 800-171 Rev 2 No Controls apply to any system processing CUI, this includes AI tools. Whether an AI system is in scope is a scoping determination. FY2026 The NDAA (at Section 1513) directs DoD to build an AI-specific extension of CMMC; DoD must report progress to Congress by June 2026. No implementation timeline for the AI controls has been set.
DFARS No Requires adequate security for covered defense information on contractor systems. Any contractor system processing CDI, including AI tools, must meet the 800-171 control set. 

NDAA FY2026 Section 1513 directs DoD to build an AI-specific security framework and once finalized, that framework is expected to flow down to contractors through the existing DFARS contractual mechanism.

ITAR  No ITAR and EAR risk for AI comes from existing "technical data" definitions, not AI-specific provisions. Feeding ITAR-controlled data into any AI system accessible to foreign nationals is a potential unauthorized export. No AI-specific guidance published. 
NIST SP 800-53 Rev 5 Control Overlays, not base text. General security and privacy control catalog. NIST published COSAiS (2025) as a separate overlay mapping existing controls to AI use cases. NIST AI RMF 1.0 (2023) is a companion AI risk framework. Neither is part of the base text.
CPCSC /  NIST SP 800-171 Rev 3 No Controls apply to any system handling protected defence information, including AI tools, by scoping determination. Canada may accept valid CMMC certification on a case-by-case basis. 
HIPAA Security Rule No Applies to any system handling ePHI. A Business Associate Agreement (BAA) is required for any business associate handling ePHI regardless of whether AI is involved, this includes AI providers. Proposed NPRM (Dec 2024) would mandate encryption and data flow mapping
NIS2 Recital 51 only Non-binding recital only. Article 21 is silent on AI. ENISA guidance (2025) addresses AI under ICT risk management. EU AI Act applies separately. 
EU AI Act Yes, entirely.  In force August 2024. Bans on unacceptable-risk AI applied February 2025. General-purpose AI rules applied August 2025. High-risk AI system obligations apply August 2026. 
GDPR No Technology-neutral. EDPB Opinion 28/2024 addresses AI models directly. Article 35 requires DPIAs for high-risk AI processing, requires DPIAs for processing likely to result in high risk, including systematic automated processing and profiling. Regulators apply this to AI systems by interpretation. AI is not mentioned in the text. ICO AI guidance is the most practical application. 

Practical Steps to Control AI Access to Regulated Data

Step 1: Inventory Every AI Touchpoint

If you do not know what AI systems can access regulated data, you cannot control it. Map every AI tool, feature, and integration connected to systems holding regulated data, including tools individuals have connected without IT approval.

The compliance consequence of skipping this: You cannot document your system boundary for a CMMC assessment or HIPAA risk analysis if AI tools with access to regulated data are not in it.

Step 2: Classify the Data Each AI System Can Reach and Identify Compliance Scope

Not every AI touchpoint is a compliance problem. The problem is regulated data in scope. Identify which AI systems can reach CUI, ePHI, ITAR-controlled technical data, or other protected information. That is your priority list for the steps below.

The compliance consequence of skipping this: You cannot demonstrate minimum necessary access under HIPAA or least privilege under NIST 800-171 if you have not established what access exists.

Step 3: Remove Regulated Data from AI Scope Where You Can

Tokenize or encrypt sensitive fields before they reach an AI system or any system the AI can access. The AI works with a substitute value. The original data never leaves your controlled environment. This shrinks your compliance scope and reduces the consequence of a vendor breach.

The compliance consequence of skipping this: Regulated data in a non-FedRAMP AI vendor's environment is a direct CMMC finding. Plaintext ePHI at an AI vendor without a BAA is a HIPAA violation.

Step 4: Enforce Least Privilege on Every AI Integration

Each AI agent should have an authenticated identity with access scoped to what it actually needs for its specific function. Session-level credentials that grant broad access are not sufficient. For agentic AI this is critical: an autonomous system with overly broad permissions can traverse multiple systems and reach data well beyond its intended scope before anyone notices.

The compliance consequence of skipping this: broad API credentials shared across AI integrations cannot satisfy NIST 800-171 control 3.1.1 or HIPAA's minimum necessary standard.

Step 5: Protect Data in Transit at the API Layer

Data moves between your systems and AI tools through APIs. Sensitive fields in those payloads should be tokenized or redacted in real time. Encryption must meet the standard your framework requires, not just generic TLS. Prompt injection, where malicious input attempts to manipulate an AI system into unauthorized data access, is an active threat that API-layer controls can mitigate.

The compliance consequence of skipping this: Unprotected API payloads containing CUI fail NIST 800-171 control 3.13.8. Unencrypted ePHI in transit fails HIPAA 45 CFR 164.312(e).

Step 6: Log AI Access at the Operation Level

Infrastructure logs do not tell you what an AI system accessed, when, or on whose authority. You need operation-level granular logs capturing the identity of the AI system, the authorizing user, the data categories accessed etc. Logs must be stored outside the AI vendor's environment.

For agentic AI, operation-level logging is the only way to reconstruct what the system did, in what order, and what data it touched. 

The compliance consequence of skipping this: You cannot produce the audit evidence an assessor or investigator will request. For CMMC, missing audit logs are a direct finding against controls 3.3.1 and 3.3.2.

Step 7: Keep an Eye on the Evolving Regulatory Landscape 

The compliance picture for AI is changing. Most frameworks today consider AI through the lens of their existing technology-neutral obligations. That is shifting: CMMC AI-specific controls are in development, the EU AI Act reaches full application in August 2026, and the HIPAA Security Rule NPRM is pending finalization.

Controls you implement today are likely to become the baseline for AI-specific requirements as they land. Assign someone to track regulatory updates from NIST, HHS OCR, DoW, and the European AI Office. Review your AI inventory (step 1) when new guidance drops.

How StratoKey Help With AI Security

 

  How StratoKey helps
1. Remove regulated data from AI scope The CDP Gateway tokenizes or encrypts regulated data before it reaches any AI system. The AI receives a substitute value. Regulated data never leaves your environment in readable form.
2. Enforce least privilege The Identity Gateway authenticates each AI agent, links it to an authorizing user, and enforces attribute-based access controls scoped to what that agent actually needs. Controls operate independently of the AI model or SaaS vendor.
3. Protect data at the API layer The API Gateway inspects payloads in real time, applies tokenization, encryption or redaction to sensitive fields and validates inputs to mitigate prompt injection.
4. Log AI access at the operation level The Cloud Data Protection Platform across both the CDP, Identity and API Gateway produces operation-level audit logs. Logs are stored outside the AI vendor's environment.

Ready to close the gap on AI access to regulated data?

StratoKey's cloud data protection platform gives you the data protection, identity controls, and API-layer protection to bring AI systems into your compliance posture without slowing them down.