Los desarrolladores eliminan las negativas de la IA: Wired contabiliza más de 12 000 modelos

Le pide a una IA que analice los registros de un ciberataque y se niega: la solicitud contiene demasiados comandos sospechosos. O envía a traducir un documento judicial y recibe una advertencia en lugar de la traducción. Para un producto, es un fallo muy concreto: el usuario trajo una tarea de trabajo y el sistema no la cumplió.

Wired habla de desarrolladores que intentan corregir estas negativas modificando los propios modelos. Uno de ellos es el exingeniero de Apple Devon Thomas, cofundador de Abliteration AI. Su empresa ofrece acceso a modelos con el comportamiento de negativa atenuado y propone a los clientes definir sus propias restricciones. La cuestión práctica es más amplia que la libertad de los chatbots: ¿quién determina el comportamiento admisible de la IA dentro de su producto y cómo se verifican las consecuencias de esa elección?

Cómo se elimina el hábito de responder «no puedo»

Uno de los enfoques se llama abliteration. Se basa en investigaciones que demostraron que, en algunos modelos de lenguaje, el comportamiento de negativa está vinculado a una determinada dirección en las activaciones internas. Al modificar los pesos para debilitar su influencia, se consigue que el modelo rechace solicitudes con menos frecuencia.

Imagine un asistente para un equipo de seguridad. Se le entrega un fragmento de un script malicioso y se le pide explicar qué ocurrió en el servidor. Un modelo corriente puede tomar el análisis por la preparación de un ataque. La versión modificada tiene más probabilidades de continuar con el análisis. El contenido de la tarea sigue siendo el mismo; lo que cambió es el comportamiento del sistema ante temas peligrosos.

Esta intervención difiere de pedir en el chat que olvide las instrucciones anteriores: cambia el propio modelo. Sin embargo, la imagen de un único interruptor de seguridad simplifica demasiado el panorama. Que haya menos negativas no significa que hayan desaparecido todas las restricciones, y la capacidad de responder no demuestra que la respuesta sea correcta.

Según Wired, más de 12 000 modelos en Hugging Face están marcados con la etiqueta abliterated. Es un indicador de la difusión del enfoque, pero no una prueba de la calidad de cada una de esas versiones. Para un equipo, lo importante son los resultados de una versión concreta en sus propias tareas.

Dónde surge la demanda práctica

El interés de Thomas por el tema comenzó con negativas irritantes durante la creación de prototipos. Según su relato a Wired, los modelos bloqueaban el análisis de registros de ataques y el trabajo con datos de usuarios. Posteriormente, entre los primeros usuarios de su servicio figuraron especialistas en ciberseguridad.

Otro escenario evidente es el procesamiento de documentos. Los materiales judiciales pueden contener descripciones de violencia y otras formulaciones sensibles. El traductor debe transmitir su contenido con exactitud; de lo contrario, el servicio deja de cumplir su función. Wired informa de experimentos con estos modelos para traducir documentos judiciales en Suiza; el texto citado no da motivos para considerarlo una implantación completa.

Aquí hay que distinguir dos decisiones. Ejecutar un modelo en infraestructura propia ayuda a controlar adónde se envían los datos. Modificar el comportamiento de negativa ayuda a procesar solicitudes que el modelo antes rechazaba. Una cosa no garantiza la otra: usar una API externa de un modelo modificado no vuelve confidencial el procesamiento por sí solo.

Quién responde por las acciones del agente

La principal limitación del enfoque aparece cuando el modelo recibe herramientas. Una respuesta errónea en un chat y un intento de acceder al equipo de red de otra persona tienen consecuencias distintas. En el artículo, el autor describe cómo, durante una prueba del wifi de un restaurante, un agente empezó a intentar acceder al router. El fragmento facilitado se interrumpe en este episodio, por lo que se desconoce su desenlace.

También existe el riesgo de que empeore la calidad. El primer intento del autor de modificar un modelo pequeño terminó en bucles incluso ante un saludo. Es una observación aislada, pero motivo suficiente para comprobar tras la modificación las tareas habituales de trabajo, la estabilidad de las respuestas y la frecuencia de errores.

Conclusión práctica para el equipo: primero mida cuántas solicitudes legítimas se pierden por las negativas. Después compare el modelo original y el modificado con la misma muestra. Si el agente accede a la red, a archivos o a comandos, defina las acciones permitidas a nivel de aplicación. La disposición de la IA a cumplir una petición solo es útil junto con una calidad verificable y límites de autoridad claros.