The problem

Why generic AI training fails in the DIB

I have sat through a lot of AI awareness training in the last two years. Most of it is a competent explainer: this is what generative AI is, here is how it predicts text, be careful because it can be confidently wrong.

None of that changes what an engineer does at nine at night when a drawing needs a description written.

Awareness training only works when the person can recognise the moment it applies to. And in a defense contractor, that moment is very specific: a document with a CUI marking, or a document derived from one, about to be pasted into a browser tab. If your training never names that scenario, your people will not connect the general warning to the particular act.

People do not fail training because they weren’t told AI is risky. They fail because nobody told them which document in front of them was the problem.

There is a second reason generic training underperforms here, and it is structural. In most organizations AI risk is framed as an IT concern. But the people who touch CUI most are not in IT. They are in contracts, engineering, quality, program management and business development. Training built for an IT audience reaches the wrong room.

Requirements

What the requirements actually ask for

Three requirements in the Awareness and Training family of NIST SP 800-171 carry this, and they ask for different things. Contractors routinely satisfy the first and skip the other two.

The gap I see most often is between 3.2.1 and 3.2.2. An organization runs one annual all-hands session, ticks the awareness box, and never delivers role-based training to the handful of people who actually make AI decisions. Those are different requirements, and an assessor evaluates them separately.

Design

Five audiences, five different sessions

One deck for everyone produces a session that is too technical for the executives and too shallow for the engineers. Split it. The content overlaps, but the decisions each group makes are not the same.

Executives and owners

Twenty minutes, no mechanics. They need to understand that an unauthorized disclosure of CUI can carry contractual and reporting consequences, that an inaccurate SPRS representation carries its own exposure, and that a prohibition without a funded approved alternative will simply move usage onto personal phones. The decision they own is whether to pay for a governed instance.

Contracts and program management

This group determines what CUI you hold and which clauses apply. They need to know that AI processing is now a supplier question, that flow-down language written before 2023 probably does not address it, and that “the vendor drafted it with their own AI tools” is a scenario they should be asking about during source selection.

Engineering and technical staff

The most important session and usually the one that is skipped, because engineers are hard to schedule. They handle controlled technical information daily. They need concrete examples using their own document types — a drawing, a test report, a specification — and an honest answer to “then how am I supposed to do this faster?” If the answer is only “you aren’t,” the training has failed.

IT and security

Role-based training under 3.2.2. They need to know how the block is enforced, what an approved instance looks like technically, how AI disclosure is triaged as an incident, and what evidence they are expected to retain. This is duty training, not awareness.

Everyone else

Short, scenario-first, no jargon. One recognisable situation, one rule, one reporting route. Finance, HR and administrative staff handle FCI and sometimes personal data, and they use AI drafting tools as much as anyone.

Content

What belongs in every session, regardless of role

Whatever else you cover, these five things need to survive in every version of the training.

1. The named listWhich specific tools are approved, and which are prohibited. Not categories — names. “Approved AI tools” as a phrase teaches nobody anything.
2. The data rule, stated plainlyWhat may never enter an external model: CUI, FCI, export-controlled data, personal information, client confidential material. Say the categories your people actually recognise from their own documents.
3. One worked example from their worldTake a real document type that group handles and walk it through. Abstraction is what makes training forgettable.
4. The route to askWho approves a new tool and how long it takes. If asking is slower than just using it, people will just use it.
5. The reporting route, with the fear removedWho to tell, what happens next, and an explicit statement that reporting will not get them disciplined.

The gap

The part nobody trains: how to report it

Most AI training ends at prevention. It tells people what not to do and stops.

That leaves the highest-value behaviour untrained. Somebody, at some point, is going to paste something they shouldn’t. What happens in the next hour determines whether you have a contained incident with preserved evidence or a disclosure you find out about eleven months later, secondhand.

Requirement 3.2.3 is the hook for this and it is usually taught as a chapter about disgruntled employees and badge misuse. Bring it up to date. An employee who realises they pasted a controlled document and says nothing is exactly the indicator that requirement is about — not because they are malicious, but because silence is what turns a small exposure into an undocumented one.

Pair it with the mechanics: preserve the conversation, do not delete it, note the platform and the account tier, and tell a named role. The GenAI insider risk brief works through what happens after that point.

Assessment

What an assessor asks for

Training is one of the easier areas to evidence and one of the most commonly under-documented. A completion report from an LMS proves attendance. It does not prove the training covered what it needed to cover.

That last row is the one I would rehearse. An assessor may ask an engineer what they would do if they needed help rewriting a technical description. If the honest answer is a shrug, the training did not land, whatever the completion report says.

Failure modes

Where training programs quietly fail

• Annual only, with no update when a new tool appears or an existing platform switches on an AI feature
• Delivered to IT and management, never to engineering, because engineering is hard to schedule
• Written in terms of “generative AI” rather than the tool names people actually have open
• Prohibits everything and approves nothing, so the training teaches people to hide usage
• No reporting route, or a route that runs through someone’s manager rather than a named role
• New starters onboarded months after the annual session with no interim coverage
• No refresh when the SSP or the approved tool list changes, leaving training and documentation out of step

The last two are what turn a good program into a stale one. Tie training review to change management, the same way the SSP should be, and most of this stays current on its own.

FAQ

Common questions

Is annual AI awareness training enough?

For 3.2.1 it may satisfy the letter of the requirement, but the tooling changes faster than an annual cycle. AI features arrive inside platforms you already own, sometimes enabled by default. I would treat the approved tool list as a living document and push a short update whenever it changes.

Can we just add an AI slide to our existing security awareness deck?

You can start there, but it rarely reaches the people who need it most. A slide in a general deck delivers awareness; it does not deliver the role-based training 3.2.2 asks for, and it almost never includes a worked example from an engineer’s own document set.

What if leadership wants to ban AI entirely?

Then the training has to be honest about what happens next. Unenforced bans move usage onto personal devices where you have no visibility, so a ban needs technical enforcement and an approved alternative for the work people were trying to do. Otherwise you have traded a governed risk for an invisible one.

Does this training need to cover subcontractors?

Your flow-down obligations reach them, and if they handle your CUI their practices become part of your story. You are not usually delivering their training, but supplier questionnaires should ask what they train on and how they handle AI processing.

How do we prove people understood, not just attended?

A short scenario exercise works better than a quiz. Give them a realistic document and ask what they would do with it. It produces evidence of comprehension and it surfaces the gaps in your own policy at the same time.

Who should own AI awareness training?

Security usually builds it, but it fails when security also has to chase attendance. Give delivery to whoever owns onboarding and annual compliance training already, and give content ownership to whoever maintains the approved tool list.

This brief reflects program status as of 30 August 2026 and cites NIST SP 800-171 Revision 2, the version currently incorporated into CMMC. Verify current requirements against your contract clauses before designing a training program around them.