DEV Community: Datalaria

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.

Fuentes de Interés:

MCP (Model Context Protocol): The Standard That Wants to Be the USB of Artificial Intelligence

Daniel — Sun, 28 Jun 2026 10:42:34 +0000

If you've ever tried building an AI agent system in production, you know the pain. During the construction of the agentic radar for Obsolescence, I faced the problem of connecting Gemini 2.5 with my Supabase database and an external API. I had to write custom code to adapt the tool schema (Tool Calling) to the exact format that Google demands.

If tomorrow I decided to migrate that exact same system to Anthropic's Claude or OpenAI's GPT-4o, I would have to rewrite the entire tool integration layer because each vendor uses its own JSON dialect and its own argument validation logic (Function Calling).

It's the same chaos we lived through in the late 90s with mobile phone chargers: every brand had its proprietary connector. Then USB arrived and unified everything. That is exactly the ambition behind MCP (Model Context Protocol): to become the USB of Artificial Intelligence.

What Exactly is the Model Context Protocol?

Initially proposed by Anthropic and rapidly adopted by a coalition of open-source companies, MCP is an open standard for connecting AI models with data sources and tools.

The design premise is elegantly simple, separating the architecture into two independent pieces:

MCP Hosts: Applications or frameworks where the LLM resides (for example, the Claude desktop app, a LangChain script, or your own Python application).
MCP Servers: Lightweight, small programs that expose data or tools to the Host following a strict standard contract (for example, an MCP server that reads your PostgreSQL database, another that reads your GitHub repository).

The magic happens in the middle. The Host (the LLM) tells the MCP Server: "What tools and resources do you have available?". The server responds in a universal format. From there, the LLM can read, write, or execute actions without the developer having had to write a proprietary integration between that specific model and that specific tool.

Comparison: MCP vs Native Tool Calling

On this blog, I have vehemently defended why Tool Calling is infinitely superior to traditional RAG for industrial applications that require precision. MCP does not replace Tool Calling; it standardizes it.

Let's look at the architectural difference:

Feature	Classic Tool Calling	MCP (Model Context Protocol)
Integration	1-to-1 (Specific Model ↔ Specific Tool)	N-to-M (Any Model ↔ Any MCP Server)
Format	Dictated by the LLM vendor (Google, OpenAI)	Standard, agnostic JSON-RPC 2.0
Discovery	Developer injects tools into the prompt	Host discovers tools dynamically
Portability	None. Migrating LLMs requires refactoring.	Total. You write the MCP server once.

Building an MCP Server: A Real Example

To illustrate why this changes the game for operations and backend engineers, let's imagine we want to expose a Supabase table (e.g., critical component inventory) to our LLM.

With a traditional CrewAI or Langchain approach, we would write a custom tool bound to that framework. With MCP, we write a universal Python server using the official SDK:

from mcp.server.fastmcp import FastMCP
import supabase

# Initialize the MCP server
mcp = FastMCP("Supabase_Inventory_Server")
db = supabase.create_client(URL, KEY)

@mcp.tool()
def get_critical_stock(part_number: str) -> str:
    """Fetches the stock level of a specific component."""
    response = db.table("inventory").select("stock").eq("pn", part_number).execute()

    if not response.data:
        return "Component not found."

    stock = response.data[0]['stock']
    return f"The current stock for {part_number} is {stock} units."

if __name__ == "__main__":
    # The server starts and listens for requests over stdio (JSON-RPC)
    mcp.run()

That code block is all you need. Once running, any MCP-compatible application (including Claude's official interface) can connect to this server, read the function's description (docstring), and decide when to call get_critical_stock with the correct arguments.

Opinion: Will MCP Be the Definitive Standard?

The history of software is littered with "universal standards" that only managed to add one more standard to the list of competing standards. Will MCP survive?

It has two massive advantages in its favor. The first is that it solves a real, acute pain point for corporate developers, who are sick of rewriting integrations every time a new model comes out. The second is the local-first approach. Standard MCP communication uses stdio (standard input/output), which means the MCP server runs locally on your machine or private network. This is a wet dream for industrial cybersecurity because the data never leaves your infrastructure until the LLM explicitly and authorizedly requests it.

However, MCP's success will depend on adoption by the dominant duopoly: Google and OpenAI. If Anthropic manages to create a large enough open-source ecosystem (like Kubernetes once did against proprietary clouds), the other giants will be forced to support it natively.

If you are designing the architecture for an Agentic Project Management Office or any system where you need to connect AI agents with legacy ERPs, PLMs, or document repositories, my recommendation is to bet on isolating your connectors. Today it might be through independent Python functions, and tomorrow, probably, wrapping those same functions in an MCP Server.

Just as USB killed hundreds of proprietary connectors, MCP has the potential to finally democratize LLM access to the "muscle" of enterprise data.

Sources of Interest:

MCP (Model Context Protocol): El Estándar que Quiere Ser el USB de la Inteligencia Artificial

Daniel — Sun, 28 Jun 2026 10:35:17 +0000

Si has intentado construir un sistema de agentes de IA en producción, conoces el dolor. Durante la construcción del radar agéntico para Obsolescencia, me enfrenté al problema de conectar a Gemini 2.5 con mi base de datos en Supabase y una API externa. Tuve que escribir código específico para adaptar el esquema de herramientas (Tool Calling) al formato exacto que exige Google.

Si mañana decidiera migrar ese mismo sistema a Claude de Anthropic o a GPT-4o de OpenAI, tendría que reescribir toda la capa de integración de herramientas porque cada proveedor usa su propio dialecto de JSON y su propia lógica de validación de argumentos (Function Calling).

Es el mismo caos que vivíamos a finales de los 90 con los cargadores de móviles: cada marca tenía su conector propietario. Luego llegó el USB y lo unificó todo. Esa es exactamente la ambición detrás de MCP (Model Context Protocol): convertirse en el USB de la Inteligencia Artificial.

¿Qué es exactamente el Model Context Protocol?

Propuesto inicialmente por Anthropic y rápidamente adoptado por una coalición de empresas de código abierto, MCP es un estándar abierto para conectar modelos de IA con fuentes de datos y herramientas.

La premisa de diseño es elegantemente simple, separando la arquitectura en dos piezas independientes:

MCP Hosts: Aplicaciones o frameworks donde reside el LLM (por ejemplo, la app de escritorio de Claude, un script de LangChain, o tu propia aplicación en Python).
MCP Servers: Pequeños programas ligeros que exponen datos o herramientas al Host siguiendo un contrato estándar estricto (por ejemplo, un servidor MCP que lee tu base de datos PostgreSQL, otro que lee tu repositorio de GitHub).

La magia ocurre en el medio. El Host (el LLM) le dice al Servidor MCP: "¿Qué herramientas y recursos tienes disponibles?". El servidor responde en un formato universal. A partir de ahí, el LLM puede leer, escribir o ejecutar acciones sin que el desarrollador haya tenido que escribir una integración propietaria entre ese modelo específico y esa herramienta específica.

Comparativa: MCP vs Tool Calling Nativo

En el blog he defendido vehementemente por qué el Tool Calling es infinitamente superior al RAG tradicional para aplicaciones industriales que requieren precisión. MCP no reemplaza al Tool Calling; lo estandariza.

Veamos la diferencia arquitectónica:

Característica	Tool Calling Clásico	MCP (Model Context Protocol)
Integración	1 a 1 (Modelo específico ↔ Herramienta específica)	N a M (Cualquier Modelo ↔ Cualquier Servidor MCP)
Formato	Dictado por el proveedor del LLM (Google, OpenAI)	Estándar JSON-RPC 2.0 agnóstico
Descubrimiento	El desarrollador inyecta las herramientas en el prompt	El Host descubre herramientas dinámicamente
Portabilidad	Nula. Migrar de LLM requiere refactorización.	Total. Escribes el servidor MCP una vez.

Construyendo un Servidor MCP: Un Ejemplo Real

Para ilustrar por qué esto cambia las reglas del juego para ingenieros de operaciones y backend, imaginemos que queremos exponer una tabla de Supabase (por ejemplo, el inventario de componentes críticos) a nuestro LLM.

Con un enfoque tradicional de CrewAI o Langchain, escribiríamos una herramienta personalizada atada a ese framework. Con MCP, escribimos un servidor universal en Python utilizando el SDK oficial:

from mcp.server.fastmcp import FastMCP
import supabase

# Inicializamos el servidor MCP
mcp = FastMCP("Supabase_Inventory_Server")
db = supabase.create_client(URL, KEY)

@mcp.tool()
def get_critical_stock(part_number: str) -> str:
    """Busca el nivel de stock de un componente específico."""
    response = db.table("inventory").select("stock").eq("pn", part_number).execute()

    if not response.data:
        return "Componente no encontrado."

    stock = response.data[0]['stock']
    return f"El stock actual para {part_number} es de {stock} unidades."

if __name__ == "__main__":
    # El servidor arranca y escucha peticiones sobre stdio (JSON-RPC)
    mcp.run()

Ese bloque de código es todo lo que necesitas. Una vez en ejecución, cualquier aplicación compatible con MCP (incluyendo la interfaz oficial de Claude) puede conectarse a este servidor, leer la descripción (docstring) de la función, y decidir cuándo llamar a get_critical_stock con los argumentos correctos.

Opinión: ¿Será MCP el Estándar Definitivo?

La historia del software está llena de "estándares universales" que solo lograron añadir un estándar adicional a la lista de estándares competidores. ¿Sobrevivirá MCP?

Tiene dos ventajas enormes a su favor. La primera es que resuelve un dolor real y agudo para los desarrolladores corporativos, que están hartos de reescribir integraciones cada vez que sale un nuevo modelo. La segunda es el enfoque local-first. La comunicación estándar de MCP utiliza stdio (entrada y salida estándar), lo que significa que el servidor MCP se ejecuta localmente en tu máquina o tu red privada. Esto es un sueño húmedo para la ciberseguridad industrial, porque los datos nunca abandonan tu infraestructura hasta que el LLM los solicita explícitamente y con autorización.

Sin embargo, el éxito de MCP dependerá de la adopción por parte del duopolio dominante: Google y OpenAI. Si Anthropic logra crear un ecosistema open-source lo suficientemente grande (como Kubernetes hizo en su día contra las nubes propietarias), los demás gigantes se verán obligados a soportarlo de forma nativa.

Si estás diseñando la arquitectura de un Project Management Office Agéntico o cualquier sistema donde necesites conectar agentes de IA con ERPs heredados, PLMs o repositorios documentales, mi recomendación es apostar por aislar tus conectores. Hoy puede ser mediante funciones de Python independientes, y mañana, probablemente, envolviendo esas mismas funciones en un Servidor MCP.

Al igual que el USB mató a cientos de conectores propietarios, MCP tiene el potencial de democratizar finalmente el acceso de los LLMs a la "musculatura" de los datos empresariales.

Fuentes de Interés:

Claude Shannon: The Man Who Turned the World into Bits and Defined the Future of AI

Daniel — Sun, 21 Jun 2026 08:20:29 +0000

There are historical figures who discover continents, and there are figures who invent the underlying physics that allow the ships to exist. In the realm of technology and data, Claude Shannon unequivocally belongs to the latter category. If you can read this article on your screen today, if your smartphone can compress a 12-megapixel photo, and if Multiverse Computing can compress a massive LLM into an edge chip, it is because Shannon dictated the mathematical laws of information more than 75 years ago.

While Abraham Wald taught us to read the silence of missing data and W. Edwards Deming systematized industrial quality, Shannon did something even more fundamental: he isolated the concept of 'information' from the physical meaning of the message.

The Birth of the Bit: Bell Labs, 1948

To understand Shannon's titanic achievement, you have to understand the chaos of communication in the early 20th century. The telegraph, telephone, radio, and television were considered distinct physical phenomena. Engineers improved transmission by reducing electrical noise in cables, but there was no unified theory.

In 1948, working at the mythical Bell Labs, Shannon published "A Mathematical Theory of Communication". In its pages, Shannon introduced for the first time in print the word "bit" (a contraction of binary digit, suggested by his colleague John Tukey).

Shannon proved mathematically that all information — whether text, audio, image, or video — could be encoded into a sequence of 1s and 0s. The human meaning of the message was irrelevant to the engineering problem of transmitting it. By decoupling meaning from mechanics, Shannon unified all communication media under a single mathematical framework.

Information Entropy: Measuring the Unpredictable

The most revolutionary concept Shannon borrowed from thermodynamics was Entropy. In physics, entropy measures the degree of disorder in a system. Shannon adapted the term to measure the uncertainty or surprise in a data message.

Imagine I send you a predictable message: "The sun rises in the east". That message has very low entropy; it gives you no new information. Now imagine a message containing the access password to a critical database. That message has incredibly high entropy; it is pure surprise and informational value.

Shannon formulated that the amount of information in a message is inversely proportional to its probability. This idea is the cornerstone of:

Data Compression: If a piece of data is highly predictable, we can omit or compress it. This is the principle governing ZIP, MP3, and JPEG formats. It is the exact same math that today allows deep-tech startups to use tensor networks to "squeeze" the redundancy out of LLMs.
Cryptography: During World War II, Shannon worked alongside Alan Turing exchanging ideas on cryptography. A perfectly encrypted message must look like pure random noise; meaning, it must have maximum entropy to an interceptor.
The Shannon Limit: He calculated the theoretical maximum speed at which data can be transmitted without errors over a noisy channel. Today, 5G and Wi-Fi 6 operate astonishingly close to that mathematical limit drawn decades ago.

The Link to Modern AI and Industry 4.0

Shannon's influence didn't stop at telecommunications. Today, Information Theory is the connective tissue of the industrial data architectures and artificial intelligence systems we build and operate.

When in the S&OP Engineering series we use Prophet to extract the "signal" of demand from the "noise" of seasonality and dirty data anomalies, we are directly applying Shannon's principles of channel and noise. Separating signal from noise is the foundational problem of predictive analytics.

When cybersecurity platforms like Devo ingest petabytes of network telemetry looking for the anomaly that betrays a lateral attack, what they are really doing is looking for unexpected entropy spikes in a channel that should behave predictably. The attacker generates entropy; the analyst detects it.

The Legacy of the Solitary Genius

Unlike other contemporary tech giants who sought fame or founded corporate empires, Shannon was a playful academic. He spent his free time building chess machines, juggling robots, a mechanical mouse named Theseus (one of the first Machine Learning experiments capable of solving mazes), and an "Ultimate Machine" that, when turned on, simply popped a hand out of a box to turn itself off.

Claude Shannon's legacy is the ultimate demonstration of First Principles Thinking. Instead of trying to build a better telephone cable, Shannon retreated to the chalkboard and asked: What is information?

By answering that fundamental question, he didn't build a better tool; he invented the entire ecosystem in which all our tools operate. All the software, all the cloud infrastructure, and all the autonomous AI agents we deploy today live, breathe, and communicate within the mathematical universe that Shannon imagined in 1948.

Sources of Interest:

Claude Shannon: El Hombre que Convirtió el Mundo en Bits y Definió el Futuro de la IA

Daniel — Sun, 21 Jun 2026 08:15:17 +0000

Hay figuras históricas que descubren continentes, y hay figuras que inventan la física subyacente que permite que existan los barcos. En el mundo de la tecnología y los datos, Claude Shannon pertenece inequívocamente a la segunda categoría. Si hoy puedes leer este artículo en tu pantalla, si tu smartphone puede comprimir una foto de 12 megapíxeles, y si Multiverse Computing puede comprimir un LLM masivo en un chip periférico, es porque Shannon dictó las leyes matemáticas de la información hace más de 75 años.

Mientras Abraham Wald nos enseñaba a leer el silencio de los datos ausentes y W. Edwards Deming sistematizaba la calidad industrial, Shannon hizo algo aún más fundamental: aisló el concepto de 'información' del significado físico del mensaje.

El Nacimiento del Bit: Bell Labs, 1948

Para entender el logro titánico de Shannon, hay que entender el caos que era la comunicación a principios del siglo XX. El telégrafo, el teléfono, la radio y la televisión se consideraban fenómenos físicos distintos. Los ingenieros mejoraban la transmisión reduciendo el ruido eléctrico en los cables, pero no existía una teoría unificada.

En 1948, trabajando en los míticos laboratorios Bell, Shannon publicó "Una Teoría Matemática de la Comunicación". En sus páginas, Shannon introdujo por primera vez en la historia impresa la palabra "bit" (una contracción de binary digit, sugerida por su colega John Tukey).

Shannon demostró matemáticamente que toda información —ya sea texto, audio, imagen o video— podía codificarse en una secuencia de 1s y 0s. El significado humano del mensaje era irrelevante para el problema de la ingeniería de transmitirlo. Al desacoplar el significado de la mecánica, Shannon unificó todos los medios de comunicación bajo un mismo marco matemático.

La Entropía de la Información: Midiendo lo Impredecible

El concepto más revolucionario que Shannon tomó prestado de la termodinámica fue la Entropía. En física, la entropía mide el grado de desorden de un sistema. Shannon adaptó el término para medir la incertidumbre o sorpresa en un mensaje de datos.

Imagina que te envío un mensaje predecible: "El sol sale por el este". Ese mensaje tiene muy baja entropía; no te aporta información nueva. Ahora imagina un mensaje que contiene la contraseña de acceso a una base de datos crítica. Ese mensaje tiene una entropía altísima; es pura sorpresa y valor informativo.

Shannon formuló que la cantidad de información en un mensaje es inversamente proporcional a su probabilidad. Esta idea es la piedra angular de:

La Compresión de Datos: Si un dato es altamente predecible, podemos omitirlo o comprimirlo. Es el principio que rige los formatos ZIP, MP3 y JPEG. Es la misma matemática que hoy permite a startups deep-tech usar redes de tensores para "exprimir" la redundancia de los LLMs.
La Criptografía: Durante la Segunda Guerra Mundial, Shannon trabajó junto a Alan Turing cruzando ideas sobre criptografía. Un mensaje perfectamente cifrado debe parecer ruido aleatorio puro; es decir, debe tener máxima entropía para un interceptor.
El Límite de Shannon: Calculó la velocidad máxima teórica a la que se pueden transmitir datos sin errores sobre un canal ruidoso. Hoy, el 5G y el Wi-Fi 6 operan asombrosamente cerca de ese límite matemático trazado hace décadas.

El Eslabón con la IA Moderna y la Industria 4.0

La influencia de Shannon no se quedó en las telecomunicaciones. Hoy, la Teoría de la Información es el tejido conectivo de las arquitecturas de datos industriales y de inteligencia artificial que construimos y operamos.

Cuando en la serie de Ingeniería S&OP utilizamos Prophet para extraer la "señal" de la demanda del "ruido" estacional y las anomalías de los datos sucios, estamos aplicando directamente los principios de canal y ruido de Shannon. Separar la señal del ruido es el problema fundacional del análisis predictivo.

Cuando plataformas de ciberseguridad como Devo ingieren petabytes de telemetría de red buscando la anomalía que delate un ataque lateral, lo que realmente están haciendo es buscar picos de entropía inesperados en un canal que debería tener un comportamiento predecible. El atacante genera entropía; el analista la detecta.

El Legado del Genio Solitario

A diferencia de otros gigantes tecnológicos contemporáneos que buscaron la fama o fundaron imperios corporativos, Shannon era un académico juguetón. Pasaba su tiempo libre construyendo máquinas de ajedrez, malabares robotizados, un ratón mecánico llamado Theseus (uno de los primeros experimentos de Machine Learning capaz de resolver laberintos) y una "Máquina Definitiva" que, al encenderse, simplemente sacaba una mano de una caja para apagarse a sí misma.

El legado de Claude Shannon es la demostración definitiva del Pensamiento desde los Primeros Principios (First Principles Thinking). En lugar de intentar construir un cable telefónico mejor, Shannon se retiró al pizarrón y se preguntó: ¿Qué es la información?

Al responder a esa pregunta fundamental, no construyó una herramienta mejor; inventó el ecosistema entero en el que todas nuestras herramientas operan. Todo el software, toda la infraestructura cloud, y todos los agentes de IA autónomos que desplegamos hoy, viven, respiran y se comunican dentro del universo matemático que Shannon imaginó en 1948.

Fuentes de Interés:

The Hidden Economics of AI: What It Actually Costs to Run LLMs in Production (With Real Data)

Daniel — Sun, 14 Jun 2026 08:13:27 +0000

There is an inconvenient truth the artificial intelligence industry prefers to whisper rather than proclaim: the real cost of putting an LLM into production almost never matches the API invoice. It's like buying a car and discovering that the dealership price didn't include the wheels, the insurance, or the fuel. The label says "$0.15 per million input tokens." What it doesn't say is how many millions of tokens your agent will burn in a delegation loop that spirals out of control at 3 AM.

I know this because it happened to me. Over the past six months I've operated autonomous agent systems in real production: the Autopilot Project (9 installments) to automate content distribution across social media, and the Obsolescence Engineering series (7 installments) with a 24/7 agentic radar to monitor supply chain risks. This article is not a theoretical exercise: it is an X-ray of my real invoices, my mistakes, and my lessons learned.

The Iceberg: What the API Invoice Doesn't Tell You

The most dangerous mistake when budgeting a generative AI project is confusing the API cost with the total system cost. It's like measuring the cost of a restaurant only by the price of the ingredients. In my experience operating these systems, the API represents roughly 15-25% of the real cost. The rest is the submerged iceberg:

Cost Layer	What It Includes	Typical %
LLM API	Input/output tokens, context caching	15-25%
Infrastructure	GitHub Actions (minutes), Netlify Functions, Supabase	25-35%
Engineer Time	Agent debugging, prompt tuning, defensive programming	30-40%
Silent Costs	Retries on failures, infinite loops, token overconsumption	10-15%

The third block — engineer time — is where most projects die. As I documented in the Autopilot post-mortem, models are stochastic: you run the same pipeline ten times and get ten different results. This means you can't test an AI agent the way you test a conventional microservice. You need defensive programming, output validation with JSON Schemas, and retries with exponential backoff. Every hour invested in that engineering has a cost.

The Comparison No One Makes: Gemini vs GPT-4o vs Claude in Real Production

The LLM comparisons flooding the internet typically measure academic benchmarks: MMLU, HumanEval, logical reasoning. That's fine for research papers, but in production what matters is the cost-quality-reliability equation per specific task. Here is my operational experience with the three main models:

Criterion	Gemini 2.5 Flash	GPT-4o	Claude Sonnet 4
Input Cost (per 1M tokens)	$0.15	$2.50	$3.00
Output Cost (per 1M tokens)	$0.60	$10.00	$15.00
Average latency (complete response)	~2.1s	~3.8s	~4.5s
JSON reliability (structured output)	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
System prompt adherence	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Creativity / "personality"	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

The price difference between Gemini Flash and its competitors is not a percentage: it's an order of magnitude. For high-volume, low-creativity tasks — classification, structured data extraction, email parsing — Gemini Flash is unbeatable. That's exactly why I chose it as the engine for the obsolescence agentic radar: I needed to run hundreds of analyses per month without the bill spiraling out of control.

However, when the task demands nuance, personality, or complex reasoning, the quality difference justifies the price. In the Autopilot Project, the agent writing LinkedIn posts with a "corporate" tone and the one writing tweets with a "cynical" tone (Part 3) performed significantly better with premium-tier models. The lesson: there is no "best model," there is the right model for each task in your pipeline.

Anatomy of a Real Invoice: The Autopilot Project

Let's break down the actual costs of operating the Autopilot Project during a typical month. This system analyzes each new blog post, generates optimized content for Twitter and LinkedIn in two languages (ES/EN), runs a quality audit, and publishes automatically with human approval.

Item	Monthly Cost	Notes
Gemini API (Flash + Pro)	~€1.20	~4 executions/month, ~50K tokens per execution
GitHub Actions (CI/CD minutes)	€0.00	Free tier: 2,000 min/month (more than enough)
Brevo (Newsletter)	€0.00	Free tier: 300 emails/day
Netlify (Functions + Hosting)	€0.00	Free tier: 125K invocations/month
Supabase (PostgreSQL)	€0.00	Free tier: 500MB, 2 projects
Domain (datalaria.com)	~€1.50	Monthly prorated
Engineer time	¿?	The real hidden cost
Total infrastructure	~€2.70/month

Yes, you read that right: less than 3 euros per month to operate a complete AI agent system with automated social media publishing, newsletter, and CI/CD. The key lies in three deliberate architectural decisions:

Gemini Flash as the main engine: At $0.15/M input tokens, the cost per execution is cents, not euros.
Aggressive free tiers: GitHub Actions, Netlify, Supabase, and Brevo offer generous free plans that comfortably cover an individual project or early-stage startup.
On-demand execution: The pipeline doesn't run 24/7 — it only triggers on each new post (event-driven), avoiding the cost of always-on servers.

The Loop Trap: When Your Agent Burns Money on Its Own

But the invoice isn't always that friendly. In the Autopilot post-mortem I documented a critical failure every engineer should know about: CrewAI's infinite delegation loops. When an agent can't find the expected answer, it can re-delegate the task to itself in a loop that consumes tokens exponentially until GitHub Actions kills the process on timeout (SIGTERM at 60 minutes).

In a single failed execution, that loop can consume more tokens than an entire month of normal operation. It's the digital equivalent of leaving a tap running overnight. The solution is brutally simple, yet nobody implements it by default:

max_iter and max_execution_time on every CrewAI agent
Output validation with Pydantic before passing to the next agent
Cost alerts configured in the Google Cloud console
Circuit breakers that kill execution if consumption exceeds a threshold

The 10x Rule: When It's Worth Paying More

After six months operating these systems, I've distilled a pragmatic rule I call the 10x Rule: a more expensive model is only justified if it produces a result at least 10 times better on the metric that matters for your use case. What does "10 times better" mean?

In classification: 10x fewer classification errors
In content generation: 10x fewer human correction iterations
In data extraction: 10x fewer verifiable hallucinations
In latency: 10x faster on the user's critical path

If the improvement is 20-30%, stick with the cheap model. If it's 2x-3x, evaluate. If it's 10x, don't think twice. This rule led me to use Gemini Flash for 90% of tasks and reserve premium models only for creative content generation.

Looking Ahead: The Deflation of Intelligence

There is a macro trend every engineer needs to have on their radar: the cost per token is falling at a brutal pace. Gemini Flash in June 2025 cost $0.35/M input tokens. One year later, it costs $0.15 — a 57% drop in 12 months. If this trend holds (and everything suggests it will accelerate with competition from open-source models like Llama and Mistral), in two years we'll be talking about API costs that are essentially free for most use cases.

That doesn't mean AI will be free. It means the cost will definitively shift from the API to the engineer: the ability to design robust systems, implement defensive programming, and orchestrate complex pipelines will be the true competitive differentiator. The model will be a commodity; the architecture will be the moat.

As W. Edwards Deming — to whom I dedicated a full article — put it: "It is not enough to do your best; you must first know what to do." In the hidden economics of AI, knowing which model to use, when to use it, and when not to use it is the most valuable skill you can develop.

Sources of Interest:

La Economía Oculta de la IA: Cuánto Cuesta Realmente Usar LLMs en Producción (Con Datos Reales)

Daniel — Sun, 14 Jun 2026 08:06:44 +0000

Hay una verdad incómoda que la industria de la inteligencia artificial prefiere susurrar en lugar de proclamar: el coste real de poner un LLM en producción casi nunca coincide con la factura de la API. Es como comprar un coche y descubrir que el precio del concesionario no incluía ni las ruedas, ni el seguro, ni la gasolina. La etiqueta dice "0,15$ por millón de tokens de entrada". Lo que no dice es cuántos millones de tokens quemará tu agente en un bucle de delegación que se descontrola a las 3 de la madrugada.

Lo sé porque me ha pasado. Durante los últimos seis meses he operado sistemas de agentes autónomos en producción real: el Proyecto Autopilot (9 entregas) para automatizar la distribución de contenido en redes sociales, y la serie de Ingeniería de la Obsolescencia (7 entregas) con un radar agéntico 24/7 para monitorear riesgos en la cadena de suministro. Este artículo no es un ejercicio teórico: es una radiografía de mis facturas reales, mis errores y mis lecciones aprendidas.

El Iceberg: Lo que la Factura de la API No te Cuenta

El error más peligroso al presupuestar un proyecto de IA generativa es confundir el coste de la API con el coste total del sistema. Es como medir el coste de un restaurante solo por el precio de los ingredientes. En mi experiencia operando estos sistemas, la API representa aproximadamente un 15-25% del coste real. El resto es el iceberg sumergido:

Capa de Coste	Qué Incluye	% Típico
API del LLM	Tokens de entrada/salida, caché de contexto	15-25%
Infraestructura	GitHub Actions (minutes), Netlify Functions, Supabase	25-35%
Tiempo de Ingeniero	Debugging de agentes, prompt tuning, programación defensiva	30-40%
Costes Silenciosos	Reintentos por fallos, bucles infinitos, sobre-consumo de tokens	10-15%

El tercer bloque —el tiempo de ingeniero— es donde la mayoría de los proyectos mueren. Como documenté en el post-mortem del Autopilot, los modelos son estocásticos: ejecutas el mismo pipeline diez veces y obtienes diez resultados diferentes. Eso significa que no puedes testear un agente IA como testeas un microservicio convencional. Necesitas programación defensiva, validación de output con JSON Schemas, y reintentos con backoff exponencial. Cada hora invertida en esa ingeniería tiene un coste.

La Comparativa que Nadie Hace: Gemini vs GPT-4o vs Claude en Producción Real

Las comparativas de LLMs que abundan online suelen medir benchmarks académicos: MMLU, HumanEval, razonamiento lógico. Eso está bien para papers de investigación, pero en producción lo que importa es la ecuación coste-calidad-fiabilidad por tarea concreta. Aquí va mi experiencia operativa con los tres modelos principales:

Criterio	Gemini 2.5 Flash	GPT-4o	Claude Sonnet 4
Coste Input (por 1M tokens)	$0,15	$2,50	$3,00
Coste Output (por 1M tokens)	$0,60	$10,00	$15,00
Latencia media (respuesta completa)	~2,1s	~3,8s	~4,5s
Fiabilidad JSON (structured output)	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Respeto de instrucciones de sistema	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐
Creatividad / "personalidad"	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐

La diferencia de precio entre Gemini Flash y sus competidores no es un porcentaje: es un orden de magnitud. Para tareas de alto volumen y baja creatividad —clasificación, extracción de datos estructurados, parsing de emails— Gemini Flash es imbatible. Es exactamente por eso que lo elegí como motor del radar agéntico de obsolescencia: necesitaba ejecutar cientos de análisis al mes sin que la factura se disparara.

Sin embargo, cuando la tarea exige matiz, personalidad o razonamiento complejo, la diferencia de calidad justifica el precio. En el Proyecto Autopilot, el agente que escribía posts para LinkedIn con tono "corporativo" y el que escribía tweets con tono "cínico" (Parte 3) rendían significativamente mejor con modelos de gama alta. La lección: no existe el "mejor modelo", existe el modelo correcto para cada tarea de tu pipeline.

Anatomía de una Factura Real: El Proyecto Autopilot

Desglosemos los costes reales de operar el Proyecto Autopilot durante un mes típico. Este sistema analiza cada nuevo post del blog, genera contenido optimizado para Twitter y LinkedIn en dos idiomas (ES/EN), pasa por una auditoría de calidad, y publica automáticamente con aprobación humana.

Concepto	Coste Mensual	Notas
Gemini API (Flash + Pro)	~1,20 €	~4 ejecuciones/mes, ~50K tokens por ejecución
GitHub Actions (CI/CD minutes)	0,00 €	Free tier: 2.000 min/mes (sobra para esto)
Brevo (Newsletter)	0,00 €	Free tier: 300 emails/día
Netlify (Functions + Hosting)	0,00 €	Free tier: 125K invocaciones/mes
Supabase (PostgreSQL)	0,00 €	Free tier: 500MB, 2 proyectos
Dominio (datalaria.com)	~1,50 €	Prorrateado mensual
Tiempo de ingeniero	¿?	El verdadero coste oculto
Total infraestructura	~2,70 €/mes

Sí, has leído bien: menos de 3 euros al mes para operar un sistema completo de agentes IA con publicación automatizada en redes sociales, newsletter y CI/CD. La clave está en tres decisiones arquitectónicas deliberadas:

Gemini Flash como motor principal: A $0,15/M tokens de entrada, el coste por ejecución es de céntimos, no de euros.
Free tiers agresivos: GitHub Actions, Netlify, Supabase y Brevo ofrecen generosos planes gratuitos que cubren sobradamente un proyecto individual o una startup temprana.
Ejecución bajo demanda: El pipeline no corre 24/7, solo se activa con cada nuevo post (evento), evitando el coste de servidores siempre encendidos.

La Trampa de los Bucles: Cuando tu Agente Quema Dinero Solo

Pero la factura no siempre es tan amable. En el post-mortem del Autopilot documenté un fallo crítico que todo ingeniero debería conocer: los bucles de delegación infinita de CrewAI. Cuando un agente no encuentra la respuesta esperada, puede re-delegarse la tarea a sí mismo en un bucle que consume tokens exponencialmente hasta que GitHub Actions mata el proceso por timeout (SIGTERM a los 60 minutos).

En una sola ejecución fallida, ese bucle puede consumir más tokens que un mes entero de operación normal. Es el equivalente digital de dejar un grifo abierto toda la noche. La solución es brutalmente simple pero nadie la implementa de serie:

max_iter y max_execution_time en cada agente CrewAI
Validación de output con Pydantic antes de pasar al siguiente agente
Alertas de coste configuradas en la consola de Google Cloud
Circuit breakers que matan la ejecución si el consumo supera un umbral

La Regla del 10x: Cuándo Merece la Pena Pagar Más

Después de seis meses operando estos sistemas, he destilado una regla pragmática que llamo la Regla del 10x: un modelo más caro solo se justifica si produce un resultado al menos 10 veces mejor en la métrica que importa para tu caso de uso. ¿Qué significa "10 veces mejor"?

En clasificación: 10x menos errores de clasificación
En generación de contenido: 10x menos iteraciones humanas de corrección
En extracción de datos: 10x menos alucinaciones verificables
En latencia: 10x más rápido en la ruta crítica del usuario

Si la mejora es de un 20-30%, quédate con el modelo barato. Si es de un 2x-3x, evalúa. Si es de un 10x, no lo pienses. Esta regla me llevó a usar Gemini Flash para el 90% de las tareas y reservar modelos premium solo para la generación creativa de contenido.

Mirando al Futuro: La Deflación de la Inteligencia

Hay una tendencia macro que todo ingeniero debe tener en el radar: el coste por token está cayendo a un ritmo brutal. Gemini Flash en junio de 2025 costaba $0,35/M tokens de entrada. Un año después, cuesta $0,15 — una caída del 57% en 12 meses. Si esta tendencia se mantiene (y todo indica que se acelerará con la competencia de modelos open-source como Llama y Mistral), en dos años estaremos hablando de costes de API que serán esencialmente gratuitos para la mayoría de los casos de uso.

Eso no significa que la IA será gratis. Significa que el coste se desplazará definitivamente de la API al ingeniero: la capacidad de diseñar sistemas robustos, implementar programación defensiva, y orquestar pipelines complejos será el verdadero diferencial competitivo. El modelo será un commodity; la arquitectura será el moat.

Como bien decía W. Edwards Deming —al que dediqué un artículo completo— : "No basta con hacer lo mejor que puedas; primero debes saber qué hacer". En la economía oculta de la IA, saber qué modelo usar, cuándo usarlo y cuándo no usarlo es la habilidad más valiosa que puedes desarrollar.