Idea principal

La base de datos de nóminas vive ahora en el entorno Azure del cliente. Una mañana, la aplicación deja de responder. ¿Es el motor del editor, la base SQL Server del cliente, una regla de red modificada la víspera, un certificado, una configuración de IAM, una saturación de conexiones, una cuota, una latencia?

Responder "la base está en casa del cliente, no es problema nuestro" no funciona. Para el usuario que no puede hacer su nómina, es el servicio del editor el que está caído.

El contrato ha desplazado una responsabilidad; la percepción, en cambio, no se ha movido.

Por qué es importante

Esto impone una obligación que no se deriva del contrato sino de la situación: supervisar lo suficiente el recurso externalizado y su conectividad para entender de dónde viene un incidente. No administrar la infraestructura del cliente, sino disponer de las señales — disponibilidad, latencia, errores de conexión, saturación, estado de salud.

Es un coste que el acuerdo no hace aparecer en el momento de negociarlo, y que después ya no desaparece nunca.

Matices y límites

La supervisión no hace al editor capaz de actuar: ver la avería y poder repararla son dos cosas distintas.

Y la obligación tiene un límite: más allá de cierto punto, supervisar todo el entorno del cliente equivale a explotarlo, que es justo lo que el reparto pretendía evitar.

Preguntas abiertas

• ¿Qué nivel de supervisión basta para diagnosticar sin invadir la explotación del cliente?