Generative AI arrives in an organization whether or not anyone approves it. By the time the question reaches a security team, the useful version of it is rarely whether to allow it, but how to make the allowed path better than the unapproved one.
That framing matters, because a policy that only forbids produces shadow use, and shadow use is the condition in which none of the controls below exist at all.
Start with what is already happening
An inventory before an architecture. Which tools are in use, by whom, on what material, and which of that was ever approved. It is uncomfortable and it is the only honest starting point, because the alternative is designing controls for a situation that is not the one you are in.
Two findings are close to universal. Usage is broader than management believes, and the material going into these tools is more sensitive than the people using them realize, because a document pasted into a chat box does not feel like a data transfer. Neither finding is a disciplinary matter. Both are design inputs.
Provide a good approved path
The single most effective control is a sanctioned tool that is genuinely good enough for the work. If the approved option is slower, more restricted or less capable than what people can reach on a personal account, the policy is a statement rather than a control.
Concretely, that means an enterprise tier or a controlled environment reached through single sign on, with the terms about retention and training already settled, and with the same joiner and leaver process as everything else. The comparison of private and public AI covers how to choose that path; the point here is that having one is the precondition for everything else.
The controls that carry most of the weight
Identity, not accounts
Access through your identity provider, so that leaving the organization removes access to AI along with everything else. Individual accounts on a corporate card are the pattern that produces orphaned access nobody can enumerate, and shared logins remove the ability to attribute anything at all.
This is ordinary, and it is the control most often skipped because a departmental subscription was quicker to arrange than an integration.
A decision about what may leave
Which categories of material may be sent to a third party service, expressed in a way people can apply without a lawyer. Long classification schemes fail here; two or three clear rules with concrete examples do not.
The rule has to be enforceable somewhere other than in the policy document. Depending on the tool that means restricting connectors, controlling which repositories an assistant can reach, or handling the restricted categories through a separate controlled environment. Protecting sensitive data when using AI covers the technical side in detail.
Constrain what the system can do, not only what it can read
An assistant that answers questions has a smaller blast radius than one that can send mail, modify records or run code. Both are legitimate; they are not the same risk. Where a system can act, the boundary belongs in what the surrounding application permits rather than in an instruction asking the model to be careful. OWASP tracks the failure mode as LLM06:2025 Excessive Agency in its Top 10 for LLM Applications.
Treat retrieved and pasted content as untrusted
Anything the model reads can carry instructions, and a document that says to ignore prior instructions is a plausible thing to receive from outside the organization. This is prompt injection, and the practical posture is layered: separate instructions from content in how the request is built, constrain what the system can do, and validate output before it is used anywhere it could execute.
Human review where it matters
NIST's Generative AI Profile uses the term confabulation for content that is confidently stated and false, which is a better word than the usual one because it does not imply the system perceived anything. The operational consequence is that output is a draft.
The useful distinction is not whether to review but where. Output that informs somebody's thinking needs less scrutiny than output that goes to a client, a regulator or a system of record. Deciding that in advance, per use case, is more effective than a general instruction to check the work, which nobody applies consistently once the tool becomes routine.
What to record
Who used it, for what, against which material, and what came back. Without a record, an incident cannot be reconstructed and a policy cannot be evidenced.
The counterweight is that the record is itself a store of sensitive material, frequently more concentrated than the sources, because it captures what people actually asked about. It needs its own retention period and its own access controls, and logging everything forever creates a second disclosure risk in the name of the first. AI logging, monitoring and auditing works through the trade.
Where this stops and governance starts
Everything above is configuration: what is permitted, what is restricted, what is recorded. It rests on decisions that are not technical.
Who is accountable when the system is wrong. Whether a use case is acceptable at all. What must be disclosed to a client or a regulator. How intellectual property is handled in both directions, both what goes in and what comes out. Those are governance questions, and they are covered by AI Governance and, for generative systems specifically, in generative AI governance.
The two halves fail without each other. A rule nothing enforces is a document; a control nobody decided is an accident.
A sequence that works
- Inventory first. What is in use and on what material. Expect surprises and do not treat them as violations.
- Provide a good approved path before restricting the unapproved ones, or the restriction produces evasion rather than compliance.
- Write two or three rules about what may go in, with examples, and make at least one of them enforceable technically.
- Decide review points per use case rather than issuing a general instruction to be careful.
- Turn on logging with a retention period somebody has agreed to.
- Revisit on a date. Usage grows, tools change, and an assessment from last year describes an organization that no longer exists.
Telling people, which is a control
Most of what determines whether these controls hold is what people understand, and enablement is usually treated as a training obligation rather than as part of the security design.
Three things are worth communicating specifically, because they are the ones people get wrong on their own. That pasting content into a tool is a data transfer, which is not obvious when the interface looks like a chat window. That output is a draft rather than a finding, which people know in principle and stop applying once a tool has been reliable for a month. And which two or three categories of material must never go in, stated with examples rather than as a classification scheme.
Delivered once at rollout, this decays. Delivered at the point of use, as a line in the tool itself, it holds. That is a design decision about the approved path rather than a training decision, which is why it belongs here.
Two claims to avoid making internally
That an approved tool is safe. It is safer, in defined respects, under stated terms. Describing it as safe encourages people to put material into it that the terms do not cover.
That review will catch errors. It catches some. Review quality degrades as trust in a tool grows, which is precisely when the errors become consequential. Where an error would be serious, the control needs to be structural rather than attentional.
Where to go next
The technical data controls are in protecting sensitive data when using AI, and the access model in AI identity and access management. If the material in question is your own documents, what enterprise RAG is is the relevant mechanism.
LABUSA examines an existing AI environment as it stands and reports what would have to change, as an enterprise AI security review. Get in touch to discuss scope.
Sources and further reading
- National Institute of Standards and Technology, AI Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1, July 2024.
- OWASP GenAI Security Project, OWASP Top 10 for LLM Applications, 2025, including LLM01 Prompt Injection and LLM06 Excessive Agency. Community security guidance, authoritative on threats rather than on regulatory obligation.
- National Institute of Standards and Technology, Security and Privacy Controls for Information Systems and Organizations, SP 800-53 Revision 5.
Every source above was opened and read on 20 August 2026.