AI Security, Privacy, and Compliance for Business

This article provides general technical and compliance information, not legal advice. Applicable requirements depend on your jurisdiction, industry, the data involved, and your specific use case; confirm your obligations with qualified legal counsel.

AI security, privacy, and compliance are three related but distinct disciplines, and most articles on this topic only really cover one of them, usually privacy basics or prompt injection, while calling it all three. Security asks whether unauthorized people or systems can access, manipulate, or abuse an AI system. Privacy asks whether personal data is collected, used, shared, retained, and deleted appropriately. Compliance asks whether applicable legal, regulatory, and contractual requirements are being met. A fourth discipline, AI governance, asks whether model behavior, human oversight, and decision risk are actually controlled. Passing a compliance review doesn't automatically mean a system is secure, and strong security doesn't automatically mean its data processing is lawful.

Last reviewed: July 2026.

AI Doesn't Exempt You From Existing Privacy Obligations

Adding AI to a product doesn't remove the obligations that already apply to the underlying data and processing. If an AI system processes personal, health, or financial data, laws such as the GDPR or HIPAA may apply, depending on your organization, jurisdiction, the data involved, and how the system is used; neither applies uniformly to every system that happens to touch personal data. HIPAA specifically applies to covered entities and business associates handling protected health information, not to every health-adjacent app; see our healthcare/HIPAA guide and fintech guide for how that applicability question actually gets answered.

AI can also change the compliance analysis even where it doesn't remove existing obligations, raising new questions around transparency, automated decision-making, vendor relationships, data reuse, and governance that a traditional data-processing review might not have covered.

AI-Specific Regulation and Assurance Frameworks Aren't All the Same Thing

A common mistake is treating privacy law, AI-specific regulation, and voluntary assurance frameworks as interchangeable. They aren't:

An organization can hold a SOC 2 report or ISO certification and still fail to meet GDPR or HIPAA obligations. Those frameworks and assurance mechanisms can provide evidence about management systems or controls, but they don't by themselves establish compliance with a specific law. Confirm which category any claim actually falls into before treating it as a compliance guarantee.

Requirements under the EU AI Act also phase in on different dates rather than applying all at once, so applicability depends not only on a system's role and risk category but also on which provisions are in force when it's deployed or operated. Verify the current implementation timeline against the official EU text and guidance rather than assuming full applicability from a single reading.

Map the Data Before You Choose Controls

Most AI security and privacy decisions become clearer once you trace the actual data path: user input, into the application, into the AI provider or model, potentially into tools or a RAG knowledge base, into logs and storage, and finally into whatever output or action the system produces. Each hop is a place data can be exposed, retained longer than intended, or accessed by someone who shouldn't see it. Controls that aren't mapped to a specific point in that path tend to leave gaps at the points nobody thought to check.

The Main Security Risks in an AI System

Security in an AI context extends well beyond prompt injection. A useful working list, informed by categories in the OWASP Top 10 for LLM Applications:

Treat model output as untrusted input to whatever system receives it next. If an LLM generates SQL, code, URLs, tool parameters, financial values, or workflow actions, validate them against deterministic rules before execution rather than running them directly. Structured-output schemas help enforce format, but they don't prove a requested action is safe or authorized.

Prompt Injection: Direct and Indirect

Direct prompt injection is a user supplying malicious instructions straight into the system. Indirect prompt injection is often more dangerous: malicious instructions embedded in external content the AI consumes, a webpage, a document, an email, retrieved RAG content, or a tool's output, that the model treats as trustworthy context. Indirect injection matters most for AI agents and RAG systems specifically, because they routinely process content nobody manually reviewed first; see our AI agents guide.

Prompt injection isn't solved by telling a model to "ignore malicious instructions" in its system prompt. Defenses should assume the model's instructions can sometimes be manipulated and limit what a compromised model is actually allowed to access or do: least privilege, tool allowlists, permission boundaries, output validation, human approval for high-impact actions, separation of trusted and untrusted content, logging, and usage limits. Prompt injection introduces failure modes traditional application security wasn't designed to address by itself, though established principles like least privilege, trust boundaries, and defense in depth remain essential to addressing it.

Secure RAG and Knowledge-Base Access

RAG introduces its own security surface: document-level permissions, retrieval authorization, stale permissions after access changes, poisoned or incorrect documents entering the knowledge base, cross-tenant data leakage in multi-customer systems, and sensitive content sitting in vector stores that may not carry the same access controls as the source system. See our LLM integration guide for how RAG works mechanically.

The core principle: an AI layer should never become a shortcut around the authorization rules of the systems underneath it. A user should never be able to get a document out of an AI assistant that they couldn't have accessed directly through the source system. Do not rely on the model itself to enforce authorization: access checks should happen in deterministic application, retrieval, or tool layers before sensitive data is returned or an action is executed. A system prompt saying "only show documents this user can access" is not a substitute for actual authorization logic.

AI Agents Need Stronger Permission Boundaries

A chatbot answering a question badly is a limited risk. An agent that can issue refunds, modify records, send emails, or execute transactions creates a materially different class of risk, because it can act, not just respond. The model shouldn't automatically inherit the full permissions of the user, developer, or connected system it's acting on behalf of.

Worth designing in from the start: least-privilege tool access scoped to what the agent actually needs, defined action scopes and transaction limits, human approval for irreversible or high-impact actions, audit logs of what the agent did and why, credential isolation so the agent doesn't hold broader access than a task requires, and a fallback or kill switch to disable it quickly if something goes wrong.

Minimize Data Before You Rely on Filtering

The strongest starting point is avoiding sending a model data the task doesn't need in the first place. Where sensitive data is genuinely required, combine minimization with redaction or pseudonymization where appropriate, access controls, encryption, retention limits, contractual safeguards, and output controls, rather than relying on any single control alone.

Removing direct identifiers isn't automatically the same as anonymization. Pseudonymized data, where identifiers are replaced but the underlying record could still be reidentified using other available information, may still count as personal data under regulations like GDPR. True anonymization, where reidentification is no longer reasonably possible, is a meaningfully higher bar than simple redaction.

Third-Party AI Provider Due Diligence

Before sending sensitive data to a model provider, review, as applicable to your situation:

• What specific data gets sent, and whether that's the minimum necessary.
• Retention duration and deletion capability.
• Whether your data is used for model training, and how to opt out if it can be. "Not used for training" and "not retained" are different claims; verify both separately, along with whether temporary logging or abuse-monitoring retention still applies even when training use is off.
• Subprocessors the provider relies on.
• Data storage and processing locations, and cross-border transfer mechanisms where relevant. A data-residency commitment may describe where certain customer data is stored without meaning every subprocess, support operation, or transient processing activity stays confined to that region; verify the provider's exact contractual scope.
• Encryption and access controls on the provider's side.
• Incident notification terms.
• Relevant audit or security certifications, understanding what they do and don't establish.
• A signed data processing agreement, and a signed BAA specifically where HIPAA applies.
• Whether you're using enterprise or API terms versus consumer-product terms; these commonly have different data-use policies, and a consumer chat interface's terms don't automatically apply to that same provider's API product, or the reverse.
• Whether prompts and outputs are logged by the provider, and for how long.

Logging Without Creating a Second Privacy Problem

Audit logging of what data went into a model and what it returned is genuinely important for investigating incidents and disputes. It also creates a second copy of potentially sensitive data if it isn't handled carefully. Log enough to actually investigate and audit the system, but apply the same access controls, redaction where appropriate, retention limits, and encryption to those logs that you'd apply to the original data, rather than treating logs as an unmonitored side channel.

Secrets and Credentials Don't Belong in Prompts

API keys, passwords, access tokens, database credentials, and private keys shouldn't sit in system prompts, context windows, or anywhere a model handles them directly. The safer pattern: the model requests an approved tool or action, the application or tool layer retrieves the credential from a secrets-management system, and the raw credential never enters the model's context at all. Agents that authenticate through credentials embedded in the text they process are one prompt-injection incident away from exposure.

Scale Controls to the System's Actual Risk

Security, privacy, and compliance controls should scale with the sensitivity of the data, the autonomy of the system, the reversibility of its errors, how many users it affects, and the regulatory context it operates in, not apply identically to every AI feature regardless of stakes. A low-risk internal tool with no sensitive data warrants a lighter review than a customer-facing agent handling financial transactions. This is a practical planning approach, not a formal industry standard, though it's consistent with the broader direction of the NIST AI Risk Management Framework: tying controls to the context, impact, and management of AI risk rather than applying an identical checklist everywhere.

Security controls also need operational monitoring after launch, not just at design time. Permission failures, prompt-injection attempts, unusual tool use, data-access anomalies, and provider or model changes should feed into the same monitoring and incident process used to operate the AI system generally; see our MLOps guide for the equivalent risk-based framework applied to model operations.

Before Launching an AI System, Answer These Questions

1. What data enters the AI system?
2. Which of that data is actually necessary for the task?
3. Where does the data travel, and where is it stored?
4. Which vendors or subprocessors can access it?
5. Is it retained, or used for model improvement?
6. Who can access the AI system and the data it's connected to?
7. What can the model or agent actually do?
8. What happens if prompt injection succeeds?
9. Can the system expose data across different users or tenants?
10. Are outputs validated before they're used downstream or acted on?
11. What gets logged, for how long, and who can see those logs?
12. Which laws, contracts, or frameworks actually apply here?
13. Is human approval required before high-impact actions?
14. How quickly can you revoke access or disable the system?
15. Who owns incident response and regulatory escalation if something goes wrong?
16. What happens if the model or provider changes behavior without your application code changing?
17. Which actions require deterministic authorization or human approval rather than model judgment?

What Happens If Controls Fail

Security architecture reduces risk; it doesn't eliminate the need for an incident plan. Have a clear process for disabling the model or tool access quickly, revoking affected credentials, isolating affected integrations, preserving the evidence needed to investigate, identifying which data and users were actually affected, following your applicable breach or incident procedures, notifying the relevant vendor, and patching and regression-testing before turning the system back on. Notification deadlines vary by law and circumstance, so don't rely on a single universal timeline; confirm what applies to your specific situation with legal counsel.

Frequently Asked Questions

Does using AI create new compliance obligations under GDPR or HIPAA?

Using AI doesn't remove obligations that already apply to the underlying data and processing, and it can introduce additional questions around transparency, automated decision-making, and vendor relationships. Whether it creates genuinely new obligations depends on your jurisdiction, use case, and whether AI-specific regulation like the EU AI Act also applies to your situation.

Is ChatGPT or another AI provider's API used to train future models on my data?

It depends on the specific provider, product, plan, and current contract terms, and consumer chat products commonly have different data-use policies than enterprise or API products from the same company. Verify directly against the provider's current terms for the specific product you're using rather than assuming.

Is AI "GDPR compliant"?

A technology isn't generically compliant or non-compliant with GDPR; compliance depends on the specific processing, legal basis, and controls around how that technology is actually used, not the technology itself.

Does HIPAA allow the use of AI?

HIPAA doesn't categorically prohibit AI. Whether it applies, and what safeguards are required, depends on whether you're a covered entity or business associate handling protected health information, and on the vendor and contract terms involved; see our healthcare/HIPAA guide.

What is prompt injection?

An attack where malicious input, supplied directly by a user or indirectly through content the AI reads, tries to manipulate a model into ignoring its original instructions, revealing information it shouldn't, or taking an unintended action.

Does a SOC 2 report mean an AI product is legally compliant?

No. SOC 2 isn't a certification; it's an independent attestation report on controls evaluated against applicable Trust Services Criteria. It doesn't establish compliance with GDPR, HIPAA, or any specific privacy law by itself.

What's the difference between AI security and AI compliance?

Security asks whether unauthorized people or systems can access, manipulate, or abuse the AI system. Compliance asks whether applicable legal, regulatory, and contractual requirements are being met. A system can be reasonably secure while still failing a compliance requirement, and the reverse.

Is RAG more secure than fine-tuning a model?

Neither is inherently more secure; they create different risks. RAG introduces risks around retrieval authorization, document permissions, knowledge-base poisoning, and retrieval-time data exposure. Fine-tuning introduces different risks around the provenance and sensitivity of training data, memorization or unintended reproduction of training examples, poisoned training data, and how a model's behavior changes as a result. The safer architecture depends on your specific data and use case, not a general rule.

Our AI/ML development team designs security and data-handling architecture in from the start of an AI engagement, scoped to your actual data, vendors, and regulatory context.