Federal AI compliance: NIST AI RMF from the engineer's seat

Lesson preparation and outcomes

Prerequisites: Task evaluation, threat analysis and change records.

By the end, you can: Map risk-management functions to observable engineering evidence and decision ownership.

Worked scenario and practice feedback

For a synthetic summarizer, GOVERN names owners and risk tolerance; MAP describes users/data/consequences; MEASURE records unsupported-claim and denial tests; MANAGE chooses containment and unresolved-risk actions. These functions inform iteration, not a one-time document ladder.

Guided and independent practice: Draft one artifact per function. Independently change the logging destination and update affected data flows, tests and decision owner.

Answer criteria: Evidence links are inspectable; absent evidence remains unresolved; voluntary framework alignment is not asserted as legal compliance or authorization. If the local pack or interpreter is unavailable, trace the synthetic input, expected output and failure guard on paper; label execution unverified. Required practice uses no paid API calls, accounts, purchase, operational data or actual deployment.

Risk management connects engineering choices to actual system evidence and responsible decisions. A bibliography or document count cannot establish compliance. This lesson applies the voluntary NIST AI Risk Management Framework to a synthetic system; the actual organization must identify binding requirements and authorization authority.

Part 1 The four functions, as code and docs.

NIST AI RMF is a voluntary risk-management framework with four functions — GOVERN, MAP, MEASURE, MANAGE. Binding obligations come from the applicable law, policy, contract and authorization boundary; the Leadership Track covers them at the policy altitude. As an engineer, here is what each one produces.

GOVERN

The accountability and process structure. The artifacts:

• A GOVERNANCE.md in your repo. Named owner. Decision authority. Escalation path. Cadence for review.
• Documented version policy for the AI components: how versions are decided, who approves them, what gets re-evaluated when versions change.
• An incident response runbook (built in Lesson 05) referenced from GOVERNANCE.md.

MAP

The context: what the system is and what it isn’t. The artifacts:

• A SYSTEM_CARD.md describing the system: intended use, out-of-scope use, users, data flows, dependencies, known limitations.
• Stakeholder map: who is affected, who decides, who is consulted.
• Data provenance documentation: where every training and reference dataset came from, license terms, consent posture.

MEASURE

The performance and risk numbers. The artifacts:

• An evals/ directory in your repo with versioned eval sets and a runner.
• A dated eval report (markdown, CSV, or dashboard) tied to model versions; choose the review cadence from system risk and actual organizational requirements.
• Drift detection from Lesson 05.
• Bias and fairness measurement for systems that touch people.
• Security testing results (Lesson 06).

MANAGE

What you do when something needs to change. The artifacts:

• The runbook from Lesson 05.
• A risk register: what you know about can go wrong, how likely, how bad, and what you’re doing about it.
• Risk reviews on a documented cadence and after relevant changes or incidents. Quarterly is one possible organizational choice, not a NIST universal minimum.

These artifacts are a starting inventory. Check applicable outcomes and actual evidence; a fixed file count does not establish alignment or authorization.

Part 2 The SYSTEM_CARD.md template.

A working system card has these sections. Each one is short, half a page to two pages.

# System Name

## Intended use
- What this system is for. One paragraph.
- Specific user populations.
- Specific operational contexts.

## Out-of-scope use
- What this system is explicitly not for.
- Known failure modes if used out of scope.

## Users and stakeholders
- Direct users.
- Indirectly affected populations.
- Decision-makers.

## Data flows
- Inputs: what data, from where, who controls it.
- Processing: where data goes (cloud, on-prem, third-party APIs).
- Outputs: what the system produces, who consumes it.
- Retention: how long data is stored, by whom.

## Dependencies
- Foundation models (name, version, provider).
- Frameworks (vLLM, TGI, etc., versioned).
- Critical third-party services.

## Known limitations
- Performance gaps.
- Bias measurements (where applicable).
- Out-of-distribution behavior.

## Risk classification
- Safety-impacting / Rights-impacting / Neither, with reasoning.
- Impact assessment summary.

Two notes:

• Write it before the system goes operational. Update it on every meaningful change.
• Make it the document a new stakeholder reads first. The act of writing forces clarity that briefings can’t.

Part 3 MEASURE: the bias and fairness work.

If your system makes decisions that touch people (eligibility, prioritization, recommendations consumed by decision-makers) you need bias measurement. The Leadership Track explained why; this lesson is how.

A working measurement pipeline:

1. Pick the protected attributes. Race, gender, age, disability status, where applicable. Use the attribute categories the relevant policy requires (OPM, EEOC, agency-specific).
2. Measure performance disaggregated by attribute. Accuracy, precision, recall, false positive rate, false negative rate, broken out by group.
3. Measure outcome disparities. When the system produces recommendations, what’s the rate of “positive” outputs per group? Compare to base rates.
4. Run the measurement on every release. Not just at launch.

Common metrics:

• Demographic parity. Do groups receive positive outcomes at similar rates?
• Equalized odds. Do groups have similar true positive and false positive rates?
• Calibration. When the system says it’s 80% confident, is it correct 80% of the time across groups?

These criteria can conflict under unequal group base rates and imperfect prediction; compatibility depends on the definitions and conditions. Choose metrics based on consequence and legitimate task requirements, document trade-offs, uncertainty and data limitations, and involve affected-user/domain reviewers. No single metric proves fairness.

Tooling: fairlearn (Microsoft), aif360 (IBM), or roll your own with pandas. Attribute collection itself requires a legitimate purpose, access/privacy rules and suitable labels. If data is missing, record the measurement gap rather than invent group identities.

Part 4 MEASURE: the cybersecurity and resilience work.

NIST AI RMF cross-references the NIST cybersecurity framework. For AI systems, you produce evidence of:

• Threat modeling for the AI-specific attack surface from Lesson 06.
• Penetration testing results against the deployed system.
• Resilience testing. Performance under load. Behavior under partial degradation (one of three GPU servers down).
• Supply chain attestation. SBOM, signed artifacts, dependency vulnerability scans.

Two patterns federal evaluators specifically ask about:

• Adversarial robustness. Have you tested the system against adversarial inputs? Where does it break?
• Provenance verification. Can you prove that the model weights running in production are the ones you authorized?

Applicability depends on the actual system, policy and contract. Define useful resilience and security tests from the threat model and consequence.

Part 5 The continuous compliance pattern.

The biggest failure mode in federal AI compliance is treating it as a one-time gate. The system gets to ATO, the documentation goes stale, the next assessment finds the documentation doesn’t match the system anymore.

The working pattern is continuous:

• Documentation lives in the repo. Updated with the code. Reviewed in PRs.
• Eval and bias measurements run in CI. Failures block deploy.
• Risk register reviewed on the chosen cadence and change triggers. Outputs are concrete changes to the system or operating posture; record the owner and reason for the cadence.
• Risk-based full review. Set cadence and independence from applicable requirements, system changes and consequence; findings drive owned follow-up actions.

Two leadership-level decisions an engineer should advocate for:

• Compliance work counted as engineering work, with calendar time allocated. Not “Friday afternoon work.”
• A named engineering point of contact who coordinates evidence with the accountable program, security, privacy and other required owners. Actual organizational policy determines decision authority; this example does not exclude those roles or assign approval to an engineer.

Part 6 What you produce by the end of all this.

An illustrative engineering evidence packet might include the following. The NIST AI RMF is voluntary and context-tailored; this list, file count, review interval and document length are course examples, not universal alignment or authorization requirements:

• The applicable governance, system-context, evaluation and risk records described in Point 01, with a requirement-to-evidence map.
• The eval framework and the results actually collected, with dates, versions and gaps. For a new system, include a baseline and future monitoring plan rather than inventing historical results.
• A bias measurement framework for human-impacting systems.
• Security test results and threat model documentation.
• A documented risk register with named owners.
• An incident response runbook and actual incident or exercise records; explicitly label simulations and absence of operational incident history.
• An SBOM and dependency attestation.

Choose the packet’s contents and level of detail from the actual system, risk decisions, organizational policy and applicable requirements. There is no universal page count or required six-month evidence history in this exercise. Build records as you work, preserve unresolved questions, and have the responsible organizational owner assess completeness before consequential use.

Interface/reference limits

Use the workflow reference to connect task, model, deployment, harness/tools, evidence and the responsible human decision. Synthetic demonstrations establish only the stated tested conditions.

Primary source checked October 2, 2026: NIST AI Risk Management Framework.