Why do healthcare organisations need a data-centric approach when securing AI and cloud environments?

Healthcare data is highly sensitive, widely distributed, and heavily regulated, so identity controls alone do not provide enough protection. A data-centric approach helps teams understand what data exists, where it moves, who can access it, and whether policy drift has increased exposure. That visibility is essential for reducing breach impact and supporting compliance obligations.

Why This Matters for Security Teams

Healthcare organisations cannot rely on identity checks alone because AI services, cloud workloads, and data pipelines move sensitive records faster than human review cycles can keep up. The practical risk is not just unauthorised login. It is excessive data exposure, overbroad service-to-service access, and hidden replication across storage, analytics, and model workflows. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls makes clear that access control, auditability, and data protection must work together, not in isolation.

This is especially important in environments handling protected health information, research data, claims data, and AI training sets. Once data is copied into notebooks, object stores, vector databases, or model prompts, the original identity boundary often no longer reflects the real exposure boundary. NHIMG research on the Ultimate Guide to NHIs — Key Research and Survey Results shows that 88.5% of organisations say non-human IAM lags human IAM, which helps explain why identity-only thinking leaves blind spots in cloud and AI estates. In practice, many security teams discover the gap only after data has already been over-shared, indexed, or copied into systems that no one intended to expose.

How It Works in Practice

A data-centric approach starts by classifying the data itself, then mapping its movement across cloud services, AI tooling, and downstream consumers. The question shifts from “who logged in?” to “what data is this, where is it now, and what policy should follow it?” That means tagging sensitive records, enforcing encryption and tokenisation where appropriate, and tracking access at the object, row, column, or file level rather than only at the account level. This is the operational logic behind current guidance in privacy and cloud control frameworks.

For AI workloads, the same approach must extend to prompts, embeddings, model outputs, and retrieval layers. If a copilot, search assistant, or agent can retrieve regulated data, the organisation needs visibility into which datasets were used, which services touched them, and whether that access was justified. This becomes even more important when secrets or credentials can be exposed through misconfigured storage or third-party integrations. Recent NHIMG reporting on the DeepSeek breach and Azure Key Vault privilege escalation exposure illustrates how quickly sensitive material can spread once data governance is weaker than identity governance.

• Classify data by sensitivity and regulatory impact before it enters AI or analytics pipelines.
• Enforce least-privilege access at the data layer, not only at the identity layer.
• Use continuous discovery to find shadow copies in object stores, caches, logs, and vector indexes.
• Apply policy-as-code so controls can evaluate data context at request time.
• Monitor for policy drift when workloads change, new connectors are added, or models are retrained.

That approach aligns well with zero trust thinking, but the implementation must be data-aware rather than account-aware. These controls tend to break down in hybrid healthcare environments where legacy systems, SaaS platforms, and AI tools all replicate the same record into separate trust zones.

Common Variations and Edge Cases

Tighter data controls often increase operational overhead, requiring organisations to balance stronger protection against slower workflows and heavier governance effort. That tradeoff is real in healthcare, where emergency care, clinical research, and revenue-cycle operations all create legitimate exceptions. Current guidance suggests the answer is not to weaken controls globally, but to define narrowly scoped exceptions with strong logging and expiry.

There is also no universal standard yet for how to govern AI prompts, embeddings, and model outputs as data assets, so teams should treat this as an evolving practice rather than a settled one. Some environments need row-level controls; others need file-level segmentation or token-level suppression before data reaches an LLM. The right choice depends on where PHI appears, how it is transformed, and whether the AI system can regenerate or expose the underlying record. NHIMG coverage of the Snowflake breach is a reminder that shared platforms can multiply exposure when data governance is not enforced consistently.

In regulated cloud estates, a data-centric model also supports incident response because it narrows which records were actually accessible, not just which accounts existed. That distinction matters when breach scope must be proven to auditors, insurers, regulators, and clinical stakeholders.

Related resources from NHI Mgmt Group

• How should healthcare organisations govern AI when data comes from many systems?
• Why do traditional access controls fail to protect sensitive data in cloud and AI environments?
• How can organisations detect cross-cloud AI abuse before data is exposed?
• Should organisations re-evaluate CNAPP after major AI adoption in cloud environments?