Why do organisations need different controls for AI-generated code and for employees using GenAI systems with sensitive data?

The risks are different. AI-generated code can introduce insecure logic, hallucinated dependencies, and embedded secrets into software delivery. Employee use of GenAI can exfiltrate PII, intellectual property, or financial data through prompts. Because the ownership, enforcement point, and evidence trail differ, organisations need separate control models and tooling.

Why This Matters for Security Teams

AI-generated code and employee use of GenAI create different failure modes, so they cannot be governed with the same control set. Code generation risks land in the software delivery pipeline, where insecure patterns, unsafe dependencies, and secrets exposure can become production defects. Employee prompting risks land in data governance, where sensitive information can leave approved boundaries through chat logs, uploads, or connected tools. The distinction matters because the control owner, the enforcement point, and the audit evidence are not the same.

Security teams often treat both as a single “GenAI policy” issue, but that usually blurs responsibilities across engineering, legal, privacy, and the SOC. A software control can require code review or dependency scanning, while a data control can require DLP, prompt filtering, and approved usage boundaries. NIST’s NIST AI 600-1 GenAI Profile is useful here because it separates governance, mapping, measurement, and management into practical actions for GenAI risk. In practice, many security teams encounter the business impact only after sensitive data has already been pasted into a chat interface or insecure code has already moved into the main branch, rather than through intentional control design.

How It Works in Practice

Organisations need two control models that are related but not interchangeable. For AI-generated code, the focus is on the software supply chain and secure development lifecycle. That means controlling where code is allowed to originate, scanning for insecure constructs, checking dependencies, reviewing output before merge, and preventing secrets from being embedded in repositories or build artefacts. For employee use of GenAI with sensitive data, the focus is on information handling. That means defining what data may be entered, where prompts are stored, whether retention is allowed, and how output is classified before it is reused.

Operationally, this usually means pairing engineering controls with governance controls:

• Use code review, SAST, dependency scanning, and secret detection for AI-generated code.
• Restrict approved GenAI tools for staff handling regulated or confidential data.
• Apply DLP, data classification, and logging controls to prompt and output flows.
• Set policy for human approval when GenAI output influences production code or business decisions.
• Track evidence separately so software assurance and data-loss events are not conflated.

NIST SP 800-53 Rev 5 Security and Privacy Controls helps translate this split into control families such as access control, audit and accountability, system and communications protection, and configuration management. The key is to enforce controls at the point of risk: the IDE and build pipeline for code, the chat or copilot interface for sensitive data. These controls tend to break down when organisations allow unmanaged browser-based GenAI tools on endpoints that also have access to source code, customer records, or internal knowledge bases, because the same session can cross both risk domains without clear logging or enforcement.

Common Variations and Edge Cases

Tighter GenAI control often increases friction for developers and staff, requiring organisations to balance speed against assurance. That tradeoff is real, and best practice is evolving rather than fully standardised. Some teams will accept AI-assisted coding only in low-risk services, while others permit it broadly but require stronger review gates. Similarly, some employers allow prompts against synthetic or redacted data, while others prohibit any sensitive data in public or unmanaged tools.

Edge cases usually appear when the same AI workflow spans both domains. For example, an employee may paste production logic into a GenAI assistant to debug code, creating both code-quality and data-exposure risk. Another common case is RAG connected to internal repositories, where a user thinks they are asking a writing assistant but is actually querying governed content. Where AI systems are agentic or connected to development tooling, the boundary between “code generation” and “data use” becomes thinner, so current guidance suggests separate policies with a shared escalation path. Organisations should also consider whether vendor contracts, retention settings, and model training opt-outs are aligned with internal data classification rules and software assurance requirements.

There is no universal standard for this yet, but the practical direction is clear: treat code risk and data risk as related control problems, not as one policy statement. The right design is usually a layered model that combines software engineering controls, privacy controls, and user-acceptable-use controls, with evidence captured separately for each.

Related resources from NHI Mgmt Group

• Should organisations change IAM controls when AI-generated code uses secrets or service accounts?
• Should organisations use different controls for human and AI data risks?
• Should organisations use AI-generated code in security-sensitive workflows?
• Should organisations use the same controls for human-written and AI-generated code?