On August 31, 2026, the European Commission designated ChatGPT a Very Large Online Search Engine under the Digital Services Act. Not a chatbot. Not a productivity tool. A search engine, in the same regulatory bucket as Google Search and Bing — which means OpenAI is now on the hook for mandatory annual risk assessments, independent audits, public transparency reports, and fines of up to 6% of global annual revenue for non-compliance. TechPolicy.Press and Winbuzzer both flagged the same detail worth sitting with: the trigger wasn’t a scandal or a leak. It was ChatGPT’s search feature crossing the DSA’s 45-million-monthly-active-users-in-the-EU threshold. Scale alone did it.
That’s the part founders and engineering leads shipping AI features should actually be paying attention to, and most aren’t. The DSA’s Very Large Online Platform and Search Engine categories were written for Meta, Google, and TikTok. Nobody building a customer support widget or an in-app assistant thought this applied to them. But the mechanism that just caught ChatGPT — a usage threshold, not an intent test — is exactly the kind of rule that cascades. The Commission has already shown it will reclassify a product based on what it does at scale, not what its maker calls it. If you’re embedding an LLM into a consumer-facing product with EU users, you are one classification memo away from being asked questions you don’t currently have answers to.
Why “we’re just calling an API” won’t be a defense
The instinct among most teams that bolt AI features onto an existing product is that compliance is someone else’s problem — OpenAI’s, Anthropic’s, whoever’s model is doing the inference. That instinct is already wrong under GDPR, and the DSA is built on the same logic: obligations attach to the deployer and the surface users interact with, not just the model vendor upstream. A search engine wrapper, a recommendation feature, a content-summarization tool — if it operates at sufficient scale and shapes what EU users see or decide, regulators have shown they’re willing to look at the product, not just the API it calls.
What actually gets audited in a DSA risk assessment is uncomfortably basic engineering hygiene:
- Can you show what data went into a given model response, and where it came from?
- Do you have logging that reconstructs a decision after the fact, not just a request/response cache?
- Is there a documented process for how the system handles manipulation, misinformation, or harmful outputs — or does “the model usually behaves” count as your policy?
- Can a non-engineer at your company produce a transparency report from your system without an engineer translating logs by hand?
Most teams that shipped an AI feature in the last eighteen months can’t answer more than one of those cleanly. That’s not a judgment — it’s what happens when “add AI chat to the app” gets scoped as a feature sprint instead of a systems decision. The gap is invisible right up until an audit, a breach, or a regulator’s letter makes it visible all at once.
What “built in from day one” actually means here
We build production software, including AI features, and this is the argument we make to clients before a line of model-integration code gets written: security and compliance posture is cheaper to design in at the start than to retrofit once you’re under scrutiny. Concretely, that means:
- Structured logging around every model call — inputs, outputs, and the context that produced them — from the first deployment, not bolted on when someone asks for it.
- Data handling boundaries that are explicit in the architecture: what gets sent to a third-party model provider, what stays local, what gets redacted before it leaves your infrastructure.
- A real answer to “what happens when the model says something wrong or harmful,” designed before launch, not a Slack thread after the first bad output goes viral.
- Documentation that a non-technical stakeholder — a founder, a compliance officer, eventually a regulator — can actually read.
None of this requires treating a seed-stage product like it’s already a Very Large Online Search Engine. It requires not treating “AI feature” as a category exempt from the same engineering discipline you’d apply to payments or authentication. The EU has now demonstrated, publicly and with teeth, that scale triggers obligations automatically. Betting your architecture on staying small forever is not a strategy.
The uncomfortable part
There’s a version of this story where the lesson is “move slower, ship less AI.” That’s not our read. The lesson is that the teams who treat AI integration as a security and infrastructure problem — not just a prompt-engineering problem — are the ones who won’t have to do a panicked rebuild when a regulator, a customer’s procurement team, or an enterprise buyer’s security questionnaire starts asking the questions the DSA just made routine for OpenAI. Those questionnaires are already trickling down from EU enterprises to their vendors. They’ll trickle down further.
We’ve built AI features into shipped products — Crumb Count and Kompete both have production-grade infrastructure behind decisions that look simple on the surface — with exactly this bias toward transparency and auditability from the start, because retrofitting it later is always more expensive and always happens under worse conditions than a calm design review. If you’re staring at an AI feature roadmap and wondering whether your current architecture would survive someone asking hard questions about it, that’s a conversation worth having before the roadmap ships, not after.