AI Sustainment: When R&D Becomes Operations and Maintenance

I've been watching defense programs transition AI prototypes into operational systems for the past year. The common assumption is that once a model is trained and deployed, you're done. Just keep the servers running, patch the OS, and you're good.

That assumption is wrong. Dangerously wrong.

FY26 budget submissions are forcing Program Management Offices (PMOs) to confront a reality they've been avoiding: AI systems don't sustain like fighter jets or enterprise software. They require continuous intervention, monitoring, and adaptation. And the cost structures look nothing like what acquisition professionals are used to.

Today, let's talk about what AI sustainment actually means—and why the shift from R&D to O&M funding is about to expose some serious gaps in how the DoD thinks about AI lifecycle management.

The FY26 Budget Shift: R&D to O&M

Starting in FY26, multiple DoD AI programs are transitioning from Research, Development, Test & Evaluation (RDT&E) funding to Operations & Maintenance (O&M) accounts. This is standard practice for systems reaching Initial Operational Capability (IOC). Once a system proves it works, it becomes a Program of Record (POR) and shifts to sustainment funding.

For traditional systems—aircraft, ships, weapons platforms—this transition is well understood. You've got spare parts inventories, depot maintenance schedules, and tech refresh cycles every 5-10 years. The cost models are mature. The processes are documented.

For AI systems, we're making it up as we go.

Here's the problem: AI systems don't have spare parts. They don't have Mean Time Between Failures (MTBF) in the traditional sense. They don't sit idle waiting for a mission. They're continuously processing data, updating weights, and drifting from their original performance baselines.

Sustainment for AI isn't about keeping hardware alive. It's about keeping performance alive in a constantly changing operational environment.

What AI Sustainment Actually Involves

Let's be specific about what sustaining an AI/ML system requires in a DoD context. This isn't theoretical—this is what PMOs are budgeting for right now.

1. Model Retraining and Versioning

AI models degrade over time. This is called concept drift or data drift. The statistical distribution of incoming data changes, and the model's performance drops. For a computer vision model detecting targets, this could mean seasonal changes, new camouflage patterns, or shifts in sensor quality. For a predictive maintenance model on Navy ships, it could mean new operating profiles or equipment modifications.

Retraining isn't optional. It's required. But how often?

• Continuous learning systems retrain daily or weekly using automated pipelines
• Periodic retraining happens quarterly or annually based on performance monitoring
• Event-driven retraining occurs when drift detection triggers a threshold

Each retraining cycle requires:

• Labeled training data (expensive, often requires human annotators)
• Compute resources (GPUs/TPUs, which aren't cheap)
• Validation against test sets to ensure performance gains
• Deployment pipelines to push new models to production
• Rollback mechanisms when new models underperform

Traditional software sustainment doesn't budget for this. You patch vulnerabilities and add features, but you don't fundamentally retrain the application every quarter.

2. Data Pipeline Maintenance

AI systems are only as good as the data they ingest. Sustainment requires maintaining the entire data pipeline, from sensors to storage to preprocessing to inference.

In practice, this means:

• Data quality monitoring: Detecting corrupt, incomplete, or anomalous data streams
• Schema evolution: Handling changes in data formats from upstream systems
• ETL pipeline maintenance: Keeping Extract, Transform, Load jobs running as source systems change
• Data lineage tracking: Ensuring you can trace every inference back to its source data (required for audits and compliance)

On Navy ERP systems, we deal with data from dozens of legacy sources—GCSS-MC, OneTouch, LMP, you name it. When one of those systems changes its output schema, downstream AI models break. Data pipeline sustainment is about catching those failures before they cascade.

3. Continuous Monitoring and Observability

You can't sustain what you can't measure. AI systems require monitoring at multiple layers:

• Model performance metrics: Accuracy, precision, recall, F1 scores
• Inference latency: Time from input to prediction (critical for real-time systems)
• Resource utilization: GPU/CPU usage, memory consumption, storage I/O
• Drift detection: Statistical tests comparing live data to training distributions
• Explainability logs: For regulated or high-stakes decisions, you need to track why the model made each prediction

This isn't a "set it and forget it" dashboard. It requires active analysis. When performance drops, someone needs to investigate. Is it bad data? Model drift? Infrastructure degradation? Adversarial inputs?

That "someone" is a data scientist or ML engineer. Not a traditional system administrator.

4. Security and Compliance

AI systems introduce new attack surfaces. Sustainment must include:

• Adversarial robustness testing: Ensuring models resist adversarial inputs designed to fool them
• Model security: Protecting model weights and architectures from exfiltration (ITAR/export control implications)
• Bias audits: Regular testing for unintended bias in predictions (required under DoD's Responsible AI guidelines)
• Compliance reporting: Documenting AI system behavior for RMF, ATO, and audit purposes

CMMC 2.0 and NIST 800-171 don't explicitly cover AI model security yet, but they will. Sustainment teams need to be ahead of that curve.

Cost Structures: Initial vs. Ongoing

Here's where the budget shock happens.

Traditional acquisition assumes that sustainment costs are a fraction of development costs. For software, you might budget 10-20% of initial development annually for O&M. For hardware, you plan for depot maintenance, tech refresh, and obsolescence management.

AI sustainment doesn't follow those rules.

Initial Development Costs

Let's say you spend $5 million developing an AI system:

• $2M for data collection and labeling
• $1.5M for model development and experimentation
• $1M for infrastructure and tooling
• $500K for testing and validation

You train the model, deploy it, and achieve IOC. The system works. Now it's a POR.

Annual Sustainment Costs

What does year 1 of sustainment look like?

• Retraining: $800K (quarterly retraining cycles with new data)
• Data pipeline operations: $600K (maintaining ETL, data quality, storage)
• Monitoring and observability: $400K (tooling, analysis, incident response)
• Security and compliance: $300K (adversarial testing, bias audits, ATO updates)
• Infrastructure: $500K (compute resources for inference and retraining)
• Personnel: $1.2M (2 data scientists, 1 ML engineer, 1 DevSecOps engineer)

Total annual sustainment: $3.8 million

That's 76% of the initial development cost, annually.

And that's assuming the operational environment doesn't change significantly. If mission requirements shift, if new sensors are integrated, if adversaries adapt their tactics—those costs can spike.

Program of Record Implications

When an AI system becomes a POR, it triggers a set of acquisition milestones and oversight requirements. This is where PMOs hit friction.

Acquisition Category (ACAT) Changes

Most AI systems start as ACAT III or below—prototypes, experiments, rapid capability offices. Once they transition to POR status and cross certain cost thresholds, they can jump to ACAT II or even ACAT I, triggering:

• Milestone Decision Authority (MDA) reviews
• Defense Acquisition Board (DAB) oversight
• Full-rate production decisions (even though there's no "production" for software)
• Test & Evaluation Master Plan (TEMP) updates

The DoD acquisition process wasn't designed for AI. It assumes discrete production units. It assumes stable requirements. It assumes you can "lock down" a design after Milestone C.

AI systems don't work that way. They evolve continuously. Trying to force them into a waterfall acquisition framework creates bureaucratic gridlock.

Continuous Authority to Operate (cATO)

Traditional systems get an Authority to Operate (ATO) after passing RMF assessments. That ATO is valid for 3 years, assuming no major changes.

AI systems change constantly. Every model retrain is a change. Every data pipeline update is a change. The RMF process, as currently structured, can't keep up.

The answer is continuous ATO (cATO), which integrates security assessments into the CI/CD pipeline. But most DoD organizations aren't set up for this. They're still doing manual assessments with 6-12 month turnaround times.

Sustainment requires modernizing the ATO process, or AI systems will spend more time in compliance limbo than in operational use.

Organizational Challenges: Who Owns AI Sustainment?

This is the question that keeps PMOs up at night: Who is responsible for sustaining an AI system?

In traditional programs, you have clear lines:

• Logistics community handles supply chain and maintenance
• Configuration management tracks changes
• Test & Evaluation ensures performance
• Cybersecurity manages ATOs

AI doesn't fit cleanly into any of those boxes.

The Data Science Gap

Sustaining AI requires data scientists and ML engineers. But most PMOs don't have them on staff. They rely on contractors. And when the original development contractor rotates off, the new O&M contractor has to reverse-engineer the system.

I've seen this play out at BSO 60 with Navy ERP AI projects. The R&D team delivers a model, writes some documentation, and moves on. The O&M team—usually a different contractor—inherits a system they didn't build, with incomplete documentation, no automated retraining pipelines, and no monitoring in place.

Sustainment fails within 6 months.

The solution requires organic capability—government employees or long-term contractors with deep knowledge of the system. But recruiting and retaining data scientists in DoD is hard. They can make 2x the salary in private sector.

DevSecOps Integration

AI sustainment looks a lot like modern software sustainment, but with additional complexity. The DevSecOps model—continuous integration, continuous deployment, automated testing, infrastructure as code—is the right framework.

But most DoD organizations are still transitioning to DevSecOps for traditional applications. Adding AI into the mix raises the bar:

• MLOps pipelines: Automated model training, validation, and deployment
• Model registries: Versioned storage of model artifacts with metadata
• Feature stores: Centralized management of input features across models
• Experiment tracking: Logging every training run for reproducibility

These are specialized tools (MLflow, Kubeflow, DataRobot, etc.) that require specialized skills. O&M contracts need to budget for them.

Comparison to Software Sustainment

AI sustainment shares some similarities with traditional software O&M, but the differences are critical.

Similarities

• Continuous deployment: Both use CI/CD pipelines
• Monitoring: Both require observability and incident response
• Security: Both need vulnerability management and patching
• Infrastructure: Both run on cloud or on-prem compute

Differences

• Performance is non-deterministic: Software either works or doesn't. AI models degrade gracefully (or catastrophically) based on data drift
• Retraining is not patching: You can't just fix a bug. You have to retrain on new data, which is expensive and time-consuming
• Data is a dependency: Software depends on libraries and frameworks. AI depends on data, which is dynamic and often proprietary
• Testing is probabilistic: You can't write unit tests that prove correctness. You run validation sets and measure statistical performance

The closest analogy is SaaS sustainment—where the product is continuously updated based on user behavior and operational metrics. But even SaaS companies struggle with AI lifecycle management.

Implications for Defense Contractors

If you're a contractor bidding on AI sustainment work, here's what you need to know:

1. O&M Contracts Are Not Passive

Traditional O&M contracts assume you're maintaining a stable system with occasional updates. AI O&M is continuous development. Your team needs to be staffed accordingly—data scientists, ML engineers, DevSecOps, not just help desk support.

2. Cost Models Need to Reflect Reality

If you bid an AI sustainment contract at 10-15% of development costs, you're going to lose money or cut corners. Plan for 50-80% of initial development costs annually, depending on retraining frequency and operational tempo.

3. Knowledge Transfer Is Critical

If you're rotating off an R&D contract and a new contractor is taking over O&M, invest in knowledge transfer. Document your pipelines. Version your models. Set up monitoring. The new team will blame you when things break, and they will break.

4. Tool Licensing Adds Up

AI sustainment requires commercial tools—cloud compute, ML platforms, monitoring services. Don't assume the government will provide these. Budget for AWS/Azure/GCP costs, MLOps tooling, and data storage.

Implications for PMOs

If you're a government PM trying to figure out how to sustain AI systems, here's my advice:

1. Budget Realistically

AI sustainment is expensive. Don't assume software O&M cost factors. Model it based on retraining frequency, data volume, and operational tempo. If you underfund it, your system will degrade.

2. Build Organic Expertise

You can't outsource everything. You need government employees or long-term contractors who understand the system deeply. Invest in training and retention.

3. Automate Everything

Manual retraining, manual monitoring, manual deployments—these don't scale. Invest in MLOps tooling and automation. It pays for itself in reduced labor costs and faster response to issues.

4. Align Acquisition with Reality

AI systems don't fit the traditional milestone framework. Push for tailored acquisition strategies—software pathways, middle-tier acquisition, OTAs—that allow continuous evolution without DAB reviews every time you retrain a model.

5. Demand Monitoring from Day 1

Don't accept delivery of an AI system without monitoring and observability built in. If the contractor can't show you drift detection, performance dashboards, and alerting, don't sign off on delivery.

The Bottom Line

AI sustainment is not like hardware O&M. It's not like traditional software O&M. It's a hybrid model that requires continuous data management, model retraining, performance monitoring, and infrastructure optimization.

The FY26 transition from R&D to O&M funding is forcing PMOs and contractors to confront these realities. The organizations that succeed will be those that budget realistically, build organic expertise, and adopt modern MLOps practices.

The ones that don't will watch their AI systems degrade into expensive paperweights.

If you're working on AI sustainment in defense, government, or any regulated industry, these challenges are universal. The technology is new, but the acquisition and budget systems are old. Bridging that gap is the work.

Amyn Porbanderwala is Director of Innovation at Navaide, where he leads AI integration programs for Navy ERP systems at BSO 60. He's a Marine Corps veteran with 8 years of service as a Cyber Network Operator and specializes in defense AI/ML systems, financial compliance, and acquisition strategy.

Working on AI sustainment challenges? Let's talk.