Choosing one tool and writing a policy around it feels like control. Under the regulations now shaping pharma AI, it answers the wrong question entirely.
In pharma, AI governance sits at the intersection of enterprise technology risk, regulated-process controls, and emerging AI law. The question is no longer just whether a tool is enterprise-approved. It is whether the specific use of that tool is understood, classified, governed, documented, and, where needed, validated for the context in which it is being used.
I have heard a version of the same sentence in a dozen pharma leadership meetings this year. It usually arrives with a note of relief, often near the end of a conversation that had been getting uncomfortable:
“We’re fine on AI. Everyone’s on Copilot, and we’ve got a policy that says only use Copilot.”
I understand why that feels like safety. You have consolidated onto an enterprise tool from a trusted vendor. Your data sits inside your Microsoft tenant. You have issued a policy. It looks like a decision has been made and a risk has been closed.
It hasn’t.
The gap between how safe that sentence feels and how little it actually protects you is, in my experience, one of the most expensive misconceptions in pharma right now.
This is not an argument against Microsoft Copilot. Copilot is a capable tool, and standardising on it is a reasonable IT decision. The problem is the belief that the tool choice, plus a short acceptable-use policy, amounts to AI governance. It doesn’t.
In pharma, that gap matters across at least three layers at once:
● AI Act exposure, where obligations depend on the use case and deployment context
● pharma quality and GxP expectations, where intended use, validation, traceability, and oversight matter
● enterprise governance, where inventory, access control, documentation, and change management determine whether policy exists in practice or only on paper
Let me explain why – using the regulations themselves, not opinion.
The Tool Is Not the Unit of Regulation. The Use Is
Start with the most fundamental misunderstanding baked into “we only use Copilot.”
The EU AI Act does not classify tools. It classifies uses. The same system – Copilot, ChatGPT, Claude, or another AI tool – can be minimal-risk in one workflow and high-risk in another, depending on its purpose and context of deployment.
Copilot summarising meeting notes may be low-risk. The same Copilot, if used to inform a hiring decision, a performance review, a promotion, or a termination, may fall into Annex III high-risk territory, because employment and worker management are named high-risk areas.
When AI is used inside a workflow that falls into a high-risk category, that deployment must be assessed against the AI Act’s high-risk requirements. The relevant obligations – including risk management, data governance, technical documentation, human oversight, logging, and post-market monitoring – attach to the use and context, not simply to the software brand.
So when a leader tells me “we only use Copilot,” my honest reaction is that the statement contains almost no information about actual regulatory exposure.
It tells me the make of the car. I asked how fast it was being driven, and whether anyone was standing in the road.
That distinction matters in pharma because the same enterprise AI assistant can touch very different workflows with very different consequences.
For example:
● summarising internal meeting notes
● drafting medical information responses
● assisting with literature reviews in medical affairs
● supporting HR screening or performance processes
● helping draft deviation, CAPA, or investigation text in quality
● generating first-pass content for regulatory or clinical operations teams
● assisting pharmacovigilance teams with case processing or narrative support
These uses should not be governed as if they carry the same regulatory, quality, or patient-risk profile. A single-tool policy ignores that entirely.
You Are the Deployer. The Obligations Are Yours, Not Microsoft’s
The Second Misunderstanding Is About Who Carries the Burden.
The EU AI Act Draws a Sharp Line Between Two Roles. There Is the Provider – for Example, Microsoft, Which Builds and Ships the Underlying General-Purpose AI Capability. And There Is the Deployer – Your Company, Which Puts That Capability to Use in a Specific Business Context.
Microsoft Has Obligations as a Provider. But Microsoft’s Compliance Is Not Your Compliance.
As the Deployer, You Are Responsible for How You Use the System: The Classification of Your Specific Use Cases, the Controls Around Those Uses, the Documentation, and the Human Oversight. Article 26 Makes Clear That Deployers Must Use the System in Accordance With Its Intended Purpose.
The Moment a General Productivity Tool Is Used in a Consequential Workflow, the Burden Shifts From Abstract Vendor Assurance to Concrete Internal Accountability.
If Your HR Team Uses Copilot Outputs in Employment Decisions, if Your Regulatory Team Uses Ai-Generated Text in Submission Development, or if Your Quality Organisation Relies on AI Assistance in Gxp-Relevant Documentation, Those Are Not Questions Microsoft Can Answer on Your Behalf. Microsoft Does Not Know Your Intended Use, Your Review Model, Your Reliance Model, or Your Regulated-Process Context. Only You Do.
This Is Why “Microsoft Handles the AI Act for Copilot” Is Only Half-True in a Dangerous Way. Microsoft Handles Its Provider Obligations. Your Deployer Obligations Remain With You.
High-Risk Under the AI Act Is Not the Same as GxP-Critical
One of the most important distinctions for pharma leaders is this: AI Act high-risk classification and pharma compliance criticality are not the same thing.
An AI use may not fall into an AI Act high-risk category and still create serious concerns under:
● GxP
● data integrity expectations
● validation requirements
● quality risk management
● regulatory credibility standards
● privacy and confidentiality controls
Conversely, a use that clearly raises AI Act concerns may not be GxP-relevant.
That is why pharma organisations need a governance model that asks multiple questions in parallel:
This is where many “Copilot-only” policies fail. They assume one vendor decision answers every governance question. In pharma, it answers only a small subset.
Data Residency Is Not Compliance
The third misunderstanding is the quiet engine underneath the whole “we’re safe” feeling, so it deserves the most direct correction.
When people say “we only use Copilot,” what they often mean underneath is that the enterprise version keeps their data in their tenant, is not training on their content, and sits inside the Microsoft boundary. That is real and valuable – for data security, confidentiality, and control over where information is processed.
But it is not the same as AI Act compliance.
The AI Act asks governance questions: Was the use classified? Was risk assessed? Is there meaningful human oversight? Is there logging? Is there documentation someone could actually review? Is the use aligned to the intended purpose? Can the organisation explain how the tool is governed in practice?
Enterprise Copilot may give you a better filing cabinet. It does not perform the governance work for you.
Even on the privacy side, default settings do not resolve everything automatically. Copilot operates within your existing Microsoft 365 permissions model, which means misconfigured access can expose content the requesting user should not see. A Data Protection Impact Assessment may be required under GDPR Article 35 where personal data processing carries a high risk. Sensitivity labels, audit logging, retention policies, access governance, and human review of outputs are part of the operational foundation of compliant use – not optional extras that activate themselves.
And this matters even more in the current implementation phase of the EU AI Act, where practical compliance is increasingly being shaped through guidance, implementation materials, and operational interpretation – not just by reading the regulation at a high level.
The Hidden Risk: AI Is Entering Pharma Through Platforms You Already Use
A major governance problem in pharma is that AI is not entering only through tools the company consciously selects as “AI platforms.” It is also arriving through routine upgrades and embedded features inside existing enterprise systems.
That includes capabilities appearing across platforms used in commercial, medical, R&D, quality, HR, and corporate functions – for example, Microsoft 365 and Dynamics, Veeva, Salesforce Einstein, ServiceNow, Box, Workday, SAP, Oracle, and others.
Some of these features may enter environments already treated as governed, validated, or operationally approved. That creates a dangerous assumption: if the platform is already approved, the new AI functionality must also be covered.
Often, it is not.
In pharma, embedded AI can alter:
● the nature of user reliance
● the consistency of outputs
● the intended use of the system
● the documentation needed to justify use
● the control model for review and approval
● the assumptions behind a previously validated state
This is especially important in GxP and adjacent regulated environments. A platform enhancement may look like a normal feature release while materially changing how content is generated, reviewed, or acted upon.
A “Copilot-only” policy does not solve that problem. In some cases, it makes it less visible.
A ‘Only Use Co-pilot’ Policy Does Not Stop Shadow AI. It Often Stops You Looking
The fourth misunderstanding is that “only use Copilot” is a control.
It feels like one. It usually is not.
People do not stop using other AI tools because a policy told them to. The medical affairs team may still have personal AI accounts. Someone in commercial may still paste text into a free tool for a quick summary before a meeting. R&D may still have lightweight scripts or notebook-based models that appear on no official inventory.
And then there is the AI the organisation did not explicitly choose at all – the embedded AI features discussed above.
A policy that says “only use Copilot” does not make any of this disappear. It can instead create a false sense that the environment has been simplified when the underlying AI footprint is still diffuse, expanding, and only partially visible.
In advisory work, one of the most consistent findings is that the real AI footprint is materially larger than leadership believes. I have seen an engagement scoped around a handful of data sources discover it was actually dealing with more than a hundred and fifty. That is not rare enough to dismiss as an outlier.
What you do not inventory, you cannot govern.
A Policy Without an Operating Model Is Theatre
The fifth and deepest misunderstanding is that a policy is the deliverable.
This is one of the most common failure patterns across pharma. A company decides AI governance matters. Legal or compliance drafts a policy. It says the right things: AI must be classified, high-risk uses require approval, vendor AI must be assessed, and models must be validated. It gets approved. Communications announces it. Training rolls out.
And nothing operational actually changes.
No committee meets. There is no intake process that people actually use. There is no standard classification method. There is no vendor-assessment workflow tied to deployment. There is no validation playbook for regulated AI use. The policy exists, but the operating model behind it is empty.
When the inevitable audit arrives – internal, regulator, partner, or due diligence review – the policy survives the first glance, and then the first serious question exposes that the governance it describes does not exist in practice.
“Only use Copilot” is that failure pattern compressed into a single line.
It is a sentence pretending to be a system.
In Pharma, the Governance Problem Is Bigger Because AI Can Intersect With GxP
Everything above applies to many industries. In pharma, there is an additional layer that a ‘Co-pilot only’ AI policy usually does not even acknowledge.
If Copilot – or any AI capability – touches a GxP-relevant workflow, you are now in the world of GAMP 5 Second Edition and its Appendix D11, the ISPE GAMP Guide on Artificial Intelligence, 21 CFR Part 11, ALCOA+ data integrity, and ICH Q9(R1) quality risk management.
That can include AI used to support or draft content in:
● regulatory processes
● manufacturing or quality systems
● pharmacovigilance workflows
● clinical operations
● investigation, CAPA, and deviation documentation
● medical or scientific content that feeds regulated processes
A generative model that may return a different answer to the same prompt is difficult to govern against standards built around reproducibility, traceability, justified intended use, reviewability, and auditability.
Most pharma companies already have AI or AI-like functionality influencing GxP-relevant work that was never validated to current expectations.
That is not necessarily a finding today. It becomes one the moment an auditor asks:
“Show me your AI validation documentation.”
And the documentation either does not exist, is incomplete, or reflects older assumptions that do not fit the way the tool is currently being used.
“We only use Copilot” has no answer to that question.
If You Are a US Pharma Company, This Is Still Your Problem
There is a tempting escape hatch here: the EU AI Act is a European issue, so Europe can deal with it.
That is one of the most expensive assumptions in the whole discussion.
The Act is deliberately extraterritorial. Its scope does not turn only on where your company is headquartered. It also reaches providers and deployers established outside the EU when the output produced by their AI system is used inside the EU.
Concretely:
● an HR AI in Indianapolis screening a candidate for a Europe-based role may be in scope
● a clinical operations AI hosted in North Carolina supporting trial enrolment in Germany may be in scope
● a regulatory AI in New Jersey drafting content for an EU marketing authorisation may be in scope
● a pharmacovigilance system in Boston processing adverse events involving EU patients may be in scope
The servers may be in America. The exposure can still be European.
Legal commentators have noted this reach may be broader than GDPR in some respects, because it does not depend on the same targeting or personal-data nexus logic. And a US-based provider of a high-risk system may need to designate an authorised representative inside the EU under Article 22 before placing that system on the EU market.
Yes, the headline high-risk deadlines were pushed back in the May 7, 2026 Digital Omnibus agreement – Annex III standalone systems to December 2027, Annex I embedded systems in regulated products to August 2028. But the postponement moved the timeline; it did not move the substance, and it did not reduce the underlying governance work.
The penalties are unchanged: up to €35 million or 7% of global annual turnover, whichever is higher.
Runway is not relief.
What Regulators, Auditors, and Partners Will Actually Ask For
The most useful way to pressure-test whether governance is real is to ask what evidence the organisation could produce on demand.
In practice, regulators, auditors, inspectors, partners, or acquirers are unlikely to be impressed by “we only use Copilot” unless it is backed by documentation and controls such as:
● an inventory of AI systems and AI-enabled features in use
● intended-use statements for material use cases
● risk classification decisions and their rationale
● records of legal, privacy, quality, and security review
● evidence of human oversight design
● documentation of validation or verification where required
● controls for version change, prompt change, and workflow change
● training records for relevant user groups
● logging, monitoring, escalation, and incident-management procedures
● evidence that prohibited or restricted uses are actively prevented, not merely discouraged
That is what operational governance looks like when someone asks to see it.
What a Minimum Viable Pharma AI Governance Model Looks Like
If “only use Copilot” is not a strategy, what does a minimum viable strategy look like?
At a practical level, pharma organisations need an operating model that includes, at minimum:
1. AI use-case intake
A process that captures new uses before they go live
2. AI inventory
A maintained register of tools, embedded features, scripts, models, and material use cases
3. Risk classification
A repeatable method for assessing AI Act risk, GxP relevance, privacy impact, and business criticality
4. Role clarity
Clear ownership across legal, quality, privacy, security, IT, and business functions
5. Vendor and platform assessment
A way to assess both standalone AI vendors and AI features embedded in existing platforms
6. Validation and verification approach
Fit-for-purpose controls for GxP-relevant and other high-consequence uses
7. Human oversight design
Defined review, approval, escalation, and override processes
8. Documentation and traceability
Evidence that decisions, controls, and changes can be reconstructed and defended
9. Change control and monitoring
A method for handling model updates, feature expansion, and drift in actual use
10. Training and accountability
Role-based education tied to the real workflows people use
11. Incident response and remediation
A process for when AI outputs are wrong, misleading, untraceable, or used outside approved boundaries
This is not theoretical governance. It is the minimum infrastructure needed to make policy real.
What “Ready” Actually Looks Like and What It Doesn’t
Ready is not a tool choice, and it is not a policy. It is an operating capability.
It is a governance structure where a committee genuinely meets and genuinely decides. It is an intake process that catches new AI uses before they go live rather than after an auditor finds them. It is a risk-tiering method consistent enough that two people assessing the same system independently reach the same answer. It is documentation mapped back to relevant frameworks – including the EU AI Act, FDA credibility expectations, GAMP, 21 CFR Part 11, and ISO 42001 – so that when a regulator or partner asks, “Show me how this control satisfies that obligation,” the answer already exists.
It is also a validation approach for GxP-relevant AI that has actually been applied to live systems.
That is real work. But the fastest way to see whether the work has begun is to ask a few simple questions.
Ask yourself:
● How many AI systems are actually in your environment – not just the ones IT formally tracks, but all of them?
● Which of your AI uses would classify as high-risk under Annex III, or otherwise trigger meaningful AI Act obligations?
● Has any AI touched a GxP-relevant system or record without validation or verification to current expectations?
● Which of your AI outputs are used by someone in Europe?
● Which embedded AI features have entered approved or validated platforms without separate review?
Conclusion
If those questions cannot be answered quickly, then the organisation does not yet have a clear view of its AI exposure.
That picture is one of the cheapest and most valuable things you can buy in this process, because everything else depends on it.
“We only use Copilot” is what a company says instead of having that picture.
Where this work actually starts
At Eularis, we have built AI for pharmaceutical and biotech companies for over twenty years. That experience shapes how we assess governance risk – technically, operationally, and in the context of the regulated environments you actually operate in, not a generic template.
It also means we field a senior pharma and biotech AI governance team that covers the specific disciplines this work demands:
AI Governance Lead – governance framework, operating model, intake, triage and risk-tiering
Pharma GxP / CSV-CSA SME – FDA expectations, GAMP 5, 21 CFR Part 11 and ALCOA+ validation
EU AI Act / Privacy SME – Article 6 applicability, the Swiss layer, and data protection
Controls / Shadow-AI Architecture SME – shadow-AI detection and the technical controls behind the policy
Engagement Lead and Programme Manager – accountable delivery, end-to-end
We have never had a productised AI line to sell, and no partnership with any AI platform, so when we advise on classifying a vendor’s tool or prioritising remediation, the only interest in the room is your exposure, not steering you toward a platform decision.
That is why we start with a focused two-week diagnostic: an honest, evidence-based picture of every AI system actually in your environment, where it is being used, how it classifies against the frameworks that apply to you, and what needs to be fixed first. Not a slogan – a clear view of where you really stand, with a clean decision point at the end.
If the questions above made you pause, that is where the real work begins. Talk to me to find out where you stand and how to fix it in the most painless way. Email me directly at abates@eularis.com, or use the contact form at eularis.com/contact-us.
Choosing Copilot was an IT procurement decision.
Governing it is a different discipline – and the obligations are yours, not Microsoft’s.