Ficha técnica del sistema de Inteligencia Artificial

1Finalidad clínica

Apoyo formativo a la decisión clínica y al estudio continuado del médico residente y de plantilla en Atención Primaria, Urgencias y áreas hospitalarias adyacentes. Organización personal de la guardia (calendario, agenda, registro de incidentes asistenciales pseudonimizados con fines docentes).

NO se utiliza para:

• Emitir diagnósticos vinculantes ni sustituir el juicio profesional.
• Triaje automatizado de pacientes ni priorización clínica con efectos asistenciales.
• Recomendación terapéutica directa con efectos sobre el paciente sin validación por el médico responsable.
• Tratamiento de datos identificativos de pacientes (nombres, DNI/NIE, NHC).

2Tipo de algoritmo y modelos utilizados

El sistema enruta cada consulta a un modelo distinto según el tipo de tarea, mediante la Cloud Function askAi alojada en europe-west1. Las claves API se gestionan exclusivamente en servidor; el frontend nunca tiene acceso directo a los modelos.

Tipo de consulta	Modelo primario	Modelo fallback	Proveedor / Región
Educativo / Cuaderno IA	DeepSeek V4 Flash	Gemini 2.5 Flash-Lite	DeepSeek / Google · UE para fallback
Caso clínico estructurado	Qwen2.5-VL-72B	Gemini 2.5 Flash-Lite · Mistral Small	DashScope / OpenRouter / Google · UE para Gemini
Visión médica (Scan IA)	Qwen2.5-VL-72B	Gemini 2.5 Flash	DashScope / Google · UE para Gemini
Búsqueda RAG (cuaderno)	Embeddings embedding-001 (768 dims)	—	Google · europe-west1

Tipo de arquitectura: Large Language Models (LLM) con Mixture-of-Experts en el caso de DeepSeek V4, transformers densos para Gemini Flash-Lite y modelo de visión-lenguaje (Vision Transformer + LLM) para Qwen2.5-VL. Recuperación aumentada (RAG) con búsqueda semántica por similitud coseno sobre embeddings de 768 dimensiones.

Nota EU residency: DashScope Intl (Qwen) no garantiza routing exclusivo UE. Cuando se exige residencia estricta UE, el sistema fuerza Gemini directo en europe-west1 mediante modelOverride.

3Datos de entrenamiento y de inferencia (RAG)

Los modelos base (DeepSeek, Gemini, Qwen) han sido preentrenados por sus respectivos proveedores con corpus generalistas que incluyen literatura biomédica pública. La plataforma no realiza entrenamiento adicional ni fine-tuning de estos modelos.

Corpus de Recuperación Aumentada (RAG) propio:

Volumen

132 documentos clínicos verificados · 4 961 chunks indexados

Dimensiones

768 (Gemini embedding-001)

Tamaño índice

~52 MB (Float32) servido desde Google Cloud Storage

Tipo de fuentes

Guías de práctica clínica de sociedades científicas españolas y europeas, protocolos hospitalarios públicos, documentos clínicos elaborados o revisados por el autor (Dr. Carlos Galera Román, MFyC)

Última revisión

2026-04-29

Idioma

Español (ES). Soporte parcial AR/RO/FR/EN en desarrollo.

Datos del usuario procesados en cada consulta:

• Prompt textual introducido por el médico, sin identificadores directos.
• Para casos clínicos: edad, sexo, antecedentes relevantes, motivo de consulta, exploración y pruebas. Prohibido introducir nombre, DNI/NIE, NHC o cualquier identificador directo (CLAUDE.md §regla 2).
• Para Scan IA: imágenes médicas (radiología, dermatología, ECG, etc.) seudonimizadas. El usuario es responsable de eliminar metadatos identificativos antes de subir.

Limitación temporal de los modelos base: el conocimiento de cada LLM tiene una fecha de corte declarada por su proveedor. El RAG mitiga esta limitación inyectando el corpus propio en cada consulta.

4Rendimiento y validación

Como herramienta formativa y de organización personal, no se han realizado estudios de validación clínica de desempeño diagnóstico, porque la salida del sistema no se utiliza para diagnóstico vinculante ni para decisiones terapéuticas con efectos directos sobre el paciente.

Se realizan, en cambio, los siguientes controles operativos continuos:

• Healthcheck IA automatizado (Cloud Function healthCheckAi): verifica disponibilidad y latencia de cada proveedor cada 24 h.
• Gold standard evaluation (Cloud Function goldStandardEval): banco de preguntas-respuesta verificado por el autor para detectar regresiones tras cada actualización de modelo.
• Auditoría manual: el autor revisa periódicamente respuestas marcadas por usuarios como inadecuadas (ver §8 más abajo).
• Telemetría GA4: 7 eventos clínicos custom para detectar patrones de uso anómalos o respuestas problemáticas por dominio.

5Limitaciones conocidas

El sistema tiene limitaciones que el médico usuario debe conocer y considerar en todo momento (Manual OMC, Decálogo p. 107, puntos 3 y 5):

5.1 Limitaciones de los modelos base

• Alucinaciones: los LLM pueden generar afirmaciones plausibles pero falsas. El médico debe verificar todo dato crítico (dosis, indicación, contraindicación, vía) antes de aplicarlo.
• Sesgos de entrenamiento: los corpus generalistas sobrerrepresentan ciertas poblaciones (anglófonas, varones adultos sin comorbilidad). El rendimiento puede degradarse en pediatría, geriatría frágil, embarazo y poblaciones minoritarias.
• Fecha de corte: el conocimiento de cada modelo está congelado en su fecha de entrenamiento. Para guías o fármacos posteriores, el RAG actúa como fuente complementaria.
• "Caja negra": ningún modelo actual ofrece explicabilidad clínica completa de su razonamiento (Manual OMC §3.2 p. 84).

5.2 Limitaciones del RAG propio

• Cobertura focalizada en Atención Primaria, Urgencias y áreas hospitalarias frecuentes. Especialidades muy específicas pueden no estar representadas adecuadamente.
• Última actualización del corpus: 2026-04-29. Cambios posteriores en guías no se reflejan hasta el siguiente refresh.
• El recall del RAG depende de la formulación del prompt; preguntas muy genéricas pueden recuperar chunks subóptimos.

5.3 Limitaciones del Scan IA (visión)

• Calidad de imagen heterogénea: fotografías de móvil mal iluminadas, encuadres deficientes y artefactos pueden degradar la respuesta.
• Qwen2.5-VL-72B es un modelo generalista; no está específicamente entrenado para hallazgos sutiles (microcalcificaciones, nódulos pulmonares pequeños).
• Nunca debe emplearse como única lectura de pruebas de imagen con implicaciones diagnósticas o terapéuticas.

5.4 Limitaciones operativas

• Cuota diaria: 50 consultas IA/usuario/día.
• Rate limit: 30 peticiones/minuto por IP.
• Disponibilidad sujeta a la de los proveedores externos; el sistema implementa cadenas de fallback documentadas en functions/src/routing.ts.

6Clasificación regulatoria

Producto sanitario

NO aplica Conforme al Art. 4.1 del Reglamento (UE) 2017/745 (MDR), por su finalidad exclusivamente formativa y de organización personal. No está previsto para diagnóstico, prevención, monitorización, predicción o tratamiento.

Marcado CE

No procede

Clase MDR

Fuera de ámbito

EU AI Act

Sistema GPAI (general-purpose AI) bajo art. 53 · No se ha clasificado como Anexo III (alto riesgo) porque no toma decisiones automatizadas con efectos jurídicos significativos sobre pacientes ni profesionales.

Evaluación de impacto en derechos fundamentales (FRIA)

Documentada en docs/legal/fria-statement.md

Evaluación de impacto en protección de datos (DPIA)

Documentada en docs/legal/dpia.md

Propiedad intelectual

Reg. 00765-03096622 Art. 51 LPI Registro Propiedad Intelectual Región de Murcia · Autor único: Carlos Galera Román

7Requisitos técnicos e integración

Frontend

Vanilla JS + PWA · ~4 300 líneas index.html + módulos lazy-loaded

Service Worker

sw.js (versión actual visible en el footer del sitio)

Backend

Firebase (Auth, Firestore, Storage, Cloud Functions) · región europe-west1

Cloud Functions

askAi · searchRag · embedQuery · healthCheckAi · goldStandardEval · auditLog · reportIncident

App Check

Enforce activo en Firestore, Functions y Storage (CLAUDE.md §regla 6)

Cifrado en tránsito

TLS 1.3 obligatorio (HSTS, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin)

Logs y trazabilidad

Colección auditLogs en Firestore · retención mínima 6 meses (AI Act art. 26.6) · purga programada por scheduledJobs

Observabilidad

Sentry (errores frontend) · Cloud Logging (Functions) · GA4 (eventos clínicos custom)

Interoperabilidad

Export FHIR experimental disponible vía fhirExport (no integración nativa con HCE de centros sanitarios; el sistema no accede a historias clínicas)

Hosting frontend

GitHub Pages (area2cartagena.es) · Cloudflare Pages (medikai.es)

8Procedimiento de actualización y gobernanza

El sistema se actualiza periódicamente. Cada cambio significativo en modelos, corpus RAG o flujos clínicos se documenta y se evalúa antes de su despliegue (Manual OMC §2.9 p. 32).

8.1 Actualización del software

• Cada release lleva versión semver visible en sw.js y en el footer.
• Toda modificación entra por Pull Request en el repositorio source-of-truth carlosgalera-a11y/Cartagenaeste.
• Branch protection: PR requerido, force-push bloqueado, enforce_admins=true.
• Tras merge a main, sincronización automática a los mirrors públicos vía scripts/sync-mirrors.sh.

8.2 Actualización de modelos IA

• Cambios de modelo primario o fallback se documentan en el changelog público de versiones IA con fecha y motivo.
• Cada cambio se valida contra el goldStandardEval antes de despliegue.
• El usuario puede consultar la cadena vigente en cualquier momento desde el changelog público.

8.3 Gestión de incidentes

• Cada respuesta IA incluye un botón "Reportar respuesta inadecuada" que escribe en la colección incidents y notifica al autor por correo.
• Procedimiento de triaje, corrección y comunicación documentado en docs/runbook.md.
• Conforme al Art. 26.5 AI Act, los incidentes graves se notifican al proveedor del modelo correspondiente y, en su caso, a la autoridad competente.

8.4 Supervisión humana real (no nominal)

• El médico mantiene siempre la "última palabra" (Manual OMC §2.3 cap. III).
• El sistema no toma decisiones de forma autónoma; cada salida es una propuesta que el profesional acepta, modifica o descarta.
• El usuario puede ejercer objeción de conciencia tecnológica y rechazar el uso del sistema en cualquier momento (Manual OMC §2.4 cap. III, p. 80).

9Información para el paciente

El médico que utiliza esta plataforma asume, en su relación con el paciente, las obligaciones de transparencia previstas en el Manual OMC (garantía 7, p. 15) y en el Art. 13 del Reglamento (UE) 2024/1689.

Para facilitar el cumplimiento, se pone a su disposición un folleto descargable que puede entregar o colocar en su consulta: 📄 Información sobre el uso de IA en mi consulta (PDF).

10Marco normativo de referencia

• Manual de Buenas Prácticas para la Inteligencia Artificial en Medicina · Organización Médica Colegial de España (CGCOM, 2026)
• Reglamento (UE) 2024/1689 del Parlamento Europeo y del Consejo (AI Act), de 13 de junio de 2024
• Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo (RGPD)
• Reglamento (UE) 2017/745 sobre productos sanitarios (MDR)
• Reglamento (UE) 2025/327 del Espacio Europeo de Datos de Salud (EEDS)
• Convenio de Oviedo sobre Derechos Humanos y Biomedicina (CETS 164, 1997)
• Código de Deontología Médica · CGCOM 2022
• Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de derechos digitales
• Ley 41/2002 reguladora de la autonomía del paciente
• Texto refundido de la Ley de Propiedad Intelectual (RDL 1/1996), en particular Art. 51