RUNTIME://OPERATIONAL · PROJECT: digitalrealism.toe · BUILD: 2026.05
CPU 12.4% · COOK 1.2ms · MADRID · UTC+1
ESTUDIO DE INGENIERÍA DE IA · MADRID · SECTORES REGULADOSAI ENGINEERING STUDIO · MADRID · REGULATED SECTORS

Ingeniería de IA
responsable, escalable
y medible.

La arquitectura sigue al caso, no al ciclo de hype. Diseño y despliego sistemas de IA local-first cuando los datos no pueden salir del edificio — y cloud responsable en GCP o Azure cuando la escala global lo justifica. Una arquitectura, dos planos, una sola disciplina de ingeniería. Architecture follows the case, not the hype cycle. I design and deploy local-first AI systems when data cannot leave the building — and responsible cloud on GCP or Azure when global scale justifies it. One architecture, two planes, a single engineering discipline.

Consultoría especializada en Gobierno de Datos y AI Compliance para despachos, clínicas y fintechs operando bajo RGPD, secreto profesional sectorial y AI Act UE. Arquitecturas local-first auditables y pipelines GCP/Azure que documentan su superficie regulatoria desde la primera línea de código. Specialised consultancy in Data Governance and AI Compliance for law firms, clinics and fintechs operating under GDPR, sectoral professional secrecy and the EU AI Act. Auditable local-first architectures and GCP/Azure pipelines that document their regulatory surface from the first line of code.

EmilianoVolpi.tox
typeFounder · AI Engineer
companyDigital Realism
locationMadrid · ES
roleData Engineer @ Accenture
stack_localLlama 4 Scout · Llama 3.3 70B · Qwen 3.5 · MLX
stack_cloudGemini · Vertex AI · Azure AI
stack_avTouchDesigner · Ableton · VCV
td_mcp● Claude controls TD natively
CH 01 · LOCAL_COMPUTE
128GB
RAM unificada para
modelos frontera locales
Unified memory for
local frontier models
CH 02 · CLOUD_CERTS
8×
certificaciones cloud activas
GCP · Azure · Databricks · Oracle
active cloud certifications
GCP · Azure · Databricks · Oracle
CH 03 · INFERENCE_FOOTPRINT
~30W
consumo medio inferencia local
vs racks GPU completos
average local inference draw
vs full GPU racks
CH 04 · MODELS_ORCHESTRATED
10×
modelos en producción
local + cloud híbrido
models in production
local + hybrid cloud

Siete operadores, una arquitectura coherente. Seven operators, one coherent architecture.

Cada propuesta combina ingeniería rigurosa con criterio práctico. La mejor solución es la que tu equipo entiende, mantiene y mide en resultados de negocio. Every proposal combines rigorous engineering with practical judgement. The best solution is the one your team understands, maintains, and measures in business outcomes.

[ 01 · INSIGNIA ]DAT · LOCAL

LegalVault.dat

Sistema RAG aislado por cliente para sectores regulados (legal, sanidad, finanzas). Indexa expedientes, jurisprudencia y plantillas internas; cada respuesta cita el documento fuente. Cumplimiento RGPD y secreto profesional by architecture, no por NDA. Despliegue local en Mac Mini servidor, M5 Max o, opcionalmente, en VPC privada GCP o Azure.Per-client isolated RAG system for regulated sectors (legal, healthcare, finance). Indexes case files, jurisprudence, and internal templates; every response cites its source document. GDPR and professional secrecy by architecture, not by NDA. Deploys on Mac Mini server, M5 Max, or optionally on GCP/Azure private VPC.

DEPLOYMENT: ON-PREMISE · OPCIONAL CLOUD VPC
AnythingLLMLlama 4 ScoutLlama 3.3 70BGLM-OCRChromaDBLlama Guard 3Vertex AI Search
[ 02 · A MEDIDA ]CHOP · HÍBRIDO

Agents.chop

Agentes IA type-safe en producción con memoria persistente, tests y observabilidad. Modelo agnóstico: ejecutan sobre Ollama local, Gemini, Claude o Vertex AI Agent Builder según el caso. Casos: clasificación documental, due diligence, atención cliente, automatización browser.Type-safe production AI agents with persistent memory, tests, and observability. Model-agnostic: run on local Ollama, Gemini, Claude, or Vertex AI Agent Builder per case. Use cases: document classification, due diligence, customer support, browser automation.

DEPLOYMENT: LOCAL · CLOUD · MIXED
Pydantic AILangGraphDeep AgentsBrowser UseMem0Langfuse
[ 03 · CLOUD ]TOP · GCP / AZURE

CloudEngine.top

Despliegues productivos serverless en Google Cloud y Azure con Gemini 2.5, Vertex AI Agent Builder, Cloud Run y Cloud Functions. La opción cuando el caso pide escala global o el cliente ya opera en cloud. Certificaciones activas: Professional Data Engineer + GenAI Leader + Cloud Digital Leader + Azure AI Fundamentals.Serverless production deployments on Google Cloud and Azure with Gemini 2.5, Vertex AI Agent Builder, Cloud Run, and Cloud Functions. The option when the case calls for global scale or the client already operates in cloud. Active credentials: Professional Data Engineer + GenAI Leader + Cloud Digital Leader + Azure AI Fundamentals.

DEPLOYMENT: GCP · AZURE · MULTI-CLOUD
Gemini 2.5Vertex AICloud RunCloud FunctionsBigQueryAzure AI Foundry
[ 04 · OPERACIONES ]COMP · SELF-HOSTED

Hyperflow.comp

Procesos manuales que dejan de serlo: extracción documental con OCR, integraciones cross-stack, automatizaciones web y workflows IA. Self-hosted por defecto (sin límites de ejecución ni costes por nodo); también deployable en cloud cuando se requiere alta disponibilidad gestionada. ROI medible en 90 días.Manual processes that stop being manual: document OCR extraction, cross-stack integrations, web automations, and AI workflows. Self-hosted by default (no execution limits or per-node costs); also deployable in cloud for managed high availability. Measurable ROI in 90 days.

DEPLOYMENT: DOCKER · KUBERNETES · CLOUD RUN
n8n self-hostedBrowser UsePlaywrightMCP serversComposio
[ 05 · VERTICAL ]SOP · VISION

Vision.sop

Computer Vision aplicada a problemas verticales: imagen biomédica (ultrasonido, radiología), object detection en imágenes satelitales, video analytics. Modelos custom (ResNet, U-Net, YOLO26) o LLMs multimodales (Gemini Vision, Claude Vision, Qwen3-VL). Experiencia académica con Premio al Mejor TFM por detección de sarcopenia mediante segmentación de ultrasonido.Computer Vision applied to vertical problems: biomedical imaging (ultrasound, radiology), object detection on satellite imagery, video analytics. Custom models (ResNet, U-Net, YOLO26) or multimodal LLMs (Gemini Vision, Claude Vision, Qwen3-VL). Academic background includes Best Thesis Award for sarcopenia detection via ultrasound segmentation.

DEPLOYMENT: ON-PREMISE · GCP VERTEX AI · AZURE
PyTorch MPSResNet-50YOLO26Gemini VisionOpenCVCoreML
[ 06 · INSTALACIONES AV ]TOX · LIVE

Stage.av

Instalaciones interactivas, VJ sets y experiencias audio-reactivas con TouchDesigner orquestado por Claude vía MCP server. AI Director (qwen3.5 cada 30s) ajusta parámetros en vivo. Voz sintética propia con VoiceBox + Qwen3-TTS. Para eventos corporativos, museos, marcas que buscan algo más allá del PowerPoint.Interactive installations, VJ sets, and audio-reactive experiences with TouchDesigner orchestrated by Claude via MCP server. AI Director (qwen3.5 every 30s) adjusts parameters live. Custom synthetic voice with VoiceBox + Qwen3-TTS. For corporate events, museums, and brands looking beyond PowerPoint.

DEPLOYMENT: ON-SITE · LIVE · NDI / SYPHON
TouchDesignerTD MCPAbleton LiveVoiceBoxQwen3-TTSRemotion
[ 07 · ADVISORY ]MAT · SESSIONS

AdvisoryBoard.mat

Workshops para equipos técnicos, auditoría de iniciativas IA existentes, hojas de ruta realistas para integrar IA sin caer en el hype. Sesiones presenciales en Madrid o remotas. Diseñado para CTOs, VP Engineering y comités de innovación.Workshops for technical teams, audits of existing AI initiatives, realistic roadmaps to integrate AI without hype. In-person in Madrid or remote sessions. Designed for CTOs, VP Engineering, and innovation committees.

Solicitar agenda →Request schedule →

Cuatro patrones probados en producción. Four patterns proven in production.

No vendo IA genérica: vendo arquitecturas con justificación técnica clara y métricas concretas. Estos cuatro patrones cubren el 90% de los casos reales de un cliente B2B en sectores regulados o intensivos en datos. Cada uno escala — del Mac Mini servidor en una clínica hasta GCP global multi-región — sin abandonar la disciplina de ingeniería. I don't sell generic AI: I sell architectures with clear technical justification and concrete metrics. These four patterns cover 90% of real cases for a B2B client in regulated or data-intensive sectors. Each one scales — from a Mac Mini server in a clinic to global multi-region GCP — without abandoning engineering discipline.

[ A · LOCAL-FIRST ]RGPD · Art. 9.2.h

Soberanía total. Cero red exterior.Total sovereignty. Zero external network.

Para casos donde el dato no puede salir del edificio: despachos, clínicas, defensa. Mac Mini M4/M5 servidor o M5 Max ejecutando modelos open-weight (Llama 4 Scout, Llama 3.3 70B). Cero llamadas a internet en path crítico. El hardware escala bajo pedido — desde un único Mac Mini M4 (1.500€, ~30W) para una clínica pequeña, hasta un cluster de 3-4 Mac Mini M5 Pro con Tailscale mesh para un despacho con 200 abogados. Misma arquitectura, mismo código, mismo audit trail.For cases where data cannot leave the building: law firms, clinics, defence. Mac Mini M4/M5 server or M5 Max running open-weight models (Llama 4 Scout, Llama 3.3 70B). Zero internet calls in critical path. Hardware scales on demand — from a single Mac Mini M4 (€1,500, ~30W) for a small clinic, to a cluster of 3-4 Mac Mini M5 Pro with Tailscale mesh for a 200-lawyer firm. Same architecture, same code, same audit trail.

DICOM/PDF → OCR (GLM) → Embeddings → ChromaDB ↓ Llama 4 Scout / Llama 3.3 70B (Ollama) ↓ Streamlit / Hono local · Visor en LAN (Llama Guard 3 → Langfuse audit trail)
Latencia p50~400ms Energía~30W Casos realesLegalVault · Hygeia Escala1 → N nodos · Tailscale mesh
[ B · HYBRID ]VPC · multi-region

Lo sensible local. Lo escalable cloud.Sensitive local. Scalable cloud.

Cuando el cliente quiere escalar (10 sedes, 200 usuarios simultáneos) sin comprometer aislamiento. Capa local en Mac Mini para PII; capa Vertex AI Agent Builder + Cloud Run para razonamiento sobre datos anonimizados. La frontera entre los dos planos queda documentada y auditable.When the client needs to scale (10 sites, 200 simultaneous users) without compromising isolation. Local Mac Mini layer for PII; Vertex AI Agent Builder + Cloud Run layer for reasoning over anonymised data. The boundary between the two planes is documented and auditable.

Edge gateway local (PII redaction) ↓ datos anonimizados VPC privado GCP (europe-southwest1) ↓ Vertex AI Agent Builder + Cloud Run + BigQuery ↓ Resultado regresa al gateway → cliente (zero raw PII en cloud · DPIA documentado)
Throughput~500 q/s Coste/100 usuarios~600€/mes Casos realesDeltaEngine pattern ComplianceRGPD + AI Act
[ C · CLOUD-NATIVE ]Serverless · GCP

RAG productivo en Cloud Run.Production RAG on Cloud Run.

Cuando el caso es público o con datos no sensibles: knowledge base interna pública, asistente de docs técnicos, soporte cliente con info abierta. Patrón de dos pasos — indexing offline + serving lightweight — que evita cold starts y mantiene coste sub-céntimo por query.For public or non-sensitive cases: public internal knowledge base, technical docs assistant, customer support over open data. Two-step pattern — offline indexing + lightweight serving — that avoids cold starts and keeps cost sub-cent per query.

[Step 1 · indexing offline] Cloud Storage → Cloud Run job → Embeddings → Vertex AI Search index [Step 2 · serving] Hono.js Edge → Cloud Run → Gemini 2.5 → Vertex AI Search retrieval → response (streaming SSE)
Cold start<500ms Coste / 1K queries$0.30 Casos realesAttentionRAG Escalaglobal · auto
[ D · EDGE-AI ]Cloudflare · sub-100ms

Inferencia en el edge global.Inference at the global edge.

Cuando latencia < 200ms es requisito (chat público, asistente de pre-venta, completion en formularios). Modelos pequeños (Phi-4, Gemma 2) corriendo en Workers AI o Cloudflare AI; fallback a Groq cuando el caso pide modelo más grande pero igual de rápido. Coste sub-céntimo por query, cero infraestructura que mantener.When latency < 200ms is a requirement (public chat, pre-sales assistant, form completion). Small models (Phi-4, Gemma 2) running on Workers AI or Cloudflare AI; Groq fallback when the case calls for a bigger but equally fast model. Sub-cent cost per query, zero infrastructure to maintain.

User → Cloudflare Worker (Hono.js) ↓ Workers AI (Llama 3.2 1B) — TTFT ~80ms ↓ (escalación condicional) Groq Cloud (Llama 4 Scout 800 t/s) ↓ Streaming SSE → user
TTFT p50~80ms Coste / 1K queries~$0.01 Casos realesdemo chat de este sitio Escalaglobal · 300+ POPs

Pregunta al agente.
Lo que ves es lo que el cliente experimenta.
Ask the agent.
What you see is what the client experiences.

Esta conversación se ejecuta sobre Llama 4 Scout / Llama 3.3 70B corriendo localmente en mi MacBook Pro M5 Max. Sin tokens cloud, sin latencia de red, sin datos cruzando internet del lado del cliente. Es exactamente la misma stack que tus usuarios usarían en producción sobre un Mac Mini servidor en tu sede.This conversation runs over Llama 4 Scout / Llama 3.3 70B locally on my MacBook Pro M5 Max. No cloud tokens, no network latency, no client data crossing the internet. It's exactly the same stack your users would use in production on a Mac Mini server at your office.

Sustituyendo el modelo por Gemini 2.5 Pro o Claude Opus, el mismo flujo se despliega en GCP/Vertex AI cuando el caso pide escala global.Swap the model for Gemini 2.5 Pro or Claude Opus and the same flow deploys on GCP/Vertex AI when the case calls for global scale.

Llama 4 ScoutLlama 3.3 70BChromaDBPydantic AIStreaming SSE
DigitalRealism.agent OPERATIONAL MODEL: Llama 4 Scout LOCAL

Lo que ya he construido. What I've already built.

Selección de proyectos open-source desde mi TFM premiado en Universidad Complutense hasta despliegues activos en Google Cloud. Cada caso enlaza a su repositorio cuando aplica. A selection of open-source projects, from my award-winning M.Sc. thesis at Universidad Complutense to active deployments on Google Cloud. Each case links to its repository where applicable.

[ HEALTHCARE · CV ]SOP
★ PREMIO MEJOR TFM · UCM 2024

Hygeia.cv

Detección y monitorización de sarcopenia mediante segmentación de imágenes de ultrasonido con redes neuronales profundas (ResNet-50 + U-Net). Aplicación clínica que asiste a profesionales sanitarios en diagnóstico y seguimiento. AUC 0.93 sobre holdout.Sarcopenia detection and monitoring via ultrasound image segmentation with deep neural networks (ResNet-50 + U-Net). Clinical application assisting healthcare professionals in diagnosis and follow-up. AUC 0.93 on holdout.

PyTorch MPS · ResNet-50 · U-Net · OpenCV
[ HEALTHCARE · LLM ]DAT

Hygeia2.rag

Asistente conversacional multi-dominio basado en LLaMA 3.1 (8B) con fine-tuning supervisado (LoRA + cuantización 4-bit) sobre dataset Q&A propio. Soporte para profesionales de biomedicina, IA y medicina deportiva.Multi-domain conversational assistant based on LLaMA 3.1 (8B) with supervised fine-tuning (LoRA + 4-bit quantisation) over a custom Q&A dataset. Supports biomedicine, AI, and sports medicine professionals.

LLaMA 3.1 · LoRA · PEFT · Streamlit
[ GCP · RAG ]TOP

AttentionRAG.cloud

Asistente RAG experto en el paper "Attention Is All You Need" desplegado en producción en Google Cloud. Arquitectura de dos pasos (indexing job + serving API) que resuelve el problema de cold start en serverless.RAG assistant specialised in "Attention Is All You Need" deployed in production on Google Cloud. Two-step architecture (indexing job + serving API) that solves the serverless cold-start problem.

Gemini 2.5 · LangChain · Cloud Run · GCS
[ GCP · AGENT ]CHOP

CloudSpec.ai

Agente multimodal que convierte sketches de pizarra y prompts en lenguaje natural en especificaciones de arquitectura cloud GCP, con pricing en tiempo real. Server-Driven UI vía protocolo A2UI.Multimodal agent that converts whiteboard sketches and natural-language prompts into GCP cloud architecture specs, with real-time pricing. Server-Driven UI via the A2UI protocol.

Vertex AI Gemini 2.0 · FastAPI · Cloud Run
[ ENERGY · CV ]SOP

SolarDetect.cv

Detección automática de paneles fotovoltaicos sobre imágenes satelitales de tejados (ResNet-34 fine-tuned sobre ImageNet). Aplicación: mapeo energético urbano y planificación de instalaciones renovables.Automatic photovoltaic panel detection on rooftop satellite imagery (ResNet-34 fine-tuned on ImageNet). Application: urban energy mapping and renewable installation planning.

ResNet-34 · Object Detection · fast.ai
[ NLP · DATA ]MAT

SentimentMusic.dat

Análisis de sentimiento sobre Billboard Hot 100 (29.503 canciones) cruzando audio features de Spotify (valence, energy, danceability, mode) para clasificar tracks en categorías emocionales mediante queries MongoDB.Sentiment analysis over Billboard Hot 100 (29,503 songs) cross-referencing Spotify audio features (valence, energy, danceability, mode) to classify tracks into emotional categories via MongoDB queries.

MongoDB · Aggregation Pipeline · Audio Features
[ ENTERPRISE · DATA ENGINEERING ]TOP
EXPERIENCIA ACTIVA · CLIENTE BAJO NDAACTIVE EXPERIENCE · NDA-PROTECTED CLIENT

DeltaEngine.gcp

Arquitectura de motores de procesamiento incremental near-real-time (micro-batching) sobre Google Cloud Platform en sectores de banca y energía. Integración CDC desde NoSQL hacia BigQuery, patrones HOT/COLD con idempotencia estricta, manejo de race conditions y exclusividad de versiones para garantizar Single-Version of Truth en ingesta de alta concurrencia. Trabajo desarrollado en mi rol como Data Engineer en Accenture: detalles del cliente y métricas específicas son confidenciales por NDA, pero el patrón arquitectónico es transferible a Digital Realism para clientes con necesidades equivalentes de pipelines críticos.Architecture of near-real-time incremental processing engines (micro-batching) on Google Cloud Platform in banking and energy sectors. CDC integration from NoSQL into BigQuery, HOT/COLD patterns with strict idempotency, race-condition handling, and version exclusivity to guarantee Single-Version of Truth in high-concurrency ingestion. Developed in my role as Data Engineer at Accenture: client specifics and metrics are NDA-protected, but the architectural pattern transfers to Digital Realism for clients with equivalent critical-pipeline needs.

BigQuery · Cloud Functions Gen2 · Pub/Sub · Datastream · Cloud Scheduler · Terraform · Azure DevOps · FinOps

Ingeniería certificada. Datos bajo control.Ingeniería certificada. Gobierno absoluto. Certified engineering. Data under control.Certified engineering. Absolute governance.

La innovación técnica sin rigor regulatorio es deuda escondida. Cada arquitectura que entregamos viene respaldada por certificaciones activas en GCP, Azure y Databricks, y por experiencia operando en sectores donde el dato es activo crítico.Cumplimiento normativo en cada capa del ciclo de vida del dato. Pipelines auditables, RGPD by design (no como parche posterior), arquitecturas alineadas con el AI Act UE y el secreto profesional sectorial. Credenciales activas en las tres nubes y experiencia académica revisada por pares. Technical innovation without regulatory rigour is hidden debt. Every architecture we ship is backed by active certifications in GCP, Azure and Databricks, and by hands-on experience in sectors where data is a critical asset.Regulatory compliance at every layer of the data lifecycle. Auditable pipelines, GDPR by design (not bolted on), architectures aligned with the EU AI Act and sectoral professional secrecy. Active credentials across the three major clouds and peer-reviewed academic experience.

Google CloudACTIVE

Professional Data Engineer

SEP 2023 — SEP 2027RECERTIFIED

Diseño de sistemas de procesamiento de datos a escala en GCP: BigQuery, Dataflow, Pub/Sub, Cloud Run. Foco en pipelines fiables, seguros y normativamente compliant.

Google CloudACTIVE

Generative AI Leader

NOV 2025 — NOV 2028STRATEGIC

Dirección estratégica de iniciativas GenAI corporativas. Evaluación de casos de uso, mitigación de riesgos (alucinaciones, sesgo, fuga de datos) y diseño para ROI medible.

Google CloudACTIVE

Cloud Digital Leader

OCT 2025 — OCT 2028FOUNDATIONAL

Visión transversal del ecosistema Google Cloud: mapeo de necesidades de negocio a productos cloud, casos de adopción y estrategia de modernización empresarial.

Accenture × Stanford HAIACTIVE

Reinvention with Agentic AI

DEC 2025EXECUTIVE

Programa ejecutivo en agentic AI con material licenciado de Stanford HAI. Frameworks de adopción corporativa, casos productivos y reinvención de procesos con autonomía controlada.

MicrosoftACTIVE

Azure AI Fundamentals

MAR 2026AI-900

Cargas de ML e IA sobre Azure: ML Studio, Cognitive Services, Azure AI Foundry. Ideal para clientes con stack Microsoft establecido o requisitos de soberanía europea Azure.

DatabricksACTIVE

Databricks Fundamentals

MAY 2025ACCREDITED

Lakehouse, Delta Lake, Unity Catalog y MLflow. Arquitecturas RAG productivas y vector search dentro del ecosistema Data Intelligence Platform.

OracleACTIVE

OCI Foundations Associate

SEP 2024OCI 2024

Fundamentos de Oracle Cloud Infrastructure: cómputo, almacenamiento, redes y seguridad. Cobertura para clientes regulados con stack Oracle establecido.

Coursera × StanfordVERIFIED

AI for Medicine

OCT 20243-COURSE SPECIALIZATION

Especialización Stanford de tres cursos en aplicación de ML a problemas médicos: diagnóstico (radiografías, resonancias), pronóstico clínico y estimación del efecto de tratamientos.

Premio al Mejor TFM · Universidad Complutense de Madrid

Trabajo de Fin de Máster premiado en Data Science, Big Data & Business Analytics (UCM 2024) por Hygeia — sistema de detección de sarcopenia mediante segmentación de imágenes de ultrasonido con redes neuronales profundas. Calificación 9,3/10 · Promoción 2023-2024 presencial.

NTIC MASTER × UCM
FEB · 2025
  Todas las credenciales son verificables públicamente vía Credly · Google Cloud · Microsoft Learn. Copias originales en PDF disponibles bajo petición a emilianovolpi@digitalrealism.io.

Soberanía de datos por diseño. Data Sovereignty & Regulatory Posture.

Tus datos viven donde tú decides, no donde es cómodo para el proveedor de turno. Cuando el caso lo permite, el cómputo se queda en tu edificio. Cuando exige escala, lo desplegamos en cloud privada con la misma calidad de ingeniería. Diseñamos para clientes en sectores regulados (legal, sanidad, finanzas) donde el dato no puede abandonar la jurisdicción del cliente. Cada despliegue documenta su superficie de cumplimiento: RGPD, secreto profesional sectorial, AI Act UE, ISO 27001 cuando aplica.

[ p01 ] DATA RESIDENCY

Despliegues on-premise o en VPC privada con regiones controladas. Trazabilidad documental de cada copia y derivado del dato fuente.

[ p02 ] AUDIT TRAIL

Langfuse self-hosted en infraestructura del cliente. Cada inferencia (prompt + respuesta + metadatos) queda registrada y es auditable a perpetuidad.

[ p03 ] AI SAFETY GATE

Llama Guard 3 actuando como filtro previo a cualquier salida del agente. PII detection, toxicity scoring y bloqueo configurable por casos de uso.

EmilianoVolpi.portrait
Emiliano Volpi — Founder & Principal Engineer, Digital Realism
● CAPTURED · MADRID 2026 v2026.05

Una agencia es una persona con un criterio.Empresa unipersonal con acreditaciones corporativas verificables y experiencia enterprise activa. An agency is one person with judgement.A solo studio with verifiable corporate credentials and active enterprise experience.

Soy Emiliano Volpi. Diseño y construyo sistemas de IA en producción desde 2024, con un foco editorial en lo que sirve realmente al cliente: arquitecturas que duran, que se auditan, y que respetan el dato como activo crítico.

Trabajo de día como Data Engineer en proyectos enterprise de banca y energía sobre Google Cloud Platform — pipelines críticos, FinOps disciplinado, observabilidad de datalakes Tier-1 con BigQuery, Cloud Functions, Datastream y Terraform. Esa exposición a la producción a escala es la que llevo a Digital Realism: un estudio para los despachos y clínicas que el mercado generalista ignora pero que merecen el mismo nivel de ingeniería.

Antes: Máster en Data Science con Premio al Mejor TFM (UCM 2024), computer vision biomédica para detección de sarcopenia, pre-sales cloud en Telefónica Tech. Y, anteriormente, otra vida en humanidades y crítica cultural — Máster en Teoría y Crítica de la Cultura (Carlos III).

Founder & Principal Engineer en Digital Realism. Actualmente Data Engineer & Governance Analyst en Accenture (Madrid) operando proyectos enterprise sobre Google Cloud Platform en sectores de banca y energía: arquitectura de pipelines críticos, optimización FinOps de BigQuery, ingesta CDC desde NoSQL, despliegue con Terraform y CI/CD en Azure DevOps.

Acreditaciones activas en las tres principales nubes (GCP × 3, Azure AI Fundamentals, Oracle OCI) más Databricks y formación ejecutiva certificada en Agentic AI por Accenture × Stanford HAI. Calificación 9,3/10 en Máster UCM con Premio al Mejor TFM (2024).

La misma disciplina que se aplica en proyectos enterprise — observabilidad, auditabilidad, gobernanza del dato — la traigo a Digital Realism para clientes de sectores regulados que requieren la misma calidad sin la sobrecarga de las consultoras grandes.

I'm Emiliano Volpi. I've been designing and building production AI systems since 2024, with an editorial focus on what actually serves the client: architectures that last, that audit cleanly, and that treat data as a critical asset.

By day I work as a Data Engineer on enterprise projects in banking and energy on Google Cloud Platform — critical pipelines, disciplined FinOps, Tier-1 datalake observability with BigQuery, Cloud Functions, Datastream and Terraform. That same exposure to production at scale is what I bring to Digital Realism: a studio for the law firms and clinics the generalist market ignores but who deserve the same engineering caliber.

Before that: M.Sc. in Data Science with the Best Thesis Award (UCM 2024), biomedical computer vision for sarcopenia detection, cloud pre-sales at Telefónica Tech. And, previously, humanities and cultural critique — M.A. in Cultural Theory (Carlos III).

Founder & Principal Engineer at Digital Realism. Currently Data Engineer & Governance Analyst at Accenture (Madrid) operating enterprise projects on Google Cloud Platform in banking and energy sectors: critical pipeline architecture, BigQuery FinOps optimization, CDC ingestion from NoSQL, Terraform deployment, and CI/CD on Azure DevOps.

Active credentials across the three major clouds (GCP × 3, Azure AI Fundamentals, Oracle OCI) plus Databricks and executive certification in Agentic AI from Accenture × Stanford HAI. M.Sc. UCM (9.3/10) with Best Thesis Award (2024).

The same discipline applied to enterprise projects — observability, auditability, data governance — is what I bring to Digital Realism for clients in regulated sectors who require that quality without the overhead of large consultancies.

FounderEmiliano Luis Volpi
Día actualDay roleData Engineer @ Accenture · Madrid
EstudioStudioDigital Realism · founder
BaseBased inMadrid · ES · UTC+1
Línea directaDirect lineemilianovolpi@digitalrealism.io

Principios del Realismo Digital. Principles of Digital Realism.

«Realismo digital: lo que pasa de la ficción a la realidad cuando se mide. La arquitectura adecuada no se imagina — se despliega, se audita, se mantiene.» "Digital realism: what crosses from fiction to reality when it gets measured. The right architecture is not imagined — it is deployed, audited, maintained."

— PRINCIPIO RECTOR · v2026.05 — GUIDING PRINCIPLE · v2026.05

Cada decisión técnica deja huella — energética, regulatoria, contractual. Estos seis principios articulan los criterios de ingeniería del estudio: no son un manifiesto político, son las restricciones reales con las que se firma cada arquitectura. Las lecturas que los acompañan no son ornamento — son el linaje crítico desde el que se piensa.Cada decisión técnica deja huella — energética, regulatoria, contractual. Estos seis principios articulan los criterios de ingeniería del estudio, formulados como restricciones operacionales medibles antes que como manifiesto. Cada uno se traduce en cláusulas concretas de auditoría y entregables verificables. Every technical decision leaves a trace — energetic, regulatory, contractual. These six principles articulate the studio's engineering criteria: not a political manifesto but the actual constraints under which every architecture is signed. The readings cited are not ornament — they are the critical lineage from which we think.Every technical decision leaves a trace — energetic, regulatory, contractual. These six principles articulate the studio's engineering criteria, formulated as measurable operational constraints rather than manifesto. Each one translates into concrete audit clauses and verifiable deliverables.

[ p01 · ARCHITECTURE FIRST ]

La arquitectura sigue al caso, no al ciclo de hype.Architecture follows the case, not the hype cycle.

Cuando entra un proyecto, la primera pregunta no es "qué modelo usamos" sino "qué constraint del cliente define la solución". Local-first cuando el dato no puede salir; cloud cuando la escala lo justifica; edge cuando la latencia es el requisito. Cada elección queda validada por métricas concretas — TTFT, coste/query, footprint energético — no por la narrativa que esté de moda. El criterio se firma; la moda no se firma.When a project comes in, the first question is not "which model" but "which client constraint defines the solution". Local-first when data cannot leave; cloud when scale justifies; edge when latency is the requirement. Every choice is validated by concrete metrics — TTFT, cost/query, energy footprint — not by whatever narrative is trending. Criteria get signed; trends don't.

K. BeckD. ParnasM. Fisher
[ p02 · DATA AS LIABILITY ]

El dato es responsabilidad antes que activo.Data is liability before asset.

Cumplir la norma es el suelo, no el techo. Cada arquitectura está diseñada para que el control efectivo del dato — quién accede, dónde reside, cómo se borra — quede en manos de quien lo genera, no del proveedor de turno. Privacidad, transparencia y portabilidad son requisitos de diseño grabados en la infraestructura, no checkboxes añadidos en auditoría posterior. El dato del cliente vuelve al cliente cuando me voy.Compliance is the floor, not the ceiling. Every architecture is designed so that effective control of the data — who accesses, where it resides, how it gets deleted — stays with whoever generates it, not with the vendor of the moment. Privacy, transparency, and portability are design requirements baked into the infrastructure, not checkboxes bolted on after audit. Client data returns to the client when I leave.

É. SadinC. Rikap
[ p03 · ENERGY IS ENGINEERING ]

Cada vatio cuenta — y se mide.Every watt counts — and gets measured.

Un Mac Mini a 30W ejecutando Llama 3.3 70B no es una opción ideológica: es una decisión cuantificable. ~30W locales contra ~4kW de un cluster GPU equivalente significa 130× menos consumo, menor coste operativo, menos huella térmica, más vida útil del hardware. La eficiencia energética no es un valor añadido — es una métrica de calidad alineada con la latencia y la precisión. El ecosistema en el que opera el sistema es parte del sistema.A Mac Mini at 30W running Llama 3.3 70B is not an ideological choice: it's a quantifiable decision. ~30W locally vs ~4kW for an equivalent GPU cluster means 130× less power draw, lower operational cost, smaller thermal footprint, longer hardware lifecycle. Energy efficiency is not an added value — it's a quality metric on par with latency and accuracy. The ecosystem the system runs in is part of the system.

Yuk HuiCosmotechnicsJevons
[ p04 · MEASURABLE OUTCOMES ]

Si no se mide en resultados de negocio, no se entrega.If it's not measured in business outcomes, it doesn't ship.

Cada despliegue lleva un dashboard concreto: horas/semana liberadas, % consultas resueltas sin escalar, tiempo medio de redacción, queries/día, coste por inferencia. Sin esos KPIs el proyecto es un experimento, no una solución. Langfuse self-hosted + Metabase mantienen la auditoría dentro del cliente, no en SaaS externo donde la observabilidad se vuelve dependencia. Lo que no se mide se pierde; lo que se mide se defiende.Every deployment ships with a concrete dashboard: hours/week freed, % of queries resolved without escalation, mean drafting time, queries/day, cost per inference. Without those KPIs the project is an experiment, not a solution. Self-hosted Langfuse + Metabase keep the audit inside the client, not in external SaaS where observability becomes dependency. What isn't measured gets lost; what gets measured can be defended.

F. BerardiM. FisherCapitalist Realism
[ p05 · MAINTAINABLE BY YOUR TEAM ]

La mejor arquitectura es la que tu equipo entiende cuando me voy.The best architecture is the one your team understands when I'm gone.

Open source por convicción operativa (Llama, Ollama, AnythingLLM, n8n, Hono, ChromaDB, Pydantic AI): sin lock-in propietario que el cliente herede sin haberlo pedido. Documentación viva en el repo, IaC versionado con Terraform, runbooks que un junior pueda seguir sin contexto previo. La continuidad operativa después del consultor no es un favor — es parte del entregable firmado. Si el equipo no puede mantenerlo, no lo entrego.Open source by operational conviction (Llama, Ollama, AnythingLLM, n8n, Hono, ChromaDB, Pydantic AI): no proprietary lock-in inherited without consent. Living documentation in the repo, versioned IaC with Terraform, runbooks a junior can follow without prior context. Operational continuity after the consultant leaves is not a favour — it's part of the signed deliverable. If the team can't maintain it, I don't ship it.

Z. BaumanLiquidityD. Graeber
[ p06 · SHIP, ITERATE, MEASURE ]

Ingeniería como disciplina, no como espectáculo.Engineering as discipline, not spectacle.

Prototipo rápido sobre datos reales del cliente, validación con métricas en producción, iteración basada en lo que el sistema realmente hace — no en lo que el slide dice que hace. Sin sobre-ingeniería, sin mock dashboards, sin demos que no llegarán nunca a producción. Cada línea de código es una promesa al equipo del cliente: que mañana seguirá funcionando y que sabrán por qué. El sistema es lo que el sistema hace, no lo que el deck promete.Rapid prototype on real client data, validation with production metrics, iteration based on what the system actually does — not what the slide says it does. No over-engineering, no mock dashboards, no demos that never reach production. Every line of code is a promise to the client team: that it will still work tomorrow and that they'll know why. The system is what the system does, not what the deck promises.

K. BeckTest-FirstWorse is Better
«La ingeniería responsable no es la que evita riesgos, sino la que los nombra y los mide. Cada arquitectura que entrego documenta sus límites con la misma claridad con la que documenta sus capacidades. La frontera entre lo que el sistema hace y lo que no debe hacer es parte del diseño — no una nota al pie de la auditoría posterior.» "Responsible engineering is not engineering that avoids risk; it is engineering that names risk and measures it. Every architecture I ship documents its limits with the same clarity it documents its capabilities. The boundary between what the system does and what it must not do is part of the design — not a footnote to the audit that follows." — DIGITAL REALISM · ENGINEERING DOCTRINE
«El cumplimiento normativo no se añade al final del proyecto: se firma en la primera línea de código. Cada arquitectura entregada por Digital Realism documenta su superficie regulatoria — RGPD Art. 9.2.h, AI Act EU, secreto profesional sectorial — con la misma trazabilidad con la que documenta su rendimiento técnico.» "Regulatory compliance is not bolted on at the end of the project: it's signed into the first line of code. Every architecture delivered by Digital Realism documents its regulatory surface — GDPR Art. 9.2.h, EU AI Act, sectoral professional secrecy — with the same traceability it documents its technical performance." — DIGITAL REALISM · COMPLIANCE DOCTRINE
Versión extendida de estos seis principios — con su linaje crítico completo, citas largas y autores referenciados (Fisher, Sadin, Berardi, Hui, Rikap, Bauman, Graeber, Jevons). Lo que aquí cabe en seis tarjetas, allí cabe en seis ensayos: Extended version of these six principles — with their full critical lineage, long-form citations and referenced authors (Fisher, Sadin, Berardi, Hui, Rikap, Bauman, Graeber, Jevons). What fits here in six cards, fits there in six essays:

El estudio que ejecuta todo lo anterior. The studio that runs all of the above.

El setup real desde el que se diseñan, prueban y entregan los proyectos. M5 Max 128GB ejecutando modelos frontera localmente, hardware musical conectado por audio-rate, TouchDesigner controlado por Claude vía MCP. Mismo equipo que sale a una instalación cliente. Roadmap incluye Mac Mini servidor 24/7 para Q3 2026. The actual setup where projects are designed, tested and shipped. An M5 Max with 128GB running frontier models locally, musical hardware at audio-rate, TouchDesigner controlled by Claude via MCP. The same rig that goes out to a client installation. Roadmap includes a 24/7 Mac Mini server for Q3 2026.

[ 01 ]SIGNAL INPUTS · MIDI + AUDIO RATE
NORDSSYNTH
Nord Stage 2
76 keys · piano · organ · synth
NORDSSYNTH
Nord Lead A1
analog modeling · 4-part
YAMAHAFM
Reface DX
FM 8-op · 37 keys
ROLANDRHYTHM
TR-8
drum machine · USB audio
[ 02 ]INTERFACE + DAW · SIGNAL ROUTING
MOTUDAC
M6 Interface
ESS Sabre32 · 6in/4out · USB-C
NOVATIONCTRL
Launchkey MK3 49
MIDI controller · DAW integration
ABLETONDAW
Live 12 Suite
48k · 128 smp · Max for Live
VCVMODULAR
VCV Rack 2
virtual eurorack · ARM64 native
[ 03 ]BRAIN · COMPUTE + AI ORCHESTRATION
APPLECOMPUTE
M5 Max
128GB unified · 4TB SSD · 614GB/s
OLLAMALLMs
10× modelos locales
Llama 4 Scout · Llama 3.3 70B · Qwen 3.5
CLAUDEAGENT
Claude Code + MCP
Opus 4.7 · Sonnet 4.6 · Haiku 4.5
VOICEBOXTTS
Qwen3-TTS Studio
voice cloning · 23 idiomas
[ 04 ]VISUAL OUTPUT · TOUCHDESIGNER + AI DIRECTOR
DERIVATIVEVISUAL
TouchDesigner
controlado por Claude vía MCP server
OLLAMADIRECTOR
qwen3.5 AI Director
ajusta parámetros TD cada 30s
EXISTENTIALPIPE
BlackHole 16ch
Ableton → TouchDesigner audio
SYPHON / NDISHOW
Projector + OBS
live · streaming · Resolume
[ 05 ]FUTURE FLEET · ROADMAP 2026—2027
APPLE · Q3 2026SERVER
Mac Mini M5 Pro
48GB · 24/7 · always-on inference
APPLE · Q4 2026RESEARCH
Mac Studio M5 Ultra
256GB · fine-tune · large models
SYNOLOGY · 2027STORAGE
NAS DS923+ ZFS
backup · audit logs · Restic
TAILSCALEMESH
Private overlay
m5max + minisrv + studio + nas
SECURITY:FileVault · Llama Guard 3 · Tailscale · 1Password (4 vaults) UPTIME:24/7 · daily backup cifrado CARBON:~30W avg · vs ~4kW datacenter equivalente

Lo que realmente usamos en producción. What we actually run in production.

No es marketing. Cada operador de esta tabla se ejecuta hoy en mi MacBook Pro M5 Max o en infraestructura cloud de clientes activos.No marketing. Every operator on this table runs today on my M5 Max or on active client cloud infrastructure.

OPS COUNT: 17
LOCAL CLOUD EDGE
LLMs
Llama 4 Scout · Llama 3.3 70B · Qwen 3.5 · DeepSeek V4 Flash · Claude Opus 4.7 · Sonnet 4.6 · Gemini 2.5 Pro/Flash
LOCAL+CLOUD
Agentes
Pydantic AI · LangGraph · Deep Agents · Browser Use · n8n · Claude Code · Vertex AI Agent Builder
LOCAL+CLOUD
Memoria · Embeddings
Mem0 (cross-agent) · Claude-Mem (session) · TEI · ChromaDB · sentence-transformers
LOCAL+CLOUD
RAG · OCR
AnythingLLM · ChromaDB · GLM-OCR (0.9B, #1 benchmark) · LangExtract · Vertex AI Search
LOCAL+CLOUD
Vision · ML
PyTorch MPS · MLX · ResNet-50 · U-Net · YOLO26 · Gemini Vision · Claude Vision · CoreML
LOCAL+CLOUD
Web
HTML · CSS · Vanilla JS · Astro (Q3 2026) · Hono · Cloudflare Pages · Tailwind v4
EDGE
GCP · AI
Gemini 2.5 Pro/Flash · Vertex AI Agent Builder · Vertex AI Studio · Model Garden · AutoML
CLOUD
GCP · Compute
Cloud Run · Cloud Functions Gen2 · GKE · Cloud Build · Artifact Registry
CLOUD
GCP · Data
BigQuery · Dataflow · Pub/Sub · Cloud Storage · Dataform · Looker · Datastream (CDC) · Cloud Scheduler
CLOUD
FinOps · BigQuery
Query optimization · execution plan analysis · partition pruning · semi-join reduction · SLA monitoring · ghost data detection
CLOUD
Azure
Databricks · Azure AI Foundry · Azure OpenAI · Functions · Cosmos DB · Azure DevOps (CI/CD)
CLOUD
Edge
Cloudflare Workers · Workers AI · Vercel Edge · Tailscale · Hono on Edge · Groq
EDGE
AV · Visual
TouchDesigner · TD MCP server (Claude controla TD) · Resolume · Spline 3D · Remotion
LOCAL
AV · Audio
Ableton Live 12 · Max for Live · VCV Rack 2 · MOTU M6 · Nord Stage 2 · Reface DX · TR-8 · BlackHole 16ch
LOCAL
AV · Voice
VoiceBox (Qwen3-TTS, 23 idiomas) · Kokoro 82M · MLX-Whisper v3 · MusicGen 3.3B
LOCAL
Infra · IaC · Security
Terraform · Azure DevOps · Docker · OrbStack · Tailscale · 1Password · FileVault · Llama Guard 3 · CI/CD pipelines
LOCAL+CLOUD
Observabilidad
Langfuse self-hosted · Logfire · Postgres · Redis · Metabase
LOCAL

Notas técnicas y reflexiones de campo. Technical notes and field reflections.

Aprendizajes prácticos de despliegues reales. Sin marketing, sin hype. Lo que funciona, lo que no, y qué probar la próxima vez. Practical learnings from real deployments. No marketing, no hype. What works, what doesn't, and what to try next.

Por qué la sarcopenia en deportistas pide computer vision local-first. Why sarcopenia in athletes demands local-first computer vision.

Notas sobre el TFM premiado en la Universidad Complutense (Master en Data Science, Big Data & Business Analytics, 2024) realizado en colaboración con Dawako Med Tech, Valencia. Por qué los datos de ultrasonido no pueden cruzar internet bajo Art. 9.2.h RGPD, qué pipeline real funcionó sobre el dataset Rectus Femoris, y cómo replantearía el despliegue hoy si el caso entrara como cliente en Digital Realism. Notes on the award-winning thesis at Universidad Complutense (M.Sc. Data Science, Big Data & Business Analytics, 2024), developed with Dawako Med Tech, Valencia. Why ultrasound data cannot cross the internet under GDPR Art. 9.2.h, what pipeline actually worked on the Rectus Femoris dataset, and how I would re-frame deployment today if the case came in as a Digital Realism client.

Leer artículo Read article Cerrar artículo Close article

Este texto comenta la arquitectura y el caso de uso de mi TFM en el Master en Data Science, Big Data & Business Analytics de la Universidad Complutense de Madrid (promoción 2023-2024), desarrollado en colaboración con Dawako Med Tech (Valencia) bajo acuerdo de protección de datos. El dataset, el código fuente y los pesos entrenados no son públicos — y no lo serán. Pero el problema clínico, la lógica arquitectónica y las decisiones de despliegue sí pueden compartirse, y son lo realmente transferible a otros clientes en sectores regulados.

Por qué la sarcopenia, por qué deportistas

La sarcopenia — pérdida progresiva de masa y función muscular — dejó hace tiempo de ser un asunto exclusivo de la geriatría. En medicina deportiva de élite es un marcador temprano de sobreentrenamiento, recuperación incompleta o lesión inminente. El recto femoral es la estructura más estudiada para estimarla porque es accesible, repetible y permite medir área transversal y arquitectura fascicular con ecografía portátil.

Dawako Med Tech ya tenía un dataset clínico considerable adquirido con un ecógrafo Esaote MyLab Sigma y una aplicación propia (DAWAKO App) para que profesionales sanitarios generaran máscaras de segmentación manuales — imágenes binarias PNG donde la región muscular vale 255 y el fondo 0, sin huecos internos. El TFM consistió en construir un sistema de visión por computador capaz de aprender esa segmentación profesional y devolver áreas y clasificaciones automáticas, asistiendo al clínico, no sustituyéndolo.

El dato que no puede irse del edificio

El input clínico es ultrasonido del recto femoral. En Europa, ese dato cae con claridad bajo el Art. 9 del RGPD: categoría especial de datos relativos a la salud. La excepción 9.2.h permite tratamiento con fines de medicina preventiva y diagnóstico, pero exige garantías técnicas y organizativas reforzadas. Traducción operativa: el dato no se sube a una API SaaS estadounidense para que un endpoint te devuelva un mapa de segmentación.

No es ideología. Es ingeniería de cumplimiento. Cualquier acuerdo entre una empresa MedTech y un investigador académico — incluso con fines exclusivamente formativos como un TFM — tiene que documentar la jurisdicción del dato desde la primera línea. El NDA con Dawako lo dejó claro: el dataset no se distribuye, el código no se publica, y cualquier divulgación de resultados pasa por revisión.

El pipeline que realmente funcionó

El stack del TFM fue Python sobre TensorFlow 2.15-2.17 con interfaz Keras 2.15, ejecutado en Google Colab con acceso a GPUs gratuitas para iteración rápida. Para producción local final se empaquetó en una app interactiva de Streamlit que carga imagen ecográfica y devuelve la segmentación predicha sobre el navegador. El procesamiento de imágenes se apoyó en OpenCV, NumPy y Scikit-learn — toolkit clásico, sin frameworks exóticos, deliberadamente mantenible.

Esaote MyLab Sigma (ultrasonido RF probe)
                  ↓
          DAWAKO App (máscaras manuales · binarias 255/0)
                  ↓
          Pre-procesamiento OpenCV:
             ├─ pipeline A: Gaussian Blur + CLAHE (256×256)
             └─ pipeline B: Median + CLAHE + Wavelet (512×512)
                  ↓
          Modelos TensorFlow/Keras (Colab GPU):
             ├─ U-Net para segmentación
             └─ ResNet para clasificación binaria sarcopenia
                  ↓
          Métricas: Dice Coefficient + Balanced Multi-Class Accuracy
                  ↓
          Streamlit local · médico revisa antes de validar

La elección de pipeline de pre-procesamiento fue lo más interesante del trabajo. Las imágenes de ultrasonido tienen bajo contraste y ruido speckle característico, así que probamos cinco técnicas (CLAHE, Histogram Equalization global, Gaussian Blur, Bilateral Filter, Median Filter, transformada Wavelet) y dos combinaciones ganadoras quedaron documentadas:

Combinación A · 256×256. Gaussian Blur + CLAHE. El desenfoque gaussiano suaviza el ruido speckle; CLAHE realza contraste localmente con clip limit controlado para no amplificar ruido. Rápido, robusto, buen baseline.

Combinación B · 512×512. Median Filter → CLAHE → Wavelet. El filtro mediano reduce ruido salt-and-pepper preservando bordes (crítico en límites de tejido); CLAHE mejora contraste sobre la imagen ya limpia; finalmente la transformada Wavelet conserva sólo los componentes de baja frecuencia (LL) y descarta el ruido de alta frecuencia. Más caro de computar, pero el modelo aprendía bordes fasciculares con mucha más nitidez.

«Las métricas que importan en imagen biomédica no son las del paper. Son las que el clínico acepta cuando ve la salida superpuesta sobre la imagen que conoce.»

Las métricas que importaban

Dos métricas guiaron la evaluación, elegidas para los dos cabezales del modelo:

Dice Coefficient para la cabeza de segmentación — mide el solapamiento entre máscara predicha y máscara de referencia (la generada por profesionales con la DAWAKO App). Es el estándar en imagen médica porque penaliza tanto falsos positivos como negativos en la región de interés.

Balanced Multi-Class Accuracy para el clasificador. Es la métrica honesta cuando hay desequilibrio de clases (más imágenes de músculo sano que sarcopénico): calcula precisión por clase y promedia, así el modelo no puede ganar score prediciendo siempre la clase mayoritaria. Esa decisión metodológica fue la que defendí en el tribunal y la que considero más generalizable: cualquiera que reporte accuracy simple sobre un dataset clínico desbalanceado está vendiendo humo.

Cómo replantearía el despliegue hoy

El TFM se entregó en 2024. Si Dawako, o un cliente equivalente — clínica deportiva, federación, hospital deportivo de élite — entrara hoy en Digital Realism con el mismo problema, no replicaría exactamente el stack del TFM. Hay tres cosas que cambiaría, no porque el TFM fuera incorrecto, sino porque el ecosistema avanzó y porque las exigencias de un despliegue productivo son más altas que las de un trabajo académico.

Uno · adiós Colab, hola Apple Silicon nativo. Colab fue ideal para iterar rápido durante la tesis, pero como dependencia de producción es frágil: cuotas variables, sesiones que mueren, dato que viaja. PyTorch MPS (Metal Performance Shaders) cerró su brecha de soporte con CUDA durante 2024-2025 y hoy ejecuta U-Net y ResNet sobre Apple Silicon sin fricción. Un Mac Mini M4 (24-32 GB de memoria unificada) cubre inferencia productiva para una clínica con 30-60 ecografías/día con latencia sub-segundo y consumo medio ~30W. Mismo modelo, sin Colab, sin cloud, dato 100% en sede.

Dos · audit trail incorporado al producto. El TFM no necesitaba traceabilidad porque era un trabajo académico. Un despliegue clínico real sí. Langfuse self-hosted sobre la misma infraestructura del cliente registra cada inferencia (hash del input, modelo, versión, máscara devuelta, score) sin enviar nada a SaaS externo. Eso es lo que convierte un sistema improvisado en uno auditable bajo Art. 30 RGPD. Veinte líneas de código, cinco minutos de configuración, defensa técnica perpetua frente a una inspección.

Tres · cuantización int8 para producción, fp32 para reentrenamiento. El modelo cuantizado pierde una fracción de Dice contra fp32, pero gana 3-4× en latencia y eficiencia energética. Para un caso donde el clínico revisa cada salida antes de validar, esa pérdida es aceptable. La regla operativa: cuantizar lo que va a producción, mantener checkpoints fp32 para reentrenamiento periódico cuando entren imágenes nuevas anotadas.

Lo que el TFM demostró y por qué importa más allá del paper

Tres lecciones de Hygeia que valen para cualquier caso clínico equivalente — radiología, dermatología, oftalmología — donde el dato está bajo Art. 9.

El visor importa tanto como el modelo. El clínico no firma sobre una salida JSON; firma sobre una imagen anotada que entiende. Streamlit con overlay de la segmentación cubre el 90% de los casos sin necesidad de Slicer 3D ni infraestructura PACS pesada. El médico vio la máscara, asintió, y eso fue el primer indicador real de que el sistema servía.

El pre-procesamiento es 50% del modelo. La diferencia entre el pipeline ingenuo (imagen original a la red) y el pipeline Median→CLAHE→Wavelet fue mayor que cualquier ajuste de hiperparámetros que probamos después. En imagen biomédica, la decisión de pre-procesamiento es ingeniería tan crítica como la elección de arquitectura.

El acuerdo de datos es parte del entregable. Un TFM en colaboración con MedTech sin NDA no debería existir. Es lo que distingue una colaboración seria de una práctica académica. El NDA firmado con Dawako fue el motivo por el que esta entrada existe: define exactamente qué se cuenta y qué no, y eso es replicable como práctica con cualquier cliente futuro.

«La mejor arquitectura clínica no es la que usa el modelo más grande. Es la que el equipo del hospital puede mantener cuando el consultor se ha ido.»

Hygeia obtuvo el Premio al Mejor TFM de la promoción 2023-2024 del Master en Data Science de la Universidad Complutense — pero su valor real no estaba en la calificación académica. Estaba en haber cerrado el ciclo completo: problema clínico bien definido, dato real bajo NDA serio, pipeline reproducible, métricas honestas, despliegue local primero, y un clínico que dijo «esto me sirve».

This is a commentary on the architecture and use case of my M.Sc. thesis in Data Science, Big Data & Business Analytics at Universidad Complutense de Madrid (cohort 2023-2024), developed in collaboration with Dawako Med Tech (Valencia) under a data-protection agreement. The dataset, source code, and trained weights are not public — and will not be. But the clinical problem, the architectural logic, and the deployment decisions are shareable, and they are what's actually transferable to other clients in regulated sectors.

Why sarcopenia, why athletes

Sarcopenia — the progressive loss of muscle mass and function — has long since stopped being a geriatric concern alone. In elite sports medicine it is an early marker of overtraining, incomplete recovery, or imminent injury. The rectus femoris is the most-studied structure for estimating it because it's accessible, repeatable, and lets you measure cross-sectional area and fascicular architecture with portable ultrasound.

Dawako Med Tech already had a sizeable clinical dataset acquired with an Esaote MyLab Sigma ultrasound device and their own application (DAWAKO App) for healthcare professionals to generate manual segmentation masks — binary PNG images where the muscle region is 255 and background is 0, with no internal gaps. The thesis was to build a computer-vision system capable of learning that professional segmentation and returning automatic areas and classifications, assisting the clinician, not replacing them.

The data that cannot leave the building

The clinical input is rectus femoris ultrasound. In Europe, that data falls cleanly under GDPR Art. 9: special category health data. Exception 9.2.h allows processing for preventive medicine and diagnostic purposes, but demands reinforced technical and organisational safeguards. Operational translation: the data does not get uploaded to a US-based SaaS API for some endpoint to return a segmentation map.

This isn't ideology. It's compliance engineering. Any agreement between a MedTech company and an academic researcher — even for purely educational purposes like a thesis — has to document data jurisdiction from line one. The NDA with Dawako made it explicit: the dataset is not distributed, the code is not published, and any disclosure of results goes through review.

The pipeline that actually worked

The thesis stack was Python on TensorFlow 2.15-2.17 with the Keras 2.15 interface, run on Google Colab with free GPU access for fast iteration. For final local production it was packaged into an interactive Streamlit app that loads the ultrasound image and returns the predicted segmentation in the browser. Image processing leaned on OpenCV, NumPy, and Scikit-learn — classical toolkit, no exotic frameworks, deliberately maintainable.

Esaote MyLab Sigma (RF probe ultrasound)
                  ↓
          DAWAKO App (manual masks · binary 255/0)
                  ↓
          OpenCV pre-processing:
             ├─ pipeline A: Gaussian Blur + CLAHE (256×256)
             └─ pipeline B: Median + CLAHE + Wavelet (512×512)
                  ↓
          TensorFlow/Keras models (Colab GPU):
             ├─ U-Net for segmentation
             └─ ResNet for binary sarcopenia classification
                  ↓
          Metrics: Dice Coefficient + Balanced Multi-Class Accuracy
                  ↓
          Local Streamlit · clinician reviews before validating

The pre-processing pipeline choice was the most interesting part of the work. Ultrasound images have low contrast and characteristic speckle noise, so we tested five techniques (CLAHE, global Histogram Equalization, Gaussian Blur, Bilateral Filter, Median Filter, Wavelet transform) and two winning combinations were documented:

Combination A · 256×256. Gaussian Blur + CLAHE. Gaussian blur smooths speckle noise; CLAHE locally enhances contrast with controlled clip limit so noise isn't amplified. Fast, robust, solid baseline.

Combination B · 512×512. Median Filter → CLAHE → Wavelet. The median filter reduces salt-and-pepper noise while preserving edges (critical at tissue boundaries); CLAHE improves contrast over the cleaned image; finally the Wavelet transform keeps only low-frequency components (LL) and discards high-frequency noise. More expensive to compute, but the model learned fascicular boundaries with much more clarity.

"The metrics that matter in biomedical imaging are not the ones in the paper. They are the ones the clinician accepts when they see the output overlaid on the image they know."

The metrics that mattered

Two metrics guided evaluation, one for each model head:

Dice Coefficient for the segmentation head — measures overlap between predicted mask and ground-truth mask (the one generated by professionals with the DAWAKO App). It is the standard in medical imaging because it penalises both false positives and false negatives in the region of interest.

Balanced Multi-Class Accuracy for the classifier. It's the honest metric when there's class imbalance (more healthy than sarcopenic muscle images): it computes per-class accuracy and averages, so the model can't win score by always predicting the majority class. That methodological decision was the one I defended at the tribunal and the one I consider most generalisable: anyone reporting plain accuracy on an imbalanced clinical dataset is selling smoke.

How I would re-frame deployment today

The thesis was delivered in 2024. If Dawako, or an equivalent client — sports clinic, federation, elite sports hospital — came into Digital Realism today with the same problem, I wouldn't replicate the thesis stack exactly. There are three things I'd change, not because the thesis was wrong, but because the ecosystem moved on and because the demands of a production deployment are higher than those of an academic project.

One · goodbye Colab, hello native Apple Silicon. Colab was ideal for fast iteration during the thesis, but as a production dependency it's fragile: variable quotas, dying sessions, traveling data. PyTorch MPS (Metal Performance Shaders) closed its support gap with CUDA over 2024-2025 and today runs U-Net and ResNet on Apple Silicon without friction. A Mac Mini M4 (24-32 GB unified memory) covers production inference for a clinic with 30-60 ultrasounds/day with sub-second latency and ~30W average draw. Same model, no Colab, no cloud, data 100% on premises.

Two · audit trail built into the product. The thesis didn't need traceability because it was an academic work. A real clinical deployment does. Self-hosted Langfuse on the client's own infrastructure logs every inference (input hash, model, version, returned mask, score) without sending anything to external SaaS. That is what turns an improvised system into one auditable under GDPR Art. 30. Twenty lines of code, five minutes of configuration, perpetual technical defence against an inspection.

Three · int8 quantisation for production, fp32 for retraining. The quantised model loses a fraction of Dice against fp32, but gains 3-4× in latency and energy efficiency. For a case where the clinician reviews each output before validating, that loss is acceptable. The operational rule: quantise what goes to production, keep fp32 checkpoints for periodic retraining when new annotated images arrive.

What the thesis proved and why it matters beyond the paper

Three lessons from Hygeia that apply to any equivalent clinical case — radiology, dermatology, ophthalmology — where data falls under Art. 9.

The viewer matters as much as the model. Clinicians don't sign on JSON output; they sign on an annotated image they understand. Streamlit with segmentation overlay covers 90% of cases without needing 3D Slicer or heavy PACS infrastructure. The clinician saw the mask, nodded, and that was the first real signal the system was useful.

Pre-processing is 50% of the model. The difference between the naive pipeline (raw image into the network) and the Median→CLAHE→Wavelet pipeline was greater than any hyperparameter tuning we tried afterwards. In biomedical imaging, the pre-processing decision is engineering as critical as the architecture choice.

The data agreement is part of the deliverable. A thesis collaboration with a MedTech company without an NDA shouldn't exist. It's what distinguishes a serious collaboration from an academic exercise. The NDA signed with Dawako is the reason this entry exists: it defines exactly what gets told and what doesn't, and that is replicable as practice with any future client.

"The best clinical architecture is not the one that uses the largest model. It is the one the hospital team can maintain after the consultant is gone."

Hygeia received the Best Thesis Award for the 2023-2024 cohort of Universidad Complutense's M.Sc. Data Science programme — but its real value was not in the academic grade. It was in having closed the full cycle: a well-defined clinical problem, real data under a serious NDA, a reproducible pipeline, honest metrics, local-first deployment, and a clinician who said "this is useful to me".

RAG en Cloud Run con Gemini: el patrón de dos pasos que evita cold starts. RAG on Cloud Run with Gemini: the two-step pattern that avoids cold starts.

Construir un RAG productivo en GCP no es entrenar un job pesado dentro del serving. Separar indexing (offline) de serving (lightweight) es el patrón estándar para ML en serverless. Walkthrough completo con AttentionRAG. Building production RAG on GCP is not about training a heavy job inside serving. Separating indexing (offline) from serving (lightweight) is the standard ML serverless pattern. Full walkthrough with AttentionRAG.

Leer artículo Read article Cerrar artículo Close article

El error más común al desplegar un RAG en Cloud Run no es de modelo: es de arquitectura. La mayoría de los tutoriales que circulan empaquetan el indexing y el serving en el mismo container — un patrón que parece razonable hasta que el primer usuario espera 14 segundos a que el embedder se cargue. Hay un patrón mejor, viejo y aburrido, que es el que usa Google internamente para serving de ML: separar las dos cargas.

El problema del cold start

Cloud Run es serverless por diseño: si nadie pide la URL durante 15 minutos, el container se apaga. Cuando llega la siguiente request, hay que arrancarlo de cero. Si dentro de ese container está cargando un modelo de embeddings de 400 MB y abriendo una conexión a Vertex AI Search, el TTFB del primer usuario salta a la luna. Lo he medido — 11.8 segundos en p99 con un sentence-transformer mediano.

La solución parece obvia: subir min-instances=1. Pero eso te cuesta ~$45/mes por cada instancia warm — y rompe la economía serverless del proyecto. Si tenés 4 endpoints, son $180 fijos antes de servir la primera query.

El patrón de dos pasos

La solución arquitectónica es separar las dos fases del RAG en dos servicios distintos, cada uno optimizado para su carga.

Cloud Storage (corpus PDF)
        ↓
Cloud Run Job (no serving · sin SLA)
        ↓
chunking + embeddings (Gemini text-embedding-004)
        ↓
Vertex AI Search index (managed)
User query
        ↓
Cloud Run service (Hono.js · 256MB · cold start <500ms)
        ↓
Vertex AI Search retrieval (managed, sin warm-up)
        ↓
Gemini 2.5 Flash (streaming SSE)
        ↓
Response al cliente

El truco está en que el serving no carga ningún modelo. Solo orquesta llamadas a servicios managed (Vertex AI Search + Gemini API), que ya están warm globalmente. Un container Hono.js de 256 MB cold-starta en menos de 500ms — eso es aceptable para un primer usuario después de 15 minutos sin tráfico.

Por qué Hono.js y no Python

Una decisión que sorprende a algunos clientes: el serving en este patrón es JavaScript, no Python. Razón concreta: Hono.js sobre Node 22 cold-starta en ~120ms, contra ~800ms de FastAPI sobre Python 3.12. Cuando el bottleneck es el cold start y no la lógica de negocio (que aquí es trivial — recibir query, llamar dos APIs, streamear respuesta), la elección está clara.

El indexing job sí es Python, porque ahí el ecosistema de procesamiento de texto manda — unstructured, langchain, tiktoken. Pero ese job no tiene SLA: corre una vez al día, tarda lo que tenga que tardar, y nadie está esperando.

«El cold start no es un problema técnico. Es una mala separación de fases.»

Métricas reales en AttentionRAG

AttentionRAG es un asistente sobre el paper "Attention Is All You Need" desplegado en producción en GCP. Lo construí como demo pública del patrón. Estas son las métricas observadas durante tres meses:

Cold start p50
~340ms
TTFT warm
~180ms
Coste / 1K queries
$0.30
Min-instances
0

Cuándo NO usar este patrón

El patrón de dos pasos asume tres cosas: que tu corpus cambia poco (puede reindexarse offline), que tu serving es stateless, y que el provider managed cubre tu caso. Si necesitás re-embeddings en tiempo real (corpus que cambia segundo a segundo), si el serving requiere estado entre llamadas (memoria conversacional persistente compleja), o si tu requisito de soberanía no permite Vertex AI Search — el patrón no aplica. Para esos casos, una arquitectura local-first sobre ChromaDB es probablemente la respuesta.

Pero para el 80% de los casos B2B reales — knowledge base interna pública, asistente de documentación técnica, soporte cliente sobre información abierta — el patrón resuelve el cold start, mantiene el coste sub-céntimo por query, y escala globalmente sin tocar config.

The most common mistake when deploying RAG on Cloud Run is not a model issue: it's an architectural one. Most circulating tutorials package indexing and serving in the same container — a pattern that seems reasonable until the first user waits 14 seconds for the embedder to load. There is a better, older, boring pattern, the one Google uses internally for ML serving: separate the two workloads.

The cold-start problem

Cloud Run is serverless by design: if no one hits the URL for 15 minutes, the container shuts down. When the next request arrives, it has to start from scratch. If inside that container you're loading a 400 MB embedding model and opening a connection to Vertex AI Search, the first user's TTFB shoots through the roof. I've measured it — 11.8 seconds at p99 with a medium sentence-transformer.

The obvious fix: bump min-instances=1. But that costs you ~$45/month per warm instance — and breaks the project's serverless economics. If you have 4 endpoints, that's $180 fixed before serving the first query.

The two-step pattern

The architectural fix is to split the two RAG phases into distinct services, each optimised for its workload.

Cloud Storage (PDF corpus)
        ↓
Cloud Run Job (no serving · no SLA)
        ↓
chunking + embeddings (Gemini text-embedding-004)
        ↓
Vertex AI Search index (managed)
User query
        ↓
Cloud Run service (Hono.js · 256MB · cold start <500ms)
        ↓
Vertex AI Search retrieval (managed, no warm-up)
        ↓
Gemini 2.5 Flash (streaming SSE)
        ↓
Response to client

The trick: the serving loads no model. It only orchestrates calls to managed services (Vertex AI Search + Gemini API), which are already warm globally. A 256 MB Hono.js container cold-starts in under 500ms — acceptable for a first user after 15 minutes of no traffic.

Why Hono.js and not Python

A decision that surprises some clients: serving in this pattern is JavaScript, not Python. Concrete reason: Hono.js on Node 22 cold-starts in ~120ms, vs ~800ms for FastAPI on Python 3.12. When the bottleneck is cold start and not business logic (which here is trivial — receive query, call two APIs, stream response), the choice is clear.

The indexing job is Python, because that's where the text-processing ecosystem dominates — unstructured, langchain, tiktoken. But that job has no SLA: it runs once a day, takes as long as it takes, no one is waiting.

"Cold start is not a technical problem. It is a phase-separation problem."

Real metrics from AttentionRAG

AttentionRAG is an assistant over "Attention Is All You Need" deployed in production on GCP. I built it as a public demo of the pattern. These are the metrics observed over three months:

Cold start p50
~340ms
Warm TTFT
~180ms
Cost / 1K queries
$0.30
Min-instances
0

When NOT to use this pattern

The two-step pattern assumes three things: your corpus changes slowly (it can be reindexed offline), your serving is stateless, and the managed provider covers your case. If you need real-time re-embeddings (corpus changing second to second), if serving requires complex stateful conversational memory across calls, or if your sovereignty requirement disallows Vertex AI Search — the pattern doesn't apply. For those cases, a local-first ChromaDB architecture is probably the answer.

But for 80% of real B2B cases — public internal knowledge base, technical docs assistant, customer support over open data — the pattern solves cold start, keeps cost sub-cent per query, and scales globally without touching config.

Local vs cloud no es una guerra ideológica. Es una decisión técnica. Local vs cloud is not an ideological war. It's a technical decision.

Los datos sensibles van en local. La escala global va en cloud. Casi todo lo demás es ego del consultor o miedo del cliente. Reflexión sobre cuándo Vertex AI Agent Builder gana y cuándo Llama 3.3 70B sobre Mac Mini es la mejor decisión. Sensitive data stays local. Global scale goes to cloud. Almost everything else is consultant ego or client fear. A reflection on when Vertex AI Agent Builder wins and when Llama 3.3 70B on Mac Mini is the right call.

Leer artículo Read article Cerrar artículo Close article

El debate local-first vs cloud-first se ha convertido en una guerra de identidad. Hay un bando que predica soberanía y eficiencia energética como si fuera una religión. Hay otro que asume que cualquier cosa que no esté en una hyperscaler es amateurismo. Los dos están equivocados — porque los dos están confundiendo una decisión arquitectónica con una posición tribal. Aquí va una reflexión, desde alguien que opera a diario en GCP y en Azure, y que también ejecuta modelos frontera localmente sobre Apple Silicon.

El falso dilema

La pregunta «¿local o cloud?» está mal planteada. La pregunta correcta es: «¿qué constraint del cliente define la arquitectura?». Y los constraints son técnicos, no ideológicos. Los principales son tres: jurisdicción del dato, latencia exigida por el caso, y escala efectiva del tráfico. Cualquiera que te venda local o cloud sin haber medido los tres está vendiéndote su biografía, no tu solución.

Cuándo cloud es la respuesta correcta

Trabajo a diario sobre GCP y Azure en proyectos enterprise — banca, energía, sectores donde el dato no sale de la región europea pero sí transita masivamente entre servicios managed. Y soy el primero en defender el cloud cuando el caso lo pide. Hay tres escenarios donde la cloud no solo gana: es la única respuesta sensata.

Escala global con tráfico desigual. Una landing pública con 10K visitas/día desde 40 países, donde el 80% del tráfico se concentra en 2 horas. Cloud Run + Cloudflare resuelve eso por $30/mes. Hacerlo local exigiría 40 nodos distribuidos. La economía no cierra.

Cargas burst irregulares. Un cliente con 200 ingestiones de PDF por día durante 3 meses al año, y 2 por día el resto. Pagar un servidor 24/7 para esos 3 meses es absurdo. Cloud Run Jobs cobra solo el cómputo real — y desaparece cuando no hay carga.

Servicios managed que ya hacen el 80% del trabajo. Vertex AI Search es un retriever vectorial managed con SLA 99.95% que escala a millones de docs. Construir eso en local con ChromaDB + un sharding propio es seis meses de ingeniería para llegar al mismo sitio con peor uptime.

«La pregunta correcta no es 'local o cloud'. Es: '¿qué constraint del cliente define la arquitectura?'»

Cuándo local es la respuesta correcta

Y hay tres escenarios igualmente nítidos donde la nube pierde — no por ideología, por mala economía o por riesgo regulatorio.

Datos bajo Art. 9 RGPD. Salud, biometría, datos judiciales. Cuando el constraint es el dato no puede salir del edificio, no hay debate: local o VPC privada con cifrado at-rest controlado por el cliente. Y si va a VPC, mejor que sea por una razón de escala, no de comodidad.

Tráfico estable y previsible. Una clínica con 60 ecografías al día. Un despacho con 200 abogados que consultan jurisprudencia interna. Pagar tokens cloud por cada query cuando un Mac Mini de 1.500€ cubre la carga durante 5 años — es simplemente mala matemática.

Cuando la latencia importa más que la escala. Un agente que asiste en consulta médica en tiempo real necesita TTFT < 200ms consistente. La latencia de red a la región más cercana de un hyperscaler es ~30ms en buenas condiciones, ~150ms en malas. Local elimina esa varianza.

El patrón híbrido que casi siempre gana

En la mayoría de los proyectos reales, la respuesta no es elegir un bando. Es una arquitectura híbrida con frontera bien dibujada: capa local para PII y datos sensibles, capa cloud para razonamiento sobre datos anonimizados o agregados. La frontera entre las dos está documentada en un DPIA y es auditable. Esto no es comodidad — es ingeniería de cumplimiento.

Un caso típico: edge gateway local que redacta PII, envía solo embeddings o resúmenes anonimizados a Vertex AI Agent Builder en VPC privado europeo, recibe respuesta, la entrega al cliente. El dato bruto nunca sale. La inteligencia escala. Los dos planos viven juntos sin contradecirse.

El error tribal

El error que veo más en consultores junior — y a veces en seniors que se han especializado de un solo lado — es proyectar su preferencia tecnológica sobre la realidad del cliente. El consultor que solo ha tocado AWS te dará una arquitectura de Lambda + DynamoDB para un problema que se resuelve con un Mac Mini en una habitación. El que solo ha tocado modelos open-source te dirá que ChatGPT es vendor lock-in cuando tu cliente solo quiere un asistente de soporte que funcione bien.

El criterio profesional empieza cuando aceptás que las dos arquitecturas son válidas en contextos distintos, y que tu trabajo es identificar el contexto antes que la solución. Después, ejecutás con la disciplina que el caso pida — observabilidad, audit trail, IaC — independientemente de dónde corra el cómputo.

«El criterio profesional empieza cuando aceptás que las dos arquitecturas son válidas en contextos distintos.»

El stack que defiende esta posición

Por eso este estudio mantiene certificaciones activas en las dos fronteras. GCP × 3, Azure AI Fundamentals, Oracle OCI, Databricks — para defender el caso cloud cuando es el adecuado. Y un MacBook Pro M5 Max con 128 GB de memoria unificada ejecutando Llama 4 Scout, Llama 3.3 70B y Qwen 3.5 — para defender el caso local cuando es el adecuado. Ninguna de las dos colecciones es decoración: las dos resuelven problemas reales en proyectos reales.

El día que Digital Realism predique solo una de las dos arquitecturas como la verdadera, cerralo. Habrá dejado de ser un estudio de ingeniería para convertirse en un fan club.

The local-first vs cloud-first debate has turned into an identity war. There's one camp that preaches sovereignty and energy efficiency like a religion. There's another that assumes anything not on a hyperscaler is amateurism. Both are wrong — because both are confusing an architectural decision with a tribal stance. Here's a reflection, from someone who operates daily on GCP and Azure, and also runs frontier models locally on Apple Silicon.

The false dilemma

The question "local or cloud?" is poorly framed. The right question is: "which client constraint defines the architecture?". And constraints are technical, not ideological. The main three: data jurisdiction, case-required latency, and effective traffic scale. Anyone selling you local or cloud without having measured all three is selling you their biography, not your solution.

When cloud is the right answer

I work daily on GCP and Azure on enterprise projects — banking, energy, sectors where data doesn't leave the European region but transits massively between managed services. And I'm the first to defend cloud when the case calls for it. There are three scenarios where cloud isn't just winning: it's the only sensible answer.

Global scale with uneven traffic. A public landing with 10K visits/day from 40 countries, where 80% of traffic concentrates in 2 hours. Cloud Run + Cloudflare solves that for $30/month. Doing it locally would require 40 distributed nodes. The economics don't close.

Irregular burst workloads. A client with 200 PDF ingestions per day for 3 months a year, and 2 per day the rest. Paying for a 24/7 server for those 3 months is absurd. Cloud Run Jobs charges only real compute — and disappears when there's no load.

Managed services that already do 80% of the work. Vertex AI Search is a managed vector retriever with 99.95% SLA scaling to millions of docs. Building that locally with ChromaDB plus your own sharding is six months of engineering to land at the same place with worse uptime.

"The right question is not 'local or cloud'. It's: 'which client constraint defines the architecture?'"

When local is the right answer

And there are three equally clear scenarios where the cloud loses — not for ideology, but for bad economics or regulatory risk.

Data under GDPR Art. 9. Health, biometrics, judicial data. When the constraint is data cannot leave the building, there's no debate: local, or private VPC with at-rest encryption controlled by the client. And if it goes to VPC, that better be for a scale reason, not for convenience.

Stable, predictable traffic. A clinic with 60 ultrasounds a day. A firm with 200 lawyers querying internal jurisprudence. Paying cloud tokens per query when a €1,500 Mac Mini covers the load for 5 years — that's simply bad math.

When latency matters more than scale. An agent assisting a clinical consultation in real time needs consistent TTFT < 200ms. Network latency to the nearest hyperscaler region is ~30ms in good conditions, ~150ms in bad ones. Local removes that variance.

The hybrid pattern that almost always wins

In most real projects, the answer isn't picking a side. It's a hybrid architecture with a clearly drawn boundary: local layer for PII and sensitive data, cloud layer for reasoning over anonymised or aggregated data. The boundary between the two is documented in a DPIA and is auditable. This isn't convenience — it's compliance engineering.

A typical case: local edge gateway redacting PII, sending only embeddings or anonymised summaries to Vertex AI Agent Builder in a private European VPC, receiving response, returning it to the client. The raw data never leaves. The intelligence scales. The two planes coexist without contradiction.

The tribal mistake

The most common mistake I see in junior consultants — and sometimes in seniors who have specialised on one side only — is projecting their tech preference onto the client's reality. The consultant who has only touched AWS will hand you a Lambda + DynamoDB architecture for a problem solved by a Mac Mini in a room. The one who has only touched open-source models will tell you ChatGPT is vendor lock-in when your client just wants a support assistant that works well.

Professional judgement begins when you accept that both architectures are valid in different contexts, and that your job is identifying the context before the solution. After that, you execute with whatever discipline the case demands — observability, audit trail, IaC — regardless of where compute runs.

"Professional judgement begins when you accept that both architectures are valid in different contexts."

The stack that defends this position

That's why this studio maintains active credentials on both frontiers. GCP × 3, Azure AI Fundamentals, Oracle OCI, Databricks — to defend the cloud case when it's the right one. And a MacBook Pro M5 Max with 128 GB unified memory running Llama 4 Scout, Llama 3.3 70B and Qwen 3.5 — to defend the local case when it's the right one. Neither collection is decoration: both solve real problems in real projects.

The day Digital Realism preaches only one of the two architectures as the true one, shut it down. It will have stopped being an engineering studio and become a fan club.

Hablemos de tu caso concreto.Let's talk about your specific case.

Una sesión de descubrimiento, sin compromiso, para entender qué problema quieres resolver y si nuestra forma de trabajar encaja con tu organización.A no-commitment discovery session to understand what problem you want to solve and whether our way of working fits your organisation.

// SCHEDULE_DISCOVERY()

30 minutos, formato remoto o presencial en Madrid. Te diré con sinceridad si tu caso encaja con alguno de nuestros servicios o si necesitas otra cosa.30 minutes, remote or in-person in Madrid. I'll tell you honestly whether your case fits one of our services or whether you need something else.

emilianovolpi@digitalrealism.io
● RESPONSE_TIME: 24hUTC+1 · MADRID