Governing Copilot and AI Agents Over Dynamics 365 Data You Do Not Fully Trust

Why is switching Copilot on over unreliable Dynamics 365 data the wrong first step?

Copilot does not fix data; it summarises and drafts from whatever the user can already see. If account records are duplicated, opportunity notes are years out of date and case histories mix two customers, the assistant produces fluent, confident summaries of the wrong facts, and it does so faster than a person reading the record would. The board sees a demo on clean sample data; the sales team sees a summary that names the wrong decision maker.

The pressure to deploy is real, and refusing outright rarely survives the next board meeting. The defensible position is a sequence: measure the data Copilot will read, expose only what passes, pilot narrowly with review, and widen scope on evidence. That turns "we are not ready" into a plan with a date attached to each gate rather than a veto.

• Wrong facts stated confidently: a summary built from a stale or duplicated record reads as authoritative.
• Over-exposure: an assistant respects security roles, so any over-broad access the security model already grants becomes easier to discover.
• Unreviewed personal data in drafts: an email draft can pull details from notes that should never leave the organisation.
• Cost without a baseline: consumption starts before anyone has agreed what a useful outcome would look like.

What can Copilot in Dynamics 365 actually do today that justifies the cost?

The honest answer is narrower than the marketing and more useful than the sceptics admit. Copilot works best where the value is saving a person from reading a lot of history they already have access to, or from writing the first draft of something a human will check. It works worst where it is asked to generate new facts over data nobody trusts. Exact feature names and availability depend on your licences, region and release wave, so treat the table as categories to test, not a feature list.

Which Dynamics 365 tables and columns does Copilot read, and how do you measure their quality?

Start from the scenarios you intend to pilot, not from the whole database. Each scenario reads a small, knowable set of tables: the record itself, its related parent records, the activity timeline, notes and attachments, and, for knowledge-grounded answers, the knowledge articles or other sources an agent is connected to. Measure those, with numbers you can recompute every month, and publish the results before anyone argues about readiness.

The measurement below is a readiness check, not a full audit. If the numbers are poor across the board, or the security model itself is in doubt, run the Dynamics 365 health check and technical audit first, which covers data quality, security roles and configuration in depth, rather than repeating that work inside a Copilot project.

How do you define and scope a trusted cohort for a Copilot pilot?

A trusted cohort is a set of users and records that passes your quality measures, is small enough to review, and represents real work. Built-in Copilot features generally work on whatever the signed-in user can access, so the practical levers are who gets the feature and what those users can see. Copilot Studio agents add a further lever, because you choose the knowledge sources and data an agent is grounded in.

• Pick one team and one scenario, for example key account managers summarising account history, or a single service queue summarising cases.
• Mark the trusted records explicitly, for example with a data quality status column set by a reviewed cleanup, so the cohort is auditable rather than a vague agreement.
• Scope the users through a security group or team, enabling the feature only for them where the product allows it, and keep everyone else on the current process.
• Where an agent is involved, ground it only in the views, tables and knowledge sources that belong to the cohort, not in the whole environment.
• Write down the exit criteria before the pilot starts: what reviewers must find acceptable, how often, and what would stop the pilot.
• Keep a control group doing the same work without Copilot, so the value discussion rests on comparison rather than enthusiasm.

Why should a Copilot pilot be read-only before any agent is allowed to write?

Reading and drafting fail safely: a bad summary is ignored and a bad draft is edited. Writing fails into the system of record, where a wrong update is copied to reports, integrations and the next summary. So the order is fixed: summaries and drafts first, then actions proposed by the assistant and confirmed by a person, and only then narrowly scoped actions that run unattended.

When an agent does need to change data, such as updating a case or creating a lead, build that action as a governed flow with validation and logging, as described on our Copilot Studio agent development page, rather than granting broad write access. The same flow is where you enforce which fields may change and who is recorded as having changed them.

Where do human review gates and compliance checks belong when PII or regulated data is involved?

Before rollout and at every point where content leaves the screen of the person using the assistant. Compliance review is easier when it is asked concrete questions about a defined pilot than when it is asked to approve "Copilot" in general. Solzet does not give legal or regulatory advice; your data protection and compliance teams make the calls, and we supply the technical facts and build the controls they choose.

• A data protection impact assessment scoped to the pilot scenario, the tables in scope and the users in the cohort.
• Confirmation of where prompts and responses are processed, including any tenant or environment settings that allow data to move across geographies for generative AI features, and a decision recorded on each.
• Column security or removal from scope for special category data, health data, financial identifiers and anything the regulator treats as sensitive.
• A rule that no AI-drafted customer communication is sent without a named person approving it during the pilot.
• A review of retention for transcripts and logs, so the audit trail does not itself become an unmanaged store of personal data.
• Staff guidance that states plainly what the assistant is for, what it must not be used for, and how to report a wrong or inappropriate output.

How do you produce an audit trail of what the assistant saw and did?

Assemble it from several layers, because no single log answers every question an auditor asks. Decide before the pilot which question each layer answers, confirm what is actually captured for the specific features you enable in your tenant, and test that you can retrieve an example end to end.

What drives Copilot consumption cost, and how do you cap it?

We do not quote prices, because Microsoft sets and revises them, but the cost drivers are stable enough to plan around. Some Copilot capabilities in Dynamics 365 apps are included with qualifying Dynamics 365 licences, subject to region and admin settings. Copilot Studio agents are billed on consumption, in units Microsoft defines per type of interaction, bought as prepaid capacity or billed pay-as-you-go through an Azure subscription. Generative answers and agent actions generally consume more than simple scripted responses, and autonomous agents triggered by events consume without anyone typing a message. Check the current Microsoft licensing guide for the specifics that apply to your agreement before committing a budget.

• Know which of your scenarios use included app features and which need Copilot Studio capacity; the budget conversation is different for each.
• Allocate capacity to specific environments so a pilot cannot draw down capacity intended for production agents.
• For pay-as-you-go, set Azure budgets and alerts on the billing subscription, so overspend is noticed in days rather than on the invoice.
• Limit channels and audiences: an internal agent in Teams for a cohort costs a fraction of the uncertainty of a public website agent.
• Review autonomous triggers carefully; an event-driven agent on a busy table can consume steadily without any user involved.
• Measure consumption per scenario during the pilot and use that, not a vendor estimate, to model wider rollout.

When is a different tool, or no AI at all, the better answer?

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both.

The same honesty applies to AI. If the underlying process is not in the CRM at all, a Copilot rollout adds cost to a system people avoid; fixing the process and the data comes first, and for sales teams our Dynamics 365 Sales implementation page describes that work. If answers must be fully deterministic and traceable at every step, a structured app or automated flow is better than a conversation. If Microsoft licensing does not fit the organisation, a custom CRM on React, Node.js, PostgreSQL or .NET can include narrowly scoped AI features where you control the model, the data sent and the logging.

How does Solzet run a Copilot readiness and governance engagement?

Senior consultants with 8+ years of Dynamics 365 Customer Engagement and Power Platform delivery run it as a short sequence with a decision at each gate. It produces a pilot you can defend to the board and to compliance, or a documented reason to wait.

• Scenario selection with the business owner: which one or two uses are worth testing and what a useful outcome looks like, described qualitatively rather than as a promised return.
• Readiness measurement on the tables those scenarios read, or a full health check where the wider build is in doubt.
• Cleanup of the trusted cohort, security scoping and the compliance pack: scope, data flows, settings decisions and review gates.
• Pilot configuration, including any Copilot Studio agents and governed flows, deployed through managed solutions.
• Audit trail and consumption monitoring set up and tested before users start.
• A pilot review against the written exit criteria, with a recommendation to widen, adjust or stop.