Today, we complete our map of 8 key technology decisions by analyzing the final four pillars that ensure the integrity, security, and long-term impact of our digital ecosystem.

5 Data governance and traceability

This is the engine that ensures data remains a trustworthy asset, directly impacting the company’s Governance (G). Reliable data doesn’t just ensure compliance—it accelerates decision-making and builds market trust.

Key selection factors

Data must have a clear identity and ownership. It is essential to choose technologies that guarantee end-to-end traceability for critical data and provide governance capabilities that ensure quality and integrity.

• Key usage factors

Transparency is non-negotiable. It requires clearly defined access and retention policies, along with continuous security monitoring and audit processes for responsible usage.

• Organizational impact

Faster decisions driven by trusted data. The result is strong regulatory compliance and support for ESG transparency through verifiable and auditable reporting.

“Trusted data doesn’t just ensure compliance: it accelerates decisions, builds market confidence, and opens the door to new opportunities.”

6 Cybersecurity and resilience

Security is not a cost; it is the insurance policy that protects business continuity and value, making it a critical pillar of Governance (G) and Social Responsibility (S).

• Key selection factors

Prepare for “when,” not “if.” We must evaluate incident response and recovery capabilities, ensuring compliance with standards such as ISO 27001, NIS2, or DORA.

• Key usage factors

No one enters without permission. Implement Zero Trust-based access management and foster a security culture through continuous training and strict protocols.

• Organizational impact

Peace of mind knowing your business is resilient. It minimizes financial risks from cyberattacks, ensures operational continuity, and strengthens trust among customers and investors.

“Security is no longer a cost: it is the insurance policy that protects continuity, reputation, and business value.”

7 ESG integration in the supply chain

Our technological responsibility extends to every partner; a supply chain aligned with Environmental (E), Social (S), and Governance (G) criteria is more competitive and reliable.

• Key selection factors

Tell me who you work with, and I’ll tell you who you are. It is essential to adopt platforms that enable supplier traceability and integrate with ESG risk management systems.

• Key usage factors

Your suppliers’ commitment is your own commitment. It requires continuous monitoring of their ESG performance and clear criteria for selection and retention.

• Organizational impact

A “clean” platform end to end. It reduces reputational risks across the value chain and ensures compliance with governance best practices.

“An ESG-aligned supply chain is more competitive, more reliable, and more attractive to customers and investors.”

8 Software lifecycle optimization

Efficient code means lower costs and faster delivery; it contributes positively to the Environmental (E) pillar by optimizing resource consumption.

• Key selection factors

Build today with tomorrow in mind. Choose frameworks that facilitate maintainability and scalability, while supporting energy efficiency metrics.

• Key usage factors

Deploy fast, but thoughtfully. Implement CI/CD processes for agile delivery and apply refactoring strategies to eliminate obsolete code that consumes unnecessary resources.

• Organizational impact

Sustainability translated into profitability. It reduces operational costs, improves delivery quality, and extends the lifespan of technological assets.

“Efficient code means lower costs, faster delivery, and development that leaves a… positive footprint.”

Conclusion: choosing technology is choosing the future

As I shared at the Smart Energy Congress 2025, choosing technology is choosing the future. By integrating these 8 decision points into our strategy, we transform technology from a support function into a driver that aligns business with social, environmental, and governance challenges.

• Enabler of real impact: technology drives everything from energy efficiency to digital inclusion.
• Competitive advantage: conscious decisions in architecture, data, security, AI, and accessibility enable new business models.
• Investment in resilience: purpose-driven design is not a cost, but an investment that fosters innovation and trust.
• Engine of transformation: platforms don’t just support the business—they connect it to a positive global impact.

"True technological disruption lies not in what machines can do, but in the purpose we choose when designing them."

After everything shared in this series of three posts on technology platforms, what will you do from today onwards? I’ll read you in the comments.

Being one of the latest to arrive does not mean it should be overlooked. Given its track record as a true game-changer—especially when it comes to transparent application execution—Docker has completely revolutionized the development world.

Model Runner is the new tool that Docker has released for running AI models locally, and in this article we will explore its main features.

As a quick reminder, in case you missed any of the previous articles, you can check out the rest of the local LLM execution series here:

• Running LLMs locally: getting started with Ollama
• Running LLMs locally: advanced Ollama
• Running LLMs locally: LM Studio
• Running LLMs locally with Llamafile

How it works and key features

Docker Model Runner enables AI model execution by embedding an inference engine (built on top of the llama.cpp library) as part of the Docker runtime environment. At a high level, the architecture is composed of three main components:

• Model distribution (model storage and client): the model store is the core component of the architecture, where tensor files are stored. The client performs operations (such as downloading) against OCI registries.
• Model Runner: maps API requests to processes that run inference engines (/engines) and models (/models). It includes components such as the scheduler, loader, and runner, which coordinate loading and unloading models from memory (both inference engines and models operate as ephemeral processes). For each combination of inference engine (e.g., llama.cpp) and model (e.g., ai/llama3.2:3B-Q4_0), a separate process is executed depending on incoming API requests.
• Model CLI: the main user interaction component. This is a Docker CLI plugin that provides an interface similar to running Docker images. Under the hood, the CLI communicates with the Model Runner API to execute most operations.

An important note is that, although the overall architecture remains the same, depending on the platform where it is deployed, these three components are packaged, stored, and executed differently (sometimes on the host, sometimes in a virtual machine, and sometimes inside a container).

Some of the main features of Docker Model Runner include:

• Ability to download and upload models to/from Docker Hub.
• Model execution via endpoints compatible with the OpenAI API.
• Packaging GGUF files as OCI artifacts to publish them in any container registry.
• Running and interacting with models directly from the command line.
• Managing local models.
• Defining input prompt details as well as model responses.
• Support for multi-turn interactions (chat).

Installation

Model Runner is available for major operating systems (Windows, macOS, and Linux), either through Docker Desktop or Docker Engine. In this article, we will run Docker Model Runner on Ubuntu using Docker Engine.

After installing Docker Engine if necessary, you can proceed to install Model Runner by executing the following command:

sudo apt-get install docker-model-plugin

Verifying the installation using the command:

docker model version

CLI Commands

Once Docker Model Runner is installed, you can interact with models using the following commands:

1 INSPECT

This command displays detailed information about a model.

docker model inspect ai/llama3.2:3B-Q4_0

docker model inspect ai/llama3.2:3B-Q4_0 --openai #Presentar la información en formato OpenAI

2 LIST

Command to list the models downloaded to the local environment.

docker model list

docker model list --json #List the models in JSON format

docker model list --openai #List the models in OpenAI format

docker model list --quiet #Show only the model IDs

3 LOGS

Command to display logs.

docker model logs

docker model logs --follow#View logs in real time

4 PACKAGE

Command to package a file in GGUF format into a Docker Model OCI artifact.

docker model package --gguf <path> [--license <path>...] [--context-size <tokens>] [--push] MODEL

docker model package --gguf /home/simonrodriguez/dockerModelRunner/model.gguf my_new_llama_model

The available options for this command are:

• --chat-template: absolute path to the chat template file (the template must be in Jinja format).
• --context-size: size of the context window.
• --gguf (required): absolute path to the file in GGUF format.
• --license: absolute path to the license file.
• --push: upload to the registry.

5 PULL

Command to download a model from Docker Hub or Hugging Face.

When downloading from Hugging Face, if no tag is specified, it will attempt to download the Q4_K_M version of the model. If this version does not exist, it will download the first GGUF file found in the model’s Files section on Hugging Face. To specify the model quantization, you simply need to add the corresponding tag.

6 PUSH

Command to upload a model to Docker Hub.

docker model push ai/llama3.3

7 RM

Command to delete local models.

docker model rm ai/llama3.2:3B-Q4_0

docker model rm ai/llama3.2:3B-Q4_0 --force #Force model deletion

8 RUN

Command to run a model and interact with it by sending a prompt or via chat mode.

docker model run ai/llama3.2:3B-Q4_0 #A prompt opens for an interactive chat, which you can exit with the command /bye

docker model run ai/llama3.2:3B-Q4_0 “Hello, what can you tell me about Docker Model Runner?”

docker model run ai/llama3.2:3B-Q4_0 --debug #Enables debug mode

docker model run ai/llama3.2:3B-Q4_0 --ignore-runtime-memory-check #Option to prevent the download from being blocked if the model is estimated to exceed system memory

When a Docker model is executed, it calls the API endpoint of the inference server hosted by Model Runner. The model will remain in memory until another model is loaded or the inactivity timeout is reached.

9 PS

Command that displays the models currently running.

docker model ps

10 UNLOAD

Command to unload a running model.

docker model unload ai/llama3.2:3B-Q4_0

11 DF

Command that displays the disk space occupied by the models.

docker model df

12 STATUS

Command to check if Docker Model Runner is running.

docker model status

docker model status --json #Display the information in JSON format

13 TAG

Command to create a specific tag for a model.

docker model tag ai/llama3.2:3B-Q4_0 quantized-model

If the tag is not specified, the default value is latest.

14 VERSION

Command to check which version of Docker Model Runner is installed on the system.

docker model version

API

Once Model Runner is enabled, API endpoints are automatically exposed (both native Docker Model Runner endpoints and OpenAI-compatible endpoints), which can be used to interact with models programmatically.

When making requests to the exposed API, it is important to consider the origin of the request:

• From other containers: send requests to http://172.17.0.1:12434/. This interface may not always be available for calls from containers. If that is the case, you must include the extra_hosts instruction in the Docker Compose configuration file:

extra_hosts:
  - "model-runner.docker.internal:host-gateway"

With the previous instruction, the API can be accessed through the address http://model-runner.docker.internal:12434/

• From the host: send requests to http://localhost:12434/

Native endpoints

The available endpoints are:

• /models/create (POST): endpoint to download a model.

• /models (GET): endpoint to list existing models in the system along with their information.

• /models/{namespace}/{name} (GET): endpoint to display information about a model.

• /models/{namespace}/{name} (DELETE): endpoint to delete a local model.

OpenAI-compatible endpoints

The exposed endpoints are:

• /engines/llama.cpp/v1/models (GET): endpoint to list available models in the system.

• /engines/llama.cpp/v1/models/{namespace}/{name} (GET): endpoint to expose information about a model.

• /engines/llama.cpp/v1/chat/completions (POST): endpoint to send a chat interaction and receive the assistant’s response. Multiple parameters can be specified, such as temperature, stream, seed, etc.

• /engines/llama.cpp/v1/completions (POST): model response to user input. This endpoint is already deprecated by OpenAI.

• /engines/llama.cpp/v1/embeddings (POST): endpoint to retrieve embeddings from a text.

Since currently only one inference engine (llama.cpp) is supported, this part can be omitted from the URLs above (for example, /engines/llama.cpp/v1/models becomes /engines/v1/models).

Docker Compose

Docker Compose allows you to define models as core components of your application, so they can be declared alongside services, enabling the application to run on any platform compatible with the Compose specification. To run models in Docker Compose, you need at least version 2.38.0 of the tool, as well as a platform that supports models in Compose, such as Docker Model Runner.

For using models in Docker Compose, the models element has been introduced, which allows you to:

• Declare AI models required by the application.
• Specify configurations and requirements for each model.
• Make the application portable across different platforms.
• Allow the platform to manage the model lifecycle.

The configuration options for the models element are:

• model (required): the OCI artifact identifier for the model. This is what will be downloaded and executed by Model Runner.
• context_size: defines the maximum context window size for the model.
• runtime_flags: list of parameters passed to the inference engine when the model starts. For example, for llama.cpp, the parameters can be found here.
• x-*: extensible properties for platform-specific options.

A simple example of a models definition could be:

models:
  llm:
    model: ai/llama3.2:3B-Q4_0
    context_size: 4096
    runtime_flags:
      - "--temp"                # Temperature
      - "0.1"
      - "--top-p"               # Top-p sampling
      - "0.9"

Services can reference models in two ways:

• Short form: the simplest approach. With this method, the platform automatically generates environment variables based on the model name:
  • LLM_URL: URL to access the LLM model.
  • LLM_MODEL: identifier of the LLM model.
  • EMBEDDING_MODEL_URL: URL to access the embedding model.
  • EMBEDDING_MODEL_MODEL: identifier of the embedding model.

services:
  app:
    image: my-app
    models:
      - llm
      - embedding-model

models:
  llm:
    model: ai/llama3.2:3B-Q4_0
  embedding-model:
    model: ai/embeddinggemma

• Long form: with this configuration, the service is explicitly provided with:
  • AI_MODEL_URL and AI_MODEL_NAME for the LLM model.
  • EMBEDDING_URL and EMBEDDING_NAME for the embedding model.

services:
  app:
    image: my-app
    models:
      llm:
        endpoint_var: AI_MODEL_URL
        model_var: AI_MODEL_NAME
      embedding-model:
        endpoint_var: EMBEDDING_URL
        model_var: EMBEDDING_NAME

models:
  llm:
    model: ai/llama3.2:3B-Q4_0
  embedding-model:
    model: ai/embeddinggemma

Here you can find some configurations for specific use cases of the models element in Docker Compose.

Demo

To see this new models element in Docker Compose in action, we created a simple application to interact with an LLM. The application uses the following components:

• Java 21
• Spring Boot 3.4.4 (with built-in support for Buildpacks to create Docker images for applications)
• Spring AI
• Maven 3.8.5
• Docker version 28.4.0
• Docker Model Runner 0.1.40
• Docker Compose 2.39.4

The application simply exposes a /chat endpoint that receives user input and sends it to the corresponding LLM.

Here you can download the sample application code and the README file with the steps to run it.

Conclusions

In this final post of the series, we explored how to run LLMs with Docker and the ease it provides to integrate them into our applications thanks to Docker Compose integration.

Throughout this series focused on running LLMs locally, we have reviewed the most widely used tools and their particularities, all of which offer core functionalities such as commands and API endpoints to interact with models. Currently, Ollama arguably stands out among the rest in terms of available features and advanced model customization.

Based on what we have seen with Ollama and Docker, will we soon see custom AI models (containerized or not) running in the cloud alongside our microservices? Only time will tell.

References

• Docker Model Runner Documentation

In this second article of our Green Quality Assurance (GQA) series, we leave behind the “why” and move into the “how.” If in the first article we established that measuring quality in watts and CO2 is just as important as ensuring software works properly, now it is time to build the foundations that will support this new way of working. It is not just about reducing the energy consumption of our tests or running fewer test cases; it is about completely reimagining our approach to software quality.

The software industry must understand that technical excellence and environmental responsibility are not mutually exclusive goals. In fact, the most innovative organizations are discovering that sustainable QA practices often lead to more efficient processes, more productive teams, and, surprisingly, better final product quality.

But to achieve this balance, we need a robust framework that allows us to assess, implement, and continuously improve our practices.

The journey toward Green QA is evolutionary. We cannot expect an organization to go from zero to one hundred overnight. That is why, in the following sections, we explain a gradual approach that recognizes different maturity levels, provides concrete tools for each stage, and enables us to measure our progress.

Framework layers

Addressing cultural change in an organization regarding quality is usually an evolutionary process in which awareness plays a major role. The shift proposed by GQA (Green QA) introduces a new dimension to that awareness: the goal of doing things in the greenest way possible. But are we really aware of what must change to make this happen? Let’s explore it.

Governance

First of all, it is important to have governance that is appropriate for this context. This is the organization’s official “mandate” and the basis of the entire process. Without it, Green QA remains an isolated initiative. Governance addresses the following points:

• Sustainable quality policy

This is not just a document; it is about defining the “Green Acceptance Threshold.” It establishes the sustainability goals the company is pursuing, setting targets by resource type. Once these goals are defined, everything else is aimed at meeting them. For example: “No production deployment may increase the energy consumption of the microservice by more than 5%.”

• Responsibility matrix

This defines what each member of the organization involved in the delivery lifecycle is responsible for.

1. QA: designs efficiency test cases, defines baseline metrics, and is responsible for executing measurements in each cycle.
2. Architecture: validates that design decisions do not introduce structural energy debt before reaching the testing phase.
3. DevOps / Platform Engineering: ensures that the instrumentation needed to measure consumption is available in test environments. Without observability infrastructure, QA cannot measure.
4. Sustainability: provides energy-to-CO2 conversion factors and ensures data traceability into the ESG reporting system.
5. Compliance: verifies that data collection, processing, and reporting comply with current regulations, particularly the CSRD.
6. Product Owner: formally accepts that acceptance criteria include efficiency metrics, not only functionality and traditional performance.

• Alignment with ESG and corporate strategy. In the previous post, we discussed ESG extensively and its connection to Green QA, and it is something that must be considered within governance.

Processes

This layer establishes how Green QA is integrated into the project’s day-to-day work.

• Shift-Left Green: integrating environmental criteria during the Refinement phase. If a feature consumes too much unnecessary data, it is rejected before development begins.
• Green Gateways in the Pipeline: adding “quality gates” into CI/CD. If automated tests detect an unusual spike in CPU or RAM usage, the build fails. Environmental controls must be present in design, development, testing, and deployment.
• Suppliers: evaluating whether our service providers (Cloud, SaaS) operate using renewable energy.

It is important that governance also defines the consequences of non-compliance with the policy, whether by blocking a release, creating technical debt, or establishing the appropriate mechanisms to prevent bypassing the defined goals.

Data and metrics

This framework layer analyzes the quality of the data that will support decision-making.

• Data traceability: ensuring that ESG data has a clear lineage, from the sensor or server log to the annual report.
• QA Data Cleaning: a process for deleting test environments, temporary databases, and old execution logs that worsen storage conditions and consume unnecessary energy.
• Accuracy vs. estimation: defining which data is measured (real) and which is estimated (mathematical models), applying different QA approaches to each.
• Definition of environmental and ESG KPIs
• Data quality controls (accuracy, completeness, traceability)
• Audit and reporting

Technology

This is the layer of tools. Green QA needs technical eyes to “see” energy. Therefore, it is advisable to have tools to measure the impact of programming languages (for example, comparing Python vs. Rust consumption in critical processes), optimize test suites so they do not run 2,000 tests if only 2 lines of code changed (risk-based test selection), configure the framework so test environments “self-destruct” immediately after execution, and have measurement tools (energy, carbon, resources), green test automation, and infrastructure optimization (cloud, hardware).

Continuous improvement

Within the framework layers, it is advisable to invest in the cultural and improvement aspect so that the framework becomes circular rather than linear.

Elements such as “Retro-Green,” where each sprint retrospective can include a question like: “what process or code did we make more efficient this month?”, gamification through rankings of development/QA teams that have reduced their digital carbon footprint the most, and the updating of standards.

As ESG laws evolve, this layer changes and is typically reviewed quarterly. In this way, the framework continues to comply with new regulations and allows organizations to establish measurable reduction goals, whether quantitative or qualitative.

The path toward Zero-waste Testing

One of the points mentioned above is measurement. It is essential to understand at every moment where we stand relative to the objectives in order to take the necessary actions and decisions while working within the defined governance. If you are familiar with TMMi, it is a process that measures maturity levels in relation to testing within an organization.

In this regard, below is an analysis of existing levels in relation to GQA, so that we can understand where we are and what the goals should be to consolidate or advance through them. Each of these levels should be further developed to make evaluations more concrete.

Level 1: initial (we start walking)

At this level, the company is not aware of the environmental impact of its testing. If there is efficiency, it is for cost savings, not because of purpose. Compliance is reactive, without metrics.

At this early stage, all tests are always executed in environments where we have no visibility into their consumption and which generally remain on 24/7.

Level 2: basic (awareness has awakened)

Stakeholders understand what Green QA is, and the first manual efforts begin to document impact. Manual controls and basic reporting appear.

At this intermediate level, assets such as servers and tools are identified in order to request sustainability reports from providers, creating an inventory of digital assets. Testing begins to be handled more consistently with this policy, for example by deleting old test data.

At this stage, actions still depend on people rather than automated processes.

Level 3: defined (the green standard)

Sustainability is officially integrated into the quality manual. The first standardized processes and KPIs appear.

At this level, having a green production readiness checklist should be one of the goals. To support this, green KPIs are defined (for example, watts per test suite).

At the same time, this level seeks to ensure that the QA team has sufficient training in Green Coding and energy efficiency.

Level 4: managed (automated and measurable quality)

A set of metrics has been established, and continuous reporting automation through pipelines is in place.

Once certain aspects are consolidated, including cultural ones, the goal becomes the use of “real-time carbon dashboards” integrated into tools like Jira or Grafana, so teams can see their daily impact.

The challenge is integrating this data with the rest of the company (ESG). CI/CD pipelines include tools that automatically measure the CPU/RAM consumption of tests. If a test is inefficient, an alert is generated.

Level 5: optimized (Green QA as DNA)

GQA is no longer an “extra”; it is the only way of working. It is aligned with the company’s overall strategy.

Now the company uses AI to predict and minimize the energy consumption of tests. The carbon savings achieved by the QA team are reported directly in the company’s annual sustainability report (ESG). The challenge is maintaining innovation and leading standards in the industry.

Aspects such as the “circular economy of data,” where test data is intelligently reused to avoid generating new loading processes, begin to be taken seriously in order to consolidate green goals.

Strategy and methodology

The strategy is the decision-making framework in which the elements needed to address GQA in practice are defined, aligned with all the framework layers described above.

The methodology describes how we implement the strategy we have defined and is responsible for defining how to execute GQA.

In the context of GQA (or sustainability in the software lifecycle), these tools do not only measure emissions, but also integrate into the quality process to ensure that software is efficient and complies with environmental regulations (ESG).

Once a strategy aligned with objectives has been established, the tools and frameworks that will be used for its implementation are selected. Below are some examples.

Measuring software efficiency (Green Testing)

This is where QA has direct control. The energy consumption of a process or test suite is measured. These measurements are used to establish the baseline.

Before optimizing a single line of code, QA needs to know how many grams of CO2 the hardware running the application generates. Without that, we cannot measure improvement after an optimization.

Tool: Scaphandre (energy metrology)

An open-source power consumption metrics agent designed for Kubernetes and bare-metal servers.

• What it is used for

It measures exactly how many watts a specific process consumes (for example, your Selenium suite or a microservice under load).

• Setup and use

1. Installation: it is installed as a binary or Docker container on the server where tests run.
2. Usage: it exposes metrics in Prometheus format.
3. Green QA Step: configure a Grafana dashboard that crosses “CPU consumption” with “Watts consumption.” If, after a code optimization, the tests take the same time but consume fewer watts, Green QA has succeeded.

Tool: Eco-Code / SonarQube (Green Rules)

• What it is used for

Static code analysis focused on energy efficiency.

• Setup

1. Installation: add the "Green IT" or "Eco-Code" plugin to your SonarQube instance.
2. Usage: QA defines quality gateways. If the code contains patterns that wake up the CPU unnecessarily (inefficient loops, redundant API calls), the quality test fails.

Tool: SimaPro and GaBi

These are industrial standards that can be adapted to the QA ecosystem in the following way:

• What they mean for IT environments

They allow us to model the impact of our digital infrastructure (servers, test mobile devices, or networks). They do not only measure energy expenditure, but also the “carbon debt” of the hardware supporting our software.

• Their strategic use in Green QA

They are used to establish the baseline. Before optimizing a single line of code, QA needs to know how many grams of CO2 the hardware generates. Without this, we cannot measure improvement after optimization.

• Setup and data sources

To control the environmental footprint of our applications, Green QA maps:

• Hardware inventories: CPUs, RAM, and storage systems used in staging and production environments.
• Environmental databases: sources such as Ecoinvent are integrated to calculate the impact of the energy mix (it is not the same to run a test on a server in Norway powered by hydroelectric energy as in a coal-dependent region).
• Practical decision example

Thanks to these tools, the QA team can make comparisons based on real data:

Case study: is it more sustainable to run our regression suite on old on-premise servers or migrate testing to a cloud instance with Energy Star certification and auto-scaling? Green QA uses LCA to demonstrate that migration reduces carbon footprint by X%.

Measuring Cloud Carbon Footprint (CCF)

If you do not want to rely on native tools (which are sometimes opaque), Cloud Carbon Footprint is the open standard.

Tool: Cloud Carbon Footprint (CCF)

• What it is used for

To visualize emissions from AWS, Azure, and GCP in one place with a transparent calculation methodology.

• Setup

1. Connection: you need read permissions for billing files (CUR in AWS, Billing Export in GCP).
2. Usage: it allows the QA team to compare regions.
3. Technical decision: QA can demonstrate that moving the staging environment from a coal-based region (for example, Virginia, US-East-1) to one powered by cleaner energy (for example, Sweden or France) instantly reduces carbon footprint without changing a single line of code.

Tools: Watershed, Persefoni, Plan A

These are SaaS platforms for measuring corporate carbon footprint.

• What they are

They automate the calculation of Scope 1, 2, and 3 emissions.

• Usage in Green QA

Software falls under Scope 3 (indirect emissions). These tools collect data from your electricity bills and cloud providers.

• Setup

They connect via API to your inventory systems. The QA team reports the energy consumption of test server farms here so the company has real data on IT department impact.

Measuring sustainability in the Frontend

GQA also measures the impact on the end-user device.

Tool: GreenFrame.io or Lighthouse (Carbon Indicator)

• What it is used for

To measure the carbon footprint of a user session in the browser.

• Setup and use

1. CI/CD Integration: it integrates with GitHub Actions or Jenkins.
2. Usage: every time a visual regression test is launched, GreenFrame estimates the grams of CO2 produced by loading the page (data transfer + JS execution on the client).
3. QA Metric: “this new Home version weighs 2MB more and generates 0.5g of extra CO2 per visit.” This is reported as a Sustainability Bug.

QA and audit: green quality management

This is where you connect data with the testing process.

Jira and TestRail

• Usage in Green QA: they do not measure carbon by themselves, but they are configured to manage green requirements.
• Setup
  • Jira: create custom fields such as Estimated Carbon Cost in User Stories.
  • TestRail: create a “Green Test Cases” section where you validate that the app enters power-saving mode or does not make unnecessary API requests.

ESG data platforms (Environmental, Social, and Governance)

• What they are

Repositories where all evidence for legal audits is stored.

• Usage in Green QA

The result of your green tests is uploaded here as proof of regulatory compliance (for example, to comply with the CSRD directive in Europe).

• Pipeline configuration

For this to be true “Green QA,” the flow must be:

1. Define thresholds: in Jira, set an energy consumption limit per feature.
2. Measure: during execution (Cucumber/Playwright), monitor consumption with tools such as Scaphandre or Intel Power Gadget.
3. Visualize: cross that data with the Azure Emissions Dashboard.
4. Audit: export reports to Persefoni or Plan A for annual accounting.

Conclusions

The transition process within an organization to embrace GQA involves a series of unavoidable steps and an adaptation process at every level.

It requires involvement from both the business and technical sides, beginning with cultural change and continuing through methodological and strategic adaptation.

All these changes will help the company comply with the legal framework already mentioned in the previous post.

My experience

I have been managing projects for almost fifteen years — first under a waterfall methodology, and now I am an agilista (or at least I try), working with Scrum. When humanity took that great leap toward true value delivery, leaving behind endless Project Management Plan documents printed in A3, we also forgot to ensure, through a time-box, this space to understand the project, the client, and the team — to make initial contact, put faces to names, and start getting to know each other.

Defining the rules of the game, understanding needs, feeding the backlog, making initial estimates… all of this is just as important as delivering a Minimum Viable Product (MVP). In fact, it is essential for the MVP to meet the expectations of all stakeholders. Because sometimes — just sometimes — in that first contact, one side realizes the other cannot deliver what was expected, and we avoid discovering this when half the work is already done.

It is true that working in consulting is not the same as working for a final client. Consultants serve clients who have a product to sell, which somehow also becomes our product. But this service has an end date, so generally in consulting we tend to request these time-boxes to align expectations and ensure deliverables with greater reliability. On the client side, where information is more direct and immediate, there is often a tendency to think that these spaces — where the team reflects, plans, aligns, and gathers context — are unnecessary.

This initial phase of the project provides a series of advantages that allow us to start the first Sprint with a higher chance of success, compared to diving straight into it without fully understanding what we are facing:

1. You will get to know your client

And to do so, you will make time — even when there is none — for kickoff meetings where the team presents what has been understood from the agreed scope (the project charter) and the conclusions drawn from this initial phase, where sometimes people only understand what they want (or are able) to understand.

From these meetings, questions will arise that may (or may not) change the product scope and even increase its value — because, honestly, they had not even been considered before. And what better value delivery than adding value to your own product?

2. You will get to know the team and start building relationships

I’m not talking about having “a good team” in abstract terms, but about creating the feeling of moving as one, rowing in the same direction. In those early days, you begin to see — and be seen: strengths, habits, styles, and how each person reacts under pressure or uncertainty.

That knowledge is invaluable because it allows you to anticipate and manage risks and dependencies that are not visible at first: misunderstandings, misaligned expectations, misinterpreted silences, or decisions no one dares to make without a clear framework.

3. You will help the team and the client get to know each other

In those early meetings filled with questions and clarifications (business, technical, and “how do we actually do this?”), the real starting point is built. If mutual trust is established during this period, everything flows better afterward: when the team proposes something unexpected, the client will at least listen; and when business priorities change mid-way, the team will treat it as what it is — an adjustment, not an impossible drama.

4. Together, we establish the rules of the game

This already accounts for half the success of the deliverable: sprint duration, daily stand-up time, planning/review/retro agendas, estimation approach, and how we write user stories. We also set up the basics: repositories, access, tools (Jira or not?), and initial technical decisions to avoid improvisation. With all this, we outline a lightweight initial roadmap to understand where we are starting and what milestones lie ahead.

5. The Product Owner can leave this phase with an initial Product Backlog

A first version — but enough to build an MVP that becomes the foundation for everything else. As Scrum dictates, the backlog will evolve throughout the product lifecycle, but defining initial epics, stories, and tasks gives us a solid starting point to begin building (and learning) from Sprint 1.

6. From all meetings, impressions, ideas, and decisions, an initial risk management can be established

This allows us to create an initial picture of potential scenarios the team may face and try to eliminate or mitigate them before they become real problems.

All of this lays the foundation of the project, from which the path begins — not only toward successful deliverables but toward doing things properly, always, always through alignment.

In real life…

Let me share a real case that reinforced all of this for me. I was assigned to a project with a client we had worked with before — in theory, nothing should have surprised us. A short, urgent project: the client wanted a deliverable by early year, and we received it in mid-November. December in between, with holidays already scheduled… so the margin was tight.

Looking ahead, we realized it was necessary to discover each other to strengthen the product and build as much as possible at the highest possible speed, delivering a quality MVP that could grow incrementally.

We spent two weeks getting to know each other: 10 working days where, based on the project initiation document, we worked closely with the client to resolve requirement doubts, extract all necessary User Stories, estimate them, and therefore estimate the entire project.

Given the impossibility of delivering everything desired by the client’s deadline, the idea was to propose an MVP that would evolve through value deliveries every two weeks, with new features and deployment milestones until completing everything defined in the requirements document.

We started with enthusiasm, determined to do it right. We explained that sprints would be 2-week time-boxes, used every available moment to gather more information, clarify doubts, define how features could be more effective, and build a roadmap with milestones and value deliveries.

The first week went smoothly: committed client, motivated team… what could go wrong? By the second week, the client stopped attending meetings, became vague in responses, and stopped replying. Before we could finalize the roadmap and delivery plan, they canceled the project.

A failure? For me, quite the opposite: it was an early signal that saved us weeks of pressure and wasted effort. Without that initial phase, we would have discovered it much later — with work already done, an exhausted team, and a frustrated client.

What conclusion do we draw?

So, was Scrum wrong for not “inventing” a Sprint Zero? From a strict Scrum perspective, it may not make sense: a Sprint is a Sprint. But real life — especially in consulting — rarely starts under ideal conditions, and that’s where this discovery time-box becomes an ally.

In today’s context, with the growing need for adaptability, it makes sense to go through this discovery phase with the client — something that has existed since the origins of project management.

What would have happened in that project where the client withdrew in week two? Would we have realized so quickly that we were not aligned? Probably not. We would have gone through six weeks of intense pressure, trying to deliver something unachievable, with a stressed team, a frustrated client, and quality and methodology both questioned.

Traditional project management already accounted for something similar: before execution, you needed to initiate and plan — understand the context, align expectations, and define a roadmap.

Call it what you want, but the need to understand the client, the problem, and the project conditions is not new — what has changed is how we do it. Today, we don’t aim for exhaustive waterfall-style planning, but for a lightweight and adaptive start: empathizing with goals, clarifying needs, making assumptions visible, identifying risks, and leaving with a first working vision.

In short: think just enough at the beginning so you don’t pay later for not thinking at all.

At Paradigma, we apply this mindset through Polaris, our framework, where we maintain Agile principles while adapting to each client’s lifecycle:

• We keep the Agile essence, applying the 80/20 rule: 80% is team attitude, 20% is practices, tools, and experience.
• The Scrum Master evolves into an Agile Delivery Leader, ensuring coordination, value focus, and clarity.
• We follow a shared True North, guiding decisions and maintaining direction.
• We work in a 100% adaptive framework with clear phases: pre-project, kickoff (Sprint Zero), iterations, and closure.
• We proactively manage risks from day one.
• We aim for productivity, doing what is necessary first, then what is possible, and eventually what seemed impossible.
• We rely on metrics to make decisions, adapting them to each context.
• Quality is non-negotiable, ensuring superior products.
• We understand that software is about solving business problems, so our approach is always aligned with the client.
• Team experience matters, and relationships with clients are key to success.

And I’ll close with something simple: life gives us the ability to choose — also when managing projects and trusting others with our products. Nothing guarantees 100% success, but if we can choose, I’m clear: better to get to know each other before jumping to conclusions, better to empathize before blaming.

Better to discover things early than end up with a list of “I told you so” that leads nowhere… and certainly not to product success.

The good news is that the industry has already found the solution, and it’s not something invented overnight. The answer, as we have been advocating, lies in applying the most rigorous discipline we have: Platform Engineering. The days of “testing with soda” (the AI preparation phase) are over — now it’s time for the application of AI in production, at scale, with responsibility and speed.

The need for an AI platform is not just a trend — it is the AI-native infrastructure that leading companies, including some of our clients, are already building in the market today.

The industry is already there, and there are reference solutions

The truth is, we don’t need to be guinea pigs. The heavyweights are already clearly stating what we are seeing: AI needs Platform Engineering.

Google and Thoughtworks are just two examples of how the industry’s vision is converging. The message is clear: if you want to scale MLOps consistently, you need Golden Paths and the abstraction that only Platform Engineering can provide. It’s not just about having more GPUs — it’s about making those GPUs consumable without a 300-page manual.

What does this mean? It means that the goal is not just to support current models, but to create AI-native infrastructure. In other words, a platform designed from the ground up to orchestrate the complexity of AI agents, vector data, and the MLOps lifecycle. We are talking about a platform where automation and intelligence are built in.

If industry leaders have already validated this blueprint, the question is not if we should build it, but when we start.

An AI platform is rarely built from scratch using a single product. It is based on an intelligent orchestration of components that reduce friction and provide flexibility. For teams starting this journey, it is crucial to identify the stack that will serve as the foundation. An example of an industrialized Golden Path includes tools such as:

• Pipeline orchestration: Kubeflow or MLflow, to standardize workflows (training, packaging, and model deployment).
• Training data management (Feature Store): tools like Feast, ensuring data consistency between training (offline) and prediction (online).
• Model serving and MLOps core: using Kubernetes for deployment is just the beginning. Specialized solutions like KServe help manage scaling and model monitoring complexity.

The key is not adopting all these tools, but ensuring that the AI Platform abstracts them, so Data Scientists only interact with the simplified Golden Path we define.

Real use cases: tangible ROI

CxOs love the word ROI. How do we evangelize the value of this platform? Simple: with facts — showing where self-service and traceability generate revenue or mitigate risk.

Let’s ground this with three examples where the AI Platform provides the strongest foundation:

• Retail and personalization at scale

A platform that enables deploying a recommendation engine for each customer segment (or even each individual) in a matter of hours. The advantage: if Data Scientists can iterate on recommendations ten times faster thanks to an automated Golden Path, the company sells more. The business focus is on improving the algorithm’s Time-to-Market.

• Dynamic fraud detection

Risk analysis. Here, the AI platform not only deploys the detection model but also ensures auditability and real-time monitoring of model drift. If the model starts to fail, the platform detects it and automatically rolls it back, protecting the company from multimillion losses or regulatory failures.

• Internal IT and automation

We can use the AI platform to enable Data Scientists to build internal AI agents that automate support ticket management or optimize cloud resources. Moving from “we have an AI agent in testing” to “the agent resolves 20% of L1 incidents” is only possible with a platform that reliably manages its lifecycle and state.

There are countless use cases. As experts in your vertical and business domain, you will surely identify many more opportunities to capitalize on.

The CxO roadmap: beyond code and technology

This is where the CxO shifts into strategic consultant mode. Technology is the how, but strategy and people are the what. We cannot talk about an AI Platform without addressing change management.

Strategic alignment: connecting DORA to the balance sheet

We need to translate Feature Store jargon into business language — the language of those who unlock investment.

Using principles from our Platform Engineering series:

• Business KPIs and MLOps metrics: demonstrating that reducing Lead Time for Changes (a DORA metric we should use to measure the platform) directly translates into faster product launches and reduced risk. This is the only way to justify the investment with evidence.

Additionally, for AI and models, we can introduce specific metrics:

• PoC-to-Prod Ratio: the percentage of Proofs of Concept that reach production within 90 days. The platform should increase this ratio from the current 10–20% to over 70%.
• Model Lift: measuring the incremental improvement in business metrics (e.g., conversion increase, fraud reduction) before and after deploying the model through the platform.
• MLOps TCO Reduction: quantifying operational cost savings achieved through self-service and automation, eliminating dependency on TicketOps and manual infrastructure configuration.

Change management: bridging Data Science and engineering

This is probably the hardest part. We need to reconcile and empower both worlds:

• Data Scientists are not DevOps — and they shouldn’t be. That’s why the platform is essential as a bridge. We must establish an internal product culture: the platform team provides services and capabilities, and the Data Science team is the customer.
• Training and new roles: invest in developing Machine Learning Engineers, the glue between Data Scientists and Platform Engineers.

The first step is technological abstraction and addressing real business needs

The industry is doing it. At Paradigma, we are already doing it. We see that the benefits are tangible, and above all, we see that the risk of falling behind is unacceptable. AI is the new competitive battlefield.

So, where do we start?

My recommendation for all C-level executives, decision-makers, and business unit leaders responsible for technology decisions is simple: start with the highest-friction components — those that consume the most effort without directly impacting the business.

Focus on what is most valuable to optimize and industrialize, and what accelerates the journey from idea to production.

• Do not try to build the entire IDP at once. That would be a mistake. Be pragmatic.
• Start with capabilities like a Feature Store to solve data quality issues, or a Model Registry to address traceability and governance of model usage within your organization.

These are just a couple of examples, but those familiar with the process and its pain points will be able to identify “small wins” that gradually build momentum and shape the AI Platform.

Any effort that reduces manual self-service and increases standardization is paving the way toward that inevitable AI Platform. The platform is not built in a day — it is a journey. The best way to evangelize and generate traction is to demonstrate value through small but solid Golden Paths.

I hope this series of posts has sparked your curiosity about why this topic is so important, provided strategic justification through real-world challenges, and most importantly, given you ideas on where to start building a practical roadmap that delivers value and helps lead the AI conversation in your organization.

If you’d like to revisit the previous two posts in the series, here they are:

• 2026 will be the year of AI platforms
• From PoC to production: many proofs of concept, but few in production

All of this has worked relatively well. Beyond the constant change and evolution across the entire technological landscape related to AI, there are no major problems until the moment comes to make it production-ready.

The reality of AI in production

As we already mentioned in the first post of this three-part series, the AI Platform is no longer an option but a necessity. But why is this need so urgent? In my opinion, it’s because we are losing money, time, and opportunities every single day.

Most companies are trapped in a discouraging “Groundhog Day” loop: proofs of concept tend to succeed, but moving them into production is painful. The reality is that Data Scientists perform magic in their notebooks and the results are promising, but when trying to move those models into the real world, they hit a wall of bureaucracy, tickets, lack of standardized tools, missing automation, and security team bottlenecks.

It becomes a nightmare. And that nightmare translates into very concrete bottlenecks and problems that the AI Platform must eliminate.

Problem 1: self-service and the pain of TicketOps

Let’s put ourselves in the shoes of the AI team. They have just trained a model that could save millions, and all they need is surprisingly to deploy it.

What happens next? In 90% of cases, they need to contact an infrastructure team, open a ticket, wait three days to get a namespace assigned, request network permissions, and hope for access to a feature database. This is what we call "TicketOps", and it is a major problem for Time-to-Market.

⚠️ Important: this process is necessary. We should not underestimate the potential security or regulatory compliance issues that could arise.

However, the situation is becoming even worse. With the rise of LLMs, the problem has grown significantly. Deploying an LLM is very different from deploying a simple regression model. It may require GPUs, specialized storage, and APIs that manage the complexity of prompting and memory usage. Without a self-service tool that allows this to be deployed in minutes, it simply does not happen. The democratization of LLMs ends right there.

Previously, a Data Scientist could request a server and that solved everything. Today, it is necessary to deploy a microservice that consumes an LLM, uses a vector database for long-term memory, and also requires dedicated access to a GPU node in the cluster. If that process cannot be reduced to a single command in our IDP, we are creating a technical barrier for every new AI idea — directly impacting the business and, therefore, our customers.

Problem 2: compliance and regulatory requirements

When we talk about AI, the risk is enormous. A model that makes biased decisions or operates with outdated (or private) data can cost a fortune in fines or even destroy a company’s reputation.

Here, the problem is twofold:

1. Quality

The AI Platform must guarantee that training data is consistent. If we do not standardize how data is ingested and versioned, the production model will inevitably drift. It is Garbage In, Garbage Out taken to the extreme.

The consistency problem is caused by the absence of a Feature Store. Data Science teams often calculate the mean or standard deviation of a data column during training, but the code that calculates that feature in real-time in production is different.

A Feature Store, managed by the platform, guarantees that the code used to compute a feature is the same during training and serving (production). It is the only way to ensure mathematical consistency.

2. Security

Who has access to the model? How are changes in code and datasets tracked? Without traceability and security policies by design (integrated into the Golden Paths), auditing becomes impossible.

And honestly, the idea of a Data Science team manually configuring firewall rules gives me chills. It’s a disaster waiting to happen.

Problem 3: Time-to-Market (TTM) pressure

This is the point that matters most to the business. What is the value of having an innovative model if it takes six months to reach the customer? Competitors are not waiting, and Time-to-Market becomes the most critical business metric.

Today, platform teams face enormous pressure to operationalize AI (that is, to make it reliable and fast). They must move at the speed of innovation, not at the speed of infrastructure.

The solution — and this is where Platform Engineering starts to feel almost like science fiction, is moving from TicketOps to Intent-to-Infrastructure.

In other words, giving a Data Scientist the ability to tell the platform: "I want an environment to train a classification model with a specific dataset."

The platform automatically translates that intent into all the required infrastructure (Kubernetes, networking, secure storage) in a matter of minutes.

This removes the biggest bottleneck: friction and dependency between teams. It allows us to move from idea to production at the speed the business demands.

Conclusion

If we combine bureaucracy and rigid processes (often tied to ticket-based workflows), the importance of data quality, and relentless Time-to-Market pressure, we quickly understand that AI without a platform becomes an expensive and frustrating research project, not a competitive advantage.

AI platforms are the only tool that allows organizations to maintain control without sacrificing speed.

We have seen the real problems and bottlenecks that slow down the ability of AI to deliver value to businesses and customers. In the final post of this series, we will stop talking about pain and start focusing on solutions.

We will explore what the industry is doing, with concrete examples and use cases, and define the first steps of a practical roadmap so your team can start building that model factory today.

Testing everything at all times may not be the most optimal or the most ecological approach. Improving testing cycles and adapting both process quality and product quality to reduce emissions becomes a new challenge for teams.

In this series of three posts about Green Quality Assurance, we will explore this new perspective to understand what it consists of, which frameworks may be most suitable to achieve our goals, and how to establish KPIs and metrics within an organization or project to guide our practices toward greater efficiency and sustainability.

In this first part, we will focus on explaining what it means to be environmentally conscious in the QA world and how this need arises, driven by European regulations such as CSR (Corporate Sustainability Reporting Directive) and concepts like ESG (Environmental, Social, and Governance).

What is Green QA?

Imagine your quality process becoming an “athlete”: faster, stronger, and much more efficient. Green Quality Assurance (GQA) redefines QA, QC, and testing processes so that each one matters, reducing energy consumption and carbon footprint without losing the rigor required.

Integrating sustainability into the quality of the process (QA activities during software construction) and into the quality of the product (QC and testing, validating and verifying the built product) means ensuring that software is not only good in terms of quality, but also efficient in terms of energy consumption and sustainability, and aligned with ESG principles, which we will explore later.

Organizations that integrate social responsibility into their development lifecycle, while maintaining performance and controlling costs, present a competitive advantage to potential clients. This allows those clients to improve their sustainability metrics without sacrificing other objectives.

Aligned with the concept of GQA is GreenCode, which focuses on coding practices that seek energy efficiency through techniques such as lazy loading, microservices instead of monoliths, and lightweight code that extends the lifespan of the devices on which it runs, among other aspects.

Green IT goes hand in hand with the above concepts and serves as their foundation. It refers to the use of hardware with high energy efficiency certifications and the use of cloud infrastructure, since large providers such as Amazon and Google often rely partly on renewable energy sources like solar power to maintain their data centers.

Currently, from a legal perspective, there are regulations that require companies to present CSR reports (or Sustainability Reports). At the European level, this is known as the CARD directive, which in Spain has been mainly integrated through the Corporate Sustainability Reporting Law (LIES). It is important to remember that the CARD directive requires the use of ESRS standards (European Sustainability Reporting Standards). These standards require certain companies to break down their energy consumption and emissions depending on the size and type of company. As you can see, Green QA has legal coverage and, if its objectives are achieved, it helps companies comply with these requirements.

As an example of the use of these regulations and Green QA, a traditional CSR report might say: “we want to be green,” while a report under the CARD directive would require something like: “our Green QA suite reduced CPU consumption by 12%, saving X tons of CO₂ this year.”

ESG as DNA

Continuing with the concepts surrounding GQA, and since we will refer to it frequently, let’s briefly explain what ESG is.

ESG (Environmental, Social, and Governance) is the set of criteria that investors, governments, and customers use to measure whether a company is responsible in terms of environmental impact, social responsibility, and internal governance.

When we talk about Environmental, we refer to the environmental impact a company has on the planet. Green QA plays a significant role here, helping with aspects such as:

• Key topics: carbon footprint, energy efficiency, waste management, and climate change.
• In software: how much energy do your servers consume? Is your code optimized to avoid unnecessarily heating processors?

When we talk about Social, we refer to how the company manages its relationships with people and society.

• Key topics: diversity, human rights, workplace safety, and data protection.
• In software: this includes accessibility (ensuring that people with disabilities can use your application) and ethical data practices (user privacy).

Finally, when we talk about Governance, we refer to how the company is managed internally — the rules and transparency that guide its operations.

• Key topics: business ethics, executive compensation transparency, anti-corruption measures, and legal compliance.
• In software: quality audits, compliance with software regulations, and transparency in development processes.

Now that we understand ESG, we can see how the technical quality role can evolve — from guaranteeing the method and the product to also ensuring ESG compliance, thereby becoming a guardian of sustainability as well.

Understanding the major ESG pillars (environmental impact, social impact, and internal governance), GQA helps achieve objectives in the technological domain:

• 🍃 Environmental: optimizing automated test suites and improving cloud efficiency to directly reduce the software’s carbon footprint.
• 🤝 Social: promoting digital inclusion. Efficient code consumes fewer resources and performs better on older devices, helping combat planned obsolescence.
• ⚖️ Governance: generating technical metrics and transparent reports on energy consumption, facilitating compliance with green audits.

Organizations that align their quality lifecycle management processes with ESG goals without compromising speed, cost, or performance will gain a decisive advantage in a market increasingly saturated with high-performance CSR requirements.

Main objectives

The main objectives of this philosophy are resource optimization, operational efficiency, and profitability. Among the goals pursued are reducing environmental impact by lowering consumption, reducing waste and emissions, and optimizing the use of material and computational resources.

We know that every time a test suite runs (especially in the cloud or on large servers), electricity is consumed, which generates a carbon footprint. Reducing this impact through selective testing and efficient test code should be a key goal.

Another objective of Green QA is alignment with ESG, providing environmental metrics:

• Enabling auditable sustainability reports (test cycle consumption, etc.)
• Providing insights for sustainable data governance (reducing data duplication in TDM test environments), which lowers physical storage requirements in data centers.
• Providing audit trails proving that quality processes comply with the organization’s “Net Zero” policies.

Impact areas: where quality becomes green

To achieve Green QA objectives, we must intervene in key digital assets. It’s not only about verifying that software works — it’s about ensuring it is sustainable. To do so, we must act in the following areas:

Validation of digital products and processes

• Software lifecycle analysis (S-LCA): QA no longer only validates the “Go-Live”; it audits environmental impact from development and testing through deployment and eventual software decommissioning. Its role is to ensure that energy consumption calculations at each stage are accurate and realistic.
• Code sustainability verification: implementing protocols to measure the “energy density” of functions. QA performs efficiency tests to prevent bloatware and ensure the product does not force user hardware obsolescence.

Sustainability audits in infrastructure

• Cloud provider validation: QA verifies that the infrastructure hosting the software complies with renewable energy certifications (PUE – Power Usage Effectiveness). We don’t just test in the cloud — we audit that the cloud is green.
• Optimization of the digital supply chain: reviewing third-party libraries and dependencies. Green QA detects inefficient dependencies that consume resources in the background without delivering value.

Validation of eco-design in software

• Repairability and modularity criteria: validating that code is structured so it can be easily maintained and updated without refactoring the entire system, saving unnecessary computation cycles.
• Data transfer efficiency: specific tests to reduce the weight of API requests and data traffic, directly lowering electricity consumption in data centers and telecom networks.
• Carbon-aware load testing: measuring not only how many users the system supports but also how much CO₂ the server emits under that load.

Ensuring ESG data integrity

For a sustainability report to be valid, the data must be highly accurate. Green QA becomes the technical auditor ensuring the integrity of every metric, which requires proper training for this role to certify the provided information.

1. Validation of emissions KPIs

The QA profile must ensure that calculation algorithms and data sources reflect the real energy consumption of the digital ecosystem:

• Direct emissions: first level. Validation of data from proprietary infrastructure and on-premise servers.
• Purchased energy: second level. Verification of electricity consumption reports from contracted data centers and their energy mix (renewable vs. fossil).
• Value chain: third level. The biggest challenge. QA audits the efficiency of third-party APIs and the energy consumption generated by the software on end-user devices.

2. Accuracy and reliability of reports

Having data is not enough — it must be correct. Techniques are applied to prevent bias in sustainability reports:

• Stress testing of carbon footprint calculation models.
• Validation to ensure there are no duplicated emissions counted across departments.

3. Traceability and auditing (Data Lineage)

Implementation of traceability tests to ensure that every data point in the annual report can be traced back to its technical origin (server logs, CPU metrics, etc.). If an auditor asks where a number comes from, Green QA has the documented answer.

4. Consistency in ESG disclosure

Ensuring that the data published on the website, in the app, and in the legal CARD directive report are identical. Automated cross-validation processes should be implemented to avoid discrepancies that could result in legal penalties.

Application of standards and regulations

Several frameworks and standards support the implementation of these “green” processes. Here we briefly review them; in future articles we will explain how they can be applied strategically and methodologically:

• ISO frameworks (14001 and 50001): ensuring QA processes are documented to pass external environmental and energy management audits.
• CARD (Corporate Sustainability Reporting Directive): the new European regulation ensuring legal sustainability reporting requirements are technically fulfilled.
• EU Taxonomy: validating that company activities are correctly classified as “green” according to EU technical criteria.
• GHG Protocol (Greenhouse Gas Protocol): establishing the standard methodology for calculating carbon emissions derived from the software lifecycle. QA must validate energy consumption data collection in Scope 2 (server/cloud energy) and Scope 3 (third-party cloud services and end-user software usage), ensuring emission factors are accurate for carbon footprint reports.

Conclusion

We have seen how, within the world of software quality, there is an aspect that is rarely considered yet has a significant impact.

Applying GQA not only improves sustainability but also enhances efficiency, which ultimately reduces costs in both processes and product development.

All these processes are supported by a set of European regulations and their transposition into Spanish law, making them even more relevant since non-compliance can result in financial penalties for companies.

Ultimately, Green QA is about doing our part to improve life through quality practices.

Today we’ll go one step further: we’ll see how Angular Signals, the new reactivity API in Angular introduced experimentally in Angular 16, makes it possible to improve UI efficiency, update only what is necessary, and simplify state management in Angular components, optimizing the performance of your applications.

The problem with classic change detection in Angular

In the traditional approach:

• Each component has its own change detector.
• Angular traverses the component tree every time an asynchronous event occurs (click, timer, HTTP request).
• In applications with many components or large lists, this creates unnecessary change detection cycles, affecting performance.

For example, in the previous article we created a clock that updates every second and a table of users. The clock update triggered a full Angular change detection cycle, recalculating random values in each row, even though the data had not changed.

Angular Signals: how they improve reactivity

With Angular Signals:

• Each signal represents a reactive value.
• Angular updates only the bindings that depend on that signal.
• Derived values (computed) are recalculated automatically.
• There is no need for ChangeDetectionStrategy.OnPush or ChangeDetectorRef to optimize performance.

This makes Signals a key tool for improving performance in Angular, especially in large applications with lists and complex components.

Signals, effects, and derived values

To better understand it, let’s see how Signals work in Angular.

Create a signal

import { signal } from '@angular/core';

const counter = signal(0);

• A signal represents a reactive value.
• To read it, it is invoked as a function: counter().
• To write to it, .set() or .update() is used.

Effects (effect)

Effects are functions that run automatically when the signals they use change.

import { signal, effect } from '@angular/core';
const counter = signal(0);
effect(() => {
  console.log(`The counter value is ${counter()}`);
});
counter.set(1); // The effect runs and prints “The counter value is 1”

Computed values

You can compute a value from one or more signals without having to rewrite additional logic.

import { computed } from '@angular/core';

const double = computed(() => counter() * 2);

• When counter changes, Angular automatically recalculates double.
• computed is read-only and cannot be modified manually.

Advanced features of Angular Signals

In addition to what we have seen, Angular Signals includes several important features, according to the official documentation:

Computed is lazy and memoized

• It does not execute until someone reads it.
• It memorizes its last value.
• It only recalculates if one of its dependencies changes.

const counter = signal(0);
const double = computed(() => {
  console.log('Recalculando...');
  return counter() * 2;
});

• If you never call double(), the function is not executed.

Dynamic dependency tracking

Angular only tracks signals that are actually read within a computed or effect.

const show = signal(false);
const counter = signal(0);

const conditional = computed(() => show() ? counter() : 0);

• As long as show() is false, conditional does not depend on counter.
• This optimizes performance and avoids unnecessary recalculations.

Signals in templates

{{ counter() }}

• Angular automatically detects that the template depends on the signal.
• The UI updates only when the value changes.
• You don't need async pipe, ChangeDetectorRef, or markForCheck.

untracked(): avoid reactive dependencies

Allows you to read a signal without registering it as a dependency within an effect or computed.

effect(() => {
  console.log(`User set to ${currentUser()} and the counter is ${untracked(counter)}`);
});

• The effect runs only when currentUser changes.
• Changes in counter do not trigger the effect, but we can still read its current value.
• This is useful when you want to read data incidentally without turning it into a trigger for reactivity.

Live practical example: clock and user table with Angular Signals

Instead of showing all the code here, we’ve prepared an interactive example on StackBlitz so you can see Angular Signals working in real time.

In this example you will observe:

• A clock that updates every second.
• A user table where each row depends on a signal, avoiding unnecessary updates.
• How the UI updates only when the relevant state changes, improving performance compared to classic change detection.

Try the live example on StackBlitz.

Visual comparison

Conclusion

Angular Signals represents the evolution of the change detection model explained in our previous article.

Previously, any asynchronous event could trigger a full change detection cycle. Now, Angular updates only the bindings that depend on the signals that change, avoiding unnecessary computations and improving efficiency.

With Signals and derived values (computed), we can build faster, more predictable, and easier-to-maintain applications, especially as the component tree grows.

Before we begin…

Throughout this post we will use some concepts that are very common when talking about digital product development, but that’s okay if you’re not familiar with all of them. Here are a few to make sure we can provide as much value as possible:

Product vision: what we want to achieve with our product and how we see it in the future. It’s an inspiring statement that indicates where we want to go and where we want to be in the future.

Product strategy: the how we will achieve our vision. Strategy includes aspects such as differentiation from competitors, the type of users we are creating the product for, and the value proposition. Strategy aligns what we can do with what we should do.

Product backlog: a prioritized list of the features we need to develop to create solutions for our users’ problems and needs — in other words, the product.

What is a roadmap

A roadmap is the plan to follow in the development of your product in order to achieve the vision and meet the objectives.

Contrary to what some may think, a roadmap and a project plan are two different tools, although both are used in software product management and can complement each other.

While a project plan is very operational and reflects aspects such as scope, budget, dependencies, and tasks in great detail, a roadmap is much more strategic and focuses on how to achieve the product vision.

Here are some of the most significant characteristics of roadmaps:

• It is the plan to achieve the vision. It is not a list of tasks but an action plan that guides the path toward our vision.
• Flexible and adaptable tool. It is dynamic and evolves over time as we receive feedback from users, allowing us to adapt our strategy to achieve the vision.
• A communication tool. It helps align different stakeholders through transparency, ensuring that everyone shares a common vision.
• Connects business goals with the plan to achieve them. The initiatives included in the roadmap, individually or together, aim to achieve the objectives of the product and the company.

We can say that a roadmap is how we present our strategy to achieve our vision.

What a roadmap is NOT

Now that we’ve discussed what a roadmap is, let’s also clarify what it is not:

• It is not a list of tasks. Our roadmap will not include every task we need to develop, but rather a set of initiatives that will guide product or project development.
• It is not a timeline. Although a roadmap may include timeframes and dates, they are more flexible and can change if the strategy evolves based on feedback. A roadmap should always be agile, flexible, and adaptable.
• It is not an execution plan. It does not explain how to carry out each initiative; instead, it focuses on what needs to be achieved.

For example, an initiative in the roadmap could be improving the onboarding process. The tasks required to achieve it might include adding an interactive demo or integrating an assistant to guide users through the process. These tasks might have specific dates, but those would not appear directly in the roadmap.

Steps to create a roadmap

To start working on your roadmap, consider the following:

Product vision

The first thing you need to do is ensure that you clearly understand your product vision. If not, try asking yourself the following questions to help define it:

• Why does our product exist?
• What problems does it solve or what needs does it cover?
• Who will use it?
• What would have to happen for us to consider it a success?

For example, Slack’s vision is: Make work life simpler, more pleasant and more productive.

Here is a template to help you develop your product vision.

Themes

These are initiatives or specific projects that help achieve business goals. These themes will later be broken down into more specific tasks such as user stories.

Example: “Redesign the purchase funnel.”

Choosing the type of roadmap

There are several ways to design your roadmap, which will determine the next steps you need to follow. Here are two examples to help you get an idea — although many more exist.

Now–Next–Later roadmap

If we focus on the flexibility of roadmaps, we can talk about a well-known type: Now, Next, Later.

In this type of roadmap, no specific timeframes are defined. Instead, we focus on what we are currently working on (Now), what we will work on next (Next), and what we plan to do in the future (Later).

Here is a visual example of a Now–Next–Later roadmap 👇

As you can see, each theme is represented, and within each column (Now / Next / Later), projects are shown in the color corresponding to their initiative.

Additionally, below the roadmap we display the product vision, since it is essential to keep it in mind when building the roadmap.

Timeline-based roadmap

These roadmaps use a time scale or timeframe, which can vary depending on the needs of your product or project: 3 months (short term), 6 months (mid term), 12 months (long term), or even per sprint if you work with Scrum.

Our advice is not to plan your roadmap more than six months ahead, because the idea behind a roadmap is agility. You should be able to adapt it based on feedback and new needs that arise.

Here is a visual example of a timeline-based roadmap 👇

In this example, we see a roadmap with four different initiatives that will be developed during Q2. Each initiative or theme has a different color indicating which project or epic it belongs to.

Just like in the previous type of roadmap, the vision is included to ensure it is always considered during roadmap development.

In this case, the months are also included, helping provide transparency and alignment with stakeholders and the team.

Key elements

As you’ve seen, regardless of the type of roadmap that best fits your product or project, its core elements are the same:

• Time scale, whether a timeline or a Now–Next–Later format.
• Themes or initiatives at a high level.
• Projects or epics for each initiative.

And don’t forget to reflect your product vision!

Next steps

Although we haven’t mentioned it earlier in this post, there are other important aspects when creating a roadmap:

• Prioritization. We cannot do everything, and certainly not all at once. That’s why we must make decisions and prioritize initiatives. There are different techniques and frameworks that can help with this, as we explained in this post 👉 Unlocking the potential of prioritization: the most important frameworks.
• Communication. The main value of building a roadmap is that it acts as a tool for alignment and transparency. It helps everyone understand the focus and why certain decisions are made.
• Connection with the business. Every initiative must be linked to a business objective; otherwise, we risk investing time in developments that generate no real value. To achieve this connection, it’s important to stop thinking about outputs and start focusing on outcomes — generating real impact by solving specific problems and needs.

There is still much more to say about this last point, which we’ll cover in future posts 😉.

Conclusion

A roadmap is a tactical tool that aligns product vision with strategy.

Also keep in mind that no roadmap is better than another. You simply need to adapt it to the specific needs of each project and continue iterating until you find the roadmap that best fits your product.

A roadmap is a compass. Build yours!

From Cognitive Load to Model Load

If you’ve been following what we’ve published at Paradigma, you already know our mantra and our Platform Engineering series: the discipline was born to free development teams from operational hell.

Do you remember that “sentence” of You Build It, You Run It? It created an unbearable cognitive load. Countless teams, instead of inventing the next feature that brings business value, spent their days fighting with Kubernetes, Prometheus, and a thousand other tools.

The truth is, Platform Engineering has been our great lever to bring order to that chaos and tell development teams: “Focus on the secret sauce, we’ll take care of the kitchen.”

The pattern is always the same when a technological shift or new trend emerges: we start experimenting, applying it to use cases, and then we feel the need to scale and bring it to production as quickly as possible.

But you know what? Just when we begin to breathe again, the next big wave arrives and it’s… even more complex.

In this case, I’m talking (as you might expect) about Artificial Intelligence and Machine Learning. This isn’t just about code and infrastructure; it’s about data, expiring models, versioning, explainability, and an MLOps lifecycle that is frankly a superset of what we already had in DevOps.

That’s why my bet is clear: 2026 will not simply continue the “AI everywhere” narrative, 2026 will be the year when the AI Platform becomes a strategic imperative for both business and technology inside companies, not an option.

The Platform Engineering legacy: friction reduction as the foundation for MLOps

Platform Engineering is our recipe for success: the use of Golden Paths to standardize, and the Internal Developer Platform (IDP) as a self-service entry point so no one has to open a ticket just to spin up an environment.

Now we add ML to the equation. And the problem is that a data scientist cannot be configuring CI/CD pipelines for a model or dealing with networking. They simply can’t (and even if they could, they shouldn’t).

MLOps needs the same Golden Paths we built for traditional software but extended to more delicate tasks. Imagine a Golden Path that guides you from the experimental notebook where you play with algorithms and models, all the way to production deployment with traceability, feature stores, and model monitoring… all in one go!

And here we see the first major specialization emerging. In the coming years, I believe we’ll see a surge in the Data Platform Engineer role. This role doesn’t just manage the IDP; it focuses on ensuring the reliability and governance of the data that feeds the model.

If the model is a black box, at least let’s make sure the data inputs feeding it are flawless! This is not a minor technical detail it’s a matter of corporate trust and compliance.

Fundamental distinction: Platforms with AI vs. Platforms for AI

At the CxO level, we must be precise with terminology. Because using AI to improve your platform is not the same as building a platform to do AI. The difference determines where you should place the bulk of your AI budget.

• Platforms with AI (AI-powered platforms). This is cool, trendy (and like all trends, it will eventually become BAU). It’s about using AI inside the platform to enhance developer experience. Think automated troubleshooting or predictive auto-scaling. Great, but it’s an add-on that improves DevEx.
• Platforms for AI (AI Platforms). This is the real focus. This means building infrastructure, tools, and Golden Paths specifically to support the entire MLOps lifecycle end-to-end. It’s the factory that allows you to move from three models in production to fifty. It’s the layer that generates new business value.

If your AI investment exceeds ten projects per year, you need the second one. There’s no alternative.

Why 2026 is the tipping point

Why 2026 (and 2027)? Because the market will force us. We’re at a tipping point driven by risk and ambition.

The Proof-of-Concept “Groundhog Day” (And the C-Level's Fear)

Many companies are stuck in an endless PoC loop: AI projects that work beautifully in a sandbox or controlled environment but take months to reach production or worse, reach production and fail due to lack of monitoring or security policy compliance.

Here’s where the rebel in me speaks up: the AI Platform is the only answer to scale and prove ROI. When the business demands speed, the platform must guarantee that a model goes into production in hours, not weeks.

And let’s not forget governance. As AI makes critical decisions, auditability and explainability become vital. You need a platform that forces you to document training datasets and monitor bias. You can’t rely on each team’s goodwill. The risk is simply too high.

As if this weren’t complex enough, the future of AI is not just static classification models. It’s AI agents: applications that maintain state, have memory, plan, and act and their architectures are, unsurprisingly, incredibly complex.

Who will orchestrate their state, persistence, and interactions? For me, the answer is clear: Kubernetes. But who will make Kubernetes consumable for AI teams? Exactly, the AI Platform. This is, without a doubt, the final catalyst that will make the platform a fundamental requirement.

Recap: putting everything on the table

We’ve reached the point where we can no longer apply patches or continue running experiments that bring no real business return. Extending the Platform Engineering mindset, the AI Platform will teach us how to master AI at scale. It’s a matter of competitive survival and risk management.

The AI Platform allows us to build the model factory with security, control, and the speed the market demands.

But of course, if this were easy, we would have done it already, right? In the next post, I want to get more concrete and explore the real, raw, everyday pain points faced by data scientists and MLOps teams and how the AI Platform finally becomes the necessity that business and technology will be compelled to drive forward.

I’ll read you in the comments! 👇

Exactly seven years ago, we wrote about the launch of ITIL 4, a well-intentioned and agile version that received a lukewarm welcome: the ITIL fan lovers were not convinced by the shift from “processes” to “practices,” and agilists were not thrilled either, given the extensive number of practices to master (34, no less).

With version 5, things get interesting. If you work in technology, this is not just an update: it’s a paradigm shift!

If this is your first time approaching ITIL, you can read what it’s about here. A subtle nuance is that it is no longer defined as a library of best practices, but directly as a framework.

ITIL 5 has been long awaited, and my impression is that they wanted to see how AI evolved before integrating it properly, rather than forcing AI into the framework just for the sake of trendiness.

Its progression scheme remains, with a Foundations level covering the fundamentals and specialized modules aligned across strategy, business, and technical roles.

The conceptual leap: from service to digital ecosystem

The concept of digital ecosystems in ITIL 5 marks the end of the corporate view of ITSM as a technological island.

While ITIL 4 focused on how an organization co-created value with its customers, ITIL 5 recognizes that today we operate within a hyperconnected network of partners, cloud providers, external AI platforms, and third-party APIs. We no longer manage “our” services in isolation; we now orchestrate an interdependent network where the success or failure of an external partner directly impacts our value proposition.

ITIL 5 provides the framework to govern this complexity, ensuring that value flows seamlessly across organizational boundaries. This evolution transforms IT’s role: from being an “internal provider” to becoming an “ecosystem orchestrator.”

In ITIL 5, optimization does not stop at your company’s walls — it extends to intelligent, dynamic integration with strategic partners. By adopting this mindset, organizations shift from managing fixed assets to managing dynamic capabilities, enabling unprecedented agility. Those who master this concept do not just deliver software or support — they guarantee the resilience and growth of the entire digital fabric in which their business operates. Version 5 introduces powerful and differentiating ideas:

1 From “Digital Native” to “AI Native”

While ITIL 4 laid the groundwork for agility and value, ITIL 5 integrates Artificial Intelligence into the framework’s DNA. It’s not just about using bots — it offers practical and ethical governance so that AI can make decisions and optimize value flows responsibly.

To achieve this, it logically leverages process mining. AI tools create a graph where process objects interact and move across events. A data-driven window opens, allowing real-time tracing of slowdowns, accelerations, or bottlenecks. More than interconnected lines (processes), it becomes a connective tissue.

2 Goodbye to the barrier between product and service

In ITIL 4, we talked about the Service Value System (SVS). ITIL 5 evolves this into the ITIL Value System (VS), unifying the lifecycle of products and services inseparably: they are no longer separate entities but are designed, delivered, and improved under a single continuous End-to-End flow. It consists of eight activities (Discover, Design, Acquire, Build, Transition, Operate, Deliver, Support).

With this, ITIL acknowledges that the traditional division between product and service must be overcome, since in practice they constantly merge, and those managing them must be prepared to understand and articulate both dimensions.

3 Practical certification (prove what you can do)

A radical shift for professionals: ITIL 5 prioritizes application over memorization. Advanced exams (not Foundations) are now “open book,” focusing on real cases and the ability to transform organizations through optimization and articulation of variables and factors.

In my view, this gives certification much greater value compared to analogous titles. Professionals will be assessed based on deep understanding, interconnection capability, and practical deployment of practices, not on memorizing the manual and applying it rigidly — which has caused so many project management frustrations.

4 Optimization as the mantra

If in version 4 the most repeated concept was “holistic,” in version 5 it is “optimization.” In my view, where this new version converges with 2026 framework trends is in how it redefines optimization as an activity:

From manual optimization to “hyper-optimization”

In ITIL 4, we applied the principle “optimize and automate.” In ITIL 5, we move toward AI-driven continuous optimization. The system no longer waits for a consultant to find a bottleneck — machine learning algorithms and process mining tools analyze value flows in real time and suggest immediate adjustments to eliminate waste.

Self-healing processes

The major competitive advantage of ITIL 5 is its focus on operational resilience. Optimization is not just about doing things “faster,” but about ensuring that processes adjust themselves during demand spikes or technical failures, guaranteeing uninterrupted value flow. A proactive and adaptive sustainability that seeks automated homeostasis.

Optimized unified data model

ITIL 5 introduces the premise (which will surely be debated) of a unified data model, signaling the end of “data silos.” This enables transversal optimization: if you optimize development processes, the impact is automatically reflected in operations and support.

What are the advantages of the “New ITIL”?

• Speed of adaptation: designed for high-velocity IT environments.
• Lean and Agile hybridized: combines the best of Lean within complex and adaptive contexts.
• AI governance: a solid framework to implement automation without losing ethical or legal control.
• Resilience and sustainability: aligned with Industry 5.0, placing humans and the planet at the center of technology.

Who can benefit from ITIL v5?

• Digital transformation leaders who need a common language to bridge IT and business.
• Product Owners / Product Managers who now find in ITIL the tools to manage the full lifecycle of digital products.
• ITSM professionals looking to scale their careers toward strategy and AI governance.

What about ITIL 4?

ITIL 4 and ITIL 5 will run in parallel for at least 12 months, and ITIL 4 certifications remain valid and recognized as prerequisites for advanced ITIL 5 modules. However, there is no “automatic upgrade.”

A bridge exam from ITIL 4 to ITIL 5 is available from late February 2026 for certified professionals.

Recertification credits: if you already hold ITIL 4 certifications, check your PeopleCert dashboard; some credits may be transferable to accelerate your path to ITIL 5 Master.

Conclusion

In my view, the ITIL committee continues to perform a commendable exercise in self-questioning, applying double-loop learning and inspect-and-adapt thinking. It has been necessary, because the more specific and less abstract a theoretical corpus becomes, the worse it ages.

Version 5 repositions ITIL within innovation, making knowledge practical only when ideas are truly usable. Novelty becomes progress.

The real competitiveness of project management areas and consultancies in 2026 will lie in mastering complex digital ecosystems. Is your IT team still managing tickets — or can it orchestrate value for your organization?

If you are ready to broaden your horizons toward Ecosystem Orchestration beyond certifications, we propose a roadmap designed for professionals seeking these integrated and systemic outcomes.

1 Lay the Foundation

Before automating with AI, your understanding of flow must be solid and efficient. Strengthen your foundations in process optimization. This phase should formalize everything you know and embed it within recognized international standards:

• Quality and Continuous Improvement (ISO + Lean)

The key here is Operational Efficiency as described in ISO 9001 (Quality Management Systems). Don’t see it as bureaucracy, but as a governance framework that allows optimization and quality experts to align foundations and standards for shared understanding. A plus: learn how to align OKRs with standard requirements using a Hoshin Kanri matrix.

• Lean Thinking

Focus on mastering the identification of the 8 wastes. Training your mindset in a disciplined way to automatically detect inefficiencies in any system and group them for prioritized action is a differentiating factor when designing and deploying frameworks as an Agile Coach.

• ISO 18404 (Lean & Six Sigma)

This standard defines competencies in Lean and Six Sigma, a testament to how significant Lean Six Sigma has been to earn its own ISO standard. Mastering it provides international recognition as an optimizer under global standards and enables you to measure dispersion and variance to scientifically identify causes and effects.

2 Secure

Flow resilience (ISO + Agile). Once a flow is efficient, it must also be secure and adaptable. Secure in terms of compliance and risk mitigation, adaptable in terms of understanding human relational dynamics and their need

• ISO/IEC 27001 (Information Security)

Essential today for any optimization activity. If you optimize a process but expose data, you have failed.

• ISO 22301 (Business Continuity)

An ideal complement in Agile environments. It teaches how to maintain value flow even during crises.

• Lean Change Management (LCM)

To manage the cultural transition often required by these standards in teams accustomed to “total freedom” due to lack of governance, train in the change management model proposed by LCM. While maintaining efficiency, it emphasizes a systemic vision of people, teams, tools, and processes, focusing on their interactions.

3 Orchestrate

Combining intelligences and perspectives. This is where an experienced Agile Coach can integrate Intelligent Process Modeling to connect them into a diagram that maps the territory. Flows must be connected and dynamic.

• Prompt Engineering for Process Analysts

It’s not just “chatting.” It’s about learning how to leverage AI and augmented intelligence tools to analyze Value Stream Maps (VSMs), SIPOCs, any diagrammatic representation, or Business Process Automations (BPAs) in seconds. You obtain a process map, an organizational infrastructure…

• RAG for Automated Inefficiency Detection

RAG (Retrieval-Augmented Generation) connects LLM applications with proprietary data sources. Instead of fragmented information in silos (PDFs, emails, tools, manuals), RAG unifies these assets into an accessible layer easily managed by analysts.

• Process Mining

Extracts data from event logs in systems like ERP or CRM to create a “digital twin” showing how the company truly operates at the system level, delegating supervised analysis to these platforms. Not what manuals say, but the real operational flow.

• ISO/IEC 42001 (Artificial Intelligence Management System)

The first international AI standard — today’s “Holy Grail” for management teams. It teaches how to implement AI ethically, securely, and efficiently. You need it as a new vector within your VSMs. Subscribe to EU updates to stay current.

• Transcontextuality with Warm Data

Often grouped under Systemic Symbiosis or Ecology of Mind, “Transcontextuality” studies how information gains meaning only when it crosses multiple contexts simultaneously (biological, cultural, economic, emotional, etc.). Familiarize yourself with these concepts — they can reveal inefficiencies invisible to tools and AI, enabling you to provide brilliant, holistic analyses to clients.

Why this order?

If you automate (AI) an inefficient process (Lean) that is not under control (ISO), you will only make mistakes at unprecedented speed. If you ignore the relationships within the ecosystem where processes operate, you will oversimplify in a dangerous and ineffective way.

This roadmap ensures that each layer of knowledge strengthens the previous one: ISO provides the structure, Lean clears the path, and AI accelerates the engine.

Do you have this need in your area or organization? At Paradigma Digital, we have professionals who integrate all dimensions of Flow and Process Orchestration to ensure the proposed model has consistent technical, operational, and relational foundations within your organizational ecosystem.

Interested in Process Optimization and already familiar with Lean? Contact us!

The word AI has become a catch-all term. It’s used to describe both deep learning models and simple rule-based systems with a couple of if statements. And amid all that noise, it’s becoming increasingly difficult to answer a simple but important question: what does it really mean to use AI in engineering systems?

In the world of infrastructure, CI/CD, and platform operations, AI usually has nothing to do with giant neural networks or “thinking” models. Here, it shows up in a much more humble — and, interestingly, much more useful — way: as a tool to detect anomalous behavior and make automated decisions.

This article is not about grand promises or dashboards full of futuristic charts. It’s about a very concrete problem: how to detect anomalies in pipelines that, at first glance, seem to work perfectly.

A practical case: detecting pipelines that get “stuck thinking”

The use case we built is quite down-to-earth: detecting pipelines that take too long to do things that should, in theory, be fast. No science fiction. No future-predicting models. Just identifying those moments when a pipeline lingers longer than usual… and we pretend it’s normal.

Instead of manually deciding what counts as “too long” using the classic number pulled out of thin air, we let the system observe how pipelines usually behave. If the normal execution time is a few seconds and, suddenly, one decides to take several minutes (to reflect on the meaning of life, perhaps), the system raises its hand.

Not because it crossed some magical threshold, but because it doesn’t fit the usual pattern.

The result is a pipeline that monitors itself. When it behaves as expected, it passes without issue. When it starts getting creative with waiting times, it automatically fails. No debates, no ignored dashboards, and no humans deciding whether “this time we’ll let it slide.”

In the end, it’s not about making pipelines smarter — it’s about making them a bit less naive. And above all, about letting the data decide when something stops being normal.

What tools did we use to achieve this?

To make this solution work, we need a set of tools that complete the loop of pipeline execution, anomaly detection, and model training for automation.

Argo Workflows: pipeline execution and control

Argo Workflows is the execution engine. This is where the real pipelines live: in this case, workflows that simulate jobs with variable durations and, once finished, execute an automatic validation step.

A key design point is the use of onExit, which allows:

• The workflow to execute its main logic.
• Once finished, an AIOps evaluation step to run.
• If that step fails, the entire workflow is marked as failed.

This ensures that anomaly detection becomes part of the pipeline lifecycle, not an external observer system.

One way to apply this is to build a workflow that simulates a pipeline. The pipeline configuration includes a one-second sleep, but we add a “variable” (for lack of a better explanation) so that, occasionally, the sleep lasts 300 seconds.

Prometheus: the source of truth for behavior

Prometheus acts as the historical data source. It doesn’t make decisions, but it collects key metrics such as workflow duration and exposes them consistently.

It allows us to:

• Build the model’s training dataset.
• Understand how the system behaves under normal conditions.
• Separate real signals from noise.

An important point is that Prometheus is not used as an ML engine, but as a time-series database.

Exporting metrics from Prometheus to learn

We built a custom exporter because we needed a simple and reliable metric representing the total duration of each workflow. Argo Workflows does not expose this directly, and for an AIOps system, duration is a key behavioral signal.

The exporter simply queries the workflow state, calculates its execution time, and exposes it as a Prometheus metric. It doesn’t make decisions or apply logic — it just converts internal platform state into reusable observability data.

This way, we keep responsibilities clearly separated: the exporter generates data, Prometheus stores it, and the AI layer decides how to interpret it.

from kubernetes import client, config
from prometheus_client import Gauge, start_http_server
from kubernetes.config.config_exception import ConfigException
from datetime import datetime
import time

print("Exporter starting...", flush=True)

try:
   config.load_incluster_config()
   print("Using in-cluster config", flush=True)
except ConfigException:
   config.load_kube_config()
   print("Using local kubeconfig", flush=True)

api = client.CustomObjectsApi()

DURATION = Gauge(
   "argo_pipeline_duration_seconds",
   "Workflow duration",
   ["workflow"]
)

def parse(ts):
   return datetime.fromisoformat(ts.replace("Z", "+00:00"))

start_http_server(8000)
print("Metrics server listening on :8000", flush=True)

while True:
   wfs = api.list_namespaced_custom_object(
       group="argoproj.io",
       version="v1alpha1",
       namespace="argo",
       plural="workflows"
   )

   count = 0
   for wf in wfs["items"]:
       status = wf.get("status", {})
       if status.get("phase") == "Succeeded":
           start = parse(status["startedAt"])
           end = parse(status["finishedAt"])
           duration = (end - start).total_seconds()
           DURATION.labels(
               workflow=wf["metadata"]["name"]
           ).set(duration)
           count += 1

   print(f"Updated {count} workflows", flush=True)
   time.sleep(30)

With the query argo_pipeline_duration_seconds{workflow=~"sleep-random-.*"} we can view the exported data in Prometheus.

The trainer: how we teach the system what “normal” looks like

We implemented a simple and explicit trainer whose sole purpose is to learn what “normal” workflow duration looks like based on real historical data.

The process is straightforward:

• We load a dataset with historical durations.
• We validate that there is enough data for training.
• We compute basic statistics to gain visibility into system behavior.
• We train an anomaly detection model (Isolation Forest).
• We store the trained model in a persistent volume.

Training runs as a Kubernetes Job/CronJob, allowing us to refresh the model periodically without impacting pipeline execution. There’s no complex logic or heavy dependencies: the value lies in learning the system’s real distribution, not in algorithmic sophistication.

This way, the definition of “normal” evolves over time and automatically adapts to environmental changes.

import pandas as pd
from sklearn.ensemble import IsolationForest
import joblib
import os
import time

def log(msg):
   print(f"[TRAINER] {msg}", flush=True)

DATASET_PATH = "/data/dataset.csv"
MODEL_PATH = "/models/sleep-random.pkl"
MIN_SAMPLES = 20

log("Starting model training")

if not os.path.exists(DATASET_PATH):
   log("Dataset not found, aborting training")
   exit(1)

df = pd.read_csv(DATASET_PATH)

log(f"Loaded dataset with {len(df)} samples")

if len(df) < MIN_SAMPLES:
   log(f"Not enough samples (<{MIN_SAMPLES}), skipping training")
   exit(0)

min_d = df["duration"].min()
max_d = df["duration"].max()
mean_d = df["duration"].mean()

log(f"Duration stats → min={min_d:.2f}s max={max_d:.2f}s mean={mean_d:.2f}s")

X = df[["duration"]]

log("Training IsolationForest model")

model = IsolationForest(
   contamination=0.02,
   random_state=42
)

start = time.time()
model.fit(X)
elapsed = time.time() - start

log(f"Model trained in {elapsed:.2f}s")

# 4️⃣ model saved
joblib.dump(model, MODEL_PATH)
log(f"Model saved to {MODEL_PATH}")

ts = int(time.time())
versioned_path = f"/models/sleep-random-{ts}.pkl"
joblib.dump(model, versioned_path)
log(f"Versioned model saved to {versioned_path}")

log("Training job completed successfully")

The test workflow: putting the system to work

To validate the entire architecture, we created a simple but intentionally variable Argo Workflows workflow. Its purpose is not to perform real work, but to generate executions with different behaviors so we can verify that the AIOps system works as expected.

The workflow runs a single step that sleeps for a random amount of time:

• Most of the time it simulates a fast execution.
• Occasionally, it forces an abnormally slow execution.

This way, we introduce controlled noise and create a clear signal that the system can learn from.

The key part lies in the onExit section. When the workflow finishes, an additional step is executed that:

• Loads the trained machine learning model.
• Evaluates the total workflow duration.
• Decides whether the execution is normal or anomalous.

If the model detects an anomaly, the workflow automatically fails. Otherwise, it is considered valid.

This turns anomaly detection into part of the pipeline itself, rather than an external, after-the-fact analysis.

This workflow acts as a test bench to run the system multiple times, observe how the model evolves, and verify that automatic detection works consistently under real conditions.

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
 generateName: sleep-random-
 namespace: argo
spec:
 serviceAccountName: mmartin
 entrypoint: main
 onExit: aiops-check

 templates:
   - name: main
     steps:
       - - name: random-sleep
           template: sleep

   - name: sleep
     container:
       image: alpine:3.19
       command: [sh, -c]
       args:
         - |
           R=$((RANDOM % 5))
           if [ "$R" -eq 0 ]; then
             SLEEP_TIME=300
             echo "🔥 ANOMALOUS RUN: sleeping ${SLEEP_TIME}s"
           else
             SLEEP_TIME=1
             echo "Normal run: sleeping ${SLEEP_TIME}s"
           fi

           sleep ${SLEEP_TIME}

   - name: aiops-check
     container:
       image: quitos90/argo-aiops-ml-check:0.1
       imagePullPolicy: Always
       command: ["python", "-u", "/app/aiops-check-ml.py"]
       env:
         - name: STEP_DURATION
           value: "{{workflow.duration}}"
       volumeMounts:
         - name: models
           mountPath: /models

 volumes:
   - name: models
     persistentVolumeClaim:
       claimName: aiops-models

We ran the job a few times and…

Voilà! We can see the results in Argo Workflows.

If we look at the two executions that failed, they are the ones that lasted more than 5 minutes and, upon closer inspection, we can see that they are the ones we deliberately forced to behave as anomalies.

With this, even though the pipeline appears to have finished successfully at first glance (since its main task did not fail), we can clearly see that something unusual is happening. In this case, it takes 5 minutes when most pipelines complete in approximately 40 seconds.

Why not simply use a timeout?

The most common way to control slow pipelines is to add a fixed timeout. It’s simple, easy to understand, and works… until it doesn’t. The AIOps-based approach we followed addresses limitations that timeouts simply cannot solve.

A timeout is static

A timeout defines a rigid limit: if the pipeline takes longer, it fails. This forces you to choose an arbitrary value that is almost never perfect:

• Too low → false positives.
• Too high → real issues go unnoticed.

Our approach, instead, learns what normal system behavior looks like and adapts over time.

Conclusions

After walking through the entire process, the main conclusion is clear: the difficulty of applying AIOps lies not in the model itself, but in training it properly. The algorithm we used is simple, but its behavior depends entirely on the quality and representativeness of the data it learns from.

For this type of system to work, it is essential to have good observability and sufficient historical data. Without reliable metrics and temporal context, any attempt at “intelligence” quickly degrades into arbitrary rules or constant false positives. AI does not fix a lack of visibility; it simply amplifies what already exists.

This exercise leaves us with an important lesson: before thinking about more complex models or more sophisticated architectures, it is crucial to invest in understanding the real behavior of the system. In AIOps, intelligence begins long before training and is often much closer to observability than to machine learning.

It has always been about something deeper: how an organization behaves, how it makes decisions, and how it learns.

Five years ago, we identified the main challenges holding modern organizations back. Today, with the massive arrival of Artificial Intelligence, those challenges have not disappeared: they have become more visible… and more costly.

AI does not replace organizational transformation. It is an accelerator. And like any accelerator, it does not only boost what works: it also amplifies what is broken.
To understand this, we need to revisit the core challenges that are still present.

1 Communication: the root of almost every problem

In many organizations, formal communication does not flow to decision-makers. Information arrives late, biased, or incomplete. This leads to endless meetings, poorly informed decisions, and documents that nobody reads.

Informal communication, which should act as a lubricant, turns into rumor when trust and psychological safety are missing.

What happens when AI arrives?

• You have more information than ever.
• But not more clarity.
• Nor more alignment.

AI does not fix poor communication; it makes it more evident. You can have spectacular dashboards, but if people do not speak honestly, the quality of decisions does not improve.

2 Alignment: if every area optimizes its own goals, the organization loses

Misalignment is not a lack of good intentions; it is a lack of a shared framework. Objectives defined in closed committees, departments competing with each other, priorities changing without warning… This generates duplication, conflict, fatigue, and loss of focus.

What happens when you introduce AI in this context?

• AI optimizes locally.
• But the organization needs global optimization.
• And without alignment, AI generates more noise, not more impact.

AI can provide valuable insights, but it cannot decide why one objective is more important than another, nor resolve tensions between departments. That is still leadership.

3 Lack of focus: doing everything is the fastest way to achieve nothing

A lack of focus is a clear symptom of an organization without real priorities. More projects are started than can be sustained. People attend ten meetings and make zero decisions. Initiatives drag on because nobody knows what should stop or what should continue.

What happens when we add AI?

• AI generates more possibilities.
• But more options without focus = more dispersion.

AI does not provide focus. The organization must define it, sustain it, and protect it.

4 Adaptation to change: structures designed for stability, not learning

Organizations have innovated in technology… but they continue operating with structures designed for a different time and context. Strong structures, yes, but rigid ones. Structures that slow down today’s market speed.

What about AI?

AI requires fast cycles, experimentation, and distributed decision-making. If your structure does not allow this, AI will simply collide with existing bureaucracy. AI does not make a slow organization agile. It makes its slowness more visible.

5 Talent: attracting is difficult, wasting is easy

New generations seek purpose, autonomy, growth, and balance. Rigid structures, lack of clarity, and limited internal mobility generate frustration and talent loss.

What happens when AI arrives?

Talent wants to leverage technology to learn, create, and deliver more value. But if the organization does not enable it, AI becomes a threat rather than an opportunity. Wasting talent is, more than ever, losing competitive advantage.

6 Customer proximity: more data does not mean more understanding

Paradoxically, the more many organizations grow, the further they move away from real customers. No direct contact, no feedback, no deep understanding.

And here AI can be misleading

• You may have thousands of data points about your users.
• But if you do not understand their context, emotions, or intent… you will not make the right decisions.

AI does not replace empathy. It complements it.

The real problem is not AI

The problem is not being clear about why we want to transform.

AI can:

• Automate
• Accelerate
• Recommend
• Optimize

But it cannot, on its own:

• Generate clarity / build trust
• Align teams
• Resolve tensions
• Set priorities
• Define purpose
• Rebuild culture

…unless we are all AI agents (Skynet muhahaha).

Organizational transformation remains a human process. AI is a powerful tool that only creates real impact when the organizational system is ready to adopt it.

That is why, before asking “How do we implement AI?”, the critical question is:
“Why do we want to transform as an organization?”
“What behaviors, beliefs, and dynamics must change for AI to create impact?”

If we do not address cultural, structural, and leadership challenges, AI will not be the transformation lever we expect. It will be a mirror that amplifies our inefficiencies.

Conclusion

AI is the multiplier.
Culture is the enabler.
Transformation is the purpose.

The organizations that will survive in the coming years will not be those that adopt AI the fastest. They will be those that have:

• A culture that enables learning,
• A structure that enables decision-making,
• The clarity that enables prioritization,
• A leadership that enables trust,
• And a purpose that guides every decision.

AI needs all of that to create real impact.

Is your organization preparing the ground for AI… or trying to implement it on structures that cannot sustain it? I’d love to read your thoughts 👇

If you’re considering implementing microfrontends in your project, or if you already have them and feel identified with the chaos I’m about to describe, this post is for you.

The Promised Dream

Let’s start with the beautiful part. Microfrontends arrive with a brilliant promise:

• Full autonomy for each team
• Independent deployments without stepping on others’ code
• Organizational and technical scalability
• Different technologies coexisting in harmony
• Clear ownership by business domains

It sounds perfect, right? And in theory, it is. Each team builds its own slice of the frontend, deploys whenever it wants, uses the framework it prefers, and everything works like a Swiss watch.

Until it doesn’t.

When Reality Hits

The truth is that the real complexity of microfrontends isn’t in the code, but in everything else: teams, blurry boundaries, maintenance, coordination.

Let me tell you what no one mentions when they sell this architecture as the silver bullet.

1 The Complexity You Didn’t Expect

"We went from having one big monolith that was hard to maintain to having 10 small monoliths that are hard to coordinate."

Suddenly you have:

• A multiplication of CI/CD pipelines (one per microfrontend).
• Versioning nightmares with shared libraries.
• Communication strategies between microfrontends that no one properly documented.
• Dependency synchronization issues breaking things everywhere.

What used to be a problem in one place is now ten distributed problems. And distributing problems doesn’t make them disappear, it makes them harder to find.

2 The User Experience Becomes Fragmented

"Each microfrontend is independent… until the user notices they all have different spinners."

Every team has its own priorities, pace, and way of doing things. The result:

• Visual inconsistencies everywhere.
• Uneven performance (one loads in 200ms, another in 3 seconds).
• Interactions that don’t feel cohesive.
• Global changes (like a rebranding or accessibility improvements) turning into near-impossible missions.

In the end, users don’t know or care that you’re using microfrontends. They just know your app feels weird.

3 Integration and Security: The Constant Headache

Sharing authentication between microfrontends is more complex than it seems:

• Token handling across domains or contexts.
• Cookies that work in development but break in production.
• Sandboxing issues when using iframes (and all the problems that come with them).
• Permissions and roles that must stay synchronized.

And all of this while trying to keep things secure. Guaranteed fun.

4 The Invisible Cost

Microfrontends aren’t free. They carry a cost that isn’t always visible at the beginning:

• Onboarding time multiplies (now you need to understand N architectures).
• Duplicated dependencies that bloat your bundles.
• Longer build times because everything is built separately.
• More complex infrastructure to maintain and monitor.

Oh, and your cloud bill? It grows too.

5 The Human Factor (The Most Important One)

"Microfrontends don’t fix misaligned teams, they just make the problems more visible."

This was the hardest lesson for me: architecture does not solve organizational problems.

If your teams don’t communicate, if there are no clear agreements, if ownership boundaries are blurry… microfrontends will only amplify those issues:

• Conflicts over who owns what.
• Duplicated work because teams don’t know what others have already built.
• Technical inconsistency that turns into distributed technical debt.

In the end, you’re left with frustrated development teams arguing with each other.

So, What Do We Do?

I won’t leave you with a bitter aftertaste. Microfrontends can work, and despite how it may sound, I don’t hate them at all. But you need to carefully evaluate whether you truly need them and be willing to invest in doing them right.

Here are some lessons I’ve learned:

1. Evaluate whether you really need them

If your team is small or medium-sized, you probably don’t. A well-structured monolith can take you very far.

2. Establish clear contracts

APIs, events, interfaces… everything clearly defined and documented. Without this, you’re heading straight into chaos. A well-organized Architecture team is your best ally.

3. Communication

Having people who act as bridges between different development teams (business domains) is essential for things to flow smoothly.

4. Unify the experience

Invest in a solid design system and shared base components. Consistency is non-negotiable.

5. Automate everything you can

Your pipelines, deployments, versioning, tests. Complexity is only manageable if it’s automated.

6. Organization first, technology second

Microfrontends should reflect how your organization works, not the other way around. Remember Conway’s Law: your architecture will inevitably mirror your organizational structure.

In Conclusion

As architects, we shouldn’t focus only on the technical impact on the final product (scalability, resilience, etc.), but also on the Developer Experience. Our goal should be to provide the right tools and the necessary support so development teams can work efficiently and effectively.

Microfrontends are not the villain, but they’re not the hero that will save your project either. They’re just a tool. And like any powerful tool, you need to know when to use it… and when to leave it in the box.

The real question isn’t “Are microfrontends good or bad?” but rather:
“Do they solve the concrete problems we have right now and are we willing to pay their cost?”

If the answer is yes then great, use them. If not, that’s fine too: sometimes the best architecture is the simplest one that works.