StealthTech
A design engineer at a machine shop outside Sarasota pastes a drawing revision into ChatGPT to get a faster tolerance calculation. A project coordinator in Boston uses Claude to draft a proposal response, copying in boilerplate from a prior DoD contract. Neither one thinks twice about it, because neither one has been told not to — and neither one realizes that the moment CUI or FCI touches a public model’s input field, the contractor’s compliance posture just changed without anyone in leadership signing off on it.
This is the actual state of AI adoption inside most small and mid-sized defense contractors right now. Not a controlled rollout with governance and audit logging, but a patchwork of individual employees finding tools that make their jobs easier and using them the way they’d use a personal Gmail account. The absence of a written AI usage policy doesn’t mean AI isn’t in use. It means AI is in use without guardrails, without a data flow diagram, and without anyone able to answer a DIBCAC assessor’s question about where sensitive data has actually traveled.
Building a policy that closes that gap without turning your team into a group of people afraid to touch a new tool is a narrower problem than most guidance treats it as. It’s not about banning AI. It’s about defining, in writing, which data can go where, which tools are sanctioned, and who’s accountable when a shortcut turns into an incident.
Where CUI Actually Leaks: Mapping the Real Risk Surface Before You Write a Word
Most AI policies get written backward. Someone drafts a set of rules first, then tries to map them onto the organization’s actual workflows, and the result is a document that either misses the real exposure points or restricts activities nobody was doing anyway. The better starting point is a data flow exercise: walk through every place an employee currently touches a document, drawing, spreadsheet, or communication that might contain Controlled Unclassified Information, and ask what tool they’d reach for if they wanted AI to help with it.
For an engineering team, that’s CAD files, technical data packages, and test results. For finance, it’s contract pricing data and DCAA-adjacent cost models. For a program manager, it’s proposal narratives that quote directly from a Statement of Work. Each of these has a different risk profile depending on whether the underlying contract carries DFARS clauses tied to covered defense information under DFARS 252.204-7012, and each department needs its own answer rather than one blanket rule applied company-wide.
This is where a lot of contractors underestimate the work. The compliance team can’t write this policy in isolation, because they don’t know which of the twelve tools an engineering lead has bookmarked. The policy has to come out of a joint exercise between IT, compliance, and the department heads who actually know where the data lives day to day.
Public LLMs, Shadow AI, and the DFARS Problem You Can’t Ignore
The distinction that matters most in this entire policy is the one between a consumer-facing AI tool and an enterprise deployment with a contractual data processing agreement. ChatGPT’s free tier, Gemini’s consumer version, and most browser-based AI assistants retain user inputs by default for model improvement unless an organization has negotiated an enterprise agreement that explicitly excludes this. That single fact is the crux of the entire policy — not because the tools are inherently insecure, but because feeding CUI into a system with no contractual guarantee about data handling is functionally identical to emailing that data to an unknown third party.
NIST SP 800-171 doesn’t mention generative AI by name because the current revision predates the mainstream adoption curve, but the control families around access control, media protection, and system and communications protection apply with full force regardless of what tool is moving the data. An AI usage policy isn’t a new compliance category sitting outside your System Security Plan — it’s an operational extension of controls you’re already assessed against.
This is also where the term “shadow AI” earns its place in the conversation. It refers to employees adopting AI tools on their own initiative, often through free browser extensions or personal accounts, without IT’s knowledge. A cybersecurity program built around endpoint monitoring and firewall rules doesn’t automatically catch a user pasting text into a web form — this requires either DNS-level filtering of unsanctioned AI domains or, more sustainably, a policy people actually understand and follow because it was built with their workflow in mind rather than imposed on top of it.
What Belongs in the Policy — and What You Should Leave to Other Documents
A policy that tries to cover acceptable use, tool approval, incident response, data classification, and training requirements in one document tends to become unreadable, and an unreadable policy gets skimmed once and ignored. The AI usage policy itself should be narrow: what data classifications may or may not be entered into AI tools, which tools are approved for which purposes, and what the consequences are for violations. Data classification schemes, incident response procedures, and training curricula can live as referenced appendices or link out to existing documents your compliance function already maintains.
The policy also needs an explicit statement about output, not just input. An AI-generated draft of a technical response, a summary of a contract, or code suggested by a coding assistant needs a human review step before it’s treated as final work product — not because AI output is unreliable in some abstract sense, but because an employee who didn’t write something is less likely to catch an error in it, and a subtly wrong compliance claim or technical spec buried in AI-generated text is exactly the kind of thing that surfaces during an audit at the worst possible moment.
Where the policy intersects with your broader technology roadmap — evaluating new AI-driven tools for the business, not just governing employee behavior — that’s a separate conversation best had through your AI integration planning rather than folded into the usage policy itself. Conflating “here’s how we vet new AI tools for the company” with “here’s what an individual employee can and can’t do with ChatGPT” muddies both documents.
Building Role-Based Tiers Instead of a Blanket Ban
The single biggest mistake in AI policy design is treating every employee the same way. A blanket “no AI tools” policy is easy to write and almost impossible to enforce, because it ignores the fact that a marketing coordinator drafting a newsletter and a mechanical engineer handling ITAR-adjacent drawings have completely different risk profiles. A tiered structure gets you further:
- General administrative use — scheduling, internal communications, non-technical drafting — can typically use approved AI tools with minimal restriction, provided no client-identifiable or contract-specific data is entered.
- Client- and contract-facing roles — proposal writers, account managers, project coordinators — need clear rules about which contract details can be referenced in an AI prompt, since even seemingly benign contract numbers or program names can qualify as sensitive depending on the customer.
- Technical and engineering roles handling CAD data, technical data packages, or test results should be restricted to approved, enterprise-grade tools with contractual data protections, or barred from using AI tools on this category of data entirely until such a tool is vetted.
- Finance and compliance staff working with cost data, SSPs, or POA&Ms need the strictest tier, since this data directly informs your CMMC assessment posture.
This tiering does more than reduce risk. It also prevents the policy from becoming an productivity tax on employees whose work genuinely doesn’t touch sensitive data, which is usually the majority of the headcount at a small or mid-sized contractor.
Approved Tools vs. Shadow AI: Vetting Before You Deploy
Once the tiers exist, someone has to own the process of vetting which specific tools qualify for which tier — and this ownership question trips up more organizations than the vetting criteria themselves. In practice, this responsibility usually sits with whoever manages your managed IT services relationship or, for contractors running a hybrid internal-external model, your co-managed IT partner, working alongside your compliance lead.
Vetting an AI tool for use against CUI or FCI means reviewing its data retention policy, confirming whether an enterprise agreement exists that excludes training-data use, checking where data is processed and stored geographically, and verifying whether the vendor will sign a data processing agreement with terms your legal counsel is comfortable with. Most consumer AI products fail this bar outright. Enterprise tiers of major platforms increasingly pass it, but “increasingly” is doing a lot of work in that sentence, and the answer changes often enough that this can’t be a one-time evaluation — it needs a recurring review cadence, ideally tied to your annual security assessment cycle.
A vCIO engagement is a natural home for this ongoing evaluation work, since it already involves the kind of technology roadmap planning that AI tool vetting fits into, rather than treating it as a one-off IT ticket that gets closed and forgotten.
Training That Sticks: Beyond the Annual Click-Through
A policy nobody reads carefully might as well not exist, and the standard once-a-year compliance training video is precisely the format most likely to be ignored. AI usage training works better as short, role-specific sessions tied to actual scenarios: showing an engineering team exactly what a prohibited prompt looks like versus an approved one, rather than reading them a paragraph of policy language.
The training also needs to address a psychological reality that policy documents tend to skip: employees adopt shadow AI tools because the sanctioned alternative is slower or clunkier, not because they’re trying to violate policy. If the approved AI tools are genuinely harder to use than the free consumer versions employees already know, the policy will get quietly circumvented regardless of how clearly it’s written. Part of the job of whoever owns this rollout is making sure the sanctioned path is actually competitive on convenience, which sometimes means investing in a better enterprise tool rather than simply restricting access to the popular ones.
Refresher training tied to actual incidents — even near-misses — tends to land harder than scheduled annual sessions. If someone in your Boston office nearly pastes proposal pricing into a public chatbot and catches themselves, that’s a better training moment shared (anonymized) across the team than another slide deck.
Enforcement Without Killing Morale
Enforcement is where most AI policies either fall apart from being unenforced or backfire from being enforced too rigidly. A policy that’s purely aspirational, with no mechanism for detecting violations, teaches employees that the rules are optional. A policy enforced through heavy-handed monitoring and immediate disciplinary action for every infraction teaches employees to hide their AI use rather than ask questions when they’re unsure.
The middle path treats early violations, especially from employees who are clearly trying to follow the spirit of the policy but got a boundary wrong, as training opportunities rather than disciplinary events. Reserve formal consequences for repeated or willful violations, particularly ones involving CUI or FCI moving into an unapproved tool. This distinction needs to be explicit in the policy document itself, not left to management discretion in the moment, because inconsistent enforcement across departments or locations — say, different standards applied in your Tampa office versus Boston — creates its own compliance and morale problems.
Detection capability matters here too. Without some visibility into which AI tools employees are actually reaching for — through DNS filtering, browser extension management, or endpoint data loss prevention — the enforcement structure has nothing to act on. This is a technical control question as much as a policy question, and it typically needs to be built into your broader cybersecurity architecture rather than bolted on separately.
Tying the Policy to Your SSP and CMMC Assessment
An AI usage policy that exists as a standalone document, disconnected from your System Security Plan, is a missed opportunity and a future audit headache. When a C3PAO or your own internal assessor reviews your controls under NIST SP 800-171, they’re going to ask how you control the flow of CUI across systems and services — and “we have an AI policy” is a much weaker answer than “here’s how our AI policy maps to our access control and media protection controls, and here’s the training record showing our staff were trained on it.”
Practically, this means the policy document should reference specific control families it supports, your SSP should reference the AI policy as an implementing document, and your POA&M should include AI governance as a tracked item if it isn’t fully mature yet. Data classified as CUI, per the guidance maintained in the CUI Registry, needs handling instructions that are consistent whether that data is sitting in a file server or being typed into a prompt window — the medium doesn’t change the classification.
This is also a good moment to loop in whatever framework you’re using to track overall security maturity. If your organization already benchmarks itself against a broader model — the kind referenced in Stealth Technology Group’s piece on measuring cybersecurity maturity without relying purely on compliance frameworks — AI governance should be one of the domains tracked, not a separate initiative running on its own timeline. The same logic applies to how leadership consumes this information: if your CEO-level cybersecurity reporting already tracks metrics beyond raw threat counts, AI policy adherence — training completion rates, detected shadow AI incidents, tool approval turnaround time — belongs in that same reporting cadence.
For contractors still working through the broader question of what CMMC compliance actually demands beyond the paperwork, the deeper discussion in CMMC compliance beyond the checklist covers how operational controls like this one need to reflect actual practice, not just documented intent — an assessor testing your AI policy will ask employees what they’d do in a specific scenario, not just whether they signed an acknowledgment form.
Rolling It Out Without Grinding Operations to a Halt
The rollout sequence matters as much as the policy content. Announcing a comprehensive AI policy company-wide on a single date, with immediate enforcement, tends to generate confusion and resentment in roughly equal measure. A phased approach — starting with the highest-risk tier, giving that group time to adjust and ask questions, then expanding to lower-risk tiers over subsequent weeks — gives IT and compliance staff bandwidth to actually field questions rather than getting buried.
It also helps to pilot the policy with a smaller group before full rollout, particularly a group that includes at least one skeptic. Someone who’s going to push back on an unclear rule during the pilot phase saves you from discovering that ambiguity during a live audit six months later. Contractors running distributed teams across Boston, Tampa, and Sarasota offices in particular should expect some variation in how quickly each location adapts, and building in a longer runway for full compliance across all sites tends to produce a policy people actually follow rather than one they resent.
Ongoing threat awareness matters here too — AI adoption is expanding the attack surface generally, not just through data leakage but through AI-enabled phishing and social engineering that CISA’s cybersecurity resources track in more detail than most internal security teams have bandwidth to monitor independently. A policy that only addresses outbound data risk while ignoring inbound AI-enabled threats is solving half the problem.
Conclusion
An AI usage policy isn’t a document you write once and file away next to your employee handbook. It’s a living operational control that needs to evolve as fast as the tools your employees are adopting on their own — which, at the moment, is faster than most compliance calendars are built to handle. Get the classification tiers right, vet your tools on a real schedule instead of a one-time basis, tie the whole structure back into your SSP, and you end up with a policy that protects CUI without making your engineers feel like they’re fighting their own IT department every time they want to work faster.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
