Datos de menores, tratados como lo exige la ley

De un estudiante guardamos su nombre, su fecha de nacimiento y el curso en que está matriculado. No pedimos documento de identidad, ni dirección, ni teléfono, ni foto.

La fecha de nacimiento no es un dato de más: es la que determina si el estudiante es menor de edad, y de ahí depende que cualquier tratamiento no esencial exija el consentimiento vigente de un acudiente verificado. Se pide porque decide una regla, no porque «podría servir después».

No porque la aplicación filtre bien, sino porque el motor de la base de datos no le entrega esas filas. Cada tabla de negocio tiene activado el aislamiento por institución a nivel de Postgres, y la aplicación no escribe el filtro a mano — un where olvidado en una sola consulta sería una fuga entre colegios.

Y hay una regla de desarrollo que lo sostiene: una tabla nueva sin su prueba de aislamiento no entra al producto. La prueba monta dos colegios de mentira, escribe datos en uno y comprueba, conectada como un usuario real del otro, que no ve ni una fila. Corre en cada cambio de código.

Al construir el panel de rectoría apareció que la función de permisos dejaba pasar a la administración del colegio: la dirección podía leer, fila por fila, el progreso y las anotaciones de cualquier niño. La regla estaba escrita en la documentación del producto y no estaba implementada.

Se corrigió con una migración que reescribe esas políticas sin delegar en la función compartida —una función compartida se amplía un día por otro motivo y se lleva por delante una regla que nadie recordaba que dependía de ella— y hoy hay pruebas que fallan si alguien vuelve a abrir esa puerta.

Lo contamos porque un proveedor que jamás ha encontrado un problema de privacidad en su propio producto es un proveedor que no ha mirado.