Data security controls answer what information is visible, protected, and allowed to move. Compliance controls answer whether that handling is auditable and aligned to policy or regulation. In generative AI, both are required because service entitlement alone cannot prove that prompts, outputs, and stored artefacts were handled correctly.
Why data security and compliance controls split in generative AI
Generative AI changes the control boundary because prompts, retrieved context, outputs, training artefacts, logs, and tool calls can all carry sensitive information. Data security controls are aimed at keeping that material visible only to the right parties and preventing it from moving where it should not. Compliance controls are aimed at proving the handling was authorised, traceable, and policy-aligned.
That split matters because a model can be “allowed” to process data in an entitlement sense and still fail if the data was overexposed, retained too broadly, or copied into records that were never meant to exist. Conversely, a workflow can be technically locked down and still fail audit if you cannot show who approved the use, what was recorded, and how retention and disclosure were governed.
In practice, data security asks whether the right guardrails were in place around content and movement. Compliance asks whether those guardrails were measurable, documented, and defensible after the fact. Generative AI systems force both questions to be answered at the same time because the same interaction can create immediate exposure and later evidentiary obligations.
What data security controls protect in a generative AI workflow
Data security controls focus on the content itself: classification, masking, tokenisation, encryption, access restriction, retention limits, and controls on what is sent into prompts or retrieved from connected systems. The question is not only whether the model can see data, but whether it should see that data at all, and whether outputs can be exported or reused safely.
This is especially important for prompts and retrieval-augmented generation, where users often paste business records, source code, customer data, or credentials into a system that was designed for fluent text generation rather than safe handling of sensitive artefacts. At scale, the control problem becomes one of blast radius: if one chat, connector, or workspace is too permissive, the model can surface data far beyond the original request.
For practitioner teams, the most useful data-security question is whether the model and its surrounding tools are operating on the minimum data necessary. That includes controlling what is indexed, what is cached, what is retained in logs, and what can be echoed back in outputs or summaries.
What compliance controls prove in generative AI
Compliance controls focus on whether the organisation can demonstrate governance over AI use. That usually means audit logs, approval records, policy enforcement evidence, records of data-sharing choices, retention decisions, incident handling, and the ability to show that the system’s behaviour matches internal policy and external obligations.
In generative AI, this often extends beyond the model itself to the full chain of use: who was permitted to use the system, what categories of data were allowed, whether disclosures were logged, and whether outputs that influenced business or regulatory decisions were reviewable later. Where regulated data is involved, the requirement is not only “was access restricted?” but “can you prove the handling was lawful and consistent?”
Current guidance from NIST AI 600-1 GenAI Profile reflects this dual need by linking generative AI governance to provenance, testing, and incident disclosure. For organisations building cloud-based AI controls, the CSA Cloud Controls Matrix is a useful reference point because it connects data security, IAM, auditability, and cloud operational control in one model.
Why both control types are required, not optional
Data security without compliance leaves you unable to prove why the data was handled that way. Compliance without data security leaves you with records of unsafe handling rather than actual protection. Generative AI makes that gap visible because the system can create, transform, and distribute data faster than traditional review processes can observe.
A practical example is an AI assistant that is entitled to use a source repository or document store. That entitlement may satisfy a platform access check, but it does not answer whether the prompts exposed sensitive material, whether the output was retained appropriately, or whether the interaction can be reconstructed for audit. The same is true for connectors, plugins, and agent workflows that can move information between systems.
For that reason, practitioners should treat service entitlement as a starting condition, not as evidence of correct handling. The real control objective is to keep data exposure, transformation, logging, and retention inside a governed envelope that can be demonstrated after the fact.
Risk and Threat Considerations
Generative AI increases the chance that sensitive data will be copied, summarised, re-emitted, or retained in places that were not designed for long-term protection. The main risk is not only leakage to outsiders, but uncontrolled internal dissemination through prompts, outputs, logs, and connected tools.
Failure mechanism: Overbroad access, weak redaction, permissive connectors, and excessive retention allow sensitive prompts or artefacts to move through the AI stack without adequate control or traceability.
Impact: The result can be confidentiality loss, policy breach, failed audit evidence, regulatory exposure, and a larger blast radius if the same data is reused across workflows or models.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and NIST AI 600-1 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Generative AI needs audit evidence for prompts, outputs, and access. |
| AC-6 — Least Privilege | AI tools should only access the data and systems needed for the use case. | |
| SC-28 — Protection of Information at Rest | Stored prompts, logs, and artefacts need protection when retained by AI systems. | |
| Recommendation — Log AI inputs, outputs, and admin actions to support audit and investigation. Limit AI tool and data access to the minimum required for the task. Encrypt retained AI data and restrict access to stored artefacts. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Generative AI handling depends on controlled access to data, prompts, and outputs. |
| A.8.15 — Logging | AI use requires logs that support traceability and post-event review. | |
| Recommendation — Define and enforce access rules for AI data sources and outputs. Record AI activity needed for monitoring, incident response, and audit. | ||
| NIST AI 600-1 | Generative AI Profile | The GenAI profile directly addresses provenance, testing, and incident disclosure. |
| Recommendation — Apply the GenAI profile to govern provenance, testing, and disclosure. | ||
Practitioner Guidance
What to verify: Verify that prompt inputs, retrieval sources, output storage, and logs each have explicit data-handling rules. If any layer is exempt from review because it is “just model traffic,” the control design is incomplete.
Decision rule: If the AI workflow can see regulated, confidential, or business-critical data, require both data-handling controls and evidence-producing controls before broad rollout. Do not accept access entitlement as proof of compliant processing.
What good looks like: The organisation can show which data classes are allowed, where that data can move, how long it is retained, who approved the use case, and how the interaction would be reconstructed during an audit or investigation.
Practitioner takeaway: In generative AI, the safe design question and the audit question are different, and mature controls answer both.
Related resources from NHI Mgmt Group
- How do IAM and NHI controls affect generative AI data security?
- How should security teams implement employee data access controls when staff use generative AI and productivity tools?
- Why does generative AI create security and compliance risk when it is fed incident data or sensitive logs?
- How do organisations decide where AI data security controls should sit?