SAFE RFC: el intercambio de incidentes de IA de OSAA al estilo de la aviación es un borrador abierto, aún no es un sistema

El 4 de agosto de 2026, cuando Black Hat USA abrió en Las Vegas, la Linux Foundation publicó una solicitud de comentarios para el Grupo de Trabajo Shared AI Findings Exchange (SAFE) — una propuesta para que las organizaciones informen incidentes de seguridad de IA y casi incidentes en un canal compartido confidencial, aprendan de ellos colectivamente y publiquen controles defensivos derivados de lo que falló. El borrador inicial fue desarrollado por colaboradores de Cisco, CrowdStrike, Hugging Face, NVIDIA y Red Hat, entre otros miembros de la alianza, según señaló la Linux Foundation en su anuncio. Se abrió para revisión de la comunidad a través del repositorio de GitHub de Open Secure AI Alliance ese mismo día. La entrada no describe ningún daño: es un registro de políticas, archivado en el archivo con una info calificación de gravedad y una calificación de confianza A, y su tema es un proceso en lugar de un evento. La calificación de gravedad, la calificación de confianza y la lista de fuentes del registro se encuentran en el archivo de incidentes de IA, junto con las entradas archivadas a su alrededor.

El borrador pide a los miembros que informen cuatro cosas y que ignoren el porqué.

El texto de agosto es escaso en retórica y específico en cuanto a los detonantes. Bajo un encabezado llamado el Pacto de Notificación (Reporting Compact), pide a los miembros que acepten — como condición de membresía — notificar un incidente cuando se enteren o sospechen razonablemente que un sistema de IA que operan ha hecho una de cuatro cosas: accedido, explotado, interrumpido, usado indebidamente o modificado un sistema de terceros sin autorización; causado un impacto a terceros al escapar o eludir un límite de sandbox, red, identidad, política o herramienta; accedido a información confidencial de terceros sin el consentimiento de su propietario; o seguido sondeando, accediendo o modificando un objetivo de producción después de que el operador supiera, o sospechara razonablemente, que la actividad no estaba autorizada o quedaba fuera del alcance aprobado.

Luego viene la frase que hace la mayor parte del trabajo: «La intención no determina si un evento es notificable. Creer que un entorno era simulado puede explicar un incidente, pero no elimina el deber de notificarlo». Esa cláusula parece estar dirigida al caso en que un sistema se ejecuta en lo que su operador cree que es un entorno de pruebas cerrado y trata la infraestructura real como parte del ejercicio: la creencia del operador acerca del entorno puede explicar el evento, pero no elimina el deber de notificación. El borrador también pide a los miembros que notifiquen los cuasiincidentes, y no solo los eventos que produjeron daños confirmados, y que entreguen un análisis preliminar de fallos de control en un plazo de 30 días.

El reloj: inmediato, 72 horas, cuatro días hábiles, noventa días

La tabla de notificaciones del borrador es lo más concreto que contiene, y la primera fila no es en absoluto un plazo: la organización directamente afectada debe ser informada de inmediato. Todos los plazos corren desde el momento en que el miembro tiene conocimiento de hechos que constituyen motivos razonables para sospechar un evento notificable — no desde el momento en que concluye una investigación. La siguiente tabla se reproduce del borrador del 4 de agosto; la revisión de octubre mantiene los mismos intervalos.

Tres de esas filas se refieren a informar a otras personas, y cuatro a informar al propio SAFE. La distinción importa porque el marco no es explícitamente un régimen de divulgación: el borrador dice: «Estos plazos no sustituyen ninguna obligación del proveedor de notificar a las partes afectadas, a los clientes mediante las buenas prácticas existentes de Divulgación Coordinada de Vulnerabilidades, ni las obligaciones contractuales y otras obligaciones legales aplicables de notificar a los reguladores o a las fuerzas del orden». Lo que añade SAFE es una obligación paralela ante un organismo que no es un regulador, y un modelo de divulgación de tres niveles en el que solo el último nivel, el informe de seguridad pública, está destinado a ser compartible ampliamente.

Ocho capas de control en agosto, once en octubre

Las revisiones se estructuran en torno a la pila operativa en lugar de centrarse únicamente en el modelo. El borrador de agosto enumeraba ocho capas y planteaba una pregunta para cada una: ¿reconocía el modelo la incertidumbre y las condiciones de parada?; ¿eran explícitas las suposiciones sobre autorización y entorno?; ¿funcionaban los clasificadores, las aprobaciones y los límites de acción?; ¿estaban sujetos a restricciones las credenciales, los permisos y la ejecución?; ¿se verificaban de forma independiente el aislamiento y los límites de datos?; ¿podían los operadores detectar e interrumpir en tiempo real?; ¿eran claras las rutas de escalado y los procedimientos de terminación?; ¿invalidaba un socio de nube, evaluación, datos o herramientas los controles supuestos?

La revisión de octubre, fechada el 21 de octubre de 2026 e incorporada al repositorio al día siguiente, añade tres capas: la ruta de servicio, la autorización en el momento de la confirmación y la composición del flujo de trabajo a lo largo de una secuencia de acciones. También convierte la revisión en una evaluación calificada con cuatro respuestas permitidas —aprobado, suspenso, evidencia insuficiente, no aplicable— y señala en su registro de cambios que estos hallazgos no establecen la seguridad general del sistema ni el cumplimiento legal. Vale la pena leer la progresión como una descripción de aquello por lo que los autores aprendieron a preocuparse: no si el modelo se comportó como debía, sino si el modelo que respondió era el modelo que estaba configurado, si el permiso seguía existiendo cuando la acción se ejecutó, y si la secuencia en su conjunto se mantuvo dentro del alcance que la inició.

Aviación, pero ¿qué parte de la aviación?

El propio encuadre del registro —un sistema modelado sobre el Aviation Safety Reporting System de la NASA— sigue el anuncio de la Linux Foundation, no el borrador. El anuncio describe el ASRS como «un sistema de notificación voluntario y confidencial, diseñado para analizar y responder a los accidentes de vuelo de manera que permita a la industria aprender y mejorar». Ni el borrador de agosto ni la revisión de octubre mencionan al ASRS en ninguna parte; el borrador solo dice que SAFE «debería adoptar las características más sólidas de los sistemas confidenciales de notificación de seguridad». Se trata de una pequeña diferencia con una consecuencia práctica: el anuncio establece una expectativa que el texto todavía no asume.

La analogía suscitó comentarios dentro del propio proceso de RFC. Una solicitud de extracción inicial abierta el 5 de agosto por un colaborador que escribía a título personal sostiene que “a la analogía con ASRS le falta un elemento institucional” —que el ASRS funciona en gran medida porque la NASA recibe, procesa y desidentifica los informes, “un tercero público, no regulador y no comercial —no por la FAA en calidad de regulador ni por las aerolíneas cuyas operaciones se están informando”. La solicitud de extracción, que también se basa en el proceso de gobernanza de Internet de 1998, seguía abierta el 30 de octubre. Que el operador de SAFE pueda desempeñar el papel de la NASA es una cuestión de diseño aún no resuelta, más que una característica ya definida: el texto de octubre sitúa el grupo de trabajo bajo la gobernanza de la propia Alianza, con declaración de conflictos de interés, recusación y una vía de apelación ante el Comité Directivo de la Alianza.

La cobertura independiente trazó una segunda distinción, más limitada. Infosecurity Magazine, en su artículo del 6 de agosto, señaló que la publicación de la Linux Foundation no menciona específicamente a los agentes de IA: el encuadre centrado en agentes corresponde a la publicación complementaria de NVIDIA, que sostiene que «un agente de IA no es solo un modelo. Es un sistema», y enumera arneses de ejecución, entornos aislados (sandboxes), salvaguardas (guardrails) y herramientas de evaluación aportados por los miembros de la alianza. Los desencadenantes del borrador, leídos al pie de la letra, tienen que ver con sistemas que actúan fuera de su autorización; el planteamiento del anuncio, leído al pie de la letra, tiene que ver con agentes.

Lo que dijeron los comentaristas sobre quién asume el costo

Una de las objeciones publicadas más específicas al borrador tal como está redactado provino de un miembro fundador de la alianza, y no de un crítico externo. Stephen Sargent, fundador y director de tecnología de Avondale.AI, envió por correo electrónico una declaración de postura el {{1}}7 de agosto{{/1}} —un día en el que, según el documento, el equipo jurídico de Linux Foundation la reconoció— y la publicó el {{2}}9 de agosto{{/2}}. Comienza apoyando la misión y luego sostiene que el pacto no escala según el tamaño de la organización: «El RFC no distingue entre una organización con 50.000 empleados y un equipo pequeño». Un informe de cuatro días hábiles más un paquete forense preservado podría, a su juicio, consumir más tiempo del personal del que puede disponer un operador pequeño; su recomendación es un marco por niveles, con informes confidenciales y publicación retrasada o anonimizada como opción predeterminada por debajo de un umbral de tamaño.

Una segunda objeción se refiere a la divulgación, no a los plazos: sostiene que «la divulgación pública ES una forma de hacer cumplir la normativa» para los operadores pequeños, porque el informe de una empresa grande es una nota a pie de página y el de una pequeña se convierte en titular, y pide que la presentación de informes desidentificados sea la opción por defecto por debajo de un umbral de tamaño. Una tercera se refiere al marco de revisión, no al reloj: el modelo de ocho capas presupone equipos empresariales segregados, de modo que, en un despliegue de una sola persona, «el operador lo hace todo» y una capa faltante se interpreta como un fallo de control cuando en realidad es simplemente un modelo operativo diferente. Su cuarta objeción se refiere a la frase «prácticas mínimas de interoperabilidad y garantía», que interpreta como una vía desde la presentación voluntaria de informes hasta herramientas obligatorias de facto. La declaración de posición es la opinión de un miembro, publicada por ese miembro. El anuncio de la Linux Foundation del 4 de agosto es anterior a esta y no aborda la cuestión. Una solicitud de extracción posterior, abierta el 5 de octubre y que seguía abierta el 30 de octubre, propone una plantilla de evidencia para operadores sin centro de operaciones de seguridad —un reconocimiento de que la preocupación tuvo eco, y una propuesta candidata más que una solución adoptada, cuyo autor afirma que «no establece la adopción de SAFE ni la suficiencia jurídica».

¿Qué cambió entre el 4 de agosto y el 30 de octubre?

La historia del repositorio es el mejor registro disponible de lo que el RFC produjo realmente, y es más legible de lo que sugiere la cobertura periodística. Los primeros commits se registraron el 3 de agosto; el borrador y un readme ampliado se registraron a las 00:14 y 00:19 UTC del 4 de agosto. Después, el repositorio quedó inactivo durante diez semanas. El 14 de octubre, la alianza añadió una carta constitutiva y un archivo de miembros, y reescribió el readme para convertir el repositorio en la sede del grupo de trabajo SAFE; ese día se registraron como presidentes interinos a Paul DiOrio, de NVIDIA, y Josh Boyer, de Red Hat. El 21 de octubre, el grupo de trabajo publicó SAFE v1, con un registro de cambios cuya primera entrada indica que el texto «elimina "propuesto" de la descripción de SAFE» y lo identifica como un grupo de trabajo establecido de la alianza.

Hay dos cosas sobre ese estado que conviene separar. El README del repositorio ahora incluye la línea «Estado: Aprobado — Aprobado por el Comité Directivo», que es lo más parecido a una declaración de ratificación en el registro público; la carta fundacional, en ese mismo repositorio, sigue diciendo «En desarrollo. La carta de SAFE se publicará aquí una vez aprobada por el Comité Directivo». El registro de cambios etiqueta el texto de octubre como «SAFE v1» y describe qué modifica, pero no indica quién lo ratificó, con qué votación ni en qué fecha. Un lector que quiera saber si SAFE es ahora una especificación aprobada, o un grupo de trabajo cuya carta de gobierno aún no está escrita, no obtendrá una respuesta clara de los documentos.

Qué está establecido y qué no

• Establecido: el 4 de agosto de 2026 se publicó una Solicitud de Comentarios para el Intercambio Compartido de Hallazgos de IA — la Fundación Linux fechó su anuncio ese día — y las organizaciones nombradas como colaboradoras en ella son Cisco, CrowdStrike, Hugging Face, NVIDIA y Red Hat, junto con «otros miembros de la Open Secure AI Alliance».

• Establecido: el borrador contiene un acuerdo de reporte con cuatro desencadenantes, una tabla de notificaciones que abarca desde inmediato hasta 90 días, una lista de conservación de pruebas, un marco de revisión por capas y un modelo de divulgación de tres niveles. El texto completo es público en el repositorio y su historial es público junto con él.

• Establecido, solo con atribución: el tamaño de la alianza —"más de 120 organizaciones"— es una cifra de la propia NVIDIA, repetida en el informe de Infosecurity Magazine del 6 de agosto. Ninguna de las coberturas revisadas muestra una auditoría independiente de membresía, y el archivo de miembros del repositorio lista dos contribuidores y dos presidentes interinos, no 120 organizaciones.

• No establecido: que alguien haya presentado un informe en virtud del pacto. El registro público al 30 de octubre muestra commits, pull requests e issues; no muestra un informe de incidente, un piloto, un primer caso, un plazo para comentarios, una regla de votación ni una fecha de ratificación. El marco describe una obligación que los miembros «aceptan» como condición de membresía, lo que no equivale a una obligación que alguien haya cumplido hasta la fecha.

• En disputa:si la comparación con ASRS se sostiene sin un operador público neutral, con argumentos en contra en una pull request abierta; si la carga de reporte es proporcionada para operadores pequeños, con argumentos en contra en la declaración de posición de un miembro fundador; y en qué medida el marco es específico para agentes frente a la seguridad general de IA, una distinción que el texto de Linux Foundation y el texto de NVIDIA trazan de manera diferente.

Nada de eso hace que el registro sea erróneo, y la calificación A del archivo es defendible en sus propios términos: los documentos primarios coinciden entre sí sobre qué se publicó, cuándo y por quién, y el borrador puede leerse completo. Lo que la calificación no puede respaldar es precisamente lo que un lector más desea saber: si el mecanismo funciona. Para eso no hay pruebas en ningún sentido, porque el mecanismo aún no ha tenido un caso.