Build AI fast, then own it smart

A few days ago my long-awaited Nvidia DGX Spark “mini AI supercomputer” finally arrived.

As I’ve written before, I’m planning to bring (some of) my AI workers back to the office. But so far, the Spark – which hit my desk with a couple months of delay – hasn’t been plugged in. Not because I don’t know what to do with it, but because I’ve been traveling so much I simply haven’t had a chance to set it up. And that’s fine. Because I already know exactly what I’ll run on it once I plug it in.

In fact, that’s what this newsletter is really about.

Let’s dive in!

The new gravity of AI

We’ve all grown used to the idea that AI lives in the cloud. You want to build something smart? You call an API. Your embeddings, inference, and fine-tuning models? All somewhere, far far away, in a galaxy of somebody else.

That model works brilliantly for quick experimentation. It’s why a single person can prototype an AI product over a weekend. But as more teams move beyond “let’s test an idea” and into scaling AI into production the gravity starts to shift.

Because building in the cloud and owning in the cloud are two very different things.

“Sovereign AI”

People love throwing around the words Offline AI and Sovereign AI (me included). Most assume they’re about performance – lower latency, faster inference, higher accuracy.

But that’s not really the story. The story is ownership and control. Who controls the data, the infrastructure, and the models your AI solution depends on? Who really owns the outcomes and value your system creates?

That’s what “sovereign” means: being able to keep the core of your intelligence – your models, your logic, your workflows – under your own roof when it actually matters.

Why I’m taking my AI offline

My expectation for buying a DGX Spark (or whatever other supercomputer) is not to create a local ChatGPT clone that runs better than OpenAI. If you need big “brain power”, and a bunch of sleek features, you’ll always find more of it in the cloud. The largest models simply don’t fit on a single machine and the best user features are often built when they’re built at scale.

But many real-world use cases don’t need the newest 5-trillion parameter model or the ability to share a custom GPT with your colleagues. They need consistency, cost control, and often: privacy.

This affects especially those use cases that sit on the right side of the Integration-Automation Matrix:

Speaking of which, here are a few of the use cases I’m personally most excited to explore once I power mine on:

• Document Value Extraction: run OCR, field extraction, and validation entirely locally without paying for every single API call.

• Offline Data Analysis: analyze internal datasets that are too sensitive to upload — think financial ledgers, internal performance reports, or customer feedback.

• Private Meeting Transcripts: transcribe, summarize, and index internal meetings without sending a word outside the company network.

• Undisclosable company files: especially in regulated industries like healthcare and finance where exposing data to a 3rd party can have severe consequences.

If we zoom out, there are really 3 main reasons why it makes sense for “going local”:

• Cost that switch from mainly operating expenses (OPEX) to mainly capital expenditures (CAPEX) and are therefore easier to budget and plan.

• Data security that follows your defined governance process and standards.

• Resilience – which is the ability to keep working even when APIs, prices, or policies change. (Especially in AI where you never really know what drama will unfold next in San Francisco.)

Build it fast. Then own it smart.

Thanks to out-of-the box systems like the Spark (or you could even get a maxed-out Mac Mini Studio if you prefer), getting the necessary hardware for running AI models locally is getting both more affordable and less complicated. But still, setting up a local AI environment is much harder than signing up for a service where you put in your email with a credit card, click a few buttons and you’re all set.

That’s why offline typically, isn’t where you start.
It’s where you arrive once you’ve proven the value.

Too many teams begin by over-engineering. They spend months talking about GPUs, infrastructure, and deployment – before ever validating that the workflow actually helps anyone. Worst case it can be a form of procrastination.

That’s backwards.
The better pattern is:
build fast in the cloud, validate, and then bring it home.

Because Local AI doesn’t magically make your solutions better.
It just makes it yours.

And you can still do that with data-critical use cases:

• Try a financial statement that’s already public

• Use fake data for patient records

• Ask explicitly for permission

The bridge between online and local AI

The trick is to not throw everything away that you had built during the discovery phase in the cloud. This would not only be foolish, but also pretty much doomed to failure. As I explained in my AI Gardener mindset article, the idea is to build and develop a solution iteratively over time. Not to build something somewhere, and then try to migrate it to another ecosystem.

And that’s in fact where technology can help. Because if you choose an AI tool stack that can bridge both online and offline worlds, you’ll make your life 10x easier.

That’s where tools like n8n come in for me. They make this transition surprisingly simple. You can design an entire workflow online – connecting APIs, models, and data sources – then deploy the exact same thing locally once you know it delivers value.

Prototype in the cloud.
Deploy in your office.
Own your destiny.

Prototype → Product → Property

So yes, my Spark is still sitting in the box. That’s because I’ve barely been home. But I heard my clients. They don’t just want AI. They want profitability and ownership.

So bringing AI back into the office isn’t about nostalgia for servers. It’s about building resilience and cost-control in phase of high uncertainty. Knowing that your business logic can keep running even if the world outside cuts you from their APIs or your cloud provider updates their pricing overnight.

(What sets AI workloads here apart from other cloud services like CPU and storage, is that GPU workloads – no matter how well they are abstracted – indeed cost a ton of money to run at scale for cloud providers.)

The real sequence therefore is like this:

• First you build and test fast. Prove value.

• Then you refine and scale. See what drives the needle (cost and returns)

• Finally, you make it your property — something that lives inside your walls, runs on your terms, and continues to work long after the hype cycle moves on.

I’ll be sharing more about those use cases — document extraction, offline analytics, private transcription — in upcoming posts once the Spark is running.

For now, the philosophy stays simple:
Build it fast. Then own it smart.

See you next Friday,
Tobias