Official intent
Adopt AI capabilities securely, protecting sensitive defense information from exposure through AI tools. The official source remains authoritative.
Read the official campaign ↗AI is entering the workplace whether you plan for it or not. Secure adoption means deciding — before staff paste data into a chatbot — which tools are approved, what data may and may not go into them, and how AI use is governed and logged. The goal is to capture AI's value without leaking CUI or feeding sensitive data into systems you do not control.
Who this applies to: Every organization, whether or not AI adoption is a strategy. Staff are already using these tools; the only decision is whether the use is governed.
Why it matters
Public AI tools can retain, train on, or expose whatever is entered into them. A single prompt containing controlled or proprietary information can put CUI outside your boundary in seconds — an unmonitored, unauthorized data flow. Governing AI use turns an uncontrolled shadow-IT risk into a managed capability with clear rules.
Risks this reduces
- Controlled or proprietary information pasted into a consumer AI service
- Data retention or model training on content you did not intend to share
- Unsanctioned AI tools and browser extensions operating as shadow IT
- Over-trusted AI output driving decisions without verification
Who owns it
Engineering lead
IT leader, Security lead, Executive sponsor
Medium
Low to medium
Ownership is a named person, not a department. If nobody can be named, that is the first finding.
Dependencies and prerequisites
Leans on: IT-02 — Asset inventory
- A data classification that staff can actually apply — at minimum, what is controlled and what is not
- A sanctioned tool staff can use, so the policy has an alternative to point at
- Visibility into which AI services are already being reached from your network
Action timeline
- Publish an interim rule: no CUI or sensitive data in public AI tools
- Identify which AI tools staff are already using
- Publish an interim rule — no controlled or sensitive data in public AI tools — and tell people what they may use instead
- Inventory the AI tools and browser extensions already in use, including ones embedded in products you own
- Choose approved enterprise AI tools with acceptable data terms
- Write and communicate an AI acceptable-use policy
- Route AI access through managed accounts and log usage
- Extend data-loss prevention to flag sensitive content heading to AI
- Align governance to the NIST AI RMF
- Train staff on what may and may not go into AI tools
The 90-day target for this practice is the Measured level below: coverage and effectiveness are reported, and exceptions are handled rather than accumulated.
Step-by-step implementation
- Inventory the AI tools already in use — including browser extensions and embedded assistants.
- Decide which tools are approved and require enterprise terms that prohibit training on your data.
- Publish an AI acceptable-use policy that classifies what data may and may not be entered.
- Provide sanctioned tools so staff have a compliant option, and route access through managed identities.
- Log AI usage and extend data-loss prevention to detect CUI or sensitive data heading to AI services.
What good looks like
Seven levels, used identically across every practice, scorecard, and download on this site. The distinction that matters most is between having a tool, deploying it to the correct scope, and operating it consistently.
- Absent
No rule, no sanctioned tool, and no idea what staff are using.
Is there anything at all — a tool, a document, a person who owns it? - Documented
An acceptable-use policy defines approved tools and what data may never be entered.
Is the intent written down, with a named owner and a scope? - Configured
At least one enterprise AI tool is provisioned with terms that prohibit training on your data.
Is it switched on and set up somewhere — even if only in part of the estate? - Deployed
Staff have sanctioned access through managed identities, and known unapproved services are blocked or flagged.
Does it cover everything in scope, with the exceptions written down? - Measured
Usage and policy-violation attempts are reported, and the approved-tool list is re-checked against changing vendor terms.
Can you state a number for coverage or effectiveness, and show the trend? - Governed
AI governance has an owner and a review cadence, aligned to a recognized framework, with training refreshed as tools change.
Is there an accountable owner, a review cadence, and retained evidence?
Validation procedures
Until these pass, the practice is configured — not deployed.
- Confirm the approved AI tools' terms prohibit using your data for training.
- Test that a data-loss rule flags a document marked CUI when sent to an AI tool.
- Review usage logs for access to unapproved public AI services.
Evidence to retain
AI acceptable-use and data-classification policy
Approved-tool list with data-protection terms; DLP rules for AI
AI usage logs and review of unapproved-tool access
DLP test result and periodic tool/terms review
Retaining these supports your own assurance and gives a reviewer something concrete to examine. It does not constitute an assessment or satisfy a contractual requirement on its own.
Operating metrics
| Metric | How it is calculated | Directional target |
|---|---|---|
| Sanctioned-tool share | AI sessions through managed accounts ÷ observed AI sessions. | Rising toward full coverage. |
| Sensitive-content interceptions | Data-loss events where controlled content was heading to an AI service. | Detected every time; trending down as training lands. |
| Vendor terms review | Approved tools whose data-retention and training terms were re-verified this period. | 100% at each review cycle. |
Targets are directional guidance for your own programme, not compliance thresholds.
Common failure modes
A policy that bans AI while everyone quietly uses it anyway, approving a tool without reading its data-retention terms, and treating AI output as automatically safe or accurate. Prohibition without a sanctioned alternative just drives the risk into the shadows.
Two sized paths
Pick one enterprise AI tool with acceptable data terms, provision it through your existing identity provider, and publish a one-page rule: this tool for work, nothing controlled in anything else. Prohibition without a sanctioned alternative just moves the activity somewhere you cannot see it.
Govern against the NIST AI Risk Management Framework, classify data well enough that data-loss rules can act on it, log AI interactions where the platform allows, and review tools and prompts periodically — vendor terms change more often than policies do.
Tool categories
Categories, not recommendations. This site ranks no vendors and accepts no paid placement.
Blocking AI services without providing a sanctioned path reliably produces workarounds. Sequence it: provide the approved tool, communicate the rule, then restrict. Treat additions to the approved-tool list as a reviewed change, including a read of the vendor's current data terms.
Framework mappings
Independent mappings are aids to your own analysis — not authoritative equivalence, not coverage, and not a compliance determination. Read the caveat on every row before using it.
Why: The GOVERN and MAP functions cover establishing AI policy, roles, and context — the governance half of this practice.
What this does not claim: The AI RMF is voluntary guidance. It carries no contractual obligation and is not an assessable standard.
Why: The same reasoning carries to the inherited CMMC practices.
What this does not claim: Supports the requirement; it does not satisfy it on its own and does not establish an assessment outcome. Scope, implementation quality, and evidence decide that.
Why: Data access control and data-loss prevention describe the technical enforcement side of this practice.
What this does not claim: CIS is a voluntary benchmark. Alignment with it carries no contractual weight.
Method: Read against the primary source text, then classified by relationship type and confidence. No automated mapping tool was used. How mappings are made →
NIST SP 800-171 relationships have their own requirement-level section below, with links into the full mapping experience.
Related NIST SP 800-171 requirements
Requirement-level relationships from the site’s independent 800-171 mapping. Each one names what it does and does not claim — a practice supports implementation of a requirement; it never satisfies one by itself. Expand a row for the rationale and caveat.
NIST SP 800-171 Rev. 2
3.1.3CUI flow controlContextual relationshipModerate
Why: Governing which AI services may receive which classes of information is a flow-authorization decision for one specific and fast-growing destination: sanctioned tools become an approved flow path, and the practice's blocking and policy work constrains the unapproved ones.
What this does not claim: SP 800-171 has no AI-specific requirement, and this relationship holds only where an AI service would handle CUI — governance of uncontrolled data flowing to AI tools is good practice but outside the requirement. The bulk of 3.1.3 — internal network flow enforcement, email and media channels, the approved-authorization record — is untouched by AI governance.
Review status: Technical review complete.
Open the 3.1.3 page →3.1.20External system connectionsPartial implementation supportModerate
Why: Third-party AI services are external systems, and the practice does to them exactly what this requirement asks: inventory what is in use, sanction specific services under known terms, and limit or block the rest.
What this does not claim: External systems reach far beyond AI — personal devices, partner networks, every unsanctioned cloud service — and the practice governs only the AI class, so the requirement's full inventory and verification work remains. Sanctioning a tool also requires verifying its handling terms (retention, training use, tenancy) against your obligations, which takes contract and configuration review the acceptable-use rule alone does not provide.
Review status: Technical review complete.
Open the 3.1.20 page →3.13.16CUI at restContextual relationshipModerate
Why: Deciding which AI services may receive, retain, or train on sensitive data — the data-protection half of this practice — determines where CUI is permitted to come to rest in the first place, which is the scoping decision at-rest protection depends on.
What this does not claim: Informs the requirement without acting on its substance: the practice encrypts no storage and configures no at-rest protection anywhere. Every location where CUI legitimately rests — file servers, endpoints, cloud tenants, backups — needs its own protection decisions and evidence, and an AI-usage policy governs only the new resting places AI adoption would otherwise create.
Review status: Pending NIST SME review.
Open the 3.13.16 page →NIST SP 800-171 Rev. 3
03.01.20Use of External SystemsContextual relationshipModerate
Why: External AI services are external systems in this requirement's sense the moment CUI could reach them, and the practice's sanction-and-boundary decisions about AI tools inform which such uses are authorized and under what conditions.
What this does not claim: Informs the approach; it does not implement the requirement's machinery. The default prohibition, defined security conditions, verification, retained agreements, and portable-storage restriction span every external system — partner networks, home computers, all unvetted SaaS — of which AI services are one slice. A strong AI-adoption stance leaves the rest of the external-system population unexamined.
Review status: Pending NIST SME review.
Open the 03.01.20 page →03.04.11Information LocationPartial implementation supportModerate
Why: The practice's precondition is knowing what information is controlled and where it lives — a data classification staff can apply, discovery of where sensitive content already sits, and data-loss rules pointed at those places. That location knowledge is the substance this requirement wants identified and documented for CUI.
What this does not claim: May partially address the requirement: the practice reaches information location only as far as AI-exposure protection needs it, while the requirement wants CUI locations and their system components documented comprehensively and kept current through changes, whether or not AI is in use. An organization could run this practice well and still lack the component-level CUI location record an assessor asks for.
Review status: Pending NIST SME review.
Open the 03.04.11 page →03.13.08Transmission and Storage ConfidentialityContextual relationshipModerate
Why: The practice's data-protection work — deciding which AI services may receive which data, and blocking CUI from leaving approved boundaries — determines where CUI is transmitted and stored, which is the scope this requirement's cryptographic mechanisms must then cover.
What this does not claim: The practice informs the requirement's scope without acting on its substance: it implements no cryptography. Whether CUI in transit to, or at rest within, an approved service is cryptographically protected is a property of that service's configuration and the organization's parameter choices, and it must be assessed on its own evidence regardless of how well AI data flows are governed.
Review status: Pending NIST SME review.
Open the 03.13.08 page →03.14.08Information Management and RetentionContextual relationshipModerate
Why: Secure AI adoption forces the questions this requirement institutionalizes — what data an AI tool retains, for how long, and under whose terms — so the practice's data-protection decisions inform CUI retention management for one fast-growing class of services.
What this does not claim: The practice informs the requirement without acting on its substance: information management and retention spans every repository holding CUI, driven by records schedules and legal authorities, and the practice touches only the AI-tool slice of that landscape. Retention terms negotiated for AI services are a contribution to the requirement's implementation, not an implementation of it.
Review status: Pending NIST SME review.
Open the 03.14.08 page →Review status
| Technical review | Reviewed |
|---|---|
| Editorial review | Reviewed |
| Reviewed by | inDirectIT practitioner review — CUI security and NIST SP 800-171 engineering |
| Last reviewed | |
| Official source verified | |
| Content version | 1.0 |