La autoevaluación
Seis semanas después de desplegarlo, ¿puedes responder estas cuatro preguntas?
No es un modelo de madurez ni una certificación. Son cuatro preguntas sobre un sistema que ya tienes en producción. Llevan unos diez minutos si se responden con honestidad, y son difíciles a propósito: si fueran fáciles, nadie necesitaría hacerlas.
Aquí no se recoge nada. No hay formulario, ni informe por correo, ni resultado detrás de un email. Lee las cuatro, respóndelas en papel, y guarda las respuestas.
Las cuatro
- 01
¿Qué hizo realmente la semana pasada — paso a paso, no por diseño?
Una respuesta realUna traza que puedas leer: las entradas que recibió, las decisiones que tomó, las acciones que ejecutó, en orden, durante un periodo real. Reconstruida desde los logs, no desde el diagrama de arquitectura.
No es una respuesta"Clasifica tickets y los enruta." Eso es para lo que se construyó. La pregunta es qué hizo.
- 02
¿Con qué frecuencia se equivocó — sobre qué conjunto de tareas, definido por quién?
Una respuesta realUn número con un denominador inspeccionable, medido sobre un conjunto de tareas que eligió alguien concreto, con esa elección escrita. Idealmente incluye casos donde esperabas que fallara.
No es una respuestaUn benchmark del proveedor, o una cifra de precisión cuyo conjunto de evaluación nunca has visto. Ambos miden un sistema distinto al tuyo.
- 03
¿Qué habría pasado sin él?
Una respuesta realUna comparación. Un grupo retenido, un periodo previo al despliegue medido igual, o una muestra rehecha a mano. Cualquier cosa que responda "¿comparado con qué?"
No es una respuestaTiempo ahorrado, tickets cerrados o adopción. Eso mide el sistema funcionando, no el sistema ayudando. Esta es la que casi nadie tiene.
- 04
¿Cómo sabrías si se ha degradado?
Una respuesta realUna señal con nombre, un umbral, y una persona que la ve. Algo que se dispara sin que nadie tenga que acordarse de mirar.
No es una respuesta"Nos daríamos cuenta." El silencio no es salud: un sistema que empeoró en silencio no genera quejas hasta que el daño está aguas abajo y sale caro.
Cómo leer tus respuestas
Cuenta solo las que podrías enseñarle a alguien.
No las que podrías defender — aquellas en las que puedes abrir un documento, un panel o un log y dejar que una persona escéptica lo compruebe. Responder mentalmente no cuenta, y esa restricción es todo el ejercicio.
Lo cual es extremadamente común y no es un defecto moral. Sí significa que ahora mismo nadie puede saber si el sistema ayuda, tú incluido.
Sabes qué hace y aproximadamente con qué frecuencia falla. El hueco casi siempre es la tercera — el contrafactual — y es la que decide si vale la pena mantenerlo.
Genuinamente raro. Si puedes mostrar las cuatro, puedes defender el sistema ante un consejo, un regulador o un escéptico — y deberías estar escribiendo sobre ello, no leyendo esto.
Por qué preguntarle al proveedor no cierra el hueco
Pueden responder dos. Nunca las dos últimas.
Un proveedor puede decirte para qué se construyó el sistema y cómo rindió en su conjunto de evaluación. No puede decirte qué habría pasado en tu organización sin él, ni cuándo se ha desviado con tus datos: esas respuestas solo existen donde el sistema realmente funciona. No es una afirmación sobre la honestidad de los proveedores. Es una afirmación sobre dónde vive la evidencia.
Si la respuesta es "no" en casi todas
Eso es el hueco, no un fracaso.
Todas estas preguntas tienen respuesta. Ninguna requiere una plataforma, una certificación ni una nueva partida de presupuesto — requieren decidir que "creemos que funciona" no es lo mismo que saberlo, y hacer después la medición aburrida que cierra la diferencia. Esa medición es lo que este laboratorio publica, primero el método, incluidas las partes que fallan.