Skip to content
Contact Us

AI Compliance Explained: HIPAA, SOC 2, GDPR & EU AI Act

Contact Us

Author

Harshit Kumar

August 25, 2026

Introduction

There is a funny thing happening with AI in the workplace. A tool that once needed a meeting, a security review and a long discussion with IT can now be tried by an employee in a few minutes. That convenience is one of the reasons AI has spread so quickly. It is also one of the reasons compliance teams are paying attention. 

The question is no longer whether people will use AI. In many organizations, they already are. The better question is what happens to company and customer information when they do. 

This is where AI Compliance becomes useful. It is less about finding a magic certificate and more about understanding the complete journey of an AI request. What information goes into the system? Who provides the model? Where is the information processed? What comes back? Who can see it? And what happens to the information afterward? 

Those questions become more important when the information is sensitive or the AI output can influence a person’s life. A healthcare assistant, for example, raises very different concerns from a tool that turns meeting notes into a to-do list. 

Four names, four different jobs

HIPAA, SOC 2, GDPR and the EU AI Act are often placed in the same article because businesses may have to think about several of them at once. They should not, however, be treated as interchangeable. 

HIPAA is relevant to protected health information and the organizations and activities covered by the law. SOC 2 is an assurance framework around controls at service organizations. GDPR deals with personal-data processing and individual rights. The EU AI Act is an AI-specific regulation that uses a risk-based approach. 

The easiest mistake to make is to ask, ‘Are we compliant with AI?’ before asking, ‘What exactly are we doing with AI?’ The second question has to come first. A company cannot sensibly decide which controls it needs until it understands the actual use case. 

That is also why AI compliance should be discussed during design. Waiting until a feature is finished can turn a simple change in the data flow into an expensive redesign. 

HIPAA Compliance for AI: be careful with the input

Healthcare is probably the clearest example of why the data going into an AI system deserves as much attention as the answer coming out of it. 

Imagine a clinic introducing a tool that turns clinical notes into a short summary for a doctor. On the surface, it sounds straightforward. Behind the scenes, the request could contain a patient’s name, history, medications, test results and other information that identifies the person. 

If PHI is involved, the organization needs to understand how that information is being used and disclosed. One useful HIPAA concept here is the minimum necessary standard. HHS says covered entities generally should take reasonable steps to limit PHI use, disclosure and requests to what is needed for the intended purpose. citeturn0search1turn0search5 

For an AI project, that raises a very practical question: does the model really need the whole record? Sometimes it will. Sometimes it will not. The answer should come from the job the system is supposed to perform. 

De-identification may also be an option for some uses. HHS describes two HIPAA methods, Expert Determination and Safe Harbor. Properly de-identified information is treated differently from PHI under the Privacy Rule, although de-identification does not mean the risk of identification becomes literally zero. citeturn0search0 

Before a healthcare AI tool goes live

  • Identify whether PHI is entering the workflow. 
  • Work out which fields the task actually needs. 
  • Review the AI provider’s role, contract and safeguards. 
  • Check what is stored in prompts, uploads, outputs and logs. 
  • Limit access to the people who need the feature. 
  • Consider whether de-identification is suitable for the use case. 

The important point is easy to miss: buying an AI product does not move responsibility for the data to the vendor. The organization using the product still needs to understand the arrangement and the information being handled. 

SOC 2: where the controls come in

SOC 2 is a different conversation. It is not an AI law. It is a framework used to evaluate controls against the applicable Trust Services Criteria, including security, availability, processing integrity, confidentiality and privacy. 

For a SaaS business, adding an AI feature does not create a completely separate universe of controls. The new feature becomes another part of the company’s technology environment. 

That means familiar questions still matter. Who can access the feature? How are changes approved? How is the AI provider reviewed? What happens if the provider has an incident? Can the company show evidence that its controls are actually operating? 

That last question is particularly important in an assurance exercise. Having a policy on paper is one thing. Being able to show access reviews, approvals, logs or vendor assessments is another. 

GDPR AI Compliance: start with the purpose

GDPR AI Compliance becomes much easier to discuss when the conversation starts with purpose rather than the model. 

A team may want to feed more information into an AI system because the extra context improves the response. That can make sense technically. From a privacy perspective, however, the next question is whether all of that information is actually needed. 

The GDPR includes principles such as lawfulness, fairness and transparency, purpose limitation and data minimization. Those ideas apply whether the processing is done by a person, a traditional application or an AI system. 

Consider a customer-service assistant that sorts complaints into categories. It may need the complaint itself and a product name. If the integration also sends the customer’s complete account history, the company should have a reason for doing so. Convenience is not automatically a privacy justification. 

The same thought process should be applied to the less obvious parts of an AI system. A prompt can contain personal information. An uploaded document can contain it. A generated answer can repeat it. Logs can preserve it long after the original request has finished. 

When an AI output affects a person

Things get more serious when AI is used to support decisions about people. 

Article 22 of the GDPR deals with certain decisions based solely on automated processing, including profiling, when the decision has legal or similarly significant effects. Whether it applies to a particular system depends on the facts of that system and the decision-making process. 

Recruitment is a useful example. Suppose software reviews resumes and puts candidates into a recommended order. A recruiter may still make the final decision, but that does not automatically answer every compliance question. The company should understand what the system considered, how much weight the recommendation carries, and whether the person reviewing the result can genuinely challenge it. 

A few questions worth asking

  • What personal information is actually being sent to the AI service? 
  • Why is that information needed? 
  • What is the legal basis for the processing? 
  • How long are prompts, files, results and logs retained? 
  • Is the system profiling people or supporting an important decision? 
  • Can the organization explain the process to the people affected? 

There is no useful shortcut here. The right answer comes from looking at the actual workflow, not from putting a ‘GDPR compliant’ label on an AI product. 

Where the EU AI Act comes in

The EU AI Act adds a layer that is specifically about AI. Its risk-based structure means that the obligations depend on what an AI system is being used for and the role it plays. 

For a business, the first job is therefore classification. A writing assistant used internally is not the same thing as an AI system used in a sensitive employment, healthcare, biometric or other high-impact setting. 

The European Commission’s implementation information also shows that the Act is being phased in rather than switched on all at once. Some provisions have applied since 2025, with further obligations taking effect at later dates. That makes keeping track of the implementation timeline part of the compliance work. citeturn0search0 

The practical lesson is simple: describe the system clearly before trying to decide what rules apply. Once the use, users, data and possible impact are clear, the compliance discussion becomes much less abstract. 

AI Regulations tend to overlap

In a real company, regulations rarely arrive in neat boxes. A software provider might have European customers, process personal information, serve healthcare organizations and maintain a SOC 2 program at the same time. One AI feature can therefore sit underneath several sets of expectations. 

The answer does not have to be four separate compliance projects. In fact, that can make things worse. A shared AI review process is usually easier to manage. 

For example, a vendor review can cover security, privacy, retention, subprocessors, model-training practices, regional processing, deletion and incident notification. Different teams may use the same information for different purposes. 

A workable AI review

Start with a list

Make an inventory of the AI tools the company is using. Include customer-facing features, employee tools, development assistants, analytics and third-party APIs. The list does not need to be complicated. Owner, purpose, provider and data type are a good starting point. 

Then look at the data

Classify what the tool receives. Public content is one thing. Customer records, employee information, financial details, PHI and confidential material deserve more attention. This is also where a company can find surprisingly simple fixes, such as removing a field that the model never needed. 

Ask what happens if the answer is wrong

This question is easy to skip. A bad summary of a meeting is annoying. A bad recommendation about a job applicant, a financial decision, healthcare information or access to a service is a different matter. 

The impact of the output should therefore be part of the risk assessment, not just the sensitivity of the input. 

Do not treat vendor documentation as the whole review

A provider may have strong security documentation and useful compliance certifications. Those are valuable, but the customer’s configuration and use still matter. Check the contract, retention settings, training terms, subprocessors, deletion process and incident commitments. 

Decide what humans are supposed to do

Human review sounds reassuring until we ask what the reviewer actually does. If a person receives an AI recommendation and approves it every time, the human may be acting more like a button than a safeguard. 

For higher-impact use cases, the reviewer should have enough context to question the output and enough authority to reject it. 

Review it again later

An AI system is not necessarily finished just because it has gone live. A model can change. A provider can change its terms. A new integration can add another source of data. Employees can discover a new use for an existing tool. 

A lightweight review after significant changes is often much easier than rebuilding the compliance picture after an incident. 

Common mistakes

  • Assuming compliance is only the legal team’s responsibility. 
  • Assuming a vendor’s certification covers every possible use of its product. 
  • Letting employees paste confidential information into public AI tools. 
  • Leaving data mapping until after development is complete. 
  • Calling a process ‘human reviewed’ without checking what the reviewer actually does. 
  • Never revisiting the assessment after the model, vendor or business purpose changes.

What good AI governance looks like in practice

Good AI governance does not have to be a giant policy document. If the process is too complicated, people will work around it. 

A smaller set of questions can be much more useful. Before a new AI feature is approved, someone should know what it does, what data it needs, who owns it, who can access it, which vendors are involved and what could happen if it behaves badly. 

The process should also have a clear owner. Engineering should not have to guess what the privacy team needs. Privacy should not have to reverse-engineer a product after it has already been built. Security should know which third-party services are involved. Product teams should understand what claims they can make about the feature. 

In other words, AI compliance works better when it becomes part of normal project work. 

HIPAA, SOC 2, GDPR and the EU AI Act a quick comparison

HIPAA is mainly concerned with protected health information and the organizations and activities covered by the law. In an AI project, the focus is on how PHI is used, disclosed and protected. 

SOC 2 is about controls and assurance. For an AI-enabled SaaS product, access, change management, vendor management, monitoring, incident response and evidence all remain important. 

GDPR focuses on personal-data processing and the rights of individuals. With AI, that means paying attention to why data is used, what information is necessary, how people are informed, and whether automated processing has significant effects. 

The EU AI Act is focused specifically on AI systems and follows a risk-based approach. The obligations are not identical for every AI application, which is why understanding the use case matters so much. 

Why this is a business issue

Compliance can sound like paperwork until a project runs into a problem. Then the value of having asked the questions early becomes obvious. 

Suppose a company discovers after launch that an AI provider retains customer prompts in a way the product team did not expect. Fixing that might mean changing the integration, reviewing contracts, notifying customers or moving data. If the retention question had been asked during vendor selection, the problem might have taken one meeting to avoid. 

The same is true of access. Finding out during a review that dozens of employees can see sensitive AI logs is much less comfortable than designing the permissions correctly before launch. 

This is why AI compliance should not be presented as the enemy of innovation. Good controls can actually make it easier for a company to approve useful AI projects because everyone understands what is being accepted. 

Final Thoughts

AI is moving quickly. Businesses are going to keep experimenting with it, and many of those experiments will turn into real products and internal processes. 

The sensible response is not to treat every AI project as a legal emergency. It is to develop a habit of asking the right questions early. 

What data are we sending? Why do we need it? Who gets it? What can the system do? What happens when it is wrong? Who can challenge the result? Which rules and customer commitments apply? 

Those questions will not solve every compliance problem, but they give a team somewhere useful to start. 

That is ultimately what AI Compliance should provide: a practical way for a business to keep using new technology while staying responsible for the information it handles and the decisions it influences. 

Author

Harshit Kumar

Recent Posts

FAQ

FAQs

Yes. AI compliance may be required when an organization uses AI to process personal, health, financial, employee, or other sensitive information, or when AI is used in areas covered by specific regulations. The exact requirements depend on the AI system, the data it handles, where the business operates, and how the AI is used. Companies should review compliance requirements before deploying an AI tool rather than assuming that every AI system follows the same rules. 

The main regulations and frameworks businesses commonly need to consider include HIPAA, GDPR, SOC 2, and the EU AI Act. Each one has a different purpose. HIPAA focuses on protected health information, GDPR covers personal-data processing and individual rights, SOC 2 focuses on controls and assurance, and the EU AI Act regulates AI systems using a risk-based approach. A business may need to follow more than one depending on its industry, location, customers, data, and AI use case. 

Yes, GDPR can apply when an AI system processes personal data that falls within the regulation’s scope. GDPR does not stop applying simply because the data is processed by an AI system instead of a traditional application. Companies should understand what personal data the AI receives, why it is needed, the legal basis for processing, how long it is kept, who can access it, and whether people are affected by automated decision-making. 

The EU AI Act uses a risk-based approach, so not every AI system has the same compliance requirements. Companies first need to understand what the AI system does, how it is used, and what risks it may create. Higher-risk systems can have additional requirements around areas such as risk management, data governance, logging, human oversight, and other controls. The AI Act is also being introduced in stages, so organizations need to keep track of the rules that apply to their systems and the relevant implementation dates. 

HIPAA focuses on protected health information and applies to covered entities and their business associates in the situations defined by the law. GDPR focuses on personal-data processing and the rights of individuals. SOC 2 is an assurance framework used to evaluate controls at service organizations, rather than an AI-specific law. The EU AI Act is specifically focused on artificial intelligence and uses a risk-based regulatory approach. A company may need to consider more than one of these at the same time, depending on its AI use case, customers, location, and data. 

You Have Questions,
We Have Answers

Talk to our experts today and explore how we can help you build a connected and efficient digital ecosystem.

Engineering enterprise intelligence through AI and Cloud excellence.

AI Solutions

Salesforce

Industries

Company

Copyright © 2026. All rights reserved.

Terms

Privacy

llms.txt