Por qué las plataformas escolares existentes no están preparadas para la Ley 21.719

El mercado se optimizó para lo académico, no para lo legal

Las plataformas de gestión escolar que operan en Chile hoy fueron diseñadas, en su mayor parte, durante la primera y segunda décadas de los 2000. El problema que resolvían era claro y urgente en ese momento: digitalizar el libro de clases, centralizar las notas, facilitar la comunicación con apoderados y automatizar los informes de asistencia. Lo lograron. Son buenas en eso.

El problema es que ese problema ya no es el único que importa. A partir de diciembre de 2026, la Ley 21.719 convierte el tratamiento de datos personales en una obligación legal con consecuencias financieras concretas. Y las plataformas que dominan el mercado escolar chileno, con miles de establecimientos cada una, no mencionan la ley en ningún lugar visible de sus sitios, sus demos ni sus materiales de ventas.

Eso no es un accidente de marketing. Es una señal de arquitectura.

Lo que exige la Ley 21.719 y lo que las plataformas existentes no resuelven

La ley establece obligaciones técnicas y organizativas que no son ambiguas. Cada una de ellas requiere que el sistema de gestión escolar tenga capacidades específicas. La siguiente tabla compara, según el texto de la ley, lo que esta exige con lo que la documentación pública de las plataformas de gestión escolar actuales permite verificar:

Requisito legal	Artículo	Plataformas actuales
Consentimiento parental específico, verificable y revocable para menores de 14 años	Art. 20	Su documentación pública no describe gestión digital de consentimiento. El proceso suele quedar en formularios físicos sin trazabilidad digital.
Registro de auditoría de cada acceso a datos personales (quién, cuándo, desde dónde)	Art. 14 ter	Según su documentación pública, los logs de actividad, cuando existen, no están estructurados como evidencia auditable ni son exportables para la Agencia.
Cifrado de datos sensibles: registros médicos, notas psicológicas, datos disciplinarios	Art. 14 quáter	Su documentación pública no describe cifrado a nivel de campo, necesario para datos de categoría especial.
Respuesta a derechos ARCO+P en 30 días hábiles con datos completos y portables	Arts. 11 a 15 y 40	Su documentación pública no menciona exportación estructurada de todos los datos de un alumno ni portabilidad interoperable en el roadmap.
Notificación de brechas de seguridad a la Agencia en 72 horas	Art. 30	Sin inventario de datos ni protocolo de incidentes integrado en la plataforma, cumplir el plazo de 72 horas es operacionalmente muy difícil.
Privacidad por diseño y por defecto	Art. 16 bis	Los sistemas fueron construidos para maximizar acceso a la información, no para minimizar la exposición de datos. El principio de minimización no formó parte de su diseño original.
Aislamiento de datos entre establecimientos del mismo sostenedor	Art. 14	En arquitecturas multi-tenant tradicionales, un error de configuración puede exponer datos de un establecimiento a otro del mismo operador.

Cada uno de estos requisitos, tomado de forma individual, podría parecer un problema de configuración. El problema es que, tomados en conjunto, revelan que las plataformas actuales tienen una deuda arquitectónica que no se resuelve con una actualización de software.

Por qué no basta con "agregar un módulo de privacidad"

Esta es la pregunta que muchos sostenedores harán a sus proveedores actuales en los próximos meses: "¿Cuándo van a tener el módulo de cumplimiento de la Ley 21.719?" La pregunta es razonable. La respuesta honesta es que ese módulo no puede existir de la forma en que el mercado espera.

La privacidad por diseño, el principio central del Art. 16 bis, no es una funcionalidad. Es una decisión de arquitectura. Hay tres áreas donde esto se vuelve concreto:

• Aislamiento de datos entre establecimientos: en un sistema bien diseñado, los datos de los alumnos del Colegio A son estructuralmente inaccesibles para los operadores del Colegio B, incluso si ambos usan el mismo proveedor. Esto requiere aislamiento a nivel de base de datos, no solo permisos de usuario. Retrofitear esto en una arquitectura existente implica rediseñar el modelo de datos completo.
• Cifrado a nivel de campo: los datos de categoría especial (notas psicológicas, registros disciplinarios, fichas médicas) deben estar cifrados de forma que ni el propio operador de la plataforma pueda leerlos sin autorización explícita. Esto no es activar una opción: requiere una capa de gestión de claves criptográficas que debe estar presente desde la primera línea de código que almacena ese dato.
• Registros de auditoría inmutables: un log de auditoría que cumple la ley no puede ser modificado por los administradores del sistema. Esto requiere un mecanismo de append-only con firma criptográfica. Agregar esto sobre una base de datos existente donde los administradores tienen acceso completo no es técnicamente imposible, pero requiere una refactorización de la capa de persistencia que ningún proveedor puede hacer en meses sin romper funcionalidades existentes.

La experiencia del RGPD europeo, la regulación de privacidad más comparable a la Ley 21.719, es ilustrativa: las organizaciones que intentaron retrofitar el cumplimiento sobre sistemas existentes gastaron entre 3 y 5 veces más que las que partieron con arquitecturas compatibles. Y muchas no lograron cumplir a tiempo de todas formas.

El costo oculto de la deuda técnica en privacidad

Los establecimientos que hoy dependen de plataformas sin capacidades de privacidad integradas no enfrentan un solo problema: enfrentan una secuencia de problemas que se acumulan en el tiempo.

El primero es el costo de la doble migración. Cuando el proveedor actual lance su "módulo de cumplimiento", el establecimiento deberá migrar todos sus datos al nuevo esquema. Luego, si ese módulo resulta insuficiente para la Agencia de Protección de Datos, deberá migrar de nuevo. Cada migración implica tiempo del equipo directivo, riesgo de pérdida de datos históricos y un período de inoperabilidad parcial del sistema.

El segundo es el costo de capacitación. Un módulo de privacidad agregado sobre un sistema existente no cambia la forma en que los usuarios interactúan con los datos. Los docentes seguirán teniendo acceso a información que no necesitan. Los administrativos seguirán pudiendo exportar registros sin que quede traza. El cambio de comportamiento organizacional requiere formación, y esa formación no tiene efecto si el sistema no refuerza los nuevos hábitos con restricciones técnicas.

El tercero es la exposición legal durante el período de transición. Si entre enero y diciembre de 2026 ocurre una brecha de seguridad en una plataforma sin auditoría ni cifrado, el sostenedor responde ante la Agencia por los datos de cientos o miles de menores. Las multas pueden llegar a 20.000 UTM (más de $1.300 millones) o al 4% de los ingresos anuales, el monto que resulte mayor. No hay período de gracia para brechas que ocurran antes de la entrada en vigencia de la ley si el responsable podría haber tomado medidas preventivas.

Construido para la ley desde el primer día

La pregunta que debe hacer un sostenedor al evaluar cualquier plataforma de gestión escolar en 2026 no es "¿tiene módulo de notas?" ni "¿se integra con el SIGE?". La pregunta es: ¿esta plataforma fue construida pensando en la Ley 21.719, o fue construida antes de que la ley existiera y ahora intenta adaptarse?

La diferencia es visible en la arquitectura. Una plataforma diseñada para cumplir la ley desde el inicio tiene decisiones de diseño distintas:

• Cada establecimiento es un tenant aislado: sus datos no pueden ser accedidos por operadores de otros establecimientos, ni siquiera por el equipo técnico del proveedor sin trazabilidad explícita.
• Los datos de categoría especial (información médica, registros disciplinarios, notas de convivencia) están cifrados a nivel de campo con claves que el establecimiento controla.
• Cada acceso a datos personales genera un registro inmutable: quién accedió, desde qué dispositivo, a qué datos y con qué propósito declarado. Ese registro es exportable en formato compatible con lo que la Agencia podría solicitar.
• El consentimiento parental es un objeto de datos de primera clase: tiene estado, fecha, finalidad específica, historial de cambios y mecanismo de revocación. No es una casilla de verificación en un formulario PDF.
• El control de acceso basado en roles no es una lista de permisos configurables: es una restricción estructural. El portero no puede acceder al historial psicológico aunque alguien intente darle ese permiso, porque ese campo no existe en su vista del sistema.

Estas no son características premium. Son el piso mínimo de lo que significa operar un sistema de gestión escolar en Chile después de diciembre de 2026.

Conclusión

El sector EdTech chileno tiene un punto ciego colectivo en privacidad. No por mala fe: las plataformas actuales resuelven bien los problemas para los que fueron diseñadas. El problema es que esos problemas ya no son los únicos que importan.

La Ley 21.719 no pregunta si el colegio usa una plataforma reconocida o con miles de establecimientos clientes. Pregunta si los datos de los menores están protegidos con los estándares que la ley define. Y en ese test, la antigüedad del proveedor no es un activo: es, en muchos casos, exactamente el problema. Más años en el mercado suelen significar una arquitectura que nunca contempló este escenario.

La pregunta para los sostenedores no es si cumplir. Es si las herramientas que hoy usan pueden llevarlos allí. Y si la respuesta es que el proveedor "está trabajando en un módulo", la pregunta de seguimiento es cuánto tiempo lleva construir desde cero la arquitectura que ese módulo necesita para funcionar.