AI and CMMC: Controlled Information in AI Systems

CMMC turns on where controlled unclassified information flows, which makes one question decisive for AI systems: does CUI reach a model, and where does that model run. This guide covers the options and the evidence, drawing on FISTA Solutions' AI enablement work. This article is general guidance, not legal advice.

When does CMMC reach an AI system?

Whenever controlled information touches it, directly or through connection.

Situation	Consequence
Model reads CUI documents	In scope
Prompts contain CUI	In scope, plus provider questions
Outputs contain CUI	Outputs are CUI; audit accordingly
Connected to in-scope systems	Generally in scope
Strictly unclassified material only	Potentially out of scope
Self-hosted inside the enclave	In scope, boundary stays clean

Why are external providers usually blocking?

Because sending controlled information to a general commercial service means transmitting it outside the assessed environment to a provider that has not met the applicable requirements.

Teams frequently assume a contractual assurance resolves this. It does not, and discovering that during an assessment — after building a product around the provider — is among the more expensive failures available in this space.

What is the practical architecture?

Either a model deployed inside the assessed environment, or a design where controlled information never reaches the model.

The second is workable more often than teams expect: many useful applications operate on unclassified material, and keeping controlled content in a separate path with its own tooling preserves both the capability and the boundary. Decide which you are building before writing code. See what is an air-gapped AI deployment.

What does logging need to cover?

Who accessed controlled information and when, including through model outputs.

An output containing CUI is CUI. A summary of a controlled document is controlled, and access to it needs the same audit trail as access to the source. Systems that log model calls without recording who saw the response have an audit gap that becomes visible immediately in assessment.

What evidence do you need?

Scope documentation showing where controlled information flows, evidence that none reaches unapproved services, access and audit logs covering model outputs, configuration and change records, and a system security plan reflecting the AI components.

If that evidence exists as a by-product of how systems are built and operated, you are in good shape. If it exists only as documents written for a review, you are not, and the difference is visible to anyone who looks carefully.

How does this change engineering practice?

It pushes deployment topology and data classification to the front. Knowing which documents carry controlled markings, and preventing them from entering an unapproved path, is an engineering control rather than a training message.

Build the classification check into ingestion so that controlled content cannot reach a general-purpose path by accident. Relying on users to apply the rule produces exactly the incident the framework exists to prevent.

How does it interact with other regimes?

Usually more than expected. The same system can attract questions from a data protection authority, a sector supervisor, and a general AI regulator, each starting from a different premise and arriving at overlapping requirements.

One evidence base mapped to several requirements answers all of them. Separate programmes produce separate documents describing the same systems, and inconsistencies between them are themselves a finding.

What does compliance cost?

Mostly the cost of good engineering practice: evaluation, documentation, logging, and oversight design. Built into a project, the incremental cost is modest and much of it is work the system needed anyway.

Retrofitted onto a live system it becomes a project, performed under a deadline you did not choose, on something people already depend on. See AI compliance audit cost.

What are the common mistakes?

Assuming contractual assurances make an external provider acceptable. Treating model outputs as uncontrolled. Relying on user discipline rather than an ingestion control. And designing the product before confirming where the model can run.

Who owns this internally?

The function that owns the systems, with legal and compliance support. Ownership by compliance alone produces documents describing systems nobody changed; ownership by engineering alone produces good practice with no one accountable for the interpretation.

Name a person per system rather than a committee. Committees review; people decide.

What should you ask a supplier?

What documentation they provide about capabilities and limitations, what evaluation evidence they share, how they handle personal data, where processing happens, and what happens to your prompts and outputs.

Suppliers who have prepared answer those quickly. Suppliers who have not take weeks, and that delay is itself information about how the relationship will run.

How do you keep this current?

Assign someone to watch the sources that actually bind you rather than general commentary. Record what was checked and when, so the next review starts from a known point.

Rules in this area change, and a position taken eighteen months ago and never revisited is a risk in itself.

How does this affect product strategy?

It splits the market. A product that can operate entirely inside a customer's enclave is sellable to defence suppliers; one that depends on a commercial model service is not, regardless of its quality.

Deciding which market you are in before architecture saves a rebuild. Supporting both means supporting a self-hosted deployment path, which is an ongoing engineering commitment rather than a packaging exercise.

What should you do first?

Check whether any document ingestion path can accept controlled material and send it to an external service. If it can, that is the first control to build.

How FISTA Solutions helps

FISTA Solutions builds AI systems so the evidence exists when it is needed: deployment topology decided before architecture so controlled information never reaches an unapproved path, model outputs audited as controlled data, evaluation results dated and versioned, oversight designed structurally rather than asserted in policy, and documentation produced during the build rather than reconstructed afterwards. Delivery runs through AI enablement, AI agents, and forward deployed engineers. The record is 150+ projects for 50+ companies across 12+ countries.

To align a system with these requirements, message FISTA on WhatsApp, or read what is an air-gapped AI deployment.