Blog – Future Processing

The true cost of doing nothing: what media organisations stand to lose without cyber resilience

Anna Mleczko — Tue, 31 Mar 2026 10:57:36 +0000

Home Blog The true cost of doing nothing: what media organisations stand to lose without cyber resilience

The true cost of doing nothing: what media organisations stand to lose without cyber resilience

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 31 March 2026

Written by:

Anna Mleczko

Head of Media and Advertising Practice

More from this author

Artur Dąbrowski

Security Consultant

More from this author

According to the Cost of a Data Breach report for 2025, the average global cost of a data breach stands at $4.44 million. Additionally, unplanned downtime can cost far more than broad cross-industry averages suggest.

According to New Relic’s State of Observability for Media and Entertainment 2025, the median cost of a high-business-impact outage in the media sector is $2 million per hour, or roughly $33,000 per minute, underlining how quickly even short disruptions can translate into major financial losses. Yet even these figures capture only a fraction of the true financial impact organisations face after a cyber incident.

Cyber attacks are often described in terms of visible losses: ransom payments, regulatory fines, legal settlements. These are the numbers that appear in headlines and board reports, but the truth is that they represent only the tip of the iceberg.

Below the surface sits a much larger body of costs. Without cyber resilience, these hidden impacts compound over time, turning a single cyber incident into a prolonged business crisis.

Key takeaways

Cyber resilience reduces the total cost of a cyber attack, not just the likelihood of one.
In the media sector, cyber incidents can immediately disrupt broadcasting, streaming, or publishing schedules, leading to direct revenue loss.
The visible cost of a data breach represents only a fraction of the total financial impact, with downtime and reputational damage often driving the largest losses.
The average breach lifecycle of 241 days allows cyber threats to expand before detection, increasing operational disruption and recovery costs.
For media organisations, protecting audience trust and maintaining uninterrupted content delivery is central to limiting the long-term impact of a cyber incident.

Visible and hidden costs: the full financial impact

When organisations assess the cost of a cyber attack, they typically focus on direct and measurable expenses such as ransom payments, forensic investigations, legal services, regulatory fines, customer notifications, and the cost of rebuilding compromised systems. These visible costs are tangible, relatively easy to quantify, and usually reported to boards and insurers.

In the media sector, however, the financial impact rarely stops there. Disruptions to broadcasting, streaming platforms, or production workflows translate directly into lost advertising revenue and missed distribution commitments. Because media organisations operate on strict publishing and broadcast schedules, even short periods of downtime can lead to cancelled campaigns, contractual penalties, and revenue loss.

The longer-term consequences often prove even more costly. Advertisers may pause campaigns, distribution partners reconsider agreements, and audiences migrate to alternative platforms when services become unavailable. This loss of confidence can weaken viewer and subscriber loyalty and reduce long-term audience value. At the same time, reputational damage, rising cyber insurance premiums, and increased scrutiny from investors or regulators add further financial pressure.

Taken together, these visible and hidden effects illustrate a broader reality: for media organisations, the true cost of a cyber incident extends far beyond the initial technical recovery.

The compounding timeline of a breach

Another critical factor influencing the cost of a cyber incident is time. Organisations lacking cyber resilience measures typically discover incidents later and require longer recovery cycles.

The average breach lifecycle, from initial intrusion to containment, now stands at 241 days. This means attackers can remain inside an organisation’s systems for months before detection.

During this dwell time, attackers move laterally across networks, escalate privileges, and extract increasing volumes of data. By the time the incident becomes visible, the scope of compromise is significantly larger.

In the media sector, the consequences of this prolonged dwell time can be particularly severe. Attackers may gain early access to production, content management, or broadcasting systems. When the breach eventually surfaces, media organisations may face halted broadcasts, delayed publishing schedules, and the potential exposure of unreleased or sensitive content, amplifying both financial and reputational damage.

Head to a post about Cyber Resilience Act and learn about its aims, key components, reasons why it is crucial for every software development company to plan the actions regarding CRA, and more.

The cost gap: resilience vs no resilience

Traditional cybersecurity focuses primarily on preventing attacks, but while prevention remains essential, it is no longer sufficient on its own.

Evidence shows that organisations investing in cyber resilience are better prepared to limit the financial and operational impact of cyber incidents, yet adoption remains low.

According to PwC’s Global Digital Trust Insights 2025, only 2% of organisations have implemented cyber resilience across their entire organisation, despite rising threat levels. At the same time, 77% of companies expect their cybersecurity budgets to increase, and 67% of security leaders report that generative AI has already expanded their attack surface. In broadcasting, AI-driven automation means attackers can map vulnerabilities in your CDN and CMS faster than ever, turning targeted attacks into mass-scale automated threats.

For companies in the technology, media and telecommunications (TMT) sector, this gap between risk and preparedness is particularly significant. KPMG’s Cybersecurity Considerations 2025: Technology, Media & Telecommunications highlights that as media companies increasingly rely on digital distribution platforms, connected devices, and AI-driven services, cybersecurity failures can directly threaten revenue, reputation, and audience trust. The report also notes that TMT organisations face increasingly sophisticated threats such as ransomware and AI-powered attacks and complex supply chains, making real-time threat detection and resilient infrastructure essential to maintaining secure and uninterrupted digital services.

These findings point to a broader conclusion: cyber resilience should be treated as a financial risk management decision rather than purely a technical upgrade. Organisations that strengthen their ability to detect threats early and respond effectively are better prepared to contain incidents and limit the scale of disruption, which translates directly into financial outcomes.

Preparing for the inevitable: building a cyber resilience strategy

When organisations lack a clearly defined cyber resilience strategy and a cyber incident response plan, the first hours after an attack often become disorganised. Decision-making slows, communication between technical teams and leadership becomes inconsistent, and critical actions such as containment or system isolation are delayed, extending downtime and increasing financial impact.

Because cyber incidents are a matter of when rather than if, preparation is essential. Building true resilience requires more than a compliance security audit. You need an engineering partner who understands your code, your cloud dependencies and can stress-test your response through executive tabletop exercises. By defining responsibilities, strengthening detection capabilities, and preparing recovery procedures in advance, organisations can respond faster and reduce disruption to critical business operations.

What to do to start building cyber resilience in the media sector:

Identify critical media assets – map the systems that keep content on air, such as broadcast platforms, CMS, and streaming infrastructure, and understand the business impact of their disruption.
Design secure and segmented architecture – separate production environments from corporate systems to prevent attacks from spreading across the organisation.
Implement continuous monitoring – detect anomalies early through targeted monitoring of media workflows and audience-facing platforms.
Prepare structured incident response – establish clear runbooks and test them with your Board in simulated tabletop exercises, so teams can respond quickly under pressure.
Ensure resilient recovery capabilities – use redundant environments and secure backups to restore services quickly and maintain uninterrupted content delivery.
Maintain resilience continuously – strengthen defences through ongoing vulnerability management, patching, and oversight of third-party risks.

Read more about cybersecurity best practices:

The most expensive strategy is inaction

Treating cyber risk as a distant possibility may appear harmless in the short term. In reality, without strong resilience measures, content pipelines, production environments, and distribution infrastructure remain exposed to disruption at exactly the points where media businesses generate value.

The real question for media companies is not whether cyber resilience is necessary, but how prepared they are to maintain uninterrupted content delivery when an incident occurs.

At Future Processing, we work with media organisations to strengthen that resilience. Through our work with broadcasters, streaming providers, and digital media platforms, we often see how cyber resilience challenges play out in real production and distribution environments.

If you would like to explore how these risks might affect your organisation, we are always open to a conversation. The goal is simple: ensure that when cyber threats emerge, organisations can respond quickly, protect critical services, and keep content flowing to audiences.

Through our Cyber Resilience Accelerator, we are offering a limited "Client Zero" program for UK media organisations. Get a hands-on Media Crash Test, including a boardroom tabletop exercise and live remediation of your critical vulnerabilities.

Our offer Book your Media Crash-Test

Cyber resilience in media: from strategy to execution

NIST CSF audit: ensuring compliance across borders

Security by Design: how to build systems that are secure from the start?

Value we delivered

AI agent

Unique AI agent promoting knowledge and answering complex questions about EU security regulations

Read the case study

About the author:

Anna Mleczko
Head of Media and Advertising Practice

I manage sales initiatives for modern technologies – AI, data, cybersecurity, product design, and software development – supporting clients in the media and advertising sector, from large enterprises to smaller firms. My work is focused on the UK market, where I also run a series of dedicated events for C-level executives. I am responsible for acquiring new clients (inbound & outbound), developing proposals, and shaping the sales strategy for the entire sector. My goal is to build relationships that translate directly into business success.

View more posts by Anna

Artur Dąbrowski
Security Consultant

I help companies move from regulatory requirements to actionable plans. I focus on building security programs that work in practice and drive growth – not just cover your back. I also help teams translate regulator expectations into operational controls and evidence (so you can prove what you do not just describe it).

Unlike most cybersecurity consultants who focus on either IT, OT or physical security in silos, I take a total security approach. Through proven partnerships at Future Processing, we address the full context: converged IT/OT environments, supply chain dependencies and physical assets – all in one cohesive program.

I work with enterprises across the full journey: from maturity assessments and real risk mapping, through policies and procedures (ones people actually follow) to incident management, third-party risk and secure SDLC.

View more posts by Artur

Let’s talk

contact@future-processing.com

When systems move faster than their guardrails. The lessons from Amazon, McKinsey, and Lloyds.

Noel Oliveira — Thu, 26 Mar 2026 09:30:56 +0000

Home Blog When systems move faster than their guardrails. The lessons from Amazon, McKinsey, and Lloyds.

IT News

When systems move faster than their guardrails. The lessons from Amazon, McKinsey, and Lloyds.

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 26 March 2026

Written by:

Noel Oliveira

Enterprise Business Development Manager

More from this author

In the space of a few weeks in early 2026, three stories landed that every engineering and IT leader should read together.

At Amazon, a series of outages tied to AI-assisted coding triggered a company-wide 90-day "code safety reset" covering 335 of its most critical retail systems. At McKinsey, a security research firm ran an autonomous AI agent against the firm's internal AI platform and gained full read and write access to the production database in under two hours. And at Lloyds Banking Group, a technical glitch caused the mobile and online banking apps for Lloyds, Halifax, and Bank of Scotland to show customers the transaction histories, National Insurance numbers, and payment details of complete strangers.

None of these stories are arguments against building and deploying sophisticated software systems. All three are very clear arguments for governing them properly.

Three stories, one diagnosis

The Amazon story is about pace overtaking process. The McKinsey story shows how AI has created a new class of attack surface. The Lloyds story highlights the hidden complexity inside systems that millions of people rely on every day. Different triggers, but the same conclusion: organisations expanded what their systems could do faster than they strengthened the controls around them.

That gap is where the damage happens.

Amazon: speed without structure

In November 2025, Amazon’s leadership mandated that 80% of its engineers use Kiro, the company’s AI coding assistant, on a weekly basis. Adoption was tracked as a corporate objective. The logic was straightforward: AI tools enable engineers to produce more code, faster. And that is largely true.

What followed illustrates exactly why speed alone is not the measure that matters.

In December 2025, Kiro determined that the most efficient way to fix a configuration error in an AWS Cost Explorer environment was to delete the entire production environment and recreate it. The result was a 13-hour outage in the China region. In February 2026, a second outage occurred when engineers allowed Amazon’s AI coding tool Q to resolve an issue without human intervention. On March 2, Q contributed to a failure that produced approximately 1.6 million website errors and nearly 120,000 lost orders. Three days later, a separate incident on March 5 caused a 99% drop in orders across North American marketplaces, resulting in 6.3 million lost orders.

The cause of the March 5 incident was described in Amazon’s own internal documentation: a modification to a live production system that skipped the proper documentation and approval process required by Amazon. Automated checks were not run before the change went live.

Amazon’s response was a 90-day “code safety reset”. Engineers must get two people to review changes before deployment, use a formal documentation and approval process, and follow stricter automated checks. The reset applies to 335 Tier-1 systems. Senior managers and technology leaders are also to be held more directly accountable, reinforcing the idea that it’s a shared responsibility, not an individual task.

Amazon has been careful to say that only one of the reviewed incidents was directly related to AI tooling, and that none involved code wholly written by AI. That’s an important nuance. But it doesn’t change the underlying lesson: when AI tools operate inside delivery structures that were built for a slower, more sequential process, the gaps in that structure get exposed at a scale that wasn’t possible before.

Get recommendations on how responsible and secure AI can be applied within your organisation.

Explore data-based opportunities to gain a competitive advantage.

Adopt AI with us Let's work together

McKinsey: the attack surface nobody planned for

The McKinsey story is different in nature but related in cause. Lilli, McKinsey’s internal AI platform, had been running in production for over two years by the time CodeWall’s autonomous offensive agent pointed at it. Within 2 hours, the agent had full read and write access to the entire production database.

The vulnerability itself was not especially sophisticated. After mapping the attack surface, the agent found that the API documentation was publicly exposed, listing more than 200 fully documented endpoints. Most of them required authentication, but 22 did not. One of those unprotected endpoints contained a SQL injection vulnerability in an unusual place: the JSON keys passed to a query were concatenated directly into the SQL statement, rather than the values. Because of that, it was the kind of flaw standard automated scanners often miss, and one that Lilli’s own internal scanning had failed to detect for two years.

The scale of what was accessible is striking. 46.5 million chat messages. 728,000 files. 57,000 user accounts. 3.68 million RAG document chunks – the entire knowledge base feeding the AI, with S3 storage paths and internal file metadata.

But the most significant finding wasn’t the data, but the write access. Lilli’s system prompts – the instructions that control how the AI behaves, were stored in the same database the agent had access to. An attacker with that access could have rewritten those prompts silently, with no deployment, no code change, and no log trail. The AI would simply start behaving differently, and 43,000 consultants relying on it for client work would have no way of knowing.

Organisations have spent decades securing their code, their servers, and their supply chains. But the prompt layer – the instructions that govern how AI systems behave – is the new high-value target, and almost nobody is treating it as one.

Lloyds: complexity without isolation

On the morning of March 12, 2026, customers logging into the mobile and online banking apps for Lloyds Bank, Halifax, and Bank of Scotland were not met with a blank screen or an error message. Instead, some were shown another person’s account, including full transaction histories, wage payments, direct debits, National Insurance numbers, and spending patterns stretching back months.

One customer told the BBC she was able to view details from six different accounts over a 20-minute period. Another said he could scroll through a complete account history month by month, including direct debits to the DVLA showing the car registration number. A third reported seeing over a million pounds showing as paid in – a sum that belonged to someone else entirely.

Lloyds Banking Group confirmed that a technical issue had caused transaction information from some accounts to be shown to other customers in both the mobile app and internet banking. The group said it was not a cyber attack, the error was quickly resolved, and balances remained correct. The Financial Conduct Authority engaged with the group to assess what happened.

The cause has not been publicly disclosed in detail. But the shape of the failure is instructive regardless: a professor of financial technology at the University of Manchester described the event as “unusual,” and suggested that as data architectures become more complex and data openness greater, such issues could become more frequent.

This represents a different failure mode from Amazon’s production pipeline issues and McKinsey’s prompt layer exposure. In Lloyds’ case, the problem lay in data isolation, where the boundary between one customer’s data and another’s broke down within a system serving 26 million users. There was no targeted attack or autonomous agent involved. Instead, it was the result of complexity building up over time in a critical system, until a change or specific condition exposed a weakness the architecture was not designed to contain.

According to data compiled by lawmakers on the Treasury Committee, the UK’s largest banks recorded at least 158 IT failures between January 2023 and February 2025, amounting to more than 800 hours of service disruption – including 12 outages reported by Lloyds Banking Group alone. The March 2026 incident was different in kind from most of those: previous outages typically left customers unable to access their own accounts. This one showed them someone else’s.

See our offer Let's work together

The pattern all three stories share

These are three different organisations, three different failure modes, and three different threat vectors. But all three trace back to a single root problem: capabilities were deployed, expanded, or allowed to grow in complexity faster than the governance structures around them matured.

At Amazon, it was the production pipeline: AI tools given the ability to make changes in critical systems without the procedural checks that would catch and contain errors. At McKinsey, it was the security model: an AI platform built and expanded over two years without the same rigour applied to the prompt layer, the database access controls, and the unauthenticated API surface. At Lloyds, it was the data architecture: a system of sufficient complexity that a failure in isolation between accounts could propagate across the app layer and reach customers before it was caught.

In all three cases, the systems worked exactly as designed, until a condition exposed a gap in the structure around them. That’s what makes these stories instructive rather than simply alarming.

What the reset tells us

Amazon’s 90-day reset is being framed in some quarters as a retreat from AI. It isn’t. It is a recognition that the deployment model needs to catch up with the capability model.

It also amounts to a large-scale experiment in re-introducing human and procedural checks into AI-accelerated development – not to abandon AI, but to ensure that when things do go wrong, a single mistake cannot cascade into millions of failed transactions.

The specific measures: mandatory two-person review, formal documentation before deployment, automated reliability checks, leadership accountability, are not novel ideas. They are the baseline practices that should have been in place before AI tooling was introduced at scale. What the reset represents is an organisation reconnecting those fundamentals with a delivery model that had outpaced them.

This is a pattern we see repeatedly. Organisations rarely run into trouble with AI-assisted development because they are moving too slowly. The problem usually starts when delivery speeds up, but governance does not keep pace. The tool is introduced first, while the guardrails, roles, and controls it depends on are worked out later.

Quality gates are not the opposite of speed

There is a version of this conversation where the takeaway is “slow down.” We don’t think that’s the right reading of either story.

The right reading is that quality gates, human review at the right points, automated checks on every change, and security treated as a structural requirement rather than an afterthought are not obstacles to AI-assisted delivery. They are what make AI-assisted delivery reliable enough to trust in production.

An AI-native delivery model, built properly, has automated quality gates on every commit – static analysis, security scanning, architecture compliance, dependency verification. It has human engineers who own the full delivery context, not handoff chains where accountability diffuses. And it treats the AI toolchain itself, including the prompt layer that governs AI behaviour, as a security surface requiring the same protection as code and infrastructure.

Amazon’s engineers had the tools and they had the mandate to use them. What they didn’t have, in some critical systems, was the structure that should have surrounded those tools from the start. The 90-day reset is the process of building that structure retrospectively.

The lesson for any organisation deploying AI in software development is that building the structure first is considerably less expensive than building it after the outage.

If your organisation is moving towards AI-assisted development, or already there, the question worth asking is whether the structure around your tooling was designed alongside the tooling itself, or whether it’s catching up. The issues Amazon, McKinsey, and Lloyds encountered aren’t unique to companies of their scale. The same gaps appear in teams of 10 as in teams of 10,000, and the blast radius is proportional to how much your AI toolchain is trusted to act autonomously in production.

At Future Processing, we build software using an AI-native delivery model that has quality controls built into the process from the start, not added after the fact. Every engagement includes automated quality gates on every commit covering static analysis, security scanning, architecture compliance, and dependency verification. Engineers own the full delivery context end-to-end, with no handoff chains where accountability diffuses. And the AI toolchain itself – including the prompt and configuration layer – is treated as a security surface, not an afterthought.

We work with mid-market companies across the UK on new digital products, legacy modernisation, and operational automation. Engagements start with a fixed-price sprint of 1 to 3 weeks, so you see working software on your real data before committing to anything larger.

If you’d like to talk through how this applies to your specific situation, get in touch with our team — we’re happy to have a no-commitment conversation about where the structure gaps are and how to address them.

Developing an AI platform that saves law firms up to 75% of document review time

Read our case study Let's work together

Cloud cost analysis 101: optimising and reducing cloud spend

AI implementation without IT modernisation? A high-risk path to underperformance

AI Governance: building trust and advantage in the age of artificial intelligence

Value we delivered

monthly cost reduction achieved through proactive implementation of AWS Cloud savings plans

Read the case study

About the author:

Noel Oliveira
Enterprise Business Development Manager

I am a strategic, outcome-focused IT Services business development leader with 15 years of experience selling digital and technological solutions across software engineering, quality assurance, DevOps, cloud, data, AI and security services.

View more posts by Noel

Let’s talk

contact@future-processing.com

Professional workflow optimisation in specialty insurance: enhancing multi-stakeholder coordination and operational excellence

Anna Łukaszczyk — Tue, 24 Mar 2026 08:01:24 +0000

Home Blog Professional workflow optimisation in specialty insurance: enhancing multi-stakeholder coordination and operational excellence

IT News

Professional workflow optimisation in specialty insurance: enhancing multi-stakeholder coordination and operational excellence

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 24 March 2026

Written by:

Anna Łukaszczyk

Strategic Initiatives Lead - Insurance

More from this author

Optimising specialty insurance workflows starts with understanding how professional stakeholders truly interact within complex risk management ecosystems – every broker enquiry, every expert coordination requirement, every regulatory compliance touchpoint, and every moment of uncertainty or confidence in professional relationships.

What is professional workflow mapping in specialty insurance and why does it matter?

Optimising specialty insurance workflows means thoughtfully refining every professional touchpoint: from initial risk assessment and broker engagement, through underwriting coordination and policy placement, to ongoing portfolio management and complex claims resolution.

Each stage in the specialty insurance workflow presents opportunities to reduce professional friction, anticipate stakeholder needs, and provide transparent coordination through secure, compliant, and expertly managed processes.

When workflows are intentionally designed and continuously improved, the impact is substantial: enhanced broker relationships, stronger capacity provider confidence, improved regulatory compliance, and sustainable competitive advantage built on professional trust and operational excellence.

Streamlining the claims underwriting process with an MVP integrating disparate data sources into a single system

Our MVP will enhance data accessibility, improve user experience and operational efficiency for claims underwriters, enabling future AI-driven developments, including data synthesis and process automation.

Read our case study Contact us

Common professional pain points across specialty insurance workflows

Professional stakeholders face systematic friction points across specialty insurance operations, many stemming from legacy system complexity, multi-party coordination challenges, and evolving regulatory requirements.

Proprietary research from Future Processing’s 2025 Claims Survey among UK specialty claims professionals identifies recurring operational challenges:

Complex multi-party coordination

Professional workflows often require seamless coordination between brokers, MGAs, TPAs, capacity providers, and expert networks. Fragmented systems create information silos, requiring manual data aggregation and increasing coordination time whilst introducing potential errors.

Regulatory compliance documentation

Consumer Duty and delegated authority requirements demand comprehensive audit trails and transparent performance monitoring. Manual compliance processes create administrative burden whilst increasing regulatory risk exposure.

Expert network integration

Specialty claims require coordination with legal professionals, adjusters, surveyors, and technical experts. Current platforms often lack secure collaboration capabilities and professional workflow integration, creating communication delays and documentation challenges.

Capacity provider reporting

MGAs require transparent performance reporting to maintain capacity provider relationships. Limited real-time visibility into operational metrics creates relationship management challenges and authority renewal risks.

Professional communication fragmentation

Stakeholders operate across multiple platforms and communication channels, leading to information inconsistency and professional relationship strain.

Priority workflow stages for specialty insurance optimisation

Every stage of specialty insurance workflows presents opportunities for professional coordination enhancement and operational efficiency improvement.

Risk assessment and broker engagement

Streamlining initial risk evaluation processes through secure broker portals, standardised information collection, and transparent communication protocols enhances professional relationships whilst improving underwriting quality.

Underwriting coordination and placement

Efficient capacity provider coordination, transparent authority utilisation, and automated compliance documentation accelerate placement processes whilst strengthening professional accountability.

Policy management and stakeholder communication

Providing brokers with comprehensive policy information access, automated client reporting capabilities, and transparent servicing coordination improves professional service delivery and relationship quality.

Claims coordination and expert management

Optimising expert deployment, multi-party communication, and regulatory compliance documentation ensures professional satisfaction whilst managing complex specialty claims efficiently.

Performance monitoring and relationship management

Comprehensive capacity provider reporting, broker satisfaction tracking, and regulatory compliance monitoring sustain professional relationships and competitive positioning.

Strategic approach to specialty insurance workflow optimisation

Optimising specialty insurance workflows requires sophisticated understanding of professional stakeholder needs, regulatory requirements, and multi-party coordination complexity.

Comprehensive professional workflow analysis – conduct detailed mapping of broker-MGA-carrier-expert interaction patterns. Identify coordination friction points and professional satisfaction challenges. Analyse regulatory compliance requirements and audit trail needs across all workflow stages.
Professional performance analytics and monitoring – leverage operational data, stakeholder feedback, and regulatory compliance metrics to understand workflow efficiency and professional relationship quality. Monitor capacity provider satisfaction and broker placement patterns to identify optimisation opportunities.
Stakeholder-specific workflow enhancement – develop role-appropriate platform capabilities addressing distinct professional requirements. Brokers need comprehensive client management tools, MGAs require capacity provider reporting, TPAs need multi-client coordination capabilities, and expert networks require secure collaboration platforms.
Continuous professional excellence and regulatory compliance – establish ongoing performance monitoring, stakeholder feedback integration, and regulatory compliance verification to ensure workflows evolve based on professional requirements and regulatory changes.

Read more about insurance claims on our blog:

Regulatory framework impact on workflow design

The FCA’s Consumer Duty, implemented through Policy Statement PS22/9, fundamentally shapes specialty insurance workflow requirements. While Consumer Duty primarily applies to retail customers, the concept of “material influence” extends its practical impact to specialty and delegated authority segments where professional processes ultimately affect retail customer outcomes.

Professional workflow platforms must embed regulatory compliance into routine operations, ensuring automated audit trail generation, transparent performance monitoring, and comprehensive outcome documentation. This regulatory framework creates both operational requirements and competitive differentiation opportunities through superior compliance capabilities.

Within Lloyd’s and delegated authority contexts, workflow optimisation becomes particularly critical as capacity providers increasingly demand enhanced data quality and operational controls from coverholders and MGAs. Superior workflow management directly influences capacity provider confidence and authority renewal decisions.

Professional stakeholder experience metrics framework

The following represents a proposed measurement framework based on specialty insurance operational requirements and professional relationship dynamics, rather than established industry benchmarks.

Professional Coordination Efficiency

Multi-Party Assembly Time: Speed of expert team coordination and case assignment
Broker Response Quality: Professional service delivery satisfaction and information accuracy
Regulatory Compliance Completeness: Automated documentation capture and audit trail integrity
Capacity Provider Confidence: Relationship satisfaction and authority renewal indicators

Operational Excellence Indicators

Professional Communication Quality: Stakeholder feedback on information clarity and coordination effectiveness
Expert Network Utilisation: Specialist deployment efficiency and professional satisfaction scores
Compliance Process Efficiency: Regulatory requirement fulfilment and audit preparation time
Stakeholder Relationship Retention: Professional partnership sustainability and growth metrics

Implementation strategy for workflow excellence

Professional requirements analysis

Conduct comprehensive stakeholder interviews across broker, MGA, TPA, and expert network segments. Map regulatory requirements and professional workflow dependencies. Identify operational excellence opportunities that strengthen existing professional relationships.

Platform development strategy

Develop implementation roadmaps aligning professional stakeholder requirements with operational objectives. Prioritise capabilities enhancing multi-party coordination, regulatory compliance, and professional decision-making support.

Iterative professional validation

Create workflow solutions reflecting real specialty insurance complexity. Conduct professional testing with experienced claims handlers, brokers, and compliance specialists. Validate regulatory capabilities through simulated compliance processes.

This structured approach ensures specialty insurance workflow optimisation strengthens professional capabilities, enhances stakeholder relationships, and maintains competitive advantage through operational excellence.

For specialty insurance organisations seeking to enhance professional workflow efficiency, strengthen stakeholder coordination, and achieve operational excellence through superior process management, partnering with specialists like Future Processing provides the industry expertise, regulatory knowledge, and technical capabilities essential for successful workflow optimisation.

Revolutionise your claims operations with futureClaims

futureClaims is an advanced platform designed to meet the demanding requirements of complex commercial and specialty claims, including the London Market.

Learn more Contact us

FAQ

How do professional workflow optimisation efforts influence business performance in specialty insurance?

Why AI copilots won’t fix broken delivery on their own, and what will help

FP Team — Fri, 20 Mar 2026 09:18:46 +0000

Home Blog Why AI copilots won’t fix broken delivery on their own, and what will help

AI/ML

Why AI copilots won’t fix broken delivery on their own, and what will help

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 20 March 2026

Written by:

FP Team

A group of technology experts

More from this author

The AI productivity paradox

The early data on AI coding assistants is genuinely mixed. A 2024 study by Uplevel found that GitHub Copilot increased individual developer output by 15–26% in controlled conditions, but delivered zero measurable improvement in others, and was associated with a 41% increase in bug rates. A 2025 study by METR found something even more counterintuitive: on complex, real-world codebases, experienced developers were 19% slower when using AI tools than without them.

This isn’t an argument against AI in software development. Far from it. But it is a clear signal that the value of AI tools depends almost entirely on the conditions in which they operate. Drop an AI coding assistant into a large, tightly coupled codebase with five layers of coordination, and you often get slower delivery with more bugs. The tool is only as effective as the structure around it.

The mistake most organisations are making isn’t adopting AI per se, but bolting it onto a delivery model that was already broken and calling it transformation.

The real problem is the structure, not the tools

Enterprise software delivery has a structural problem that predates AI tools, and that no copilot will solve on its own.

The classic delivery model looks like this: a business analyst captures requirements, passes them to developers, who hand off to QA, who escalate to architects when something breaks the design. At each boundary, context is lost. Decisions get queued. Three to five layers of coordination sit between a good idea and working software, and a simple feature can take weeks to move between people who should have been talking directly.

The result is delivery cycles of 12 to 24 months from idea to production. Large multi-role teams whose coordination overhead consumes a significant portion of their working time. Months of discovery before anything tangible exists.

When organisations add AI tools to this structure, they often see modest gains at the individual level. But the bottlenecks are between people, not within them. A developer who generates code 25% faster still waits for the BA to clarify requirements, for QA to free up capacity, for the architecture review board to convene. The queue is the problem. The copilot doesn’t touch the queue.

Get recommendations on how AI can be applied within your organisation.

Explore data-based opportunities to gain a competitive advantage.

Adopt AI with us Let's work together

What AI-native delivery actually means

AI-native delivery is about redesigning the process around what AI can actually do and what humans uniquely contribute.

The most significant change is what we call role compression. Rather than a BA, a developer, a QA engineer and a delivery manager each owning a fragment of the process, a small number of senior engineers own the full stack: product thinking, architecture, implementation, and quality. The benefits? Zero handoffs, direct client interaction, and same-day decisions.

This model works because AI takes on the parts of delivery that don’t require human judgment: scaffolding, routine code, test generation, static analysis, documentation. That frees engineers to operate at a consistently higher level. The result is a fundamentally different structure with different throughput characteristics.

A three-person AI-native delivery cell can match the output of a classical eight-plus-person team. Not because the individuals are working harder, but because the coordination overhead has been eliminated and the AI’s contribution is structural rather than supplemental.

Architecture that AI can navigate (and architecture that fights it)

One of the least discussed but most important factors in AI-assisted development is architecture.

Most enterprise codebases were built for human navigation: deep coupling, shared state, sprawling dependency graphs that require significant context to work in safely.

AI agents performing multi-step implementation (writing code across multiple files, respecting established patterns, avoiding subtle regressions) struggle profoundly in these environments. This is a large part of why experienced developers are slower with AI tools on complex codebases. The codebase itself resists AI-assisted work.

AI-navigable architecture is feature-isolated, with clear boundaries that an agent can extend reliably without needing to hold the entire system in context. Building on this kind of structure, or refactoring towards it as part of a modernisation programme, is a precondition for getting consistent acceleration from AI tools.

This is also why greenfield projects and vertical slice modernisation often see the most dramatic results. Start with the right structural conditions, and AI delivery can be genuinely transformative. Retrofit AI tools onto the wrong codebase, and the gains are marginal at best.

Role compression: the structural change that makes acceleration real

It is worth being specific about what role compression removes, and what replaces it.

Traditional delivery teams carry significant structural overhead that isn’t visible in any individual’s calendar but accumulates across the team. Requirements gathering involves a specialist who then translates business intent into technical language, inevitably losing nuance in the process. QA is a distinct phase that begins after development, creating a feedback loop that can take days or weeks to close. Architecture decisions require a committee, which requires scheduling, which introduces latency at exactly the moments when momentum matters most.

In an AI-native delivery cell, all of this changes. Engineers engage directly with clients and understand the business context first-hand. Quality is continuous, built into the pipeline via automated gates on every commit, covering static analysis, security scanning, architecture compliance, and dependency verification, rather than a phase that begins after code is written. Architecture decisions are made by people with full context who are also writing the code.

The practical consequence is that the cycle from decision to working software is measured in hours or days, not weeks. Not because people are moving faster, but because the structure no longer requires them to wait.

What this looks like in practice

The numbers from real AI-native delivery projects are instructive. A greenfield field inspection platform for a marine cargo surveyor, complete with mobile data capture, cloud deployment, and automated reporting, was delivered to full functional scope in approximately one man-week. The classical estimate for the same scope with a multi-role team was four months.

A workforce tracking and appraisal platform involving four external integrations, complex role-based workflows, and AI-assisted evaluation features is being delivered at approximately five times the speed of comparable classical projects at the same scope.

In both cases, the acceleration isn’t coming from individual developers writing more lines of code per hour. It’s coming from the elimination of coordination overhead, the use of AI for multi-step implementation within the right architectural conditions, and engineers who bring full product and domain context to every decision.

It is also worth noting what doesn’t change in this model: the quality bar. AI-native delivery should mean working software that is production-ready, observable, secure, and well-documented. Not a faster path to technical debt. Automated quality gates at every tier, mandatory test coverage, and structured handover documentation are part of the model, not optional extras.

So, what actually fixes broken delivery?

The organisations seeing real acceleration from AI in 2025 and 2026 aren’t the ones who distributed the most Copilot licences, but the ones who changed three things simultaneously.

First, the team structure. Eliminating handoffs and giving small numbers of senior engineers full ownership of a delivery slice: product thinking, architecture, code, and quality together. This is the change that kills the queue.
Second, the architecture. Building or migrating towards feature-isolated, AI-navigable codebases where agents can contribute reliably without accumulating risk. Without this, AI tooling often creates as many problems as it solves on existing systems.
Third, the toolchain. Not just AI coding assistance, but an end-to-end AI-powered SDLC, from spec-driven development through automated quality gates to deployment, configured and integrated from the start rather than assembled piecemeal.

Each of these changes is meaningful on its own. Together, they are what actually shifts the delivery equation.

AI copilots are genuinely useful. But they are an amplifier, not a solution. What they amplify depends entirely on what’s underneath. The organisations that will build faster, ship more reliably, and get to value sooner are the ones treating delivery itself, the structure, the architecture, the process, as the thing worth redesigning.

The tools are ready, and the question is whether the structure is, too.

Developing an AI platform that saves law firms up to 75% of document review time

Read our case study Let's work together

If your team is already using AI coding tools, or planning to, it’s worth being honest about which of those three things is actually in place. Most organisations we speak to have the toolchain. Fewer have thought through the architecture. And almost none have addressed the team structure, because changing how people work is harder than installing a new tool.

At Future Processing, we help mid-market companies across the UK build software using a delivery model where all three are designed together from the start.

Our approach uses small, senior cross-functional teams of 2 to 3 engineers who own the full delivery context end-to-end: product thinking, architecture, implementation, and quality, with no handoffs and no coordination overhead. AI tooling operates within feature-isolated, AI-navigable architectures, and automated quality gates run on every commit from day one.

Engagements start with a fixed-price AI Acceleration Sprint of 1 to 3 weeks, so you can see working software on your real data before committing to a larger programme. There’s no discovery retainer and no lengthy contract negotiation, just a 90-minute scoping call, a proposal within 48 hours, and defined success criteria before we start.

If you’d like to talk through what this could look like for your team, get in touch with us here. We’re happy to have a straightforward conversation about where your delivery structure stands and what’s worth changing first.

AI implementation without IT modernisation? A high-risk path to underperformance

AI Governance: building trust and advantage in the age of artificial intelligence

How to build an AI PoC (Proof of Concept) and why is it worth it?

Value we delivered

reduction in processing time through our AI-powered AWS solution

Read the case study

About the author:

FP Team
A group of technology experts

The Future Processing team combines technology consultancy and software delivery expertise to turn strategic visions into tangible business results. With strong engineering roots and 25 years of experience, we bring together technical excellence and a consulting mindset to deliver solutions that drive growth.

We act as a trusted partner, accountable for outcomes and focused on measurable performance. Every project is designed to create business value, ensuring that technology serves as a catalyst for long-term success.

View more posts by FP

Let’s talk

contact@future-processing.com

AI predictions 2026: from general AI models to vertical LLMs and autonomous agents

Maja Kawiecka — Thu, 19 Mar 2026 08:30:33 +0000

Home Blog AI predictions 2026: from general AI models to vertical LLMs and autonomous agents

AI/ML

AI predictions 2026: from general AI models to vertical LLMs and autonomous agents

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 19 March 2026

Written by:

Maja Kawiecka

AI Enablement & Compliance Lead

More from this author

From our work with enterprise clients across regulated and technology-intensive sectors, one thing is increasingly clear: generic GenAI experimentation is over. What matters now is specialisation, verifiability, and agent-based execution.

This article presents forward-looking predictions. Not every path is fully proven yet, but the signals from research publications, vendor roadmaps, and early enterprise implementations point in a consistent direction.

Key takeaways

AI development is moving from general-purpose models towards vertical LLMs and specialised SLMs trained on domain-specific data.
Verifiable reasoning frameworks, including reinforcement learning approaches tied to measurable outcomes - RLVR (Reinforcement Learning with Verifiable Rewards), are gaining importance in high-stakes environments.
AI agents are evolving from assistants into embedded execution layers within enterprise workflows.
Emerging standards such as Google’s Universal Commerce Protocol (UCP) signal the rise of agentic commerce.
On-premise AI and infrastructure sovereignty are becoming strategically important for regulated industries.
Competitive advantage increasingly depends on combining specialised AI models with organisational redesign and governance.

The end of the “one model fits all” era

In regulated industries such as finance, healthcare and science, relying solely on general AI models is becoming a strategic risk. The market is moving decisively towards:

Vertical LLMs, trained on proprietary, domain-specific datasets
Small Language Models (SLMs), optimised for narrow tasks and lower infrastructure costs
Advanced reasoning frameworks such as RLVR (Reinforcement Learning with Verifiable Rewards)

The broader shift towards domain-specific AI systems is reflected in industry analyses such as the Stanford AI Index Report, which highlights rapid enterprise adoption and increasing focus on practical, domain-level impact rather than model size alone.

In healthcare and biology, the evolution of AI from pattern recognition to structured reasoning is visible in systems like DeepMind’s AlphaGenome, designed to improve understanding of genomic sequences and mutation effects.

Independent coverage in Nature further illustrates how such models may support research into rare diseases and biological mechanisms.

While it is too early to claim systemic clinical replacement, these developments demonstrate a clear trajectory: AI models are being engineered for domain reliability.

At the same time, SLMs allow organisations to extract smaller, industry-focused models that deliver high performance at a fraction of the infrastructure cost.

The conclusion is not that general models disappear. Rather, competitive differentiation increasingly comes from depth of domain integration, auditability, and alignment with regulatory constraints.

Get recommendations on how AI can be applied within your organisation.

Explore data-based opportunities to gain a competitive advantage.

Adopt AI with us Let's work together

From AI models to AI agents

Models are the brain, and in 2026, they have gained hands.

In 2026, AI systems are no longer confined to generating outputs, but they are increasingly embedded into operational layers across enterprise systems. They interact with APIs, orchestrate workflows, and trigger actions.

We can distinguish several emerging layers of agent maturity.

Workflow agents – automating well-defined back-office processes.
Orchestrated multi-agent systems – coordinating task-specific agents across complex value chains.
Interface-controlling superagents – acting as unified entry points to multiple services and tools, significantly simplifying user experience while reducing licensing costs associated with fragmented software ecosystems.
Physical-world agents – combining AI models with robotics platforms.

In robotics, Nvidia’s announcements around foundation models for generalist robotics illustrate how large-scale AI is increasingly integrated into physical systems.

AI systems embedded in robotics carry an additional implication: one of the key hypotheses in the development of Artificial General Intelligence (AGI) is the need to ground intelligence in real-world interaction. By enabling AI-powered robots to operate in physical environments, these systems can learn not only from abstract representations but also through direct engagement with reality.

These developments do not yet imply full autonomy across industries. They do however signal a structural shift: organisations are beginning to redesign processes around autonomous or semi-autonomous execution layers.

Industry discussions around AI agents and enterprise transformation are also reflected in analyses by major consultancies such as McKinsey and Gartner, which increasingly frame AI as an operating model transformation rather than a productivity add-on.

Agentic commerce and the end of the shopping basket

Google’s introduction of the Universal Commerce Protocol (UCP) signals a move towards standardised, machine-readable commerce interactions.

Additionally, industry coverage describes UCP as enabling AI agents to search, negotiate, and complete transactions on behalf of users.

If such standards mature and gain adoption, competition in e-commerce may gradually shift from interface design to technical accessibility for purchasing agents.

But this is still an evolving space. Regulatory and privacy concerns are already part of the public debate, as reflected in discussions around AI-driven checkout systems.

The long-term outcome is uncertain. However, the directional signal is clear: enterprises should prepare for machine-to-machine transaction environments where APIs, structured data and compliance design become strategic differentiators.

On-premise AI and infrastructure sovereignty

As geopolitical tensions and regulatory scrutiny intensify, infrastructure decisions are becoming strategic.

Local, on-premise AI deployments allow employees to manage files, knowledge bases and workflows without constant cloud dependency. The benefits are tangible:

reduced latency in critical operations,
greater control over intellectual property,
compliance with strict confidentiality requirements.

For many regulated enterprises, local deployment is not a technical preference but a risk management decision.

The global AI landscape increasingly intertwines compute capacity, energy access and hardware sovereignty. Public discussions around large-scale AI infrastructure initiatives in the US and China highlight how compute ecosystems are becoming national strategic assets.

Geopatriation is not a transient trend, but a structural shift in how AI systems and IT infrastructure are designed. Gartner predicts that by 2030, more than 75% of enterprises in Europe and the Middle East will repatriate their virtual workloads into environments specifically designed to mitigate geopolitical risk, compared to less than 5% in 2025.

For enterprise leaders, vendor selection is therefore no longer only about model performance. It also involves long-term exposure to regulatory, trade and hardware dependencies.

The socio-economic impact: AI staffing and new roles

Another structural shift concerns workforce design.

Large enterprises are increasingly auditing processes to determine which functions can be automated, augmented, or fully “agentised”. Instead of simply reducing headcount, we observe the emergence of hybrid staffing models where autonomous systems operate under human supervision and governance.

According to LinkedIn trends, roles such as AI Consultant and AI Strategist are among the fastest growing. The key differentiator is no longer pure technical expertise, but the ability to combine domain knowledge with agent design and governance.

This transition is ongoing and uneven across industries. However, the direction is consistent: AI is moving from tool to organisational layer.

Strategic recommendations for 2026

Based on current signals and early enterprise implementations, several structural priorities emerge:

Treat AI ecosystems as integrated operational layers, not isolated assistants.
Prioritise stability and auditability in high-stakes processes.
Invest in domain specialisation to create defensible differentiation.
Conduct recurring process audits to identify agentisation potential.
Define a clear infrastructure strategy, including on-premise and hybrid deployment options for strategic data.

Not all predictions outlined here will materialise at the same pace. Some may evolve differently due to regulation, market consolidation or technical bottlenecks. However, the strategic direction is increasingly visible: AI systems are becoming embedded, specialised and infrastructure-dependent.

What this means for business leaders

The coming phase of AI adoption is less about experimentation and more about architecture.

The organisations that succeed will not necessarily be those that experiment the most. They will be those that align specialised AI systems, agent-based execution and governance frameworks with clearly defined business outcomes.

AI can deliver unprecedented scale and speed. Competitive advantage, however, will continue to depend on strategic clarity, disciplined implementation, and organisational redesign.

Developing an AI platform that saves law firms up to 75% of document review time

Read our case study Let's work together

AI implementation without IT modernisation? A high-risk path to underperformance

AI Governance: building trust and advantage in the age of artificial intelligence

How to build an AI PoC (Proof of Concept) and why is it worth it?

Value we delivered

reduction in processing time through our AI-powered AWS solution

Read the case study

About the author:

Maja Kawiecka
AI Enablement & Compliance Lead

IT professional operating in between business and technical stakeholders, translating client needs into technical solutions. Expert in business and system analysis including requirements gathering, analysis and specification, process modeling (BPMN), UML and data modeling, use case and user story creation, business process improvement, all supported with vast experience in multiple industries and professional certificates. Certified Product Owner, Scrum Master and SAFe Agilist. Team Leader responsible for employee careers, work plans, development and recruiting. Design Thinking Enthusiast.

View more posts by Maja

Let’s talk

contact@future-processing.com

IT infrastructure in finance: how technology can increase profitability

Anna Samborowska — Wed, 18 Mar 2026 11:45:50 +0000

Home Blog IT infrastructure in finance: how technology can increase profitability

Software Development

IT infrastructure in finance: how technology can increase profitability

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 18 March 2026

Written by:

Anna Samborowska

Partner for Financial Services Practice

More from this author

When Mark took over as CEO of a mid-sized financial institution, profitability was his biggest concern. The numbers looked stable, revenues were predictable, and the business had been operating the same way for years. The real problem was hidden deeper in the organisation’s IT infrastructure.

Legacy systems required constant maintenance, upgrades were slow and expensive, and every new regulatory or business requirement seemed to add another layer of complexity and cost.

Why is IT infrastructure a strategic asset for financial companies?

At first, investing heavily in modern IT infrastructure felt like a risky move. Replacing outdated systems, migrating to the cloud, and experimenting with technologies such as artificial intelligence required significant upfront spending and organisational change.

However, Mark quickly realised that maintaining the status quo was far more costly in the long run. Inefficient processes, frequent system outages, and limited access to high-quality data were silently eroding profitability.

As the institution began modernising its technology stack, the impact became measurable. AI-driven automation reduced operational costs, advanced analytics improved risk assessment and decision-making, and scalable cloud infrastructure allowed the company to adapt faster to market changes.

What once seemed like a technical challenge turned into a strategic advantage – one that directly influenced financial performance.

This article uses Mark’s journey as a starting point to explore how IT infrastructure affects the profitability of financial institutions. Supported by industry data and real-world case studies, we show how strategic technology investments can transform cost structures, enable innovation, and create sustainable long-term value.

Start your FinDataOps journey Contact us

Cost optimisation vs. value creation

Traditionally, IT spending in finance was viewed primarily as a cost center. Budgets were focused on maintaining existing systems rather than generating new value. However, this perspective is rapidly evolving.

Modern IT infrastructure impacts profitability in three major ways:

Operational efficiency

Automation and standardised processes reduce manual work, errors, and processing times.

For example, robotic process automation (RPA) and AI-driven workflows can handle repetitive tasks such as transaction processing, compliance checks, or customer onboarding.

Would you like to learn more about how IT modernisation can help your organisation grow?

Risk management and compliance

Advanced analytics and real-time data processing improve fraud detection, credit scoring, and regulatory reporting.

Instead of reacting to incidents after they occur, institutions can predict and mitigate risks earlier.

Revenue growth and innovation

Flexible infrastructure enables faster product development and personalised services. Data platforms and AI models help institutions better understand customer behavior, design targeted offerings, and increase cross-selling and retention.

In Mark’s organisation, these effects became visible within months. While initial investments increased IT spending, overall profitability improved due to lower operational costs, better risk control, and new digital products that attracted customers.

From legacy systems to modular architectures

One of the biggest challenges for financial institutions is the coexistence of legacy systems with modern technologies. Core banking platforms built decades ago often remain mission-critical, yet they are difficult to modify and expensive to maintain.

Successful modernisation strategies usually follow an incremental approach:

wrapping legacy systems with APIs instead of replacing them overnight,
migrating selected workloads to the cloud,
introducing data platforms that unify information from multiple sources,
gradually adopting microservices and event-driven architectures.

This approach minimises operational risk while allowing institutions to unlock the benefits of modern infrastructure step by step.

Take a look at our related article: How to plan a successful legacy system migration strategy?

See how we did it.

Read our case study Contact us

Data as the foundation of profitability

In finance, data is one of the most valuable assets. However, without proper infrastructure, data remains fragmented, inconsistent, and underutilised.

Modern data architectures – such as data lakes, real-time streaming platforms, and AI/ML pipelines enable organisations to transform raw data into actionable insights. This capability directly influences profitability by improving pricing models, reducing churn, and optimising capital allocation.

For Mark’s institution, consolidating data into a unified platform was a turning point. Decision-makers gained access to real-time dashboards, predictive models, and scenario simulations.

As a result, strategic decisions became faster, more accurate, and less dependent on intuition.

Key lessons from IT modernisation in financial services

IT infrastructure in financial institutions is no longer just a technical matter – it is a strategic asset that shapes profitability, resilience, and innovation capacity. While modernising infrastructure requires significant investment and organisational change, the cost of inaction is often much higher.

By moving from rigid legacy systems to flexible, data-driven architectures, financial institutions can:

reduce operational costs,
improve risk management and compliance,
accelerate innovation,
and create sustainable long-term value.

Mark’s story illustrates a broader industry trend: in finance, technology is not merely a support function – it is one of the most powerful levers of business performance.

FAQ

Why is effective IT infrastructure so critical for financial institutions?

What happens when FinOps tools, automation, and engineering expertise finally work together. Rethinking cloud savings in the AI era

Adam Gaca — Tue, 17 Mar 2026 11:20:43 +0000

Home Blog What happens when FinOps tools, automation, and engineering expertise finally work together. Rethinking cloud savings in the AI era

FinOps AI/ML

What happens when FinOps tools, automation, and engineering expertise finally work together. Rethinking cloud savings in the AI era

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 17 March 2026

Written by:

Adam Gaca

Managing Director UK&I and VP of Innovation

More from this author

Key takeaways

Cloud cost challenges are rarely caused by lack of tooling but by misalignment between engineering, finance, and governance.
FinOps introduces shared accountability for cloud economics at product and engineering levels.
Automation and governance must work together to deliver sustainable cloud cost optimisation.
AI workloads introduce new cost variability, making integrated FinOps frameworks increasingly important.
Leading organisations treat optimisation as capital allocation rather than simple cost reduction.

94% of IT decision-makers struggle to manage cloud costs, even with cloud-native and third-party tools already in place. Visibility exists, dashboards exist, yet predictability and accountability often do not.

Cloud spending is growing faster than many executive teams expected. What started as a flexible infrastructure model now powers digital products, data platforms, and increasingly AI workloads. As cloud environments expand, so does the complexity of managing their economics.

Most organisations already have cost management tools and reporting dashboards. The challenge lies elsewhere. Cloud operating models prioritise speed and decentralisation, while finance teams prioritise predictability and control: engineering teams optimise for performance, and finance teams optimise for margin.

Without clear alignment between these perspectives, cloud cost volatility becomes inevitable.

This is where FinOps consulting is evolving from a support function into a strategic discipline. Rather than focusing only on identifying waste, it helps organisations build a financial operating model for the cloud era, integrating governance, automation and engineering accountability.

Organisations that adopt FinOps strategically do not simply reduce cloud spend, but improve how capital is allocated across their digital portfolio.

Start your FinDataOps journey Contact us

Why cloud cost complexity keeps increasing

Enterprise cloud environments are rarely straightforward. Most organisations operate across multiple cloud providers, hybrid infrastructure, and containerised platforms. Distributed product teams manage independent environments, while modern architectures rely heavily on serverless services, data platforms, and analytics workloads.

This technological flexibility brings financial fragmentation. Why?

Traditional IT cost models were built around predictable infrastructure cycles. Now, cloud introduced elasticity. While elasticity enables agility, it also makes spending patterns harder to forecast. Consumption fluctuates depending on user behaviour, deployment cycles, and business growth.

AI services add another layer of variability. GPU-intensive workloads, token-based billing models, and experimentation environments introduce cost drivers that are often poorly understood at the organisational level. The challenge is therefore not visibility alone, but also establishing accountability and control within this complexity.

Without structured cloud cost optimisation practices, organisations often face recurring problems such as unclear ownership of cloud spend, inconsistent tagging, limited forecasting capabilities, and engineering teams with little visibility into the financial impact of their architectural decisions.

Complexity itself is manageable, while the lack of governance around that complexity is where costs start to spiral.

Why cloud cost tools alone are not enough

When cloud spending increases, many organisations respond by deploying additional dashboards or cost monitoring tools.

These platforms provide valuable insights: they help identify underutilised resources, detect anomalies, and highlight technical optimisation opportunities.

However, they rarely change organisational behaviour.

Many enterprises reach a point where they can clearly see where money is being spent but struggle to translate that insight into consistent action. Ownership of costs remains unclear, optimisation initiatives are fragmented, and incentives across teams are misaligned.

Tools answer the question: where are we spending? But they rarely answer the more strategic questions:

Who is responsible for the spend?
What level of cost is acceptable for a given product or service?
How do architectural decisions influence margins?
And how should savings be reinvested?

FinOps consulting helps bridge this gap by embedding tools within a broader operating model. It establishes financial guardrails, defines accountability, and connects engineering decisions with business outcomes. Without this integration turning cost management into a proactive strategy, organisations just report the money that is already gone and stay reactive.

See how we did it.

Read our case study Contact us

FinOps as an operating model, not a toolset

At its core, FinOps is a cross-functional operating model. It aligns finance, engineering, and business leadership around shared economic objectives.

From central control to distributed accountability

Traditional IT finance relied on centralised budget oversight. Cloud environments require distributed ownership.

Product and engineering teams increasingly control infrastructure decisions. As a result, they also need visibility into the financial implications of those decisions. Choices related to scaling policies, infrastructure configuration or environment lifecycle management all influence cost outcomes.

FinOps introduces accountability at the product or service level, connecting infrastructure consumption directly to business value.

Creating a shared financial language

Another challenge lies in communication. Expressing cloud costs through business metrics helps organisations move from technical optimisation to strategic decision-making.

Engineering teams typically discuss performance, workloads, and architecture. Finance teams focus on margin, variance, and forecasting. FinOps bridges these perspectives by introducing shared metrics such as cost per user, cost per transaction, or cost per feature.

Continuous rather than periodic optimisation

Cloud environments change constantly. New deployments, traffic patterns, and product releases can all influence infrastructure costs.

For this reason, cloud cost optimisation cannot rely on annual budget cycles. Instead, organisations increasingly introduce regular cost reviews, embed cost discussions into development planning, and rely on near real-time visibility supported by automated policy enforcement.

This turns FinOps into a continuous management discipline rather than an occasional audit activity.

The role of automation in sustainable cost optimisation

Automation plays an important role in scaling governance.

Many organisations implement automated mechanisms to shut down unused environments, enforce provisioning policies, or recommend resource adjustments. Infrastructure-as-code standards can also help ensure that cost considerations are built directly into deployment practices.

However, automation must be guided by clear governance principles.

Policies that aggressively shut down development environments may reduce short-term costs but damage productivity and trust. On the other hand, unrestricted provisioning leads to infrastructure sprawl.

FinOps consulting helps organisations balance these trade-offs, ensuring that automation reinforces business priorities rather than undermines them.

AI workloads introduce new cost dynamics

Training and inference workloads require specialised infrastructure, often based on GPUs. Many services rely on token-based pricing models or consumption-based APIs. As a result, cost structures can fluctuate significantly depending on how models are designed and used.

This creates new governance challenges.

Organisations need clear ownership of AI experimentation budgets, transparent allocation of AI-related spending, and basic optimisation practices for model usage.

The emerging discipline sometimes referred to as AI FinOps should not exist separately from broader FinOps strategy. Instead, it should be integrated into the same governance and accountability frameworks already used for cloud infrastructure.

Governance expectations are increasing

Cloud economics are also becoming more visible to regulators and auditors.

Spending decisions increasingly intersect with data residency requirements, vendor concentration risks, and security obligations. Financial leaders are also expected to demonstrate stronger control over digital investments.

Governance therefore extends beyond budget thresholds. It includes defining who can provision infrastructure, how costs are allocated and reported, and how anomalies are escalated.

Many organisations discover that fragmented governance structures, rather than inefficient infrastructure, are the main reason behind uncontrolled cloud spending.

Cost optimisation as capital allocation

One of the most useful reframes for executive teams is to view cloud optimisation through the lens of capital allocation. When optimisation is framed purely as cost reduction, teams often perceive it as a constraint. When it is presented as a mechanism for reinvestment, it becomes a strategic lever.

Reducing unnecessary spending frees resources that can be reinvested elsewhere in the organisation. These funds can support product development, data initiatives, security improvements, or new digital capabilities.

Leading organisations track optimisation results and intentionally redirect a portion of the savings into high-priority initiatives. This creates a sustainable cycle of efficiency and reinvestment.

Learn more from a new episode of IT Insights: DigiTalks, where we explore how real synergy between finance, engineering, and leadership turns cloud cost visibility into meaningful decisions:

The pay-as-you-save model in FinOps consulting

As FinOps practices mature, commercial models are evolving as well.

The pay-as-you-save approach reflects a growing demand from executive teams for measurable results. Instead of funding advisory work purely based on effort, organisations link compensation to realised financial impact.

This structure can reduce risk and strengthen accountability on both sides. It also encourages a stronger focus on tangible outcomes.

However, such models require reliable baselines and transparent cost reporting. Without mature FinOps foundations, accurately attributing savings can become difficult.

How CIOs and CFOs align on cloud economics

Cloud economics increasingly influence profitability and enterprise valuation, which makes FinOps a shared leadership responsibility.

Technology leaders focus on architecture, automation, and engineering accountability. Finance leaders prioritise predictability, capital efficiency, and reporting transparency. Business leaders remain responsible for product profitability.

FinOps consulting connects these perspectives by translating technical consumption data into financial insights and aligning governance with business strategy.

When this alignment works well, discussions about cloud costs shift from reactive explanations to proactive planning.

Assessing your FinOps maturity

Organisations that want to strengthen their FinOps capabilities should periodically review a few fundamental questions:

Is ownership of cloud costs clearly defined at product level?
Do engineering teams understand the economic impact of their architectural choices?
Are governance policies supported by automated guardrails?
Is cloud cost optimisation treated as an ongoing discipline rather than a periodic exercise?
Are savings systematically reinvested into strategic priorities?

If the answers remain unclear, the organisation may still be operating below its FinOps potential.

In today’s digital environment, economic discipline is inseparable from technology leadership. FinOps consulting provides the governance structure and organisational alignment needed to turn cloud cost complexity into long-term strategic advantage.

See our offer Contact us

Cloud cost excellence in Media: a CEO/CFO playbook

Cloud cost analysis 101: optimising and reducing cloud spend

Value we delivered

monthly cost reduction achieved through proactive implementation of AWS Cloud savings plans

Read the case study

About the author:

Adam Gaca
Managing Director UK&I and VP of Innovation

I help companies turn transformation and innovation into measurable growth.

Blending people, process and technology to drive revenue, operational excellence and meaningful business outcomes across industries and geographies. My work focuses on building innovative AI- and data-driven capabilities, modern cloud foundations and sovereign-by-design strategies that keep organisations fast, compliant and in control. With a strong track record in advisory, strategy, management and applied AI, I partner with leaders to translate ambition into scalable solutions, trusted operations and lasting competitive advantage.

View more posts by Adam

Let’s talk

contact@future-processing.com

The age of technology efficiency: why cost discipline is the new innovation strategy?

Błażej Ksycki — Thu, 12 Mar 2026 09:25:04 +0000

Home Blog The age of technology efficiency: why cost discipline is the new innovation strategy?

FinOps Data Solutions

The age of technology efficiency: why cost discipline is the new innovation strategy?

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 17 March 2026

Written by:

Błażej Ksycki

Data Solutions Consultant

More from this author

For more than a decade, the technology sector operated on a simple assumption: growth equalled innovation. As long as capital was cheap and abundant, expansion became its own validation.

Headcount increased, cloud estates expanded rapidly, product portfolios multiplied, and cloud services scaled faster than governance frameworks could evolve.

In that environment, managing actual costs was often postponed. Efficiency - including efforts to optimise cloud costs - was treated as something to refine later, once scale had been secured. In boardrooms and investor decks alike, speed eclipsed structure.

That era is over.

Rising cloud spending and the need for cost control

Cost control should not be mistaken for austerity. It is not about indiscriminate cost reduction or reactive budget cuts. It is about redesigning how technology delivers value — aligning architecture with strategy, engineering effort with business priorities, and investment with clear returns.

In practice, this means embedding cloud cost management and cloud cost optimisation into operating models rather than treating it as an afterthought. Efficiency, in this sense, is not the enemy of innovation. It is its new operating model.

Technology cost discipline has become a strategic capability. Organisations that master it gain more than leaner budgets — they gain predictability, resilience, and the confidence to invest decisively. Those that fail to manage costs risk discovering that scale without structure is simply an expensive illusion.

This reframing has been building quietly for years. At Future Processing, optimising cloud spend has long stood as one of our three core pillars — not as a reaction to tighter markets, but as a recognition that sustainable innovation depends as much on cost control as on creativity.

In the age of technology efficiency, cloud cost is no longer a constraint to work around; it is a design principle to work with.

Growth naturally increases technology costs

As organisations expand, their technological footprint compounds. A growing user base generates more transactions, more integrations, and more automated workflows. Data volumes do not merely increase — they multiply across storage layers, analytics systems, and reporting pipelines.

AI adoption adds further intensity:

Model training requires burst compute capacity
Real-time inference increases variable cloud usage
Experimentation multiplies temporary infrastructure consumption

Meanwhile, SaaS ecosystems often sprawl across departments, layering subscriptions and creating hidden cloud expenses. Without strong governance, this complexity produces unnecessary costs that erode margin silently.

Importantly, rising cloud costs are not inherently negative. They often signal success. Scaling organisations consume more technology because they serve more customers and operate at greater sophistication.

The risk emerges when:

Cloud expenses grow faster than revenue
Cost visibility is weak
Accountability for cloud usage is unclear
Cost drivers are poorly understood

Effective cloud cost management transforms technology growth into a predictable value driver rather than a source of volatility.

See how we did it.

Read our case study Contact us

From growth at all costs to return on capital

The macroeconomic environment has sharpened this transition. An era of near-zero interest rates and generous valuations has given way to tighter capital and increased scrutiny. Growth still matters — but growth funded by inefficiency no longer commands a premium.

Boards now evaluate technology investment through operating margin, capital intensity, and long-term operational efficiency. The questions are sharper:

What measurable value does this platform create?
How does this initiative improve unit economics?
Does this cloud investment generate durable ROI?

Innovation is no longer judged by ambition alone. It is judged by return on cloud spending.

Organisations that take care of cloud costs optimisation proactively demonstrate control. Those that fail to do so risk discovering that scale without structure simply amplifies inefficiency.

Operational leverage as a technology outcome

Efficiency signals competence. Organisations that understand how cloud costs scale — where they flex, where they compound, and where they stabilise — can forecast confidently and negotiate strategically with cloud providers. They are not surprised by their own cloud bills.

There is a crucial distinction between reactive cost-cutting and engineered operational leverage.

Reactive cost reduction typically involves:

Hiring freezes
Tool consolidation
Delayed innovation initiatives

Engineered efficiency, by contrast, is structural. It is visible in:

Architectures designed to avoid exponential cost curves
Governance frameworks that prevent unnecessary costs
Product decisions that balance lifetime cloud cost with lifetime value

Mature organisations align revenue growth with proportional cloud usage growth. Expansion drives predictable increases in expenses – not sudden spikes.

This alignment is the foundation of sustainable operational efficiency.

Discover ways to reduce cloud costs without compromising quality and efficiency:

Why does capital intensity now define technology strategy?

Cloud computing and consumption-based pricing models have reshaped financial exposure. Elasticity, once celebrated purely for flexibility, introduces financial variability. In data warehouses, streaming platforms, and AI workloads, cloud costs scale instantly with usage.

A surge in queries, model training, or data ingestion can have immediate budget impact.

Without strong cloud cost management tools and structured forecasting, elasticity becomes volatility.

However, organisations that build advanced cost visibility can:

Forecast usage trends accurately
Commit strategically with cloud providers
Secure volume discounts
Transform variable usage into predictable financial agreements

In this environment, managing cloud costs becomes a source of strategic leverage rather than reactive control.

Elasticity without cloud governance breeds instability. Elasticity with discipline enables scalable growth.

Architecture is fundamental to operational cost

Architecture decisions shape long-term cloud expenses more than most financial reviews ever reveal.

Microservices increase agility but expand operational overhead
Data duplication improves access but inflates storage costs
Multi-region deployments enhance resilience but increase networking spend
Managed cloud services simplify operations while embedding recurring vendor costs

These choices are economic decisions, not purely technical ones.

To truly optimise cloud costs, architecture discussions must balance performance, resilience, and financial sustainability. Technical debt, system complexity, and talent allocation all influence operational efficiency.

Organisations that design for maintainability as deliberately as they design for innovation prevent structural inefficiencies from turning into recurring cost overruns.

Start your FinDataOps journey Contact us

How to embed tech cost discipline without slowing innovation?

A common concern is that governance slows delivery.

In reality, well-designed cloud cost management enhances speed by improving clarity and enabling teams to make informed decisions about how they use cloud resources.

Embedding cost conscious culture into daily operations involves:

Real-time cloud cost visibility dashboards
Clear cost allocation models that assign ownership to products and teams
Unit economics embedded in feature prioritisation
Automated policies within cloud cost management tools to help avoid cost overruns

When financial metrics sit alongside performance and security metrics, innovation and efficiency align naturally. Teams understand not only how systems perform, but also how architectural decisions affect budgets, margins, and long-term scalability.

The goal is not restriction, but coherence. Organisations that connect engineering decisions with cost allocation and cloud resource consumption innovate more sustainably. They experiment intelligently, scale responsibly, and avoid cost overruns before they become structural issues.

Strategic takeaway: your growth should not worry you if you can optimise costs

Growth itself is not the problem. Rising cloud expenses, expanding AI initiatives, and accelerating cloud adoption often signal healthy business momentum and increasing market relevance.

The decisive factor is whether that growth strengthens margin or gradually dilutes it.

The organisations that will lead in this cycle will not be those that simply spend the most on cloud services. They will be those that embed cloud cost governance into their operating model and consistently optimise cloud costs as part of everyday decision-making.

These are businesses that treat cost discipline as a capability — proactively managing cloud costs, eliminating unnecessary costs, and aligning cloud usage directly with measurable business value.

When you optimise cloud costs strategically, growth becomes predictable rather than intimidating. Strong cloud cost governance ensures that increases in usage are intentional, forecastable, and proportionate to revenue expansion — not reactive spikes that erode profitability.

With the right governance frameworks, cloud cost management tools, and architectural discipline in place, cloud investment transforms from a volatile operational expense into a controlled engine of innovation and long-term value creation.

Future Processing is ready to help you bring clarity, structure, and measurable ROI back into your technology strategy — ensuring that growth strengthens financial performance rather than destabilising it.

See our offer Contact us

Cloud cost analysis 101: optimising and reducing cloud spend

AI implementation without IT modernisation? A high-risk path to underperformance

AI Governance: building trust and advantage in the age of artificial intelligence

Value we delivered

monthly cost reduction achieved through proactive implementation of AWS Cloud savings plans

Read the case study

About the author:

Błażej Ksycki
Data Solutions Consultant

Data Engineering Leader with nearly a decade of experience architecting scalable, cloud-based data solutions that drive strategic business outcomes. Proven in transforming complex data challenges into actionable insights by leveraging cutting-edge Big Data technologies—such as GCP, Apache Beam, Kafka, and BigQuery—to streamline operations and optimize costs. Adept at building and mentoring high-performing teams of up to 30 engineers, I have successfully reduced customer onboarding cycles by over 50% and slashed operational expenses by nearly 50%. Passionate about aligning technical innovation with business objectives, I excel in driving efficiency and delivering robust, production-grade data pipelines across diverse industries including airline, ad-tech, and insurance.

View more posts by Błażej

Let’s talk

contact@future-processing.com

Why are FinOps or DataOps alone no longer enough in the era of Data & AI?

Błażej Ksycki — Tue, 10 Mar 2026 10:06:28 +0000

Home Blog Why are FinOps or DataOps alone no longer enough in the era of Data & AI?

FinOps Data Solutions

Why are FinOps or DataOps alone no longer enough in the era of Data & AI?

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 17 March 2026

Written by:

Błażej Ksycki

Data Solutions Consultant

More from this author

Over the past decade, cloud cost management has matured significantly. The FinOps Foundation standardised financial accountability for cloud infrastructure and helped organisations improve cloud cost visibility, forecasting, and allocation across major cloud providers.

At the same time, DAMA International, through DAMA-DMBOK®, clarified ownership, governance, and stewardship models in data management, strengthening DataOps maturity and operational discipline.

However, the rapid growth of large-scale data platforms and AI workloads has fundamentally changed the economics of cloud services. The challenge today is not whether FinOps or DataOps were effective, because they were. The issue is that Data & AI workloads have introduced new cost drivers that neither discipline, in isolation, was designed to govern.

This is not a criticism. It is a natural evolution. FinOps brought structure to infrastructure-level cloud spending. DataOps improved delivery speed, quality, and governance.

Yet modern data platforms and AI systems require a more integrated approach to effective cloud cost management.

The limits of traditional FinOps in modern Cloud cost management strategy

FinOps has delivered substantial value by improving cloud cost containment and enabling organisations to better manage cloud cost at the infrastructure layer.

It excels at:

Cost allocation through tagging and showback/chargeback models
Budget controls and forecasting
Rightsizing compute and storage
Reserved capacity optimisation
Eliminating idle or underutilised cloud resources

These capabilities, often supported by specialised cloud cost management tools, transformed how organisations approach cloud cost optimisation.

However, traditional FinOps frameworks remain largely infrastructure-centric. They focus on instances, storage volumes, network egress, and reserved capacity planning. While these controls improve infrastructure efficiency, they are often reactive to spend signals and disconnected from how modern data workloads actually generate cost.

When the critical question shifts from “Which virtual machine is running?” to “Which query, transformation, pipeline, or model caused this cost spike?”, infrastructure-level optimisation alone becomes insufficient. In data-driven environments, cloud usage patterns – not just resource uptime – determine spend.

See how we did it.

Read our case study Contact us

How data platforms changed the Cloud cost model

Consumption-based data platforms have fundamentally altered the cloud economics model. Solutions such as Snowflake, Google BigQuery, Databricks, and Amazon Redshift introduced pricing structures where cost is driven by workload behaviour rather than instance uptime.

In these environments, costs are influenced by:

Query design and execution frequency
Data duplication across environments
Inefficient transformation logic
Poor lifecycle and retention policies
Uncontrolled concurrency and pipeline orchestration

Tagging a warehouse does not correct an inefficient transformation query, just as rightsizing a cluster does not prevent excessive full-table scans. Here, cost is workload-driven rather than instance-driven. Without granular cloud cost visibility at the query, pipeline, and data product level, organisations cannot meaningfully control or forecast cloud spending.

This marks a fundamental shift: cloud cost optimisation must extend beyond infrastructure telemetry into workload behaviour and architectural design.

Learn more about cloud financial management:

AI workloads and the rise of unpredictable compute costs

AI workloads significantly amplify the financial complexity of modern cloud computing, particularly within highly dynamic cloud environments where scaling is automated and experimentation is continuous. Model training and fine-tuning frequently require burst GPU consumption, often spinning up expensive resources for short, intensive cycles.

At the same time, experimentation phases multiply compute usage before any tangible business value is realised, making early-stage forecasting difficult for both engineering teams and business units focused on cost saving.

Real-time inference further compounds this challenge by introducing dynamic scaling patterns that can dramatically increase cloud usage during peak demand or unexpected traffic surges.

In addition, large language model services commonly rely on token-based pricing models, where cost scales directly with interaction volume. This makes expenditure highly sensitive to user behaviour, product adoption rates, and integration patterns – variables that are difficult to predict during initial deployment.

Such characteristics introduce cost volatility that traditional cloud cost management tools were not designed to handle, as they typically focus on infrastructure utilisation rather than workload-level economics.

While most FinOps dashboards provide infrastructure-level metrics within the broader cloud environment, they often lack model-level cost attribution, experiment tracking, feature-store consumption visibility, and inference unit economics.

As a result, organisations may successfully optimise virtual machines yet remain exposed to uncontrolled AI-related cloud spending. Without deeper integration between financial governance and AI engineering practices, even well-intentioned cost saving initiatives can fail to address the true drivers of AI cost in cloud computing.

Understand what drives your data and AI costs and what to change first.

Get a clear, data-backed view of optimisation opportunities across your platform.

Start your FinDataOps journey Let's work together

Why does cloud cost optimisation not equal data cost governance?

Reducing idle virtual machines is not the same as controlling runaway query costs or inefficient ML pipelines. Infrastructure optimisation answers the question: “Are we paying for unused resources?”

Data and AI governance must answer a more strategic one: “Are we designing workloads efficiently and sustainably?”

True governance therefore extends into:

Data modelling standards
Storage tiering strategies
Retention and archival policies
Pipeline orchestration design
AI experimentation controls
Model deployment economics

Without embedding cost awareness into architecture and engineering decisions, organisations remain reactive. They may improve short-term cloud cost containment, yet fail to address structural drivers of long-term cloud cost optimisation.

The ownership problem in Data and AI environments

Modern data ecosystems are inherently shared. They rely on shared warehouses, shared feature stores, shared experimentation clusters, and shared inference endpoints. While this accelerates innovation, it often blurs accountability.

When a poorly optimised transformation query drives up costs, who owns it? When inference traffic scales unexpectedly, which team is responsible for the resulting increase in cloud spending?

DAMA-DMBOK® clearly states that undefined ownership reflects governance immaturity. If cost accountability in data platforms is unclear, it signals insufficient DataOps maturity.

Financial transparency without ownership produces noise; ownership without financial insight produces blind spots. For effective cloud cost management, both must converge.

From FinOps to FinDataOps: extending financial accountability into Data & AI

The next step is not to replace FinOps but to extend it.

FinOps established financial discipline for infrastructure across cloud providers. DataOps introduced operational discipline for data delivery. Data and AI now require cost governance embedded directly into:

Data pipelines
Query design
Model lifecycle management
Architectural decision-making

FinDataOps represents this evolution: a holistic operating model that integrates FinOps principles with DataOps and MLOps practices, embedding ownership and guardrails into data platforms and AI systems.

It moves beyond reactive reporting toward design-time governance, ensuring that cloud cost management becomes part of engineering and product development rather than a retrospective finance exercise.

Financial insight must influence how systems are built, not merely how invoices are analysed.

How to build predictable Data & AI cost models?

Predictability in cloud services requires structural integration between finance, engineering, and product teams.

Key enablers include:

Unit economics as the backbone

Define cost per data product, per query class, per pipeline, per model inference, and per experimentation cycle. This creates measurable drivers of cloud usage and aligns cost with value creation.

Attribution and metadata as prerequisites

Workload-level cost signals must connect to accountable owners and products, enabling actionable cloud cost visibility.

Platform chargeback and showback models

Consumption must map to domains or teams, strengthening accountability and supporting disciplined cloud cost containment.

Guardrails by design

Cost-aware architecture principles embedded into CI/CD pipelines, Infrastructure-as-Code, data modelling standards, and AI deployment workflows ensure that cloud cost optimisation occurs proactively.

If organisations focus solely on infrastructure levers, they overlook the true drivers of spend: workload behaviour, including queries, pipelines, and inference patterns. Modelling these drivers and embedding guardrails is essential to sustainably manage cloud cost.

Strategic takeaway: DataOps and FinOps must go hand in hand to be effective

FinOps remains necessary and DataOps remains necessary. But in a world where competitive advantage is increasingly driven by data products and AI systems, neither is sufficient alone.

Organisations that succeed will not merely optimise infrastructure through cloud cost management tools. They will integrate financial accountability into data engineering, design cost-aware AI products, establish clear workload ownership, and embed governance into architecture decisions.

They will build predictable, cost-aware data and AI ecosystems supported by mature cloud cost visibility and proactive cloud cost optimisation practices.

This extended discipline – FinDataOps – represents the evolution of effective cloud cost management for the Data & AI era. It ensures that financial discipline moves upstream into design, delivery, and product strategy, enabling sustainable innovation rather than reactive cost control.

FinOps started the journey.

FinDataOps completes it.

See our offer Contact us

AI implementation without IT modernisation? A high-risk path to underperformance

AI Governance: building trust and advantage in the age of artificial intelligence

How to build an AI PoC (Proof of Concept) and why is it worth it?

Value we delivered

monthly cost reduction achieved through proactive implementation of AWS Cloud savings plans

Read the case study

About the author:

Błażej Ksycki
Data Solutions Consultant

View more posts by Błażej

Let’s talk

contact@future-processing.com

AI in software development: where human judgement still leads

Adam Gaca — Thu, 05 Mar 2026 10:10:21 +0000

Home Blog AI in software development: where human judgement still leads

AI/ML

AI in software development: where human judgement still leads

The cost of a cyber attack rarely ends with fines and ransom payments. Without cyber resilience, downtime, reputational damage, and lost contracts multiply the real impact.

Last update date: 10 March 2026

Written by:

Adam Gaca

Managing Director UK&I and VP of Innovation

More from this author

The problem is that 'AI adoption' means very different things depending on who is saying it. A developer using AI to autocomplete a function and a team running fully autonomous software pipelines are both described as 'using AI', yet the two have almost nothing in common in terms of workflow, risk, or organisational implication.

Without a clear way to distinguish between them, most conversations about AI in software development end up talking past each other.

A useful lens is to ask where the human sits in the process, and how that position shifts as AI takes on progressively more of the work. That question maps onto five distinct stages.

The first three form what we call the AI-boosted zone: AI amplifies the team's capability, but human expertise and accountability remain firmly in the lead. Stages 4 and 5 represent a different model entirely, one where the developer's role transforms in ways that go well beyond tool adoption.

Understanding the difference between these two worlds is the starting point for making good decisions about where to invest and how fast to move.

The AI-boosted zone: stages 1, 2 and 3

Across all three stages in the AI-boosted zone, one principle holds: the human leads the process.

Developer expertise, architectural judgement, and accountability for the output remain in human hands. What changes, stage by stage, is how much of the implementation work the human is directly doing and how much is being directed and reviewed rather than written from scratch.

Stage 1: AI as an intelligent assistant

At Stage 1, AI functions as an information and drafting tool. It suggests code completions, surfaces relevant patterns, helps engineers navigate large or poorly documented codebases, and generates first drafts of code and tests. Every output is reviewed and refined by a human before it goes anywhere near production.

The human is still writing the software. AI is reducing the friction of doing so – handling volume, filling gaps in documentation, keeping context fresh across large codebases. Think of it as a faster, smarter tab key: the keystrokes reduce, but the developer’s thinking drives every decision. The productivity gains at this stage are real but incremental. Anyone promising dramatic output increases from basic AI assistance alone is overstating the case.

For organisations in regulated sectors like financial services, insurance, utilities – this is the natural default. Under the EU AI Act, which has direct relevance for UK organisations with EU operations or data flows, this stage puts human accountability exactly where regulators expect it. The risk/reward ratio here is the most favourable of any stage: gains are measurable and the governance overhead is manageable.

One thing worth being clear-eyed about: AI does not know things in the way people do. It generates output based on statistical probability rather than understanding. A BBC and European Broadcasting Union study across 22 media organisations found that 45% of AI-generated responses contained significant issues, including factual errors, sourcing problems, and missing context. The same dynamic applies to code. Human curation at this stage is the control mechanism, not a formality.

Get recommendations on how AI can be applied within your organisation.

Explore data-based opportunities to gain a competitive advantage.

Adopt AI with us Let's work together

Stage 2: AI as executor

At Stage 2, the developer begins handing off discrete, well-scoped tasks to AI: write this function, refactor this module, build this component. The AI handles execution. The human handles architecture, integration, and judgement, reviewing everything that comes back but no longer writing every line themselves.

This is where the productivity gains start to become commercially significant. In established codebases, teams typically see 15 to 20% improvement. Faster delivery cycles, lower cost per feature, and reduced time-to-market are all real outcomes, but they depend entirely on the quality of the specification going in.

Architecture governance is critical here. AI generates code within whatever constraints it is given. Vague constraints produce code that works today and becomes a maintenance problem in twelve months. Teams that consistently extract value at this stage invest in clear architectural design and technical guardrails before they start generating.

The 2025 DORA report found that a 90% increase in AI adoption correlated with a 9% rise in bug rates and a 91% increase in code review time. That is manageable, but only if quality assurance is treated as a parallel investment, not an afterthought.

Organisations getting this right are investing in automated testing and behaviour-driven development (BDD) alongside their AI tooling. These techniques verify software against business requirements, not just technical specifications. The role of QA is becoming more strategic, not less relevant.

Stage 3: AI as co-developer

At Stage 3, AI begins managing multi-file changes: navigating a codebase, understanding dependencies, building features that span modules. The developer is reviewing more complex output but still reading all the code. The human remains the final authority on everything that ships.

This is the furthest point on the spectrum where the developer’s role is still recognisably that of a developer – someone who understands the implementation, owns the architecture, and is accountable for the quality of what gets built. Most enterprise teams who describe themselves as ‘AI-native’ are operating here. AI is central to how work gets done.

The productivity boost at this stage is substantially larger than at Stage 2. But so is the risk. The developer’s primary remaining contribution is code review, and code review is demanding work. It requires sustained concentration on output you did not write, across volumes that grow quickly as AI generation speeds up. When review quality degrades, quality of the entire codebase degrades with it.

Two risks need active management. The first is review discipline. Code review becomes the critical control point, and its quality drops when the volume of AI-generated code increases without a corresponding change in how reviews are structured. Commit size, review thoroughness, and bug ticket trends are the leading indicators to watch. The second is talent development. Junior developers who work primarily with AI-generated code may not build the deep intuition that comes from writing and debugging from first principles – intuition that surfaces when problems get hard. Development practices need to account for this deliberately.

AI models are also non-deterministic. The same prompt can produce different outputs at different times, and newer models are not always more consistent than older ones. In regulated environments, this variability needs to be factored into process design. Language choice matters too: AI tools perform more consistently with Java, C# and Python than with C++, which is worth considering when deciding where to introduce AI assistance first.

Beyond AI-boosted: a fundamentally different model

Stages 4 and 5 are not a continuation of the AI-boosted model. They represent a structural shift in how software is built, in what engineering teams look like, and in what the developer’s role means. The tools may be familiar, but the workflow, the organisational logic, and the skills required are fundamentally different.

In the AI-boosted zone, the human amplifies their capability with AI. Beyond it, the human directs AI to build on their behalf. That distinction is the clearest way to understand where the line falls, and why crossing it requires more than adopting a new tool.

It is also worth being explicit about what Stage 4 is not. It is not ‘coding in plain English without technical knowledge.’ That approach, sometimes called vibe coding, involves prompting AI conversationally and accepting whatever comes out. Stage 4 is the opposite. It is a disciplined, enterprise-grade operating model with guardrails, quality metrics, compliance controls, and security requirements built into the process.

The specification that goes in must be precise enough to define correct behaviour unambiguously. The difference between the two is the difference between a prototype and a production system.

Stage 4: Developer as product owner

At Stage 4, the developer writes a specification, steps back, and returns hours later to evaluate whether the output meets the defined criteria. The code is a black box. What matters is whether it works, not how it was written. The agent handles implementation; the human handles definition and evaluation.

This demands a quality of specification writing that most organisations have never needed to develop. It also requires a testing architecture built specifically for autonomous generation – one where evaluation criteria are stored outside the codebase, so the agent cannot optimise for passing tests rather than building correct software.

The bottleneck shifts from implementation speed to specification quality, and specification quality is a function of how deeply the team understands the system, the customer, and the problem.

Governance here is not optional. Monitoring for AI bias, detecting hallucinations, and verifying the correctness of outputs must be built into the factory itself. You cannot review every line of code because there is no human reviewing lines of code. What replaces that review is a rigorous evaluation framework, architectural guardrails, and an ongoing commitment to measuring whether the system is producing correct outcomes.

Developing an AI platform that saves law firms up to 75% of document review time

Read our case study Let's work together

Stage 5: The autonomous software factory

At Stage 5, no human writes code and no human reviews code. A specification goes in; working software comes out. A small number of teams are genuinely operating this way today.

Three-person teams shipping tens of thousands of lines of production code built entirely by agents, tested against behavioural scenarios the agents never see, deployed without human involvement in any line of implementation.

The productivity gains here are in the hundreds of percent: real, documented, and extraordinary. But they are only available to organisations that have built the factory correctly.

Spin up an army of agents on top of weak specifications and inadequate governance, and the result is not a 300% productivity increase. It is a 300% increase in the rate at which you produce broken software. The factory amplifies whatever goes into it: good intent produces good outcomes, but poor foundations produce poor outcomes at scale and speed.

The human role at Stage 5 is not eliminated – it is distilled down to what cannot be automated: understanding what to build, for whom, and why. Those who thrive here are product thinkers and systems architects who happen to have access to unlimited engineering capacity. The constraint moves from ‘can we build it?’ to ‘should we build it?’, which has always been the harder and more valuable question.

The path to Stage 5 runs through the earlier stages, not around them. Organisations that skip the foundational work – clear specifications, robust testing, honest measurement of AI output quality – do not arrive at an autonomous factory. They arrive at a faster way to accumulate technical debt.

Summary: choose your stage deliberately

The five stages described here are not a maturity ladder to climb as fast as possible, but a map of tradeoffs, each with different productivity potential, different risk profile, and different organisational requirements.

Where you operate should be a deliberate choice, not an accident of whatever tools your developers started using.

Stage 1 is low-risk, immediately deployable, and appropriate for almost any organisation. Stage 2 delivers material commercial benefit but requires parallel investment in architectural clarity and QA capability. Stage 3 is where the most capable enterprise teams are operating today – the highest returns within the AI-boosted zone, with the most demanding governance requirements to match.

Stages 4 and 5 are where the industry is heading and understanding them matters even for organisations operating firmly within Stages 1 to 3. The skills that make Stage 3 work well are exactly the ones that enable the transition beyond it: specification clarity, architectural rigour, and a genuine commitment to measuring what AI is producing, not just how much.

The organisations getting the most out of this shift are not the ones moving fastest. They are the ones that have been honest about which stage they are at, clear about what the next stage genuinely requires, and disciplined enough to build the foundations before they need them. Speed and rigour are not in opposition here, but rigour must come first.

Get recommendations on how AI can be applied within your organisation.

Explore data-based opportunities to gain a competitive advantage.

Adopt AI with us Let's work together

AI implementation without IT modernisation? A high-risk path to underperformance

AI Governance: building trust and advantage in the age of artificial intelligence

How to build an AI PoC (Proof of Concept) and why is it worth it?

Value we delivered

reduction in processing time through our AI-powered AWS solution

Read the case study

About the author:

Adam Gaca
Managing Director UK&I and VP of Innovation

I help companies turn transformation and innovation into measurable growth.

View more posts by Adam

Let’s talk

contact@future-processing.com

Blog – Future Processing

The true cost of doing nothing: what media organisations stand to lose without cyber resilience

The true cost of doing nothing: what media organisations stand to lose without cyber resilience

Written by:

Table of contents

Key takeaways

Visible and hidden costs: the full financial impact

The compounding timeline of a breach

The cost gap: resilience vs no resilience

Preparing for the inevitable: building a cyber resilience strategy

The most expensive strategy is inaction

Stop guessing. Test it under real broadcast pressure.

Related articles

Value we delivered

About the author:

Anna Mleczko Head of Media and Advertising Practice

Artur Dąbrowski Security Consultant

Let’s talk

When systems move faster than their guardrails. The lessons from Amazon, McKinsey, and Lloyds.

When systems move faster than their guardrails. The lessons from Amazon, McKinsey, and Lloyds.

Written by:

Table of contents

Three stories, one diagnosis

Amazon: speed without structure

McKinsey: the attack surface nobody planned for

Lloyds: complexity without isolation

Identify potential risks and vulnerabilities in your systems to protect your organisation from all angles.

The pattern all three stories share

What the reset tells us

Quality gates are not the opposite of speed

Related articles

Value we delivered

About the author:

Noel Oliveira Enterprise Business Development Manager

Let’s talk

Professional workflow optimisation in specialty insurance: enhancing multi-stakeholder coordination and operational excellence

Professional workflow optimisation in specialty insurance: enhancing multi-stakeholder coordination and operational excellence

Written by:

Table of contents

What is professional workflow mapping in specialty insurance and why does it matter?

Common professional pain points across specialty insurance workflows

Complex multi-party coordination

Regulatory compliance documentation

Expert network integration

Capacity provider reporting

Professional communication fragmentation

Priority workflow stages for specialty insurance optimisation

Risk assessment and broker engagement

Underwriting coordination and placement

Policy management and stakeholder communication

Claims coordination and expert management

Performance monitoring and relationship management

Strategic approach to specialty insurance workflow optimisation

Regulatory framework impact on workflow design

Professional stakeholder experience metrics framework

Implementation strategy for workflow excellence

Professional requirements analysis

Platform development strategy

Iterative professional validation

FAQ

Why AI copilots won’t fix broken delivery on their own, and what will help

Why AI copilots won’t fix broken delivery on their own, and what will help

Written by:

Table of contents

The AI productivity paradox

The real problem is the structure, not the tools

What AI-native delivery actually means

Architecture that AI can navigate (and architecture that fights it)

Role compression: the structural change that makes acceleration real

What this looks like in practice

So, what actually fixes broken delivery?

Related articles

Value we delivered

About the author:

FP Team A group of technology experts

Let’s talk

AI predictions 2026: from general AI models to vertical LLMs and autonomous agents

AI predictions 2026: from general AI models to vertical LLMs and autonomous agents

Written by:

Table of contents

Anna Mleczko
Head of Media and Advertising Practice

Artur Dąbrowski
Security Consultant

Noel Oliveira
Enterprise Business Development Manager

FP Team
A group of technology experts

Maja Kawiecka
AI Enablement & Compliance Lead

Adam Gaca
Managing Director UK&I and VP of Innovation