The pilot did not fail. It succeeded somewhere production does not exist.
The shape is familiar enough to be boring. A team gets budget for a pilot, exports a sample of the data to a workspace they already have, fits a model, and gets a number good enough for a slide. The demo goes well. Then the customer's security officer joins a call and asks where the data sat, what left the network, who holds the weights, who wrote the acceptance criteria, and who operates this in eighteen months. Every answer is a version of "we would have to change that." The model was never the risky part. The pilot was scoped as an experiment, the thing that has to ship is a system, and almost none of the decisions separating the two were made before work started.
This is not a machine-learning problem, which is worth saying plainly. Sculley and colleagues made the point in "Hidden Technical Debt in Machine Learning Systems" (NeurIPS, 2015): in a deployed system the box labeled ML code is a small fraction of the whole, and the boxes around it — data collection and verification, feature extraction, configuration, resource management, serving, monitoring — are the bulk of the engineering surface. A pilot that builds only the small box has built the part that ports easily and skipped every part that does not.
If a federal or defense customer is downstream the effect is sharper, because the constraints they bring are not preferences to be negotiated later — they are conditions of operating at all. Four do most of the damage when deferred: where the data may live, who owns what the pilot produces, what "good" means in writing, and who runs the thing on the Monday after the demo. Each is cheap before the build and expensive after code exists that assumed the other answer.
Constraint one: where the data may live
This is the one that causes rebuilds, and it is almost always decided by accident. The pilot runs wherever the data was easiest to reach — a commercial cloud account, a laptop, a vendor's hosted workspace — and production has to run somewhere else. Then nothing measured in the pilot transfers cleanly: not the model selection, because a restricted boundary offers a different set of models; not the latency, because the hardware differs; not the cost; and not even the accuracy figures, because the data inside the boundary is rarely identical to the export you were handed.
Get the vocabulary early; the customer will use it and mean something specific. If the data is Controlled Unclassified Information, the government-wide program sits at 32 CFR Part 2002, and on defense contracts the safeguarding obligation arrives through DFARS 252.204-7012, which points at NIST SP 800-171 and carries 72-hour incident reporting. One wrinkle: NIST published SP 800-171 Revision 3 in May 2024, but DFARS 252.204-7012 and CMMC Level 2 assessments still key to Revision 2 under a DoD class deviation, so "which revision" is a real question. IL4, IL5, and IL6 are impact levels from DISA's DoD Cloud Computing Security Requirements Guide; they govern where infrastructure physically sits, who may administer it, and what it may connect to — we lay them out in IL4, IL5, and IL6 for AI workloads.
The practical rule is short. Run the pilot under production handling rules on a representative sample, or, if that is impossible, write down which results will not survive the move and budget to re-measure them. The second option is respectable; discovering the gap in the security review is not. Ask the runtime question on day one too, because it eliminates candidates fast: can this component run with no outbound call at inference time — no license check, no telemetry, no model download at start-up? Many cannot, and the pattern that survives is described in headless model deployment into a customer sandbox and air-gapped inference.
Getting the data is usually the longest pole in the schedule, and almost never on it. Agreements, sanitization, and internal approvals consume calendar time unrelated to engineering. If a government customer furnishes the data, the attached terms matter as much as the contents — see government furnished data. Where the real data cannot move, synthetic data is a legitimate bridge with limits worth stating rather than discovering.
Constraint two: who owns what comes out
A pilot manufactures assets nobody assigned an owner to: labeled data that did not exist before, an evaluation set that took real effort, fine-tuned weights or adapters, prompts and configurations refined over weeks, code, and its documentation. Six months later these are the most valuable things anyone produced, and who holds them is being argued between two parties who each already relied on the answer being theirs.
On a federal contract this is clause text, not goodwill. For defense noncommercial software, DFARS 252.227-7014 sets the standard license categories — unlimited rights, government purpose rights, and restricted rights — with government purpose rights carrying a nominal five-year period that is negotiable and converts to unlimited rights on expiry. FAR 52.227-14 covers rights in data on the civilian side. SBIR and STTR work falls under a more protective regime: SBA's Policy Directive effective May 2, 2019 set a uniform 20-year protection period beginning at award, implemented for DoD by a DFARS final rule effective January 17, 2025. More in SBIR data rights and march-in rights.
A newer layer aims squarely at AI. OMB Memorandum M-25-22, "Driving Efficient Acquisition of Artificial Intelligence in Government" (April 3, 2025), directs civilian agencies to address ownership of government data used to train, fine-tune, or develop an AI system, to restrict vendors from using non-public agency inputs and outputs to further train publicly or commercially available models without consent, and to favor terms that prevent vendor lock-in. National security systems are carved out, so a defense customer's requirements arrive differently — but the question is one every commercial buyer should ask: if your data improves someone's model, whose improvement is that?
Constraint three: what "good" means, written down before anything is built
The most common success criterion for an AI pilot is that the stakeholders were impressed. That is a mood, not a criterion, and it does not survive a change of stakeholder. Write the acceptance test first, specific enough that two people reading it would score the same system the same way.
That means both error types counted separately rather than blended into one accuracy figure, because missing something and raising something that was never there rarely cost the same. It means the volume and base rate the system will actually see, since the size of a review queue is set by the false-alarm rate, not the headline — see the false-extraction rate. It means a stated behavior when the model is unsure, latency and throughput at production volume, and a human review budget in minutes per day, because that number decides whether anyone still uses the system in month three.
Hold back a slice of the evaluation data the builders never see, and keep the right to re-run the test after any model, prompt, or dependency change; a number produced on an instrument the builder also wrote measures the instrument as much as the system, the argument in testing on someone else's instrument. With a federal customer downstream this stops being optional. OMB M-25-21, issued the same day as M-25-22, sets minimum risk management practices for high-impact AI — pre-deployment testing, an AI impact assessment, ongoing monitoring, human oversight — and gave use cases already in operation until April 3, 2026 to meet them, waive them, or come out of service.
Three questions that predict whether a pilot survives contact with production
Ask at scoping, not at the demo. One: if this succeeds, must any part of the architecture change for it to run where it must run? Two: is there a written statement, agreed by both sides, of the number that means "it worked" and the data it is measured on? Three: can you name the person operating this a year from now? Three yes answers is a pilot. Three no answers is a demonstration — fine to build, if everyone knows that is what it is.
Constraint four: who runs it on the Monday after the demo
Pilots are staffed by the people who built them, which conceals how much operating a model takes. In production it has to be versioned, promoted, monitored, retrained on a trigger somebody defined, and rolled back at two in the morning by someone who did not write it. If nobody is named for that at scoping, nobody will do it, and the system drifts quietly until it is switched off.
The operational spine is a model registry, and its value is less engineering convenience than being able to answer one question under audit: what model is running right now, what data was it trained on, who approved the promotion, and how is it performing? A security control assessor asks the same question, which is why the registry, the promotion gate, the drift monitoring, and the rollback path are one object. That is the work on our federal MLOps capability page — versioned data snapshots with lineage, experiment tracking tied to data hash and code commit, a two-human promotion gate, canary and shadow deployment, and model documentation generated on each release rather than written from memory later.
Monitoring deserves a warning: most of it is decorative. Thresholds get set, a dashboard gets built, nobody opens it again. It earns its keep only when a breach creates work for a named person, so decide at scoping which signals do that — input drift, prediction drift, performance decay against a held-out canary, latency, and slice performance where consequences fall unevenly — and who gets the ticket.
Scoping sequence — the order that avoids the rebuild
A recommended order of decisions, not a schedule. Durations depend entirely on how long data access takes.
Pilot on the hard slice, not the clean one
There is a strong pull toward piloting on the cleanest subset of the data, because it is the one that is ready. It is also the one that transfers worst: documents already in digital text rather than scans, records with no missing fields, images taken in good conditions. A system tuned on those was tuned on the part of the problem that was never hard.
Include the ugly cases deliberately — degraded inputs, mixed formats, the rare and consequential long-tail categories, and whatever version of the data the customer actually holds rather than the one they wish they held. Include realistic volume, because throughput and hardware budget most often reopen a model choice late; GPU capacity planning covers sizing, and where the target is constrained, small language models are often the honest answer.
Put the authorization work inside the pilot, not after it
Teams new to federal work treat accreditation as a phase beginning after the software is finished. That is how a working system spends a year not being used. The decisions that set how much authorization work there is — where the boundary sits, which controls are inherited from an already-authorized platform rather than implemented fresh, how the component logs into the customer's monitoring, whether it installs offline, whether an SBOM and hardened images exist — are design decisions, cheap only while the design is soft.
Two things are worth knowing about the authorization itself. An authorization to operate is granted by an authorizing official at the organization accepting the risk, for a specific system in a specific environment, under stated conditions and with a termination date — the structure NIST SP 800-37 Revision 2 describes. No component arrives pre-accredited. More usefully for a pilot, SP 800-37 Rev. 2 also contemplates authorizing a system to operate for a short period in the operational environment before all controls are in place, with restrictions such as limited users, restricted functionality, and increased logging. That is close to the shape of a well-scoped pilot — a conversation to have early. Our walk-through is in the ATO path for an AI component.
The short version
If one table goes into the kickoff meeting, use this one. None of the left-hand column is expensive. All of it is expensive later.
| The decision | Made at scoping | Deferred |
|---|---|---|
| Where the data may live | Pilot runs under production handling rules on a representative sample, so the numbers transfer. | The pilot environment is disallowed at review, and model choice, latency, cost, and evaluation all reopen at once. |
| Runtime egress | Built with no outbound call, no license check, no model fetch at start-up. | A dependency on the open internet surfaces in the security review, and the architecture changes late. |
| Ownership of the output | An asset register names an owner for weights, labels, evaluation sets, prompts, and code. | Ownership is argued after the assets exist and both sides have already relied on them. |
| What "good" means | A written acceptance test: both error types, a real volume, a held-back set. | Success becomes a matter of opinion, and the same system passes for one reviewer and fails for the next. |
| Who operates it | A named owner, a retraining trigger, a rollback path, monitoring wired to a ticket. | The build team keeps it alive informally until they are reassigned, and then nobody does. |
| Authorization work | Boundary, inherited controls, logging, SBOM, and offline install decided while design is soft. | Documentation is written backwards from a system that was never built to be documented. |
What we do here, and what we do not
We should be concrete about our own side of that line. Precision Federal builds the production side of machine learning for federal environments: versioned data pipelines with lineage, training orchestration, model registries with real promotion gates, serving and canary deployment, drift monitoring wired into the customer's existing tooling, explainability and model documentation, and the NIST AI Risk Management Framework artifacts that go with them — the scope on our MLOps page, deployable to AWS GovCloud, Azure Government, or on-premise Kubernetes. We also build small, deployable models and headless components that run inside someone else's boundary.
What we do not do: we do not issue ATOs, and no vendor can — that authority belongs to an authorizing official. We are not a C3PAO and cannot assess anyone for CMMC. We will not hold both sides of an evaluation: if we write your independent assessment, we do not also remediate its findings, and we say which role we are taking up front. We hold no facility clearance today and do not perform classified work on classified networks. We are not a training vendor, and we do not write proposals for other firms. And we will never tell you a component arrives pre-accredited, because nothing does. Fuller scope: what we build, and what we decline.
An engagement starts the same way: send the requirement and the constraint — an impact level, an air-gapped enclave, a CUI marking, a date somebody committed to — and we will say plainly whether it is work we take on, and what the first four decisions should be. If it is not our work, we would rather say so in the first reply than in the third month.
Objections you will hear, and what they usually mean
"Let's prove the model works first, then worry about the rest."
Reasonable for model quality and wrong for environment. Whether a model is accurate enough is genuinely a question you answer by trying. Whether it can run where it must run is a question you answer by reading, and the answer changes which models you would try. Do the reading first; it costs a day and it saves the selection.
"We'll harden it after the pilot."
Hardening and re-architecting are different jobs and get conflated constantly. Adding logging, scanning, and hardened base images to a system that already runs inside the right boundary is hardening. Removing an assumption of internet access from a system built around a hosted API is a rewrite. The first is a normal cost of the pilot exit; the second is the rebuild this article is about.
"The customer told us not to worry about accreditation yet."
Often true, and it usually means the authorizing official has not been in the room. The person who says "not yet" and the person who eventually signs are rarely the same person, and the second one inherits whatever the first waved through. You do not need the ATO during the pilot. You do need to know who will grant it and what they will expect, which is a short conversation somebody should have.
"We can't get the real data, so we'll pilot on samples."
A completely normal situation. The failure is not using a sample; it is forgetting that you did. Write down what the sample under-represents — volume, degraded inputs, rare categories, format variety — and treat every result touching those as provisional. Synthetic data can fill specific gaps, and it is weakest exactly where the real long tail lives.
Frequently asked questions
Length matters less than sequence. A short pilot with the environment, data terms, acceptance test, and operator settled beforehand produces a result you can build on; a long one without them produces a demo. If you need a planning heuristic, budget more calendar time for data access and agreements than for engineering, because that is usually where the schedule actually goes.
The environment. The pilot ran somewhere production is not permitted to run — a commercial account, a hosted API, a workstation with internet access — and moving it changes the available models, the hardware, the cost, and often the data itself. Because those change together, the result is a re-selection rather than a port.
Whoever the agreement says, which is why it should say. Weights, labeled data, evaluation sets, and prompts are separable assets and can be owned separately. On federal contracts the license categories are set by clause — DFARS 252.227-7014 for defense noncommercial software, FAR 52.227-14 on the civilian side, and a distinct 20-year protection regime for SBIR and STTR data. Settle it before the assets exist.
Often, yes, but through a decision rather than an oversight. NIST SP 800-37 Rev. 2 describes authorizing a system to operate for a limited period in the operational environment before all controls are in place, with restrictions such as limited users, restricted functionality, and increased logging. That is an authorizing official's call, so the practical step is identifying that person early.
Something two people could score identically without talking to each other. In practice that means both error types counted separately at the real base rate, a stated behavior when the model is unsure, latency and throughput at production volume, a human review budget in minutes per day, and a held-back evaluation set the builders never saw. "The stakeholders were impressed" fails every part of that test.