AI Compliance: Two Jobs Founders Confuse

AI compliance is two different jobs that share one name, and founders lose quarters by solving the wrong one. The first is compliance of your AI, proving the system you ship meets the rules that apply to it. The second is compliance by AI, pointing models and agents at the compliance work itself.

On the first job, you ship a system that makes or shapes decisions, and you have to show it meets the rules that apply to it. On the second, you point models and agents at the monitoring and reporting and evidence-keeping that currently eats a person or a team.

They sound like one topic. They are not. They have different owners, different budgets, and different first moves, and a vendor selling you one will happily describe the other. Sorting them takes about ten minutes and saves a quarter.

AI compliance is two jobs, not one

Compliance of your AI is a product and legal question. What does your system decide, whose data does it touch, which jurisdictions does that land in, and can you evidence any of it under questioning. The rules here come from regulators and from your customers' contracts, and the second source moves faster than the first.

Compliance by AI is an operations question. Y Combinator's request for startups on this category describes the current state bluntly: "Financial compliance is still stitched together with spreadsheets, siloed tools, and expensive headcount." The work itself, YC argues, is a natural fit for automation, because most of it is "monitoring regulatory changes, flagging anomalies, generating reports, and keeping audit trails. These are tasks that AI can handle faster and cheaper than humans."

The trap is that the two get budgeted together and then neither gets done. A founder buys a governance platform because AI compliance sounded urgent, and six weeks later the enterprise deal is still stuck behind a security questionnaire the platform does not answer. The reverse also happens: a team automates its compliance reporting beautifully while shipping a model into a regulated workflow nobody documented.

Pick which one is blocking you. Usually one of them clearly is.

Which AI compliance rules apply to a startup right now

For the first job, most founders are working from headlines that are a year out of date. Here is the actual state of the EU AI Act, which is the most consequential piece of law in this space and the one most often misdescribed.

The Act entered into force on 1 August 2024 and phases in over years rather than landing at once. Prohibited practices and the AI literacy duty applied from 2 February 2025, though the Omnibus discussed below has since softened that literacy duty into an obligation of means: take measures to support AI literacy among the people running your systems, rather than guarantee any individual's competence. Rules for general-purpose AI models applied from 2 August 2025. On 2 August 2026, per the Commission's own implementation timeline, the majority of the remaining rules started to apply and enforcement began, including the Article 50 transparency duties: tell people when they are interacting with an AI system, and mark synthetic content as synthetic.

The part that changed recently, and that most summaries still have wrong, is the high-risk regime. The AI Omnibus entered into force on 27 July 2026 and extended those deadlines. Standalone high-risk systems listed in Annex III now apply from 2 December 2027. High-risk AI embedded in regulated products under Annex I applies from 2 August 2028. There is also a 2 December 2026 date worth knowing: additional prohibitions arrive, and providers of generative systems already placed on the market before 2 August 2026 have until then to meet the Article 50(2) machine-readable marking obligation.

Three practical readings for a founder:

1. A delay is not a cancellation, and it is not the part that binds you anyway. The majority of the Act is live and enforceable now. What moved was the heaviest conformity work, for the narrow set of systems that qualify as high-risk.
2. Most B2B software startups are not high-risk providers. Annex III is a list of specific use contexts, not a mood. If you sell a coding agent or a sales tool, your near-term obligation is transparency and honest documentation, not a conformity assessment. Read the list before you assume either way, and get an actual lawyer's read if you are near the line.
3. The law you already had did not go anywhere. Data protection, health, and financial services rules applied to your product before the AI label was attached to it, and they still do. An AI feature that processes personal data is a data-protection question first and an AI Act question second.

Two frameworks come up constantly alongside this, and it is worth being precise about what they are. ISO/IEC 42001, published in December 2023, is a certifiable management-system standard for AI: you can hold a certificate, and the providers your buyers benchmark you against already do. AWS announced accredited certification in November 2024, Google Cloud in December 2024, and Anthropic in January 2025. The NIST AI Risk Management Framework, released on 26 January 2023, is voluntary and has no certificate at all, so when a buyer asks about it they are asking you to show alignment, not to produce a badge. Neither is a law. Both show up in procurement, which brings us to where the real pressure comes from.

The gate that blocks revenue is a security questionnaire

Ask a founder what forced them to take compliance seriously and you rarely hear about a regulator. You hear about a deal.

Jay V, founder and CEO of OpenCode, the open-source coding agent, described the pattern on Y Combinator's Lightcone. The company grew bottom-up through developers, and the enterprise conversation started itself. Jay V says the inbounds are typically "there are a bunch of people at this company at our company using you guys. Can you fill out the security questionnaire?" His reaction was, roughly, that he did not know they were customers, and could he have a second.

One of the hosts made the observation that should reframe this for anyone treating compliance as pure cost: "You really know you have product market fit when enterprises are bugging you to sign the security agreement so they can use your product."

That is the correct way to hold it. A security review is not a tax on a deal you already won. It is the point where usage inside a company becomes a purchase, and it arrives as a demand signal before it arrives as paperwork. Which means the useful question is not whether to do compliance, but how long your clock is.

For SOC 2, the clock is the whole problem. A SOC 2 Type 1 report opines on whether your controls are designed properly at a point in time. A Type 2 report opines on whether they actually operated across a period. You can buy a platform, you can hire help, you cannot compress an observation window that has not started yet. Founders who start the clock when a deal needs the report are already two quarters late. Founders who start it when the first enterprise user shows up in their logs are on time.

ISO/IEC 42001 has the same shape and is becoming the AI-specific version of the same conversation. If you sell AI into regulated buyers or into Europe, expect it to show up in questionnaires before it shows up in law.

The evidence pack a buyer will ask for

Almost every AI security review is the same eight questions in different fonts. Write the answers once, keep them current, and hand them over before the questionnaire arrives:

1. A data flow diagram. What customer data enters the system, where it goes, which components touch it, and where it comes to rest.
2. A model and subprocessor inventory. Every model you call, self-hosted or API, every vendor in the path, and what each one receives. This is the single most common gap, because model calls get added by engineers, not by procurement.
3. A training-data-use statement. Whether customer data trains anything, yours or a provider's, stated in one unambiguous sentence. If the answer is no, name the contractual setting that makes it no.
4. Retention and deletion. How long inputs, outputs, and logs live, and what a deletion request actually deletes. Prompt logs are the forgotten copy of the customer's data.
5. Data residency. Which regions process and store data, and whether a buyer can pin it.
6. Human oversight. Which decisions a model makes alone, which require a person, and how a person overrides one.
7. Access control for agents. What credentials the system holds and what those credentials can reach.
8. Incident response. How you detect a bad output or a breach, who is paged, and what the customer is told and when.

If those eight exist as maintained documents rather than as institutional memory, most reviews become a copy-paste exercise. If they do not, every review becomes a week of engineering time.

Passing audits without a compliance team

Here is the part that is genuinely new, and it is the second job.

The reason compliance costs so much is that evidence is reconstructed after the fact. Someone goes hunting for who approved what in March, finds it in a Slack thread, screenshots it, and pastes it into a folder. YC's read on why the existing tools have not fixed this is that they were built to speed up that same motion: most solutions today, the request for startups says, are "built around manual workflows and human review bottlenecks." Automating a bad process gets you a faster bad process.

The AI-native version inverts it: make the system emit its evidence as a byproduct of doing the work, at the moment it happens.

Concretely, for a startup with no compliance headcount:

• Log decisions, not just events. For any consequential action, record the inputs, the model and version, the policy or procedure that applied, the outcome, and who or what approved it. That record is both your debugging trail and your audit trail, and it costs almost nothing to write at the time and a fortune to reconstruct later.
• Keep the policy in one machine-readable place. If your procedure lives in a document an agent can read, an agent can check work against it and cite the clause it applied. If it lives in three people's heads, nothing can.
• Point an agent at regulatory monitoring first. It is the lowest-risk, highest-tedium slice: watching the regimes you operate in for changes and summarizing what moved. Nothing it produces is binding, so a wrong summary costs a human read rather than a filing.
• Let it draft, never file. Reports, questionnaire responses, and evidence packages are drafting work. The submission is not.
• Instrument at write time. A provenance label or an approval record added later is a claim. Added at the moment of the action, it is evidence.

The same discipline that makes an AI product auditable makes it debuggable, which is why this is worth doing even if no auditor ever calls. It is the same argument as building the feedback loop into fraud review rather than bolting analysis on afterward.

What to never let the agent decide

The security half of this deserves its own boundary, and my bias here is a CISSP's.

Give an agent compliance work and you have handed a non-deterministic system a set of credentials that reach your most sensitive records. That access is the blast radius. If the agent is wrong, or prompted by content it read, or simply over-scoped, the damage is bounded by what it could touch and nothing else. So scope it to the evidence it needs, keep read and write separate, and log every call it makes with the same rigor you would apply to a human with those permissions.

Then hold a line on authority. An agent can assemble a filing. A named human attests to it. That is not ceremony: attestation is the mechanism that puts accountability somewhere, and moving it to a model does not remove it, it just makes it unowned. This is the same lesson banks reached first, where the worry is leverage rather than intelligence: a wrong answer repeated at machine speed across thousands of records is a different class of problem from a wrong answer once.

There is an external clock on this too. Oege de Moor, founder of XBOW, told a Sequoia audience how far the defender's window has already closed. In 2018, he said, the delay between a CVE being published and bad actors exploiting it in the wild was almost two to two and a half years. Today the number has gone negative: for most CVEs, exploitation is already happening before the CVE is published. He argues that autonomous, AI-driven attacks are what the next stretch looks like, and his conclusion applies directly to anyone wiring agents into sensitive systems: "We need every possible defense that we can get against these autonomous AI-powered attacks." The controls that make you auditable, least privilege, complete logs, and a human in the approval path, are the same controls that contain an attacker who reaches your agent. You are not building them twice.

For the broader version of this argument, that the safety questions on an AI product arrive later than the capability and cost more to retrofit, the Anthropic lessons for founders piece covers the governance side.

If compliance infrastructure is the product

Some readers are not buying here, they are building. The category is genuinely open, and YC is explicit about wanting it: it is looking for founders building compliance infrastructure that "consolidates fragmented tools, reduces reliance on specialized headcount, and gives finance teams real-time visibility across regulatory regimes." The bar it sets is the same one above: "The best version of this doesn't just automate existing processes, but rethinks what compliance operations look like when AI is the default."

Two things make this market better than it looks.

The first is that regulation is a feature of this market rather than a drag on it, which is one of the four traits that make an AI-native services market worth entering: difficulty that scares off casual entrants is the moat, and legal accountability is difficulty that cannot be competed away.

The second is that the pain compounds with expansion. State-by-state licensing, renewal cycles, and audits across jurisdictions get worse per market entered, so the cost of staying compliant grows faster than revenue. That shape, cost growing superlinearly with a customer's own growth, is what makes a category infrastructure rather than a tool.

The failure mode is obvious and worth naming: shipping a tenth point solution into a stack whose actual complaint is that it already has nine. Consolidation is the requirement, and it is much harder to sell than a feature. If you cannot describe what a customer turns off when they turn you on, you are adding to the problem you named in your pitch. Price it accordingly too, because the buyer is comparing you against a headcount line and not against a software line.

What to do this week

1. Write one sentence naming which job is blocking you: governing the AI you ship, or doing compliance work with AI. Put a name and a date next to it.
2. Check whether anything you build sits in an EU AI Act high-risk category, and read the current dates rather than a 2024 summary. If you are near the line, get a lawyer's read now, while the deadline is still 2027.
3. Write the eight-answer evidence pack. Set a two-hour block. Most of it you already know, and the gaps you find are the actual work.
4. Audit your model and subprocessor list against reality. Grep the codebase for every API endpoint you call. Engineers add models; procurement never hears about it.
5. Start the SOC 2 clock if any enterprise logo is in your pipeline, and do it before the deal depends on the report.
6. Pick one compliance task to hand an agent this week, and make it monitoring rather than filing. Nothing it produces should be binding.
7. Write down what your agents' credentials can reach, in one list. If that list surprises you, that is the finding.

Compliance is where a product decision, a security decision, and a go-to-market decision turn out to be the same decision, which is exactly the kind of thing that should live in your operating system rather than in someone's inbox. That is what the AI Operating System for Startups course is for, and the AI for startups guide is the free overview of how this sits next to agents, evals, and pricing.

Sources

• AI-Native Compliance Infrastructure, Y Combinator's request for startups that this article distills: the fragmented-tooling diagnosis, the four automatable tasks, and the consolidation bar.
• EU AI Act primary sources: the European Commission's regulatory framework page, its implementation timeline, and its notice that the AI Omnibus entered into force on 27 July 2026, moving Annex III high-risk rules to 2 December 2027 and Annex I to 2 August 2028.
• Standards and frameworks: ISO/IEC 42001:2023 (published December 2023, certifiable) and the NIST AI Risk Management Framework (released 26 January 2023, voluntary, no certification). SOC 2 reporting: the AICPA's SOC suite of services.
• He Built the World's #1 Open-Source Coding Agent, Y Combinator's Lightcone, for the enterprise security questionnaire arriving as an inbound. Profile: Jay V of OpenCode (YC W21).
• Inside the Rise of Autonomous AI Hackers, Sequoia Capital, for the collapsed CVE exploitation window and the case that autonomous attacks make least privilege and complete logging urgent. Speaker: Oege de Moor of XBOW.