DEV Community: Romina Elena Mendez Escobar

Automated API Load Testing on AWS: Grafana k6 and AI-Powered Reporting with Amazon Bedrock

Romina Elena Mendez Escobar — Mon, 26 Oct 2026 09:36:06 +0000

1. Introduction

When developing an application or service, one of the common questions we face is how many concurrent requests it can handle and how the services it depends on will respond. Even if we verify that all functionalities work correctly, this does not guarantee that the system will maintain its performance as demand increases.

This is why software testing goes beyond verifying functional requirements. It also allows us to evaluate aspects such as performance, stability, and responsiveness. In particular, load testing is not simply about pushing a system until it fails, but rather about understanding how it behaves under different conditions and identifying when it stops meeting the expected requirements.

In the previous article, we built a service to identify duplicate products using Amazon Bedrock, S3 Vectors, and DynamoDB, including an AWS Lambda function to perform real-time searches. During our initial tests, the service responded within a few seconds, but one question remained unanswered: how would it behave if many users accessed it simultaneously?

To answer this question, in this second part, we will expose the service through Amazon API Gateway and evaluate its behavior under load. Before running the tests, however, we need to define what we want to measure and which criteria we will use to evaluate the results. To do this, we will introduce some fundamental concepts of Site Reliability Engineering (SRE). We will then automate load testing with Grafana k6 on AWS and, finally, generate a report in which generative AI will help us interpret the collected metrics.

2. Understanding Site Reliability Engineering (SRE)

2.1. What Is SRE?

Before evaluating how our API behaves under load, we need to establish what acceptable performance and reliability actually mean. A service may continue responding to requests, but that does not necessarily mean it is meeting the expected performance requirements.

This is where Site Reliability Engineering (SRE) comes into play. Originally developed at Google, SRE is a discipline that applies software engineering principles to operating and maintaining reliable systems. It focuses on defining measurable objectives, selecting indicators that reflect service behavior, and using automation to reduce repetitive operational tasks.
For our use case, these concepts provide a foundation for moving beyond simply checking whether the API responds. Instead, we can evaluate specific indicators such as response times, error rates, and performance under different load conditions.

2.2. Seven Principles of SRE

SRE is built on a set of principles that guide how reliable services are designed, operated, and maintained. These range from defining reliability objectives and managing risk to automation, monitoring, and keeping systems as simple as possible.
The following infographic summarizes seven of these principles, based on Google's Site Reliability Engineering book.

Illustration by the author. Based on Google's Site Reliability Engineering book.

2.3. Capacity Planning and Performance

Service reliability depends not only on availability but also on the ability to handle demand while maintaining acceptable performance. In this context, SRE includes several practices aimed at anticipating problems, optimizing resources, and reducing the impact of changes in production.

Among these practices, we can highlight:

Capacity Planning: ensuring that a system has sufficient resources and redundancy to handle expected demand without compromising availability objectives. To support this, Google recommends regular load testing to assess the actual capacity of a service.
Efficiency and Performance: understanding how performance changes as load increases, identifying potential degradation, and finding opportunities to optimize resource utilization.
Change Management: reducing the risks associated with changes in production. According to Google's documented experience, approximately 70% of service outages are caused by changes to live systems, highlighting the importance of detecting problems early. These practices are directly related to our use case, as we aim to evaluate our API's performance under different load conditions.

2.4. SLI, SLO, and SLA

Evaluating a service's capacity and performance requires more than simply running tests and collecting metrics. We also need to define what we want to measure and which service levels we consider acceptable.

In this context, SRE introduces three related concepts: SLI (Service Level Indicator), SLO (Service Level Objective), and SLA (Service Level Agreement). Together, they connect technical measurements with service objectives and commitments.

The following infographic summarizes what each concept represents, the question it helps answer, and a practical example of how it can be applied.

Illustration by the author. Based on Google's SRE framework.

3. Grafana k6: A Tool for Performance Testing

Grafana k6 is an open-source tool developed in Go and maintained by Grafana Labs, designed to perform load and performance testing on applications, APIs, and microservices. Test scenarios are defined using JavaScript, making it easier to automate tests and integrate them into development workflows.

Although we often associate these tools with stress testing, k6 allows us to evaluate how a system behaves under different load conditions, without necessarily pushing it to the point of failure.

Illustration by the author. Based on Grafana k6 documentation.

3.1. Types of Load Tests

Depending on what we want to evaluate, we can define different test scenarios:

Smoke: verify that the system responds correctly under minimal load.
Average-load: evaluate system behavior under normal operating conditions.
Stress: assess how the system responds under high load.
Soak: identify potential performance degradation when load is sustained over extended periods.
Spike: evaluate how the system responds to sudden increases in traffic.
Breakpoint: progressively increase the load to identify the point at which the system stops meeting the expected criteria. These scenarios allow us to analyze different aspects of system performance. We should also consider that an application often depends on multiple components and services, meaning that performance degradation can originate from different parts of its architecture.

3.2. Main Components of k6

To execute these tests, k6 provides several components that allow us to configure load, validate responses, collect metrics, and integrate results with other tools.

Illustration by the author. Based on Grafana k6 documentation.

We can group them into four main components:

⚙️ Options: define how a test will be executed. They allow us to configure scenarios, load stages, virtual users (VUs), duration, iterations, and acceptance thresholds. These options enable us to reproduce the different types of tests described earlier.
✅ Checks: validate conditions on received responses, such as HTTP status codes or response content. A failed check is recorded in the metrics but does not automatically stop the test execution.
📊 Metrics: collect information about system behavior, including response times, request counts, and error rates. k6 provides built-in metrics and supports custom metrics.
🔗 Integrations: allow tests to be incorporated into CI/CD pipelines and results to be exported to storage, monitoring, and visualization tools. In our case, we will use CSV and JSON to store the results and subsequently process the metrics included in the final report.

4. Architecture

Our load testing solution builds on the game-catalog-resolve-product Lambda function developed in the previous article, which uses Amazon Bedrock, S3 Vectors, and DynamoDB to identify duplicate products.

In this second part, we expose the function through Amazon API Gateway (HTTP API) with IAM authorization, requiring k6 requests to be signed using AWS credentials.

The testing process is automated using AWS Step Functions, which orchestrates k6 execution on Amazon ECS Fargate and subsequent report generation through an AWS Lambda function. Test scripts and results are stored in Amazon S3, while Amazon ECR stores the container images.

The entire infrastructure is defined using Terraform, and the code is available on GitHub, making the solution reproducible.

Architecture diagram by the author.

5. Use Case: Automated Load Testing

In this use case, we will run different load testing scenarios against our API. To do this, we use Grafana k6 running inside a Docker container to send requests and collect performance metrics. Once the tests are complete, a Python-based process calculates the results and generates a PDF report that includes an interpretation provided by Amazon Bedrock.

Illustration by the author.

5.1. The Repository

The project is available on GitHub: game-catalog-k6.

RominaElenaMendezEscobar / game-catalog-k6

Load testing a GenAI API on AWS with k6: scenarios defined in JSON (smoke, load, stress, spike) run on ECS Fargate and orchestrated by Step Functions. Metrics from k6 and CloudWatch are collected by Lambda, and Amazon Bedrock generates an analysis of the results. Tests an API Gateway endpoint backed by Lambda, Amazon Bedrock and S3 Vectors.

⚡ Automated API Load Testing on AWS: Grafana k6 and AI-Powered Reporting with Amazon Bedrock

Serverless pipeline that runs Grafana k6 load tests against an API on Amazon ECS Fargate orchestrated by AWS Step Functions, and generates a PDF report where Amazon Bedrock interprets the metrics. All the infrastructure is defined with Terraform.

📝 Article: 🔗 Part 1 (the API under test): Identical or Similar? AI-Powered Product Matching with Amazon Bedrock and S3 Vectors · repository

🎯 What it does

Runs a load test with k6 in a container on ECS Fargate, using a configurable scenario (smoke, load, stress, spike).
Stores every run in its own S3 folder, with the results and an exact copy of the scenario used.
Generates a PDF report: metrics are computed by code; Amazon Bedrock only interprets them, and the figures it quotes are validated against the computed metrics.

The thresholds…

View on GitHub

Its structure includes the k6 scripts, test scenarios, report generator, and infrastructure defined using Terraform.

game-catalog-k6/
├── Dockerfile, entrypoint.sh
├── search.js, sigv4.js
├── scenarios/
├── queries.json
├── report/
│   └── config/
├── terraform/
└── build-and-push.sh

The goal is to make this solution reusable for testing other APIs without modifying the underlying infrastructure or the report generation process. To do this, we only need to configure three elements:

〰️ The API we want to test
〰️ The requests we want to send
〰️ The load testing scenarios

5.2. Configuring Tests for Another API

1. Identify the API: `api_id`

In our case, we use Amazon API Gateway (HTTP API) with IAM authorization. The service URL follows this structure:

https://<api-id>.execute-api.us-east-1.amazonaws.com

The API identifier can be found in the AWS Management Console under API Gateway → Your API → API details.
To configure the project, we specify it in terraform/terraform.tfvars:

api_id = "<api-id>"

Terraform uses this identifier to construct the API URL and configure the necessary permissions for the k6 container to invoke the API using IAM-signed requests.

2. Define the Requests: queries.json

Once we have identified the API, we need to define which requests we want to send.
Our API accepts text searches through POST /search. To define the requests executed during testing, we use the queries.json file, which contains different video game searches in English and Spanish.

[
  {"query": "fifa 14 ps3 digital code", "lang": "en"},
  {"query": "fifa 14 ps3 codigo digital", "lang": "es"},
  {"query": "gta vice city ps2", "lang": "en"},
  {"query": "el mario kart de la wii", "lang": "es"}
]

If the API expects a different request structure, we will also need to adapt the request body in search.js.

3. Configure the Load: `scenarios`

Once we have defined what to request, we need to establish how the load will be applied. For this, we use JSON files in the scenarios/ directory, each with its own configuration.

Each JSON file defines a different load testing scenario:

smoke.json — Smoke Test: 1 virtual user for 1 minute to verify basic functionality.
load.json — Load Test: 5 virtual users for 5 minutes to evaluate system behavior under steady load.
stress.json — Stress Test: gradually increases the load from 5 to 40 virtual users over 6 minutes to identify performance degradation.
spike.json — Spike Test: increases the load from 0 to 50 virtual users in 30 seconds to evaluate how the system responds to sudden traffic spikes. Each scenario can be customized by adjusting the number of virtual users, test duration, load pattern, and performance thresholds.

Each file allows us to configure virtual users, test duration, load patterns, and performance thresholds.
For example, smoke.json contains:

{
  "name": "smoke",
  "description": "1 user for 1 minute: checks that the API works before adding load.",
  "queries_file": "queries.json",
  "endpoint": "/search",
  "think_time_seconds": 1,
  "executor": {
    "executor": "constant-vus",
    "vus": 1,
    "duration": "1m"
  },
  "thresholds": {
    "http_req_failed": ["rate<0.01"],
    "http_req_duration": ["p(95)<5000"]
  }
}

The main parameters are:

endpoint: the API path to which requests will be sent.
think_time_seconds: the pause between requests made by each virtual user.
executor: defines the load pattern, number of virtual users, and test duration.
thresholds: allows us to define acceptance criteria for the metrics. In this example, an error rate below 1% and a p95 response time below 5 seconds. These thresholds allow us to translate our performance objectives into measurable acceptance criteria during testing, following the SLI and SLO concepts introduced earlier. We can modify existing scenarios or create new JSON files to evaluate different load conditions while reusing the same k6 code.

5.3. Deploying the Infrastructure with Terraform

Once the configuration files are ready, we can deploy the solution using AWS CloudShell, with the tools needed to run Terraform and build Docker images.

1. Install Terraform (First Time Only)

AWS CloudShell does not include Terraform by default. We can download it to our home directory, which persists across sessions:

curl -sLo /tmp/terraform.zip https://releases.hashicorp.com/terraform/1.9.8/terraform_1.9.8_linux_amd64.zip
mkdir -p ~/bin && unzip -o /tmp/terraform.zip -d ~/bin
echo 'export PATH="HOME/bin:$PATH"' >> ~/.bashrc && source ~/.bashrc
terraform version

2. Create the Infrastructure

git clone https://github.com/RominaElenaMendezEscobar/game-catalog-k6.git
cd game-catalog-k6/terraform
echo 'api_id = "<api-id>"' > terraform.tfvars
terraform init
terraform apply \
  -target=aws_ecr_repository.k6 \
  -target=aws_ecr_repository.report
../build-and-push.sh

terraform apply

The deployment is performed in three stages: first, we create the Amazon ECR repositories; next, we build and push the container images; and finally, we deploy the remaining resources.

Terraform provisions the required infrastructure, including Amazon ECS Fargate, AWS Step Functions, AWS Lambda, Amazon S3, and IAM roles and permissions. It also uploads the test scenarios and queries that k6 will use to Amazon S3.

5.4. Running a Load Test

With the infrastructure deployed, we can start a test execution using AWS Step Functions, specifying the scenario we want to run.
For example, to execute load.json:

aws stepfunctions start-execution \
  --state-machine-arn "$(terraform output -raw state_machine_arn)" \
  --input '{"scenario": "load", "label": "baseline"}'

Screenshot by the author. AWS Management Console.

The state machine orchestrates three steps:

PrepareRun: takes the scenario and label provided in the input and generates a unique identifier based on the date and time (run_id). This identifier is used in the following two steps to ensure that the results and report are associated with the same test execution.
RunLoadTest: starts the k6 container on Amazon ECS Fargate, executes the selected scenario, and stores the results in Amazon S3.
GenerateReport: processes the results using an AWS Lambda function, calculates the metrics, and generates a PDF report with an interpretation provided by Amazon Bedrock. Each execution is stored in a separate folder, following a structure such as runs/<scenario>/<date>/, along with the configuration used for the test.

Screenshot by the author. Amazon S3 bucket showing the files and results generated by the automated load testing pipeline.

Generated by k6 (RunLoadTest):

k6-summary.json: a summary of the test, including aggregated metric values (averages, percentiles, error rates) and threshold evaluation results.
k6-results.csv: detailed data for each request, including when it was sent, how long it took, and whether it failed. This data is used to generate time-series charts.
run-info.json: execution metadata, including the scenario, label, timestamps, k6 version, and container image.
scripts/: an exact copy of the scripts and scenarios used, allowing us to reproduce the test configuration even if the original files are modified later. #### Generated by the Report Lambda (GenerateReport):
metrics.json: metrics calculated by the code using the files generated during the test.
ai-analysis.json: the interpretation generated by Amazon Bedrock, along with the results of the numerical validation.
report.pdf: the final report, combining all the information above. To run a different test scenario, we only need to change the scenario value in the Step Functions execution input.

5.5. Report Generation

Once the test is complete, the pipeline processes the k6 results and generates a PDF report that combines the calculated metrics with an interpretation provided by Amazon Bedrock.
For this stage, we use an AWS Lambda function deployed as a container image, as we need several Python libraries: pandas for data processing, matplotlib for generating charts, and fpdf2 for creating the PDF document.

Unlike traditional ZIP-based deployments, which have a 250 MB uncompressed size limit, AWS Lambda supports container images of up to 10 GB. This makes it easier to package the code and its dependencies into a reproducible environment while maintaining a serverless execution model.

The following infographic summarizes the main benefits of this approach.

Illustration by the author. Based on AWS Lambda documentation.

The container image is built using a Dockerfile and pushed to Amazon ECR. Terraform then configures the AWS Lambda function to use this image, as illustrated in the following workflow.

Illustration by the author. Based on AWS documentation.

We can view an example of the generated PDF report at the following link:
github.com report.pdf

Report generated by the author using Python, Grafana k6, and Amazon Bedrock.

The report consists of several pages organized into the following sections:

Test Context: the executed scenario (load, duration, and thresholds) and the test environment (k6 version, container image, and location of the results).
Results and Metrics: requests, throughput, error rates, p50, p95, and p99 latencies, threshold compliance, and a breakdown of each phase of a request.
Performance Charts: response times over time, latency distribution, percentiles, request time breakdown, throughput, errors, and virtual users.
AI-Powered Analysis: an interpretation of the metrics generated by Amazon Bedrock, along with validation of the numerical values referenced in the analysis.
Metrics Glossary: definitions of each metric, how it is calculated, an example, and why it matters.

It is important to emphasize that all metrics are calculated using Python code based on the k6 results. Amazon Bedrock is used only to interpret these values and generate the narrative analysis, with an additional validation step to verify the numerical values mentioned in the generated text.

6. Conclusions

In this article, we started with a question: how does an API behave as concurrency increases? To answer it, we implemented an automated load testing pipeline that allows us to evaluate API performance under different load scenarios and analyze the results.

This exercise allowed us to put some Site Reliability Engineering (SRE) concepts into practice: defining which aspects of the service we want to measure (SLIs), establishing what service levels we consider acceptable (SLOs), and using Grafana k6 to translate those objectives into measurable thresholds during testing.

Beyond running load tests, we also need to interpret a considerable amount of performance data. To address this, we incorporated generative AI to facilitate the analysis and generate a report that summarizes the key findings without requiring an in-depth understanding of every metric. It is important to emphasize that the metrics are calculated by code, while AI is used only to interpret them, maintaining a clear separation between the collected data and the generated conclusions.

Another important aspect is the solution's reusability. By modifying the API, queries, and load testing scenarios, we can use the same pipeline to evaluate other services. In addition, preserving the configuration and results of each execution provides traceability and facilitates future comparisons.

However, this MVP has some limitations and opportunities for improvement:

Geographic Coverage: tests are executed from a single AWS Region, so they do not necessarily reflect the experience of geographically distributed users.
Test Duration: short test scenarios may produce limited sample sizes, which can affect the stability of percentiles such as p95 and p99.
AI Interpretation: the analysis depends on the model and prompt used. It would be interesting to evaluate different models and refine the instructions based on the type of insights we want to obtain.
CI/CD Integration and Observability: the pipeline is not yet integrated into a CI/CD process. As a future improvement, we could automate testing across application versions, compare results to detect performance regressions, and incorporate Amazon CloudWatch metrics for AWS Lambda and Amazon Bedrock.

Ultimately, the goal is not simply to determine how many requests an API can handle, but to establish a reproducible process that allows us to measure its behavior, identify potential performance degradation, and evaluate how its performance evolves as we introduce changes.

References

Beyer, B. et al. (2016). Site Reliability Engineering, capítulo 4: Service Level Objectives. https://sre.google/sre-book/service-level-objectives/
Grafana Labs. (s. f.). Grafana k6. https://grafana.com/oss/k6/
Grafana Labs. (s. f.). Load test types. Documentación de Grafana k6. https://grafana.com/docs/k6/latest/testing-guides/test-types/
Amazon Web Services. (s. f.). Lambda quotas. Documentación de AWS Lambda. https://docs.aws.amazon.com/lambda/latest/dg/gettingstarted-limits.html
Méndez Escobar, R. E. (2026). Identical or Similar? AI-Powered Product Matching with Amazon Bedrock and S3 Vectors. DEV Community. https://dev.to/aws-builders/identical-or-similar-ai-powered-product-matching-with-amazon-bedrock-and-s3-vectors-3pm

Identical or Similar? AI-Powered Product Matching with Amazon Bedrock and S3 Vectors

Romina Elena Mendez Escobar — Wed, 21 Oct 2026 11:49:00 +0000

1. Introduction

A few weeks ago, someone asked me a question:

"How can I use AI to improve my inventory if I have similar or duplicate products, but their names aren't written exactly the same way?"

To explore how to solve this problem, we'll use video games as an example.

⚠️ First spoiler: that's the type of data we'll be working with in this article.

Call of Duty: Black Ops and Call of Duty: Black Ops 2 have almost identical titles, but they are different games. They are not duplicates.
Black Ops 2 and Black Ops II are exactly the same game, even though a computer sees them as two different text strings.
FIFA 14 for PlayStation 3 and FIFA 14 for Xbox 360 have the same title, but the platform is different, so they may represent distinct commercial products.

So, what does it really mean for two products to be duplicates?

Two records may describe the same product even if their names are different.
Nearly identical names may refer to different products.
The same product may be sold in different presentations or formats, which we may need to keep separate depending on the business rules.

Each use case may require different business rules. Some differences may seem obvious to a person, but when we're dealing with thousands of records, we can't rely on someone detecting them manually.

⚠️ Second spoiler: AI isn't going to solve everything.

We could send all the information about each product to an AI model and ask it to determine whether it's a duplicate. But processing an entire catalog this way can be expensive, and we can't guarantee that the responses will always be consistent.

In other projects, I have worked with text normalization, regular expressions, and similarity techniques. These remain useful tools, and in many cases, they are sufficient. For this MVP, I wanted to explore a different approach: using rules to handle straightforward cases, while reserving AI for more ambiguous scenarios that cannot be resolved by a rule.

That's why, before we start building the solution, there are three questions I want to answer:

How can we distinguish truly duplicate products from those that are simply similar?
When does AI add value, and when is it better to use traditional rules?
Can we build an MVP on AWS using a serverless architecture while keeping costs under control?

To answer these questions, we'll build a solution that combines AI with traditional rules. We'll walk through the process, from data analysis and normalization to architecture design, comparison logic, and evaluation of the results.

Because detecting duplicates isn't simply about finding similar names. First, we need to understand what we're comparing and what it actually means for two products to be the same.

2. The Business Problem

Poor product data quality is not an isolated problem. Various studies highlight the difficulties companies face in keeping information consistent, up to date, and accessible across their systems.
For example, in 2026, GS1 UK published a report on product information management in the construction sector, based on research involving more than 300 professionals and 15 prominent figures from the industry.
Some of its findings include:

£3.8 billion estimated potential annual losses resulting from inefficient product data management in the UK construction industry.
60% of respondents say that inefficiencies in managing this information are hindering progress.

The problem is not limited to construction. The 2024 Product Information Management Report by RIWI, based on a survey of more than 300 professionals, found that 37% identified bringing products to market as one of their main pain points.

What consequences can this have for a product catalog?

When products are not identified consistently, several problems can arise:

Stock: units of the same product may be spread across multiple records, making it difficult to determine actual inventory levels.
Pricing: comparing offers for the same product across suppliers or sales channels can become more difficult.
Search: users may encounter multiple listings for the same product or fail to find it when searching with a different variation of its name.
Reviews: ratings and reviews may be distributed across different listings of the same product.

That is why the objective of this project is more specific: to explore how to detect potential duplicates in a catalog, distinguish them from products that should remain separate, and evaluate whether combining AI with traditional rules can address part of the problem without driving up costs.

3. How Do We Manage Product Information?

When a company sells products through multiple channels, keeping information up to date and consistent can become a challenge. Product Information Management (PIM) systems are designed to manage this process.

3.1. 🗂️ What Is a PIM?

A PIM allows companies to centralize, enrich, organize, and distribute product information from a single location. It can manage product names, descriptions, technical specifications, images, and other attributes needed to sell a product. Adobe explains here how these systems work.

Source: Author's own diagram.

Consider, for example, a company that sells video games through its own website and marketplaces such as Amazon or eBay. Product information may come from different suppliers and in different formats, so it needs to be organized before being published across each channel.
Although this article introduces the concept of PIM, depending on the organization, product information may be managed in an Excel spreadsheet, a database table, enterprise systems such as a CRM or SAP MM, or specialized solutions like a PIM.
The idea is to explore a solution that can be accessed through an API, for example, to help perform data quality checks and detect potential duplicates, regardless of where the product information is managed.

4. MVP Design Principles

Before starting to build the solution, I had to make several decisions: which data to use, which part of the catalog to process, and how to combine AI with traditional rules without driving up costs.
These are the principles that defined the scope and design of the MVP:

1. A public, realistic dataset.

I used the product metadata from Amazon Reviews 2023, in the Video Games category. I chose this category because it covers many different scenarios: the same game can be sold for different platforms (Nintendo, PlayStation, Xbox or PC), in different editions (standard, deluxe or collector’s), in physical or digital format, or as a refurbished product.

2. A limited scope based on an external criterion.

For the MVP, I selected a subset of products based on the 20 best-selling video game franchises according to Wikipedia. To identify the records, I used regular expressions that look for the names of these franchises and their variants in the dataset titles. This keeps the data volume manageable and makes the selection criterion reproducible.

3. Cost as a design variable.

I chose a serverless AWS architecture, with on-demand processing and low-cost AI models. Every technical decision is also evaluated for its impact on cost, from data preparation to model calls.

4. Rules first, AI where it adds value.

To avoid unnecessary costs, I first analyze the data and apply deterministic rules to the cases that can be solved simply. The language model is reserved for cases that require interpreting text, recognizing abbreviations or evaluating ambiguous matches.

5. Explicit business criteria.

Deciding whether two products are the same, a variant or different products is not just a technical question: it depends on the business. In this MVP, those criteria are defined in the prompts and in the pipeline rules, with examples that guide the model. They are a proposal for this case study: in a production environment, they must be reviewed and validated with the business teams of each organization.

6. A pipeline to evaluate, not a finished system.

This MVP is a practical approach to building a data pipeline for detecting duplicate products. The goal is not a perfect system, but to check whether the approach is viable and to measure its technical behavior: how long it takes, how much it costs, which share of the decisions is resolved with rules and which needs a model, and how extraction quality evolves across prompt versions. I also review specific cases to understand where it succeeds and where it fails.

5. Architecture

Before going into the details of each step, it is worth looking at the complete solution. The goal of the architecture is to transform a disorganized product catalog into one where each listing is associated with the actual product it represents, making that information available for real-time queries.
To achieve this, the solution combines batch processing, which processes the entire catalog at once, with a real-time component that handles new products or search queries as they arrive.

Source: Architecture diagram created by the author.

The image above shows the solution architecture, organized into three parts:

Input: starts with the Amazon Reviews 2023 dataset. We apply the selection criteria defined for the MVP and the data quality rules identified during the EDA, discarding records that do not meet the requirements or fall outside the project's scope.
Pipeline: processes the products from start to finish. It extracts their attributes using a language model, converts them into vectors, searches for similar products, and determines whether they are duplicates, variants, or different products. Finally, it assigns each product a product identifier and a family identifier, storing the results in DynamoDB, a NoSQL database.
Inference: allows us to query the catalog or evaluate new products. It receives a natural language search query, such as FIFA 14 PS3 digital code, or the details of a new product, and determines whether it matches an existing product, is a variant, or is a new product. The response includes the corresponding identifiers.

One principle guided all our decisions: a fully serverless architecture that allows on-demand processing without managing dedicated servers.
For a catalog that is updated periodically, as in this case, this approach allows us to adjust resource consumption to actual needs, with costs primarily associated with data storage, operations performed, and resources used during each execution.

The following AWS services are grouped according to the diagram's legend:

🟩 Storage

Amazon S3: stores the data from each stage in its own folder, allowing us to trace each product and reprocess data from any step.
Amazon S3 Vectors: stores product vectors and performs similarity searches without requiring us to manage a vector database.
Amazon DynamoDB: stores each product with its product and family identifiers, enabling millisecond key-based queries for the real-time component.

🟨 Compute / AI

Amazon Bedrock, with three models, each selected for a specific task:
Nova Micro: extracts the attributes of each product. It is the most cost-effective model and is used for all attribute extraction calls.
Titan Text Embeddings V2: converts each product into a vector.
Nova Lite: handles ambiguous cases. It has stronger reasoning capabilities than Nova Micro and is used only for a small proportion of product pairs.

🟪 Pipeline

AWS Lambda: executes each processing step as an independent function.
AWS Step Functions: orchestrates the pipeline steps, retries temporary failures, and displays the status of each execution.

🟥 Security

AWS IAM: each Lambda function has its own role with the minimum permissions required (for example, reading only from the input folder and writing only to the output folder).
AWS KMS: encrypts data at rest.

🟦 Logs

Amazon CloudWatch: centralizes logs from all Lambda functions and Step Functions. It is the first place to look when a step fails, and it also allows us to examine metrics such as execution duration or memory usage for each run.

6. Use Case Development

6.1. 🔍 What Is EDA?

Exploratory Data Analysis (EDA) is a process that helps us better understand a dataset before applying models or making decisions. Through different exploration and visualization techniques, we can identify patterns, discover relationships between variables, detect anomalies, and assess data quality.
Although we often associate EDA with the early stages of Machine Learning projects, the concept is not new. Statistician John W. Tukey formalized it in his book Exploratory Data Analysis, published in 1977.

🎯 Why is it important?

Because it helps us understand the data before working with it, identify outliers, detect inconsistencies, and question our initial assumptions. Instead of assuming that the data has the expected structure or quality, we explore it to discover what it is actually telling us.

🤖 And what about generative AI projects?

It can be tempting to send raw data to a model with a prompt and hope for the best. But every unnecessary field adds tokens that we pay for with each call, and every inconsistent data point is a potential error that the model can propagate. EDA helps us decide which data to send, what to correct beforehand using simple rules, and which part of the catalog to process.
For this use case, I performed ten checks:

Source: Author's own infographic.

The findings that had the greatest impact on the design were:

main_category does not describe the product: it refers to the store department. The platform is taken from categories.
There are hidden nulls: thousands of products have an empty categories list.
Not everything in Games is actually a game: there are controllers, statues, and bundles.
Accessory titles are full of keywords: so comparing titles directly does not work.
Some fields seem useful, but are not: Pricing is a legal notice, and Date First Available is not the release date.

These findings lead to an initial conclusion: before looking for duplicates, we need to understand what each field represents and distinguish the products that can actually be compared.

📓 Would you like to explore the full analysis? The eda_video_games.ipynb notebook, including the code and charts, is available in the project repository. There, you will also find the files needed to continue implementing the architecture.

6.2. ☁️ Infrastructure Deployment

With the data analyzed, the next step is to create the resources required by the pipeline.
Ideally, we would define the entire infrastructure as code using Terraform, AWS SAM, or CDK and deploy it with a single command. To keep this MVP simple, I created the resources through the AWS Console and included the scripts and AWS CLI commands in the repository to reproduce the deployment.

🧰 Prerequisites

Before getting started, you will need:

An AWS account with access to Amazon Bedrock in us-east-1 and the Nova Micro, Nova Lite, and Titan Text Embeddings V2 models enabled.
AWS CLI v2, configured with the permissions required to create the resources.
The meta_Video_Games.jsonl file from the Amazon Reviews 2023 dataset.
Clone the repository and navigate to the project directory:

git clone https://github.com/RominaElenaMendezEscobar/aws-games-products.git
cd aws-games-products

RominaElenaMendezEscobar / aws-games-products

A serverless AI solution on AWS to identify similar products and distinguish duplicates, variants, and different items using Amazon Bedrock, embeddings, business rules, and S3 Vectors.

🎮 Identical or Similar? AI-Powered Product Matching with Amazon Bedrock and S3 Vectors

Is it the same product? A serverless pipeline that detects duplicate and variant listings in an e-commerce catalog, combining a language model, vector search and simple rules, with cost as a design constraint.

The use case is a video game catalog: the same game can be sold for different platforms, in different editions and formats, as a budget reprint or refurbished, and its title can be written in many ways ("GTA: Vice City" vs "Grand Theft Auto: Vice City", "Black Ops II" vs "Black Ops 2"). Some of those listings are the same product; others look almost identical but are not.

📝 This repository accompanies the article Identical or Similar? AI-Powered Product Matching with Amazon Bedrock and S3 Vectors].

📊 Results at a glance

Processed with the final version of the pipeline (prompt v8) on the…

View on GitHub

📁 Repository Structure

The resources are organized by service under aws/. Each Lambda function has its own directory containing the code, permissions policy (policy-role.json), and required configuration.

aws/
├── S3/                 → data bucket
├── S3Vectors/          → vector bucket and index
├── DynamoDB/           → products table
├── lambda/             → 8 functions + deployment script
└── step-function/      → pipeline definition and its role

The deployment follows this order: storage → Lambda functions → Step Functions, as each stage depends on resources created earlier.

6.2.1. 🟩 Storage

6.2.1.1 Amazon S3 · `game-catalog-dedup`

This bucket stores the intermediate data generated during the different pipeline stages.

bash aws/S3/create_s3_bucket.sh

6.2.1.2 Amazon S3 Vectors · `game-catalog-vectors / index games-v2`

This is where the product embeddings are stored. First, we create the vector bucket and then the index, which uses 1,024-dimensional vectors compatible with the Titan Text Embeddings V2 configuration and cosine distance.
The title and base_title fields are configured as non-filterable metadata: they are preserved in the results but cannot be used as filtering criteria in the index.

aws s3vectors create-vector-bucket \
  --vector-bucket-name game-catalog-vectors

aws s3vectors create-index \
  --vector-bucket-name game-catalog-vectors \
  --index-name games-v2 \
  --data-type float32 \
  --dimension 1024 \
  --distance-metric cosine \
  --metadata-configuration '{"nonFilterableMetadataKeys": ["title", "base_title"]}'

6.2.1.3 Amazon DynamoDB · `game-catalog-products`

The table stores products identified by parent_asin and uses on-demand capacity. Two global secondary indexes allow us to query the results by identifier:

canonical_id-index: all listings representing the same product.
family_id-index: all variants of the same game.

bash aws/DynamoDB/create_dynamodb_table.sh

6.2.2. 🟥 Permissions and Configuration

Each function has its own IAM role with least-privilege permissions. The policies are defined in the policy-role.json file in each directory and specify which services each Lambda can access. Each role also includes the AWS managed policy AWSLambdaBasicExecutionRole, so the function can send logs to CloudWatch. The deployment script (6.2.3) creates the roles and attaches both policies.
Before deploying, review the ARNs in each policy-role.json and replace <account_number> with your own AWS account ID. Also check the resource names and the Region.

6.2.3. 🟪 Lambda Functions

All eight functions use Python 3.12. To simplify deployment, I prepared a script that creates each function's IAM role from its policy-role.json file, packages the code, and creates the Lambda function or updates it if it already exists.

The script receives the function’s folder, its name, the memory and the timeout, and optionally a Lambda Layer ARN and the ephemeral storage size:

./aws/lambda/deploy_lambda.sh <folder> <function-name> <memory-MB> <timeout-s> [layer-arn] [ephemeral-MB]

These are the commands to deploy the eight functions:

cd aws/lambda
./deploy_lambda.sh <folder> <function-name> <memory-MB> <timeout-s> [layer-arn] [ephemeral-MB]
./deploy_lambda.sh ETL01-game-catalog-etl              game-catalog-etl                     2048 900 <pandas-layer-arn> 2048
./deploy_lambda.sh SP01-game-catalog-prepare-batch     game-catalog-prepare-batch           1024 180 "" 1024
./deploy_lambda.sh SP02-game-catalog-extract-ondemand  game-catalog-extract-ondemand-access  512 900
./deploy_lambda.sh SP03-game-catalog-parse-results     game-catalog-parse-results           1024 300 "" 1024
./deploy_lambda.sh SP04-game-catalog-embed             game-catalog-embed                    512 900
./deploy_lambda.sh SP05-game-catalog-decide-pairs      game-catalog-decide-pairs            1024 900
./deploy_lambda.sh SP06-game-catalog-build-clusters    game-catalog-build-clusters          1024 900
./deploy_lambda.sh RT01-game-catalog-resolve-product   game-catalog-resolve-product          512 60

⚠️ The ETL Lambda function uses pandas, which is not included in the default Lambda runtime. It requires the AWS-managed AWSSDKPandas-Python312 layer (in the Lambda console: Layers → Add a layer → AWS layers) and 2 GB of ephemeral storage, as it writes the cleaned catalog to /tmp before uploading it to S3.
The configuration depends on the task: the ETL Lambda requires more memory to process the dataset, while functions that invoke models may need longer execution times. The real-time query Lambda has a shorter timeout.

6.2.4. 🟪 Step Functions · `game-catalog-dedup-pipeline`

Finally, we create the Standard state machine game-catalog-dedup-pipeline, which coordinates the six processing stages. Its role has permission to invoke only the six Lambda functions used by the pipeline (LambdaInvokeScopedAccessPolicy.json).

aws iam create-role --role-name game-catalog-dedup-pipeline-role \
  --assume-role-policy-document file://aws/step-function/trust-policy.json

aws iam put-role-policy --role-name game-catalog-dedup-pipeline-role \
  --policy-name LambdaInvokeScopedAccessPolicy \
  --policy-document file://aws/step-function/LambdaInvokeScopedAccessPolicy.json

aws stepfunctions create-state-machine \
  --name game-catalog-dedup-pipeline \
  --definition file://aws/step-function/game-catalog-dedup-pipeline.json \
  --role-arn <step-functions-role-arn> \
  --type STANDARD \
  --region us-east-1

6.2.5. 📥 Upload the Raw Data

aws s3 cp data/meta_Video_Games.jsonl s3://game-catalog-dedup/raw/

6.3. 🛠️ Data Preparation

After exploring the dataset, the next step is to prepare it for the duplicate detection pipeline.
The EDA helped us understand its structure, identify data quality issues, and determine which attributes could be useful. Based on these findings, I divided the preparation process into two stages: first, cleaning and filtering the data; then, selecting the catalog we would use for the MVP.

6.3.1. 🧹 Data Cleaning and Filtering (ETL)

A Lambda function applies the rules defined during the EDA before any AI model is involved. The goal is to prevent incomplete records or unnecessary fields from affecting subsequent processing stages.
The main operations are:

Discard products without titles or categories. Without this information, it becomes more difficult to identify the product and determine whether it falls within the experiment's scope.
Remove columns without useful information. This reduces the amount of data we need to store and process, avoiding the need to carry empty fields into subsequent stages.
Convert prices to numeric values. When available, this conversion makes prices easier to analyze and ensures a consistent data type.
Filter the Games category. We keep only records belonging to this dataset category, reducing the initial dataset before selecting the franchises.

These operations do not identify duplicates yet. They prepare the data so that subsequent stages can compare products using more consistent information.

This stage is important because it defines the information the model will receive: if a piece of data arrives incomplete or incorrect, the error carries over into the extraction, the search, and the decision-making process.

6.3.2. 🎯 Why the 20 Best-Selling Video Game Franchises?

As mentioned in the MVP design principles, I used the 20 best-selling video game franchises as a reference to define the scope of the dataset.
This choice was intentional: I wanted to work with franchises that would allow us to explore different duplicate and variant scenarios, such as annual releases, titles published for different consoles, re-releases, and versions with similar names.
For example, FIFA has successive releases that should not be confused with one another, while the Mario and The Legend of Zelda franchises include games released for different Nintendo consoles. In these cases, similar titles do not necessarily identify the same product.
Additionally, limiting the catalog helps control the volume of data and the cost of model invocations during experimentation.

The dataset is progressively reduced at each stage:

📦 Original dataset: 137,269 products
🧹 Products with titles and categories: 124,624
🎮 Products in the Games category: 46,530
🏆 Products from the 20 best-selling franchises: 3,740

6.3.3. 📦 Storing Each Stage's Results Separately

Each stage stores its results in a separate Amazon S3 folder (raw/,clean/,mvp/…). In addition, the pipeline stages store their outputs in an execution-specific subfolder, such as attributes/top20-v8/.
This separation offers two practical advantages:
First, it allows us to reuse the results of a stage without repeating the entire processing workflow.
Second, it makes it easier to compare different pipeline executions and identify what has changed between versions.
This proved especially useful when refining the prompt: I could rerun subsequent stages using the already prepared data, without repeating the catalog cleaning process every time I modified the model instructions.

6.4. 🧠 Prompt Design and Evaluation

Once the data is prepared, the next step is to define how we will use AI. The goal is not to ask a model to find duplicates directly across the entire catalog, but rather to break the problem down into more specific tasks.
To achieve this, I designed two prompts: one to normalize the attributes of each product and another to determine whether two candidate products are duplicates, variants, or different products.
However, before selecting the models and writing the instructions, there were several requirements the solution needed to meet.

6.4.1. 📋 What Do We Expect from AI?

The first requirement was consistency. If two listings describe the same video game, we need the model to generate normalized attributes that allow us to recognize them as the same product, even when their original titles are different.
We also needed structured output that followed a predefined schema and could be processed programmatically without requiring manual interpretation.

Source: Author's own infographic.

The main requirements were:

Normalize products: extract the base title, platform, edition, format, region, publisher, and product type.
Maintain structured output: return valid JSON with the fields and values expected by the pipeline.
Apply business rules: distinguish an edition from a re-release, a physical product from a digital one, and a video game from an accessory.
Avoid unnecessary assumptions: do not invent attributes when the available information is insufficient to determine them.
Control costs and execution time: choose the appropriate model for each task and avoid unnecessary model calls.

6.4.2. ✂️ Two Prompts for Two Different Tasks

During testing, I decided to separate the process into two tasks: normalizing each product's attributes and evaluating candidate pairs that require further analysis. I also found that I could use different models depending on the task: Nova Micro for attribute extraction and Nova Lite for resolving ambiguous cases.

6.4.2.1. How Do We Invoke a Model from AWS Lambda?

One of the advantages of Amazon Bedrock is that we can invoke a model through its Converse API without having to manage the underlying model infrastructure. In this case, the prompt is sent as a system message, while the product listing is sent as a user message.
The basic implementation in Python is straightforward:

response = bedrock.converse(
    modelId="us.amazon.nova-micro-v1:0",
    system=[{"text": SYSTEM_PROMPT}],
    messages=[{"role": "user",
               "content": [{"text": json.dumps(build_payload(product))}]}],
    inferenceConfig={"temperature": 0, "maxTokens": 300},
)
attributes = json.loads(response["output"]["message"]["content"][0]["text"])

The build_payload function sends only the fields I selected during the EDA: title, store, categories, four keys from details, and three product features. This way, we avoid sending unnecessary information to the model.
This snippet shows the basic model invocation. The complete implementation also needs to handle response validation and error management.

6.4.2.2. SYSTEM_PROMPT: Product Normalization (Nova Micro)

This prompt uses Amazon Nova Micro and runs on every product in the catalog. Its purpose is to transform an original product listing into a set of normalized attributes that we can use in subsequent stages.
For example, a product listing might contain:

{
  "title": "GTA : Vice City - platinum [Playstation 2]",
  "categories": [
    "Video Games",
    "Legacy Systems",
    "PlayStation Systems",
    "PlayStation 2",
    "Games"
  ]
}

The expected output would have a structure similar to this:

{
  "product_type": "game",
  "base_title": "Grand Theft Auto: Vice City",
  "platform": "PlayStation 2",
  "edition": "Standard",
  "format": "physical",
  "region": "unknown",
  "publisher": "Rockstar Games",
  "confidence": "high"
}

In this example, the model normalizes the title and platform, while other attributes are determined according to the rules defined in the prompt. For instance, the Platinum label is treated as a budget re-release and normalized to Standard for this MVP. Other values may be inferred from the available information, so it is important to consider the limitations of these inferences.
The key is not simply to clean up the title, but to ensure that equivalent products are represented consistently without losing important distinctions, such as the platform.
📍 This prompt is used by the game-catalog-prepare-batch (batch) and game-catalog-resolve-product (on-demand) Lambda functions, both for the initial catalog processing and for resolving subsequent queries.

6.4.2.3. DECISION_PROMPT: Candidate Pair Comparison (Nova Lite)

This prompt uses Amazon Nova Lite and is reserved for ambiguous cases that require additional evaluation.
After normalization and candidate retrieval, not every match is straightforward. Two titles may be very similar while referring to different video games.

For example:

A: Mario & Sonic at the Olympic Games [Nintendo Wii]
B: Mario and Sonic at the Olympic Winter Games - Nintendo Wii

Although they share many words, these titles refer to different games. The presence of Winter is a meaningful distinction that we should not ignore.
The prompt must return a structured decision, for example:

{
  "relation": "different",
  "reason": "The base titles of the games are different."
}

📍 This prompt is used by the game-catalog-decide-pairs (batch) and game-catalog-resolve-product (on-demand) Lambda functions. By reserving Nova Lite for ambiguous pairs, we avoid using a more expensive model for every record in the catalog.

6.4.3. 🏗️ How I Built the Extraction Prompt

The SYSTEM_PROMPT was organized into five parts:

Source: Author's own diagram.

Role: a product data specialist who responds only in JSON.
Purpose: explains that the output will be used to detect duplicates and that consistency matters more than preserving the original title.
Rules: each rule comes from an EDA finding or an observed error: labels in brackets, product condition (“Renewed”) is not an edition, budget re-releases are considered the same product, sequel numbers are part of the title.
Schema: the fields and their allowed values, including a predefined list of platforms.
Examples: two complete cases using franchises outside the evaluated dataset, to assess whether the model generalizes rather than simply copying the answers.

6.4.4. 🧪 Testing Plan in Amazon Bedrock

To develop and test the prompts, I used the Amazon Bedrock Playground, which allows you to change the prompt, model, and parameters and see the response immediately, without writing a single line of code. Its comparison mode displays two models side by side using the same input, along with token consumption and latency.
This was especially useful during experimentation: I could modify a rule, rerun a problematic case, and check whether the result improved or a new error appeared.

Source: Screenshot captured by the author from the Amazon Bedrock console (AWS).

To evaluate the models' behavior and improve the prompts, I organized the tests across several dimensions:

🤖 Model Comparison

I tested Amazon Nova Micro and Nova Lite with equivalent inputs to evaluate their performance on extraction and comparison tasks.
The final decision was to use Nova Micro to normalize all products and reserve Nova Lite for ambiguous pairs. This way, the model with stronger reasoning capabilities is used only when it can provide additional value.

🌡️ Generation Parameters

I used a temperature of 0 to reduce response variability during testing. This is useful when comparing prompt versions, although it does not guarantee that every execution will produce identical results.

📦 One Product per Call or Multiple Products Together

Grouping ten products into a single call could have reduced the number of extraction calls from approximately 3,740 to 374. However, during testing, I observed that the model could mix information between records, incorrectly modify titles, or return results without properly associating them with their identifiers.
For this reason, I kept one call per product and used eight concurrent calls. This decision increases the number of requests but makes it easier to maintain the correspondence between each input and its result.

🌍 Queries in Different Languages

Although the catalog is primarily in English, I also wanted to test how the system would respond to searches written in Spanish.
I tested queries such as pokemon esmeralda game boy advance, fifa 14 ps3 código digital, and el mario kart de la wii. The goal was to evaluate whether the model could interpret these expressions and normalize them to the vocabulary and attributes used in the catalog.
These tests are relevant for a system that not only processes existing records but can also receive search queries written by users.

🧪 Edge Cases and Regression Testing

Each new version was tested against previously failing cases and control cases that already worked, to ensure that fixing one issue did not introduce another. These included titles without numbers, titles that already use digits (“FIFA 23”, “NBA 2K17”), and letters that are part of a game's name (“Pokémon X”, “Call of Duty: WWII”, “Mega Man X”).

🧠 Influence of Conversation Context

During testing, I noticed another important detail: the Playground can preserve conversation history. When I tested many products consecutively in the same chat, previous responses could influence subsequent ones.
In one test, the model stopped correctly normalizing Roman numerals after several examples. Since each Lambda invocation is independent, this behavior did not reflect the actual conditions of the pipeline.
To avoid misleading comparisons, tests needed to use the same message sent by the application, without previous conversational context, starting a new conversation whenever necessary.

💰 Tokens, Costs, and Execution Time

The Amazon Bedrock Playground allowed me to observe token consumption and call latency to estimate costs before running the full pipeline.
I later compared these estimates with the actual results. I also measured the extraction time for all 3,740 products, which was 8 minutes and 26 seconds, mainly constrained by Bedrock's requests-per-minute quota.
These measurements allowed me to evaluate technical decisions beyond response quality, taking both cost and processing time into account.

📊 Results

The prompt went through eight versions. Here are some of the differences between the first run on the 20 franchises (version 6) and the final version (version 8):

Games with no identified platform: from 5.3% to 1.1%.
Games with no identified format: from 8.3% to 3.1%.
Input tokens per product: from approximately 620 to 1,500.
Estimated cost of extracting 3,740 products: from approximately $0.12 to $0.24. ##### 💡 Lessons Learned
Examples work better than abstract rules. I tried four different ways of instructing the model to convert Roman numerals into digits (“Black Ops II” → “Black Ops 2”). A simple rule, one explaining the purpose, and a more detailed version all failed in some cases. With two examples, the model correctly converted “Black Ops II”, “Final Fantasy VII”, and “GTA V”, while also preserving “Mega Man X”, where the X is part of the name.
Examples can also teach the model what you don't want. A single example containing "platform": "unknown" was enough for the model to leave the platform unidentified for 14% of the games. After correcting the examples to reflect the actual data format, that figure dropped to 1%.
“Don't guess” is not always the best instruction. An unknown value may seem like the safest choice, but in the comparison rules it acts as a wildcard and can cause different products to be grouped together. For the format attribute, an explicit business assumption worked better: in this marketplace, digital products are always labeled as such, so products without a digital label are treated as physical.
Test under the same conditions as production. The same product produced different results in the Playground and the pipeline because I sent only the title in the Playground, while the pipeline also included categories. Tests are only reliable when they use the actual application input.
Measure every change. Every prompt improvement comes with a token cost, and a new rule can break something that previously worked. Comparing metrics across versions was what allowed me to detect regressions in time.

6.5. ⚙️ The Pipeline

The catalog is processed by an AWS Step Functions state machine that orchestrates six Lambda functions. Each function performs a single task, reads the previous stage's output from S3, and stores its results in a separate folder.

Source: Screenshot captured by the author from the AWS Step Functions console (AWS).

6.5.1.❓Why Did I Choose Step Functions?

I chose Step Functions to coordinate the processing for six reasons:

Orchestration: executes the steps in the defined order and passes the required parameters to each function.
Error handling: allows us to configure retries for temporary failures, such as certain Bedrock throttling errors.
Traceability: provides a visual representation of each step's status, inputs, outputs, and any errors that occur.
Execution isolation: each execution has a run_name and stores its results in separate S3 paths, allowing us to compare versions without overwriting the results of other executions.
Serverless architecture: there is no need to provision or manage servers to coordinate the pipeline. The services manage the underlying infrastructure and scale according to processing needs.
Cost control: processing runs on demand, without maintaining dedicated infrastructure while idle. This allows us to adjust resource consumption and pay for the resources used, including Lambda invocations, Step Functions state transitions, Bedrock calls, and storage.

AWS explains the Step Functions pricing model here.

6.5.2. 🔄 The Six Stages of the Pipeline

Before the Step Functions workflow begins, the game-catalog-etl Lambda function cleans the original dataset (raw/) and stores the products within the defined scope in mvp/.

PrepareRequests · game-catalog-prepare-batch
Filters the 20 franchises and generates one extraction request per product, including the extraction prompt and only the relevant fields.

📥 mvp/ → 📤 bedrock-input/
ExtractAttributes · game-catalog-extract-ondemand-access
Sends each request to Nova Micro, using eight concurrent calls, and stores the model's response.

📥 bedrock-input/ → 📤 bedrock-output/
ParseResults · game-catalog-parse-results
Validates the JSON returned by each request, separates video games from other products (bundles, DLC, accessories, etc.), and generates an extraction quality report.

📥 bedrock-output/ → 📤 attributes/, reports/
CreateEmbeddings · game-catalog-embed
Converts each game into a vector using Titan Text Embeddings V2 and stores it in the S3 Vectors index, along with its attributes.

📥 attributes/ → 📤 S3 Vectors
DecidePairs · game-catalog-decide-pairs
Finds the nearest neighbors of each game and determines the relationship between each pair using deterministic rules or Nova Lite for cases in the gray area.

📥 S3 Vectors → 📤 pairs/, reports/
BuildClusters · game-catalog-build-clusters
Groups related pairs and assigns each product a canonical_id (same product) and a family_id (same game).

📥 pairs/, attributes/ → 📤 clusters/, reports/, DynamoDB

6.5.3. 🎛️ Execution Configuration

To run the pipeline, we start a Step Functions execution with the following input:

{
  "bucket": "game-catalog-dedup",
  "run_name": "top20-v8",
  "title_contains": [
    "\\bmario\\b", "\\btetris\\b", "\\bpok[eé]mon\\b", "\\bcall of duty\\b",
    "\\bgrand theft auto\\b|\\bgta\\b", "\\bminecraft\\b", "\\bfifa\\b",
    "\\bassassin'?s creed\\b", "\\bresident evil\\b", "\\bfinal fantasy\\b",
    "\\bwii (sports|fit|play|party|music)\\b", "\\blego\\b", "\\bthe sims\\b",
    "\\bnba 2k", "\\bzelda\\b", "\\bmadden\\b", "\\bneed for speed\\b",
    "\\bsonic\\b", "\\bmonster hunter\\b", "\\bred dead\\b"
  ],
  "model_id": "us.amazon.nova-micro-v1:0",
  "prompt_version": "v8",
  "index_name": "games-v2",
  "decision_model_id": "us.amazon.nova-lite-v1:0",
  "pairs_run": "pairs-top20-v8",
  "clusters_run": "clusters-top20-v8",
  "attribute_keys": ["attributes/top20-v8/attributes_games.jsonl"]
}

What each parameter represents:

bucket: the S3 bucket where data from all stages is read and stored.
run_name: the execution name. Everything generated is stored under this name (for example, attributes/top20-v8/), keeping each version separate so it can be compared with previous ones.
title_contains: the patterns used to select products within the scope, in this case, the 20 franchises. These are regular expressions; \b represents a word boundary, preventing false matches such as “gta” appearing within another word.
model_id: the model used to extract attributes (Nova Micro).
prompt_version: the extraction prompt version. It is stored alongside each result to track which version generated it.
index_name: the S3 Vectors index where vectors are stored and queried.
decision_model_id: the model used to resolve ambiguous cases in the gray area (Nova Lite).
pairs_run and clusters_run: the folder names where the pair decisions and final clusters are stored.
attribute_keys: the attributes file used by the final stage to build the clusters.

6.5.4. ⏱️ Execution Time and Scalability

Processing all 3,740 products in the MVP took 14 minutes and 4 seconds. Attribute extraction was the slowest stage, taking 8 minutes and 26 seconds, mainly due to Bedrock's available requests-per-minute quota. The remaining stages took anywhere from a few seconds to a few minutes.

There is an important limitation to consider when scaling the solution: a single Lambda invocation cannot run for more than 15 minutes. To process a larger catalog, such as the more than 46,000 products in the Games category, it would be advisable to distribute requests across batches and control concurrency. Step Functions Distributed Map is one option for orchestrating this processing, adjusting concurrency according to model quotas and service limits.

📄 The Lambda source code, permissions, memory configuration, and maximum execution times are available in the repository.

6.6. ⚖️ How Do We Determine Whether Two Products Are the Same?

The central idea behind the design is to separate two questions:

🔎 Which products are similar? Vector search answers this question.
⚖️ Are they the same product? The attributes determine the answer.

If we relied on similarity alone, FIFA 14 for PS3 and FIFA 14 for Xbox 360 would be classified as duplicates because their vectors are very close. However, they are different products, each with its own stock and price. Vector distance helps us find candidates, while attributes help us make the final decision.
This process takes place in the last three stages of the pipeline:

CreateEmbeddings: converts normalized attributes into vectors.
DecidePairs: finds candidates and determines the relationship between each pair.
BuildClusters: groups related products and assigns identifiers.

6.6.1. 🔎 Finding Candidates

To find similar products, each game is converted into an identity text using its normalized attributes:

base title | platform | edition | format

For example:

Grand Theft Auto: Vice City | PlayStation 2 | Standard | physical

Normalized attributes are used instead of the original title so that two listings written differently can generate the same representation when they describe the same product. This helps reduce naming inconsistencies and improves candidate retrieval through vector similarity search.

Next, Amazon Titan Text Embeddings V2 converts this representation into a vector. Amazon S3 Vectors returns the 20 nearest neighbors for each product in the index, and we keep those with a cosine distance below 0.25.

A distance of zero indicates identical vectors; the greater the distance, the lower the similarity between them.
This threshold helps reduce the number of comparisons, but it does not determine on its own whether two products are duplicates. That decision is made in the next stage by evaluating their attributes and applying the defined business rules.

6.6.1.1. How Do We Generate the Identity Text and Embeddings?

The implementation is divided into two functions: one builds the text from the normalized attributes, and the other invokes the Bedrock embedding model.

def identity_text(attrs):
    parts = [
        attrs["base_title"],
        attrs["platform"],
        attrs["edition"],
        attrs["format"],
    ]

    return " | ".join(
        p for p in parts if p and p != "unknown"
    )


def embed(text):
    response = bedrock.invoke_model(
        modelId="amazon.titan-embed-text-v2:0",
        body=json.dumps({
            "inputText": text,
            "dimensions": 1024,
            "normalize": True,
        }),
    )

    return json.loads(
        response["body"].read()
    )["embedding"]

The identity_text function omits unknown attributes: if one listing does not specify the format and another does, including "unknown" would make their identity texts different and push apart two products that might actually be the same. The embed function sends the text to Titan Text Embeddings V2 and returns the generated vector.
For this MVP, I configured 1,024 dimensions to match the S3 Vectors index.

6.6.2. 🌳 Determining the Relationship

Once we have identified the candidate products, the next step is to determine the relationship between them. Similar titles are not enough: we need to check whether they represent the same product, a variant, or different games.
To do this, we combine business rules with an AI model that intervenes only when the rules are not sufficient.
The following decision tree summarizes the logic implemented in the MVP.

Source: Decision diagram created by the author.

6.6.2.1. Do the Base Titles Match?

First, we normalize the titles to prevent differences in capitalization, apostrophes, or punctuation from affecting matching. For example, “Link’s Awakening” and “Links Awakening” are considered equivalent after normalization.

6.6.2.2. Are the Attributes Compatible?

If the base titles match, we compare the platform, edition, format, and region.

If the attributes are compatible, we classify the pair as a duplicate.
If any known attribute differs, we classify the pair as a variant.

In this implementation, two attributes are considered compatible when they match or when one of them is unknown. This rule makes it easier to work with incomplete product listings, although it also introduces a risk: an unknown value may hide a real difference. Therefore, the classification needs to be evaluated alongside the results and any errors identified.

6.6.2.3. What Happens When the Titles Don't Match?

If the base titles differ but the vectors are very close, we enter a gray area. For this MVP, we use a distance below 0.08 as the threshold for sending these pairs to Amazon Nova Lite.
The model evaluates whether the titles describe the same product or refer to different games. When the conditions for this evaluation are not met, the pair is classified as different.

6.6.2.4. The Complete Rule in Code

The three steps described above are implemented in a single function, following the same sequence as the decision tree:

def rule_decision(a, b, distance):
    """Returns (relation, reason), or None when the pair goes to Nova Lite."""

    if normalize_title(a["base_title"]) == normalize_title(b["base_title"]):
        diffs = [
            f for f in ["platform", "edition", "format", "region"]
            if not compatible(a.get(f), b.get(f))
        ]

        if not diffs:
            return "duplicate", "same base_title and compatible attributes"

        return "variant", "differs in " + ", ".join(diffs)

    if distance < 0.08:
        return None  # gray zone: Nova Lite decides

    return "different", "different base_title"

The normalize_title and compatible functions apply the rules from steps 1 and 2: the first normalizes the titles, and the second checks whether two attributes match or whether one of them is unknown. When rule_decision returns None, the pair is sent to Nova Lite together with the DECISION_PROMPT.

📄 The full code is in aws/lambda/SP05-game-catalog-decide-pairs/lambda_function.py.

In the final run, 10,209 of the 10,449 candidate pairs (97.7%) were classified using deterministic rules applied to the attributes extracted by the AI, and only 240 pairs (2.3%) required an additional evaluation with Nova Lite.

This result shows that combining AI-based attribute extraction with deterministic rules can significantly reduce the number of additional model calls. However, these figures describe how the decisions were made, not how accurately the system identified duplicates.

In addition, the distance thresholds used in this MVP (0.25 to select candidates and 0.08 for the gray zone) were set empirically, based on cases observed during development. For a production implementation, a labeled reference set would be needed to check whether these thresholds are appropriate for each use case.

6.6.3. 🧩 Grouping Related Products

Once the pairs have been classified, we need to turn these individual relationships into groups that we can query and use later.

In this MVP, we create two levels of grouping:

🏷️ canonical_id: identifies listings that represent the same commercial product.
👨‍👩‍👧 family_id: groups duplicates and their variants, such as the same game available on different platforms, in different editions, or in different formats.

This distinction helps us answer two questions that are often confused: how many listings represent the same product, and how many products belong to the same game family.

6.7. ⚡ Inference and Real-Time Queries

So far, the pipeline has processed the entire catalog in a single run. But the result is more than just a duplicate detection report: once processing is complete, we have a product database in DynamoDB, where each listing is associated with its corresponding product and family, and a vector index in S3 Vectors containing each game's vector representation.

With these two components, we can query the catalog in real time. This also opens the door to integrating the solution with systems used to manage product information, such as a PIM or ERP.

Some possible scenarios include:

🛒 A purchasing team searches for “fifa 14 ps3 digital” and finds the correct listing, even if it is written differently in the catalog.
📦 A supplier submits a new product, and before it is added to the catalog, the system indicates whether it already exists or is a variant of another product.
🌍 Someone searches in Spanish within a catalog written in English.

To support these scenarios, the Lambda function has two modes: search, which receives a free-text query and identifies the corresponding product, and product registration, which receives the complete details of a new product, determines whether it already exists, and stores it with its identifiers.

6.7.1. 🔍 How Search Works

The important point is that the search does not directly compare the user's query with the catalog's product titles. Instead, it first converts the query into the same format used to represent products in the catalog and only then performs the comparison. Let's look at an example.

1. The User's Query

The following query is in Spanish, uses an abbreviation (“ps3”), and does not look like the product titles in the catalog, which are written in English and follow many different naming conventions.

fifa 14 ps3 codigo digital

2. Extract Attributes as JSON

The query is sent to Nova Micro using the same extraction prompt as the pipeline. The model returns the normalized attributes:

{
  "product_type": "game",
  "base_title": "FIFA 14",
  "platform": "PlayStation 3",
  "edition": "Standard",
  "format": "digital",
  "region": "unknown"
}

The key transformation has already happened: “ps3” has become “PlayStation 3”, and “codigo digital” has been interpreted as format: digital. The user's query now uses the same vocabulary as the catalog.

3. Build the Identity Text and Vector

Using these attributes, we build the same identity text format used for every game in the catalog, and Titan converts it into a vector:

FIFA 14 | PlayStation 3 | Standard | digital

4. Find Candidate Products

S3 Vectors returns the candidates with the highest vector similarity. Among them is the listing “FIFA 14 - PS3 [Digital Code]”, which has the same normalized identity text as the query and therefore a distance of zero, along with other physical versions of FIFA 14.

5. Retrieve the Identifiers

For each candidate, we query DynamoDB to retrieve its canonical_id (which commercial product it represents) and family_id (which game it belongs to).

6. Determine the Relationship

Using the same rules as the pipeline, we compare the query against each candidate: the digital listing is a duplicate because its title, platform, and format match, while the physical copies are variants because the format is different.

7. Output

{
  "decision": "duplicate",
  "canonical_id": "CAN-B00GGUW312",
  "family_id": "FAM-B00CD90R7M",
  "identity_text": "FIFA 14 | PlayStation 3 | Standard | digital",
  "matched_with": {
    "title": "FIFA 14 - PS3 [Digital Code]",
    "distance": 0,
    "method": "rule"
  }
}

The response does more than identify the product: the family_id also allows us to retrieve all its variants (other platforms, physical copies, and different editions).

🧪 More Examples

The game-catalog-resolve-product Lambda function allows us to test different queries and see how the system identifies a product and retrieves its variants. The following images show some examples of the responses.

Two fields are especially important:

canonical_id: identifies a specific commercial product. Listings that share this identifier are considered duplicates, even when their original titles are written differently.
family_id: groups products belonging to the same game family, including variants across different platforms, editions, or formats.

This distinction allows us to query not only duplicate listings but also the different versions of the same game.
For example, when querying the Assassin’s Creed III family in DynamoDB, we find 8 listings grouped into 4 commercial products: Xbox 360, PlayStation 3, PC in physical format, and PC via digital code.

Source: Screenshot captured by the author from the AWS Lambda console (AWS).

7. Results

The pipeline processed 3,740 product listings in 14 minutes and 4 seconds, from preparing the requests to creating the product clusters.

7.1. ⏱️ Execution Time

According to the AWS Step Functions execution history, the most time-consuming stages were:

ExtractAttributes: 8 min 26 s, to extract and normalize attributes using Nova Micro.
CreateEmbeddings: 4 min 21 s, to generate embeddings and store them in S3 Vectors.
DecidePairs: 55 s, to evaluate 10,449 candidate pairs.

Each of the remaining stages took less than 15 seconds. Attribute extraction was mainly constrained by Bedrock's requests-per-minute quota, while embedding generation was the second most time-consuming stage.

7.2. ⚖️ Rules Before AI in the Decision Step

In the final run, 10,209 of the 10,449 candidate pairs (97.7%) were classified using deterministic rules applied to the attributes previously extracted by the AI model, and only 240 pairs (2.3%) required an additional evaluation with Nova Lite.
This approach reserves the model for ambiguous cases and avoids unnecessary model calls. These decisions were reviewed through specific cases, but not validated one by one; measuring their accuracy would require a labeled reference dataset, as discussed in the conclusions.

7.3. 💰 Attribute Extraction Cost

The game-catalog-extract-ondemand-access Lambda function collects the input and output token counts returned by Bedrock. The execution summary, available in the ExtractAttributes step output in Step Functions, recorded:

3,740 products successfully processed, with no errors.
5,661,802 input tokens.
264,153 output tokens.

Based on these figures and Amazon Nova Micro pricing in us-east-1, the estimated extraction cost is:

Input: 5.66 million tokens × $0.035 per million = $0.20.
Output: 0.264 million tokens × $0.14 per million = $0.04.
Total extraction cost: approximately $0.24.

This calculation covers attribute extraction only. The total pipeline cost also includes embeddings, Nova Lite decisions, Lambda and Step Functions executions, and storage.

7.4. 📈 Prompt Evolution

Prompt engineering was an important part of this project. I used the Amazon Bedrock Playground to test instructions and examples, compare models, review errors, and refine the prompt without having to modify or deploy the code after each iteration. I then validated the changes by running the complete pipeline.

Between versions 6 and 8, the extraction metrics improved (Section 6.4.4), with fewer games missing an identified platform or format.

These metrics indicate an improvement in attribute extraction, although they do not, on their own, demonstrate greater accuracy in duplicate detection.

8. Conclusions

This MVP allowed me to demonstrate that deterministic rules, embeddings, and language models can be combined to detect potential duplicates without sending every comparison to an AI model.

It also showed that cost does not depend solely on the model selected. Data preparation, attribute selection, prompt design, and the rules used to handle straightforward cases all have a direct impact on resource consumption and execution time.

During the development of this MVP, I tested various products, edge cases, and prompt versions using a subset of the catalog. These tests made it possible to refine the extraction rules and evaluate the technical behavior of the pipeline, but they do not replace a systematic assessment of accuracy using labeled data.

However, the results should be interpreted within the scope of the experiment. Before using a similar solution with a real-world catalog, I would focus on several areas:

📊 Measure accuracy: create a reference dataset with pairs labeled as duplicates, variants, or different products.
🧪 Expand testing: cover more edge cases, such as titles with subtle differences or queries containing limited information.
🧩 Use more data: experiment with descriptions, images, and additional attributes, evaluating their impact on quality and cost.
🤖 Compare models: evaluate alternatives based on accuracy, latency, and cost.
📈 Scale processing: review Bedrock quotas, concurrency, and options such as batch inference.
🏗️ Automate infrastructure: define the deployment using Terraform, AWS SAM, or CDK.
🗂️ Version prompts: use Amazon Bedrock Prompt Management to maintain traceability across prompt versions.
👥 Incorporate feedback and human review: allow users to validate results and manually review the most ambiguous cases.

This exercise shows that identifying duplicate or similar products is not just about finding matches between their names, but about understanding which attributes define their identity and how to combine them with business rules. AI can help us solve the most complex cases, but its real value appears when we use it as part of a solution that also takes data quality, efficiency and costs into account.

⚠️ Note: this project is an exploratory MVP and is not intended for production use as is. Keep in mind that:

The figures come from a single run on a subset of 3,740 products, so the results may vary with other catalogs.
The rules work on the attributes extracted by the model: if the extraction fails, the error propagates to the search and the decision.
The thresholds, rules and business criteria were defined empirically.

Before applying a similar approach to a real catalog, it should be adapted to each organization's business rules, the models should be evaluated, and the accuracy of the results should be measured with your own data.

9. 📚References

Adobe. (s. f.). Product information management (PIM). https://business.adobe.com/blog/perspectives/product-information-management
Amazon Reviews 2023. (s. f.). Amazon Reviews 2023. https://amazon-reviews-2023.github.io/
Amazon Web Services. (s. f.). Amazon Bedrock pricing. Recuperado el 20 de octubre de 2026, de https://aws.amazon.com/bedrock/pricing/
Amazon Web Services. (s. f.). AWS Step Functions pricing. Recuperado el 20 de octubre de 2026, de https://aws.amazon.com/step-functions/pricing/
GS1 UK. (s. f.). Construction’s product information problem. https://www.gs1uk.org/insights/thought-leadership/constructions-product-information-problem
IBM. (s. f.). Exploratory data analysis (EDA). https://www.ibm.com/think/topics/exploratory-data-analysis
RIWI. (2024). 2024 product information management report. https://riwi.com/2024-product-information-management-report-2/
Tukey, J. W. (1977). Exploratory data analysis. Addison-Wesley.
Wikipedia contributors. (s. f.). List of best-selling video game franchises. Wikipedia. Recuperado el 20 de octubre de 2026, de https://en.wikipedia.org/wiki/List_of_best-selling_video_game_franchises

When Product Strategy Meets AI: What Happens to Metrics, Alignment and Decisions?

Romina Elena Mendez Escobar — Sat, 10 Oct 2026 11:36:36 +0000

1. Introduction

I have worked on application analytics projects, and there is one question that comes up again and again: what does it mean for our product to be successful?

It seems like a simple question, but agreeing on the answer can be much more difficult than it appears.

Marketing may focus on attracting new users and encouraging them to return. Product may prioritize feature adoption and user experience. Fraud and Security teams may focus on reducing risks and protecting the application. They all contribute to the success of the product, but each department looks at it from a different perspective and has its own priorities.

This diversity of objectives is also reflected in the questions that arise when analyzing data: What should we measure? Which indicators are relevant? How do we know if we are moving in the right direction? These questions are not always easy to answer when each team starts from a different definition of success.

Data governance can help establish common criteria for managing, interpreting, and using information. However, there is a question we need to address first: before agreeing on how to measure results, we need to agree on what we want to achieve as an organization.

How can we establish a shared direction that connects the priorities of different teams with a common objective, without losing sight of their specific needs?

In this article, I will explore how the North Star Framework can help answer that question, how to put it into practice through a workshop, and how generative artificial intelligence can support the process, from defining a primary metric to analyzing results and planning new initiatives.

2. When Measuring More Doesn't Mean Understanding Better

Today, we have tools that allow us to collect and analyze large volumes of information about how people use our products. We can measure downloads, active users, retention, conversions, or feature usage. However, having all these indicators does not necessarily mean we understand what is working or what we should improve.

The challenge is not only deciding which metrics to use, but understanding what they tell us about the product and how they relate to the objectives we want to achieve. An indicator may show positive results for one team without necessarily representing an improvement in the user experience or the value users receive.

For example, increasing the number of app downloads may seem like a good result. But what happens if those new users never return? Can we consider the product to be growing sustainably?

These questions lead us to distinguish between measuring product activity and measuring the value it actually generates.

The North Star Framework proposes addressing this challenge by establishing a shared direction: identifying a primary metric that represents the value users receive and connecting it to the factors that different teams can influence.

It is not about measuring less or replacing the indicators each department needs, but about giving them a common context that allows us to interpret results, connect decisions, and understand how each initiative contributes to the success of the product.

3. What Is the North Star Framework?

The North Star Framework is a methodology that helps organizations identify what product success means and how to measure it, using the value users receive as a reference point.

Its starting point is the North Star Metric (NSM), a primary metric that aims to reflect the value a product delivers to its customers and its relationship with sustainable business growth.

However, the framework goes beyond selecting a single indicator. It also helps identify the factors that influence this metric, establish relationships between them, and guide the decisions and initiatives of different teams.

3.1 Origin and Evolution of the Concept

The concept of the North Star Metric became popular in the field of growth hacking, driven by Sean Ellis, as a way to identify the metric that best represents the core value a product offers to its users.

Later, Amplitude developed and promoted the North Star Framework, expanding the concept of a primary metric into a more structured methodology.

This approach incorporates what are known as input metrics, which help identify the factors that teams can influence to impact the North Star, as well as different models of value creation depending on the type of product and practices for connecting strategy with the decisions made by each department.

In this way, the North Star is no longer just a reference indicator but becomes the center of a framework that connects user value, product metrics, and business decisions.

3.2 What Does a North Star Metric Bring?

Defining a North Star Metric is not simply about choosing an indicator that represents product success. Its true value lies in helping us understand how the decisions and actions of different teams contribute to creating value for users and driving business growth.

This approach allows us to move from analyzing metrics in isolation to interpreting them as part of a shared strategy. Below, we can identify six key benefits of adopting a North Star Metric.

Ultimately, it is not about measuring less, but about measuring with a clear purpose. The North Star does not replace the indicators that each team needs to manage its activities, but rather provides a strategic context for understanding how they relate to one another and how they contribute to the success of the product.

3.3 North Star Metric vs. One Metric That Matters (OMTM)

Although both concepts aim to focus attention on a relevant metric, the main difference lies in their purpose and the time horizon they represent.

The North Star Metric (NSM) provides a long-term strategic direction. It aims to reflect the value the product delivers to its users and serves as a reference point for connecting the decisions of different teams with the overall business objectives.

On the other hand, the One Metric That Matters (OMTM) allows teams to focus their efforts on a specific priority during a defined period. Unlike the North Star, it does not aim to represent the overall success of the product, but rather to help a team address a specific challenge and evaluate the results of the actions implemented.

For an OMTM to be useful, it should meet three conditions:

Be specific: focus on a concrete, measurable outcome rather than a broad objective such as “improving retention.”
Have a defined time frame: establish a working period, such as a few weeks or a quarter, that allows progress to be evaluated.
Address a current priority: adapt to the product's needs and change when the expected results are achieved or new challenges arise.

Both metrics can coexist and complement each other. While the North Star establishes the strategic direction we aim to achieve, the OMTM helps identify where to focus efforts at a given moment.

In this way, an organization can maintain a shared long-term vision without losing the flexibility needed to respond to specific challenges and opportunities.

3.4 How Do We Know If We've Chosen a Good North Star Metric?

So far, we have explored what a North Star Metric represents and how it can help establish a shared direction. But this leads us to an important question: how do we know if the metric we have chosen truly reflects the success of our product?

There is no universal metric that works for every organization. The choice depends on the product, the needs of its users, and the business strategy.

Amplitude proposes a series of criteria that can help us evaluate potential metrics. Rather than treating them as a checklist of requirements, I find it interesting to use them as questions that encourage us to reflect on what we want to measure.

Are we measuring the value the customer receives? A good North Star should represent a real benefit for those who use the product, rather than simply the number of interactions they have within it.
Is it connected to our strategy? The metric should reflect what we aim to achieve as an organization and remain relevant beyond the priorities of a specific team.
Does it help us anticipate success? Not all indicators serve the same purpose. Metrics such as Monthly Recurring Revenue (MRR) or Average Revenue per User (ARPU) allow us to evaluate business results, but they do not necessarily help us understand whether we are creating the conditions for sustainable growth.
Can we influence its evolution? It is important that teams can identify actions capable of improving it. Measuring external factors over which we have no control may provide context, but it is unlikely to help guide our decisions.
Is it understandable across the entire organization? A North Star should be easy to explain without relying on complex technical definitions. If each team interprets it differently, it will be difficult to use it as a shared reference point.
Can we measure it reliably? We need a clear definition and data that allow us to track its evolution. However, there is something I consider important: we should not choose a metric simply because we currently have the data needed to calculate it. Sometimes, measuring what truly matters requires tracking new events, improving data quality, or developing additional analytical capabilities.

This does not mean that these indicators are useless. They can be essential for evaluating specific initiatives, but we need to question whether they are suitable for representing the product's primary objective.

Choosing a North Star Metric should not be a competition between departmental indicators, but an opportunity to build a shared vision of what success means.

And this brings us to a question worth exploring separately: when does a metric that appears positive become a vanity metric?

3.5 Vanity Metrics: What Are We Trying to Demonstrate?

In many organizations, each team uses indicators to evaluate and demonstrate the results of its work. Marketing may highlight user growth, Product may focus on feature adoption, and Sales may emphasize increased conversions. All these results can be positive, but does that mean the product as a whole is successful?

This is where the risk of so-called vanity metrics arises: indicators that show favorable results but, when analyzed in isolation, do not necessarily reflect the value users receive or help us make better decisions.

A common example is the number of Daily Active Users (DAU). Having more and more people open an application may seem like a good sign, but does it mean they are actually getting value from it?

The answer depends on the context. For some applications, frequency of use may be essential, while for others, what matters is that users complete a task or fulfill a specific need. Even within the same product, the relevance of a metric can change depending on its stage of maturity. A newly launched application may prioritize user acquisition, while a more established one may focus on retention.

That is why a metric is not inherently a vanity metric, but becomes one depending on what it represents, how we interpret it, and what we use it for.

The challenge is not to stop measuring the performance of each team, but to avoid confusing positive results from individual indicators with the overall success of the product. The North Star Framework helps us connect these different perspectives with a shared objective.

4. From Framework to Practice: How to Organize a Workshop

So far, we have explored what the North Star Framework is and which criteria can help us identify a metric that represents the value our product generates. But there is an important question: how do we define that metric when each team has its own priorities and interpretations of success?

One way to address this challenge is through a collaborative workshop, as suggested by Amplitude in its documentation, that brings together different perspectives and helps transform ideas, data, and hypotheses into a shared direction.

To illustrate how I would put this process into practice, I designed a hypothetical exercise based on a language learning application like Duolingo. It does not represent the company's internal processes, but will serve as an example throughout the different stages of the workshop.

4.1 Who Participates

The first step is to identify the stakeholders who should participate in the workshop. To build a shared vision, we need to bring together different perspectives on the product, including areas such as Marketing, Product, Business, Data, Engineering, and, depending on the context, Fraud or Security.

We can use tools such as the Power–Interest Matrix to identify relevant stakeholders and understand their level of influence and interest. However, we should not select participants solely based on their hierarchical position, but also on the knowledge and experience they can contribute.

The goal is not for everyone to share the same priorities, but for their different perspectives to contribute to defining a common direction.

And these differences are reflected not only in each team's objectives, but also in the beliefs and assumptions that each person brings to the workshop.

4.2 The Beliefs and Assumptions We Bring to the Workshop

Once we have identified the stakeholders, there is another aspect we need to consider: each person comes to the workshop with their own ideas about what makes the product successful. Some are supported by data, while others come from experience, intuition, or the priorities of each team.

Amplitude's North Star Playbook identifies different types of beliefs that can influence these conversations:

〰️ 👥 Customers: what we believe our users need and value.
〰️ 🔗 Causality: which actions we think lead to certain outcomes.
〰️ 📈 Market: how we believe the market will evolve and what opportunities may arise.
〰️ 🤖 Technology: which trends could transform our product.
〰️ 🏁 Competition: what we think other players are doing or planning.
〰️ 💎 Value Proposition: what we believe differentiates our product.

The problem is not having these beliefs, but confusing them with facts that we have not yet validated.

For example, in our hypothetical language learning application, someone might say: “Users come back because they want to maintain their learning streaks.” This may sound reasonable, but do we have data to support it, or are we starting from an assumption?

Making these differences visible allows us to identify what we know, what we need to validate, and which hypotheses should guide our analysis.

And this is especially important in a workshop involving different departments: our goal is not to let the opinion of the person with the most influence prevail, but to build decisions based on collective knowledge and the available evidence.

4.3 Before the Workshop: Creating the Right Environment

Once we have selected the participants and identified the different perspectives they can contribute, we need to prepare an environment that encourages participation and the exchange of ideas.

In a workshop where we aim to define a shared direction, the way the conversation unfolds can be just as influential as the ideas that emerge from it. That is why it is important to establish certain conditions from the beginning:

〰️ 🤝 Build trust: create a space where people can share ideas, ask questions, and challenge assumptions without fear of being judged.
〰️ 📏 Establish clear rules: agree on the time allocated to each activity, respect speaking turns, and encourage discussions focused on ideas rather than individuals.
〰️ 🏢 Balance hierarchies: prevent the opinions of those in positions of greater responsibility from influencing everyone else. One alternative is to collect ideas individually before opening the discussion.
〰️ 🔕 Avoid interruptions: set aside dedicated time and space to maintain focus and continuity throughout the activities.

The goal is not to eliminate differences of opinion, but to allow all perspectives to be expressed before reaching a conclusion.

With these conditions in place, we can begin working on the activities that will help us transform different ideas into a proposed North Star and its input metrics.

4.4 During the Workshop: From Ideas to a North Star Metric

Once we have identified the participants, recognized the different beliefs, and established the conditions for working together, we can begin the workshop.

To illustrate the process, I will use a hypothetical example based on a language learning application like Duolingo. It is not intended to represent how the company works internally, but rather to help us visualize how we can move from different perspectives to a North Star Metric and its input metrics.

We will organize the workshop into three stages: divergence, convergence, and hypothesis definition.

4.4.1. Divergence: Generating Ideas

The first objective is to gather different perspectives without trying to reach a conclusion immediately.

We can start with a question that encourages reflection:

What do we believe drives the success of our application?

And complement it with some additional questions:

〰️ Why do we believe users continue using the application?
〰️ At what point do they feel they are actually learning?
〰️ What factors might cause them to abandon it?
〰️ What would motivate them to return after a break?

To carry out this activity, we can use the 3-12-3 Brainstorming technique: three minutes to write down ideas individually, twelve minutes to share and develop them in pairs, and three minutes to present the main proposals to the group.

An interesting practice is to use two different colors of sticky notes to distinguish ideas supported by data from those that are still assumptions.

At this stage, we are not trying to determine who is right, but rather to gather different perspectives and prevent some ideas from being dismissed before they have been heard.

4.4.2. Convergence: Grouping and Prioritizing

Once we have collected the ideas, the next step is to organize them to identify what they have in common and how they relate to one another. At this stage, we are no longer trying to generate new proposals, but rather to find patterns that help us understand which factors could contribute to the product's success.

To do this, we can use Affinity Mapping, a technique that involves grouping ideas based on their themes or similarities.

Returning to our language learning application example, we could identify different groups related to motivation and learning habits, how easy it is to get started, the ability to resume lessons after a break, or users' perception of their own progress.

As we organize these ideas, we can also begin to distinguish between the outcomes we want to achieve and the actions or factors that could help us achieve them. For example, encouraging users to return daily may be a desired outcome, while timely reminders or features related to learning streaks could be factors that influence this behavior.

However, not all ideas will be equally relevant or supported by the same level of evidence. To identify which ones participants consider most important, we can use Dot Voting, a technique in which each person receives a limited number of votes to select the proposals they consider priorities.

Voting does not determine which ideas are correct, but rather which ones deserve greater attention. If a proposal receives many votes but is still based on assumptions, we have an interesting hypothesis that needs to be validated before making decisions.

During this process, questions or topics may also arise that we cannot resolve at that moment. To prevent the conversation from losing focus, we can use a Parking Lot to record these issues and revisit them later.

In this way, we move from a collection of individual ideas to an initial organization of potential outcomes, influencing factors, and hypotheses that will serve as a starting point for defining a North Star Metric and its input metrics.

4.4.3. Defining the Hypothesis: Connecting the Metrics

With the ideas grouped and prioritized, we can begin to build a hypothesis about which factors contribute to the product's success.

The goal is to identify a North Star Metric that represents the value we want to create and connect it to a limited set of input metrics that we can influence.

To express this relationship, we can use a phrase such as:

“If we do all of this right, then…”

This exercise encourages us to explain why we believe that improving certain factors will contribute to the outcome we want to achieve.

From there, we can identify opportunities for improvement, propose potential interventions, and define how we would measure their results.

It is important to remember that not every idea automatically becomes a metric, and not every relationship we propose has been proven. The outcome of the workshop is a shared hypothesis that we will later need to validate with data.

4.4.4. Documenting: The Workshop's Memory

At the end of the workshop, it is important to document not only the decisions made, but also how we arrived at them: the ideas proposed, the groups identified, the votes, the hypotheses that still need to be validated, and the reasons why certain alternatives were discarded.

This documentation allows us to maintain traceability of decisions and revisit the reasoning that led us to define our North Star and its input metrics.

But there is another aspect I consider important: metrics are defined within a specific context, and that context can change. That is why it is also useful to record the product's stage of maturity, the features it offered, who its users were, and what the business priorities were at that time.

Consider, for example, how Duolingo has evolved: it went from offering language courses to incorporating new learning experiences, other disciplines, and AI powered features. These changes can influence how people use the product and the value they expect to receive.

The same can happen due to external factors. The emergence of new technologies, changes in the market, or evolving user needs may mean that a metric that was once relevant needs to be reviewed.

Documenting the context allows us to understand why we made certain decisions and recognize when it is necessary to question them again.

4.4.5. After the Workshop: Validating and Reviewing

The workshop allows us to build a shared vision, but the metrics and relationships we have identified still need to be validated with data. Reaching an agreement does not necessarily mean that our hypotheses are correct.

Validating the Hypotheses

Once the session is over, we can transform ideas and assumptions into concrete hypotheses that allow us to analyze which factors influence our North Star.

This involves reviewing the available data, identifying what information is missing, and defining how we will test whether the proposed relationships actually hold true.

Here, generative AI can help us organize workshop notes, structure hypotheses, and prepare questions for analysis. However, validation requires evidence and the judgment of the teams, not just an interpretation generated by AI.

Reviewing Periodically

Organizations evolve, products incorporate new features, and user needs change. That is why a North Star should not be considered a permanent decision.

It is advisable to establish periodic reviews to evaluate whether the metric continues to represent the value the product generates and whether the defined inputs remain relevant.

The goal is not to change metrics constantly, but to ensure that we continue measuring what truly matters.

5. A Real Case to Understand Input Metrics: Duolingo's Growth Model

In the previous section, we explored how we can use a workshop to define our North Star Metric and identify the factors we believe influence it. But how can we connect a primary metric to more specific indicators that help us understand what drives its results?

To better understand this, I will use the growth model that Duolingo published in 2023 as a reference. It is an interesting example of how a company can leverage its product data to understand user behavior and guide its decisions.

Faced with stagnating growth in Daily Active Users (DAU), Duolingo's Data Science team developed a Growth Model based on a Markov model to analyze how users transitioned between different activity states.

Rather than looking only at the total number of active users, the model distinguishes seven states based on user behavior:

New Users: users who open the application for the first time.
Current Users: users who are active today and were also active during the past week.
Reactivated Users: users who return after more than a week of inactivity, but within the past month.
Resurrected Users: users who return after more than 30 days of inactivity.
At-risk WAUs (Weekly Active Users): users who were active during the past week, but not today.
At-risk MAUs (Monthly Active Users): users who were active during the past month, but not during the past week.
Dormant Users: users who have not used the application for at least 30 days.

Illustration of the Duolingo Growth Model: Technical Details

What makes this model interesting is that it does not simply classify users, but also allows us to analyze how they move from one state to another and which factors may contribute to their continued use of the product, their return after a break, or their decision to stop using it.

To study these transitions, Duolingo uses different retention metrics, including four worth highlighting:

〰️ CURR (Current User Retention Rate): measures the retention of regular users.
〰️ NURR (New User Retention Rate): analyzes the retention of new users.
〰️ RURR (Reactivated User Retention Rate): measures the retention of users who return after a relatively short break.
〰️ SURR (Resurrected User Retention Rate): analyzes the retention of users who return after an extended period of inactivity.

Using these metrics, Duolingo ran simulations to understand which ones could have the greatest impact on DAU. In its analysis, the team identified that improving CURR offered a particularly significant opportunity and used A/B experiments to evaluate strategies aimed at improving retention.

What I find interesting about this example is how a general metric can be broken down into more specific indicators that help identify where to take action.

We can also apply this logic to the North Star Framework. We do not always need to create new metrics from scratch. Many organizations already have indicators related to acquisition, activity, retention, or conversion. The challenge may lie in selecting the most relevant ones, understanding how they relate to each other, and connecting them to the value we want to create for our users.

In other cases, we will need to introduce new ways of measuring or review existing metrics as our product evolves.

It is important to clarify that Duolingo's Growth Model is a product analytics model and not necessarily its official North Star Framework. However, it helps illustrate how we can identify factors that influence a primary metric and use them to guide our decisions.

But selecting a limited set of input metrics does not mean that other indicators are no longer important.

An application still needs to analyze other dimensions, such as user acquisition, feature adoption, user experience, retention, and product quality.

These complementary metrics provide context to help us interpret results, identify problems, and understand what is happening beyond our North Star.

6. From the North Star to Contextual Metrics

So far, we have explored how a North Star Metric can help us establish a shared direction and how its input metrics allow us to identify the factors that contribute to achieving it.

But the success of an application cannot be understood through a single indicator or a limited set of metrics.

Teams need to analyze different aspects of the product: how users arrive, what happens during their first interactions, which features they use, why they return, and whether they encounter technical issues that affect their experience.

These metrics provide context and allow us to interpret results from different perspectives. For example, a decline in retention could be related to performance issues, difficulties during onboarding, or changes in the behavior of certain user segments.

The following infographic brings together some of the KPIs we can use to analyze different dimensions of an application, from acquisition and activation to engagement, retention, and product quality.

The North Star helps us maintain a strategic direction, while contextual metrics allow us to understand what is happening within the product and which aspects we need to investigate.

It is not about constantly analyzing every indicator, but rather selecting those that provide relevant information to interpret results and make better decisions.

7. How AI Can Support the North Star Framework

The North Star Framework does not end when we define a metric. It is an ongoing process that requires analyzing results, testing hypotheses, communicating decisions, and reviewing whether we are still creating value for our users.

Throughout this process, artificial intelligence can help us work with information, explore different perspectives, and transform data into useful knowledge to support decision-making.

However, it is important to distinguish between generative AI and other artificial intelligence techniques. While machine learning can be used to detect anomalies, identify patterns, or build predictive models, generative AI offers other capabilities, such as summarizing information, facilitating its interpretation, and allowing people to interact with data through natural language.

The following infographic summarizes five stages in which AI can support the application of the framework, while keeping validation and final decisions in human hands.

🧭 1. Define the North Star

During workshops, generative AI can serve as a supporting tool to organize ideas and broaden participants' perspectives.

For example, we can provide it with information about the product, interviews, surveys, user feedback, and internal documentation to identify recurring themes, compare opinions, and detect potential contradictions.

It can also help us transform workshop ideas into metric proposals and evaluate them using the framework's criteria.

What makes this interesting is not having AI choose our North Star, but using it to help us ask better questions and explore alternatives we may not have considered.

🔬 2. Validate the Metric and Identify Its Inputs

Once we have defined the candidate metrics, we need to verify whether they represent the value we want to create and whether we can measure them reliably.

Generative AI can help us review definitions, identify ambiguities, and translate business questions into SQL queries that must subsequently undergo technical validation.

We can also complement this work with machine learning techniques to explore relationships between variables, identify patterns, and estimate which indicators are most strongly associated with changes in our North Star.

However, finding a correlation does not mean proving causation. The relationships identified need to be tested through appropriate analysis and, when relevant, experimentation.

🗣️ 3. Explain Results to Different Teams

One of the challenges of working with metrics is ensuring that people with different responsibilities and levels of technical knowledge can understand and interpret them.

Here, generative AI can help transform complex analyses into explanations tailored to each audience, connecting changes in the North Star with input metrics and contextual indicators.

It also allows people to explore data by asking questions in natural language, without requiring everyone to know how to write SQL queries.

The goal is not for every team to analyze the same indicators, but for them to understand how their metrics relate to the product's results.

📡 4. Monitor and Understand Changes

Once the metrics have been implemented, we need to track their evolution and understand what happens when results change.

We can use analytics tools to detect anomalies and combine their outputs with generative AI to prepare reports, summarize trends, and identify potential areas for investigation.

But there is one question I consider particularly important: are we observing a real change in user behavior or a problem with our data?

A sudden decline in activity may be caused by a change in the product, but it could also result from instrumentation errors, events that are no longer being recorded, or issues in data pipelines.

That is why monitoring should not be limited to business indicators. We also need to consider data quality and technical changes that may affect how results are interpreted.

AI can help us connect this information and suggest possible explanations, but these hypotheses must be verified before being presented as conclusions.

🔁 5. Review and Plan New Initiatives

Finally, the results of our analysis should help us decide what to do next.

Generative AI can support the formulation of hypotheses, the preparation of improvement proposals, the design of experiments, and the documentation of lessons learned.

It can also help us explore scenarios, such as analyzing what might happen if we improve retention or reduce difficulties during onboarding.

These estimates can be useful for prioritizing initiatives, provided they are based on appropriate models and subsequently compared with actual results.

AI Supports the Process, but Does Not Replace Decisions
There is one principle that applies across all these stages: AI does not replace product knowledge, data quality, or the judgment of teams.

If each department uses different definitions for the same metric, introducing AI will not automatically resolve that lack of agreement. It could even amplify inconsistencies and generate incorrect interpretations.

Similarly, optimizing an indicator without understanding what it represents may lead us to improve the numbers without creating more value for our users.

The true potential of combining AI with the North Star Framework lies in helping organizations connect data, knowledge, and decisions while maintaining a shared direction without losing sight of the value they want to create.

8. Conclusions: Beyond Metrics and Technology

Throughout this article, we have explored how the North Star Framework can help us establish a shared direction, connect product metrics with the value users receive, and transform different perspectives into more aligned decisions. However, while defining a good metric is an important step, it does not guarantee that an organization will work toward the same goal, especially when team priorities, incentives, and dynamics are not aligned.

8.1 When Individual Goals Do Not Guarantee Collective Success

Metrics allow us to evaluate results, but they can also influence how people work and make decisions. When a team's performance depends on certain indicators, it is natural for them to focus their efforts on improving those metrics, even if doing so does not always contribute directly to the overall objective.

To illustrate this, I want to revisit an example I once heard involving football, where a striker can be evaluated by the number of goals they score and a goalkeeper by the goals they prevent. Let's imagine three scenarios:

3 to 4: the striker scores three goals and achieves an excellent individual result, but the team loses.
0 to 0: the goalkeeper keeps a clean sheet and achieves their objective, but the team does not win.
2 to 1: the striker scores fewer goals and the goalkeeper concedes one, but the team wins.

If we look only at individual metrics, we might conclude that the striker performed better in the first scenario and the goalkeeper in the second. However, when we consider the collective result, the interpretation changes because, as a team, our goal is to win the match.

This does not mean that the striker's goals or the goalkeeper's saves are no longer relevant, but rather that we need to understand how they contribute to the shared objective. Something similar happens in organizations, where Marketing may achieve its acquisition targets, Product may improve feature adoption, and other departments may meet their own KPIs, without those improvements necessarily translating into a better user experience.

The challenge, therefore, is not to eliminate individual metrics, but to find a balance that allows us to evaluate each team's responsibilities without losing sight of the outcome we want to achieve as an organization.

8.2 People Are Also Part of the Equation

This reflection leads us to consider another dimension that is often left out of measurement models: the human and organizational context in which objectives are defined and results are interpreted.

Organizations are made up of people with different experiences, motivations, responsibilities, and ways of understanding success. That is why relationships between teams, trust, communication, and organizational culture also influence the decisions being made and how data is used.

Furthermore, when we talk about building a product, we usually think primarily of Product, Technology, or Marketing teams, but its success is also influenced by other departments, such as Human Resources, Administration, or those responsible for organizational management. Even if they are not directly involved in developing a feature, their decisions can influence working conditions, motivation, and the ability of those teams to collaborate.

For example, a performance evaluation system that rewards only the achievement of individual goals may end up encouraging behaviors that favor one department's results while making collaboration with other teams more difficult. In this context, metrics can become a way to demonstrate performance rather than helping us understand whether we are creating real value, bringing us back to the risk of vanity metrics.

That is why aligning metrics also means understanding the incentives and dynamics of the people who work with them. We can define a shared North Star, but if evaluation systems, priorities, or working conditions push teams in different directions, it will be difficult for that common objective to translate into consistent decisions and actions.

8.3 AI Can Help Us Think, but Not Decide for Us

This organizational complexity also brings a new opportunity: artificial intelligence, which can help us organize information, identify patterns, test hypotheses, and make data more accessible. However, its usefulness is not limited to analyzing metrics. It can also extend to the way we make decisions.

During the ideation stages, for example, generative AI can help us review participants' proposals, identify potential contradictions, or highlight perspectives that were not considered. This can be particularly useful when hierarchical differences, individual interests, or shared assumptions influence the conversation, as it allows us to introduce new questions and challenge some of the conclusions we reach.

Nevertheless, we must remember that AI can also reproduce biases present in the information it receives and that its interpretations are not necessarily correct. That is why its role should be to expand our capacity for analysis and reflection without replacing product knowledge, data quality, or human judgment.

Similarly, if each department uses different definitions for the same metric, introducing AI will not automatically resolve that lack of agreement and could even amplify inconsistencies. And if we focus solely on optimizing indicators without understanding what they represent, we may end up improving dashboard results without actually improving the experience of our users.

A Final Reflection

After exploring these concepts, I believe the greatest challenge is not necessarily finding the perfect metric, but building an organization capable of agreeing on what success means, identifying the factors that contribute to achieving it, and reviewing its decisions as the product, people, and their context evolve.

The North Star Framework can provide a structure to guide this process, and AI can help us analyze information and challenge our hypotheses, but neither of these tools replaces the need to build agreements, establish trust, and understand how different responsibilities contribute to a common purpose.

Because, ultimately, it is not just about aligning metrics, but about aligning people, decisions, and objectives around the value we want to create.

9. References

Amplitude. (s. f.). North Star Playbook: The guide to discovering your product’s North Star. https://amplitude.com/books/north-star/
Duolingo. (2023). The Duolingo Growth Model. https://blog.duolingo.com/growth-model-duolingo/
Koithra, J. (2025, March 6). Navigating product growth with the North Star Framework. Institute of Product Leadership. https://www.productleadership.com/blog/navigating-product-growth-with-north-star-framework/
Product Hackers. (s. f.). Hacking Growth con Sean Ellis [Episodio de pódcast]. https://producthackers.com/es/podcast/hacking-growth-sean-ellis/
Redacción Emprendedores. (2021, 26 de mayo). «North Star»: la métrica definitiva para medir el crecimiento bajo la metodología «growth hacking». Emprendedores. https://emprendedores.es/ayudas/empezartv-north-star-metrica-medir-crecimiento-growth-hacking/
Simborg, M. (2018, December 10). What is a North Star metric? Mixpanel. https://mixpanel.com/blog/north-star-metric/

When Talent Meets AI: What Happens to Learning, Experience and Early Careers?

Romina Elena Mendez Escobar — Mon, 21 Sep 2026 16:04:39 +0000

Introduction

Working with AI has something particular about it: we not only have to keep learning, we also have to learn how to unlearn. The speed at which technology is evolving means that accumulating knowledge is no longer enough. We also need the adaptability to question what we know, let go of ways of working that no longer make sense, and learn again.

But there is one question I find increasingly difficult to ignore: Can we learn at the same pace as technology evolves?

AI needs good prompts that describe what we are trying to achieve, but it also requires something much harder to automate: knowing when to ask another question, what information is missing, which alternatives should be compared, and how to evaluate the result. This can make experienced professionals even more productive because their existing knowledge allows them to get more value from these tools.

And this is where a paradox emerges: if we want experienced professionals tomorrow, someone has to hire and develop the juniors of today. At the same time, we constantly talk about reskilling and upskilling as responses to the future of work, yet it is still not entirely clear who should be responsible for making that transition possible.

Reskilling means developing a new set of skills to move into a different role or career.
Upskilling means developing new capabilities within the work we already do.

So, rather than trying to predict which jobs will disappear or which skills we will need tomorrow, I wanted to look at what is actually happening. Not the hype. Not the panic. The data.

That leads me to three questions:

What do the data actually tell us about the jobs AI is creating, changing and displacing?
If companies need new skills faster than ever, why might entry-level roles be particularly vulnerable?
Who should be responsible for preparing people for this transition: companies, governments, universities, or all of them?

What kind of impact can AI have on a role?

Before looking at what is happening to junior professionals, it is worth making one distinction: not every role exposed to AI will necessarily have the same future.

The first dimension comes from the AI Occupational Exposure Index (AIOE) [4], which measures the relationship between AI capabilities and the skills required across different occupations. Researchers at the International Monetary Fund (IMF) later introduced a complementarity dimension, helping distinguish between occupations where AI is more likely to enhance human work and those where it has greater potential to substitute for a significant share of tasks. PwC later incorporated both dimensions into its Global AI Jobs Barometer 2025 to analyse the potential effects of AI across occupations.

source:Source: Author’s adaptation based on PwC, The Fearless Future: 2025 Global AI Jobs Barometer.

PwC uses these two dimensions to distinguish between occupations with greater potential for augmentation and those with greater potential for automation.

In PwC’s analysis, an occupation is considered to have high AI exposure when its exposure index is above 0.5. From there, a complementarity score above 0.5 places the occupation in the augmented category, while a score below 0.5 places it in the automated category.

However, this matrix should not be interpreted as a definitive prediction about the future of a profession. It is a starting point for understanding how AI may affect a role, because technological exposure is not the only factor shaping what ultimately happens. For example:

Regulation may limit which tasks can be performed by AI.
Professional accountability may require certain decisions to remain in human hands.
Sector characteristics, professional norms and levels of autonomy can influence how AI is adopted.
The way an organization structures its processes can also significantly change the outcome.

As a result, two roles with a similar level of AI exposure may evolve in very different ways.

This is where the classification becomes particularly useful for thinking about talent. Instead of simply asking whether a role is “at risk” from AI, we can start asking which tasks are being automated, which are being augmented, and which increasingly depend on human knowledge, experience and judgement.

That distinction will be important for understanding what is happening to junior professionals.

2. The challenge facing junior professionals

If AI can significantly increase the productivity of an experienced professional, it is worth asking what happens to those who are still building that foundation. The technological transition is not affecting work evenly. Instead, it may be reshaping the threshold for entering the labour market.

Several recent sources point in this direction. In the Anthropic Economic Index survey, Cadences (June 2026), more than one third of respondents estimated that a more junior colleague had a greater than 60% chance of losing their job. A separate Anthropic analysis published in March 2026 also identified an approximately 14% slowdown in hiring among workers aged 22 to 25 in AI-exposed occupations following the launch of ChatGPT, without an equivalent slowdown among more experienced workers.

LinkedIn’s AI Labor Market Update from August 2026 points to a similar pattern. Entry-level hiring in AI-augmented occupations declined by between 3 and 10 percentage points more than overall hiring within those same occupations.

The contraction affected several areas:

🎨 Design and interface: hiring for UX Designer and UI Designer roles fell by between 34% and 49% year over year in the United States and India.
🔍 Analysis and management: entry-level hiring for Data Analyst roles fell by 27% in the United Kingdom, while hiring for Project Manager roles declined by 39% in France and 29% in Germany.
🛠️ Software development: entry-level Software Engineer roles fell by 32% in Germany, while Frontend Developer roles declined by 39% in India.

The pattern is also visible at a more local level. In Barcelona, the Digital Talent Overview 2026 shows that between 2023 and 2025, job postings for junior profiles fell by 26.93%, while demand increased for mid-level (+21.68%) and senior (+15.04%) profiles.

These figures do not prove that AI alone is responsible for the change, but they do suggest that entry-level workers are facing a different labour-market dynamic from more experienced professionals.

There is also another perspective that hiring data alone cannot capture.

From my experience working on software projects, I increasingly see the assumption that introducing AI automatically means accelerating implementation. And to some extent, that is true. We can generate code, build prototypes and automate certain tasks much faster.

But building software still requires much more than writing code: understanding requirements, designing the architecture, working with data, developing, deploying, testing, monitoring and maintaining the solution. Once AI is introduced, new requirements also emerge around evaluation, telemetry and observability to make sure the system behaves as expected.

AI can accelerate the construction of a solution, but it does not remove the need for engineering.

This creates another tension. If projects become shorter and teams are expected to deliver faster, it may become harder to integrate junior professionals precisely because a larger share of the remaining work requires autonomy, decision-making and contextual understanding from the outset.

At the same time, we are working with technologies that continue to evolve rapidly, meaning that everyone, including senior professionals, is still learning.

3. The experience paradox

The evidence above suggests that entry-level professionals may be facing increasing pressure. But the question does not end with hiring. If organisations increasingly value experience, autonomy and judgement, how are people supposed to develop those capabilities in the first place?

3.1. Does AI make us more productive, or does it change what productivity means?

The same sources discussed earlier also reveal another side of the story: AI is not only affecting who gets hired, but also how work is performed once someone is in the role.

The Digital Talent Overview 2026 helps illustrate this shift in the context of software development, where AI is already being used across several everyday tasks. Among the 372 software development and digital professionals surveyed in the Barcelona metropolitan area, 74.20% considered AI effective for generating documentation and 74.19% for explaining or understanding existing code.

Yet faster execution does not mean that the output can simply be accepted as it is. 87.80% of respondents said they always or almost always review AI-generated code before accepting or integrating it. In addition, 68.92% reported that these tools can produce code that appears correct at first glance but is not reliable, while 63.25% said that achieving high-quality results still requires substantial effort in prompting, correction and refinement.

These findings suggest that productivity gains do not eliminate the need for human judgement: AI can make certain tasks faster, but the output still needs to be understood, reviewed and validated.

The Anthropic Economic Index adds a broader perspective. Beyond the concerns about early-career employment discussed in the previous section, the Cadences survey also explored how active Claude users perceived AI to be changing their own work.

This reveals an important tension: AI can accelerate certain parts of the work, but that speed does not remove the need to understand, review and validate what it produces. In software development, generating code or documentation may take less time, but deciding whether a solution is correct, secure, maintainable and appropriate for a specific context still requires knowledge and judgement.

That ability to evaluate an output, identify potential issues, compare alternatives and understand their implications is precisely one of the capabilities that professional experience helps us develop.

3.2. What happens when the work that used to teach us starts to disappear?

For years, many professional careers followed a fairly natural progression. Junior professionals often started with relatively simple tasks such as implementing features, fixing bugs, writing documentation or working on well-defined problems. Over time, those tasks helped them understand systems, recognize patterns, learn why certain decisions had been made and gradually develop judgement.

AI is beginning to intervene precisely in some of those early layers of work. If a tool can generate code, explain a function, create documentation or solve a task that was previously assigned to a junior professional, we gain speed. But we also change one of the traditional ways in which that professional used to learn.

This connects with another pattern in the sources analysed: AI tends to absorb tasks based on knowledge that can be codified more easily, while capabilities such as judgement, negotiation, contextual understanding and evaluating alternatives depend much more heavily on experience.

The hiring patterns discussed earlier add another dimension to this challenge. If organisations increasingly seek professionals who can contribute greater autonomy and experience from the outset, they may also need to think more deliberately about how early-career professionals are given opportunities to develop those capabilities.

That does not mean every junior task will disappear, nor that the only way to become senior is to follow exactly the same career path as before.

But it does raise an important question: if some of the tasks we used to learn through are disappearing or changing, how do we build that experience now?

4. If work is changing, we also need to rethink how we learn

Today, terms such as reskilling and upskilling are often used almost automatically whenever we talk about the impact of AI on employment. But what they really mean, when they apply and how they should be implemented are questions that come up frequently in conversations with colleagues and teams.

We have courses, training programmes, mentoring and many other ways of learning. The challenge is not simply having access to them, but knowing how to combine and structure them, because people do not all start from the same place or learn in the same way. The key is to understand what each person needs to learn, what knowledge they already have, and how they can build new capabilities while the nature of work itself is changing.

Before thinking about specific techniques, it is useful to distinguish the type of development we are trying to achieve:

🌱 Upskilling. Developing new capabilities to improve or expand what we already do. For example, a lawyer using AI to analyse documents or prepare an initial contract review.
🔄 Reskilling. Developing the capabilities needed to move into a different role. For example, someone working in operations preparing to transition into a role related to data analysis or automation.
🔗 Cross-skilling. Building knowledge in an adjacent area that complements an existing profile. For example, a marketing professional learning the fundamentals of data analysis to better interpret campaigns and collaborate with technical teams.
⚠️ Deskilling. The movement can also happen in the opposite direction. If technology systematically takes over certain tasks, some capabilities may be practised less often and gradually weaken. For example, if we consistently leave the initial assessment of a problem to AI, we may lose some of the practice that previously helped us develop judgement.

The following image is not intended to be a closed academic taxonomy. It brings together professional development concepts, learning mechanisms, methodologies and practices that can be used to design different learning journeys. They do not all belong to the same category, nor do they need to be used independently. Many of them complement each other and can form part of the same learning process.

One simple way to read the image is to think about which aspect of learning each block addresses:

Alongside expertise [Who do you learn from?]: Learning alongside more experienced people through mentoring, coaching, shadowing or pair working.
Progressive challenge [How do you stretch?]: Gradually increasing difficulty, autonomy or responsibility through stretch assignments, scaffolding or deliberate practice.
Learning by doing [How do you build skill?]: Developing capabilities through projects, simulations and real-world situations.
Feedback & reflection [How do you improve?]: Using feedback and reflection to understand what works and what needs to change.
Learning in the flow of work [When does knowledge arrive?]: Accessing knowledge at the moment it is needed through microlearning, support resources or self-directed learning.
Social learning [Who helps learning spread?]: Sharing experiences and solutions through peer learning, communities of practice or interest groups.

The important point is that we do not need to choose just one of these approaches. Different learning mechanisms can be combined depending on the person, the knowledge they already have and the capabilities they need to develop.

In this context, deskilling introduces another dimension. Some tasks may be practised less often because they become partially or fully automated. That is not necessarily negative. It can free up time and reduce repetitive work. But it does change which capabilities we continue to exercise and which ones stop being part of everyday learning.

And this opens up a broader question: if people start from different experiences, knowledge and ways of learning, should we begin to think about more personalised learning pathways?

AI itself could play a dual role here: not only transforming the skills we need, but also helping us adapt content, pace, practice and support to each person.

Could AI also help us personalise the way we learn and develop new capabilities?

5. Redesigning early-career pathways in the age of AI

So far, we have looked at training, upskilling and the different ways people can learn within the flow of work. But there is a more structural question: what happens if the pathway through which someone enters a role, learns and builds experience is also changing?

The report Artificial Intelligence and the Future of Entry-Level Work, published by the World Economic Forum in collaboration with PwC in 2026, addresses precisely this challenge. Its starting point is that the impact of AI on entry-level roles will not depend only on what the technology can do, but also on the decisions we make about hiring, job design, talent development and education.

The report proposes four interconnected dimensions for thinking about those decisions: Job Access, Job Design, Talent Pipelines and Education System Alignment.

What I find particularly interesting about this framework is that it shifts the conversation from “which skills should we teach?” to a broader question: how do we build pathways that allow people to enter the workforce, learn, gain experience and progress professionally in an environment where AI can also perform part of the work?

n the image, I have summarised some of the concepts I consider most relevant within each dimension. They do not represent every recommendation in the report, but rather a selection of mechanisms that help illustrate how these pathways could evolve. [5]

5.1. Job Access: keeping the entry doors open

The challenge begins even before learning takes place: to build experience, people first need the opportunity to gain it.

Keeping entry points into the labour market open means deliberately considering how people access their first opportunities while AI changes entry-level roles and tasks. Some of the practices that can support this include:

🚪 Entry-level hiring. Embedding early-career hiring into workforce and talent planning, rather than allowing it to disappear as an unintended consequence of automation decisions.
⚙️ Work experience. Creating opportunities for people to gain practical experience and demonstrate their capabilities, particularly when “previous experience” itself becomes a barrier to entry.
🚧 Alternative pathways. Complementing traditional routes with internships, apprenticeships, placements and other mechanisms that provide different ways into the workforce.
🎓Access to AI tools. Providing access to AI tools and training so that the ability to experiment and develop these capabilities does not depend entirely on an individual’s personal resources.

Dropbox provides an interesting example of this approach. The company expanded its internship and new-graduate programmes by 25% and chose to reinvest part of the productivity gains associated with AI into higher-value work, while continuing to preserve entry routes for early-career talent.

5.2. Job Design: redesigning work so people can keep learning

Once someone gains their first opportunity, a second question emerges: what kind of work allows them to continue developing capabilities while AI takes on part of the workload?

Redesigning entry-level roles means deciding how work should be distributed between people and technology, and which experiences should be intentionally preserved because they remain important for developing judgement, autonomy and contextual understanding. Some of the practices that can support this include:

Human–AI collaboration. Designing tasks and workflows around what people contribute, what AI can take on and how both can work together effectively.
Automate vs retain. Deliberately deciding which tasks to automate and which to preserve because they remain important for developing professional judgement, domain knowledge or the ability to detect errors.
Judgement & decision-making. Shifting part of the work away from mechanical execution and towards interpreting results, evaluating alternatives and making decisions.
Learning by doing. Preserving opportunities to practise in real situations, particularly when AI begins to take over some of the tasks that traditionally helped people learn.

Hitachi provides a clear example of this approach. The company automates repetitive and transactional work, while intentionally preserving experiences that help build judgement, critical thinking and business understanding. In engineering, for example, early-career professionals continue to develop programming fundamentals before relying heavily on AI-generated code, so that they can validate and challenge what the technology produces.

5.3. Talent Pipelines: building new forms of progression

If entry-level roles are changing, and the tasks within them are changing as well, another challenge emerges: how do we build the experience people need to continue progressing professionally?

Rethinking talent pipelines means moving away from the assumption that development happens only through a traditional hierarchical sequence and considering more flexible pathways based on capabilities, exposure and mobility. Some of the practices that can support this include:

Capability-based progression. Making progression depend more on demonstrated capabilities and impact, rather than only on tenure or job title.
Non-linear movement. Allowing development to happen through movement across projects, functions or domains, rather than only by climbing a vertical career ladder.
Cross-functional exposure. Exposing people to different teams, problems and contexts to broaden their understanding of the business and develop complementary capabilities.
Mentoring & mobility. Combining support from more experienced professionals with internal mobility opportunities that allow people to build knowledge across different contexts.

Dentsu Japan shows one way of making this type of progression visible. The organisation created four internal levels of AI capability development, AI Basic, AI Facilitator, AI Master and Chief AI Master, to recognise progression beyond job title alone.

The report also highlights Allianz, which uses intergenerational mentoring tandems to combine the digital fluency of younger professionals with the experience, business context and professional judgement of more senior colleagues.

5.4. Education Alignment: bringing education closer to real work

The final dimension extends the challenge beyond organisations. If the capabilities required by the labour market are changing faster, education and training also need to remain connected to the evolving nature of work.

Aligning education with the labour market means creating more continuous mechanisms of collaboration between education providers, employers and other actors in the ecosystem to reduce the distance between what people learn and what they eventually need to apply. Some of the practices that can support this include:

Work-integrated learning. Embedding projects, practical experience and real-world problems into education so that learning is not separated from application.
Employer partnerships. Building more continuous relationships between employers and education providers to share how roles, technologies and capability requirements are evolving.
Co-designed curricula. Designing parts of educational programmes with input from employers and industry specialists to reduce the gap between education and work.
Skills frameworks. Using shared frameworks to describe required capabilities and provide employers, educators and individuals with a common language.

Singapore provides a particularly interesting example of this approach. Its ecosystem combines labour-market data, National Skills Frameworks and skills-based job matching tools to connect employers, education providers and individuals.

The report also highlights examples such as Merck, which works with universities to define required capabilities and connect educational programmes with hiring opportunities, and Guanghua School of Management, which has incorporated AI, applied projects, internships and employer collaboration into its educational model.

6. Conclusions: if work is changing, the way we build experience needs to change too

After looking at how AI is affecting roles, entry-level positions and traditional ways of learning in different ways, one idea runs through the entire article: the transformation is not happening only in the tasks we perform, but also in the way we build the experience needed to perform them well.

🔄 Are we changing what it means to be junior or senior?

For a long time, many career paths followed a relatively predictable logic. Junior professionals started with more limited and repetitive tasks that allowed them to practise, make mistakes and gradually understand a system, while more experienced professionals took on decision-making, coordination and supervision.

AI is beginning to change that distribution. Some of the coding, documentation, initial analysis and information gathering that used to form part of the learning ground can now be completed much faster. At the same time, approaches such as vibe coding make it possible to build solutions at a speed that would have been difficult to imagine only a few years ago. Yet they still require us to understand what we are trying to build, provide the right context, review the output and recognise when something that looks correct actually is not.

This creates an interesting paradox: experienced professionals may begin performing tasks directly again that they previously delegated, while people at the beginning of their careers may encounter supervision and validation tasks earlier, even though they are still developing the judgement required to perform them well.

The traditional boundaries between what we consider a junior role and a senior role therefore begin to look less clear. If we automate part of the work through which experience was traditionally acquired, we will need to find new ways to build that experience.

🧠 Does learning also mean unlearning?

Years ago, a manager I worked with used to say that one of the biggest challenges technology creates for experienced professionals is learning how to unlearn. Over time, that idea has become increasingly relevant to me.

Experience remains valuable, but not because it allows us to repeat indefinitely what we already know how to do. Its value also lies in recognising which knowledge remains useful, which practices need to change and when a way of working needs to be reconsidered.

People at the beginning of their careers face a different situation. They are often building their foundational knowledge at the same time as these new tools become part of the normal way of working. That does not mean one group is better prepared than the other. Their starting points and learning needs are different.

In this context, deskilling also becomes increasingly relevant. Automating a task can free up time, reduce repetitive work and allow people to focus on higher-value problems. At the same time, however, it can mean that certain capabilities are practised less often. The question should not necessarily be how to avoid that process altogether, but rather which capabilities we can afford to practise less and which ones we need to preserve because they will remain essential for supervision, questioning and decision-making.

🎯 Will we all continue learning in the same way?

These different starting points also challenge a fairly common practice: designing large-scale training programmes that are essentially the same for everyone.

From my experience as both a professional and an educator, it is becoming increasingly clear that different groups have different needs, even when they work within the same organisation. Their prior knowledge differs, their experience differs, the problems they solve differ, and so does the way they develop new capabilities.

AI could play a particularly interesting role here. The same technology that is accelerating the need to learn can also help us personalise content, exercises, pace, feedback and support according to what each person already knows and what they still need to develop.

Bill Gates has highlighted this potential when discussing systems capable of understanding a person’s interests and learning style, measuring their comprehension, and adapting content and feedback accordingly. The opportunity is not simply to digitise the training we already have, but to begin thinking about much more personalised learning pathways.

🌍 What if AI could also expand opportunity?

After discussing automation, junior roles, deskilling and changing career pathways, it would be easy to end this analysis by focusing only on the risks. Yet the same technology creating these tensions can also expand what is possible.

Yann LeCun captured this perspective in a simple phrase: “AI will amplify human intelligence.” The idea matters because it shifts the conversation away from replacement and towards the expansion of human capabilities.

That potential may be especially significant in areas where resources remain scarce. Education and healthcare are two clear examples. Bill Gates has argued that AI can play an important role in sectors where there is a major shortage of professionals, helping expand access to support, knowledge and learning opportunities that are not currently available equally to everyone.

This does not remove the challenges explored throughout the article, but it allows us to close the discussion from a different perspective. We have seen that not every job will be affected in the same way, that junior positions are facing particular pressures, that experience remains important for providing context and judgement, and that some of the tasks traditionally used to build that experience are changing.

That is why responding with more courses, upskilling or reskilling may not be enough. We may also need to rethink how people learn through work, how roles are designed, how career pathways are built and how education and the labour market remain connected.

AI can transform roles, accelerate work and expand our ability to learn. It can also force us to question structures that we have taken for granted for decades.

Technology can expand our possibilities... The question is how we choose to use them.

References

[1] Digital Applied Team. (2026, July 1). AI won’t take your job, but it will reshape it. Digital Applied. https://www.digitalapplied.com/blog/anthropic-economic-index-jobs-change-not-vanish-2026
[2] World Economic Forum. (2025, January 7). Future of Jobs Report 2025: 78 million new job opportunities by 2030 but urgent upskilling needed to prepare workforces. https://www.weforum.org/press/2025/01/future-of-jobs-report-2025-78-million-new-job-opportunities-by-2030-but-urgent-upskilling-needed-to-prepare-workforces/
[3] LinkedIn Economic Graph. (2026, August). AI Labor Market Update: August 2026. LinkedIn. https://economicgraph.linkedin.com/workforce-data/publications
[4] PwC. (2025). The fearless future: Global AI Jobs Barometer 2025: Methodology appendix. https://www.pwc.com/gx/en/issues/artificial-intelligence/job-barometer/2025/methodology-report.pdf
[5] World Economic Forum. (2026, June 22). Artificial intelligence and the future of entry-level work: A framework for safeguarding and reinventing early career pathways. In collaboration with PwC. https://www.weforum.org/publications/artificial-intelligence-and-the-future-of-entry-level-work-a-framework-for-safeguarding-and-reinventing-early-career-pathways/
[6] United Nations Security Council. (2024, December 19). Security Council, seventy-ninth year: 9821st meeting, Thursday, 19 December 2024, New York (S/PV.9821). United Nations. https://digitallibrary.un.org/record/4070651
[7] Gates, B. (2023, March 21). The age of AI has begun. Gates Notes. https://www.gatesnotes.com/the-age-of-ai-has-begun
[8] Mobile World Capital Barcelona. (2026, May 27). Digital Talent Overview 2026. https://mobileworldcapital.com/en/trends/digital-talent-overview-2026/

When Fashion Meets AI: What Happens to Creativity, Business and Authenticity?

Romina Elena Mendez Escobar — Mon, 31 Aug 2026 10:50:10 +0000

Introduction

Some time ago, I completed the INSIDE LVMH certification, a program focused on the luxury industry that gave me the opportunity to learn how some of the group’s leading brands, such as Louis Vuitton, Dior and Fendi, operate. It was my first deep dive into everything that happens behind a brand: creativity, technology, production, supply chain, marketing and customer experience.

AI-generated illustration created with Google Gemini

Since then, I’ve become especially interested in how the fashion industry is integrating AI into these processes and what impact it could have on an industry where creativity, technology and business are so closely interconnected.

Some of the questions that inspired me were:

What happens when an industry built around creativity, people and trends starts using AI?
Is AI simply a tool to accelerate production processes, or will it also change what we value about fashion?
If fashion has already been questioned for decades over the beauty standards portrayed in its campaigns, what happens when those models can be entirely created or modified using AI?

1. AI is changing the fashion business

The impact of AI on fashion goes far beyond virtual runways, image generation or automated advertising campaigns. Its real impact begins much earlier, transforming the supply chain and even the way products themselves are conceived.

Today, the most agile brands use data analytics, machine learning and AI to capture trends in real time, anticipate consumer demand, optimize inventory and accelerate the creation of visual content.

This phenomenon reaches its clearest expression in the ultra-fast fashion model. An analysis by researchers from Stanford Graduate School of Business [1] shows that the real advantage of giants such as Shein and Temu does not lie in producing or shipping garments faster than traditional brands such as Zara. Instead, their advantage comes from designing at an exceptionally fast pace.

Their competitive edge lies in design speed. These companies use data analytics and machine learning models to track trends across the internet and social media, and then use AI to rapidly generate thousands of designs ready to be tested in the market.

This efficiency enables them to adopt a volume-based strategy: rather than betting on a small number of carefully selected collections, they launch a massive range of options and let the market itself determine what works.

2. From the design to the campaign: AI becomes the fashion studio

So far, we have seen how artificial intelligence can help brands detect trends, anticipate demand and accelerate the design of new products, but its impact does not end there.

AI is also beginning to change how those products are presented, communicated and brought to consumers. In other words, the transformation is not limited to the supply chain or the design process: AI is also entering the creative studio.

One interesting example is Zalando, which is using generative AI to transform its content production process through digital twins. According to the company, the time required to produce certain images has fallen from 6–8 weeks to just 3–4 days, while production costs for those images have been reduced by approximately 90%. [2]

AI-generated illustration created with Google Gemini

In this case, Zalando uses the term digital twins to refer to virtual representations of real models that make it possible to create new scenarios, compositions and images without having to physically repeat each production.

As someone who works in technology, there is something about this transformation that feels especially familiar to me. In software projects, we constantly think about three variables: scope, time and cost. When a technology significantly changes one of them, it usually ends up changing the way we design and execute the entire project as well.

If producing a campaign no longer takes weeks but only a few days, a brand can do more than simply reduce costs. It can experiment with more ideas, test different versions, adapt the same campaign to different markets and react much faster to a trend.

AI, therefore, does not just reduce costs: it changes the speed at which a brand can create and make creative decisions.

A traditional fashion production brings together many different professionals: photographers, producers, makeup artists, hairstylists, stylists, models and other creative roles. If part of that process can be generated, adapted or repeated digitally, some tasks may be reduced, others transformed, and new roles are likely to emerge.

The question, then, is no longer simply how much a brand can save by using AI.

If AI reduces the time and cost of producing fashion content, what will change first: the way brands create, the way professionals work, or the way we consume?

3. When the image looks real, what are we actually seeing?

We have already seen how AI can accelerate design and content production. But there is another, less visible consequence: it is becoming increasingly difficult to tell how much of a fashion image comes from a real production and how much has been created or modified digitally.

A campaign may start with a real model and use a digital twin, combine real photographs with AI-generated elements or, in some cases, feature a completely artificial person.

AI-generated illustration created with Google Gemini

This does not necessarily mean that the campaign is misleading. For a brand, it may simply be a new creative tool that makes it possible to produce content faster, test different ideas or adapt a campaign to different markets.

But it raises a new question for those of us looking at these images:

Do we need to know when a fashion image has been created or modified using AI?

This question has already reached the regulatory sphere with the EU AI Act, which establishes transparency obligations for certain types of AI-generated or manipulated content, including content that may be considered deepfakes. Since August 2, 2026, these obligations have started to apply, introducing new rules on how users should be informed when they interact with certain AI-generated or manipulated content. [4]

The debate also extends to the industry itself. EuroCommerce, which represents major retail companies including H&M, Inditex and Zalando, has argued that certain AI-generated advertising images should not automatically be treated as deepfakes when they are used to showcase products and are not intended to mislead consumers. [4]

I find this discussion particularly interesting because neither side of the debate has to be seen as simply black or white.

For consumers, knowing when an image has been generated or modified using AI can provide greater transparency and allow them to decide what kind of content they want to engage with.

For companies, indiscriminately labelling any AI-generated content as a deepfake may not accurately reflect the purpose of an advertising image and could create confusion between the authenticity of the product being promoted and the way that product has been visually represented.

In fashion ecommerce, one of the most fundamental expectations is that what appears on screen should correspond to the product that eventually arrives at home. Fashion photography has always relied on lighting, editing and retouching to construct a particular representation of a garment, but AI can take this much further, modifying not only the environment or the person, but also specific visual attributes of the product itself.

This raises an increasingly relevant question:

To what extent does an AI-generated or AI-modified image remain a faithful representation of what we are actually buying?

4. Before AI, fashion was already editing images

Long before generative AI entered the conversation, the fashion industry was already debating how some campaign images were digitally altered, raising questions around visual representation, authenticity and beauty standards that had existed for years.

From advertisements considered inappropriate for portraying extremely thin models to photographs in which the subjects themselves questioned how their appearance had been changed, these cases show that debates around visual representation, authenticity and beauty standards have been present in the industry for years.

Some particularly relevant examples include:

Gucci, 2016: The Advertising Standards Authority (ASA) banned an image from Gucci’s Cruise 2016 campaign following a complaint. The regulator considered that the model appeared “unhealthily thin,” noting, among other things, that the pose elongated her torso and visually emphasized a very small waist. Gucci argued that the model had a slim, but not unhealthy, physique. The advertisement could not appear again in that form. [5]
Dior, 2012: The ASA banned a Dior advertisement featuring Natalie Portman for a mascara product because the digital retouching of her eyelashes could exaggerate the results the product was able to achieve. Dior acknowledged that the eyelashes had been digitally altered, while the ASA found that there was insufficient evidence to demonstrate that the effect shown was achievable with the product. [6]
Zendaya, 2015: Zendaya publicly criticized Modeliste Magazine for digitally altering her body, making her hips and legs appear slimmer. The magazine ultimately withdrew the issue and later published the unretouched photographs. [7]
Lupita Nyong’o, 2017: Lupita Nyong’o publicly criticized Grazia after the magazine altered her cover photograph by removing her natural hair. She explained that she wanted her appearance to reflect her identity and questioned the idea that her natural hair had to be changed to fit certain editorial standards. [8]

These cases show that digital manipulation in fashion imagery did not begin with AI, and that questions around representation, expectations and authenticity were already part of the conversation. The difference is that generative tools significantly expand what can be altered or created. It is no longer only about modifying an existing image, but about generating the person, the setting or even the entire campaign from scratch.

5. Opening the AI Toolbox: From the Fashion Lifecycle to the Technologies Behind It

We have already explored some of the most visible effects of artificial intelligence in fashion: brands reacting faster to trends, campaigns that can be produced in just a few days, digital models, and new questions around authenticity and representation.

But behind all these examples, the same word keeps appearing: AI.

Before looking further at its impact on the industry, it is worth opening that black box for a moment and understanding what technologies are involved, what they require as input, what they produce as output, and where they can create value within the fashion business.

5.1 Mapping AI across the fashion lifecycle

AI can be incorporated into almost every stage of a fashion product’s lifecycle, although not every technique is designed to solve the same type of problem.

The following map provides a simplified view of some of the key points where different AI capabilities can create value across the fashion product lifecycle.

In practice, this journey is not completely linear.

Each stage generates data, images, designs, digital assets or information about consumer behavior that can later become an input for another part of the process.

For example, a trend identified through market data can become a design concept. That concept can generate different visual proposals, evolve into a 3D asset, and eventually be used for prototyping, a campaign or ecommerce.

Consumer interactions with those products generate new data that can then feed into the next cycle.

For that reason, rather than thinking of AI as an isolated tool, it is more useful to look at how different capabilities can connect across the entire product lifecycle.

5.2 From the lifecycle to the AI techniques

Once we understand where AI can be applied, another question emerges:

What techniques make these applications possible?
There is no single technology behind “AI for fashion.” Depending on the objective, a solution may combine image generation and modification, computer vision, generative models, pose estimation, 3D reconstruction, simulation, data integration and other capabilities.

The following map focuses specifically on some of the techniques related to visual content generation and transformation, fashion-specific applications, 3D representation, and Digital Twins.

This technical perspective can be connected to the previous lifecycle through five broad groups of capabilities. For each one, we can ask three questions:

⚙️ Techniques: what technologies or methods are used?
🔄 Input → Output: what information does the system need, and what result does it produce?
🎯 Industry application: who could use it, at what stage of the lifecycle, and what problem can it help solve?

This distinction is important because the same technical capability can have very different applications depending on where it is incorporated within the process.

5.2.1 💭 Create Image: From ideas to visual concepts

At the creative stage, image generation can transform an idea, a description or a visual reference into a visual concept without requiring an immediate physical production.

This can be especially valuable during the early stages of the creative process, when many possibilities still exist and different directions need to be explored before decisions are made.

⚙️ Techniques: text-to-image and diffusion-based generative models, combined with visual references or other conditioning mechanisms.
🔄 Input → Output: text prompt and/or visual references → generated 2D image.
🎯 Industry application: designers, creative teams and marketing departments can use these capabilities during Concept, Design & Development, and Marketing & Content to explore moodboards, campaign compositions, scenarios, visual styles or early concepts.

One of its main values lies in the ability to explore and iterate through different alternatives quickly before investing time and resources in a full production.

It is not necessarily about replacing the final production, but about expanding the range of possibilities a team can explore during the early stages of the process.

5.2.2 ✨ Modify Image: Extending what already exists

Much of a brand’s visual content already exists before AI comes into play. Product photography, campaigns, ecommerce images and other visual assets can be reused, adapted or transformed for different products, markets, formats and channels.

This is where image modification techniques become especially relevant.

⚙️ Techniques: image-to-image, inpainting, outpainting, super-resolution and style transfer.
🔄 Input → Output: existing image + instructions, masks or visual references → modified or extended image.
🎯 Industry application: photographers, creative teams, ecommerce and marketing teams can use these techniques mainly in Marketing & Content and Ecommerce & Sales to adapt existing photographs, modify specific elements, remove objects, extend compositions, change visual characteristics or prepare content for different formats and markets.

The main opportunity lies in reusing existing assets and generating multiple variations without repeating the entire production process. This can reduce time and costs while also allowing the same production to be adapted to much more specific needs.

5.2.3. 👗 Fashion Applications: From digital content to consumer experiences

In fashion, some solutions go beyond a single technique and combine different AI and computer vision capabilities to address specific industry use cases.

⚙️ Techniques: Virtual try-on can combine image generation, garment warping, pose estimation and different conditioning mechanisms. Synthetic humans can use generative models and identity control techniques. Sketch-to-design and pattern generation can combine image generation with references and domain-specific constraints.
🔄 Input → Output: person + garment → composed image; prompt/reference/pose → synthetic person; sketch → realistic design; text/reference → textile pattern.
🎯 Industry application: designers, product teams, ecommerce teams and consumers can use these applications across different stages, especially in Design & Development, Marketing & Content, and Ecommerce & Sales.

Virtual try-on, for example, brings AI directly into the consumer experience: it allows users to visualize how a garment might look on a particular person before making a purchase. This can help improve the user experience and, depending on the implementation, reduce purchases that may later end in returns.

In addition, these systems can generate new data on how consumers interact with products: which garments they try on, which ones they reject and which products they ultimately purchase. This opens the possibility of connecting the digital experience with new insights for other stages of the lifecycle.

5.2.4. 🧊 3D Generation: Moving from images to product representations

3D generation introduces an important shift compared with the previous techniques: the output is no longer necessarily a 2D image, but a digital representation of the product that can be used from different perspectives and across different environments.

⚙️ Techniques: 3D asset generation, multi-view reconstruction and neural rendering techniques such as NeRFs or 3D Gaussian Splatting.
🔄 Input → Output: text, images or multiple views of a product → 3D model or representation, geometry and/or textures.
🎯 Industry application: designers, product development teams, ecommerce, AR/VR teams and others working with digital representation can use these assets during Design & Development, Prototyping, Ecommerce & Sales, and other stages.

The value of this type of representation lies in the fact that the same digital asset can be reused for different purposes.

Instead of creating a separate visual representation for each scenario, a 3D model can become a resource that supports different experiences and processes.

This becomes especially interesting when we look at the full product lifecycle: an asset created at one stage can continue to provide value long after it was originally generated.

5.2.5. 🔗 Digital Twin: Connecting the digital and physical product

Digital Twin introduces a different level of complexity because we are no longer talking only about generating a visual representation, but about connecting that representation to a physical object, system or process and to the data it produces.

⚙️ Techniques: 3D representations, simulation, data integration and IoT, computer vision and AI can be combined depending on the use case.
🔄 Input → Output: physical product or process + digital representation + operational data → connected digital representation that can be used for monitoring, simulation, analysis or decision-making.
🎯 Industry application: product development, production, supply chain and operations teams can use Digital Twins mainly in Prototyping, Production and other operational stages of the lifecycle.

In the context of fashion, a digital representation of a product can be used to prototype scenarios, visualize changes, simulate certain processes or connect information from the physical product with its digital representation.

The distinction from 3D generation is important: 3D generation can help create the digital representation, while a Digital Twin also incorporates a connection to the physical object or process and its data.

5.3. From individual techniques to a connected system

When we look at these capabilities together, AI stops looking like a collection of isolated tools and starts behaving like a technological layer that can connect different parts of the product lifecycle.

Outputs generated at one stage can become inputs for another, connecting design, prototyping, production, marketing, ecommerce and customer experience within the same ecosystem.

This perspective also changes how we evaluate the value of each technique. The value lies not only in what a model can generate, but in how that output can be reused, connected to other systems and transformed into a new input within the product lifecycle.

And this is precisely where technology architecture becomes just as important as the generative capability itself.

6. Not every fashion brand is embracing AI

After exploring all these possibilities, it may seem that adopting AI is an inevitable evolution for any fashion brand. But not every company is following the same strategy. In some cases, even deciding where not to use AI can become part of a brand’s positioning, as seen with Aerie, the American Eagle brand.

In 2014, the company launched its 100% Aerie Real commitment, stopping the digital retouching of people and their bodies in its imagery. In 2025, it extended this commitment to artificial intelligence, stating that it would not use AI to generate bodies or digitally alter the people featured in its campaigns.

AI-generated illustration created with Google Gemini

The decision, then, does not appear to be an isolated reaction to the arrival of AI, but rather a continuation of a brand strategy that has spent more than a decade linking its communication to real people and unretouched imagery.

The most interesting development came in March 2026, when Aerie turned this position into the creative concept for a new campaign featuring Pamela Anderson.

The ad begins with Anderson giving instructions to an AI system to generate models. She keeps refining the result: asking for the models to look happier, more natural and less expressionless. Eventually, she asks them to “feel real.”

At that point, the artificial scene disappears and we see a real Aerie studio, with Pamela Anderson and other people working on the campaign.

Anderson’s final line captures the idea:

“You can’t prompt this.”

Frame from Aerie’s 2026 campaign featuring Pamela Anderson. Source: Aerie.

What is interesting is that the campaign does not necessarily take an anti-AI position. The decision is more closely related to the brand’s positioning and to what it wants to communicate to its consumers.

If you want to watch the campaign: https://www.youtube.com/watch?v=kg9JqAQlX6E

Perhaps this is not so different from what has happened in other industries. When mass production makes something increasingly accessible and homogeneous, what is handcrafted or produced in a more traditional way can gain new value precisely because it is less scalable.

As AI makes it possible to generate campaigns, models and scenarios faster and at a lower cost, productions involving real people and creative teams may become not only a form of differentiation, but also a way to connect with consumers who value authenticity and human experience.

This leaves us with a question: could working with real people and creative teams become a way not only to differentiate a brand, but also to build a stronger connection with consumers who value authenticity and human experience?

7. Conclusion: So, what does AI really change in fashion?

After looking at these different cases, we can identify some of the main changes AI can bring to the fashion business:

⚡**Speed:v analyzing trends and large volumes of data to respond more quickly to market changes.
💰 Cost: reducing the time and resources needed to produce and adapt content, while also automating parts of these processes when appropriate and maintaining human validation where needed.
📈 Scale: creating and adapting content more easily across different products, markets and consumer segments.
🎯 Personalization: using data to deliver experiences, recommendations and content that are increasingly tailored to different audiences.
🎨 Creative experimentation: testing more ideas, variations and concepts without requiring a full production for every experiment.
⚠️ New risks: managing emerging challenges related to copyright, data provenance, authenticity, representation and transparency. The easier it becomes to generate content, the more important it is to understand what information is being used, where it comes from and how what ultimately reaches the consumer is represented.

🚧 AI can lower the barriers to fashion

These possibilities may also change who has access to them.

For emerging designers and brands, reducing production costs and timelines can create new opportunities to experiment, build a visual identity and reach new markets without needing the resources of a large company from the outset.

👤 AI can make personalization part of the brand experience

Self-Congruity theory, developed in the 1980s within consumer behavior research, suggests that people tend to be more attracted to brands and products they perceive as consistent with their own identity.

This becomes particularly interesting in fashion, where a garment does not only serve a functional purpose but can also become part of how a person wants to look, feel and express themselves.

AI can take this idea of personalization much further by using consumer data and preferences to adapt not only recommendations, but also the images, campaigns and ways in which a product is presented to different audiences.

In other words, the same brand could begin telling different stories about the same product depending on who is seeing it.

That raises an especially interesting question:

How far can the personalization of a brand experience go before the brand begins to lose the common identity behind it?

🔮 What does this mean for the future of fashion?

Perhaps this is one of the biggest changes AI will bring to fashion.

It is not only about producing faster, reducing costs or generating better images, but also about deciding how far we want to take personalization, automation and content generation without losing what makes a brand, a person or even a form of self-expression recognizable.

Technology can expand the possibilities of fashion… The question is how we choose to use them.

📚 References

[1] Blumberg, D. L. (2026, January 16). How AI and tariffs are transforming fast fashion. Stanford Report. https://news.stanford.edu/stories/2026/01/fast-fashion-us-tariffs-artificial-intelligence
[2] Reid, H. (2025, May 7). Zalando uses AI to speed up marketing campaigns, cut costs. Reuters. https://www.reuters.com/business/media-telecom/zalando-uses-ai-speed-up-marketing-campaigns-cut-costs-2025-05-07/
[3] H&M Group. (2026). Annual & sustainability report 2025. https://hmgroup.com/wp-content/uploads/2026/03/HM-Group-Annual-and-sustainability-report-2025.pdf
[4] Reid, H. (2026, June 19). AI-generated ads should be exempt from EU transparency rules, retail association says. Reuters. https://www.reuters.com/legal/litigation/ai-generated-ads-should-be-exempt-eu-transparency-rules-retail-association-says-2026-06-19/
[5] Sweney, M. (2016, April 6). Gucci ad banned over ‘unhealthily thin’ model. The Guardian. https://www.theguardian.com/media/2016/apr/06/gucci-ad-banned-unhealthily-thin-model-asa
[6] Advertising Standards Authority. (2025, August 18). Beauty and cosmetics: The use of production techniques. https://www.asa.org.uk/advice-online/cosmetics-the-use-of-production-techniques.html
[7] Gajanan, M. (2015, October 22). Zendaya calls out fashion magazine for retouched photos. The Guardian. https://www.theguardian.com/fashion/2015/oct/22/zendaya-retouched-photos-modeliste-magazine
[8] Wang, M. (2017, November 10). Lupita Nyong’o is the latest star to call out offensive retouching on Instagram. Vogue. https://www.vogue.com/article/lupita-nyongo-retouching-instagram
[9] Aerie. (n.d.). 100% Aerie Real. American Eagle. https://www.ae.com/intl/en/content/aerie/aerie-real
[10] Hammers, J. (2026, March 26). How Aerie is pushing back against AI content with Pamela Anderson. Marketing Dive. https://www.marketingdive.com/news/how-aerie-is-pushing-back-against-ai-content-with-pamela-anderson/815668/

From Apple Health Data to Clinical Storytelling: Building an AI-Powered Report with Python and Gemini

Romina Elena Mendez Escobar — Mon, 20 Jul 2026 09:55:58 +0000

Introduction

At recent technology conferences, one topic has caught my attention: every year, more health-focused devices, sensors, and applications appear. Smartwatches track heart rate, smart scales measure body data, glucose monitors record blood sugar levels, and apps help users track sleep or nutrition. Today, the amount of information we can collect about our own bodies is enormous.

This article was inspired by an everyday experience with my father, Herminio ❤️. Whenever he has a medical appointment, he opens the Apple Health app and shows the doctor the evolution of his heart rate, physical activity, sleep hours, and other recorded metrics.

While watching this, I kept asking myself the same question: are we really making the most of all this information?

Showing a chart during a medical appointment can be useful, but the data could provide much more value if it were automatically processed, summarized, and transformed into a structured health report.

For this reason in this project, I use Gemini to transform previously calculated metrics into a clear and organized summary. The LLM does not analyze all the raw records or perform the main calculations. The pipeline processes the data, calculates the indicators, and generates the visualizations, while the model acts as a support layer for building the report narrative.

The goal is not to create a medical application or replace professional judgment. Instead, the purpose is to build a prototype that shows how Apple Health exports, deterministic data processing, visualizations, and an LLM can be combined to generate automated reports.

This project was developed using simulated data from three patients, so the complete pipeline can be reproduced without using real clinical information.

✨ Why Gemini?

This project uses an LLM to transform previously processed metrics into a structured narrative that can be reviewed more easily by a healthcare professional.
I chose Gemini for practical reasons:

〰️ I was already familiar with its API, it integrates easily with Python, and Google AI Studio makes it simple to test and adjust prompts.
〰️ It also offers a good balance between speed, performance, and cost for text-generation tasks.
〰️ Its free tier also makes it easier to reproduce this MVP without initial costs.

In this case, I use a general-purpose model because all calculations are completed in Python before the data is sent to Gemini. The model only organizes the results into readable text.
For projects that need to analyze clinical documents or medical images directly, specialized models such as MedGemma could also be evaluated. MedGemma is a family of open Google models adapted for healthcare-related tasks. However, its implementation, evaluation, and validation are outside the scope of this tutorial.

2. HealthKit: The Framework Behind the Data

Although most users only interact with the Apple Health app, HealthKit is the framework behind it. Apple provides HealthKit so developers can securely access health information stored on the device.

HealthKit works as a central repository where the iPhone and Apple Watch store health and fitness data. With the user’s explicit permission, authorized applications can read and write information through a single API. This avoids the need for every app to maintain its own separate database.

HealthKit currently supports hundreds of data types across many areas of health and well-being. The following figure presents a simplified grouping of some of these categories to provide a clearer overview of the available information.

This taxonomy was created specifically for this article based on publicly available HealthKit documentation. It is not an official Apple classification and should be understood as a summarized, author-created interpretation for explanatory purposes.

Thanks to this architecture, HealthKit makes it possible to:

Collect and store health and fitness information.
Analyze and visualize how this data changes over time.
Share information between authorized applications, reducing duplication and enabling new user experiences.

One of the most interesting design decisions in HealthKit is its large catalog of predefined classes and data types for standardized health metrics.

At first, this may seem restrictive for developers. However, it is actually one of the platform’s main strengths because it ensures that all stored information follows a consistent data model. This means that heart rate, blood glucose, or body weight always represent the same type of information and use the same units, regardless of the device or application that created the record.

This standardization simplifies application development, improves interoperability between apps, and helps maintain consistency across the data stored in HealthKit.

2.1 Data Sources

One of HealthKit’s main benefits is its ability to bring data from multiple sources into a single repository.
The most common sources include:

iPhone: records steps, distance traveled, mobility data, and other indicators collected through its sensors.
Apple Watch: provides physiological metrics such as heart rate, electrocardiogram (ECG), blood oxygen saturation (SpO₂), body temperature, sleep data, workouts, and cardiorespiratory fitness (VO₂ Max).
Third-party apps: can add information related to nutrition, mental health, hydration, medication, menstrual cycles, or sports training.
Connected medical devices and wearables: HealthKit supports Bluetooth Low Energy (BLE) health devices and medical data profiles. It can also work with FHIR (Fast Healthcare Interoperability Resources), making it possible to integrate data from devices such as glucose meters and blood pressure monitors, as well as clinical records from authorized healthcare institutions.

3. HL7 / FHIR Compatibility

So far, we have mainly discussed data generated by devices and applications. However, in 2018 Apple expanded the Health app by introducing Health Records, a feature that allows users to import structured clinical information from supported healthcare institutions. That same year, Apple also opened access to these records for authorized applications through the HealthKit API.

Health Records is built on HL7 FHIR, which stands for Fast Healthcare Interoperability Resources. FHIR is a standard developed by HL7 International to represent and exchange health information electronically between hospitals, applications, and Electronic Health Record systems.

FHIR organizes information into modular resources such as Patient, Observation, Condition, Procedure, MedicationRequest, and Immunization. Each resource represents a specific piece of clinical information that can be connected, queried, and exchanged between systems. Although FHIR can also be used to build clinical documents, its architecture does not require the entire patient record to be handled as one large document.

When records are downloaded from a supported institution, HealthKit represents each one as an HKClinicalRecord object, which keeps the original FHIR resource. Authorized applications can request the clinical record types they need and process their content as FHIR JSON. However, these records are read-only, which means applications cannot create new HKClinicalRecord objects or modify existing ones.

Access to any HealthKit information requires user consent, but clinical records have additional requirements because of their sensitivity. An application must enable the Clinical Health Records capability, include the required entitlement, explain why the information is needed, and request permission for each record type it wants to access. The use of this capability is also subject to Apple’s review process.

In HealthKit, clinical records are represented as read-only HKClinicalRecord objects that preserve the original FHIR content. Access requires explicit user authorization and is subject to additional privacy and platform requirements.

This architecture makes it possible to bring together information from different sources while keeping access centered on user consent and privacy.

4. HealthKit: Clinical Use Cases

The availability of large volumes of physiological data, combined with interoperability standards such as FHIR, has created many opportunities for research and clinical applications.

The value of this data does not come only from individual measurements, but from how they are analyzed over time. Tracking changes in heart rate, sleep, mobility, or activity levels can help identify patterns, summarize relevant information, and support patient monitoring in different healthcare scenarios.

The following figure presents some representative use cases, including early anomaly detection, remote patient monitoring, clinical summary generation, and synthetic data generation for research.

5. Technical, Clinical, and Regulatory Considerations

Before running the tutorial or using the code presented in this article, it is important to understand its scope and consider several limitations related to privacy, data quality, and the use of artificial intelligence in healthcare contexts.

5.1 Privacy and Data Protection

Health information is one of the most sensitive categories of personal data. Depending on the country and the context of use, it may be subject to regulations such as HIPAA in the United States or GDPR in the European Union.

Although this article uses only simulated data, any implementation that processes real information should include suitable controls for:

User consent.
Access management.
Data minimization.
Anonymization or pseudonymization.
Encryption.
Secure storage and processing.

5.2 Consumer Data Is Not a Diagnosis

Measurements collected through consumer devices can provide useful information for identifying trends and supporting long-term monitoring.
However, these records do not represent a medical diagnosis on their own and should not replace measurements taken with certified clinical equipment.

5.3 Data Quality and Continuity

The quality of the measurements can be affected by factors such as incorrect device placement, low battery levels, synchronization failures, periods when the device is not used, or differences between sensors and applications.
These situations may produce:

Incomplete records.
Duplicate measurements.
Outliers.
Periods with missing information.
Differences in units or sampling frequency.

For this reason, the data should be validated, cleaned, and normalized before generating any analysis. It is also important to identify periods where the available information is not complete enough to support reliable conclusions.

5.4 Use and Limitations of the LLM

In this project, the large language model does not diagnose conditions or recommend treatments. Its role is to transform previously calculated metrics into a clear and structured summary that can be reviewed more easily by a healthcare professional.

Any generated output should be treated as a draft that requires human review. The model may omit information, misunderstand a result, or produce statements that are not fully supported by the input data.

5.2 Scope of the Code

The repository provided with this article should be understood as an educational and experimental MVP. It is designed to demonstrate the general processing flow using simulated data.

It is not a medical product, a diagnostic tool, or an implementation ready for direct use in a clinical environment.
Before adapting the code to a real use case, additional validation would be required in areas such as:

Security and access control.
Error handling and traceability.
Data quality and provenance.
Reproducibility of the results.
Evaluation of the model’s responses.
Compliance with applicable standards and regulations.
Review and approval by qualified professionals.

The goal of this project is to present one possible architecture and explore its main components, not to provide a production-ready clinical solution.

6. Building the Apple Health Reporting Pipeline

In this tutorial, we will build a Python pipeline that processes an Apple Health XML export and generates a structured PDF report.
The pipeline will:

read and normalize the exported health records;
calculate mobility, cardiovascular, and sleep metrics;
compare the results against configurable reference values;
generate charts;
use Gemini to create a structured narrative;
combine everything into a final PDF report.

The generated report contains four main sections:

🚶 Mobility: daily steps, walking speed, steadiness, gait metrics, and caloric expenditure.
❤️ Cardiovascular: resting heart rate, HRV, oxygen saturation, VO₂ Max, and recovery metrics.
😴 Sleep: average sleep duration and nights above or below the configured references.
🤖 AI-generated summary: a structured narrative with patient profile, mobility, cardiovascular, sleep, and overall assessment sections.

The following diagram shows the complete flow of the project:

The implementation follows a modular architecture in which each class is responsible for one stage of the pipeline:

📥 HealthDataReader reads and processes the Apple Health export.
📊 HealthChartBuilder generates the visualizations.
✨ HealthSummaryGenerator creates the narrative using Gemini.
📄 HealthReportPDF combines the metrics, charts, and generated text into the final report.

In the next sections, we will review each stage separately. To keep the article focused, I will only include the most relevant code fragments and design decisions. The complete implementation, configuration files, prompt template, and simulated data are available in the project repository.

6.1 Prerequisites

To follow the tutorial, you will need:

The project repository cloned locally.
An Apple Health XML export or one of the simulated files included in the repository.
A Gemini API key created from Google AI Studio.
The Python dependencies installed from the project requirements.txt file.

You can clone the repository and install the dependencies with:

RominaElenaMendezEscobar / apple-health-data

Python pipeline that processes Apple Health XML exports, calculates health metrics, generates visualizations, creates a structured narrative with Gemini, and builds a final PDF report using simulated patient data.

From Apple Health Data to Clinical Storytelling: Building an AI-Powered Report with Python and Gemini

Apple Health Reporting Pipeline with Python and Gemini

A modular Python pipeline that processes Apple Health XML exports, calculates health metrics, generates visualizations, creates an AI-assisted narrative with Gemini, and builds a structured PDF report.

This repository is an educational MVP built with simulated data. It is not a medical device, diagnostic tool, or production-ready clinical solution.

Overview

The pipeline:

Reads and normalizes Apple Health XML records.
Calculates mobility, cardiovascular, and sleep metrics.
Compares results with configurable reference values.
Generates charts with Matplotlib.
Creates a structured narrative with Gemini.
Combines metrics, charts, and text into a PDF report.

HealthKit: The Framework Behind the Data

HealthKit is Apple’s framework for storing and sharing health and fitness information collected by the iPhone, Apple Watch, third-party apps, and compatible devices.

It provides standardized data types for metrics such…

View on GitHub

✨Gemini API key
You can create an API key from Google AI Studio.
After creating it, add a .env file at the root of the project:

gemini_api_key=YOUR_CREDENTIAL

6.2 Data source

Apple Health allows users to export their information as a ZIP file containing an XML document.

The export can be generated from the Health app:

Open the Health app on the iPhone.
Tap the profile icon.
Select Export All Health Data.
Confirm the export.
Extract the generated ZIP file.

The tutorial uses the export.xml structure produced by this process. However, to avoid exposing real health information, the repository includes three simulated patient files:

alex_28m.xml: 28-year-old male patient.
carlos_68m.xml: 68-year-old male patient.
maria_61f.xml: 61-year-old female patient. These files are stored in the patients/ folder and allow the complete pipeline to be reproduced without using real clinical data.

6.3 Orchestrating the Pipeline

The complete project is coordinated from the main.py file, which works as the application entry point. Its responsibility is not to process the data directly, but to create the specialized classes and execute each stage of the pipeline in the correct order.

This file also defines the list of patients to be processed. For each patient, it includes the XML file path and the name that will appear in the final report. The files are declared explicitly to make the example easier to follow, although a more general implementation could discover them automatically from a folder.

The complete main.py file is shown below:

from healthChartBuilder import HealthChartBuilder
from healthDataReader import HealthDataReader
from healthReportPDF import HealthReportPDF
from healthSummaryGenerator import HealthSummaryGenerator
import utils
import os

if __name__ == "__main__":
   patients = [
       ("patients/alex_28m.xml",   "Alex Torres"),
       ("patients/maria_61f.xml",  "María González"),
       ("patients/carlos_68m.xml", "Carlos Mendez"),
   ]

   os.makedirs("reports", exist_ok=True)
   os.makedirs("charts",  exist_ok=True)
   os.makedirs("data",    exist_ok=True)

   env = utils.read_env()

   for xml_path, name in patients:
       print(f"\n── {name} ──")
       prefix = name.lower().replace(' ', '_')

       # Step 1: read and compute
       reader = HealthDataReader(xml_path).load()

       # Step 1.1: save the compact LLM-friendly summary for this patient
       reader.save(write_llm_summary=True, file_name=prefix)

       # Step 2: generate charts
       builder = HealthChartBuilder(
           metrics    = reader.metrics,
           output_dir = "charts",
           prefix     = prefix,
       )
       charts = builder.build_all()

       # Step: generate the narrative summary with Gemini
       generator = HealthSummaryGenerator(
           json_path   = f"data/{prefix}_llm_summary.json",
           yml_path    = "config/params_health.yml",
           prompt_path = "prompt/prompt_summary.txt",
           api_key     = env["gemini_api_key"],
       ).load()
       llm_text = generator.generate()

       # Step 3: build PDF
       HealthReportPDF(
           metrics        = reader.metrics,
           charts         = charts,
           patient_name   = name,
           date_of_birth  = reader.date_of_birth,
           biological_sex = reader.biological_sex,
           start_date     = reader.df['start'].min(),
           end_date       = reader.df['start'].max(),
           out_path       = f"reports/{prefix}_report.pdf",
           llm_summary    = llm_text,
       ).build()

6.4 Reading and Processing the Apple Health Export

The HealthDataReader class reads the XML file exported from Apple Health and transforms it into a structure that can be analyzed with Python. During this process, it extracts the available records, normalizes dates and numeric values, limits the analysis to the configured period, and calculates the metrics used by the next stages of the pipeline.

The class receives the XML file path and, optionally, the number of months to include in the analysis:

reader = HealthDataReader( 
xml_path="patients/alex_28m.xml", months=6, 
).load()

The load() method runs two main operations:

📥 _parse_xml() reads the file, extracts the records, and transforms them into a Pandas DataFrame.
📐 _compute_metrics() calculates the daily series and aggregated indicators used in the analysis.

Threshold Configuration

The values used to classify or compare the metrics are not hardcoded inside the class. Instead, they are loaded from config/params_health.yml.

This separation makes it possible to update the reference values without changing the Python implementation:

threshold_steps_low:
  description: Step count threshold for red zone.
  value: 3000
threshold_steps_mid:
  description: Step count threshold for orange zone.
  value: 5000
threshold_steps_goal:
  description: Step count goal line.
  value: 7000
threshold_speed_low:
  description: Walking speed considered critically low.
  value: 3.5
threshold_speed_goal:
  description: Walking speed reference value.
  value: 4.5
threshold_steadiness:
  description: Steadiness warning value.
  value: 0.60
threshold_spo2_low:
  description: SpO2 critical threshold.
  value: 95.0
threshold_spo2:
  description: Minimum SpO2 reference value.
  value: 96.0
threshold_sleep_min:
  description: Sleep duration for red zone.
  value: 5.0
threshold_sleep_mid:
  description: Sleep duration for orange zone.
  value: 6.0
threshold_sleep_goal:
  description: Sleep duration goal.
  value: 7.0
threshold_hrv:
  description: Minimum HRV reference value.
  value: 25.0

These parameters affect several parts of the project. They are used, for example, to calculate how many days fall below a specific step count, identify periods of low walking speed, evaluate sleep duration, and define the reference zones later used in the charts and the final report.

⚠️ Note: The values included in the repository are only for demonstration and are intended to support the example with simulated data. They should not be treated as clinical criteria. Before adapting the code to a real use case, the thresholds should be reviewed and validated by healthcare professionals, considering the population, age group, clinical context, and specific purpose of the solution.

Metric Selection

The _compute_metrics() method defines which data types are processed and which indicators are calculated. In the current implementation, the metrics are mainly organized into three groups:

🚶 Mobility and activity: steps, walking speed, step length, steadiness, asymmetry, active energy, and flights climbed.
❤️ Cardiovascular: resting heart rate, HRV, oxygen saturation, respiratory rate, VO₂ Max, and heart rate recovery.
😴 Sleep: daily duration, average sleep, and the number of nights below or above the configured thresholds. The daily series are calculated using sums or averages, depending on the type of record:

steps = self._daily_sum("StepCount")
speed = self._daily_mean("WalkingSpeed")
hr = self._daily_mean("RestingHeartRate")
hrv = self._daily_mean("HeartRateVariabilitySDNN")
spo2 = self._daily_mean("OxygenSaturation")

⚠️ Note: The thresholds are not the only values that should be reviewed. It is also important to confirm that the statistical methods used by the class are appropriate for each metric. For example, the mean can be affected by outliers. Before using this approach in production, other measures such as the median or percentiles may need to be evaluated.

Preparing the Data for the LLM

In addition to the full set of metrics, the class generates a smaller JSON file through to_llm_summary().
Instead of sending the complete time series, Python creates a compact and deterministic representation that includes:

📊 mean and standard deviation;
↕️ minimum and maximum values;
📈 trend over the analysis period;
📅 best and worst weekly averages;
🔄 weekly variability;
⏱️ longest consecutive period below the configured threshold.

Not every metric includes all of these fields, because some calculations do not apply in the same way to every type of data. This decision has two main benefits:

1. Reducing the amount of data sent to the model. An Apple Health export may contain thousands of records. Sending all observations would increase the prompt size, token usage, and execution cost, while also adding repetitive information that may not improve the final summary.
2. Keeping the calculations in Python. Averages, trends, minimum and maximum values, weekly statistics, and threshold streaks are calculated in advance using deterministic code. The LLM receives fixed and verifiable values and is only responsible for turning them into a natural-language summary.

This separation also makes the project easier to maintain. If the trend calculation changes or a new metric is added, the update can be made in Python without changing the role of the language model.
For example, the model receives a structure like this:

{
  "steps": {
    "mean": 9498.53,
    "std": 1728.37,
    "min": 5667.0,
    "max": 14201.0,
    "trend": "stable",
    "worst_week_mean": 8214.29,
    "best_week_mean": 10672.71,
    "weekly_volatility": 576.09,
    "worst_streak_below_threshold": 0
  }
}

6.5 Generating Clinical Charts

The HealthChartBuilder class receives the metrics calculated by HealthDataReader and generates the charts that are later included in the final report.
To keep the presentation logic separate from the data-processing logic, the class uses two configuration files:

🎯 params_health.yml: defines the reference thresholds used for color zones and horizontal lines in each chart.
🎨 params_styles.yml: stores the color palette applied consistently across all visualizations.

Generated Charts

The build_all() method coordinates the chart-generation process and delegates each visualization to an independent private method:

🚶 Activity and mobility — _chart_steps(), _chart_mobility(), and _chart_calories(): daily steps with threshold-based color zones, walking speed with a reference line, and active versus basal calories.
❤️ Cardiovascular — _chart_hrv() and _chart_spo2(): heart rate variability with a minimum reference value, and oxygen saturation with critical, low, and normal zones.
😴 Sleep — _chart_sleep(): nightly sleep duration displayed with threshold-based color zones. If no sleep data is available, the chart shows an alternative message. Each chart is implemented independently, so it can be modified or replaced without affecting the rest of the pipeline.

6.6 Generating the Narrative with Gemini

The HealthSummaryGenerator class receives the summary created by HealthDataReader and uses Gemini to transform it into structured natural-language text. At this stage, the original Apple Health records are not sent to the model. Instead, Gemini receives the metrics that were already calculated and summarized in the previous step.
To build the prompt, the class uses three input files:

📊 json_path: contains the patient’s compact summary, including the previously calculated metrics and statistics.
🎯 yml_path: points to params_health.yml, which contains the thresholds used to compare each metric.
📝 prompt_path: contains the prompt template and the instructions the model must follow. The load() method reads these files and initializes the Gemini client:

self.datos = utils.read_json_file(self.json_path)
self.yml = utils.read_yml_file(self.yml_path)
self.prompt = utils.read_txt_file(self.prompt_path)
self.client = genai.Client(api_key=self.api_key)

Prompt Structure

The prompt template defines how the report should be generated. Instead of including the complete prompt in the article, its main instructions can be summarized as follows:

🧭 Patient context: calculates the patient’s age from the date of birth and considers biological sex and the analysis period.
📐 Threshold comparison: defines which value from params_health.yml should be used to evaluate each metric.
📑 Report structure: requires fixed sections for patient profile, mobility, cardiovascular data, sleep, and overall assessment.
🔎 Trends and continuity: asks the model to consider metric trends, weekly variability, and consecutive periods below the configured thresholds.
🚫 Restrictions: prevents the model from inventing data, using unavailable fields, or making general judgments about the patient’s health. It also avoids subjective terms such as “healthy” or “concerning.” The model should only report whether each value is above, within, or below its corresponding threshold.

This last point is especially important, because the model should describe the available values and their relationship to the configured thresholds without making a diagnosis or turning the summary into medical advice.

Building and Running the Prompt

The class separates prompt preparation from the model call:

_build_prompt()replaces the {datos} and {yml} placeholders with the actual JSON data and threshold configuration.
generate() sends the completed prompt to Gemini and returns the generated text.

prompt = self._build_prompt()

response = self.client.models.generate_content(
    model=self.model_id,
    contents=prompt,
    config=types.GenerateContentConfig(
        max_output_tokens=self.max_tokens,
        thinking_config=types.ThinkingConfig(
            thinking_budget=0
        ),
    ),
)

6.7 Generating the Final PDF Report

The HealthReportPDF class combines the results produced during the previous stages and creates the final PDF report using ReportLab.
The class receives four main inputs:

📊 Metrics and KPIs: obtained directly from the metrics dictionary generated by HealthDataReader. The class does not recalculate the main statistics. Instead, it organizes them into KPI cards, tables, alerts, and short descriptions.
📈 Charts: receives the image paths generated by HealthChartBuilder and adds each chart to the corresponding report section.
✨ Gemini summary: receives the narrative generated by HealthSummaryGenerator and includes it as a separate section.
🎯 Configuration: uses params_health.yml and params_styles.yml to apply the same thresholds and visual styles used across the rest of the pipeline.

This class does not calculate averages, trends, or weekly statistics. Those values are already produced by HealthDataReader. It only performs simple comparisons against the configured thresholds to decide whether a table should display a ✓ or ⚠ status and whether an alert should be added to the report.

Report Structure

The generated document is divided into four sections:

🚶 ① Mobility: KPIs for steps, walking speed, steadiness, gait asymmetry, and activity, together with the related charts and reference tables.
❤️ ② Cardiovascular: resting heart rate, HRV, SpO₂, VO₂ Max, and recovery metrics. This section is adapted when Apple Watch data is not available.
😴 ③ Sleep: average sleep duration, nights below the minimum threshold, and nights that meet the configured goal.
🤖 ④ AI-Generated Summary: the narrative generated by Gemini, converted from simple Markdown into formatted PDF content.

Alerts and Reference Status

Before building the report sections, the build() method checks the main metrics against their configured thresholds.

For example, it can generate an alert when:

the average number of steps is below the target;
walking speed is below the reference value;
HRV or SpO₂ is below the configured threshold;
average sleep duration does not meet the expected value. These alerts are based on simple comparisons and do not represent medical diagnoses.

AI Disclaimer

The AI-generated section always includes a visible disclaimer. It explains that the text was created from device data, is not a clinical evaluation or diagnosis, and may contain errors or incorrect interpretations.
The disclaimer also reminds the reader that the generated narrative should be checked against the original metrics and reviewed by a qualified professional before being used in any health-related decision.

7. Conclusions

One of the main challenges of this project was transforming Apple Health records into useful and understandable information. HealthKit’s consistent data structure makes this processing easier and supports the creation of a reusable pipeline. It also opens the door to interoperability: in a real environment, representing the results with standards such as HL7 FHIR could simplify their exchange with applications, hospitals, and electronic health record systems.

Separating Calculation from Interpretation

A relevant design decision was to keep the calculations in Python and use Gemini only to generate the narrative. Averages, trends, threshold comparisons, and weekly statistics are calculated in a controlled way, while the model receives already processed values and turns them into readable text.
Summarizing the data before sending it to the LLM also reduces token usage, execution cost, and the risk of reaching the context window limit. This approach provides more control over the information used to generate the report.

Personalization and Data Quality

The same metrics and thresholds are not suitable for every patient or every use case. Making these values configurable allows the analysis to be adapted to the patient profile, the monitoring objective, and the specific needs of the project.
However, configuration alone does not guarantee reliable results. The statistical methods should also be validated, and the pipeline should measure data completeness. For example, it should be able to distinguish between a real reduction in activity and missing records caused by low battery, synchronization problems, or irregular device use.
In a real implementation, metrics, thresholds, and validation rules should be reviewed together with healthcare professionals.

Security and Responsible Data Use

Health data requires specific controls for privacy, access, storage, and retention. A real solution should define what information is collected, who can access it, how long it is stored, and which data may be sent to external services.
Although these topics are outside the scope of this article, they should be considered from the beginning of the design process. Consent, data minimization, and retention policies should not be added only after the technical implementation is complete. This principle is also reflected in Apple Health, which requires explicit permission to read and write health information.

Final Note

This project is an educational MVP built with simulated data. It is not ready for production and should not be used directly to make health-related decisions.
Its main purpose is to demonstrate how continuous health data, deterministic processing, visualizations, and a language model can be combined in a modular pipeline. The LLM can help communicate the results, but the calculations, validation rules, and data-quality controls should remain reproducible and verifiable.

8. 📚 Reference

Apple. (2018, 24 de enero). Apple announces solution bringing health records to iPhone. Apple Newsroom. https://www.apple.com/newsroom/2018/01/apple-announces-effortless-solution-bringing-health-records-to-iPhone/
Apple. (2020). Handling FHIR without getting burned [Video]. Apple Developer. https://developer.apple.com/videos/play/wwdc2020/10669/
Apple. (s. f.). Accessing Health Records. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/healthkit/accessing-health-records
Apple. (s. f.). Configuring HealthKit access. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/xcode/configuring-healthkit-access
Apple. (s. f.). HealthKit. Apple Developer Documentation. Retrieved July 10, 2026, from https://developer.apple.com/documentation/healthkit
Google. (2026, 23 de junio). Gemini 2.5 Flash. Google AI for Developers. https://ai.google.dev/gemini-api/docs/models/gemini-2.5-flash
Google. (s. f.). Guía de inicio rápido de Google AI Studio. Google AI for Developers. Retrieved July 10, 2026, from https://ai.google.dev/gemini-api/docs/ai-studio-quickstart?hl=es-419
Google. (s. f.). MedGemma 27B instruction-tuned model card. Hugging Face. Retrieved July 10, 2026, from https://huggingface.co/google/medgemma-27b-it
Health Level Seven International. (2023, 26 de marzo). FHIR overview: FHIR release 5. https://fhir.hl7.org/fhir/overview.html
Health Level Seven International. (2023, 26 de marzo). Introducing HL7 FHIR: FHIR release 5. https://fhir.hl7.org/fhir/summary.html

Apple WWDC 2026: Apple Intelligence, Privacy-First AI, and the Future of Digital Experiences

Romina Elena Mendez Escobar — Wed, 10 Jun 2026 17:25:47 +0000

At WWDC 2026 (its annual developers conference), Apple announced a new generation of Apple Intelligence, a completely redesigned Siri, and a host of AI-powered features across its ecosystem.

What was interesting was observing how Apple is building a vision where design, privacy, accessibility, and artificial intelligence are no longer separate issues, but rather integrated into a single product strategy.
Between the evolution of Liquid Glass, an AI architecture that prioritizes local data processing, new parental control tools, and features that expand accessibility through natural language and visual understanding, WWDC 2026 offered several clues about where the next generation of digital products might be headed.

1. Design Is Never Finished: The Evolution of Liquid Glass

Last year, Apple introduced Liquid Glass as one of the most ambitious visual changes in its ecosystem. This year, they did something that we often forget in technology: they iterated on it.
Apple explicitly acknowledged feedback from users and developers, adjusting aspects related to legibility, contrast, visual depth, and customization. The addition of transparency controls and the refinement of core components reflects a practice we see in the most successful digital products: ship, observe, learn, evolve.

Key updates in this iteration:

〰️ Improved legibility: the system now diffuses complex content behind surfaces differently, creating greater separation and visual depth between interface layers
〰️ Customization slider: users can now adjust Liquid Glass appearance from ultra-clear to fully tinted directly in Settings
〰️ Icon depth: additional Liquid Glass layers are now integrated directly into app icon artwork for sharper definition in the dock and home screen
〰️ Structural consistency: sidebars expand to window edges to reduce distractions while maintaining the characteristic glass refractions; window corners use a tighter radius for visual coherence The evolution of Liquid Glass tells a broader story: design at this scale is not a launch event, it's a continuous discipline.

2. Privacy-First: An Architecture That Could Change How We Build AI

This is arguably the most relevant part of WWDC 2026 for those of us who work in technology.

Apple reinforced an idea it has been building for years: privacy in AI is not a marketing slogan… it's a non-negotiable architectural feature.

The new generation of Apple Intelligence combines on-device processing with Private Cloud Compute, allowing most personal information to remain on the device. This opens important questions for architects, data engineers, and developers — because for years we assumed AI required sending large amounts of data to centralized services to function. Apple is exploring a different path: bringing intelligence closer to where the data actually lives.

The shift is conceptual as much as technical. Privacy stops being a constraint and becomes a design principle.

How the architecture works

Private Cloud Compute (PCC) is the key piece for data engineers. Complex requests are sent to servers running Apple Silicon, with a guarantee that data is never stored or accessible (not even to Apple) and that this promise can be verified by independent experts at any time.

•••

Real examples of this in practice

〰️🧭 Safari: unlike other AI-powered browsers, Safari does not share sensitive browsing history with anyone
〰️ 📱Phone app: the "Call Context" feature analyzes who is calling and searches for relevant information across your apps, but the entire process runs on-device with nothing shared externally
〰️🏞️ Image Playground: even when powerful cloud models generate photorealistic images, personal photos used as reference are never stored or shared
For sectors like healthcare, finance, or legal — this model matters. On-device AI inference at this quality level removes one of the core objections to AI adoption: data residency and third-party access. When the compute moves to the device and the results are verifiable, many compliance conversations change.

3. Technology to Learn With, Not Just to Consume: Child Safety Reimagined

One of the announcements that caught my attention most was the focus on children and teenagers.
The conversation about kids and devices often reduces to a single question: are they good or bad? Apple proposes a more interesting frame. The question becomes how to use them safely and intentionally.
What Apple introduced is not just parental controls — it's a framework for intentional digital access, built on recommendations from child development experts and organizations including the American Academy of Pediatrics.

Key tools announced

〰️🚸 Child Account: the first step: activates age-appropriate safeguards automatically, including adult site blocking and App Store media restrictions
〰️? Ask to Browse: extends the "Ask to Buy" model to web navigation; children request permission to visit new sites, parents review and approve from their own devices
〰️✔️ Contact approval: parents must approve any new contact added within apps
〰️💬 Communication Safety: proactive intervention before children see violent or graphic content in shared images and videos, in addition to existing nudity protection
〰️⏰ Time Allowances: daily recommendations by category (games, social media, entertainment) based on the child's age and validated by the AAP — with parents retaining full control to adjust
〰️🗓️ Schedules: define which apps are available during school hours to reduce distraction and support focus The goal is not to take the device away. It's to make it useful, safe, and age-appropriate. A child can use educational apps during school time, creative apps in the afternoon, and have social apps gated for weekends. ### APIs for developers Apple extended this safety ecosystem to third parties:
〰️ Declared Age Range API — lets developers privately adapt their app experience to the child's verified age range, without exposing the actual age
〰️ Contact control resources — tools to ensure parents approve new contacts within third-party applications The underlying principle resonates beyond child safety: the device is not the problem. The design of access is.

4. Siri AI, Visual Intelligence, and AI-Powered Accessibility

The new Siri is probably the most visible announcement of the event — but its implications go well beyond a conversational assistant.
Siri is no longer a command interface. It is a context-aware, multimodal agent that understands what you see, what you are doing, and what you have said before — across all your devices.
The architecture diagram Apple shared illustrates this clearly:

•••

Visual Intelligence in Practice

The examples Apple showed during the session represent architectural shifts in how humans interact with technology:

〰️ Point the camera at a restaurant bill → Siri splits it automatically using Apple Cash
〰️ Scan the food on your plate → get nutritional information in real time
〰️ Look at something in your environment → ask what it is and get context

AI as Accessibility Infrastructure

The new capabilities Apple introduced through voice interactions and visual understanding were primarily presented as productivity and assistance features. However, from my perspective, they also represent a meaningful step forward in accessibility.

For decades, digital accessibility has often been approached as an additional layer added on top of products: screen readers, magnification tools, voice commands, or specialized interfaces designed for specific needs. Those tools remain essential, but what Apple appears to be demonstrating points in a different direction.

When a system can understand what is happening on the screen, interpret what the camera sees, maintain conversational context, and respond through natural language, accessibility stops being a separate feature and becomes part of the interaction model itself.

From the perspective of Universal Design, several principles begin to emerge naturally through these capabilities.

Flexibility in Use: Users can interact with the same functionality in different ways depending on their preferences, abilities, or context. A person can type, speak, show an image, or combine multiple interaction methods to achieve the same outcome. The technology no longer imposes a single path; it adapts to different ways of engaging with it.
Simple and Intuitive Use: Natural language interactions reduce the need to learn complex navigation structures, extensive menus, or specific commands. Users can express their intent using their own words and receive contextual assistance without needing to understand how the system works behind the scenes.
Perceptible Information: Visual Intelligence can transform visual information into verbal or contextual information. Users can receive descriptions of objects, understand documents, identify elements in their surroundings, or obtain explanations about what appears in front of the camera. Information is no longer tied to a single sensory channel.
Low Physical Effort: Many tasks that previously required multiple steps, manual searches, or switching between applications can now be completed through a conversation or a single image capture. Reducing the number of actions required to accomplish a task lowers the effort needed to interact with the system.

•••

Beyond Traditional Accessibility

Accessibility becomes less about specialized accommodations and more about creating technology that understands people, their context, and their intent.
Perhaps the most significant shift is that technology is no longer asking people to adapt to interfaces... because the interface is beginning to adapt to people.

•••

Intelligence That Follows the User

Another interesting aspect of the new Siri architecture is cross-device continuity.
Conversations can now move seamlessly between iPhone, iPad, Mac, and Vision Pro while preserving context. A user can start a conversation on one device and continue it on another without losing the flow of the interaction.
This may seem like a convenience feature, but it reflects a deeper design principle. The context window is no longer tied to a specific device. It follows the user.
In summary Users do not think in terms of devices; they think in terms of tasks, goals, and conversations. Apple's approach suggests a future where intelligence becomes a persistent layer across the entire ecosystem rather than a capability attached to individual products.

5. From Features to Platform

Beyond the end-user experience, Apple also introduced a set of frameworks, APIs, and development tools that open Apple Intelligence to the broader ecosystem.

🧠 Foundation Models Framework
Developers can access Apple's foundation models directly from Swift, extend them with custom capabilities, and use the same programming model across different environments.

❤️ Core AI
Applications can run third-party models locally on Apple Silicon, taking advantage of hardware acceleration while keeping inference close to where the data resides.

🔗 App Intents
App Intents continue to become a foundational integration layer. They allow Siri and Apple Intelligence to understand and interact with application functionality. Apps that expose meaningful intents become part of the broader intelligence ecosystem.

🤖 Agentic Coding in Xcode
Apple introduced agentic development capabilities directly into Xcode, allowing developers to connect AI assistants to tools such as GitHub, Figma, and simulators as part of the development workflow.

📱 Device Hub
A unified interface for testing applications across real and simulated devices, simplifying validation across Apple's growing ecosystem.

•••

APIs Extending the Ecosystem

Apple also expanded several APIs that allow developers to integrate these capabilities into their own applications.
〰️ Image Playground API enables AI-powered image generation directly within third-party applications.
〰️ Declared Age Range API allows applications to provide age-appropriate experiences while preserving user privacy.
〰️ App Intents API enables applications to become deeply integrated with Siri and Apple Intelligence.

Final Thoughts

If I had to summarize WWDC 2026 in one sentence, I would say Apple presented a vision where design, privacy, intelligence, accessibility, and digital safety are no longer separate concerns. They become part of the same product architecture.

In summary, WWDC 2026 highlights several important lessons:

The evolution of Liquid Glass showed that design is a continuous process of learning and refinement.
Apple Intelligence demonstrated that AI can be built around privacy rather than treating it as a constraint.
The new child safety features reframed the conversation from restricting technology to designing intentional access.
Visual Intelligence suggested a future where accessibility emerges naturally from systems that understand context, language, images, and user intent.

For developers, the message was equally significant. Apple did not only introduce new user-facing experiences; it exposed the frameworks, APIs, and intelligence layers required to build on top of them.

What I take away from this event is that we need to focus less on individual features and more on complete solutions that help people accomplish tasks across different contexts. The platform is no longer a standalone destination; it becomes part of a continuous experience that follows the user across devices and moments.

As intelligence becomes more integrated into everyday interactions, personalization and security increasingly emerge as foundational design principles. Building products now requires thinking beyond a single application or device and considering how experiences evolve across an entire ecosystem.

The most important takeaway is not any individual feature announced during WWDC. It is the direction these announcements collectively point toward: technology that becomes more contextual, more personal, more accessible, and more deeply integrated into people's daily lives.

How will these principles reshape the way we design digital products, platforms, and enterprise architectures over the next decade?

Reference

Apple. (2026, June 8). Apple WWDC 2026 June 8: Introducing Siri AI and more [Video]. YouTube. Retrieved June 9, 2026, from https://www.youtube.com/watch?v=hF8swzNR1-o

Serverless Research Paper Intelligence: Docling, Lambda Containers, and Amazon Bedrock

Romina Elena Mendez Escobar — Wed, 27 May 2026 13:25:25 +0000

1.🚀 Introduction

Processing scientific PDFs is not as simple as extracting text.

Many papers include tables, multiple columns, formulas, figures, and structures that can easily break when we use traditional extractors.
The problem becomes even bigger when those documents are private. We do not always want to depend completely on multimodal models to analyze them, and the cost can also grow quickly when we work with many files.

A few months ago, I attended PyData Berlin and during one of the talks I discovered IBM Docling, an open source project focused on intelligent document processing. What caught my attention the most was its ability to extract structured information from complex PDFs, especially scientific documents with tables, multiple columns, formulas, and layouts that are difficult to process with traditional tools.

From that moment, I started thinking about how to bring this type of processing to the cloud in a simple and scalable way, while also keeping costs under control. Some current solutions for analyzing complex documents with generative AI rely heavily on multimodal models, but in scenarios where we work with large volumes of papers or private documents, cost and privacy can quickly become a problem.

If you have read some of my previous articles, you have probably seen that I like to build content around a real use case. In this tutorial, I decided to work with scientific papers related to research on GLP-1 receptor agonists, a class of medications widely studied for type 2 diabetes and obesity.

These treatments are currently very popular because many people use them for weight loss purposes.

The objective of the tutorial

The idea is not to build a generic search engine over the internet, but something much more interesting: a private knowledge base where you can query only your own research documents in a secure environment.
To solve this, we are going to build an architecture based on:

📦 AWS Lambda Containers
📑 Amazon Bedrock Knowledge Bases
🐣 PDF processing with Docling
🪣 Storage in Amazon S3
✂️ Chunking strategies to improve information retrieval

During the tutorial, I will also show several real problems that I found while implementing this solution:

〰️ size limits in Lambda,
〰️ timeouts caused by model downloads,
〰️ Docker image optimization,
〰️ scientific document processing,
〰️ and architecture decisions to keep a serverless and low cost approach.

The final objective will be to transform a set of scientific papers into a knowledge base that can be queried using natural language. This will allow us to ask questions about adverse effects, clinical criteria, study results, and comparisons between different research papers.

2.🧪 Use case

In this tutorial, we are going to work with a set of scientific papers related to research on GLP-1 receptor agonists (Glucagon-Like Peptide-1), a natural hormone involved in glucose regulation, insulin secretion, and the feeling of fullness.

In recent years, different treatments based on this family of molecules have appeared, and a large number of clinical studies, academic papers, and research documents have been published. These documents are related to cardiovascular outcomes, weight loss, adverse effects, and inclusion or exclusion criteria in clinical trials.

The objective of this use case is not to build a search engine over the internet or use public information in real time. The idea is to work with a private and curated set of scientific documents, simulating a scenario where researchers, medical teams, or research areas need to query only their own papers in a secure environment.

For this MVP, I am going to use 10 public papers as an example dataset, but the architecture is designed for scenarios where the documents can be private or belong to internal research processes.
From these documents, we are going to build a knowledge base that allows queries using natural language, for example:

〰️ identify adverse effects reported in different studies,
〰️ compare results between treatments,
〰️ validate exclusion criteria in clinical trials,
〰️ analyze cardiovascular outcomes,
〰️ retrieve specific information across multiple scientific papers.

3. 🏗️ Solution Architecture

Before going into the theoretical concepts, we are going to describe the solution that we will build.

This solution is based on a serverless architecture that processes scientific papers in PDF format and later uses them as input for an Amazon Bedrock Knowledge Base to build a RAG system.

The architecture clearly separates the ingestion and processing flow from the intelligent query flow, while keeping the solution simple and scalable.

The following blueprint shows how each component connects inside the complete pipeline.

In summary, this pipeline processes PDF files using a Python Docker image with Docling, running inside an AWS Lambda function based on a container image.

This Lambda function transforms the files into structured documents in Markdown.

Then, these documents are stored in Amazon S3 and indexed by Amazon Bedrock, which generates embeddings and allows semantic queries over the content.

4. 📑 Docling: structured document extraction

One of the main challenges when working with scientific PDFs is that they are not “simple” documents. They are full of tables, columns, formulas, figures, and complex layouts that are not always preserved correctly when text is extracted.

IBM Docling is an open source library designed for PDF extraction and document structuring. Its goal is not only to extract text, but also to convert complex documents into a structured representation that can be used in artificial intelligence pipelines and RAG systems.

Instead of returning messy plain text, Docling tries to preserve the structure of the document, including the reading order, tables, formulas, images, and other key elements of the content.

The following image summarizes some of the key benefits of using Docling for complex document processing.

Why use Docling?

Traditional tools like PyPDF, PDFPlumber, or classic OCR are usually enough for simple documents, but they can struggle when working with scientific papers that have complex layouts.

In these cases, important information can be lost, such as:

〰️table structure
〰️ column separation
〰️relationship between text and figures
〰️mathematical formulas

Docling appears as an alternative that tries to solve exactly these problems, generating a much more consistent output for later analysis.

Docling features

Below, you can find the main features published by the library on Hugging Face:

🏷️ DocTags for Efficient Tokenization – Introduces DocTags an efficient and minimal representation for documents that is fully compatible with DoclingDocuments.
🔍 OCR (Optical Character Recognition) – Extracts text accurately from images.
📐 Layout and Localization – Preserves document structure and document element bounding boxes.
💻 Code Recognition – Detects and formats code blocks including identation.
🔢 Formula Recognition – Identifies and processes mathematical expressions.
📊 Chart Recognition – Extracts and interprets chart data.
📑 Table Recognition – Supports column and row headers for structured table extraction.
🖼️ Figure Classification – Differentiates figures and graphical elements.
📝 Caption Correspondence – Links captions to relevant images and figures.
📜 List Grouping – Organizes and structures list elements correctly.
📄 Full-Page Conversion – Processes entire pages for comprehensive document conversion including all page elements (code, equations, tables, charts etc.)
🔲 OCR with Bounding Boxes – OCR regions using a bounding box.
📂 General Document Processing – Trained for both scientific and non-scientific documents.

🏥 Practical example: processing a medical record with Docling

In this example, we will use a synthetically generated clinical record in PDF format to show how Docling can extract and structure information from a healthcare document.

All patient data, medical records, and clinical findings are completely fictional and were created only for educational purposes. No real patient information was used.

This example represents a common use case in the healthcare industry, where medical documents need to be processed, structured, and prepared for analysis with AI.

In the next steps, we will use Docling to:

〰️ load and convert the PDF
〰️ explore the document structure and identify sections
〰️ extract structured patient data into a pandas DataFrame

📌The following image shows part of the clinical record that we will process in this example.

📑 Loading and converting the PDF

In this step, we load the clinical record PDF using Docling's DocumentConverter.

Docling automatically detects the document structure and exports the result in two formats:

〰️Markdown: a human readable output to preview the content
〰️Dictionary: programmatic access to text, tables, images, and metadata

This structured output is what makes Docling more powerful than a basic PDF text extractor.

from docling.document_converter import DocumentConverter, PdfFormatOption
import pandas as pd
converter = DocumentConverter()
result = converter.convert("clinical_history_structured.pdf")
# export markdown
data_markdown = result.document.export_to_markdown()
# export dict
data_dict = result.document.export_to_dict()
texts = data_dict['texts']

🗂️ Exploring document sections

Every clinical record is organized into sections. Here, we extract all the section headers detected by Docling, such as Patient Identification, Chief Complaint, and Laboratory Results.

This gives us:

〰️ A map of the document structure
〰️ The ability to target specific sections for downstream processing

[item['text'] for item in data_dict['texts']  if item['label'] == 'section_header']

['CITYVIEW MEDICAL CENTER CLINICAL HISTORY AND RECORD',
 '1. PATIENT IDENTIFICATION',
 '4. PAST MEDICAL HISTORY',
 '5. MEDICATIONS',
 '6. ALLERGIES',
 '2. CHIEF COMPLAINT',
 '3. HISTORY OF PRESENT ILLNESS',
 '7. FAMILY HISTORY',
 '8. SOCIAL HISTORY',
 '9. REVIEW OF SYSTEMS',
 '10. PHYSICAL EXAMINATION',
 '12. LABORATORY RESULTS',
 '13. ASSESSMENT',
 '14. PLAN',
 '11. IMAGING']

🧩 Extracting patient data as a structured table

Now we extract the content of the first section, Patient Identification, by filtering the items that belong to #/groups/0.

Docling preserves the key value layout of the original PDF, so we can split the flat list into field names and values using Python slice notation.

The result is a clean pandas DataFrame ready for:

〰️ Analysis
〰️ Storage
〰️ Downstream AI processing

# Filter group 0
group_0 = [item['orig'] for item in texts 
           if item.get('parent', {}).get('$ref') == '#/groups/0']
# Convert the flat list into key value pairs
keys   = group_0[0::2]  
values = group_0[1::2]  
df = pd.DataFrame({
    'field': [k.replace(':', '').strip() for k in keys],
    'value': values
})
df

result.document.tables[0].export_to_dataframe()

5. ⚡ AWS Lambda

AWS Lambda is a serverless service that allows you to run code without managing infrastructure. It scales automatically and you only pay for what you use.
It is commonly used for file processing, service integration, scheduled tasks, and real time event processing.

However, even though it is one of the most used services in the serverless ecosystem, some limitations appear quickly when we start working with heavier workloads or complex dependencies.
Some of the main limitations are:

〰️ memory and CPU limits
〰️ maximum execution timeout
〰️ deployment package size restrictions
〰️ the need to use ZIP files or Layers for dependencies
〰️ cold starts in heavier workloads These restrictions mean that, in some cases, traditional Lambda is not enough to run workloads such as intensive PDF processing or libraries with large dependencies.

6. 🐳 AWS Lambda Containers

To solve part of these limitations, AWS Lambda allows you to run functions using container images instead of ZIP packages.
This approach allows you to package the function as a Docker image, push it to Amazon Elastic Container Registry, and run it directly from Lambda.
The main advantage is that it significantly increases the size limit, up to 10 GB. This makes it possible to include heavy dependencies, predownloaded models, or complex libraries like Docling without needing workarounds with Layers.
In this project, this option is key because it allows us to run Docling inside Lambda without compromising dependencies or the runtime.
The following image summarizes the key benefits of using Lambda Containers for this type of workload.

Deploying a Docling Lambda Container to AWS

As we saw in the previous section, the limitations of traditional Lambda make it difficult to run heavy libraries like Docling using ZIP packages or Layers.
To solve this, we are going to run AWS Lambda from a container image. This allows us to package Docling, its dependencies, and its models inside a Docker image, and deploy it using Amazon Elastic Container Registry (ECR).
In this section, we are going to build the image, push it to AWS, and use it inside Lambda to process our scientific papers.
The following image shows the deployment flow that we will follow step by step.

Prerequisites

Before starting, you need to have:

AWS CLI installed and configured
Docker installed with buildx support
Repository cloned locally
Create Amazon S3 bucket named docling-papers-tutorial, with the PDFs that we are going to process already uploaded
You also need an IAM user with permissions to create images in ECR and deploy Lambda functions. In the repository, you will find JSON files with the required policies inside iam/user_policies.

Github repository

RominaElenaMendezEscobar / docling-bedrock-research-rag

Serverless RAG pipeline for turning research papers into a private knowledge base using Docling, AWS Lambda Containers, Amazon S3, and Amazon Bedrock.

Serverless Research Paper Intelligence: Docling, Lambda Containers, and Amazon Bedrock

1.🚀 Introduction

The objective of the tutorial

The idea is not to build a generic search engine over the internet, but something much more interesting: a private knowledge base where you can query only your own research documents in a secure environment. To solve this, we are going to build an architecture based on:

📦 AWS Lambda Containers
📑 Amazon Bedrock Knowledge Bases
🐣 PDF processing with Docling
🗑️ Storage in Amazon S3
✂️ Chunking strategies to improve information retrieval

During the tutorial, I will also show several real problems that I found while implementing this solution:

〰️ size limits in Lambda,
〰️ timeouts caused by model downloads,
〰️ Docker image optimization,
〰️ scientific document processing,
〰️and architecture decisions to keep a serverless and low cost approach.

The final objective will be to transform a set of scientific papers into…

View on GitHub

Building the Docker image

Once the repository is cloned, we start by configuring the environment variables required for the deployment.

•••••

Setup

Create a .env file with your credentials:

AWS_ACCESS_KEY_ID=your_access_key
AWS_SECRET_ACCESS_KEY=your_secret_key
AWS_DEFAULT_REGION=us-east-1

Then export the variables:

export $(grep -v '^#' .env | xargs)
export AWS_ACCOUNT_ID=$(aws sts get-caller-identity \
--query Account --output text)
export ECR_REPO_NAME=docling-lambda
export LAMBDA_FUNCTION_NAME=docling-lambda
export IMAGE_NAME=docling-lambda

⚠️ Remember to add .env to your .gitignore.

•••••

Step 1: Verify your AWS identity

Before deploying, verify which AWS account and IAM user are currently configured in your environment.

aws sts get-caller-identity

•••••

Step 2: Authenticate Docker with Amazon ECR

This command generates a temporary ECR authentication token and passes it to docker login, so Docker can push images to your private ECR registry.

aws ecr get-login-password --region $AWS_DEFAULT_REGION | \
  docker login --username AWS --password-stdin \
  $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com

⚠️ This token expires after 12 hours. Run this step again if you get authentication errors.

•••••

Step 3: Build the Docker image

Now we build the Docker image from the Dockerfile.

docker buildx build \
  --platform linux/amd64 \
  --provenance=false \
  --sbom=false \
  --no-cache \
  --load \
  -t $IMAGE_NAME .

The most important flags are:

Flag	Description
`--platform linux/amd64`	Forces the `x86_64` architecture required by AWS Lambda. This is required if you are building on an Apple Silicon Mac, such as M1, M2, or M3.
`--provenance=false`	Disables build attestation metadata, which can cause issues with Lambda image deployments.
`--sbom=false`	Disables Software Bill of Materials generation, which can also cause issues with Lambda deployments.
`--no-cache`	Builds the image from scratch, ignoring cached layers.
`--load`	Loads the image into your local Docker daemon after building.
`-t $IMAGE_NAME`	Tags the image with the selected image name.

•••••

Step 4: Tag the image for ECR

Before pushing the image, we need to create a new tag that points to the full ECR repository URI.
Docker requires the image name to match the complete ECR URI before it can push the image to the registry.

docker tag $IMAGE_NAME:latest \
$AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_REPO_NAME:latest

•••••

Step 5: Verify that the image exists locally

Before pushing the image to ECR, confirm that it exists in your local Docker environment.

docker images

The image should appear with both tags: the local tag and the ECR tag.

•••••

Step 6: Push the image to ECR

Now we push the image to your private ECR repository.

This step may take several minutes because the Docling image is large due to the ML models included inside the container.

docker push \
$AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_REPO_NAME:latest

•••••

Step 7: Update the Lambda function

Run this step only if you need to update an existing Lambda function with a new image version.

aws lambda update-function-code \
--function-name $LAMBDA_FUNCTION_NAME \
--image-uri $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$ECR_REPO_NAME:latest

This command tells AWS Lambda to use the new image that you just pushed to ECR.
Lambda will pull the image from ECR and deploy it automatically.

7. 🧯 Real problems during the deployment

What I had to solve to run Docling on Lambda

Up to this point, the flow looks relatively simple: build the image, push it to ECR, and deploy the Lambda function.
However, when working with heavy libraries like Docling, several problems started to appear. These problems were related to the image size, the Lambda runtime, and the download of models during execution.
This section summarizes some of the real problems I found during the implementation and the solutions I finally applied.

•••••

Reducing the image size

One of the first problems I ran into was related to the Docker image size. When working with libraries like Docling, which include ML models and multiple heavy dependencies, the final image can grow considerably.
To avoid issues during the build and push process, I added a cleanup step inside the Dockerfile to remove temporary files, __pycache__ folders, and compiled .pyc files.

# Clean up temporary files to reduce image size
RUN find /var/lang/lib/python3.12/site-packages \
-type d -name "__pycache__" -exec rm -rf {} + 2>/dev/null || true && \
find /var/lang/lib/python3.12/site-packages \
-type f -name "*.pyc" -delete

Although this may look like a small optimization, this type of cleanup helps reduce the final size of images with many Python dependencies.

•••••

Avoiding timeouts and model downloads at runtime

Another important problem appeared during the first executions of the Lambda function.

In the version used in this project, Docling tried to automatically download the models at startup if they were not found locally. This caused timeouts and also created another issue: the Lambda filesystem is read only outside the temporary directory,
which means models cannot be downloaded or saved there at runtime.

To solve this, I decided to predownload the models during the Docker build and store them directly inside the image.

In the Dockerfile, I added the following:

# Copy and run model download script
COPY download_models.py /tmp/download_models.py

RUN mkdir -p /opt/docling-models && \
python3.12 /tmp/download_models.py && \
rm /tmp/download_models.py

The script initializes a DocumentConverter, which forces the required Docling models to be downloaded during the image build instead of during Lambda execution.

from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.base_models import InputFormat
from docling.datamodel.pipeline_options import PdfPipelineOptions
from pathlib import Path

def main():

   artifacts_path = Path("/opt/docling-models")

   pipeline_options = PdfPipelineOptions(
       artifacts_path=artifacts_path,
       do_ocr=False
   )

   converter = DocumentConverter(
       format_options={
           InputFormat.PDF: PdfFormatOption(
               pipeline_options=pipeline_options
           )
       }
   )
if __name__ == "__main__":
   main()
   print("✓ Models downloaded successfully")

With this approach, the models are packaged inside the container and the Lambda function can start much faster, avoiding unnecessary downloads and problems related to the restricted filesystem.

8. 🔁 Orchestrated paper processing

The following function corresponds to the orchestration Lambda. Its goal is to list the papers stored in Amazon S3 and run the processing by invoking the docling-lambda function, which contains the Docker image with Docling.
In this case, the processing is done in a distributed way. Each PDF file is sent individually to the Lambda function responsible for converting the document into Markdown.
In the repository, you will find an implementation similar to the following:

import boto3
import json
from botocore.config import Config

s3 = boto3.client("s3")

lambda_client = boto3.client(
   "lambda",
   config=Config(
       read_timeout=900,
       connect_timeout=10,
       retries={"max_attempts": 0}
   )
)

BUCKET = "docling-papers-tutorial"
DOCLING_LAMBDA = "docling-lambda"

def lambda_handler(event, context):

   # List PDFs
   response = s3.list_objects_v2(
       Bucket=BUCKET
   )

   pdfs = [
       obj["Key"]
       for obj in response.get("Contents", [])
       if obj["Key"].endswith(".pdf")
   ]

   print(f"PDFs found: {len(pdfs)}")

   results = []

   for pdf_key in pdfs:

       s3_url = f"s3://{BUCKET}/{pdf_key}"

       print(f"Processing: {s3_url}")

       response = lambda_client.invoke(
           FunctionName=DOCLING_LAMBDA,
           InvocationType="RequestResponse",
           Payload=json.dumps({"s3_url": s3_url})
       )

       result = json.loads(response["Payload"].read())

       results.append({
           "input": s3_url,
           "output": result.get("output"),
           "status": result.get("status")
       })

       print(f"✓ {pdf_key} → {result.get('output')}")

   return {
       "processed": len(results),
       "results": results
   }

Once the function is deployed, we can execute the Lambda function and analyze the results from CloudWatch.

In my tests with these 10 papers, the average was approximately 3.8 seconds per page. This can vary significantly depending on document complexity

This confirms something important: the processing time depends much more on the complexity of the content, such as tables, images, multiple columns, or figures, than on the file size or the number of pages.

9. 🟩 Amazon Bedrock Knowledge Base

Before configuring our Knowledge Base, it is worth understanding what this service is inside Amazon Bedrock and why it plays a key role in a RAG architecture.

•••••

What is a Knowledge Base?

In simple terms, a Knowledge Base is a layer that connects private data with artificial intelligence models, so they can use that information as context to answer questions.

•••••

What is a Knowledge Base in Amazon Bedrock?

In Amazon Bedrock, a Knowledge Base is a fully managed service that allows you to build RAG systems over your own data.
This means that models can query information stored in a knowledge base to generate more accurate and contextualized answers based on private data.
The following image summarizes the key benefits of using Amazon Bedrock Knowledge Bases in this type of architecture.

Also, it includes capabilities such as:

〰️ automatic embedding management
〰️ context management
〰️ source attribution in the answers
〰️ direct integration with private data

•••••

Supported data sources

A Knowledge Base in Amazon Bedrock can connect to different data sources:

〰️ 🪣 Amazon S3
〰️ 🟦 Confluence depending on availability
〰️ ☁️ Salesforce depending on availability
〰️ 📑 Custom data sources
〰️ 🕸️ Web Crawler

Availability can depend on the AWS Region and account configuration.

In this use case, we are mainly going to work with Amazon S3, where we store the documents processed with Docling.

•••••

Chunking: how information is divided

One of the most important concepts when building a Knowledge Base is chunking, which is the process of dividing documents into smaller parts called chunks.
This is necessary because models have context limitations and cannot process very long documents all at once.

We can understand this from two perspectives:

〰️ Context limit: models can only handle a limited number of tokens
〰️ Efficient search: dividing the content allows the system to retrieve more precise information faster In this project, chunking is key because we are working with scientific papers, where the context between sections is very important, for example: results, methods, and adverse effects. The following image describes the main chunking features available in Amazon Bedrock Knowledge Bases.

•••••

Step by step configuration

Creating the Knowledge Base in Amazon Bedrock

In this section, we are going to configure the Knowledge Base in Amazon Bedrock using the papers processed with Docling and stored in Amazon S3 in Markdown format.
The chunking strategy selected for this use case is Hierarchical Chunking, because it allows us to keep the relationship between document sections, for example results, methods, or adverse effects. This is key when working with scientific papers.

Below, I explain why I did not choose the other strategies and what each one implies:

〰️ ❌ Default: uses the default chunking configuration, which may split content without preserving the full document structure.
〰️ ❌ Fixed size: similar to the default strategy, but configurable. It still has the same problem of losing context.
〰️ ❌ Semantic: groups content by semantic similarity. It can be useful, but it may add extra processing time and can be less predictable depending on the documents.
〰️ ❌ No chunking: useful when documents are already small or manually preprocessed into meaningful units.
〰️ ✅ Hierarchical: keeps a parent child structure, allowing each chunk to preserve its context inside the document.

•••••

Prerequisites and permissions

To create a Knowledge Base, you need to consider the following permissions:

〰️ IAM: create or select roles with the right permissions
〰️ Bedrock: access to Knowledge Bases and embedding models
〰️ S3: access to the bucket where the processed documents are stored
〰️ KMS: optional, for data encryption
〰️ Lambda: optional, for custom data transformations

⚠️ AWS does not support creating a Knowledge Base using root user credentials — you need an IAM user or role with the right permissions. Permission configuration is usually one of the most delicate parts of this type of architecture.

_______________

Step 1: Create the Knowledge Base

In Amazon Bedrock, go to the Knowledge Bases section and select Create knowledge base with vector store.
Complete the configuration:

Name: docling-glp1-papers-kb
Description: Knowledge base with GLP-1 papers processed with Docling and Lambda
IAM Role: AmazonBedrockExecutionRoleForKnowledgeBase-docling
Data source: Amazon S3

_______________

Step 2: Configure the data source

Configure the data source with the following values:

〰️ Source name: docling-glp1-papers-ds
〰️ S3 path: s3://docling-papers-tutorial/output/
〰️ Parsing strategy: Amazon Bedrock default parser
〰️ Chunking strategy: Hierarchical chunking

_______________

Step 3: Vector store and embeddings

Here, we are going to select the model that we will use to create the RAG system and the destination where the information will be stored.

〰️ Embeddings model: Titan Text Embeddings v2
〰️ Vector store: Amazon S3 Vectors

In this case, we use on demand mode, although other models are available depending on the use case.
After that, we select the Amazon S3 bucket used by S3 Vectors to store the vector index.

To better understand how this type of storage works, you can check a previous article I wrote:

Romina Elena Mendez Escobar for AWS Community Builders

Dec 31 '25

From Coffee Products to AI Search: Building a Serverless Semantic Search Architecture with Amazon S3 Vectors and Bedrock

#ai #aws #python #cloud

21 min read

_______________

Step 4: Data synchronization

Once the Knowledge Base is created, its initial status will be Available.
To load the documents, you need to run a manual synchronization:

〰️ Go to the Knowledge Base
〰️ Select the data source
〰️ Click on Sync This synchronization processes the documents, generates the required embeddings, and makes the content available for natural language queries.

10. 🟩 BEDROCK: Test the Knowledge Base

Now we return to the point where we left off a few steps ago: testing our Knowledge Base with the processed papers.

The idea in this stage is to validate whether the system can retrieve relevant information from the 10 scientific papers that we previously loaded and processed.

To do this, we are going to ask some questions focused on clinical analysis and study comparison:

〰️ What gastrointestinal adverse effects were reported in semaglutide clinical trials and what were the incidence rates?
〰️ What were the cardiovascular outcomes reported in semaglutide clinical trials and which patient populations benefited most?
〰️ How does semaglutide compare to liraglutide and tirzepatide in terms of weight loss efficacy and adverse effects across the clinical trials?

These queries allow us to evaluate how the system retrieves specific information across different studies, especially in scenarios where the results are distributed across multiple documents.

11. 🎯 Conclusions

This MVP shows that it is possible to build a queryable knowledge base over private scientific documents using AWS serverless services together with open source tools like Docling.

What I learned while building this system:

〰️ The chunking strategy matters more than it may seem. In the case of scientific papers, Hierarchical Chunking preserves the context between sections such as Results or Adverse Effects better than fixed token based strategies.
〰️ Docling can help reduce the cost and complexity of preprocessing when working with complex PDFs, especially those with tables, columns, and non linear structures. It allows us to convert these documents into structured information ready to be used in AI systems. *〰️ Embeddings are not the same as security. Even though we work with vector representations, research has shown that in some scenarios it is possible to infer or reconstruct sensitive information from embedding vectors. Because of this, treating vector stores as sensitive data and applying access controls and encryption is a good practice in real scenarios.

If we take this to a production environment, three pieces become fundamental:

〰️ CI/CD pipelines are necessary to automate processing and system updates as improvements are added.
〰️ Infrastructure as Code with Terraform, or similar tools, is key to replicate, scale, and maintain the environment consistently across different stages.
〰️ Any solution that is deployed, especially one that uses AI models, should include observability systems to detect and solve problems in production. In terms of impact, this type of solution opens a very relevant space in industries such as healthcare and research, where controlled access to large volumes of knowledge can significantly accelerate scientific analysis and decision making.

Finally, beyond the tools used, the most interesting part of this architecture is how it combines different cloud services and generative AI capabilities to solve a very concrete problem: converting unstructured information into accessible, private, and queryable knowledge using natural language.

12. 📚 Technical references

Amazon Web Services. (n.d.). AWS Lambda Developer Guide. AWS Documentation. Retrieved May 26, 2026, from https://docs.aws.amazon.com/es_es/lambda/latest/dg/welcome.html
Amazon Web Services. (n.d.). Create a Lambda function using a container image. AWS Documentation. Retrieved May 26, 2026, from https://docs.aws.amazon.com/lambda/latest/dg/images-create.html
Amazon Web Services. (n.d.). Amazon Bedrock Knowledge Bases. Retrieved May 26, 2026, from https://aws.amazon.com/es/bedrock/knowledge-bases/
IBM. (n.d.). Docling. Retrieved May 26, 2026, from https://www.docling.ai/
Docling Project. (n.d.). SmolDocling 256M preview. Hugging Face. Retrieved May 26, 2026, from https://huggingface.co/docling-project/SmolDocling-256M-preview
University of Utah Health. (2026). GLP 1 FAQs answered by weight loss experts. Retrieved from https://healthcare.utah.edu/healthfeed/2026/03/preguntas-frecuentes-sobre-el-glp-1-respondidas-por-expertos-en-perdida-de-peso

13. 📄 Research papers used in the use case

Han, S. H., Safeek, R., Ockerman, K., Trieu, N., Mars, P., Klenke, A., Furnas, H., & Sorice Virk, S. (2023). Public interest in the off label use of glucagon like peptide 1 agonists (Ozempic) for cosmetic weight loss: A Google Trends analysis. Aesthetic Surgery Journal. https://doi.org/10.1093/asj/sjad211
Ryan, N., & Savulescu, J. (2026). The ethics of Ozempic and Wegovy. Journal of Medical Ethics, 52(3), 185–193. https://doi.org/10.1136/jme-2024-110374
Mailhac, A., Pedersen, L., Pottegård, A., Søndergaard, J., Mogensen, T., Sørensen, H. T., & Thomsen, R. W. (2024). Semaglutide (Ozempic®) use in Denmark 2018 through 2023: User trends and off label prescribing for weight loss. Clinical Epidemiology. https://doi.org/10.2147/CLEP.S456170
Manoharan, S. V. R. R., & Madan, R. (2024). GLP 1 agonists can affect mood: A case of worsened depression on Ozempic (Semaglutide). Case Reports in Psychiatry. https://pmc.ncbi.nlm.nih.gov/articles/PMC11208009/
Humphrey, C. D., & Lawrence, A. C. (2023). Implications of Ozempic and other semaglutide medications for facial plastic surgeons. Facial Plastic Surgery. https://doi.org/10.1055/a-2148-6321
Pillarisetti, L., & Agrawal, D. K. (2025). Semaglutide: Double edged sword with risks and benefits. Archives of Internal Medicine Research, 8(1), 1–13. https://doi.org/10.26502/aimr.0189
Fong, S., Carollo, A., Lazuras, L., Corazza, O., & Esposito, G. (2024). Ozempic (Glucagon like peptide 1 receptor agonist) in social media posts: Unveiling user perspectives through Reddit topic modeling. Dialogues in Health. https://www.sciencedirect.com/science/article/pii/S2667118224000163
Carboni, A., Woessner, S., Martini, O., Marroquin, N. A., & Waller, J. (2024). Natural weight loss or “Ozempic Face”: Demystifying a social media phenomenon. Journal of Drugs in Dermatology, 23(1). https://doi.org/10.36849/JDD.7613
Grech, V. S., Lotsaris, K., Grech, I., & Kefala, V. (2024). Semaglutide (Ozempic) and obesity: A comprehensive guide for aestheticians. Review of Clinical Pharmacology and Pharmacokinetics, 38(Suppl. 1), 31–35. https://www.researchgate.net/publication/378300594_Semaglutide_Ozempic_and_obesity_A_comprehensive_guide_for_aestheticians
Vambe, S. D., Zulu, W., Hough, E., & Luvhimbi, M. J. (2024). Semaglutide (Ozempic®): A comprehensive review of its pharmacology, efficacy, and safety profile in type 2 diabetes mellitus and weight management. SA Pharmaceutical Journal, 91(6), 31–34. https://www.researchgate.net/publication/388790459_Semaglutide_Ozempic_R_a_comprehensive_review_of_its_pharmacology_efficacy_and_safety_profile_in_type_2_diabetes_mellitus_and_weight_management

Google I/O 2026: What Happens When Everything Connects?

Romina Elena Mendez Escobar — Sat, 23 May 2026 14:03:06 +0000

This is a submission for the Google I/O Writing Challenge

Google I/O 2026 showed us something that goes beyond a list of launches: a vision of where technology is heading.

Image source: Image created by the author ____________

Sundar Pichai (Google CEO) opened the presentation sharing some interesting numbers about the *evolution of AI with Google statistics that you can see in the following infographic.

Image source: Infographic created by the author ____________

But let’s get back to the event…
Over two hours, Google announced a wide range of products, updates and platforms. From new AI models to smart glasses, from music generation tools to a digital twin of the entire planet.
What stands out is not any single product on its own, but the way they are designed to work together. Most of them are not meant to exist in isolation but to integrate with each other and with the models Google is deploying across its ecosystem.

Below you will find all the launches organized by category, with my take on each one and direct links to the exact moment in the keynote where it was announced.

🧠 Models & Infrastructure

Behind almost everything presented at Google I/O 2026 has the same foundation: more advanced models and an infrastructure designed to scale new forms of interaction between people and systems.

Image source: Image created by the author ____________

Gemini Omni

The first model that allows you to modify videos using natural language, with inputs that can be images, text or video. But it is not just about understanding text, images, audio and video at the same time; it is about reasoning over all of them together to generate something new.
What sets it apart from any previous video generator is that it combines an intuitive understanding of physics with real knowledge about history, science and cultural context. So you can take a video you recorded and ask it to change what happens in it, edit the action, add characters, transform a moment into something completely unexpected.

📍 Gemini Omni → 17:15

• • • •

Gemini 3.5 Flash

Gemini 3.5 Flash is the direct evolution of the main line of large language models (LLM) from Google, optimized to deliver ultra-high speed performance, advanced logical reasoning capabilities and code orchestration. It is an ideal model for building autonomous agents capable of executing complex task flows in the background, writing code, processing large text contexts or powering searches.
All of this while being four times faster than comparable models, which makes it the option specifically designed for agentic tasks.

📍 Gemini 3.5 Flash → 23:43

🤖 Agents & Productivity: Your Digital Life, Managed

This is one of the categories I enjoyed the most, featuring several tools that change the way we work and organize our daily tasks.

Image source: Image created by the author ____________

Gemini Spark

Gemini Spark is a personal AI agent that runs tasks in the background, across all your applications, without you having to supervise every step. With Spark you can organize an event, manage a chain of emails, coordinate a complex task across multiple services.
It also connects with external tools through the open MCP protocol, which extends its reach beyond the Google ecosystem.

📍 Gemini Spark → 35:18

• • • •

Daily Brief

Google has been offering AI summaries for a while, but Daily Brief is something different. Instead of summarizing a document you provide, it reads your chats, your Gmail emails, your calendar context and your pending tasks, and then prioritizes what matters for your day. The difference between a generic summary and one that actually understands your context is significant, and that is exactly what Daily Brief proposes.

📍 Daily Brief → 1:15:06

• • • •

Ask YouTube

Ask YouTube changes the search bar we know on YouTube into a conversation. You can ask for a summary, a specific recommendation, or request to find exactly what you need at a precise moment without watching the full video.
What I find most interesting is the impact on creators. The algorithm can now understand the deeper context of content and recommend videos that used to stay hidden behind generic titles. For creators, this is an opportunity, and for content consumption in general, it changes the way we interact with the platform.

📍 Ask YouTube → 7:41

• • • •

Docs Live

Docs Live changes the way we create documents. While it's already possible to create content using Gemini's voice input options, this solution lets you share your ideas aloud, and Gemini will start creating a document, formatting, structuring, and writing the text in real time.
The key difference from Gemini's existing voice input is that the result isn't a chat response; it's a properly formatted Google Docs document, complete with headings, lists, and a professional structure right from the start.

📍 Docs Live → 9:14

🔍 Search & Commerce: Your Next Purchase Will Be Made by an Agent

AI search is already part of our daily routine, but this year Google took it further, turning search from a simple query into an agent that can look for information and even make purchases on your behalf.

Image source: Image created by the author ____________

AI Search Box

The new search box is no longer limited to text. It now accepts images, files, videos and even Chrome tabs as input. It may seem like a small change, but it completely transforms the experience of searching for something, powered by the new Gemini 3.5 Flash models.

📍 AI Search Box → 46:05

• • • •

Search Agents

Search agents are a feature that, in my opinion, will become essential without many people noticing at first. They are background agents that you can set up to monitor specific topics, such as the value of a stock you are tracking, a flight route for an upcoming trip, or a property you want to rent in a specific neighborhood.

If the agent detects changes, it can summarize the information and notify you. It can pick up updates from blogs, news sites, social media, and real-time data on finance, shopping and sports.
This changes the current experience we have with Google Alerts, which were based only on keywords, since it takes both alerts and information retrieval to a much more advanced level.

📍 Search Agents → 47:48

• • • •

Generative UI in Search

This announcement is quite interesting because information can already be accessed through agents, chats or other channels, but the main idea is to provide an interface that is intuitive for users to interpret that information. Instead of returning a list of links, Search can now build a personalized interactive interface for complex queries. Here you can get a live comparison table, a dynamic chart or an interactive explanation, all generated in real time for your specific question.

📍 Generative UI → 51:17

• • • •

Universal Cart & UCP + AP2

Google is redefining the online shopping experience with two announcements. On one hand, Universal Cart turns the shopping cart into something where you can add products, and the system then works in the background autonomously, monitoring price drops, analyzing price history and notifying you when an item becomes available again.

On the other hand, the Universal Commerce Protocol (UCP) establishes an open standard that allows all of this to scale beyond Google. It creates a common language for agents and systems to work together across the entire shopping process, from finding a product to post-purchase support, connecting consumer platforms, businesses and payment providers.

UCP is compatible with other key ecosystem protocols such as Agent2Agent (A2A), Agent Payments Protocol (AP2) and Model Context Protocol (MCP), positioning it not as a Google tool, but as the infrastructure for agentic commerce.

📍 AP2 Protocol → 1:01:17
📍 Universal Cart → 1:03:13

🎬 Creative Tools: Can anyone make a movie today?

Content creation was another area where the shift in focus at Google I/O 2026 became very clear. It is not just about generating images, music or video, but about how these tools are starting to integrate into a continuous creative flow, closer to a conversation than to a technical process.

Image source: Image created by the author ____________

Google Flow

Google Flow is a creative platform developed by Google that allows users to generate, edit and compose videos, images and music from prompts or images. In its latest update, it integrates with Gemini Omni to take video editing to a more conversational level, allowing you to change environments, add characters, and generate 16 different camera angles from a single image.

📍 Google Flow → 1:28:08

• • • •

Flow Music

Flow Music is a generative tool that allows users to compose songs and create full music videos from prompts. It also lets you provide a reference recording and build a complete track around it, edit it section by section, reimagine the style of a song while keeping its original melody, or create music videos by directly conversing with the agent.
I think it is an ideal tool for independent artists who develop games, apps or video content and want to create using AI.

📍 Flow Music → 1:31:01

• • • •

Stitch

Google Stitch is a tool developed by Google Labs that uses AI to design user interfaces (UI/UX). These designs can be exported directly to code, Figma, Google Antigravity or Google AI Studio. The design process is driven by instructions that can be given through text or voice, and it is generated in real time.

📍 Stitch → 1:25:36

• • • •

Google Pics

Google Pics is a new image creation and editing tool based on Nano Banana, Google’s model for this type of task. It allows users to select and edit specific elements with precision, such as moving objects, changing colors, or transforming one element into another without affecting the rest of the image.

Without a doubt, it is a very useful tool for content creators, making it easier to modify and edit images using text instructions.

📍 Google Pics → 1:24:20

⚙️ Developer Tools & Hardware

This section is perhaps one of the most diverse of the event, as it combines developer tools with consumer hardware that is still in active development. It ranges from systems capable of coordinating code agents at scale to devices that start bringing Gemini interactions directly into the physical world.

Image source: Image created by the author ____________

Antigravity 2.0

Antigravity 2.0 is a native desktop application that works as a central platform for coordinating multiple sub-agents running tasks in parallel. The keynote demo showed one of the most complex examples, building an operating system from scratch, and this tool allows you to create a plan and define how sub-agents should run in parallel in order to achieve the goal.

📍 Antigravity 2.0 → 26:55

• • • •

CodeMender

CodeMender is a security tool originally developed by Google DeepMind. The tool scans code, identifies vulnerabilities autonomously, recommends fixes, tests them in a safe environment, and can apply the necessary patches with your approval at each step.
📍 CodeMender → 1:45:58

• • • •

Audio Glasses

Audio glasses, developed with Samsung and designed in collaboration with Gentle Monster and Warby Parker, allow you to use Gemini without a screen and without taking your phone out. With these glasses, you can ask about a restaurant you just passed, get step-by-step directions, manage calls and messages, take photos with a voice command, or use the apps installed on your phone.
📍 Audio Glasses → 1:34:32

• • • •

Display Glasses & Android XR

Display Glasses go one step further: they include micro-projectors built into the lenses that overlay useful information on the real world, such as navigation maps or real-time translations on signs, among other features.
Meanwhile, Android XR is the operating system platform that powers these devices, developed with Samsung and Qualcomm. It is still in a trusted testers phase, with a wider rollout expected later this year.
📍 Android XR / Display Glasses → 1:33:15

🔬 Science: What Happens When AI Never Stops Researching?

This was, for me, the most important section of the event. The following initiatives from Google apply AI to problems that go far beyond personal productivity, from accelerating scientific research to modeling the global climate and rethinking the process of drug discovery.

Image source: Image created by the author ____________

Gemini for Science

Gemini for Science is a research acceleration platform that allows scientists to stay up to date with newly published papers, turn research goals into executable code, and generate new hypotheses. It is still in a prototype phase in Google Labs, but the concept is what matters: AI is not presented as a replacement for scientific thinking, but as infrastructure that removes friction from the early stages of research, enabling literature search, synthesis of papers, and translation of hypotheses into experiments.
A researcher who can stay updated in real time across their entire field and automatically translate a hypothesis into an experiment is a researcher who can focus on more meaningful work.

📍 Gemini for Science → 1:46:37

• • • •

AlphaEarth Foundations & WeatherNext

AlphaEarth Foundations is a model developed by Google DeepMind that works as an interactive digital twin of the Earth, powered by real-time satellite data, climate sensors, ocean readings, and biodiversity records. Meanwhile, WeatherNext is its atmospheric counterpart, a weather forecasting engine capable of predicting hurricane paths and extreme weather events with greater accuracy and speed than traditional systems.
These models were presented at the conference as examples of how Google’s AI technology can be applied to solve problems that affect billions of people around the world.

📍 AlphaEarth + WeatherNext → 1:46:37

• • • •

Isomorphic Labs

Isomorphic Labs, the biotechnology company within Alphabet (a sister company of Google DeepMind), continues to build on AlphaFold. This is an AI system developed by DeepMind that enables the prediction of protein structures.
It is another example of how Google’s technology is being applied in the pharmaceutical industry, helping to significantly accelerate research and molecular design for treatments against cancer and complex immune disorders.
In the keynote, this work was described as “science at digital speed”, where AI acts as a tool to understand biological systems that were previously impossible to model directly.

📍 Isomorphic Labs → 1:46:37

• • • •

SynthID

SynthID is Google’s invisible watermarking system for AI-generated content. This label is added to images, videos and audio at the moment of creation, allowing anyone or any system to later verify whether something was generated by AI.
This announcement is important not only from a safety perspective, but also because it is being adopted as a standard by companies such as OpenAI and ElevenLabs.

📍 SynthID → 21:06

What I'm Most Excited to Try

If I had to choose the three announcements I will follow most closely:

🛒 Universal Cart & UCP + AP2

These two announcements will change the way we shop online. For years, we have designed experiences for human users: visual interfaces, marketplaces, recommendations and conversion funnels. But Google is proposing something different: agents capable of discovering products, evaluating options, monitoring prices and executing purchases on our behalf.
This means ecommerce is no longer only a human platform interaction, but starts to become an ecosystem where agents also participate as consumers.
I do not think these solutions will replace traditional commerce overnight, but they will deeply change how trust is built, how products are presented, and how companies compete for attention, not only from people but also from intelligent agents.

🔍 Search Agents

Traditional alerts have always been passive: they depended on exact keywords and often generated more noise than context. This is one of the announcements I will probably follow most closely because it completely changes that logic.
Instead of manually searching for information, you can now delegate the monitoring of a topic to a system that understands intent, relevance and meaningful changes. An agent that continuously tracks the internet in the background.
And the more I think about it, the clearer it becomes that this might be one of the most important features of the keynote, precisely because it will quietly integrate into our daily routine.

• • • •

🧬 Gemini for Science

Of everything announced, this is probably the project with the deepest potential impact.
Modern scientific research has a silent problem: the speed of knowledge has already surpassed human capacity to absorb it. Thousands of papers are published every week, information is fragmented, hypotheses are scattered, and entire weeks are spent just trying to stay updated.
Gemini for Science proposes something fundamentally different: turning AI into infrastructure for research.
The ability to translate scientific literature into actionable hypotheses, generate experimental code, connect discoveries across disciplines and accelerate research processes could completely change the scale at which science progresses.
Because perhaps the most important application of artificial intelligence is not to automate work, but to accelerate human knowledge.

🎥 What I Actually Tried: Google Flow

Most of the announcements that caught my attention were related to systems, agents and infrastructure. But beyond the long term vision, I also wanted to understand what it actually feels like to interact with one of these tools in practice.
So instead of just describing them, I decided to try one myself. I opened Google Flow and started experimenting with a short video prompt, and for a moment, I found myself living that childhood idea of creating my own animation.

Image source: Image created by google flow ____________

While doing this, I could not help but think about how tools like this could evolve beyond individual experimentation. In the future, they might become part of how schools teach storytelling, narration and creative thinking, helping children express ideas through visual and generative tools. At the same time, it also raises an interesting challenge: how younger generations will learn to use these systems in a way that is both creative and intentional, rather than just consumptive.

What the Experience Felt Like

The result was an 8 second clip and honestly, the quality surprised me. With a fairly simple prompt describing a scene, the model generated something that looked cinematic and coherent. The prompt itself was also AI generated, and I am leaving it in the appendix at the end of this article in case you want to replicate the experiment.
A few things stood out from the experience.
The 8 second limit felt a bit frustrating at first. But after thinking about it, I am not sure if that is a limitation of Flow or simply how professional video production works. Scenes in film and TV are often short clips that are later assembled in post production. Flow seems to follow that same logic, where you build a story by connecting multiple clips instead of generating one long video in a single shot.

In a previous test, I was able to concatenate two clips, and what impressed me the most was the character consistency between them. The same character appeared in both scenes without drifting, keeping the same look and style. That is actually one of the hardest problems in AI video generation today: maintaining character consistency across different prompts. Flow’s approach of letting you define and save a character that can later be reused across scenes feels like a real step forward. Whether it can maintain that consistency across longer or more complex sequences is something I still want to keep testing.

How I Tested It

Under the hood, I used Gemini Omni Flash as the base model, with an 8 second duration, 2x speed and a 16:9 aspect ratio.
Each generation costs 50 credits, which gives a more concrete sense of the cost per clip when planning a longer project. The tool also allows direct publishing to YouTube and lets you select a custom thumbnail, making the end to end workflow surprisingly complete for a creative platform.

🔮 How far do we want to go?

Google I/O 2026 presented a series of solutions, models and use cases where artificial intelligence is becoming more deeply integrated into our daily lives. But while watching each demo, one broader question kept coming to my mind:

How far do we really want to go?

Because many of these tools do not only automate tasks, they also start to reorganize how we access information, how we make decisions and how we interact with the digital world.

What stood out the most was not each announcement on its own, but what happens when you look at them together. Agents that run in the background, search that becomes conversational, interfaces that adapt to context in real time. Not as isolated products, but as parts of a system that is still being built.

And in any system, what matters is not only each component, but how they connect with each other and what kind of emerging behavior appears when they start interacting.

Google showed the pieces based on AI.

What is still being defined is the full system: its direction, its shape, and how it will integrate into our daily lives and work.
And maybe that is the most important part of this new era: it is not only about what technology is capable of building, but about how each of us decides to interpret it, use it, and become part of it.

⚠️ A note on process and transparency

I am an organizer at GDG Barcelona, and I led the event where we brought together 37 people to watch the full Google I/O 2026 keynote live. That experience, I was able to follow the announcements in real time, listening to the reactions in the room ... is what shaped the perspective and opinions in this article.

This article is also based on the official sources listed in the references section, which I read and consulted directly after the event to verify and expand on each announcement.

All the visuals in this article were designed by me using Figma Design, because creating my own images is something I genuinely enjoy as part of my writing process. AI tools were used for text correction and translation assistance and all opinions, analysis and perspectives are my own.

📚 References

Google. (n.d.). Gemini Omni. Google Blog. https://blog.google/intl/es-es/productos/presentamos-gemini-omni/ (Accessed May 22, 2026)
Google. (n.d.). Gemini Spark. Gemini Overview. https://gemini.google/overview/agent/spark/ (Accessed May 22, 2026)
Google. (n.d.). Daily Brief. Gemini Overview. https://gemini.google/overview/daily-brief/ (Accessed May 22, 2026)
Google. (n.d.). The next evolution of the Gemini app. Google Blog. https://blog.google/innovation-and-ai/products/gemini-app/next-evolution-gemini-app/ (Accessed May 22, 2026)
YouTube. (n.d.). YouTube News: Google I/O 2026. YouTube Blog. https://blog.youtube/news-and-events/youtube-news-google-io-2026/ (Accessed May 22, 2026)
Google. (n.d.). YouTube search updates and AI features. Google Support. https://support.google.com/youtube/answer/16943763?hl=en (Accessed May 22, 2026)
Google. (n.d.). Search at Google I/O 2026: AI-powered search updates. Google Blog. https://blog.google/products-and-platforms/products/search/search-io-2026/ (Accessed May 22, 2026)
Google. (n.d.). Universal Cart and shopping updates. Google Blog. https://blog.google/intl/es-419/actualizaciones-de-producto/informacion/google-shopping-cart/ (Accessed May 22, 2026)
Google. (n.d.). Merchant Center help: Shopping updates. Google Support. https://support.google.com/merchants/answer/16837055?hl=es (Accessed May 22, 2026)
Google. (n.d.). Flow updates. Google Blog. https://blog.google/intl/es-419/actualizaciones-de-producto/flow-updates/ (Accessed May 22, 2026)
Google. (n.d.). Stitch updates from Google Labs. Google Blog. https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-updates/ (Accessed May 22, 2026)
Google. (n.d.). Google I/O 2026 developer tools highlights. Google Blog. https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-collection/ (Accessed May 22, 2026)
Google. (n.d.). Workspace updates at Google I/O 2026. Google Blog. https://blog.google/products-and-platforms/products/workspace/workspace-updates/ (Accessed May 22, 2026)
Google. (n.d.). Antigravity 2.0. https://antigravity.google/product/antigravity-2 (Accessed May 22, 2026)
Google. (n.d.). Developer highlights from Google I/O 2026. Google Blog. https://blog.google/innovation-and-ai/technology/developers-tools/google-io-2026-developer-highlights/ (Accessed May 22, 2026)
Google Cloud. (n.d.). Innovations from Google I/O 2026 on Google Cloud. https://cloud.google.com/blog/products/ai-machine-learning/innovations-from-google-io-26-on-google-cloud (Accessed May 22, 2026)
Google. (n.d.). Android XR at Google I/O 2026. Google Blog. https://blog.google/products-and-platforms/platforms/android/android-xr-io-2026/ (Accessed May 22, 2026)
DeepMind. (n.d.). SynthID. https://deepmind.google/models/synthid/ (Accessed May 22, 2026)

📄 Appendix

This is the AI-generated prompt I used to create the video in Google Flow. I am including it here so you can replicate the experiment or explore it further.

A short animated intro video, 15 seconds. Chibi anime art style — soft cel-shading, vibrant neon colors, cinematic lighting, dark moody atmosphere. Think Lo-Fi anime meets cyberpunk gamer aesthetic.
Character: A small chubby panda in chibi style. Oversized black hoodie with hood down while walking, round panda ears visible on top. Serious and unbothered expression. Tiny paws. Soft black and white fur with subtle neon light reflections. This is a developer panda — cool, focused, says nothing.
Scene 1 — 0:00 to 0:05: Wide shot of a dark misty forest at night. A distant neon city skyline glows purple and cyan through the trees. Fog rolls along the ground. The panda walks alone from the right side of frame through a forest path, hands in hoodie pocket, completely unbothered. He approaches a large mossy rock formation — a hidden cave entrance covered by hanging vines with faint bioluminescent blue glow. He pushes the vines aside and steps in. Slow cinematic cut to black.
Scene 2 — 0:05 to 0:10: Interior of the cave — full gamer setup. RGB neon strips in Google colors (blue, red, yellow, green) line the rocky cave walls casting dramatic colored light on everything. A dark stone desk holds a glowing MacBook Pro, mechanical keyboard with RGB backlighting, mouse with neon underglow, and stacked empty energy drink cans. The panda walks to the desk, drops his backpack on the floor. Pulls out the chair and sits down. He opens the MacBook — a burst of white light floods his face and the cave. He slowly reaches to the side, picks up thick black sunglasses and puts them on. Then places large black headphones over his panda ears. He cracks his tiny paw knuckles. Leans forward. The RGB strips pulse once in sync.
Scene 3 — 0:10 to 0:15: Ultra slow cinematic push-in toward the MacBook screen. The cave darkens around it. The screen fills the entire frame glowing bright. Bold text appears: "GOOGLE I/O 2026 — THE AGENTIC ERA IS HERE" in clean white typography on dark background. Neon blue and green light pulses around the text edges. Below it, six glowing color blocks appear one by one with smooth fade-ins: MODELS · AGENTS · SEARCH · CREATIVE · DEV · SCIENCE. Each block in its Google neon color, white bold uppercase text, subtle neon glow border. Final frame holds 2 seconds with all blocks visible, neon pulsing softly. Fade to black.
Lighting & mood throughout: Dark, moody, cinematic. Neon reflections on all surfaces — the panda's fur, the cave walls, the desk. Color palette: deep black backgrounds, cyan #00F5FF, neon green #39FF14, Google blue #4285F4, Google red #EA4335, Google yellow #FBBC04, purple #BF5FFF. Inspired by cyberpunk anime aesthetics — think lo-fi coder vibes meets Akira color palette.

From Hype to Product: How AI Is Being Used Today

Romina Elena Mendez Escobar — Fri, 10 Apr 2026 12:10:27 +0000

For years, we talked about artificial intelligence as a promise, and over the last two years in the era of LLMs… AI has stopped being the protagonist and has become invisible infrastructure.

Today we don’t see it as “AI”, it becomes invisible and already forms part of our interactions and experiences without us noticing. This means when an app understands what you need before you search, when a recommendation hits the mark effortlessly, or when a decision happens in real time without an explicit interface.

In this article, we explore some concrete examples of how artificial intelligence is moving from hype to product, and the patterns that are starting to emerge.

💄Sephora Transforms User Experience with AI in ChatGPT

Image Reference: https://newsroom.sephora.com

Sephora, a global leader in premium beauty products, has launched its app within ChatGPT, currently in a pilot phase in the United States. Participating users can receive personalized beauty product recommendations by linking their Beauty Insider account, explore solutions tailored to their needs, and take advantage of benefits such as free shipping and samples.

🔗 Link: https://newsroom.sephora.com/sephora-app-in-chatgpt-brings-a-new-personalized-beauty-experience/

☕️ What’s Behind Every Cup of Coffee You Enjoy at Starbucks?

Starbucks, the global coffeehouse chain, is using artificial intelligence to enhance the experience for both customers and partners without replacing human interaction. Tools like Green Dot Assist help baristas get quick answers about recipes, routines, and service standards, while Smart Queue optimizes the order flow across in-store, drive-thru, mobile, and delivery channels.

Additionally, the Starbucks Ordering Companion, still in development, will guide customers to discover their ideal drink and locate nearby stores, while maintaining the warmth and personalization that define the brand.

🔗 Link: https://about.starbucks.com/press/2026/supporting-the-moments-that-matter-with-artificial-intelligence/

🖼️ Pinterest AI Turns Your Ads into Scalable Results

Pinterest, the visual discovery and search platform, is integrating artificial intelligence into its Performance+ campaigns, allowing advertisers to optimize results without micromanaging every detail. AI automation helps intelligently combine content, audiences, and placements, making ads more relevant and scalable while advertisers focus on providing content and product signals.

🔗 Link: https://business.pinterest.com/es/blog/pinterest-performance-plus-campaigns/

✈️ Delta Reveals Why We Still Seek Real Experiences When Traveling

Reference image: https://news.delta.com/deltas-inaugural-connection-index-finds-why-travelers-are-priorizing-real-wold-experiences

A new global trends report from Delta Air Lines, Connection Index: Why We Fly, examines why travelers choose to fly and how these experiences impact their emotions. The study shows that even in an increasingly digital world, travelers prioritize authentic experiences: 84% of international travelers report a strong desire to explore new places and meet people, and 73% have traveled specifically to see in person something they first discovered online.

🔗 Link: https://news.delta.com/deltas-inaugural-connection-index-finds-why-travelers-are-prioritizing-real-world-experiences

📊 Agentic AI in Action: How Amazon Helps Sellers Make Real-Time Decisions

Amazon, a global leader in e-commerce and technology, is integrating generative and agentic AI into its Seller Central platform to improve how sellers manage and scale their businesses. Through a new experience called Canvas, sellers can create interactive visual spaces that combine business data, insights, and recommended actions in real time.

Reference Image: https://www.aboutamazon.com/news/innovation-at-amazon

This experience is based on the agentic architecture of Seller Assistant, powered by Amazon Bedrock and models such as Amazon Nova and Anthropic Claude. Sellers can ask questions or select suggestions, and the system automatically builds a personalized dashboard that enables performance analysis, scenario simulations (such as changes in demand or inventory), and optimization of marketing campaigns with concrete projections.

🔗 Link: https://www.aboutamazon.com/news/innovation-at-amazon/amazon-sellers-canvas-artificial-intelligence

📱Apple Unifies Business Management on a Single Platform

Apple, a leading technology company, has launched Apple Business, an all-in-one platform that integrates device management, collaboration tools, and brand presence into a single environment. The solution allows companies to automatically configure devices through Blueprint projects, manage users and apps, and centralize services such as email, calendar, and directory with their own domains.

🔗 Link: https://www.apple.com/es/newsroom/2026/03/introducing-apple-business/

🛒 How Instacart Connects Physical Stores and Real-Time Data with AI

Instacart, a technology platform for retail and supermarkets, is developing a “Physical AI” system that connects real-world data with cloud models to enhance the shopping experience. Through devices like Caper Carts, equipped with sensors, cameras, and edge processing (NVIDIA Jetson), the company captures real-time information about products, cart location, and user behavior within the store. This data is combined with cloud systems that use recommendation models and transformer-based architectures to generate insights and suggestions at the exact moment of purchase.

Reference: https://www.instacart.com/company/enterprise-blog

🔗 Link: https://www.instacart.com/company/enterprise-blog/connecting-stores-from-edge-to-cloud-reinventing-retail-with-physical-ai

💳 How Mastercard Is Building Trust in the Era of AI Agents
Mastercard is a global payments technology company that connects consumers, merchants, and financial institutions, developing infrastructures that enable secure and scalable transactions worldwide.

In this context, it introduces Verifiable Intent, a new layer of trust for commerce with AI agents, developed in partnership with Google. This system creates a cryptographically verifiable record of what a user authorized before an agent acts on their behalf, connecting identity, intent, and action in a single source of truth. As agents move from assisting to executing purchases, this solution addresses a key challenge for bringing AI into production: ensuring traceability, authorization, and dispute resolution in autonomous transactions, making trust a central component of the product.

🔗 Link: https://www.mastercard.com/global/en/news-and-trends/stories/2026/verifiable-intent.html

Before You Go

As we wrap up this edition, here’s a tool to help you put AI into action in your own projects:

🧩 Recommended App

Stitch is an experimental AI tool from Google Labs that lets you quickly turn text prompts into functional app designs for mobile and desktop. It supports interactive prototyping, allows real-time collaboration, and can export your designs to popular platforms like Figma or as HTML code. In short, Stitch makes it easy to transform ideas into high-fidelity UI prototypes without complex setup.

Reference image: https://stitch.withgoogle.com

📢 Join the Conversation

What do you think about the ways AI is transforming experiences across industries, from retail to travel to design? I’d love to hear your thoughts, ideas, or favorite AI tools.

Hit reply and share your perspective!

More women in Tech. Fewer women leading

Romina Elena Mendez Escobar — Tue, 31 Mar 2026 13:41:07 +0000

Every March invites me to pause, and on a personal level, it’s a moment to acknowledge the progress made toward equality, but also to reflect honestly on the challenges that still remain.

In recent years, we have seen encouraging signs: more women are pursuing careers in technology, science, and data. At the same time, initiatives to promote diversity within organizations have grown, along with conversations around female leadership and inclusion programs across the sector.

However, when we look at who occupies decision-making roles in technology (who leads teams, defines strategy, or drives innovation) the reality still reflects an uneven path.

From my experience working in IT, one question keeps coming up: if more women are studying STEM fields (science, technology, engineering, and mathematics) and developing technical skills, why is it still so difficult to see them in technical leadership roles?

With that question in mind, I reviewed several recent reports and what I found is that there is no single cause, but rather a combination of structural and cultural factors that reinforce one another.

Understanding them together is key to explaining why progress remains so slow.

A persistent gap: the numbers behind the reality

To frame the conversation, it is worth starting with a few recent data points:

〰️ (1) Globally, women represent around 50% of the working-age population, yet they hold only 40% of total employment and approximately 35.4% of management positions, according to the International Labour Organization [1].
〰️ (2) Within the technology sector, the situation is even more pronounced. In Europe, women account for fewer than one in five tech workers [6], and according to McKinsey’s analysis, their presence in core technical roles has not only failed to improve over time but has actually declined: from 22% in earlier reports to approximately 19% in more recent ones. This suggests that, rather than closing, the gap may in fact be widening [2].
〰️ (3) At the highest levels, the numbers are equally telling. In 2025, women lead just 11% of Fortune 500 companies, compared to 10.4% the previous year [3], a modest increase that, in perspective, highlights the slow pace of progress.
〰️ (4) According to the 2025 Women’s Power Gap report, of the 64 new CEOs appointed in the S&P 500 in 2024, only 11 were women (17% of the total), and none were founders of the companies they were set to lead [4].
〰️ (5) The gender pay gap adds another layer to this picture: in the European Union, women earn on average around 12% less than men [9].
〰️ (6) The 82% of the female leaders surveyed say they have had to change companies at least once in order to take the next step in their professional career [9].

These figures describe the outcome, but not the process. To understand why this situation persists, we need to look inside organizations and examine the mechanisms shaping women’s career progression.

The broken rung: when careers start at a disadvantage

One of the most useful concepts for explaining this gap is called Broken Rung. The image is precise: it is not about a glass ceiling preventing women from reaching the top, but rather a damaged step at the very beginning that makes it harder for many women to take their first step into leadership.

According to a McKinsey study conducted in the United States, for every 100 men promoted to their first management role, only around 80 women achieve the same advancement [2]. At first glance, this may seem like a small difference, but its consequences compound over time. If fewer women reach the first step of leadership, there will also be fewer candidates at the next level, and even fewer at the level above.

With each promotion, the starting pool shrinks, and female representation gradually diminishes as one moves up the hierarchy.

This cascading effect largely explains why executive levels in technology companies show such limited representation. The problem is not the final barrier before reaching roles such as CEO or CTO, it lies in that initial moment when decisions are made about who takes on early management and leadership responsibilities and who does not.

At this point, it is worth adding another insight highlighted by McKinsey: 49% of women in the European technology sector reported experiencing sexism or bias in the past year, and 82% said they feel the need to prove their competence more than their male peers in order to be recognized [2].

These are not just individual experiences; they are indicators of an environment where the standards of evaluation are not the same for everyone, and where promotion decisions may be influenced by different expectations based on gender.

Invisible work: tasks that consume time without building careers

Alongside the broken rung, there is a second mechanism that operates more quietly but just as effectively: non-promotable work. This refers to all the tasks that are necessary for the day-to-day functioning of organizations but are not recognized in performance evaluations nor contribute to career advancement.

The list is familiar to anyone who has worked in an organization: taking meeting notes, organizing team events, coordinating onboarding logistics for new hires, managing recognition initiatives or gifts, or participating in committees that have no direct impact on the business. These tasks are essential, yet they are not reflected in any performance metric and, when it comes to evaluating promotions, they simply do not count.

The issue is not only that these tasks go unrecognized, but also that they are not distributed equitably. According to an analysis published by The Guardian in 2022 [7], women tend to take on these responsibilities more frequently. This results in less time available for strategic projects and reduced visibility within the organization. In some cases, this difference can amount to nearly a month of work per year spent on tasks that do not contribute to professional growth, compared to their male counterparts.

Over time, this pattern not only limits individual development but also structurally reinforces the gap in access to leadership roles.

Learning to stay relevant: the challenge of continuous upskilling

In this context, one of the most important responses is reskilling: the ability to learn new skills and adapt to ongoing market transformations. Developing capabilities in areas such as AI, data, cloud, infrastructure, cloud computing, DevOps and security will be critical in the coming years for those who want to remain relevant and grow professionally.

However, technical training, while necessary, is not sufficient on its own. It is equally essential to develop a deep understanding of the industries where technology is applied: understanding the real challenges organizations face, identifying the most appropriate solutions for each context, and being able to design realistic implementation paths. In this sense, training in project management, agile methodologies, and research and development practices is not an optional complement, but a core component of the professional profile the market will demand.

As Meirav Oren, CEO and co-founder of Versatile, noted during the World Economic Forum:

This insight points to a well-documented phenomenon: many women tend to apply for new positions only when they feel they meet all the requirements, whereas men often apply when they meet only part of them. This is not a difference in capability, but rather a reflection of how the environment has shaped confidence and risk perception.

For this reason, fostering environments where women can take on challenges, learn through the process, and make their work visible is just as important as any technical training program.

Systemic barriers in transition: the added impact of AI

When viewed together, what emerges is not a list of isolated issues, but a system of barriers that reinforce one another. The broken rung reduces, from the outset, the number of women who enter leadership, while non-promotable work consumes the time and energy that could otherwise be invested in building visibility and career progression.

And to this already complex system, we must now add a new and accelerating force: artificial intelligence.

AI is redefining skills, roles, and organizational dynamics. As new opportunities emerge, others evolve or transform at an increasing pace.

However, this transformation also presents a specific challenge for women's participation in technology. In many teams, women have historically had stronger representation in areas such as design, user experience, and product management. According to McKinsey, women represent approximately 53% of design roles and 39% of product management positions [2].

These same areas are among those most affected by the adoption of AI-driven tools. In particular, early-career roles are already showing signs of decline, with a 3% decrease in design and a 2% decrease in product roles between 2024 and 2025 [2].

This does not mean these roles will disappear, but rather that they are evolving rapidly and demanding new technical and strategic capabilities. Entry-level profiles, in particular, face greater challenges, as they require structured support, continuous learning, and real opportunities to adapt.

In this context, the risk is not technological but structural: if women do not have equitable access to reskilling, upskilling, and leadership opportunities within these transformations, the gap may widen even further in the coming years.

None of these dynamics operate in isolation. Rather, it is their combination that explains why, despite the growing number of women entering the technology sector, representation in leadership roles remains so limited.

And precisely because the problem is systemic, the solutions must be as well.

Building the future of technology is also a matter of diversity

Technological progress opens up enormous opportunities for society, but it also raises a question we cannot ignore: who is designing the systems we will use in the future?

Algorithms, digital platforms, and artificial intelligence systems are not neutral. They are shaped by the decisions, experiences, and contexts of those who build them.

In software architecture, there is a principle known as Conway’s Law, which states that organizations design systems that mirror their communication structures. Applied to diversity, this means that if technology teams are not diverse — or if communication is hierarchical and limited — those same constraints may be reflected in the solutions we create.

This is not only a matter of equality, but also of innovation, social impact, and the quality of the technology we bring into the world. Diverse teams make better decisions, consider more perspectives, and ultimately build more robust solutions.

March 8 serves as a reminder that, although progress has been made, the path toward equitable participation in technology leadership is still ongoing. And this challenge does not belong to a single day or a single sector: it is part of an ongoing responsibility.

Promoting inclusion, supporting the professional development of women in technology, and creating real pathways to leadership are not just goals. They are ways of building teams where different perspectives can coexist and enrich the decisions we shape — now more than ever — in technology.

Because the future of technology will not only be defined by what we build... but by who is given the opportunity to build it.

📚References

[1] Deloitte. (n.d.). Women at work: Global outlook. https://www.deloitte.com/global/en/issues/work/content/women-at-work-global-outlook.html
[2] McKinsey & Company. (n.d.). Women in tech and AI in Europe: Can the region close its gender gap? https://www.mckinsey.com/capabilities/mckinsey-technology/our-insights/women-in-tech-and-ai-in-europe-can-the-region-close-its-gender-gap#/
[3] Fortune. (2025, June 2). Fortune 500 female CEOs 2025. https://fortune.com/2025/06/02/fortune-500-female-ceos-2025/
[4] Women’s Power Gap. (2025). CEO report 2025. https://www.womenspowergap.org/wp-content/uploads/2025/05/WPG_CEO-Report_2025.pdf
[5] Council of the European Union. (n.d.). The EU’s gender pay gap: Facts and figures. https://www.consilium.europa.eu/en/policies/the-eu-s-gender-pay-gap-facts-and-figures/
[6] Euronews. (2026, March 8). Why women are disappearing from Europe’s tech workforce. https://www.euronews.com/next/2026/03/08/why-women-are-disappearing-from-europes-tech-workforce
[7] The Guardian. (2022, May 9). They feel guilty: Why women should say no to office housework. https://www.theguardian.com/society/2022/may/09/they-feel-guilty-why-women-should-say-no-to-office-housework
[8] World Economic Forum. (2025, June). What to know about AI and the gender gap. https://www.weforum.org/stories/2025/06/amnc25-what-to-know-about-ai-and-the-gender-gap/
[9] KPMG. (2025). Global female leaders outlook 2025. https://assets.kpmg.com/content/dam/kpmgsites/pt/pdf/kpmg-global-female-leaders-outlook-2025.pdf.coredownload.inline.pdf

AI in healthcare: how OpenAI is transforming medical care

Romina Elena Mendez Escobar — Mon, 19 Jan 2026 10:17:37 +0000

Introduction
Artificial intelligence is increasingly being adopted in highly regulated industries, and healthcare is a clear example of how this technology can improve processes, access to information, and the quality of care.
According to OpenAI’s latest product announcements, more than 230 million people worldwide use ChatGPT every week to ask questions related to health and wellbeing. This growing adoption reflects a broader shift in how individuals and professionals seek medical information and support.

Healthcare systems face significant challenges: clinical staff are often overwhelmed, medical knowledge is highly fragmented, and administrative complexity continues to grow. AI is beginning to address these issues by supporting decision-making, reducing operational burdens, and making medical information more accessible.

This month, OpenAI introduced new healthcare-focused capabilities designed to support both medical professionals and patients. These services aim to bring trusted information and care-related workflows closer to people, while prioritizing security, compliance, and responsible use in one of the most sensitive and regulated industries.

OpenAI for Healthcare: Operationalizing AI in Healthcare Organizations

OpenAI for Healthcare is specifically designed for healthcare organizations such as hospitals, research centers, clinic networks, and integrated health systems. Its primary goal is to provide a secure, enterprise-grade platform that enables these institutions to deliver more consistent, high-quality care, while reducing the administrative burden that consumes a significant amount of clinicians’ time.

One of the platform’s most distinctive capabilities is its evidence retrieval with clear citations. Responses are grounded in trusted medical sources, including millions of peer-reviewed studies, public health guidelines, and up-to-date clinical directives. This allows healthcare professionals to verify information more easily and support clinical decisions with reliable, evidence-based insights.

Another particularly valuable feature is the use of reusable templates to streamline workflows. These shared templates support common tasks such as drafting discharge summaries, patient instructions, clinical letters, and prior authorization requests. As a result, clinical teams spend less time rewriting repetitive documentation and searching for information, while patients benefit from clearer guidance and smoother transitions of care.

image source: https://openai.com/es-419/index/openai-for-healthcare/

Below is an overview of the main capabilities offered by this solution.

ChatGPT Health: A Smarter Way to Understand Your Health

ChatGPT Health is designed for individual users who want to better understand their own health and navigate a complex healthcare system. Health is already one of the most popular topics on ChatGPT, because every week, users ask questions about health and wellbeing.

Users can securely connect personal health data from multiple sources, including electronic health records and wellness apps. They can also upload their own documents or images, such as lab results or medical reports. This centralization allows ChatGPT Health to provide more relevant, personalized responses, helping users interpret information, summarize results, and prepare for appointments.

The tool is designed for practical, everyday use. It can help users review lab results, prepare questions for medical visits, provide guidance on diet, exercise, or wellness routines, and support understanding of insurance options based on personal health habits. It also includes features like voice input, dictation, and advanced search, making the experience more accessible and tailored to individual needs.

image source: https://openai.com/es-ES/index/introducing-chatgpt-health/

Below is an overview of the types of data sources users can integrate with ChatGPT Health.

Comparative Overview

A side-by-side look at how OpenAI for Healthcare and ChatGPT Health support clinical teams and individual users with AI-driven health insights.

Conclusion

The introduction of AI in healthcare is showing real potential, not only as a tool to support clinical workflows, but also as a way to provide reliable information and guidance to people who may not have easy access to specialized care. OpenAI for Healthcare and ChatGPT Health represent a major step forward in applying AI to one of the most regulated and sensitive industries.

Currently, these tools are limited in availability: OpenAI for Healthcare serves select institutions, and ChatGPT Health operates through a waitlist. How and when these solutions expand to smaller clinics, rural areas, or other countries will be key in determining their ability to truly democratize access to high-quality health support.

Healthcare is constantly evolving, with new scientific evidence, clinical guidelines, and regulatory updates. AI solutions like these can help by keeping pace with these changes, providing relevant and accurate information over time.

While AI will not replace healthcare professionals, these tools offer opportunities to reduce administrative burdens, improve efficiency, and empower both clinicians and patients with personalized insights. By making healthcare more accessible, understandable, and responsive, AI can complement human care, helping to achieve better outcomes while supporting professionals rather than replacing them.

📚Referencias

OpenAI. (2025). OpenAI for Healthcare. OpenAI. https://openai.com/es-419/index/openai-for-healthcare/
OpenAI. (2025). Introducing ChatGPT Health. OpenAI. https://openai.com/es-ES/index/introducing-chatgpt-health

📌 How to cite this article

APA style

Mendez Escobar, Romina Elena. (2025). AI in healthcare: how OpenAI is transforming medical care.

https://dev.to/r_elena_mendez_escobar/ai-in-healthcare-how-openai-is-transforming-medical-care-ffn

BibTeX


text
@article{mendez2025aihealthcare,
  title  = {AI in healthcare: how OpenAI is transforming medical care},
  author = {Mendez Escobar, Romina Elena},
  year   = {2025},
  url    = {https://dev.to/r_elena_mendez_escobar/ai-in-healthcare-how-openai-is-transforming-medical-care-ffn}
}

DEV Community: Romina Elena Mendez Escobar

Automated API Load Testing on AWS: Grafana k6 and AI-Powered Reporting with Amazon Bedrock

1. Introduction

2. Understanding Site Reliability Engineering (SRE)

2.1. What Is SRE?

2.2. Seven Principles of SRE

2.3. Capacity Planning and Performance

2.4. SLI, SLO, and SLA

3. Grafana k6: A Tool for Performance Testing

3.1. Types of Load Tests

3.2. Main Components of k6

4. Architecture

5. Use Case: Automated Load Testing

5.1. The Repository

RominaElenaMendezEscobar / game-catalog-k6

⚡ Automated API Load Testing on AWS: Grafana k6 and AI-Powered Reporting with Amazon Bedrock

🎯 What it does

5.2. Configuring Tests for Another API

1. Identify the API: api_id

2. Define the Requests: queries.json

3. Configure the Load: scenarios

5.3. Deploying the Infrastructure with Terraform

1. Install Terraform (First Time Only)

2. Create the Infrastructure

5.4. Running a Load Test

Generated by k6 (RunLoadTest):

5.5. Report Generation

6. Conclusions

References

Identical or Similar? AI-Powered Product Matching with Amazon Bedrock and S3 Vectors

1. Introduction

2. The Business Problem

What consequences can this have for a product catalog?

3. How Do We Manage Product Information?

3.1. 🗂️ What Is a PIM?

4. MVP Design Principles

1. A public, realistic dataset.

2. A limited scope based on an external criterion.

3. Cost as a design variable.

4. Rules first, AI where it adds value.

5. Explicit business criteria.

6. A pipeline to evaluate, not a finished system.

5. Architecture

🟩 Storage

🟨 Compute / AI

🟪 Pipeline

🟥 Security

🟦 Logs

6. Use Case Development

6.1. 🔍 What Is EDA?

🎯 Why is it important?

🤖 And what about generative AI projects?

6.2. ☁️ Infrastructure Deployment

🧰 Prerequisites

RominaElenaMendezEscobar / aws-games-products

A serverless AI solution on AWS to identify similar products and distinguish duplicates, variants, and different items using Amazon Bedrock, embeddings, business rules, and S3 Vectors.

🎮 Identical or Similar? AI-Powered Product Matching with Amazon Bedrock and S3 Vectors

📊 Results at a glance

📁 Repository Structure

6.2.1. 🟩 Storage

6.2.1.1 Amazon S3 · game-catalog-dedup

6.2.1.2 Amazon S3 Vectors · game-catalog-vectors / index games-v2

6.2.1.3 Amazon DynamoDB · game-catalog-products

6.2.2. 🟥 Permissions and Configuration

6.2.3. 🟪 Lambda Functions

6.2.4. 🟪 Step Functions · game-catalog-dedup-pipeline

6.2.5. 📥 Upload the Raw Data

6.3. 🛠️ Data Preparation

6.3.1. 🧹 Data Cleaning and Filtering (ETL)

6.3.2. 🎯 Why the 20 Best-Selling Video Game Franchises?

6.3.3. 📦 Storing Each Stage's Results Separately

6.4. 🧠 Prompt Design and Evaluation

6.4.1. 📋 What Do We Expect from AI?

6.4.2. ✂️ Two Prompts for Two Different Tasks

6.4.2.1. How Do We Invoke a Model from AWS Lambda?

6.4.2.2. SYSTEM_PROMPT: Product Normalization (Nova Micro)

6.4.2.3. DECISION_PROMPT: Candidate Pair Comparison (Nova Lite)

6.4.3. 🏗️ How I Built the Extraction Prompt

6.4.4. 🧪 Testing Plan in Amazon Bedrock

🤖 Model Comparison

1. Identify the API: `api_id`

3. Configure the Load: `scenarios`

6.2.1.1 Amazon S3 · `game-catalog-dedup`

6.2.1.2 Amazon S3 Vectors · `game-catalog-vectors / index games-v2`

6.2.1.3 Amazon DynamoDB · `game-catalog-products`

6.2.4. 🟪 Step Functions · `game-catalog-dedup-pipeline`