Shadow AI creates risk because employees can use dozens of GenAI apps outside the EHR, and those tools may receive resident, family, or operational data without oversight. In long-term care, the sensitivity is broader than patient data alone. The result is uncontrolled disclosure of protected information into external systems that the organisation may not monitor, govern, or be able to retrieve.
Why the privacy boundary breaks so easily in long-term care
Long-term care teams often treat privacy as a chart problem, but shadow ai expands the boundary far beyond the EHR. Staff may paste resident notes, family details, shift handover context, discharge plans, incident summaries, or staffing issues into tools that are outside formal review and retention controls. That makes the privacy exposure broader, less visible, and harder to reverse once information leaves the organisation.
The practical issue is not only that the data is sensitive, it is that the business context is sensitive too. Long-term care workflows often include residents with complex needs, family advocates, contractors, agency staff, and operational details that can identify individuals even when a record fragment seems routine. A tool that can infer, store, or reuse that context creates a second privacy surface that is not captured by the EHR alone.
Unmanaged GenAI use also weakens data minimisation. Users tend to provide full context so the tool can produce a useful answer, which means more identifiers, more narrative detail, and more adjacent operational data are exposed than would normally be needed for the task. Once that information is copied into an external service, the organisation may lose practical control over where it is processed, whether it is retained, and who can access it later. For a privacy-focused control view, the NIST Privacy Framework is the clearest reference point for classification, governance, and privacy risk management.
Where shadow AI creates the biggest exposure points
Shadow AI becomes most risky when it sits between staff convenience and weak oversight. The common failure pattern is a well-meaning worker using a public or unsanctioned tool to summarise, rewrite, translate, or analyse information that should have stayed inside approved systems. That workflow is attractive because it is fast, but it can move protected information into a service that the organisation cannot audit or reliably retrieve.
The largest exposure points are usually:
- resident narratives, care notes, and assessments
- family communications and complaint handling details
- incident reports, safeguarding summaries, and clinical escalations
- staffing, rostering, and operational issues that reveal identifiable patterns
- attachments, screenshots, and copied text that include hidden identifiers
Long-term care is especially exposed because privacy harm can arise from context, not just from a named diagnosis. A short prompt that blends resident history, location, family relationships, and operational detail can be enough to identify a person or disclose their circumstances. The risk is compounded when teams assume that a tool is harmless because it is “just summarising text” rather than acting as a formal data processor.
That is why the strongest privacy controls here are governance controls, not just technical ones. The organisation needs approved use cases, data handling rules, and clear boundaries around what can never be entered into external AI tools. EU General Data Protection Regulation (GDPR) is useful here because it reinforces minimisation, purpose limitation, and security of processing. For broader privacy risk framing, the NIST Privacy Framework remains a strong organising reference.
Shadow AI also creates a retrieval problem. If a resident or regulator later asks where a data element went, the answer may be “into a tool used by one employee,” which is not an operationally useful control state. That is why this issue is more serious than casual consumer app use: the organisation can inherit privacy obligations without inheriting corresponding visibility, retention, or deletion authority.
What teams should do before the exposure becomes routine
What to verify: confirm which AI tools staff actually use, what data they are entering, and whether any of those tools are capable of storing prompts, outputs, or uploaded files. In practice, the first question is usually not “do we have an AI policy?” but “can we prove the policy matches day-to-day behaviour?”
What to prioritise: classify long-term care content by sensitivity and by recoverability. Resident-identifying information, family data, incident material, and operational records should be treated as controlled content even when no obvious medical term appears in the prompt. If a team cannot retrieve or delete what it sent, that use case should be treated as a privacy exception rather than a convenience.
Common mistake: focusing only on the EHR and ignoring every other pathway where staff create, transform, or summarise resident information. Shadow AI often enters through routine work, so the control gap is usually behavioural and procedural before it is technical.
Practitioner takeaway: The right control objective is to keep sensitive care context inside governed workflows, because in long-term care the privacy harm often comes from cumulative context, not from a single obvious record.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST SP 800-63, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST AI RMF | Govern | AI use needs governance over data handling, oversight, and risk decisions. |
| Recommendation — Establish AI governance that defines approved data use, accountability, and review for staff-entered prompts. | ||
| NIST SP 800-63 | Digital identity and lifecycle guidance — Digital Identity Guidelines | Access to AI tools and data sources depends on strong identity assurance and lifecycle control. |
| Recommendation — Tie sanctioned AI access to verified identities and revoke access promptly when staff leave or change roles. | ||
| CIS Controls v8 | 3 — Data Protection | Shadow AI can expose sensitive resident data outside approved controls. |
| 6 — Access Control Management | Only approved users and approved tools should be able to move protected information. | |
| Recommendation — Classify sensitive care data and restrict its movement into unsanctioned external services. Limit access to sanctioned AI tools and remove unapproved application paths for sensitive data sharing. | ||
| NIST CSF 2.0 | PR.DS — Data Security | The subject is fundamentally about protecting sensitive information from uncontrolled disclosure. |
| GV.RM — Risk Management Strategy | Shadow AI requires explicit privacy risk decisions and documented tolerance levels. | |
| ID.IM — Improvements | Teams need continuous discovery of new AI usage patterns and policy gaps. | |
| Recommendation — Apply data-security controls that prevent sensitive care information from leaving approved systems. Define and document acceptable AI use cases, prohibited data types, and escalation thresholds. Review observed staff AI use and update privacy controls when new workflows emerge. | ||
Related resources from NHI Mgmt Group
- Why do consumer AI answer engines create higher data privacy risk than many teams expect?
- Why do untrusted AI model files create a larger security risk than many teams expect?
- Why do service principals create a larger escalation risk than many teams expect?
- Why do long-lived keys create more risk than many IAM teams expect?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
