Fuga por consultas y por registros

Una API de modelo puede devolver más que texto. Algunas ofrecen, para cada palabra generada, qué probabilidad le asignó el modelo. Es útil para quien construye, pero también es una señal: la literatura sobre ataques de inferencia de pertenencia explica que un modelo suele mostrarse más seguro con textos que vio al entrenarse que con textos que no vio, y esa diferencia puede servir para sospechar si un dato estuvo en el entrenamiento.

Quien defiende no necesita entender el ataque en detalle; necesita preguntarse qué devuelve su API de más y si el usuario lo necesita.

Abre la configuración de la API de Cuyén. Una configuración revisada con ojo de privacidad hace una sola pregunta por línea: ¿esto lo necesita quien consulta? Si la respuesta es no, se apaga. Es el principio de dar solo lo necesario, aplicado a lo que devuelve la interfaz.

Localiza el parámetro que hace que la API devuelva esa señal adicional.

El registro de uso de un día resume, por cuenta, cuántas consultas hizo, de qué tipo y cuántas respuestas coincidieron literalmente con material de los lotes de afinado, según un detector que el equipo de Coirón puso a la salida. Una cuenta normal pregunta con contexto de un paciente; una que consulta sin contexto, a gran volumen y con coincidencias, merece una pregunta del equipo, no una conclusión.

Cruza las columnas y localiza la cuenta con más coincidencias.

Mirando la configuración y el registro, las medidas se reparten en tres capas: lo que la interfaz devuelve (cerrar lo que sobra), cuánto se puede preguntar (límites por cuenta y alertas por coincidencia) y lo que se guarda del uso (el registro del día es, él mismo, un dato sensible que lleva retención). Una alerta que avisa a una persona con nombre vale más que un registro que nadie lee.

La política de alertas de Coirón fija un umbral y un contacto. La respuesta correcta combina capas, no apuesta por una sola.