Ejecuta un LLM en tu propia máquina.
Un modelo que nunca ve la red es un modelo que nunca filtra tus notas. Aquí tienes cómo montar uno con Ollama y qué dejar fuera por completo.
Hay un momento concreto que empuja a la gente de seguridad hacia los modelos locales: quieres pegar un fragmento de log, una configuración o la cronología de un incidente en un modelo para que te ayude a pensar, y te das cuenta de que ese fragmento no debería salir de tu red bajo ningún concepto. Un LLM local resuelve eso. Se ejecuta en tu propio hardware, funciona sin conexión y nada de lo que escribes se envía a nadie. Para redactar, tomar notas y documentar material sensible, esa propiedad por sí sola ya justifica la configuración.
Por qué en local, concretamente
- Privacidad por diseño. Los datos nunca salen de la máquina. No hay ningún proveedor de API en el que confiar, ninguna política de retención que leer, ninguna transferencia transfronteriza que justificar ante un equipo de cumplimiento.
- Sin conexión y reproducible. El modelo funciona en un avión o en un laboratorio aislado, y la misma versión del modelo te da el mismo comportamiento mañana: sin actualizaciones silenciosas del lado del servidor.
- Sin coste por token. Una vez que está en marcha, puedes lanzarle todo el texto que tu hardware permita sin vigilar un contador.
La contrapartida es honesta: un modelo que puedes ejecutar en un portátil es más pequeño y menos capaz que los mayores modelos alojados. Para resumir notas, reformatear, redactar documentación y usarlo como pato de goma para pensar un problema, esa diferencia rara vez importa. Para razonamiento de frontera, sí importa.
Instalar Ollama
Ollama es la forma con menos fricción de ejecutar modelos de pesos abiertos en local en macOS, Linux y Windows. Después de instalarlo desde el sitio oficial, descargar y ejecutar un modelo son dos comandos:
# descarga un modelo de pesos abiertos pequeño y capaz
ollama pull llama3.2
# empieza a chatear con él, totalmente sin conexión
ollama run llama3.2Esa es toda la configuración. El primer comando descarga los pesos una sola vez; a partir de ahí todo se ejecuta en local. Si tienes GPU, Ollama la usa automáticamente; en máquinas solo con CPU, un modelo más pequeño (de 1 a 3 mil millones de parámetros) mantiene las respuestas ágiles. Puedes listar lo que has descargado con ollama list y eliminar un modelo con ollama rm.
Prompts que se ganan su sitio
Un modelo local es una potente ayuda para escribir y pensar en el trabajo de seguridad. Unos cuantos patrones que ayudan de forma constante:
- Resumir la cronología de un incidente. Pega notas en bruto con marcas de tiempo y pide un resumen cronológico limpio con una sección de "preguntas abiertas". Ideal para los traspasos.
- Explicar una configuración o una línea de log. "Explica qué hace esta regla de iptables, línea por línea, y señala cualquier cosa que parezca demasiado permisiva." Sigues verificando, pero acelera la lectura.
- Redactar documentación. Convierte una lista con viñetas de lo que hiciste en un primer borrador de runbook, y luego edítalo. El modelo se encarga del texto repetitivo; tú aportas el criterio.
- Generar material de estudio. Dale un tema y pídele preguntas de práctica: combina bien con nuestros prompts para autoestudio.
Lo que nunca entra en ningún modelo, local o no
Ejecutarlo en local elimina el riesgo de exposición a la red, pero no suspende el buen criterio. Mantén esto fuera del prompt pase lo que pase:
- Credenciales y secretos activos. Claves de API, contraseñas, claves privadas. Un modelo local no las va a exfiltrar, pero acaban en el historial de tu shell, en el scrollback y en cualquier transcripción guardada. Censúralos primero.
- Datos personales reales que no necesitas procesar. Minimizar lo que manejas es un hábito que merece la pena mantener incluso cuando la herramienta está sin conexión.
- Cualquier cosa que luego pegarías en un shell o en una consulta sin leerla. Trata la salida del modelo como el borrador de un becario rápido y confiado: útil, a veces equivocado, nunca de fiar a ciegas. Este es el riesgo de "gestión insegura de la salida" de la lista OWASP para LLM, aplicado a tu propio flujo de trabajo.
Elegir el tamaño de modelo para tu hardware
La frustración inicial más habitual es descargar un modelo demasiado grande para la máquina y verlo arrastrarse. Una guía aproximada para ajustar el modelo al hardware:
| Clase de modelo | Ajuste de hardware |
|---|---|
| Modelos de 1 a 3B de parámetros | Funcionan cómodamente en un portátil moderno sin GPU dedicada. Son ideales para resúmenes, reformateo y explicaciones: las tareas de pan y mantequilla de las notas de seguridad. |
| Modelos de 7 a 8B | Requieren o bien una GPU o bien una máquina con bastante RAM y paciencia. Razonan notablemente mejor y siguen siendo perfectamente ejecutables en una estación de trabajo decente. |
Compilaciones cuantizadas (etiquetas como q4) | Sacrifican algo de calidad a cambio de una gran reducción del uso de memoria, que a menudo es la diferencia entre un modelo que cabe y uno que tira de disco. |
Empieza pequeño, confirma que el flujo de trabajo es útil y luego sube de tamaño solo si la calidad realmente se queda corta. Un modelo de 3B rápido que de verdad usas gana a uno de 8B lento que evitas. Puedes tener varios descargados a la vez y cambiar según la tarea: uno pequeño para reformatear rápido, uno mayor cuando necesitas que razone.
Un LLM local no va a sustituir a tu mejor modelo alojado para el razonamiento difícil. Pero como asistente privado, sin conexión y de coste cero para el día a día de la escritura de seguridad (resúmenes, explicaciones, borradores, estudio), es una de las herramientas de mayor valor que puedes montar en diez minutos, y cada byte se queda en tu máquina.