Dark Harvest

Knowledge as code

2026-04-12T00:00:00+00:00

You already know how this goes.

New tool shows up. Everyone gets excited. Teams adopt it. Projects fail. The tool gets blamed. Someone writes the “Why We Abandoned X” post. A newer tool shows up. Back to the top of the script.

Microservices were going to fix the monolith. Then microservices became the problem. Kubernetes was going to fix the infrastructure. Then Kubernetes became the infrastructure. AI is going to fix the productivity problem. And three years from now, someone will write a blog post titled “Why We Abandoned AI” that describes the exact same failure pattern: good tools, applied without understanding, to problems they were never designed to solve.

The tool is not the problem. It never was. The problem is that the knowledge of how to use a tool well, when to apply it, when to walk away, what trade-offs you’re signing up for, what mistakes the last ten teams already made, lives in the wrong places. In the heads of senior engineers who leave. In Slack threads that expire. In post-mortems nobody reads. In consultancy reports that cost six figures and gather dust.

We need knowledge management that works like code. Versioned. Reviewed. Executable. Open. Alive.

01. Problems</h2>
The analysis
The blame cycle</h3>
The pattern is so consistent you could script it.
Phase one: a technology gains momentum. Conference talks. Vendors. Job postings. Phase two: teams adopt it without understanding the preconditions for success. Phase three: projects struggle, not because the technology is bad, but because it got applied to the wrong problem, at the wrong scale, by people who didn’t have the context to use it right. Phase four: blame the tool. Phase five: a new tool shows up. Restart.
Docker did not fail anyone. Teams that containerised stateful applications without thinking about data persistence failed themselves. Kubernetes did not make operations harder. Teams that reached for it to orchestrate three services, when a systemd unit file would have done the job, made operations harder. Microservices did not create distributed system nightmares. Teams that split a monolith into two hundred services without understanding what a microservice actually is, where its boundaries belong, what it costs to run, what distributed systems demand in return, made those nightmares themselves.
The tool is seldom the root cause. The absence of knowledge about how to use the tool is the root cause. And that knowledge exists. It’s just not in the room when the decision gets made.
Knowledge trapped in heads</h3>
The most valuable technical knowledge in any organisation lives in the heads of maybe five to ten people.
They know which architectural decisions were made, and why. They know which vendor promises turned out to be lies. They know the three things you must never do with the payment system on a Friday. They know that the auth service works because of a bug that everyone has agreed to pretend is a feature.
Then they leave. They always leave.
When they go, the knowledge walks out with them. The organisation keeps the code. Loses the reasoning. Inherits the system. Does not inherit the judgement that built it.
The documentation graveyard</h3>
Most organisations have documentation.
It is out of date. Scattered across four platforms. Written in a style that assumes context the reader does not have. Maintained by no one. Wikis rot. Confluence pages become archaeology. READMEs describe systems that have not existed in years.
The problem is not that people don’t write documentation. The problem is that documentation is treated as a one-time artefact instead of a living system. Nobody reviews it. Nobody revises it. Nobody owns it. It is the first thing written and the first thing forgotten.
Best practices without context</h3>
The internet is full of best practices. Most of them are harmful.
“Always use microservices.” A best practice. “Always write unit tests.” A best practice. “Always use a message queue.” A best practice. None of them are true. Not without context. What is your scale? Your team size? Your deployment cadence? The cost of failure? A best practice with no stated context is just a popular opinion with better marketing.
And yet teams keep citing them, in design docs, in architecture reviews, in interviews, as if the label alone carried authority. It doesn’t. A best practice that worked at Netflix in 2018 is not a best practice for your three-engineer team in 2026. It is a historical note.

We do not have a tooling problem. We have a memory problem. The industry keeps learning the same lessons and forgetting them on a three-year cycle. </blockquote>
What policy-makers must do
Stop funding technology adoption. Start funding technology understanding. Every public sector digital programme should allocate a minimum percentage of its budget to knowledge capture: architectural decision records, post-mortems, pattern libraries, context-rich documentation. If the knowledge cannot survive the team that made it, the investment is temporary.
Require decision records on public projects. Every significant technology choice on a publicly funded project should be documented. What was decided. What alternatives were considered. Why this option was chosen. What would trigger a reversal. This is not bureaucracy. It is institutional learning. The thing every public institution claims to want and almost none of them fund.
Fund open knowledge commons for the public sector. A shared, searchable, version-controlled record of technical decisions, patterns, and anti-patterns from government IT projects. Across municipalities. Across agencies. Across nations. The same mistake made in Stockholm and in Rotterdam is a mistake that should have been made only once.
Speaking partners</h3>
Government digital service agencies (GDS, 18F, DIGG in Sweden). ThoughtWorks and similar practice-led consultancies willing to open-source their methodology. The InnerSource Commons. Maintainers of open documentation frameworks (Docusaurus, MkDocs, Backstage). And, most of all, the senior engineers and architects already inside government who maintain informal knowledge networks despite every incentive to keep their heads down.
What individuals & companies can do
Write decision records. Not just documentation. Every time your team makes a significant technical choice, write an ADR: the context, the decision, the consequences. Fifteen minutes. In two years, when someone asks “why did we use Kafka here?”, the answer exists. And it is not “because Dave thought it was cool, and Dave left.”
Stop blaming the last tool. Before your team walks away from a technology, ask the three questions. Did we understand the preconditions for its success? Did we have the skills to use it correctly? Did we apply it to the right problem? If the answer to any of those is no, the next tool will fail for the exact same reason. You will just get to rename the failure.
Build a failure library. Document not just what worked but what didn’t, and why. Make it searchable. Make it part of onboarding. The most valuable knowledge in any organisation is the list of things that have already been tried and have already failed.

02. Solutions</h2>
The analysis
Knowledge as code</h3>
The software industry solved the problem of collaborative, versioned, reviewable work product decades ago. It is called version control.
Code is written. Reviewed by peers. Merged. Versioned. Tested. Deployed. If it breaks, you revert. If it is wrong, someone submits a correction. If it is outdated, the diff shows when it changed and who changed it.
Knowledge about technology decisions should work the same way. Not wiki pages anyone can edit and no one reviews. Not PDFs that are correct the day they ship and wrong the day after. Living documents in version-controlled repositories. Subject to pull requests. Subject to peer review. Subject to continuous integration. When a best practice changes, the change is tracked. When a pattern is deprecated, it is marked, not deleted, so the reasoning survives.
Contextual pattern libraries</h3>
A pattern library is not a list of best practices.
It is a collection of solutions, each annotated with the problem it solves, the context in which it works, the context in which it fails, the trade-offs it introduces, and real examples of both success and failure.
“Use event sourcing” is not a pattern. “Use event sourcing when you need a complete audit trail, when your team has distributed systems experience, and when you can tolerate eventual consistency. Avoid it when your domain is simple, your team is small, or you need strong consistency.” That is a pattern.
These libraries should be open, collaborative, and opinionated. Not neutral surveys of every possible option. That is what Google is for. Opinionated guides that say: in this context, do this. In that context, do not. Here is why. Here is what happened when someone ignored the advice.
Open KMS: knowledge management that ships</h3>
Most knowledge management systems are built for managers who want to organise information. They need to be built for practitioners who want to find answers.
The difference is fundamental. Managers want taxonomy, hierarchy, dashboards. Practitioners want search, context, and examples. One group wants to see the whole map at once. The other just wants to find the right road.
An open KMS for technical leaders should be: version-controlled (Git-based), searchable (full-text and semantic), contextual (tagged with team size, domain, scale, technology), peer-reviewed (pull request workflow), executable (runnable examples, not just descriptions), and federated (organisations contribute to a shared commons while keeping private extensions).
The tools exist. Git. Markdown. Static site generators. Semantic search. The stack is mature and free. What is missing is the curation. Someone has to decide what goes in, what the quality bar is, how to keep it alive. That is a community problem, not a technology problem. And community problems are harder than technology problems, which is why the industry keeps trying to solve this with another product.
The anti-pattern catalogue</h3>
Best practices get all the attention. Anti-patterns are more valuable.
Knowing what not to do, and why, prevents more damage than knowing what to do. An open, community-maintained catalogue of technology anti-patterns, each documented with the pattern, why it seems like a good idea at the time, why it fails, what to do instead, and examples of the failure. This would save the industry billions in repeated mistakes.
This catalogue already exists informally. Scattered across blog posts. Conference talks. Twitter threads. Slack DMs. It needs to be consolidated, structured, and maintained. Not by a vendor with a product to sell, but by practitioners with scars to share.

The best code is reviewed before it ships. The best decisions should be reviewed before they are made, against a record of every time the same decision was made before. </blockquote>
What policy-makers must do
Fund an open-source KMS for the public sector. Not a SaaS product from a vendor. A Git-based, community-maintained, nationally hosted knowledge base of technology patterns, anti-patterns, and decision records from public sector projects. Seed it with retrospectives from completed projects. Make contribution a condition of future funding.
Mandate post-mortems as deliverables. Every publicly funded IT project should produce a structured post-mortem on completion. What worked. What did not. What would be done differently. Publish it. Index it. An organisation that funds ten projects and captures ten post-mortems is building institutional intelligence. One that funds ten projects and captures none is buying the same lesson ten times and calling it variety.
Create cross-agency knowledge exchanges. Secondments. Shared retrospectives. Joint architecture reviews. The municipality that solved the identity verification problem last year should be in the room when the next municipality starts. This costs almost nothing. The savings are enormous. The only reason it does not happen is that nobody is paid to make it happen.
Speaking partners</h3>
InnerSource Commons. The Architectural Decision Records community. Backstage adopters and contributors. Open-source documentation communities. DevOps and platform engineering networks. The growing community of practice around engineering effectiveness, particularly the leads at companies like Spotify, Zalando, and Klarna who have already built internal knowledge systems at scale.
What individuals & companies can do
Adopt ADRs tomorrow. Architectural Decision Records take fifteen minutes to write and save weeks of re-litigation. Use the format: Title, Status, Context, Decision, Consequences. Store them in the repository next to the code they describe. If your team does nothing else from this article, do this.
Build your team’s pattern library. Start small. Five patterns your team uses often. Five anti-patterns you have learned the hard way. Put them in a Git repo. Review them every quarter. Share them with new hires on day one. This is your most valuable onboarding document. It will also be the one document everyone actually reads.
Contribute to open knowledge projects. If you have learned an expensive lesson, write it up. Not as a blog post that will be buried in a month. As a structured contribution to a shared knowledge base. Projects like the Technology Radar, the DORA reports, and the C4 model all started as one practitioner’s hard-won knowledge, shared openly.
Review decisions, not just code. Add a decision review step to your development process. Before committing to a significant technical choice, check: has this been tried? What happened? What were the preconditions for success? If your team cannot answer these questions, you are making the decision blind. And you will get the result that blindness usually gets.

03. Opportunities</h2>
The analysis
Breaking the cycle</h3>
The three-year blame cycle is not inevitable. It persists because the industry has no institutional memory.
Each team, each company, each new generation of developers starts from scratch. Makes the same mistakes. Different brand names. The team that adopted SOA badly in 2008 is the team that adopted microservices badly in 2018 and will adopt AI agents badly in 2028. The technology changes. The failure mode does not.
Breaking the cycle does not require better tools. It requires better knowledge infrastructure. If every significant technical decision were recorded, reviewed, and searchable, if every failure were documented with the same rigour as every success, the industry would learn at the rate it invents, instead of limping three years behind its own experience.
AI-augmented knowledge systems</h3>
Here is the irony.
AI is exceptionally good at the exact problem the industry refuses to solve manually. Semantic search across decision records. Pattern matching across post-mortems. Surfacing relevant precedent the moment a team proposes a decision.
An AI-augmented KMS could, when someone says “let’s use event sourcing for the billing system,” immediately surface: three previous projects that tried this, two that succeeded with these preconditions, one that failed for this reason, and the resulting recommendation. Not because the AI is clever. Because the record exists, and the AI can read it.
This is not speculative. The components exist. The thing that is missing is the structured knowledge to feed them. AI cannot learn from lessons that were never recorded.
Competitive advantage through institutional memory</h3>
The company that remembers is faster than the company that rediscovers.
Every decision that does not need to be re-debated. Every mistake that does not need to be re-made. Every pattern that does not need to be re-learned. Compound that over years and the difference is staggering. Two companies. Identical talent. Identical budgets. Identical technology stack. One has a living knowledge base. The other does not. They will diverge in delivery speed within six months.
This is the least glamorous competitive advantage in technology. It is also one of the most durable. You cannot poach an organisation’s institutional memory. You cannot acquire it in a fundraising round. You can only build it. Deliberately, consistently, openly.
The open knowledge economy</h3>
When organisations share knowledge openly (patterns, anti-patterns, decision records, post-mortems) they do not lose competitive advantage. They gain ecosystem leverage.
The company that publishes its engineering practices attracts engineers who want to work that way. The municipality that shares its project retrospectives helps the next municipality avoid the same pitfalls, and in return benefits from theirs. Open knowledge is not zero-sum. It is compounding. Every contribution raises the floor for everyone, including the contributor, and the floor is where most of the industry currently lives.

The industry does not have a tooling problem. It has an amnesia problem. And the cure is not a better tool. It is a better memory. </blockquote>
What policy-makers must do
Treat knowledge infrastructure as critical infrastructure. A national open knowledge base of technology decisions, patterns, and failures has the same strategic value as a national compute cluster. It costs a fraction as much. Fund it. Staff it. Maintain it. The return is not measured in one project. It is measured in every project that comes after.
Incentivise open knowledge sharing. Offer procurement advantages to companies that contribute to open knowledge commons. Make post-mortem publication a condition of government contract completion. Create awards for the most valuable public contribution to shared technical knowledge. Shift the incentive from hoarding to sharing, because right now the incentive runs the wrong way.
Embed knowledge practices in education. Teaching developers to write code without teaching them to record decisions, document trade-offs, and learn from failures is like teaching doctors to prescribe without teaching them to take a patient history. Decision records, post-mortems, and pattern thinking should be part of every computer science curriculum. Not as a seminar. As a habit.
Speaking partners</h3>
University computer science departments. National digital skills agencies. The Software Engineering Institute. IEEE and ACM working groups on software engineering practice. Companies with mature engineering effectiveness programmes (Spotify, Google, Etsy, Netflix) whose published engineering practices have already quietly shaped the industry. And the open-source communities maintaining the tools that make knowledge-as-code possible in the first place.
What individuals & companies can do
Stop starting from scratch. Before your team kicks off a new project, spend one day, just one, looking for precedent. Who has built something similar? What did they learn? What would they do differently? This one habit, applied consistently, eliminates more waste than any process improvement framework ever will.
Build the KMS you wish you had. Start with a Git repo. A folder of Markdown files. A search tool. Add your team’s top ten decisions, top five failures, top five patterns. Share it with the next team. Improve it every quarter. In a year, it will be the most valuable asset your engineering organisation owns. And it will have cost almost nothing to build.
Name the cycle when you see it. When someone in your organisation says “microservices were the wrong choice, let’s rewrite everything as a monolith”, or “the data lake was a mistake, let’s move to a data mesh”, ask the question: was the tool wrong, or was our understanding of how to use the tool wrong? If it’s the latter, the rewrite will fail for the same reason. Fix the knowledge gap before you fix the architecture.
Make knowledge a first-class engineering output. Code ships. Tests ship. Documentation should ship. Decisions should ship. Retrospectives should ship. If your team’s only deliverable is working software, you are producing a product but not building an organisation. The organisation is the thing that remembers.

Conclusion</h2>
The technology industry is extraordinarily good at building new things. It is extraordinarily bad at remembering what it learned while it was building the last thing. This is not a character flaw. It is a systems failure. Knowledge lives in the wrong places, in the wrong formats, maintained by the wrong incentives.
The fix is not another tool. It is a practice. Treat knowledge with the same rigour you treat code. Version it. Review it. Test it against reality. Maintain it. Share it. When someone proposes a decision, check it against the record. Not because you distrust their judgement, but because you respect the judgement of everyone who came before.
The tools are blamed because the patterns are forgotten. The patterns are forgotten because they were never written down. And they were never written down because the industry decided, somewhere along the way, that only code is worth saving.
It is time to save the rest.

Kubernetes is not your problem. Microservices are not your problem. AI will not be your problem. Your problem is that you keep making decisions in a room with no memory. Build the memory. The decisions will follow. </blockquote>

Catching up

2026-04-11T00:00:00+00:00

The narrative is seductive and paralysing.
The US has the models. China has the scale. Everyone else is a customer. Europe and the Nordics missed the boat. The only rational move is to rent from the winners and focus on regulation.
This is defeatism dressed up as pragmatism. And it is wrong.
The AI landscape is not a finished race. It is a shifting terrain. The leaders carry enormous costs, geopolitical baggage, and architectural debt. The followers, if they are strategic, carry none of it. Catching up is not about matching OpenAI parameter for parameter. It is about understanding which parts of the stack are commoditising, which are still open to disruption, and where a smaller, more focused player can build asymmetric advantage.
01. Problems</h2>
The analysis
The defeatism trap</h3>
The most dangerous constraint is not technical. It is psychological.
When decision-makers believe the gap is unclosable, they stop investing. When they stop investing, the gap actually becomes unclosable. The prophecy fulfils itself. Every European minister who says “we can’t compete with the US hyperscalers” makes it slightly more true by saying it.
China faced a similar narrative a decade ago. Its response was not to wait for permission. It was to train on what existed, build on what was open, and invest ferociously in what was missing. The playbook is not secret. It is just uncomfortable for cultures that prefer consensus over speed.
The compute gap</h3>
Training frontier models requires GPU clusters that cost hundreds of millions of dollars. The US dominates supply through NVIDIA. Export controls restrict what China, and by extension the rest of us, can access. Europe has almost no domestic GPU manufacturing. The Nordics have energy, talent, and cooling. Not the silicon.
This is real. It is also narrower than it appears.
Training a frontier model from scratch is one activity. Fine-tuning, distilling, and deploying existing open-weight models is another. The second requires orders of magnitude less compute. The question is not “can we build GPT-5 from scratch?”. The question is “do we need to?”
Smaller models, sharper edges</h3>
The arms race for the largest model is a game with diminishing returns and escalating costs.
Meanwhile, something quieter is happening at the other end of the scale. Models with 7 to 14 billion parameters, a fraction of frontier size, are increasingly competitive on real-world tasks when properly fine-tuned. They are cheaper to train by orders of magnitude. Fast enough to run on consumer hardware. Small enough to deploy on-premises without a data centre.
If Europe cannot afford to compete at 1 trillion parameters, it does not have to. It can invest in becoming the best in the world at small, task-specific models. Models that beat the giants on the domains that matter: local languages, regulated industries, edge deployment, privacy-sensitive applications. This is not a consolation strategy. It is where the market is already moving. Even the hyperscalers are racing to make their models smaller. Europe can start where they are trying to arrive.
The talent drain</h3>
Europe’s best AI researchers leave. Not because they can’t do the work here. Because the work is not here to do.
When the most ambitious projects are in San Francisco, the most ambitious people follow. This is not a salary problem alone. It is a gravity problem. Large clusters of talent attract more talent. Breaking the cycle requires building something worth staying for.
The standards vacuum</h3>
Europe excels at regulation. It is less good at setting technical standards that the rest of the world adopts voluntarily.
The AI Act is a legal framework. What is missing is a European-led open technical stack: model formats, evaluation benchmarks, deployment standards, interoperability protocols. Something with gravity of its own.

You do not catch up by running the same race faster. You catch up by finding a shorter course. </blockquote>
What policy-makers must do
Kill the defeatist narrative publicly. Every speech that opens with “we are behind” reinforces the problem. Reframe. Europe is not behind in AI. It is early in sovereign AI, and early is where strategic investment has the highest return.
Audit the actual gap. Commission an honest, technical assessment of what European organisations can and cannot do today. Not a consultancy slide deck. A practitioner-led audit. The gap in model training is real. The gap in deployment, fine-tuning, and application is much smaller. Policy should target the real gaps, not the imagined ones.
Stop subsidising dependence. Every grant that helps a European company buy more US cloud compute deepens the dependency. Redirect subsidies toward domestic compute infrastructure, open-source model development, and hardware supply chain diversification.
Speaking partners</h3>
EuroHPC Joint Undertaking. Nordic AI research institutes (WASP in Sweden, FCAI in Finland, NORA in Norway). National science foundations. The European Innovation Council. And the CTOs of European AI startups who are shipping products today, not waiting for permission.
What individuals & companies can do
Stop waiting for a European GPT. You do not need one. Open-weight models from Mistral, Meta (LLaMA), Alibaba (Qwen), and others are available now, run on European infrastructure, and can be fine-tuned for your domain in days. The best European AI companies are already building on this stack. Join them.
Refuse the “we need the big clouds” default. Every architectural decision that routes through a US hyperscaler is a decision that could have routed through a European provider, a Nordic data centre, or your own hardware. The performance difference is often negligible. The sovereignty difference is not.
Hire and retain locally. If you are a European AI company paying Silicon Valley salaries to attract Silicon Valley talent, you are competing on their terms. Instead: build the most interesting projects. Offer the best working conditions. Create the research environment that makes people stay. Talent follows ambition, not just money.

02. Solutions</h2>
The analysis
The open-weight playbook</h3>
China’s AI ecosystem did not emerge from a vacuum. It bootstrapped aggressively from open research, open code, and pre-trained models. When DeepSeek demonstrated that competitive results were possible at a fraction of the frontier compute budget, it dented the assumption that only frontier labs could produce frontier capability.
The technique, at a high level, is pragmatic. Take an open-weight model. Adapt it (through fine-tuning, LoRA, quantisation, or knowledge transfer). Optimise for inference efficiency. Ship something small, fast, and task-specific. For most real-world applications, this is not a compromise. It is the right engineering decision.
Europe and the Nordics can do this legally, at scale, and without asking permission. The permissive open-weight models are there. Mistral ships under Apache 2.0. Qwen’s flagship models under Apache 2.0. Meta’s LLaMA under a community license that allows commercial use below a very high user threshold, which no European AI startup is likely to hit any time soon. What is missing is not capability. It is organisational will.
Hardware openings</h3>
NVIDIA’s dominance is real but not permanent. Several forces are converging to create space:
RISC-V and open silicon. The RISC-V instruction set is open, royalty-free, and increasingly viable for AI accelerators. RISC-V International, the governing body, is now headquartered in Switzerland. European companies like SiPearl in France are designing AI-capable chips on open architectures. The EU Chips Act has mobilised investment commitments on the order of tens of billions of euros, though much of that figure is private capital and existing state aid rebadged, not fresh EU budget. The question is whether this money reaches the right projects or disappears into legacy fabs building yesterday’s chips. The cancelled Intel Magdeburg fab and the cancelled Wolfspeed Saarland plant are early warnings that it often does.
Nordic energy as a competitive advantage. Training AI models is, at its core, an energy problem. The Nordics have some of the cheapest and cleanest electricity in Europe, abundant natural cooling, and stable political environments. A GPU cluster in northern Sweden or Finland costs less to operate than one in most of central Europe, and emits a fraction of the carbon. At scale, energy cost is a dominant variable.
Alternative architectures. The assumption that AI requires NVIDIA GPUs is already weakening. Cerebras, with its wafer-scale design. Graphcore, the UK-founded IPU company now owned by SoftBank. An expanding class of custom AI ASICs showing that different architectures can outperform GPUs on specific workloads. Europe does not need to win the GPU race. It needs to be ready for the post-GPU era, and invest accordingly.
Automation as cost collapse</h3>
The cost of building AI systems is not fixed. It is falling. Automation is the mechanism.
Data preparation. Synthetic data generation, automated labelling, and AI-assisted cleaning are reducing the human labour cost of dataset creation by an order of magnitude or more. A small European team with good tooling can build training datasets that previously required a room full of annotators.
Model development. Automated architecture search, hyperparameter optimisation, and distillation pipelines mean that a small team with the right toolchain can iterate at the pace of a large team without one. The leverage is in the tooling, not the headcount.
Deployment and operations. AI-assisted DevOps, automated monitoring, and self-healing infrastructure mean that running a model in production no longer requires a dedicated ops team for every deployment. One engineer with good automation now does what recently took a small team.
The implication is that the cost of being a fast follower is dropping faster than the cost of being a leader. Every year that passes makes catching up cheaper, provided you are building the automation infrastructure to take advantage of it.

China did not ask for permission to train on open models. It did not wait for a domestic GPU industry to mature before starting. It used what was available, improved what it could, and built what was missing. The strategy was not elegant. It was effective. </blockquote>
What policy-makers must do
Fund fine-tuning and adaptation centres. Not every country needs to train a frontier model. Every country needs the infrastructure to take an open-weight model and make it their own. Fund national AI centres whose explicit mandate is: take the best open models, adapt them on domestic data, evaluate them against local benchmarks, and make them available to the public sector and SMEs.
Make small models a strategic priority. Allocate research funding specifically for efficient architectures. Models that maximise capability per parameter, not parameters per headline. Europe’s comparative advantage is not brute compute. It is engineering precision. Fund the teams building 7B models that beat 70B models on specific tasks. That is where the leverage is.
Accelerate the EU Chips Act toward open architectures. Ensure that a meaningful share of semiconductor investment goes to RISC-V and open-silicon AI accelerator projects. Not just to conventional fabs replicating what TSMC already does better. The Magdeburg and Saarland cancellations should be a lesson. The goal is not to copy the US chip industry. It is to build the next one.
Create Nordic AI infrastructure zones. Designate areas in northern Scandinavia and Finland as AI compute zones with fast-tracked permitting, energy subsidies, and fibre connectivity. Market them internationally. The value proposition of cheap green energy, political stability, GDPR compliance, and Arctic cooling is rare globally.
Invest in automation R&D as a force multiplier. Every euro spent on AI development automation (data pipelines, evaluation frameworks, deployment tooling) reduces the cost of every subsequent AI project. This is infrastructure spending with compound returns. Prioritise it over individual model training projects.
Speaking partners</h3>
EuroHPC. WASP (Sweden), FCAI (Finland), NORA (Norway). DFKI (Germany). SiPearl and other European chip designers. RISC-V International. Nordic data centre operators (including those in Luleå, Kajaani, and along the LUMI corridor). Mistral AI. The SiloGen research group (now operating inside AMD after the Silo AI acquisition, but still shipping Poro and Viking Nordic language models). And the growing DeepTech ecosystem in the Nordics and Baltics.
What individuals & companies can do
Start adapting today. If you are building an AI product, you do not need to train from scratch. Take Mistral, LLaMA, or Qwen. Adapt it for your domain. Deploy on European infrastructure. This is not a shortcut. It is state of the art. The best Chinese labs do exactly this, and they are not embarrassed about it.
Bet on small. A 7B model fine-tuned on your domain data, running on a single GPU, responding in milliseconds, deployable on-premises with no API dependency. That is a product. A product you own, a product you control, a product no hyperscaler pricing change can take away from you. Stop chasing parameter counts. Start chasing usefulness per watt.
Invest in automation before headcount. Before hiring your tenth ML engineer, ask a simple question: could better tooling make your existing five twice as productive? The answer is almost always yes. Build data pipelines that run without human intervention. Automate evaluation. Automate deployment. The team that automates first wins, regardless of geography.
Use Nordic infrastructure. If you are running GPU workloads, look north. Swedish and Finnish data centres offer electricity at a fraction of the cost of Frankfurt or Amsterdam, with lower carbon emissions and natural cooling. Several now offer GPU-as-a-service with GDPR-compliant hosting. The cost advantage is real and growing.
Contribute to open hardware. If your company has chip design, firmware, or systems engineering expertise, engage with RISC-V AI accelerator projects. The open silicon ecosystem is where Linux was in 2003. Early, messy, and about to become very important. Early contributors will shape the architecture.

03. Opportunities</h2>
The analysis
The follower’s advantage</h3>
Leaders pay the R&D tax. They explore dead ends, burn capital on failed architectures, carry the technical debt of being first. Followers see which paths worked and skip the rest. This is not cheating. It is how technology has always diffused. Japan did it with manufacturing. South Korea did it with semiconductors. Europe and the Nordics can do it with large parts of the AI stack.
The key insight: you do not need to reproduce the leader’s journey. You need to reproduce their current position. And that position is increasingly built on open components that anyone can assemble.
Sovereignty as a market differentiator</h3>
In a world of increasing geopolitical fragmentation, “made in Europe” is becoming a selling point, not a limitation. European data residency, GDPR compliance, and political neutrality are features that US and Chinese providers cannot replicate. Every industry with regulatory constraints (healthcare, finance, defence, public administration) is a market where sovereign AI is not optional. It is the product.
The total addressable market for “AI that does not route through a US hyperscaler” is not niche. It is the entire regulated economy of Europe, plus every country that prefers European values to American commercial terms or Chinese state oversight.
The small-language moat</h3>
Frontier models are trained primarily on English and Chinese text. Their performance in smaller languages (Swedish, Finnish, Norwegian, Danish, Estonian, Icelandic, the rest) improves every generation but still lags behind their English performance on domain-specific tasks. This is not a bug to complain about. It is a market opportunity.
A model fine-tuned on high-quality Swedish legal text, operated by a team that speaks the language and knows the courts, will outperform any generic frontier model on Swedish legal tasks. A model trained on Finnish healthcare records will do the same in Finnish healthcare. Language specificity is a moat that geography gives you for free.
The green compute premium</h3>
AI training is becoming one of the largest energy consumers on the planet. As carbon pricing tightens and ESG reporting becomes mandatory, the cost of running AI on fossil-fuel grids will rise. The Nordics, running largely on hydro, nuclear, and wind, will offer compute at a structural cost advantage that grows every year. This is not a trend. It is physics and policy converging.

The leaders built the road. The followers get to drive on it, faster, lighter, and without the construction debt. The only mistake is standing on the roadside and admiring the traffic. </blockquote>
What policy-makers must do
Brand sovereign AI as an export product. European AI sovereignty is not just a domestic policy goal. It is a product the rest of the world wants to buy. Position European AI infrastructure, models, and standards as the alternative for nations that want AI capability without US or Chinese dependency. This is a foreign policy opportunity as much as an industrial one.
Fund language-specific AI as critical infrastructure. Allocate dedicated budget for training, fine-tuning, and evaluating models in every official EU language. Do it with public data, open weights, and open benchmarks. A Swedish-language model trained on Swedish public sector data is not a research project. It is national infrastructure, as essential as roads.
Set the global standard for green compute. Propose international benchmarks for carbon-per-inference and energy-per-training-run. If Europe defines these metrics first, it defines the playing field. And the playing field tilts toward Nordic energy. This is standards-setting as competitive strategy.
Create fast-track visas for AI talent. If the US restricts immigration and China restricts information, Europe should do the opposite. Be the easiest place in the world for a talented AI researcher to move to, work in, and build a company. Talent follows opportunity, and opportunity follows policy.
Speaking partners</h3>
Nordic Council of Ministers. European Commission DG Connect. National energy regulators. Nordic and Baltic AI startup ecosystems. The European Open Source AI community. Language technology institutes (Språkbanken in Sweden, Kielipankki in Finland). And trade representatives from countries actively seeking alternatives to US and Chinese AI dependency, particularly in the Middle East, Southeast Asia, Africa, and Latin America.
What individuals & companies can do
Position yourself as the sovereign alternative. If you are a European AI company, your pitch is not “we are almost as good as OpenAI”. Your pitch is: “we are better for your use case, your language, your regulation, and your data stays in your jurisdiction”. That is not a consolation prize. For a growing number of buyers, it is the deciding factor.
Build language-specific products. The English-language AI market is crowded. The Swedish, Finnish, Norwegian, Dutch, and Polish AI markets are much less so. If you can fine-tune a model that handles Swedish tax law, Norwegian fisheries regulation, or Finnish patient records better than any generic frontier model, you own that market. No one in San Francisco is coming for it.
Market your energy story. If you run AI workloads on Nordic green energy, say so. Loudly. As carbon reporting becomes mandatory for enterprise procurement, your sustainability credentials become a competitive advantage that compounds with every new regulation.
Collaborate across borders. The Nordics individually are small markets. Collectively, they are close to 30 million people with high digital literacy, excellent infrastructure, and compatible regulatory frameworks. Build products that work across Nordic languages. Form consortia that bid for EU-wide contracts. The scale is there. It just requires coordination.

Conclusion</h2>
Catching up is not about matching the leaders step for step. It is about recognising that the game has changed.
The cost of AI capability is falling. The tools are open. The architectures are published. The training techniques are documented. What took billions to create can be adapted for millions, deployed for thousands, and operated for a fraction of what the original builders spend.
The Nordics and Europe have assets no amount of venture capital can buy. Clean energy. Political stability. Regulatory credibility. Linguistic diversity. A population that expects technology to serve public interest, not just shareholder value.
The only thing that can stop Europe from catching up is the belief that it cannot. And that belief is a choice, not a fact.

They built the models. We have the energy, the standards, and the will. The only thing we were missing was the nerve to start. Consider this the starting signal. </blockquote>

Frugal IT

2026-04-10T00:00:00+00:00

Governments and tax-funded organisations spend billions on information technology every year. Much of it is wasted. Not through corruption. Through habit.
The same procurement patterns. The same vendor relationships. The same absence of technical scrutiny that turned “digital transformation” into a polite euphemism for writing large cheques to large consultancies.
Frugal IT is not austerity. It is the disciplined application of constraints. Spending less by understanding more. Accessing industry expertise without routing every decision through a firm that bills by the hour.
01. Problems</h2>
The analysis
The consultancy dependency cycle</h3>
Most public sector IT strategy is written by the same five consultancies that also implement it.
The incentive structure is obvious. The more complex the recommendation, the longer the engagement. A firm paid to diagnose will always find a disease that requires treatment. Preferably ongoing. Preferably expensive. This is not bad faith. It is structural misalignment between the advisor’s revenue model and the taxpayer’s interest.
Absence of internal expertise</h3>
Decades of outsourcing have hollowed out technical capability within government.
When a ministry cannot evaluate a vendor’s architecture proposal, it cannot negotiate. When it cannot negotiate, it overpays. When it overpays, it cuts elsewhere. Often from the very training budgets that would rebuild internal competence. The cycle is self-reinforcing and nobody is in charge of stopping it.
Procurement as theatre</h3>
Public procurement frameworks were designed for buying bridges. Not software.
Multi-year RFP cycles. Compliance-heavy evaluation criteria. A bias toward “nobody gets fired for buying IBM” that produces outcomes favouring incumbents over innovators, size over suitability, and process over results. A startup with a better solution at a tenth the cost often cannot even submit a bid. The paperwork is the barrier, and the paperwork was written by people who benefit from the barrier existing.
Bigger is not better</h3>
Government IT has a gravitational pull toward the monolithic.
A problem that could be solved in twelve weeks with a small team and a focused scope gets packaged into a multi-year, multi-million-euro “transformation programme”. The bigger the project, the higher the compliance bar. Turnover thresholds. Insurance requirements. Reference lists. The smaller the pool of eligible bidders.
In practice, this means the same four or five consultancies win the same contracts, year after year. Not because they are best. Because they are big enough to qualify.
The irony is that large projects fail more often. Research consistently shows that IT projects over a certain size have dramatically higher failure rates. Smaller, iterative deliveries succeed more often. The procurement system is not built for them. It rewards ambition on paper over delivery in practice.
The hidden cost of “enterprise” software</h3>
Licence fees are the tip of the iceberg.
The real cost of enterprise software in government is lock-in. Proprietary data formats that prevent migration. Customisation layers that only the original vendor can maintain. Integration dependencies that turn every adjacent system into a hostage. By the time an organisation realises the total cost of ownership, switching is more expensive than staying. Which is the whole point, from the vendor’s perspective.

The most expensive IT decision a government makes is not the one it signs. It is the one it cannot walk away from. </blockquote>
What policy-makers must do
Impose budget ceilings as a design constraint. Frugality is not a limitation. It is a forcing function for better engineering. When a project has half the budget, it cannot afford unnecessary complexity. Mandate that IT projects demonstrate what they would cut, not just what they would build.
Separate advisory from implementation. The firm that designs the architecture should not be the firm that builds it. This single rule eliminates the most corrosive incentive in public sector IT. Where legislation does not yet require it, procurement guidelines should.
Default to open source. Every procurement should begin with the question: does an open-source solution exist? If it does, the proprietary alternative must justify its cost against a baseline of zero licence fees. This is not ideology. It is due diligence with public money.
Break big projects into small contracts. Cap individual IT contracts at a size that small and mid-sized companies can deliver. Six months. Clearly scoped. With defined outcomes. Chain them iteratively, the next contract awarded based on the results of the last. This opens the door to smaller actors, reduces risk per engagement, and creates natural checkpoints where a failing project can be stopped before it consumes its entire budget.
Lower the entry barriers for small vendors. Reduce turnover thresholds, simplify insurance requirements, and accept relevant project experience over corporate scale. A three-person team that has delivered five successful government projects is a better bet than a consultancy with ten thousand employees and a mixed track record. Current procurement rules cannot see the difference.
Rebuild internal technical teams. Hire engineers into government at competitive salaries. Not as advisors. As decision-makers. A single senior architect on staff can save more than their salary in avoided vendor lock-in within the first year.
Cut the paperwork. A procurement process that takes nine months and two hundred pages of documentation to buy a €50,000 service is not rigorous. It is wasteful. Bureaucracy does not prevent bad decisions. It prevents fast ones. Streamline approval chains, reduce redundant compliance layers, and trust empowered teams to make proportionate decisions. The goal is accountability, not ceremony.
Speaking partners</h3>
Open Source Programme Offices (OSPOs) in governments that have them, including France, Germany, and Italy. The Free Software Foundation Europe. The Code for All network. GovTech agencies (UK GDS, Singapore GovTech, Estonia’s e-Governance Academy). And, critically, the CTOs and engineering leads of small-to-mid-sized companies who have delivered government projects without an army of consultants.
What individuals & companies can do
If you work in government: document what you actually need. Before the RFP. Before the vendor calls. Write down, in plain language, what the system must do. Not what features would be nice. What it must do. This document is worth more than any consultancy’s discovery phase, and it takes an afternoon.
If you run a small tech company: make yourself visible. Register on government procurement platforms. Attend pre-tender briefings. Publish case studies in language procurement officers understand. Outcomes, timelines, cost. Not technical jargon. The barrier to government work is often not capability. It is discoverability.
If you are an independent expert: offer micro-engagements. Governments do not always need a six-month strategy review. Sometimes they need a two-day architecture audit, a four-hour procurement review, or a single afternoon with someone who has built what they are trying to buy. Make these formats available. Price them accessibly.

02. Solutions</h2>
The analysis
The expertise marketplace</h3>
The knowledge governments need already exists. It lives in the heads of practitioners who build production systems every day.
The problem is access. Big consultancies act as intermediaries, packaging practitioner knowledge at a markup and wrapping it in slide decks. The solution is to disintermediate. Connect public sector decision-makers directly with working engineers, architects, and technical leads. Pay them for their time, not for the slide deck.
Constraints as architecture</h3>
The best systems are not the ones with the most resources. They are the ones designed within the tightest constraints.
A government IT team with a small budget and a clear mandate will, on average, build something more maintainable than a well-funded team with a vague one. The constraint forces choices. Choices produce clarity. Clarity produces systems that actually work.
Modular procurement</h3>
Instead of one contract for an entire platform, break the work into modules. Authentication. Data layer. User interface. Integration. Hosting. Each module can be competed separately, built by different vendors, and replaced independently. This is how the private sector builds resilient systems. There is no reason government cannot do the same.
Smaller modules mean smaller contracts. Smaller contracts mean smaller companies can compete. And when five different vendors each build one component, no single vendor holds the keys to the whole system. The result is not just cost savings. It is architectural antifragility. If one vendor fails, you replace one module. Under the monolithic model, you replace everything.
The fellowship model</h3>
Bring industry practitioners into government on short rotations. Three to six months. Not as consultants billing through a firm, but as embedded fellows with direct access to teams, codebases, and decision-making. They bring current practice. They leave behind capability. The cost is a fraction of a traditional engagement, and the knowledge transfer is dramatically higher.
Prototype before you procure</h3>
The most expensive line in any requirements document is the one nobody tested.
Government IT projects routinely spend months writing specifications, then years building to them, only to discover that the assumptions were wrong. The alternative is cheap and fast. Build a rough prototype in weeks. Put it in front of real users. Learn what actually works before committing budget. A €10,000 prototype that kills a bad idea saves €10 million in failed implementation. This is not agile methodology as buzzword. It is risk management through rapid learning.
Institutional memory</h3>
Government has a chronic amnesia problem.
Projects fail, lessons get written into reports that nobody reads, and the next team makes the same mistakes with the same vendors five years later. The knowledge exists. Buried in post-mortem documents, archived Slack channels, and the heads of people who have since moved on. Organisations that systematically capture, index, and revisit their own failures build compounding institutional intelligence. Those that don’t are condemned to pay for the same education twice.

Frugal is not the same as cheap. Frugal means the right thing, sized right, priced right, delivered on time by people who understand it. Cheap means whatever the lowest bidder said they would deliver. One is sustainable. The other is a liability with a deferred invoice. </blockquote>
What policy-makers must do
Create direct procurement channels for SMEs and independents. Simplified frameworks, lower insurance thresholds, faster payment terms. If a qualified individual can deliver the work, the procurement system should not require them to incorporate a limited company with five years of accounts to be eligible.
Fund technology fellowships. Allocate budget for practitioners from industry to spend time inside government departments. Model it on the US Digital Service, the UK’s Government Digital Service, or France’s Entrepreneurs d’Intérêt Général. Extend it beyond the usual suspects.
Publish spend data. Every IT contract, every vendor, every renewal, published openly. Transparency does not just prevent waste. It enables comparison. When one municipality pays three times what another pays for the same software, the conversation changes very quickly.
Mandate interoperability standards. No system purchased with public money should store data in a proprietary format. No integration should depend on a single vendor’s API without a documented exit path. These are not technical details. They are fiscal protections.
Require a prototype phase before full procurement. No IT project above a threshold value should proceed to full tender without a time-boxed prototype. Four to eight weeks. Minimal budget. Validates the core assumptions with real users. If the prototype fails, the project stops. This single rule would prevent more waste than any audit office.
Build a failure library. Establish a central, searchable repository of past IT project outcomes. What worked, what didn’t, and why. Make it mandatory reading before any new project of similar scope is approved. Require project teams to demonstrate they have reviewed relevant precedents. Learning from your own mistakes is free. Repeating them is not.
Speaking partners</h3>
Digital service agencies with proven track records (18F in the US, GDS in the UK). The Open Contracting Partnership. Transparency International’s public procurement programme. Local tech communities and meetup organisers. Freelancer cooperatives. And the growing network of public-interest technologists.
What individuals & companies can do
Mentor a civil servant. If you have production engineering experience, volunteer an hour a month to someone in government IT. Not to sell. To teach. The compound effect of practical knowledge entering the public sector is enormous.
Build government-ready open-source tools. Most open-source projects are built for developers. Government needs tools built for operators. Clear documentation. Deployment guides. Security hardening. And, above all, a path to support without vendor lock-in. If your project serves this audience, say so explicitly.
Form consortia. Small companies competing individually against large consultancies will lose on credentials every time. Small companies bidding together, with clear role separation, shared delivery frameworks, and combined track records, can win on quality and cost simultaneously.

03. Opportunities</h2>
The analysis
The public sector as innovation lab</h3>
Government is the largest buyer of technology in most economies.
When it buys well, it creates markets. A municipality that adopts an open-source document management system does not just save money. It validates the product for every other municipality. Public procurement, done right, is the most powerful accelerator the technology ecosystem has. It is also the one governments use least well.
AI as the great equaliser</h3>
The current generation of AI tools can collapse the capability gap between a well-staffed IT department and an understaffed one.
A single engineer with access to coding assistants, automated testing, and AI-driven documentation can maintain systems that previously required a team. This is not about replacing people. It is about amplifying the ones you have. The civil servant who was managing twelve systems with a spreadsheet and a prayer can now manage them with confidence.
Citizen-facing services as competitive advantage</h3>
Governments that deliver excellent digital services attract businesses, talent, and investment.
Estonia’s e-residency programme. India’s UPI payment system. Singapore’s SingPass. These did not just improve public services. They became national brands. Frugal IT is not a cost-cutting exercise. It is an investment in the quality of civic infrastructure that compounds over decades.
The sovereignty dividend</h3>
Every system built on open standards, hosted on domestic or European infrastructure, and maintained by local talent is a system that cannot be switched off by a foreign policy decision, a corporate acquisition, or a pricing change.
In an era of increasing geopolitical volatility, this is not a nice-to-have. It is a strategic imperative. And it gets harder to retrofit every year you don’t start.

The public sector is not a bad customer. It is an unprepared one. Give it the ability to buy small, test fast, and walk away from bad bets, and it becomes the best customer technology has. </blockquote>
What policy-makers must do
Measure outcomes, not inputs. Stop reporting IT success as “projects delivered on time and budget”. Start reporting it as “citizens served, processing time reduced, cost per transaction”. The metric change alone will transform what gets built.
Create shared services across agencies. Authentication. Payments. Notifications. Document storage. These are commodities. Every agency building its own version is waste. Shared platforms, maintained centrally and consumed as services, free individual departments to focus on their domain-specific problems.
Invest in maintainability, not novelty. The most valuable IT investment a government can make is not a new system. It is making an existing system easier to change. Refactoring, documentation, automated testing, and dependency upgrades are unsexy. They are also the difference between a system that lasts five years and one that lasts twenty.
Plan for exit. Every contract should include a documented exit path before it is signed, not after the relationship sours. Require open data formats, published APIs, full documentation, and a knowledge transfer phase as standard deliverables. A system you cannot walk away from is not an asset. It is a liability. The time to negotiate your independence is when the vendor still wants your business.
Speaking partners</h3>
National audit offices and their IT divisions. Parliamentary committees on digital affairs. Municipal CIO networks. The OECD Observatory of Public Sector Innovation. Academic programmes in public administration and digital governance. And, most importantly, the end users: citizens, caseworkers, teachers, and healthcare workers who use these systems every day.
What individuals & companies can do
Show your work. If you have delivered a government project cheaply and well, write about it. Present at conferences. Publish the architecture, the timeline, the cost. The public sector learns by example more than by argument. Every documented success makes the next frugal project easier to approve.
Participate in public consultation. When governments propose new IT strategies, procurement frameworks, or digital legislation, respond. The consultation process is often dominated by large vendors with dedicated policy teams. Independent voices, especially those with delivery experience, are underrepresented and urgently needed.

Conclusion</h2>
Frugal IT is not about spending less. It is about understanding more.
Understanding what you need before you buy. Understanding the market well enough to buy from the right people. Understanding your own systems well enough to maintain them without permanent external life support.
The constraints are real. Budgets are finite. Procurement is complex. Technical talent in government is scarce. But constraints, applied deliberately, produce better outcomes than abundance applied carelessly. Every euro spent on a system that works, that can be maintained, that can be changed, and that can be replaced is a euro that compounds in public value for years.
The alternative, the consultancy-dependent, vendor-locked, procurement-theatre model that dominates today, is not just expensive. It is fragile. And fragile systems, funded by taxpayers, are a risk that no government can afford to ignore.

The goal is not to make government IT cheap. The goal is to make it intelligent. And to make sure the intelligence comes from practitioners, not slide decks. </blockquote>

Democratizing AI

2026-04-09T00:00:00+00:00

Artificial intelligence is no longer an emerging technology. It is infrastructure. It shapes what you see, what you buy, who gets hired, and who gets a loan. The capacity to build, train, and deploy these systems remains concentrated in a handful of corporations, headquartered in an even smaller handful of nations.
This is not a market quirk. It is a structural risk. And structural risk requires action at every level. Understanding the problem. Demanding change from those who set the rules. Building alternatives from the ground up.
01. Problems</h2>
The analysis
The geography of power</h3>
The world’s most capable AI models are built by fewer than ten organisations, nearly all of them based in the United States or China.
The values, priorities, and blind spots of two political cultures get encoded, often invisibly, into systems used by billions. Europe, Africa, Southeast Asia, and Latin America are consumers of intelligence they had no hand in shaping. When the next generation of models decides what a “good” answer looks like, the rest of the world does not get a vote. It gets a bill.
The cost barrier</h3>
Training a frontier model now costs hundreds of millions of dollars in compute alone. Salaries, data acquisition, and energy come on top.
For a startup in Nairobi or a research lab in São Paulo, the entry ticket is not just expensive. It is structurally exclusionary. And the gap, measured in raw compute, is not closing. It is widening with every new parameter count.
But raw compute is not the whole story. The gap in adaptation, fine-tuning, and deployment is much smaller. That is where the opening is.
Socio-economic fragility</h3>
When capability concentrates, so do its economic returns.
Productivity gains flow to shareholders of a few firms. Labour displacement hits globally, but the new jobs cluster in the same cities that already have them. Nations that depend on outsourced cognitive labour (call centres, content moderation, translation, customer support) face economic shocks with no domestic AI industry to absorb the blow. The transition is not optional. The preparation is.
The closed stack problem</h3>
When the most capable AI is also the most closed, nobody outside the building can audit it.
You cannot inspect what you cannot access. You cannot fix what you cannot see. You cannot build an alternative if every ecosystem decision points back to the vendor. A closed AI stack is not just a commercial choice. It is a democratic one, made by people who were never elected to make it.

If electricity had been invented and owned by three companies in one country, the danger would be obvious. AI is no different. The wires are just invisible. </blockquote>
What policy-makers must do
Treat compute as critical national capability. Access to AI training infrastructure belongs in the same policy conversation as energy grids and telecommunications. Public investment in shared compute. Multilateral agreements for access, particularly for the Global South. The alternative is a world where twenty countries have AI and everyone else rents it.
Regulate data asymmetry. A few corporations harvest data from every country but concentrate the models built on that data in one jurisdiction. Data governance frameworks must ensure that value extracted from a population’s digital footprint returns, in capability, to that population.
Fund AI literacy at the ministerial level. Policy-makers who do not understand what a foundation model is cannot regulate one. Dedicated AI advisory bodies, staffed by technologists and not just lawyers, should be standard in every government. Not for decoration. For actual technical judgement inside the room where policy is written.
Fund research that questions the dominant stack. Most AI research money flows through channels that assume the current paradigm. Transformer architectures. GPU-based training. Hyperscaler deployment. A strategic portion of research funding should go to projects that question those assumptions. Different architectures, different hardware, different deployment models. That is where the next wave will come from.
Speaking partners</h3>
National science academies. OECD AI Policy Observatory. UNESCO. Digital rights organisations (EFF, Access Now, European Digital Rights). Telecom regulators already navigating infrastructure sovereignty questions. And the growing community of AI ethics researchers working outside the big labs.
What individuals & companies can do
Use open-source tools. Every time you choose an open model over a closed API, you vote with your compute. A consumer laptop can now run capable models locally. The barrier is lower than you think.
Demand transparency. Ask your employer, your bank, and your government: which AI systems make decisions about me, and who built them? The question itself shifts the conversation. Most organisations have never been asked. When they start being asked, the answers start getting better.
Diversify your AI stack. Vendor lock-in to a single frontier provider is a business risk dressed as convenience. Build abstraction layers. Evaluate open-weight alternatives for every use case. The performance gap is narrower than the sales pitch suggests, and the cost advantage of switching grows every quarter.
Invest in internal capability. An “AI team” that only calls external APIs is not an AI team. It is an API integration team with better branding. Train your engineers. Build fine-tuning pipelines. Own your models where it matters. The first time your primary provider triples its prices will be the day you wish you had started.

02. Solutions</h2>
The analysis
Open-weight models as public infrastructure</h3>
The release of capable open-weight models has done more for AI access than any policy paper.
Mistral. LLaMA. Qwen. DeepSeek. And the long tail of smaller, community-built derivatives. When a 70-billion-parameter model can run on rented cloud compute for dollars per hour, the geography of capability shifts. The solution is not to slow proprietary AI down. It is to accelerate the open alternative until it becomes the default choice, not the backup plan.
Some of the most capable open-weight models in the world are now coming out of Chinese labs. Some of the most permissive licenses come from European labs. The ecosystem is genuinely global, genuinely open, and growing faster than most policy frameworks can keep up with.
Collapsing the on-ramp</h3>
Fine-tuning frameworks like LoRA and QLoRA have reduced the compute cost of specialisation by orders of magnitude. A task that once required renting a GPU cluster for weeks can now be done on a single consumer graphics card in an afternoon.
Community-driven datasets in underrepresented languages are emerging. Tooling is maturing. What is still missing: structured pathways that take a developer from first API call to production deployment without requiring a PhD or a Silicon Valley network. The technical on-ramp is shorter than it has ever been. The social and educational on-ramp has not caught up.
Regulatory pluralism</h3>
The EU AI Act, Brazil’s proposed framework, and a dozen other national approaches represent different philosophies of AI governance. This is a feature, not a bug.
Multiple regulatory experiments create antifragile governance. Each jurisdiction learns from the others’ failures. No single point of regulatory capture can lock the market. The worst outcome would be a single global framework designed by the incumbents it is supposed to regulate.
Small models for real problems</h3>
The public attention stays glued to frontier labs and trillion-parameter model announcements. Meanwhile, the most useful AI work is happening at the other end of the scale.
A 7-billion-parameter model, fine-tuned on the right data and deployed on the right hardware, can outperform a frontier model on a specific task. It can run on a laptop. It does not require an API key. It does not disappear when your vendor changes its terms of service. For the majority of business problems, small and specific beats large and general. The only reason anyone pretends otherwise is because the people selling large-and-general have much bigger marketing budgets.

Openness is not a threat to safety. Closed systems hide their risks. Open systems expose them. If you had to choose which one you wanted running your bank, you would choose the one you could audit. </blockquote>
What policy-makers must do
Protect and fund open-source AI. Open-weight models are the single greatest democratising force in AI today. Policy must resist industry pressure to regulate openness out of existence under the banner of “safety”. Closed systems are not safer. They are just less accountable.
Create public AI testbeds. Governments should offer sandbox environments where startups, researchers, and civic organisations can experiment with AI at scale without commercial cloud costs. Universities are one place. National compute facilities are another. The point is to lower the cost of trying.
Harmonise, don’t homogenise. International AI governance should pursue interoperability between regulatory frameworks, not a single standard controlled by incumbents. Let a thousand experiments bloom. Then share the results. Convergence, if it happens, should emerge from what works, not from who lobbies hardest.
Make public data public. Health records, agricultural data, climate measurements, transport patterns. Anonymised and available to domestic researchers and entrepreneurs by default. Data sitting in government silos is capability left on the floor. It is also, in most cases, paid for by the same taxpayers who are now denied access to it.
Speaking partners</h3>
Linux Foundation AI & Data. Apache Software Foundation. Mozilla Foundation. CERN, whose open infrastructure heritage extends well beyond the invention of the web. National research councils. The growing network of sovereign AI initiatives, including France’s Mistral, the UAE’s open-model programmes, and China’s open-source labs. Plus the academic research community keeping open benchmarks and open evaluation honest.
What individuals & companies can do
Contribute to open datasets. AI is only as good as its training data. If you speak an underrepresented language, contribute to projects like Common Voice or local Wikipedia initiatives. Your voice, literally, makes the next generation of models more equitable.
Teach someone. The most effective scaling mechanism in AI is not compute. It is people. Run a workshop. Write a tutorial. Mentor a junior developer. Knowledge that stays in one head is wasted infrastructure.
Open-source your non-differentiating AI work. The tooling, pipelines, and evaluation frameworks you build internally are rarely your competitive advantage. They are, however, someone else’s entry barrier. Releasing them builds ecosystem, reputation, and talent pipeline at the same time.
Hire globally. If your AI team sits in one timezone, you are not serious about democratisation. You are also leaving talent on the table. Remote-first AI teams staffed across continents are not a moral compromise. They are a strategic advantage.

03. Opportunities</h2>
The analysis
Local models for local problems</h3>
The most transformative applications of AI will not come from general-purpose frontier models.
They will come from smaller, domain-specific models trained on local data. Agricultural yield prediction in sub-Saharan Africa. Flood routing in Bangladesh. Legal document parsing in Brazilian Portuguese. Swedish patient records. Finnish tax law. These models do not need to be the largest. They need to be the most relevant. The frontier labs have no comparative advantage in any of them.
The talent arbitrage</h3>
There are more software developers outside the United States than inside it. As AI tooling matures, the barrier shifts from “can you build a model” to “do you understand the problem”.
Domain expertise in healthcare, logistics, education, and governance is globally distributed. The organisations that pair local knowledge with accessible AI infrastructure will outperform those still hoarding compute in one zip code. This is not a speculation. It is already happening, quietly, in places the press does not usually cover.
Sovereign AI as economic policy</h3>
Nations that invest in domestic AI capability, training clusters, open datasets, technical education, are not just making a technology bet. They are building economic resilience.
Sovereign AI capacity means the ability to inspect, adapt, and govern the systems that run your economy. The 21st-century equivalent of energy independence. And like energy independence, it cannot be retrofitted cheaply. The countries that start building now will be a decade ahead of the ones that wait.
The compound effect of open</h3>
Every capable open model that gets released lowers the barrier for the next one.
Every open dataset makes the next training run cheaper. Every open evaluation framework makes the next model more honest. Every open deployment tool makes the next application faster to ship. This is not a linear improvement. It is compounding. The open stack in 2026 is more capable than the closed stack was in 2023. Extrapolate that by another three years and the competitive picture looks very different.

The question is not whether AI will be everywhere. It already is. The question is whether “everywhere” includes the people who need it most. And whether they get to shape it, not just consume it. </blockquote>
What policy-makers must do
Treat AI education as infrastructure spending. Every euro spent training a machine learning engineer domestically returns in reduced dependency on foreign AI services. Embed AI literacy in secondary education. Fund university research with open-access strings attached. Results paid for by the public should be available to the public.
Incentivise local AI deployment. Tax credits, grants, and procurement preferences for companies deploying AI solutions built on domestic or open-source infrastructure. Make it cheaper to build locally than to import from a hyperscaler. Right now, the incentives run the wrong way.
Build data commons. National datasets, anonymised and indexed, available to domestic researchers and entrepreneurs by default. The Nordic countries have already shown what is possible with public health and education data. Extend the model. Broaden the coverage. Accelerate the access.
Invest in language-specific AI as critical infrastructure. A frontier model that struggles with Swedish legal text or Finnish medical records is not just an inconvenience. It is a gap. And a gap somebody has to fill, either with domestic capability or with dependency on whoever owns the next model generation. Choose now.
Speaking partners</h3>
World Bank Digital Development. ITU. Regional development banks. Domestic chambers of commerce. University AI labs. And the countries already executing sovereign AI strategies, including several Nordic nations, Singapore, and a growing list of governments treating AI capacity as industrial policy rather than procurement.
What individuals & companies can do
Build something small that matters. You do not need a frontier model to change a workflow. A fine-tuned 7B model running on a modest machine can automate document classification, triage support tickets, or summarise meeting minutes. Start with a problem you know. The technology will meet you halfway.
Join a community. Local AI meetups, open-source contributor groups, and online collectives like EleutherAI and LAION are where the real democratisation is happening. Not in press releases. Show up. Build in public. Share what you learn.
Become a platform, not just a consumer. If your company benefits from AI, consider what you can offer back. Compute credits for local researchers. Anonymised datasets. Mentorship programmes. API access for non-profits. The ecosystem that feeds you is the same one you should be feeding.
Measure AI independence. Add a metric to your risk dashboard: what percentage of your AI capability would survive if your primary provider tripled its prices tomorrow? If the answer is uncomfortable, start building alternatives today. Not next year.

Conclusion</h2>
Democratizing AI is not charity. It is risk management.
Concentrated capability produces fragile systems. Single points of failure in supply chains. Monocultures in decision-making. Political leverage that no technology company should hold. Distributing capability produces the opposite. Resilience. Diversity. The kind of redundancy that lets civilisations survive surprises.
The tools exist. The talent exists. What remains is coordinated action. From the policy-makers who set the rules. From the companies that deploy the technology. From the individuals who refuse to accept that intelligence should be someone else’s monopoly.

The question is not whether AI will be everywhere. It already is. The question is whether “everywhere” includes the people who need it most. And whether they get to shape it, not just consume it. </blockquote>

Dark Harvest

Knowledge as code

02. Solutions</h2>
The analysis</strong></p>

03. Opportunities</h2>
The analysis</strong></p>

Catching up

02. Solutions</h2>
The analysis</strong></p>

03. Opportunities</h2>
The analysis</strong></p>

Frugal IT

01. Problems</h2>
The analysis</strong></p>

02. Solutions</h2>
The analysis</strong></p>

03. Opportunities</h2>
The analysis</strong></p>

Democratizing AI

01. Problems</h2>
The analysis</strong></p>

02. Solutions</h2>
The analysis</strong></p>

03. Opportunities</h2>
The analysis</strong></p>

Dark Harvest

Knowledge as code

02. Solutions</h2> The analysis</strong></p>

03. Opportunities</h2> The analysis</strong></p>

Catching up

02. Solutions</h2> The analysis</strong></p>

03. Opportunities</h2> The analysis</strong></p>

Frugal IT

01. Problems</h2> The analysis</strong></p>

02. Solutions</h2> The analysis</strong></p>

03. Opportunities</h2> The analysis</strong></p>

Democratizing AI

01. Problems</h2> The analysis</strong></p>

02. Solutions</h2> The analysis</strong></p>

03. Opportunities</h2> The analysis</strong></p>

02. Solutions</h2>
The analysis</strong></p>

03. Opportunities</h2>
The analysis</strong></p>

02. Solutions</h2>
The analysis</strong></p>

03. Opportunities</h2>
The analysis</strong></p>

01. Problems</h2>
The analysis</strong></p>

02. Solutions</h2>
The analysis</strong></p>

03. Opportunities</h2>
The analysis</strong></p>

01. Problems</h2>
The analysis</strong></p>

02. Solutions</h2>
The analysis</strong></p>

03. Opportunities</h2>
The analysis</strong></p>