Exploratory AI Architecture for Pharmaceutical Product Development and Stability Sample Knowledge Management
Using Microsoft Copilot Studio, SharePoint Metadata, Microsoft Purview, Power Platform, Outlook and Microsoft Teams as a Conceptual Citizen Development Architecture
Important Disclaimer
This article is a technology exploration and educational architecture exercise only.
The scenario described below is hypothetical. It does not represent an implemented pharmaceutical system, a validated computerized system, a validated GxP process, or a recommendation for managing regulated pharmaceutical records.
Nothing in this article should be interpreted as pharmaceutical, regulatory, quality, validation, laboratory, clinical, manufacturing or compliance guidance.
The architecture deliberately simplifies many requirements that could apply to a real pharmaceutical organization. Depending on the intended use, applicable regulations, company procedures and jurisdiction, a production implementation could require formal validation, computerized system validation, data-integrity controls, electronic-record and electronic-signature requirements, audit trails, segregation of duties, records management, change control, security assessments, supplier qualification and Quality approval.
In particular, SharePoint Lists, Power Apps, Power Automate, Copilot Studio, Outlook, Teams or Generative AI should not automatically be considered suitable Systems of Record for regulated laboratory, stability, quality or product-development information simply because they can technically store or process that information.
In this article, Generative AI is treated primarily as a Knowledge, communication, classification and assistance layer. It is not considered an authority for stability decisions, specification assessment, product release, quality disposition, regulatory decisions or other controlled pharmaceutical decisions.
Any real implementation would require evaluation and approval by the appropriate organization’s Quality, Regulatory, IT, Security, Data Integrity and Validation functions.
1. The Scenario
Consider a hypothetical pharmaceutical organization developing new products.
During product development, different groups collaborate around formulations, analytical methods, technical documents, development reports, protocols, project information and stability studies.
Stability activities generate another important information domain.
Samples may be placed under defined study conditions and analyzed according to approved schedules. Teams need visibility into what information exists, which project it belongs to, which documents are current, which activities require attention and what information can appropriately be communicated to different audiences.
For this conceptual exercise, we are not going to attempt to build a stability-management system.
Instead, we will explore a collaboration and Knowledge architecture surrounding such a process.
The architecture will use:
Microsoft Copilot Studio + SharePoint Online + SharePoint Metadata + Microsoft Purview + Sensitivity Labels + DLP + Power Apps + Power Automate + Outlook + Microsoft Teams + Human Review.
The underlying regulated System of Record, if one exists, remains outside this architecture and authoritative for regulated data.
This distinction is fundamental.
2. The Architectural Objective
Our objective is not:
Build a pharmaceutical stability system with Power Platform.
Our objective is:
Explore how Microsoft 365 and Power Platform could provide a controlled collaboration, Knowledge, metadata, communication and workflow layer around a hypothetical product-development environment.
This immediately establishes several boundaries.
The architecture can help professionals:
Find approved Knowledge.
Classify collaborative information.
Organize documents.
Capture non-authoritative project information.
Generate summaries.
Identify information requiring attention.
Send controlled notifications.
Coordinate discussions.
Manage collaboration workflows.
It should not automatically:
Determine whether a pharmaceutical product is stable.
Approve analytical results.
Release product.
Replace a LIMS.
Replace a QMS.
Replace an ELN.
Replace a validated stability-management system.
Generate authoritative specifications.
Override Quality decisions.
This distinction allows us to explore the technology without claiming that it is appropriate for regulated decision-making.
3. The Same Architectural Pattern
Our previous scenarios followed a consistent pattern:
Knowledge → Retrieval → Grounding → Answer → Capture → Analysis → Action → Workflow → Human Authority.
We retain that pattern.
However, we now introduce another important layer:
Classification.
The architecture becomes:
Content → Metadata → Classification → Protection → Knowledge → Retrieval → Grounding → Communication → Workflow → Human Authority.
This is especially interesting because SharePoint is not merely a place where documents are stored.
Its metadata can become part of the information architecture.
4. SharePoint as a Collaborative Knowledge Layer
Imagine a SharePoint site dedicated to a hypothetical development program.
It might contain libraries for collaborative documents such as:
Development documentation.
Project documentation.
Reference information.
Technical reports.
Protocols.
Working documents.
Approved Knowledge intended for the Agent.
Meeting materials.
Lessons Learned.
The first architectural mistake would be creating folders such as:
Documents/ProjectA/2026/Stability/Reports/Final/ReallyFinal/Approved
Instead, we can begin thinking in terms of metadata.
A document is not merely a file inside a folder.
It represents information with business context.
5. SharePoint Metadata
Suppose a library contains development and stability-related collaborative documents.
We might conceptually define metadata such as:
| Metadata | Example |
|---|---|
| ProductCode | NPD-042 |
| Project | Project Atlas |
| DocumentType | Stability Protocol |
| DevelopmentPhase | Development |
| StudyType | Long-Term |
| Market | Global |
| Department | Analytical Development |
| DocumentStatus | Approved |
| KnowledgeEligible | Yes |
| Confidentiality | Confidential |
| QualityRelevant | Yes |
| Owner | Technical Owner |
| EffectiveDate | 2026-04-10 |
| ReviewDate | 2027-04-10 |
This metadata provides meaning that the filename alone cannot provide.
Instead of having:
Protocol_Final_v7_APPROVED.pdf
we have a document whose business context is explicitly represented.
6. Metadata Is Not Security
This distinction is extremely important.
Suppose a SharePoint column contains:
Confidentiality = Highly Confidential
That does not automatically protect the document.
It is simply metadata.
Likewise:
QualityRelevant = Yes
does not make the document a validated quality record.
Metadata describes information.
Security controls access.
Sensitivity Labels classify and protect information.
DLP controls certain data-handling scenarios.
Retention controls lifecycle.
Permissions determine who can access content.
These concepts must not be confused.
7. Business Metadata vs Compliance Controls
We can establish a useful separation:
| Concept | Primary Purpose |
|---|---|
| SharePoint Metadata | Describe business context |
| Permissions | Control access |
| Sensitivity Labels | Classify/protect sensitive information |
| DLP | Detect/control inappropriate information movement |
| Retention | Govern retention/deletion lifecycle |
| Audit | Record relevant activities |
| Knowledge | Provide information to Agent |
| Workflow | Coordinate business process |
This distinction is one of the most important aspects of the architecture.
8. Introducing Microsoft Purview
Microsoft Purview provides information-protection, DLP, retention and related governance capabilities across Microsoft 365.
For our conceptual architecture, suppose the organization has defined sensitivity classifications such as:
Public
Internal
Confidential
Highly Confidential
These names are illustrative. A real organization would define its own information-classification taxonomy and policies.
A development document could therefore simultaneously have:
SharePoint Metadata:
ProductCode = NPD-042
DocumentType = Development Report
and a Microsoft Purview Sensitivity Label:
Confidential
The two mechanisms solve different problems.
9. Metadata Provides Meaning; Labels Provide Classification
This distinction deserves emphasis.
Metadata might tell us:
What is this document?
Sensitivity classification tells us:
How sensitive is this information and what protections/policies should apply?
Therefore:
DocumentType = Stability Protocol
is business metadata.
Confidential
could be a Sensitivity Label.
The architecture becomes much more robust when we stop attempting to use a single classification mechanism for every purpose.
10. DLP as a Protection Layer
Microsoft Purview Data Loss Prevention can evaluate information across supported Microsoft 365 locations.
Microsoft currently documents that sensitivity labels can be used as conditions in DLP policies for locations including Exchange email, SharePoint and OneDrive. DLP can therefore participate in preventing or controlling inappropriate movement of sensitive information according to organizational policy.
In our conceptual scenario, a document classified according to the organization’s sensitivity model might trigger restrictions when users attempt inappropriate sharing.
The principle becomes:
Classification → Policy Evaluation → Enforcement.
This is much stronger than relying on instructions such as:
“Please don’t email confidential files externally.”
11. Metadata Can Drive Automation
SharePoint metadata can also participate in business automation.
Suppose:
DocumentStatus = Approved
and:
KnowledgeEligible = Yes
A Power Automate flow might perform a defined collaboration action.
Alternatively:
ReviewDate <= Today + 30 days
could generate a review notification.
Or:
QualityRelevant = Yes
might route an item through an additional review process.
The metadata therefore becomes operational.
We move from:
Metadata describes content
to:
Metadata can help drive process.
12. Metadata Should Not Become an AI Guess
There is an important caveat.
Some metadata may be appropriate for AI-assisted suggestion.
For example, the LLM might suggest:
DocumentCategory = Technical Report
But critical classifications should not necessarily be accepted simply because an LLM proposed them.
A safer pattern is:
Document → AI Suggestion → Human Confirmation → Metadata.
This maintains human control over important classification decisions.
13. Copilot Studio as the Knowledge Interface
Now we introduce the Agent.
The Agent uses approved SharePoint locations as Knowledge Sources.
The user might ask:
“Where is the approved stability protocol for Project Atlas?”
Copilot Studio searches the configured SharePoint Knowledge.
The architecture becomes:
User → Agent → SharePoint → Retrieval → Grounding → Answer.
Microsoft currently documents that the full SharePoint Knowledge integration in Copilot Studio surfaces only content that the signed-in user has permission to access.
This is important.
Connecting SharePoint to an Agent does not mean every Agent user receives access to all SharePoint content.
14. Sensitivity Labels and Copilot Studio
Sensitivity classification introduces another interesting interaction.
Microsoft documents that the SharePoint Knowledge option in Copilot Studio respects sensitivity labels for permission trimming.
However, there is an important limitation: Copilot Studio cannot extract or ground responses in content whose protection encrypts the file, including certain sensitivity-label encryption scenarios, Double Key Encryption and password-protected files.
Therefore, architecture design must not assume:
“The user can open the file, therefore the Agent can always ground on it.”
That assumption can be false.
This is precisely why information protection must be considered during Agent architecture rather than after deployment.
15. Knowledge Eligibility
This leads to a useful conceptual metadata field:
KnowledgeEligible
Suppose the organization decides that only specific collaborative documents should participate in the Agent Knowledge experience.
Possible values:
Yes
No
Pending Review
This field is not a security mechanism.
It is an information-governance signal.
The Knowledge architecture can then deliberately separate:
Documents stored in SharePoint
from:
Documents approved for Knowledge use.
That is an important governance distinction.
16. The Agent Should Not Interpret Analytical Results as Authority
Suppose someone asks:
“Does this stability result mean the product is acceptable?”
That is completely different from:
“Where is the approved protocol?”
The first question potentially involves scientific and regulated interpretation.
Our exploratory Agent should not be positioned as the authority making that determination.
Instead, it might be designed to locate the relevant controlled documentation or direct the user to the appropriate process.
This creates an important boundary:
Knowledge Retrieval ≠ Quality Decision.
17. Introducing the Sample Collaboration View
Now consider stability samples.
Again, we will deliberately avoid claiming that SharePoint should be the regulated System of Record.
Instead, imagine that an authoritative laboratory/stability system exists.
SharePoint contains a collaborative or reporting view of selected non-authoritative information.
For example:
| Field | Example |
|---|---|
| SampleReference | STB-042-001 |
| ProductCode | NPD-042 |
| Study | STB-2026-014 |
| Condition | Study Condition A |
| PlannedDate | 2026-09-28 |
| CollaborationStatus | Upcoming |
| ResponsibleGroup | Analytical Development |
| SourceSystem | Stability System |
| SourceRecordId | 928471 |
| LastSynchronized | Timestamp |
The authoritative data remains in the appropriate source system.
SharePoint provides a collaboration surface.
18. System of Record vs System of Engagement
This distinction is essential.
The regulated system might be the:
System of Record.
SharePoint, Teams and the Agent can form a:
System of Engagement.
The System of Record owns authoritative transactions.
The System of Engagement helps people find, discuss and coordinate information.
This architectural separation is particularly valuable in regulated environments.
19. Power Automate as the Orchestration Layer
Power Automate can now coordinate collaboration activities.
Suppose the SharePoint collaboration view contains upcoming items.
A scheduled Flow runs once per week.
Conceptually:
Recurrence → Query SharePoint → Filter Relevant Items → Build Summary → Send Outlook Email → Post Teams Summary.
This is deterministic automation.
No Generative AI is required simply to determine which records have a date within a defined range.
20. The Weekly Stability Collaboration Digest
Every Friday, for example, Power Automate could retrieve collaborative records relevant to the following week.
The summary might contain:
Upcoming activities.
Items requiring review.
Documents approaching review dates.
Open Knowledge questions.
Recently approved collaborative Knowledge.
Outstanding project actions.
The architecture becomes:
SharePoint Metadata → Power Automate → Weekly Digest.
Now we can distribute the same controlled summary through multiple channels.
21. Outlook as the Formal Communication Channel
Power Automate can send an Outlook email containing the weekly digest.
For example:
Subject: Weekly Product Development & Stability Collaboration Summary
The body might contain sections such as:
Upcoming Activities.
Documents Requiring Review.
Open Actions.
Knowledge Updates.
Items Requiring Attention.
Each section can link back to the authoritative or collaborative source rather than copying excessive information into the email.
This is an important design principle.
Email should often point to the information rather than become another uncontrolled copy of the information.
22. Why Links Can Be Better Than Copies
Suppose a confidential document exists in SharePoint.
Attaching a copy to an email creates another information object.
Linking to the governed SharePoint location allows existing permissions, labels and lifecycle controls to continue participating in access.
Therefore, where appropriate:
Send Context + Link
instead of:
Send Complete Document Copy.
The exact policy would, of course, depend on organizational requirements.
23. Teams as the Collaborative Communication Channel
The same weekly process can post a summary into a Teams channel.
For example:
Product Development – Stability Collaboration
Power Automate supports posting messages to Teams channels using the Microsoft Teams connector.
The channel might receive:
“Weekly collaboration summary is available.”
followed by:
Upcoming items.
Open review actions.
New approved Knowledge.
Links to SharePoint.
This creates a common awareness surface for the team.
24. Outlook and Teams Have Different Roles
It is useful not to treat Outlook and Teams as interchangeable.
Outlook can provide a formal scheduled digest.
Teams provides ongoing collaborative visibility.
SharePoint remains the information repository.
The architecture becomes:
SharePoint = Information
Outlook = Scheduled Communication
Teams = Collaborative Discussion
This separation reduces the risk of Teams becoming the unofficial database.
25. Teams Should Not Become the System of Record
Suppose someone posts:
“Sample STB-042 looks fine.”
That Teams message should not automatically become an authoritative quality decision.
Teams is a communication environment.
The appropriate System of Record remains responsible for controlled decisions and records.
Similarly:
Email ≠ Controlled Record simply because it contains technical information.
The architecture must preserve the distinction between communication and authoritative records.
26. The Agent Can Help Prepare the Weekly Summary
Generative AI can still contribute.
Instead of asking the LLM to determine which activities are due, Power Automate determines that using structured data.
Then the LLM can summarize the resulting dataset.
This gives us:
SharePoint → Deterministic Query → Structured Result → LLM Summary → Human-Readable Digest.
That is considerably safer than:
LLM → Guess what matters this week.
27. Deterministic Selection, Generative Presentation
This gives us another architectural principle:
Machines query facts deterministically.
LLMs explain those facts conversationally.
Suppose Power Automate determines:
7 upcoming activities.
3 documents requiring review.
4 open actions.
2 newly approved Knowledge items.
Those are facts.
The LLM can transform them into a concise executive summary.
But it should not silently modify the underlying counts.
28. Human Review Before Distribution
Depending on the sensitivity and intended use of the digest, a human review step could be inserted.
The process becomes:
Retrieve → Build → AI Summarize → Draft → Human Review → Distribute.
For a purely informational collaboration digest, the organization might determine that automatic distribution is acceptable.
For more sensitive content, approval may be required.
The appropriate design is a governance decision, not an AI decision.
29. Using Metadata to Build the Digest
Metadata becomes particularly valuable here.
Instead of reading every document with AI, Power Automate can query structured fields.
For example:
Project = Atlas
ReviewDate <= NextWeek
DocumentStatus = Approved
KnowledgeEligible = Yes
Owner = Analytical Development
This is faster, more predictable and easier to audit than asking an LLM to inspect every document.
Again:
Use metadata for structure.
Use AI for language.
30. Metadata-Driven Views
SharePoint can provide targeted views such as:
Documents Pending Review
Approved Knowledge
Project Atlas Documents
Upcoming Collaborative Activities
Quality-Relevant Content
Knowledge Candidates
These views can support users directly even without the Agent.
This is important because AI should not be required for tasks that SharePoint already solves well.
31. Living FAQ for Product Development
We can now reintroduce the Living FAQ concept from the previous articles.
Users ask the Agent questions such as:
“Where is the current development template?”
“Which document explains the sample collaboration process?”
“Where is the approved protocol?”
“Who owns the review?”
Relevant questions can be captured.
Repeated questions become:
FAQ Candidates.
Questions without adequate Knowledge become:
Knowledge Gaps.
The same architecture continues to work.
32. Knowledge Demand in Pharmaceutical Development
The organization can measure which information people repeatedly request.
For example:
| Canonical Question | Frequency | Knowledge Found |
|---|---|---|
| Where is the current protocol template? | 47 | Yes |
| Who reviews development reports? | 31 | Partial |
| Where is Project Atlas documentation? | 28 | Yes |
| Which collaborative view shows upcoming activities? | 22 | Yes |
| Where is the approved process guidance? | 18 | No |
This dataset does not make pharmaceutical decisions.
It measures Knowledge Demand.
That is a much safer and more useful role for AI.
33. Knowledge Gap Management
Suppose eighteen people ask a process question and no approved Knowledge exists.
The system can create:
KnowledgeGap = Yes
An appropriate owner reviews the gap.
The owner might decide to:
Create guidance.
Update an existing document.
Create an FAQ.
Clarify metadata.
Improve navigation.
Provide training.
Reject the request.
Again:
AI detects demand.
Humans determine the response.
34. Metadata Quality Becomes Important
Once metadata drives automation, poor metadata becomes an operational problem.
Suppose a document has:
DocumentStatus = Draft
when it is actually approved.
Or:
ReviewDate = blank
when the review workflow depends on that field.
Metadata quality therefore becomes part of information governance.
Required fields, controlled vocabularies, content types and validation rules can become important.
The architecture begins to reveal something fundamental:
Good AI architecture often begins with good information architecture.
35. Content Types
SharePoint Content Types can help formalize different document classes.
For example:
Development Report
Technical Protocol
Reference Document
Knowledge Article
Training Material
Each Content Type can have appropriate metadata.
This provides stronger structure than one enormous library containing unrelated files with optional columns.
36. Managed Metadata
Where appropriate, SharePoint Managed Metadata can provide controlled taxonomies.
For example:
Product Family.
Development Program.
Technical Domain.
Document Category.
Knowledge Category.
Using controlled terminology helps reduce variations such as:
Stability
Stab
Stability Study
Stability Studies
A consistent taxonomy improves filtering, search and governance.
It can also improve the context available to downstream processes.
37. Metadata + Agent
Imagine the user asks:
“Show me Knowledge about Project Atlas.”
The Agent can retrieve relevant Knowledge.
But metadata can also help us organize which sources or records are relevant.
The ideal architecture does not treat semantic search and metadata as competing approaches.
They complement each other.
Metadata provides explicit structure.
Semantic retrieval provides flexible discovery.
38. DLP + Outlook
Now suppose someone attempts to send protected information through Outlook.
Microsoft Purview DLP can evaluate supported content and policies in Exchange.
Depending on organizational policy, it can generate policy tips or enforce configured restrictions.
This gives us:
User Action → Content Classification → DLP Evaluation → Policy Enforcement.
The Agent does not need to reinvent this control.
Existing Microsoft 365 compliance capabilities should be used where appropriate.
39. DLP + SharePoint
The same principle applies to SharePoint.
Microsoft documents support for using sensitivity labels as conditions in DLP policies for SharePoint.
Therefore, the information architecture can connect:
Sensitivity Label
with:
DLP Policy.
For example, the organization might establish stricter sharing controls for selected classified content.
Again, actual policy design belongs to the organization’s compliance and security functions.
40. DLP + Teams
Teams requires another architectural nuance.
Files shared through Teams are typically stored in SharePoint or OneDrive, where applicable information protection and DLP controls can participate.
The conversation itself and the attachment are different information objects.
Therefore:
Teams Message
and:
File shared through Teams
should not be assumed to have identical governance behavior.
This distinction matters when designing collaboration policies.
41. Retention Is Different from Sensitivity
Another common mistake is confusing Sensitivity Labels and Retention Labels.
They solve different problems.
Sensitivity asks:
How sensitive is this information and how should it be protected?
Retention asks:
How long should this information be retained, and what lifecycle controls apply?
Microsoft Purview supports retention policies and retention labels, including item-level retention scenarios for SharePoint.
In a real pharmaceutical environment, retention requirements would need formal regulatory and records-management analysis.
For our exercise, the important concept is simply:
Sensitivity ≠ Retention.
42. Records Management Is Yet Another Layer
Some content may eventually need to be treated as a record.
Again, that is not something we should infer casually from this conceptual architecture.
The organization would need to determine:
What constitutes a record?
Which system owns it?
When does it become a record?
What retention applies?
Who can modify it?
What audit requirements exist?
This reinforces why our SharePoint environment is described as a collaborative Knowledge layer rather than automatically as the pharmaceutical System of Record.
43. The Weekly Automation
Our conceptual weekly Flow now becomes relatively sophisticated.
Every week:
1. Trigger
Scheduled recurrence.
2. Retrieve
Query relevant SharePoint collaborative records.
3. Filter
Apply deterministic metadata criteria.
4. Aggregate
Group information by project, owner or category.
5. Summarize
Optionally use AI to create a readable summary.
6. Review
Optional human review depending on governance.
7. Email
Send Outlook weekly digest.
8. Teams
Post collaboration summary to the appropriate channel.
9. Link
Point users back to SharePoint or the authoritative system.
This is an excellent example of combining deterministic automation with Generative AI.
44. Conceptual Weekly Information Flow
Authoritative Systems
|
v
Controlled Integration
|
v
SharePoint
Collaboration Layer
|
+----------------+----------------+
| | |
v v v
Metadata Knowledge Classification
| | |
| v v
| Copilot Studio Purview
| | Labels / DLP
| |
+-------+--------+
|
v
Power Automate
|
Deterministic Query
|
v
Structured Dataset
|
v
Optional AI Summary
|
v
Human Review
|
+-------+-------+
| |
v v
Outlook Teams
Weekly Digest Channel Summary
| |
+-------+-------+
|
v
SharePoint
Controlled Links
45. Teams Channel Management
The Teams channel should have a defined purpose.
For example:
Product Development – Stability Collaboration
The channel might contain:
Weekly summaries.
Knowledge announcements.
Review reminders.
Links to approved guidance.
Discussion threads.
Questions for the team.
But it should not become a substitute for structured records.
A useful principle is:
Discuss in Teams.
Store Knowledge in SharePoint.
Execute process in Power Automate.
Retrieve Knowledge through Copilot Studio.
Protect information with Microsoft Purview.
46. Outlook Weekly Digest
Outlook plays a complementary role.
Some professionals may not monitor the Teams channel continuously.
A scheduled weekly digest provides predictable communication.
The email can contain a concise summary and links.
The email itself should avoid unnecessarily duplicating sensitive source content.
This gives us a communication pattern:
Push Awareness → Pull Detail.
Outlook and Teams push awareness.
SharePoint and authoritative systems provide detail.
47. Copilot Studio Agent
The Agent becomes the interactive layer.
Instead of waiting for Friday’s digest, the user can ask:
“What collaborative activities require attention this week?”
“Where is the approved Knowledge for Project Atlas?”
“Which documents are approaching review?”
“What questions are being asked frequently?”
“Where is the current development guidance?”
Depending on the question, the Agent may use:
Knowledge.
Tool.
SharePoint query.
Power Automate.
The conversational experience remains unified while the architecture stays separated.
48. Knowledge vs Action
The distinction remains fundamental.
“Where is the approved guidance?”
Knowledge.
“Create a Knowledge Gap.”
Action.
“What documents are approaching review?”
Tool / structured query.
“Send the weekly summary.”
Action.
“What does this procedure say?”
Knowledge.
“Post the approved summary to Teams.”
Action.
Conversation hides complexity from the user.
Architecture must not.
49. Security Identity Questions
For every component, we must ask:
Who is accessing SharePoint?
Who executes the Flow?
Which Outlook mailbox sends the digest?
Which identity posts to Teams?
Which users can invoke the Agent?
Which users can access the Knowledge Sources?
Which connection accesses external systems?
These questions become especially important in regulated environments.
The existence of an Agent does not eliminate identity boundaries.
50. Least Privilege
Suppose the weekly Flow only needs to read a specific SharePoint list and send a summary.
Its connection should not automatically have unrestricted access to every development site.
Similarly, an Agent Tool designed to retrieve collaborative status should not have permission to modify regulated source records.
The capability should be narrow.
For example:
GetUpcomingCollaborativeActivities
is preferable to:
FullStabilitySystemAccess.
Tool design is part of security architecture.
51. DLP for Copilot Studio
There is another DLP dimension.
Power Platform data policies can control which connectors and capabilities makers can use with Copilot Studio Agents.
Microsoft currently documents data-policy controls for Copilot Studio, including controls around Knowledge Sources and Power Platform connectors used as Tools.
This means governance can operate not only on the content but also on what the Agent is allowed to connect to.
That is particularly important for Citizen Development.
52. Citizen Development Governance
A Citizen Developer may be allowed to:
Create a SharePoint List.
Build a Power App.
Build a Flow.
Create an Agent.
Use approved Knowledge Sources.
Post to an approved Teams channel.
Send approved notifications.
But that does not imply permission to:
Connect arbitrary external systems.
Expose confidential development information.
Create uncontrolled APIs.
Change retention policies.
Modify DLP.
Override Quality controls.
The Citizen Developer operates inside platform guardrails.
This is what turns Citizen Development into governed Citizen Development.
53. Environment Strategy
A real organization would also need an environment strategy.
Development.
Test.
Production.
Solutions.
Connection references.
Environment variables.
DLP policies.
Security roles.
Deployment controls.
The Agent, Power Automate flows and Power Apps should not simply be edited directly in production without governance.
This brings our architecture closer to enterprise Power Platform ALM.
54. AI Output Must Have Provenance
Suppose the Agent produces a weekly summary.
Users should understand whether the information came from:
Structured SharePoint metadata.
Retrieved Knowledge.
An authoritative external system.
AI-generated interpretation.
These sources should not be silently mixed.
A mature architecture should make provenance visible.
For example:
Source Data: SharePoint Collaboration List.
Period: 21–27 September 2026.
Summary: AI-generated from retrieved records.
This increases transparency.
55. Hallucination Is Particularly Important Here
A fluent LLM response can look authoritative.
That is dangerous in highly regulated contexts.
Therefore the Agent should be designed to prefer:
Grounded Knowledge.
Structured Tools.
Source links.
Explicit uncertainty.
Escalation to humans.
over:
Unsupported generation.
If sufficient Knowledge cannot be retrieved, the appropriate response may be:
No approved Knowledge was located.
That can be far more valuable than a plausible invented answer.
56. Human-in-the-Loop
Human review remains central.
Possible authorities include:
Technical Owner.
Analytical Development.
Project Manager.
Quality.
Regulatory.
Information Owner.
Security.
Records Management.
The LLM assists them.
It does not replace them.
57. Auditability
Another major architectural concern is auditability.
For important automated processes, the organization may need to understand:
What triggered the process?
Which records were selected?
Which metadata values were used?
Which user or connection executed the action?
What summary was generated?
Who approved it?
When was it distributed?
Power Automate run history and Microsoft 365 audit capabilities can contribute to operational traceability, but whether they satisfy any specific regulated requirement would require formal validation and compliance assessment.
58. The Architecture as a Controlled Information Pipeline
We can now reinterpret the entire solution as an information pipeline.
CREATE
Users create collaborative information.
DESCRIBE
SharePoint metadata adds business context.
CLASSIFY
Sensitivity Labels identify information sensitivity.
PROTECT
Permissions and DLP enforce information-handling policies.
RETAIN
Retention capabilities manage lifecycle where appropriate.
KNOW
Approved information becomes Knowledge.
RETRIEVE
Copilot Studio locates relevant Knowledge.
GROUND
Responses are connected to approved sources.
QUERY
Power Automate retrieves structured operational information.
SUMMARIZE
AI transforms structured data into readable communication.
REVIEW
Humans validate where required.
COMMUNICATE
Outlook and Teams distribute awareness.
DISCUSS
Teams supports collaboration.
ACT
Tools and workflows initiate controlled actions.
GOVERN
Quality, Security, Records Management and platform governance maintain boundaries.
59. Technology Responsibility Matrix
| Technology | Primary Responsibility |
|---|---|
| SharePoint | Collaborative information and Knowledge |
| SharePoint Metadata | Business context |
| Content Types | Document structure |
| Managed Metadata | Controlled taxonomy |
| SharePoint Permissions | Access control |
| Sensitivity Labels | Information classification/protection |
| Microsoft Purview DLP | Data loss prevention |
| Retention | Information lifecycle |
| Copilot Studio | Conversation and orchestration |
| Knowledge Sources | Approved information for retrieval |
| Retrieval | Locate relevant Knowledge |
| Grounding | Connect answers to sources |
| LLM | Interpret, classify, summarize and draft |
| Power Apps | Structured capture where appropriate |
| Power Automate | Deterministic orchestration |
| Outlook | Scheduled communication |
| Teams | Collaborative communication |
| Authoritative Laboratory/Quality Systems | Regulated System of Record where applicable |
| Human Review | Validation and authority |
| Quality | Governance |
| Security | Information protection governance |
60. Final Architectural Summary
| Requirement | Preferred Layer |
|---|---|
| Describe document | SharePoint Metadata |
| Categorize business content | Content Type / Metadata |
| Standardize terminology | Managed Metadata |
| Control access | SharePoint / Entra permissions |
| Classify sensitive content | Sensitivity Labels |
| Prevent inappropriate sharing | Purview DLP |
| Manage lifecycle | Retention |
| Store collaborative Knowledge | SharePoint |
| Retrieve approved Knowledge | Copilot Studio |
| Generate grounded response | Copilot Studio |
| Query structured records | Power Automate / Tool |
| Determine dates and thresholds | Deterministic logic |
| Produce readable summary | LLM |
| Send weekly digest | Power Automate + Outlook |
| Publish weekly collaboration update | Power Automate + Teams |
| Discuss information | Teams |
| Maintain controlled source links | SharePoint |
| Capture FAQ demand | Agent + SharePoint |
| Identify Knowledge gaps | Agent + SharePoint |
| Approve Knowledge | Human governance |
| Make regulated Quality decision | Authorized regulated process, not LLM |
| Maintain authoritative laboratory records | Appropriate validated System of Record |
| Protect Citizen Development boundaries | Power Platform governance + DLP |
Conclusion
This hypothetical pharmaceutical scenario demonstrates why enterprise Generative AI architecture cannot be reduced to simply connecting an Agent to documents.
Information has structure.
Information has ownership.
Information has sensitivity.
Information has lifecycle.
Information has provenance.
Information has access boundaries.
And in regulated industries, information can have significant compliance implications.
SharePoint Metadata provides explicit business context. Content Types and Managed Metadata provide structure and taxonomy. Permissions control access. Microsoft Purview Sensitivity Labels provide classification and protection capabilities. DLP can enforce organizational information-handling policies. Retention provides a separate lifecycle-management layer. Copilot Studio provides conversational access to approved Knowledge. Retrieval and Grounding connect answers to source information. Power Automate executes deterministic processes. Outlook distributes scheduled awareness. Teams supports collaborative discussion.
Generative AI sits inside this architecture rather than above it.
The LLM can summarize.
It can classify.
It can explain.
It can organize.
It can transform structured information into readable communication.
But it should not silently become the authority responsible for scientific, Quality or regulatory decisions.
The architecture can therefore be summarized as:
Metadata provides context.
Permissions provide access boundaries.
Sensitivity Labels provide classification and protection.
DLP provides information movement controls.
Retention provides lifecycle governance.
SharePoint provides collaborative Knowledge.
Copilot Studio provides conversational discovery.
Power Automate provides deterministic orchestration.
Outlook provides scheduled communication.
Teams provides collaborative communication.
Authoritative systems provide regulated facts.
Humans provide scientific and Quality authority.
This leads to the same principle that has guided the previous architectures in this series, expanded for information governance:
Systems provide facts. Metadata provides context. Knowledge provides approved information. AI provides interpretation. Workflows provide deterministic execution. Microsoft 365 provides collaboration. Purview provides information-governance controls. Humans provide authority.
For a Citizen Developer, this is perhaps the most important lesson from the scenario.
Citizen Development is not the absence of governance.
In a mature enterprise, it is precisely the opposite.
Citizen Development becomes powerful when users can rapidly create solutions inside an architecture where identity, metadata, information protection, DLP, permissions, environments, workflows and human authority already establish the boundaries within which innovation can safely occur.
