The Pentagon’s artificial intelligence strategy documents promise decision advantage at scale. Defense contractors pitch predictive logistics and machine-speed targeting. The narrative is seductive… and largely irrelevant to a destroyer executive officer (XO) at sea.
At the deckplate level, the questions are fundamentally different. To the degree that an XO has time to think, the question is not “How transformative is AI?” but, “Will it work when the satellite link drops? Will my sailors trust it enough to use it, but not so much that they stop thinking for themselves? Will its absence during a high-end fight create a liability I haven’t trained for?”
These are practical, even deadly realities that determine whether a technology earns its place aboard a warship or becomes dead weight in a server rack. If artificial intelligence is to earn a place aboard surface combatants, it must be evaluated against operational reality, not against a PowerPoint brief delivered in a climate-controlled conference room. By 2027, the destroyer XO should expect onboard AI that is bounded, transparent, and resilient. They should be equally prepared for the moments when it is not.
The Environment AI Must Survive
A destroyer is a paradox. It is an austere and unforgiving operating environment that continuously produces more data than practically any other platform. Engineering systems generate continuous data streams across propulsion, electrical, and auxiliary plants, which go mostly ignored today. Combat systems fuse inputs from multiple sensors simultaneously, each with its own refresh rate, classification level, and failure modes. Administrative demands, from supply chain management to personnel qualification tracking, compete with operational demands for the crew’s every available hour. Within this data-rich environment, watch standers work under sustained fatigue, often standing six-on, six-off rotations for weeks on end.
The intuitive response is off-platform connectivity, but connectivity cannot be assumed. Even during routine steaming, communications bandwidth is finite and intermittent at best. Emissions control requirements, satellite geometry, adversary interference, and occasional equipment failure can all degrade or eliminate communications without warning. In a contested maritime environment, the very scenario the United States Navy should and is preparing to fight in, network access may be deliberately denied by the adversary for extended periods, making AI capability that depends on persistent cloud reach-back operationally irrelevant. Even without deliberate electronic interference, transmitting can be a beacon for enemy targeting. Cloud-based AI is a peacetime tool wearing a warfighting costume.
The baseline requirement is therefore unambiguous. Onboard AI must run locally, on ship-approved hardware, without external dependencies. If a system fails when the network drops, it has no place at sea. This is not some abstract aspirational standard. It is the minimum threshold for credibility in combat environments.
What Onboard AI Should Actually Do
A destroyer XO is responsible for, among other things, the standardized training of every division across the ship. By 2027, a destroyer XO should expect AI to assist the trained warfighter in all aspects of naval warfare, not as a replacement for judgment, but as a force multiplier. The most promising applications reduce friction for existing processes, freeing the crew’s cognitive bandwidth for the decisions that actually require human expertise. Applications with immediate value fall into several broad categories.
Maintenance triage. Engineering departments manage a continuous flow of discrepancies, preventive maintenance actions, and corrective work orders across complex, interdependent systems. A gas turbine engine does not fail in isolation. Rather, its degradation cascades through reduction gears, lube oil systems, and electrical generation in patterns that are difficult to track manually across thousands of maintenance entries. A mature onboard AI tool should analyze historical maintenance logs, identify recurring fault patterns before they escalate, and recommend actions based on the ship’s own operational history, not a generic baseline developed from fleet averages that may not reflect a ship’s specific material condition.
This does not displace the engineering team’s expertise. It structures information that already exists but is nearly impossible to synthesize under time pressure. The ship already has the data. AI makes the data useful. The difference between a well-maintained warship and a materially degraded one is often not a lack of information but a lack of time to process it. Critically, the tool must be transparent about its reasoning. When it flags a discrepancy as high-priority, watch standers need to understand why. They need to understand the historical pattern that drove the recommendation and how confident the model is. This is what makes an maintenance AI agent question is not a diagnostic tool. It is a black box wearing a maintenance hat.
Log and report synthesis. Warships generate an enormous quantity of written records. This includes deck logs, engineering logs, operational reports, casualty reports, and administrative correspondence, all of which accumulates daily. An effective AI assistant should compress and synthesize that data, summarize logs into concise operational briefs, flag negative trends, and cross-reference issues across departments that would otherwise remain siloed. When the combat systems officer’s maintenance trends correlate with the chief engineer’s power generation anomalies, the XO needs to see that connection without manually reading two hundred pages of logs. The value is not novelty. It is time recovery. Hours currently spent reviewing administrative records become minutes, and those recovered hours translate directly into training time, rest, or tactical planning. The caveat, as with maintenance AI, is transparency and the consequent trust: a synthesis tool that obscures the source data behind its conclusions cannot be trusted, because the XO has no way to assess whether the summary has missed something operationally significant.
Procedural recall under stress. When a flooding boundary is expanding, smoke is filling a space, or the repair locker team needs to know the location of the nearest fire main valve, cognitive load is at its highest and error tolerance is at its lowest. An AI system should rapidly surface relevant instructions and present structured guidance tied to approved technical documents. It should not generate novel doctrine on the fly. Instead, it should organize what already exists and make it accessible under pressure. The caveat here is critical: the system must draw exclusively from verified, configuration-controlled source documents. A tool that synthesizes procedures from multiple sources, or worse, generates plausible-sounding guidance from training data rather than authoritative technical manuals, introduces risk precisely when the stakes are highest. The value of procedural AI is speed and clarity, not creativity.
Distributed training support. Training time is scarce and constantly competed against by maintenance demands, watch rotations, and administrative requirements. AI can assist by generating scenario-based prompts, tracking qualification progress across divisions, and reinforcing procedural understanding between formal evolutions. A junior officer preparing for a professional knowledge board, or a damage controlman reviewing casualty procedures between drills, benefits from on-demand support that does not require pulling a senior sailor off watch. The limitation worth acknowledging is that AI-assisted training is a supplement, not a substitute, for the mentorship and direct observation that develop genuine competence. Scenario prompts can reinforce knowledge. They cannot replicate the judgment that comes from working alongside experienced petty officers over time.
The Dependency Trap
The more subtle risk of onboard AI is that sailors stop performing without it.
If the Combat Information Center (CIC) watch relies on AI-generated track correlation, if the engineering watch relies on AI-prioritized maintenance queues, if the quarterdeck watch relies on AI-drafted reports, then their absence during combat operations will create friction at exactly the wrong moment. This is not a hypothetical. It is the predictable consequence of any capability that integrates faster than the training culture adapts. Every augmentation is an amputation. History offers ample precedent. GPS navigation degraded celestial navigation skills across the fleet within a generation, and the Navy is still working to recover that competency. AI presents the same risk at greater scale and speed.
A destroyer XO must treat onboard AI as an augmentation layer, not as infrastructure. The distinction is critical. An augmentation layer improves performance when present but does not create a capability gap when absent. Infrastructure, by contrast, is load-bearing. Its removal causes structural failure. Before fielding any AI tool, the XO should ask three questions: “What manual processes exist if the system fails?”, “Are watchstanders trained to operate independently of AI assistance?”, and “Does institutional knowledge live in the crew, or has it migrated into the tool?”
Redundancy in mechanical systems is standard practice at sea. The same logic must apply to cognitive systems. If AI becomes a silent dependency, its failure will produce operational surprise, and operational surprise is the one thing a warship cannot afford in a contested environment.
When AI Gets It Wrong
Probabilistic models generate confident outputs. They also generate confident wrong outputs. Even mission-specific, locally deployed AI systems can misinterpret data, surface misleading correlations, or fail silently in ways that are not immediately apparent. A maintenance prediction model trained on peacetime steaming patterns may produce dangerously inaccurate recommendations during high-tempo combat operations where equipment is driven well beyond normal parameters. The architecture of modern machine learning does not provide natural safeguards against this, though deliberate architectures can mitigate some risks. The real safeguard, however, is the human in the loop.
An XO should expect any onboard AI system to offer transparent reasoning pathways, traceability to source data, and clear articulation of uncertainty. A system that presents conclusions without exposing its basis is a liability, not an asset. The correct operational posture is disciplined skepticism, neither blind acceptance of AI output nor reflexive dismissal of AI insights. Watch standers should be trained not only to use AI tools, but to interrogate them. What data drove this recommendation? What is the confidence interval? What was excluded from the analysis?
That training is not optional. It is the difference between AI as a capability and AI as a vulnerability. The fleet has always understood that a tool is only as good as the sailor operating it. AI does not change that principle. It raises the stakes.
Command Authority Does Not Transfer
Artificial intelligence should compress cognitive load. It cannot compress accountability. Onboard AI must remain subordinate to command authority at every layer. It can assist with pattern recognition and information synthesis. It cannot bear responsibility for the decisions that follow. Final authority must always rest with the accountable officers.
The Navy’s culture of command responsibility did not emerge arbitrarily. It reflects hard-earned understanding, often paid for in lives, of what happens when accountability diffuses. AI does not change that calculus. If anything, the introduction of capable AI tools makes the deliberate preservation of command culture more important, not less. When a machine recommends a course of action and a commanding officer accepts it, the responsibility for the outcome belongs entirely to the officer. Technology should reinforce that culture, not erode it by degrees through the gradual normalization of deference to algorithmic output.
The Standard
Artificial intelligence aboard a warship should not look like a revolution. It should look like a well-trained petty officer who never sleeps, never tires, and never lets a maintenance log fall through the cracks.
By 2027, a destroyer XO should demand AI that operates fully offline without degradation, exposes transparent and traceable reasoning, integrates without destabilizing shipboard networks, reduces administrative and cognitive burden measurably, and fails gracefully, loudly enough that watch standers notice before the gap becomes a hazard.
If a system meets those criteria, it earns a place aboard. If it promises transformation while depending on perfect conditions, it is not yet ready for sea. The Navy does not field systems that only function in permissive environments. Neither should it field AI that does.
The decisive variable in AI adoption is not model sophistication. It is operational fit, and operational fit is proven at sea, not in a vendor demonstration. The fleet’s standard has always been simple: perform when conditions are imperfect, and give commanders the tools to succeed. That standard does not change because the technology is new.
John Babick is a retired naval officer and defense technology professional with experience in edge AI deployment for maritime operations. He currently works for EdgeRunner. The views expressed are his own and do not represent the views of the Department of Defense or the United States Navy.
Featured image: Jim Blesse, standing, from the Office of Naval Research, explains project BlueShark to Lt. Col. John Moore from the Marine Corps Warfighting Laboratory. Project BlueShark is an ONR effort to create a high-tech, futuristic environment to demonstrate what operational work environments might look like and what emerging innovative technologies might provide in the next decade. (U.S. Navy photo by John F. Williams)
Naval warfare is approaching a point where the traditional capital ship is no longer an unambiguous asset in contested waters. For decades, naval power was measured in tonnage and platforms: the size of destroyers, the number of vertical launch cells, the quietness of submarines. That framework still matters, but it is no longer sufficient. Increasingly, the most serious threat to a multi-billion-dollar surface combatant is not a peer navy’s capital ship, but a mass of inexpensive, expendable autonomous systems that strain the ship’s ability to defend itself.
This dynamic resembles a modern incarnation of the Jeune École theory of the late nineteenth century, which argued that small, inexpensive platforms armed with torpedoes could undermine battleship dominance. What technology has changed is not the idea itself, but its feasibility. Today, autonomous systems allow navies that cannot compete ship-for-ship to impose risk at sea at a fraction of the cost. Concepts resembling Project Seawarden illustrate how sea denial can be achieved not by matching an adversary’s fleet, but by making forward operations increasingly hazardous.
Doctrinal Shifts: The Indo-Pacific Reality
This shift from theory to doctrine is currently manifesting across the Indo-Pacific, where regional powers are actively prioritizing asymmetric denial over traditional fleet matching.
The USV Threat: Surface Denial
Recognizing that matching Chinese naval tonnage is financially and logistically prohibitive, Taiwan is rapidly shifting its procurement toward sea denial capabilities. Taipei is prioritizing the development and mass production of uncrewed surface vessels (USVs), such as the Endeavour Manta and Kuai Chi.1,2 These platforms are explicitly designed for intelligence, surveillance, reconnaissance, and one-way kamikaze missions. Capable of carrying explosive payloads, they present a highly expendable, low-cost threat specifically optimized to strike high-value surface combatants and enforce sea denial in the contested waters of the Taiwan Strait.
The UUV Threat: Subsurface Friction
Beneath the surface, the focus has shifted toward generating persistent friction without risking multi-billion-dollar crewed submarines. The Royal Australian Navy, in collaboration with industry partners, is rapidly producing the “Ghost Shark” Extra Large Autonomous Undersea Vehicle (XL-AUV).3 This program aims to deliver a stealthy, long-range autonomous capability to conduct persistent surveillance and strike missions, effectively laying down an affordable undersea deterrence layer. Concurrently, China views the undersea domain as central to great-power competition, actively integrating seabed sensors and unmanned underwater vehicles (UUVs) into a vast anti-submarine warfare network designed to control maritime choke points and compel adversary vessels to withdraw.4
The Network: The Multi-Domain Fabric
Physical drones, however, cannot enforce denial in isolation; they require a battle space management network capable of coordinating them across domains to overwhelm adversary defenses. Acknowledging the need to counter the People’s Liberation Army’s advantage in mass, the U.S. Department of Defense launched the “Replicator” initiative.5 Driven heavily by the operational needs of the Indo-Pacific Command, Replicator aims to field thousands of attritable, autonomous systems across multiple domains within a two-year window. By networking these small, smart, and cheap systems, the strategic objective is to penetrate heavily contested anti-access/area-denial (A2/AD) environments, creating a distributed autonomous fabric that paralyzes adversary logistics and operational tempo.
The Logistics of the Interceptor Trap
The central problem is not simply that autonomous drones are cheap. It is that defending against them is expensive, finite, and logistically fragile. Modern surface combatants rely on highly capable interceptors such as the SM-2 or Aster 30, each costing millions of dollars and occupying limited space in a ship’s vertical launch system. Against a small number of high-end threats, this exchange makes sense. Against large numbers of low-cost autonomous platforms, it does not.
This creates what can be described as the “Interceptor Trap.” Defenders are compelled to expend scarce, high-value interceptors against targets that may cost only tens of thousands of dollars. The imbalance is not merely financial. Missile magazines cannot be replenished at sea, and once depleted, a ship must withdraw to reload. By contrast, an adversary can scale production of simple autonomous systems far more rapidly and with fewer constraints. Systems modeled on the Seawarden concept exploit this friction. They do not need to penetrate defenses perfectly; they need only to force defenders to consume their most capable weapons on the least valuable targets.
Attacking the Logistics Chain
Much of the discussion around autonomous maritime systems focuses on dramatic scenarios involving aircraft carriers or major surface combatants. In practice, the more consequential vulnerability lies elsewhere. Fleet oilers, replenishment ships, and other logistics vessels are essential to sustained naval operations, yet they are slow, lightly defended, and highly visible.
Disrupting these ships does not require sinking them outright. Damage to propulsion, steering, or hull integrity can remove a logistics vessel from service for months. Without reliable replenishment, even the most capable carrier strike group becomes tethered to distant ports. Autonomous underwater or surface systems do not need to breach the layered defenses of a destroyer to shape a campaign; targeting the logistics tail can achieve the same effect more reliably. It is not a dramatic way to fight, but it is an effective one.
Persistent Friction and the Zone of Uncertainty
Autonomous systems impose costs even when they do not attack. The maritime environment is already cluttered with biological noise, commercial traffic, and complex acoustic conditions. Introducing large numbers of small, low-signature platforms into this environment compounds the problem. Distinguishing a hostile autonomous system from benign background noise becomes a continuous challenge rather than a discrete event.
For operators, this creates sustained cognitive strain. Commanders must assume that any contact could represent a threat, even if most do not. Ships maneuver more aggressively, burn more fuel, and devote greater attention to defensive postures. Over time, this persistent uncertainty degrades operational tempo and increases the likelihood of error. Autonomous systems designed for endurance and persistence are particularly effective at generating this friction, regardless of whether they ever fire a weapon.
Conclusion: The End of Maritime Sanctuary
High-value naval platforms carry significance far beyond their military utility. They are symbols of national prestige, and damage to them carries political consequences even when losses are limited. By contrast, unmanned systems carry little political risk. Losing an autonomous platform does not provoke domestic backlash or escalation pressure.
As competition intensifies in regions such as the Indian Ocean, the balance of advantage may increasingly Favor those who can impose denial rather than project dominance. The decisive question is shifting away from who fields the most impressive platforms, and toward who can most effectively deny the use of contested maritime spaces. In that environment, low-cost autonomous systems are not force multipliers; they are force limiters, capable of eroding the operational freedom of even the most advanced navies.
Rudraksh Pathak is an undergraduate engineering student and co-founder of Enlir Avant Systéme. His research focuses on maritime strategy, autonomous systems, and distributed unmanned architectures in naval warfare. His current work explores ontologies for defense systems, systems engineering for unmanned battle management systems, and digital twin frameworks for autonomous operational environments.
References
[1] “Taiwanese Drone Firm Pitches Unmanned Surface Vessels for Coastal Defense,” USNI News, December 2025.
[2] Sutton, H. I. “Taiwan’s Asymmetric Capabilities: Weaponised Uncrewed Surface Vessels,” Covert Shores, August 2024.
[3]”Anduril Wins Ghost Shark Contract,” Australian Defence Magazine, September 10, 2025.
[4]”Exploring the Role of UUVs in Maritime Surveillance and A2/AD Capabilities,” Center for a New American Security (CNAS), June 2024.
[5]”Implementing the Department of Defense Replicator Initiative to Accelerate All-Domain Attritable Autonomous Systems,” Defense Innovation Unit (DIU), U.S. Department of Defense, November 30, 2023.
Featured Image: Medium displacement unmanned surface vessel Sea Hunter sails in formation during Rim of the Pacific (RIMPAC) 2022., Aug. 3, 2022. (U.S. Navy Photo by Petty Officer 3rd Class Kylie Jagiello.)
“When companies spend millions of dollars on new information technologies but don’t change anything else, there are usually barely detectable productivity improvements. In contrast, when they also invest similar amounts in business process changes and in worker training, productivity can double or more.”-The Second Machine Age: Work, Progress, and Prosperity in a Time of Brilliant Technologies by Andrew McAfee and Erik Brynjolfsson
In the last year, Israel disabled all of Iran and Hezbollah’s senior military leadership at a stroke with a series of audacious precision strikes. Ukraine launched hundreds of small drones against Russia’s strategic air assets from clandestine launch locations deep inside Russian territory. Though the weaponry and tactics employed in these strikes varied wildly from explosive pagers to first person view (FPV) drones, one common thread tied these operations together – innovation in the realm of Information Warfare (IW). From the Levant to the Black Sea, the crucial role played by IW (hereafter used collectively to refer to the intelligence, cryptology, information technology, meteorology/oceanography, cyber, and space communities) has never been more impactful to warfighting than it is today.
The US Navy has adjusted accordingly to this changing character of war. In 2024, the Navy moved Information Warfare (IW) out of the Restricted Line officer category and into a newly minted Information Warfare Line (IWL) category, which serves to both acknowledge IW’s growing impact on operations and to open additional opportunities for leadership across the Fleet. This elevation offers the IW community an excellent chance to step back, assess its tactical strengths and weaknesses, and innovate where needed.
If called upon today, could the Navy’s IW community deliver the same level of support to operations that the IDF and Ukrainian military receive from their respective military intelligence communities today? Surely it has the resources. The IW community has a workforce in the tens of thousands and close working ties with the national intelligence community. The DoW is making huge capital investments in AI solutions that should positively impact IW workflows. With all these resources available, is innovation even necessary?
The answer is yes. Despite being well-stocked with talented personnel and appropriated funds, the Navy IW community aboard Carrier Strike Groups (CSGs), Amphibious Readiness Groups (ARGs), and at fleet-level Maritime Operations Centers (MOCs) still operate according to increasingly antiquated and inefficient business practices. Dozens of human analysts spend countless man-hours every day creating and editing PowerPoints. Others spend time using outdated search tools to answer requests for information (RFIs) from senior leadership, watchstanders, and other operators throughout the organization. Compounding these challenges is the structure of the information systems themselves, as critical information remains siloed in disparate databases, thwarting rapid retrieval, analysis, and automated fusion. The net effect of these overlapping issues is that the most data-centric part of the Navy, the Information Warfare Community, is today poorly postured to lead the Navy’s digital transformation and risks failing to effectively adapt to the modern maritime battlespace.
Luckily for the Navy and the country at-large, there are several innovative initiatives underway across the naval IW enterprise that are showing us the way forward. These efforts, coupled with the thoughtful integration of commercially available AI solutions, offer Navy IW a once in a generation opportunity to increase productivity and output for relatively little cost. The solutions can be grouped into three categories: workforce, organizational reform, and technological solutions.
Workforce: Identifying and Cultivating Digital Talent
Walk into any MOC in the Navy and you may find an intelligent, bright-eyed young individual who identifies themselves as the command’s Chief Data Officer, or maybe Chief Technology Officer, or perhaps lead for Artificial Intelligence or Data Science. Press them a little further and they will happily explain to you that they started off at the MOC doing something entirely different but at some point they shared with their leadership that they had a technical background and could do some coding and voila they received a new job, a new set of responsibilities, and a direct line of communication to senior leadership.
The positions of Chief Data Officer, Chief Technology Officer, AI Lead, etc. do not exist on any MOC manning documents. Still, those individuals are today found at every MOC in the Fleet. What is happening? The simplest answer is that the operational leadership at the MOCs realized they needed something that Big Navy was unable or unwilling to provide, then created new positions of their own accord by drawing from their own staffs. Every MOC did this independently, seemingly without coordinating across the Service. This is both an admirable example of deckplate innovation at the MOC-level and a fairly serious indictment of the Navy’s manpower challenges when it comes to manning a modern, digital workforce.
But the need for an innovative solution only highlights a Fleet-wide problem. The Navy lacks the ability to identify, employ, and retain digital talent (hereafter “digital” will refer to data science, data engineering, and artificial intelligence, broadly defined). There is one Navy Additional Qualifying Designator (AQD) for Data Science and it is only granted upon graduation from the Naval Postgraduate School’s (NPS) Data Science Program. There are no equivalent AQDs for artificial intelligence or other information- and data- related fields of study. The Navy currently has a much better understanding of which Sailors speak Hausa than which can code in Python, C++, or Java.
The easiest way for the Navy to address this issue is to leverage work already done by the DoW. The DoW’s Digital Workforce initiative, started by the DoW Chief Data and Analytics Office (CDAO) in 2022, generated multiple highly readable reports and useful insights for how to develop “digital talent” across the DoW. CDAO already did the hard work by creating language that could easily convert to Navy AQDs and Sub Specialty Codes (SSPs) related to data science, data engineering, software engineering, AI, etc. Once established, these AQDs and SSPs should be called out explicitly in board convening orders and other promotion criteria, making plain to both promoters and promotees that such skills are as much Navy priorities as Operations Research and Financial Management. The IW community can further lead in workforce development by serving as the community sponsor for innovative graduate certificate programs and “stackable” degrees delivered asymmetrically, including the recently-launched Master of Applied Computing program at NPS.
The AQD/SSP approach has the advantage of increasing the Navy’s oversight of who has which digital skills without unduly disturbing existing career paths, and allows detailers, commanders, and other senior leaders to quickly find and fit talent to key roles in the Fleet. Formally recognizing digital qualifications would have positive impacts on URL communities as well. For instance, an E-2D pilot with coding expertise can still be a pilot, but the Navy will also be aware that he or she has coding expertise, allowing that person to fill relevant billets, liaison roles, or collateral duties. Over time, this AQD/SSP approach will allow the formal creation of billets like the MOC Chief Data Officer and ensure that those billets are manned by qualified personnel. We believe the above recommendations are in alignment with the “Talent” section of the DoW’s January 9, 2026 AI guidance.
Organizational Reform Afloat and at the Fleets
In November 2022, Carrier Strike Group One (CSG-1), in collaboration with Project Overmatch, established the Navy’s first Data Science at Sea (DS@S) team empowered to use all available intelligence, battlespace, and operational data to address emerging warfare requirements. The DS@S team, cobbled together from volunteers around CSG-1 and its subordinate units, automated routine tasks and found novel ways to analyze, fuse, and visualize battlespace data over two deployments to the Western Pacific and the 2024 Rim of the Pacific (RIMPAC) exercise in Hawaii. This grassroots effort went on to inspire similar efforts through PACFLT and resulted in the generation of a classified TACMEMO from the Navy Information Warfare Development Center (NIWDC) detailing the initiative.1
Over the teams’ nearly three years of operations on CSG-1, it partially or fully automated many IW processes across the Strike Group. The major lesson learned was not that you can do more IW work with fewer people – although this is true – but rather that the DS@S approach creates more bandwidth and time for meaningful human analysis. The DS@S team also developed several novel battlespace awareness and planning tools that are now commonly used by units across the Pacific.2
These teams cannot continue to operate on an ad hoc basis, however, and must be codified, trained, and employed with the same eye towards standardization as at any ESG or MOC across the Fleet. Activating reservists and peeling civilian shipriders away from other tasks has worked well enough to date but is not sustainable over time due to an ever expanding list of operational requirements with ever limited material and personnel resources. To generate consistent decision advantage, build skills over time, and be maximally responsive to the needs of the CSG, ESG, or MOC Commander, data science teams must have a permanent home, dedicated billets, and funding for both training and equipment. In May 2025, the Naval Postgraduate School hosted a summit with a variety of stakeholders to tackle these issues and explore how best to scale the DS@S initiative across the Fleet and “productionalize” the tools that the deployed teams develop.
Until now, the CSG-1 DS@S team has been housed within the Admiral’s staff, but the most natural fit for such a group is within the Information Warfare Commander (IWC) afloat construct. At present, the IWC is the senior member of the IW community embarked with the CSG, but as a member of the Admiral’s staff is without ADCON of any personnel and OPCON of only a select few. The exact nature of the IWC’s roles and responsibilities varies between CSGs based on commander’s discretion. The lack of job standardization and formal authorities (i.e., budget, NJP) for IWCs across the Fleet has hamstrung the role.
There is an effort underway to address the structural weakness of the current IWC construct. In December 2025, Naval Information Forces (NAVIFOR), the TYCOM for IW across the fleet, established two Information Warfare Squadrons or IWRONs. These IWRONs are designed to “addresses the increasing complexity and sophistication of global threats, which actively seek to exploit vulnerabilities from seabed to space.”3 It is critical that these new IWRONs establish DS@S teams as a Department within the command. Should these pilot IWRON initiatives succeed, they should be replicated both ashore at the MOC (as previously discussed) and afloat at the Navy’s Amphibious Readiness Groups (ARGs). In this construct, the DS@S team would have the personnel, budget, hardware, and authorities to operate continuously as a digital innovation hub for the entire CSG. The IWC could even dispatch the team to work with allies and partners, as the CSG-1 DS@S team did with its French counterparts aboard ships within the CHARLES DE GAULLE Strike Group during the PACIFIC STELLER series of exercises in early 2025.4
Technological Transformation: Leveraging AI and Data
First airing in 1966, Gene Rodenberry’s Star Trek imagined a future where technology had completely redefined the human experience, allowing us to explore the universe with a fleet of massive spacecraft. One thing that the starship Enterprise did not have was an Intelligence Officer. If someone wanted to know a specific scientific fact, the capabilities of Klingon ships or the location of the nearest spaceport, they asked “Computer.” The US Navy is not quite there yet, but we’re much closer now than ever. In July 2025, the DoW announced it was granting contract awards of up to $200 million for artificial intelligence development at Anthropic, Google, OpenAI and xAI.5 Not all of that money will directly impact Navy priorities, nor will it be immediately available to afloat units, but we are getting very close to the day when almost all classified RFIs can be answered by a Large Language Model (LLM) connected to every SIPR and JWICS on a ship. Secretary Hegseth’s December announcement of GenAi.mil is a welcome step towards realizing this vision.6
The deployment of LLMs on classified datasets across the Fleet is unlikely to lead to the wholesale replacement of IW personnel but will likely change the nature of their work. LLMs on warships will need to be optimized to operate in denied or degraded communications environments, meaning they likely need to be installed and run locally onboard ships. This will improve daily performance by removing the need for an internet connection, but it also means that over the course of a deployment the datasets feeding the LLM will become out of date and questions like “when is the last time Country X’s ship operated here” will go from being accurate and useful to inaccurate and misleading after a few weeks.
This means that the role of deployed IW personnel will be ensuring that the datasets feeding LLMs are accurate and up to date. This includes the tactical data that is collected by the ship during the course of a deployment, whether that is intelligence, METOC, or SIGINT data. As this data management and LLM curation will be a cross-IW enterprise it should become a core function of the nascent IWRON structure discussed above. Some learning and experimentation will be required as the knowledge management practices onboard most ships today do not extend beyond maintaining Sharepoint sites, Collaboration at Sea (CaS) pages, or share drive folders.
Of course ships themselves must also be considered in the execution of this concept, particularly regarding space available for hardware and power output to run LLMs as described. Operating the aforementioned equipment requires specialized–or at least dedicated–compute, which will have to be installed likely in classified spaces already at a premium on smaller classes of warship. Furthermore, both the ship’s Engineering and Information Warfare teams must be engaged to determine what capabilities could be lost or degraded if LLMs are integrated into the ship’s technology stack, including hardware, software, power supply, maintainers, and operators. These conversations and their solutions fall squarely in the wheelhouse of NAVIFOR’s IWRON program, currently being piloted on both the east and west coasts. IW Commodores and their staffs should work directly with both operational and training DESRONs, along with AIRLANT/PAC and CSG staffs, to ensure hardware, software, and manpower training and operational needs are met going into workup and deployment cycles. Integrating these solutions into routine operations as quickly as possible will be key to fully implementing an AI strategy that is set up for success.
Innovation is Necessary to Retain IW’s Warfighting Edge
As McAfee and Brynjolfsson note, investments in both workforce training and improved business practices are more impactful than technological investment alone. The Navy IW community must therefore be proactive in addressing its productivity challenges by taking a round turn on training and innovation. We must organize our forces both afloat and ashore to identify current talent, train new innovators, and ensure they are accounted for throughout their time in uniform. We must prioritize our operational forces both afloat and ashore. This means the IWC must be resourced, staffed, and authorized appropriately to operate afloat, while their MOC counterparts must be similarly taken care of ashore. And we must incentivize our most innovative personnel–the Navy’s greatest strength–to learn, train, fight, and stay Navy.
Taken together, these improvements are critical to the Navy’s future and certainly greater than the sum of their parts. The journey of a thousand miles begins with a single step, after all. The Navy has reorganized itself to adapt to technological change time and again – steel over wood, steam over wind. Now the Navy must absorb, understand, and harness the power of the digital technologies to maintain its warfighting edge.
Lieutenant Commander Shane Halton is an Intelligence Officer currently serving in Washington DC. He previously served as a Requirements Officer at the Navy’s Digital Warfare Office and helped create the Navy’s first Data Science at Sea team aboard CSG-1.
Lieutenant Commander Adam Reiffen is an Intelligence Officer currently serving as a Federal Executive Fellow at Brown University’s Watson School of International and Public Affairs. He previously served as a Requirements Officer at OPNAV N2N6 and was Officer-in-Charge of the Navy’s Data Science at Sea team aboard CSG-1 from 2024-25.
The opinions expressed are those of the authors and do not reflect the views or policy of the U.S. Department of War, the Department of the Navy, or the U.S. government. No federal endorsement is implied or intended.
References
1. Rear Admiral Carlos Sardiello and Lieutenant Commander Shane Halton, U.S. Navy, and Annie Voigt, CNA, “The Case for Data Science at Sea,” CNA In-Depth, June 2024, https://www.cna.org/our-media/indepth/2024/06/the-case-for-data-science-at-sea.
2. Lieutenant Commanders Adam Reiffen and Shane Halton, U.S. Navy, “Lessons Learned in Year One of Data Science at Sea,” Proceedings, May 2024, https://www.usni.org/magazines/proceedings/2024/may/lessons-learned-year-one-data-science-sea.
3. Joshua Rodriguez, U.S. Navy, “A Paradigm Shift: Navy Establishes First Information Warfare Squadron, ” navy.mil, Dec 2025, https://www.navy.mil/Press-Office/News-Stories/display-news/Article/4353901/a-paradigm-shift-navy-establishes-first-information-warfare-squadron/
4. Ensign Rachael Jones, U.S. Navy, “U.S. and French Host First-Ever Military Hackathon at Sea,” DVIDS, May 2024, https://www.dvidshub.net/news/492989/us-french-host-first-ever-military-hackathon-sea.
5. Sydney J. Freedberg, Jr., “Anthropic, Google and xAI win $200M each from Pentagon AI chief for ‘agentic AI’,” Breaking Defense, July 14, 2025, https://breakingdefense.com/2025/07/anthropic-google-and-xai-win-200m-each-from-pentagon-ai-chief-for-agentic-ai/
6. C. Todd Lopez, ”Hegseth Introduces Department to New AI Tool,” war.gov, Dec 2025, https://www.war.gov/News/News-Stories/Article/Article/4355797/hegseth-introduces-department-to-new-ai-tool/.
Featured Image: GULF OF ALASKA (Aug. 23, 2025) Lt. Michael Zittrauer works on a terminal in the combat information center (CIC) aboard the Arleigh Burke-class guided-missile destroyer USS Frank E. Petersen Jr. (DDG 121) during exercise Northern Edge 2025 (NE25). (U.S. Navy photo by Mass Communication Specialist 3rd Class Christian Kibler)
In September 2023, the Royal Navy (RN) advertised the launch of the Naval AI Cell (NAIC), designed to identify and advance AI capability across the RN. NAIC will act as a ‘transformation office’, supporting adoption of AI across RN use cases, until it becomes part of Business as Usual (BaU). NAIC aims to overcome a key issue with current deployment approaches. These usually deploy AI as one-off transformation projects, normally via innovation funding, and often result in project failure. The nature of an ‘Innovation Budget’ means that when the budget is spent, there is no ability to further develop, or deploy, any successful Proof of Concept (PoC) system that emerged.
AI is no longer an abstract innovation; it is fast becoming BaU, and it is right that the RN’s internal processes reflect this. Culturally, it embeds the idea that any AI deployment must be both value-adding and enduring. It forces any would-be AI purchaser to focus on Commercial Off The Shelf (COTS) solutions, significantly reducing the risk of project failure, and leveraging the significant investment already made by AI providers.
Nevertheless, NAIC’s sponsored projects still lack follow-on budgets and are limited in scope to just RN-focused issues. The danger still exists that NAIC’s AI projects fail to achieve widespread adoption, despite initial funding; a common technology-related barrier, known as the ‘Valley of Death.’ In theory, there is significant cross-Top Line Budget (TLB) support to ensure the ‘Valley’ can be bridged. The Defense AI and Autonomy Unit within MOD Main Building is mandated to provide policy and ethical guidance for AI projects, while the Defense Digital/Dstl Defense AI Centre (DAIC) acts as a repository for cross-MOD AI development and deployment advice. Defense Digital also provides most of the underlying infrastructure required for AI to deploy successfully. Known by Dstl as ‘AI Building Blocks’, this includes secure cloud compute and storage in the shape of MODCloud (in both Amazon Web Service and Microsoft Azure) and the Defense Data Analytics Portal (DDAP), a remote desktop of data analytics tools that lets contractors and uniformed teams collaborate at OFFICIAL SENSITIVE, and accessible via MODNet.
The NAIC therefore needs to combine its BaU approach with other interventions, if AI and data analytics deployment is to prove successful, namely:
Create cross-TLB teams of individuals around a particular workflow, thus ensuring a larger budget can be brought to bear against common issues.
Staff these teams from junior ranks and rates, and delegate them development and budget responsibilities.
Ensure these teams prioritize learning from experience and failing fast; predominantly by quickly and cheaply deploying existing COTS, or Crown-owned AI and data tools. Writing ‘Discovery Reports’ should be discouraged.
Enable reverse-mentoring, whereby these teams share their learnings with Flag Officer (one-star and above) sponsors.
Provide these teams with the means to seamlessly move their projects into Business as Usual (BaU) capabilities.
In theory this should greatly improve the odds of successful AI delivery. Cross-TLB teams should have approximately three times the budget to solve the same problem, when compared to an RN-only team. Furthermore, as the users of any developed solution, teams are more likely to buy and/or develop systems that work and deliver value for money. With hands-on experience and ever easier to deploy COTS AI and data tools, teams will be able to fail fast and cheaply, and usually at a lower cost than employing consultants. Flag Officers providing overarching sponsorship will receive valuable reverse-mentoring; specifically understanding first-hand the disruptive potential of AI systems, the effort involved in understanding use-cases and the need for underlying data and infrastructure. Finally, as projects will already be proven and part of BaU, projects may be cheaper and less likely to fail than current efforts.
Naval AI Cell: Initial Projects
The first four tenders from the NAIC were released via the Home Office Accelerated Capability Environment (ACE) procurement framework in March 2024. Each tender aims to deliver a ‘Discovery’ phase, exploring how AI could be used to mitigate different RN-related problems.1 However, the nature of the work, the very short amount of time for contractors to respond, and relatively low funding available raises concern about the value for money they will deliver. Industry was given four days to provide responses to the tender, about a fifth of the usual time, perhaps a reflection of the need to complete projects before the end of the financial year. Additionally, the budget for each task was set at approximately a third of the level for equivalent Discovery work across the rest of Government.2 The tenders reflect a wide range of AI use-cases, including investigating JPA personnel records, monitoring pictures of rotary wing oil filter papers, and underwater sound datasets, each of which requires a completely different Machine Learning approach.
Figure 1: An example self-service AI Workflow, made by a frontline civilian team to automatically detect workers not wearing PPE. The team itself has labelled relevant data, trained and then deployed the model using COTS user interface. Source: V7 Labs.
Take the NAIC’s aircraft maintenance problem-set as an example. The exact problem (automating the examination of oil filter papers of rotary wing aircraft) is faced by all three Single Services. First, by joining forces with the RAF to solve this same problem, the Discovery budget could have been doubled, resulting in a higher likelihood of project success and ongoing savings. Second, by licensing a pre-existing, easy-to-use commercial system that already solves this problem, NAIC could have replaced a Discovery report, written by a contractor, with cheaper, live, hands-on experience of how useful AI was in solving the problem.3 This would have resulted in more money being available, and a cheaper approach being taken.
Had the experiment failed, uniformed personnel would have learnt significantly more from their hands-on experience than by reading a Discovery report, and at a fraction of the price. Had it succeeded, the lessons would have been shared across all three Services and improved the chance of success of any follow-on AI deployment across wider MOD. An example of a COTS system that achieves this is V7’s data labeling and model deployment system, available with a simple user interface; it is free for up to 3 people, or £722/month for more complex requirements.4 A low-level user experiment using this kind of platform is unlikely to have developed sufficient sensitive data to have gone beyond OFFICIAL.
Introducing ‘Workflow Automation Guilds’
Focusing on painful, AI-solvable problems, shared across Defense, is a good driver to overcome these stovepipes. Identification of these workflows has been completed by the DAIC and listed in the Defence AI Playbook.5 It lists 15 areas where AI has potential to deliver a step-change capability. Removing the problems that are likely to be solved by Large Language Models (where a separate Defence Digital procurement is already underway), leaves 10 workflows (e.g. Spare Parts Failure Prediction, Optimizing Helicopter Training etc) where AI automation could be valuably deployed.
However, up to four different organizations are deploying AI to automate these 10 workflows, resulting in budgets that are too small to result in impactful, recurring work; or at least, preventing this work from happening quickly. Cross-Front Line Command (FLC) teams could be created, enabling budgets to be combined to solve the same work problem they collectively face. In the AI industry, these teams are known as ‘Guilds’; and given the aim is to automate Workflows, the term Workflow Automation Guilds (WAGs) neatly sums up the role of these potential x-FLC teams.
Focus on Junior Personnel
The best way to populate these Guilds is to follow the lead of the US Navy (USN) and US Air Force (USAF), who independently decided the best way to make progress with AI and data is to empower their most junior people, giving them responsibility for deploying this technology to solve difficult problems. In exactly the same way that the RN would not allow a Warfare Officer to take Sea Command if they are unable to draw a propulsion shaft-line diagram, so an AI or data deployment program should not be the responsibility of someone senior who does not know or understand the basics of Kubernetes or Docker.6 For example, when the USAF created their ‘Platform One’ AI development platform, roles were disproportionately populated by lower ranks and rates. As Nic Chaillan, then USAF Chief Software Officer, noted:
“When we started picking people for Platform One, you know who we picked? A lot of Enlisted, Majors, Captains… people who get the job done. The leadership was not used to that… but they couldn’t say anything when they started seeing the results.”7
The USN takes the same approach with regards to Task Force Hopper and Task Group 59.1.8 TF Hopper exists within the US Surface Fleet to enable rapid AI/ML adoption. This includes enabling access to clean, labeled data and providing the underpinning infrastructure and standards required for generating and hosting AI models. TG 59.1 focuses on the operational deployment of uncrewed systems, teamed with human operators, to bolster maritime security across the Middle East. Unusually, both are led by USN Lieutenants, who the the USN Chief of Naval Operations called ‘…leaders who are ready to take the initiative and to be bold; we’re experimenting with new concepts and tactics.’9
Delegation of Budget Spend and Reverse Mentoring
Across the Single Services, relatively junior individuals, from OR4 to OF3, could be formed on a cross-FLC basis to solve the Defence AI Playbook issues they collectively face, and free to choose which elements of their Workflow to focus on. Importantly, they should deploy Systems Thinking (i.e. an holistic, big picture approach that takes into account the relationship between otherwise discrete elements) to develop a deep understanding of the Workflow in question and prioritize deployment of the fastest, cheapest data analytics method; this will not always be an AI solution. These Guilds would need budgetary approval to spend funds, collected into a single pot from up to three separate UINs from across the Single Services; this could potentially be overseen by an OF5 or one-star. The one-star’s role would be less about providing oversight, and more to do with ensuring funds were released and, vitally, receiving reverse mentoring from the WAG members themselves about the viability and value of deploying AI for that use case.
The RN’s traditional approach to digital and cultural transformation – namely a top-down, directed approach – has benefits, but these are increasingly being rendered ineffective as the pace of technological change increases. Only those working with this technology day-to-day, and using it to solve real-world challenges, will be able to drive the cultural change the RN requires. Currently, much of this work is completed by contractors who take the experience with them when projects close. By deploying this reverse-mentoring approach, WAG’s not only cheaply create a cadre of uniformed, experienced AI practitioners, but also a senior team of Flag Officers who have seen first-hand where AI does (or does not) work and have an understanding of the infrastructure needed to make it happen.
Remote working and collaboration tools mean that teams need not be working from the same bases, vital if different FLCs are to collaborate. These individuals should be empowered to spend multi-year budgets of up to circa. £125k. As of 2024, this is sufficient to allow meaningful Discovery, Alpha, Beta and Live AI project phases to be undertaken; allow the use of COTS products; and small enough to not result in a huge loss if the project (which is spread among all three Services to mitigate risk) fails.
Figure 2: An example AI Figure 2: An example AI Opportunity Mapping exercise, where multiple AI capabilities (represented by colored cards) are mapped onto different stages of an existing workflow, to understand where, if anywhere, use of AI could enable or improve workflow automation. Source: 33A AI.
WAG Workflow Example
An example of how WAGs could work is as follows, using the oil sample contamination example. Members of the RN and RAF Wildcat and Merlin maintenance teams collectively identify the amount of manpower effort that could be saved if the physical checking of lube oil samples could be automated. With an outline knowledge of AI and Systems Thinking already held, WAG members know that full automation of this workflow is not possible; but they have identified one key step in the workflow that could be improved, speeding up the entire workflow of regular helicopter maintenance. The fact that a human still needs to manually check oil samples is not necessarily an issue, as they identify that the ability to quickly prioritize and categorize samples will not cause bottlenecks elsewhere in the workflow and thus provides a return on investment.
Members of the WAG would create a set of User Stories, an informal, general description of the AI benefits and features, written from a users’ perspective. With the advice from the DAIC, NAIC, RAF Rapid Capability Office (RCO) / RAF Digital or Army AI Centre, other members of the team would ensure that data is in a fit state for AI model training. In this use-case, this would involve labeling overall images of contamination, or the individual contaminants within an image, depending on the AI approach to be used (image recognition or object detection, respectively). Again, the use of the Defence Data Analytics Portal (DDAP), or a cheap, third-party licensed product, provides remote access to the tools that enable this. The team now holds a number of advantages over traditional, contractor-led approaches to AI deployment, potentially sufficient to cross the Valley of Death:
They are likely to know colleagues across the three Services facing the same problem, so can check that a solution has not already been developed elsewhere.10
With success metrics, labelled data and user requirements all held, the team has already overcome the key blockers to success, reducing the risk that expensive contractors, if subsequently used, will begin project delivery without these key building blocks in place.
They have a key understanding of how much value will be generated by a successful project, and so can quickly ‘pull the plug’ if insufficient benefits arise. There is also no financial incentive to push on if the approach clearly isn’t working.
Alternatively, they have the best understanding of how much value is derived if the project is successful.
As junior Front-Line operators, they benefit directly from any service improvement, so are not only invested in the project’s success, but can sponsor the need for BaU funding to be released to sustain the project in the long term, if required.
If working with contractors, they can provide immediate user feedback, speeding up development time and enabling a true Agile process to take place. Currently, contractors struggle to access users to close this feedback loop when working with MOD.
Again, Flag Officer sponsorship of such an endeavor is vital. This individual can ensure that proper recognition is awarded to individuals and make deeper connections across FLCs, as required.
Figure 3: Defense Digital’s Defense Data Analytics Portal (DDAP) is tailor-made for small, Front-Line teams to clean and label their data and deploy AI services and products, either standalone or via existing, call-off contract contractor support.
Prioritizing Quick, Hands-on Problem Solving
WAGs provide an incentive for more entrepreneurial, digitally minded individuals to remain in Service, as it creates an outlet for those who wish to learn to code and solve problems quickly, especially if the problems faced are ones they wrestle with daily. A good example of where the RN has successfully harnessed this energy is with Project KRAKEN, the RN’s in-house deployment of the Palantir Foundry platform. Foundry is a low-code way of collecting disparate data from multiple areas, allowing it to be cleaned and presented in a format that speeds up analytical tasks. It also contains a low-level AI capability. Multiple users across the RN have taken it upon themselves to learn Foundry and deploy it to solve their own workflow problems, often in their spare time, with the result that they can get more done, faster than before. With AI tools becoming equally straightforward to use and deploy, the same is possible for a far broader range of applications, provided that cross-TLB resources can be concentrated at a junior level to enable meaningful projects to start.
Figure 4: Pre-existing Data/AI products or APIs, bought from commercial providers, or shared from elsewhere in Government, are likely to provide the fastest, cheapest route to improving workflows.11
Deploying COTS Products Over Tailored Services
Figure 4 shows the two main options available for WAGs when deploying AI or data science capabilities: Products or Services. Products are standalone capabilities created by industry to solve particular problems, usually made available relatively cheaply. Typically, COTS, they are sold on a per-use, or time-period basis, but cannot be easily tailored or refined if the user has a different requirement.
By contrast, Services are akin to a consulting model where a team of AI and Machine Learning engineers build an entirely new, bespoke system. This is much more expensive and slower than deploying a Product but means users should get exactly what they want. Occasionally, once a Service has been created, other users realize they have similar requirements as the original user. At this point, the Service evolves to become a Product. New users can take advantage of the fact that software is essentially free to either replicate or connect with and gain vast economies of scale from the initial Service investment.
WAGs aim to enable these economies of scale; either by leveraging the investment and speed benefits inherent in pre-existing Products or ensuring that the benefits of any home-made Services are replicated across the whole of the MOD, rather than remaining stove-piped or siloed within Single Services.
Commercial/HMG Off the Shelf Product. The most straightforward approach is for WAGs to deploy a pre-existing product, licensed either from a commercial provider, or from another part of the Government that has already built a Product in-house. Examples include the RAF’s in-house Project Drake, which has developed complex Bayesian Hierarchical models to assist with identifying and removing training pipeline bottlenecks; these are Crown IP, presumably available to the RN at little-to-no cost, and their capabilities have been briefed to DAIC (and presumably briefed onwards to the NAIC).
Although straightforward to procure, it may not be possible to deploy COTS products on MOD or Government systems, and so may be restricted up to OFFICIAL or OFFICIAL SENSITIVE only. Clearly, products developed or deployed by other parts of MOD or National Security may go to higher classifications and be accessible from MODNet or higher systems. COTS products are usually available on a pay-as-you-go, monthly, or user basis, usually in the realm of circa £200 per user, per month, providing a fast, risk-free way to understand whether they are valuable enough to keep using longer-term.
Contractor-supported Product. In this scenario, deployment is more complex; for example, the product needs to deploy onto MOD infrastructure to allow sensitive data to be accessed. In this case, some expense is required, but as pre-existing COTS, the product should be relatively cheap to deploy as most of the investment has already been made by the supplier. This option should allow use up to SECRET but, again, users are limited to those use-cases offered by the commercial market. These are likely to be focused on improving maintenance and the analysis of written or financial information. The DAIC’s upcoming ‘LLMs for MOD’ project is likely to be an example of a Contractor-supported Product; MOD users will be able to apply for API access to different Large Language Model (LLM) products, hosted on MOD infrastructure, to solve their use-cases. Contractors will process underlying data to allow LLMs to access it, create the API, and provide ongoing API connectivity support.
Service built in-house. If no product exists, then there is an opportunity to build a low-code solution in DDAP or MODCloud and make it accessible through an internal app. Some contractor support may be required, particularly to provide unique expertise the team cannot provide themselves (noting that all three Services may have Digital expertise available via upcoming specialist Reserve branches, with specialist individuals available at a fraction of the cost of their civilian equivalent day rates).12 Defense Digital’s ‘Enhanced Data Teams’ service provides a call-off option for contractors to do precisely this for a short period of time. It is likely that these will not, initially, deploy sophisticated data analysis or AI techniques, but sufficient value may be created with basic data analytics. In any event, the lessons learnt from building a small, relatively unsophisticated in-house service will provide sufficient evidence to ascertain whether a full, contractor-built AI service will provide value for money, if built. Project Kraken is a good example of this; while Foundry is itself a product and bought under license, it is hosted in MOD systems and allows RN personnel to build their own data services within it.
Service built by contractors. These problems are so complex, or unique to Defense, that no COTS product exists. Additionally, the degree of work is so demanding that Service Personnel could not undertake this work themselves. In this case, WAGs should not be deployed. Instead, these £100k+ programs should remain the purview of Defense Digital or the DAIC and aim to instead provide AI Building Blocks that empower WAGs to do AI work. In many cases, these large service programs provide cheap, reproducible products that the rest of Defense can leverage. For example, the ‘LLMs for MOD’ Service will result in relatively cheap API Products, as explained above. Additionally, the British Army is currently tendering for an AI-enabled system that can read the multiple hand-and-type-written text within the Army archives. This negates the need for human researchers to spend days searching for legally required records that can now be found in seconds. Once complete, this system could offer itself as a Product that can ingest complex documents from the rest of the MOD at relatively low cost. This should negate the need for the RN to pay their own 7-figure sums to create standalone archive scanning services. To enable this kind of economy of scale, NAIC could act as a liaison with these wider organizations. Equipped with a ‘shopping list’ of RN use cases, it could quickly deploy tools purchased by the Army, RAF or Defense Digital across the RN.
Finding the Time
How can WAG members find the time to do the above? By delegating budget control down to the lowest level, and focusing predominantly on buying COTS products, the amount of time required should be relatively minimal; in essence, it should take the same amount of time as buying something online. Some work will be required to understand user stories and workflow design, but much of this will already be in the heads of WAG members. Imminent widespread MOD LLM adoption should, in theory, imminently reduce the amount of time spent across Defense on complex, routine written work (reviewing reports, personnel appraisals, post-exercise or deployment reports or other regular reporting).13 This time could be used to enable WAGs to do their work. Indeed, identifying where best to deploy LLMs across workflows are likely to be the first roles of WAGs, as soon as the ‘LLMs for MOD’ program reaches IOC. Counter-intuitively, by restricting the amount of time available to do this work, it automatically focuses attention on solutions that are clearly valuable; solutions that save no time are, by default, less likely to be worked on, or have money spent on them.
Conclusions
The RN runs the risk of spreading the NAIC’s budget too thinly, in its attempt to ‘jumpstart’ use of AI across Business as Usual disciplines. By contrast, users should be encouraged to form Workflow Automation Guilds across FLCs. Supported by a senior sponsor, knowledgeable members of the Reserves, the NAIC and one-on-one time with the DAIC, WAGs could instead focus on the COTS solution, or pre-existing Crown IP, that will best solve their problem. Budget responsibilities should be delegated down too, thereby enabling access to existing, centralized pools of support, such as the Enhanced Data Teams program, DDAP, or the upcoming ‘LLMs for MOD’ API Service. In this way, projects are more likely to succeed, as they will have demonstrated value from the very start and will have been co-developed by the very users that deploy them. The speed at which AI and data services are becoming easier to use is reflected by the RN’s Kraken team, while the need to trust low-level officers and junior rates is borne out by the success currently being enjoyed by both the USAF and USN with their own complex AI deployments.
Prior to leaving full-time service, Lieutenant Commander Francis Heritage, Royal Navy Reserve, was a Principal Warfare Officer and Fighter Controller. Currently an RNR GW officer, he works at the Defence arm of Faculty, the UK’s largest independent AI company. LtCdr Francis is now deployed augmenting Commander United Kingdom Strike Force (CSF).
The views expressed in this paper are the author’s, and do not necessarily represent the official views of the MOD, the Royal Navy, RNSSC, or any other institution.
References
1. Discovery’ is the first of 5 stages in the UK Government Agile Project Delivery framework, and is followed by Alpha, Beta, Live and Retirement. Each stage is designed to allow the overall program to ‘fail fast’ if it is discovered that benefits will not deliver sufficient value.
2. Author’s observations.
3. Volvo and the US commodities group Bureau Veritas both have Commercial off the Shelf products available for solving this particular problem.
6. AI systems rely on machine learning frameworks and libraries; Docker packages these components together into reproducible ‘containers’, simplifying deployment. Kubernetes builds on Docker, providing an orchestration layer for automating deployment and management of containers over many machines.
10. The author knows of at least 3 AI projects across MOD aimed at automating operational planning and another 3 aiming to automate satellite imagery analysis.
11. API stands for Application Programming Interface, a documented way for software to communicate with other software. By purchasing access to an API (usually on a ‘per call’ or unlimited basis) a user can take information delivered by an API and combine it with other information before presenting it to a user. Examples include open-source intelligence, commercial satellite imagery, meteorological data, etc.
12. Army Reserve Special Group Information Service, RNR Information Exploitation Branch and RAF Digital Reserves Consultancy. RNR IX and RAFDRC are both TBC.
