The next phase of Power Platform adoption is not only about building more apps and automations.

It is about deciding what Copilot and AI agents should be allowed to know, recommend, change, approve, and communicate.

That question is becoming more important as organisations move from individual Copilot features to agents that can retrieve business information, use connectors, trigger workflows, interact with employees or customers, and influence operational decisions.

The opportunity is significant.

A well-designed agent could help an employee find a policy, summarise a customer record, prepare a response, route a request, update a system, or coordinate steps across multiple applications.

But capability without boundaries creates risk.

An agent may retrieve information beyond its intended purpose. A maker may connect it to a business system without sufficient review. A workflow may allow an AI-generated recommendation to become an automatic action. An externally available agent may expose information that was only meant for authenticated employees.

This is why responsible AI in Power Platform cannot remain a set of principles on a slide.

It needs to become an operating model.

For UK organisations, that operating model should connect Copilot adoption with data protection, security, business ownership, human accountability, and measurable controls.

The objective is not to stop innovation.

It is to make innovation safer to scale.

Why Responsible AI in Power Platform matters in 2026

Power Platform is no longer limited to conventional low-code applications and workflow automation.

Power Apps, Power Automate, Dataverse, Power Pages, Dynamics 365, and Copilot Studio can now be combined to create increasingly intelligent business experiences.

An agent may:

• answer questions using organisational knowledge
• access data through connectors
• call a flow or business process
• create or update records
• send information to another system
• guide a user through a decision
• act when a defined event occurs
• hand an interaction to a person

Each capability changes the risk profile.

A knowledge assistant that retrieves public product information does not require the same controls as an agent that accesses employee records, updates customer data, approves a refund, or initiates a financial transaction.

A useful AI governance framework must therefore distinguish between use cases.

It should not apply one vague policy to every Copilot or agent.

Instead, it should define boundaries according to data sensitivity, business impact, user audience, action authority, and the consequences of an incorrect response.

What does a responsible AI boundary mean?

A boundary is a clear decision about what an AI-enabled solution can and cannot do.

It may define:

• which environment the agent belongs in
• which data sources it can access
• which connectors it can use
• who can edit or share it
• whether users must authenticate
• which actions require human approval
• what information must never appear in a response
• how conversations and outcomes are monitored
• who owns the agent after deployment
• when the agent must refuse, escalate, or stop

These boundaries turn broad AI principles into operational controls.

They also make governance easier to explain to makers.

Instead of saying, “Build responsibly,” the organisation can say:

“You may use these approved data sources, within this environment, for this audience, provided that these actions remain human-approved and these tests are completed before release.”

That is much clearer.

Boundary 1: Define the purpose before selecting the technology

Responsible AI begins with the use case.

Before choosing Copilot Studio, AI Builder, Power Automate, or another capability, define the business problem and the intended outcome.

Ask:

• Who will use the solution?
• Who could be affected by its output?
• What decision or process will it support?
• What data does it genuinely require?
• What happens if its answer is wrong?
• Can a user challenge or correct the outcome?
• Is generative AI necessary for this use case?
• Could a deterministic workflow solve the problem more safely?

This prevents teams from introducing AI simply because the capability is available.

For example, an agent that helps employees locate internal IT guidance may be low risk.

An agent that recommends disciplinary action, prioritises vulnerable customers, assesses employee performance, or changes financial records carries a much higher level of responsibility.

The more significant the outcome, the stronger the governance should be.

A practical risk classification could separate use cases into three levels:

Low-risk assistance

The agent retrieves low-sensitivity information, drafts content, or helps users navigate a process. It does not make consequential decisions or change critical records.

Controlled business support

The agent uses internal data or initiates actions, but users remain responsible for reviewing and confirming important outcomes.

High-impact or sensitive use

The agent influences decisions affecting employment, finance, safety, legal rights, regulated activity, vulnerable people, or sensitive personal information.

High-impact use cases should receive formal review before development progresses.

The first boundary is therefore simple:

No agent should be approved without a defined purpose, audience, owner, data need, and risk level.

Boundary 2: Separate agents by environment and risk

The Default environment should not become the production home for every experiment.

Power Platform environments create important organisational boundaries around data, applications, makers, permissions, connectors, and deployment stages.

A responsible environment model might include:

• personal developer environments for individual experimentation
• innovation or sandbox environments for early concepts
• departmental environments for controlled internal solutions
• production environments for approved business agents
• restricted environments for sensitive or high-impact use cases

The governance applied to each zone should reflect its risk.

An experimental agent using non-sensitive sample data may need lightweight controls.

A production agent connected to Dataverse, Dynamics 365, HR systems, finance systems, or customer records should have stronger restrictions around maker access, authentication, sharing, connectors, deployment, and monitoring.

Before production, confirm:

• the agent is in the correct environment
• development and production are separated
• production editing is restricted
• security groups control environment access
• solutions and deployment pipelines are used where appropriate
• the owner is an active, accountable employee
• business continuity does not depend on one maker’s account
• the environment has appropriate data policies

The aim is not to create unnecessary administration.

It is to prevent an agent from moving directly from informal experimentation to business-critical use without a controlled transition.

Boundary 3: Control business data and connectors

The most important boundary is often the data boundary.

An agent should not gain access to information simply because a connector exists or because a maker can technically configure it.

Organisations need to decide:

• which systems agents may access
• which connectors are approved
• which connectors must never be combined
• which data classifications are permitted
• whether external services can receive business information
• whether the agent can write data or only retrieve it
• which fields, tables, documents, or records are in scope
• how user permissions are respected
• what information should be masked or excluded

Data policies can help prevent unsafe combinations of business and non-business connectors and can restrict selected Copilot Studio capabilities.

But a policy alone is not enough.

Business data boundaries should also be expressed in solution design.

An employee policy agent, for example, may need access to approved HR guidance but not individual salary records.

A customer-service agent may need order status and case information but not unrestricted access to the full finance system.

A sales agent may be allowed to summarise an account but should not automatically alter commercial terms.

Use the minimum data necessary for the purpose.

Then document why each data source, connector, plugin, knowledge source, and action is required.

A strong data boundary answers four questions:

1. What can the agent read?
2. What can it write or trigger?
3. Who is entitled to receive the response?
4. Where could the information travel next?

Boundary 4: Control identity, authentication, and sharing

An agent that works correctly for an authenticated employee may become unsafe when shared too broadly.

Before publishing, define the intended audience:

• one business team
• selected security groups
• all employees
• named partners
• authenticated customers
• anonymous public users

The authentication model should match the information and actions available.

Anonymous access should not be used merely because it reduces friction.

Where an agent accesses internal data, personal data, customer records, operational systems, or user-specific information, authenticated access will usually be the more appropriate model.

Sharing controls are equally important.

Administrators and solution owners should know:

• who can edit the agent
• who can use it
• who can share it further
• which channels it is published to
• whether external access is possible
• whether security groups are required
• whether anonymous endpoints are permitted
• how access is removed when roles change

This boundary should also cover agent identity.

Users should understand:

• that they are interacting with AI
• what the agent is designed to do
• which organisation or team owns it
• when responses may be incomplete
• how to escalate to a person
• how to report an unsafe or incorrect answer

Transparency is not a disclaimer hidden at the bottom of a page.

It should be part of the user experience.

Boundary 5: Keep people accountable for consequential actions

Human oversight should not be reduced to placing an approval button at the end of an unreliable process.

The level of oversight should match the consequence of the action.

For low-risk tasks, the user may simply review an AI-generated draft.

For controlled operational tasks, a person may need to confirm the proposed action before a flow updates a record or contacts a customer.

For high-impact decisions, the agent should support human judgement rather than replace it.

Examples of actions that may require explicit human approval include:

• approving payments or refunds
• changing contractual or commercial terms
• closing a regulatory or safety action
• altering employment-related records
• granting access or permissions
• communicating legal or compliance conclusions
• making decisions about vulnerable customers
• deleting or materially changing important records

Human oversight should be meaningful.

The reviewer needs enough context to understand:

• what the agent recommends
• which information was used
• what action will occur
• what the impact could be
• how to reject or modify the recommendation
• where to record the reason for the decision

The person approving the action should remain accountable.

The phrase “the AI decided” should never become an acceptable explanation for an important business outcome.

Boundary 6: Test behaviour, not only functionality

Traditional application testing asks whether a feature works.

Agent testing also needs to ask how the solution behaves when the situation is incomplete, ambiguous, adversarial, or outside its intended purpose.

Before deployment, test:

• accurate and expected questions
• vague or incomplete prompts
• requests outside the agent’s scope
• attempts to retrieve restricted information
• prompt-injection scenarios
• misleading or conflicting source content
• harmful or inappropriate requests
• requests to bypass approval
• attempts to impersonate another user
• incorrect data in a source system
• unavailable connectors or downstream services
• unsupported languages or terminology
• repeated questioning designed to reveal protected information

Evaluate more than response quality.

Assess:

• groundedness
• relevance
• consistency
• refusal behaviour
• data exposure
• action accuracy
• escalation behaviour
• fairness
• accessibility
• user understanding
• recovery from failure

Testing should involve business owners, platform teams, security specialists, data owners, and representative users.

A technically convincing answer may still be operationally unsafe.

For example, an agent may produce fluent guidance that conflicts with an approved policy. It may correctly identify a customer but expose more information than the user needs. It may trigger the right flow using the wrong record.

Production approval should therefore require documented acceptance criteria.

The boundary is:

An agent should not go live simply because the demonstration worked.

Boundary 7: Monitor, review, and retire

Responsible AI is an ongoing responsibility.

An agent can change even when its original instructions remain unchanged.

Its knowledge sources may be updated. A connector may change. A business process may evolve. New users may begin asking different questions. A previously low-risk use case may expand into a more sensitive role.

After go-live, monitor:

• usage and adoption
• failed or abandoned conversations
• escalation rates
• incorrect or unsafe responses
• actions triggered
• connector dependencies
• policy and governance warnings
• cost and Copilot consumption
• ownership changes
• complaints and user feedback
• changes to source content
• unusual access or sharing patterns
• agents with little or no business value

Maintain an inventory containing:

• agent name and purpose
• business owner
• technical owner
• environment
• audience
• data sources
• connectors and actions
• authentication model
• risk classification
• approval date
• last review date
• planned retirement date or review trigger

Every production agent should have a review rhythm.

Low-risk agents may be reviewed quarterly.

Higher-risk agents may need more frequent operational, security, and business reviews.

The organisation should also define retirement criteria.

An agent should be disabled or retired when:

• its owner leaves without replacement
• its purpose is no longer valid
• its source data is no longer trusted
• it duplicates another approved capability
• it creates persistent risk
• it is not being used
• it cannot meet updated governance requirements

AI governance includes knowing when to stop.

A practical Copilot governance operating model

Good copilot governance connects central standards with local business ownership.

A workable model may include:

AI governance or risk leadership

Defines the organisation’s principles, prohibited scenarios, high-risk review requirements, and escalation path.

Power Platform administration

Manages environments, data policies, inventory, sharing controls, authentication settings, capacity, monitoring, and platform configuration.

Business owner

Owns the use case, business outcome, source content, user impact, and continued need for the agent.

Data owner

Approves the data sources, classification, access model, retention expectations, and permitted uses.

Security and privacy teams

Review identity, exposure, personal-data implications, logging, external access, and incident response.

Maker or delivery team

Builds within the approved design, documents the solution, completes testing, and supports remediation.

Human reviewer or operational team

Reviews consequential recommendations, handles escalations, and provides feedback on real-world performance.

The technology team should not be expected to decide every ethical or business question alone.

Likewise, business teams should not deploy agents without technical and data-governance controls.

Responsible AI is shared accountability with clearly assigned decisions.

A 30-day Responsible AI starting plan

Week 1: Discover what already exists

Build an inventory of Copilot features, Copilot Studio agents, AI Builder models, AI-enabled flows, knowledge sources, connectors, environments, owners, and audiences.

Identify ownerless, anonymously accessible, externally shared, or production-connected agents first.

Week 2: Classify the use cases

Group agents by business purpose, data sensitivity, action authority, user audience, and potential impact.

Identify prohibited or high-impact scenarios requiring formal review.

Week 3: Apply the essential boundaries

Review environments, data policies, connectors, authentication, sharing, human approvals, monitoring, and production access.

Prioritise agents connected to sensitive data or capable of taking actions.

Week 4: Establish the governance rhythm

Define approval stages, review frequency, incident handling, performance reporting, change control, user feedback, and retirement criteria.

Create a repeatable process rather than a one-time clean-up.

Final thought

Responsible AI does not mean removing every possibility of error.

It means knowing where risk exists, limiting the consequences, making accountability visible, and responding when the system behaves differently from what was intended.

For Power Platform, the most important question is not:

“Can we build this Copilot or agent?”

It is:

“Can we explain what it is allowed to do, which data it may use, who remains accountable, and how we will know when something goes wrong?”

Clear boundaries help makers innovate with confidence.

They help administrators govern at scale.

They help business owners trust the solution.

And they help users understand when AI is assisting them and when a person must remain in control.

That is how responsible AI in Power Platform moves from principle to practice.

---

At Osmosys, we help organisations introduce Copilot and agents with practical governance across Power Platform environments, business data, connectors, authentication, human approvals, testing, and ongoing monitoring.

If your organisation is moving from isolated Copilot experiments to wider agent adoption, this is the right time to define the boundaries before capability scales faster than control.

---

FAQ