Tras un incidente grave, un investigador de la Junta Nacional de Seguridad en el Transporte no le pide a la aerolínea que presente una nota privada y siga adelante. El evento entra en un sistema. Los hallazgos se redactan para que diseñadores, formadores y reguladores puedan cambiar su comportamiento. El pasajero que nunca oye la historia vuela dentro de la actualización. Esa memoria compartida es una gran parte de la razón por la que volar comercialmente se volvió tan seguro como es.

La notificación de incidentes de IA es el intento de dar a este campo el mismo hábito: registro sistemático, intercambio e investigación de casos en los que los sistemas causan daño o están a punto de hacerlo. Cuando un modelo falla en el despliegue, escapa a sus barreras de seguridad por uso indebido o muestra un comportamiento peligroso en las pruebas, todavía no existe el deber consistente de registrarlo, ni un lugar compartido que deba recibirlo, ni una ruta de investigación estándar. Las lecciones que podrían proteger a todos permanecen dentro de una sola empresa o desaparecen.

La propuesta es simple sobre el papel: definir categorías de daño y casi-incidente, requerir reportes en un sistema compartido, y dejar que el campo aprenda una vez, colectivamente.

Qué capturaría un buen sistema

La versión útil es más amplia que los desastres de titulares.

  • Daños desplegados, donde un sistema en el mundo real causó daño o mal funcionamiento grave.
  • Casi accidentes, donde algo salió mal y el daño se evitó por poco. La aviación los considera tan informativos como los siniestros.
  • Comportamientos peligrosos encontrados en las pruebas, incluyendo fallos revelados por pruebas de equipo rojo y evaluaciones, para que la advertencia de peligro de un laboratorio llegue al resto.
  • Eventos de seguridad, como intentos de robar pesos de modelos o eludir salvaguardas.

Los reportes deben ser estructurados y, cuando corresponda, protegidos. Las organizaciones divulgan con más honestidad cuando la investigación de seguridad se separa del teatro de culpas. La aviación aprendió esa separación por una razón. Sin ella, el movimiento racional es el silencio.

¿Por qué vale la pena hacerlo?

Los datos compartidos de incidentes permiten al campo detectar patrones que ninguna organización vería por sí sola. Los reguladores obtienen una base de evidencia anclada en lo que realmente está fallando, no en especulaciones. El modo de fallo de un laboratorio se convierte en advertencia para todos la semana en que se descubre. Con el tiempo, la industria adquiere la memoria institucional que aún le falta. Entre las medidas de gobernanza de superinteligencia esta es barata, ampliamente aceptada y pendiente. La Fundación quiere que sea obligatoria.

Aviación está equivocada.

La aviación demostró que la información y la investigación pueden reducir las tasas de pérdida de casco. Los sistemas de incidentes todavía ayudan. No son el motor de seguridad principal para un fracaso que no puede llegar a estudiar dos veces. Los límites anticipatorios son lo que utiliza cuando el primer accidente puede ser el último punto de datos.

El reporte de incidentes es retrospectivo. Se entera de los daños que ya han ocurrido. Eso funciona cuando los fracasos, sin embargo trágicos, son sobrevivibles en el nivel de la industria, por lo que cada uno puede enseñar la flota. El sistema mejora el evento por evento.

Esa lógica falla para los riesgos que más preocupan a la Fundación. Una falla catastrófica de un sistema superinteligente no es un consejo que se convoque después. La afirmación central del riesgo existencial es que el fallo más grave puede ser aquel sin recuperación y, por tanto, sin lección. Los reportes de incidentes manejan bien los daños acumulativos y sobrevivibles. Por diseño no pueden abordar el irrecuperable.

Aprender de los fracasos supone que sobrevives a ellos. Para los fracasos que más importan, esa suposición es el problema.

Dónde está

Construir el sistema, ordenarlo y proteger la divulgación honesta. Entonces manténgalo fuera de la ranura superior del kit de herramientas. Debe sentarse junto a los límites anticipatorios y la verificación establecida en nuestro plan, que existen precisamente porque algunos fallos no se pueden manejar después del hecho.