Exploring autonomous regulatory intelligence

An agentic regulatory intelligence system designed to investigate policy changes, determine organizational relevance, preserve supporting evidence, surface uncertainty, and prepare controlled actions for human approval.

A summary is not the same as knowing what to do

Regulatory information rarely arrives as a clean instruction addressed to one organization. It appears across long publications, amendments, government portals, announcements, consultations, and technical guidelines. Even after someone finds the right document, the difficult questions remain: what changed, does it apply here, when does it take effect, and what should happen next?

Large organizations can distribute that work across compliance teams, legal advisers, and public-affairs professionals. Smaller organizations often have less capacity. A missed requirement may only become visible when a deadline is close, an application fails, or an operational problem has already appeared.

ARIA began from a simple observation: summarizing a regulatory publication solves only the reading problem. The more useful system connects a policy change to the organization that may need to respond.

ARIA starts with the organization, not only the document

A generic summary can explain what a publication says, but relevance depends on context. A requirement may apply differently based on jurisdiction, industry, employee count, business activity, licenses, handling of personal information, or whether the organization sells products online.

ARIA therefore works with an organization profile. When a publication appears, the agent does not immediately produce a summary. It first investigates what kind of publication it is and whether it deserves further analysis.

The system distinguishes between new regulations, amendments, proposals or consultations, implementation guidelines, duplicate announcements, and irrelevant publications. That distinction matters because documents can discuss the same subject while carrying very different operational consequences.

The workflow moves from publication to action.

This sequence is what makes ARIA different from a single model response. The system maintains a case around the publication, related evidence, applicability assessment, uncertainty, and proposed actions.

For a relevant change, ARIA prepares an impact brief containing the previous and current requirements, why the change may affect the organization, effective dates, supporting passages, possible exemptions, unresolved questions, recommended actions, and suggested owners or deadlines.

Regulatory status has to come before recommendation

A consultation paper and an enacted requirement can contain similar language, but acting on them as if they carry the same force would be a serious mistake. ARIA therefore identifies the status of a publication before moving into operational recommendations.

The same applies to amendments and implementation guidance. A new document may not replace an earlier rule; it may modify one section, explain implementation, or introduce an exception. The agent needs related documents and version context before it can explain what substantively changed.

This is one reason the project required persistent cases and document-version tracking rather than a stateless question-and-answer interface.

Evidence changes how the agent is allowed to reason

Regulatory explanations can sound convincing even when they are unsupported. Fluency is not evidence. ARIA was designed so that important conclusions remain connected to identifiable source passages.

The system separates its output into three categories: published facts, agent inferences, and unresolved questions. A published fact is explicitly supported by the source. An inference is a conclusion reached by comparing that evidence with the organization profile. An unresolved question is something the available evidence cannot establish confidently.

This distinction makes review easier because the system does not present every sentence with the same level of authority. When evidence is insufficient, uncertainty is part of the output rather than something the model is encouraged to hide.

Exemptions are where shallow analysis breaks

Regulatory language often contains conditions, thresholds, exceptions, and cross-references. A requirement can appear applicable in one passage while another provision narrows its scope. Reading an isolated paragraph can therefore produce a confident but incomplete conclusion.

ARIA investigates surrounding context and can flag possible exemptions rather than treating the first matching passage as the final answer. Where applicability still cannot be established, the issue remains an unresolved question for human review.

The goal is not to make the agent appear certain about everything. The goal is to make uncertainty visible before it becomes an operational decision.

Reasoning and deterministic operations have different jobs

ARIA uses model reasoning for work that requires interpretation and context: classifying publications, comparing policy language, identifying substantive changes, detecting possible exemptions, evaluating organizational relevance, explaining requirements, identifying uncertainty, and producing structured action plans.

Operations that need predictable behavior are handled by deterministic application code. The project description includes numerical threshold checks, date calculations, jurisdiction matching, document version tracking, organization profile storage, approval enforcement, task execution, and audit logging in this category.

This boundary matters because an agent does not become safer by asking the model to do everything. Some decisions benefit from probabilistic interpretation. Others should behave the same way every time.

Structured outputs turn reasoning into system state

Free-form prose is useful for people, but difficult for software to validate and act on. ARIA uses structured outputs for policy changes, evidence, applicability assessments, uncertainties, and proposed actions.

That allows downstream application code to inspect the agent's work before anything is executed. It also keeps proposed actions connected to the regulatory case and the evidence that produced them.

The project uses typed tools and data models to give the agent explicit capabilities instead of unrestricted access to the application. This makes the workflow easier to test, reason about, and audit.

Autonomy stops at the execution boundary

ARIA is intended to work independently where autonomy is useful: monitoring, investigating, comparing, gathering evidence, assessing relevance, and preparing a plan. But preparing work is different from committing an organization to an action.

The system therefore requires explicit human approval before creating anything in an external system. An agent can prepare tasks, reminders, and internal briefings, but external execution remains behind an approval boundary.

This is a practical definition of controlled autonomy. The system can reduce the amount of research and preparation a person has to perform without removing accountability from the person responsible for the organization.

The hardest part was making an agent, not a summarizer

A document summarizer can accept text and return an explanation. ARIA needed more: organization profiles, related publications, persistent regulatory cases, evidence, deterministic tools, structured outputs, approval controls, and an execution record.

Those pieces create a loop in which the agent can discover a publication, decide whether it warrants investigation, find a related version, identify substantive changes, compare them with an organization, support conclusions with evidence, surface uncertainty, prepare an action plan, and wait for approval.

The difference is operational. A summarizer produces content. ARIA is designed to maintain enough context and state to move from information toward controlled work.

Evaluation focused on failure modes that matter

The project description identifies evaluation scenarios around irrelevant publications, jurisdiction mismatches, threshold changes, duplicate documents, proposals, hidden exemptions, and unclear effective dates. These are not cosmetic edge cases; they test whether the system knows when not to recommend an action.

The source material does not provide a final verified count of evaluation scenarios, so this case study does not invent one. It also leaves the final production stack and initial jurisdiction unspecified because those details were placeholders in the project description.

That restraint is intentional. A portfolio case study is stronger when it clearly separates implemented design decisions from details that have not been finalized or verified.

What ARIA demonstrates

ARIA demonstrates a complete agent workflow rather than a chatbot wrapped around regulatory documents. Its value comes from the connection between organization context, document comparison, evidence, uncertainty, action planning, and human approval.

It also demonstrates an engineering pattern that extends beyond regulation: use language models where interpretation is valuable, deterministic code where predictability matters, structured data between the two, and explicit boundaries before external action.

ARIA is not intended to replace lawyers, compliance professionals, or regulators. It is designed to give organizations an earlier warning, a clearer starting point, and a more structured path from a policy publication to the questions and actions that deserve human attention.

What we learned

A capable language model is only one component of a useful agent. Persistent state, specialized tools, evidence requirements, deterministic validation, structured outputs, and execution controls are what turn model reasoning into a system that can participate in real work.

We also learned that grounding is architectural. Requiring evidence affects retrieval, comparison, data models, output schemas, review interfaces, and action records. It cannot be solved reliably by adding citations as decoration at the end.

Finally, autonomy does not mean removing people. A useful agent can perform substantial research and preparation independently while still giving humans control over consequential actions.

The principle we carried forward.

Regulatory intelligence becomes useful when a decision can be traced from source, to reasoning, to action.

ARIA began as an attempt to move beyond regulatory summarisation. The result is a system design in which evidence, organisational context, uncertainty, and approval are part of the workflow itself.

That is the larger lesson for agentic AI. The question is not only whether an agent can produce a good answer. The question is whether the surrounding system makes that answer trustworthy enough to support the next piece of work.

Project notes

This case study is based on the documented ARIA project description. It intentionally does not fill unresolved placeholders for the final technology stack, initial jurisdiction or regulatory domain, or evaluation-scenario count.

The project is presented as an agent-system case study and not as legal advice, a legal service, or a replacement for professional regulatory judgement.