DEV Community: Datalaria

Fine-Tuning vs Prompt Engineering vs RAG: When to Use Each (And the Fourth Option Nobody Mentions)

Daniel — Sun, 09 Aug 2026 14:32:58 +0000

You have an AI model that hallucinates with your company's data. You open a support ticket and ask the chatbot about your returns policy. The chatbot, powered by GPT-4 or Gemini 2.5, responds with a fabricated policy that sounds perfectly plausible but has nothing to do with your company's reality. Your boss stares at you. Your customer complains. You open Google and search "how to connect LLM to my data".

The top 10 results offer three contradictory answers: "use RAG," "do fine-tuning," "improve your prompt." All three are right. All three are wrong. Because the correct answer isn't any of the three in the abstract — it's the one that fits your specific use case. And there's a fourth option that almost nobody mentions, and which, in my experience, is the right call in more cases than the industry admits.

This article is the decision tree I wish I'd had when I started building the AI systems behind this blog. I've distilled it after implementing all four techniques in real production: Prompt Engineering across the entire Autopilot series, RAG in the Ops Copilot with Algolia, pure Tool Calling in the Obsolescence Radar, and experimental fine-tuning in industrial classification pipelines. It closes the trilogy that began with RAG: 7 Anti-Patterns and continued with MCP Protocol.

The Question Nobody Asks

Before choosing a technique, ask yourself this: Does the knowledge your LLM needs change, or is it static?

If the answer is "it changes frequently" (product documentation, inventory, prices, regulations), you need a technique that accesses data in real time without retraining the model. If the answer is "it's static or changes very slowly" (brand tone, formatting rules, domain nomenclature), you can consider techniques that incorporate that knowledge into the model.

This distinction is the first node of the decision tree. It seems obvious written this way. Yet most teams I've seen jump straight to whatever technique is trending (RAG in 2024, fine-tuning in 2023, prompt engineering always) without asking this fundamental question.

Option 1: Prompt Engineering — 80% of Cases

The uncomfortable truth the AI tooling industry doesn't want you to know: for 80% of use cases, a well-designed prompt is sufficient. You don't need RAG. You don't need fine-tuning. You need a system prompt that clearly defines the role, context, constraints, and expected output format.

When it's sufficient:

The required knowledge fits in the model's context window (Gemini 2.5 handles up to 1 million tokens; Claude up to 200K).
The task is generic but needs structure (drafting emails, summarizing documents, classifying text, generating code).
You don't need updated proprietary data — the model's general knowledge is enough.

Advanced techniques that make the difference:

Structured system prompts: Define the role ("You are a senior supply chain engineer"), constraints ("Always respond in technical English"), and output format ("Return a JSON with fields: analysis, recommendation, confidence").
Few-shot prompting: Include 3-5 correct input-output examples in the prompt. In the Autopilot series, CrewAI agents use few-shot to maintain style consistency across generated articles.
Chain-of-thought (CoT): Instruct the model to "think step by step" before giving the final answer. Dramatically improves accuracy in reasoning, calculation, and multi-step analysis tasks.
Prompt chaining: Break complex tasks into sequential subtasks, each with its own optimized prompt. This is exactly what CrewAI does with its agent architecture: each agent has a specialized prompt for its role.

Cost: Virtually zero (only API token cost). A well-designed prompt can take hours of iteration, but operational cost is minimal.

Fatal limitation: The context window has a limit. If you need the model to "know" about 10,000 documents from your knowledge base, you can't inject them all into the prompt. This is where RAG enters.

Option 2: RAG — Updatable Proprietary Knowledge

RAG (Retrieval-Augmented Generation) is the right answer when you need the LLM to respond about your proprietary knowledge and that knowledge updates frequently.

When it's necessary:

Product documentation, technical manuals, internal knowledge bases that update weekly or monthly.
The user can ask unpredictable questions about a broad document corpus (you don't know in advance which fragment the LLM will need).
You need citability: the answer must include the sources it draws from (critical for compliance, as we documented in the EU AI Act, Article 13 on transparency).

When NOT to use it: When data is structured (SQL tables, APIs with defined schemas) or when you need numerical precision. As I extensively documented in Anti-Pattern 7 of the RAG article, RAG over structured data generates narrative hallucinations where you need exact figures.

Correct architecture (summarized):

Semantic chunking (not fixed-length — Anti-Pattern 1)
Evaluated embeddings with your domain benchmark (Anti-Pattern 2)
Reranking between retriever and LLM (Anti-Pattern 3)
Generous context (top-10/15, not top-3 — Anti-Pattern 4)
Evaluation with RAGAS/DeepEval before production (Anti-Pattern 6)

Real cost: Moderate. The vector store (Pinecone, Weaviate, Algolia) has a monthly cost (€0-100 depending on volume), plus embedding cost (low) and generation cost (API tokens). In the Ops Copilot, the total RAG cost with Algolia was under €3/month for the blog's ~70 posts.

Real case at Datalaria: The Ops Engineering Copilot (Autopilot Part 8) uses RAG with Algolia Agent Studio to answer questions about blog content. Posts are indexed as semantic records (one record per section), and the copilot retrieves relevant fragments before generating the response. Works well for semantic search over free text.

Option 3: Fine-Tuning — The Scalpel, Not the Hammer

Fine-tuning is the most powerful technique and the most misused. It involves partially retraining a base model (Gemini, Llama, Mistral) with your own data so the model internalizes specific knowledge, style, or behavior.

When it's essential:

You need the model to adopt a very specific tone or style consistently (a brand with strict voice & tone, a domain with very particular technical jargon).
The task is highly specialized and generalist models don't solve it well even with advanced prompting (industrial defect classification, proprietary nomenclature entity extraction, specialized medical diagnosis).
You need to reduce latency and cost in production: a fine-tuned smaller model (7B-13B parameters) can match the quality of a large model (70B+) on your specific task, at a fraction of the cost and latency.

When NOT to use it (the most widespread myth):

Don't use fine-tuning to "teach the model data." Fine-tuning is not a database. If you need the model to know your product catalog, use RAG. Fine-tuning "burns in" behavioral patterns, not updatable facts.
Don't use fine-tuning if your knowledge changes frequently. Each update requires retraining, which can cost hours and hundreds of euros. RAG is instant: update the document and the retriever finds it immediately.

Modern tools:

LoRA (Low-Rank Adaptation): The standard technique. Instead of retraining the model's billions of parameters, LoRA trains only low-rank matrices "attached" to the model's layers. Reduces training cost by 90%+ and stores the fine-tuned model as a few MB of "adapters."
QLoRA: LoRA applied to a 4-bit quantized model. Enables fine-tuning 70B-parameter models on a single consumer GPU (24GB VRAM). Democratized fine-tuning for startups and teams without GPU clusters.
Vertex AI Tuning / OpenAI Fine-Tuning API: Managed services where you upload your training dataset (instruction-response pairs) and the platform runs the fine-tuning without you managing GPU infrastructure.

Real cost: Variable. Fine-tuning with LoRA on a 7B-parameter model with 10,000 examples costs €5-20 on cloud (Google Cloud, AWS). A 70B model can cost €50-200 per training session. Plus the cost of preparing the dataset (hours of human work). As we analyzed in The Hidden Economics of AI, fine-tuning's hidden cost isn't compute — it's training dataset curation.

Option 4: Tool Calling / MCP — The One Nobody Mentions

This is the option I discovered by elimination after RAG failed spectacularly on the Obsolescence Radar. Tool Calling means the LLM doesn't try to "know" the answer; instead, it knows who to ask — that is, which tool to execute to get the information with deterministic precision.

When it's the right option:

Data is structured (SQL databases, REST APIs, spreadsheets with schemas).
You need absolute numerical precision (financial calculations, inventory metrics, sensor data).
The operation requires actions, not just answers (create a ticket, send an email, run a query, call an external API).
You want to standardize connections between the LLM and tools to avoid vendor lock-in — exactly the problem solved by MCP (Model Context Protocol).

Architecture: The LLM (Gemini 2.5, Claude) acts as a semantic orchestrator: it understands the user's natural language intent, decides which tool(s) to execute, constructs the parameters, executes the tool(s), and interprets results for the user. Tools are deterministic Python functions (decorated with @tool in CrewAI) that execute precision operations: SQL queries to Supabase, supplier API calls, linear programming calculations with PuLP.

Cost: The lowest of all four options. You only pay for LLM tokens (typically few, since the prompt is short) and tool execution (SQL queries, API calls). In the Obsolescence Radar, the cost per complete execution (analyze a component, traverse the BOM graph, calculate financial impact, generate executive report) was under €0.02 per query.

Real case at Datalaria: The Agentic Obsolescence Radar uses Tool Calling exclusively. The LLM (Gemini 2.5 via CrewAI) understands the obsolescence alert in natural language, but all data operations — SQL query to the component catalog, BOM graph traversal, P&L calculation, PDF generation — are executed by deterministic Python tools. Result: executive reports in 4 seconds with 0% numerical hallucination.

The Decision Matrix

Criterion	Prompt Engineering	RAG	Fine-Tuning	Tool Calling
Initial cost	⭐ Minimal	⭐⭐ Low-medium	⭐⭐⭐ High	⭐⭐ Low
Operational cost	⭐ Low	⭐⭐ Medium	⭐ Low (small model)	⭐ Minimal
Precision (free text)	⭐⭐ Medium	⭐⭐⭐ High	⭐⭐⭐ Very high	⭐ N/A
Precision (structured data)	⭐ Low	⭐ Low	⭐ Low	⭐⭐⭐ Exact
Data freshness	⭐⭐⭐ Instant	⭐⭐⭐ Instant	⭐ Requires retraining	⭐⭐⭐ Real-time
Implementation effort	⭐ Hours	⭐⭐ Days-weeks	⭐⭐⭐ Weeks-months	⭐⭐ Days
Maintenance	⭐ Minimal	⭐⭐ Medium	⭐⭐⭐ High (data drift)	⭐⭐ Medium
Traceability (EU AI Act)	⭐ Difficult	⭐⭐⭐ High (citable sources)	⭐ Opaque (black box)	⭐⭐⭐ Total (deterministic)
Ideal use case	Generic tasks with clear instructions	Updatable proprietary text knowledge	Specific style/tone, ultra-specialized tasks	Structured data, numerical precision, actions

The 3-Question Framework

If the matrix seems dense, I've distilled a 3-question framework that resolves 90% of decisions:

Question 1: Does the data the LLM needs fit in the prompt?

Yes → Prompt Engineering. Inject context directly. Simpler, cheaper, faster.
No → Next question.

Question 2: Is the data free text or structured?

Free text (documentation, manuals, posts) → RAG. Semantic retrieval is superior for searching unstructured text.
Structured (SQL, APIs, tables, calculations) → Tool Calling. Deterministic tools that execute exact queries.
Both → Hybrid architecture (RAG for textual context + Tool Calling for structured data, as we proposed in the RAG article).

Question 3: Do you need a behavior or style the base model can't reproduce even with the best prompt?

Yes (unique brand tone, ultra-specific domain jargon, task that generalist models consistently fail) → Fine-Tuning on a base model.
No → Go back to Prompt Engineering and refine your prompt before considering more complex techniques.

What I Learned Implementing All Four

The most valuable lesson from operating these four techniques in production fits in a single sentence: always start with the simplest technique that could work.

The temptation is to jump straight to RAG or fine-tuning because they're more "sophisticated." But sophistication doesn't correlate with effectiveness. In the Autopilot, the majority of output quality comes from Prompt Engineering — carefully designed system prompts, few-shot examples, and Chain-of-thought. RAG added marginal value in the Ops Copilot for blog search. Fine-tuning wasn't necessary in any case. And Tool Calling was the transformative technique in the Obsolescence Radar, where RAG had failed.

The evaluation order should always be:

Prompt Engineering (hours, ~€0)
Tool Calling if data is structured (days, ~€0)
RAG if you need access to proprietary text (days-weeks, ~€3-50/month)
Fine-Tuning only if the previous three consistently fail (weeks, €50-500+)

And in the era of the EU AI Act, there's a fifth consideration that isn't technical but legal: traceability. Article 10 of the regulation requires that training data for high-risk systems be "relevant, representative, and to the extent possible, free of errors and complete." This applies directly to fine-tuning: if you fine-tune a model with biased or incorrect data, and that model makes decisions in a regulated domain, you're exposed to sanctions. RAG and Tool Calling, being transparent in their sources, offer traceability that fine-tuning cannot match.

As we wrote in The Hidden Economics of AI, the 10x Rule applies: if a more complex technique doesn't give you a result 10 times better than the previous one, it probably doesn't justify its added cost and complexity. Start simple. Measure. Scale only when the data demands it.

Sources of Interest:

Fine-Tuning vs Prompt Engineering vs RAG: Cuándo Usar Cada Uno (y la Cuarta Opción que Nadie Menciona)

Daniel — Sun, 09 Aug 2026 14:28:43 +0000

Tienes un modelo de IA que alucina con los datos de tu empresa. Abre un ticket de soporte y le pides al chatbot que responda sobre tu política de devoluciones. El chatbot, alimentado por GPT-4 o Gemini 2.5, responde con una política inventada que suena perfectamente plausible pero no tiene nada que ver con la realidad de tu empresa. Tu jefe te mira. Tu cliente se queja. Tú abres Google y buscas "cómo conectar LLM a mis datos".

Los primeros 10 resultados te ofrecen tres respuestas contradictorias: «usa RAG», «haz fine-tuning», «mejora tu prompt». Los tres tienen razón. Los tres están equivocados. Porque la respuesta correcta no es ninguna de las tres en abstracto — es la que encaja con tu caso de uso específico. Y hay una cuarta opción que casi nadie menciona y que, en mi experiencia, es la correcta en más casos de los que la industria admite.

Este artículo es el árbol de decisión que ojalá hubiera tenido cuando empecé a construir los sistemas de IA de este blog. Lo he destilado después de implementar las cuatro técnicas en producción real: Prompt Engineering en toda la serie Autopilot, RAG en el Ops Copilot con Algolia, Tool Calling puro en el Radar de Obsolescencia, y fine-tuning experimental en pipelines de clasificación industrial. Cierra la trilogía que empezó con RAG: 7 Antipatrones y continuó con MCP Protocol.

La Pregunta que Nadie Se Hace

Antes de elegir una técnica, hazte esta pregunta: ¿El conocimiento que necesita tu LLM cambia o es estático?

Si la respuesta es «cambia frecuentemente» (documentación de producto, inventario, precios, regulaciones), necesitas una técnica que acceda a datos en tiempo real sin reentrenar el modelo. Si la respuesta es «es estático o cambia muy lento» (tono de marca, reglas de formato, nomenclatura de dominio), puedes considerar técnicas que incorporen ese conocimiento al modelo.

Esta distinción es el primer nodo del árbol de decisión. Parece obvia escrita así. Sin embargo, la mayoría de los equipos que he visto saltan directamente a la técnica que está de moda (RAG en 2024, fine-tuning en 2023, prompt engineering siempre) sin hacerse esta pregunta fundamental.

Opción 1: Prompt Engineering — El 80% de los Casos

La verdad incómoda que la industria del tooling de IA no quiere que sepas: para el 80% de los casos de uso, un prompt bien diseñado es suficiente. No necesitas RAG. No necesitas fine-tuning. Necesitas un system prompt que defina claramente el rol, el contexto, las restricciones y el formato de salida esperado.

Cuándo es suficiente:

El conocimiento necesario cabe en la ventana de contexto del modelo (Gemini 2.5 maneja hasta 1 millón de tokens; Claude hasta 200K).
La tarea es genérica pero necesita estructura (redactar emails, resumir documentos, clasificar textos, generar código).
No necesitas datos propietarios actualizados — el conocimiento general del modelo basta.

Técnicas avanzadas que marcan la diferencia:

System Prompts estructurados: Define el rol («Eres un ingeniero de supply chain senior»), las restricciones («Responde siempre en español técnico»), y el formato de salida («Devuelve un JSON con los campos: análisis, recomendación, confianza»).
Few-shot prompting: Incluye 3-5 ejemplos de entrada-salida correctos en el prompt. En la serie Autopilot, los agentes de CrewAI usan few-shot para mantener la consistencia de estilo entre artículos generados.
Chain-of-thought (CoT): Instruye al modelo a «pensar paso a paso» antes de dar la respuesta final. Mejora drásticamente la precisión en tareas de razonamiento, cálculo y análisis multi-paso.
Prompt chaining: Divide tareas complejas en subtareas secuenciales, cada una con su propio prompt optimizado. Es exactamente lo que hace CrewAI con la arquitectura de agentes: cada agente tiene un prompt especializado para su rol.

Coste: Prácticamente cero (solo el coste de tokens de la API). Un prompt bien diseñado puede llevar horas de iteración, pero el coste operativo es mínimo.

Limitación fatal: La ventana de contexto tiene un límite. Si necesitas que el modelo «sepa» sobre 10.000 documentos de tu base de conocimiento, no puedes inyectarlos todos en el prompt. Aquí es donde entra RAG.

Opción 2: RAG — Conocimiento Propietario Actualizable

RAG (Retrieval-Augmented Generation) es la respuesta correcta cuando necesitas que el LLM responda sobre tu conocimiento propietario y ese conocimiento se actualiza frecuentemente.

Cuándo es necesario:

Documentación de producto, manuales técnicos, bases de conocimiento internas que se actualizan semanalmente o mensualmente.
El usuario puede hacer preguntas impredecibles sobre un corpus amplio de documentos (no sabes de antemano qué fragmento necesitará el LLM).
Necesitas citabilidad: que la respuesta incluya las fuentes de donde proviene la información (crítico para compliance, como documentamos en el EU AI Act, Artículo 13 sobre transparencia).

Cuándo NO usarlo: Cuando los datos son estructurados (tablas SQL, APIs con esquemas definidos) o cuando necesitas precisión numérica. Como documenté extensamente en el Antipatrón 7 del artículo de RAG, RAG sobre datos estructurados genera alucinaciones narrativas donde necesitas cifras exactas.

Arquitectura correcta (resumida):

Chunking semántico (no por longitud fija — Antipatrón 1)
Embeddings evaluados con benchmark de tu dominio (Antipatrón 2)
Reranking entre el retriever y el LLM (Antipatrón 3)
Contexto generoso (top-10/15, no top-3 — Antipatrón 4)
Evaluación con RAGAS/DeepEval antes de producción (Antipatrón 6)

Coste real: Moderado. El vector store (Pinecone, Weaviate, Algolia) tiene un coste mensual (€0-100 según volumen), más el coste de embeddings (bajo) y el coste de generación (tokens de API). En el Ops Copilot, el coste total de RAG con Algolia fue inferior a €3/mes para los ~70 posts del blog.

Caso real en Datalaria: El Ops Engineering Copilot (Autopilot Part 8) usa RAG con Algolia Agent Studio para responder preguntas sobre el contenido del blog. Los posts se indexan como records semánticos (un record por sección), y el copilot recupera los fragmentos relevantes antes de generar la respuesta. Funciona bien para búsqueda semántica sobre texto libre.

Opción 3: Fine-Tuning — El Bisturí, No el Martillo

Fine-tuning es la técnica más potente y la más mal utilizada. Consiste en reentrenar parcialmente un modelo base (Gemini, Llama, Mistral) con tus propios datos para que el modelo internalice conocimiento, estilo o comportamiento específico.

Cuándo es imprescindible:

Necesitas que el modelo adopte un tono o estilo muy específico de forma consistente (una marca con un voice & tone estricto, un dominio con jerga técnica muy particular).
La tarea es altamente especializada y los modelos generalistas no la resuelven bien ni con prompting avanzado (clasificación de defectos industriales, extracción de entidades de nomenclatura propietaria, diagnóstico médico especializado).
Necesitas reducir latencia y coste en producción: un modelo fine-tuneado más pequeño (7B-13B parámetros) puede igualar la calidad de un modelo grande (70B+) en tu tarea específica, a una fracción del coste y la latencia.

Cuándo NO usarlo (el mito más extendido):

No uses fine-tuning para "enseñarle datos" al modelo. Fine-tuning no es una base de datos. Si necesitas que el modelo conozca tu catálogo de productos, usa RAG. Fine-tuning «graba» patrones de comportamiento, no hechos actualizables.
No uses fine-tuning si tu conocimiento cambia frecuentemente. Cada actualización requiere reentrenar, lo que puede costar horas y cientos de euros. RAG es instantáneo: actualiza el documento y el retriever lo encuentra inmediatamente.

Herramientas modernas:

LoRA (Low-Rank Adaptation): La técnica estándar. En lugar de reentrenar los miles de millones de parámetros del modelo completo, LoRA entrena solo unas matrices de bajo rango «acopladas» a las capas del modelo. Reduce el coste de entrenamiento en un 90%+ y el almacenamiento del modelo fine-tuneado a unos pocos MB de «adaptadores».
QLoRA: LoRA aplicado sobre un modelo cuantizado a 4 bits. Permite fine-tunear modelos de 70B parámetros en una sola GPU de consumo (24GB VRAM). Democratizó el fine-tuning para startups y equipos sin clusters de GPUs.
Vertex AI Tuning / OpenAI Fine-Tuning API: Servicios gestionados donde subes tu dataset de entrenamiento (pares instrucción-respuesta) y la plataforma ejecuta el fine-tuning sin que gestiones infraestructura GPU.

Coste real: Variable. Fine-tuning con LoRA en un modelo de 7B parámetros con 10.000 ejemplos cuesta entre €5-20 en cloud (Google Cloud, AWS). Un modelo de 70B puede costar €50-200 por sesión de entrenamiento. Más el coste de preparar el dataset (horas de trabajo humano). Como analizamos en la Economía Oculta de la IA, el coste oculto del fine-tuning no es el compute — es la curación del dataset de entrenamiento.

Opción 4: Tool Calling / MCP — La que Nadie Menciona

Esta es la opción que descubrí por eliminación después de que RAG fallara estrepitosamente en el Radar de Obsolescencia. Tool Calling significa que el LLM no intenta «saber» la respuesta; en su lugar, sabe a quién preguntarle — es decir, qué herramienta ejecutar para obtener la información con precisión determinista.

Cuándo es la opción correcta:

Los datos son estructurados (bases de datos SQL, APIs REST, hojas de cálculo con esquemas).
Necesitas precisión numérica absoluta (cálculos financieros, métricas de inventario, datos de sensores).
La operación requiere acciones, no solo respuestas (crear un ticket, enviar un email, ejecutar un query, llamar a una API externa).
Quieres estandarizar las conexiones entre el LLM y las herramientas para no quedar atado a un proveedor — exactamente el problema que resuelve MCP (Model Context Protocol).

Arquitectura: El LLM (Gemini 2.5, Claude) actúa como orquestador semántico: entiende la intención del usuario en lenguaje natural, decide qué herramienta(s) ejecutar, construye los parámetros, ejecuta la(s) herramienta(s), e interpreta los resultados para el usuario. Las herramientas son funciones Python deterministas (decoradas con @tool en CrewAI) que ejecutan operaciones de precisión: queries SQL a Supabase, llamadas a APIs de proveedores, cálculos de programación lineal con PuLP.

Coste: El más bajo de las cuatro opciones. Solo pagas los tokens del LLM (típicamente pocos, porque el prompt es corto) y la ejecución de las herramientas (queries SQL, llamadas API). En el Radar de Obsolescencia, el coste por ejecución completa (analizar un componente, cruzar el grafo BOM, calcular impacto financiero, generar reporte ejecutivo) fue inferior a €0.02 por consulta.

Caso real en Datalaria: El Radar Agéntico de Obsolescencia usa exclusivamente Tool Calling. El LLM (Gemini 2.5 vía CrewAI) entiende la alerta de obsolescencia en lenguaje natural, pero todas las operaciones de datos — consulta SQL al catálogo de componentes, cruce del grafo BOM, cálculo del P&L, generación del PDF — las ejecutan herramientas Python deterministas. Resultado: reportes ejecutivos en 4 segundos con 0% de alucinación numérica.

La Matriz de Decisión

Criterio	Prompt Engineering	RAG	Fine-Tuning	Tool Calling
Coste inicial	⭐ Mínimo	⭐⭐ Bajo-medio	⭐⭐⭐ Alto	⭐⭐ Bajo
Coste operativo	⭐ Bajo	⭐⭐ Medio	⭐ Bajo (modelo pequeño)	⭐ Mínimo
Precisión (texto libre)	⭐⭐ Media	⭐⭐⭐ Alta	⭐⭐⭐ Muy alta	⭐ N/A
Precisión (datos estruct.)	⭐ Baja	⭐ Baja	⭐ Baja	⭐⭐⭐ Exacta
Actualización de datos	⭐⭐⭐ Instantánea	⭐⭐⭐ Instantánea	⭐ Requiere reentrenar	⭐⭐⭐ Tiempo real
Esfuerzo de implementación	⭐ Horas	⭐⭐ Días-semanas	⭐⭐⭐ Semanas-meses	⭐⭐ Días
Mantenimiento	⭐ Mínimo	⭐⭐ Medio	⭐⭐⭐ Alto (data drift)	⭐⭐ Medio
Trazabilidad (EU AI Act)	⭐ Difícil	⭐⭐⭐ Alta (fuentes citables)	⭐ Opaca (caja negra)	⭐⭐⭐ Total (determinista)
Caso de uso ideal	Tareas genéricas con instrucciones claras	Conocimiento propietario textual, actualizable	Estilo/tono específico, tareas ultra-especializadas	Datos estructurados, precisión numérica, acciones

El Framework de 3 Preguntas

Si la matriz te parece densa, he destilado un framework de 3 preguntas que resuelve el 90% de las decisiones:

Pregunta 1: ¿Los datos que necesita el LLM caben en el prompt?

Sí → Prompt Engineering. Inyecta el contexto directamente. Es más simple, más barato, más rápido.
No → Siguiente pregunta.

Pregunta 2: ¿Los datos son texto libre o estructurados?

Texto libre (documentación, manuales, posts) → RAG. El retrieval semántico es superior para buscar en texto no estructurado.
Estructurados (SQL, APIs, tablas, cálculos) → Tool Calling. Herramientas deterministas que ejecutan queries exactos.
Ambos → Arquitectura híbrida (RAG para el contexto textual + Tool Calling para los datos estructurados, como propusimos en el artículo de RAG).

Pregunta 3: ¿Necesitas un comportamiento o estilo que el modelo base no reproduce ni con el mejor prompt?

Sí (tono de marca único, jerga de dominio ultra-específica, tarea que los modelos generalistas fallan consistentemente) → Fine-Tuning sobre un modelo base.
No → Vuelve a Prompt Engineering y afina tu prompt antes de considerar técnicas más complejas.

Lo que Aprendí Implementando las Cuatro

La lección más valiosa que me dejó la experiencia de operar estas cuatro técnicas en producción se resume en una frase: empieza siempre por la técnica más simple que podría funcionar.

La tentación es ir directamente a RAG o fine-tuning porque son más «sofisticados». Pero la sofisticación no correlaciona con la efectividad. En el Autopilot, la mayor parte de la calidad del output proviene del Prompt Engineering — system prompts cuidadosamente diseñados, few-shot examples, y Chain-of-thought. RAG añadió valor marginal en el Ops Copilot para búsqueda en el blog. Fine-tuning no fue necesario en ningún caso. Y Tool Calling fue la técnica transformadora en el Radar de Obsolescencia, donde RAG había fracasado.

El orden de evaluación debería ser siempre:

Prompt Engineering (horas, ~€0)
Tool Calling si los datos son estructurados (días, ~€0)
RAG si necesitas acceso a texto propietario (días-semanas, ~€3-50/mes)
Fine-Tuning solo si las tres anteriores fallan consistentemente (semanas, €50-500+)

Y en la era del EU AI Act, hay una quinta consideración que no es técnica sino legal: la trazabilidad. El Artículo 10 del reglamento exige que los datos de entrenamiento de sistemas de alto riesgo sean «pertinentes, representativos, y en la medida de lo posible, exentos de errores y completos». Esto aplica directamente al fine-tuning: si fine-tuneas un modelo con datos sesgados o incorrectos, y ese modelo toma decisiones en un ámbito regulado, estás expuesto a sanciones. RAG y Tool Calling, al ser transparentes en sus fuentes, ofrecen una trazabilidad que fine-tuning no puede igualar.

Como escribimos en la Economía Oculta de la IA, la Regla del 10x aplica: si una técnica más compleja no te da un resultado 10 veces mejor que la anterior, probablemente no justifica su coste y complejidad adicional. Empieza simple. Mide. Escala solo cuando los datos lo exijan.

Fuentes de Interés:

An Engineer's Productivity Stack in 2026: The Tools I Use Every Day

Daniel — Sat, 01 Aug 2026 18:48:01 +0000

After more than 60 articles, 9 technical series, 4 production applications, and a bilingual blog that generates weekly content, I get asked the same question over and over: "What tools do you use?" Not what tools I recommend, not what tools are trending, but which ones I actually use, every single day, to build what you see on Datalaria.

This article is the answer. No sponsorships, no affiliate links, no filters. Every tool listed here has been tested in production, paid for (or not) with my own money, and documented in at least one post on this blog. If I haven't used it in a real project, it's not on this list.

The Workflow: 10 Phases, 10 Tools

The key to my productivity isn't in individual tools but in how they fit together. Each workflow phase feeds the next, and the output of one tool is the input of another. No silos; it's a pipeline.

Phase	Tool	Why this one
🧠 Think	Gemini Deep Research	Exhaustive research in minutes
✍️ Write	Hugo + VS Code + Markdown	Full control, Git-native, speed
💻 Code	Python + Pandas + FastAPI	The data engineering trident
🗄️ Store	Supabase (PostgreSQL)	Free BaaS, RLS, automatic REST APIs
🤖 Orchestrate AI	CrewAI + Gemini 2.5	Autonomous agents with Tool Calling
⚙️ Automate	GitHub Actions	Free CI/CD, event-driven
🚀 Deploy	Netlify	Deploy from Git in seconds
📧 Communicate	Brevo (Newsletter)	Free email marketing, API, segmentation
📊 Visualize	Chart.js + Vanilla JS	Lightweight, no heavy frameworks, interactive
📚 Learn	NotebookLM	Transforms any source into study resources

🧠 Think: Gemini Deep Research

Before writing a single line, I research. And this is where generative AI has radically changed my workflow. Gemini Deep Research (within Gemini Advanced) is the tool I use for exhaustive research before every article and every technical project.

When I was preparing the article on Thomas Bayes, I needed to verify dates, publications, historical context of the Royal Society, and the precise mathematical connection between Bayes' theorem and Facebook Prophet. What previously would have required hours of browsing through Wikipedia, Stanford Encyclopedia of Philosophy, and academic papers, Gemini Deep Research compiled into a structured report in under 10 minutes, with verifiable citations and sources.

The key: I don't use it to write; I use it to research. The final text is always mine. Gemini gives me the raw material; I build the narrative. I documented this approach in detail in AI in Education with Deep Research.

✍️ Write: Hugo + VS Code + Markdown

Everything you see on Datalaria is written in pure Markdown, edited in VS Code, compiled with Hugo, and versioned in Git. Zero WordPress, zero visual CMS, zero drag-and-drop.

Why this seemingly masochistic decision? Because a Hugo blog is code. I can run git diff to see what I changed in an article. I can run git blame to know when I changed it. I can fork, create a branch, experiment with a new structure, and merge only if it works. And I can automate deployment with a git push. I documented all these architectural decisions in Building Datalaria.

Hugo compiles the 700+ pages of this blog (Spanish + English) in under 4 minutes. A traditional CMS would take several seconds just to render a single page. When you iterate fast, compilation speed isn't a luxury; it's a necessity.

💻 Code: Python + Pandas + FastAPI

The trident I use for absolutely everything involving data:

Python as the base language. No debate. The library ecosystem for data engineering, ML, and automation has no rival.
Pandas for data manipulation, cleaning, and transformation. Every pipeline in the S&OP series — from sales data ingestion to forecast generation with Prophet — goes through Pandas.
FastAPI when I need to expose a service as a REST API. We used it in Part 6 of the Observability series to build the obsolescence radar backend, and in the OpenWeather app as a weather prediction backend.

🗄️ Store: Supabase (PostgreSQL)

Supabase is managed PostgreSQL with superpowers: authentication, Row Level Security (RLS), automatic REST APIs generated from the database schema, and a free tier that covers 95% of my development and prototyping needs.

I use it as the data backend in the Observability series (storing the component catalog, obsolescence alerts, and BOM graphs), in the S&OP pipelines (demand data, forecasts, production plans), and in the Snake game with a global leaderboard.

Why Supabase over Firebase? Because Supabase is real PostgreSQL. I can write native SQL, create materialized views, use complex JOINs, and migrate to any other managed PostgreSQL (RDS, Cloud SQL) without changing a single line of code. Firebase traps you in its proprietary ecosystem; Supabase includes the exit door.

🤖 Orchestrate AI: CrewAI + Gemini 2.5

When I need AI to not just answer questions but execute complex multi-step tasks, I use CrewAI as the agent orchestration framework. Each agent has a role, an objective, specific Python tools (decorated with @tool), and the ability to coordinate with other agents.

Gemini 2.5 Pro/Flash is the LLM powering the agents. The CrewAI + Gemini + Tool Calling combination is the architecture documented across the entire 9-part Autopilot series, from the automatic content generator to the Ops Copilot.

As we analyzed in the RAG vs. Tool Calling article, the key is separating the "semantic brain" (the LLM understands context) from the "deterministic muscle" (Python tools execute precision operations). The LLM thinks; the tools do.

⚙️ Automate: GitHub Actions

Every CI/CD pipeline at Datalaria runs on GitHub Actions. It's free for public repositories, event-driven (triggers on push, cron, webhook), and flexible enough to orchestrate everything from Hugo compilation to CrewAI pipeline execution.

In Autopilot Part 5, we documented how to configure a GitHub Actions workflow that runs the complete agentic pipeline every week: generates content with CrewAI, creates Markdown files, commits, pushes, and automatically deploys to Netlify. All without human intervention.

🚀 Deploy: Netlify

Netlify deploys Datalaria directly from the GitHub repository. Every git push to the main branch triggers a Hugo build and publishes the site in seconds. Features like Netlify Functions (serverless), redirects, and custom headers cover everything I need without managing servers.

We documented it in OpenWeather app Part 2 as the deployment platform for frontend applications with serverless backends.

📧 Communicate: Brevo (Newsletter)

Datalaria's newsletter uses Brevo (formerly Sendinblue). Generous free tier (300 emails/day), REST API for automation, audience segmentation, and a template editor.

In Autopilot Part 6, we documented how the CrewAI pipeline generates email content, builds the HTML, and sends it automatically via Brevo's API — closing the complete generation → publication → distribution cycle without manual intervention.

📊 Visualize: Chart.js + Vanilla JS

When I need interactive charts in web apps, I use Chart.js with vanilla JavaScript. No React, no Vue, no heavy frameworks. The philosophy is intentional: every library you add is a dependency to maintain, an attack surface to protect, and a bundle to inflate.

OpenWeather app Part 4 and Basic Visualizations demonstrate that Chart.js + pure CSS produces professional-quality interactive dashboards without needing a 200KB framework.

📚 Learn: NotebookLM

Google's NotebookLM is my accelerated learning tool. I upload technical documentation, academic papers, or conference transcripts, and NotebookLM generates summaries, study questions, and — most transformatively — audio podcasts where two hosts discuss the material as if it were a natural conversation.

I documented it in depth in NotebookLM + SQL, showing how to transform PostgreSQL documentation into interactive study resources.

What I Tried and Discarded

Not everything you try survives contact with production. These are the tools I evaluated and discarded, with reasons:

WordPress: Used it for years. Abandoned it for the slowness, the plugins, the constant security updates, and the impossibility of versioning content with Git. Hugo is 100x faster and everything is code.
LangChain: LLM orchestration framework I tried before CrewAI. Too much abstraction, deep inheritance chains that were hard to debug, and an API that changed with every minor version. CrewAI is simpler, more explicit, and more stable.
Streamlit: Excellent for rapid data dashboard prototypes. But when you need control over the frontend (CSS, animations, UX), Streamlit becomes a straitjacket. For production, I prefer FastAPI + HTML/CSS/JS, where I have full control.
MongoDB: Tried it as a PostgreSQL alternative for semi-structured data. But the lack of JOINs and the impossibility of complex relational queries quickly ruled it out for my industrial use cases (BOM graphs, demand table cross-referencing).

Total Stack Cost: The Real Economics

This is where the Hidden Economics of AI becomes directly relevant. How much does operating this entire stack cost?

Tool	Monthly cost	Notes
Gemini Advanced	~€22/month	Includes Deep Research, 2.5 Pro, etc.
Hugo	€0	Open source
VS Code	€0	Open source
Python + libraries	€0	Open source
Supabase	€0	Free tier
CrewAI	€0	Open source
GitHub Actions	€0	Free for public repos
Netlify	€0	Free tier
Brevo	€0	Free tier (300 emails/day)
Chart.js	€0	Open source
NotebookLM	€0	Included in Gemini Advanced
TOTAL	~€22/month

Virtually the entire stack is free or open source. The only recurring cost is the Gemini Advanced subscription, which covers both Deep Research and the models powering CrewAI agents. Even if we count Gemini API costs for Autopilot pipeline executions, the total rarely exceeds €5 extra per month.

Compare this with the cost of an "enterprise" stack: a licensed CMS (€50-500/month), a premium email marketing tool (€30-200/month), a managed hosting service (€20-100/month), and a BI platform (€50-300/month). The open source stack isn't just cheaper; it's more powerful, because every tool is a box you can open, inspect, modify, and learn from.

The Philosophy: Learning > Comfort

If there's a common thread across every decision in this stack, it's this: I prioritize learning over comfort. Hugo is harder than WordPress, but I learned static site generation, Go templates, and CI/CD. FastAPI is more work than Streamlit, but I learned REST API design, async/await, and OpenAPI. Supabase with native SQL is more verbose than Firebase, but I learned real PostgreSQL, RLS, and migrations.

Every tool in the stack isn't just a tool; it's a course. And the 60+ articles on this blog are the notes from those courses, shared openly so anyone can walk the same path.

As Deming would say: "Learning is not compulsory. Neither is survival." In a world where AI redefines the rules of the game every quarter, the stack you use matters less than your ability to learn the next stack. And that ability is built by choosing tools that force you to understand what's under the hood.

Sources of Interest:

El Stack de Productividad de un Ingeniero en 2026: Las Herramientas que Uso Cada Día

Daniel — Sat, 01 Aug 2026 18:43:23 +0000

Después de más de 60 artículos, 9 series técnicas, 4 aplicaciones en producción y un blog bilingüe que genera contenido semanal, me hacen la misma pregunta una y otra vez: «¿Qué herramientas usas?». No qué herramientas recomiendo, no qué herramientas están de moda, sino cuáles uso yo realmente, todos los días, para construir lo que ves en Datalaria.

Este artículo es la respuesta. Sin patrocinios, sin enlaces de afiliados, sin filtros. Cada herramienta que aparece aquí la he testeado en producción, he pagado (o no) por ella con mi propio dinero, y he documentado su uso en al menos un post de este blog. Si no la he usado en un proyecto real, no está en esta lista.

El Workflow: 10 Fases, 10 Herramientas

La clave de mi productividad no está en las herramientas individuales sino en cómo encajan unas con otras. Cada fase del workflow alimenta a la siguiente, y la salida de una herramienta es la entrada de otra. No hay silos; hay un pipeline.

Fase	Herramienta	Por qué esta y no otra
🧠 Pensar	Gemini Deep Research	Investigación exhaustiva en minutos
✍️ Escribir	Hugo + VS Code + Markdown	Control total, Git-native, velocidad
💻 Codificar	Python + Pandas + FastAPI	El tridente de la ingeniería de datos
🗄️ Almacenar	Supabase (PostgreSQL)	BaaS gratuito, RLS, APIs REST automáticas
🤖 Orquestar IA	CrewAI + Gemini 2.5	Agentes autónomos con Tool Calling
⚙️ Automatizar	GitHub Actions	CI/CD gratuito, evento-driven
🚀 Desplegar	Netlify	Deploy from Git en segundos
📧 Comunicar	Brevo (Newsletter)	Email marketing gratuito, API, segmentación
📊 Visualizar	Chart.js + Vanilla JS	Ligero, sin frameworks pesados, interactivo
📚 Aprender	NotebookLM	Transforma cualquier fuente en recursos de estudio

🧠 Pensar: Gemini Deep Research

Antes de escribir una sola línea, investigo. Y aquí es donde la IA generativa ha cambiado radicalmente mi workflow. Gemini Deep Research (dentro de Gemini Advanced) es la herramienta que uso para hacer investigación exhaustiva antes de cada artículo y cada proyecto técnico.

Cuando estaba preparando el artículo sobre Thomas Bayes, necesitaba verificar fechas, publicaciones, contexto histórico de la Royal Society, y la conexión matemática precisa entre el teorema de Bayes y Facebook Prophet. Lo que antes habría requerido horas de navegación por Wikipedia, Stanford Encyclopedia of Philosophy y papers académicos, Gemini Deep Research lo compiló en un informe estructurado en menos de 10 minutos, con citas y fuentes verificables.

La clave: no lo uso para escribir; lo uso para investigar. El texto final siempre es mío. Gemini me da la materia prima; yo construyo la narrativa. Documenté este enfoque en detalle en IA en Educación con Deep Research.

✍️ Escribir: Hugo + VS Code + Markdown

Todo lo que ves en Datalaria está escrito en Markdown puro, editado en VS Code, compilado con Hugo y versionado en Git. Cero WordPress, cero CMS visual, cero drag-and-drop.

¿Por qué esta decisión aparentemente masoquista? Porque un blog en Hugo es código. Puedo hacer git diff para ver qué cambié en un artículo. Puedo hacer git blame para saber cuándo lo cambié. Puedo hacer un fork, crear una rama, experimentar con una estructura nueva, y hacer merge solo si funciona. Y puedo automatizar el despliegue con un git push. Documenté todas estas decisiones arquitectónicas en Construyendo Datalaria.

Hugo compila las más de 700 páginas de este blog (español + inglés) en menos de 4 minutos. Un CMS tradicional tardaría varios segundos solo en renderizar una página individual. Cuando iteras rápido, la velocidad de compilación no es un lujo; es una necesidad.

💻 Codificar: Python + Pandas + FastAPI

El tridente que uso para absolutamente todo lo que implique datos:

Python como lenguaje base. Sin discusión. El ecosistema de librerías para ingeniería de datos, ML y automatización no tiene rival.
Pandas para manipulación, limpieza y transformación de datos. Cada pipeline de la serie S&OP — desde la ingesta de datos de venta hasta la generación de forecasts con Prophet — pasa por Pandas.
FastAPI cuando necesito exponer un servicio como API REST. Lo usamos en la Parte 6 de la serie de Observabilidad para construir el backend del radar de obsolescencia, y en la app de OpenWeather como backend de predicción meteorológica.

🗄️ Almacenar: Supabase (PostgreSQL)

Supabase es PostgreSQL gestionado con superpoderes: autenticación, Row Level Security (RLS), APIs REST automáticas generadas a partir del esquema de la base de datos, y un tier gratuito que cubre el 95% de mis necesidades de desarrollo y prototipado.

Lo uso como backend de datos en la serie de Observabilidad (almacenando el catálogo de componentes, alertas de obsolescencia y grafos BOM), en los pipelines de S&OP (datos de demanda, forecasts, planes de producción), y en el juego Snake con leaderboard global.

¿Por qué Supabase y no Firebase? Porque Supabase es PostgreSQL real. Puedo escribir SQL nativo, crear vistas materializadas, usar JOINs complejos y migrar a cualquier otro PostgreSQL gestionado (RDS, Cloud SQL) sin cambiar una línea de código. Firebase te atrapa en su ecosistema propietario; Supabase te da la puerta de salida incluida.

🤖 Orquestar IA: CrewAI + Gemini 2.5

Cuando necesito que la IA no solo responda preguntas sino que ejecute tareas complejas de múltiples pasos, uso CrewAI como framework de orquestación de agentes. Cada agente tiene un rol, un objetivo, herramientas Python específicas (decoradas con @tool), y la capacidad de coordinarse con otros agentes.

Gemini 2.5 Pro/Flash es el LLM que alimenta a los agentes. La combinación CrewAI + Gemini + Tool Calling es la arquitectura que documenta toda la serie Autopilot de 9 partes, desde el generador automático de contenido hasta el Ops Copilot.

Como analizamos en el artículo de RAG vs. Tool Calling, la clave está en separar el «cerebro semántico» (el LLM entiende el contexto) del «músculo determinista» (las herramientas Python ejecutan las operaciones de precisión). El LLM piensa; las herramientas hacen.

⚙️ Automatizar: GitHub Actions

Cada pipeline de CI/CD de Datalaria corre en GitHub Actions. Es gratuito para repositorios públicos, evento-driven (se dispara con un push, un cron, un webhook), y lo suficientemente flexible para orquestar desde la compilación de Hugo hasta la ejecución de pipelines de CrewAI.

En la Parte 5 del Autopilot, documentamos cómo configurar un workflow de GitHub Actions que ejecuta el pipeline agéntico completo cada semana: genera contenido con CrewAI, crea los archivos Markdown, hace commit, push, y despliega automáticamente en Netlify. Todo sin intervención humana.

🚀 Desplegar: Netlify

Netlify despliega Datalaria directamente desde el repositorio de GitHub. Cada git push a la rama main dispara un build de Hugo y publica el sitio en segundos. Funcionalidades como Netlify Functions (serverless), redirects, y headers personalizados cubren todo lo que necesito sin gestionar servidores.

Lo documentamos en la Parte 2 de la app OpenWeather como plataforma de despliegue para aplicaciones frontend con backend serverless.

📧 Comunicar: Brevo (Newsletter)

La newsletter de Datalaria usa Brevo (antes Sendinblue). Tier gratuito generoso (300 emails/día), API REST para automatización, segmentación de audiencia, y editor de templates.

En la Parte 6 del Autopilot, documentamos cómo el pipeline de CrewAI genera el contenido del email, construye el HTML, y lo envía automáticamente vía la API de Brevo — cerrando el ciclo completo de generación → publicación → distribución sin intervención manual.

📊 Visualizar: Chart.js + Vanilla JS

Cuando necesito gráficos interactivos en las apps web, uso Chart.js con JavaScript vanilla. Sin React, sin Vue, sin frameworks pesados. La filosofía es intencional: cada librería que añades es una dependencia que mantener, una superficie de ataque que proteger, y un bundle que inflar.

La Parte 4 de la app OpenWeather y las Visualizaciones Básicas demuestran que Chart.js + CSS puro produce dashboards interactivos de calidad profesional sin necesidad de un framework de 200KB.

📚 Aprender: NotebookLM

NotebookLM de Google es mi herramienta de aprendizaje acelerado. Subo documentación técnica, papers académicos o transcripciones de conferencias, y NotebookLM genera resúmenes, preguntas de estudio, y — lo más transformador — podcasts de audio donde dos hosts discuten el material como si fuera una conversación natural.

Lo documenté en profundidad en NotebookLM + SQL, mostrando cómo transformar la documentación de PostgreSQL en recursos de estudio interactivos.

Lo que Probé y Descarté

No todo lo que pruebas sobrevive al contacto con la producción. Estas son las herramientas que evalué y descarté, con las razones:

WordPress: Lo usé durante años. Lo abandoné por la lentitud, los plugins, las actualizaciones de seguridad constantes, y la imposibilidad de versionar el contenido con Git. Hugo es 100x más rápido y todo es código.
LangChain: Framework de orquestación de LLMs que probé antes de CrewAI. Demasiada abstracción, cadenas de herencia profundas y difíciles de depurar, y una API que cambiaba con cada versión minor. CrewAI es más simple, más explícito, y más estable.
Streamlit: Excelente para prototipos rápidos de dashboards de datos. Pero cuando necesitas control sobre el frontend (CSS, animaciones, UX), Streamlit se convierte en una camisa de fuerza. Para producción, prefiero FastAPI + HTML/CSS/JS, donde tengo control total.
MongoDB: Lo probé como alternativa a PostgreSQL para datos semi-estructurados. Pero la falta de JOINs y la imposibilidad de hacer queries relacionales complejas lo descartaron rápidamente para mis casos de uso industriales (grafos BOM, cruce de tablas de demanda).

El Coste Total del Stack: La Economía Real

Aquí es donde la Economía Oculta de la IA cobra relevancia directa. ¿Cuánto cuesta operar todo este stack?

Herramienta	Coste mensual	Notas
Gemini Advanced	~€22/mes	Incluye Deep Research, 2.5 Pro, etc.
Hugo	€0	Open source
VS Code	€0	Open source
Python + librerías	€0	Open source
Supabase	€0	Tier gratuito
CrewAI	€0	Open source
GitHub Actions	€0	Gratuito para repos públicos
Netlify	€0	Tier gratuito
Brevo	€0	Tier gratuito (300 emails/día)
Chart.js	€0	Open source
NotebookLM	€0	Incluido en Gemini Advanced
TOTAL	~€22/mes

Prácticamente todo el stack es gratuito o open source. El único coste recurrente es la suscripción a Gemini Advanced, que cubre tanto Deep Research como los modelos que alimentan los agentes de CrewAI. Incluso si contamos los costes de API de Gemini para las ejecuciones del pipeline Autopilot, el total rara vez supera los €5 adicionales al mes.

Compara esto con el coste de un stack «enterprise»: un CMS con licencia (€50-500/mes), una herramienta de email marketing premium (€30-200/mes), un servicio de hosting gestionado (€20-100/mes), y una plataforma de BI (€50-300/mes). El stack open source no es solo más barato; es más potente, porque cada herramienta es una caja que puedes abrir, inspeccionar, modificar y aprender de ella.

La Filosofía: Aprendizaje > Comodidad

Si hay un hilo conductor en todas las decisiones de este stack, es este: priorizo aprender sobre comodidad. Hugo es más difícil que WordPress, pero aprendí generación de sitios estáticos, Go templates y CI/CD. FastAPI es más trabajo que Streamlit, pero aprendí diseño de APIs REST, async/await y OpenAPI. Supabase con SQL nativo es más verboso que Firebase, pero aprendí PostgreSQL real, RLS y migraciones.

Cada herramienta del stack no es solo una herramienta; es un curso. Y los 60+ artículos de este blog son los apuntes de esos cursos, compartidos en abierto para que cualquiera pueda recorrer el mismo camino.

Como diría Deming: «El aprendizaje no es obligatorio. Tampoco lo es la supervivencia». En un mundo donde la IA redefine las reglas del juego cada trimestre, el stack que uses importa menos que tu capacidad de aprender el siguiente stack. Y esa capacidad se construye eligiendo herramientas que te obliguen a entender qué hay debajo del capó.

Fuentes de Interés:

Flywire: How a Spaniard Built the Brain of International Payments from Boston

Daniel — Sun, 26 Jul 2026 14:29:18 +0000

When a Korean student tries to pay tuition at a university in Madrid, they face a Kafkaesque maze: opaque banking fees that devour 3% to 5% of the transaction, unfavorable exchange rates unilaterally imposed by the intermediary bank, SWIFT transfers that take 3 to 5 business days to settle, and a payment reference system where a single wrong digit means the university cannot reconcile the deposit with the student's enrollment. The result: the student overpays, the university receives less, and both waste time in emails and phone calls trying to square the accounts.

Iker Marcaide, a Spanish engineer pursuing his MBA at MIT Sloan School of Management in Boston, experienced this pain firsthand. But unlike the 99% of people who complain about the international banking system and move on, Marcaide did what founders do: he asked why it had to be this way and built the alternative.

In 2009, he founded peerTransfer — a platform that allowed international students to pay tuition in their local currency, with transparent exchange rates, minimal fees, and guaranteed settlement in the university's account. In 2016, the company rebranded as Flywire to reflect its expansion beyond education. In May 2021, it went public on the Nasdaq under the ticker $FLYW. In fiscal year 2025, it generated over $603 million in revenue, with 27% year-over-year growth. In Q1 2026, revenue reached $188 million, a 41% increase over the same quarter the prior year.

Alongside Carto, Devo, Clarity AI, Nextail, and Freepik, it is one of the Spanish startups that have achieved global scale. But Flywire has a distinguishing trait: it trades on an American stock exchange. Not on a private round, not on a European secondary market — on the Nasdaq, alongside Apple, Google, and Tesla.

The Technology: The Intelligent Brain of Payments

Flywire is not a conventional payment processor like Stripe or PayPal. The fundamental difference is that Flywire has built a platform designed specifically for complex, high-value, cross-border payments, where friction isn't at the user's final click (Stripe already solved that) but in the entire chain behind it: routing between banks, currency conversion, reconciliation with the receiver's system, and regulatory compliance across multiple jurisdictions.

The platform operates across three technological layers that reinforce each other:

1. Proprietary Global Payment Network: Flywire has built a network of direct banking connections across more than 240 countries and territories, supporting payments in over 140 currencies. This proprietary network allows them to select the optimal route for each transaction — not the default SWIFT route, which may pass through 3-4 intermediary banks, each charging its fee, but the most direct, fastest, and most cost-effective route for that specific currency corridor.

2. Machine Learning for Transaction Optimization: This is where data engineering creates the competitive moat. Flywire uses ML algorithms for three critical functions:

Intelligent routing: For each transaction, the system evaluates multiple banking routes and selects the optimal combination of exchange rate, settlement speed, and total cost. It's not a static routing table; it's a model that continuously learns from historical transactions to optimize each currency corridor.
Automatic reconciliation with deep learning: The nightmare for university and hospital treasury offices is reconciling received payments with outstanding invoices. When a student pays from South Korea, the payer's name may appear transliterated three different ways, the payment reference may be truncated, and the received amount differs from the invoiced amount due to intermediary fees. Flywire uses deep neural networks and reinforcement learning to automatically match payments to invoices, even when data doesn't match exactly.
Fraud detection: ML models that analyze transaction patterns to identify anomalies and prevent fraud before the transaction completes.

3. Vertical-Specific Software: For each industry, Flywire doesn't just process payments but integrates directly into the client's core systems — Student Information Systems (SIS) in education, Electronic Health Records (EHR) in healthcare, ERPs in B2B. This deep integration turns Flywire into infrastructure, not an interchangeable vendor.

Vertical Expansion: The "Land and Expand" Pattern

Flywire's growth story follows a pattern we've seen repeat in every Spanish unicorn analyzed on this blog: find a specific pain in one vertical, solve it with obsessive engineering, and expand horizontally.

Education (2009-2016): The starting point. peerTransfer solved the international tuition payment pain, beginning with universities in the United States and expanding to Europe, Australia, and Asia. The value proposition was clear: the student pays in their local currency with full transparency, the university receives exactly the invoiced amount with no hidden fees, and reconciliation is automatic. Today, Flywire processes payments for more than 3,800 educational institutions worldwide.

Healthcare (2016-2019): The leap to healthcare was natural. American hospitals face the same complex payment problem: international patients, fragmented insurance, installment plans, and administrative reconciliation that consumes enormous resources. Flywire adapted its platform to integrate with hospital management systems and offer flexible payment options (financing plans, partial payments) that improve the hospital's collection rate and the patient experience.

Travel (2019-present): The third vertical. Tour operators, travel agencies, and luxury hotels handle high-value bookings from international clients who want to pay in their local currency. Margins are tight, and losing 3-5% in exchange rate fees can destroy a booking's profitability. Flywire offers the same transparency and intelligent routing, adapted to the travel industry's specific workflow.

B2B (2021-present): The fourth frontier. International business-to-business payments — invoices, supplier settlements, royalty payments. The pattern repeats: regulatory complexity, multiple currencies, inefficient manual reconciliation. Flywire automates the complete invoice-to-cash flow.

The Numbers: A Spanish Unicorn on the Nasdaq

Metric	Data
Founded	2009 (as peerTransfer)
Rebranded to Flywire	2016
Nasdaq IPO	May 2021 (ticker: $FLYW)
FY2025 Revenue	~$603 million (+27% YoY)
Q1 2026 Revenue	$188 million (+41% YoY)
Currencies supported	140+
Countries	240+
Education clients	3,800+ institutions
Headquarters	Boston, MA (USA)
Founder	Iker Marcaide (Spain)

To put these numbers in context within the Spanish unicorn ecosystem: Flywire generates more revenue than Devo (acquired by LogRhythm in 2023 after reaching unicorn valuation) and more than Nextail (which operates in a narrower retail niche). The most direct comparison is with Clarity AI — both are fintech, both operate from the European regulatory ecosystem but with a global market, and both face the requirements of the EU AI Act for operating in sensitive categories (essential financial services, Annex III of the regulation).

Lessons for Engineers

Flywire's story distills three lessons applicable to any engineer building technology products:

Lesson 1: The "Platform Effect" — Start with a pain, expand through infrastructure

Flywire didn't start by saying "let's build a global payments platform." It started by saying "let's solve international tuition payments for American universities." A specific pain, a specific customer, a specific market. Once the platform was built and proven in education, the expansion to healthcare and travel was a natural extension of the same technological engine applied to a different workflow.

It's the same pattern we saw in Carto (started as a geospatial visualization tool, expanded to enterprise Location Intelligence), in Devo (started as a next-gen SIEM, expanded to full observability for defense and cybersecurity), and in Nextail (started optimizing store inventory, expanded to prescriptive AI for the entire retail supply chain).

Lesson 2: Build vs. Buy — Why Flywire built its own payments engine

The obvious question is: why not use Stripe? Stripe is extraordinary for standard online payments (e-commerce, SaaS). But high-value cross-border payments have three requirements that Stripe didn't solve in 2009 (and still doesn't fully solve for this niche): intelligent routing by currency corridor, automatic reconciliation with vertical systems (SIS, EHR), and multi-jurisdiction regulatory compliance for payments crossing borders. Flywire needed to control the entire chain to optimize every link. The build vs. buy decision boils down to one question: is payment the product, or is it an auxiliary feature of your product? If payment is the product (as with Flywire), you build. If it's auxiliary (as with an e-commerce shop), you buy.

Lesson 3: Regulation as competitive advantage, not as a brake

Flywire operates in one of the most regulated sectors on the planet: cross-border financial payments. It complies with anti-money laundering (AML) regulations, know-your-customer (KYC) requirements, PCI DSS for card data security, and the financial regulations of every country where it operates. As we discussed in the EU AI Act article, AI systems that determine access to essential financial services fall under the European regulation's "high-risk" category.

But Flywire has turned this regulatory complexity into a barrier to entry for competitors. Any startup wanting to compete with Flywire in cross-border university payments needs not only to build a comparable technology platform but also to obtain regulatory licenses in dozens of jurisdictions — a process that can take years and cost millions. The regulation that suffocates potential competitors protects well-positioned incumbents.

The Spanish Pattern: Local Pain, Global Scale

If you look at the complete series of Spanish startups analyzed on this blog, the pattern repeats with almost algorithmic consistency:

Startup	Initial pain	Expansion	Outcome
Flywire	International tuition payments	Education → Healthcare → Travel → B2B	Nasdaq ($FLYW), $603M revenue
Devo	Security logging	SIEM → Observability → Defense	Unicorn, LogRhythm acquisition
Carto	Web maps	Visualization → Location Intelligence	Enterprise cloud platform
Nextail	Store inventory	Retail → Prescriptive AI → Supply chain	ESPR 2026, global expansion
Clarity AI	ESG scoring	Sustainability → Fintech → Regulation	Impact platform, BlackRock
Freepik	Stock images	Stock → Generative AI → Design	Profitable from day 1

The common denominator is always the same: a Spanish founder with international training, a concrete and verifiable pain, a technically obsessive solution, and horizontal expansion once the base platform demonstrates traction. Neither the lack of VC ecosystem in Spain, nor the distance to Silicon Valley, nor the language barrier has prevented these companies from reaching global scale. What propelled them is exactly what Deming preached decades ago: obsessive quality in execution and continuous improvement based on evidence.

Iker Marcaide didn't invent international payments. But he did what great engineers do: he looked at a broken process, understood every link in the chain, and built a solution that was 10 times better than the status quo. Today, that solution processes billions of dollars and trades on the Nasdaq. And it started with a Spanish student at MIT who refused to pay abusive fees on his tuition.

Originally published at Datalaria.

Sources of Interest:

Flywire: Cómo un Español Construyó desde Boston el Cerebro de los Pagos Internacionales

Daniel — Sun, 26 Jul 2026 14:09:16 +0000

Cuando un estudiante coreano intenta pagar la matrícula de una universidad en Madrid, se enfrenta a un laberinto kafkiano: comisiones bancarias opacas que devoran entre un 3% y un 5% de la transacción, tipos de cambio desfavorables impuestos unilateralmente por el banco intermediario, transferencias SWIFT que tardan entre 3 y 5 días hábiles en liquidarse, y un sistema de referencia de pago que, si el estudiante se equivoca en un solo dígito, provoca que la universidad no pueda reconciliar el ingreso con su matrícula. El resultado: el estudiante paga de más, la universidad recibe de menos, y ambos pierden tiempo en correos electrónicos y llamadas intentando cuadrar las cuentas.

Iker Marcaide, un ingeniero español cursando su MBA en el MIT Sloan School of Management en Boston, vivió este dolor en primera persona. Pero a diferencia del 99% de las personas que se quejan del sistema bancario internacional y siguen adelante, Marcaide hizo lo que hacen los fundadores: se preguntó por qué tenía que ser así y construyó la alternativa.

En 2009, fundó peerTransfer — una plataforma que permitía a los estudiantes internacionales pagar su matrícula en su moneda local, con tipos de cambio transparentes, comisiones mínimas y liquidación garantizada en la cuenta de la universidad. En 2016, la empresa se rebautizó como Flywire para reflejar su expansión más allá de la educación. En mayo de 2021, salió a cotizar en el Nasdaq bajo el ticker $FLYW. En el año fiscal 2025, facturó más de 603 millones de dólares, con un crecimiento interanual del 27%. En el primer trimestre de 2026, los ingresos alcanzaron 188 millones de dólares, un 41% más que el mismo trimestre del año anterior.

Es, junto a Carto, Devo, Clarity AI, Nextail y Freepik, una de las startups españolas que han alcanzado escala global. Pero Flywire tiene un rasgo que la distingue de todas las demás: cotiza en la bolsa americana. No en el MAB, no en una ronda privada, no en el BME Growth — en el Nasdaq, junto a Apple, Google y Tesla.

La Tecnología: El Cerebro Inteligente de los Pagos

Flywire no es un procesador de pagos convencional como Stripe o PayPal. La diferencia fundamental está en que Flywire ha construido una plataforma diseñada específicamente para pagos complejos, de alto valor y cross-border, donde la fricción no está en el último clic del usuario (eso ya lo resolvió Stripe), sino en toda la cadena que ocurre detrás: el routing entre bancos, la conversión de divisas, la reconciliación con el sistema del receptor, y el cumplimiento regulatorio de múltiples jurisdicciones.

La plataforma opera en tres capas tecnológicas que se refuerzan mutuamente:

1. Red Global de Pagos Propietaria: Flywire ha construido una red de conexiones bancarias directas en más de 240 países y territorios, soportando pagos en más de 140 divisas. Esta red propia les permite seleccionar la ruta óptima para cada transacción — no la ruta por defecto del sistema SWIFT, que puede pasar por 3-4 bancos intermediarios, cada uno cobrando su comisión, sino la ruta más directa, rápida y económica para ese corredor de divisas específico.

2. Machine Learning para Optimización de Transacciones: Aquí es donde la ingeniería de datos marca la diferencia competitiva. Flywire utiliza algoritmos de ML para tres funciones críticas:

Routing inteligente: Para cada transacción, el sistema evalúa múltiples rutas bancarias y selecciona la combinación óptima de tipo de cambio, velocidad de liquidación y coste total. No es una tabla estática de rutas; es un modelo que aprende continuamente de las transacciones históricas para optimizar cada corredor de divisas.
Reconciliación automática con deep learning: La pesadilla de las oficinas de tesorería de universidades y hospitales es reconciliar los pagos recibidos con las facturas pendientes. Cuando un estudiante paga desde Corea del Sur, el nombre del pagador puede aparecer transliterado de tres formas diferentes, la referencia de pago puede estar truncada, y el importe recibido difiere del facturado por las comisiones intermedias. Flywire usa redes neuronales profundas y aprendizaje por refuerzo para emparejar automáticamente pagos con facturas, incluso cuando los datos no coinciden exactamente.
Detección de fraude: Modelos de ML que analizan patrones de transacciones para identificar anomalías y prevenir fraude antes de que la transacción se complete.

3. Software Vertical Especializado: Para cada industria, Flywire no solo procesa pagos sino que se integra directamente en los sistemas core del cliente — Student Information Systems (SIS) en educación, Electronic Health Records (EHR) en sanidad, ERPs en B2B. Esta integración profunda convierte a Flywire en infraestructura, no en un proveedor intercambiable.

La Expansión Vertical: El Patrón "Land and Expand"

La historia de crecimiento de Flywire sigue un patrón que hemos visto repetirse en cada unicornio español que hemos analizado en este blog: encuentra un dolor específico en una vertical, resuélvelo con ingeniería obsesiva, y expándete horizontalmente.

Educación (2009-2016): El punto de partida. peerTransfer resolvió el dolor de los pagos de matrícula internacional, empezando por universidades en Estados Unidos y expandiéndose a Europa, Australia y Asia. La propuesta de valor era clara: el estudiante paga en su moneda local con total transparencia, la universidad recibe exactamente el importe facturado sin comisiones ocultas, y la reconciliación es automática. Hoy, Flywire procesa pagos para más de 3.800 instituciones educativas a nivel global.

Sanidad / Healthcare (2016-2019): El salto a sanidad fue natural. Los hospitales americanos enfrentan el mismo problema de pagos complejos: pacientes internacionales, seguros fragmentados, planes de pago a plazos, y una reconciliación administrativa que consume recursos enormes. Flywire adaptó su plataforma para integrarse con los sistemas de gestión hospitalaria y ofrecer opciones de pago flexibles (planes de financiación, pagos parciales) que mejoran la tasa de cobro del hospital y la experiencia del paciente.

Viajes / Travel (2019-presente): La tercera vertical. Los operadores turísticos, agencias de viajes y hoteles de lujo manejan reservas de alto valor con clientes internacionales que quieren pagar en su moneda local. Los márgenes son estrechos, y perder un 3-5% en comisiones de tipo de cambio puede destruir la rentabilidad de una reserva. Flywire ofrece la misma transparencia y routing inteligente, adaptada al flujo de trabajo específico de la industria del viaje.

B2B (2021-presente): La cuarta frontera. Pagos entre empresas a nivel internacional — facturas, liquidaciones de proveedores, pagos de royalties. El patrón se repite: complejidad regulatoria, múltiples divisas, reconciliación manual ineficiente. Flywire automatiza el flujo completo de invoice-to-cash.

Las Cifras: Un Unicornio Español en el Nasdaq

Métrica	Dato
Fundación	2009 (como peerTransfer)
Rebrand a Flywire	2016
IPO Nasdaq	Mayo 2021 (ticker: $FLYW)
Revenue FY2025	~$603 millones (+27% YoY)
Revenue Q1 2026	$188 millones (+41% YoY)
Divisas soportadas	140+
Países	240+
Clientes educación	3.800+ instituciones
Sede	Boston, MA (EE.UU.)
Fundador	Iker Marcaide (España)

Para poner las cifras en contexto dentro del ecosistema de unicornios españoles: Flywire factura más que Devo (adquirida por LogRhythm en 2023 tras alcanzar valoración de unicornio) y más que Nextail (que opera en un nicho más estrecho de retail). La comparación más directa es con Clarity AI — ambas son fintech, ambas operan desde el ecosistema regulatorio europeo pero con mercado global, y ambas enfrentan las exigencias del EU AI Act por operar en categorías sensibles (servicios financieros esenciales, Anexo III del reglamento).

Lecciones para Ingenieros

La historia de Flywire destila tres lecciones que aplican a cualquier ingeniero que construya productos tecnológicos:

Lección 1: El "Efecto Plataforma" — Empieza por un dolor, expándete por la infraestructura

Flywire no empezó diciendo «vamos a construir una plataforma global de pagos». Empezó diciendo «vamos a resolver los pagos de matrícula internacional para universidades americanas». Un dolor específico, un cliente específico, un mercado específico. Una vez que la plataforma estaba construida y probada en educación, la expansión a sanidad y viajes fue una extensión natural del mismo motor tecnológico aplicado a un flujo de trabajo diferente.

Es el mismo patrón que vimos en Carto (empezó como herramienta de visualización geoespacial, se expandió a Location Intelligence empresarial), en Devo (empezó como SIEM de siguiente generación, se expandió a observabilidad completa para defensa y ciberseguridad), y en Nextail (empezó optimizando el inventario de tienda, se expandió a IA prescriptiva para toda la cadena de suministro del retail).

Lección 2: Build vs. Buy — Por qué Flywire construyó su propio motor de pagos

La pregunta obvia es: ¿por qué no usar Stripe? Stripe es extraordinario para pagos online estándar (e-commerce, SaaS). Pero los pagos cross-border de alto valor tienen tres requisitos que Stripe no resolvía en 2009 (y que sigue sin resolver completamente para este nicho): routing inteligente por corredor de divisas, reconciliación automática con sistemas verticales (SIS, EHR), y cumplimiento regulatorio multi-jurisdicción para pagos que cruzan fronteras. Flywire necesitaba controlar la cadena completa para optimizar cada eslabón. La decisión build vs. buy se resume en una pregunta: ¿el pago es tu producto, o es una funcionalidad auxiliar de tu producto? Si el pago es tu producto (como en Flywire), construyes. Si es auxiliar (como en un e-commerce), compras.

Lección 3: La regulación como ventaja competitiva, no como freno

Flywire opera en uno de los sectores más regulados del planeta: pagos financieros transfronterizos. Cumple con regulaciones de anti-lavado de dinero (AML), know-your-customer (KYC), PCI DSS para seguridad de datos de tarjetas, y las regulaciones financieras de cada país donde opera. Como discutimos en el artículo sobre el EU AI Act, los sistemas de IA que determinan el acceso a servicios financieros esenciales caen en la categoría de «alto riesgo» del reglamento europeo.

Pero Flywire ha convertido esta complejidad regulatoria en una barrera de entrada para competidores. Cualquier startup que quiera competir con Flywire en pagos universitarios cross-border necesita no solo construir una plataforma tecnológica comparable, sino también obtener las licencias regulatorias en docenas de jurisdicciones — un proceso que puede tardar años y costar millones. La regulación que ahoga a los competidores potenciales protege a los incumbentes bien posicionados.

El Patrón Español: Dolor Local, Escala Global

Si miras la serie completa de startups españolas que hemos analizado en este blog, el patrón se repite con una consistencia casi algorítmica:

Startup	Dolor inicial	Expansión	Resultado
Flywire	Pagos de matrícula internacional	Educación → Sanidad → Viajes → B2B	Nasdaq ($FLYW), $603M revenue
Devo	Logging de seguridad	SIEM → Observabilidad → Defensa	Unicornio, adquisición LogRhythm
Carto	Mapas web	Visualización → Location Intelligence	Plataforma cloud empresarial
Nextail	Inventario de tienda	Retail → IA prescriptiva → Supply chain	ESPR 2026, expansión global
Clarity AI	Scoring ESG	Sostenibilidad → Fintech → Regulación	Plataforma de impacto, BlackRock
Freepik	Banco de imágenes	Stock → IA generativa → Diseño	Rentable desde día 1

El denominador común es siempre el mismo: un fundador español con formación internacional, un dolor concreto y verificable, una solución técnicamente obsesiva, y una expansión horizontal una vez que la plataforma base demuestra tracción. Ni la falta de ecosistema VC en España, ni la distancia a Silicon Valley, ni la barrera del idioma han impedido que estas empresas alcancen escala global. Lo que las ha impulsado es exactamente lo que Deming predicaba hace décadas: calidad obsesiva en la ejecución y mejora continua basada en evidencia.

Iker Marcaide no inventó los pagos internacionales. Pero hizo lo que hacen los grandes ingenieros: miró un proceso roto, entendió cada eslabón de la cadena, y construyó una solución que era 10 veces mejor que el status quo. Hoy, esa solución procesa miles de millones de dólares y cotiza en el Nasdaq. Y empezó con un estudiante español en MIT que se negó a pagar comisiones abusivas por su matrícula.

Fuentes de Interés:

Thomas Bayes: The Reverend Who Taught Us to Update Our Beliefs with Data

Daniel — Sat, 18 Jul 2026 15:02:17 +0000

There is a question every professional who works with data should ask — and almost no one formulates explicitly: How should I change my opinion when I receive new evidence? I don't mean a philosophical answer, but a mathematical one. If I believe there's a 30% probability that an electronic component will become obsolete this year, and I suddenly receive an email from the supplier announcing a production capacity reduction, how much should my estimate increase? To 50%? To 70%? How do I calculate it rigorously?

The answer to that question was formulated by an English Presbyterian reverend sometime before 1761, and it wasn't published until two years after his death. His name was Thomas Bayes, and his posthumous essay is, without exaggeration, one of the most influential documents in the history of science. From the spam filters in your email to the probabilistic forecasting models we used in the S&OP Engineering series with Facebook Prophet, everything passes through Bayes' Theorem.

In the lineage of historical figures who shaped our relationship with data — Florence Nightingale and visualization, John Snow and geolocation, Abraham Wald and survivorship bias, Kantorovich and optimization, Deming and quality, Claude Shannon and information — Bayes occupies a singular place: he taught us to think of uncertainty as something quantifiable and updatable, not as an obstacle but as raw material.

The Reverend and the Posthumous Essay

Thomas Bayes was born in London in 1702 into a family of religious dissenters. His father, Joshua Bayes, was one of the first Presbyterian ministers ordained in England. Thomas followed in his father's footsteps, was ordained a minister, and spent most of his life as a pastor in Tunbridge Wells, a quiet spa town southeast of London.

But Bayes was no ordinary pastor. He was a Fellow of the Royal Society (elected in 1742), which indicates that his mathematical reputation was recognized by the scientific elite of his era. He is known to have published a work defending the logical foundations of Newton's calculus, but during his lifetime he was a discreet figure, almost invisible in the great intellectual debates of the Enlightenment.

History might have completely forgotten Bayes were it not for his friend Richard Price, a distinguished Welsh philosopher and mathematician. After Bayes's death in 1761, Price found among his papers an unfinished manuscript titled "An Essay towards solving a Problem in the Doctrine of Chances". Price immediately recognized its importance, completed it, and presented it to the Royal Society in 1763.

The problem Bayes was trying to solve was deceptively simple in its formulation and profoundly revolutionary in its implications: given a series of observations, what is the probability that the underlying cause is one thing or another? In other words, how do we reverse the direction of probability? Not "given that the coin is fair, what is the probability of getting 7 heads in 10 flips?" but the inverse question: "given that I observed 7 heads in 10 flips, what is the probability that the coin is fair?"

The Theorem: Updating Beliefs with Evidence

Bayes' Theorem can be expressed without intimidating formulas using three intuitive concepts:

Prior (Previous Belief): What you believe before seeing the data. Your initial estimate based on experience, intuition, or historical data. In an S&OP context, the prior might be: "Historically, we sell about 10,000 units of this product in July."
Evidence (Likelihood): The new data you observe and the probability of observing that data under different hypotheses. For example: "This June we've received 40% more advance orders than last year."
Posterior (Updated Belief): Your new estimate after integrating the evidence with your previous belief. The posterior mathematically combines what you knew before with what the new data tells you. It doesn't discard your prior experience nor lets itself be blinded by a single new data point: it weighs both.

The beauty of the Bayesian approach is that it's iterative: today's posterior becomes tomorrow's prior. Each new piece of data refines your estimate. It's not a static photograph; it's a movie that updates frame by frame. It is exactly the same philosophy as W. Edwards Deming's PDCA cycle: plan, do, check, adjust. Repeat.

Modern Connection: Prophet and Demand Forecasting

Where does Bayes appear in modern data engineering? Virtually everywhere, but the most direct connection with this blog is Facebook Prophet, the tool we used in Part 2 of the S&OP series to generate probabilistic demand forecasts.

Prophet is, at its core, a Bayesian additive model. It decomposes a time series into three components — trend, seasonality, and holiday effects — and generates not a point prediction, but a confidence interval. That confidence interval is, literally, a Bayesian posterior distribution: it reflects the model's uncertainty given the historical evidence.

Why does this matter in practice? Because the Safety Stock we calculated in Part 3 of the S&OP series — the amount of buffer inventory to absorb demand variability — is calculated on the upper bound of that confidence interval (typically at 95%). If Prophet used a deterministic model (a single number, no uncertainty), our Safety Stock would be a guess. Thanks to Bayes, it's a decision grounded in the probability distribution of future demand.

The prior in this context is the accumulated experience of the demand planning team and the historical patterns of the time series. The evidence is the new data arriving each week or month. The posterior is the updated forecast that feeds the PuLP linear programming engine to optimize the production plan. Bayes is at the heart of the chain, even though his name is never mentioned in S&OP meetings.

Modern Connection: A/B Testing and Netflix

When Netflix decides which thumbnail to show for a series, it runs a massive A/B test: it shows version A to millions of users and version B to millions of others, then measures which generates more clicks. The classical (frequentist) approach requires waiting until a predetermined sample size is reached to declare a "winner" with statistical significance. If you do peeking — looking at results before time — you invalidate the experiment.

The Bayesian approach to A/B testing eliminates this problem. Instead of a binary hypothesis test (is there a difference or not?), Bayesian A/B testing continuously calculates the probability that version A is better than version B given the data observed so far. You don't need to wait for a fixed sample size because the posterior distribution updates with each new data point.

This has enormous practical implications for startups and teams with limited traffic. If your product doesn't have millions of users, a frequentist test can take weeks or months to be conclusive. A Bayesian test gives you a useful probability estimate much sooner, with the honesty of telling you: "With current data, there's a 78% probability that A is better than B." You decide if that 78% is enough to act on.

Modern Connection: Spam Filters and Classification

One of the first triumphs of machine learning in production at scale was the Bayesian spam filter. The Naive Bayes algorithm (called "naive" because it assumes independence between words, a crude simplification that's surprisingly effective) calculates the probability that an email is spam given the words it contains.

The prior is the base rate of spam (approximately 45% of all global email). The evidence is the email's words: "offer," "free," "urgent" increase the posterior probability of spam; "meeting," "budget," "attached" reduce it. Each word updates the probability, exactly as Bayes prescribed 260 years ago.

The connection with Abraham Wald's survivorship bias is direct: in a spam filter, the data you don't see (legitimate emails erroneously filtered as spam) is as important as what you do see. If your filter has a high false positive rate, you're making the same mistake as the WWII engineers who only analyzed the planes that returned. Bayes and Wald, separated by two centuries, are talking about the same problem: absent information distorts your conclusions.

Modern Connection: Medical Diagnosis and the Perfect Test Paradox

There's a classic example of Bayesian reasoning that should be mandatory in every engineer's training, because it destroys a very widespread intuition. Suppose there's a medical test for a rare disease (prevalence: 1 in 10,000 people). The test has a sensitivity of 99% (correctly detects 99% of the sick) and a specificity of 99% (correctly identifies 99% of the healthy).

Question: if you test positive, what is the probability that you're actually sick?

The intuitive answer most people give — including many physicians — is "99%." The correct Bayesian answer is approximately 1%. How is this possible? Because the prevalence (the prior) is so low that, even with a 99% test, the vast majority of positives are false positives.

This reasoning is directly applicable to AI system engineering. When we configure alerts in the obsolescence radar or in any monitoring system, the false positive rate is the silent enemy. An anomaly detection system with 99% accuracy can generate hundreds of false alerts if the base rate of actual anomalies is very low. Bayes forces us to think about the prior before celebrating the test's accuracy.

The Legacy: Think in Distributions, Not Points

Thomas Bayes's deepest contribution was not a formula; it was a mindset shift. Before Bayes, probability was conceived as a fixed property of objects: a coin has a 50% chance of landing heads, period. After Bayes, probability became a measure of our degree of knowledge about the world, continuously updated with new evidence.

This distinction is the difference between an engineer who says "July demand will be 10,000 units" and one who says "July demand has a 95% probability of falling between 8,500 and 11,500 units, and our production plan must absorb that variability." The first operates with false certainties; the second, with quantified uncertainty. The first is vulnerable to the bullwhip effect that destroys supply chains; the second is armored against it.

In a world where AI models are stochastic by nature — as we painfully documented in the Autopilot post-mortem, where the same pipeline produces different results on each run — thinking Bayesianly isn't a philosophical option: it's an operational necessity. Don't ask "what is the answer?" Ask "what is the distribution of possible answers, and with what confidence?"

A reverend from the 18th century, working in solitude with quill and ink in an English spa town, solved a problem that today powers medicine, marketing, cybersecurity, supply chain management, and artificial intelligence. And he did it with an idea so simple it fits in a single sentence: update what you believe with what you observe. Two hundred and sixty years later, we still haven't found better advice.

Sources of Interest:

Thomas Bayes: El Reverendo que Nos Enseñó a Actualizar Nuestras Creencias con Datos

Daniel — Sat, 18 Jul 2026 14:56:46 +0000

Hay una pregunta que todo profesional que trabaja con datos debería hacerse y que casi nadie se formula explícitamente: ¿Cómo debería cambiar mi opinión cuando recibo nueva evidencia? No me refiero a una respuesta filosófica, sino a una matemática. Si creo que hay un 30% de probabilidad de que un componente electrónico quede obsoleto este año, y de repente recibo un email del proveedor anunciando una reducción de capacidad de producción, ¿cuánto debería subir mi estimación? ¿Al 50%? ¿Al 70%? ¿Cómo lo calculo de forma rigurosa?

La respuesta a esa pregunta la formuló un reverendo presbiteriano inglés en algún momento antes de 1761, y no se publicó hasta dos años después de su muerte. Su nombre era Thomas Bayes, y su ensayo póstumo es, sin exageración, uno de los documentos más influyentes en la historia de la ciencia. Desde los filtros anti-spam de tu correo electrónico hasta los modelos de predicción probabilística que utilizamos en la serie de Ingeniería S&OP con Facebook Prophet, todo pasa por el Teorema de Bayes.

En la línea de figuras históricas que han dado forma a nuestra relación con los datos — Florence Nightingale y la visualización, John Snow y la geolocalización, Abraham Wald y el sesgo del superviviente, Kantorovich y la optimización, Deming y la calidad, Claude Shannon y la información — Bayes ocupa un lugar singular: nos enseñó a pensar en la incertidumbre como algo cuantificable y actualizable, no como un obstáculo, sino como materia prima.

El Reverendo y el Ensayo Póstumo

Thomas Bayes nació en Londres en 1702 en el seno de una familia de disidentes religiosos. Su padre, Joshua Bayes, fue uno de los primeros ministros presbiterianos ordenados en Inglaterra. Thomas siguió los pasos de su padre, fue ordenado ministro y pasó la mayor parte de su vida como pastor en Tunbridge Wells, un tranquilo balneario al sureste de Londres.

Pero Bayes no era un pastor convencional. Era miembro de la Royal Society (elegido en 1742), lo que indica que su reputación matemática era reconocida por la élite científica de la época. Se sabe que publicó un trabajo defendiendo los fundamentos lógicos del cálculo de Newton, pero durante su vida fue una figura discreta, casi invisible en los grandes debates intelectuales de la Ilustración.

La historia podría haber olvidado por completo a Bayes si no fuera por su amigo Richard Price, un filósofo galés y matemático destacado. Tras la muerte de Bayes en 1761, Price encontró entre sus papeles un manuscrito inacabado titulado "An Essay towards solving a Problem in the Doctrine of Chances". Price reconoció inmediatamente su importancia, lo completó, y lo presentó ante la Royal Society en 1763.

El problema que Bayes intentaba resolver era deceptivamente simple en su formulación y profundamente revolucionario en sus implicaciones: dada una serie de observaciones, ¿cuál es la probabilidad de que la causa subyacente sea una u otra? Es decir, ¿cómo invertimos la dirección de la probabilidad? No «dado que la moneda es justa, ¿cuál es la probabilidad de sacar 7 caras en 10 lanzamientos?», sino la pregunta inversa: «dado que he observado 7 caras en 10 lanzamientos, ¿cuál es la probabilidad de que la moneda sea justa?».

El Teorema: Actualizar Creencias con Evidencia

El Teorema de Bayes puede expresarse sin fórmulas intimidantes usando tres conceptos intuitivos:

Prior (Creencia previa): Lo que crees antes de ver los datos. Tu estimación inicial basada en experiencia, intuición o datos históricos. En un contexto S&OP, el prior podría ser: «Históricamente, vendemos unas 10.000 unidades de este producto en julio».
Evidencia (Likelihood): Los datos nuevos que observas y la probabilidad de observar esos datos bajo diferentes hipótesis. Por ejemplo: «Este junio hemos recibido un 40% más de pedidos anticipados que el año pasado».
Posterior (Creencia actualizada): Tu nueva estimación después de integrar la evidencia con tu creencia previa. El posterior combina matemáticamente lo que sabías antes con lo que los datos nuevos te dicen. No descarta tu experiencia previa ni se deja cegar por un solo dato nuevo: pondera ambos.

La belleza del enfoque bayesiano es que es iterativo: el posterior de hoy se convierte en el prior de mañana. Cada nuevo dato que recibes refina tu estimación. No es una fotografía estática; es una película que se actualiza fotograma a fotograma. Es exactamente la misma filosofía del ciclo PDCA de W. Edwards Deming: planifica, ejecuta, verifica, ajusta. Repite.

Conexión Moderna: Prophet y la Predicción de Demanda

¿Dónde aparece Bayes en la ingeniería de datos moderna? En prácticamente todas partes, pero la conexión más directa con este blog es Facebook Prophet, la herramienta que utilizamos en la Parte 2 de la serie S&OP para generar forecasts probabilísticos de demanda.

Prophet es, en su núcleo, un modelo aditivo bayesiano. Descompone una serie temporal en tres componentes — tendencia, estacionalidad y efecto de festivos — y genera no una predicción puntual, sino un intervalo de confianza. Ese intervalo de confianza es, literalmente, una distribución posterior bayesiana: refleja la incertidumbre del modelo dada la evidencia histórica.

¿Por qué importa esto en la práctica? Porque el Safety Stock que calculamos en la Parte 3 de la serie S&OP — la cantidad de inventario de reserva para absorber la variabilidad de la demanda — se calcula sobre el límite superior de ese intervalo de confianza (típicamente al 95%). Si Prophet usara un modelo determinista (un solo número, sin incertidumbre), nuestro Safety Stock sería una adivinanza. Gracias a Bayes, es una decisión fundamentada en la distribución de probabilidad de la demanda futura.

El prior en este contexto es la experiencia acumulada del equipo de demand planning y los patrones históricos de la serie temporal. La evidencia son los nuevos datos que llegan cada semana o cada mes. El posterior es el forecast actualizado que alimenta el motor de programación lineal de PuLP para optimizar el plan de producción. Bayes está en el corazón de la cadena, aunque nunca se le mencione por su nombre en las reuniones de S&OP.

Conexión Moderna: A/B Testing y Netflix

Cuando Netflix decide qué carátula mostrar para una serie, ejecuta un A/B test masivo: muestra la versión A a millones de usuarios y la versión B a otros tantos, y mide cuál genera más clics. El enfoque clásico (frecuentista) requiere esperar hasta alcanzar un tamaño de muestra predeterminado para declarar un «ganador» con significancia estadística. Si haces peeking — mirar los resultados antes de tiempo —, invalidas el experimento.

El enfoque bayesiano para A/B testing elimina este problema. En lugar de un test binario de hipótesis (¿hay diferencia o no?), el A/B testing bayesiano calcula continuamente la probabilidad de que la versión A sea mejor que la versión B dado los datos observados hasta el momento. No necesitas esperar a un tamaño de muestra fijo porque la distribución posterior se actualiza con cada nuevo dato.

Esto tiene implicaciones prácticas enormes para startups y equipos con tráfico limitado. Si tu producto no tiene millones de usuarios, un test frecuentista puede tardar semanas o meses en ser concluyente. Un test bayesiano te da una estimación de probabilidad útil mucho antes, con la honestidad de decirte: «Con los datos actuales, hay un 78% de probabilidad de que A sea mejor que B». Tú decides si ese 78% es suficiente para actuar.

Conexión Moderna: Filtros Anti-Spam y Clasificación

Uno de los primeros triunfos del machine learning en producción a escala fue el filtro de spam bayesiano. El algoritmo Naive Bayes (llamado «naive» porque asume independencia entre las palabras, una simplificación burda pero sorprendentemente efectiva) calcula la probabilidad de que un email sea spam dado las palabras que contiene.

El prior es la tasa base de spam (aproximadamente el 45% de todo el email global). La evidencia son las palabras del email: «oferta», «gratis», «urgente» aumentan la probabilidad posterior de spam; «reunión», «presupuesto», «adjunto» la reducen. Cada palabra actualiza la probabilidad, exactamente como Bayes prescribió hace 260 años.

La conexión con el sesgo del superviviente de Abraham Wald es directa: en un filtro de spam, los datos que no ves (emails legítimos que fueron filtrados erróneamente como spam) son tan importantes como los que ves. Si tu filtro tiene una alta tasa de falsos positivos, estás cometiendo el mismo error que los ingenieros de la WWII que solo analizaban los aviones que regresaban. Bayes y Wald, separados por dos siglos, están hablando del mismo problema: la información ausente distorsiona tus conclusiones.

Conexión Moderna: Diagnóstico Médico y la Paradoja del Test Perfecto

Hay un ejemplo clásico de razonamiento bayesiano que debería ser obligatorio en la formación de todo ingeniero, porque destruye una intuición muy extendida. Supongamos que existe un test médico para una enfermedad rara (prevalencia: 1 de cada 10.000 personas). El test tiene una sensibilidad del 99% (detecta correctamente al 99% de los enfermos) y una especificidad del 99% (identifica correctamente al 99% de los sanos).

Pregunta: si das positivo en este test, ¿cuál es la probabilidad de que realmente estés enfermo?

La respuesta intuitiva de la mayoría de las personas — incluidos muchos médicos — es «99%». La respuesta bayesiana correcta es aproximadamente 1%. ¿Cómo es posible? Porque la prevalencia (el prior) es tan baja que, incluso con un test del 99%, la inmensa mayoría de los positivos son falsos positivos.

Este razonamiento es directamente aplicable a la ingeniería de sistemas de IA. Cuando configuramos alertas en el radar de obsolescencia o en cualquier sistema de monitoreo, la tasa de falsos positivos es el enemigo silencioso. Un sistema de detección de anomalías con un 99% de precisión puede generar cientos de alertas falsas si la tasa base de anomalías reales es muy baja. Bayes nos obliga a pensar en el prior antes de celebrar la precisión del test.

El Legado: Pensar en Distribuciones, No en Puntos

La contribución más profunda de Thomas Bayes no fue una fórmula; fue un cambio de mentalidad. Antes de Bayes, la probabilidad se concebía como una propiedad fija de los objetos: una moneda tiene un 50% de probabilidad de caer cara, punto. Después de Bayes, la probabilidad se convirtió en una medida de nuestro grado de conocimiento sobre el mundo, que se actualiza continuamente con nueva evidencia.

Esta distinción es la diferencia entre un ingeniero que dice "la demanda de julio será de 10.000 unidades" y uno que dice "la demanda de julio tiene un 95% de probabilidad de estar entre 8.500 y 11.500 unidades, y nuestro plan de producción debe absorber esa variabilidad". El primero opera con certezas falsas; el segundo, con incertidumbre cuantificada. El primero es vulnerable al bullwhip effect que destruye las cadenas de suministro; el segundo está blindado contra él.

En un mundo donde los modelos de IA son estocásticos por naturaleza — como documentamos dolorosamente en el post-mortem del Autopilot, donde el mismo pipeline produce resultados diferentes en cada ejecución —, pensar bayesianamente no es una opción filosófica: es una necesidad operativa. No preguntes «¿cuál es la respuesta?». Pregunta «¿cuál es la distribución de respuestas posibles, y con qué confianza?».

Un reverendo del siglo XVIII, trabajando en soledad con pluma y tinta en un pueblo termal inglés, resolvió un problema que hoy mueve la medicina, el marketing, la ciberseguridad, la cadena de suministro y la inteligencia artificial. Y lo hizo con una idea tan simple que cabe en una frase: actualiza lo que crees con lo que observas. Doscientos sesenta años después, seguimos sin encontrar un consejo mejor.

Fuentes de Interés:

RAG in Production: 7 Anti-Patterns That Destroy Precision (And How I Fixed Them)

Daniel — Sat, 11 Jul 2026 14:28:15 +0000

RAG is the aspirin of generative AI: everyone prescribes it, almost no one truly understands how it works, and when it fails, the patient hallucinates. If you've attended any tech conference in the past 18 months, you'll have heard the same promise repeated like a mantra: "Connect your LLM to your documents with RAG and you'll have a chatbot that responds with your company's truth." It's a seductive promise. It is also, in most implementations I've seen, a well-intentioned lie.

I know this because I've walked both paths. I built a working RAG system in production — the Ops Engineering Copilot with Algolia Agent Studio, indexing over 70 posts from this blog — and I also built a system that deliberately rejects RAG — the agentic obsolescence radar, which uses pure Tool Calling to query industrial databases with mathematical precision. The experience of operating both systems in production left me with an uncomfortable conclusion: RAG isn't bad; what's bad is how we implement it.

This article is the catalogue of the 7 errors that destroy a RAG system's precision, the solutions that work, and the question no one wants to ask: do you really need RAG, or do you need something else?

Anti-Pattern 1: Blind Chunking

The first step in any RAG pipeline is splitting your documents into fragments (chunks) that will be stored as vectors. And this is where most tutorials commit the first mortal sin: chunking by fixed length (e.g., 500 tokens per chunk with 50 tokens of overlap).

The problem is brutal: a paragraph explaining a complex technical concept gets cut in half. The first half ends up in one chunk, the second in another. When the user asks a question, the retriever finds the first half (which contains the keywords) but misses the context from the second. The LLM, true to its nature, fills in what's missing with a plausible fabrication. Hallucination served.

The fix: Semantic chunking. Split by logical units of meaning: sections delimited by headers, complete paragraphs, or functional blocks of the document. In the Ops Copilot, when we indexed Datalaria's posts with Algolia, each record corresponds to a complete article section (delimited by ### in Markdown), not an arbitrary block of N tokens. The result: each chunk is self-contained and holds a complete thought.

Anti-Pattern 2: Generic Embeddings for Specialized Domains

Pre-trained embeddings (like OpenAI's text-embedding-3-small or Vertex AI's) are trained on general internet text. They work reasonably well for generic questions. But when your domain is highly specialized — industrial engineering, European regulation, electronic component nomenclature — the semantic distance between key terms can be completely wrong in the vector space.

A real example: in the context of obsolescence management, the terms "EOL" (End of Life), "NRND" (Not Recommended for New Designs), and "PDN" (Product Discontinuation Notice) are semantically very close for a supply chain engineer. But for a generic embedding, "End of Life" might be closer to an article about palliative care than to a chip discontinuation notice.

The fix: Evaluate embeddings with your own dataset before committing. Build a small benchmark of 50-100 question-answer pairs from your domain and measure the retriever's hit rate. If generic embeddings don't exceed 80% accuracy on your benchmark, consider fine-tuning or specialized embeddings for your sector. And if your domain is highly structured (codes, nomenclatures, tables), you probably don't need embeddings at all: you need Tool Calling.

Anti-Pattern 3: Forgetting Reranking

The vector retriever returns the k documents "closest" in the embedding space. But vector proximity is not synonymous with relevance. A document can contain the same keywords as the user's question and yet answer a completely different question.

I've seen this anti-pattern cause havoc in technical support systems: the user asks "How do I configure the CrewAI agent timeout?", the retriever returns a chunk about GitHub Actions timeouts (same vocabulary, different context), and the LLM generates a response that's technically correct for the wrong chunk.

The fix: Add a reranking layer between the retriever and the LLM. A reranker (like Cohere Rerank or a local cross-encoder) receives the original question and the k candidates from the retriever, and reorders them by actual semantic relevance, not mere vector proximity. In practice, a well-configured reranker can improve retrieval precision by 15% to 30% — an improvement that translates directly into fewer hallucinations.

Anti-Pattern 4: Insufficient Context in the Prompt

The most widespread and easiest mistake to make: injecting 2-3 chunks into the LLM's prompt and expecting a miracle. Modern models like Gemini 2.5 or Claude handle context windows of hundreds of thousands of tokens. Feeding them 500 tokens of retrieved context is like giving a Formula 1 engine the fuel from a cigarette lighter.

The fix: Experiment aggressively with the size of the injected context window. Increase from top-3 to top-10 or top-15 chunks and measure the impact on response quality. Include enriched metadata in each chunk: source document title, creation date, author, section. These metadata give the LLM a referential framework to evaluate the relevance and recency of the information. In the Ops Copilot, each Algolia record includes not just the post text, but also the title, category, tags, and publication date.

Anti-Pattern 5: Hallucination from Partial Retrieval

This is the most dangerous anti-pattern because it's silent. The retriever finds a partially relevant chunk. The LLM detects that the information is incomplete. Instead of stopping and confessing its ignorance, it completes the answer with fabricated information that sounds perfectly plausible. The user has no way to distinguish which part of the answer comes from retrieval and which part is a hallucination.

In industrial applications, this can be catastrophic. Imagine a RAG system connected to your maintenance documentation that, when asked about the torque specification of a critical bolt, returns a fabricated value because the correct chunk wasn't retrieved. The result could be a mechanical failure in production.

The fix: Double barrier. First: instruct the LLM in the system prompt to answer "I don't have sufficient information in the provided documentation to answer this question" when the retrieved context is insufficient or ambiguous. Include examples in the prompt (few-shot) of correct answers that acknowledge limitations. Second: implement a post-validation of the response. Programmatically evaluate whether the answer contains claims not supported by the injected chunks (frameworks like RAGAS automate this verification with metrics like faithfulness and answer relevancy).

Anti-Pattern 6: Not Measuring Quality

The sixth anti-pattern is cultural, not technical: launching a RAG system to production without evaluation metrics. Asking "does it work?" to five teammates is not an evaluation methodology; it's an anecdote. Without quantitative metrics, you can't know if a change in chunking improved or worsened precision, if a new embedding model is superior to the previous one, or if the reranker you just added justifies its latency cost.

The fix: Implement an automated evaluation framework before launching to production. The most mature tools are:

RAGAS (Retrieval Augmented Generation Assessment): Measures faithfulness (the answer is grounded in context), answer relevancy (the answer is relevant to the question), and context precision (the retrieved chunks are relevant).
DeepEval: An open-source framework that lets you define test suites with metrics like hallucination score, bias, and toxicity.

The key point is to treat RAG evaluation the way you treat your code's unit tests: if it doesn't have tests, it doesn't go to production. Every pipeline iteration (embedding change, chunk size adjustment, new reranker) must pass through the evaluation suite before deployment. It's the same CI/CD philosophy we applied in Autopilot Part 5 with GitHub Actions, but applied to retrieval quality.

Anti-Pattern 7: Using RAG When You Need Tool Calling

This is the anti-pattern that was hardest for me to accept, because it meant questioning my own architectural decision. When we built the agentic obsolescence radar, the first temptation was to use RAG: index all component documentation, datasheets, and price histories in a vector store, and let the LLM search for relevant information for each End of Life alert.

The result was disastrous. LLMs are, as I wrote in that article, mediocre calculators. When the radar needed to calculate the financial impact of an obsolescence (traverse the BOM graph, multiply quantities by prices, sum redesign costs), RAG returned narrative approximations where we needed exact figures. The financial precision was unacceptable for an executive report.

The solution was to radically separate the "semantic brain" from the "mathematical muscle": the LLM (Gemini 2.5 + CrewAI) handles natural language comprehension (extracting the Part Number from a supplier email, understanding the context of an alert), and Python tools (CrewAI's @tool) handle precision operations (SQL queries to Supabase, P&L calculations, relational graph traversal). The result: executive reports generated in 4 seconds with 0% hallucination in numerical data.

The rule I've distilled is simple:

You need...	Use...	Why
Answers about unstructured knowledge (manuals, posts, narrative documentation)	RAG	Semantic retrieval is superior for searching free text
Answers with structured data and numerical precision (SQL, APIs, financial calculations)	Tool Calling	Tools execute deterministic code, no hallucinations
Both (interpret an email + calculate financial impact)	Hybrid architecture	The LLM orchestrates; the tools execute

And if you're wondering how to standardize those connections between the LLM and the tools so you're not locked into a vendor, that's exactly what we addressed in the article about MCP (Model Context Protocol).

Conclusion: RAG Isn't Broken; Your Implementation Is

If there's one message I want you to take from this article, it's this: RAG is a legitimate and powerful architecture when implemented with engineering rigor. The problem isn't the pattern; the problem is that the industry has popularized it as a magical plug-and-play solution, when in reality it's a complex pipeline that requires intelligent chunking, evaluated embeddings, reranking, generous context, hallucination defenses, quality metrics, and the humility to recognize when Tool Calling is the right tool for the job.

The 10x Rule I proposed in the Hidden Economics of AI article applies perfectly here: if RAG doesn't give you a result 10 times better than a direct SQL query or an API call, you're probably using the wrong tool for the wrong problem.

And in the era of the EU AI Act, where traceability (Article 12) and precision are legal obligations for high-risk systems, deploying a RAG that hallucinates isn't just a technical error: it's a regulatory risk.

Sources of Interest:

RAG en Producción: 7 Antipatrones que Destruyen la Precisión (y Cómo los Solucioné)

Daniel — Sat, 11 Jul 2026 14:21:13 +0000

RAG es la aspirina de la IA generativa: todo el mundo la receta, casi nadie entiende cómo funciona realmente, y cuando falla, el paciente sufre alucinaciones. Si has asistido a cualquier conferencia de tecnología en los últimos 18 meses, habrás escuchado la misma promesa repetida como un mantra: "Conecta tu LLM a tus documentos con RAG y tendrás un chatbot que responde con la verdad de tu empresa". Es una promesa seductora. También es, en la mayoría de las implementaciones que he visto, una mentira piadosa.

Lo sé porque he recorrido ambos caminos. Construí un sistema RAG funcional en producción —el Ops Engineering Copilot con Algolia Agent Studio, indexando los más de 70 posts de este blog— y también construí un sistema que rechaza RAG deliberadamente —el radar agéntico de obsolescencia, que usa Tool Calling puro para consultar bases de datos industriales con precisión matemática—. La experiencia de operar ambos sistemas en producción me ha dejado una conclusión incómoda: RAG no es malo; lo que es malo es cómo lo implementamos.

Este artículo es el catálogo de los 7 errores que destruyen la precisión de un sistema RAG, las soluciones que funcionan, y la pregunta que nadie quiere hacerse: ¿realmente necesitas RAG, o necesitas otra cosa?

Antipatrón 1: Chunking a Ciegas

El primer paso de cualquier pipeline RAG es trocear tus documentos en fragmentos (chunks) que se almacenarán como vectores. Y aquí es donde la mayoría de los tutoriales cometen el primer pecado mortal: trocear por longitud fija (por ejemplo, 500 tokens por chunk con 50 tokens de overlap).

El problema es brutal: un párrafo que explica un concepto técnico complejo queda cortado por la mitad. La primera mitad acaba en un chunk, la segunda en otro. Cuando el usuario hace una pregunta, el retriever encuentra la primera mitad (que contiene las palabras clave), pero le falta el contexto de la segunda. El LLM, fiel a su naturaleza, rellena lo que falta con una invención plausible. Alucinación servida.

La solución: Chunking semántico. Trocear por unidades lógicas de significado: secciones delimitadas por headers, párrafos completos, o bloques funcionales del documento. En el Ops Copilot, cuando indexamos los posts de Datalaria con Algolia, cada record corresponde a una sección completa del artículo (delimitada por ### en Markdown), no a un bloque arbitrario de N tokens. El resultado: cada chunk es autosuficiente y contiene un pensamiento completo.

Antipatrón 2: Embeddings Genéricos para Dominios Especializados

Los embeddings pre-entrenados (como text-embedding-3-small de OpenAI o los de Vertex AI) están entrenados con texto general de internet. Funcionan razonablemente bien para preguntas genéricas. Pero cuando tu dominio es altamente especializado —ingeniería industrial, normativa europea, nomenclatura de componentes electrónicos—, la distancia semántica entre términos clave puede ser completamente incorrecta en el espacio vectorial.

Un ejemplo real: en el contexto de la gestión de obsolescencia, los términos "EOL" (End of Life), "NRND" (Not Recommended for New Designs) y "PDN" (Product Discontinuation Notice) están semánticamente muy próximos para un ingeniero de supply chain. Pero para un embedding genérico, "End of Life" podría estar más cerca de un artículo sobre cuidados paliativos que de un aviso de discontinuación de un chip.

La solución: Evalúa los embeddings con tu propio dataset antes de comprometerte. Construye un pequeño benchmark de 50-100 pares pregunta-respuesta de tu dominio y mide la tasa de acierto del retriever (hit rate). Si los embeddings genéricos no superan el 80% de acierto en tu benchmark, considera fine-tuning o embeddings especializados para tu sector. Y si tu dominio es altamente estructurado (códigos, nomenclaturas, tablas), probablemente no necesitas embeddings en absoluto: necesitas Tool Calling.

Antipatrón 3: Olvidar el Reranking

El retriever vectorial te devuelve los k documentos más "cercanos" en el espacio de embeddings. Pero cercanía vectorial no es sinónimo de relevancia. Un documento puede contener las mismas palabras clave que la pregunta del usuario y, sin embargo, responder a una pregunta completamente diferente.

He visto este antipatrón causar estragos en sistemas de soporte técnico: el usuario pregunta "¿Cómo configuro el timeout del agente CrewAI?", el retriever devuelve un chunk sobre timeouts de GitHub Actions (mismo vocabulario, contexto diferente), y el LLM genera una respuesta técnicamente correcta para el chunk equivocado.

La solución: Añadir una capa de reranking entre el retriever y el LLM. Un reranker (como Cohere Rerank o un cross-encoder local) recibe la pregunta original y los k candidatos del retriever, y los reordena por relevancia semántica real, no por simple proximidad vectorial. En la práctica, un reranker bien configurado puede mejorar la precisión del retrieval entre un 15% y un 30%, una mejora que se traduce directamente en menos alucinaciones.

Antipatrón 4: Contexto Insuficiente en el Prompt

El error más extendido y más fácil de cometer: inyectar 2-3 chunks en el prompt del LLM y esperar un milagro. Los modelos modernos como Gemini 2.5 o Claude manejan ventanas de contexto de cientos de miles de tokens. Alimentarlos con 500 tokens de contexto recuperado es como darle a un motor de Fórmula 1 el combustible de un mechero.

La solución: Experimenta agresivamente con el tamaño de la ventana de contexto inyectada. Aumenta de top-3 a top-10 o top-15 chunks y mide el impacto en la calidad de la respuesta. Incluye metadatos enriquecidos en cada chunk: título del documento fuente, fecha de creación, autor, sección. Estos metadatos le dan al LLM un marco referencial para evaluar la relevancia y la actualidad de la información. En el Ops Copilot, cada record de Algolia incluye no solo el texto del post, sino también el título, la categoría, los tags y la fecha de publicación.

Antipatrón 5: Alucinación por Retrieval Parcial

Este es el antipatrón más peligroso porque es silencioso. El retriever encuentra un chunk parcialmente relevante. El LLM detecta que la información está incompleta. En lugar de detenerse y confesar su ignorancia, completa la respuesta con información fabricada que suena perfectamente plausible. El usuario no tiene forma de distinguir qué parte de la respuesta proviene del retrieval y qué parte es una alucinación.

En aplicaciones industriales, esto puede ser catastrófico. Imagina un sistema RAG conectado a tu documentación de mantenimiento que, ante una pregunta sobre el par de apriete de un tornillo crítico, devuelve un valor inventado porque el chunk correcto no fue recuperado. El resultado puede ser un fallo mecánico en producción.

La solución: Doble barrera. Primera: instruye al LLM en el system prompt para que responda "No tengo información suficiente en la documentación proporcionada para responder a esta pregunta" cuando el contexto recuperado sea insuficiente o ambiguo. Incluye ejemplos en el prompt (few-shot) de respuestas correctas que reconocen limitaciones. Segunda: implementa una validación posterior de la respuesta. Evalúa programáticamente si la respuesta contiene afirmaciones que no están respaldadas por los chunks inyectados (frameworks como RAGAS automatizan esta verificación con métricas como faithfulness y answer relevancy).

Antipatrón 6: No Medir la Calidad

El sexto antipatrón es cultural, no técnico: lanzar un sistema RAG a producción sin métricas de evaluación. Preguntar "¿funciona?" a cinco compañeros de equipo no es una metodología de evaluación; es una anécdota. Sin métricas cuantitativas, no puedes saber si un cambio en el chunking mejoró o empeoró la precisión, si un nuevo embedding model es superior al anterior, o si el reranker que acabas de añadir justifica su coste de latencia.

La solución: Implementar un framework de evaluación automatizado antes de lanzar a producción. Las herramientas más maduras son:

RAGAS (Retrieval Augmented Generation Assessment): Mide faithfulness (la respuesta está fundamentada en el contexto), answer relevancy (la respuesta es relevante a la pregunta), y context precision (los chunks recuperados son relevantes).
DeepEval: Framework open-source que permite definir test suites con métricas como hallucination score, bias, y toxicity.

El punto clave es tratar la evaluación de RAG como tratas los tests unitarios de tu código: si no tiene tests, no va a producción. Cada iteración del pipeline (cambio de embedding, ajuste de chunk size, nuevo reranker) debe pasar por la suite de evaluación antes de desplegarse. Es la misma filosofía de CI/CD que aplicamos en el Autopilot Parte 5 con GitHub Actions, pero aplicada a la calidad del retrieval.

Antipatrón 7: Usar RAG Cuando Necesitas Tool Calling

Este es el antipatrón que más me costó aceptar, porque implicaba cuestionar una decisión arquitectónica propia. Cuando construimos el radar agéntico de obsolescencia, la primera tentación fue usar RAG: indexar toda la documentación de componentes, las hojas de datos y los históricos de precios en un vector store, y dejar que el LLM buscara la información relevante ante cada alerta de End of Life.

El resultado fue desastroso. Los LLMs son, como escribí en aquel artículo, calculadoras mediocres. Cuando el radar necesitaba calcular el impacto financiero de una obsolescencia (cruzar el grafo BOM, multiplicar cantidades por precios, sumar costes de rediseño), RAG devolvía aproximaciones narrativas donde necesitábamos cifras exactas. La precisión financiera era inaceptable para un informe ejecutivo.

La solución fue separar radicalmente el "cerebro" semántico del "músculo" matemático: el LLM (Gemini 2.5 + CrewAI) se encarga de la comprensión del lenguaje natural (extraer el Part Number de un email de proveedor, entender el contexto de una alerta), y las herramientas Python (@tool de CrewAI) se encargan de las operaciones de precisión (consultas SQL a Supabase, cálculos de P&L, cruce de grafos relacionales). El resultado: reportes ejecutivos generados en 4 segundos con 0% de alucinación en los datos numéricos.

La regla que he destilado es sencilla:

Necesitas...	Usa...	Por qué
Respuestas sobre conocimiento no estructurado (manuales, posts, documentación narrativa)	RAG	El retrieval semántico es superior para buscar en texto libre
Respuestas con datos estructurados y precisión numérica (SQL, APIs, cálculos financieros)	Tool Calling	Las herramientas ejecutan código determinista, sin alucinaciones
Ambos (interpretar un email + calcular impacto financiero)	Arquitectura híbrida	El LLM orquesta; las herramientas ejecutan

Y si te preguntas cómo estandarizar esas conexiones entre el LLM y las herramientas para no quedar atado a un proveedor, eso es exactamente lo que abordamos en el artículo sobre MCP (Model Context Protocol).

Conclusión: RAG No Está Roto; Tu Implementación Sí

Si hay un mensaje que quiero que te lleves de este artículo es este: RAG es una arquitectura legítima y poderosa cuando se implementa con rigor ingenieril. El problema no es el patrón; el problema es que la industria lo ha popularizado como una solución mágica plug-and-play, cuando en realidad es un pipeline complejo que requiere chunking inteligente, embeddings evaluados, reranking, contexto generoso, defensas contra alucinaciones, métricas de calidad, y la humildad de reconocer cuándo Tool Calling es la herramienta correcta.

La Regla del 10x que propuse en el artículo sobre la Economía Oculta de la IA aplica perfectamente aquí: si RAG no te da un resultado 10 veces mejor que una búsqueda SQL directa o una llamada a una API, probablemente estás usando la herramienta equivocada para el problema equivocado.

Y en la era del EU AI Act, donde la trazabilidad (Artículo 12) y la precisión son obligaciones legales para sistemas de alto riesgo, implementar un RAG que alucina no es solo un error técnico: es un riesgo regulatorio.

Fuentes de Interés:

EU AI Act: What Every Engineer Needs to Know (No Lawyers Required)

Daniel — Sun, 05 Jul 2026 21:36:38 +0000

Picture this scenario: your European startup launches an AI tool that scans résumés to filter candidates in hiring processes. The product works, clients are happy, revenue is growing. Three months later, you receive a formal notification from the national AI supervisory authority. Your system has been classified as "high-risk" under Regulation (EU) 2024/1689, better known as the EU AI Act. You have no mandatory technical documentation, you haven't implemented human oversight, and your training data doesn't meet the governance requirements. Potential fine: up to 35 million euros or 7% of your worldwide annual turnover.

Impossible? Not at all. This is exactly what European regulation has stipulated since February 2025 for prohibited practices, and what from August 2, 2026 extends to the majority of obligations for high-risk systems (Art. 113, Regulation (EU) 2024/1689).

If you already operate AI agents in production — as we've done on this blog with the Autopilot Project or the agentic obsolescence radar — you need to know exactly where the line is. And most guides on the EU AI Act are written by lawyers, for lawyers. Not this one. This one is written by an engineer who translates every article of the regulation into the language we actually understand: architectures, pipelines, and code.

The Risk Pyramid: Classify Your AI in 60 Seconds

The EU AI Act doesn't ban artificial intelligence. What it does is classify every AI system into four risk levels and assign proportional obligations to each level. It's a pragmatic approach inspired by existing regulatory frameworks like REACH for the chemical industry or the Machinery Directive for manufacturing: the higher the potential risk, the stricter the control requirements.

🔴 Unacceptable Risk — PROHIBITED (Article 5)

These practices have been completely banned in the EU since February 2, 2025 (Art. 5, Regulation (EU) 2024/1689). There are no commercial exceptions or sandboxes that permit them. They are the absolute red lines of the regulation:

Subliminal or deceptive manipulation: AI systems designed to distort a person's behavior using techniques that operate below their threshold of consciousness, causing significant harm.
Exploitation of vulnerabilities: AI that exploits the age, disability, or socioeconomic situation of vulnerable persons to alter their behavior in a harmful way.
Social scoring: Systems used by public authorities to evaluate or classify people based on their social behavior or personal traits, resulting in unjustified detrimental treatment.
Predictive policing: AI that predicts a person's criminal behavior based solely on their profiling or personality traits (with limited exceptions for ongoing investigations).
Untargeted facial scraping: The creation or expansion of facial recognition databases through untargeted collection of facial images from the internet or CCTV footage.
Emotion recognition at work and school: Inferring the emotions of employees in the workplace or students in educational institutions (with very limited medical or safety exceptions).
Sensitive biometric categorization: Systems that infer data such as political or religious beliefs, sexual orientation, or race from biometric data.

If any AI system in your organization touches any of these categories, the correct position is not to "find a legal loophole" but to remove it from the product. The fine for these practices reaches 35 million euros or 7% of global annual turnover, whichever is higher (Art. 99.3, Regulation (EU) 2024/1689).

🟠 High Risk — STRICT REGULATION (Articles 6-49 and Annex III)

This is where most enterprise AI systems land, and where the regulation demands the greatest technical effort. A system is classified as "high-risk" if it is a safety component of a product regulated by EU harmonized legislation (medical devices, toys, aviation), or if it operates in any of the sensitive areas defined in Annex III of the regulation:

Critical infrastructure: Systems for the management of essential services (transport, water, gas, electricity, telecommunications).
Education and training: AI that determines access to educational institutions or assesses student performance.
Employment and HR: AI tools for recruitment, CV screening, task assignment, or worker management. This is directly relevant to what we analyzed in the Onboarding with AI article: using IDP and GenAI to automate employee onboarding falls into the high-risk category if the system makes or influences decisions about people.
Essential services: Systems that determine access to credit, essential public services, or life and health insurance. Startups like Clarity AI, which calculates sustainability scores for investment decisions, operate directly in this zone.
Law enforcement, justice, and migration: AI in border control, asylum processing, security risk assessment, or the administration of justice.
Biometrics: Certain remote biometric identification systems.

The fine for non-compliance with high-risk system obligations is up to 15 million euros or 3% of worldwide annual turnover (Art. 99.4, Regulation (EU) 2024/1689).

Important note: The legislative proposal known as the "Digital Omnibus" (2025) may postpone certain Annex III (high-risk) obligations from August 2026 to December 2027. However, the underlying technical requirements remain unchanged — only the enforcement timeline shifts. Don't wait.

🟡 Limited Risk — TRANSPARENCY (Articles 50-52)

Limited-risk systems have a single fundamental obligation: inform the user that they are interacting with an AI. This applies to chatbots, content generation systems (deepfakes), and conversational assistants. Our Ops Engineering Copilot (the chatbot based on Algolia Agent Studio and RAG that answers questions about the blog) falls into this category: the user must know they're talking to a machine, not a person.

🟢 Minimal Risk — FREE (no additional obligations)

The majority of commercial AI systems fall here: spam filters, recommendation engines, generative AI for marketing content. The Autopilot Project that automatically generates social media posts has no specific obligations under the EU AI Act beyond general good practices. The same applies to tools like the unit converter or the flashcards app.

The 5 Technical Commandments of High Risk

If your system falls into the 🟠 category, you need to implement five blocks of technical requirements. What's notable is that, if you already follow the engineering practices we've documented on this blog, you're closer to compliance than you think:

1. Risk Management — Article 9

The regulation requires establishing, implementing, and maintaining a risk management system that operates throughout the entire lifecycle of the AI system (Art. 9, Regulation (EU) 2024/1689). This includes identifying known and foreseeable risks to health, safety, and fundamental rights, estimating those risks, and adopting mitigation measures.

Translation for engineers: It's a CI/CD pipeline applied to risk. Document, monitor, iterate. It's not a static document you write once and file away; it's a living process. Exactly the philosophy that W. Edwards Deming systematized with the PDCA cycle (Plan-Do-Check-Act). If you already implement PDCA in your quality processes, the AI Act's risk management will feel familiar.

2. Data Governance — Article 10

Training, validation, and testing datasets must meet high-quality criteria: be representative, relevant, free of errors to the extent possible, and with appropriate governance practices to prevent bias (Art. 10, Regulation (EU) 2024/1689).

Translation: The data hygiene we preached in the S&OP series is no longer an optional best practice — it's the law. The cleanup pipeline with Z-Score for outlier detection, anomaly flagging (not deletion), and persistence in Supabase with Row Level Security that we built in that series directly fulfills the spirit of this article. What the regulation adds is the requirement that all of this be documented and auditable.

3. Technical Documentation — Article 11 and Annex IV

Before marketing or putting a high-risk system into service, you must prepare a technical file demonstrating compliance with the regulation (Art. 11, Regulation (EU) 2024/1689). Annex IV details the minimum content: general system description, detailed architecture and components, training data information, performance metrics (accuracy, robustness, cybersecurity), and the development process.

Translation: Your README and your Confluence page aren't enough. The regulation requires a living document covering the system architecture (like the Mermaid diagrams we use in the Obsolescence series), model performance metrics, robustness tests, and cybersecurity measures. Think of it as an Architecture Decision Record on regulatory steroids.

4. Record-Keeping and Logging — Article 12

High-risk systems must be designed to automatically generate logs during operation, ensuring full traceability of every decision and the ability to reconstruct events if a compliance issue arises (Art. 12, Regulation (EU) 2024/1689).

Translation: If you already use Supabase + FastAPI with the architecture from the agentic radar, this should sound familiar. Every ingestion event, every CrewAI agent decision, every LLM response gets logged in the database. What the regulation formalizes is what any competent backend engineer should already be doing: structured logging, not as an afterthought, but as a design requirement from day zero.

5. Human Oversight — Article 14

The system must be designed with "human-in-the-loop" or "human-on-the-loop" mechanisms, ensuring that a qualified human operator can oversee, interpret, and if necessary, override the AI's decisions (Art. 14, Regulation (EU) 2024/1689).

Translation: This is the principle we implemented in Autopilot Part 5 with GitHub Environments for manual approval. The pipeline generates content automatically with AI agents, but no post gets published without explicit human review and approval. It's not a new concept for us; now it has the force of law.

Spain and the AESIA: The Local Sheriff

The EU AI Act is a European Regulation (not a Directive), which means it is directly applicable in Spain without needing national legislative transposition. However, Spain has taken an additional step: in May 2026, the Council of Ministers approved the Spanish AI Law, which complements the European regulation and defines the role of the AESIA (Spanish Agency for AI Supervision) as the national competent authority.

The AESIA is the entity that will investigate complaints, conduct audits, and, where applicable, impose the AI Act's penalties on Spanish territory. Additionally, Spain has launched regulatory sandboxes: controlled environments where startups and companies can test innovative AI systems under AESIA supervision, without sanctioning risk during the trial period.

The Spanish startups we've analyzed on this blog are not strangers to this regulation. Clarity AI operates in ESG financial scoring, an area that Annex III classifies as high-risk. Nextail makes inventory decisions with prescriptive AI in the supply chain. Devo protects critical military infrastructure, the most sensitive category in the regulation. All of them will need to demonstrate compliance.

Compliance-as-Code: The Engineer's Checklist

If there's one thing we've learned building data pipelines on this blog, it's that documentation that isn't automated doesn't get maintained. Here's an actionable checklist, designed so that a technical team can execute it sprint by sprint:

Phase 1 — Inventory and Classification (Sprint 1)

Inventory all AI systems in your organization (including ones you don't call "AI" but internally use ML)
Classify each system in the risk pyramid: Prohibited / High / Limited / Minimal
For each system classified as High Risk, assign a technical compliance owner

Phase 2 — Technical Implementation (Sprints 2-4)

Implement automatic logging of model decisions (Art. 12): timestamps, inputs, outputs, confidence scores
Create living technical documentation (Art. 11 + Annex IV): architecture, data, metrics, process
Design human oversight mechanism (Art. 14): manual approval, "kill switch" button, monitoring dashboards
Audit training datasets (Art. 10): bias, representativeness, traceability, versioning

Phase 3 — Continuous Management (Ongoing)

Establish risk management pipeline (Art. 9): periodic review, Concept Drift monitoring, mitigation plan
For Limited Risk systems: verify the user knows they're interacting with AI
Configure cost and usage alerts (connect with The Hidden Economics of AI: compliance is an additional hidden cost)
Register the system in the EU public database (when applicable for high-risk)

The Regulation Isn't the Enemy; Ignorance Is

There is an understandable temptation to see the EU AI Act as a bureaucratic brake on European innovation. And in part, the criticism has merit: the definition of "high-risk" in Annex III is extremely broad, the documentation burden of Annex IV can be disproportionate for a five-person startup, and the uncertainty around the Digital Omnibus generates paralysis in legal teams.

But if you strip away the legal jargon and look at the bare technical requirements, what the regulation actually asks is: document your system, control your data, log your AI's decisions, manage risks continuously, and keep a human in the control loop. In other words, exactly what a good engineer should already be doing.

If you've followed the practices we've documented on this blog — data hygiene with Z-Score, automatic logging with FastAPI and Supabase, human-in-the-loop with GitHub Environments, risk management with Deming's PDCA cycle — you're already 80% of the way to compliance. The remaining 20% is formalization and documentation.

As Deming said: "It is not enough to do your best; you must first know what to do." Now the regulation tells you what to do. How to do it, you already know. Or at least, you have a blog where you can find it.

Sources of Interest:

EU AI Act: Lo que Todo Ingeniero Español Necesita Saber (Sin Abogados)

Daniel — Sun, 05 Jul 2026 21:32:28 +0000

Imagina este escenario: tu startup española lanza una herramienta de IA que analiza currículums para filtrar candidatos en procesos de selección. El producto funciona, los clientes están contentos, la facturación crece. Tres meses después, recibes una notificación formal de la AESIA (Agencia Española de Supervisión de Inteligencia Artificial). Tu sistema ha sido clasificado como "alto riesgo" bajo el Reglamento (UE) 2024/1689, más conocido como el EU AI Act. No tienes documentación técnica obligatoria, no has implementado supervisión humana, y tus datos de entrenamiento no cumplen los requisitos de gobernanza. Multa potencial: hasta 35 millones de euros o el 7% de tu facturación mundial anual.

¿Imposible? No. Es exactamente lo que la regulación europea vigente estipula desde febrero de 2025 para las prácticas prohibidas, y lo que a partir del 2 de agosto de 2026 se extiende a la mayoría de las obligaciones para sistemas de alto riesgo (Art. 113, Reglamento (UE) 2024/1689).

Si ya operas agentes de IA en producción —como hemos hecho en este blog con el Proyecto Autopilot o el radar agéntico de obsolescencia— necesitas saber exactamente dónde está la línea. Y la mayoría de guías sobre el EU AI Act están escritas por abogados, para abogados. Esta no. Esta está escrita por un ingeniero que traduce cada artículo del reglamento al lenguaje que de verdad entendemos: arquitecturas, pipelines y código.

La Pirámide del Riesgo: Clasifica tu IA en 60 Segundos

El EU AI Act no prohíbe la inteligencia artificial. Lo que hace es clasificar cada sistema de IA en cuatro niveles de riesgo, y asignar obligaciones proporcionales a cada nivel. Es un enfoque pragmático que se inspira en marcos regulatorios existentes como REACH para la industria química o la Directiva de Máquinas para la industria manufacturera: a mayor riesgo potencial, mayor exigencia de control.

🔴 Riesgo Inaceptable — PROHIBIDO (Artículo 5)

Estas prácticas están completamente vetadas en la UE desde el 2 de febrero de 2025 (Art. 5, Reglamento (UE) 2024/1689). No hay excepciones comerciales ni sandboxes que las permitan. Son las líneas rojas absolutas de la regulación:

Manipulación subliminal o engañosa: Sistemas de IA diseñados para distorsionar el comportamiento de una persona usando técnicas que operan por debajo de su umbral de consciencia, causando un perjuicio significativo.
Explotación de vulnerabilidades: IA que explota la edad, la discapacidad o la situación socioeconómica de personas vulnerables para alterar su comportamiento de forma perjudicial.
Puntuación social (social scoring): Sistemas utilizados por autoridades públicas para evaluar o clasificar a personas en función de su comportamiento social o sus rasgos personales, resultando en un trato desfavorable injustificado.
Policiamiento predictivo: IA que predice el comportamiento delictivo de una persona basándose exclusivamente en su perfilado o rasgos de personalidad (con excepciones limitadas para investigaciones en curso).
Scraping facial masivo: La creación o expansión de bases de datos de reconocimiento facial mediante la recopilación no dirigida de imágenes faciales de Internet o de cámaras de vigilancia.
Reconocimiento emocional en el trabajo y la educación: Inferir emociones de empleados en el lugar de trabajo o de estudiantes en centros educativos (con excepciones médicas o de seguridad muy limitadas).
Categorización biométrica sensible: Sistemas que infieren datos como creencias políticas o religiosas, orientación sexual o raza a partir de datos biométricos.

Si un sistema de IA de tu organización roza cualquiera de estas categorías, la posición correcta no es «buscar un hueco legal», sino eliminarlo del producto. La multa para estas prácticas alcanza los 35 millones de euros o el 7% de la facturación anual global, lo que sea mayor (Art. 99.3, Reglamento (UE) 2024/1689).

🟠 Alto Riesgo — REGULACIÓN ESTRICTA (Artículos 6-49 y Anexo III)

Aquí es donde la mayoría de los sistemas empresariales de IA caen, y donde la regulación exige el mayor esfuerzo técnico. Un sistema se clasifica como «alto riesgo» si es un componente de seguridad de un producto regulado por la legislación armonizada de la UE (dispositivos médicos, juguetes, aviación), o si opera en alguna de las áreas sensibles definidas en el Anexo III del reglamento:

Infraestructura crítica: Sistemas para la gestión de servicios esenciales (transporte, agua, gas, electricidad, telecomunicaciones).
Educación y formación: IA que determina el acceso a instituciones educativas o que evalúa el rendimiento de estudiantes.
Empleo y RRHH: Herramientas de IA para reclutamiento, filtrado de CVs, asignación de tareas o gestión de trabajadores. Esto es directamente relevante para lo que analizamos en el artículo sobre Onboarding con IA: usar IDP y GenAI para automatizar la incorporación de empleados cae en la categoría de alto riesgo si el sistema toma o influye en decisiones sobre personas.
Servicios esenciales: Sistemas que determinan el acceso a crédito, servicios públicos esenciales o seguros de vida y salud. Startups como Clarity AI, que calcula scores de sostenibilidad para decisiones de inversión, operan directamente en esta zona.
Orden público, justicia y migración: IA en control fronterizo, asilo, evaluación de riesgos de seguridad o administración de justicia.
Biometría: Ciertos sistemas de identificación biométrica a distancia.

La multa por incumplimiento en sistemas de alto riesgo es de hasta 15 millones de euros o el 3% de la facturación mundial anual (Art. 99.4, Reglamento (UE) 2024/1689).

Nota importante: La propuesta legislativa conocida como "Digital Omnibus" (2025) podría aplazar algunas obligaciones del Anexo III (alto riesgo) de agosto de 2026 a diciembre de 2027. Sin embargo, los requisitos técnicos subyacentes no cambian, solo el calendario de enforcement. No esperes.

🟡 Riesgo Limitado — TRANSPARENCIA (Artículos 50-52)

Los sistemas de riesgo limitado tienen una única obligación fundamental: informar al usuario de que está interactuando con una IA. Esto aplica a chatbots, sistemas de generación de contenido (deepfakes), y asistentes conversacionales. Nuestro Ops Engineering Copilot (el chatbot basado en Algolia Agent Studio y RAG que responde preguntas sobre el blog) caería en esta categoría: el usuario debe saber que habla con una máquina, no con una persona.

🟢 Riesgo Mínimo — LIBRE (sin obligaciones adicionales)

La mayoría de los sistemas de IA comerciales caen aquí: filtros de spam, sistemas de recomendación, IA generativa para contenido de marketing. El Proyecto Autopilot que genera automáticamente posts para redes sociales no tiene obligaciones específicas bajo el EU AI Act más allá de las buenas prácticas generales. Lo mismo aplica a herramientas como el conversor de unidades o la app de flashcards.

Los 5 Mandamientos Técnicos del Alto Riesgo

Si tu sistema cae en la categoría 🟠, necesitas implementar cinco bloques de requisitos técnicos. Lo notable es que, si ya sigues las prácticas de ingeniería que hemos documentado en este blog, estás más cerca del cumplimiento de lo que crees. Veamos:

1. Gestión de Riesgos — Artículo 9

El reglamento exige establecer, implementar y mantener un sistema de gestión de riesgos que opere durante todo el ciclo de vida del sistema de IA (Art. 9, Reglamento (UE) 2024/1689). Esto incluye la identificación de riesgos conocidos y previsibles para la salud, la seguridad y los derechos fundamentales, la estimación de esos riesgos, y la adopción de medidas de mitigación.

Traducción para ingenieros: Es un pipeline de CI/CD aplicado al riesgo. Documenta, monitorea, itera. No es un documento estático que se escribe una vez y se archiva; es un proceso vivo. Exactamente la filosofía que W. Edwards Deming sistematizó con el ciclo PDCA (Plan-Do-Check-Act). Si ya implementas PDCA en tus procesos de calidad, la gestión de riesgos del AI Act te será familiar. Si además conoces el Concept Drift (la degradación progresiva de un modelo en producción que Deming habría llamado «proceso inestable»), ya tienes la mentalidad correcta.

2. Gobernanza de Datos — Artículo 10

Los datos de entrenamiento, validación y test deben cumplir criterios de alta calidad: ser representativos, relevantes, libres de errores en la medida de lo posible, y con prácticas de gobernanza apropiadas para prevenir sesgos (Art. 10, Reglamento (UE) 2024/1689).

Traducción: La higiene de datos que predicamos en la serie S&OP ya no es una buena práctica opcional; es ley. El pipeline de limpieza con Z-Score para detectar outliers, el marcado (no borrado) de anomalías, y la persistencia en Supabase con Row Level Security que construimos en esa serie cumplen directamente con el espíritu de este artículo. Lo que el reglamento añade es la exigencia de que todo esto esté documentado y sea auditable.

3. Documentación Técnica — Artículo 11 y Anexo IV

Antes de comercializar o poner en servicio un sistema de alto riesgo, debes preparar un expediente técnico que demuestre el cumplimiento del reglamento (Art. 11, Reglamento (UE) 2024/1689). El Anexo IV detalla el contenido mínimo: descripción general del sistema, arquitectura detallada y componentes, información sobre los datos de entrenamiento, métricas de rendimiento (exactitud, robustez, ciberseguridad), y el proceso de desarrollo.

Traducción: Tu README y tu Confluence no bastan. El reglamento exige un documento vivo que cubra la arquitectura del sistema (como los diagramas Mermaid que usamos en la serie de Obsolescencia), las métricas de rendimiento del modelo, las pruebas de robustez y las medidas de ciberseguridad. Piensa en ello como un documento de arquitectura de referencia (Architecture Decision Record) con esteroides regulatorios.

4. Registros y Logging — Artículo 12

Los sistemas de alto riesgo deben diseñarse para generar logs automáticos durante su funcionamiento, garantizando la trazabilidad de cada decisión y la capacidad de reconstruir eventos si surge un problema de cumplimiento (Art. 12, Reglamento (UE) 2024/1689).

Traducción: Si ya usas Supabase + FastAPI con la arquitectura del radar agéntico, esto debería sonar familiar. Cada evento de ingesta, cada decisión del agente CrewAI, cada respuesta del LLM queda registrado en la base de datos. Lo que el reglamento formaliza es lo que cualquier ingeniero de backend competente ya debería estar haciendo: logging estructurado, no como una idea tardía, sino como un requisito de diseño desde el día cero.

5. Supervisión Humana — Artículo 14

El sistema debe diseñarse con mecanismos de «human-in-the-loop» o «human-on-the-loop», garantizando que un operador humano cualificado pueda supervisar, interpretar y, si es necesario, anular las decisiones de la IA (Art. 14, Reglamento (UE) 2024/1689).

Traducción: Este es el principio que implementamos en el Autopilot Parte 5 con los GitHub Environments de aprobación manual. El pipeline genera contenido automáticamente con agentes de IA, pero ningún post se publica sin la revisión y aprobación explícita de un humano. No es un concepto nuevo para nosotros; ahora tiene fuerza de ley.

España y la AESIA: El Sheriff Local

El EU AI Act es un Reglamento europeo (no una Directiva), lo que significa que es directamente aplicable en España sin necesidad de transposición legislativa nacional. Sin embargo, España ha dado un paso adicional: en mayo de 2026, el Consejo de Ministros aprobó la Ley española de Inteligencia Artificial, que complementa el reglamento europeo y define el rol de la AESIA (Agencia Española de Supervisión de Inteligencia Artificial) como autoridad nacional competente.

La AESIA es la entidad que investigará denuncias, realizará auditorías y, en su caso, impondrá las sanciones del AI Act en territorio español. Además, España ha puesto en marcha sandboxes regulatorios: entornos controlados donde startups y empresas pueden testear sistemas de IA innovadores bajo la supervisión de la AESIA, sin riesgo sancionador durante el periodo de prueba. Es un mecanismo inspirado en los que ya utilizan la CNMV y el Banco de España para fintech.

Las startups españolas que hemos analizado en este blog no son ajenas a esta regulación. Clarity AI opera en el scoring financiero ESG, un área que el Anexo III clasifica como alto riesgo. Nextail toma decisiones de inventario con IA prescriptiva en la cadena de suministro, y ya tuvo que adaptarse al ESPR 2026. Devo protege infraestructura crítica militar, la categoría más sensible del reglamento. Todas ellas deberán demostrar cumplimiento.

Compliance-as-Code: El Checklist del Ingeniero

Si algo hemos aprendido construyendo pipelines de datos en este blog, es que la documentación que no está automatizada no se mantiene. Aquí va un checklist accionable, diseñado para que un equipo técnico pueda ejecutarlo sprint a sprint:

Fase 1 — Inventario y Clasificación (Sprint 1)

Inventariar todos los sistemas de IA de tu organización (incluidos los que no llamas «IA» pero usan ML internamente)
Clasificar cada sistema en la pirámide de riesgo: Prohibido / Alto / Limitado / Mínimo
Para cada sistema clasificado como Alto Riesgo, asignar un responsable técnico de cumplimiento

Fase 2 — Implementación Técnica (Sprints 2-4)

Implementar logging automático de decisiones del modelo (Art. 12): timestamps, inputs, outputs, scores de confianza
Crear documentación técnica viva (Art. 11 + Anexo IV): arquitectura, datos, métricas, proceso
Diseñar mecanismo de supervisión humana (Art. 14): aprobación manual, botón de «kill switch», dashboards de monitoreo
Auditar datasets de entrenamiento (Art. 10): sesgo, representatividad, trazabilidad, versionado

Fase 3 — Gestión Continua (Ongoing)

Establecer pipeline de gestión de riesgos (Art. 9): revisión periódica, monitoreo de Concept Drift, plan de mitigación
Para sistemas de Riesgo Limitado: verificar que el usuario sabe que interactúa con IA
Configurar alertas de coste y uso (conectar con la Economía Oculta de la IA: el compliance es un coste oculto adicional)
Registrar el sistema en la base de datos pública de la UE (cuando aplique para alto riesgo)

El Reglamento No Es el Enemigo; la Ignorancia Sí

Existe una tentación comprensible de ver el EU AI Act como un freno burocrático a la innovación europea. Y en parte, la crítica tiene fundamento: la definición de «alto riesgo» en el Anexo III es extremadamente amplia, la carga documental del Anexo IV puede resultar desproporcionada para una startup de cinco personas, y la incertidumbre sobre el Digital Omnibus genera parálisis en los equipos legales.

Pero si retiras la capa de jerga legal y miras los requisitos técnicos desnudos, lo que el reglamento realmente pide es: documenta tu sistema, controla tus datos, registra las decisiones de tu IA, gestiona los riesgos de forma continua, y mantén a un humano en el bucle de control. Es decir, exactamente lo que un buen ingeniero ya debería estar haciendo.

Si has seguido las prácticas que documentamos en este blog —higiene de datos con Z-Score, logging automático con FastAPI y Supabase, human-in-the-loop con GitHub Environments, gestión de riesgos con el ciclo PDCA de Deming—, ya estás al 80% del camino hacia el cumplimiento. El 20% restante es formalización y documentación.

Como decía Deming: "No basta con hacer lo mejor que puedas; primero debes saber qué hacer". Ahora la regulación te dice qué hacer. El cómo hacerlo, ya lo sabes. O al menos, ya tienes un blog donde encontrarlo.