Wazzy: cientos de citas al mes y ninguna reservada dos veces

La primera versión de Wazzy era un agente con herramientas a su disposición y la dejamos atrás. La que está hoy en producción reparte el trabajo de otra manera, con mucho más peso del lado del código y bastante menos del lado del modelo. Cómo está montada por dentro no lo vamos a contar aquí, entre otras cosas porque no es información que le debamos a la competencia. Lo que sí se puede enseñar es lo que esa decisión produce.

Ninguna cita se ha reservado dos veces en toda la historia del producto. Ni una. Es un fallo que no se arregla pidiendo perdón, porque cuando ocurre hay dos personas en la puerta a la misma hora y una se tiene que ir a casa.

Nada sale a producción sin pasar antes una batería de casos reales con su respuesta correcta anotada. Eso incluye lo que edita la propia clínica desde su panel, que no cambia lo que el asistente responde hasta que la batería lo aprueba. Y la versión del modelo la fijamos nosotros, así que una actualización del proveedor no aparece sola en producción un martes por la mañana.

Sobre el sistema en marcha hay 103 controles vigilando, atados a 91 reglas con nombre que el sistema tiene que cumplir. Y una vez por semana una prueba recorre el sistema entero de punta a punta, pidiendo cita como lo haría una persona.

Eso cambia las reglas antes de escribir una línea. El reglamento europeo aparta los datos de salud en su artículo 9, entre las categorías que no se pueden tratar sin un motivo tasado. El que ampara a una clínica es el 9.2.h, el de la asistencia sanitaria.

Sí guardamos datos personales. Decir lo contrario sería más cómodo y sería falso. Lo que hacemos es guardarlos cifrados campo a campo en vez de cifrar el almacén entero de una pieza, de modo que lo que se descifra es el dato que hace falta en ese momento.

La ley marca cuánto tiempo hay que conservar una historia clínica, pero esa obligación es de la clínica y no nuestra. Wazzy borra a petición todo lo que no tenga un plazo legal por encima. Lo que sí lo tiene se conserva mientras ese plazo dure.

Y el modelo no habla con la base de datos. Las dos cosas que un asistente puede hacer mal aquí, inventarse un dato o sacar el de otra persona, no dependen de que el modelo se porte bien.

Ningún sistema en producción está libre de haber hecho algo tonto. Este es el nuestro y lo contamos porque de él salió una regla que usamos desde entonces en todo lo que construimos.

El asistente había pedido confirmar la asistencia a una cita y esa pregunta se quedaba abierta veinticuatro horas. Dos horas y media después, la persona contestó con dos emojis. El asistente los leyó como lo que eran, algo que no iba de la cita, pero al marcarlos así dio por cerrada la confirmación.

Un minuto más tarde esa misma persona escribió que sí iba. Ya no había nada abierto que confirmar. La cita se quedó en pendiente, la clínica nunca supo que iba y fue.

La confirmación tenía veintiuna horas de vida por delante. No expiró, la mató un emoji. De ahí salió una regla de una línea que hoy va en todo lo que construimos. Que un mensaje no vaya de algo no significa que ese algo haya terminado. Solo una acción cierra una acción.

Y lo medimos, porque una anécdota sin cifra no sirve para decidir nada. En toda la vida del producto hay 287 confirmaciones que fueron por el camino bueno, 105 que caducaron sin respuesta y 10 que se quemaron así.

Wazzy es el único sistema nuestro donde el que paga cuando algo sale mal somos nosotros. Por eso es donde probamos primero. Casi todo lo que sabemos sobre lo que se rompe en un asistente conversacional lo sabemos por él. Ese aprendizaje llega a los proyectos de cliente ya hecho.

Un cliente no compra Wazzy. Wazzy es de una clínica y de sus citas. Lo que construimos para otra empresa se construye para su problema. Lo que se hereda de aquí es el método, que son las pruebas delante de cada cambio y la disciplina de no dejarle al modelo una decisión que puede tomar el código.