How to avoid compliance pitfalls in AI-built apps

The gap nobody asked the AI to close

We see the same failure mode over and over in Launch-Readiness Scans: an app that works, demos well, and has zero compliance guardrails. It's not that the AI tool botched the job — it's that nobody told it there was a job to do.

Ask an AI coding tool to "build a dashboard" and it will build you a dashboard. It won't ask what that dashboard is allowed to do with a user's data, whether the logs it writes might leak something sensitive, or which regulations apply to the industry you're building for. The model is optimized to produce working code, not compliant code, and those two things only overlap when you make them overlap on purpose.

Requirements go in the prompt, not in your head

"Make this secure" doesn't give a model anything to check its own work against — it's a wish, not a spec. Compliance and security requirements need the same precision as functional ones, and they work best written once into a .cursorrules file, AGENTS.md, or whatever your tool reads on every session, rather than retyped each time you remember to care:

• Say which rules actually apply. If the product touches health data, healthcare privacy law belongs in the prompt by name. If it touches EU users, so does data-protection-by-design. A model can act on a named requirement; it can't act on your assumption that it already knows your regulatory context.
• Spell out how data gets handled, not just that it should be. Which validation library to use on every input boundary, what's forbidden from ever reaching a log line, which fields get redacted before they're persisted anywhere. Concrete rules are the ones a model can follow — and the ones you can go check afterward.

Don't let the author grade its own work

Ask the same model that just wrote your auth code whether that code is secure, and it will tell you it looks fine. Not because it checked carefully — because agreeing with you is closer to what it's trained to optimize for than finding its own mistakes.

The fix is cheap: hand the finished code to a different model and ask it to go looking for problems specifically, rather than to generally "review" the work. A reviewer told to assume there are mistakes and go find them behaves very differently from one asked whether everything looks okay — the second question invites a yes.

Guardrails that run themselves

A one-time review, however careful, only checks the code that existed at review time. The gap reopens with the next commit unless something is watching continuously:

• Catch secrets before they're committed, not after. A pre-commit hook or a scanner in CI that blocks any push containing something that looks like a key or credential closes this permanently, instead of relying on someone noticing.
• Scan for the basics on every push — injection points, an admin route nobody meant to expose publicly, dependencies with known vulnerabilities. Open-source scanners exist for all of this; the point isn't which one, it's that it runs automatically instead of "when someone remembers."

This site's own CI does exactly that with secrets: it isn't a step we ran once before launch, it runs on every single push, so nothing hardcoded can quietly land in a later commit.

The best fix is not needing one

All of the above matters, but the highest-leverage move is smaller: if you don't need to store sensitive data — personal, medical, financial — don't.

It's part of launch-readiness

Checking exactly this — whether auth, secrets, and user data are handled the way the app claims to, not just the way it demos — is one of the things our Launch-Readiness Scan looks for. Compliance gaps in AI-built apps are almost never deliberate; they're just the requirements nobody typed into the prompt. Type them in, let a second model try to break what the first one built, automate the parts that don't need a human, and collect less in the first place.