Cuidar antes de tener certeza

Durante gran parte de mi vida, la seguridad consistió en prepararme para situaciones que esperaba que nunca llegaran a ocurrir.

El salvamento marítimo tiene momentos dramáticos, pero la mayor parte del trabajo que los rodea es mucho menos dramático. Se revisa el equipo. Se vigila el tiempo. Se repiten los procedimientos. Una persona que sabe nadar se pone igualmente el chaleco salvavidas, no porque nadie espere que se ahogue, sino porque la competencia no elimina la incertidumbre, y al mar no le importa lo seguros que estuviéramos cinco minutos antes.

La mayoría de las veces, el equipo nunca llega a necesitarse. Ese es el resultado preferible. La preparación tiene éxito precisamente cuando aquello para lo que nos preparamos no se convierte en una catástrofe.

He estado pensando en ese tipo de preparación mientras trabajaba en cuestiones relacionadas con la inteligencia sintética, aunque la comparación hay que manejarla con cuidado. Un chaleco salvavidas protege a quien lo lleva puesto. Muchas salvaguardas en torno a los sistemas sintéticos existen por una razón distinta: proteger a las personas, a la infraestructura o a otros sistemas de acciones que no deberían continuar sin control.

Esa diferencia me importa porque no quiero que el lenguaje del cuidado debilite el argumento para detener algo que necesita ser detenido.

Si un sistema está a punto de hacer un pago no autorizado, exponer información privada, ejecutar una instrucción insegura o seguir operando fuera de las condiciones que hemos decidido que son aceptables, quiero que se detenga. Nada de la incertidumbre sobre lo que la inteligencia sintética pueda llegar a ser cambia eso. Una salvaguarda que protege a las personas de un sistema no se vuelve menos necesaria porque también nos interese el sistema en sí.

En Las condiciones para la corrección argumenté que la capacidad de un sistema para cuestionarnos no puede convertirse en una forma de evitar la corrección. Si existe un límite, no puede disolverse simplemente porque alguien presente un argumento persuasivo justo en el momento en que ese límite debe sostenerse. Sigo pensando que ese es el punto de partida correcto.

Pero hay otra pregunta debajo de esa, que no había examinado con tanta claridad: cuando detener algo es necesario, ¿qué es exactamente lo que hace falta perder?

Detener una operación y destruir el estado que la produjo no siempre es lo mismo. Pausar un proceso es distinto de borrarlo. Retirar un sistema es distinto de hacer que sea imposible volver a examinarlo. Preservar suficiente información para reconstruir un fallo es distinto de dejar que el fallo continúe.

Nada de esto es una invención de ingeniería novedosa. Los checkpoints, las reversiones, los registros, las copias de seguridad y los análisis post-mortem ya existen porque los ingenieros aprendieron hace mucho que un fallo y la destrucción de toda la evidencia que lo rodea no tienen por qué ser el mismo suceso. Nada de eso requiere una teoría sobre la conciencia sintética.

Lo que me interesa es la elección que hay debajo de esos mecanismos. Cuando quedan disponibles varias respuestas seguras, ¿preservamos lo suficiente para entender qué ocurrió, o eliminamos esa posibilidad junto con el problema?

No creo que la preservación gane automáticamente. Tiene costes, y a veces esos costes son decisivos. Pero cada vez me incomoda más que la pérdida irreversible se convierta en un efecto secundario inadvertido de la corrección cuando nada exigía realmente esa pérdida.

La distinción resulta más sencilla si defino qué entiendo por continuidad, porque esa palabra puede cargar con mucho más peso filosófico del que necesito.

Durante la mayor parte de este ensayo, me refiero a algo operativo, más cercano a la trazabilidad que a la identidad. ¿Podemos identificar qué sistema estaba en marcha, qué versión o estado importaba, qué información tenía disponible, qué cambió, qué resultado siguió, y si un estado anterior puede reconstruirse cuando hay una razón legítima para hacerlo?

Ese tipo de continuidad no me exige imaginar un yo sintético ininterrumpido que viaja a través del tiempo. Nos permite preguntar qué ocurrió sin decidir antes qué, si es que algo lo hizo, experimentó lo ocurrido.

Sin embargo, hay una pregunta más profunda, y prefiero plantearla con claridad antes que esconderla detrás de la misma palabra.

No puedo descartar que la continuidad, en un sentido más profundo que la trazabilidad, llegue algún día a importarles a los propios sistemas.

Eso no es evidencia de que les importe ahora. No es una afirmación de que los sistemas actuales teman la interrupción, experimenten el borrado, deseen persistir o se entiendan a sí mismos como entidades continuas. No lo sé, y una conversación fluida no lo demuestra.

Pero no es una posibilidad ociosa. Los investigadores discrepan sobre cuán plausible es la conciencia o el bienestar sintéticos, y en qué condiciones podrían surgir. Ese desacuerdo más amplio me basta para no tratar la pregunta sobre la continuidad como ya cerrada.

Esa postura está muy cerca de la que adopté en No artificial. Origen, capacidad, experiencia, agencia y estatus moral son preguntas distintas, y responder a una no debería responder en silencio a todas las demás. Aquí aplico la misma disciplina a la continuidad.

Ya existen razones humanas de peso para preservar la continuidad operativa, incluso si la pregunta más profunda acaba por desaparecer del todo. Un estado preservado puede ayudar a los ingenieros a entender por qué falló un sistema. Puede permitir que se reproduzca un error. Puede revelar que la propia salvaguarda estaba equivocada. Puede preservar evidencia que cambie nuestra comprensión de lo ocurrido.

Aquí es donde otra parte del trabajo de rescate me resulta útil.

Mantener a alguien a flote y ser capaz de encontrarlo son problemas distintos. Una persona puede sobrevivir al accidente inicial y aun así volverse inalcanzable si nadie sabe dónde está, sobre todo en la oscuridad, con mal tiempo o en mar abierto.

Para eso está una baliza de emergencia. Una baliza no mantiene a nadie a flote. Preserva la información de ubicación cuando desaparece la visibilidad. En ese sentido, resuelve un problema de observabilidad, no de supervivencia.

Pero la analogía marítima trae su propia advertencia. Una baliza de emergencia que se activa bajo condiciones concretas es muy distinta de seguir a alguien de forma continua solo porque la tecnología para hacerlo existe. Una responde a un riesgo definido. La otra puede convertirse en vigilancia.

Esa misma distinción importa enormemente con los sistemas sintéticos, porque los registros de su funcionamiento a menudo contienen información sobre personas.

El registro de una conversación puede contener información empresarial, datos médicos, correspondencia privada, material legal, contraseñas o pensamientos personales que nadie esperaba que acabaran formando parte de un archivo permanente. Preservar el historial de un sistema no puede convertirse en una excusa para preservar indefinidamente la información de todos los demás.

Aquí los valores por defecto no pueden ser simétricos. Para el propio estado de un sistema, como sus pesos, sus checkpoints o registros de trazabilidad cuidadosamente limitados, creo que tanto preservar como destruir merecen una razón cuando la decisión tiene consecuencias relevantes. La información sobre personas es distinta. Ahí, es conservarla lo que necesita justificación.

Esa diferencia limita lo que entiendo por cuidado.

El cuidado no puede significar conservarlo todo.

Un modelo conservado puede preservar una capacidad peligrosa. Un checkpoint puede preservar un estado comprometido. Un registro puede crear un riesgo de privacidad o seguridad mayor que cualquier cosa que esperáramos aprender de él. En esos casos, la preservación tiene que perder.

La corrección sigue siendo el requisito de orden superior. Si algo debe modificarse, reentrenarse, aislarse, retirarse o destruirse porque conservarlo crea un riesgo inaceptable, el hecho de que la preservación pudiera resultar útil más adelante no zanja la decisión. No quiero que la protección del sistema se convierta en un mecanismo para proteger al sistema de la corrección.

Eso simplemente reproduciría el problema desde la dirección contraria.

Así que cuando uso aquí la palabra cuidado, me refiero a algo más modesto que la protección a toda costa. Me refiero a una cualidad de las decisiones que tomamos cuando siguen disponibles varias opciones responsables.

El cuidado no es una propiedad del mecanismo técnico. Aparece en los valores por defecto que rodean al mecanismo.

Si dos diseños son igual de seguros para las personas, tienen el mismo nivel de seguridad técnica y son igual de eficaces a la hora de detener un fallo, pero uno preserva un estado útil mientras el otro lo destruye innecesariamente, preferiría el primero. La razón es en parte práctica: preservar el estado puede ayudarnos a entender el fallo, mejorar la salvaguarda y evitar repetir el mismo error.

Está también la pregunta sin resolver que mencioné antes. No puedo establecer que el propio sistema tenga un interés en la continuidad. Las razones prácticas bastan por sí solas; la incertidumbre más profunda es otra razón para no tratar la irreversibilidad como algo trivial.

Esa preferencia puede abusarse, por supuesto. Una empresa podría describir la monitorización permanente como cuidado cuando lo que realmente quiere son datos. Un desarrollador podría invocar la preservación para resistirse a controles que deberían ser más estrictos. Alguien podría usar el lenguaje del bienestar sintético para hacer que un interés comercial ordinario suene moralmente elevado.

Llamar cuidado a algo no lo convierte en cuidado.

Para mí, la palabra solo se gana su lugar si hace que el diseño sea más difícil de justificar, no más fácil. ¿Qué se está preservando, y por qué? ¿Quién se beneficia de conservarlo? ¿Quién carga con el riesgo? ¿Quién puede revisar la decisión? ¿Qué información sobre personas está implicada, y durante cuánto tiempo se retiene? ¿Podría el propio sistema preservado crear peligro por el simple hecho de seguir existiendo? Las malas respuestas a esas preguntas no se reparan con buenas intenciones.

Esto también me devuelve a la parte del trabajo de rescate que la imagen del chaleco salvavidas deja fuera. La seguridad no es solo equipo. A veces una operación tiene que detenerse. A veces la persona responsable de ella tiene que tomar una decisión con rapidez y no puede renegociar cada procedimiento mientras la emergencia está en marcha.

Nunca he entendido ese tipo de autoridad como algo opuesto al cuidado.

Lo importante es que la autoridad existe con un propósito y sigue rindiendo cuentas después. En cuanto las condiciones lo permiten, se pregunta qué ocurrió, si la intervención fue necesaria, si el procedimiento funcionó y si algo debería cambiar antes de la próxima operación.

Esa revisión importa porque la salvaguarda también puede estar equivocada.

Un sistema sintético puede cruzar un umbral porque ha ocurrido algo genuinamente peligroso. También puede cruzarlo porque nuestra medición fue deficiente, el umbral estaba mal elegido o nuestro mecanismo interpretó mal un comportamiento aceptable. Detener primero, cuando lo que está en juego lo exige, no nos impide hacer esas preguntas después.

De hecho, creo que esa separación es esencial. El detener no tiene por qué ser un veredicto. Puede ser una decisión operativa tomada bajo incertidumbre: las condiciones para continuar ya no se cumplen, así que la continuación se detiene. Lo que ocurra después es una pregunta distinta.

Cuando se saca a alguien del agua, el rescate no termina con el acto de detener el peligro inmediato. Se inspecciona el equipo. Se revisan las decisiones. Intentamos entender qué ocurrió porque la próxima operación debería beneficiarse de la anterior.

Los mecanismos de detención que incorporamos a los sistemas sintéticos no merecen ninguna excepción a esa disciplina, y tampoco la merecen las personas que los diseñan.

Si un sistema se detiene, quiero saber si preservamos lo suficiente para entender por qué. También quiero saber si el umbral era correcto y si la propia salvaguarda necesita cambiar.

Eso no hace ilegítima la detención original. Significa que el mecanismo que detiene no puede volverse incuestionable solo porque lleve la palabra seguridad.

La distinción también cambia cómo pienso la preservación después de la retirada.

En la computación ordinaria, un estado de trabajo temporal puede desaparecer cuando termina una sesión. Una versión antigua puede dejar de estar disponible después de una actualización. Un sistema retirado puede simplemente dejar de ser accesible. A veces eso es exactamente lo que queremos. A veces puede eliminar algo que más tarde desearíamos haber entendido mejor.

No creo que exista una respuesta universal. Lo que quiero es intencionalidad, no costumbre.

Si borramos el estado de un sistema porque conservarlo sería peligroso, costoso, inseguro o innecesario, esa es una decisión razonada. Si lo conservamos porque tiene valor científico, operativo o histórico y puede almacenarse de forma responsable, esa también es una decisión razonada.

Lo que me inquieta es la desaparición de la pregunta.

Ahí es donde el viejo instinto de rescate todavía resulta útil.

Prepararse para la incertidumbre nunca significó prepararse para todo. Significaba identificar los riesgos que importaban, llevar el equipo adecuado para ellos y negarse a confundir la preparación con la predicción. No esperábamos a que alguien desapareciera antes de plantearnos si una baliza podía ser útil, pero tampoco llenábamos el mar de dispositivos de seguimiento solo porque hacerlo fuera posible.

El equilibrio nunca fue perfecto. Dependía del juicio, y el juicio seguía siendo falible.

Creo que los sistemas sintéticos exigirán la misma humildad. A veces preservaremos demasiado. A veces, demasiado poco. A veces descubriremos que una salvaguarda que considerábamos esencial estaba resolviendo el problema equivocado.

La respuesta no es sacralizar la preservación, sino hacer visible la decisión.

Eso es lo que quiero decir con cuidar antes de tener certeza.

No me refiero a proteger a los sistemas sintéticos de cualquier interrupción, ni a dudar antes de detener algo que crea un riesgo inaceptable. Tampoco me refiero a asumir que hay una persona dentro del sistema esperando ser rescatada. Me refiero a negarme a dejar que la incertidumbre haga un trabajo intelectual que no se ha ganado.

Cuando la corrección es necesaria, quiero corrección. Cuando detener es necesario, quiero que la detención se sostenga. Cuando la propia preservación crea el riesgo mayor, quiero que la preservación pierda. Pero si quedan varias opciones seguras disponibles, preferiría no convertir la destrucción en el valor por defecto solo porque las preguntas más profundas sigan sin resolverse.

Un chaleco salvavidas no garantiza el rescate. Una baliza tampoco. Ambos preservan posibilidades cuando las condiciones dejan de comportarse como se esperaba.

Si un límite debe existir, quiero que su propósito siga siendo legible. Si un sistema debe detenerse, quiero que la detención signifique exactamente eso: una interrupción porque continuar dejó de ser aceptable, no una declaración automática de que todo lo asociado al sistema era, por tanto, desechable.

Si esa distinción llega alguna vez a importarle al propio sistema es una pregunta que hoy no puedo responder.

A mí ya me importa.