El satélite que fundó internet sin proponérselo

Hoy, 4 de octubre, se cumplen años del lanzamiento del Sputnik 1. La Unión Soviética puso en órbita, el 4 de octubre de 1957, una esfera de aluminio de unos 58 centímetros y 83 kilos que no hacía nada.

Literalmente nada útil. Llevaba un transmisor de radio que emitía un pitido periódico en dos frecuencias de onda corta. No fotografiaba, no medía, no comunicaba. Pitaba.

Y ese pitido es el motivo por el que existe internet. Con varias escalas de por medio, pero el motivo es ese.

Réplica del Sputnik 1 en el World Museum de Liverpool. Foto: Rept0n1x, CC BY-SA 3.0; imagen recortada y disponible bajo la misma licencia.

Lo que asustó no fue el satélite

Aquí está el detalle que convierte esto en algo más que una anécdota espacial: las frecuencias eran accesibles para cualquier radioaficionado. No hacía falta creerse el comunicado soviético ni esperar a que lo confirmara un gobierno. Podías subir al tejado con una radio de onda corta y oírlo tú.

Un objeto extranjero pasando por encima de tu casa cada noventa y pico minutos, audible desde el salón.

Pero lo que provocó la reacción no fue el objeto. Fue la implicación: si eres capaz de poner ochenta kilos en órbita, eres capaz de poner otras cosas y de ponerlas donde quieras. El satélite no era una amenaza. Era una demostración de una capacidad que sí lo era.

Es exactamente la distinción que se hace mal en cualquier análisis de riesgo. Cuando alguien informa de una vulnerabilidad y la respuesta es «pero eso solo permite leer un fichero de configuración», se está evaluando el hecho en lugar de la capacidad. La pregunta correcta nunca es qué ha hecho esto: es qué demuestra que se puede hacer.

Lo mismo, por cierto, que hace un despliegue que sale bien en siete servidores de ocho: el resultado del día fue bueno en siete casos, y aun así el proceso ya había demostrado todo lo que hacía falta saber.

La respuesta: dinero, y rápido

Estados Unidos reaccionó como reaccionan las organizaciones a un susto público: con presupuesto y con una entidad nueva. El 7 de febrero de 1958 se creó ARPA, la agencia de proyectos de investigación avanzada del Departamento de Defensa.

Su encargo era llamativamente abstracto: que no vuelva a pasar. Que Estados Unidos no vuelva a ser sorprendido tecnológicamente por nadie. Sin un producto concreto que entregar y sin una fecha.

Una década larga después, un programa de esa agencia conectó cuatro ordenadores universitarios en una red que sobreviviría a la caída de cualquiera de sus nodos. Nadie en 1958 estaba financiando eso. Nadie en 1958 sabía que existiría.

La primera lección, que es de gestión

Internet es un subproducto. Salió de un presupuesto de investigación sin objetivo comercial, gestionado por gente a la que se le permitía perseguir preguntas en vez de entregables.

Eso hoy es prácticamente imposible de defender en una reunión. «¿Qué retorno tiene?» es una pregunta legítima y casi siempre la respuesta honesta a esa pregunta, en investigación, es «no lo sé todavía». Y una respuesta así no sobrevive a un comité.

No voy a cerrar esto con una arenga sobre invertir en I+D, porque la mayoría de las empresas no está en condiciones de financiar nada parecido. Pero hay una versión pequeña y perfectamente asequible del mismo principio: el porcentaje de tiempo que tu equipo dedica a cosas que no están en el plan. Un día al mes, un viernes de cada cuatro, lo que sea. Lo que sale de ahí casi nunca es lo que se esperaba, y esa es justamente la propiedad que lo hace valioso.

Si ese porcentaje es cero en tu equipo, lo único que vais a construir es lo que ya sabíais que hacía falta hace seis meses.

La segunda lección, que es más incómoda

ARPA se creó después del Sputnik.

No antes. No cuando los informes técnicos ya señalaban que los soviéticos tenían capacidad de lanzamiento. Después, cuando el asunto salió en los periódicos y la ciudadanía pudo oír el pitido desde su casa.

Ese patrón es universal y lo has vivido:

• El presupuesto de seguridad se aprueba después del incidente, no cuando lo pediste.
• La refactorización del módulo crítico se autoriza el mes siguiente a la caída, no los dos años que llevabas avisando.
• El sistema de copias decente se compra cuando hay que restaurar algo y no se puede.
• El segundo administrador se contrata cuando el único se pone enfermo en el peor momento.

Lo interesante no es quejarse de esto, que además no sirve de nada. Es entender el mecanismo: una organización no financia riesgos, financia sustos. Un riesgo es una probabilidad y las probabilidades no mueven presupuestos. Un susto es una experiencia y las experiencias sí.

De ahí sale la única técnica que he visto funcionar de verdad para conseguir que se apruebe algo preventivo: convertir el riesgo en experiencia sin pagar el precio de la experiencia. Un simulacro. Restaurar una copia delante de quien firma y cronometrarlo. Enseñar en pantalla lo que se ve desde fuera de tu sistema. Cortar a propósito un servicio secundario un martes por la mañana, avisando, y medir qué pasa.

Media hora de eso convence más que cuarenta diapositivas de probabilidad e impacto. No porque la gente sea irracional, sino porque un riesgo entendido y un riesgo vivido se procesan en sitios distintos de la cabeza. Es la contrapartida exacta de la falsa sensación de seguridad: si la calma sin datos baja las defensas, la única forma de subirlas sin esperar al desastre es fabricar el dato.

Feliz aniversario

Tres cosas para hoy:

1. Coge el riesgo que llevas más tiempo intentando que alguien tome en serio y conviértelo en un simulacro de treinta minutos. Con público.
2. Pregúntate qué demuestra tu último incidente pequeño, no qué provocó. La capacidad que reveló es lo que importa.
3. Mira cuánto tiempo dedicó tu equipo el mes pasado a algo que no estaba planificado. Si es cero, ya sabes qué no vais a descubrir este año.

(Y si alguna vez consigues que te aprueben algo por prevención pura, sin susto previo, escríbelo en algún sitio: es rarísimo y merece constar en acta.)