Who is accountable when PHI reaches a Copilot surface that is outside the organisation’s approved BAA coverage?

The covered entity remains accountable for how PHI is handled before it is sent to any AI service. The provider may have contractual obligations for covered processing, but the organisation must govern user behaviour, tenant configuration, and data controls. Security, compliance, and application owners should jointly enforce surface-specific policy and evidence retention.

Why This Matters for Security Teams

When PHI can move into a Copilot surface that sits outside approved BAA coverage, the issue is not only contractual. It becomes a governance and disclosure problem that can affect HIPAA obligations, internal policy, and incident response scope. The practical risk is that users often treat AI surfaces as extensions of the approved productivity stack, even when the underlying service boundary, tenant, or feature set is different. That means the organisation can unintentionally route regulated data into an environment where the expected assurances do not exist. Guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it emphasizes control ownership, auditability, and data protection as operational duties rather than assumptions. The accountability question matters because regulators and auditors usually look at the whole handling chain, not just the vendor’s marketing claims. In practice, many security teams encounter this only after PHI has already been pasted, indexed, summarized, or retained in the wrong Copilot surface, rather than through intentional data classification and routing.

How It Works in Practice

Accountability starts before the prompt is sent. The organisation needs to know which Copilot experiences are inside BAA scope, which are not, and what data types are permitted in each one. That requires explicit control mapping across identity, endpoint, tenant, and application layers. A BAA may cover some enterprise services, but not every embedded AI feature, preview capability, connector, or consumer-adjacent surface. The safest operating model is to treat each surface as its own data path and to validate whether PHI is allowed there at all.

• Classify PHI handling rules by surface, not just by brand name or product family.
• Use tenant and application policy to block or limit PHI in unsupported AI features.
• Apply DLP, logging, and retention rules so AI interactions are discoverable after the fact.
• Require user guidance that explains which Copilot surfaces are approved and which are prohibited.
• Review connectors, plug-ins, and admin-configurable features because they can change the data boundary.

From a control perspective, this aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls for access control, audit logging, and information flow enforcement, and with contractual governance that assigns responsibility for covered processing. Organisations should also preserve evidence of policy decisions, user notices, and technical restrictions so they can show why a given surface was approved or blocked. Where Copilot is integrated into business workflows, application owners must coordinate with security and privacy teams so the approval status is continuously revalidated after product changes. These controls tend to break down in fast-moving Microsoft 365 environments because feature flags, connectors, and licensing changes can alter the effective PHI boundary without a corresponding policy update.

Common Variations and Edge Cases

Tighter control over Copilot surfaces often increases user friction and administrative overhead, requiring organisations to balance clinical or business productivity against compliance risk. Not every AI interaction is equally sensitive, and best practice is evolving around what counts as a sanctioned workspace versus an out-of-scope surface. In some cases, the organisation may have a BAA for the core platform but not for a specific AI add-on, beta feature, or external connector. In others, the issue is not the model itself but the storage, indexing, or telemetry that occurs after PHI is submitted.

There is no universal standard for this yet, so the safest approach is conservative scoping plus documented exception handling. If a Copilot surface can expose prompts, outputs, embedded content, or retrieval sources to services outside the approved contract boundary, then PHI should be treated as prohibited until proven otherwise. This is especially important when users copy text from records systems, paste screenshots, or invoke agentic workflows that chain multiple tools together. Current guidance suggests that accountability remains with the covered entity for data placement decisions, even when a third party provides the AI functionality. Where the environment includes shared tenants, federated identity, or unmanaged endpoints, enforcement becomes harder because the organisation cannot reliably prove which surface handled the data at each step. For that reason, the approval decision should be revisited whenever licensing, connectors, or retention settings change.

Related resources from NHI Mgmt Group

• Who is accountable when a vendor session touches a production system outside the approved scope?
• Who is accountable when sensitive data is shared outside approved scope?
• Who should be accountable for identities that sit outside traditional IGA coverage?
• Who is accountable when access exists outside approved governance?