Ask a subsurface team why their model runs on a rack in their own building rather than on a rented cloud instance, and the first answer you get will be about latency, or about a procurement framework, or about a card that costs a certain number of euros a month. Those answers are all true and all secondary. The real reason sits one level beneath them, and it is not an engineering reason at all. It is that the data the model reads is considered too sensitive to leave the firewall, and once you accept that constraint as fixed, every downstream choice about how to serve the model is forced. The deployment decision is made before any deployment engineering begins, by people who never look at a GPU price list, on the basis of where a corpus of well logs is legally and commercially allowed to sit.
This post is about that ordering. It argues that for subsurface vision models the question of cloud versus on-premises is decided by data gravity first and economics second, walks through why that is, and then does the part that the sovereignty enthusiasts usually skip: it counts what the firewall costs you in serving design once you have committed to it. The work this comes out of involved building a raster-log digitiser, which we call VeerNet, and the serving constraints below are the ones that shaped how it could be deployed. The wider survey of energy AI, and the public archives that make any of this concrete, belong to the field and we credit them as we go.
The corpus is heavy, and heavy things do not move
Start with the object everyone is trying to avoid naming, because the whole argument rests on it. A subsurface operator's competitive memory is its data: the seismic, the production history, and above all the well logs that record what the rock actually did. The single largest public illustration of the scale involved is a national regulator's archive, where the records sit as 136,771 scanned raster log files against only 7,781 digital files. That is the open version. A working operator's private holdings are the same shape, the same mix of pictures of paper and a thinner seam of machine-readable curves, and they are the asset the company exists to exploit.
Data of that kind has gravity. The phrase is worth taking literally: a corpus this large and this valuable exerts a pull on every system that wants to touch it, and the cheapest place to put compute is next to the data rather than the other way around. To serve a model in the cloud, you do not ship the model to the data; you ship the data to the model. For a hundred and thirty-six thousand scanned logs plus the private holdings that dwarf the public set, that is not a one-time upload you forget about. It is a standing decision to keep a copy of the company's crown jewels on infrastructure the company does not own, governed by a contract the company did not write.
Where the compute goes is decided by where the data is allowed to be
A model is small and portable; a subsurface archive is enormous and legally encumbered. So the rational move is to bring the compute to the corpus, not the corpus to the compute. Cloud serving inverts that: it requires the heavy, sensitive thing to cross a boundary it was kept inside on purpose. The sovereignty objection is therefore not paranoia about a breach. It is a refusal to relocate the asset at all.
Sovereignty is the constraint that does not have a price
Here is the move that the cost-comparison framing gets wrong. It treats sovereignty and compute as two terms in the same sum, as if enough of a discount on cloud GPUs could eventually outweigh the discomfort of moving the data. They are not in the same sum. One is a number that scales with your fleet size, and the other is a property of where the data sits that does not scale with anything you can buy.
Consider the compute side honestly first, because it is real. Serving a heavy vision model is not free. On the rates that framed our own deployment planning, a high-end serving GPU runs about 750 euros a month and a more advanced card about 1800 euros a month, and a serving fleet is some multiple of those. That bill is genuine, and on a pure compute basis a hyperscaler can often match or beat it, because amortising hardware across thousands of tenants is exactly what hyperscalers are good at. If the decision were only about euros per teraflop, cloud would frequently win.
But the sovereignty side has no euros-per-teraflop. Whether the well-log archive stays inside the firewall is not cheaper or more expensive at three GPUs than at twelve; it is the same yes-or-no regardless of how much compute you rent. Residency, egress exposure, auditability, and who holds the processing contract do not move when the fleet grows. That is the asymmetry the instrument below is built to make visible. Drag the fleet up and down, switch between the high-end and advanced cards, and watch the monthly bill swing while the sovereignty score sits perfectly still. The bill is the variable you are tempted to optimise. The constant beside it is the thing that actually decides the question.
The survey literature of the period reached the same conclusion from the top down rather than the bottom up. A wide review of upstream oil and gas AI singled out the confidentiality of operator data as a first-order obstacle to adoption, on the same footing as model accuracy and talent [1], which is to say the field already understood that the binding constraint on deploying these systems was not whether the model worked but whether the data could be exposed to it in the first place. When the most cited barrier in your domain is governance rather than gradients, the deployment target stops being an engineering preference.
What a model has to read before it can predict anything
There is a tempting escape hatch here that deserves to be closed, because people reach for it constantly. Why not keep the raw archive on-premises and only send the model a sanitised, derived feature set to the cloud? Move the small thing, not the big thing.
The escape hatch does not open for this class of model, and the reason is specific to what subsurface vision actually consumes. The whole point of a raster-log digitiser is that its input is the scanned image itself, ink on paper photographed into a grayscale file. There is no smaller, safer intermediate to send, because the image is the input. You cannot extract the curve before serving the model; extracting the curve is what the model does. The classical, non-learning approaches to the same problem make this vivid: a gridlines-elimination method for digitising well-log graphs still has to operate on the full raster of the log to recover anything at all [2], so whether you use a learned segmenter or a morphological pipeline, the thing on the table is the picture, in full, and the picture is the sensitive artifact.
The same trap closes around the downstream analytics, only later. Applied energy-AI work that predicts something useful, say the long-term viability of a storage project, draws its accuracy directly from operator-held records and would be worth very little without them [3]. So even past digitisation, the value chain keeps demanding the confidential corpus as input. There is no point along it where you get to hand the cloud a harmless summary and keep the secret at home. The secret is the input at every stage.
“For a raster-log model the input is the scanned log, not a derived feature, so there is no sanitised version to ship out. The image is both the sensitive asset and the thing the model must read, which is why the model has to come to the image.
”
The bill the firewall sends you
It would be dishonest to stop at the case for staying on-premises without counting what it costs, because it costs plenty, and pretending otherwise is how teams end up resenting the constraint they chose. Sovereignty is not free; it is paid for in serving engineering, and the invoice arrives in four parts.
The first is elasticity. A cloud serving stack can absorb a sudden batch of a hundred thousand logs by spinning up capacity for an afternoon and releasing it. An on-premises fleet is sized to a fixed number of cards, so a large reprocessing job either waits in a queue or sits against hardware you bought for the peak and idle for the trough. You trade pay-as-you-go for capital you own whether you use it or not.
The second is operations. When the model serves in your own rack, you are the platform team. Driver versions, card failures, power and cooling, the unglamorous on-call that a managed endpoint quietly handles, all of it is now yours. The 750-euro and 1800-euro figures are the rental sticker, but on-premises the equivalent cost includes the people who keep the rack alive, and that line does not appear on any GPU price list.
The third is iteration speed. Cloud teams reach for the newest accelerator the week it ships. An on-premises fleet is the generation you bought, for as long as the depreciation schedule says, so your serving hardware ages in place while the frontier moves. You decoupled yourself from the hyperscaler's roadmap, which was the point, and the price of that independence is that you no longer ride its upgrades for free.
The fourth is the most easily forgotten: you have to design the serving path yourself, end to end, with no managed autoscaler to hide behind. Batch sizing, memory budgeting for variable-width inputs, the alignment rules the architecture imposes, all of it has to be solved on hardware whose limits you cannot wave away by renting more. Building VeerNet to serve inside that envelope meant the serving design was constrained by the rack from the first commit, not adapted to it afterward.
The order that actually holds
Put the two halves together and the shape of the decision is clear, and it is the reverse of how it is usually presented. The cloud-versus-on-premises debate is staged as an economics problem with a sovereignty asterisk. For subsurface models it is a sovereignty problem with an economics asterisk. The data gravity of a hundred-thousand-file archive and the confidentiality rules wrapped around it settle the location first, the model is then engineered to live wherever the data is allowed to be, and only after both of those are fixed does anyone open the GPU price list to size the fleet they have already decided to own.
What we keep relearning on this work is that the firewall is not an obstacle the engineering has to route around; it is a premise the engineering is built on, and the teams that thrive under it are the ones who stop arguing with the premise and start designing for it. The operators who deploy these models well are not the ones who found a clever way to move the corpus to cheaper compute. They are the ones who accepted that the corpus does not move, sized a fleet they own, and paid the elasticity and operations bill with their eyes open. Treating sovereignty as the fixed point and compute as the variable, rather than the other way round, is the orientation that makes the whole deployment make sense, and the one most cost comparisons quietly get backwards.
Key takeaways
- For subsurface vision models the cloud-versus-on-premises choice is settled by data gravity and confidentiality first and by compute economics second. A national archive of 136,771 scanned raster logs against 7,781 digital files shows the scale of the corpus an operator will not let cross its firewall, and a private operator's holdings have the same shape.
- Sovereignty and compute are not terms in the same sum. Monthly compute scales with fleet size (around 750 euros per high-end GPU and 1800 euros per advanced GPU), but residency, egress exposure, auditability, and contract control do not change when the fleet grows, so no compute discount buys the sovereignty back.
- There is no sanitised intermediate to send to the cloud. A raster-log digitiser reads the scanned image itself as input, so the sensitive artifact and the model's input are the same thing, and the model must come to the data rather than the data to the model.
- Staying on-premises is not free. It is paid for in four ways: lost elasticity for burst reprocessing, an in-house platform and on-call burden, serving hardware that ages in place while the frontier moves, and a serving path you must engineer end to end with no managed autoscaler.
- The decision order is the reverse of how it is usually framed: location is fixed by sovereignty, the model is engineered to live where the data is allowed to be, and only then is the owned fleet sized. Treating sovereignty as the constant and compute as the variable is what makes the deployment coherent.
References
[1] Koroteev, D., and Tekic, Z. Artificial intelligence in oil and gas upstream: Trends, challenges, and scenarios for the future. Energy and AI (2021). A survey of upstream AI that names data confidentiality and the proprietary nature of subsurface records as a first-order barrier to adoption. https://www.sciencedirect.com/science/article/pii/S2666546821000124
[2] Yuan, B., and Yang, Q. Digitization of Well-Logging Parameter Graphs Based on Gridlines-Elimination Approach. Journal of Petroleum Exploration and Production Technology (2019). A non-learning method for turning scanned raster log graphs into numeric curves, operating on the full raster of the log. https://doi.org/10.1007/s13202-019-0625-x
[3] Buah, E., Linnanen, L., Wu, H., and Kesse, M. A. Can Artificial Intelligence Assist Project Developers in Long-Term Management of Energy Projects? The Case of CO2 Capture and Storage. Energies, 13(23), 6259 (2020). An applied energy-AI study whose accuracy depends on access to operator-held project data. https://www.mdpi.com/1996-1073/13/23/6259
