Any ERPRole & RegulationUnited States

CMMC 2.0 + on-prem AI

CMMC Level 2 AI for ERP Without Blowing Up Your Scope

Short answer

AI added to an ERP that stores Controlled Unclassified Information either lives inside your CMMC assessment boundary or it becomes a new, unassessed path into CUI - there is no third option. The workable pattern is deploying the model, retrieval index, and ERP connector on infrastructure already inside your Level 2 enclave, or on a clearly segregated extension of it, so the System Security Plan needs an update rather than a rewrite. Built this way, AI can draft control narratives, summarize access logs, and answer questions against ERP data without adding a single new external dependency for your C3PAO to scope.

ERP: SAP S/4HANA, Infor SyteLine, Deltek Costpoint, Dynamics 365 Finance & Supply Chain
Industries: Aerospace, Defense, Electronics
Written for: CISO

Discuss your SAP S/4HANA environment See use cases

CMMC 2.0 Level 2 requires implementing all 110 controls from NIST SP 800-171 and, for most contractors, a third-party assessment against them. If your ERP is in scope because it processes CUI - contract data, technical specifications, unclassified but controlled program information - then anything you add to that ERP, including AI, inherits the same scope question: does it touch CUI, and if so, is it inside the boundary your SSP describes.

The instinct to reach for a familiar SaaS AI tool is understandable, but most of those tools were never designed with a CMMC boundary in mind. They call external APIs, log data to vendor-controlled infrastructure, and cannot produce the kind of control-by-control evidence a C3PAO assessor expects during a Level 2 assessment. Adding one to an in-scope ERP without redrawing the boundary is a fast way to create a finding, not a productivity win.

The alternative is not avoiding AI, it is putting it inside the enclave you already operate and already pay to secure. GPUs, model weights, and the retrieval index run on hardware inside the existing boundary, and access follows the same identification, authentication, and audit controls the rest of your CUI environment already implements. The SSP gets a new system description, not a new boundary.

This page walks through what that looks like in practice, the control families most affected, and the questions worth asking any AI vendor, including Netray, before anything touching CUI reaches a model.

What usually gets in the way

The problems we hear most from ciso teams running SAP S/4HANA.

AI can silently expand CUI scope

The moment an AI feature reads from or writes to an ERP table holding CUI, that AI system is in scope for CMMC Level 2 whether anyone updated the SSP or not. Assessors look for this gap specifically.

C3PAO assessors will ask about AI components directly

Third-party assessors increasingly ask what AI tools touch in-scope systems and how access, logging, and data flow controls apply to them. A vague answer is a finding waiting to happen.

Shadow AI is a scoping problem, not just a policy problem

Staff pasting ERP data into a personal AI account does not just violate policy, it potentially creates an unassessed CUI flow outside the boundary the SSP describes.

Enclave-grade GPU capacity is a real cost line

Running models inside an assessed boundary means procuring and securing hardware to the same standard as the rest of the CUI environment, which is a genuine budget conversation, not a footnote.

SSP and POA&M language has not caught up to AI

Most System Security Plans were written before AI tools were part of the conversation, so there is no template language ready to describe how an AI system satisfies access control, audit, and configuration management requirements.

Where AI earns its place in SAP S/4HANA

Each use case names the ERP objects it reads or writes, so your ERP team can judge the integration effort before anyone commits budget.

Control narrative drafting from existing configuration data

Draft first-pass SSP control narratives for control families where ERP and infrastructure configuration data already documents the implementation, for a compliance team member to review and finalize.

Touches: ERP role/permission tables, network and endpoint configuration exports, existing policy documents

Outcome: shortens the drafting time for routine control narratives ahead of an assessment cycle

Access review summarization

Condense ERP user, role, and CUI-object access logs into a review-ready summary for periodic access reviews required under the AC control family.

Touches: ERP user/role tables, permission change history, CUI-flagged document access logs

Outcome: turns a manual quarterly access review into a focused read instead of a raw export

POA&M item drafting support

Draft plain-language Plan of Action and Milestones entries from a control gap description, pulling relevant configuration facts from the environment to support the narrative.

Touches: Vulnerability scan exports, configuration baseline data, prior assessment findings

Outcome: reduces time compliance staff spend translating technical gaps into POA&M language

CUI marking and handling flag on ERP attachments

Flag ERP attachments and free-text fields that appear to contain unmarked or inconsistently marked CUI, before the document is shared outside its authorized recipients.

Touches: Document attachment tables, project/contract records, free-text notes fields

Outcome: reduces marking inconsistencies found during internal spot checks

Incident documentation drafting support

Draft an initial incident timeline and affected-system summary from ERP and system logs to speed up the documentation required for DoD cyber incident reporting.

Touches: System and application logs, ERP access records around the incident window

Outcome: shortens the time to a documented incident timeline during the reporting window

SSP-to-implementation gap check

Compare SSP control language against current ERP configuration and flag where the documented implementation no longer matches reality, ahead of an assessment.

Touches: ERP configuration exports, role definitions, SSP control text

Outcome: surfaces documentation drift before an assessor finds it

Enclave-scoped operational Q&A

Answer plain-language questions about ERP data (open orders, WIP status, contract deliverable dates) for staff inside the enclave, without any query or response leaving the boundary.

Touches: Order, WIP, and contract deliverable tables inside the in-scope ERP instance

Outcome: reduces time spent building ad hoc reports for routine operational questions

Reference architecture

The design principle is scope containment: the AI system either lives entirely inside the existing CMMC Level 2 boundary or on a segment explicitly extended into it, with every control family the SSP already tracks (AC, AU, IA, SC, SI, CM) applied to the AI components the same way they apply to everything else in scope.

1
ERP connectors (in-boundary)
Connections to the ERP run inside the same network segment as the ERP itself, authenticated with the same identity provider used for CUI-scoped access, satisfying the AC and IA control families without a separate identity system.
2
Data and semantic layer
A tagging layer marks which ERP fields and documents carry CUI, so retrieval and generation respect the same handling requirements the rest of the environment already enforces.
3
Model serving
Open-weight models served on GPUs physically or logically inside the assessment boundary, with configuration baselines tracked under the same CM process as other in-scope systems.
4
Retrieval and agents
Retrieval-augmented generation and narrow agents (control narrative drafting, access review summarization) operate only on data the requesting user's role already permits inside the boundary.
5
Governance and audit
Every query and response is logged to the same SIEM or log pipeline that satisfies the AU control family, with retention and alerting configured to match your existing continuous monitoring process.

Integration notes for your ERP team

AI components authenticate through the same identity provider as the rest of the in-scope environment; there is no separate login path that would need its own IA control documentation.
Model weights, the vector index, and logs are stored on media already covered by your media protection procedures, not a new storage location requiring a fresh control review.
Outbound internet access from the AI stack is disabled at the network layer, consistent with SC controls already applied to other in-scope systems.
Audit logs from the AI layer feed the same SIEM or log aggregation pipeline used for AU control compliance elsewhere in the boundary, so monitoring does not require a second toolchain.
Configuration baselines for the model, connectors, and retrieval index are version-controlled and tracked under the same CM process as other in-scope system components.
Any write-back from an AI agent to ERP data requires explicit human approval, keeping the control story simple: the AI drafts, a person with the right role approves.
SSP language is drafted alongside the architecture, not after deployment, so the system description an assessor reads matches what is actually running.

Deployment options

Air-gapped on-prem, inside the existing enclave

Contractors who already operate a physically or logically isolated CUI enclave

The AI stack runs on hardware inside the existing enclave boundary, so the SSP needs a system description update rather than a new boundary definition or a new assessment scope discussion.

Private cloud with dedicated, customer-controlled tenancy

Contractors using an already-assessed cloud environment (for example, a GCC High-equivalent tenancy) for part of their CUI footprint

The AI components run in the same dedicated tenancy, under the same access and monitoring controls, avoiding a second cloud environment that would need its own assessment narrative.

Hybrid with a clearly segregated AI segment

Contractors whose ERP is only partially in scope, with CUI isolated to specific modules or record types

The AI system is deployed only against the in-scope subset of ERP data, on its own segment, so non-CUI operational data can be served by a broader, less restrictively controlled instance.

Compliance and data control

How the architecture supports your obligations. Certification and accountability stay with your organisation; the design keeps the evidence straightforward.

CMMC 2.0 Level 2 (NIST SP 800-171 Rev 2, 110 controls)

AI components are scoped into the same SSP and inherit the same control implementations (AC, AU, IA, SC, SI, CM) as the rest of the in-scope ERP environment, rather than being treated as an unassessed add-on.

DFARS 252.204-7012

The AI system does not create a new location where Covered Defense Information is processed outside the boundary already covered by adequate security controls and incident reporting procedures.

NIST SP 800-171A (assessment objectives)

Architecture and logging are designed with the specific assessment objectives in mind, so the evidence an assessor asks for (configuration exports, access logs, control narratives) already exists in a usable format.

32 CFR Part 2002 (CUI marking and handling)

AI-assisted flagging helps surface inconsistently marked CUI in ERP attachments and free-text fields, supporting the marking discipline the CUI program requires rather than replacing it.

Where Netray fits

Custom build

Control narrative drafting, access review summarization, and POA&M support are specific enough to your SSP language and control implementation that a purpose-built agent inside the boundary outperforms a generic tool.

ERPray

For in-boundary operational question answering over ERP data, ERPray's read-only, permission-aware design maps cleanly onto a CMMC Level 2 environment where every access path needs a clear justification.

How an engagement runs

Phase 1 . 2-3 weeks

Discovery and scoping

-Review of current SSP boundary and CUI flow through the ERP
-Session with your compliance team (and RPO or C3PAO liaison if engaged) on how AI will be scoped
-Control family impact map (AC, AU, IA, SC, SI, CM) for the proposed AI architecture
-Draft SSP system description language for the AI component

Phase 2 . 6-8 weeks

Pilot

-One or two use cases live inside the existing enclave or its cloud equivalent
-Audit logging validated against AU control expectations
-Access control tested against real CUI-scoped roles
-Pilot evidence package suitable for internal assessment readiness review

Phase 3 . 8-12 weeks

Production

-Pilot use cases hardened and extended to the full authorized user base
-SSP updated and control narratives finalized
-POA&M items closed or updated based on pilot findings
-Monitoring and alerting tuned for the AI system's normal usage pattern

Phase 4 . ongoing

Scale

-Additional use cases added within the same assessed boundary
-Annual or triennial assessment support with AI-specific evidence ready to hand to the assessor
-Model and index refresh performed inside the boundary
-Support extending the pattern to additional in-scope facilities or business units

Questions to ask any vendor, including us

A short list that separates real SAP S/4HANA AI work from a chatbot demo.

Does the AI component run inside our existing CMMC assessment boundary, or does it require a new boundary and a new assessment?
Can you provide draft SSP control narrative language for how the AI system satisfies AC, AU, IA, SC, SI, and CM?
What identity provider does the AI layer authenticate against, and is it the same one already covering our in-scope users?
Where do audit logs from the AI system go, and do they integrate with our existing SIEM without a second toolchain?
If our C3PAO asks about AI during assessment, what evidence package can you provide us in advance?
How is CUI data isolated from non-CUI data if only part of our ERP is in scope?
What happens to model weights, logs, and cached data if we end the engagement?
Can this architecture support a Level 1 subset (FCI only) for a smaller facility without over-building controls?

Frequently asked questions

Does adding AI to an in-scope ERP automatically expand our CMMC assessment boundary?

It does if the AI component processes CUI outside your existing boundary. If the AI system is deployed inside the same enclave or dedicated tenancy that already covers your ERP, and inherits the same controls, it should not require a new boundary, only an update to the SSP's system description.

Can we use a commercial AI copilot if we restrict what data it can see?

Restricting data helps, but most commercial copilots were not designed to produce the control-by-control evidence a C3PAO assessor expects, and many still transmit queries to vendor infrastructure outside your boundary. For CUI-touching use cases, a design where the model runs inside your enclave is a more defensible starting point than restricting inputs to an external tool.

What control families are most affected by adding AI to an in-scope ERP?

Access Control (AC) and Identification and Authentication (IA) govern who can query the system; Audit and Accountability (AU) governs logging of queries and responses; System and Communications Protection (SC) governs network isolation; Configuration Management (CM) governs how the model and connectors are baselined and changed over time.

How much does enclave-grade GPU capacity typically cost for a mid-size defense contractor?

It varies widely with model size and concurrent user count, but a pilot-scale deployment for a handful of use cases on a mid-size model can often run on one to a few enterprise GPUs, while broader production use across many concurrent users needs a capacity plan matched to actual query volume rather than a single upfront guess.

Do we need a new POA&M item just because we are adding AI?

Not necessarily. If the AI system is designed to inherit existing controls rather than introduce new gaps, it may not generate a new POA&M item at all. If it does introduce a temporary gap (for example, before audit logging is fully tuned), documenting that as a time-bound POA&M item is standard practice.

Can a smaller supplier with only Level 1 requirements use the same approach?

Yes, with a lighter touch. Level 1 covers Federal Contract Information rather than CUI and does not require the full 110-control implementation, so the AI architecture can be simpler, but the same principle applies: keep the AI system inside whatever boundary already protects the in-scope data.

How do we show a C3PAO assessor evidence for the AI system specifically?

Prepare the same evidence types you already prepare for other in-scope systems: a system description, access control mapping, sample audit logs, and configuration baselines, framed in the assessor's control language rather than product marketing language. Assessors respond better to a clear, boring evidence package than to a claim that the AI system is inherently secure.

Related guides

ITAR + on-prem AI

ITAR-Compliant AI for ERP Technical Data

How to add generative AI to your ERP without creating a deemed export under ITAR. On-prem architecture patterns an Empowered Official can sign off on.

DFARS 7012 + NIST 800-171

Mapping DFARS 7012 and NIST 800-171 Controls to AI on Your ERP

Map DFARS 252.204-7012 and NIST SP 800-171 control families to an AI system layered on your ERP, with evidence a Compliance Manager can defend.

Costpoint + CMMC-scoped AI

On-prem AI for Costpoint inside a CMMC Level 2 enclave

Deploy AI beside Deltek Costpoint inside a CMMC Level 2 enclave: what to check before adding any AI tool, and how on-prem inference avoids new CUI flows.

GovCon accounting + DCAA + on-prem AI

AI for Government Contractor ERP Under DCAA Scrutiny

AI for government contractor ERP under DCAA scrutiny: draft indirect rate variance narratives, flag unallowable costs, and build audit trails, run on infrastructure you control.

Buyer guide: cloud AI vs private AI

FedRAMP / GCC High AI vs On-Prem AI for Your ERP: An Honest Comparison

An honest CISO comparison of FedRAMP High or GCC High AI copilots versus on-prem private LLMs for ERP data: what each authorization actually covers, and when each fits.

On-prem AI, any ERP, A&D

On-Prem AI for ERP in Aerospace, Defense, and Electronics Manufacturing

A hub guide to on-prem AI across SAP, Infor LN, Costpoint, IFS, and Oracle EBS for aerospace, defense, and electronics manufacturers under ITAR, CMMC, and AS9100.

Plan it with numbers

Free Tool

Talk it through with an engineer who knows SAP S/4HANA

Bring one real question your team cannot answer from the ERP today. We will map the data path, the model, and where it runs, and tell you honestly if AI is the wrong tool for it.

Start the conversation See ERPray

All AI for ERP guides