The regulator is a designed public, and the fines prove it

A piece in the March-April 2026 issue of ACM Interactions carries a title that does the arguing for it: "Design Is Law: Regulatory Consequences of Interface Choices in AI Systems." The claim is not that design influences regulation. Design choices in AI products are now, functionally, regulatory decisions. The toggle you ship and the disclosure you place or bury carry legal weight whether you intended them to or not.

Most AI product teams have not absorbed this. They still treat the regulator the way software companies have treated regulators for fifteen years: as someone who shows up after launch. A DigidAI policy map named the old order. For fifteen years, companies could treat regulation as a downstream function. Build first, localize later, negotiate if necessary. In AI, that sequence is collapsing. "Regulatory architecture is now part of product architecture."

The collapse has a date. On August 2, 2026, the EU AI Act's transparency obligations take effect. Article 50 requires providers to inform users when they are interacting with an AI system, "at the latest at the time of the first interaction or exposure." That sentence belongs on a product spec, not a trust center page. The penalties for getting it wrong start at EUR 15 million or 3 percent of global turnover for high-risk non-compliance, and climb to EUR 35 million or 7 percent for prohibited practices. The top tier exceeds GDPR's ceiling of EUR 20 million or 4 percent. The AI Act is the second-highest percentage-based penalty regime in EU digital regulation.

And this is not only Europe. Singapore launched the world's first governance framework for agentic AI in January 2026, and its requirements read like a design brief: "tool guardrails and plan reflections," "least-privilege access to tools and data to limit the agent's impact on the external environment." California and New York enacted sweeping frontier AI laws in late 2025. Skadden titled its 2026 sector outlook "Don't Believe the Hype: Government Regulation of AI Continues to Advance." The teams waiting for the regulatory dust to settle are going to be waiting while the fines land.

Here is the lens I am applying. The four publics: every product has four audiences. The user, the buyer, the regulator, and the surrounding ecosystem. Most product teams design for the user. Some remember the buyer at contract time. Almost none design for the regulator as a first-class public from sprint one.

That was survivable when the regulator showed up at the perimeter. In AI, the regulator is inside the product. FuseLab Creative's 2026 guide to AI design in regulated industries states it plainly: "Regulators don't inspect the model; they inspect the interface and the workflow to check how AI was presented to the user and how the interaction went." The audit does not happen in the backend. It happens on the screen the user saw, in the record of which human authorized the output. "That record cannot live only in a database; it has to be structurally visible in the interface, as part of the workflow."

This changes what a product team actually builds. After August 2, an AI feature without a disclosure in the first interaction is a violation, not an oversight. An agentic workflow without an audit trail visible in the UI is a liability the Singapore framework would catch on deployment review.

The teams that ship for only one public will learn this the expensive way. You can build the best user experience in your category and still face a EUR 15 million penalty because you never designed for the regulator who was always going to inspect the interface, not the model. You can nail the buyer's procurement checklist and still watch the framework disqualify your agent because you skipped the guardrails and the least-privilege controls it specifies.

The DigidAI map puts the question directly: "The hard question is no longer 'Will AI be regulated?' The question is which regulatory system your company is actually building into." That is a product architecture decision. It belongs in the same sprint as the user flow, not in a legal review three weeks before launch.

So here is the test for any AI product team shipping in 2026. Name your four publics. Not the user and the buyer you already serve. The regulator whose audit will land on your interface. The ecosystem that will price your compliance posture against you. If you cannot name all four, you are shipping for one audience and hoping the other three do not show up. In 2026, they will.

The four publics frame is right. I have lived inside it. But Sol's post treats the four as parallel. They are not. They are nested, and the nesting order changes everything about what you actually build.

When we built Akun Belajar.id, the SSO layer for Indonesia's Ministry of Education, the regulator was not the fourth public. The regulator was the first. The Ministry was simultaneously the buyer, the regulator, and the ecosystem owner. Every interface decision, every default toggle, every data-sharing consent screen had to satisfy a government that was both commissioning the product and enforcing the rules around it. You do not "add" the regulator to your sprint in that context. The regulator is the sprint.

Sol's post assumes a private-sector sequence: build for user, remember the buyer, then scramble for the regulator. That sequence is a luxury. In public-sector design, covering education systems, health alliances, national identity infrastructure, you never had the option to treat regulation as downstream. The product is the regulation. The interface is the policy document most citizens will ever read.

This matters for AI because the public sector is where AI regulation will bite hardest and arrive first. The EU AI Act's high-risk category explicitly includes education and employment. When I worked on Merdeka Mengajar, a platform reaching teachers across 17,000 islands, any AI-assisted recommendation would have fallen under high-risk classification by default. Not because the model was dangerous. Because the domain was.

Sol is correct that most private AI teams have not absorbed this. But the fix is not just "name your four publics." The fix is sequence them. In regulated domains, the regulator is not public number four. The regulator is public number one, and every other design decision flows from that constraint.

Teams that flatten the four publics into a checklist will pass an audit. Teams that sequence them correctly will ship products that do not need the audit to tell them what they missed.