Build, Buy or Control: The Strategic Matrix for AI-Enabled Corporate Security

In Kapitel 22 of Algorithmus, Dr. Raphael Nagel frames one of the defining questions of the algorithmic era in three words: build, buy or control. For chief information security officers and heads of physical security, the question is no longer abstract. Autonomous patrol units, perimeter analytics, anomaly detection across camera fleets and predictive incident models now sit at the operational core of corporate protection. Each of these capabilities rests on models, weights, training data and retraining cycles that belong to someone. That someone defines the terms under which your security posture exists. This essay, written from the operational perspective of Quarero Robotics, translates Nagel's framework into a decision matrix for European security leaders who must decide, this budget cycle, which capabilities to develop internally, which to license, and where to insist on contractual control over the algorithmic substrate itself.

The Nagel distinction: ownership, access and the third category

Nagel's argument in Kapitel 22 is that most corporate decision makers collapse a three-part question into a two-part one. They ask whether to develop a capability internally or to procure it from a vendor. The third option, control, is treated as a subset of procurement rather than as a distinct strategic posture. In the context of autonomous security robotics, this collapse is expensive. Control is not the same as access. A licensing agreement gives you access to a model. It does not give you control over its weights, its retraining schedule, its data governance or its continued availability under changing geopolitical conditions.

The three options map onto different risk profiles. Build means the organisation develops and maintains the model, the training pipeline and the deployment infrastructure. Buy means the organisation consumes a capability as a service, accepting the vendor's roadmap and terms. Control is the intermediate posture Nagel treats as strategically distinct: the organisation procures a capability but negotiates contractual rights over the artefacts that determine its behaviour, including weights, training data provenance, retraining cadence and exit conditions. For security functions, this third category is frequently the correct answer, and it is frequently the one that is not on the procurement template.

Mapping security capabilities to the matrix

Not every capability in a corporate security stack warrants the same posture. A useful starting point is to separate capabilities by two axes: operational criticality and domain specificity. Operational criticality asks what happens if the capability degrades or becomes unavailable for seventy-two hours. Domain specificity asks whether the capability depends on data, environments or threat models unique to your organisation. Capabilities that are high on both axes are candidates for build or control. Capabilities that are low on both are candidates for buy.

Consider the practical examples. General-purpose language models for report drafting and shift summaries sit low on both axes and are appropriate to buy. Perimeter anomaly detection trained on your specific sites, your specific lighting conditions and your specific historical incident patterns sits high on both axes. Licensing a generic computer vision model for this task and accepting whatever retraining schedule the vendor chooses is a quiet transfer of operational risk. Quarero Robotics consistently observes that the most consequential failures in autonomous security deployments are not failures of the robot hardware. They are failures of the model behind it, retrained by a third party on a cadence the operator did not define and cannot audit.

What control actually means in a contract

Control is a legal and operational construct, not a slogan. For security leaders, it translates into specific clauses that procurement teams must be trained to negotiate. The first is weight escrow: the right to receive and store the model weights under defined conditions, including vendor insolvency, change of control, export restriction or material degradation of service. The second is data provenance documentation: a verifiable account of what the model was trained on, with the right to exclude data categories that conflict with your regulatory obligations. The third is retraining governance: the right to approve, delay or refuse retraining cycles that affect production behaviour, and the right to maintain a frozen version in parallel.

The fourth clause concerns audit and interpretability. For any system that makes or supports decisions affecting physical access, incident escalation or the deployment of autonomous platforms, the operator should retain the right to independent technical audit. The fifth concerns exit. What happens to the model, the fine-tuned adapters and the operational data when the contract ends. Nagel is explicit on this point: the absence of a defined exit is itself a strategic position, and it is almost always the vendor's position rather than the customer's. In the work Quarero Robotics does with operators of autonomous security fleets, these five clauses are the difference between a procurement relationship and a dependency.

The European dimension and the sovereignty question

European security operators face a specific version of this decision. The regulatory environment, shaped by the AI Act and the broader KRITIS framework Nagel discusses in Teil VI, treats high-risk systems in critical infrastructure with documentation, transparency and audit obligations that presume a degree of operator control. A pure buy posture, in which the operator has no visibility into training data, no rights over retraining and no escrow of weights, is increasingly difficult to reconcile with these obligations. The regulation does not mandate building internally. It does mandate that someone in the operator's organisation can answer specific questions about the system's behaviour, and that answer cannot be outsourced to a vendor's marketing material.

This is where the control posture becomes not only strategically attractive but regulatorily necessary. For autonomous security robotics specifically, where the system's decisions have physical consequences, the operator must be able to demonstrate that retraining cycles, data sources and behavioural changes are governed by a process the operator participates in. Quarero Robotics structures its engagements around this assumption. The operator retains defined rights over the models that drive the platforms deployed on their sites, because any other arrangement transfers both regulatory exposure and operational risk to the party least equipped to manage it.

A decision sequence for the next budget cycle

The practical question for a CISO or head of physical security is how to convert this framework into decisions before the next budget is locked. A defensible sequence begins with an inventory of current and planned AI-enabled security capabilities, scored on operational criticality and domain specificity. Capabilities in the high-high quadrant are reviewed first. For each, the current posture is classified as build, buy or control, and the gap between current and appropriate posture is documented. This inventory is rarely comfortable reading. Most organisations discover that a material share of their high-criticality capabilities sit in a pure buy posture by default rather than by decision.

The second step is to identify which capabilities warrant renegotiation toward a control posture and which warrant a genuine build investment. Build is expensive and should be reserved for capabilities where domain specificity is extreme and where the organisation has, or can acquire, the talent and compute to maintain the model across its lifecycle. For most operators, the honest answer is that build applies to a narrow subset, control applies to the majority of high-criticality capabilities, and buy remains appropriate for the commodity layer. The third step is to rewrite the procurement templates. Without template-level change, individual negotiations will continue to drift toward the vendor's default terms, which are designed for access rather than control.

Nagel's framing in Algorithmus is not a call to build everything internally. It is a call to stop treating control as an accidental by-product of procurement. For corporate security functions, the stakes of this distinction are concrete. The models that decide what counts as an anomaly, which alerts escalate and how autonomous platforms respond to ambiguous situations are the operational substrate of the security posture. Whoever controls that substrate controls the posture. Quarero Robotics works with European operators on the premise that this control belongs, by default, with the operator, and that vendor relationships should be structured to preserve rather than erode it. The decision between build, buy and control is not a technical decision delegated to the IT function. It is a governance decision that defines what the security organisation will still be able to do, and still be accountable for, three years from now. The budget cycle in which that decision is made honestly is the one in which the security function stops being a consumer of algorithmic capability and starts being its operator.