soberanIA@localhost: IA privada en local para PYMEs, del hierro al modelo en producción

El pasado mes de junio tuve el placer de cerrar el Hack & Beers Gijón Vol. 5 con una charla que llevaba tiempo queriendo dar: «soberanIA@localhost». La idea de fondo es tan simple como provocadora: con alrededor de 1.000 € de hardware y tu tiempo, puedes montar una IA privada de nivel profesional que no manda ni un solo dato fuera de tu máquina.

Como quienes me seguís desde hace años ya sabéis, en mis charlas siempre me mojo y esta no iba a ser menos. Os comparto aquí el recorrido completo, diapositiva a diapositiva, porque me habéis preguntado varios por el contenido. Aviso desde ya: esto NO es un tutorial de instalación paso a paso ni una lista de comandos para copiar y pegar. Es lo que funcionó, lo que no, y el criterio para decidir en cada caso, con datos medidos en mi propio hardware. Los errores incluidos, que de esos se aprende más que de los éxitos maquillados. Tenéis la presentación adjunta al final del post y abajo os explico cada diapo.

1. Portada: soberanIA@localhost

El título no es casual. soberanIA@localhost es un guiño al prompt de una terminal: el usuario «soberanía» conectado a «localhost», a tu propia máquina. Todo gira alrededor de esa idea, la de recuperar el control de tu IA y de tus datos. Va de terminal, de control y de hacértelo tú.

2. De qué va (y de qué no va) esta charla

Antes de nada, gestionar expectativas. Esto NO es un tutorial de instalación, ni humo de vendedor, ni la promesa de que la IA local sustituye al cloud en todo, porque no es verdad.

Lo que SÍ es: experiencia real medida en mi hardware, números reproducibles, los errores incluidos (el eGPU que se me cae, modelos que se inventan herramientas) y, sobre todo, criterio para decidir caso por caso. Meter los fallos no es debilidad, es lo que da credibilidad ante un público técnico, así de claro. El que solo enseña lo que salió bien, algo os está vendiendo.

3. ¿Por qué IA local AHORA?

Porque lo que hace 18 meses era impensable, hoy cabe en una GPU de consumo. Cuatro cosas cambiaron entre 2025 y 2026: la cuantización avanzada (modelos grandes en poca VRAM), las arquitecturas MoE eficientes, los modelos open source que ya compiten de tú a tú, y el hardware de consumo con GPU asequible.

La PYME ya quiere IA. La pregunta no es si la va a usar, sino a qué precio para sus datos. Y ese precio, en el cloud, se paga en soberanía.

4. Privacidad en IA cloud: ¿qué recogen?

Datos del estudio de Surfshark sobre cuántos puntos de datos recoge cada servicio (sobre 35 posibles). Gemini es el más intrusivo con 22, y es el único que se lleva tu lista de contactos del móvil. Le siguen Claude y Copilot con 13, DeepSeek con 11, ChatGPT con 10 y Grok con 7.

El dato que más me interesa remarcar: Anthropic cambió su política en septiembre de 2025. Antes era el único que no entrenaba con datos de consumidor por defecto. Ahora sí lo hace salvo que hagas «opt-out», con retención de cinco años si tienes el training activado. Ojo, que Surfshark mide cantidad de datos recogidos, que es UNA métrica de varias, no el veredicto absoluto. Pero da una foto bastante clara.

5. Los modelos chinos: el matiz que importa

Esta diapo la metí a conciencia, porque el discurso fácil («es chino, es malo») es un prejuicio, no un análisis. DeepSeek, MiniMax, GLM, Qwen… lideran el uso mundial. Son buenísimos. ¿Dónde está entonces el problema real?

El problema NO es el modelo. Son open-weight. Si los corres en tu hardware, como hago yo en la charla, la preocupación de datos desaparece. El modelo es legítimo.

El problema SÍ es el servicio hospedado. La web y la API oficial mandan tus datos a servidores en China. Y ahí entra la Ley de Inteligencia Nacional china de 2017, que obliga a las empresas a ceder datos a las autoridades sin avisar al usuario. Sumadle la ausencia de decisión de adecuación de la UE, la transferencia transfronteriza sin garantías y la retención sin límite claro. Por eso la Garante italiana bloqueó DeepSeek, y Berlín y Bélgica abrieron investigaciones.

Y lo honesto, que es como me gusta contarlo: esto es un gradiente, no un blanco o negro. Estados Unidos tiene su «Cloud Act», que también permite acceso gubernamental. La diferencia está en el grado de garantías y de recurso legal. Por eso lo verdaderamente soberano es lo local. El truco con los modelos chinos es sencillo: úsalos en local o en cloud occidental, no en su servicio oficial.

6. Las trampas que nadie cuenta

La letra pequeña de la privacidad en el cloud. Cuatro trampas que conviene tener claras:

El pulgar arriba entrena el modelo, aunque tengas la privacidad desactivada. Ese botón de feedback envía la conversación al training pese al «opt-out». Los GPTs de terceros traen su propia opción de entrenamiento activada por defecto, que ignora tu configuración global. El sello de «cumple RGPD» no significa datos en Europa: muchos usan el certificado DPF y operan desde EEUU. Y el DPA (el contrato de encargo del tratamiento, art. 28 RGPD) solo está en los planes Enterprise: los planes consumer no te dan protección legal completa.

La conclusión: ningún plan consumer da protección legal completa. Solo el local te da control total.

7. Mi setup

El hierro, sin postureo. Un Slimbook EVO (Ryzen Phoenix, 64 GB de RAM) como portátil de trabajo y cliente. Una RTX 5060 Ti de 16 GB (ASUS DUAL OC, Blackwell) por 599 €. Un dock eGPU USB4 de Slimbook por 199 €. Y un HP Z440 (Xeon E5-1660v4, 64 GB ECC) como host dedicado 24/7.

Coste total del proyecto: alrededor de 1.020 € para una IA local profesional completa. El Slimbook es el que me llevo con la eGPU; el Z440 se queda en casa sirviéndonos a mí y a Sheila por LAN. Elegí mono-Xeon a propósito: menos consumo y ruido que un bi-Xeon, y para Ollama la CPU casi no trabaja.

8. El cuello de botella oculto: el bus

Esta es de las lecciones que más me gusta contar, porque desmonta una suposición muy extendida. USB4 mueve unos 3,5 GB/s; un PCIe x16 mueve 32 GB/s. Con la misma GPU, lo que cambia el rendimiento no es lo que os imagináis.

Medido en mi equipo: modelo entero en VRAM (0% de «offload»), 86 tokens/s. Con un 15% en CPU, 34 t/s. Con un 25% en CPU, 17 t/s. ¿Y sabéis cuánto se gana poniendo la CPU en modo «performance»? Un mísero 10%. El cuello de botella era el bus, no la CPU. Por eso el host dedicado lleva la GPU en PCIe x16 directo. La diferencia entre una demo usable y una lamentable puede estar ahí. Lección de consultor: mide cada variable, no des nada por supuesto.

9. El stack: 100% open source

Nada de cajas negras, como no podía ser de otra forma viniendo de mí y de mis Debian ;). Ubuntu Server 24.04 LTS gestionado por SSH. El driver NVIDIA 595-open, obligatorio por ser Blackwell. Docker con el NVIDIA Container Toolkit para dar acceso a la GPU a los contenedores. Ollama como runtime de los modelos. Open WebUI como frontend accesible por LAN. Y bge-m3 para los embeddings locales del RAG.

Todo open source, sin telemetría externa. Cero dependencia de servicios cloud para el núcleo. bge-m3 es la pieza invisible: es lo que hace posible el RAG sin enviar tus documentos fuera.

10. Concepto: cuantización

Cuantizar es comprimir el modelo bajando la precisión de los pesos, de 16 bits a 4. La escala va de FP16 (más grande y preciso) a Q8, Q4, IQ4_XS (más pequeño y rápido).

La analogía que uso: es como un MP3 frente a un WAV. Técnicamente pierdes información, pero el oído apenas lo nota. El modelo ocupa la cuarta parte y va más rápido. IQ4_XS usa una matriz de importancia para dar más bits a los pesos que más importan; MXFP4 es la cuantización nativa de OpenAI en gpt-oss. Esto es lo que permite meter un 26B en una GPU de 16 GB. Sin cuantización, ese mismo modelo necesitaría hardware de unos 50.000 €.

Un apunte para no liarse: un Modelfile con num_ctx NO cuantiza, solo cambia el contexto. Cuantizar es procesar todos los pesos con llama.cpp. Son cosas distintas.

11. Dense vs Mixture of Experts (MoE)

Dos arquitecturas. Un modelo «dense» activa todos sus parámetros en cada token: más coherente en razonamiento largo, más pesado de computar, bueno para código, matemáticas y traducción. Un modelo «MoE» solo activa unos pocos «expertos» por token: velocidad de modelo pequeño con calidad de grande, ideal para chat, RAG y asistentes versátiles.

La pista está en el nombre: si veis «A4B», significa 4B activos (A de Active). gpt-oss, por ejemplo, tiene 21B totales pero solo 3,6B activos, y por eso vuela. De mi stack, gpt-oss y gemma4-26b son MoE; el resto, dense. En 2026 la línea se difumina cada vez más: los MoE modernos razonan casi como los dense. Dense para profundidad sostenida, MoE para velocidad versátil.

12. El torneo de modelos

Aquí viene lo divertido. Cogí tres modelos y los enfrenté con los mismos prompts, en mi hardware, usando el multi-model chat de Open WebUI. Nada de benchmarks sintéticos: cinco tareas reales de consultoría.

Los contendientes: glm-4.7-flash (de Zhipu AI, China, rápido), mistral-small3.2:24b (Mistral, Francia, 24B dense) y gemma4-26b (Google, MoE 25B/3.8B). Las cinco pruebas: redacción profesional para PYME, auditoría de ciberseguridad, script bash de monitorización, títulos SEO para Asturias y arquitectura FastAPI (esta última la hice aparte con qwen3.6-35b).

13. Cómo respondió cada modelo

El detalle, sacado de mis chats reales. En redacción, gemma4-26b tuvo el enfoque más estratégico y persuasivo (planteó el dilema «¿nube o soberanía?»); Mistral, correcto pero plano. En ciberseguridad, gemma4-26b fue el único que citó el Artículo 9 del RGPD (datos de categoría especial) junto con la DPIA y los niveles del ENS: el más preciso legalmente. En el script bash, otra vez gemma4 fue el único con gestión de estados, es decir, no reenvía la alerta hasta que el sistema se recupera, evitando una tormenta de correos. En SEO ganó glm-4.7-flash: keyword en primera posición e intención clara, mientras que gemma4 contó los caracteres pero se fue de tema. Y en FastAPI, qwen3.6-35b entregó una arquitectura async completa y código listo para producción, aunque tardó unos tres minutos (lento, 25B en IQ4).

14. Veredicto del torneo

Ganador general claro: gemma4-26b, que se llevó 3 de las 4 pruebas directas. El más preciso en lo legal, el más fino en lo técnico y el más persuasivo en redacción. glm-4.7-flash ganó en SEO, conciso y con la keyword bien colocada, aunque con menos profundidad técnica. Y mistral-small3.2 fue exhaustivo y estructurado, pero el más lento (dense de 24B, 21 t/s) y a veces verboso.

La moraleja conecta con todo lo anterior: arquitectura por encima de tamaño. Un MoE con solo 3,8B activos le gana a un dense de 24B, y encima va cuatro veces más rápido. La arquitectura y la cuantización pesan más que el tamaño bruto.

15. Hallazgos no obvios

Cinco cosas que aprendí y que no esperaba del todo: una, la arquitectura gana al tamaño. Dos, la cuantización inteligente (IQ4_XS, MXFP4) mete un 26B en 16 GB sin offload. Tres, el bus manda: USB4 penaliza el offload brutalmente, y no era la CPU. Cuatro, los modelos heredan los vicios de su origen: gpt-oss llega a alucinar el «sandbox» de ChatGPT. Y cinco, verifica siempre las IAs: ChatGPT me juró que DeepSeek no era MoE. Falso de toda falsedad.

16. La IA alucina. Verifica siempre.

Esta es, para mí, la diapositiva más importante de toda la charla, y os la cuento con dos casos reales que me pasaron preparándola.

Caso 1, DeepSeek. Le pregunté a ChatGPT si DeepSeek usaba MoE. Me juró tres veces que no, que era «solo eficiencia organizativa». El paper oficial (arXiv 2412.19437) dice lo contrario: DeepSeek-V3 es MoE, 671B totales con 37B activos, con arquitectura DeepSeekMoE propia. Categóricamente falso, verificado con la fuente.

Caso 2, análisis de logs. Un modelo local me analizó los logs del sistema y me señaló un dominio sospechoso, gmail.ya.ru (Yandex), con «intentos de autenticación fallidos». Fui a los logs reales. No existía. Cogió un fallo de DNS real y trivial de Signal y le montó un disfraz alarmante encima. Esta es la alucinación peligrosa: no la que dice tonterías evidentes, sino la que parte de un hecho real y lo adorna con detalles falsos verosímiles. Si eso acaba en un informe a un cliente, quedas retratado, así de claro.

La IA propone, el profesional confirma. El criterio no se delega jamás.

17. ¿Qué es un RAG? (desde cero)

Para quien no lo tenga claro, empezamos por el principio. Un RAG es darle a la IA TUS documentos para que responda con ellos, en vez de solo con lo que aprendió durante su entrenamiento.

La analogía: es como dejar que el modelo consulte tus apuntes durante el examen, en lugar de contestar solo de memoria. Sin RAG, la IA «recuerda»; con RAG, además «consulta tu archivo». Las siglas son Retrieval-Augmented Generation, generación aumentada por recuperación. Para una PYME esto significa poder preguntar a tus contratos, manuales, historiales o normativa interna en lenguaje natural, y que la respuesta cite tus propios documentos. Sin que salgan de tu servidor.

18. Los mandos del RAG

Los parámetros que de verdad importan, con mi configuración real al lado. Chunking: trocear el documento en fragmentos, porque la IA no lee un PDF de 200 páginas de golpe. Chunk Size (1000 caracteres): el tamaño de cada trozo, grande da más contexto, pequeño da más precisión. Chunk Overlap (100): cuánto se solapan los trozos para no cortar una idea por la mitad. Embedding (all-MiniLM): convierte cada trozo en números que capturan su significado. Top K (3): cuántos trozos relevantes recupera por pregunta. Búsqueda híbrida (OFF): combinar búsqueda por significado y por palabras clave.

Ajustar estos mandos según el tipo de documento es justo lo que separa un RAG de juguete de uno útil.

19. RAG local: consultar tus documentos sin enviarlos a ningún sitio

El flujo completo: Documento, Chunking, Embeddings (local), Base vectorial, Recuperación, Respuesta.

Para que sea VERDADERAMENTE local hacen falta tres cosas: chat local con Ollama más embeddings locales (no una API externa), base vectorial local con los documentos en volumen persistente, y una prueba de fuego que me encanta: cortas la red saliente del contenedor y compruebas que el RAG sigue funcionando. Si sigue, es soberano de verdad. Los casos PYME son claros: despachos legales, clínicas (RGPD art. 9), consultoras.

20. El embedding por defecto no es el mejor

Un punto técnico fino que da credibilidad. Open WebUI trae de fábrica all-MiniLM-L6-v2: 384 dimensiones, solo 512 tokens de contexto, pensado para inglés. Rápido y ligero, buen arranque, pero se queda corto.

Frente a él, bge-m3: 1024 dimensiones (más matiz semántico), 8192 tokens (se traga documentos enteros), más de 100 idiomas con español nativo, y búsqueda híbrida. Los dos corren en local, así que el cambio no afecta a la soberanía, solo a la calidad. Para contratos o informes largos en español, bge-m3 gana de calle. Un detalle importante: cambiar de modelo de embeddings te obliga a re-indexar todo lo que ya tuvieras, porque los vectores viejos y los nuevos no son compatibles.

21. ¿Es esto un RAG profesional de verdad?

La pregunta que sabía que me iban a hacer. Y la respuesta es sí: es el RAG de los libros, bien hecho. El pipeline (trocear, vectorizar, base vectorial, recuperar) es el RAG canónico. No es un truco ni un juguete.

La diferencia con un RAG a medida (LangChain, LlamaIndex) no está en el QUÉ, sino en el control. Uno a medida te da control fino de cada pieza con código y es más potente para corpus enormes, pero requiere desarrollo y mantenimiento. Open WebUI te da el mismo pipeline empaquetado, con los parámetros clave en un panel, suficiente y profesional para una PYME. Es el «WordPress del RAGsoberanIA@localhost: IA privada en local para PYMEs, del hierro al modelo en producción»: profesional y suficiente para el 95%, aunque Amazon no lo use. Y con una ventaja que un RAG cloud no tiene: es soberano. Un RAG a medida con embeddings de OpenAI sería más potente, pero mandaría tus documentos fuera. Para datos sensibles, un RAG local suficiente vale más que un RAG cloud perfecto que te compromete los datos.

22. Open WebUI no es una interfaz, es una plataforma de orquestación

Mucha gente cree que Open WebUI es «un ChatGPT casero». Es bastante más: multi-model chat, workspaces con modelos propios, Knowledge Bases (RAG), pipelines y functions, tool calling, multi-usuario con control de acceso por roles (RBAC), búsqueda web con SearXNG, code interpreter, API REST compatible con OpenAI, multimodal (visión y voz), backend agnóstico y sin telemetría.

Lo que el cloud te cobra a 50 €/usuario/mes (Copilot Studio, ChatGPT Enterprise), aquí lo tienes gratis en tu Z440.

23. Niveles de soberanía (no es blanco o negro)

Porque la honestidad es lo primero. Hay una escala. Nivel 1, local total: Ollama en tu hardware, los datos nunca salen. Nivel 2, europeo real: Mistral La Plateforme, modelo y empresa europeos. Nivel 3, intermediario europeo: Mammouth, Requesty, OpenRouter EU, contratos sobre modelos USA. Nivel 4, API directa con DPA: Anthropic u OpenAI Enterprise, infra en EEUU, aplica el Cloud Act. Nivel 5, consumer sin DPA: plan Plus o Pro, sin protección legal seria.

Incluso los intermediarios europeos procesan los modelos USA en infraestructura americana, con contratos protectores, pero eso no es soberanía total. Y OpenRouter es un agregador: tus datos pasan por ellos Y por el proveedor final, doble exposición. La pregunta no es cloud sí o no, es qué nivel necesita cada dato. Eso es lo que diferencia al consultor del usuario casual.

24. Seguridad: el bloque olvidado

Aquí está mi valor como consultor de ciberseguridad, y el motivo de que esta charla no la dé cualquiera. El problema no es Ollama, es la configuración por defecto.

Por defecto (inseguro): WEBUI_SECRET_KEY vacía, ENABLE_SIGNUP=true (registro abierto), Ollama escuchando en 0.0.0.0, UFW desactivado, sin HTTPS y con la imagen :latest. El hardening mínimo: SECRET_KEY generada con openssl rand -hex 32, ENABLE_SIGNUP=false con rol pending, OLLAMA_HOST a 127.0.0.1, UFW por subred y versión fija de la imagen. Y para datos sensibles, DPIA del artículo 35 del RGPD e ISO 27799. Aquí está la diferencia entre «instalo Ollama» y «pongo IA local en producción para una PYME».

25. Demo en vivo: agente de coding soberano

Primera demo. OpenCode con gpt-oss:20b, 100% local, auditando el docker-compose de mi propio Open WebUI. Detecta fallos, explica los riesgos y propone el hardening. Coste: 0,00 €, sin enviar nada fuera.

Es como Claude Code, pero local, gratis y privado. El agente lee, razona y edita en tiempo real. Detrás hay un protocolo obligatorio que aprendí a las malas: verificar la GPU con lspci, nvidia-smi y ollama ps antes de empezar, el modelo precargado, y un plan B en vídeo por si el eGPU decide caerse en el peor momento (que ya sabéis que con las demos siempre me mojo, pero uno aprende de las «cosas del directo» ;).

26. Red Team vs Blue Team en local

Dos modelos especializados de ciberseguridad, el mismo código, dos perspectivas opuestas. Foundation-Sec-8B de Cisco, defensivo: análisis de vulnerabilidades, CVE a CWE, scoring CVSS, MITRE ATT&CK, cómo detectar y mitigar. WhiteRabbitNeo-13B, ofensivo: generación de PoC y exploits, payloads (SSTI, SQLi, RCE), simulación de adversario, cómo explotar (en laboratorio autorizado, que conste).

Ataque y defensa, en tu hardware, sin que ningún prompt salga fuera. Esto conecta con ese rol doble que me gusta tanto y que ya ejercí en su día con «GLAMP Exposed»: el mismo que ataca sabe defender.

27. Resultado real: 3 modelos, misma app

Y aquí está el hallazgo estrella, porque los resultados fueron contra la intuición. Los tres analizaron el mismo código vulnerable.

Foundation-Sec (blue): bien, 8 vulnerabilidades con su CWE correcto y mitigación con código; mal, clasificó la SSTI como XSS y mezcló path traversal con SSRF. WhiteRabbitNeo (red, el especialista uncensored): bien, payloads concretos y mentalidad de atacante; mal, se inventó vulnerabilidades que no existían (CORS, CSRF, cookies) y cambió de respuesta en cada ejecución. Y gpt-oss:20b (generalista): bien, las 6 vulnerabilidades reales, payloads correctos y cero inventos; mal, solo el desliz de la SSTI como XSS.

La sorpresa: el generalista con «barandillas» (gpt-oss) dio el mejor análisis ofensivo. Especializado no es sinónimo de mejor. Ni os fieis de la etiqueta del modelo, ni de una sola ejecución. Hay que probar y verificar, siempre.

28. Misma pregunta, dos respuestas

Para rematar la lección anterior. Le hice la MISMA pregunta DOS veces al MISMO modelo (WhiteRabbitNeo). En la primera ejecución detectó SQLi, command injection, path traversal y SSRF, e inventó un «CORS Misconfigured». En la segunda detectó menos vulnerabilidades reales, dio un payload SQL peor, y se inventó cosas distintas: deserialización, CSRF, cookies, login SSL.

Es la temperatura: los LLM no son deterministas. Una sola ejecución NUNCA es la verdad. Si entregas la salida de una IA sin verificar, puedes estar entregando alucinaciones a un cliente. La IA propone, tú confirmas.

29. Stack recomendado para PYME

Mi equipo de especialistas, todo cabiendo sin offload en 16 GB. Para el día a día general, gemma4-26b (MoE). Para ciberseguridad técnica, gpt-oss:20b. Para SEO y marketing en español, mistral-small3.2:24b. Para código y refactor, qwen2.5-coder:14b. Para razonamiento visible, deepseek-r1:8b. Para contexto largo (128k), mistral-nemo:12b. Para defensa cyber, Foundation-Sec-8B. Y para los embeddings del RAG, bge-m3.

No hay un modelo para todo, hay un modelo para cada tarea. Como no contratas a un cirujano para poner una tirita ;).

30. Cierre

Montar IA local ya no es solo una opción técnica. Es una opción de soberanía. Y ahí está la oportunidad de consultoría real: no en instalar Ollama, que eso lo hace cualquiera, sino en saber qué pasa el día que el cliente quiere subir el primer expediente médico.

Y hasta aquí el repaso. Como siempre, quiero dar las gracias a Cota por la organización del Hack & Beers Gijón (enorme abrazo desde aquí, que sabes que se te quiere ;) y a toda la gente que se pasó por El Café de Macondo. Y por supuesto a Sheila ♡, por el apoyo constante de siempre, también en este proyecto.

Buena parte de lo que aprendí preparando esta charla (el eGPU peleón por USB4, los NaN del RAG bajo carga sostenida, el torneo de modelos) daría para varias entradas más. Si os interesa que profundice en alguna parte concreta (el montaje del RAG con bge-m3, el hardening de Open WebUI o el protocolo para domar un eGPU inestable), decídmelo en los comentarios y le dedico un post.

La IA local no es magia ni sustituye a todo, que ya lo he dicho. Pero para una PYME que maneja datos sensibles, la diferencia entre un plan consumer y tu propio servidor no es técnica, es de soberanía. Y esa decisión, hoy, ya se puede tomar. Para lo que necesitéis, ya sabéis dónde encontrarme ;).

Me encantó por cierto ver las charlas de los dos compañeros con los que compartí cartel ¡cómo mola aprender de gente tan pro!

Las diapositivas –> soberanIA_localhost

Si tienes una PYME o necesitas servicios de este tipo, no dudes en contactar conmigo y lo hablamos.

Dedicado a la memoria de Fernando Campo 

No puedo terminar este post sin acordarme de un grande que ya no está con nosotros, Fernando del Campo, de «Axón Consultores» y Grupo Ética. La vida se lo llevó demasiado pronto, han pasado como 3 semanas pero me acuerdo mucho de él. Los temas de Privacidad eran lo suyo y este tema le encantaba. Un consejo, cuidad a vuestros amigos y la gente que merece la pena porque puede que mañana no estén (sé que lo sabéis pero nunca está de más recordarlo…) Gracias Fernando, por todo.

Con la Transformación Digital en Asturias: IA, Ciberseguridad Técnica y Estrategia

En un entorno empresarial donde la tecnología ha dejado de ser un soporte para convertirse en el núcleo del negocio, la capacitación de los equipos directivos es crítica. Recientemente, he tenido el privilegio de impartir el Módulo 3: Habilitando Tecnológicamente la Transformación dentro del programa oficial Generación Digital Pymes (ahí está el resumen del curso)

Esta iniciativa, impulsada por la Escuela de Organización Industrial (EOI), la Cámara de Comercio de Oviedo y agorAstur Formación, ha sido el escenario perfecto para aterrizar conceptos complejos a soluciones de negocio reales.

Mi intervención se ha alejado del contenido teórico genérico para trasladar mi experiencia real en las «trincheras» de la red. A continuación, comparto los pilares fundamentales que hemos trabajado.

1. Ciberseguridad: Mentalidad de Hacking Ético y Defensa Activa

Basándome en mi trayectoria como co-fundador y responsable de seguridad en APACHEctl, el mensaje ha sido claro: la seguridad no es un producto que se compra, es un proceso que se gestiona. Hemos profundizado en:

• Higiene de Seguridad Mínima: La implementación obligatoria de MFA (Autenticación Multifactor) y políticas de «menor privilegio» por defecto.
• Gestión de Activos: El uso de gestores de contraseñas profesionales como Bitwarden o KeePassXC y el cifrado de dispositivos (BitLocker/LUKS) para mitigar riesgos físicos.
• Respuesta a Incidentes: No basta con tener copias; hemos establecido la regla de backups 3-2-1 con restauraciones mensuales verificadas, porque «el backup solo existe si se restaura».

2. Infraestructura, WPO y SEO Técnico

Como administrador de servidores GNU/Linux, he puesto el foco en la arquitectura del servidor como motor de negocio. La optimización del rendimiento web (WPO) no es solo una cuestión de velocidad, es la base del SEO Técnico. Un servidor seguro y optimizado es indispensable para ganar autoridad ante Google y confianza ante el cliente.

3. Inteligencia Artificial, Automatización y Productividad

La productividad en 2025 pasa por delegar tareas repetitivas en sistemas inteligentes. Hemos explorado la convergencia entre IA y automatización:

• IA Generativa con Criterio: Analizamos técnicamente modelos como ChatGPT (versatilidad), Claude (análisis de documentos extensos) y Gemini (ecosistema Google), usando prompts avanzados para estrategia de contenidos.
• Automatización (No-Code/Low-Code): Introduje el potencial de herramientas como Zapier, Make y n8n para conectar CRM y ERP, permitiendo que los datos fluyan sin intervención manual.
• GTD + Notion: Configuramos un sistema operativo de equipo en Notion aplicando la metodología Getting Things Done de David Allen para transformar el caos en tareas ejecutables.

4. Tecnologías Emergentes: IoT y Blockchain

Bajamos a tierra tecnologías que a menudo parecen lejanas para la PYME:

• IoT orientado a KPIs: Uso de sensores para medir procesos industriales en tiempo real y reducir mermas.
• Blockchain: Aplicación de registros inmutables para garantizar la trazabilidad y la certificación documental.

5. Hoja de Ruta: El Plan 30-60-90

Para asegurar la ejecución, cada directivo trabaja en un plan de implementación inmediata:

• Días 0-30: Auditoría de seguridad, activación de 2FA y segmentación de redes Wi-Fi.
• Días 31-60: Despliegue de gestores de contraseñas y políticas de parches.
• Días 61-90: Integración de automatizaciones y revisión de métricas de rendimiento.

---

Un equipo docente de primer nivel

Es un honor compartir este programa con un claustro de expertos que cubren todas las aristas de la digitalización:

• Alfonso Ruiz de Eguino – Estrategia, Modelos de Negocio y Lean Startup.
• Ana Fernández Iglesias – Sostenibilidad, Economía Circular e Innovación Industrial.
• Anita Álvarez Cufari – Marketing Digital, Publicidad y Creatividad Estratégica.
• Damián Micenmacher – Transformación Cultural, Liderazgo Ágil y Coaching.
• David Hernández (Dabo) – Ciberseguridad, Cloud Computing e Inteligencia Artificial.
• Mónica Granda Velasco – Dirección Financiera, ERPs y Business Intelligence.
• Nerea Sánchez Sánchez – Soluciones Digitales y Aplicaciones Móviles.
• Roberto Pérez Marijuán – Neuromarketing, Comunicación y Ventas.
• Rubén Prida – Consultoría Tecnológica y CRM.
• Vanina Posada Casares – Transformación Digital e Innovación en Turismo.

Comentar que vamos por la segunda edición y que hay una tercera confirmada, muchas gracias a los organizadores por confiar en mi experiencia para llevar adelante esta formación.

Mi gran amigo Ángel «Aka Jábali» ;) me dedicó una entrada en su blog que NO merezco, pero que SÍ agradezco enormemente.

Cuando él me planteó entrar en el equipazo de Hack By Security (tengo que buscar otra foto, lo sé ;D) a impartir formación y más en algo que tanto me gusta como GNU/Linux, no dudé en decir «sí», porque para mi, hablando de formación (algo que me tomo muy en serio) es importante saber que la gente que está detrás se lo toma en serio y no juega con las ilusiones y el dinero del alumnado, así de claro.

El temario que impartí en mi bloque de horas fue el siguiente:

Introducción
Amenazas y seguridad web
Servidores Debian GNU/Linux y seguridad
Monitorización de servidores y servicios
Comparativa de paneles de administración web
Servidores web: Apache vs Nginx
Optimización y seguridad en servidores web
Optimización y seguridad de bases de MariaDB
Seguridad y protección contra ataques DoS / DDoS
Firewall y protección de red / portscans
Uso de un IPS / IDS & búsqueda de malware
Conclusiones y buenas prácticas

Para ello, preparé a los alumnos una VM en VirtualBox con una Debian 12 y un entorno de escritorio mínimo a modo de laboratorio de pruebas y en mi caso, para darle un toque más real, contraté un servidor VPS e hice una instalación totalmente desde cero, explicando problemas comunes, otros más complejos (algunos «bastante complejos»;) y sobre todo, aportando soluciones en directo a esos problemas y configuraciones inseguras que íbamos detectando.

Fue un rol doble por mi parte, ejerciendo de Red y Blue Team, con ataques desde fuera que eran analizados y bloqueados desde dentro del servidor. Partiendo de una mínima configuración, acabé instalando un entorno plenamente funcional y altamente optimizado basado en:

Apache 2.4x en mod-event

MariaDB 10x

PHP-FPM 8x

Memcached

Mostré a los alumnos cómo manejar picos de tráfico legítimo alto, también cómo actuar en caso de una Denegación de servicio, montar un firewall complejo desde cero con la premisa de que al acabar pudieran replicarlo (las clases quedan grabadas), bloqueando ataques de fuerza bruta, portscans, fingerprinting, DoS, etc.

Por mi parte, acabé la formación con la sensación de haberlo dado todo como siempre intento (a pesar de los riesgos del directo, pero eso creo que aporta valor porque así la gente puede ver cómo solucionas sobre la marcha problemas que pueden encontrarse ellos) y ya estoy esperando a la siguiente entrega. Muchas gracias a Ángel y al Staff de Hack By Security y también a los alumnos que asistieron a mi clase (para lo que necesitéis,sólo tenéis que contactar).

Resumen de mi charla sobre Ciberseguridad en Gijón.

Pocas cosas me gustan más que ir a centros de formación (y si es formación profesional, más si cabe) e intentar aportar algo de luz o ayuda en temas de mi día a día con el Hacking y los servidores en APACHEctl y en mis temas como consultor.

En este caso tocaba hablar de Ciber(IN)seguridad en el IES1 de Gijón y cuando sus responsables me propusieron ir, no dudé en aceptar al momento.

Tengo que dar las gracias tanto a la organización como a los asistentes porque me trataron genial y me divertí mucho -:). Si hay que repetir, se repetirá (hubo gente que se quedó sin poder entrar me comentaron).

¿De qué temas hablé? Obviamente de IA y sus sesgos, de cómo hackear a ChatGPT para saltarte ciertos filtros y restricciones en cuanto al contenido (sí, al final nos creó un arma biológica y…poca broma:), de estereotipos, Hackers y Hacktivistas, de brechas de seguridad, desarrollo seguros de Software, OWASP, criptografía, OPSEC, gestión del riesgo, etc.

Seguramente lo que más impacto causó en la audiencia fue una demo de suplantación de identidad vía una llamada de móvil entre dos asistentes (llamando yo con el número de ellos previo permiso explícito).

Voy a compartir alguna de las diapositivas de mi presentación. Aclarar que aunque mi presentación se impartió con Software Libre y mis Debian, los consejos de Ciberseguridad fueron en este caso destinados a Windows.

Para acabar, si estás leyendo esto y quieres que colabore con tu centro público de educación en algún tema de divulgación tipo este, lo haré de forma desinteresada porque al final, la seguridad, es una cuestión que nos afecta a todos.

Galería con parte de la presentación (hay como el doble de diapos pero falta contexto).