Insights · 12 min read
What AI compliance actually requires before you build: the EU AI Act, GDPR, HIPAA, SOC 2, and the engineering work they add to AI projects in regulated industries.
By GGP Editorial
Most AI projects do not die on the model. They stall on the rules around the model. A team builds a customer-support assistant or a document-processing tool, ships it, and then a buyer asks for a SOC 2 report, a data protection assessment, or evidence the model was not trained on data it should not have touched. The answer comes late, and the deal falls over.
This guide is for founders, product leads, and CTOs planning an AI product or adding AI to an existing system. It covers the rules that actually apply, how they change the build itself, and how to scope the work so compliance is something you plan for instead of a surprise at the end. It is not legal advice. Regulation differs by jurisdiction and use case, and you should confirm specifics with counsel before you ship.
Three things changed in a short window, and they compound.
The European Union passed the AI Act, and its obligations are now phasing in. The law entered into force in August 2024. Prohibited practices, such as social scoring and AI that manipulates people in ways that cause harm, have been banned since February 2025. Obligations for general-purpose AI models, including documentation and copyright transparency, began applying in August 2025. The heavy part, the duties for high-risk systems, starts applying in August 2026, with some product categories given until August 2027. The fines are large enough to matter: up to 7% of global annual turnover for prohibited practices, 3% for most other obligations. That is not a rounding error for a growing software business.
Existing laws that predate the AI wave bind it all the same. GDPR has governed automated decision-making over personal data since 2018, and it is enforced. HIPAA governs health information in the United States regardless of whether a human or a model reads it. These laws were written before large language models, but they do not care. A model that processes personal or health data inherits every obligation of the system around it.
Enterprise buyers started asking for proof. Sell software to a bank, hospital, or insurer and you will get a security questionnaire. Increasingly the questionnaire now asks about model governance, training data, and monitoring, not just password policy and encryption. If you cannot answer, the deal stalls no matter how good the product is. Compliance has become a procurement requirement, not only a legal one.
Not every framework applies to every project. The useful starting point is a short map of what exists and when it bites.
| Framework or law | Who it applies to | What it demands | Status |
|---|---|---|---|
| EU AI Act | Anyone selling or deploying AI in the EU, with extra duties for high-risk systems | Risk classification, technical documentation, logging, human oversight, transparency, post-market monitoring | Phasing in through 2027 |
| GDPR | Anyone processing personal data of EU residents | Lawful basis, data protection impact assessments, rights requests, safeguards for automated decisions | In force since 2018 |
| HIPAA | US healthcare providers, payers, and their vendors | Protection of health information, business associate agreements | In force |
| SOC 2 | B2B software vendors, especially in the US | Attestation over security, availability, and confidentiality controls | Voluntary but market-driven |
| ISO/IEC 42001 | Any organization running AI | A certifiable AI management system | Published 2023, voluntary |
| NIST AI RMF | Widely used as a reference, especially in the US | A risk process built on Govern, Map, Measure, Manage | Voluntary framework |
| US state AI laws | High-risk AI in states like Colorado | Risk management, consumer notice, impact assessments | Colorado takes effect February 2026 |
The pattern across all of them is the same. None of these rules say "do not use AI." They say: know what your system does, document it, control the data, keep a record, and leave a human able to intervene. The difference between a high-risk system and a low-risk one is how much of that evidence you must produce.
This is the part most teams underestimate. Compliance is not a document you write at the end. It is a set of requirements the engineering has to satisfy, and each one adds scope.
Data governance comes first. A high-risk system under the AI Act must be trained, validated, and tested on data that is relevant, representative, and free of errors to the extent possible, and you must document the data. That means knowing where training data came from, what consent covers it, how long you keep it, and how you delete it. For personal data, GDPR adds lawful basis and rights requests. You cannot bolt this on after the model is built, because you will not know what went in.
Logging and audit trails matter more than most people expect. High-risk systems must record events automatically so a failure can be traced. What input went in, what the model produced, what a human did with the output, and when. That is engineering work, not a policy paragraph.
Human oversight is a hard requirement for high-risk systems. There must be a person who can understand the output, override it, or stop the system. That has a UI cost and an operational cost. A model that produces an answer with no way to review it before it reaches a customer fails this test.
Transparency shows up early and cheaply, but only if you build it in. Users interacting with a chatbot must generally be told they are talking to a machine. Deployed without that disclosure, the fix is usually a small change. Deployed after a regulator asks, the fix is the same change plus a problem.
Explainability and documentation are where teams lose weeks. You need technical documentation that describes the system, its intended purpose, its data, and its limits. Model cards and evaluation reports are the standard shape of that evidence. If the team cannot say why the model produced an output, you will not be able to document it either.
Security and monitoring round it out. AI systems fail in ways ordinary software does not: prompt injection, adversarial input, and quiet performance drift as real-world data changes. You need adversarial testing, access controls, and monitoring that catches drift and triggers an incident process. The EU AI Act also requires serious incidents with high-risk systems to be reported.
None of this is exotic. It is ordinary engineering done on purpose. But it is real scope, and skipping it does not leave you "nearly done." It leaves you unshipped.
The single most valuable step before you build is to classify the system. The AI Act sorts systems into risk levels, and the same logic maps well onto other frameworks.
Prohibited uses are off the table: social scoring, exploitative manipulation, most real-time biometric surveillance in public. Minimal-risk systems, a chatbot that answers product questions or a classifier that tags support tickets, carry few obligations beyond basic transparency. Limited-risk systems add disclosure duties. High-risk systems, the ones that touch credit, hiring, education, healthcare, insurance, or essential services, carry the full set: documentation, data governance, logging, human oversight, and monitoring.
| Risk tier | Typical examples | What it means for the build |
|---|---|---|
| Minimal | Internal document tagging, a simple FAQ bot | Basic transparency, light documentation |
| Limited | A customer-facing chatbot, an email drafting tool | Disclosure that users interact with AI |
| High | Loan decisioning, resume screening, medical triage, insurance pricing | Full documentation, data governance, logging, human oversight, monitoring |
A team building a tool that scores loan applications has a different project from a team building an internal summarizer. The second can ship fast. The first cannot, and pretending otherwise is how schedules and budgets break. Classify first, then plan.
Compliance work is not a final phase. It threads through the whole build.
During discovery, you identify the risk tier, the applicable rules, and the jurisdictions you will operate in. A data protection impact assessment happens here, before the data starts moving.
During design, you decide the data flows, retention, consent handling, and where a human reviews output. You pick the logging and monitoring you will need, because retrofitting them later means rewriting parts of the system.
During model development, you record training data, run evaluation and bias testing, and write the model documentation. This is the part that produces the evidence a buyer or auditor will ask for.
During deployment, you add the transparency disclosures, the audit trail, and the oversight workflow. During operation, monitoring and incident response take over, and documentation stays current as the system changes.
The timeline consequence is simple. A regulated use case adds weeks, sometimes a couple of months, to the front and back of a project compared with an unregulated one. If the estimate for your build does not mention compliance, the estimate is missing part of the job. For the underlying cost drivers, our piece on AI development cost walks through where the budget actually goes, and our FinTech security requirements article covers the same ground for financial platforms specifically.
Off-the-shelf AI APIs are the right default for many projects, but they have a blind spot that matters in regulated work: you cannot see the training data or the internal controls. A generic model from a vendor comes with a set of claims you did not verify, and you have no visibility into how it was trained, what it was trained on, or how it will behave next quarter.
For a high-risk use case, that lack of visibility is exactly what you need to document. A bank explaining its credit model to a regulator needs to show the data, the evaluation, and the limits. A generic API does not give you that evidence. This is where a controlled build, or a carefully governed integration, earns its cost. It is also where the decision gets nuanced, which is the subject of our build vs buy AI software comparison.
Even when you do use an external model, the integration around it, the data handling, the logging, and the oversight, is still custom work. Our guide on integrating an LLM into existing software covers how that part is scoped.
If you are going to hire a team to build a regulated AI system, a few questions separate the ones that understand compliance from the ones that will discover it mid-project.
Have you built systems in regulated industries, and which rules did they have to meet? Ask for specifics, not a yes. Which data will be used for training, where does it come from, and what consent covers it? How will the system log decisions and keep an audit trail? Where does a human review the output, and who is that person? How will you test for bias and monitor for drift after launch? What documentation will I receive at the end?
These are ordinary questions, but the answers tell you a lot about how the project will go.
We build AI systems for clients in financial services, healthcare, and other regulated sectors, and the compliance work is part of how we scope the project from the start rather than a discovery at the end. GlobeSoft has been building software since 2018, with 40 plus engineers and more than 300 delivered projects, and we ship for clients across Brazil, South Africa, Singapore, the United States, and beyond. If your AI project sits anywhere near a regulated line, the earlier we look at it together, the cleaner the build.
Does every AI product need to comply with the EU AI Act?
Only if you sell or deploy it in the EU. The obligations scale with risk: most business AI is minimal or limited risk and carries light duties, while high-risk systems carry the full set.
What counts as high-risk AI?
Systems used in areas like employment, credit, education, healthcare, insurance, and essential services, plus certain biometric and safety systems. If your tool makes or shapes a decision about a person in one of those areas, assume it may be high risk and get it classified.
Is there a single AI compliance standard I should follow?
No single one covers everything, but ISO/IEC 42001 and the NIST AI Risk Management Framework are the two most common references, and SOC 2 is what most enterprise buyers will ask for regardless.
How much does compliance add to an AI project?
It depends on the risk tier and jurisdiction, but it adds real scope across data governance, documentation, testing, and monitoring. A high-risk build is a longer and more careful project than a minimal-risk one, and the estimate should reflect that.
Can I use an off-the-shelf model in a regulated product?
Yes, with care. The issue is visibility into training data and internal controls. For high-risk use cases you usually need the custom integration, documentation, and oversight around the model even when the model itself is bought.
Planning a custom software, AI, SaaS, or FinTech project? Share your requirements with GlobeSoft. Our team can help you define the scope, architecture, development approach, timeline, and estimated budget.
Tell us what you are building and where you are today. We typically reply within 24 hours.
