Regulatory compliance as infrastructure: rules as code, agents at the edges

There is a moment in almost every conversation we have with regulatory teams when someone opens a spreadsheet with forty tabs, one per market, and apologizes for it. They shouldn’t. That spreadsheet is often the most complete encoding of the company’s regulatory knowledge that exists, maintained under pressure by a small team that also has to answer every “can we ship this to Korea?” or “does this ingredient still clear China?” request.

The problem is not the spreadsheet, or the people maintaining it. The problem is that the knowledge has no infrastructure. A formula may have to clear IFRA Standards, the annexes of the EU Cosmetics Regulation 1223/2009, REACH restrictions, national cosmetic ingredient inventories, and market-specific thresholds, prohibitions and exceptions. The rules move: IFRA is moving from its 51st toward its 52nd Amendment, the EU Cosmetics Regulation continues to receive updates, and China’s NMPA has introduced a dynamic mechanism for maintaining its Inventory of Existing Cosmetic Ingredients. Checking one formula against one market is careful work. Rechecking hundreds or thousands of formulas after a change is something else entirely.

The temptation, and where language models actually help

The obvious 2026 move is to hand the problem to a large language model. There is a useful idea buried in that instinct: regulatory material is written for humans, spread across websites, documents and languages, and language models are genuinely useful for navigating it. They can locate relevant passages, summarize amendments, compare documents, translate source material, and turn a question such as “can we use this in Korea?” into the investigation needed to answer it.

But the model should not become the compliance system. A hallucinated threshold is not a minor software bug; it is a compliance failure, and “probably compliant” has no operational meaning. The useful separation is straightforward: use models where the input is ambiguous prose, and code where the answer is a rule.

That means collecting regulatory sources into a structured, versioned database, preserving the original source behind every record, and encoding the requirements that can be evaluated deterministically. The conversational layer then sits on top of that infrastructure rather than replacing it.

Rules as code

The idea is not new. Governments have explored machine-consumable legislation for years, and the same principle applies naturally to regulatory work in formulation. Where a requirement can be expressed deterministically, the system should do exactly that.

An encoded rule needs more than a threshold. It needs the substance or ingredient it applies to, market, product category, conditions and exceptions, effective dates, source document and rule-base version. A compliance check can then become:

this formula + this market + this rule-base version → these triggered rules.

For structured regulation—chemical inventories, prohibited lists, concentration limits and other quantitative restrictions—the difference is dramatic. Work that previously meant manually checking compounds across spreadsheets, websites and source documents for days or weeks can become a database evaluation across an entire portfolio in minutes. Twenty markets are no longer twenty independent searches; for encoded checks, they are a batch query.

The same infrastructure can be rerun whenever regulations change. When an amendment lands, the question becomes not “which spreadsheets do we need to revisit?” but “which formulas are affected?”

Where the agents belong

Not every regulatory question fits neatly into code. Requirements can depend on intended use, ingredient identity, documentation, exceptions or language that requires expert interpretation. Natural complex substances can contribute restricted constituents indirectly, ingredient names may not map cleanly across systems, and new publications can introduce ambiguity.

Those cases should not be forced into pass or fail. Review required is a valid result.

This is where agents are useful. An agent can retrieve a new amendment, identify what appears to have changed and propose an update to the rule base with the supporting source attached. A regulatory expert reviews and approves it before it becomes authoritative. At the other end, when a compliance check is ambiguous, the same interface can surface the relevant records, retrieve the underlying source and translate or summarize it for review.

The division of labor is deliberate: the agent accelerates reading and ingestion; the expert retains authority; the rule base remains deterministic. The objective is not to automate regulatory judgment, but to remove the repetitive work around it.

What this unlocks

Once regulatory knowledge has infrastructure behind it, compliance stops being a search problem repeated from scratch. A team can ask which formulas contain an ingredient newly affected by an amendment, which products clear one market but fail another, which ingredient or dosage prevents a formula from becoming global, or which products need immediate review after a regulatory change. Portfolio triage becomes a query rather than a project.

The same layer moves compliance earlier in development. Formulators can see regulatory constraints while they are designing instead of discovering them at the end. Eventually, optimization and generative formulation systems can use the same rule base as a constraint layer, searching within the permitted regulatory space rather than generating candidates freely and filtering violations afterwards.

Just as importantly, every answer remains traceable. A useful result is not simply “EU: fail.” It is: this formula, evaluated against this rule-base version, triggered this rule, derived from this source, effective from this date. That provenance makes the result reproducible in software, defensible in audits and actionable for product teams.

The aspirational endpoint is a regulatory layer that behaves like type-checking for formulation: always available while you work, almost invisible when everything clears, and precise about what failed when it doesn’t. Regulatory teams should not spend their time repeatedly proving facts a system can check in seconds. They should spend it on the cases where the answer actually requires a regulatory expert.

That is the point of regulatory compliance as infrastructure: not replacing judgment, but making judgment available where it matters.

References