DEV Community: Daniel

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.

Fuentes de Interés:

Devo: How a Self-Taught Chemist from Madrid Built the Data Engine That Defends the U.S. Air Force

Daniel — Sun, 07 Jun 2026 21:55:59 +0000

On the cyber battlefield, where a state-sponsored attacker can compromise credentials and move laterally through a military network in just 18 minutes and 49 seconds, every second of detection delay can mean the difference between defending critical infrastructure or losing it. Yet for years, the cybersecurity industry accepted as normal that its analytics tools took up to 15 minutes to process a single security log.

This is the story of Devo, the chronicle of how a self-taught chemist from Madrid identified that absurd gap in the trenches of a Spanish bank, founded a startup that investors tried to wrestle away from him, and ended up building the real-time data engine that today protects the networks of the United States Air Force. A journey from the operational chokepoints of the financial sector to unicorn status at a $1.9 billion valuation.

The Origin: A Phishing Attack and an Obsession with Speed

Devo's seed didn't germinate in a Silicon Valley garage, but in the crisis room of Bankinter in 2003. Pedro Castillo doesn't fit the mold of the conventional tech entrepreneur. A graduate in Chemical Sciences from the Universidad Complutense de Madrid, he discovered his true calling by chance when he stumbled upon a Silicon Graphics computer in his faculty, sparking a fascination that led him to learn programming entirely on his own.

In the mid-1990s, when the internet was still the exclusive domain of universities and government agencies, Castillo was already providing advanced IT services to corporations like El Corte Inglés, Spain's largest department store chain. That early experience culminated in the founding of Webline in 1996, his first cybersecurity company, which opened the doors to Spain's financial sector. Bankinter, one of the country's most innovative banks, recruited him and eventually elevated him to Director of Technology Security.

It was precisely in those banking trenches where everything changed. In 2003, a sophisticated phishing attack struck Bankinter. Castillo and his team hit a paralyzing obstacle: the tools of the era were incapable of ingesting and correlating the massive volumes of data generated by servers, firewalls, and network traffic fast enough to stop the attack before fraud was committed. Existing solutions imposed an impossible choice: pay exorbitant costs to store everything, or filter the data and create "blind spots" that attackers would inevitably exploit.

Obsessed with unlocking the value of raw data, Castillo left his comfortable executive position and founded Logtrust in Madrid in 2011. His philosophy was radical: while other startups rushed to conferences and press coverage, he and his team entrenched themselves in software development, building a database engine from scratch. A product that was, in his own words, "absolutely differential."

The Technological Revolution: HyperStream and Zero Latency

Why did Devo manage to dethrone giants like Splunk in multiple bids? The answer lies in a radical reengineering of security data processing.

The industry standard, dominated by Splunk, relied on index-on-ingest: data had to be parsed, normalized, and structured into a massive index before being stored. This design created three critical weaknesses:

Lethal delay: In high-volume environments, events took over 15 minutes to become available to the analyst.
Resource contention: Index reading and writing shared CPU resources, degrading performance precisely when speed was most urgent.
Prohibitive costs: Maintaining petabyte-scale indexes forced executives to create "blind spots," leaving up to a third of their systems unmonitored.

Devo completely discarded traditional indexing and built HyperStream, a proprietary streaming analytics technology based on opposing principles:

Ingest without normalization: Data is stored in its original format. The platform applies the schema at query time (schema-on-read), not at ingestion.
Immutable micro-indexes: Instead of a global index, HyperStream creates a daily micro-index per data source that, once generated, is never rewritten. The result: 10:1 compression and massive parallelization.
Zero latency: Telemetry is available for alerts and searches at the exact millisecond it hits disk.

The convergence of these innovations enabled an unprecedented achievement: maintaining 400 days of "always-hot" data, queryable in sub-seconds. While competitors archived old data in cold, inaccessible storage, a forensic analyst using Devo could investigate a year-old intrusion with the same speed as if it had occurred five minutes ago.

The Trial by Fire: Defending U.S. Air Force Networks

HyperStream's definitive validation came in July 2020, when Devo was awarded a $9.5 million contract with the United States Air Force to deploy its technology as the central SIEM for the Enterprise Cyberspace Security & Defense program.

The situation was critical: cyber squadrons operated on a SIEM dating back to 1999 that aggregated up to 70 disconnected applications, generating over 8 million daily alerts with no automated correlation capability. The operational environment was, as senior commanders described it, analogous to a cockpit where the pilot had to press 40 different buttons just to fire a single missile. The military's "12N12" initiative demanded a drastic but necessary consolidation: replacing those 70 chaotic applications with approximately 12 functional tools within 12 months.

The results of Devo's deployment were transformative:

A single pane of glass that eliminated operational fragmentation.
Over 20,000 human hours saved in manual threat triage.
Reorientation of cyber analysts from repetitive tasks to proactive threat hunting against state-sponsored actors.

The Venture Capital Crucible: From Boardroom Battles to Unicorn Status

Devo's financial journey was as intense as its engineering. In early 2017, the first $11 million round brought what Castillo described as a "terrible situation": investors attempted to force his removal as CEO to install an external corporate profile. The intervention of Insight Partners, which led a $35 million Series B, stabilized governance and backed the founder's technical vision.

In 2018, coinciding with the Series C, Logtrust was rebranded as Devo (a contraction of "Data Evolution") and relocated its headquarters to Cambridge/Boston, Massachusetts—establishing its commercial epicenter in the world's most competitive tech market—while keeping its engineering heart in Madrid. The name change was no mere marketing exercise: Devo was no longer just a log repository but a true data operations platform capable of unifying historical and streaming data from applications, IT operations, security, IoT, and industrial machines. The hypergrowth that followed was explosive: 80% year-over-year revenue growth and an astonishing 136% client growth by 2021.

Round	Date	Capital	Lead Investor(s)	Milestone
Venture Round	Jan 2017	$11M	Kibo Ventures, Atlantic Bridge	Initial expansion
Series B	Sep 2017	$35M	Insight Partners	Leadership stabilization
Series C	Jun 2018	$25M	Insight Partners, Kibo Ventures	Devo rebrand; HQ to Boston
Series D	Sep 2020	$60M	Georgian, Bessemer Venture	Marc van Zadelhoff, new CEO
Series E	Oct 2021	$250M	TCV, General Atlantic, Eurazeo	Unicorn: $1.5B
Series F	Jun 2022	$100M	TCV, Insight, Bessemer	Valuation: $1.9B

The Future: Agentic AI and Strike48

But massive ingestion isn't enough if the organization cannot respond to findings with equal speed. The contemporary Security Operations Center (SOC) suffers from a systemic ailment: alert fatigue. An average corporate SOC receives over 4,400 daily alerts from more than 28 different security tools, and 53% of those alerts are false positives that consume irretrievable time. With a global shortage estimated at 4.8 million cybersecurity professionals, automation has ceased to be a luxury and become an existential necessity.

In 2026, Devo leaped forward into Agentic Artificial Intelligence with the launch of Strike48. Instead of copilots that passively assist the analyst, Strike48 deploys a squadron of autonomous micro-agents that execute complex investigations: correlating alerts, identifying "patient zero," collecting forensic evidence, and building visual evidence trees, stopping only for human approval of irreversible actions.

The architecture also solves a devastating problem: companies monitor only 66% of their systems due to budget constraints imposed by legacy SIEMs. Strike48's connectors query data directly where it resides—AWS buckets, data lakes, existing Splunk installations—without duplicating storage, granting the AI agents the omniscient visibility needed to detect what previously lurked in the shadows. In early trial deployments, this model reduced Mean Time to Detection (MTTD) to under eight minutes, uncovering stealthy campaigns that legacy tools had completely missed.

As a final note in this trajectory: having consolidated Devo as an undisputed titan, Pedro Castillo proved his serial-entrepreneur credentials by founding Onum in 2023, a platform to reduce data pipeline noise by 80%. The validation was swift: in August 2025, it was acquired by CrowdStrike.

Conclusion: Engineering Against Dogma

The story of Devo demonstrates that transformational change doesn't spring from bold commercial strategies, but from the stubborn engineering conviction to question accepted dogma. While the entire industry kept building bigger indexes, a self-taught chemist from Madrid asked: "What if the index is the problem?"

That question, answered through a decade of obsessive engineering and the resilience to survive venture capital power plays, produced an engine capable of protecting everything from a Spanish bank to the most demanding military cyberspace on the planet. Pedro Castillo's journey—from a chemistry lab at the Complutense to the innovation hubs of Massachusetts, through the banking trenches of Madrid—is a powerful reminder that, in the age of Big Data, battles aren't won with more ammunition, but with faster weapons. And in that arena, the machine-speed processing that Devo has mastered may well be the only reliable defense against threats that operate at that very same speed.

Sources of Interest:

Devo: Cómo un Químico Autodidacta Construyó desde Madrid el Motor de Datos que Defiende a la Fuerza Aérea de EE.UU.

Daniel — Sun, 07 Jun 2026 21:51:21 +0000

En el campo de batalla del ciberespacio, donde un atacante patrocinado por un estado puede comprometer credenciales y moverse lateralmente a través de una red militar en apenas 18 minutos y 49 segundos, cada segundo de retraso en la detección puede significar la diferencia entre defender una infraestructura crítica o perderla. Sin embargo, durante años, la industria de la ciberseguridad aceptó como normal que sus herramientas de análisis tardaran hasta 15 minutos en procesar un simple registro de seguridad.

Esta es la historia de Devo, la crónica de cómo un químico madrileño autodidacta identificó esa brecha absurda en las trincheras de un banco español, fundó una startup que los inversores intentaron arrebatarle, y terminó construyendo el motor de datos en tiempo real que hoy protege las redes de la Fuerza Aérea de los Estados Unidos. Un viaje desde la asfixia operativa del sector financiero hasta el estatus de unicornio valorado en 1.900 millones de dólares.

El Origen: Un Ataque de Phishing y una Obsesión por la Velocidad

La semilla de Devo no germinó en un garaje de Silicon Valley, sino en la sala de crisis de Bankinter en 2003. Pedro Castillo no responde al arquetipo del emprendedor tecnológico convencional. Licenciado en Ciencias Químicas por la Universidad Complutense de Madrid, descubrió su verdadera vocación de forma fortuita al encontrar un ordenador Silicon Graphics en su facultad, lo que despertó una fascinación que le llevó a aprender a programar de manera completamente autodidacta.

A mediados de los años noventa, cuando Internet era aún territorio exclusivo de universidades y organismos gubernamentales, Castillo ya prestaba servicios informáticos avanzados a corporaciones como El Corte Inglés. Esa experiencia temprana culminó con la fundación de Webline en 1996, su primera empresa de ciberseguridad, que le abrió las puertas del sector financiero español. Bankinter, una de las entidades más innovadoras del país, lo reclutó hasta convertirlo en Director de Seguridad Tecnológica.

Fue precisamente en esas trincheras bancarias donde todo cambió. En 2003, un sofisticado ataque de phishing golpeó a Bankinter. Castillo y su equipo se encontraron con un obstáculo paralizante: las herramientas de la época eran incapaces de ingerir y correlacionar los volúmenes masivos de datos generados por servidores, cortafuegos y tráfico de red a la velocidad necesaria para detener el ataque antes de que se consumara el fraude. Las soluciones existentes imponían una elección imposible: pagar costes exorbitantes para almacenarlo todo, o filtrar los datos y crear «puntos ciegos» que los atacantes explotarían inevitablemente.

Obsesionado con liberar el valor del dato en bruto, Castillo abandonó su cómoda posición ejecutiva y fundó Logtrust en Madrid en 2011. Su filosofía fue radical: mientras otras startups corrían a las conferencias y a la prensa, él y su equipo se atrincheraron en el desarrollo de software, construyendo un motor de base de datos desde cero. Un producto, en sus propias palabras, «absolutamente diferencial».

La Revolución Tecnológica: HyperStream y la Latencia Cero

¿Por qué Devo logró desbancar a gigantes como Splunk en múltiples licitaciones? La respuesta reside en una reingeniería radical del procesamiento de datos de seguridad.

El estándar de la industria, dominado por Splunk, dependía de la indexación durante la ingesta (index-on-ingest): los datos debían ser analizados, normalizados y estructurados en un índice masivo antes de almacenarse. Este diseño creaba tres debilidades críticas:

Retraso letal: En entornos de alto volumen, los eventos tardaban más de 15 minutos en estar disponibles para el analista.
Contención de recursos: La lectura y escritura del índice compartían CPU, degradando el rendimiento justo cuando más urgía la velocidad.
Costes prohibitivos: Mantener índices de petabytes obligaba a los directivos a crear «puntos ciegos», dejando de monitorizar hasta un tercio de sus sistemas.

Devo descartó por completo la indexación tradicional y construyó HyperStream, una tecnología propietaria de análisis en streaming basada en principios opuestos:

Ingesta sin normalización: Los datos se almacenan en su formato original. La plataforma aplica el esquema en el momento de la consulta (schema-on-read), no al guardar el dato.
Micro-índices inmutables: En lugar de un índice global, HyperStream crea un micro-índice diario por fuente de datos que, una vez generado, nunca se reescribe. Resultado: compresión 10:1 y paralelización masiva.
Latencia cero: La telemetría está disponible para alertas y búsquedas en el milisegundo exacto en que toca el disco.

La convergencia de estas innovaciones permitió un logro sin precedentes: mantener 400 días de datos «siempre calientes», consultables en sub-segundos. Mientras los competidores archivaban los datos antiguos en almacenamiento frío e inconsultable, un analista forense con Devo podía investigar una intrusión de hace un año con la misma velocidad que si hubiera ocurrido hace cinco minutos.

La Prueba de Fuego: Defender las Redes de la Fuerza Aérea de EE.UU.

La validación definitiva de HyperStream llegó en julio de 2020, cuando Devo se adjudicó un contrato de 9,5 millones de dólares con la Fuerza Aérea de los Estados Unidos para desplegar su tecnología como SIEM central del programa de Ciberdefensa Empresarial.

La situación era crítica: los escuadrones cibernéticos operaban con un SIEM de 1999 que aglomeraba hasta 70 aplicaciones inconexas, generando más de 8 millones de alertas diarias sin capacidad de correlación automatizada. La iniciativa militar «12N12» exigía consolidar ese caos en 12 herramientas funcionales en 12 meses.

Los resultados del despliegue de Devo fueron transformadores:

Un panel de control unificado que eliminó la fragmentación operativa.
Más de 20.000 horas humanas ahorradas en triaje manual de amenazas.
Reorientación de los analistas cibernéticos de tareas repetitivas hacia la caza proactiva de amenazas contra actores estatales.

El Crisol del Capital Riesgo: De la Batalla en la Junta al Estatus de Unicornio

El camino financiero de Devo fue tan intenso como su ingeniería. A principios de 2017, la primera ronda de 11 millones de dólares trajo consigo lo que Castillo describió como una «situación terrible»: los inversores intentaron forzar su destitución como CEO para imponer un perfil corporativo externo. La intervención de Insight Partners, que lideró una Serie B de 35 millones de dólares, estabilizó la gobernanza y respaldó la visión técnica del fundador.

En 2018, coincidiendo con la Serie C, Logtrust se rebautizó como Devo (contracción de «Data Evolution») y trasladó su sede a Boston, manteniendo la ingeniería en Madrid. El hipercrecimiento que siguió fue explosivo: 80% de crecimiento interanual en ingresos y 136% en clientes hacia 2021.

Ronda	Fecha	Capital	Inversores Principales	Hito
Venture Round	Ene 2017	$11M	Kibo Ventures, Atlantic Bridge	Expansión inicial
Serie B	Sep 2017	$35M	Insight Partners	Estabilización del liderazgo
Serie C	Jun 2018	$25M	Insight Partners, Kibo Ventures	Rebranding a Devo; sede a Boston
Serie D	Sep 2020	$60M	Georgian, Bessemer Venture	Marc van Zadelhoff, nuevo CEO
Serie E	Oct 2021	$250M	TCV, General Atlantic, Eurazeo	Unicornio: $1.500M
Serie F	Jun 2022	$100M	TCV, Insight, Bessemer	Valoración: $1.900M

El Futuro: IA Agentística y Strike48

Pero la ingesta masiva no es suficiente si la organización no puede responder a los hallazgos con igual celeridad. El Centro de Operaciones de Seguridad (SOC) contemporáneo padece un mal sistémico: la fatiga de alertas. Un SOC corporativo promedio recibe más de 4.400 alertas diarias procedentes de más de 28 herramientas de seguridad diferentes, y el 53% de esas alertas son falsos positivos que consumen un tiempo irrecuperable. Con una escasez global estimada en 4,8 millones de profesionales de ciberseguridad, la automatización dejó de ser un lujo para convertirse en una necesidad existencial.

En 2026, Devo dio el salto hacia la Inteligencia Artificial Agentística con el lanzamiento de Strike48. En lugar de copilotos que asisten pasivamente al analista, Strike48 despliega un escuadrón de micro-agentes autónomos que ejecutan investigaciones complejas: correlacionan alertas, identifican al «paciente cero», recopilan evidencia forense y construyen árboles de evidencia visuales, deteniéndose únicamente para la aprobación humana de acciones irreversibles.

La arquitectura resuelve además un problema devastador: las empresas monitorizan apenas un 66% de sus sistemas por restricciones presupuestarias de los SIEM legados. Los conectores de Strike48 interrogan los datos directamente donde residen —buckets de AWS, lagos de datos, instalaciones de Splunk— sin duplicar almacenamiento, otorgando a los agentes de IA la visión omnisciente necesaria para detectar lo que antes quedaba en la sombra. En las implementaciones de prueba tempranas, este modelo redujo el Tiempo Medio de Detección (MTTD) a menos de ocho minutos, descubriendo campañas sigilosas que las herramientas legadas habían pasado completamente por alto.

Como nota final de esta trayectoria: habiendo consolidado a Devo como un titán indiscutible, Pedro Castillo demostró su condición de emprendedor en serie fundando Onum en 2023, una plataforma para reducir el ruido de los pipelines de datos en un 80%. La validación fue fulminante: en agosto de 2025, fue adquirida por CrowdStrike.

Conclusión: Ingeniería Contra Dogma

La historia de Devo es la demostración de que los cambios transformacionales no nacen de estrategias comerciales audaces, sino de la terquedad ingenieril de cuestionar los dogmas aceptados. Mientras la industria entera construía índices cada vez más grandes, un químico autodidacta de Madrid se preguntó: «¿Y si el índice es el problema?».

Esa pregunta, respondida con una década de ingeniería obsesiva y con la resiliencia de sobrevivir a las maniobras del capital riesgo, generó un motor capaz de proteger desde un banco español hasta el ciberespacio militar más exigente del planeta. El trayecto de Pedro Castillo —desde un laboratorio de química en la Complutense hasta los centros de innovación de Massachusetts, pasando por las trincheras bancarias de Madrid— es un recordatorio potente de que, en la era del Big Data, las batallas no se ganan con más munición, sino con armas más rápidas. Y en ese terreno, la velocidad de máquina que Devo ha logrado dominar es, quizás, la única defensa fiable contra las amenazas que operan a esa misma velocidad.

Fuentes de Interés:

W. Edwards Deming: The Father of Total Quality Who Predicted the Future of AI

Daniel — Sun, 31 May 2026 13:54:54 +0000

The contemporary industrial landscape demands robust management frameworks in the face of extreme volatility. At the epicenter of this organizational and analytical architecture stands the monumental philosophy of W. Edwards Deming. Conceived in the early decades of the 20th century, his theoretical approach has transcended the factory floor to become the undisputed foundation of Sales and Operations Planning (S&OP) and the management of complex value networks.

Deming's fundamental premise postulates that quality is not achieved through massive end-of-line inspection, which is reactive and costly. True quality is born from reducing variation in the underlying processes.

The System of Profound Knowledge and Statistical Control

Deming proposed a radical managerial paradigm: the System of Profound Knowledge. This system requires that we optimize the "whole" (the interconnected network) rather than maximizing departmental silos. He taught us that variation is inherent to any activity, but the key to leadership lies in differentiating "chronic variation" (common causes) from "anomalies" (special causes) through Statistical Process Control (SPC).

One of his most destructive insights toward traditional management was the concept of Tampering or over-adjustment. When management (for example, in monthly S&OP meetings) reacts to normal statistical variations as if they were systemic crises by drastically adjusting the plan, it paradoxically amplifies the disaster and increases instability. This is the root cause of why a fearful sales forecast breeds the infamous Bullwhip Effect in the supply chain.

Toyota and the Data-Driven Revolution

Deming's impact was most forcefully seen in the miraculous industrial reconstruction of post-war Japan. Toyota embraced his doctrine, instituting the famous PDCA (Plan-Do-Check-Act) cycle.

Before Deming, decisions depended on instinct. Afterwards, Toyota engineers understood that planning S&OP or designing plant capacity without statistically reliable data was equivalent to walking blindly toward obsolescence. Thanks to him, Toyota eradicated the philosophy of final inspection in favor of "building quality into the process," cementing what the world would later know as Lean Manufacturing.

The Technological Horizon: AI and Concept Drift

Perhaps the most astonishing proof of the immortality of Deming's mathematics is its current application at the frontier of Artificial Intelligence and corporate automation.

The golden rule of modern robotics is: "Stabilize before you automate, always". AI cannot infer precise causalities from a chaotic human workflow or noisy data. Deming's principles of standardization are inescapable prerequisites for any Machine Learning initiative.

Even more profound is how modern data science uses Statistical Process Control to audit AI models themselves. When a real-world predictive model begins to fail due to unforeseen macroeconomic changes (a phenomenon known as Concept Drift), engineers resort to multivariate control charts—essentially, Deming's statistical engine—to mathematically identify when the model is facing a "Special Cause" and requires retraining.

Conclusion

Deming's legacy warns us against blind faith in technology: the only way to tame AI, mitigate global disruptions, and optimize S&OP in our era is to subordinate the overwhelming raw computing power to the inexorable dictates of process stability and variance reduction. Statistical Control is not dead; in fact, today it orchestrates the algorithms that run the world.

References and Further Reading

Deming, W. E. (1993). The New Economics for Industry, Government, Education.
The W. Edwards Deming Institute
History of the Toyota Production System (TPS)

W. Edwards Deming: El Padre de la Calidad Total que Predijo el Futuro de la IA

Daniel — Sun, 31 May 2026 13:51:07 +0000

El panorama industrial contemporáneo exige marcos de gestión robustos frente a la extrema volatilidad. En el epicentro de esta arquitectura organizativa y analítica se encuentra la filosofía monumental de W. Edwards Deming. Concebido en las primeras décadas del siglo XX, su enfoque teórico ha trascendido la planta de producción para convertirse en el cimiento indiscutible de la Planificación de Ventas y Operaciones (S&OP) y la gestión de redes de valor complejas.

La premisa fundamental de Deming postula que la calidad no se logra mediante la inspección masiva al final, que es reactiva y costosa. La verdadera calidad nace de reducir la variación en los procesos subyacentes.

El Sistema de Conocimiento Profundo y el Control Estadístico

Deming proponía un paradigma gerencial radical: el Sistema de Conocimiento Profundo (System of Profound Knowledge). Este sistema requiere que optimicemos el "todo" (la red interconectada) en lugar de maximizar silos departamentales. Nos enseñó que la variación es inherente a cualquier actividad, pero que la clave del liderazgo radica en diferenciar la "variación crónica" (causas comunes) de las "anomalías" (causas especiales) mediante el Control Estadístico de Procesos (SPC).

Uno de sus insights más destructivos hacia la gestión tradicional fue el concepto de Tampering o sobre-ajuste. Cuando la gerencia (por ejemplo, en las reuniones mensuales de S&OP) reacciona a variaciones estadísticas normales como si fueran crisis sistémicas ajustando el plan drásticamente, paradójicamente amplifica el desastre y aumenta la inestabilidad. Esta es la raíz de por qué un pronóstico de ventas asustadizo engendra el infame Efecto Látigo en la cadena de suministro.

Toyota y la Revolución Impulsada por Datos

El impacto de Deming se vio con mayor contundencia en la milagrosa reconstrucción industrial del Japón de la posguerra. Toyota abrazó su doctrina, instaurando el famoso ciclo PDCA (Planificar-Hacer-Verificar-Actuar).

Antes de Deming, las decisiones dependían del instinto. Después, los ingenieros de Toyota comprendieron que planificar el S&OP o diseñar capacidad de planta sin datos estadísticamente fiables equivalía a caminar a ciegas hacia la obsolescencia. Gracias a él, Toyota erradicó la filosofía de inspección final en favor de "construir la calidad dentro del proceso", cimentando lo que más tarde el mundo conocería como Lean Manufacturing.

El Horizonte Tecnológico: IA y Concept Drift

Quizás la prueba más asombrosa de la inmortalidad de las matemáticas de Deming es su aplicación actual en la frontera de la Inteligencia Artificial y la automatización corporativa.

La regla fundamental de la robótica moderna es: "Estabilizar antes de automatizar, siempre". La IA no puede inferir causalidades precisas a partir de un flujo de trabajo humano caótico o datos ruidosos. Los principios de estandarización de Deming son requisitos ineludibles para cualquier iniciativa de Machine Learning.

Aún más profundo es cómo la ciencia de datos moderna utiliza el Control Estadístico de Procesos para vigilar a los propios modelos de IA. Cuando un modelo predictivo en el mundo real comienza a fallar debido a cambios macroeconómicos imprevistos (un fenómeno conocido como Concept Drift o Deriva de Concepto), los ingenieros recurren a gráficos de control multivariantes—esencialmente, el motor estadístico de Deming—para identificar matemáticamente cuándo el modelo está enfrentando una "Causa Especial" y requiere ser reentrenado.

Conclusión

El legado de Deming nos advierte frente a la fe ciega en la tecnología: la única forma de domar la IA, mitigar las disrupciones globales y optimizar el S&OP en nuestra era es subordinar la abrumadora potencia de cálculo a los inexorables dictámenes de la estabilidad del proceso y la reducción de la varianza. El Control Estadístico no ha muerto; de hecho, hoy orquesta a los algoritmos que mueven el mundo.

Fuentes de interés

Deming, W. E. (1993). The New Economics for Industry, Government, Education.
The W. Edwards Deming Institute
Historia del Sistema de Producción Toyota (TPS)