AI Agents for Regulated Industries: The Architecture Behind Microsoft Copilot Studio

Real use cases and system design for regulated environments across Australia

AI in regulated industries is no longer a slide in a strategy deck. It is operational. The conversation has moved from “should we” to “how do we introduce it without unpicking the controls that keep this organisation defensible”.

That is the question Microsoft Copilot Studio is being adopted to answer. AI agents are built to take a user request through to a governed outcome, using approved information, inside Microsoft environments that already carry the organisation’s identity, audit and compliance posture.

This piece is about what that architecture looks like, where each layer earns its place, and the patterns we see when agents go live in real regulated environments.

What does AI agent architecture look like in regulated industries?

AI agent architecture for regulated industries connects key Microsoft technologies into a single governed operating model, with Microsoft Copilot Studio acting as the entry point where requests arrive and are directed through workflow and data layers.

Each layer has a defined role:

• Microsoft Copilot Studio manages how users interact with the agent
• Microsoft Power Automate carries out workflow execution and process progression
• Microsoft Dataverse and Microsoft SharePoint provide access to structured data and approved content
• Microsoft Entra ID, sensitivity labels and Microsoft Purview govern user access, classification and audit

Sitting underneath all of it, Microsoft Dataverse provides the row level security, environment separation and audit history that makes the rest of the architecture defensible when scrutiny arrives.

How do AI agents connect interaction with workflow action?

The architecture is best understood as three functional layers, each carrying real operational weight.

1. Interaction layer

This is where users engage with the agent. Built using Microsoft Copilot Studio, the agent interprets a natural language request and works out what information or action is required.

In a regulated environment, that shows up in scenarios like:

• A caseworker asking “what’s the precedent for refusing this type of application?” before drafting a recommendation
• A field inspector asking “does this regulation apply to a class B facility?” while standing on site
• A frontline officer asking “what’s the current status of submission 12345?” without opening four different systems to find out
• A new staff member asking “what’s our policy on secondary employment approvals?” instead of guessing or interrupting a senior colleague

How the request is interpreted determines how it moves through the rest of the architecture. Interpretation is not a clever feature. It is the moment the agent decides which controls apply.

2. Execution layer

Once a request is understood, the agent can trigger an action through Microsoft Power Automate. This is where the architecture stops talking and starts doing.

Typical execution patterns in regulated environments include:

• Routing an approval to the right delegate based on dollar value, jurisdiction or risk category
• Generating a structured briefing note from a long correspondence chain and placing it in the right queue for human review
• Updating a case record with the information the agent retrieved, so the next person who picks up the file does not redo the work
• Initiating a follow up task, notification or reminder against a statutory timeframe

The point is not that Power Automate is doing anything new. It is that the action now sits inside the same audit trail as every other workflow in the organisation.

3. Data layer

AI agents rely on Microsoft Dataverse and Microsoft SharePoint to access the organisation’s information.

Microsoft Dataverse holds the structured business data: records, transactions, case files, licence registers, applicants and entities. Microsoft SharePoint holds the approved content: policy libraries, procedure manuals, ministerial directives, internal guidance.

Because the agent is grounded in these systems, responses are based on information the organisation already manages, classifies and trusts. Sensitivity labels and row level security carry through, which means a response is shaped by what the user is allowed to see, not by what the model happens to know.

In regulated environments, that is the whole game. An agent that answers from approved data is useful. An agent that answers from somewhere else is a problem looking for an incident report.

How this looks in practice: an end-to-end example

A community services caseworker is reviewing an applicant’s eligibility for an emergency housing payment. The case is time sensitive and the caseworker is not the original assessor.

In Microsoft Teams, the caseworker asks the agent: “Is this applicant eligible for an emergency housing payment, and what’s the most recent precedent for cases like this?”

In the interaction layer, Microsoft Copilot Studio interprets the request as two intents: an eligibility check against the applicant record, and a precedent lookup against approved guidance.

In the data layer, the agent retrieves the applicant’s case record from Microsoft Dataverse, applies row level security so only the fields this caseworker is permitted to see come back, and pulls the relevant eligibility criteria and recent decision precedents from a SharePoint policy library that is already classified and version controlled.

In the execution layer, Microsoft Power Automate writes a structured note back to the case record showing what was asked, what was retrieved and which policy version was referenced, then offers to start the assessment workflow with the relevant manager pre-populated as the approver.

The caseworker gets a defensible answer in under a minute. The organisation gets an auditable record of how that answer was produced. The architecture did exactly what it was designed to do, which is the point.

How is control maintained in AI agents for regulated industries?

AI agents for regulated industries operate inside Microsoft’s existing security and governance model. Access to information is determined by user roles, and responses are shaped by what each person is permitted to see.

This aligns with how Microsoft 365 implementation in regulated environments is already managed. Permission settings, identity controls and sensitivity labels carry through to the agent experience without a parallel access model to maintain.

In practice, this means:

• Responses reflect user permissions, not the model’s training data
• Actions follow approved workflow pathways, with the same approvers and SLAs that already apply
• Interactions can be reviewed where required, including which sources were used
• Sensitive data remains governed by the labels and classifications already attached to it

In regulated environments, this is where architecture matters most. It is the difference between AI as a capability and AI as a liability.

Common patterns we see when AI agents enter regulated environments

The architecture above is straightforward. The operational reality around it is where most of the work happens. These are the patterns we see most often:

• Agents that look brilliant in the demo and useless on a Tuesday because the grounding data was never properly prepared
• Citizen-facing agents pushed live before the content library is curated, leading to answers no one in the organisation would actually stand behind
• Agents that produce confident responses no one can audit, because the prompt, the source and the action were never tied to a single record
• Sensitivity labels that exist on paper but are not enforced in the data the agent can reach
• Organisations treating the agent as the solution, rather than the operating model and workflow design around it

None of these are AI problems. They are governance, content and process problems that the agent quietly exposes the moment it goes live. The architecture is what gives you the space to address them properly.

Why this architecture fits regulated environments

Systems in regulated industries are designed for accountability and public trust. New capability has to align with that from the start, not be retrofitted to it later.

AI agents built on Microsoft Copilot Studio sit inside the systems agencies already use. They create a more direct way for people to interact with information and processes while keeping the controls intact around them.

This is particularly relevant for legacy application modernisation in Australia, where new capability has to integrate with existing platforms and support gradual, governed uplift rather than a wholesale replacement program.

How The Factor delivers AI agent architecture for regulated industries

At The Factor, we design and deliver AI agents using the Microsoft technologies already in place across regulated environments. As a Power Platform partner for regulated industries in Australia, we build solutions that align with governance requirements and fit inside existing operating models from day one.

That includes work across Microsoft Business Applications in Australia and Microsoft Dynamics 365 environments where required. The focus is practical adoption: introducing AI capability into operational processes without disrupting the systems and controls teams already rely on.

Good architecture should feel like it belongs there from the start. Quietly useful, properly governed, and ready for the real world.