From 2-Month Pilot to Full Program Adoption: Rolling Out AskSage AI in a CUI Environment

Most defense contractors treat AI as a compliance liability to be blocked. We took the opposite approach: we treated it as a capability to be governed. Over a two-month pilot, we put a generative AI platform into the hands of 20 people working inside our CUI boundary, measured the results, and drove it to full program adoption. This is how we did it without putting controlled information at risk.

Why the Platform Choice Came First

The single most important decision in this rollout was made before any user touched a prompt: which platform. Consumer AI assistants are Tier 1 prohibited tools for CUI work. Pasting a controlled document into a public chatbot sends it to an uncontrolled system, and that is a reportable incident, not a productivity win.

We selected AskSage because it is purpose-built for defense workloads. AskSage's platform holds FedRAMP High and DoD Impact Level 5 and 6 authorizations and is designed to support Controlled Unclassified Information. That authorization posture is what made it defensible to use inside our boundary at all. A quick accuracy note for anyone copying this approach: the IL5/IL6 authorizations attach to AskSage's dedicated DoD/GovCloud environments. The commercial-facing environment runs on a FedRAMP High footprint. Confirm with AskSage which environment your tenant is provisioned in and validate that it matches your CUI categorization before you rely on it.

What We Scoped the Pilot To

We deliberately kept the pilot small enough to govern and large enough to prove value. Twenty users across three functions received access for two months. The use cases were mostly chat-based: software engineering, ISSM and ISSO documentation, and GRC documentation work. Access was browser-based for the majority of users, with a VS Code integration using the platform's Codex-style API for the software engineering team.

The functions we piloted were chosen because they generate a lot of structured writing and review work, which is exactly where a CUI-authorized LLM earns its keep. Engineers used it for code review and boilerplate. ISSMs and ISSOs used it to draft and refine control narratives and assessment documentation. The GRC team used it to accelerate policy and procedure drafting.

The One Guardrail That Mattered Most

We did not bolt on a dozen homegrown controls. The primary guardrail was the platform's CUI-model-only mode on the AskSage Enterprise plan, enabled by AskSage support. In that mode, prompts are constrained to the authorized model set rather than routing to general commercial models that fall outside the boundary. That single configuration did most of the heavy lifting, because it removed the most common failure path: a well-meaning user sending controlled text to a model that should never see it.

This is the core lesson. The right architectural choice replaces a stack of compensating controls. When the platform itself enforces the boundary, you spend far less effort policing user behavior after the fact.

From Pilot to Program: What Drove the Decision

Three things turned a two-month experiment into a permanent program. First, the documentation functions saw real cycle-time reduction on drafting and review, which leadership could see in output, not anecdotes. Second, the platform's authorization posture meant we were not accepting new, undocumented risk to get that benefit. Third, demand pulled it forward. Once the ISSM, ISSO, and GRC teams had a CUI-safe tool, the alternative was watching people quietly reach for tools that were not safe.

Adoption became the secure default. The fastest way to stop shadow AI is to give people a sanctioned tool that is good enough that they have no reason to look elsewhere.

How This Maps to Your CMMC Controls

A sanctioned AI rollout touches your assessment whether you plan for it or not. These NIST SP 800-171 controls are the ones to document up front.

• AC.L2-3.1.1 Authorized Access Control governs who can reach the AI platform inside the CUI environment.
• AC.L2-3.1.2 Transaction and Function Control limits what the tool is permitted to do with controlled data.
• AT.L2-3.2.1 Role-Based Training requires AI-specific awareness for everyone with CUI access.
• AU.L2-3.3.1 System Auditing means platform usage logs should be captured as assessment evidence.
• CM.L2-3.4.1 System Baselines: the approved AI platform becomes part of your documented baseline.
• SC.L2-3.13.1 Boundary Protection must account for the platform's data flows in and out of the enclave.
• SI.L2-3.14.1 Flaw Remediation: platform vulnerabilities get tracked like any other in-scope system.

Quick-Start Checklist

• Select a platform with authorization that matches your CUI categorization before anything else.
• Confirm with the vendor which environment your tenant runs in (FedRAMP High vs. IL5/IL6).
• Enable CUI-model-only or equivalent boundary-enforcing mode at the platform level.
• Scope a small, measurable pilot tied to high-volume documentation work.
• Capture usage logs from day one as assessment evidence.
• Update your SSP to document the AI platform boundary and data flows.
• Add AI-specific scenarios to your security awareness training.
• Brief leadership on residual risk and the accepted-risk decision before going to full adoption.

This account reflects one organization's approach and is shared for informational and planning purposes only. It is not legal advice, an assessment determination, or a recommendation of any specific vendor. Validate platform authorizations, your CUI categorization, and your control implementation with a qualified security professional before relying on them in an assessment or in representations to the U.S. Government.