AI strategy, use case scoping, tool evaluation, and compliant deployment for defense contractors operating inside a CMMC boundary.
Leadership is demanding AI adoption. Your compliance officer is demanding you don't blow up the CMMC boundary. These two imperatives are not mutually exclusive — but reconciling them requires more than picking a vendor with a FedRAMP authorization and calling it done.
"FedRAMP authorized" means a system has received a federal authorization to operate in a general sense. It does not mean that system is inside your authorization boundary. It is not an SSP entry. It does not define where your CUI flows. It will not survive a CMMC assessment. An assessor asking "show me how your AI system is documented in your SSP" is not a hypothetical — it is a question that will be asked, and contractors who deployed AI without answering it first are going to have a difficult day.
The three decisions that determine compliance before any code is written: Does the AI system touch, process, or store CUI? Is your Azure tenant GCC High, not commercial? Have you amended your SSP to include the AI components? Contractors who skip these questions — and there are many — don't discover the problem until the evidence review is already underway.
Fulcrum Advisory has designed and deployed a production enterprise AI assistant inside a CMMC-scoped GCC High environment. That is not a reference architecture or a proof of concept. It runs in production, with real users, against real CUI-adjacent data, inside a live DCSA compliance program. The architecture advice comes from having actually built it — not from reading vendor documentation.
Engagements start with scoping and strategy. Deployment is one possible outcome — not the assumed one. Every client situation is different, and the deliverables reflect what that situation actually requires.
A structured plan for AI adoption that accounts for your compliance posture, use case priorities, and organizational readiness. Covers which use cases to pursue, in what sequence, and what the compliance path looks like for each — before any tool selection or deployment decisions are made.
The required starting point. Mapping each proposed use case against CUI handling requirements and CMMC boundary implications before architecture, tooling, or deployment decisions are made. Scope determines everything that follows — this step is not skippable.
Commercial AI tools are proliferating faster than compliance frameworks can address. Before adopting any cloud AI solution — Microsoft Copilot, third-party LLM APIs, SaaS AI products — a structured evaluation against your CUI handling requirements, data residency constraints, and CMMC boundary is necessary. Not every tool that claims government cloud support fits within your authorization boundary.
For use cases where GCC High deployment is the appropriate path, architecture design covers the relevant Azure services — Azure OpenAI, Azure AI Search, CosmosDB, Entra ID — configured for the GCC High compliance environment. Architecture follows scoping and tool evaluation, not the other way around.
Adding AI system components to your System Security Plan with proper boundary documentation, data flow descriptions, and mapping to relevant NIST SP 800-171 Rev 3 controls. Required regardless of whether AI runs in GCC High or any other compliant environment.
Acceptable use policy governing AI tool use with CUI, data handling SOP, audit trail and logging requirements, and risk register entries. Written to survive a CMMC assessment review, not just to satisfy an internal checklist.
AI use case inventory, CUI boundary analysis, and evaluation of candidate tools and platforms against your compliance constraints. This includes any commercial AI tools already in use or under consideration — not just Azure services. The output determines whether GCC High deployment, a commercial platform with appropriate controls, or a different approach is the right path. Deliverable: written strategy and readiness report with tool recommendations and compliance path analysis.
For engagements that proceed to deployment: architecture finalization, configuration, integration, and testing in your environment. Your team has full visibility and access throughout — no opaque handoff. Deliverable: running system in your environment, with your team in a position to operate and maintain it independently.
SSP amendment covering AI system components and their boundary relationship, acceptable use policy, data handling SOP, and risk register update. Required for any AI system that touches or is adjacent to CUI — regardless of deployment path. Deliverable: complete compliance documentation package written to hold up under C3PAO review.
Does Azure OpenAI in GCC High have the same capabilities as commercial Azure OpenAI?
No, and this matters for your architecture. GCC High Azure OpenAI has a subset of the models available in commercial Azure. Some features — certain GPT-4 variants, fine-tuning, some preview capabilities — may be unavailable or on a delayed release schedule compared to commercial. The architecture we design accounts for what is actually available in GCC High at deployment time, not what the vendor marketing materials describe. This is one of the reasons the readiness assessment comes before architecture finalization.
We already use Microsoft 365 GCC High. Does that mean our AI deployments are compliant?
Not automatically. M365 GCC High and Azure GCC High are separate authorization boundaries. If you are using Copilot for M365, that has its own compliance posture and its own SSP considerations. If you are building a custom AI application in Azure, it needs to be in an Azure GCC High tenant with proper boundary configuration, private endpoint networking, and SSP documentation. The two can coexist, but they are not the same thing and cannot substitute for each other.
What does adding AI to our SSP actually look like?
Your SSP needs to document the AI system components (the Azure services, their configuration, and data flows), how they handle CUI, the boundary between AI components and other systems, and how the relevant NIST SP 800-171 Rev 3 controls apply to the AI environment — particularly the AC, AU, CM, and SC families. The logging and audit trail requirements under AU are often the most significant gap in AI deployments that were not designed with compliance in mind. We write these SSP amendments as part of the deployment engagement or as a standalone policy package.
Can you deploy in our tenant or do we need to manage the deployment ourselves?
We deploy directly in your GCC High Azure tenant, with your team having full ownership and access throughout the engagement. There is no opaque black box. Your team sees every configuration decision and understands the architecture before the engagement ends. The deliverable is a running production system your team can operate and maintain independently — not a handoff document or architecture diagram they have to implement themselves afterward.
Most AI conversations in GovCon start with the tool and work backwards to compliance. The ones that go well start with use cases, CUI handling, and what your boundary can actually support. If your organization is evaluating AI adoption, the conversation starts there — not with the feature list.
Schedule a CallThree decisions determine compliance before a single line of code is written. Most contractors get at least one of them wrong.
The actual technical differences between GCC High and commercial Azure that matter for compliance, and the architecture pattern for a compliant RAG deployment.
32 CFR Part 170 took effect December 16, 2024. What actually changed from CMMC 2.0 and what your first 90 days should look like.