Últimamente circula una idea por LinkedIn, X y un par de hilos de Hacker News que conviene mirar con calma: que los LLM modernos —Claude en particular— ya no necesitan Markdown para ser eficientes, que mandar HTML «es más elegante», queda más bonito por pantalla, y que el modelo internamente «limpia el ruido» y termina consumiendo prácticamente los mismos tokens. La conclusión que se vende es tentadora: HTML gratis, mejor presentación, mismo coste.

No es así. Y como casi todo en este oficio, lo razonable no es opinar, sino medirlo.

De dónde viene esto

El origen del debate es real y serio. El 8 de mayo de 2026, Thariq Shihipar, engineering lead de Claude Code en Anthropic, publicó un artículo viral llamado «Using Claude Code: The Unreasonable Effectiveness of HTML». Su argumento, resumido sin caricaturas, es que para outputs destinados a humanos (planes de proyecto, code reviews, comparativas visuales, dashboards efímeros) HTML aporta densidad informativa, color, tablas con jerarquía, SVG inline e interactividad que Markdown no puede dar. Y eso, dice, justifica el sobrecoste.

Hasta ahí, opinión legítima sobre experiencia de usuario.

El problema empieza cuando ese argumento se simplifica en el camino y acaba como «Claude ya consume los mismos tokens con HTML que con Markdown». Eso es lo que se ha colado en muchos hilos, y eso es lo que es técnicamente falso.

La medición, antes que la teoría

Tomé un fragmento idéntico (una intro corta a Azure Functions, ~700 caracteres de contenido real) y lo serialicé en tres formatos. Tokenización con regex GPT-2 + estimación BPE; el número absoluto puede variar según el tokenizador exacto, pero el ratio entre formatos es robusto.

Estos números no son una sorpresa ni un invento mío:

• Web2MD publicó un benchmark sobre artículos web reales: un texto que ocupa ~2.800 tokens en Markdown sube a ~8.000 en HTML. Reducción del 67% al pasar HTML → Markdown.
• Sobre 200 páginas mixtas (docs, blogs, Wikipedia, noticias), la conversión a Markdown supone una reducción media del 87,5% en tokens.
• El propio Thariq lo admite en su post: el HTML limpio cuesta 2-3x más tokens que el Markdown equivalente, y HTML con CSS y JS reales puede llegar a 8-10x.

Es decir, el debate honesto no es «¿HTML cuesta lo mismo?». El debate es: «¿compensa pagar entre 2x y 10x más tokens a cambio de mejor experiencia visual?». Y la respuesta depende del caso.

Por qué la frase «Claude limpia todo y consume lo mismo» no se sostiene

Tres razones técnicas, ordenadas:

1. El modelo no controla los tokens que genera. Cuando un LLM produce su respuesta, cada <h2>, cada class="...", cada </div> pasa por el tokenizador exactamente igual que el contenido. No existe un paso oculto de compresión semántica entre lo que el modelo escribe y lo que se factura. Lo que sale es lo que se cuenta.

2. BPE no está optimizado para markup. Los tokenizadores BPE (cl100k, el de Claude, los de la familia GPT) están entrenados predominantemente sobre prosa y código. Símbolos densos como <, >, /, ="..." suelen partirse en varios tokens. Markdown, al usar caracteres ligeros (#, -, **, ```) consume menos. No es opinión, es cómo está entrenado el vocabulario.

3. «Limpiar el HTML antes de enviarlo» es input, no output. Sí existe una pipeline legítima web → Markdown → modelo, y es lo que hacen herramientas tipo Jina Reader, Trafilatura o Web2MD. Pero esa pipeline confirma exactamente lo contrario del bulo: el ahorro está en convertir a Markdown, no en mandar HTML «limpio».

Donde quizá nace la confusión: caching ≠ menos tokens

Anthropic, OpenAI y otros proveedores ofrecen prompt caching: si reenvías el mismo prefijo de contexto, el coste por token cacheado es menor. Esto reduce el coste en € por token, pero no el número de tokens consumidos. Son dos métricas distintas y se mezclan a menudo en los hilos divulgativos. Si alguien ha medido el gasto en factura y ha visto bajada, probablemente está viendo efecto del caché, no eficiencia del formato.

Calidad del output, no solo coste

Más allá del recibo, el formato afecta a la calidad de las respuestas. Benchmark de Web2MD con el mismo contenido en ambos formatos sobre GPT-4, Claude y Gemini:

En tablas, las representaciones Markdown superan a las HTML en precisión de extracción (60,7% vs 53,6% en evaluaciones sobre GPT). Lógica detrás de esto: el corpus de entrenamiento contiene una cantidad gigantesca de Markdown bien formado (README, wikis, docs), y muy poco HTML bien estructurado y libre de ruido.

¿Y con Claude Opus 4.7? Spoiler: peor

La objeción razonable es legítima: «los benchmarks que citas son sobre GPT-4 o Claude 3.5, modelos de hace un año. ¿Sigue siendo válido con Opus 4.7?». La respuesta corta es sí, y además el problema se agrava. Veamos los datos publicados desde el lanzamiento.

Opus 4.7 estrena tokenizer nuevo, y eso cambia el escenario por completo. La propia documentación de Anthropic lo dice sin maquillaje: «This new tokenizer may use roughly 1x to 1.35x as many tokens when processing text compared to previous models (up to ~35% more, varying by content)». Es decir, el mismo texto que en Opus 4.6 ocupaba 100 tokens, en 4.7 puede ocupar hasta 135. Mismo precio por token, mismo cupo en el plan, pero más tokens por prompt.

Los números medidos en producción son aún peores que la horquilla oficial:

El análisis de Korchasa sobre 53 idiomas y 12 tipos de datos identifica el motivo: en 4.7 se han eliminado del vocabulario las cadenas largas de palabras inglesas pre-mergeadas (BPE merges) que tenía 4.6. Ahora el modelo necesita varios tokens cortos donde antes usaba uno largo. JSON, espacios en blanco y dígitos no cambian; lenguajes no latinos (CJK, árabe, hebreo, hindi, ruso) tampoco. Lo que se ha pagado son las palabras inglesas, que es justo el tipo de contenido que llena un CLAUDE.md, un system prompt o un payload HTML.

Por qué esto amplifica el problema con HTML

Aquí está la conexión con el debate del artículo. Si el tokenizer de 4.7 fragmenta más cualquier texto inglés, fragmenta todavía más el markup HTML, que ya partía con desventaja en BPE por sus símbolos densos (<, >, /, ="..."). El gap entre Markdown y HTML, lejos de cerrarse con el «modelo más nuevo y más inteligente», se ensancha:

• En Opus 4.6, HTML semántico limpio costaba ~1.5x más tokens que su equivalente Markdown.
• En Opus 4.7, esa misma penalización se compone con la inflación general del nuevo tokenizer (1.3x – 1.45x), porque los símbolos del markup están entre lo que peor encaja con un vocabulario al que le han quitado merges largos.

OpenRouter, midiendo cohortes reales de usuarios que migraron 4.6 → 4.7, reporta incrementos de coste del 12% al 27% en producción después del descuento del 90% por caching. Sin caching, la inflación de tokens es del 32% al 45% sobre prompts y completaciones.

Lectura operativa

Esto refuerza, no debilita, el argumento del artículo:

1. Si ya estabas dudando entre MD y HTML para input a Claude, en 4.7 la balanza se inclina aún más hacia Markdown. El sobrecoste de HTML se multiplica por la inflación base del nuevo tokenizer.
2. Si tienes pipelines en producción, replay obligatorio antes de migrar 4.6 → 4.7. La factura no se mantiene aunque el rate card sí: la documentación oficial avisa de que count_tokens devolverá números distintos para el mismo contenido.
3. El caching sigue siendo la palanca principal de coste. El 90% de descuento por cache hit se mantiene en 4.7, pero el prefijo que escribes al caché es 1.3x – 1.45x más grande la primera vez. Es decir, el cold-start es más caro, aunque el régimen estacionario apenas se note.
4. camelCase paga +51% de inflación. Si tu RAG corporativo serializa nombres de variables, identificadores Java/C#, paths de Azure (Microsoft.Storage/storageAccounts), o cualquier código fuente sin formato, ese 51% va directo a tu factura. Es otro argumento para limpiar el input antes de mandarlo, no para meter HTML.

Resumido: el tokenizador nuevo de Opus 4.7 mejora cosas (multilenguaje no latino, soporte de imágenes a alta resolución, instruction-following estricto en +5pp según IFEval), pero no resuelve la economía del formato. Si acaso, la acentúa. El consejo no cambia: mide con el count_tokens oficial del modelo concreto que vas a usar, no con heurísticas de hace un año.

Cuándo cada uno

Sin dogmatismo. Cada formato tiene su sitio:

Markdown es la elección por defecto cuando:

• Cargas contexto al modelo (RAG, ingestión de documentación, system prompts largos).
• El output va a otro paso de la pipeline (parser, embedding, log estructurado, otro agente).
• El artefacto vive en Git y necesita diffs legibles en pull requests.
• Estás en un escenario de alto throughput donde el coste por output domina.

HTML puede compensar cuando:

• El consumidor final es un humano que va a leer el artefacto una sola vez.
• Necesitas densidad visual: tablas con color, SVG inline, badges, jerarquía clara.
• Estás en Claude Artifacts o un canvas donde el render aporta valor real.
• Aceptas pagar 2-3x tokens a cambio de mejor cognición humana, y lo presupuestas.

Resumido en una frase: si el lector es un modelo, Markdown. Si el lector es un humano que va a leerlo una vez, HTML puede compensar.

Aterrizando en arquitectura enterprise

En los escenarios que tocamos a diario —MCP en .NET y Azure, AI Gateway sobre YARP, agentes orquestados, RAG corporativo, control plane de IA con APIM— el flujo dominante es modelo dentro de pipeline, no «informe bonito para enseñar a un cliente». En ese terreno, mandar HTML para hablar con el LLM es regalar tokens sin contrapartida.

Y en gobierno de coste de IA empresarial, esa diferencia no es cosmética: a 1.000 páginas al mes a precios actuales de Claude Sonnet, el sobrecoste por usar HTML en lugar de Markdown en la entrada se mueve en el orden de cientos de euros por pipeline. Con Opus 4.7 el cálculo es aún más sangrante: multiplica ese sobrecoste por la inflación del nuevo tokenizer y multiplícalo por número de pipelines y por entornos (dev, staging, prod). En cualquier organización con varios casos de uso en producción, esto se nota en el FinOps mensual.

No soy el único que lo ve así

Scott S. Nelson, en Markup is the New Markdown (12 mayo 2026), pone el dedo en la llaga del propio fenómeno viral:

«Que se haya viralizado así dice menos del artículo en sí y más de las ganas que tenía la gente de que alguien les diera permiso para hacer lo que ya querían hacer.»

En el original: «The fact that it spread the way it did says less about the content and more about how hungry people are for permission to do the thing they already half-wanted to do.»

Es exactamente lo que ha pasado. El post de Thariq es legítimo en su acotación original —output destinado a humanos, no input a modelos— pero la versión que circula por LinkedIn ha perdido toda esa precisión por el camino. Y eso, en enterprise, cuesta dinero.

Conclusión

La intuición correcta es la que muchos teníamos: no, HTML no consume los mismos tokens que Markdown, ni se «limpia mágicamente» por el modelo ni por la tool que el modelo usa. El argumento real de Thariq es legítimo, pero acotado: pagas más tokens a cambio de mejor experiencia humana, en outputs concretos, no como regla general.

Y con Opus 4.7, el argumento se refuerza en lugar de debilitarse. El nuevo tokenizer infla todo el texto inglés entre un 30% y un 45% real medido en producción, lo que amplifica la penalización del markup denso del HTML en lugar de mitigarla. Quien esperaba que «los modelos nuevos resuelvan el problema del formato» se ha llevado lo contrario: un tokenizer que paga más por palabra y, por composición, más todavía por etiqueta.

Para input al modelo y para flujos agente-a-agente, Markdown sigue siendo objetivamente la elección correcta en 2026. Y la única forma honesta de zanjar el debate en cada caso no es leer hilos, es medir tokens con el tokenizador del modelo concreto que usas.

Antes de cambiar el formato por defecto de tu stack, pasa tu contenido real por count_tokens de Anthropic (o tiktoken de OpenAI) especificando el modelo destino, no el genérico. Probablemente te llevarás la misma sorpresa que me llevé yo.

Enlaces y referencias

El debate original

• Galería oficial de Thariq Shihipar (20 ejemplos HTML generados por Claude Code) https://thariqs.github.io/html-effectiveness
• Simon Willison — cobertura del post de Thariq (fecha de referencia: 8 mayo 2026) https://simonwillison.net/2026/May/8/unreasonable-effectiveness-of-html/
• Scott S. Nelson — Markup is the New Markdown (réplica matizada, 12 mayo 2026) https://theitsolutionist.com/2026/05/12/markup-is-the-new-markdown/
• Kurtis Redux — The Unreasonable Ineffectiveness of HTML (contraréplica directa) https://kurtis-redux.medium.com/the-unreasonable-ineffectiveness-of-html-5bd01ae1e879

Datos empíricos sobre tokens, Markdown y HTML

• Web2MD — Markdown vs HTML para LLM (benchmark de calidad por tarea) https://web2md.org/blog/markdown-vs-html-for-llm
• Web2MD — Guía práctica para reducir consumo de tokens (reducción media del 87,5%) https://web2md.org/blog/reduce-llm-token-usage-practical-guide
• Beam.ai — HTML vs Markdown for AI Agents: Which Format Wins in 2026 https://beam.ai/agentic-insights/html-vs-markdown-which-format-actually-makes-ai-agents-more-useful
• ReleasePad — The Optimal Format for LLM Content Ingestion https://www.releasepad.io/blog/html-vs-markdown-the-optimal-format-for-llm-content-ingestion/
• SearchCans — Markdown vs HTML for LLM Context Optimization https://www.searchcans.com/blog/markdown-vs-html-llm-context-optimization-2026/

Datos específicos del tokenizer de Opus 4.7

• Anthropic — What’s new in Claude Opus 4.7 (documentación oficial: 1.0x – 1.35x) https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-7
• Simon Willison — Claude Token Counter con comparativa 4.6 vs 4.7 (medido: 1.46x) https://simonwillison.net/2026/apr/20/claude-token-counts/
• Claude Code Camp — I Measured Claude 4.7’s New Tokenizer (medido: 1.45x – 1.47x) https://www.claudecodecamp.com/p/i-measured-claude-4-7-s-new-tokenizer-here-s-what-it-costs-you
• OpenRouter — Opus 4.7’s New Tokenizer: What It Actually Costs (cohorte real de migración) https://openrouter.ai/announcements/opus-47-tokenizer-analysis
• Korchasa — opus 4.7: tokenizer changes and rising costs (análisis sobre 53 idiomas y 12 tipos de datos) https://korchasa.dev/posts/2026_04_17_opus_4_7_tokenizer/
• Finout — Claude Opus 4.7 Pricing: The Real Cost Story (análisis FinOps del impacto real) https://www.finout.io/blog/claude-opus-4.7-pricing-the-real-cost-story-behind-the-unchanged-price-tag

Herramientas para medir tú mismo

• Anthropic — Endpoint oficial count_tokens (gratuito, sin inferencia) https://docs.claude.com/en/api/messages-count-tokens
• OpenAI — tiktoken (proxy razonable para BPE genérico) https://github.com/openai/tiktoken
• Token Calculator multi-modelo (GPT-5.5, Claude Opus 4.7, Gemini 3.1 Pro) https://token-calculator.net/

Durante años hemos vendido la nube como una conversación casi binaria: o estás en cloud o estás on-premises. Para mí, ese debate ya se ha quedado corto.

La cuestión real ya no es “cloud sí” o “cloud no”. La cuestión relevante para gobiernos, banca, salud, industria, defensa o infraestructuras críticas es otra:

¿Qué nivel de control operativo, jurídico, técnico y de continuidad necesito sobre mis sistemas más sensibles?

Y aquí es donde empieza a ponerse interesante la conversación sobre cloud soberana, Azure Local, operaciones desconectadas, Microsoft 365 Local, Foundry Local y modelos de DevOps más controlados.

Mi tesis es sencilla: la soberanía digital no consiste en sacar todo de la nube pública. Consiste en diseñar una arquitectura capaz de demostrar control cuando las condiciones normales dejan de ser normales.

Microsoft ya presenta su estrategia de Sovereign Cloud en tres modelos: nube pública soberana, nube privada soberana y nubes nacionales operadas con socios locales. La propia documentación de Microsoft describe la Sovereign Public Cloud como Azure/Microsoft cloud con controles añadidos de residencia, claves gestionadas por cliente, transparencia operativa, Data Guardian, External Key Management y logs resistentes a manipulación; y define la Sovereign Private Cloud como un modelo ejecutado en datacenters controlados por el cliente o por socios, basado en Azure Local y Microsoft 365 Local, orientado a escenarios híbridos o desconectados.

Soberanía no es solo residencia de datos

Uno de los errores habituales es reducir la soberanía a “mis datos están en Europa” o “mis datos están en una región concreta”.

Eso es importante, pero no suficiente.

La soberanía real tiene varias capas:

Primero, soberanía del dato: dónde reside, quién lo cifra, quién puede acceder y bajo qué condiciones.

Segundo, soberanía operativa: quién administra la plataforma, qué accesos excepcionales existen, cómo se auditan y si puedo demostrar trazabilidad.

Tercero, soberanía tecnológica: si mis cargas críticas pueden seguir funcionando aunque pierda conectividad, aunque haya una crisis contractual, regulatoria, geopolítica o de proveedor.

Cuarto, soberanía del ciclo de vida del software: dónde vive el código, dónde se ejecutan los pipelines, dónde están los secretos, quién puede modificar la cadena de suministro y cómo se evidencia cada cambio.

Para mí, esta última parte se olvida demasiado. En empresas reguladas, el código fuente, los pipelines y los artefactos de despliegue son tan sensibles como los datos de producción. No tiene sentido proteger obsesivamente una base de datos si luego el camino que permite cambiar el software está débilmente gobernado.

Azure Local: la nube híbrida empieza a parecerse a una póliza de continuidad

Azure Local es especialmente relevante porque deja de plantear el datacenter como un “mundo antiguo” separado de la nube. Microsoft lo describe como una solución de infraestructura distribuida para ejecutar máquinas virtuales, contenedores y determinados servicios Azure en infraestructura propiedad del cliente; además, Azure Stack HCI forma ya parte de Azure Local.

La diferencia importante no es solo técnica. Es estratégica.

Azure Local puede convertirse en la base para una arquitectura donde ciertas cargas sigan beneficiándose del modelo cloud, pero con más control sobre ubicación, operación y continuidad. En la documentación de Sovereign Private Cloud, Microsoft posiciona Azure Local como la capa base de infraestructura para workloads soberanos, incluyendo cómputo, almacenamiento, red, lifecycle management, VMs y AKS habilitado por Arc.

Esto no significa que Azure Local sea “todo Azure dentro de tu CPD”. Esa lectura sería equivocada y peligrosa. Significa algo más concreto: una base local, gestionable con experiencia cloud, sobre la que construir escenarios regulados, híbridos, edge o desconectados.

Y aquí está el matiz que a mí me parece clave: Azure Local no debería venderse como nostalgia on-premises. Debería entenderse como resiliencia arquitectónica soberana.

Operaciones desconectadas: útil, pero no magia

Las operaciones desconectadas son probablemente una de las piezas más importantes para sectores regulados. La documentación pública indica que permiten desplegar y administrar instancias de Azure Local sin conexión a la nube pública de Azure, usando un plano de control local y una experiencia familiar de portal y CLI para máquinas virtuales y aplicaciones contenedorizadas mediante servicios seleccionados habilitados por Azure Arc.

Esto es muy potente, pero hay que aterrizarlo bien.

Desconectado no significa “sin gobierno”.
Desconectado no significa “sin parches”.
Desconectado no significa “sin identidad”.
Desconectado no significa “sin operación”.

De hecho, cuanto más aislado está un entorno, más disciplina necesita: gestión de versiones, procedimientos de actualización offline, control de identidades locales, backups, observabilidad, evidencias, runbooks, pruebas de conmutación, restauración y validación periódica.

La cloud soberana no elimina la complejidad. La mueve al terreno donde los arquitectos debemos estar cómodos: diseño de riesgos, controles y evidencias.

Microsoft 365 Local: útil, pero no confundamos el alcance

Microsoft 365 Local es otra pieza interesante, pero conviene explicarla con precisión. Según Microsoft Learn, Microsoft 365 Local permite ejecutar Exchange Server, SharePoint Server y Skype for Business Server sobre infraestructura Azure Local propiedad y gestionada por el cliente, con mayor control de residencia, acceso y cumplimiento. También se indica que soporta escenarios híbridos y completamente desconectados.

Esto es importante para sectores que necesitan productividad local o continuidad en escenarios de aislamiento.

Pero hay que evitar una confusión: Microsoft 365 Local no debe interpretarse automáticamente como “todo Microsoft 365 cloud funcionando localmente”.

No estamos hablando, al menos con la información pública actual, de replicar sin más toda la experiencia SaaS moderna de Microsoft 365, Teams, Copilot, Entra ID, Conditional Access y ecosistema cloud en un datacenter local. Es una solución con un alcance concreto, útil para determinados escenarios, pero que debe explicarse sin crear expectativas incorrectas.

En entornos regulados, vender mal el alcance de una plataforma es casi tan peligroso como diseñarla mal.

IA soberana: el dato no siempre puede ir al modelo

La IA introduce una nueva tensión. Antes nos preocupaba dónde estaba la base de datos. Ahora también debemos preguntarnos:

¿Dónde se ejecuta la inferencia?
¿Dónde se procesan los embeddings?
¿Dónde se guardan los prompts?
¿Dónde se evalúan los modelos?
¿Dónde quedan las trazas?
¿Qué datos pasan por una cadena RAG?
¿Qué agente puede actuar sobre qué sistema?

Microsoft ya documenta Foundry Local sobre Azure Local como una vía para acercar la IA al dato, desplegando y ejecutando modelos dentro del entorno Azure Local. La documentación pública indica que Foundry Local está en preview, que puede desplegarse sobre Kubernetes conectado a Azure Arc o Kubernetes directo, y que requiere acceso de preview para el despliegue.

Para mí, esto apunta a una idea importante: la IA empresarial no se va a decidir solo por el modelo más potente, sino por el modelo operativo más gobernable.

En banca, salud, administración pública o industria, muchas cargas de IA no podrán moverse alegremente a cualquier endpoint global. Necesitaremos arquitecturas donde los datos sensibles se queden cerca de su dominio de control, donde la inferencia tenga trazabilidad y donde los agentes no puedan actuar sin límites.

Aquí conecto con algo que llevo tiempo defendiendo: la IA empresarial no puede ser solo productividad individual. Tiene que evolucionar hacia un modelo gobernado de ciclo de vida: intención, especificación viva, controles, ADRs, guardrails, testing, despliegue y auditoría.

DevOps soberano: el código también es soberanía

Hay un punto que creo que va a ganar peso: la soberanía del software delivery.

GitHub Enterprise Server ya existe como versión self-hosted de GitHub. La documentación oficial de GitHub lo describe como una plataforma autohospedada que se ejecuta en infraestructura propia, con controles de acceso, seguridad, red, IAM, monitorización y VPN definidos por la empresa. También deja claro que el administrador es responsable de mantener la instancia actualizada.

Esto no es menor.

Si una organización necesita soberanía extrema, no basta con tener producción controlada. Tiene que controlar también:

• repositorios;
• pull requests;
• secretos;
• pipelines;
• artefactos;
• políticas de branch;
• evidencias de revisión;
• SBOMs;
• firmas de artefactos;
• trazabilidad de cambios;
• dependencias de terceros.

Mi punto aquí es claro: GitHub Enterprise Server encaja muy bien conceptualmente en una estrategia de soberanía del software delivery. Pero en arquitectura no deberíamos vender intuiciones como certezas. Hasta que no exista documentación suficiente o una validación real en un entorno controlado, lo responsable es tratarlo como una opción prometedora, no como una capacidad cerrada y universalmente aplicable.

La nube soberana no es una tecnología: es una arquitectura de decisión

Para mí, el mayor error sería convertir esto en otro catálogo de productos.

Azure Local, Microsoft 365 Local, Foundry Local, Confidential Computing, External Key Management, Data Guardian, Sovereign Landing Zone o Regulated Environment Management son piezas. Algunas ya están disponibles, otras evolucionan, y todas requieren diseño.

La Sovereign Landing Zone, por ejemplo, se plantea como un enfoque de policy-as-code para aplicar controles de localización, cifrado, configuración y computación confidencial en entornos soberanos. Microsoft también documenta REM como una experiencia para configurar, desplegar y monitorizar workloads en soporte de operaciones soberanas, complementando EKM, Data Guardian y Confidential Computing.

Pero ninguna landing zone sustituye a una conversación seria sobre riesgo.

La pregunta correcta no es: “¿Qué producto compro?”
La pregunta correcta es: “¿Qué escenarios de pérdida de control debo resistir?”

Por ejemplo:

¿Qué pasa si pierdo conectividad durante días?
¿Qué pasa si un proveedor externo no puede operar mi entorno?
¿Qué pasa si una carga crítica debe moverse a ejecución local?
¿Qué pasa si necesito demostrar que ningún operador no autorizado accedió a datos sensibles?
¿Qué pasa si mi pipeline de software queda comprometido?
¿Qué pasa si un modelo de IA procesa información regulada fuera del perímetro aceptado?

Ahí es donde un arquitecto aporta valor. No dibujando cajas, sino convirtiendo incertidumbre en decisiones verificables.

Mi punto de vista

Mi lectura es que estamos entrando en una etapa donde la cloud híbrida deja de ser una solución de transición y pasa a ser una estrategia de resiliencia soberana.

Durante años, muchas organizaciones han visto lo híbrido como una deuda: “todavía no hemos migrado todo”. Creo que eso cambia. En los próximos años, lo híbrido bien diseñado puede convertirse en una ventaja competitiva para sectores regulados.

Pero tiene que ser híbrido de verdad, no un Frankenstein.

Tiene que tener identidad pensada.
Tiene que tener red pensada.
Tiene que tener observabilidad pensada.
Tiene que tener actualizaciones pensadas.
Tiene que tener DevSecOps pensado.
Tiene que tener IA pensada.
Tiene que tener pruebas reales de desconexión.
Tiene que tener evidencias.

La cloud soberana no debería ser una excusa para volver a modelos artesanales, opacos y difíciles de operar. Debería ser justo lo contrario: llevar la disciplina cloud, la automatización, el gobierno y la trazabilidad a los entornos donde el control local es obligatorio.

Conclusión

No creo que el futuro sea abandonar la nube pública. Tampoco creo que el futuro sea confiar ciegamente en ella para todo.

Creo que el futuro será más matizado:

• cloud pública para innovación, elasticidad y servicios avanzados;
• cloud soberana pública para cargas reguladas con controles reforzados;
• Azure Local y modelos privados para continuidad, edge, defensa, industria y escenarios críticos;
• IA local o híbrida cuando el dato, la latencia o la regulación lo exijan;
• DevOps soberano cuando el código y la cadena de suministro sean activos críticos.

La soberanía digital no es un botón.
No es una región.
No es un contrato.
No es una landing zone.
No es un producto.

Es una arquitectura de control, continuidad y evidencia.

Y esa, sinceramente, es una conversación donde los arquitectos tenemos que estar mucho más presentes.

Fundamentos, arquitectura limpia y estrategia de testing

Introducción

Model Context Protocol (MCP) está emergiendo como el estándar de facto para conectar agentes de IA con capacidades reales de sistemas: APIs, datos, operaciones.

El problema es que está entrando en proyectos por la puerta equivocada.

Estoy viendo equipos que:

• diseñan directamente “un MCP Server”
• meten lógica dentro de tools
• acoplan dominio a protocolo
• y luego se preguntan por qué no pueden testear ni escalar

Este artículo va a ser claro:

MCP no es tu arquitectura. Es un adaptador.

Y si no lo tratas como tal, vas a construir algo frágil.

1. Qué es MCP (desde el punto de vista arquitectónico)

MCP define un contrato:

• tools (acciones ejecutables)
• resources (datos)
• prompts (plantillas)
• comunicación vía JSON-RPC

Especificación oficial:
https://modelcontextprotocol.io/specification/2025-03-26

En .NET, ya puedes montar servidores MCP sobre ASP.NET Core:

• SDK C#
• integración con HTTP / streaming
• despliegue en Azure

Ejemplo oficial de Microsoft:
https://learn.microsoft.com/en-us/azure/container-apps/tutorial-mcp-server-dotnet

Lo importante

MCP:

• expone capacidades
• no define cómo construirlas

2. El anti-patrón que debes evitar

Este diseño aparece constantemente:

Problemas:

• acoplamiento extremo
• imposible testear en aislamiento
• difícil evolucionar
• no reutilizable
• sin separación de responsabilidades

Esto no escala.

3. Patrón correcto: Clean Architecture + MCP como adapter

La única forma sostenible es separar:

Regla clave

Cada tool MCP debe ser un wrapper fino sobre un caso de uso.

Ejemplo conceptual en .NET:

Nada de lógica en el tool.

4. Por qué no debes diseñar “directo a MCP”

Hay razones técnicas, no opiniones.

4.1 El protocolo aún está evolucionando

El propio roadmap lo reconoce:

• retos en transporte remoto
• balanceo
• operación stateless
• sesiones

Información adicional: https://modelcontextprotocol.io/development/roadmap

4.2 MCP no cubre necesidades operativas

No resuelve:

• health checks
• observabilidad estándar
• control de errores avanzado

De hecho, Microsoft recomienda endpoints adicionales:

Ir al tutorial: https://learn.microsoft.com/en-us/azure/container-apps/tutorial-mcp-server-dotnet

4.3 Te ata a un canal de entrada

Si todo está dentro de MCP:

• no puedes exponer REST fácilmente
• no puedes reutilizar lógica
• no puedes integrar otros sistemas

5. Testing: separar lo determinista de lo probabilístico

Aquí está la clave que suele confundirse.

5.1 Qué puedes testear de forma determinista

Dominio y aplicación

• tests unitarios clásicos
• sin MCP
• sin LLM

100% determinista

Adaptador MCP (contrato)

Puedes validar:

• nombre del tool
• schema de entrada/salida
• mapping a casos de uso
• errores

Endpoint MCP

Puedes testear:

• JSON-RPC correcto
• estructura de respuesta
• códigos HTTP
• streaming

El protocolo está definido para permitir esto: https://modelcontextprotocol.io/specification/2025-03-26

5.2 Qué NO es determinista

La respuesta final de un agente:

Aquí entran:

• decisiones del modelo
• contexto
• temperatura

Esto no es testing clásico. Es:

• evaluación
• métricas
• observabilidad

5.3 ¿Necesitas una API REST para testear?

No.

Puedes testear directamente MCP:

• llamadas HTTP JSON-RPC
• herramientas como MCP Inspector

https://modelcontextprotocol.io/docs/tools/inspector

REST es útil, pero no obligatorio.

6. Diseño de un MCP Server en .NET

Stack típico:

• ASP.NET Core
• ModelContextProtocol.AspNetCore
• hosting en Azure

Opciones de despliegue:

• Azure Container Apps
• Azure App Service
• Azure Kubernetes Service

Referencia oficial: https://learn.microsoft.com/en-us/azure/container-apps/tutorial-mcp-server-dotnet

Endpoints recomendados

Nunca uses /mcp como health endpoint.

Nota del autor: siento repetir esto, pero cuando lo ves, lo explicas 1 vez, 2 veces, …, pues insistes otra vez.

7. Problemas reales en producción

Cuando sales de local aparecen problemas serios.

7.1 Transporte

• streaming HTTP
• proxies que rompen conexiones
• buffering inesperado

7.2 Escalado

• sesiones implícitas
• balanceadores no preparados
• pérdida de contexto

7.3 Seguridad

• autenticación
• exposición de tools
• ejecución indirecta

7.4 Observabilidad

• correlación entre tool calls
• trazabilidad de decisiones

8. Insight clave

Este es el punto que debes interiorizar:

MCP introduce ejecución remota de capacidades controladas por un modelo.

Eso cambia completamente:

• el modelo de seguridad
• el modelo de testing
• el modelo de arquitectura

9. Patrón recomendado

Estructura de solución

Principios

• MCP = adapter, no core
• dominio independiente
• casos de uso testeables
• infraestructura desacoplada
• tools sin lógica

Para terminar

MCP es una pieza clave en la arquitectura de sistemas con IA.

Pero no es el sistema.

Si diseñas directamente alrededor de MCP:

• pierdes testabilidad
• pierdes control
• pierdes capacidad de evolución

Si lo usas correctamente:

• ganas interoperabilidad con agentes
• mantienes arquitectura sólida
• puedes escalar en Azure

No construyas un MCP Server.
Construye capacidades bien diseñadas y expónlas vía MCP.

Nota del autor

Una observación recurrente en proyectos recientes es que muchas de las malas prácticas en torno a MCP aparecen en desarrollos realizados en Python.

Es importante matizar que esto no es un problema del lenguaje en sí —aunque, como cualquier stack, tiene sus limitaciones—, sino principalmente una cuestión de falta de disciplina arquitectónica.

En muchos casos se detecta:

• ausencia de separación clara entre dominio, aplicación e infraestructura

• lógica de negocio incrustada en handlers o tools

• falta de contratos explícitos

• baja testabilidad desde el diseño

• falta de testing (derivado de lo anterior)

Python facilita iterar rápido, pero también facilita saltarse estructuras formales si no se imponen desde el inicio. En entornos MCP esto se agrava, porque el protocolo introduce una capa adicional de complejidad (ejecución indirecta, tools, agentes, etc.).

La conclusión no es “evitar Python”, sino:

sin un modelo de arquitectura limpia, cualquier lenguaje deriva rápidamente en sistemas difíciles de mantener, testear y escalar.

En contextos enterprise —especialmente cuando se integran agentes y MCP—, la disciplina arquitectónica deja de ser opcional.

Control plane de IA: APIM, seguridad y escalado real en Azure

Introducción

En la primera parte hemos dejado claro algo fundamental:

MCP no es tu arquitectura. Es un adaptador.

Pero eso abre una pregunta crítica:

¿Qué controla realmente lo que un agente puede hacer cuando usa MCP?

Porque aquí cambia el paradigma.

Ya no hablamos de:

• APIs invocadas por humanos
• o sistemas integrándose de forma explícita

Ahora hablamos de:

un modelo tomando decisiones y ejecutando capacidades reales en tu sistema

Y eso tiene implicaciones directas en:

• seguridad
• gobierno
• coste
• escalabilidad

La respuesta en Azure es clara:

API Management como AI Gateway (control plane)

1. El problema real: MCP sin control es una superficie de ataque

Cuando expones MCP, estás exponiendo:

• tools ejecutables
• acceso a datos
• operaciones reales

Pero además introduces un intermediario:

Esto genera nuevos riesgos:

1. Prompt Injection

El modelo recibe instrucciones maliciosas y ejecuta acciones no deseadas.

2. Tool Misuse

Uso indebido de tools válidas pero fuera de contexto.

3. Data Exfiltration

Extracción de datos vía tools.

4. Cost Explosion

Uso descontrolado de tokens o ejecución de operaciones costosas.

Insight clave

MCP convierte un problema de input en un problema de ejecución distribuida.

2. APIM como AI Gateway (control plane de IA)

Microsoft introduce explícitamente este concepto:

https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities

APIM deja de ser solo un API Gateway y pasa a ser:

un punto de control para modelos, agentes y MCP servers

3. Qué aporta realmente APIM en escenarios MCP

No es solo “poner un gateway delante”.

3.1 Control de acceso y autenticación

• integración con Entra ID
• OAuth para agentes
• control por consumidor

Sin esto:

• cualquiera puede invocar tools
• no hay trazabilidad real

3.3 Control de tokens (FinOps real)

En sistemas clásicos:

• controlas requests

En IA:

• controlas tokens

APIM permite:

• limitar tokens por usuario
• cortar ejecuciones antes de coste
• medir consumo real

https://learn.microsoft.com/en-us/azure/api-management/genai-gateway-capabilities

Punto clave

El control debe hacerse antes de que el prompt llegue al modelo.

3.4 Observabilidad semántica

No es logging HTTP.

Es:

• prompts
• completions
• tokens
• uso de tools

Esto permite:

• detectar anomalías
• auditar comportamiento
• entender decisiones

3.5 Routing inteligente y resiliencia

APIM permite:

• fallback entre modelos
• balanceo entre endpoints
• circuit breaker

Esto es crítico cuando dependes de LLMs.

3.6 Semantic caching

• cache basado en embeddings
• reducción de latencia
• reducción de coste

4. MCP + APIM: patrón correcto

5. Seguridad: cómo se mitiga realmente prompt injection

Error típico:

“el modelo lo gestiona”

No.

Estrategia correcta

1. Pre-filter en APIM

• bloquear inputs maliciosos

2. Validación estricta en MCP

• schema obligatorio
• sin inputs libres

3. Dominio protegido

• invariantes
• validaciones

4. Observabilidad

• detección de patrones anómalos

Regla de oro

Cada tool es potencialmente peligrosa.

6. Escalado de MCP en Azure (lo que diferencia a un arquitecto)

Aquí está el valor real.

6.1 Azure Container Apps (ACA)

Cuándo usarlo

• cargas variables
• arquitectura event-driven
• simplicidad operativa

Patrón

Claves

• stateless
• autoscaling por concurrencia
• cuidado con cold start

6.2 Azure Kubernetes Service (AKS)

Cuándo usarlo

• alta carga
• control fino
• escenarios enterprise

Patrón

Claves

• estado fuera (Redis, DB)
• affinity si hay sesiones
• configuración de streaming (SSE)
• HPA basado en métricas reales

Problema importante

MCP no es naturalmente stateless.

Tienes que diseñarlo como tal.

6.3 Azure MCP Server (managed)

https://learn.microsoft.com/en-us/azure/developer/azure-mcp-server/overview

Qué es

• servicio gestionado
• acceso a capacidades Azure vía MCP

Cuándo usarlo

• acelerar integraciones
• evitar infraestructura

Limitación

• no sustituye tu backend

7. Arquitectura de referencia completa

8. Decisión arquitectónica

Sin APIM:

• no hay control
• no hay gobierno
• no hay seguridad real

Con APIM:

• tienes control plane
• puedes escalar
• puedes operar

MCP define cómo ejecutar.
APIM define qué está permitido ejecutar.

Para terminar

En sistemas con IA:

• el modelo decide
• MCP ejecuta
• tu sistema responde

Pero alguien tiene que gobernar ese flujo.

En Azure, ese “alguien” es:

API Management como AI Gateway

Nota:

No expongas capacidades a un agente sin un control plane.
Porque en ese momento, ya no controlas el sistema tú.

Si revisas mis repositorios y artículos anteriores, verás que esta preocupación no es nueva.

• GitHub: https://github.com/jmfloreszazo
• Blog: https://jmfloreszazo.com

En particular, llevo tiempo trabajando y escribiendo sobre piezas que hoy encajan directamente en este problema:

• Reverse proxy y control de tráfico con YARP
• Exposición y gobierno de capacidades (antes APIs, ahora MCP)
• Evolución hacia modelos más dinámicos y agentic

Si conectas esos puntos, verás que el patrón es el mismo:

control del flujo, control de la ejecución y desacoplo de responsabilidades

Lo único que ha cambiado es el actor que está en medio.

Antes era un cliente.
Ahora es un modelo.

Y quizá ahora se entienda mejor por qué esta preocupación surgió en cuanto MCP empezó a hacerse mainstream: fue entonces cuando se hicieron evidentes, de forma bastante clara, muchas de sus carencias en escenarios reales.

Porque al final, el problema nunca ha sido la tecnología concreta.

El problema es no tener control sobre cómo se utiliza.

Durante muchos años en arquitectura de software hemos hablado de:

• CI/CD

• DevSecOps

• SBOM

• supply chain security

• SLSA

Pero hay una pregunta que durante demasiado tiempo ha quedado en segundo plano:

¿Cómo sabemos que el binario que estamos ejecutando es realmente el que generó nuestro pipeline?

No el código.

El binario final.

Ahí es donde entra Azure Artifact Signing.

El problema: confiar en binarios

Un pipeline moderno genera artefactos continuamente:

• ejecutables

• librerías

• paquetes

• contenedores

Ejemplo típico en .NET:

Esos archivos son artefactos de software.

Pero surge una cuestión crítica:

• ¿quién generó ese binario?

• ¿ha sido modificado?

• ¿proviene de un pipeline legítimo?

La respuesta clásica es code signing.

Una firma criptográfica que permite verificar que el binario:

1. proviene de una identidad concreta

2. no ha sido modificado

3. fue emitido por una autoridad confiable

Revisa este documento: https://learn.microsoft.com/en-us/azure/artifact-signing/how-to-signing-integrations

El problema del Code Signing tradicional

Históricamente firmar software implicaba:

• comprar certificados

• proteger claves privadas

• tokens hardware

• procesos manuales

• renovación de certificados

En muchos equipos esto acababa así:

La propuesta de Azure Artifact Signing

Azure Artifact Signing cambia el modelo:

la firma se convierte en un servicio gestionado en la nube

Las claves privadas se almacenan en HSM gestionados por Azure.

Los desarrolladores no gestionan certificados directamente.

El flujo se integra con el pipeline.

Arquitectura simplificada:

El resultado es un artefacto que contiene una identidad verificable.

Qué es exactamente un Artifact

Un artifact es el resultado de un build.

Ejemplos comunes:

Ejemplo real:

Ese ejecutable es el artifact que se firmará.

Ejemplo práctico en .NET

1. Crear la aplicación

Programa simple:

Compilamos:

Se genera:

Ese es el artifact.

Preparar Azure Artifact Signing

En Azure necesitamos tres elementos:

1. Artifact Signing Account

2. Identity validation

Ejemplo:

Este profile define el certificado usado para firmar.

Metadata de firma

Azure necesita un pequeño archivo JSON que describe qué perfil usar.

metadata.json

Firma del ejecutable

Usamos SignTool + Azure CodeSigning library.

Ejemplo:

Qué ocurre aquí:

1. SignTool calcula el hash del binario

2. Azure Artifact Signing firma ese hash

3. se adjunta una firma Authenticode al archivo

Resultado:

Verificar la firma

Podemos comprobarlo con:

Resultado esperado:

Windows ahora reconoce ese binario como software firmado.

Integración en CI/CD

Lo interesante aparece cuando esto se integra en el pipeline.

Ejemplo conceptual:

Ahora cada release tiene:

• identidad verificable

• timestamp

• provenance del pipeline

Más allá de los ejecutables

Artifact Signing no se limita a .exe.

También puede aplicarse a:

• paquetes NuGet

• drivers

• artefactos Windows

• otros binarios distribuidos

Esto empieza a ser crítico en modelos modernos de seguridad.

Supply Chain Security

Los ataques recientes han demostrado algo importante:

El objetivo de los atacantes ya no es solo comprometer servidores.

El objetivo es comprometer pipelines.

Ejemplos conocidos:

• SolarWinds

• ataques a repositorios npm

• supply chain malware

Si un atacante compromete el pipeline, el software generado puede parecer legítimo.

La firma añade una capa clave:

solo artefactos generados por identidades verificadas pueden ejecutarse

El detalle arquitectónico importante

Artifact Signing introduce algo que hasta ahora era difuso: la identidad del software.

No solo sabemos:

• qué código hay

• qué dependencias tiene

También sabemos:

• qué organización lo firmó

• qué pipeline lo generó

• cuándo se creó

Esto permite construir controles como:

• execution policies

• Kubernetes admission control

• software provenance

• runtime verification

Hacia pipelines de confianza

El modelo que está emergiendo en muchas organizaciones es este:

Cada paso añade confianza verificable.

Y para terminar

Durante años hemos tratado la seguridad del software como un problema de código.

Pero el verdadero punto crítico suele aparecer después del build.

La pregunta clave no es solo:

¿El código es seguro?

La pregunta real es:

¿Podemos confiar en el binario que estamos ejecutando?

Azure Artifact Signing intenta resolver precisamente eso.

No es simplemente una herramienta más.

Es un paso hacia algo más profundo:

software con identidad verificable.

Y en un mundo donde la supply chain del software es cada vez más compleja, eso empieza a ser absolutamente fundamental.