The post Nordic Digital Infrastructure 2026 | Cloud & Enterprise Analysis appeared first on T-21.

The post Nordic Digital Infrastructure 2026 | Cloud & Enterprise Analysis appeared first on T-21.

For the current generation of AI startups, cloud credits have become the de facto currency of early-stage infrastructure. Accelerator programmes from Y Combinator, Microsoft for Startups, Google for Startups, and AWS Activate routinely distribute credit packages ranging from $50,000 to $350,000 across providers including Azure, Google Cloud, AWS, and increasingly the API platforms of model providers like OpenAI, Anthropic, and Cohere. These credits are meant to give startups runway to build, train, and deploy without upfront infrastructure costs. In theory, the system works. In practice, it is creating a set of problems that few people in the ecosystem are willing to discuss openly.

The credit allocation mismatch

The core issue is straightforward: the credits startups receive rarely match the infrastructure they actually need.

A startup accepted into a major accelerator programme might receive $150,000 in Google Cloud credits and $100,000 in Azure OpenAI credits as part of a standard partner package. But if the founding team has built its stack on AWS Bedrock with Anthropic’s Claude as the primary model, a significant portion of those credits sits unused. The startup cannot transfer them. It cannot combine them. In most cases, it cannot even convert Google Cloud credits into Google Cloud AI API credits for a different service tier within the same provider.

The result is that AI startups across the ecosystem are sitting on tens of thousands of dollars in credits they cannot use, while simultaneously paying full price for the compute they actually need. According to estimates from secondary market participants, more than $2 billion in AI credits expire unused every year across the major cloud providers. For startups operating on eighteen-month runways, that waste is not an abstraction — it is the difference between an additional engineer and an earlier funding round.

What the credits actually cost

The sticker price of AI compute has declined on a per-token and per-GPU-hour basis over the past two years. But the effective cost for startups has not fallen proportionally, for several reasons.

First, the models themselves have become more capable but also more expensive to run at production scale. A startup using GPT-4o or Claude Sonnet for real-time inference in a customer-facing product is spending meaningfully more per request than one that used GPT-3.5 two years ago. The quality improvement justifies the cost in most cases, but it compresses margins and accelerates credit burn.

Second, fine-tuning and evaluation pipelines consume credits at rates that are difficult to predict during the experimentation phase. A team iterating on a retrieval-augmented generation architecture might burn through $20,000 in credits over a two-week sprint without producing a production-ready system. That is an expected part of the development process, but it means that a $100,000 credit package provides less effective runway than founders anticipate when they receive it.

Third, multi-model architectures are becoming standard practice. Startups increasingly use different models for different tasks within the same product — a smaller model for classification, a larger model for generation, a specialised model for code or structured output. Each model may run on a different provider’s infrastructure, multiplying the number of credit accounts that need to be funded and managed.

The secondary market response

The mismatch between credit allocation and credit consumption has created a growing secondary market. Platforms have emerged where startups and enterprises can trade unused credits — selling what they cannot use and buying what they need at discounts that typically range from twenty to forty percent below list price.

For a startup sitting on $150,000 in Google Cloud credits it cannot use, the ability to sell google cloud credits and recover even sixty to seventy percent of the face value represents a meaningful extension of runway. Conversely, for a team that has committed to Google’s ecosystem but exhausted its initial allocation, the option to buy google cloud credits at a significant discount from the secondary market is an obvious efficiency gain.

The model is not dissimilar to what happened in other enterprise software markets as cloud adoption matured. Unused software licences, reserved instance commitments, and prepaid SaaS contracts all eventually developed secondary markets as buyers and sellers recognised the inefficiency of letting paid-for capacity go to waste.

What makes AI credits slightly different is the velocity at which they lose value. Most credit packages expire within twelve to eighteen months. Unlike a reserved EC2 instance that provides predictable compute capacity over a three-year term, an AI credit package is a depreciating asset from the moment it is issued. Every month that passes without using the credits reduces their effective value — not because the credit amount changes, but because the window for extracting value from them narrows.

Provider dynamics and the credit ecosystem

The major cloud and AI providers have complex incentives around the credit ecosystem. On one hand, credits are a customer acquisition tool. Google, Microsoft, Amazon, and the model API providers distribute credits generously because they want startups to build on their platforms, creating long-term lock-in that generates revenue well beyond the initial credit period. On the other hand, unused credits that expire represent recognised revenue without corresponding infrastructure cost — a favourable outcome from a pure financial perspective.

This creates a tension that the providers have not resolved publicly. The official terms of service for most credit programmes prohibit transfer or resale. But enforcement has been inconsistent, and the practical reality is that the secondary market exists and is growing because it solves a genuine problem for both buyers and sellers.

For streaming and media technology companies — the core audience of this publication — the dynamics are particularly relevant. Media AI workloads including automated transcription, content moderation, video understanding, and recommendation systems are among the most compute-intensive applications in production today. A mid-stage media technology startup might be spending $30,000 to $50,000 per month on inference costs alone. At those consumption rates, a twenty to thirty percent discount on credits through secondary channels is not a minor optimisation — it is a material impact on unit economics.

What this means for the market

The AI credit economy is still in its early stages. As the market matures, several things are likely to happen. Credit terms will become more standardised, making them easier to value and trade. Providers may introduce official transfer mechanisms as they recognise that rigid credit allocation discourages multi-cloud adoption without actually preventing it. And startups will become more sophisticated about credit management as a financial discipline — treating compute credits with the same rigour they apply to cash management and equity dilution.

For now, the practical advice for AI startups is simple. Audit your credit portfolio regularly. Know what you have, when it expires, and whether you are actually going to use it. If the answer is no, explore the secondary market before the expiration date turns your credits into a write-off. The compute bill is already one of the largest line items on an AI startup’s P&L. Letting paid-for credits expire unused is one of the few costs that is entirely avoidable.

The post The Hidden Compute Bill: Why AI-First Startups Are Burning Through Credits Faster Than Runway appeared first on T-21.

The post The Hidden Compute Bill: Why AI-First Startups Are Burning Through Credits Faster Than Runway appeared first on T-21.

Sam Cooper is the founder of Flowpast, a consultancy that helps organisations implement AI-driven workflow automation across their operations. Rather than building bespoke AI models, Flowpast focuses on the automation layer — connecting existing tools, eliminating manual process steps, and building the operational infrastructure that allows AI capabilities to deliver value at scale. We spoke with him about why workflow automation is becoming a priority for media and technology organisations, where the biggest efficiency gains are hiding, and what streaming operations teams should consider before investing in another AI tool.

The workflow problem in media operations

T-21: You work with organisations across several industries. What patterns do you see when companies come to you for help with automation?

Sam Cooper: Almost universally, the organisations we work with have already invested in capable tools. They have good encoding platforms, decent monitoring systems, functional content management. The problem is rarely that they lack technology — it is that the technology does not talk to itself. A file lands in an ingest system, someone manually checks the metadata, emails a team to confirm the delivery specification, waits for approval, then triggers the transcode job. Each individual step takes five minutes. But when you chain twenty of those steps together across a content pipeline that handles hundreds of assets per day, you have built a system that runs on human memory and email threads. That is where things break.

T-21: Is this specific to media and streaming, or is it a broader problem?

Sam Cooper: It is universal across data-intensive industries, but media operations have some unique characteristics that make the problem particularly acute. Content pipelines are time-sensitive — a live event has a hard deadline that does not move. The number of output formats and delivery specifications has exploded — a single piece of content might need to be transcoded into fifteen different profiles for different platforms and territories. And the volume has increased dramatically while team sizes have stayed flat or shrunk. When you combine time pressure, format complexity, and volume growth with manual handoff processes, the result is predictable: errors, bottlenecks, and teams that spend their time firefighting instead of improving their systems.

Automation before optimisation

T-21: You have a phrase you use with clients — “automate before you optimise.” What does that mean in practice?

Sam Cooper: It means that most organisations try to make individual steps faster when they should be eliminating steps entirely. I will give you a concrete example. A streaming platform we worked with had invested in an AI-powered quality assessment tool that could analyse transcoded output and flag artefacts in near real-time. Impressive technology. But the output of that tool was a report that was emailed to a QC team, who would manually review it, log the findings in a spreadsheet, and then send a re-transcode request through a ticketing system. The AI tool was doing its job in seconds. The human workflow around it was adding hours of latency.

As an AI workflow consultant, what we did was not replace the QC tool or build a better model. We automated the surrounding process — the quality assessment output now triggers conditional logic that either auto-approves clean assets, routes flagged assets directly into a re-transcode queue with the correct parameters, or escalates genuinely ambiguous cases to a human reviewer with all the relevant context pre-assembled. The AI model did not change. The workflow around it transformed the actual operational impact.

T-21: That sounds straightforward. Why do organisations struggle to do this on their own?

Sam Cooper: Two reasons. First, workflow automation sits in an organisational gap. The engineering team builds and maintains the tools. The operations team runs the processes. Nobody owns the connective tissue between them. When we come in, we are often the first people who have mapped the entire end-to-end process from ingest to delivery and asked the question: where does a human touch this, and does that touch add judgment or just add latency?

Second, there is a cultural bias towards building new capabilities rather than connecting existing ones. It is more exciting to pitch a board on an AI-powered content recommendation engine than to explain that you automated forty-seven manual steps in your content supply chain. But the forty-seven manual steps are costing you more money and causing more operational risk than the absence of a recommendation engine ever will.

The economics of workflow automation

T-21: How do you quantify the return on automation investment for clients?

Sam Cooper: We measure three things. First, time recovered — how many hours per week were spent on manual process steps that are now automated. This is the easiest to measure and the most immediately visible. Second, error reduction — how many re-transcodes, missed deliveries, or specification errors were caused by manual process failures. Every error in a content pipeline has a cost, whether that is a re-processing charge, a late delivery penalty, or a customer experience impact. Third, and this is the one that takes longer to materialise, throughput capacity — how much additional volume can the existing team handle without adding headcount. That third metric is where the long-term economics become compelling. If your operations team can handle thirty percent more content volume without hiring, the cost avoidance over two or three years dwarfs the automation investment.

T-21: Are there areas within streaming and broadcast operations where you see particularly high automation potential that organisations are not yet addressing?

Sam Cooper: Metadata management is the big one. The amount of manual metadata entry, validation, and correction happening across the industry is staggering. Every content asset needs technical metadata, descriptive metadata, rights metadata, localisation metadata, and platform-specific metadata. Much of this information already exists somewhere in the supply chain but is being manually re-entered or copy-pasted between systems. Automating metadata propagation and validation across the content lifecycle is probably the single highest-return automation project most media organisations could undertake today.

The other area is compliance and regulatory reporting. As content regulation becomes more complex across different territories, the reporting burden on operations teams is increasing. Automating the assembly of compliance documentation from existing system data is a significant opportunity that most organisations have not yet addressed systematically.

Advice for operations teams

T-21: For streaming or broadcast operations teams reading this who want to start their automation journey, where should they begin?

Sam Cooper: Map your processes before you buy any tools. Literally draw the flow of a content asset from the moment it arrives to the moment it reaches the end consumer. Mark every point where a human intervenes. Then ask yourself at each of those intervention points: is this person adding judgment, or are they acting as a manual integration layer between two systems? If the answer is the latter, that is your automation candidate.

Start with one workflow. Do not try to automate everything at once. Pick the process that fails most visibly or most frequently, automate it well, measure the impact, and use that evidence to build organisational confidence for the next project. Automation adoption in operations teams is as much a change management challenge as it is a technical one. Showing your team that automation makes their work better rather than replacing their jobs is essential for long-term success.

T-21: Sam, thank you for your time.

Sam Cooper: Thank you. The media and streaming industry is at an inflection point where the competitive advantage shifts from having the best individual tools to having the best-connected operational systems. The organisations that figure that out early will be significantly more efficient than their competitors within two or three years.

The post Why Streaming Operations Teams Are Automating Before They Optimise: A Conversation with Sam Cooper appeared first on T-21.

The post Why Streaming Operations Teams Are Automating Before They Optimise: A Conversation with Sam Cooper appeared first on T-21.

The distinction that matters is not whether AI valuations are inflated. Most informed observers accept that some correction is likely. The question that should concern broadcast engineers and media technology leaders is more specific: what happens to the production infrastructure that now depends on AI services if the companies providing those services restructure, reprice, or disappear?

Valuation Risk Is Not Technology Risk

It is worth separating two things that often get conflated. The underlying capabilities that machine learning brings to media workflows — automated transcription, intelligent metadata tagging, content-aware encoding, real-time language translation — are not going away. These are genuine technical advances that solve real operational problems.

What could change rapidly is the commercial landscape around them. The current AI market is characterised by enormous capital expenditure with limited near-term revenue to match. Cloud providers and AI platform companies are spending at a pace that assumes adoption curves will justify the investment within a few years. If those curves flatten or the returns take longer than projected, pricing models will change. Some providers will consolidate. Others will exit.

For a broadcaster running a 24/7 news operation where AI-powered transcription feeds downstream captioning, translation, and metadata workflows, a provider changing its API pricing by 300% or deprecating a model version is not an abstract financial event. It is an operational crisis.

The Dependency Problem

The more pressing concern is architectural. Over the past three years, media organisations have woven AI services into their workflows at an accelerating pace. MAM systems now rely on AI for automated tagging. Playout automation uses machine learning for content verification. Editorial tools depend on large language models for draft generation and summarisation.

In many cases, these integrations point directly at a single provider’s API. The workflow does not just use AI — it depends on a specific vendor’s implementation of AI. That is a fundamentally different risk profile.

The smart architectural response is abstraction. Organisations that have built orchestration layers between their workflows and the underlying AI models can swap providers without redesigning their entire production chain. Those that have hardcoded a specific provider’s SDK into their automation platform face a much harder migration path if circumstances change.

Microsoft’s Azure AI services, for example, now underpin a significant portion of enterprise media workflows through their integration with tools like Azure Media Services and the broader cognitive services suite. Google’s Vertex AI platform similarly powers an expanding range of media processing pipelines, from automated content moderation to real-time speech recognition. When organisations build directly against these platforms without an abstraction layer, they are making a bet not just on the technology but on the commercial stability and pricing trajectory of that specific provider.

Workforce Decisions Compound the Risk

There is a secondary risk that connects directly to the valuation question. Many media organisations have used the promise of AI-driven efficiency to justify workforce reductions. Headcount has been cut based on projected gains from tools that, in some cases, have been in production for less than a year.

If AI investment contracts and the efficiency gains do not materialise at the scale used to justify those reductions, these organisations face a compounded problem. They have fewer people to manage workflows that may suddenly require more human intervention, at exactly the moment when the automated systems they relied on become less reliable or more expensive.

This is not a hypothetical scenario. It is the predictable outcome of making permanent structural decisions based on technologies whose commercial trajectory is still uncertain.

What Broadcast Organisations Should Be Doing

None of this argues against using AI in broadcast workflows. The technology delivers genuine value in transcription, metadata generation, content analysis, quality monitoring, and dozens of other applications. Walking away from these capabilities would be operationally foolish.

But the way these capabilities are integrated matters enormously. Three principles should guide how broadcast organisations approach AI infrastructure in the current environment.

First, treat AI as a service layer, not a foundation. Workflows should be designed so that the AI component can be replaced without triggering a cascade of downstream failures. This means API abstraction, standardised data formats between pipeline stages, and explicit fallback procedures.

Second, maintain vendor optionality. Any workflow that depends on a single AI provider for a critical function should have a documented alternative path. This does not mean running parallel systems in production. It means having tested the migration path and knowing what it takes to execute it.

Third, preserve operational knowledge. The institutional understanding of how workflows function — including the manual processes that AI replaced — should not be allowed to disappear entirely. If automated transcription fails at scale during a breaking news event, someone needs to know how to manage the fallback. That knowledge evaporates quickly once the people who held it leave the organisation.

The AI capabilities now embedded in broadcast infrastructure are real and valuable. The commercial landscape supporting them is less certain than the technology itself. Building workflows that acknowledge both of those realities is not pessimism. It is engineering discipline.

The post Is Broadcast’s AI Infrastructure Built on Stable Ground? appeared first on T-21.

The post Is Broadcast’s AI Infrastructure Built on Stable Ground? appeared first on T-21.