AI Act: qué entra en vigor el 2 de agosto de 2026

/en
AI Act · Julio 2026

AI Act 2 de agosto: lo que aplica de verdad (y lo que se ha ido a 2027).

Durante meses el 2 de agosto iba a ser "el día del alto riesgo". Ya no. El Digital Omnibus lo empujó a diciembre de 2027 y dejó en pie el Article 50: chatbots que se identifican, contenido generado por IA marcado en machine-readable y deepfakes etiquetados. Si tu producto habla, escribe o dibuja, esta semana hay tarea.

8 min de lectura ●Cumplimiento IA ●

El calendario del Reglamento (UE) 2024/1689 — el AI Act — se movió el 29 de junio y muchos equipos técnicos no lo tienen fichado todavía. El Digital Omnibus, aprobado ese día por el Consejo de la UE, pospuso las obligaciones de alto riesgo del Anexo III del 2 de agosto de 2026 al 2 de diciembre de 2027. Lo que no se movió es el Article 50 de transparencia: sigue en el 2 de agosto de 2026.

Las tres fechas que importan
2 ago 2026Aplica ya
Article 50 · Transparencia. Chatbots que se identifiquen, contenido generado por IA marcado machine-readable, deepfakes etiquetados. Multas hasta 15 M€ o 3 % de facturación mundial.
2 dic 2026Este otoño
Article 5 · Nueva prohibición. Se prohíben los sistemas de IA que generan imágenes íntimas no consentidas. Aplica a todos los operadores, con o sin alto riesgo.
2 dic 2027+16 meses
Anexo III · Alto riesgo. RRHH, crédito, biometría, educación, servicios esenciales. Retrasado desde el 2 de agosto de 2026 por el Digital Omnibus.
01 · Contexto

Qué se suponía que iba a pasar el 2 de agosto

Hasta el 29 de junio, el 2 de agosto era la fecha del Anexo III: biometría, RRHH, decisiones de crédito, educación reglada, infraestructuras críticas, aplicación de la ley y servicios esenciales.

Para cualquier operador con un sistema en esa lista, tocaba dejar instrumentado en producción: gestión de riesgos, calidad y sesgos de datos, documentación técnica, logging automático de eventos, transparencia hacia el usuario, supervisión humana, ciberseguridad y monitorización post-mercado. Todo demostrable sobre tu propio código y tu propia infra.

Ya no toca en agosto. Solo queda el Article 50.

02 · Digital Omnibus

Qué cambió el 29 de junio

El Digital Omnibus es el paquete de simplificación digital que aprobó el Consejo de la UE el 29 de junio. Es una modificación del propio AI Act. La razón real, aunque no se diga tan claro: ni las empresas ni las autoridades nacionales iban a llegar en agosto con las estructuras técnicas y de supervisión listas.

Su medida más visible: las obligaciones de alto riesgo del Anexo III, que iban a entrar en vigor el 2 de agosto de 2026, quedan aplazadas al 2 de diciembre de 2027. Dieciséis meses más.

No es amnistía

Es aplazamiento, no exención. Las obligaciones no cambian: cambia cuándo son exigibles. Si tu sistema es alto riesgo del Anexo III, el trabajo técnico es el mismo, con 16 meses más para hacerlo. En cuanto abres el proyecto de verdad, ese margen se acorta rápido.

Lo que no cambió con el Omnibus es igual de importante: el Article 50 de transparencia mantiene su fecha. Y la nueva prohibición del Article 5 sobre imágenes íntimas no consentidas también sigue en calendario, para el 2 de diciembre de 2026.

03 · Article 50

Las tres cosas que sí entran en vigor

El Article 50 del Reglamento (UE) 2024/1689 impone obligaciones de transparencia a proveedores y a operadores (deployers), con independencia de si el sistema es alto riesgo o no. Son tres bloques concretos.

50 · 1

Chatbot que se identifica

Los sistemas de IA que interactúan con personas deben avisar al usuario de que habla con una IA, salvo que sea obvio por el contexto. Aplica a chatbots, asistentes conversacionales, IVR con voz sintética y agentes en apps. En la práctica: un aviso inicial visible, no una nota al pie del footer.

50 · 2

Marcado de contenido generado

Los proveedores de IA generativa (texto, imagen, audio, vídeo) deben marcar sus outputs en formato machine-readable para que se puedan detectar como generados o manipulados. La obligación es del proveedor del modelo, no del usuario final que pide la imagen.

50 · 4

Deepfakes etiquetados

Los deployers que usen IA para crear deepfakes (imagen, audio o vídeo que se parece a una persona real, objeto o evento) deben etiquetar el contenido como generado o manipulado. Hay excepciones para uso artístico, satírico y de aplicación de la ley, pero son estrechas.

Ámbito extraterritorial

El Article 50 aplica a cualquier sistema de IA que se ponga en el mercado o se use dentro de la UE, sin importar dónde se entrenó ni dónde esté establecido el proveedor. Un modelo entrenado en California y servido en SaaS a clientes europeos entra. Estar fuera de la UE no libra de la multa si tus outputs entran aquí.

04 · Sanciones

Cuánto cuesta ignorarlo

El AI Act ordena las sanciones en tres tramos (Article 99). Circula mucho titular con la cifra grande, pero no se aplica a todo por igual.

35 M€ · 7%
Prácticas prohibidas
(Article 5)
15 M€ · 3%
Article 50 y otras
infracciones
7,5 M€ · 1%
Información incorrecta
a la autoridad

Las infracciones del Article 50 caen en el segundo tramo: hasta 15 millones de euros o el 3 % de la facturación anual mundial, la que sea mayor. La supervisión y las sanciones las lleva la autoridad nacional competente de cada estado miembro. En España es la AESIA, con sede en A Coruña y operativa desde 2023.

05 · Comprobación rápida

¿El Article 50 te aplica?

Tres preguntas y sabes si el 2 de agosto te obliga a mover ficha o si puedes respirar hasta 2027.

Comprobación en 3 clics

Sin telemetría, sin cookies, sin enviar nada. Todo se resuelve en el navegador.

1. ¿Tu producto tiene algún chatbot, asistente conversacional o IVR con voz sintética que hable con personas reales?

2. ¿Tu producto genera texto, imágenes, audio o vídeo con IA que ven o descargan usuarios finales?

3. ¿Vuestro producto crea o distribuye deepfakes — imagen, audio o vídeo que se parece a una persona real, objeto o lugar?

Sí, en varios frentes.

Con dos o tres bloques marcados tienes obligación de chatbot disclosure, watermarking y/o etiquetado de deepfakes. Es el escenario más denso: hay que tocar UI, tocar el pipeline de generación y dejar logs auditables. Prioridad de una semana: empezar por lo que ve el usuario.

Sí, en un bloque concreto.

Tienes una obligación clara. Si el "sí" fue el chatbot, la parte pesada es UX: aviso inicial visible más un log. Si fue generación de contenido, es técnica: C2PA + watermark + logging. Si fue deepfakes, es de proceso: etiquetado sistemático en el pipeline de publicación.

No, puedes respirar.

Sin chatbot, sin contenido generado por IA cara al usuario y sin deepfakes, el Article 50 no te aplica. Ojo: si tu IA cae en el Anexo III (biometría, RRHH, crédito, educación, infraestructuras críticas, servicios esenciales) tienes cita el 2 de diciembre de 2027 con las obligaciones de alto riesgo. Y eso es bastante más trabajo que un aviso de chatbot.

06 · Watermarking

Por qué ninguna tecnología de watermarking cumple sola

La obligación 50(2) — marcar contenido generado por IA en formato machine-readable — parece que se resuelve con una etiqueta. No. El reglamento pide cuatro cosas al mismo tiempo que ninguna tecnología conocida cumple sola: imperceptibilidad (sin degradar el contenido), robustez (sobrevivir a compresión, edición, capturas), detectabilidad (verificable aguas abajo) y trazabilidad (identificar generador y versión).

La solución práctica no es una tecnología, son tres capas — cada una cubriendo lo que la anterior no aguanta.

Capa 1

Metadatos C2PA

Estándar de content provenance impulsado por Adobe, Microsoft y Sony, entre otros. Firma criptográficamente metadatos que viajan con el fichero: quién lo generó, con qué modelo, cuándo. Sobrevive a la compresión, pero desaparece al hacer captura de pantalla o al re-comprimir sin firmar.

Capa 2

Watermark imperceptible

SynthID (Google DeepMind) para imágenes y audio, técnicas similares para texto y vídeo. Modifica de forma imperceptible el output para que un detector lo reconozca. Sobrevive a captura de pantalla, pero se degrada con manipulaciones agresivas, recorte fuerte o mezcla de fuentes.

Capa 3

Logging en el generador

Registro auditado en el lado del proveedor: qué se generó, cuándo, con qué prompt, qué modelo y qué versión. La menos vistosa y la más importante — la única que sigue estando cuando las capas 1 y 2 se han caído por el camino.

Cómo lo hacemos en SIXE

La capa 3 es donde el on-premise deja de ser un argumento comercial y empieza a valer para algo. Sobre tu propio stack de inferencia registras cada prompt, cada output y cada versión de modelo — sin depender de que un proveedor SaaS te exporte sus logs cuando le viene bien.

07 · Checklist

Lo mínimo que tienes que dejar hecho

Si el quiz te dijo que el Article 50 te aplica, esta es la lista corta. Marca lo que ya tengas; lo que quede sin marcar es tu backlog.

Checklist Article 50 · 7 puntos

0/7 completos
  • Aviso "hablas con IA" en tus chatbotsUn mensaje inicial visible, no un asterisco en el footer. Aplica también a asistentes de voz e IVR sintéticos.
  • Log de sesión del chatbotFecha, sistema, versión del modelo, ID de sesión. Si la autoridad pregunta, tienes que poder demostrar que el aviso salió.
  • C2PA en los outputs generadosMetadatos firmados en imágenes, audio y vídeo. Es la capa 1 del watermarking.
  • Watermark imperceptibleSynthID o equivalente para lo que C2PA pierde en cuanto alguien hace captura y lo reenvía por WhatsApp.
  • Logging en el generadorRegistro auditable de prompts, outputs, modelo y versión en tu lado. El que menos ganas dan de escribir y el que salva la conversación con la autoridad.
  • Etiquetado de deepfakes en el pipelineSi generas o distribuyes contenido que se parece a personas reales, etiquétalo en el propio flujo de publicación. No lo dejes al criterio del editor de turno.
  • Documento interno de conformidadMedia página que explique qué obligaciones aplican a qué sistemas, quién es responsable y dónde están los logs. Es donde encaja de forma natural la gobernanza de ISO 42001.
Los siete marcados. Si es de verdad y no autoengaño, cumples el mínimo del Article 50.
08 · Diciembre 2026

La otra fecha que casi nadie mira

Cuatro meses después, el 2 de diciembre de 2026, se activa una prohibición nueva añadida por el Digital Omnibus al Article 5: los sistemas de IA que generan imágenes íntimas no consentidas pasan al catálogo de prácticas prohibidas.

Al ser prohibición no admite matices por tamaño ni por nivel de riesgo del sistema. Aplica a todos los operadores del mercado europeo — proveedores, deployers, importadores, distribuidores — sin excepción. No hay Anexo intermedio ni periodo de gracia. Se prohíbe.

Afecta de forma directa a generadores de imágenes de personas reales sin consentimiento, apps de face-swap sobre contenido íntimo y herramientas de nudify, que han proliferado sin freno en los dos últimos años. Los modelos generalistas caen por la vía de los usos previsibles: si tu modelo se puede usar razonablemente para eso, las salvaguardas técnicas dejan de ser opcionales.

09 · Arquitectura

Por qué on-premise facilita el papeleo

El Article 50 aplica esté la IA donde esté. Pero demostrar que cumples es donde el on-premise juega a tu favor:

  • Los logs viven en tu sistema, con tu política de retención. No dependes del audit trail de un tercero ni de los límites de exportación de un dashboard SaaS.
  • La documentación técnica del modelo — pesos, procedencia del entrenamiento, evaluaciones, versión — la controlas tú. Nada depende de tu proveedor cloud.
  • El gobierno de datos se demuestra sobre datos que no han salido de tu perímetro. En sanidad, banca y sector público es requisito de facto — el AI Act solo lo pone por escrito.
  • Los agentes auditables (OPA, LangChain, CrewAI) encajan de forma natural con la supervisión humana que el alto riesgo va a pedir en 2027.
FAQ

Preguntas frecuentes estos días

¿Qué entra en vigor del AI Act el 2 de agosto de 2026?

Las obligaciones de transparencia del Article 50. Los chatbots deben avisar al usuario de que hablan con una IA; los contenidos generados por IA (texto, imagen, audio, vídeo) deben ir marcados en formato machine-readable; los deepfakes deben ir etiquetados como generados o manipulados. El incumplimiento se sanciona con multas de hasta 15 millones de euros o el 3 % de la facturación anual mundial (Article 99.4).

¿Se ha retrasado la aplicación a los sistemas de alto riesgo?

Sí. El Digital Omnibus, aprobado por el Consejo de la Unión Europea el 29 de junio de 2026, pospuso las obligaciones del Anexo III (biometría, RRHH, crédito, educación, infraestructuras críticas, aplicación de la ley, servicios esenciales) del 2 de agosto de 2026 al 2 de diciembre de 2027.

El Article 50 no ha sido pospuesto y sigue aplicando el 2 de agosto de 2026.

¿Qué es el Digital Omnibus?

El paquete de simplificación digital aprobado por el Consejo de la Unión Europea el 29 de junio de 2026 que retrasa la aplicabilidad de varias obligaciones del AI Act y aclara aspectos operativos del reglamento. La medida más relevante es el aplazamiento del alto riesgo del Anexo III al 2 de diciembre de 2027.

¿Cuánto cuesta incumplir el Article 50?

Hasta 15 millones de euros o el 3 % de la facturación anual mundial del ejercicio anterior, la cifra que sea mayor (Article 99.4). Es el segundo tramo de sanciones. El primero (35 M€ o 7 %) se reserva a las prácticas prohibidas del Article 5 — otra cosa distinta.

¿Cómo se cumple lo del marcado machine-readable?

Con un enfoque en tres capas: metadatos C2PA firmados criptográficamente en el fichero; watermark imperceptible tipo SynthID para lo que C2PA pierde al hacer captura de pantalla; y logging auditado en el propio generador. Ninguna capa sola cubre los cuatro requisitos que exige el reglamento — imperceptibilidad, robustez, detectabilidad y trazabilidad.

¿Qué prohibición nueva entra en vigor el 2 de diciembre de 2026?

El Article 5 añade una nueva prohibición: los sistemas de IA que generan imágenes íntimas no consentidas. Aplica a todos los operadores con independencia del nivel de riesgo del sistema.

¿Aplica si mi IA es on-premise?

Sí. El AI Act aplica a cualquier sistema puesto en el mercado o en servicio en la UE, sin importar dónde esté desplegado ni dónde esté establecido el proveedor. Que la IA sea on-premise no exime — pero facilita la parte de demostrar: logging, trazabilidad y auditoría son tuyos, no de un tercero.

¿AI Act, NIS2 e ISO 42001 son lo mismo?

No, pero se apoyan. NIS2 es la directiva europea de ciberseguridad — obliga a gestionar riesgos y notificar incidentes. ISO/IEC 42001 es la norma internacional de gestión de sistemas de IA — un marco de gobernanza. El AI Act es la ley europea con obligaciones concretas por nivel de riesgo. Los tres se solapan en gobierno de datos, trazabilidad y logging: hacer bien uno cubre parte del siguiente.

Cumplimiento técnico

¿Tu producto habla, escribe o dibuja con IA?

Revisamos tus chatbots, montamos el watermarking en capas y dejamos el logging auditable. La parte técnica la llevamos nosotros; la interpretación jurídica queda con tu abogado.

Consultoría AI Act → Ver soluciones IA

Qué almacenamiento elegir para IA y HPC: Ceph, Lustre o DAOS

/en
Infraestructura · Almacenamiento IA / HPC · Open Source

Almacenamiento para IA y HPC en 2026: Ceph, Storage Scale, Lustre, DAOS y BeeGFS.

Montas un clúster de GPUs que cuesta como un edificio y luego decides dónde viven los datos. Esa decisión —el sistema de ficheros— es la que marca si tus GPUs calculan o esperan. Mapeamos los cinco grandes, para qué sirve cada uno y cómo no equivocarte.

12 min lectura●Comparativa técnica●

Hay una escena que se repite cuando revisamos una plataforma de IA o HPC. El cliente nos enseña, con razón orgullosa, el clúster de GPUs recién comprado. Números impresionantes de TFLOPS. Y entonces preguntamos lo aburrido: «¿y de dónde leen los datos?». La respuesta, demasiadas veces, es un NAS por NFS montado en una esquina.

Comprar ocho GPUs que cuestan como un piso en Madrid y alimentarlas con un NFS es el equivalente digital a ponerle a un Fórmula 1 el depósito de una moto: la potencia está toda ahí, pero se pasa el día en boxes. El almacenamiento es lo que decide si esas GPUs trabajan o esperan — y elegirlo bien empieza por saber qué opciones hay y para qué sirve cada una.

1 y 2
Puestos de DAOS en la
IO500 de producción (SC25)
×4
Score de esos dos frente
a los 30 siguientes
#1
Lustre, el FS más extendido
en supercomputación
50+ PB
Ceph desplegado
en el CERN
01 · El vocabulario que decide la arquitectura

Cuatro conceptos antes de comparar nada

El almacenamiento distribuido acumula jerga rápido y las etiquetas de marketing no siempre ayudan. Antes de entrar en materia, conviene fijar cuatro ideas — porque son las que de verdad separan a un sistema de otro cuando toca elegir.

POSIX paralelo vs. objeto Un FS paralelo (rutas, permisos, open()/read()) reparte cada fichero entre cientos de servidores que lo sirven a la vez: es lo que espera el software HPC clásico. El almacenamiento de objetos no tiene directorios, sino claves y objetos vía API S3: es el idioma de los data lakes y de la IA moderna.
Ancho de banda vs. IOPS El HPC clásico quiere GB/s secuenciales para volcar checkpoints enormes. El entrenamiento de IA suele querer lo contrario: millones de ficheros diminutos leídos al azar, donde mandan los IOPS y el rendimiento de metadatos. Casi ningún sistema es el rey de las dos cosas.
El metadato manda El servidor de metadatos (MDS) es el que sabe dónde está cada cosa. En cargas de IA con millones de ficheros pequeños, suele ser el primer cuello de botella, antes que el disco. Muchas migraciones fracasan por dimensionar bien el disco y olvidar el metadato.
GPUDirect Storage Un camino directo entre el almacenamiento y la memoria de la GPU, sin pasar por la CPU ni por un buffer intermedio en RAM. Menos latencia, menos CPU quemada moviendo bytes y GPUs que dejan de esperar. Es la pieza que la IA moderna exige al almacenamiento.
La distinción que importa

El mejor almacenamiento es el que encaja con tu carga dominante. Si tu día a día son simulaciones que escriben ficheros gigantes, buscas ancho de banda secuencial. Si es entrenar modelos sobre millones de imágenes, buscas metadatos rápidos e IOPS. Confundir las dos cosas es el error de diseño más caro que vemos.

02 · Los cinco contendientes

¿Quién juega en qué liga?

Aquí están los cinco sistemas que dominan el almacenamiento serio para IA y HPC. No hay un ganador único: cada uno tiene un punto dulce. Las barras comparan, de forma orientativa, dos ejes que casi siempre están en tensión: el rendimiento pico que puede alcanzar y la facilidad de operarlo en el día a día.

Ceph
Unificado · objeto + bloque + fichero Rendimiento pico Versatilidad / operación
La navaja suiza
Storage Scale
POSIX paralelo · GPFS · IBM Rendimiento pico Soporte / operación
El caballo enterprise
Lustre
POSIX paralelo · el del TOP500 Rendimiento pico Facilidad de operación
El estándar HPC
DAOS
Objeto / KV sobre NVMe Rendimiento pico Facilidad de operación
El cohete de la IO500
BeeGFS
POSIX paralelo · fácil de montar Rendimiento pico Facilidad de operación
El de despliegue rápido
Barras orientativas · el mejor sistema es el que encaja con tu carga, no el de la barra más larga
03 · La tabla que puedes enseñar en una reunión

Cinco sistemas, de un vistazo

Lo esencial de cada uno: qué tipo de almacenamiento es, dónde brilla, con qué licencia se distribuye y en qué versión está en producción a mediados de 2026.

SistemaTipoPunto dulceLicenciaVersión (2026)
CephUnificadoPlataformas híbridas IA + HPC, nubes privadas, data lakes S3. Objeto, bloque y fichero desde un mismo clúster.Open source LGPL20.2.2 «Tentacle» (jun 2026)
IBM Storage ScalePOSIX paraleloHPC empresarial con soporte y SLA, IA sobre NVIDIA DGX BasePOD/SuperPOD, alto rendimiento «llave en mano».Comercial IBM5.2.x
LustrePOSIX paraleloSupercomputación clásica de máximo ancho de banda. El estándar del TOP500 cuando hay equipo que sepa operarlo.Open source GPLv22.17 (dic 2025)
DAOSObjeto / KVRendimiento extremo sobre NVMe puro. Lo más rápido de la IO500, para cargas donde la latencia lo es todo.Open source BSD2.6
BeeGFSPOSIX paraleloClústeres HPC medianos y grupos de investigación que quieren buen rendimiento sin un equipo de almacenamiento dedicado.Community + Enterprise8.3.x
04 · Uno a uno

Qué hace bien cada uno (y qué no)

Ceph — el que lo hace casi todo

Ceph es la navaja suiza del almacenamiento distribuido open source: sirve objeto (S3 vía RGW), bloque (RBD) y fichero (CephFS) desde el mismo clúster, se autorreplica y escala sumando nodos. En IA eso se traduce en RBD para las máquinas de entrenamiento, S3 para el data lake y CephFS para acceso paralelo — con integración nativa en OpenStack y Kubernetes. No es el rey del rendimiento pico en HPC extremo, pero su versatilidad no tiene rival, y despliegues como los 50+ PB del CERN demuestran que aguanta escalas serias. La versión 20.2.2 «Tentacle» (junio 2026) trae Crimson para pools con erasure coding y mejoras de cifrado en RGW. Es, además, el ganador natural del hueco que dejó MinIO al pasar a «maintenance mode» a finales de 2025 — lo contamos en nuestra guía Ceph vs MinIO 2026. En SIXE lo tocamos a diario: Ceph para IA & HPC y formación oficial de Ceph.

IBM Storage Scale (GPFS) — rendimiento con SLA

Antes GPFS, luego Spectrum Scale y hoy IBM Storage Scale: el mismo caballo de batalla con tres nombres. Es un FS paralelo POSIX maduro, con soporte enterprise, que en su versión 5.2.x integra GPUDirect Storage de NVIDIA y certificación para plataformas DGX BasePOD/SuperPOD y Grace Blackwell. Es la elección cuando quieres el rendimiento de un FS paralelo pero sin depender de que tu equipo sepa reconstruir un Lustre a las tres de la mañana: pagas licencia, ganas SLA. Montamos infraestructura HPC con Storage Scale + Spectrum LSF/SLURM y damos formación de administración de Storage Scale.

Lustre — el estándar del TOP500

Lustre sigue siendo, con diferencia, el sistema de ficheros más extendido en supercomputación: mueve una fracción enorme de los grandes centros de cálculo del mundo. Da un ancho de banda secuencial altísimo y escala a exabytes. El precio es la operación: no es «instalar y olvidar», y requiere expertise real para tunearlo y recuperarlo. La versión 2.17 (diciembre 2025) sigue esa línea, con la 2.18 preparando erasure coding a nivel de fichero (FLR-EC) y compresión en cliente. Si vienes de Lustre y buscas soporte comercial, escribimos sobre migrar de Lustre a IBM Storage Scale.

DAOS — el cohete que resucitó

DAOS es la respuesta a «¿y si tiramos POSIX a la basura y diseñamos para NVMe desde cero?». El resultado: ocupa los puestos 1 y 2 de la IO500 de producción (Argonne y LRZ, SC25), y 16 de los 30 primeros del ranking completo corren DAOS. Nació atado a la memoria Optane de Intel; cuando Intel mató Optane, muchos lo dieron por muerto. Pero desde la versión 2.6 (julio 2024) funciona solo con NVMe SSD y sigue muy vivo. Hoy lo gobierna la DAOS Foundation bajo la Linux Foundation (Argonne, HPE, Google Cloud, Intel), tras la cesión del equipo de Intel a HPE en 2024. Es la opción de máximo rendimiento para quien tiene NVMe puro y una carga que lo justifique; no un reemplazo general.

BeeGFS — el fácil de vivir

BeeGFS es el FS paralelo que prioriza que puedas desplegarlo un martes por la tarde sin un doctorado en almacenamiento. Da muy buen rendimiento para clústeres medianos y es el favorito de muchos grupos de investigación por su sencillez. Ojo con un cambio importante: desde BeeGFS 8 la Community Edition sigue siendo gratuita pero exige generar una licencia comunitaria (beegfs license), y las funciones enterprise quedan tras licencia de pago. La versión estable en 2026 es la 8.3.x.

El patrón que se repite

Fíjate en la tensión: Lustre y DAOS dan el rendimiento máximo pero exigen equipo experto. Storage Scale compra ese rendimiento con licencia y soporte. Ceph y BeeGFS renuncian a algo de pico a cambio de que la vida sea más fácil. Ninguna opción es gratis: cada una cambia rendimiento por sencillez, o licencia por soporte.

05 · El eje que de verdad decide

¿Tu carga es HPC clásica o es IA?

Antes de mirar marcas, mira tu carga. Lo que de verdad ordena la decisión es qué le vas a pedir al almacenamiento. Estos son los dos perfiles y lo que cada uno necesita.

HPC clásico
  • Simulación, CFD, dinámica molecular, meteorología
  • Escribe checkpoints enormes de forma secuencial
  • Lo que pide: GB/s de ancho de banda sostenido
  • Ficheros grandes, acceso más predecible
  • Encaja con: Lustre, Storage Scale, BeeGFS
Carga de IA / ML
  • Entrenamiento e inferencia sobre datasets masivos
  • Lee millones de ficheros pequeños al azar
  • Lo que pide: IOPS, metadatos rápidos y GPUDirect
  • Necesita alimentar GPUs sin que se queden esperando
  • Encaja con: DAOS, Storage Scale, Ceph (S3)

La mayoría de plataformas modernas mezclan las dos cosas — por eso el almacenamiento open source para IA y HPC tiende a arquitecturas híbridas: un FS paralelo para la parte de cálculo y objeto S3 para el data lake, a menudo conviviendo sobre Ceph + OpenStack + Kubernetes.

06 · Cómo elegir sin arrepentirte

Cuatro pasos antes de firmar nada

Define tu carga dominante

Antes de mirar productos, mide. ¿Escribes pocos ficheros gigantes o lees millones de pequeños? ¿Manda el ancho de banda o los metadatos? Esa única respuesta ya descarta la mitad de las opciones. Y no te fíes solo del hoy: dimensiona para la carga que tendrás cuando el proyecto de IA crezca.

Decide: open source con equipo, o soporte con SLA

Lustre y DAOS son gratis de licencia pero caros de operar: necesitas gente que los conozca. Storage Scale invierte esa ecuación: pagas licencia y compras tranquilidad. Ceph y BeeGFS quedan en medio. La pregunta honesta es: ¿tienes —o quieres tener— un equipo de almacenamiento?

Mira el ecosistema que ya tienes

¿Ya corres OpenStack o Kubernetes? Ceph encaja como un guante. ¿Tienes NVIDIA DGX / BasePOD? Storage Scale está certificado. ¿NVMe puro y sed de latencia? DAOS. El mejor almacenamiento suele ser el que menos fricción crea con lo que ya está en producción.

Prueba a escala antes de casarte

Un benchmark con cuatro nodos no predice el comportamiento con cuarenta. Prueba con tu carga real, no con la sintética del datasheet, y presta atención al metadato bajo concurrencia. Aquí la experiencia previa ahorra meses — y una compra equivocada de seis cifras.

Dónde entra SIXE

Diseñar la capa de almacenamiento de una plataforma de IA o HPC, comparar Ceph, Storage Scale, Lustre, DAOS o BeeGFS para tu caso, o migrar de una a otra sin perder datos ni noches de sueño — en SIXE llevamos más de 15 años en el cruce entre almacenamiento distribuido, IBM Power y open source. Ver soporte de Ceph e IBM Storage.

Resumen

Lo esencial en 5 puntos

Para llevarse de este post

→ El almacenamiento decide si tus GPUs trabajan o esperan. Es tan estratégico como el propio clúster de cálculo.

→ No hay «el mejor»: hay el mejor para tu carga. HPC clásico pide ancho de banda; la IA pide metadatos, IOPS y GPUDirect.

→ DAOS manda en rendimiento (1º y 2º de la IO500), Lustre en prevalencia, Storage Scale en soporte enterprise.

→ Ceph es la opción versátil para arquitecturas híbridas IA + HPC; BeeGFS, la más fácil de desplegar.

→ Antes de elegir: define la carga, decide open source vs. SLA, mira tu ecosistema y prueba a escala real.

FAQ

Preguntas frecuentes

¿Qué es mejor para IA, Ceph o Lustre?

Depende de la carga. Lustre da más ancho de banda secuencial y es el estándar en supercomputación clásica, pero requiere expertise para operarlo. Ceph es más versátil: ofrece objeto S3, bloque y fichero a la vez, se integra con OpenStack y Kubernetes, y su almacenamiento de objetos encaja con los data lakes de IA. Para entrenamiento masivo con checkpoints enormes, Lustre o Storage Scale; para plataformas híbridas y data lakes, Ceph.

¿DAOS está listo para producción?

Sí, en su nicho. Ocupa los puestos 1 y 2 de la lista de producción de la IO500 (SC25) y lo gobierna la DAOS Foundation bajo la Linux Foundation. Desde la versión 2.6 (julio 2024) funciona solo con NVMe SSD, sin la memoria Optane. Es la opción de máximo rendimiento, pero exige hardware NVMe y equipo especializado; no es un reemplazo general de Lustre o Ceph.

¿Storage Scale es lo mismo que GPFS o Spectrum Scale?

Sí. Es el mismo producto de IBM con distintos nombres: GPFS, luego IBM Spectrum Scale y hoy IBM Storage Scale. En 2026 va por la 5.2.x e incorpora GPUDirect Storage de NVIDIA y certificación para DGX BasePOD/SuperPOD.

¿BeeGFS sigue siendo gratis?

La Community Edition sigue siendo gratuita, pero desde BeeGFS 8 hay que generar una licencia comunitaria con beegfs license. Las funciones enterprise quedan tras una licencia de pago. La versión estable en 2026 es la 8.3.x.

¿Se puede usar Ceph para HPC serio?

Ceph aparece en la lista de producción de la IO500 y hay despliegues masivos (CERN supera los 50 PB), pero en cargas HPC de rendimiento extremo no suele sustituir a Lustre, Storage Scale o DAOS. Su fuerza está en las arquitecturas híbridas HPC + IA: objeto, bloque y fichero desde un mismo clúster e integrado con OpenStack y Kubernetes.

Almacenamiento IA / HPC · Open Source

¿Tus GPUs calculan o esperan?

Cuéntanos qué carga vas a mover, cuántas GPUs y qué tienes hoy en infraestructura. Te respondemos en menos de 24 horas con un esbozo de arquitectura de almacenamiento y una idea real de esfuerzo. Si Ceph encaja, te lo decimos. Si lo tuyo es Lustre, Storage Scale o DAOS, también.

Ver almacenamiento IA/HPC Contacto

IBM QRadar, líder G2 en SIEM, UEBA, NTA e IR 2026

/en
Ciberseguridad · IBM QRadar · SOC

IBM QRadar entra líder en cuatro categorías G2 a la vez.

SIEM, UEBA, análisis de tráfico de red y respuesta a incidentes. Repasamos qué mide cada categoría, qué significa en un SOC de verdad y qué formaciones QRadar 7.6 tenemos actualizadas para que el reconocimiento no se quede en póster de despacho.

8 min lectura●Análisis técnico●

El 10 de julio, IBM anunció que QRadar SIEM ha vuelto a entrar como líder del G2 Grid en cuatro categorías: SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) e Incident Response. La nota oficial es cortita — cuenta las medallas y ya.

Aquí las repasamos con más detalle. Qué mide G2 en cada una de las cuatro, qué significa para un SOC que las va a operar en el día a día y qué versión de QRadar cubren nuestras formaciones (las tres actualizadas a la 7.6, la última).

01

Las cuatro medallas G2, una por una

G2 puntúa el software con reseñas verificadas de gente que lo tiene en producción. Que QRadar aparezca líder en las cuatro categorías a la vez es un dato interesante: son cuatro capacidades que hasta hace no tanto se compraban en productos separados y que aquí van dentro de la misma plataforma.

Categoría 01 SIEM

Security Information and Event Management. Recoge logs de sistemas, red, aplicaciones y nube, los normaliza, los correlaciona y detecta patrones que apuntan a incidentes.

Es la categoría de siempre de QRadar. La que llevan usando bancos, telcos y administración pública desde hace más de una década. La sorpresa no está aquí, está en que aparezca también líder en las otras tres.

Categoría 02 UEBA

User and Entity Behavior Analytics. Analiza el comportamiento de usuarios y activos, construye una base de "lo normal" y avisa cuando algo se sale de ella.

Es la capacidad de detectar que a las tres de la mañana un usuario que nunca ha movido más de 200 MB empieza a bajarse 300 GB. Hasta hace unos años se resolvía con un producto UEBA aparte; en QRadar viene integrado como app.

Categoría 03 NTA · Network Traffic Analysis

Análisis de tráfico de red. Mira los flujos (NetFlow, IPFIX y equivalentes) para detectar movimientos laterales, exfiltraciones o comunicaciones con C2 que en los logs no aparecen.

Módulo QRadar Network Insights. Los logs cuentan lo que pasó en las máquinas; el NetFlow cuenta lo que pasó por los cables. Sin la segunda parte, media película se pierde. Útil sobre todo para quien tenía el NetFlow en una consola separada.

Categoría 04 Incident Response

Respuesta a incidentes. Detectar es la mitad del trabajo. La otra mitad es orquestar la respuesta: playbooks, tickets, contención y coordinación entre equipos.

Aquí entra QRadar SOAR (antes Resilient), que cuenta como líder G2 aparte del SIEM. Es el trozo que más peso está ganando en Europa desde que NIS2 exige notificar incidentes en 24 horas — plazo que se queda corto si el playbook lo tienes apuntado en un post-it.

02

Qué certifica exactamente un liderazgo G2

G2 es, si se nos permite la analogía, el TripAdvisor del software empresa. Y como TripAdvisor: si cuatrocientos usuarios coinciden en que la paella está buena, algo se está haciendo bien. Pero no lo convierte en guía Michelin.

Traducido a QRadar: las reseñas confirman que a la gente que lo opera le convence en satisfacción, ecosistema de integraciones y capacidad de escalar. Lo que no confirman es que sea equivalente a un Gartner Magic Quadrant o a una Forrester Wave, que son análisis de analistas. Señales complementarias, ambas.

En las mismas reseñas también aparece lo que la nota oficial se salta: QRadar tiene curva de aprendizaje, el tuning inicial es exigente y la factura por EPS/FPI puede subir más rápido de lo previsto si el dimensionamiento no se hace con cabeza. Nada de eso es una debilidad del producto — es una lista de cosas que sabemos por experiencia y que se resuelven con formación y planificación.

03

Por qué la ola G2 llega en buen momento

El calendario europeo está movidito. NIS2 lleva vigente desde 2024 y en 2026 empiezan las inspecciones y sanciones a entidades esenciales e importantes. DORA obliga a las entidades financieras a demostrar resiliencia operativa TIC, incluida la capacidad de detectar, notificar y responder a incidentes con tiempos medibles. En los dos casos, tener un SIEM instalado no basta: hace falta un SIEM bien afinado y un SOC que sepa operarlo.

Ahí es donde el reconocimiento G2 sirve para algo práctico: pista de qué merece la pena aprender. Si las cuatro categorías rankean alto en satisfacción — SIEM, UEBA, tráfico de red y respuesta —, formar al equipo en QRadar cubre esas cuatro capas de una vez. Un solo curso, cuatro capacidades: la ecuación que gusta ver en cualquier presupuesto de formación.

04

Tres formaciones actualizadas a la última versión de QRadar (7.6)

Los tres cursos SIXE de formación IBM QRadar están actualizados a la última versión del producto, la 7.6. Se pueden hacer sueltos o como itinerario. Presencial o remoto, en español, inglés o francés, con material propio y laboratorios sobre QRadar 7.6 — el producto real, con sus manías y todo.

Fundamentos · BQ205G IBM QRadar SIEM 7.6 · Curso Fundamentos Arquitectura, offenses, reglas, búsquedas AQL y dashboards. El curso base para analistas L1 y L2 que van a operar QRadar en el día a día del SOC. Ver el curso Administración IBM QRadar SIEM 7.6 · Despliegue y administración Instalación, tuning, gestión de usuarios y dominios, integración de log sources, alta disponibilidad y actualizaciones. Para quien tiene que mantener el motor en producción. Ver el curso Operaciones avanzadas IBM QRadar SIEM 7.6 · Operaciones avanzadas UEBA, Network Insights, threat hunting con AQL avanzada, playbooks SOAR e integración con MITRE ATT&CK. Para el SOC maduro que quiere sacar rendimiento real al motor. Ver el curso
FAQ

Preguntas frecuentes

¿En qué categorías G2 es líder IBM QRadar en 2026?

En cuatro categorías críticas de seguridad: SIEM, User and Entity Behavior Analytics (UEBA), Network Traffic Analysis (NTA) e Incident Response. El reconocimiento se basa en reseñas verificadas de usuarios y presencia de mercado, no en una evaluación de analista independiente.

¿Un liderazgo G2 equivale a un Gartner Magic Quadrant?

No. G2 recoge reseñas verificadas de usuarios reales; Gartner y Forrester usan análisis de sus propios analistas. Son cosas distintas y complementarias: un producto que puntúa alto en las dos suele ser una apuesta más tranquila que uno que solo destaca en una.

¿Qué versión de QRadar cubren las formaciones actualizadas de SIXE?

Los tres cursos (Fundamentos, Despliegue y administración, Operaciones avanzadas) están actualizados a IBM QRadar SIEM 7.6, la última versión soportada por IBM en el momento de la revisión. Los laboratorios se realizan sobre entornos 7.6 reales.

¿La formación QRadar es presencial o remota?

Los tres cursos se imparten en formato presencial en las oficinas del cliente o remoto en aula virtual, en español, inglés o francés. Se adaptan al calendario del cliente y al nivel del equipo, desde analistas L1 hasta administradores senior.

Formación IBM QRadar 7.6 · Presencial o remoto

Y ahora, ¿cómo se lleva el titular a producción?

Cuéntanos cuántas personas necesitáis formar, qué rol tienen (analista, administrador, arquitecto) y en qué versión estáis. Te preparamos una propuesta con temario, formato, fechas e idioma en menos de lo que tarda un tuning inicial.

Pedir presupuesto WhatsApp Ver hub formación QRadar

Los 10 riesgos OWASP de seguridad de APIs vs IBM API Connect

/en
API Security · OWASP · IBM API Connect

Los 10 riesgos OWASP de seguridad de APIs vs IBM API Connect.

Los 10 riesgos críticos de seguridad de APIs según OWASP, uno a uno, mapeados a las capacidades reales de IBM API Connect y DataPower. Dónde el gateway resuelve, dónde ayuda y dónde el trabajo sigue siendo del backend.

10 min lectura●Análisis técnico●

Las APIs son el principal vector de ataque contra aplicaciones empresariales y, con la adopción creciente de agentes de IA y protocolos como MCP, el inventario de consumidores autónomos sigue creciendo. Los riesgos del OWASP API Security Top 10 (edición 2023, vigente) no cambian — solo se vuelven más críticos.

Esta entrada va al grano: mapeo riesgo por riesgo de qué cubre IBM API Connect + DataPower y qué no. De los 10, el gateway tiene cobertura nativa en 4, ayuda parcial en otros 4, impacto indirecto en 1 y deja 1 al backend. Saber cuál es cuál es lo que diferencia a un equipo formado de uno que descubre las cosas en producción.

10
Riesgos críticos
en la lista OWASP
2023
Última edición
vigente OWASP
4 / 10
Cobertura nativa
del gateway IBM
3
Categorías nuevas
frente a 2019
01 · Contexto

¿OWASP qué y por qué importa más en 2026?

La OWASP API Security Top 10 es la lista de referencia del sector con los 10 riesgos más críticos de seguridad en APIs. La última edición es de 2023 — y en 2026 sigue siendo el estándar, sin reedición pendiente. Lo que ha cambiado no es la lista, es el contexto en el que aplica:

  • Las APIs siguen siendo uno de los principales vectores de ataque contra aplicaciones empresariales.
  • La adopción creciente de agentes de IA y protocolos como MCP añade consumidores autónomos al mapa — distintos de las apps y los partners de toda la vida.
  • El API sprawl — APIs no documentadas ni gobernadas — sigue siendo un reto recurrente en organizaciones con muchos años de integraciones acumuladas.

En este escenario el gateway deja de ser solo un proxy y se convierte en la pieza donde se aplican (o se dejan de aplicar) los controles del OWASP API Top 10.

Cómo leer este post

Cada riesgo lleva un badge de cobertura con cuatro niveles: Total (lo cubre el gateway por sí solo), Parcial (ayuda pero requiere diseño correcto), Indirecto (aporta poco) o No directo (el problema está en el backend). El objetivo no es vender — es que sepas dónde poner el esfuerzo.

02 · Los 10 riesgos

OWASP API Top 10 (2023) · mapeo a IBM API Connect + DataPower

API1:2023 Broken Object Level Authorization (BOLA) Cobertura parcial

El cliente cambia un ID en la URL (/orders/42 → /orders/43) y accede a un objeto que no es suyo. Sigue siendo el riesgo nº1 — porque la lógica de propiedad vive en el backend.

Lo que SÍ hace el gateway Valida JWT, extrae claims de usuario y los pasa al backend en headers firmados. Puede aplicar políticas por scope OAuth.
Lo que tiene que hacer tu backend Comprobar que el user_id del token coincide con el dueño del objeto solicitado en cada endpoint. El gateway no conoce el modelo de datos.
API2:2023 Broken Authentication Cobertura nativa

Tokens mal validados, mecanismos de autenticación inseguros, JWT firmados con none, credenciales por defecto. La autenticación es el plano donde el gateway aporta más, sin discusión.

Lo que SÍ hace el gateway OAuth 2.0 completo (authorization server, scopes, refresh), JWT validation (firma, exp, aud, iss), OIDC, mTLS, API keys con rotación, integración con LDAP/AD/IAM externo. Es WD509G y WE752G en estado puro.
Lo que tiene que hacer tu backend Confiar en el resultado de validación del gateway. Si validas otra vez en el backend, asegúrate de no introducir inconsistencias.
API3:2023 Broken Object Property Level Authorization Cobertura parcial

El backend devuelve más campos de los que el usuario debería ver (excessive data exposure) o acepta más campos en escritura (mass assignment). Combina los antiguos API3:2019 y API6:2019.

Lo que SÍ hace el gateway Transformaciones de respuesta (mascarado de campos sensibles, filtrado por scope). DataPower puede aplicar XSLT o políticas GatewayScript para sanear payloads.
Lo que tiene que hacer tu backend No devolver campos que el rol no debería ver. No aceptar campos no esperados en escritura. El gateway puede ayudar a posteriori, pero la responsabilidad sigue siendo del diseño del API.
API4:2023 Unrestricted Resource Consumption Cobertura nativa

Falta de rate limiting, ausencia de quotas, payloads sin tamaño máximo. Antes se llamaba "Lack of Resources & Rate Limiting". Donde el gateway brilla.

Lo que SÍ hace el gateway Rate limit por consumidor, por plan, por endpoint. Quotas diarias/mensuales. Throttling configurable. Límite de tamaño de payload. Burst control. Todo configurable en el manager y aplicado en DataPower o Nano Gateway.
Lo que tiene que hacer tu backend Definir los SLAs de cada plan/consumidor. El gateway aplica lo que tú decidas — no decide por ti qué es razonable.
API5:2023 Broken Function Level Authorization Cobertura parcial

Un usuario normal accede a endpoints de admin porque la API no comprueba el rol más allá de la autenticación.

Lo que SÍ hace el gateway Aplicar políticas distintas por endpoint en función de scopes OAuth. Bloquear acceso a rutas admin desde tokens sin el scope correspondiente. Routing condicional.
Lo que tiene que hacer tu backend Diseñar bien los scopes OAuth desde el principio. Un scope admin es inútil si lo conceden todos los flujos. El gateway aplica reglas — no las inventa.
API6:2023 Unrestricted Access to Sensitive Business Flows Cobertura parcial

Una API expone un flujo de negocio sensible (compras, transferencias, votación) y un atacante automatiza miles de llamadas legales pero abusivas. El daño no viene de un exploit técnico — viene del volumen.

Lo que SÍ hace el gateway Throttling por consumidor, detección de patrones, geo-blocking, CAPTCHA gateway integration, integración con WAF (DataPower) para reglas avanzadas.
Lo que tiene que hacer tu backend Identificar cuáles son tus flujos sensibles (no todos lo son) y diseñar contadores de negocio que el gateway pueda consumir vía analytics.
API7:2023 Server Side Request Forgery (SSRF) No directo

Una API acepta una URL del usuario y la usa para hacer peticiones internas — el atacante la usa para atacar tu red interna. Vector subiendo en cloud por el uso de servicios de metadata (AWS IMDS, Azure IMDS).

Lo que SÍ hace el gateway Poco directamente. Si el backend reenvía vía el gateway hacia outbound, se puede restringir destinos. Pero no es el patrón habitual.
Lo que tiene que hacer tu backend Validar URLs entrantes contra lista blanca. Bloquear rangos internos (RFC 1918, link-local). No usar inputs de usuario directamente en peticiones HTTP server-side. Esto es 95% backend.
API8:2023 Security Misconfiguration Cobertura nativa

Defaults inseguros, TLS mal configurado, CORS demasiado abierto, headers de seguridad ausentes, errores stack-trace expuestos. El clásico que sigue causando incidentes.

Lo que SÍ hace el gateway DataPower viene con defaults seguros y permite políticas centralizadas de TLS, CORS, headers de seguridad (HSTS, CSP, X-Frame-Options), supresión de stack traces. Auditoría unificada de configuración desde API Connect V12.
Lo que tiene que hacer tu backend No anular en el backend lo que el gateway ya hace correctamente (errores de doble configuración). Mantener defaults seguros también dentro de la red interna.
API9:2023 Improper Inventory Management Cobertura nativa

APIs zombi en producción, versiones antiguas sin retirar, entornos de staging accesibles desde internet, documentación inexistente. La base del API sprawl.

Lo que SÍ hace el gateway El núcleo de API Connect es exactamente esto: catálogo de APIs, versionado, ciclo de vida (creación, publicación, deprecación, retirada), gobierno federado en V12 (gateways heterogéneos visibles desde un solo plano), Developer Portal con documentación auto-generada.
Lo que tiene que hacer tu backend Cumplir el proceso de gobierno: cada API publicada pasa por el manager. Las APIs que no están en el catálogo son shadow — y son las que generan brechas.
API10:2023 Unsafe Consumption of APIs Cobertura indirecta

Tu app consume APIs de terceros sin validar lo que devuelven — y un proveedor comprometido te lleva por delante. Nuevo en 2023, especialmente relevante en arquitecturas con muchas integraciones SaaS.

Lo que SÍ hace el gateway Si el consumo de APIs externas pasa por el gateway hacia outbound, se pueden aplicar políticas de schema validation, sanitización de respuestas y rate limit al proveedor. No siempre es el patrón.
Lo que tiene que hacer tu backend Validar contratos de API consumidos. No confiar en payloads recibidos. Aislar dependencias. Esto es disciplina de desarrollo, más que configuración de plataforma.
03 · Resumen visual

Los 10 riesgos, de un vistazo

Tabla de cobertura del gateway IBM (API Connect + DataPower) por riesgo OWASP:

Riesgo Nombre corto Cobertura gateway Capacidad clave
API1
BOLA
Parcial
JWT claims propagados
API2
Broken Authentication
Nativa
OAuth, JWT, OIDC, mTLS
API3
Object Property Level Authz
Parcial
Mascarado de campos
API4
Unrestricted Resource Consumption
Nativa
Rate limit, quotas, throttling
API5
Function Level Authorization
Parcial
Scopes OAuth + políticas
API6
Sensitive Business Flows
Parcial
Detección patrones, WAF
API7
SSRF
No directo
Backend principalmente
API8
Security Misconfiguration
Nativa
TLS, CORS, headers, auditoría
API9
Improper Inventory Management
Nativa
Catálogo, versionado, V12
API10
Unsafe Consumption of APIs
Indirecta
Validación de contratos

Balance: 4 cobertura nativa (API2, API4, API8, API9) · 4 cobertura parcial (API1, API3, API5, API6) · 1 indirecta (API10) · 1 no directa (API7).

04 · El factor humano

El gateway aplica reglas — alguien tiene que diseñarlas

La conclusión honesta tras leer el mapeo es la que rara vez sale en el material comercial: el gateway es una herramienta potente, pero sin criterio propio. Aplica al pie de la letra lo que tu equipo configure. Si los scopes OAuth están mal pensados, el gateway no los arregla por ti. Si pones un rate limit de 10.000 req/s en un endpoint de transferencias, el gateway te ayuda a fallar más rápido.

Las capacidades de API Connect y DataPower son las que has visto arriba. La diferencia entre "tenemos API Connect" y "tenemos API Connect mitigando 8 de los 10 riesgos OWASP correctamente" la marca el equipo que lo opera.

Los 5 cursos oficiales que cubren todo esto WD509G y WD514G para el núcleo de API Connect; WE761G, WE752G y WE754G para DataPower. En español, in-company desde 2 personas.
Catálogo de cursos
Qué hay en los cursos

No es solo "qué hace cada nodo de DataPower". Es cuándo aplicar qué política, cómo diseñar scopes OAuth que escalen, cuándo el rate limit por consumer se queda corto y conviene pasar a business flow throttling — el tipo de decisión operativa que se ve en proyecto, no en el manual.

Resumen

Lo esencial en 5 puntos

Para llevarse de este post

→ OWASP API Top 10 2023 sigue siendo el estándar vigente en 2026 — sin reedición pendiente, pero más relevante por la era agéntica.

→ El gateway IBM (API Connect + DataPower) tiene cobertura nativa de 4 riesgos — autenticación, rate limiting, configuración segura e inventario de APIs.

→ Ayuda parcialmente en otros 4 (BOLA, property authz, function authz, business flows) — pero la lógica de negocio sigue siendo del backend.

→ SSRF y unsafe consumption son territorio principalmente de los developers — no esperes que el gateway los resuelva por ti.

→ La diferencia entre tener la herramienta y mitigar los riesgos es la formación del equipo que la configura.

FAQ

Preguntas frecuentes

¿La versión 2023 de OWASP API Top 10 sigue vigente en 2026?

Sí. La OWASP Foundation publicó la última actualización del API Security Top 10 en 2023 y no hay versión nueva publicada en 2026. La lista sigue siendo el estándar de referencia del sector — más relevante todavía con la adopción de agentes de IA que consumen APIs masivamente.

¿API Connect / DataPower cubre los 10 riesgos OWASP?

No, y eso no es un defecto del gateway. De los 10 riesgos, el gateway cubre completamente 4 (API2, API4, API8, API9), ayuda parcialmente en 4 (API1, API3, API5, API6), tiene impacto indirecto en 1 (API10) y deja 1 a backend (API7 SSRF). El resto requiere diseño correcto del backend y validación humana.

¿Qué riesgo es el más fácil de mitigar con el gateway?

API4 (Unrestricted Resource Consumption) y API9 (Improper Inventory Management). Rate limiting, quota plans y throttling son territorio nativo de API Connect. El catálogo, versionado y gobierno federado de V12 cubren directamente la gestión de inventario.

¿Dónde aprendo a configurar todo esto en API Connect?

Los cursos oficiales WD509G (admins) y WD514G (devs), más los de DataPower (WE761G, WE752G, WE754G). En SIXE los impartimos in-company desde 2 personas con ingenieros que despliegan estos productos en cliente. El catálogo está en el hub de formación API Connect.

Fuentes

Referencias

OWASP Foundation. OWASP API Security Project. owasp.org/www-project-api-security

OWASP Foundation. API Security Top 10 (2023 edition). owasp.org/API-Security · edición 2023

IBM. IBM API Connect — Cloud Pak for Integration. ibm.com/products/api-connect

IBM. IBM DataPower Gateway. ibm.com/products/datapower-gateway

SIXE. Hub formación oficial IBM API Connect. sixe.es/formacion/ibm-api-connect

Última actualización: .

Formación API Connect & DataPower

¿Hablamos de formación para tu equipo?

Cuéntanos qué riesgos OWASP os preocupan más, cuántos sois y dónde estáis. Te respondemos en menos de 24 horas con itinerario, modalidad y presupuesto cerrado. Sin formularios kilométricos.

Ver el hub completo Contacto

Informix 15, watsonx y fin de soporte de 12.10 en 2026

/en
Bases de datos · IBM Informix · 2026

Informix en 2026: versión 15, watsonx y fin de soporte de 12.10.

Tres noticias concretas — incluido un EOS que ya entró en vigor — y un movimiento estratégico de IBM hacia analítica e IA. Si tienes Informix en producción o lo estás valorando, conviene tener el mapa al día.

8 min lectura●Guía técnica●

Informix es una de esas bases de datos sobre las que de tanto en tanto se publica el obituario — y un par de años después sigue en producción en miles de organizaciones gestionando OLTP intensivo, series temporales e IoT. En lo que va de 2026 han pasado tres cosas concretas que conviene tener en el radar.

En SIXE impartimos los tres cursos oficiales del itinerario Informix vinculados a la línea 15, y trabajamos con clientes que tienen instancias en producción desde hace años. Esto es el repaso útil: qué hay encima de la mesa, qué fechas son importantes y dónde encaja.

Nov 2024
Informix 15
Disponibilidad general
Ene 2026
Informix 14.10xC13
Último fixpack
30-Abr-2026
EOS Informix 12.10
Ya en vigor
01 · Lo que ha pasado este año

Tres movimientos en lo que va de 2026

Si solo tienes 30 segundos, este es el resumen — el resto del post desarrolla cada punto:

Plataforma

Informix 15 consolida la línea

Eliminación de límites internos, almacenamiento hasta media yottabyte, external smartblobs y InformixHQ renovado. La actualización más relevante del motor en más de una década.

Mantenimiento

14.10xC13 (enero 2026)

archecker ya recupera tablas con columnas SmartLOB (BLOB/CLOB) desde backup. Direct I/O con bloques 2K y 4K. Set habitual de correcciones acumuladas.

Calendario

EOS de 12.10 — ya en vigor

Informix 12.10 está fuera de soporte estándar desde el 30 de abril de 2026. IBM ofrece Extended Support contratable hasta 2030 para quien necesite puente.

VERSIONES DE INFORMIX · ESTADO EN 2026 12.10 EOS · 30-abr-2026 Solo Extended Support (hasta 2030) 14.10 xC13 · Ene 2026 Versión soportada 15 Línea activa · Nov 2024 Sin límites internos → migración recomendada → → ruta de upgrade →
Estado de las versiones Informix vigentes en 2026 · Fuentes: IBM Support Lifecycle, IIUG.
02 · Plataforma

Qué trae Informix 15

La 15 — anunciada por IBM el 19 de noviembre de 2024 — es la actualización más relevante del motor en más de una década. Los cambios principales:

  • Almacenamiento sin límites prácticos. Una instancia Informix 15 puede gestionar hasta media yottabyte de datos. La eliminación de los topes internos (filas por página, páginas por partición, tamaños de página) deja de obligar a particionar por arquitectura — particionas solo cuando tiene sentido funcional.
  • External smartblobs. Los BLOBs y CLOBs (vídeos, documentos, multimedia) pueden vivir en un filesystem externo. Backups más rápidos y almacenamiento más barato.
  • InformixHQ renovado. La herramienta gráfica de monitorización y administración estrena configuración más sencilla de Enterprise Replication.
  • Más capacidad de diagnóstico. Mejoras en depuración SQL para acelerar el trabajo de los desarrolladores.
En cristiano

Hasta ahora, en muchos despliegues Informix planificabas la partición de tablas por los límites del motor, no por necesidad funcional. Eso cambia con la 15: particionas porque tiene sentido a nivel de negocio, no porque toque.

03 · Mantenimiento

Novedades de 14.10xC13 (enero 2026)

Si tu organización todavía está en la línea 14.10 — y es perfectamente válido, sigue siendo versión soportada — el último fixpack publicado en enero trae:

  • archecker recupera tablas con columnas SmartLOB (BLOB / CLOB) desde backup. Hasta ahora era un escenario más manual.
  • Direct I/O con tamaño de bloque 2K y 4K, además de los tamaños previos. Más control sobre el rendimiento de E/S.
  • Conjunto habitual de correcciones acumuladas y mejoras de estabilidad.

14.10xC13 es un fixpack pensado para mantener la línea saludable mientras planificas el salto a 15.

04 · Integración IA

Informix en el ecosistema watsonx.data

IBM ha publicado un conector oficial Informix dentro de watsonx, documentado también en el portal de docs de watsonx SaaS. La propuesta de valor:

  • Zero-ETL. El conector consulta los datos de Informix sin replicarlos a un data lake aparte. Una sola copia. Lo dice IBM literalmente: "access and query multi-modal data types in IBM Informix [...] with zero-ETL".
  • Formatos abiertos en watsonx.data. El propio watsonx.data usa Apache Iceberg como formato de tabla abierto para unificar y compartir datos entre integraciones (Db2, Netezza, Informix y otras) sin necesidad de re-catalogar. Tus datos en Informix siguen siendo Informix.
  • Queries en lenguaje natural. Las capacidades de IA generativa de watsonx.data permiten — según IBM — que los clientes de Informix analicen sus datos "using natural language with no SQL required".

Para una organización con Informix instalado, esta integración convierte la base operacional en también un activo analítico, sin migración ni replicación.

Cómo enfocarlo

Si tu organización ya está usando watsonx.data o lo está evaluando, la integración con Informix elimina una de las objeciones típicas: "cómo conectar mis datos operacionales con la capa de IA sin montar un pipeline aparte".

05 · Calendario

Informix 12.10 — fuera de soporte estándar desde el 30 de abril

Ya en vigor

Desde el 30 de abril de 2026, Informix 12.10 (ediciones Enterprise, Workgroup y Express) está fuera del soporte estándar de IBM. Las organizaciones que todavía corren 12.10 pueden contratar IBM Extended Support con cobertura hasta 2030 como puente. Sin uno ni otro, no hay parches de seguridad ni resolución de incidencias por parte de IBM.

Implicaciones prácticas:

  • La línea 12.10 ya no admite nuevas adquisiciones de licencias.
  • Las instancias en 12.10 sin extensión están sin parches ni soporte oficial desde el 30 de abril.
  • Extended Support es la ruta contratable para extender la cobertura hasta 2030 — útil como puente mientras se planifica la migración.
  • La ruta de upgrade habitual lleva a la última versión soportada (Informix 15). 14.10 es una parada intermedia válida si hace falta por compatibilidad de aplicaciones.

Compatibilidad y movimientos sugeridos

Versión Informix 12.10 Informix 14.10 Informix 15
Soporte IBM
EOS 30-abr-2026
Soportada
Línea activa
Último fixpack
xC16
xC13 · Ene 2026
Última GA Nov-2024
Límites de almacenamiento
Heredados
Heredados
Eliminados
External smartblobs
No
No
Sí
Integración watsonx.data
Limitada
Limitada
Sí
Acción sugerida
Plan de salida
Plan de upgrade
Línea destino
06 · Encaje

Dónde Informix encaja bien en 2026

Escenarios donde Informix sigue siendo una opción competitiva:

  • OLTP intensivo con latencia baja. Retail, punto de venta, banca, telco — la huella de memoria y el rendimiento por núcleo siguen siendo de las mejores del mercado.
  • IoT y series temporales. El motor soporta tipos temporales y manejo de time series de forma nativa, sin depender de soluciones externas.
  • Edge computing. Informix Embedded está pensado para dispositivos con poco hardware y conectividad intermitente — quioscos, tiendas remotas, equipamiento industrial.
  • Bases de datos con muchos años de servicio. Cuando ya tienes 12.10 o 14.10 corriendo, la ruta natural es subir a 15 — mantienes el conocimiento del equipo, las aplicaciones y las integraciones existentes.

A esto se suma la ventaja operativa de tener un único proveedor (IBM) para soporte, formación oficial y partners con experiencia real en producción.

07 · Formación oficial

Los 3 cursos que impartimos

En el itinerario Informix de SIXE tenemos los tres cursos oficiales IBM, alineados con la versión 15:

Código Curso Nivel Duración
SIFMX89G
System Administration v15 & v14.10
Intermedio
3-4 días · 24h
SIFMX229G
Database Administration 14.10
Fundamental
3 días · 24h
SXIFX15A
Informix 15: Migration, Admin & Cloud
Avanzado
3-4 días · 24h

Online o presencial, en español, con laboratorios sobre infraestructura real. Impartidos por los ingenieros de SIXE que operan Informix en cliente. In-company desde 2 personas, con descuento por volumen.

Resumen

Lo esencial en 4 puntos

Para quien tiene prisa

→ Informix 15 (nov 2024) elimina límites internos, añade external smartblobs y renueva InformixHQ. Línea destino para migración.

→ 14.10xC13 (ene 2026) aporta restauración de SmartLOBs con archecker y direct I/O en bloques 2K/4K. 14.10 sigue siendo versión soportada.

→ 12.10 está fuera de soporte estándar desde el 30-abr-2026. IBM Extended Support contratable hasta 2030 como puente.

→ Integración watsonx.data con conector zero-ETL e Iceberg — los datos operacionales pasan a ser activo analítico sin replicar.

FAQ

Preguntas frecuentes

¿Sigue habiendo soporte oficial de IBM para Informix en 2026?

Sí. Informix 15 es la línea activa. Informix 14.10 sigue como versión soportada con fixpacks (el último, xC13, salió en enero de 2026). Informix 12.10 está fuera de soporte estándar desde el 30 de abril de 2026; IBM ofrece Extended Support contratable hasta 2030 para quien necesite extender la cobertura.

¿La integración con watsonx.data requiere mover los datos a otro sistema?

No. El conector zero-ETL accede a Informix donde esté (on-premise, cloud, híbrido) sin replicar los datos. Una sola copia, dos planos de consumo: operacional y analítico.

¿Qué relación tiene HCL con Informix?

HCL y IBM co-licencian Informix desde 2017. Existen IBM Informix y HCL Informix con la misma base técnica y numeración equivalente (15.0). Los cursos oficiales de SIXE son IBM.

¿Vale la pena migrar a Informix 15 si ya estoy en 14.10?

Vale la pena planificarlo. Los cambios estructurales (eliminación de límites internos, smartblobs externos) son significativos y el conector watsonx.data está alineado con la línea actual. 14.10 sigue siendo versión soportada, así que el salto se puede planificar con calma.

Estoy en Informix 12.10. ¿Qué hago?

El soporte estándar terminó el 30 de abril de 2026. Las opciones son contratar IBM Extended Support (cobertura hasta 2030) como puente o planificar la migración. La ruta de upgrade habitual lleva a la última versión soportada (Informix 15); 14.10 funciona como parada intermedia si hace falta por compatibilidad de aplicaciones.

Fuentes

Referencias

IBM. Informix 15: Unparalleled Scalability for the Modern Data-Driven World. ibm.com — Informix 15 announcement

IBM. IBM Informix Enterprise Edition 12.10.x — End of support. ibm.com/support — 12.10 EOS

IBM. Fix list for Informix Server 12.10.xC16 (último fixpack). ibm.com/support — 12.10.xC16

IBM. IBM Informix connection — watsonx documentation. dataplatform.cloud.ibm.com — Informix connector

IBM. watsonx.data SaaS — Informix connection docs. ibm.com/docs — watsonx Informix

IBM. Página oficial del producto. ibm.com/products/informix

IIUG. International Informix Users Group — End of support dates. iiug.org — EOS dates

Última actualización: .

Soporte y formación Informix

¿Migrar, formar al equipo o solo evaluar? Hablamos.

Migración 12.10 → 15, healthcheck de instancias en producción, soporte continuado y formación oficial. Ingenieros de SIXE con Informix real en cliente — sin helpdesks, sin colas de tickets.

Contactar con SIXE Ver formación

NIS2 en 2026: a quién aplica, plazos y cómo cumplir

/en ,
Cumplimiento · Ciberseguridad · Directiva UE

NIS2 en 2026: a quién aplica, plazos y cómo cumplir.

A año y medio largo de la fecha límite de transposición, NIS2 ha dejado de ser un proyecto futuro y se ha convertido en deuda técnica acumulada. Si tu empresa entra en alguno de los 18 sectores y supera los 50 empleados o los 10 millones de facturación, esto va contigo — y las autoridades europeas ya están haciendo preguntas. Esta guía te dice exactamente qué pide la directiva, qué herramientas la cubren y por dónde se empieza sin alarmismo.

7 min lectura●Guía●

Si en tu empresa la frase «plan de continuidad» todavía provoca risa nerviosa, llevas tarde con NIS2 — pero no eres la única. La Directiva (UE) 2022/2555 entró en vigor en enero de 2023, la fecha límite de transposición fue octubre de 2024 y, a estas alturas de 2026, las primeras inspecciones en sectores esenciales ya están en marcha. La parte que importa: las obligaciones ya aplican, esté como esté la ley española en el momento que estés leyendo esto.

Esto no es un artículo jurídico (no soy abogado, no juego a serlo) ni una pieza de marketing del miedo. Es lo que repetimos en cada reunión con un cliente al que NIS2 le ha llegado tarde: a quién aplica realmente, qué pide el artículo 21, cómo se sostienen los plazos 24/72 h en el mundo real y por dónde se empieza sin volverse loco. Spoiler: la mayoría del trabajo ya está hecho si tienes un SIEM decente, MFA donde toca y a alguien atendiendo cuando algo se rompe a las tres de la mañana.

En 30 segundos

NIS2 cubre 18 sectores (Anexos I y II) y aplica por defecto a entidades de ≥50 empleados o ≥10 M€ de facturación. Exige 10 medidas mínimas de gestión de riesgos (art. 21), notificación de incidentes en 24 h / 72 h / 1 mes (art. 23) y responsabiliza al órgano de dirección (art. 20). Sanciones: hasta 10 M€ o el 2 % de la facturación mundial (esenciales) y 7 M€ o el 1,4 % (importantes).

18
Sectores cubiertos
(Anexos I + II)
24 / 72 h
Plazos de notificación
de incidentes (art. 23)
10 M€ / 2 %
Sanción máxima
entidades esenciales
01 · Contexto

¿Qué es NIS2 y por qué sustituye a la NIS de 2016?

NIS2 es la segunda directiva europea sobre seguridad de las redes y los sistemas de información. Reemplaza a la Directiva 2016/1148 (NIS1) con tres cambios mayores: amplía sectores y entidades cubiertas, endurece las obligaciones técnicas y de gobernanza, e introduce sanciones armonizadas en toda la UE. La NIS1 se quedó pequeña después del volumen de ciberataques que sufrió Europa entre 2020 y 2023; la NIS2 no es revolución, es la lección aprendida.

Recordatorio útil

NIS2 es directiva, no reglamento. Eso significa que cada país transpone a su derecho nacional, pero las obligaciones de fondo no cambian — el calendario y los detalles administrativos (autoridad competente, procedimientos sancionadores) sí los pone cada Estado. Que la ley española aún no haya cerrado todos los matices no es una excusa para no estar cumpliendo lo que ya pide la directiva.

02 · Alcance

¿A quién aplica NIS2?

NIS2 aplica por defecto a entidades medianas y grandes en alguno de los 18 sectores recogidos en los anexos I y II de la directiva. Por «mediana» se entiende ≥50 empleados o ≥10 M€ de facturación anual o balance (artículo 2, referenciando la Recomendación 2003/361/CE). Por debajo del umbral, las autoridades nacionales pueden incluir a una entidad de manera específica si su actividad es crítica.

Sectores
Esenciales (Anexo I)
Importantes (Anexo II)
Algunos ejemplos
Energía, transporte, banca, infraestructuras de mercados financieros, sanidad, agua potable, aguas residuales, infraestructura digital, gestión de servicios TIC B2B, administración pública, espacio.
Servicios postales y de mensajería, gestión de residuos, productos químicos, alimentación, fabricación (incl. dispositivos médicos, vehículos, electrónica), proveedores digitales (marketplaces, buscadores, redes sociales), investigación.
Supervisión
Proactiva (la autoridad audita por iniciativa propia).
Reactiva (solo cuando hay indicios de incumplimiento).
Sanción máxima
10 M€ o 2 % facturación anual mundial.
7 M€ o 1,4 % facturación anual mundial.
Obligaciones técnicas
Las mismas — artículo 21.
Las mismas — artículo 21.

Fuente: Anexos I y II + arts. 31–32 + art. 34, Directiva (UE) 2022/2555.

03 · Obligaciones

Las 10 medidas mínimas del artículo 21

El artículo 21(2) lista diez áreas mínimas que toda entidad afectada tiene que cubrir con medidas «técnicas, operativas y organizativas adecuadas y proporcionadas». No hay que reinventar nada — la mayoría ya están en ISO 27001, ENS o NIST CSF. La novedad es que ahora son obligación legal, con sanciones armonizadas.

01

Políticas de análisis de riesgos y seguridad de la información

02

Gestión de incidentes (detección y respuesta)

03

Continuidad de negocio: backups, recuperación, gestión de crisis

04

Seguridad de la cadena de suministro

05

Seguridad en adquisición, desarrollo y mantenimiento (incl. vulnerabilidades)

06

Evaluación de la eficacia de las medidas

07

Ciberhigiene básica y formación

08

Criptografía y, cuando proceda, cifrado

09

Seguridad de RR. HH., control de acceso y gestión de activos

10

MFA o autenticación continua y comunicaciones seguras

Texto literal en el artículo 21(2) de la Directiva (UE) 2022/2555.

Lo que toca traducir a herramientas

Las medidas 2, 5, 6 y 10 (gestión de incidentes, vulnerabilidades, evaluación de eficacia y MFA) son las que más esfuerzo requieren si arrancas desde cero. La forma rápida y razonable de cubrirlas — y demostrarlas en una auditoría — es un SIEM/XDR centralizado. En SIXE desplegamos Wazuh con dashboards mapeados a NIS2 y ENS, sin coste de licencia, que es justo lo que la mayoría de empresas medianas necesitan oír cuando NIS2 entra en el presupuesto.

04 · Plazos

¿En cuánto hay que notificar un incidente?

El artículo 23 define tres pasos para reportar un incidente significativo a la autoridad competente. La clave está en la palabra «significativo» (impacto operativo grave, pérdidas financieras o repercusión en terceros) y en que el reloj corre desde que la entidad tiene conocimiento del incidente, no desde que ocurre.

Notificación de incidentes significativos · art. 23
24 h
Alerta temprana
Indica si se sospecha origen ilícito o repercusión transfronteriza.
72 h
Notificación
Evaluación inicial, severidad, IoC y medidas adoptadas.
1 mes
Informe final
Causa raíz, mitigación e impacto transfronterizo si aplica.

Aguantar estos plazos sin un SIEM/XDR con casos de uso decentes, runbooks y un equipo localizable 24/7 es, sencillamente, imposible. La forma rápida de quedarse fuera de plazo es enterarte por un usuario que «algo va raro» a las 8 de la mañana, descubrir que el incidente empezó ayer y mirar el reloj con cara de circunstancias.

La pieza que materialmente sostiene NIS2

Detección sin ojos no existe. En SIXE combinamos implantación de Wazuh (SIEM/XDR open source con casos de uso adaptados a NIS2) con soporte 24/7 atendido en español, inglés y francés. Esa es la pieza que materialmente sostiene los 24 y 72 horas — sin telemetría y sin alguien que descuelgue, los plazos son papel mojado. Si necesitas plataforma comercial con integraciones avanzadas, también desplegamos IBM QRadar.

05 · Sanciones

Sanciones (sí, también personales)

NIS2 armoniza el régimen sancionador (artículo 34). Pero la parte que suele acabar las reuniones de comité es la otra: la responsabilidad del órgano de dirección.

  • Entidades esenciales: hasta 10 M€ o el 2 % de la facturación anual mundial (la mayor).
  • Entidades importantes: hasta 7 M€ o el 1,4 % de la facturación anual mundial (la mayor).
  • Dirección (art. 20): los órganos de dirección son responsables de aprobar y supervisar las medidas de gestión de riesgos. Tienen que recibir formación en ciberseguridad y velar por que el resto del personal la reciba también.
  • Inhabilitación (art. 32.5): en entidades esenciales y casos graves, las autoridades pueden inhabilitar temporalmente a personas físicas de ejercer funciones de dirección en la entidad afectada.
El detalle que cambia conversaciones

Más allá de la cifra, dos cosas suelen hacer que la dirección financiera empiece a tomarse esto en serio: la posibilidad de que se publique el incumplimiento y la responsabilidad personal del directivo. La parte económica es importante; la parte reputacional, en muchas empresas, lo es aún más — sobre todo si la inspección llega antes de que tengas el SIEM en pie.

06 · Comprobación rápida

¿NIS2 te aplica? Tres preguntas y un veredicto

Atajo orientativo de tres preguntas para hacerte una idea. No sustituye un análisis formal de aplicabilidad (la autoridad competente puede incluir entidades por debajo del umbral) pero te da una primera lectura útil antes de empezar a llamar a abogados.

¿NIS2 te aplica?

3 preguntas · respuesta inmediata · ninguna telemetría

1. ¿Tu organización tiene 50 o más empleados o factura 10 M€ o más al año?

2. ¿Operáis en alguno de los sectores esenciales? (energía, transporte, banca, mercados financieros, sanidad, agua potable, aguas residuales, infraestructura digital, servicios TIC B2B, administración pública o espacio)

3. ¿Operáis en alguno de los sectores importantes? (postales, residuos, productos químicos, alimentación, fabricación —p. ej. dispositivos médicos, electrónica, vehículos—, proveedores digitales o investigación)

Probablemente sí — como entidad esencial.

Sois del grupo con supervisión proactiva y sanciones máximas de 10 M€ o el 2 % de la facturación. En este perfil, lo razonable es arrancar ya con un análisis de brechas contra el artículo 21 y tener SIEM + soporte 24/7 operativos para sostener los plazos.

→ Pedir diagnóstico NIS2 (auditoría de seguridad)

Probablemente sí — como entidad importante.

Las obligaciones técnicas son las mismas que para una esencial; cambia la supervisión (reactiva) y la sanción máxima (7 M€ o 1,4 %). Mismo plan: gap analysis del artículo 21, SIEM operativo y proceso de notificación de incidentes documentado.

→ Pedir diagnóstico NIS2 (auditoría de seguridad)

A verificar — caso a caso.

Si vuestro sector no aparece claramente en los anexos I/II, la decisión depende del análisis concreto. La autoridad competente puede incluir entidades específicas por su criticidad. Lo prudente: revisar los anexos y, si hay duda, una llamada de 30 minutos resuelve la mayoría de los casos.

→ Consulta rápida con SIXE

Por defecto, fuera del alcance directo.

Por debajo del umbral, NIS2 no aplica por defecto. Pero dos avisos: las autoridades pueden incluir entidades pequeñas si su actividad es crítica, y si sois proveedores de una entidad afectada, los contratos van a empezar a incluir cláusulas NIS2 (medida 4 del art. 21 — cadena de suministro). En cualquier caso, el SIEM y el MFA siguen siendo buena idea.

→ Empezar con Wazuh (SIEM sin coste de licencia)

07 · Plan de acción

Cómo cumplir NIS2 sin entrar en pánico

Cumplir NIS2 no es magia. Es disciplina, instrumentación y dejarlo documentado. Estos son los siete frentes por los que arrancamos cuando un cliente nos llama para esto — y, en cada uno, la pieza concreta que ponemos:

  1. Diagnóstico de aplicabilidad y brechas. Sector, tamaño y mapeo contra el artículo 21 partiendo de lo que ya tienes documentado (ISO 27001, ENS, NIST CSF). Lo que típicamente cubrimos con una auditoría de seguridad y hacking ético.
  2. Gobierno de la ciberseguridad. Responsable nombrado, política aprobada en consejo (es obligatorio que la dirección la apruebe) y formación documentada para la dirección.
  3. SIEM/XDR y gestión de incidentes. Sin telemetría centralizada y runbooks, los plazos 24/72 h son cuento. Wazuh es nuestra vía por defecto — open source, sin coste de licencia, dashboards mapeados a NIS2/ENS. Si necesitas plataforma comercial corporativa con integraciones avanzadas, también desplegamos IBM QRadar.
  4. Soporte 24/7 con SLA. Detección sin equipo que responda no sirve para sostener las 24 h. Soporte 24/7 atendido en español, inglés y francés — sin intermediarios.
  5. MFA donde toca. Accesos privilegiados y remotos, mínimo. Si tienes entornos IBM Power (AIX, IBM i), PowerSC cubre esa capa con compliance integrado.
  6. Cadena de suministro. Inventario de proveedores TIC críticos y cláusulas de seguridad/notificación en contratos. La medida 4 del artículo 21 es donde más empresas se atascan — y donde, si eres proveedor de una entidad afectada, vas a recibir cláusulas igual aunque NIS2 no te aplique directamente.
  7. Formación periódica a empleados y dirección. La directiva lo exige expresamente (art. 20.2).

Capa extra si tu sector es industrial (energía, agua, transporte, fabricación, OT en general): la seguridad operativa no aparece en ningún ISO genérico. Para eso desplegamos Claroty con visibilidad de red OT y la auditoría de dispositivos industriales con Tenable.

FAQ

Preguntas rápidas

¿NIS2 ya es exigible si España no ha publicado la ley nacional?

Sí. La fecha límite de transposición era el 17 de octubre de 2024 (art. 41 de la directiva). El estado concreto de la ley española puede haber cambiado para cuando leas esto — comprueba el BOE —, pero las obligaciones de la directiva ya aplican desde esa fecha.

¿Qué diferencia hay entre entidad esencial e importante?

Las obligaciones técnicas del artículo 21 son idénticas. Cambian dos cosas: el régimen de supervisión (proactivo en esenciales, reactivo en importantes) y la sanción máxima (10 M€ o 2 % en esenciales; 7 M€ o 1,4 % en importantes).

¿Plazos exactos para notificar un incidente?

Alerta temprana en 24 h, notificación en 72 h e informe final en 1 mes. Cuentan desde que la entidad tiene conocimiento del incidente significativo (art. 23). Para sostenerlos hace falta SIEM y equipo localizable: Wazuh + soporte 24/7 es la combinación que típicamente desplegamos en SIXE.

¿Hay sanciones personales para directivos?

Sí. En supuestos graves de entidades esenciales: inhabilitación temporal para funciones de dirección (art. 32.5). Además, los órganos de dirección son responsables de aprobar y supervisar las medidas y de recibir formación específica (art. 20).

¿Vale mi ISO 27001 o ENS para cumplir NIS2?

Como base, sí — la mayoría de controles ya están. Pero no es equivalencia automática. Hay que mapear contra el artículo 21 y completar lo que falte: notificación 24/72 h, cadena de suministro, formación documentada a dirección. Es el primer entregable de una auditoría de seguridad bien hecha.

¿Y si soy proveedor TIC de una entidad afectada?

Aunque NIS2 no te aplique directamente, vas a empezar a recibir cláusulas NIS2 en contratos (medida 4 del art. 21 — cadena de suministro). Mejor anticiparlo: SIEM básico, MFA y un análisis propio de brechas evitan que un cliente te exija cosas a contrarreloj.

Cumplimiento NIS2 — paso por paso

Te ayudamos a aterrizar NIS2 sin venderte miedo

Empezamos por un diagnóstico de aplicabilidad y brechas contra el artículo 21, montamos el SIEM que sostiene los plazos 24/72 h y dejamos un equipo localizable 24/7 para cuando algo se rompe a las tres de la mañana. Más de 15 años en ciberseguridad de infraestructuras críticas, atención en español, inglés y francés, sin intermediarios.

Pedir diagnóstico NIS2 → Implantación de Wazuh Soporte 24/7

Si tocas open source en IBM Power, esto te interesa

/en
Comunidad · Open Source · IBM Power

LibrePower 2026: la encuesta anual sobre open source en IBM Power.

AIX, IBM i, Linux on Power, ppc64le. 12–20 minutos de tu experiencia se convierten en un informe público anual que ayuda a entender, con datos, cómo está realmente el ecosistema. Difundimos la encuesta desde SIXE para que llegue a más gente.

5 min lectura●Encuesta abierta●
Póster de la encuesta anual LibrePower 2026 sobre open source en IBM Power
Encuesta abierta en librepower.org/annual-survey

LibrePower acaba de abrir su encuesta anual sobre el estado del open source en IBM Power, y la puede responder cualquier persona que trabaje con la plataforma — administradores de AIX o IBM i, equipos Linux on Power, devs ppc64le, arquitectos, pre-sales, ISVs, IBM Champions y Business Partners. El resultado es un informe público anual que da una foto agregada y útil de qué funciona bien, qué cuesta más y qué prioridades ve la comunidad.

"Si IBM Power aparece en algún punto de tu trabajo, esta encuesta es para ti."
— LibrePower 2026

¿Qué es LibrePower y por qué participar?

LibrePower es un proyecto independiente centrado en el ecosistema open source de IBM Power. Su trabajo principal es publicar — una vez al año — un informe agregado y público sobre cómo está la plataforma desde el punto de vista de quien la opera y la construye: el admin de AIX que mantiene paquetes del Toolbox, el equipo IBM i que empieza a integrar herramientas modernas, el ingeniero que prepara ruedas de Python para ppc64le, el arquitecto que evalúa un workload nuevo en Power.

Entre encuestas, LibrePower mantiene una newsletter técnica en Substack con benchmarks, notas de porting a ppc64le y entrevistas con IBM Champions. Funciona como complemento a los canales oficiales y a los blogs de los vendors — una mirada adicional desde la propia comunidad técnica.

Por qué importa

Un informe basado en respuestas reales de la comunidad da contexto útil para todos: para quien usa la plataforma, para quien la construye y para quien decide qué priorizar. Cuanto más diversa sea la muestra, más representativo es el resultado.

¿Eres del público objetivo? Probablemente sí

La encuesta se adapta a tu perfil: solo ves las preguntas que tienen sentido para tu plataforma. Si trabajas con IBM i, no te aparecen las preguntas de AIX. Si haces Linux on Power, no opinas sobre VIOS. Y si tu único contacto con la plataforma es seguir el ecosistema desde fuera, también hay un camino para ti.

Está pensada para todo el espectro:

  • Operaciones — administradores L1, L2, L3 de AIX, IBM i, VIOS y Linux on Power. La gente que está al pie del cañón cuando algo se mueve en producción.
  • Desarrollo y plataforma — devs ppc64le, equipos DevOps/SRE, mantenedores open source, ingenieros que portan stacks a Power.
  • Arquitectura y pre-sales — quien decide entre Power y otras plataformas, quien diseña migraciones, quien acompaña a clientes en la elección técnica.
  • ISVs, IBM Business Partners y empleados de IBM — la voz de quien construye y vende sobre la plataforma cuenta tanto como la de quien la consume.
Qué te van a preguntar

Las áreas que cubre LibrePower 2026

La encuesta se divide en bloques temáticos. Verás solo los que apliquen a tu perfil, así que el recorrido real es más corto que la lista completa:

Estructura de la encuesta
01
Tú y tu plataformaRol, entornos que gestionas, workloads (Oracle, Db2, SAP, HANA, Java, contenedores, IA, HA/DR, modernización…). Define el resto del recorrido.
02
Tu visión desde el terrenoMadurez del open source en Power, recomendación (NPS 0–10), comunidad, contratación de skills, perfil de uso en producción.
03
Apertura por capasDe la ISA al firmware, pasando por documentación, distros, contenedores, CI/CD. Una matriz que mide qué tan abierta es cada capa que tocas en la práctica.
04
Realidad de AIX, IBM i y Linux on PowerTres bloques específicos — solo ves el que aplique. AIX Toolbox y dnf, RPM en IBM i vía ACS, ecosistema ppc64le en Linux, contenedores y CI.
05
Confianza en cada actorIBM, Red Hat, SUSE, Canonical, mantenedores independientes, ISVs, Business Partners. Solo evalúas a quien tengas base para juzgar.
06
Prioridades y cómo participarQué debería atacar LibrePower en los próximos 12 meses, qué paquete o runtime es el #1 a desbloquear, y cómo sumarte al proyecto si te interesa.

Por qué difundimos esto desde SIXE

Como IBM Business Partner con foco en open source, Linux on Power, AIX, IBM i y la plataforma Power en general, en los últimos años hemos visto crecer todo el bloque de software libre dentro del ecosistema — desde los repositorios oficiales hasta las herramientas modernas que aterrizan en IBM i, pasando por la evolución de ppc64le en Linux. Lo que vemos en consultoría y en formación es complementario a lo que se publica en los canales oficiales: casos concretos, decisiones reales, dudas que aparecen en proyectos.

Difundimos la encuesta porque cuanto más diversa sea la muestra, más útil es el informe — y, ya que estamos, nos gusta especialmente que la voz hispanohablante también esté ahí.

Si quieres ver con qué venimos trabajando en este espacio: probamos AIX 7.3, repasamos las novedades de IBM i 7.6 y comparamos hipervisores alternativos a ESXi (PowerVM, Proxmox, OCP). También damos formación oficial de AIX y soporte en Power, AIX, IBM i y Linux on Power.

Tres preguntas rápidas antes de empezar

¿Está en español?

De momento la encuesta está en inglés. Si esto es un freno, hay un campo libre al final ("¿algo que deberíamos haber preguntado?") donde puedes decirlo — es exactamente el tipo de feedback que mueve la próxima edición.

¿Y si no tengo experiencia en algo concreto?

Casi todas las preguntas tienen un "N/A" o "no lo sé". La encuesta está diseñada para que solo opines cuando tengas base para hacerlo — eso es justamente lo que da credibilidad al informe.

¿Puedo compartir el enlace con mi equipo?

Sí, encantados. Es librepower.org/annual-survey. Cuantos más perfiles distintos respondan, más útil es el informe.

15 minutos · Informe en tu buzón

Responde la encuesta anual de LibrePower

AIX, IBM i, Linux on Power, ppc64le. Si trabajas con la plataforma en cualquier capa, tu experiencia hace que el informe sea mejor. Independiente, anónima por defecto, accesible para toda la comunidad.

Responder la encuesta → Suscribirse a la newsletter Hablar con SIXE

Ceph en 2026: Novedades, versiones y hoja de ruta

/en
Almacenamiento · Ceph · Open Source

Ceph 2026: versiones, roadmap y despliegue en producción.

Squid es la versión estable. Tentacle está en camino. Y las decisiones que tomes sobre tu arquitectura de almacenamiento distribuido este año van a definir tu infraestructura los próximos cinco. Aquí tienes todo lo que necesitas saber — sin pitch comercial, solo ingeniería.

10 min lectura●Guía técnica●

Ceph es la plataforma de almacenamiento distribuido open source más madura y extendida que ofrece bloque, objeto y ficheros desde un solo clúster sin ningún punto único de fallo. Lo usan en producción organizaciones que gestionan petabytes de datos — desde centros de investigación hasta proveedores cloud. Con Tentacle (v20) ya publicada y Squid (v19) ampliamente desplegada, 2026 es buen año para entender dónde está Ceph y hacia dónde va.

En SIXE llevamos años desplegando y dando soporte a infraestructura Ceph en producción. Esta página es la referencia que nos habría gustado tener cuando empezamos: releases actuales, funcionalidades reales, mejores prácticas honestas y cero humo.

v20
Última release
(Tentacle)
3 en 1
Bloque + Objeto + Ficheros
en un solo clúster
0
Puntos únicos
de fallo
01 · Contexto

¿Qué es Ceph?

Ceph es una plataforma de almacenamiento distribuido open source que unifica almacenamiento de objeto, bloque y ficheros en un solo clúster. Fue creado por Sage Weil como parte de su doctorado en UC Santa Cruz, y actualmente lo mantiene una comunidad global con soporte comercial de IBM (como IBM Storage Ceph) y Red Hat (como parte de OpenShift Data Foundation).

Lo que diferencia a Ceph del almacenamiento tradicional es su algoritmo CRUSH: los datos se distribuyen en hardware commodity sin servidor central de metadatos, así que el clúster puede auto-repararse cuando un disco o nodo falla. Sin appliance propietario, sin vendor lock-in, sin punto único de fallo silencioso esperando a fastidiarte el trimestre.

Si estás evaluando alternativas, nuestra comparativa Ceph vs Storage Scale (GPFS), NFS y GFS2 cubre las diferencias. Para almacenamiento de objetos, consulta Ceph vs MinIO.

En pocas palabras

A Ceph le da igual cuántos discos tengas ni dónde estén. Añades hardware, Ceph redistribuye los datos. Pierdes hardware, Ceph reconstruye automáticamente. Esa es toda la propuesta de valor, y es buena.

02 · Versiones

Historial de versiones de Ceph

Ceph sigue un ciclo predecible con versiones mayores cada 12–18 meses, nombradas alfabéticamente con criaturas marinas:

ReleaseTentacle (20.x)Squid (19.x)Reef (18.x)
Publicada
Nov 2025
Mar 2024
Ago 2023
Estado
Activa / Recomendada
Activa
Fin de vida
Motor
Crimson madurando
Crimson adopción temprana
OSD clásico
Novedad clave
EC Crimson, tiering, MDS
RGW perf + CephFS NFS
Mirroring RBD
Ruta de upgrade
Objetivo actual
→ Tentacle
→ Squid → Tentacle

Quincy (17.x) llegó a fin de vida en 2025. Si sigues en ella, la ruta es Quincy → Reef → Squid → Tentacle. La documentación oficial de upgrade lo detalla paso a paso.

Recomendación

No te saltes versiones. Ceph solo soporta upgrades secuenciales (Quincy → Reef → Squid). Planificar el salto antes de que tu versión llegue a fin de vida sale considerablemente más barato que hacerlo con prisas.

CRONOLOGÍA DE VERSIONES CEPH Reef18.x · 2023EOL Squid19.x · 2024Activa Tentacle20.x · Nov 2025Recomendada U21.x · ~2027 → upgrade →→ upgrade →
Cronología de releases de Ceph — solo upgrades secuenciales. Cada versión mayor tiene soporte durante aproximadamente 2 años.
ARQUITECTURA UNIFICADA DE ALMACENAMIENTO CEPH RADOS Reliable Autonomic Distributed Object Store RBD Bloque RGW Objetos S3 CephFS Sistema de ficheros OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD · OSD Distribuido en hardware commodity — sin punto único de fallo VMs · Kubernetes · BBDDs Backups · Datos IA · Media HPC · CI/CD · Compartidos
Ceph ofrece almacenamiento de bloque, objeto y ficheros a través de un solo clúster RADOS. Cada interfaz sirve distintas cargas de trabajo, todas compartiendo la misma infraestructura auto-reparable.
03 · Novedades

Ceph Squid (v19): la release que consolidó Ceph

Squid es un paso adelante importante en rendimiento y madurez operativa. Lo más destacado:

Crimson OSD: adopción temprana

El Crimson OSD es una reescritura completa del Object Storage Daemon clásico usando el framework Seastar. Sustituye la arquitectura multi-hilo por un modelo shared-nothing, run-to-completion. En cristiano: latencia significativamente menor en clústeres con NVMe, especialmente para los patrones de I/O aleatorio pequeño típicos de bases de datos y virtualización. Crimson sigue madurando release a release — está disponible para adopción temprana en escenarios concretos, pero el OSD clásico sigue siendo el recomendado para la mayoría de despliegues en producción.

Rendimiento del RADOS Gateway

La capa de almacenamiento de objetos S3 ganó uploads multipart más rápidos, mejor garbage collection y menor consumo de memoria bajo cargas PUT intensivas. Si usas Ceph como data lake para datasets de entrenamiento de IA o como target de backup, este tipo de mejora poco sexy es la que te ahorra dinero real a escala.

CephFS + NFS-Ganesha

CephFS mejoró el soporte para exports NFS vía NFS-Ganesha, mejor rendimiento de snapshots y cuotas más granulares. Tenemos una guía detallada sobre alta disponibilidad NFS con Ceph y Ganesha si lo estás montando en producción.

Dashboard renovado

La interfaz web de gestión se renovó, con mejor integración de alertas Prometheus y nuevas páginas para mirroring RBD y subvolúmenes CephFS. No va a ganar premios de diseño, pero cumple.

04 · Última release

Ceph Tentacle (v20): la nueva generación

Tentacle se publicó el 18 de noviembre de 2025 y es la versión recomendada para nuevos despliegues. Sus mejoras principales sobre Squid:

  • Crimson para pools con erasure coding — extendiendo los beneficios de rendimiento de Crimson más allá de pools replicados.
  • Tiering RADOS más inteligente — políticas de colocación de datos mejoradas para clústeres híbridos NVMe + SSD + HDD.
  • Mejoras en cifrado RGW — gestión de claves más granular a nivel de bucket con integración KMS externa.
  • MDS a escala — mejor rendimiento del metadata server para clústeres con miles de millones de ficheros.

Las notas de release completas están en la página de releases de Ceph. Sigue el desarrollo en el tracker del proyecto y la lista ceph-devel.

A tener en cuenta

Si tienes Squid en producción y funciona bien, no hay prisa por saltar a Tentacle. Pero para nuevos despliegues, Tentacle es el punto de partida recomendado — arrancas con todas las mejoras de Squid más las novedades de Tentacle desde el día uno.

05 · Kubernetes

Rook-Ceph: almacenamiento para clústeres Kubernetes

Rook es el operador graduado en la CNCF que despliega y gestiona Ceph nativamente dentro de Kubernetes. Si trabajas con cargas de trabajo containerizadas, Rook-Ceph es la forma estándar de tener almacenamiento persistente sin salir del ecosistema Kubernetes.

Las releases recientes de Rook se han centrado en estabilidad del operador, escalado de OSDs más suave, mejores defaults de Helm para producción y mayor integración con OpenShift Data Foundation.

SIXE ofrece formación en Ceph que cubre tanto administración standalone como despliegues basados en Rook.

06 · Casos de uso

Funcionalidades y casos de uso de Ceph

Un clúster, tres interfaces. Ese es el truco de Ceph — y es uno bastante útil:

Tres interfaces, un clúster
■
RBD — Almacenamiento de bloqueDiscos virtuales para VMs (Proxmox, KVM, OpenStack) y PVs de Kubernetes. Thin provisioning, snapshots, clones y mirroring entre sites para DR.
■
RGW — Almacenamiento de objetos S3API REST compatible con S3. Targets de backup, datasets de IA/ML, repositorios multimedia, data lakes. Consulta nuestra comparativa Ceph vs MinIO.
■
CephFS — Sistema de ficheros POSIXAcceso compartido a ficheros para HPC, pipelines CI/CD y plataformas de contenidos. Multi-filesystem, cuotas, backups basados en snapshots.
■
Caso emergente: infraestructura IAS3 para distribución de modelos/datasets + RBD para volúmenes GPU. Consulta nuestro análisis de Storage Scale vs Ceph para inferencia IA.
Por qué importa

La mayoría de soluciones de almacenamiento te obligan a elegir: bloque O objeto O ficheros. Ceph hace las tres cosas desde un solo pool de hardware. Menos sistemas que operar, menos proveedores que gestionar y menos llamadas a las 3 de la mañana por el array de almacenamiento que habías olvidado que existía.

07 · Adopción

¿Quién usa Ceph en producción?

Ceph no es un experimento de laboratorio — ejecuta cargas críticas a escala. Proveedores cloud lo usan para infraestructura multi-tenant, instituciones de investigación para data lakes de petabytes, y empresas para almacenamiento unificado detrás de Kubernetes y OpenStack. CERN, Bloomberg, Deutsche Telekom, DigitalOcean y OVHcloud son algunos de los grandes adoptantes conocidos públicamente.

Los escenarios de despliegue más habituales que vemos en SIXE:

  • Infraestructura cloud — almacenamiento backend para OpenStack o Kubernetes, sustituyendo SANs propietarias.
  • Pipelines IA/HPC — almacenamiento de objetos S3 para datasets de entrenamiento, bloque para nodos de cómputo GPU.
  • Backup y archivo — almacenamiento de objetos con erasure coding sustituyendo cintas o appliances de deduplicación propietarias.
  • Compartidos empresariales — CephFS + NFS-Ganesha reemplazando NAS tradicional para compartidos departamentales.

Compatibilidad de plataformas

PlataformaCompatibleIntegraciónNotas
Kubernetes
Sí
Rook (CNCF)
CSI nativo, PV dinámico
OpenShift
Sí
ODF / Rook
Soporte Red Hat
Proxmox
Sí
Integrado
RBD + CephFS nativo
OpenStack
Sí
Cinder / Glance / Manila
Estándar de facto
VMware
Sí
Gateway iSCSI
No nativo, vía gateway
Nutanix
Parcial
iSCSI
Nutanix tiene su propio storage
08 · Mejores prácticas

Mejores prácticas de Ceph en 2026

Desplegar Ceph no es difícil. Desplegarlo bien es lo que marca la diferencia entre un clúster que funciona solo durante años y uno que te quita el sueño:

Dimensionamiento de hardware

  • OSDs: NVMe dedicados para la partición WAL/DB, aunque los discos principales del OSD sean HDD. Solo este cambio puede duplicar el rendimiento de escritura aleatoria.
  • Red: Mínimo 10 Gbps para la red pública, 10 Gbps separados para la red de clúster/replicación. La red es casi siempre el cuello de botella — no la CPU, no la memoria.
  • Memoria: Cuenta con 4–5 GB de RAM por daemon OSD. BlueStore sobre NVMe puede necesitar más.

Configuración

  • Replicación vs erasure coding: Replicación (3x) para cargas sensibles a la latencia (RBD, CephFS). Erasure coding para almacenamiento masivo (backups RGW, archivos). No adivines — haz profiling primero.
  • Mapa CRUSH: Diseñalo para reflejar tus dominios de fallo físicos (rack, fila, datacenter). La configuración por defecto asume que todos los OSDs están en un mismo dominio de fallo. No lo están.
  • Monitorización: Ceph Dashboard + Prometheus + Grafana. Alertas para caídas de OSD, umbrales nearfull y slow ops.

Errores comunes

El error de Ceph más frecuente que vemos en producción — could not connect to ceph cluster despite configured monitors — tiene una solución sorprendentemente simple la mayoría de las veces. Nuestra guía de troubleshooting de Ceph lo cubre paso a paso.

La regla de oro

Nunca dejes que un clúster Ceph supere el 85% de capacidad. El rebalanceo de CRUSH se vuelve cada vez más doloroso a medida que te acercas al límite. No notarás el problema gradualmente — lo notarás todo de golpe. Planifica la ampliación antes de necesitarla.

09 · Alternativas

Ceph vs el resto: comparativa rápida

Cada solución de almacenamiento tiene sus compromisos. Aquí va una foto honesta — sin tirar piedras a nadie, solo herramientas distintas para trabajos distintos:

​CephMinIOIBM Storage Scale
Tipos de almacenamiento
Bloque + Objeto + Fichero
Solo objeto
Fichero + Objeto
Protocolo
S3, NFS, iSCSI, RBD
S3
POSIX, NFS, S3
Complejidad
Media–Alta
Baja
Alta
Kubernetes nativo
Rook (CNCF)
Operator
Driver CSI
Coste licencia
Open source
Open source
Comercial
Mejor para
Infraestructura unificada
Cargas S3 puras
HPC / IA a escala

¿Necesitas el detalle completo? Nuestros análisis van más al fondo: Ceph vs MinIO y Ceph vs Storage Scale (GPFS).

10 · Soporte profesional

¿Necesitas ayuda con Ceph en producción?

Leer documentación es una cosa. Operar un clúster Ceph bajo SLA con datos que importan es otra conversación. SIXE es IBM Business Partner con experiencia directa diseñando, desplegando y operando infraestructura Ceph en toda Europa.

  • Consultoría y despliegue — Diseño de arquitectura, dimensionamiento de hardware, optimización del mapa CRUSH y hardening para producción.
  • Formación oficial en Ceph — Desde administración standalone hasta despliegues con Rook en Kubernetes, con laboratorios prácticos.
  • Soporte continuado — Monitorización, upgrades, resolución de incidencias. Ingenieros senior, sin helpdesks.
  • Consultoría de almacenamiento para IA/HPC — Arquitecturas Ceph para pipelines de machine learning y computación de alto rendimiento.
Ingeniería que habla tu idioma

Somos el equipo al que llamas cuando el clúster está en llamas — y el equipo al que deberías haber llamado antes de que se incendiara. Cuéntanos tu proyecto y te decimos lo que realmente hace falta.

Resumen

Lo esencial en 5 puntos

Para quien tiene prisa

→ Ceph Tentacle (v20) es la última release (nov 2025), con Crimson para erasure coding, tiering más inteligente y mejor rendimiento MDS.

→ Squid (v19) sigue siendo una rama activa sólida — ampliamente desplegada, con Crimson OSD en adopción temprana, RGW más rápido y mejor soporte CephFS/NFS.

→ Reef (v18) ha llegado a fin de vida — última release 18.2.8 en marzo de 2026. Planifica tu upgrade a Squid o Tentacle.

→ Rook-Ceph sigue siendo el estándar para despliegues Kubernetes nativos, ahora con escalado más suave.

→ Tres interfaces desde un solo clúster: bloque (RBD), objeto (RGW) y ficheros (CephFS) — la plataforma open source de almacenamiento unificado más madura que existe.

FAQ

Preguntas frecuentes

¿Cuál es la última versión estable de Ceph?

Ceph Tentacle (v20.x), publicada en noviembre de 2025. Squid (v19.x) sigue siendo una rama estable activa ampliamente desplegada. Reef (v18.x) llegó a fin de vida con su release final (18.2.8) en marzo de 2026 — los despliegues nuevos deberían orientarse a Squid o Tentacle.

¿Puede Ceph sustituir a NFS en producción?

CephFS puede servir exports NFS vía NFS-Ganesha, y funciona bien en producción. Pero Ceph no es un sustituto directo de NFS — requiere planificación de clúster, diseño de red y experiencia operativa. Es otro animal.

¿Es Ceph adecuado para cargas de producción?

Sí. Ceph funciona en producción en organizaciones que gestionan petabytes, desde instituciones de investigación hasta proveedores cloud. Tiene soporte comercial de IBM y Red Hat.

¿Cuál es la diferencia entre Ceph y MinIO?

Ceph ofrece bloque, objeto y ficheros desde un solo clúster. MinIO se centra exclusivamente en almacenamiento de objetos S3. Ceph es más versátil pero operativamente más complejo; MinIO es más sencillo para cargas de objetos puras. Ambos son excelentes — herramientas distintas, compromisos distintos.

¿Cómo funciona Rook-Ceph con Kubernetes?

Rook es un operador graduado en la CNCF que automatiza el despliegue, escalado y actualizaciones de Ceph dentro de Kubernetes. Proporciona aprovisionamiento dinámico CSI para volúmenes RBD y CephFS — creas un PVC, Rook se encarga del resto.

Fuentes

Referencias

Ceph. Documentación oficial y notas de release. docs.ceph.com/releases

Ceph. Página del proyecto y descargas. ceph.io

Rook. Cloud-Native Storage for Kubernetes. rook.io

IBM. IBM Storage Ceph. ibm.com/products/storage-ceph

Red Hat. Red Hat Ceph Storage. redhat.com/technologies/storage/ceph

Última actualización: .

Soporte Ceph profesional

¿Necesitas Ceph en producción? Hablemos de arquitectura.

Diseño de clúster, despliegue, formación y soporte continuado. Ingenieros senior de almacenamiento en toda Europa — sin helpdesks, sin colas de tickets. Solo gente que sabe de Ceph.

Contactar con SIXE +34 91 198 02 43

VMware en 2026: cuatro vías tras el cambio de Broadcom

/en
Virtualización · Infraestructura · 2026

VMware en 2026: cuatro vías tras el cambio de modelo de Broadcom.

Si tu vSphere 7 u 8 va como un tiro, no tienes ninguna obligación de tocarlo. Punto. Lo que cambió es el modelo de licencias, no la plataforma — y hay cuatro vías razonables: seguir con Broadcom, mantener lo que tienes con soporte de terceros (third-party support), migrar a Proxmox o saltar a OpenShift. La decisión sobre cuándo —o si— actualizar vuelve a tu lado. Nosotros llevamos cualquiera de las cuatro.

10 min lectura●Guía●

En 30 segundos: hay cuatro vías razonables para tu VMware en 2026 — seguir con Broadcom (VCF/VVF), mantener tu vSphere con soporte de terceros, migrar a Proxmox VE o saltar a OpenShift Virtualization. Las cuatro funcionan; el encaje depende de tu pila, tu calendario y cuánto presupuesto te apetece atar al fabricante.

Llevamos VMware desde antes de que existiera Broadcom y desde que existe Broadcom. Hacemos también soporte de terceros para tu pila empresarial, migraciones a Proxmox y a OpenShift, y formación oficial en lo que toque. No tenemos caballo ganador — tenemos clientes muy distintos, y este post es lo que les contamos cuando preguntan "¿y yo qué hago?".

4
Vías razonables
en 2026
2023
Adquisición de VMware
por Broadcom
15+
Años de SIXE
en virtualización empresarial
01 · Contexto

¿Qué ha cambiado en VMware desde la adquisición por Broadcom?

Broadcom cerró la compra de VMware el 22 de noviembre de 2023. A partir de ahí cambiaron varias cosas del modelo comercial —recogidas en el artículo oficial de Broadcom sobre cambios de portfolio—. La plataforma técnica sigue siendo la misma. Lo que cambia es cómo se contrata, no cómo funciona.

  • Fin de las licencias perpetuas nuevas. El catálogo pasó a vender suscripciones, principalmente a través de dos bundles: VMware Cloud Foundation (VCF) y VMware vSphere Foundation (VVF).
  • Reorganización del catálogo. Productos que antes se vendían por separado (vSAN, NSX, Aria) se integran en los bundles, lo que cambia el cálculo de licencias por servidor.
  • Programa de partners renovado. Los acuerdos de canal se renegociaron y muchos clientes pasaron a tratar directamente con Broadcom o con un partner de nivel superior.
  • Las licencias perpetuas existentes siguen siendo válidas: los clientes que ya las habían comprado pueden seguir usándolas, aunque sin actualizaciones nuevas si no contratan soporte.
En contexto

Es un cambio de modelo comercial, no un fallo técnico de VMware. Para algunas organizaciones la transición es asumible; para otras —especialmente las que no usan todos los componentes del bundle— la factura puede multiplicarse. Conviene hacer números antes de renovar, no después.

02 · Decisión

¿Por qué muchas empresas están repensando su VMware en 2026?

Lo escuchamos en casi todas las conversaciones — tres motivos que aparecen casi siempre juntos:

  1. La factura sube. Pasar a un bundle con piezas que no usas (vSAN, NSX, Aria) multiplica el coste por core.
  2. El reloj aprieta. Contratos plurianuales que vencen, y el típico email de "tu renovación es en 90 días, ¿confirmas?".
  3. La plataforma envejece. vSphere 7 cerró soporte general el 2 de octubre de 2025; vSphere 8 está anunciado para 2027.

No todo el mundo lo vive igual. Si tienes 3 hosts y un cluster modesto, el ajuste es asumible. Si tienes 300 hosts con vSAN extendido, abrir el abanico tiene un retorno claro y rápido. La pregunta ya no es "¿qué versión compro?"; ahora es "¿qué hago con todo lo que ya tengo desplegado y funcionando?".

03 · Las cuatro vías

¿Cuáles son tus cuatro opciones reales en 2026?

A día de hoy hay cuatro caminos razonables. No hay una respuesta universal: el encaje depende de cuánto VMware tienes, qué hace tu plataforma encima, qué equipo lo opera y qué calendario manejas.

Opción Para quién encaja Lo que ganas Lo que cuesta
1. Continuar con Broadcom (VCF / VVF)
Quien usa o necesita el bundle completo (vSAN, NSX, Aria) y tiene presupuesto para el nuevo modelo de suscripción.
Plataforma íntegra, hoja de ruta oficial, soporte directo del fabricante, acceso a nuevas versiones.
Suscripción anual, factura ligada al número de cores.
2. Mantener tu VMware con soporte de terceros
Quien está estable con vSphere 7 u 8 y quiere quedarse así varios años más, con ahorro en factura de licencias y autonomía sobre cuándo —o si— migrar.
Versión actual segura y operativa; SLA contractual; presupuesto liberado para inversión o capital humano; tiempo para evaluar Proxmox u OpenShift sin prisa.
Renunciar a nuevas versiones del fabricante y a soporte directo de Broadcom mientras dure el contrato.
3. Migrar a Proxmox VE
Equipos que buscan un hipervisor open source de propósito general equivalente a vSphere para VMs y contenedores LXC.
Plataforma abierta, sin licencias por host, con suscripciones de soporte opcionales y ecosistema empresarial maduro.
Proyecto de migración (P2V/V2V), reentrenamiento del equipo, reescritura de algunos automatismos.
4. Migrar a OpenShift Virtualization
Quien ya va hacia contenedores y Kubernetes y quiere consolidar VMs y pods en una sola plataforma.
Una sola plataforma para VMs y contenedores, integración nativa con CI/CD y red Kubernetes, soporte empresarial Red Hat/IBM.
Curva de adopción Kubernetes, rediseño de red y almacenamiento, plan de migración por oleadas.

Las cuatro funcionan. Lo que NO recomendamos: decidir a contrarreloj con la renovación encima. En ese escenario casi siempre se acaba renovando por inercia, sin haber comparado nada — y esa es la peor opción de todas, porque ni siquiera la has elegido.

Toca para seleccionar

¿Qué vía encaja contigo?

Tres preguntas rápidas y te decimos cuál de las cuatro vías tiene más sentido en tu caso. Sin recoger datos, sin pedir email — todo se calcula en tu navegador.

01¿Cuándo te vence el contrato actual con VMware?
02¿Hacia dónde mira tu plataforma en los próximos 3 años?
03¿Cómo de "VMware-pesado" es tu stack hoy?
Responde las 3 para ver el resultado
Tu recomendación inicial

04 · Vía 2 en detalle

¿Qué es el soporte de terceros (third-party support) para VMware?

No es "soporte técnico" al uso. Es lo que pasa cuando el fabricante deja de ser tu proveedor de mantenimiento y otro entra a hacer ese trabajo — nosotros, en este caso. Te mantenemos vSphere 7 u 8 estable, parcheado y con SLA contractual mientras tú decides qué hacer a largo plazo. No sustituye a las actualizaciones de versión del fabricante. Sí sustituye al contrato de mantenimiento — que es donde se va el dinero.

La gente nos contrata por cuatro motivos, en distintos órdenes:

  • Quedarse en vSphere 7 u 8 cinco o diez años más sin que nadie te apriete a actualizar. Si tu plataforma está estable, no necesitas una versión nueva — necesitas que la tuya siga segura.
  • Recuperar la palanca: el calendario lo fijas tú, no la fecha de fin de soporte general que te marca Broadcom.
  • Sacar el dinero del mantenimiento de software y meterlo donde aporta — hardware nuevo, un proyecto que llevabas un año aparcando, una persona más en el equipo.
  • Un solo contrato para toda la pila (hipervisor, hardware, SO invitado). Dejas de coleccionar contratos verticales con el fabricante de turno.

Encaja particularmente bien cuando tu vSphere está sólido y quieres estirarlo mientras evalúas con calma Proxmox u OpenShift — o ninguna de las dos, si cambias de idea por el camino. Cubrimos vSphere 7 y 8 desde España, en castellano, con ingeniero asignado que no rota. El alcance exacto, el SLA y el proceso están en soporte VMware 7 y 8; si lo que necesitas es la misma idea para SAP, eso vive en el hub de soporte de terceros.

05 · Vías 3 y 4 en detalle

¿Y si lo que quiero es migrar? ¿Proxmox u OpenShift?

Depende de a dónde va tu plataforma en los próximos cinco años.

Proxmox VE — la migración lateral

Proxmox VE es la respuesta natural si lo que tienes es un VMware-shop clásico —VMs Windows y Linux, almacenamiento compartido, copias de seguridad— y quieres un hipervisor open source que se parezca a lo que ya operas. Soporta importación de VMs desde VMware, vive sobre KVM y LXC, y tiene suscripción de soporte empresarial disponible. Es una migración lateral, no un cambio de paradigma.

OpenShift Virtualization — la consolidación con Kubernetes

OpenShift Virtualization (basado en KubeVirt) es la respuesta si tu organización ya va hacia contenedores y quieres una sola plataforma para VMs y pods. Permite ejecutar máquinas virtuales como recursos de Kubernetes, junto a tus aplicaciones contenerizadas, con la misma red y el mismo almacenamiento. Tiene más curva de aprendizaje, pero también más recorrido si tu hoja de ruta es cloud-native.

Una tercera vía: OpenStack

Hay un cuarto destino que conviene tener en mente: OpenStack con Ceph sigue siendo una opción sólida para entornos grandes que quieren operar una nube privada completa. La elección entre los tres no es ideológica; es de fit técnico y de equipo.

06 · Coste y plazos

¿Cuánto cuesta migrar de VMware? ¿Y cuánto se tarda?

No hay tarifa de catálogo. Cualquiera que te dé una cifra sin mirar tu infraestructura, te la está inventando. Lo que tarde y lo que cueste depende de tres cosas:

  • Tamaño del estate: número de hosts, número de VMs, tamaño en TB, presencia de vSAN/NSX.
  • Complejidad de la red y el almacenamiento: redes distribuidas, microsegmentación, replicación, DR.
  • Dependencias de la pila superior: backup, monitorización, automatización, CI/CD.

Como referencia para planificar:

  • Un proyecto de migración de decenas de VMs desde vSphere a Proxmox o a OpenShift se ejecuta típicamente en semanas, con ventanas controladas por servicio.
  • Un proyecto sobre cientos de VMs se ejecuta en meses, por oleadas y con un strangler pattern: nuevas cargas en la plataforma destino, cargas existentes migradas por bloques.
Insight clave

Lo que más alarga (y encarece) los proyectos no suele ser el hipervisor: son las dependencias que cuelgan de él — backup, DRP, automatismos antiguos, integraciones con CMDBs. Por eso el primer entregable de cualquier migración seria es un inventario y un mapa de dependencias, no un PoC del hipervisor nuevo.

07 · Método

¿Cuál es el orden recomendado para decidir?

Este es el procedimiento que aplicamos en SIXE cuando un cliente nos pregunta "¿qué hago con VMware?". Marca los pasos a medida que los completes — la barra te indica cuánto te queda y el plan es tuyo.

Método SIXE · 5 pasos antes de renovar o migrar 0 / 5 completados
1
Inventario real del estate

Hosts, cores, VMs, vSAN, NSX, Aria, contratos vigentes y fecha de vencimiento. Sin esto, cualquier cálculo es ficción.

2
Mapa de dependencias de la pila superior

Backup, DRP, monitorización, automatización, integraciones con CMDBs. Aquí están los plazos reales — y los riesgos ocultos.

3
Tres números comparables

Coste de renovar con Broadcom bajo el nuevo modelo · Coste de third-party support 12-24 meses · Coste estimado de migración (mano de obra + herramientas + formación).

4
Decisión informada — o combinación

Las cuatro vías pueden combinarse. Ejemplo frecuente: soporte de terceros durante 18 meses + migración progresiva a Proxmox para cargas estándar y a OpenShift para cargas que vayan a contenedores.

5
Plan de ejecución por oleadas

Revisión trimestral. Lo importante es separar la decisión técnica del calendario comercial — la palanca está en tu mano, no en la fecha de renovación.

08 · Equipo

¿Y la formación del equipo?

Cualquiera de las cuatro vías exige formación, aunque en proporciones distintas:

  • Continuar con VMware bajo Broadcom: poca formación nueva, sobre todo en el modelo de licenciamiento y en los bundles.
  • Soporte independiente: ninguna formación adicional; el equipo sigue operando lo que ya conoce.
  • Proxmox VE: formación moderada; el modelo mental se parece a vSphere pero las herramientas y la red son distintas.
  • OpenShift Virtualization: formación significativa en Kubernetes y en el modelo declarativo; conviene empezarla antes de la migración, no durante.

En SIXE somos partner formativo para varias de estas plataformas: VMware, Red Hat (incluido OpenShift) y soluciones basadas en KVM. Si quieres mantener a tu equipo certificado en lo que ya operas, tenemos formación oficial en VMware vSphere. Cuando la migración la acompaña formación temprana, las oleadas van más rápido y con menos incidentes.

Sustituye el placeholder por la imagen real (1200×630) manteniendo el alt
10 · Nuestra postura

¿Es VMware una mala plataforma tras Broadcom?

No. Y conviene aclararlo. Hay cosas que podríamos decir para sacar clics fáciles, y que no vamos a decir:

  • Que VMware es un mal producto. No lo es — lo soportamos desde hace más de quince años.
  • Que Broadcom es el malo de la película. Es una decisión comercial legítima de un fabricante. A los clientes les toca decidir qué hacer con ella, no insultar al que la tomó.
  • Que Proxmox u OpenShift son "la respuesta". Son una respuesta cuando encajan. En otros casos lo que toca es quedarse en VMware — con o sin Broadcom.
Lo que sí te decimos

No decidas con prisa, haz números con las cuatro, y si te falta tiempo para hacerlo bien, el soporte de terceros está justamente para eso. Llevamos VMware desde antes de que existiera Broadcom. Soportamos también Proxmox, OpenShift y OpenStack. Lo que tú decidas, lo ejecutamos — esa es la diferencia.

Resumen

Lo esencial en 5 puntos

Si has venido a saltar al final

→ Cambió el modelo, no la plataforma. Suscripción (VCF/VVF) en lugar de perpetuas nuevas. Las perpetuas que ya tienes siguen siendo tuyas.

→ Cuatro vías razonables: seguir con Broadcom, soporte de terceros, migrar a Proxmox o saltar a OpenShift. Las cuatro funcionan.

→ Soporte de terceros = comprar tiempo sin renunciar a seguridad. Tu vSphere 7 u 8 sigue parcheado y con SLA, pero el contrato deja de ser con Broadcom.

→ No empieces por el PoC del hipervisor nuevo. Empieza por el inventario y el mapa de dependencias. El hipervisor casi nunca es la parte difícil.

→ Las cuatro vías son combinables. La pauta más frecuente: 12-18 meses de soporte de terceros + migración por oleadas en paralelo.

FAQ

Preguntas frecuentes

¿El soporte de terceros para VMware es legal?

Sí, y no es zona gris. Cubre el mantenimiento operativo de las versiones que ya tienes desplegadas, sin redistribuir software ni modificar licencias. No sustituye a las actualizaciones de versión del fabricante — sustituye al contrato de mantenimiento, que es otra cosa.

¿Puedo seguir usando VMware si no renuevo con Broadcom?

Si tienes licencias perpetuas previas, sí: puedes seguir ejecutándolas. Lo que pierdes es el acceso a actualizaciones nuevas y a soporte directo del fabricante. Para cubrir ese hueco existe el soporte independiente para VMware 7 y 8 con SLA contractual.

¿Cuándo termina el soporte de vSphere 7 y vSphere 8?

VMware vSphere 7 alcanzó el fin de soporte general (EoGS) el 2 de octubre de 2025, según la comunicación oficial de Broadcom. Para vSphere 8, el calendario apunta a 2027. Las fechas se actualizan periódicamente en el portal oficial de lifecycle.

¿Es Proxmox VE una alternativa empresarial seria?

Sí, y los que sigan diciendo lo contrario llevan años sin mirarlo. Se usa en producción en organizaciones serias, tiene suscripciones de soporte empresarial y un ecosistema maduro de backup, alta disponibilidad y clustering. La diferencia con VMware no es de madurez técnica — es de modelo (open source vs. propietario) y de herramientas.

¿OpenShift Virtualization sirve para sustituir a vSphere?

Para muchas cargas, sí. Ejecuta VMs como objetos de Kubernetes y te deja consolidar VMs y contenedores en una sola plataforma. Si tu organización no va a Kubernetes en los próximos años, no es para ti. Si ya vas en esa dirección, es de las mejores cartas que tienes sobre la mesa.

¿Cuánto se ahorra exactamente migrando o pasando a soporte de terceros?

Depende del estate y del modelo actual. Es habitual encontrar ahorros relevantes en infraestructuras grandes con bundles que no se usan al 100 % — pero solo se puede decir un número tras hacer el cálculo con tus números. Cualquier porcentaje sin tu inventario es marketing.

¿Y el mismo enfoque para SAP?

Sí. Aplicamos la misma lógica de "decide tú, ejecutamos cualquier vía" a la infraestructura SAP — IBM Power, AIX, Linux para SAP HANA. Lo cubrimos en nuestra página de soporte independiente para SAP.

Fuentes

Referencias

Broadcom. End of General Support for vSphere 7.0 (2 de octubre de 2025). knowledge.broadcom.com / KB 415405

Broadcom. VMware Product Portfolio and Licensing Changes. knowledge.broadcom.com / KB 313749

Broadcom. Product Lifecycle Portal. support.broadcom.com / productlifecycle

VMware Cloud Foundation Blog. Reminder: vSphere 7 to reach End of Service on October 2, 2025. blogs.vmware.com / vsphere-7-eos

VMware (Broadcom). VMware Cloud Foundation. vmware.com / cloud-foundation

Proxmox Server Solutions. Proxmox Virtual Environment — documentation. pve.proxmox.com

Red Hat. OpenShift Container Platform — Virtualization. docs.redhat.com / openshift

KubeVirt Project — upstream open source de OpenShift Virtualization. kubevirt.io

Northdoor. VMware vSphere End of Support: Action Plan for 2025 & 2027 (análisis independiente). northdoor.co.uk / vsphere-end-of-support

SIXE — soporte independiente para tu pila empresarial · soporte independiente para VMware 7 y 8

Escrito por el equipo de ingeniería de virtualización de SIXE — la gente que se mete dentro de tu pila cuando se cae. Última actualización: .

Segunda opinión, sin chorradas

¿Quieres ver las cuatro vías con tus números, no con los nuestros?

Te montamos un informe corto con el coste real de cada opción aplicado a tu inventario: seguir con Broadcom, soporte de terceros, Proxmox u OpenShift. La primera conversación es gratis — si no encajamos, no encajamos. Si encajamos, ya nos lo dirás tú.

WhatsApp Solicitar evaluación +34 91 198 02 43

Actualizar de Debian 12 a Debian 13 Trixie (guía 2026)

/en
Linux · Debian · Sistemas

Cómo actualizar de Debian 12 a Debian 13 Trixie sin romper producción.

Debian 13 «Trixie» ya es la versión estable. Esta es la guía paso a paso que seguimos en SIXE para actualizar servidores de producción: preparación, repositorios, full-upgrade y plan de rollback. Sin sustos.

8 min lectura●Guía técnica●

Para actualizar de Debian 12 Bookworm a Debian 13 Trixie: haz backup, deja Bookworm completamente parcheado, cambia los repositorios de bookworm a trixie, ejecuta primero apt upgrade --without-new-pkgs y luego apt full-upgrade, limpia y reinicia.

Simple en un servidor de laboratorio. Otra cosa es hacerlo en una flota en producción con bases de datos, servicios críticos y SLA. En SIXE llevamos más de 15 años manteniendo infraestructuras Linux en producción, y esta es la metodología exacta con la que abordamos un dist-upgrade sin downtime imprevisto. Solo se soporta el salto 12 → 13: si estás en Debian 11, pasa antes por Debian 12.

2030
Soporte de Trixie
(3 años + 2 de LTS)
~59.000
Paquetes en
los repositorios
20-60'
Duración típica
del upgrade
01 · Novedades

¿Qué es Debian 13 Trixie y qué cambia respecto a Bookworm?

Debian 13 «Trixie» es la versión estable de Debian desde el 9 de agosto de 2025. Incorpora el kernel Linux 6.12 LTS, la finalización del merge de /usr (ya obligatorio), la transición a time_t de 64 bits (preparando el problema del año 2038 en arquitecturas de 32 bits) y APT 3.0, con una salida más clara y mejor resolución de dependencias.

Para un servidor en producción no es una revolución, sino justo lo que se espera de Debian: una base más limpia, kernel moderno y cinco años de soporte de seguridad por delante. Lo más relevante a nivel operativo es que el ciclo de vida vuelve a empezar — y el de Bookworm empieza a agotarse.

En contexto

Trixie no obliga a reaprender nada: mismo APT, misma filosofía. El esfuerzo está en planificar el salto, no en adaptarse a un sistema nuevo.

02 · Ciclo de vida

¿Hasta cuándo tiene soporte Debian 12 Bookworm?

Desde que Trixie salió en agosto de 2025, Debian 12 pasó a ser oldstable. Mantiene soporte de seguridad LTS hasta aproximadamente junio de 2028, pero deja de recibir el soporte completo del equipo de seguridad. No es una urgencia crítica, pero cada mes que pasa acumulas más deuda técnica y reduces la ventana para actualizar con calma.

CICLO DE VIDA DEL SOPORTE — DEBIAN 12 vs DEBIAN 13 20232025202620282030 HOY Debian 12 «Bookworm» LTS → jun 2028 Debian 13 «Trixie» → jun 2030 Soporte completo LTS
Ventanas de soporte de Debian 12 y Debian 13 — fechas aproximadas según el ciclo de vida de Debian
Recomendación

No esperes al final del ciclo de Bookworm. Planifica la actualización en una ventana tranquila, no a contrarreloj cuando dejen de llegar los parches de seguridad.

03 · Preparación

¿Qué hay que preparar antes de actualizar?

Un dist-upgrade es seguro si lo preparas. La mayoría de los desastres que hemos visto no vienen del upgrade en sí, sino de saltarse esta fase. Marca cada punto antes de empezar:

Checklist pre-vuelo 0 / 6 completado
✓ Backup completo o snapshot. En máquina virtual, snapshot completo: es tu botón de rollback.
✓ Leer las notas de publicación de Debian 13 para tu caso (issues conocidos).
✓ Espacio en disco suficiente en / y /var para descargar los paquetes nuevos.
✓ Acceso fuera de banda (consola/IPMI/KVM) por si SSH se cae durante el proceso.
✓ Limpiar /boot de kernels antiguos para que quepa el kernel 6.12.
✓ Ventana de mantenimiento acordada y usuarios avisados.

¿Los seis marcados? Entonces sí, adelante con el upgrade.

04 · Paso a paso

¿Cómo actualizar de Debian 12 a Debian 13 paso a paso?

El proceso tiene seis fases: dejar Bookworm al día, apuntar los repositorios a trixie, desactivar repos de terceros, ejecutar primero la actualización mínima y luego la completa, limpiar y reiniciar verificando. Este es el flujo y los comandos exactos.

El upgrade en 6 fases
1
Parchear BookwormEl upgrade parte de un sistema 100% al día
2
Repos a Trixiebookworm → trixie (incluido trixie-security)
3
Desactivar repos de tercerosSe reactivan uno a uno al terminar
4
Upgrade mínimo + completo--without-new-pkgs y luego full-upgrade
5
Limpiezaautoremove + autoclean
6
Reinicio y verificacióncat /etc/debian_version → 13.x

1. Deja Debian 12 completamente al día

Cualquier parche pendiente se convierte en un conflicto durante el salto. Parte de un Bookworm impecable:

root@debian12 — bash
$ sudo apt update
$ sudo apt upgrade
$ sudo apt full-upgrade
$ sudo apt --purge autoremove

2. Apunta los repositorios a Trixie

Cambia bookworm por trixie en tus fuentes APT. Esto cubre también bookworm-security → trixie-security. Revisa el resultado con cat antes de seguir.

editar fuentes APT
# Formato clásico
$ sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list

# Formato DEB822 (instalaciones recientes de Debian 12)
$ sudo sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources

3. Desactiva temporalmente los repositorios de terceros

Cualquier repo externo en /etc/apt/sources.list.d/ (Docker, PostgreSQL, etc.) puede bloquear el upgrade si aún no soporta Trixie. Desactívalos ahora y reactívalos uno a uno después, comprobando que cada uno ya publica para Debian 13.

4. Ejecuta la actualización: mínima primero, completa después

La actualización mínima reduce el riesgo de conflictos de dependencias. Acompaña el proceso: responderás a algún prompt sobre ficheros de configuración modificados.

root@debian12 — dist-upgrade
$ sudo apt update
$ sudo apt upgrade --without-new-pkgs   # actualización mínima
$ sudo apt full-upgrade                 # actualización completa

5. Limpia los paquetes obsoletos

limpieza
$ sudo apt --purge autoremove -y
$ sudo apt autoclean

6. Reinicia y verifica

root@debian13 — verificación
$ sudo reboot
# tras el reinicio:
$ cat /etc/debian_version   # -> 13.x
$ uname -r                  # -> 6.12.x
$ systemctl --failed        # ningún servicio caído
05 · Rollback

¿Cuánto tarda y se puede hacer rollback?

En un servidor típico, el upgrade tarda entre 20 y 60 minutos según el número de paquetes y la velocidad de disco y red. El rollback de un dist-upgrade no es trivial una vez instalados los paquetes: por eso el snapshot previo es innegociable. En máquinas virtuales, revertir al snapshot es cuestión de minutos; en hardware físico, el plan de rollback es restaurar desde backup.

Regla de oro

Nunca hagas un salto de versión mayor en producción sin una vía de vuelta probada. Un backup que no has restaurado nunca no es un backup: es una esperanza.

06 · Errores comunes

¿Qué errores son los más comunes al actualizar a Trixie?

Lo que más vemos en producción, y cómo evitarlo:

  • Repos de terceros sin versión para Trixie que bloquean apt: desactívalos antes (paso 3).
  • /boot lleno que impide instalar el kernel nuevo: limpia kernels antiguos antes de empezar.
  • Ficheros de configuración pisados por aceptar la versión del paquete sin mirar: ante la duda, conserva tu versión y revísala después.
  • Olvidar --without-new-pkgs en la fase mínima, lo que dispara conflictos de dependencias.
  • Servicios propios que asumen rutas de /usr no fusionadas: el /usr-merge ya es obligatorio en Trixie.
07 · En contexto

¿Debian o Ubuntu para tu servidor?

Es la pregunta que más nos hacen. No hay respuesta universal: depende de si valoras más el control y la independencia (Debian) o el soporte comercial integrado y herramientas como Ubuntu Pro y Landscape (Ubuntu). Esta es la comparativa rápida:

​Debian 13Ubuntu ProRHEL
Gobernanza
Comunitaria
Canonical
IBM / Red Hat
Soporte / versión
5 años + ELTS
10 años
10 años
Paquetes
~59.000
~30.000
~5.000
Coste de licencia
0 €
Por nodo
Por nodo
Soporte en español
SIXE
SIXE UP
SIXE

¿Trabajas con Ubuntu? Como partner de Canonical también te cubrimos con SIXE UP. Y si tu caso es migrar entre distribuciones, gestionamos migraciones sin interrupciones.

Ingeniero de SIXE actualizando un servidor de Debian 12 Bookworm a Debian 13 Trixie en un datacenter
08 · Soporte profesional

¿Y si prefieres no tocar producción tú mismo?

Actualizar un servidor de laboratorio es una tarde. Actualizar una flota en producción con SLA, bases de datos y servicios críticos es otra historia: hay que inventariar dependencias, validar en staging, coordinar ventanas y tener un rollback probado.

Eso es exactamente lo que hacemos en SIXE. Ofrecemos soporte profesional para Debian —upgrades de versión planificados, hardening con monitorización Wazuh, y resolución de incidencias con SLA— y, si lo necesitas urgente, contamos con soporte 24/7. ¿Quieres dejar a tu equipo formado? Tenemos formación oficial en Linux.

Más de 15 años manteniendo Linux en producción

Ingeniería senior que habla tu idioma, sin helpdesks ni escalados. ¿Tienes que actualizar varios servidores a Debian 13? Cuéntanos tu caso y te proponemos un plan con ventana de mantenimiento y rollback.

Resumen

Lo esencial en 5 puntos

Para quien tiene prisa

→ Debian 13 Trixie es la estable desde agosto de 2025; Debian 12 ya es oldstable (LTS hasta ~2028).

→ Backup/snapshot antes de nada. Es tu único rollback real.

→ Parte de un Bookworm 100% parcheado, cambia los repos a trixie y haz upgrade --without-new-pkgs antes del full-upgrade.

→ Desactiva los repos de terceros durante el proceso.

→ Solo se soporta 12 → 13: desde Debian 11, pasa antes por Debian 12.

FAQ

Preguntas frecuentes

¿Se puede actualizar de Debian 11 directamente a Debian 13?

No. Debian solo soporta el salto entre versiones consecutivas. Desde Debian 11 «Bullseye» hay que actualizar primero a Debian 12 «Bookworm» y, una vez ahí, a Debian 13 «Trixie».

¿Pierdo mis datos y configuraciones al actualizar?

No, un dist-upgrade conserva datos y configuraciones. Aun así, un backup o snapshot completo es obligatorio: es tu plan de rollback si algo falla.

¿Es mejor actualizar o reinstalar desde cero?

Para un servidor bien mantenido, el dist-upgrade es seguro y mucho más rápido. La reinstalación solo compensa si el sistema arrastra mucha deuda técnica o configuraciones inconsistentes.

Fuentes

Referencias

Debian. Información de la versión Debian 13 «trixie». debian.org/releases/trixie

Debian. Notas de publicación de Debian 13. debian.org/releases/trixie/releasenotes

Debian. Debian 13 «trixie» released (09-08-2025). debian.org/News/2025

Debian Security Team. debian.org/security

Última actualización: .

Soporte Debian profesional

¿Tienes que actualizar tus servidores a Debian 13?

Te proponemos un plan de actualización con auditoría previa, validación en staging, ventana de mantenimiento y rollback probado. Ingeniería senior en español, con SLA.

Contactar con SIXE +34 91 198 02 43
SIXE