Where your data actually goes
When a developer or a team uses coding agents, a surprising amount travels with every request: the instructions given to the agent, file contents and code changes. In client work these are almost all the client's material, or even the client's client's.
The agent reaches the model over an API, so all of that content is sent there. Most often the API is American, OpenAI or Anthropic, which puts the material under United States law.
A European data centre does not on its own settle this. The US CLOUD Act reaches data held by American companies regardless of where the server physically sits, so it covers those companies' European cloud services too. That does not make them unusable, but it is worth being aware of.
In client work the requirements vary from one contract to the next, and the strictest of them require the code to stay in the EU. Rather than build a separate answer for each client, it is simpler to build one that satisfies the strictest requirement.
We rent the server from a data centre that operates under Finnish and EU law. The material does not leave our own environment, and how it is handled does not depend on what a provider's terms of service happen to say. Performance is more than enough for a team our size.
We know which electricity our tokens are made of
As a Green ICT company, it matters to us that we understand and keep track of the environmental load our own work creates. Because we run the model on our own server, we can see directly how much electricity we have used, and calculate the CO₂ load from that.
Our GPU sits in UpCloud's Helsinki data centre. The facility runs on renewable energy, and its waste heat is captured into the district heating network that serves roughly 28,000 homes. The Finnish grid it draws from carries about 54 grams of CO₂ per kilowatt hour on a lifecycle basis. The facility's power usage effectiveness is around 1.2, meaning cooling and overheads add roughly 20% on top of what the hardware itself consumes.
In practice the card draws about 124 W when a model is loaded but idle, 192–229 W under normal working load, and peaks near 330 W during sustained heavy use. Its datasheet rating is 700 W, which we have never approached. Converted using the grid and efficiency figures above, our AI infrastructure produces somewhere between 2.7 and 4.6 kg of CO₂ per month at current usage.
These emissions are estimated, not measured. We hold grid intensity and data centre efficiency constant, and in reality both vary hour to hour. The power draw is measured directly; the carbon figure derived from it is not.
On a commercial API we would not have these numbers at all. A provider's sustainability report covers the whole company, not what our own use consumed. On our own server the figure describes our work, not somebody else's average.
What running your own machine does not get you
Running your own GPU is not more efficient per token than the large cloud providers, to put it plainly.
Frontier providers fill their accelerators so that per-token efficiency is at its maximum. They batch thousands of requests into the same run and keep the hardware close to full utilisation. You cannot reach that by running one machine, nor with two or three. We run ours during business hours for one team, so waste is unavoidable: even idling, the card draws 124 watts.
But per-token efficiency is not what we are after here. If it were the metric, the sensible answer would be to buy capacity from a large provider. What we are after is knowing where the data is and where the electricity comes from, and a per-token figure answers neither question.
Compliance and sustainability as a byproduct
Almost every reporting obligation gets easier when you can point at the machine and say where the data goes, what happens to it there, and what telemetry is not collected or passed on. Questions about personal data transfers become straightforward. The documentation the EU AI Act requires has a clear subject. CSRD reporting on your own energy use rests on real measurements instead of suppliers' averages.
We did this because we wanted to know where our customers' code goes and where our electricity comes from, and everything else followed from those two answers.
At Trail Openers we help organisations design AI infrastructure that meets their responsibility and compliance requirements without guesswork. Want to work out what your own AI workloads would look like under your own control? Get in touch and we will map it out together.