Building Software in the Age of AI Regulation

Jarrett · CEO & Co-Founder, OneChair

Most software projects still begin with a blank slate, optimizing for features and speed to market. Compliance is treated as a phase that comes later — after the product is validated, when there is money to invest in getting it right. This sequence is understandable, but it is becoming increasingly expensive as privacy and AI-specific regulations reach more applications, more sectors, and more jurisdictions.

The good news: compliance is not as complicated as the legal language makes it sound. The principles behind most frameworks are consistent. Understanding them before you write a line of code is one of the highest-leverage things a founder can do — because the cost of designing for compliance at day one is an afternoon, and the cost of retrofitting it later is measured in months and significant dollars.

Why Regulation Now Touches Almost Every App

A few years ago, compliance was primarily the concern of financial services companies and healthcare organizations. Today, the radius is wider. Any application that collects personal data from EU residents is subject to GDPR — regardless of where the company is incorporated or where its servers sit. Any application handling personal data from California residents above certain thresholds is subject to CCPA and its successor CPRA. Any application that uses AI to make decisions affecting individuals in certain categories — employment screening, credit assessment, health recommendations, access to public services — is entering scope for the EU AI Act's risk-based framework. Any healthcare-adjacent platform in the US that handles protected health information is subject to HIPAA.

Put those together and you have a large proportion of the applications that founders and growth-stage companies are actually building: B2C SaaS with users in the EU, healthcare-adjacent platforms, HR and recruitment tools, financial wellness applications, customer-facing AI features. The regulations are not designed to punish startups. But they do require specific things to be designed into the architecture — things that are cheap to include from the start and expensive to add after the fact.

The Frameworks That Matter, in Plain English

GDPR

The EU General Data Protection Regulation applies to any organization processing personal data of EU residents. Its core principles are data minimization (collect only what you need), purpose limitation (use data only for what it was collected for), consent (obtain it, document it, make it revocable), and individual rights (users can request access to, correction of, or deletion of their data). From an architecture standpoint, GDPR requires a clear data map, documented consent records stored in your database, the ability to permanently delete a user's data across all systems, and a defined process for handling data access requests. None of these are impossible — all of them need to be designed in from the beginning if they are to work reliably.

CCPA / CPRA

The California Consumer Privacy Act (expanded by CPRA) applies to businesses collecting personal data from California residents above defined revenue or data-volume thresholds. The practical requirements overlap substantially with GDPR: users have the right to know what data is collected, the right to request deletion, and the right to opt out of the sale or sharing of their data. Companies that have already built GDPR compliance typically find CCPA compliance requires relatively modest additional work. Companies that have neither face both simultaneously when they first encounter an enterprise procurement questionnaire.

EU AI Act

The EU AI Act takes a risk-based approach rather than a blanket prohibition on AI. Systems classified as high-risk — those affecting safety, fundamental rights, employment, credit, education, or essential services — face requirements around transparency, accuracy documentation, human oversight, and logging. Lower-risk systems face disclosure requirements: when a user is interacting with an AI system, they should know. The Act does not prohibit AI. It requires that AI be deployed with appropriate documentation and oversight, proportionate to the risk the system poses. The practical implication for most SaaS founders: build explainability and human override mechanisms into AI-facing features from the start.

HIPAA

HIPAA applies to healthcare providers, health plans, and their business associates in the US. Its Protected Health Information requirements specify how health data must be stored (encrypted at rest), transmitted (encrypted in transit), accessed (with audit logs), and disposed of. Business Associate Agreements are required with every vendor that handles PHI on your behalf — including your cloud hosting provider, your analytics platform, your customer support tool, and your email service provider. A healthcare application built without considering BAAs is an application that cannot legally handle PHI until those agreements are in place and the infrastructure is configured to meet the requirements. See our healthcare industry page for more on what HIPAA-compliant development looks like in practice.

Designing for Compliance from Day One

Compliance from day one is not about adding overhead to the build. It is about making decisions at design time that cost nothing to implement correctly and cost enormously to correct later.

Data minimization

Only collect the data you need to deliver the service. Every additional field in your data model is additional scope, additional regulatory obligation, and additional liability in the event of a breach. Before adding any field, the question to ask is: what does the product fail to do without this data? If the answer is "nothing clear," leave it out. This is a design discipline that has compounding benefits across the life of the product.

Consent architecture

For GDPR-regulated applications, consent must be granular, specific, revocable, and recorded. An afterthought cookie banner that sets a cookie does not constitute compliant consent management for personal data processing. Consent records belong in your primary database, linked to the user account, with timestamps and the specific purpose each consent covers. This is a data model decision that must be made before the user management system is built.

Audit logging

Many frameworks — HIPAA and SOC 2 among them — require audit logs of who accessed what data and when. This is a backend architecture decision. If your data access layer does not generate audit logs from the beginning, adding them later means touching every data access path in the application — an expensive and error-prone retrofit. Designing audit logging into the persistence layer at the start costs one sprint. Adding it across an existing codebase costs many times more.

Data residency

Some regulated industries and some countries require that certain data be stored within specific geographic boundaries. Choosing a hosting architecture that supports data residency from the start — and configuring it before any user data is collected — is straightforward. Adding it after data has accumulated means migrating databases, renegotiating vendor contracts, and potentially having to notify users of data transfers.

Explainability for AI features

If your application uses AI to make recommendations or automated decisions, the EU AI Act and general best practices both point toward the same design: surface the factors behind recommendations, allow human review and override, and document the system's behavior. These are product design decisions — they affect the UI and the data model — which is why they need to be considered at design time, not after the AI feature is already shipped.

The Real Cost of Retrofitting Compliance

The most common pattern we encounter is a startup that built quickly, achieved product-market fit, raised a round, and then discovered that their most important prospective enterprise customer requires GDPR compliance or SOC 2 certification before signing. The compliance work then happens under two constraints that make it maximally expensive: under time pressure (the contract is waiting) and on top of a system that was not designed for it.

Retroactively implementing GDPR compliance on a system without consent records means auditing all data collection points, building a consent management layer from scratch, implementing a data deletion workflow across every storage system (primary database, analytics, email service, support platform, backups), and documenting everything. For a mid-complexity SaaS application, this work commonly costs $30,000–$80,000 in development time, plus compliance consulting if the team does not already know the framework.

Retrofitting HIPAA compliance is often more expensive, because HIPAA requirements touch the security architecture, not just the data model. Applications built without HIPAA in mind frequently find that their hosting configuration, their analytics service, and their customer communication tooling all need to be replaced or reconfigured. See our case study on building a HIPAA-compliant platform in 27 hours for a concrete example of what compliant architecture looks like when designed in from the start.

We ask compliance questions in the first planning call — not because it slows things down, but because getting it wrong is what actually slows things down. A compliance retrofit on a live system is one of the most expensive things we see founders deal with.

Jarrett Dargusch, OneChair

A Pre-Build Checklist for Founders

Before your next software project begins, work through these questions with whoever is designing the architecture:

• Will the application handle personal data of EU residents? If yes, design for GDPR from day one: consent records, data minimization, deletion workflows, data subject access request handling.
• Will the application have California users at meaningful scale? CCPA/CPRA applies. The GDPR architecture handles most of this already.
• Will the application handle any health information in the US? HIPAA applies. Compliant infrastructure, BAAs with every vendor, audit logging, and encryption requirements need to be specified before the architecture is finalized.
• Will the application use AI to make recommendations or decisions affecting users? Plan for AI Act transparency requirements and human override mechanisms in the product design.
• Will you need SOC 2 certification to sell to enterprise customers? Build access controls, audit logging, and incident response processes into the initial architecture.
• What data do you actually need to deliver the service? Collect only that. Write it down before the data model is designed.

The cost of answering these questions before the design phase begins is an afternoon of conversation. The cost of not answering them is a deferred liability that gets called in at the worst possible time.

Frequently Asked Questions

Does GDPR apply to my startup if I am not based in the EU?

Yes. GDPR applies to any organization that processes personal data of people in the EU, regardless of where the organization is incorporated or where its servers are located. If your application has EU users, GDPR applies to how you handle their data. The regulation is explicit on this point.

We are a small startup. Do the enforcement bodies actually come after us?

Enforcement actions against small companies are less frequent than those against large ones, but the legal exposure is real. More practically, the compliance question tends to surface at growth inflection points — a prospective enterprise customer requiring a security questionnaire, a fundraising round with due diligence, or a partnership with a larger entity. At those moments, being non-compliant is expensive regardless of whether a regulator is involved.

Do we need a BAA with our cloud hosting provider for a HIPAA application?

If your cloud hosting provider stores or processes PHI on your behalf, yes — a Business Associate Agreement is required. Major cloud providers offer HIPAA-eligible service tiers with accompanying BAAs, but you must explicitly configure your workloads on those tiers. Running HIPAA workloads on standard configurations without a BAA in place creates direct regulatory exposure regardless of the technical security controls in place.

What is the difference between GDPR compliance and SOC 2 certification?

GDPR is a legal obligation governing how you handle personal data of EU residents — it applies by law if you have EU users, regardless of whether you have sought any certification. SOC 2 is a voluntary certification from the AICPA demonstrating that your security controls meet a defined standard. It is not legally required but is frequently required by enterprise customers before they sign procurement contracts. The two frameworks overlap in some areas — both require good access controls and incident response processes — but serve different purposes and different audiences.

For companies building in regulated industries, the architecture decisions made at the start determine everything that follows. Our healthcare software practice is designed around HIPAA-compliant architecture from the first line of code, and our HIPAA platform case study shows what that looks like in a real delivery.