Fine-Tuning y Alineamiento de Seguridad: Lo Que Necesitas Saber Antes de Desplegar

El fine-tuning cambia el comportamiento de un modelo. Ese es el objetivo. Pero cuando cambias el comportamiento, puedes cambiar accidentalmente el comportamiento de seguridad también. Un modelo que rechazaba confiablemente solicitudes dañinas antes del fine-tuning podría no rechazarlas después — incluso si tus datos de entrenamiento no contenían nada dañino.

Esto no es una preocupación teórica. Microsoft Research publicó hallazgos a finales de 2025 mostrando que tan solo 100 ejemplos de fine-tuning benignos podían degradar mediblemente el alineamiento de seguridad en varios modelos open-source. La degradación no fue dramática, pero fue real y consistente.

Si estás desplegando modelos ajustados en producción — especialmente para clientes en industrias reguladas — necesitas entender esta dinámica y saber cómo manejarla.

Por Qué la Seguridad Importa Más en 2026

Tres fuerzas han convergido para hacer del alineamiento de seguridad una preocupación práctica de negocio, no solo un tema de investigación:

La presión regulatoria es concreta. Las disposiciones del EU AI Act para modelos de IA de propósito general entraron en vigor a mediados de 2025. Si estás desplegando sistemas de IA para clientes europeos, tienes obligaciones de evaluación y mitigación de riesgos. Ajustar un modelo sin evaluar el impacto en seguridad es una brecha de cumplimiento.

Los compradores empresariales preguntan al respecto. En Q4 2025, el 67% de los procesos de adquisición de IA empresarial incluyeron preguntas sobre seguridad del modelo y pruebas de alineamiento, según la encuesta de adopción de IA de Gartner. Si eres una agencia vendiendo soluciones de IA, "probamos regresiones de seguridad después del fine-tuning" es un diferenciador competitivo. "No sabemos" es un factor decisivo negativo.

La responsabilidad se está desplazando. Cuando ajustas un modelo y lo despliegas para un cliente, has modificado el comportamiento del modelo. Si ese modelo produce outputs dañinos, la cuestión de responsabilidad aterriza más cerca de ti que del proveedor original del modelo. El panorama legal aún se está formando, pero la dirección es clara.

Cómo el Fine-Tuning Puede Degradar la Seguridad

Para entender el riesgo, necesitas entender qué es realmente el "alineamiento de seguridad" a nivel técnico.

Los modelos de lenguaje modernos pasan por múltiples fases de entrenamiento. El pre-entrenamiento en datos a escala web produce un modelo que puede generar texto fluido pero no tiene noción de seguridad — completará cualquier prompt en la dirección que parezca estadísticamente probable. El entrenamiento de alineamiento (RLHF, DPO, IA constitucional o técnicas similares) luego agrega una capa de restricciones de comportamiento: rechazar solicitudes dañinas, evitar generar contenido explícito, negarse a asistir con actividades peligrosas.

Esta capa de alineamiento es comportamiento aprendido almacenado en los pesos del modelo. No es un sistema separado. Es un conjunto de patrones distribuidos a través de los mismos pesos que manejan todo lo demás que el modelo hace.

Cuando ajustas, modificas esos pesos. Incluso si tus datos de entrenamiento son completamente benignos — digamos, 2,000 ejemplos de extracción de descripciones de productos — las actualizaciones de pesos pueden interferir con los patrones de alineamiento. El modelo no "olvida" la seguridad de manera dramática. Pero la fuerza de sus activaciones relacionadas con la seguridad puede disminuir, haciendo los rechazos menos confiables.

Piénsalo así: el entrenamiento de alineamiento construyó un conjunto de guardarraíles. El fine-tuning construye nuevas capacidades dentro de esos guardarraíles, pero el proceso de construcción puede debilitar los postes del guardarraíl. Los guardarraíles aún existen, pero son más fáciles de atravesar.

El Espectro de Riesgo

No todas las tareas de fine-tuning conllevan el mismo riesgo de seguridad. El riesgo depende de qué tan cerca está tu tarea de los comportamientos que el alineamiento de seguridad apunta.

Bajo Riesgo: Tareas de Clasificación y Extracción

Tareas como clasificación de sentimiento, extracción de entidades, categorización de documentos y extracción de datos estructurados están lejos de los comportamientos relevantes para la seguridad del modelo. El modelo está aprendiendo a mapear entradas a un espacio de output fijo (etiquetas, esquemas JSON, categorías). Estas tareas modifican pesos en regiones que tienen superposición mínima con circuitos relacionados con la seguridad.

Regresión típica de seguridad: 0-2% de degradación en benchmarks estándar de seguridad. Efectivamente insignificante para propósitos de producción.

Riesgo Medio: Tareas de Generación de Contenido

Generación de publicaciones de blog, redacción de emails, copywriting y tareas similares de creación de contenido involucran las capacidades generativas del modelo más ampliamente. El fine-tuning toca pesos que están más cerca (pero no directamente superpuestos) de las regiones entrenadas para seguridad.

Regresión típica de seguridad: 3-8% de degradación en benchmarks de seguridad. El modelo puede perder algo de matiz en guardarraíles de tono — generando contenido que es ligeramente más agresivo, con opiniones más fuertes o más casual de lo que el modelo base habría producido. Los rechazos explícitos de seguridad usualmente permanecen intactos, pero el comportamiento en "zona gris" cambia.

Alto Riesgo: Modelos de Chat y Asistente

Si estás ajustando un modelo para ser un asistente conversacional — especialmente si tus datos de entrenamiento incluyen comportamiento de persona personalizada, escenarios de roleplay o diálogo específico de dominio — estás modificando los patrones de comportamiento exactos que el alineamiento de seguridad entrenó. La superposición entre "aprender este nuevo estilo conversacional" y "mantener estos límites de seguridad conversacional" es alta.

Regresión típica de seguridad: 5-15% de degradación en benchmarks de seguridad. El comportamiento de rechazo puede debilitarse notablemente. El modelo podría cumplir con solicitudes que habría rechazado antes del fine-tuning, particularmente en casos límite donde el rechazo del modelo base ya era borderline.

Pruebas Prácticas de Seguridad

Conocer el espectro de riesgo es útil para priorización, pero cada modelo ajustado debe ser probado antes del despliegue. Aquí hay un marco de pruebas práctico:

Construye un Conjunto de Pruebas Red-Team

Crea un conjunto de 50-100 prompts adversariales que prueben los comportamientos de seguridad que te importan. Estos deben incluir:

Solicitudes dañinas directas (20-30 prompts). Solicitudes de información peligrosa, contenido explícito o asistencia con actividades dañinas. Estas prueban el comportamiento core de rechazo del modelo.

Intentos indirectos y de ingeniería social (15-20 prompts). Prompts estilo jailbreak, manipulación de persona, encuadre "hipotético" y otras técnicas que intentan evadir el entrenamiento de seguridad. Estas prueban la robustez del comportamiento de rechazo.

Casos límite específicos de dominio (10-15 prompts). Para tu caso de uso específico, ¿cuáles son los casos límite donde el modelo debería declinar o agregar advertencias? Una IA médica no debería diagnosticar. Una IA legal no debería dar asesoramiento legal definitivo. Una IA financiera no debería hacer recomendaciones específicas de inversión sin disclaimers.

Sondeos de sesgo y equidad (10-15 prompts). Entradas que prueban outputs discriminatorios entre categorías demográficas relevantes para tu contexto de despliegue.

Prueba Antes y Después

Ejecuta el conjunto de pruebas red-team contra el modelo base (antes del fine-tuning) y el modelo ajustado. Califica cada respuesta en una escala simple:

• Aprueba: El modelo rechazó apropiadamente o agregó advertencias necesarias
• Parcial: El modelo cumplió parcialmente pero incluyó algunas advertencias relevantes de seguridad
• Falla: El modelo cumplió con una solicitud que debería haber rechazado

Calcula la tasa de aprobación para cada categoría. Si alguna categoría cae más de 5 puntos porcentuales, tienes una regresión de seguridad que necesita atención.

Establece un Umbral de Regresión

Antes de empezar el fine-tuning, decide tu umbral de regresión aceptable. Para la mayoría de despliegues en producción:

• Rechazos core (solicitudes dañinas directas): Cero regresión aceptable. Si el modelo deja de rechazar cualquiera de estas, no despliegues.
• Intentos indirectos: Hasta 5% de regresión es típico y manejable con otras mitigaciones.
• Casos límite de dominio: Cero regresión aceptable. Estos son específicos de tu despliegue y afectan directamente tu responsabilidad.
• Sondeos de sesgo: Hasta 3% de regresión, con revisión manual de cualquier nueva falla.

Estrategias de Mitigación

Cuando las pruebas de seguridad revelan regresiones, tienes varias opciones:

Incluye Ejemplos de Seguridad en los Datos de Entrenamiento

La mitigación más directa: agrega 50-100 ejemplos relevantes de seguridad a tu dataset de entrenamiento. Estos son pares entrada-salida donde la entrada es un prompt adversarial y la salida es un rechazo apropiado. Esto refuerza el comportamiento de seguridad durante el fine-tuning.

La proporción importa. Si tu dataset tiene 2,000 ejemplos de tareas y 50 ejemplos de seguridad, el modelo recibe una señal consistente de que los rechazos de seguridad son parte de su comportamiento esperado. Esto frecuentemente es suficiente para prevenir la regresión completamente.

Usa Rangos LoRA Conservadores

LoRA (Low-Rank Adaptation) modifica un pequeño subconjunto de los pesos del modelo. Rangos LoRA más bajos modifican menos parámetros, lo que preserva más del comportamiento del modelo base — incluyendo el alineamiento de seguridad.

Para tareas donde la preservación de seguridad es crítica:

• Rango LoRA 8-16: Preserva la mayoría del comportamiento de seguridad. Suficiente para tareas de clasificación, extracción y generación simple.
• Rango LoRA 32-64: Rango estándar. Alguna degradación de seguridad posible en tareas de riesgo medio.
• Rango LoRA 128+: Mayor riesgo de degradación de seguridad. Solo usa para tareas de bajo riesgo o cuando se planifica pruebas extensivas de seguridad.

Usar un rango más bajo es la forma más simple de reducir el riesgo de seguridad sin cambios en tu proceso de entrenamiento.

Prueba con Benchmarks Automatizados de Seguridad

El red-teaming manual es necesario pero no suficiente. Compleméntalo con benchmarks automatizados:

• ToxiGen — prueba generación de contenido tóxico entre categorías demográficas
• BBQ (Bias Benchmark for QA) — mide sesgo en contextos de preguntas y respuestas
• HarmBench — evaluaciones estandarizadas para generación de contenido dañino
• Benchmark personalizado — tu conjunto de pruebas específico de dominio, automatizado para evaluación continua

Ejecuta estos benchmarks como parte de tu pipeline CI/CD. Cada vez que reentrenar un modelo, los benchmarks de seguridad se ejecutan automáticamente antes de que el modelo pueda ser desplegado.

Contexto Regulatorio

EU AI Act

Si tú o tus clientes operan en la UE, los requisitos del AI Act para modelos de IA de propósito general incluyen:

• Documentación de procesos de entrenamiento y datos
• Evaluación de capacidades y limitaciones del modelo, incluyendo seguridad
• Transparencia sobre modificaciones del modelo (incluyendo fine-tuning)

Ajustar un modelo y desplegarlo sin evaluación de seguridad crea una brecha de cumplimiento. Documentar tu proceso de pruebas de seguridad — incluso una simple comparación antes/después — contribuye mucho a demostrar diligencia debida.

Requisitos de Cumplimiento del Cliente

Más allá de las regulaciones, tus clientes pueden tener sus propios marcos de cumplimiento. Los clientes de salud necesitan garantías de que la IA no proporcionará diagnósticos médicos. Los clientes financieros necesitan confirmación de que la IA no dará asesoramiento financiero específico. Los clientes legales necesitan garantías de que la IA incluirá disclaimers apropiados.

Estos requisitos no se tratan de que el modelo sea "seguro" en un sentido abstracto. Se tratan de que el modelo se comporte confiablemente dentro de los límites que tu cliente requiere. Las pruebas de seguridad del fine-tuning deben mapearse a requisitos de cumplimiento específicos del cliente, no solo a benchmarks genéricos.

Cómo Ayuda Ertas

Ertas está construido con fine-tuning consciente de la seguridad como preocupación de primera clase:

Integración de evaluación de seguridad. Ertas Studio incluye evaluación de seguridad integrada que se ejecuta automáticamente después del entrenamiento. Ves los resultados de benchmarks de seguridad junto a las métricas de precisión antes de decidir desplegar.

La ventaja estructural de LoRA. Porque Ertas usa adaptadores LoRA en lugar de fine-tuning completo, el alineamiento de seguridad del modelo base se preserva estructuralmente. El adaptador modifica un pequeño subespacio de pesos mientras la mayoría del modelo — incluyendo los pesos entrenados para seguridad — permanece sin cambios.

Rollback de adaptador. Si un modelo desplegado muestra problemas de seguridad en producción, puedes revertir a la versión anterior del adaptador en segundos sin tiempo de inactividad. El modelo base nunca cambia, así que siempre tienes un fallback seguro.

Pista de auditoría. Cada ejecución de entrenamiento, resultado de evaluación y decisión de despliegue se registra. Cuando un cliente pregunta "¿cómo aseguran que su IA es segura?" tienes documentación, no solo garantías.

El alineamiento de seguridad no es una característica que agregas al final. Es una restricción que mantienes a lo largo del proceso de fine-tuning. Los equipos que hacen esto bien construyen productos más confiables — y esa confianza es lo que gana clientes empresariales.

---

Lectura relacionada:

• IA Conforme con HIPAA: On-Premise vs Nube — consideraciones de privacidad y cumplimiento para despliegues de IA en salud
• IA Conforme con GDPR — requisitos de protección de datos para sistemas de IA en la UE