Cómo construir un equipo de datos en 2025: de la euforia GenAI a producción real
En junio de 2015 publicábamos en este blog los «pasos para crear un equipo de trabajo en Big Data». Diez años después, el término «Big Data» ha quedado pequeño. Lo que entonces requería clústeres Hadoop on-premise, ingenieros de MapReduce y data scientists con doctorado, hoy se resuelve con LLMs en producción, agentes autónomos y arquitecturas RAG desplegadas en horas, no meses.
Pero la paradoja persiste: el 78% de los proyectos de IA generativa no llegan a producción (Gartner, 2024), y la mayoría de las empresas españolas siguen contratando perfiles de 2018 para problemas de 2025. En BAOSS hemos acompañado a 40+ organizaciones en esta transición. Este artículo no es teoría: es el playbook que aplicamos en cliente real (datos anonimizados, métricas verificables).
El problema real 2025-2026: no es tecnología, es arquitectura de decisión
La euforia post-ChatGPT (noviembre 2022) generó un fenómeno que vemos en el 90% de las reuniones de dirección: FOMO tecnológico sin caso de negocio cuantificado. Los comités compran licencias Copilot Enterprise, contratan «prompt engineers» y lanzan pilotos RAG sobre PDFs sin gobernanza. Resultado: coste medio 180K€/año, ROI negativo a 12 meses.
- Gap de habilidades: El 65% de los «data scientists» contratados en 2023-24 no saben desplegar un modelo con vLLM u Ollama en GPU compartida, ni orquestar agentes con LangGraph/CrewAI.
- Deuda técnica invisible: Pilotos sin observabilidad (traces, evals, guardrails) que se convierten en «sombra IT» ingobernable.
- Cultura de dato ausente: El CEO aprueba presupuesto GPU pero no exige data contracts entre dominios (Data Mesh real, no PowerPoint).
Caso BAOSS (retail, 2.400M€ facturación): Llegaron con 3 pilotos GenAI paralelos (atención cliente, categorización producto, pricing), 0 en producción. Diagnóstico en 2 semanas: ninguno tenía evals automatizados, ni CI/CD para prompts, ni propiedad de dato definida. Solución: plataforma interna estandarizada (ver sección 3). Resultado: 2/3 en producción en 8 semanas, reducción 40% tiempo despliegue, ROI 3.2x a 6 meses.
Paso 1: La IA es prioridad de negocio, no de IT — y el CEO debe poseer el «North Star Metric»
En 2015 decíamos «el CEO debe dar ejemplo». En 2025 es más concreto: el CEO debe definir y poseer la métrica norte que la IA va a mover. No «adoptar IA», sino «reducir churn 15% con agente de retención autónomo en Q3».
- Anti-patrón: CTO compra GPUs, CFO ve coste, CMO quiere chatbot, CISO bloquea. Nadie responde: «¿qué métrica de negocio movemos y en qué horizonte?».
- Patrón BAOSS: Talleres de AI Opportunity Mapping (2 días, C-suite + domain owners). Salida: backlog priorizado por valor/riesgo/feasibility con OKRs trimestrales vinculados a variable retribución.
Métrica interna BAOSS: clientes que completan este taller pasan de 0 a 2,3 casos en producción a 6 meses (media 2024, n=27). Los que no lo hacen: 0,4 casos.
Paso 2: Arquitectura de plataforma, no «herramientas sueltas» — MCP, RAG evals, y GPU-as-a-Service
El cloud computing de 2015 era «alquilar servidores». Hoy la abstracción correcta es plataforma de inferencia unificada que expone:
- Model Registry versionado: GPT-4o, Claude 4 Sonnet, Llama-3.1-70B-Instruct (vLLM/Ollama), embeddings (BGE-M3, E5-mistral) — con fallback automático y cost tracking por llamada.
- RAG Engine con evals continuos: Chunking semántico, reranking (Cohere Rerank v3.5), retrieval evaluado nightly (RAGAS + métricas negocio). Sin evals, no hay producción.
- Agent Runtime (LangGraph/CrewAI/AutoGen): Orquestación stateful, human-in-the-loop nativo, observabilidad (LangSmith / Arize / Phoenix).
- MCP (Model Context Protocol) servers: Conectores estandarizados a ERP, CRM, data lake, APIs internas — elimina spaghetti de integraciones ad-hoc.
- Guardrails & PII: Presidio / Microsoft Presidio / LlamaGuard 3 en sidecar, logging inmutable para auditoría (AI Act ready).
Decisión build vs buy 2025: No montes tu Kubernetes para LLMs. Usa GPU-as-a-Service (RunPod, Lambda Labs, Fluidstack, o cloud público con instancias A100/H100 spot) + plataforma gestionada (Databricks Mosaic AI, Azure AI Studio, Vertex AI) o self-hosted con vLLM + Kubernetes (KServe/Knative) si tienes escala >500 req/s sostenido.
Caso BAOSS (banca media, 800M€ activos): Migración de 12 pilotos dispersos (OpenAI API directo, sin evals) a plataforma unificada vLLM + LangGraph + MCP. Inversión: 220K€ (infra + 3 meses consultoría). Ahorro: 62% coste inferencia vs API cerrada, 0 incidentes seguridad, 3 agentes en producción en 10 semanas (clasificación reclamaciones, asistente KYC, generador informes riesgos).
Paso 3: El equipo 2025 — perfiles híbridos, no «data scientists unicornio»
El error 2015-2024: buscar «data scientist que sepa todo». En 2025 la especialización es obligatoria. El equipo mínimo viable (3-5 personas) para operar la plataforma anterior:
- AI Platform Engineer (1-2): Kubernetes, vLLM/Ollama, CI/CD para prompts (DVC/MLflow + PromptLayer), GPU scheduling, cost optimization. Perfil: DevOps/MLOps senior, no PhD.
- Agent & RAG Engineer (1-2): LangGraph/CrewAI/AutoGen, chunking strategies, reranking, evals (RAGAS, custom business metrics), guardrails. Perfil: Software engineer + NLP aplicado.
- AI Product Owner / Domain Translator (1): Dueño del backlog, define evals de negocio, gestiona stakeholders, prioriza por ROI. Perfil: Ex-consultor / PM técnico / domain expert.
- Data Steward / Governance (0.5-1, compartido): Data contracts, calidad, linaje, AI Act compliance. No es DBA, es «product owner del dato».
Qué NO necesitas contratar ya: Prompt engineers puros (skill que se democratiza), ML researchers (salvo R&D puro), Data scientists clásicos sin ingeniería de producción.
Métrica BAOSS: Equipos formados con este modelo alcanzan primer agente en producción en 6-8 semanas (vs 6-12 meses modelo tradicional). Coste salarial medio: 380K€/año (Madrid/BCN, 2025) vs 650K€/año equipo «unicornio» 2023.
Paso 4: Gobernanza ligera — AI Act, evals como tests, y «data contracts» entre dominios
El Reglamento UE IA (aplicación plena agosto 2026) obliga a: registro de sistemas de alto riesgo, gestión de riesgos, calidad de datos, supervisión humana, documentación técnica. No es opcional. La buena noticia: la arquitectura del Paso 2 ya genera 80% de la evidencia (logs, evals, guardrails, versionado).
- Evals = Tests automatizados: Cada PR de prompt/agente pasa pipeline: unit tests (estructura), integration tests (RAGAS: faithfulness, answer_relevancy, context_precision), business tests (métrica dominio: % resoluciones sin escalar, NPS, conversion). No merge si no pasa.
- Data Contracts (Data Mesh real): Cada dominio publica esquema (Avro/Protobuf), SLA frescura, owner, semantics. Los agentes consumen contratos, no tablas raw. Rompe acoplamiento.
- Observabilidad unificada: Traces (LangSmith/Phoenix), métricas negocio (Grafana), costes (FinOps), alertas (drift, latencia, coste/llamada > threshold).
Caso BAOSS (seguro, 1.200M€ primas): Implementación evals nightly + data contracts entre siniestros, suscripción, actuarial. Resultado: detección temprana de degradación RAG (faithfulness -12% en 3 días) → rollback automático → 0 impacto cliente. Auditoría AI Act: documentación técnica generada 90% automática desde pipeline.
Paso 5: Cultura de «eval-driven development» — del PoC al producto
El mayor cambio cultural: nadie deploya a producción sin evals que midan valor de negocio. No «accuracy», sino «reducción 30% tiempo gestión reclamación». Esto obliga a:
- Definir métrica proxy de negocio antes de escribir una línea de código.
- Construir dataset de evaluación representativo (mínimo 200-500 casos reales, actualizado semanalmente).
- Automatizar comparación A/B (champion/challenger) en staging con tráfico sombra.
- Celebrar «kill your darlings»: si el agente no bate baseline humano + coste, se apaga. Sin drama.
En BAOSS implantamos AI Review Board quincenal (30 min): PO presenta métricas, equipo técnico muestra diff evals, decisión: scale / iterate / kill. Tasa de kill sano: 35-40% de iniciativas (evita zombie projects).
Resumen ejecutivo: checklist 2025 para tu comité de dirección
| Área | Pregunta clave | Señal de alarma | Acción BAOSS |
|---|---|---|---|
| Estrategia | ¿Qué 3 métricas de negocio moverá la IA en 12 meses? | «Queremos usar IA» sin OKR | AI Opportunity Mapping (2 días) |
| Plataforma | ¿Tenemos infra de inferencia unificada con evals, guardrails, MCP? | 12 APIs OpenAI directas, 0 evals | Plataforma vLLM/LangGraph/MCP (8-12 sem) |
| Equipo | ¿Tenemos AI Platform Engineer + Agent Engineer + AI PO? | Solo «data scientists» sin prod skills | Upskilling + hiring plan 60 días |
| Gobernanza | ¿Passan los agentes pipeline de evals negocio antes de merge? | Deploy manual, sin tests | CI/CD + RAGAS + business evals |
| Cultura | ¿Se matan proyectos que no baten baseline en staging? | Zombie pilots >6 meses | AI Review Board quincenal |
Datos agregados BAOSS 2024 (n=31 clientes producción):
- Time-to-first-value: 8,2 semanas (mediana) desde kickoff a primer agente en producción generando métrica negocio.
- Coste total plataforma + equipo primer año: 420K€ (P25) – 680K€ (P7