Saltar al contenido
SaberTEC

Documento legal

Autorización del acudiente — texto y flujo

Este documento define qué texto debe aceptar el acudiente y en qué momento del producto, para que la autorización sea válida ante la Ley 1581 de 2012: previa, expresa e informada, y conservable como prueba.


1. Texto de la autorización

Se muestra al acudiente antes de crear o vincular la cuenta de un estudiante menor de edad. La casilla no puede venir premarcada.

Autorización para el tratamiento de datos de mi hijo, hija o representado Declaro que soy el padre, la madre o el representante legal de [nombre del estudiante] y que estoy facultado para autorizar el tratamiento de sus datos personales. Autorizo a Sligo Group S.A.S., NIT 901617281-0, para recolectar, almacenar y usar los siguientes datos del estudiante: nombre, nombre de usuario, correo electrónico, grado, institución educativa, curso y el registro de su actividad de práctica dentro de la plataforma. Entiendo que estos datos se usarán únicamente para prestar el servicio educativo, mostrarme el avance del estudiante y, cuando corresponda, entregar indicadores agregados a su institución educativa. No se usarán con fines publicitarios ni se entregarán a terceros con fines comerciales. Conozco que puedo consultar, actualizar, rectificar o suprimir estos datos, y revocar esta autorización, escribiendo a info@sabertec.co. He leído la Política de Tratamiento de Datos Personales. ☐ Autorizo el tratamiento de los datos personales del estudiante.

2. Registro que debe quedar guardado

Cada autorización se almacena con:

Campo Descripción
guardian_idCuenta del acudiente que autoriza
student_idCuenta del estudiante autorizado
politica_versionVersión de la política aceptada (ej. 1.0)
texto_hashHash SHA-256 del texto exacto mostrado
aceptada_enFecha y hora con zona horaria
ipDirección IP desde la que se otorgó
revocada_enNulo mientras esté vigente

Guardar el hash del texto —y no solo la versión— permite demostrar años después qué leyó exactamente esa persona.

3. Dónde aparece en el producto

a) El acudiente crea la cuenta del estudiante. La autorización se muestra en el mismo formulario, antes del botón de creación. Sin la casilla marcada, el botón permanece deshabilitado.

b) El acudiente quiere vincular una cuenta que ya existe. Este es el punto que hoy está cerrado en el servidor, porque permitía que cualquier adulto se declarara acudiente de cualquier estudiante conociendo su correo. El flujo correcto tiene tres pasos:

1. El acudiente solicita la vinculación indicando el correo del estudiante. 2. La plataforma envía un código de seis dígitos al correo del estudiante, no al del acudiente. 3. El acudiente introduce el código y acepta la autorización. Solo entonces se crea el vínculo.

Así, quien controla la cuenta del estudiante confirma la vinculación. La infraestructura de códigos ya existe en el servidor (createOtpChallenge y verifyOtpChallenge); basta con añadir el propósito guardian_link.

c) La institución educativa carga estudiantes. La institución declara contar con la autorización de los acudientes y asume la responsabilidad. Debe quedar registro de quién hizo la declaración y cuándo. Esta vía debe reservarse a instituciones con contrato firmado.

4. Revocación

El acudiente puede revocar la autorización desde su cuenta. Al revocar:

5. Esquema de base de datos sugerido

```sql CREATE TABLE guardian_authorizations ( id uuid PRIMARY KEY, guardian_id uuid NOT NULL REFERENCES users(id) ON DELETE CASCADE, student_id uuid NOT NULL REFERENCES users(id) ON DELETE CASCADE, politica_version text NOT NULL, texto_hash text NOT NULL, aceptada_en timestamptz NOT NULL DEFAULT now(), ip inet, revocada_en timestamptz, UNIQUE (guardian_id, student_id) );

CREATE INDEX guardian_authorizations_student_idx ON guardian_authorizations (student_id) WHERE revocada_en IS NULL; ```

El vínculo efectivo debe leerse siempre de esta tabla: si no hay autorización vigente, no hay acceso. Conviene que guardian_students derive de aquí, o se fusione con ella.


Pendientes