← Volver al indice | Arquitectura del Sistema

Análisis Tecnológico Integral y Arquitectura de Sistemas para la Transformación Digital del Centro Oceanográfico de Malaga (IEO-CSIC)¶

Documento: Deep Research v2 — Análisis Tecnológico Integral
Fecha: 19 de marzo de 2026
Nivel: Investigación / Nivel 0
Relacionado con: Visión de Plataforma | Arquitectura del Sistema

1. Contexto Operativo y Reingeniería de la Información Institucional¶

El traslado e inauguración de las nuevas instalaciones del Centro Oceanográfico de Malaga, reubicado estrategicamente en la Explanada de San Andres (Muelle 9) del Puerto de Malaga tras cuatro décadas de permanencia en Fuengirola, marca un punto de inflexion en la capacidad científico-tecnológica del Instituto Español de Oceanografia (IEO). Este centro, integrado operativamente como Centro Nacional dentro de la estructura de la Agencia Estatal Consejo Superior de Investigaciones Cientificas (CSIC), dependiente del Ministerio de Ciencia, Innovación y Universidades, alberga a más de un centenar de profesionales, incluyendo personal científico y técnico de primer nivel.

Las lineas de investigación son excepcionalmente diversas, abarcando desde la gestión sostenible de los recursos pesqueros y el estudio de la biodiversidad marina, hasta el análisis de los efectos del cambio climatico, el cartografiado de fondos oceanicos y la evaluación de riesgos geológicos.

[!IMPORTANT] El progreso en la infraestructura fisica contrasta con los desafios persistentes en la arquitectura de la información interna. El funcionamiento de los diversos departamentos y grupos de investigación se ha caracterizado por un alto grado de autonomía, derivando en practicas de gestión de datos fuertemente compartimentadas — lo que en arquitectura de sistemas se denominan "silos de información".

1.1 Impacto de los Silos de Información¶

Los silos generan tres consecuencias críticas:

Imposibilitan la explotación transversal de los datos entre departamentos
Limitan la trazabilidad de las investigaciones a largo plazo
Impiden la aplicación directa de algoritmos avanzados de Inteligencia Artificial (IA)

1.2 Objetivo Central¶

El objetivo central es conceptualizar y diseñar la arquitectura de un sistema de información centralizado y automatizado capaz de:

Disolver los silos departamentales
Integrar flujos de datos dispares
Apalancar el vasto conocimiento histórico del IEO mediante IA multimodal
Permitir la identificación de caracteristicas biológicas críticas (sexo, especie, edad) mediante reconocimiento de imagenes
Operar tanto sobre el archivo fotográfico histórico como en tiempo real a través de camaras de dispositivos móviles

2. Auditoria del Patrimonio de Datos, Estimación Volumétrica y Digitalización¶

2.1 Dimension de las Colecciones Históricas de Referencia¶

El IEO de Malaga conserva colecciones biológicas que se remontan a los albores de la oceanografia española en las primeras décadas del siglo XX, impulsadas por pioneros como Fernando y Rafael de Buen, Alvaro de Miranda y Jimena Quiros.

Colección Histórica de Fauna Marina (CFM-HISTORICA-IEOMA)¶

Parametro	Valor
Tipo de preservación	Especímenes en reactivos liquidos
Total catalogado	1.069 especímenes
Grupo predominante	Peces (78,6%)
Segundo grupo	Decapodos (10,3%)
Tercer grupo	Cefalopodos (5,6%)
Registro mas antiguo	1907 (Mullus surmuletus)
Zona predominante	Costas de Malaga, Mar Mediterráneo (76%)

Colección Histórica Seca (CFM-HISTORICA-SECA-IEOMA)¶

Parametro	Valor
Tipo de preservación	Especímenes preservados en seco
Total catalogado	2.365 especímenes
Grupo predominante	Moluscos gasteropodos (38,5%)
Segundo grupo	Moluscos bivalvos (38%)
Tercer grupo	Crustaceos decapodos (15%)
Periodo temporal	1913 - principios de los 2000
Distribución geográfica	Mediterráneo 64%, Pacífico 15%, Atlántico 14%, Antártico 7%

[!NOTE] El volumen combinado asciende a +3.400 especímenes catalogados, cada uno requiriendo digitalización de multiples fotografías de alta resolución desde diferentes angulos, mas metadatos taxonomicos, espaciales (GPS) y temporales. Esta iniciativa esta alineada con el proyecto institucional TAXON del IEO (CSIC).

2.2 Flujos de Datos Dinamicos: Otolitos, Campañas y Biologia Pesquera¶

El núcleo de la inferencia de la IA para el MVP (detección de edad y sexo) se fundamenta en las muestras biológicas recolectadas rutinariamente en campañas oceanográficas. Ejemplo paradigmático: los otolitos (estructuras calcáreas en el oido interno de los peces).

flowchart LR
    subgraph Campana ["Campana Oceanografica"]
        C1["Captura de especimen"]
        C2["Medicion talla y peso"]
        C3["Sexo macroscopico"]
        C4["Extraccion otolitos"]
        C5["Extraccion gonadas"]
        C1 --> C2 --> C3 --> C4
        C3 --> C5
    end

    subgraph Lab ["Laboratorio IEO"]
        L1["Microfotografia otolito"]
        L2["Contaje de annuli"]
        L3["Estimacion de edad"]
        L4["Indice gonadosomatico"]
    end

    C4 --> L1 --> L2 --> L3
    C5 --> L4

Las campañas recurrentes como ECOMED y las realizadas a bordo de buques oceanograficos en zonas de Hatton, Reikjanes o Porcupine generan muestras masivas donde los investigadores documentan: talla, peso, sexo macroscopico, repleción estomacal, extracción de otolitos y gonadas.

2.3 Estimación Volumétrica para el Sistema¶

Tipo de Dato	Descripción	Volumen Estimado	Complejidad
Estructurados	Series históricas tabulares, biometrías, indices gonadales (Excel, BBDD)	Decenas de GB	Alta en ETL (limpieza y normalización)
No Estructurados	Fotografias de especímenes, microfotografias de otolitos, imagenes de campana	TB iniciales, PB a medio plazo	Requiere lectura ultrarrápida para IA

flowchart TB
    subgraph Volumetria ["Topologia de Datos"]
        S1["Datos Estructurados"] --> S2["Tablas Excel historicas"]
        S1 --> S3["BBDD locales"]
        S1 --> S4["Series biometricas"]

        N1["Datos No Estructurados"] --> N2["+3.400 especímenes históricos"]
        N1 --> N3["Miles de otolitos anuales"]
        N1 --> N4["Imagenes de campana"]
    end

    S2 --> ETL["ETL + Normalizacion"]
    S3 --> ETL
    S4 --> ETL
    ETL --> DL["Data Lake"]

    N2 --> BLOB["Blob Storage"]
    N3 --> BLOB
    N4 --> BLOB
    BLOB --> DL

    DL --> IA["Motor IA Multimodal"]

    style DL fill:#f39c12,color:#fff
    style IA fill:#e74c3c,color:#fff

3. Marco Regulador: Soberanía de Datos y Esquema Nacional de Seguridad (ENS)¶

3.1 El Esquema Nacional de Seguridad (RD 311/2022)¶

Los sistemas de información del sector público estan regulados por el ENS, actualizado mediante el Real Decreto 311/2022. El marco exige que las organizaciones categoricen sus sistemas en función de la criticidad de los datos:

Categoria	Requisitos	Auditorias
BASICA	Politicas minimas de seguridad	Declaración de aplicabilidad
MEDIA	Defensa en profundidad, cifrado	Auditoria periódica
ALTA	Controles maximos, trazabilidad total	Auditoria formal certificada

[!WARNING] El MVP gestionara: datos primarios de investigación, propiedad intelectual del CSIC, datos históricos irrepetibles, y metadatos de investigadores. La arquitectura debe cumplir como umbral mínimo categoria MEDIA, preparandose para auditorías ALTA.

3.2 Soberanía de Datos y Restricciones¶

Requisito	Implicación
Residencia de datos	Infraestructura fisica dentro de la UE
Cifrado CMEK	Claves criptográficas gestionadas por el CSIC
Anti vendor lock-in	Diseño portable, sin dependencia de un único proveedor
Legislación extraterritorial	Prevención de exposición a normativas de terceros paises

Proveedores certificados ENS ALTO (2026):

Microsoft Azure — Regiones soberanas EU certificadas
Google Cloud Platform — Certificación ENS nivel Alto
RedIRIS — Nube privada/híbrida para la comunidad academica española

4. Ecosistema de Gobernanza y Productividad: Microsoft 365 vs. Google Workspace¶

4.1 Evaluación Comparativa¶

Dominio	Microsoft 365	Google Workspace
Arquitectura	Hibrida: apps escritorio + nube	Cloud-first: solo navegador
Operativa Offline	Excepcional: funcionalidad total sin conexión	Limitada: riesgo en entornos sin red
Datos masivos (Excel)	Lider: archivos masivos, VBA, macros	Sheets: buena colaboración, bajo rendimiento a escala
API de Integración	Microsoft Graph API (endpoint único unificado)	APIs segmentadas sin punto único
Seguridad/ENS	Entra ID + Defender + Intune (gobernanza granular)	Controles solidos, consola orientada a simplicidad

4.2 Elección Estrategica: Microsoft 365¶

[!TIP] Se designa Microsoft 365 como el eje de colaboración institucional, fundamentado en tres axiomas críticos para operaciones en ciencias marinas.

Axioma 1 — Inmunidad a la Desconexión: La recolección primaria ocurre a bordo de buques en altamar (campañas en Porcupine, Hatton) donde la conectividad es intermitente o inexistente. M365 permite uso offline completo; OneDrive sincroniza al recuperar red.

Axioma 2 — Transición Transparente via Graph API: Los investigadores continuaran depositando Excels en SharePoint. El backend usara Microsoft Graph API con webhooks para extraer, transformar e ingerir silenciosamente los datos sin perturbar el flujo de trabajo humano.

Axioma 3 — Identidad Estandarizada: Autenticación federada con Entra ID (ex Azure AD) para mapeo de permisos departamentales, satisfaciendo auditorías ENS.

flowchart LR
    subgraph Dptos ["Departamentos IEO"]
        D1["Pesquerias"]
        D2["Acuicultura"]
        D3["Medio Marino"]
    end

    subgraph M365 ["Microsoft 365"]
        SP["SharePoint"]
        OD["OneDrive"]
        EI["Entra ID"]
    end

    subgraph Backend ["Backend Centralizado"]
        GR["Graph API - Webhooks"]
        ETL2["ETL Automatizado"]
        DB["Data Lake"]
    end

    D1 -->|Excel + datos| SP
    D2 -->|Excel + datos| SP
    D3 -->|Excel + datos| OD
    SP --> GR
    OD --> GR
    GR --> ETL2 --> DB
    EI -->|autenticacion| Backend

    style GR fill:#3498db,color:#fff
    style DB fill:#f39c12,color:#fff

5. Diseño del Motor de IA Multimodal: CAG + RAG Estratificado¶

5.1 Desafios del RAG Puro en Reconocimiento de Imagenes¶

El enfoque puramente RAG presenta debilidades estructurales para el caso IEO:

Debilidad	Impacto
Latencia incompatible con tiempo real	La búsqueda vectorial iterativa por fotograma destruye la fluidez de la interfaz
Fragmentación de contexto	Inferir edad de un pez requiere asimilación holistica de distribuciones poblacionales, no fragmentos aislados
Sobrecarga arquitectonica	Modelos de embedding + vector DB + motores de búsqueda + orquestadores

5.2 El Paradigma CAG: KV-Caching como Memoria Permanente¶

CAG precarga la totalidad del conocimiento estatico en el prompt inicial del modelo, aprovechando ventanas de contexto masivas de los LLM modernos.

La innovación clave es el KV-Caching (Key-Value Cache): el LLM procesa el volumen fundacional una sola vez, almacena los estados de atención computados en cache, y reutiliza esta cache en milisegundos para inferencias subsiguientes — logrando tiempos 40% mas rápidos que RAG.

5.3 Arquitectura Seleccionada: Sistema Hibrido Estratificado (CAG + RAG)¶

[!IMPORTANT] La solución no es una elección dicotómica, sino un ecosistema híbrido estratificado gobernado por agentes de enrutamiento (Agentic RAG).

Nivel de Memoria	Paradigma	Contenido Asignado	Beneficio Critico
Cache L1 (Pre-Carga)	CAG	"Golden Knowledge": guias taxonomicas, taxonomias TAXON, firmas visuales de otolitos. Datos estables	Latencia sub-segundo. Análisis rápido y libre de alucinaciones
Almacenamiento L2	RAG	"The Library": Excels sincronizados via Graph API, publicaciones nuevas, datos ambientales recientes	Precisión y frescura sin recalcular la cache CAG

flowchart TB
    subgraph L1Cache ["L1 - Cache CAG"]
        GK1["Guias taxonomicas"]
        GK2["Taxonomias TAXON"]
        GK3["Firmas otolitos"]
        GK4["Colecciones historicas"]
    end

    subgraph L2RAG ["L2 - RAG Dinamico"]
        RD1["Excels recientes - Graph API"]
        RD2["Publicaciones nuevas"]
        RD3["Datos ambientales"]
    end

    CAM["Camara investigador"] --> Agent["Agente de Enrutamiento"]
    Agent -->|consulta estable| L1Cache
    Agent -->|necesita contexto fresco| L2RAG

    L1Cache --> LLM["LLM Multimodal"]
    L2RAG --> LLM
    LLM --> OUT["Identificacion: especie, edad, sexo"]

    style L1Cache fill:#f39c12,color:#fff
    style L2RAG fill:#9b59b6,color:#fff
    style Agent fill:#e74c3c,color:#fff
    style LLM fill:#2ecc71,color:#fff

Flujo Operativo: Cuando la cámara enfoque un espécimen en lonja, el agente del LLM extraera instantaneamente los marcadores de la cache CAG (especie, edad). Si la consulta requiere contexto ambiental reciente, el agente invocara la base vectorial RAG para añadir información cruzada.

6. Arquitectura del Backend: Quarkus + Dapr + LangChain4j (Java 25)¶

6.1 Evolución del Modelo de Concurrencia¶

Enfoque	Limitación	Solución Java 25
Servlet clásico	"Un hilo por solicitud" colapsa bajo concurrencia masiva	Virtual Threads (∞ conexiones)
WebFlux reactivo	Código complejo, estado debe externalizarse	Virtual Threads (código síncrono, escalabilidad reactiva)
Actor Model	Curva alta, coordinación manual, protocolos custom	Dapr (coordinación declarativa YAML)

[!IMPORTANT] Java 25 LTS con Virtual Threads elimina la necesidad principal de un modelo de actores. Dapr proporciona los building blocks de infraestructura distribuida de forma declarativa, permettiendo que el código Quarkus se centre exclusivamente en lógica de negocio.

6.2 Arquitectura Quarkus + Dapr¶

flowchart TB
    subgraph QuarkusApp ["Quarkus (Java 25) - Lógica de Negocio"]
        QK1["REST API (RESTEasy Reactive)"]
        QK2["WebSocket (Virtual Threads)"]
        QK3["LangChain4j AI Services"]
        QK4["ETL Pipeline"]
    end

    subgraph DaprSidecar ["Dapr Sidecar - Infraestructura Distribuida"]
        D1["Service Invocation"]
        D2["Pub/Sub (Kafka)"]
        D3["State Management (Redis)"]
        D4["Workflows (long-running)"]
        D5["Bindings (GSheets, SharePoint)"]
    end

    subgraph Capacidades ["Capacidades"]
        C1["Sesión por dispositivo (Dapr State)"]
        C2["Escalado automático (K8s HPA)"]
        C3["Tolerancia a fallos (K8s probes + Dapr retry)"]
        C4["Orquestación de pipelines (Dapr Workflows)"]
    end

    QK1 --> D1
    QK3 --> D1
    QK4 --> D5
    D4 --> C4
    D3 --> C1

    style QuarkusApp fill:#2ecc71,color:#fff
    style DaprSidecar fill:#9b59b6,color:#fff

Sesión por dispositivo: Estado de conexión persistido en Dapr State (Redis), sobrevive a reinicios del servicio.

Escalado elástico: Kubernetes HPA escala pods automáticamente; Dapr placement service redistribuye estado.

Tolerancia a fallos: Si un investigador pierde conexión en altamar, el estado de sesión persiste en Redis y se reanuda al recuperar conectividad.

6.3 Arquitectura por Capas¶

flowchart TB
    subgraph Quarkus ["Quarkus - Aplicación"]
        HTTP["Controllers REST"]
        SEC["Seguridad OIDC/OAuth2"]
        GRAPH["Microsoft Graph API"]
        LC4J["LangChain4j Services"]
    end

    subgraph Dapr ["Dapr - Middleware"]
        SI["Service Invocation → Ollama"]
        PS["Pub/Sub → Kafka"]
        WF["Workflows (ETL, LoRA)"]
        BND["Bindings (SharePoint, GSheets)"]
    end

    HTTP -->|request| SI
    SEC -->|tokens OIDC| HTTP
    GRAPH -->|webhooks SharePoint| BND
    LC4J -->|inferencia| SI
    BND --> WF

    style Quarkus fill:#2ecc71,color:#fff
    style Dapr fill:#9b59b6,color:#fff

Quarkus gestiona: controllers HTTP, seguridad OIDC/OAuth2 contra M365, servicios IA declarativos (LangChain4j).

Dapr gestiona: comunicación inter-servicio, integración con fuentes externas, orquestación de workflows, estado distribuido.

Ventaja clave: El código Java se centra en lógica de negocio (identificar especies, procesar datos). La coordinación de infraestructura es declarativa (YAML).

7. Frontend: Reconocimiento Visual en el Edge (React Native)¶

7.1 El Salto Evolutivo: JSI, Worklets y Visión Camera¶

La arquitectura del frontend se basa en React Native Visión Camera v4/v5, que abandona el viejo puente asíncrono para operar sobre JSI (JavaScript Interface) — acceso directo, sincrono y por referencia a objetos C++.

flowchart LR
    subgraph Movil ["App Movil - React Native"]
        CAM2["Camara Nativa"]
        FP2["Frame Processor - JSI/Worklets"]
        TFL["TFLite - Edge AI"]
        OCV["OpenCV - Pre-procesado"]
    end

    subgraph Server ["Backend - Quarkus + Dapr"]
        ACT["Actor de Sesion"]
        VLM2["Modelo CAG+RAG"]
    end

    CAM2 -->|60-120 FPS| FP2
    FP2 --> OCV --> TFL
    TFL -->|frame limpio| ACT
    ACT --> VLM2
    VLM2 -->|especie + edad + sexo| ACT
    ACT -->|resultado| FP2

    style FP2 fill:#e74c3c,color:#fff
    style TFL fill:#9b59b6,color:#fff
    style VLM2 fill:#2ecc71,color:#fff

Inferencia en el borde (Edge AI): El telefono no transmite todo el video al servidor. El modelo TFLite ejecuta pre-procesamiento y reconocimiento básico localmente a 60-120 FPS (~69ms latencia). Solo la captura limpia y aislada se envia al backend para el veredicto final del modelo CAG+RAG.

7.2 Componentes Clave del Pipeline Móvil¶

Componente	Función
`react-native-vision-camera`	Acceso a cámara via JSI, frame processors
`react-native-worklets-core`	Ejecución en hilo GPU/CPU de cámara
`react-native-fast-tflite`	Inferencia TensorFlow Lite acelerada por GPU (C++)
OpenCV (nativo)	Limpieza y pre-procesado de imagenes

7.3 El Escollo de la Web: Estrategia de Contingencia¶

[!WARNING] react-native-vision-camera usa APIs móviles exclusivas (CameraX, AVFoundation) y JSI. El soporte para navegadores web es completamente nulo.

Solución para la Web:

Capa	Tecnología Web
Captura de video	`navigator.mediaDevices.getUserMedia` (HTML5)
Inferencia local	WebAssembly (WASM) con módulos Rust/C++
ML en cliente	TensorFlow.js como alternativa a TFLite
Arquitectura React	Rutas dinámicas con `Platform.OS === 'web'`

flowchart TB
    subgraph Mobile ["Movil - iOS/Android"]
        M1["Vision Camera + JSI"]
        M2["Worklets + TFLite"]
        M3["GPU nativa"]
    end

    subgraph Web ["Web - Navegador"]
        W1["getUserMedia HTML5"]
        W2["WebAssembly - WASM"]
        W3["TensorFlow.js"]
    end

    subgraph Shared ["Codigo Compartido - React"]
        S1["Platform.OS routing"]
        S2["UI compartida"]
        S3["API Client"]
    end

    M1 --> S1
    W1 --> S1
    S1 --> S2 --> S3
    M2 --> M3
    W2 --> W3

    style Mobile fill:#3498db,color:#fff
    style Web fill:#e67e22,color:#fff
    style Shared fill:#2ecc71,color:#fff

8. Conclusiones Analíticas y Recomendaciones para el MVP¶

8.1 Directrices Estrategicas de Diseño¶

Area	Recomendación
Ecosistema Colaborativo	Microsoft 365 — operatividad offline en campañas, Graph API para ingesta, Entra ID para identidad
Soberanía y Seguridad	Cloud certificada ENS ALTO (Azure/GCP), cifrado CMEK, confinamiento jurisdiccional UE
Inferencia IA	Arquitectura Estratificada CAG+RAG — Golden Knowledge en cache L1, datos frescos via RAG en L2
Backend	Quarkus 3.20 LTS (Java 25) + Dapr (middleware: workflows, state, pub/sub, bindings) + LangChain4j (IA)
Frontend Móvil	React Native Visión Camera (JSI/Worklets) + Edge AI (TFLite C++)
Frontend Web	Fallback HTML5 getUserMedia + WebAssembly + TensorFlow.js

8.2 Visión de la Plataforma como Producto¶

flowchart TB
    subgraph Producto ["Suite de Proposito General"]
        P1["Motor IA Multimodal - CAG+RAG"]
        P2["Backend Cloud-Native - Quarkus+Dapr"]
        P3["Edge AI - Vision Camera"]
        P4["Integracion M365 - Graph API"]
        P5["Data Lake Soberano - ENS"]
    end

    subgraph Vertical ["Verticalizacion IEO"]
        V1["Reconocimiento de Especimenes"]
        V2["Análisis de Otolitos"]
        V3["Digitalizacion Colecciones"]
        V4["Integracion Departamental"]
    end

    P1 --> V1
    P1 --> V2
    P4 --> V3
    P2 --> V4
    P5 --> V4

    style Producto fill:#2c3e50,color:#fff
    style Vertical fill:#16a085,color:#fff

[!TIP] La plataforma se concibe como un producto de propósito general especializable, donde el IEO es la primera verticalización. Los componentes (Motor IA, Backend reactivo, Edge AI, integración M365, Data Lake soberano) son reutilizables para otras instituciones CSIC o centros de investigación con necesidades analogas.

Documentos Relacionados¶

Nivel	Documento	Descripción
N0 - Investigación	Análisis LLM Departamental	Modelos de IA por departamento, datasets públicos, tests
N0 - Investigación	Gobernanza de Datasets	Fuentes de datos, carga incremental, auditoría
N0 - Investigación	Bancos de Datos Animales	Fuentes internacionales, APIs, datasets de imágenes, almacenamiento
N1 - Arquitectura	Pivote Quarkus+Dapr	Decisión arquitectónica: Quarkus + Dapr + LangChain4j
N1 - Arquitectura	Viabilidad Pekko→Dapr	FSMs, escenarios, evaluación de migración
N1 - Arquitectura	MLOps y Workflows Agénticos	MLOps, Dapr Workflow, LangChain4j, sistema agéntico
N0 - Negocio	Visión de Plataforma	Presentación de alto nivel para el cliente
N1 - Arquitectura	Arquitectura del Sistema	Diseño técnico: ER, Docker, flujos, stack
N3 - Infraestructura	Docker Compose	Configuración del entorno local
N4 - Proyecto	Roadmap	Hitos, entregables y criterios de aceptación