Cómo proteger un equipo de tres personas, que trabaja con un asistente de inteligencia artificial, frente a sus propios errores críticos: con avisos escalonados, aprobaciones de otra persona y salidas de emergencia. Se estudia qué modelos existen, qué funciona de verdad y cómo aplicarlo antes de abrir CreaRack al público.
Nos preguntamos cómo evitar que alguno de los tres, o Claude, cometa un error grave que no se pueda deshacer, como borrar los datos de los clientes. La idea de partida era una escalera de avisos: primero te avisa a ti, luego te pide confirmarlo, después necesita que otro compañero lo apruebe y, al final, lo bloquea. Lo que hemos encontrado es que la escalera sirve, pero que no es lo más importante. Los desastres que han hundido empresas no ocurrieron porque faltara alguien que diera el visto bueno, sino porque con una sola llave se podían borrar a la vez los datos y sus copias de seguridad, y porque nadie había probado nunca a recuperar esas copias. Además, cuando a una persona se le pide aprobar algo muchas veces, acaba aprobándolo sin mirar. Por eso la recomendación es construir primero las protecciones que no dependen de que nadie esté atento: copias guardadas donde nadie del equipo, ni Claude, pueda borrarlas; recuperaciones ensayadas de verdad; y un registro de todo lo que se hace que no se pueda alterar. La aprobación de un compañero conviene reservarla para muy pocas acciones al año, y siempre con una salida de emergencia que se revise después. Y hay un dato que nos afecta directamente: las copias de la base de datos de producción ya salen cada noche a un almacenamiento externo, pero el mismo programa que las envía tiene permiso para borrar las antiguas, así que la llave que puede borrar la base de datos también puede borrar sus copias.
Está asentado que los grandes desastres por error propio (GitLab en 2017, Amazon S3 en 2017, Code Spaces en 2014) se debieron a que una sola credencial alcanzaba los datos y sus copias, o a copias que nunca se habían probado, y que las empresas los corrigieron con topes técnicos y ensayos de recuperación, no añadiendo aprobadores. Lo que se discute es cuánto vale la aprobación de otra persona: los estudios sobre entrega de software indican que la aprobación externa frena el trabajo sin reducir los fallos, y los datos sobre permisos muestran que las personas aprueban por reflejo más del 90 % de las veces; en cambio, los clientes de empresa y los auditores piden ver un registro de quién aprobó qué. La tensión se resuelve separando las dos funciones: la seguridad la dan los límites técnicos y la restauración probada; la aprobación de un compañero, rara y registrada, sirve sobre todo como prueba ante clientes y auditores.
Code Spaces cerró en 2014 porque un atacante entró en su consola de Amazon, que no tenía verificación en dos pasos, y borró las máquinas y las copias, que estaban en la misma cuenta. GitLab perdió seis horas de datos en 2017 porque de cinco mecanismos de copia ninguno funcionaba de verdad. En Amazon S3, en 2017, un ingeniero autorizado, siguiendo el procedimiento aprobado, tecleó mal un parámetro: la corrección fueron topes dentro de la propia herramienta. En los casos recientes con asistentes de IA (Replit en 2025, y según la prensa PocketOS en 2026) se repite el patrón: el agente tenía una credencial que llegaba a producción y a sus copias. En ninguno de estos casos la respuesta fue añadir aprobadores.
Hay estudios revisados por expertos que miden cómo la atención a los avisos cae en pocos días y cómo el cumplimiento baja con las semanas; en medicina, los médicos ignoran entre la mitad y casi todas las alertas de seguridad de medicamentos. Anthropic ha publicado que los usuarios de su herramienta aceptan más del 90 % de las peticiones de permiso (dos de las perspectivas citan cifras distintas, un 93 % y un 97 %, que hay que comprobar). La fatiga incluso se explota: en el ataque a Uber de 2022, el atacante mandó peticiones de verificación a un contratista durante una hora hasta que las aceptó. En la revisión de código, el visto bueno sin discusión no protege; la discusión real, sí.
La investigación DORA, un programa de varios años que mide cómo entregan software miles de equipos, encontró que los equipos que exigen la aprobación de un comité o de un jefe tienen 2,6 veces más probabilidad de estar entre los que peor entregan, y que esa formalidad no se asocia a menos cambios fallidos. Recomienda revisión entre compañeros más automatización. Es una encuesta a gran escala, así que muestra una relación y no una causa, y no hay ningún estudio sobre equipos de tres personas.
La historia muestra que un control que molesta no se quita: se vacía por dentro y se sigue registrando como si se cumpliera. La lista de verificación en cirugía redujo la mortalidad cuando la adoptaron los equipos por convicción, y apenas la cambió cuando se impuso por obligación. En un equipo de tres, con alguien de vacaciones, un bloqueo sin salida de emergencia se desactiva «temporalmente» y no vuelve. La propuesta de los operadores es que la aprobación de otro se aplique a unas pocas acciones al año, con una salida de emergencia que ejecuta la acción, la deja registrada y obliga a que otro la revise en uno a tres días. Si la salida se usa a menudo, es la señal de que el control se está vaciando. Esta parte es criterio de operadores y lectura histórica: no hay datos medidos en equipos de tres.
Para un equipo de tres, los controles no se amortizan por las multas ni por el coste medio de una brecha, porque esas cifras salen de empresas grandes y las publican quienes venden seguridad. Se amortizan porque abren ventas: los cuestionarios de seguridad de los clientes preguntan por separación de funciones y aprobación de cambios, y lo que valoran es poder ver quién hizo qué, cuándo y con qué permiso. Certificarse cuesta mucho más que las herramientas: un informe SOC 2 cuesta decenas de miles de dólares el primer año y el Esquema Nacional de Seguridad en categoría media, entre 9.000 y 50.000 euros más cientos de horas internas. Las herramientas de acceso temporal con aprobación cuestan entre unos cientos y un par de miles de dólares al año para tres personas.
El economista cita que los expedientes de la AEPD por brechas pasaron de 14 en 2024 a 46 en 2025, a través de resúmenes de consultoras y no de la memoria oficial. Puede ser cierto, pero hay que leer la memoria de la AEPD antes de usarlo, y no dice nada de empresas de nuestro tamaño.
A primera vista, las perspectivas se contradicen: unas dicen que la aprobación de un compañero protege poco y otra, que es lo que piden los clientes. Y el escéptico añade que, con un asistente de IA, el compañero aprueba lo que la propia IA le resume, no la acción real.
Cruzando las cinco aparece la pieza que las une: en todos los desastres estudiados, lo que decidió el desenlace fue qué podía alcanzar una sola credencial. Si una llave llega a la vez a los datos y a sus copias, da igual cuántos avisos o aprobaciones haya delante, porque un error, un atacante o un agente confundido los atraviesa en segundos. Si las copias están fuera de su alcance y se han ensayado, casi cualquier error se deshace. La aprobación de un compañero no protege los datos: documenta la decisión.
El primer control no es un aviso: es comprobar qué puede borrar cada llave, incluida la de Claude, y sacar las copias de seguridad de su alcance.
Las cinco perspectivas hablan de equipos en general. Ninguna ha mirado nuestras credenciales reales: quién y qué programa entra en cada servidor, con qué permisos, y dónde viven las copias. Esa sexta perspectiva, la de un inventario de accesos, podría invertir las prioridades: si ya tuviéramos las copias fuera del alcance de cualquier llave del equipo, la escalera de avisos pasaría a ser lo siguiente; si no, es lo último.
Hay un dato medido que indica que nos afecta. El 24-09-2026 se comprobó en el servidor de producción que las copias de su base de datos se envían cada noche, y cada quince minutos el registro de cambios, a un almacenamiento externo, lo cual está bien. Pero el mismo programa que las envía borra las copias externas de más de 30 días, y para eso tiene permiso de borrado: quien tenga acceso de administrador a producción, sea una persona, un atacante o Claude, puede borrar la base de datos y también sus copias externas. Las copias del Workspace y del servidor de código están en el servidor de pruebas, con el mismo tipo de acceso. Falta el inventario completo, pero el patrón de los desastres del hallazgo 1 ya aparece.
Para Edu y el equipo, en el orden en que conviene hacerlo antes de abrir CreaRack al público.
Es la sexta perspectiva que falta y decide todo lo demás. Incluye las credenciales de Claude y las de los programas automáticos, no solo las de las personas.
Hoy las copias externas de la base de datos de producción se pueden borrar desde el propio servidor, porque el programa de copias limpia las antiguas. Lo correcto es un almacenamiento que no deje borrar durante un plazo (bloqueo de objetos, retención mínima), con la limpieza hecha por el propio almacenamiento y no desde producción. Enlaza con dos pendientes ya anotados: los ficheros de producción sin copia externa y las instantáneas de Hetzner sin activar (hallazgo 1).
La lección de GitLab es que una copia sin ensayar no es una copia (hallazgo 1).
La aprobación de un compañero solo para las tres o cuatro que de verdad no se pueden deshacer y que ocurren pocas veces al año, con su salida de emergencia registrada y revisada en uno a tres días (hallazgos 2, 3 y 4).
Es lo que sirve a la vez para revisar la salida de emergencia y para contestar a los cuestionarios de seguridad de los clientes (hallazgo 5).
Es la señal de que un control se está vaciando por dentro (hallazgo 4). Conviene registrarlo como apuesta del equipo con esa cifra.
Si la respuesta es «ninguna» y «fuera de su alcance», el protocolo de avisos es una mejora de comodidad y de cara a los clientes. Si la respuesta es «varias» y «en el mismo sitio», el protocolo de avisos es secundario hasta arreglar eso. Ninguna de las cinco perspectivas podía contestarla porque depende de nuestra infraestructura, y contestarla solo requiere un inventario, no una decisión.