Resumen

  • En la agenda del 24 de septiembre figura la revisión de conflicto RFC 5742 de draft-irtf-nmrg-ai-challenges-06, un texto del grupo de investigación NMRG destinado a publicación informativa.
  • La respuesta -00 proponía «sin conflicto» y una nota sobre ataques adversarios y resultados peligrosos de la IA. La versión -01 del 24 de septiembre conserva la conclusión propuesta pero elimina la nota. El estado sigue siendo IESG Evaluation y aparece un DISCUSS pendiente.
  • La prueba de que los datos o el modelo resistieron un ataque no demuestra que una orden de configuración respete capacidad física, política de acceso o posibilidades de reversión.

Se puede proteger muy bien el conjunto de entrenamiento y aun así recibir una orden mala. El borrador del NMRG menciona, entre sus ejemplos, una asignación de calidad de servicio mayor que la capacidad de un enlace y cambios en tablas de filtrado capaces de debilitar una política de acceso. Ninguno requiere, por sí mismo, que un atacante haya alterado el modelo. En el extremo opuesto, un clasificador de tráfico puede haber sido engañado antes de proponer nada. Llamar «riesgo de IA» a ambas situaciones sirve para titularlas, pero no para decidir qué evidencia debe pedir un operador.

El hecho nuevo está en la comparación de versiones. La respuesta -00 decía que no había conflicto con trabajos IETF y pedía considerar un comentario del IRSG sobre los apartados 9.2 y 9.3. El historial registra que Mohamed Boucadair comparte la conclusión de ausencia de conflicto, pero cuestiona que la respuesta solicite atender comentarios del IRSG; Tommy Jensen respalda esa objeción. La versión -01 elimina la nota y mantiene la conclusión propuesta. La cronología no demuestra por sí sola toda la motivación de la edición ni equivale a una resolución: sigue habiendo IESG Evaluation y un DISCUSS. Los dos riesgos siguen descritos en la investigación, no en el texto actual de la respuesta.

El apartado 9.2 mira hacia dentro del sistema: envenenamiento de datos, evasión de un clasificador, inferencia sobre información utilizada al entrenarlo. Para evaluarlo, importan la procedencia de entradas y el comportamiento ante manipulación deliberada. El 9.3 mira hacia fuera: decisiones que podrían modificar filtrado o distribuir recursos imposibles. Para evaluarlo, importan límites impuestos fuera del modelo, despliegues escalonados y una retirada verificable. El propio borrador analiza la actuación gradual y la reversión; no ofrece con ello una garantía automática para cualquier implementación.

RFC 5742 impide confundir el trámite con una certificación. En esta vía el IESG verifica conflictos de publicaciones ajenas al flujo IETF; no convierte la investigación en una norma de Internet ni avala la aptitud técnica de un controlador. El borrador es de consenso de un grupo IRTF y pretende ser Informational. Las fuentes examinadas no muestran una implantación concreta, un fallo de red ni una medida probada de seguridad.

Daniel Kade propone pedir dos comprobantes antes de adoptar una idea de este trabajo. Uno recogería hipótesis de amenaza, responsables de datos y ensayos frente a ataques al modelo. El otro consignaría qué órdenes puede emitir, quién verifica límites de recursos y acceso, cuándo se detiene la ejecución y qué estado recupera una reversión. Es un criterio editorial, no un requisito promulgado por la IETF. Su valor es impedir que una respuesta institucional estrecha acabe funcionando como permiso tácito para tocar equipos.

Sources