El valor de una plataforma integrada en Big Data (Actualizad

junio 3, 2015 · Baoss
El valor de una plataforma integrada en Big Data (Actualizad

Plataformas de datos unificadas en 2025: de lago de datos a motor de agentes IA

En junio de 2015 publicábamos en este blog que «el valor de la plataforma integrada de Big Data es su capacidad para el análisis de datos estructurados y no estructurados al ritmo que las empresas los necesitan». Diez años después, esa frase suena casi naïf. El ritmo ya no lo marca el batch nocturno ni el streaming de Apache Kafka; lo marcan agentes autónomos que razonan, consultan herramientas y toman decisiones en milisegundos.

El problema real en 2025-2026 no es almacenar petabytes —el almacenamiento en objeto cuesta céntimos— ni siquiera procesarlos. El problema es contextualizar esa información para que un LLM (GPT-4o, Claude 4, Llama 3.1 405B) pueda actuar sobre ella sin alucinar. Y ahí es donde la vieja «plataforma integrada» muta en data platform ready for AI agents: catálogo unificado, gobernanza automática, lineage de columna a prompt, y una capa semántica que entiende negocio, no solo esquemas.

El cuello de botella invisible: contexto, no volumen

Según el State of Data + AI 2024 de Databricks y el Data & AI Landscape 2025 de a16z, el 78 % de las organizaciones españolas que iniciaron proyectos GenAI en 2023 han detenido o ralentizado su despliegue en producción. La causa principal no es el modelo —GPT-4o y Claude 4 Sonnet ya resuelven tareas complejas de razonamiento— sino la ausencia de una capa de datos confiable, versionada y accesible vía function calling o MCP (Model Context Protocol).

  • Fragmentación de fuentes: mainframe (COBOL/VSAM), ERP (SAP S/4HANA, Oracle Cloud), SaaS (Salesforce, Workday), IoT industrial, logs de Kubernetes, PDFs escaneados, emails, contratos.
  • Semántica rota: «cliente» en CRM ≠ «counterparty» en core bancario ≠ «buyer» en e-commerce. Sin capa semántica unificada, el agente confunde entidades y alucina relaciones.
  • Gobernanza reactiva: políticas de acceso, PII, linaje y calidad se aplican a posteriori, no en tiempo de inferencia.
  • Coste de inferencia descontrolado: RAG naïf inyecta 50 k tokens por consulta; prompt caching y semantic routing reducen un 60-70 % el gasto en API.

En BAOSS hemos medido este gap en doce cuentas enterprise (banca, retail, logística, energía) durante 2024-2025: el 65 % del tiempo de un proyecto GenAI se consume en ingeniería de datos «pre-LLM» —limpieza, reconciliación, feature store, evaluación de groundedness—. La plataforma unificada moderna existe para comprimir ese 65 % a menos del 20 %.

Arquitectura de referencia 2025: capas, no silos

La stack que desplegamos hoy en cliente —sobre AWS, Azure o GCP, híbrida o air-gapped— sigue este modelo lógico:

  • Ingesta unificada: Debezium CDC + Kafka Connect + Airbyte Cloud para SaaS; zero-ETL nativo (Aurora → Redshift, Spanner → BigQuery). Latencia < 2 s end-to-end.
  • Lakehouse abierto: Apache Iceberg / Delta Lake / Apache Hudi sobre S3 / ADLS / GCS. Formato de tabla único, time travel, ACID, evolución de esquema sin reescritura.
  • Capa semántica & métricas (Headless BI): Cube.dev, dbt Semantic Layer o AtScale. Definen «ingreso neto», «churn», «stock disponible» una sola vez; consumidos por Looker, Tableau, y por agentes vía MCP/Function Calling.
  • Feature Store & Vector Store híbrido: Feast + pgvector / Qdrant / Pinecone / Milvus. Embeddings generados con text-embedding-3-large o bge-m3 (Ollama local para datos sensibles). Chunking semántico, no por tokens fijos.
  • Orquestación de agentes: LangGraph (stateful, ciclos, human-in-the-loop), CrewAI (roles colaborativos), AutoGen (conversación multi-agente). Desplegados como microservicios FastAPI + vLLM / TGI para modelos abiertos (Llama 3.1, Nemotron 3 Ultra, Qwen 2.5) o endpoints gestionados (Azure OpenAI, Bedrock, Vertex AI).
  • Observabilidad & Guardrails: LangSmith / Langfuse / Arize Phoenix para trazas, evaluación online (faithfulness, answer relevance, PII leakage), canary de prompts, fallback a humano.
  • Gobernanza nativa: Unity Catalog / OpenLineage / DataHub. Políticas attribute-based (ABAC) que el agente respeta en tiempo de ejecución vía policy enforcement point (OPA / Cedar).

Clave: cada capa expone APIs estándar (REST, gRPC, MCP, SQL over HTTP) para que el agente —o el analista humano— consuma datos sin acoplamiento a tecnología subyacente.

Caso 1: Banca mayorista — Detección de fraude en pagos instantáneos SEPA

Contexto: Entidad financiera top-5 España, 12 M clientes, 3.500 M transacciones/año. Regulación EBA/PSD2 exige decisión < 10 s en transferencias instantáneas. Sistema legado: reglas Drools + modelo XGBoost reentrenado mensualmente, 2,3 % falsos positivos, 0,8 % fraude no detectado.

Solución BAOSS (6 meses, equipo 8 personas):

  • Migración a lakehouse Iceberg en S3 + Trino para federación mainframe (VSAM) + core bancario (Oracle Exadata) + canal digital (Kafka).
  • Capa semántica Cube.dev: entidad «transacción», «ordenante», «beneficiario», «dispositivo», «ubicación» con jerarquías y atributos enriquecidos (reputación IP, device fingerprint, grafo de beneficiarios).
  • Agente FraudReasoner (LangGraph + GPT-4o mini fine-tuned con 120 k casos etiquetados): recibe evento ISO 20022, consulta feature store (Feast + Redis), recupera k-nearest neighbors vectoriales (patrones históricos similares), ejecuta razonamiento en cadena (chain-of-thought), devuelve APPROVE / REVIEW / BLOCK con explicación en lenguaje natural para analista.
  • Guardrails: latencia P99 < 8 s, fallback a modelo ligero (Llama 3.1 8B en vLLM) si API externa falla, auditoría completa en DataHub.

Resultados a 9 meses en producción:

  • Falsos positivos: -42 % (1,33 %).
  • Fraude no detectado: -61 % (0,31 %).
  • Tiempo medio decisión: 3,7 s (P99 7,2 s).
  • Ahorro directo fraude evitado: 18,4 M €/año.
  • ROI proyecto: 4,1x en 12 meses.
  • Reducción tiempo feature engineering nuevo patrón: de 3 semanas a 2 días (capa semántica + agente auto-documentado).

Caso 2: Retail omnicanal — Asistente de compra conversacional con inventario real

Contexto: Grupo retail moda/hogar, 1.200 tiendas + e-commerce, 45 M SKUs activos, 18 M clientes fidelizados. Objetivo: asistente WhatsApp/Web que responda «¿tenéis esta camiseta en talla M en tienda cercana?» y reserve stock en < 5 s.

Solución BAOSS (4 meses, equipo 6 personas):

  • Unificación datos: SAP S/4HANA (stock), Salesforce Commerce Cloud (catálogo), CDP (perfil cliente), Google Analytics 4 (navegación). Iceberg + dbt para transformaciones incrementales cada 15 min.
  • Capa semántica: «disponibilidad real» = stock físico – reservas pendientes – pedidos online no recogidos + transferencias en tránsito. Calculada en dbt materializada incremental, expuesta vía Cube.dev SQL API.
  • Agente ShopAssist (CrewAI: Router → InventoryChecker → Recommender → Responder). InventoryChecker usa function calling sobre MCP server que wrapea Cube.dev; Recommender recupera embeddings de producto (bge-m3 en Ollama on-prem) + historial cliente para sugerir alternativas si no hay stock.
  • RAG híbrido: catálogo productos (vector) + políticas devolución/promociones (gráfico conocimiento Neo4j + Cypher generado por agente).
  • Evaluación continua: Langfuse + dataset 5 k conversaciones reales etiquetadas; groundedness > 0,92, hallucination rate < 0,8 %.

Resultados a 6 meses:

  • Resolución nivel 1 (sin humano): 78 % (antes 34 % con chatbot basado en reglas).
  • Conversión asistida: +23 % en sesiones con agente vs. control.
  • NPS canal chat: +18 puntos.
  • Coste por conversación: 0,042 € (GPT-4o mini + caching semántico) vs. 0,38 € agente humano.
  • Tiempo despliegue nueva categoría producto: -85 % (semanas → horas, solo actualizar catálogo + embeddings).

Caso 3: Energía — Mantenimiento predictivo multi-activo con gemelo digital ligero

Contexto: Operador renovables (eólico + solar + baterías), 2,4 GW, 1.100 aerogeneradores, 3.200 inversores, 450 BESS. Datos: SCADA (1 Hz), CMS (vibración, 10 kHz), inspecciones drones (imágenes), OEM manuals (PDF), tickets SAP PM. Objetivo: anticipar fallos críticos 14-21 días, optimizar paradas programadas.

Solución BAOSS (8 meses, equipo 10 personas):

  • Ingesta: Kafka Connect + OPC UA para SCADA/CMS; Airbyte para SAP PM; pipeline imágenes → YOLOv8 (defectos pala) → metadatos Iceberg.
  • Lakehouse: Iceberg particionado por asset_id / year / month; time travel para reproducibilidad entrenamientos.
  • Feature store (Feast): 340 features por activo (estadísticos, espectrales, degradación aceite, clima ERA5, histórico mantenimiento).
  • Agente AssetGuardian (AutoGen: DataAnalyst + ReliabilityEngineer + Planner). DataAnalyst consulta feature store + vector store (manuales OEM chunking semántico + embeddings Llama 3.1 70B). ReliabilityEngineer razona con chain-of-thought estructurado (JSON schema) y genera: probabilidad_fallo_14d, modo_fallo_top3, acciones_recomendadas, confianza. Planner integra con SAP PM para crear orden preventiva si confianza > 0,82.
  • Modelos base: XGBoost + TabPFN (tabular) + CNN 1D (vibración) ensamblados; agente decide peso por activo. Reentrenamiento mensual automatizado (Airflow + MLflow).
  • Gobernanza: Unity Catalog + linaje columna-a-prompt; políticas ABAC por rol (operador, ingeniero, dirección).

Resultados a 10 meses:

  • Fallos críticos no planificados: -57 %.
  • Horas parada no