What should organisations do before enabling RAG or training on lakehouse data?

They should verify classification coverage, reduce broad access, confirm ownership of non-human identities, and remove shadow copies that could be pulled into the workflow. If the organisation cannot explain what the data contains and which identities can reach it, the AI use case is not ready for production.

Why This Matters for Security Teams

RAG and training pipelines can turn ordinary data sprawl into model exposure if the underlying lakehouse is not governed first. The core issue is not simply storage volume, but whether teams can prove data lineage, classify sensitive content, and control which human and non-human identities can read or write the corpus. The moment retrieval or training is enabled, weak access boundaries become model inputs, and those inputs can be surfaced in outputs, logs, embeddings, or downstream fine-tuning artefacts.

This is why security review has to happen before the AI feature switch, not after the first prompt. Guidance in the NIST Cybersecurity Framework 2.0 maps cleanly here: identify assets, protect data, and govern access in a way that reflects actual business use. For AI systems, that means treating the lakehouse as a supply chain input, not a passive repository. Ownership, retention, and access paths need to be explicit enough that the security team can explain what the model might learn and who can influence it.

In practice, many security teams encounter model leakage only after a retrieval index or training job has already amplified poorly governed data.

How It Works in Practice

Before enabling RAG or training, organisations should establish a control baseline for the data estate that feeds the model. That baseline starts with classification coverage, because retrieval and training are only as safe as the labels, lineage, and access controls behind the source data. It should also include a review of non-human identities, service accounts, connectors, and automation jobs, since those identities often have wider reach than the people who own the content.

A practical pre-launch review usually includes:

• Confirming which datasets are approved for retrieval or training, and which are excluded.
• Mapping data owners to each source, including shadow repositories and replicated copies.
• Reducing broad read access on lakehouse tables, object stores, notebooks, and vector indexes.
• Checking whether service accounts and API credentials are scoped to the minimum necessary data paths.
• Reviewing data retention, deletion, and re-indexing rules so stale content does not re-enter the pipeline.

For model-facing workflows, the key question is whether the organisation can prove provenance and explainability of inputs, not just whether the platform is technically reachable. Current guidance suggests aligning this work with data security, identity governance, and AI risk controls rather than treating it as a pure MLOps task. The NIST Cybersecurity Framework 2.0 is useful for structure, while AI-specific risk thinking should also consider prompt injection, training data poisoning, and retrieval contamination. These controls tend to break down when legacy data lakes contain duplicated data, unmanaged service principals, and ad hoc analyst exports because provenance and entitlement review no longer match reality.

Common Variations and Edge Cases

Tighter data controls often increase implementation overhead, requiring organisations to balance model speed against governance depth. That tradeoff is real, especially when teams want rapid experimentation but do not yet have a stable data catalogue or identity model.

There is no universal standard for exactly how much data minimisation is enough before a RAG rollout, but best practice is evolving toward “approved corpus only” rather than “index everything and filter later.” In regulated environments, the threshold should be higher if the corpus includes personal data, financial records, customer support transcripts, or sensitive operational content. If the lakehouse also powers analytics, the organisation may need separate policies for human analytics access and AI retrieval access, because an account that is acceptable for dashboarding is not automatically acceptable for model ingestion.

Edge cases often appear when a business unit inherits a shared lakehouse, when external connectors pull in files from collaboration tools, or when shadow copies sit in test environments that were never decommissioned. Those cases matter because AI systems often ingest from the path of least resistance, not the path of intended governance. When the organisation cannot trace which non-human identity created or refreshed a dataset, that uncertainty should be treated as a release blocker rather than a documentation gap.

Related resources from NHI Mgmt Group

• What should organisations do before allowing Microsoft Copilot or similar tools to access regulated data?
• What should organisations check before relying on a managed training platform for custom AI models?
• Should organisations prioritise AI data governance before scaling AI adoption?
• How can organisations reduce the risk of secrets in AI training data?