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 ASI esta es barata, ampliamente aceptada y pendiente. La Fundación quiere que sea obligatoria.

La objeción popular, con nombre

La versión optimista dice que la aviación demostró el método: seguir reportando, seguir investigando y el riesgo catastrófico caerá de la misma manera que cayeron las tasas de pérdida de fuselaje. En esta visión, los sistemas de incidentes son el motor principal de seguridad y los límites anticipatorios son una distracción hasta que tengamos más datos de accidentes.

Aviso el tiempo verbal en que funciona el motor. Los reportes de incidentes son retrospectivos. Aprende de daños que ya ocurrieron. Eso funciona cuando los fallos, por trágicos que sean, son sobrevivibles a nivel de la industria, de modo que cada uno pueda enseñar a la flota. El sistema mejora 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á

Construye el sistema. Hazlo obligatorio. Protege la divulgación honesta. Luego mantenlo fuera del primer lugar del conjunto de herramientas. Debería estar junto a los límites anticipatorios y la verificación establecidos en nuestro plan, que existen precisamente porque algunos fallos no se pueden manejar después del hecho.