Azure OpenAI, RAG architecture, and enterprise AI deployed inside your CMMC boundary — without destroying your compliance posture.
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.
Every component of the engagement is designed to produce a running system that your compliance program can actually account for — not just a deployment that works in isolation from your SSP.
Mapping each AI use case against CUI handling requirements and CMMC boundary implications. The boundary definition comes first — before architecture decisions are made.
Azure OpenAI, Azure AI Search, CosmosDB, and Entra ID authentication — designed specifically for the GCC High environment and its compliance constraints from the first diagram forward.
Full deployment and configuration directly in your GCC High Azure tenant. The deliverable is a running production system your team owns and can operate — not a handoff document.
Adding AI system components to your System Security Plan with proper boundary documentation, data flow descriptions, and mapping to the relevant NIST SP 800-171 Rev 3 controls.
Employee-facing policy governing AI tool use with CUI, defining permitted use cases, prohibited actions, and the handling requirements that apply to AI-generated outputs.
Data handling SOP, audit trail and logging requirements, risk register entries, and model governance framework for ongoing operation of the AI system post-deployment.
AI use case inventory, CUI boundary analysis, and GCC High tenant audit. We review your current Azure environment, documents CUI flows for each proposed AI use case, and determines what the compliant architecture needs to be before any build work begins. Deliverable: written readiness report with architecture recommendation and gap analysis.
Architecture finalization, GCC High deployment, configuration, integration, and testing. We deploy Azure OpenAI, Azure AI Search (RAG), CosmosDB, and Entra ID authentication directly in your tenant, with your team having full visibility and access throughout. Deliverable: running production AI system in your GCC High Azure tenant.
SSP amendment covering all AI system components and their boundary relationship, acceptable use policy, data handling SOP, and risk register update. Documentation is written to survive a CMMC assessment review, not just to check a box. Deliverable: complete compliance documentation package ready for C3PAO assessor 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.
Fulcrum Advisory has built this in production — not just designed it on paper. If your organization is evaluating AI adoption inside a CMMC-scoped environment, the conversation starts with the compliance architecture, not 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.