HIPAA is a US law protecting health information, SOC 2 is an independent audit report on how a service company protects customer data, and GDPR is the European law governing personal data. None of them is a box a tool can tick for you: compliance depends on what data your apps hold, who can reach it, the contracts you have with vendors, and your own processes. Before building any tool with regulated data, decide what data goes in, confirm the vendor's commitments in writing, and review the plan with your compliance advisor.
"Is it HIPAA compliant?" is one of the first questions a clinic manager asks about any new software. "Do you have SOC 2?" is one of the first an IT lead asks. "What about GDPR?" comes up the moment a company has a single European customer. When your team starts building its own tools with AI, these questions do not go away. They get more important, because now your own people are deciding what data goes where.
This guide explains HIPAA, SOC 2 and GDPR in plain English, what each one means when your team builds its own tools, the questions to put to any AI platform, and what to bring to your compliance advisor. It is general information, not legal advice. Every company's situation is different, and your compliance advisor decides what applies to you.
The short version
| Framework | What it is | Who it applies to | What it means for AI-built apps |
|---|---|---|---|
| HIPAA | A US law protecting health information | Healthcare providers, health plans, healthcare clearinghouses and the vendors that handle health information for them | Health information in a tool needs the right contracts, access controls, records and processes |
| SOC 2 | An independent audit report on a service company's controls | Service companies, usually at their customers' request | A vendor's report tells you about the vendor, not about how your team uses the tool |
| GDPR | The European law governing personal data | Organizations handling personal data of people in the EU, including some outside Europe; the UK has a closely related law | Personal data in a tool needs a lawful reason, limits on what is collected, the right contracts and the ability to honor people's rights |
The common thread: compliance belongs to your organization, not to a tool. A vendor can make compliance easier or harder, but no AI platform can make your company compliant on its own.
HIPAA in plain words
HIPAA is a US federal law that protects health information that can identify a person, such as a patient's name together with a diagnosis, appointment or treatment. It applies to healthcare providers, health plans and healthcare clearinghouses, which it calls covered entities, and to the vendors that handle that information on their behalf, which it calls business associates.
In practice, HIPAA expects:
- Privacy rules. Health information is used and shared only for allowed purposes, and patients have rights over it.
- Security safeguards. Administrative, physical and technical protections, including controlling who can access information and keeping records of access.
- Contracts with vendors. A business associate agreement with each vendor that handles health information for you.
- Breach notification. Duties to notify affected people, and in some cases regulators, when health information is exposed.
What HIPAA means when your team builds tools
- Decide whether health information goes in at all. Many clinic tools, such as supply tracking or staff scheduling, need none. Keep it out where you can.
- If it does go in, involve your advisor first. They will want to know which vendors handle the data and whether agreements are in place with each.
- Access must be limited by role. Front desk, clinicians and billing need different access. See our guide to role-based access.
- You need a record. Who accessed and changed what, and when.
- Keep health information out of the build conversation. Describe the shape of the data instead of pasting real patient details.
Our guide to whether clinics can build their own internal apps safely goes further for healthcare teams.
SOC 2 in plain words
SOC 2 is not a law. It is an audit report, prepared by an independent accounting firm, describing how a service company protects its customers' data. The audit measures the company against a set of criteria covering security, and optionally availability, processing integrity, confidentiality and privacy.
There are two kinds of report:
- Type 1: looks at whether the company's controls are designed properly at a single point in time.
- Type 2: tests whether those controls actually worked over a period, often several months to a year. Type 2 is the stronger evidence.
What SOC 2 means when your team builds tools
- It tells you about the vendor. A SOC 2 report is useful evidence that a vendor runs its own systems carefully.
- It does not cover your choices. How your team sets up access, what data you put in and how you handle departures are outside the vendor's report.
- Your customers may ask about your tools. If your business customers send security questionnaires, they may ask about the tools that hold their data. Be ready to describe your access controls and records.
- Read the scope. A report covers specific systems and criteria. Confirm it covers the product you are buying.
GDPR in plain words
GDPR, the General Data Protection Regulation, is the European Union's law on personal data, meaning any information about an identifiable person. The UK has its own closely related version. GDPR can apply to companies outside Europe that offer goods or services to people in the EU or monitor their behavior.
In practice, GDPR expects:
- A lawful reason for handling each kind of personal data.
- Data minimization: collect only what you need, and keep it only as long as you need it.
- People's rights: to see their data, correct it, and in many cases have it deleted.
- Contracts with processors: vendors that handle personal data for you need a data processing agreement.
- Security and breach reporting: appropriate protection, and strict deadlines for reporting certain breaches.
- Care with transfers: rules about moving personal data outside the EU or UK.
What GDPR means when your team builds tools
- Know what personal data each tool holds. Keep an app register that records it.
- Collect less. When describing a tool, leave out fields you do not need.
- Be able to find and delete one person's data. If someone asks, you need to find their records in every tool.
- Check vendor contracts. Ask for the data processing agreement and the list of other companies that handle your data.
It is also worth knowing how widely staff use AI on their own. Deloitte UK's 2026 survey found 63 percent of UK working adults knowingly use generative AI for work, and 31 percent of those users do so without their employer's knowledge. Personal data that goes into unapproved tools is outside every control above. Our guide to shadow AI explains how to bring that use into the open.
Other rules you may run into
HIPAA, SOC 2 and GDPR get the most attention, but they are not the only ones. Ask your advisor about these too.
- Payment card rules. Businesses that accept card payments are expected to follow the card industry's security standard, known as PCI DSS. The simplest approach for internal tools is to keep card numbers out of them entirely and let your payment provider hold them.
- US state privacy laws. A growing number of US states have their own consumer privacy laws, with California's the best known. Whether they apply depends on your size, revenue and how much personal data you handle.
- Industry and contract requirements. Government contractors, financial firms, schools and others often have their own rules, and many business customers write security requirements into their contracts.
Common misconceptions
- "The vendor is compliant, so we are." A vendor's compliance covers the vendor. Your choices about data and access are still yours.
- "It is only an internal tool." Internal tools hold the same customer and employee data as anything else, and they are often less protected.
- "We are too small for this to apply." Size changes some obligations, not all. Health information is protected regardless of practice size.
- "We will sort out compliance after launch." By then the data is already in the tool. Decide what goes in before you build.
Why AI-built apps raise the stakes
Compliance frameworks assume you know where regulated data lives and who can reach it. AI-built apps can undermine both.
- Exposure through missing access rules. In February 2026, The Register reported that one app hosted on Lovable had 16 vulnerabilities, 6 of them critical, exposing 18,697 user records. In May 2026, RedAccess reported reviewing about 380,000 vibe-coded assets, finding about 5,000 built for corporate purposes, 40 percent of which exposed sensitive data.
- Responsibility placed on you. Lovable disputes CVE-2025-48757, saying each customer is responsible for protecting their app's data. Whatever you think of that position, it is a clear reminder that the platform may not carry the compliance load.
- Records and identity controls on top tiers. As listed in October 2026, Lovable puts SCIM and audit logs on Enterprise only, and Replit lists SSO, SCIM and audit logs as Enterprise only. If your compliance needs depend on those controls, price the plan that includes them.
- Data in the conversation. People paste real records into build conversations, which may be stored with the project.
Questions to ask any AI platform
- Can anyone outside our company reach the apps we build, and how is that prevented?
- How do people join and leave, and does access end immediately on removal?
- What roles exist, and can we limit which records each person sees?
- Is there a complete record of who did what, on the plan we are buying?
- Is our data used to train AI models? Which other companies receive it?
- Do you sign a business associate agreement or a data processing agreement, and on which plans?
- Do you have independent audit reports, and what do they cover?
- Where is our data stored, and how do we export and delete it?
Our guide to what AI app builders do with your data covers the data questions in more depth.
What to bring to your compliance advisor
Before building any tool that will hold regulated data, bring your advisor a one-page summary:
- What the tool does and who uses it.
- Exactly what data it will hold, field by field.
- Who can see what, by role.
- Which vendors handle the data, and the contracts in place with each.
- How access is granted and removed.
- What record exists of access and changes.
- How you would export or delete one person's data.
- What happens if the data is exposed: who acts and who decides.
Ask your advisor to confirm in writing what is required before you go live.
A pre-launch checklist for regulated data
- Minimize. Remove every field the tool does not need.
- Separate. Keep regulated data in its own tool with the tightest roles, rather than in a general tool everyone uses.
- Restrict. Give access only to roles that need it, and test by signing in as each role.
- Record. Confirm you can see who did what.
- Contract. Confirm the agreements your advisor requires are signed.
- Test. Run the pre-launch test checklist with test data before real data goes in.
- Train. Tell users what may and may not go into the tool.
- Review. Re-check access quarterly.
How FORGE handles it
FORGE was built so the controls compliance frameworks care about most are in place from the first tool.
- Every app lives inside your company. Every request checks that the person asking belongs to your company. Anyone outside gets nothing back.
- Only the people you invite. Your admin invites each person by email, every invite works once, and there is no public sign-up.
- Access by role. Owners, admins, builders and app users each see and do exactly what their role allows, and inside each tool your team describes who sees which records.
- Security checked before it exists. Every piece of every app is checked for quality and security before it is ever saved.
- A complete record. Every step of every build is recorded with who or what did it.
- People leave, access ends. Removing someone ends their access immediately, and their tools stay with the company.
If your work involves health information, payment data or personal data covered by GDPR, bring your compliance needs to us at the start. In your workflow workshop we walk your IT lead through exactly how FORGE handles your data, on your real work, so you and your compliance advisor can confirm what your situation requires. Talk to us.
Questions people ask
Can AI-built apps be HIPAA compliant?
HIPAA compliance belongs to organizations and how they handle health information, not to an app on its own. An AI-built tool can be part of a compliant setup if the right contracts, access controls, records and processes are in place. Confirm with your compliance advisor before any health information goes into a new tool.
What is a business associate agreement?
Under HIPAA, a business associate agreement is a contract between a healthcare organization and a vendor that handles protected health information on its behalf. It sets out how the vendor must protect that information. If your tools will hold health information, ask your advisor whether you need one with each vendor involved.
What is SOC 2?
SOC 2 is an audit report, prepared by an independent accounting firm, describing how a service company protects customer data against a set of criteria covering security, availability, processing integrity, confidentiality and privacy. A Type 1 report looks at controls at one point in time; a Type 2 report tests them over a period.
Does a vendor's SOC 2 report make our apps compliant?
No. A SOC 2 report tells you about the vendor's own controls. It does not cover how your team configures access, what data you put in or how you run your processes. Those remain your responsibility.
Does GDPR apply to a US company?
It can. GDPR can apply to companies outside Europe that offer goods or services to people in the EU or monitor their behavior. The UK has its own closely related law. Ask your legal advisor whether either applies to you.
What should we never put into an AI-built app without advice?
Health information, payment card numbers, government ID numbers, and data about children, unless your compliance advisor has reviewed the tool, the vendor contracts and your access rules.
How does FORGE support teams with compliance needs?
Every FORGE app lives inside your company, people join only by invite, each role sees exactly what it should, every piece is checked for security before it is saved, and every step is recorded. Your IT lead and compliance advisor can review how FORGE handles your data in the workflow workshop.
See what FORGE builds for your team
We onboard every team ourselves, starting with the work that costs you the most time.
Talk to us
