Which AI Skills Actually Transfer to Federal Work

Every few weeks an engineer who builds AI systems for a commercial company asks me some version of the same question: how much of what I already know counts in federal work, and how much do I have to learn from scratch? The answer is more encouraging than most people expect. The encouraging part and the hard part are just not where they think.

Your engineering transfers almost intact. Your habits around evidence transfer, if you have them. What does not transfer is everything about how a government system earns permission to exist, and that is a real body of knowledge with its own vocabulary, its own document formats, and its own clock. No bootcamp teaches it. It is learnable in months rather than years, and it decides whether you are useful on a federal program in your first quarter or your fourth.

This article sorts the skills into three buckets: transfers directly, needs relearning, matters less than you expect. Then it gives the cheapest way I know to close each gap.

Who this is for

Three kinds of people ask this question. An engineer at a commercial company considering a job at a systems integrator or an agency. A founder wondering whether to bid an SBIR or subcontract to a prime. A data scientist whose employer just won federal work and now needs someone who can operate inside it. The sort below is the same for all three; only the urgency differs.

The three-bucket answer

The transfer ledger

Skill	Transfers?	What changes
Data engineering	Directly	Older sources, worse documentation, higher demand
Evaluation and measurement	Directly	Measured on the customer's data, not a public benchmark
Containers, CI/CD, IaC	Directly	Hardened base images, approved registries
Security engineering	Directly	Every control has to be written down and proven
Accreditation (RMF, ATO, FedRAMP)	Relearn	Entirely new; no commercial analogue
Air-gapped operation	Relearn	No internet at build time or run time
Documentation	Relearn	A contract deliverable with a mandated format
Supply chain and provenance	Relearn	SBOMs, attestations, model and data lineage
Framework and model choice	Overrated	Rarely appears in an evaluation
Benchmark scores	Overrated	Replaced by error rates on government data

What transfers directly

Data engineering, and it is worth more here. A common assumption is that federal data is cleaner because it is official. The opposite is true. Systems of record are old. You will meet fixed-width mainframe extracts, Oracle schemas with twenty-five years of drift, spreadsheets that are the authoritative source for a program office, and PDFs that are scans of faxes. The skills that matter are exactly the ones you already have: building ingestion that fails loudly, reconciling records that share no key, detecting schema drift before it silently corrupts a downstream model, and keeping a lineage trail from an output back to the row it came from. That last one is worth extra in federal work, because you will be asked to defend a single number in front of people who are accountable for it.

Evaluation discipline. If you already build held-out sets, report precision and recall separately instead of a single accuracy figure, put an interval around an estimate, and refuse to declare success from a demo, you are ahead of a surprising share of the field. The NIST AI Risk Management Framework (AI 100-1, January 2023) organizes work into four functions, GOVERN, MAP, MEASURE, and MANAGE, and MEASURE is where a working engineer already lives. The Generative AI Profile (NIST AI 600-1, July 2024) extends it with risks specific to generative systems. What federal buyers increasingly want is a measured error rate on their documents, with the test set described, not a vendor claim. Our pieces on how teams actually test agents and measuring hallucination rates go deeper on the mechanics.

Deployment and operations. Kubernetes is Kubernetes. Terraform is Terraform. Container builds, blue-green rollouts, structured logging, dashboards, on-call rotations: all of it carries over. The change is where images come from. Defense programs commonly pull hardened base images from Iron Bank, the Department of Defense container repository run under Platform One, rather than from a public registry. Your pipeline shape stays; your source of truth for base layers moves.

Security engineering. Least privilege, secrets management, mutual TLS, key rotation, immutable audit logs. All of it transfers, and federal work makes it explicit rather than implicit. Cryptographic modules must be validated under FIPS 140-3 through the NIST Cryptographic Module Validation Program. Logging is specified, not assumed: OMB Memorandum M-21-31 sets a four-tier maturity model and names minimum log content, including accurate timestamps in an ISO 8601 and RFC 3339 format with milliseconds and a time zone designator, plus retention periods by log category. If you have ever argued for better audit logging and lost, federal work is the place where the argument is already won.

Plain writing. Underrated everywhere, decisive here. Much of federal technical work is explaining a system in prose to a reader who is smart, accountable, and not an engineer.

What you have to relearn

Accreditation

This is the big one, and it has no commercial equivalent. In a commercial company, "ready to ship" is a technical judgment made by the team. In federal work, a system runs in production because a government official called an authorizing official signed an Authorization to Operate. Nothing about your code quality substitutes for that signature.

The framework is NIST SP 800-37 Rev. 2, the Risk Management Framework, and it runs in seven steps: Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor. Categorization uses FIPS 199 to rate the system Low, Moderate, or High across confidentiality, integrity, and availability. That rating selects a control baseline from NIST SP 800-53 Rev. 5. You implement the controls, an assessor tests them, findings go into a Plan of Action and Milestones, and the authorizing official accepts the residual risk or does not.

If you are selling a cloud service to multiple agencies rather than building inside one, the parallel track is FedRAMP, which was made statutory by the FedRAMP Authorization Act in the FY2023 National Defense Authorization Act. OMB Memorandum M-24-15, issued in July 2024, restructured the program, replacing the Joint Authorization Board with a FedRAMP Board and pushing toward automation and reuse of existing authorizations.

The mental shift that takes longest: controls are not a checklist applied at the end. Picking a component that cannot emit the required audit record, or a managed service that has no authorized government region, is a decision you will pay for at assessment time, often a year later, when changing it is expensive. Read what an ATO actually is first, then what ATO engineering takes.

Air-gapped and disconnected operation

A large share of interesting federal AI work happens where there is no internet. The Department of Defense Cloud Computing Security Requirements Guide sorts environments by impact level: IL2 for public and non-critical mission information, IL4 for Controlled Unclassified Information, IL5 for higher-sensitivity CUI and national security systems, IL6 for information classified up to SECRET. Classified fabrics such as SIPRNet and JWICS are separate networks, not restricted zones of the internet.

The practical consequences are concrete and they break normal habits. Installing a package at build time is not available; dependencies get vendored and mirrored inside the boundary. Container images arrive through an approved transfer process. A library that phones home to validate a license will hang forever. Model weights are files someone carries in and hash-verifies, not a download. You cannot call a hosted model API, so the architecture has to work with open-weight models on hardware a person physically racked, with a fixed memory budget. Anything crossing between networks goes through a cross-domain solution, and those products come from a government-maintained baseline list rather than a vendor catalog. Media that leaves the environment is sanitized under NIST SP 800-88. Our air-gapped deployment explainer and impact levels guide cover this in detail.

Documentation as a deliverable

In commercial work, documentation is a courtesy you write when there is time. On a federal contract it is a line item with a due date. Deliverables are listed on a Contract Data Requirements List (DD Form 1423), and each one points to a Data Item Description that specifies format and content. Miss the format and the deliverable can be rejected even when the underlying work is fine.

The accreditation documents are their own genre: System Security Plan, Security Assessment Plan, Security Assessment Report, Plan of Action and Milestones. A System Security Plan is not a summary; it is a control-by-control narrative saying how each requirement is met in your specific system, written so an assessor can test the claim. And if any part of the system is user-facing, Section 508 applies. The Revised 508 Standards at 36 CFR Part 1194 incorporate WCAG 2.0 Level AA, which means keyboard navigation, contrast ratios, and screen-reader compatibility are contract requirements, not polish.

Provenance and supply chain

Executive Order 14028 in May 2021 set the direction, and the follow-on OMB memoranda M-22-18 and M-23-16 turned it into a requirement: software producers selling to the government attest that they follow secure development practices drawn from NIST SP 800-218, the Secure Software Development Framework, using the attestation form CISA published as a common form. Software Bills of Materials, following the NTIA minimum elements, are now routine. FAR 52.204-25 separately prohibits certain covered telecommunications equipment and services in the supply chain.

AI adds its own provenance questions on top. Where did these model weights come from, and under what license? What is known about the training data? Can you reproduce the artifact you shipped? Model cards and data lineage stop being good practice and start being evidence. For systems that generate content, NIST's work on synthetic content (AI 100-4) and the C2PA content-credential specification are the reference points. See model provenance and citation.

Two adjacent things worth knowing early

First, data rights. The DFARS clauses at 252.227-7013 and 252.227-7014 govern rights in noncommercial technical data and computer software, and SBIR awards carry their own category under 252.227-7018. The license category you deliver under determines whether the government can hand your code to a competitor. Engineers give away rights by accident all the time, usually by delivering source that was never scoped as a deliverable. Read data rights in plain language before you write a statement of work.

Second, export control. ITAR (22 CFR Parts 120 through 130) restricts access to export-controlled technical data to U.S. persons, a definition that at 22 CFR 120.62 includes lawful permanent residents, not only citizens. That distinction matters to a lot of engineers who assume they are excluded when they are not. Handling CUI has its own rules; start with CUI basics for software teams and, if you are on the defense side, CMMC for small contractors.

What matters less than you expect

• Which framework you use. LangChain, LlamaIndex, or a raw SDK: I have never seen framework choice appear in an evaluation. What appears is whether the system works, whether the numbers are defensible, and whether it can be authorized.
• Which model is on top this month. Model rankings churn faster than a procurement cycle. Build so the model is swappable and the evidence outlives it.
• Public benchmark scores. A high score on a public suite says little about extracting fields from an agency's scanned forms. Expect to be asked for measured performance on the customer's own data, with the test set described.
• Hyperscale MLOps. Most federal AI systems are small by commercial standards. Millions of documents, not billions of events per day. Experience running a petabyte-scale feature store is nice and rarely the binding constraint.
• Research novelty. A boring approach you can measure and defend beats a novel one you cannot. Novelty that cannot be assessed is a liability in an accreditation package.
• A clearance, at the start. You cannot sponsor your own clearance; an employer or agency sponsors it against a specific position. Plenty of federal AI work sits at IL2 or IL4, or at civilian agencies, with no clearance requirement at all. Get in on unclassified work; sponsorship follows a job, not the reverse.

Closing each gap

Every gap above closes with reading and one small build. None of it requires a contract to practice.

1. Read three documents end to end. NIST SP 800-37 Rev. 2 for the framework, the FedRAMP Moderate baseline so the control language stops being foreign, and one real solicitation. All free. A weekend each.
2. Build one thing offline. Take a project you already have. Disconnect the network. Make it build and run with vendored dependencies, a local open-weight model, and no outbound calls. You will find three assumptions you did not know you had.
3. Write five control narratives. For a system you already own, write the implementation narrative for AC-2 (account management), AU-2 (event logging), IA-2 (identification and authentication), SC-13 (cryptographic protection), and CM-6 (configuration settings). Write them so a stranger could test the claim. This single exercise teaches more about federal engineering than any course.
4. Generate an SBOM and actually read it. CycloneDX or SPDX, on a real project. Then find one component you cannot explain the provenance of. There is always one.
5. Measure something honestly. Pick a task, build a held-out set, report precision and recall with an interval, and write a paragraph about what the system gets wrong. That paragraph is the thing federal evaluators trust.
6. Learn the buying vocabulary. Start with how to read a solicitation, what a contracting officer actually does, and the simplified acquisition threshold, which sits at $250,000 and changes how a purchase is competed.

A realistic first year

Months one through three are vocabulary. You will feel slow, and a meeting can pass without you knowing what was decided. This ends, on its own schedule.

Months three through nine, you work a real program and watch an accreditation happen around you. This is where the abstractions land. You see a finding written against a design decision, and you understand for the first time why the control language is shaped the way it is.

Months nine through eighteen, you start predicting. You can look at a proposed architecture and say which parts will survive assessment and which will generate findings, before anyone writes code. That is the point at which a commercial AI engineer becomes a federal AI engineer, and the technical skill that got you here is still doing most of the work.

One caution worth carrying in. The most common failure in federal AI is not a bad model; it is a good pilot that never crosses into production because nobody planned the authorization path, the data agreement, or the operations budget. If you bring one instinct from this article into your first program, bring that one. We wrote about the pattern in why AI pilots never reach production.

Where to start this month

Pick the smallest true step. Read SP 800-37 Rev. 2 this week. Write the five control narratives next week. Take one project offline the week after. Then read a live solicitation on SAM.gov end to end, including the evaluation criteria, and ask yourself honestly what you would need to write a responsive answer.

The gap is real, and it is smaller than the folklore suggests. Federal programs are short of people who can build a working system and explain it in writing. You already have the first half. The second half is a reading list and a few deliberate reps.