Cumplimiento y seguridad
Las reglas que tiene que cumplir un software del Estado
Comprar software para un organismo público tiene reglas concretas. Esta página dice qué obliga cada una, qué hacemos nosotros al respecto y —lo que casi nadie escribe— qué no hacemos.
Bloque 01
La ley que ordena todo lo demás
Desde la Ley 21.180 el procedimiento administrativo del Estado es electrónico. Sus normas técnicas D7 a D12 bajan esa regla a exigencias concretas de seguridad, documento electrónico e interoperabilidad. Casi todo lo que sigue cuelga de ahí.
Ley 21.180
Transformación digital del Estado
Qué exige. Que el expediente y la tramitación sean electrónicos, no una versión escaneada del trámite en papel.
Qué hacemos. Nuestros sistemas son el expediente, no un archivador de PDF. Un documento tiene número, responsable, plazo y recorrido dentro del sistema; el papel, cuando lo hay, es una copia de eso y no al revés.
D9 art. 6 y 10
Identidad y acceso
Qué exige. ClaveÚnica y Clave Tributaria como mecanismos oficiales de autenticación; contraseñas guardadas con bcrypt, PBKDF2, Argon2 o SHA-3; y transporte cifrado con TLS 1.2 o superior.
Qué hacemos. Las contraseñas se guardan con bcrypt de costo 12 y nunca en claro. La sesión viaja en una cookie que JavaScript no puede leer, así que un ataque de script no se lleva la sesión. ClaveÚnica está prevista en el modelo desde el primer día y se habilita por configuración cuando el organismo tiene el convenio; hoy no está conectada y lo decimos.
D9 art. 13
La hora de los registros
Qué exige. Que la trazabilidad de accesos se registre en huso horario UTC+00:00.
Qué hacemos. Todas las marcas de tiempo se guardan en UTC y se convierten a hora de Chile solo al mostrarlas. Además de cumplir la norma, evita el problema real: Chile cambia de huso dos veces al año y en la noche en que el reloj se atrasa dos hechos distintos compartirían la misma hora local.
D12 art. 6
Interoperabilidad
Qué exige. Que el nodo de interoperabilidad (PISEE) esté en la infraestructura del propio organismo.
Qué hacemos. No ofrecemos reemplazar el nodo ni alojarlo nosotros. Nuestros sistemas se conectan detrás del nodo del municipio, que es donde la norma lo pone.
Bloque 02
El documento electrónico y su trazabilidad
La norma técnica D10 es la más exigente para un sistema como el nuestro, y la que muchos proveedores no mencionan: sus artículos 10 y 36 dicen que estas obligaciones alcanzan también a los sistemas de terceros. O sea, a nosotros.
D10 art. 9
Sellado de tiempo
Qué exige. Que la fecha y hora de los documentos electrónicos se registre en UTC.
Qué hacemos. Se cumple en toda la base de datos, sin excepciones ni campos «de hora local».
D10 art. 11
Trazabilidad del ciclo de vida
Qué exige. Registro de la creación, la modificación, la transferencia y la eliminación de cada documento.
Qué hacemos. Cada una de esas acciones deja un evento con autor, hora, dirección de origen y detalle. Nada se elimina de verdad: anular es un estado del documento, y queda anulado a la vista de todos con su motivo.
D10 art. 37
Registro de accesos
Qué exige. Registrar todos los accesos a documentos que contienen datos sensibles, no solo las modificaciones.
Qué hacemos. Se auditan también las lecturas de documentos reservados. Es la parte que se suele omitir porque no se nota en una demostración, y es la que un sumario pregunta primero.
Verificable
La bitácora encadenada
Qué exige. Nada en particular: esto lo agregamos nosotros.
Qué hacemos. La bitácora solo admite escritura y cada evento incluye la huella del anterior. Alterar o borrar un evento del medio rompe todos los siguientes, y hay un botón que recalcula la cadena completa a la vista y dice si está intacta. Es la diferencia entre declarar integridad y demostrarla.
Bloque 03
Los plazos
Los plazos administrativos no se cuentan en días corridos, y un sistema que los cuenta mal produce vencimientos falsos que nadie vuelve a creer.
Ley 19.880 art. 25
Días hábiles administrativos
Qué exige. Que los plazos se cuenten en días hábiles, excluyendo sábados, domingos y festivos. Ojo: en el plazo administrativo el sábado es inhábil, a diferencia del plazo judicial.
Qué hacemos. El cálculo está en una sola librería, con el calendario de feriados chilenos, y es la misma en todos nuestros productos. Un plazo de cinco días que empieza un jueves vence el jueves siguiente, no el martes. El vencimiento se guarda como fecha fija para que actualizar el calendario no mueva plazos que ya estaban corriendo.
Bloque 04
Las firmas
Acá es donde más se exagera en los folletos, así que conviene ser exactos: hay dos firmas distintas y no sirven para lo mismo.
Ley 19.799 art. 2 f)
Firma electrónica simple
Qué exige. Identidad del firmante, intención de firmar e integridad de lo firmado.
Qué hacemos. Implementada: identidad autenticada, acto explícito de firma, sello de tiempo y huella del contenido firmado. Si el documento se edita después, la firma se muestra rota en vez de seguir figurando como válida.
Ley 19.799 art. 4
Firma electrónica avanzada
Qué exige. Que los instrumentos públicos —el decreto alcaldicio, la resolución— se firmen con firma avanzada, emitida con certificado de un prestador acreditado.
Qué hacemos. Todavía no la tenemos conectada. El modelo de datos ya distingue la firma simple de la avanzada y el punto de integración está documentado, pero la conexión con el prestador acreditado se hace en la implementación. Preferimos decirlo antes que entregar un botón que dice «firma avanzada» y no lo es.
Bloque 05
Lo que es público y lo que no
Ley 20.285
La publicidad es la regla
Qué exige. Que los actos y documentos de la Administración sean públicos; la reserva o el secreto son la excepción y hay que fundarlos en alguna de las causales del artículo 21.
Qué hacemos. La clasificación por defecto de todo documento es «público». Reservarlo es una acción deliberada, con constancia de quién lo dispuso y cuándo, y a partir de ahí cada lectura queda registrada.
Bloque 06
Datos personales
La Ley 21.719 empieza a regir el 1 de diciembre de 2026. Los sistemas que se compran hoy van a estar funcionando ese día, así que se construyen desde ya con sus reglas.
Ley 21.719
Minimización
Qué exige. Tratar solo los datos personales necesarios para la finalidad declarada.
Qué hacemos. Cada campo que pide un dato personal tiene que justificarse por una función concreta. Un formulario de contacto que pregunta el RUT «por si acaso» sobra, y por eso en el nuestro el RUT es opcional.
Ley 21.719 art. 27 b)
Dónde viven los datos
Qué exige. No hay obligación de que los datos se alojen en Chile. La transferencia internacional es lícita, entre otras vías, mediante cláusulas contractuales.
Qué hacemos. Decimos en el contrato en qué país está alojado el servicio y con qué cláusulas, en vez de dejarlo en una letra chica. Si el organismo exige alojamiento en Chile por política propia, se cotiza así.
Menores de edad
Datos de alumnos
Qué exige. Un estándar de cuidado más alto cuando los titulares son menores.
Qué hacemos. Aula se está construyendo con acceso restringido por relación —el apoderado ve a su pupilo y nadie más— y con registro de accesos, no solo de modificaciones.
Bloque 07
Ciberseguridad e incidentes
La Ley 21.663 fija plazos para informar un incidente. Los plazos corren para el organismo, y el organismo no puede cumplirlos si su proveedor le avisa tarde.
Ley 21.663 art. 9
Aviso al CSIRT Nacional
Qué exige. Alerta temprana dentro de las 3 horas de tomar conocimiento, actualización a las 72 horas e informe final a los 15 días.
Qué hacemos. Nos comprometemos a avisar al organismo apenas detectamos un incidente que lo afecte, con lo que sepamos en ese momento, para que sus 3 horas empiecen a correr con información y no con una sospecha. Y a entregarle el detalle técnico para la actualización y el informe final.
Ley 21.663
Comunicar vulnerabilidades
Qué exige. Que el contrato no restrinja la comunicación de vulnerabilidades.
Qué hacemos. Ningún contrato nuestro incluye cláusulas de confidencialidad que impidan reportar una vulnerabilidad. Si alguien encuentra una en nuestro software, queremos saberlo: se escribe a nuestro correo de contacto.
Los plazos del artículo 9
-
3 horas
Alerta temprana
desde que se toma conocimiento
-
72 horas
Actualización
con lo que se sepa a esa altura
-
15 días
Informe final
con causa, impacto y medidas
Los plazos corren desde que se toma conocimiento del incidente y son obligación del organismo, no del proveedor. Nuestro compromiso es que el organismo no se entere tarde.
Bloque 08
Accesibilidad
DS N°1/2015
Pautas WCAG del W3C
Qué exige. Que los sitios y sistemas del Estado sigan las pautas de accesibilidad del W3C.
Qué hacemos. Contraste suficiente en modo claro y oscuro, foco visible, navegación completa con teclado, estructura semántica para lectores de pantalla, texto alternativo en las imágenes y respeto por la preferencia de movimiento reducido del sistema. Empezando por este mismo sitio, que se puede leer entero con JavaScript deshabilitado.
Bloque 09
El contrato
Las Bases Tipo de ChileCompra ya resolvieron varias discusiones. Vale la pena saber qué dicen antes de firmar.
Bases Tipo 10.17
Los datos y los registros son del organismo
Qué exige. Que los datos y también los registros de actividad pertenezcan al organismo y se puedan exportar sin costo.
Qué hacemos. La bitácora completa se exporta evento por evento, y la exportación masiva del expediente está definida como parte del protocolo de salida. Nuestros sistemas no envían mediciones de uso a terceros: no hay nada que exportar de vuelta porque no hay nada afuera.
Bases Tipo 10.19
Propiedad del software
Qué exige. Que el organismo marque en el Anexo N°3 si adquiere la propiedad del código o una licencia de uso.
Qué hacemos. Ofrecemos licencia de uso, que es el modelo normal en servicio mensual. Si unas bases exigen la propiedad del código, lo evaluamos y cotizamos distinto, o no ofertamos.
Bases Tipo 10.24
Protocolo de salida
Qué exige. Un procedimiento de migración de los datos al terminar el contrato.
Qué hacemos. Se acuerda al firmar, no al terminar: formato, plazo y responsable. Un proveedor que dificulta la salida no está reteniendo un cliente, está avisando de qué tipo de proveedor es.
Bases Tipo 11.2
Nivel de servicio
Qué exige. Que el SLA se evalúe, con multas de hasta 1 UF por hora hábil y 5 UF por día hábil de incumplimiento.
Qué hacemos. Comprometemos el nivel de servicio que podemos sostener, no el que gana más puntos. Es la misma razón por la que decimos que somos una empresa pequeña.
Bloque 10
Lo que no hacemos
Cuatro cosas que a veces se ofrecen y que nosotros no vamos a ofrecer, o porque la norma no lo permite, o porque no las tenemos. Un proveedor que promete las cuatro está prometiendo mal.
-
No somos su encargado de seguridad
La norma técnica D7, artículo 5, dice que la responsabilidad de seguridad de la información del organismo no se puede externalizar. Cualquier proveedor que se ofrezca a ser su responsable de seguridad le está ofreciendo algo que la norma no permite.
-
No alojamos su nodo de interoperabilidad
La norma técnica D12, artículo 6, pone el nodo PISEE en la infraestructura del organismo. Nuestros sistemas se conectan detrás de él.
-
No emitimos firma electrónica avanzada
La firma avanzada la emite un prestador acreditado. Nosotros integramos la del organismo cuando la tiene; no la reemplazamos ni la simulamos.
-
No medimos a sus usuarios
Nuestros sistemas no envían estadísticas de uso a terceros, y este sitio no usa cookies ni servicios de medición externos. Los registros de actividad quedan en la instalación del organismo, que es de quien son.
¿Necesita esto en el formato de su propuesta técnica?
Si está preparando unas bases o evaluando una oferta y necesita el detalle punto por punto contra un criterio de evaluación concreto, escríbanos y se lo mandamos escrito, sin compromiso.