Cómo se introducen los datos, quién puede modificarlos y qué garantiza que se mantengan intactos.

Una instancia y una base de datos por cliente. El aislamiento constituye un límite de implementación.

• Cada cliente utiliza su propia base de datos con su propia licencia.
• Se aloja en la jurisdicción que elijas. Los registros permanecen en ese país. Existe la posibilidad de implementarlo en un proveedor de propiedad canadiense en centros de datos canadienses.
• Es posible realizar una implementación autohospedada en tu propia infraestructura.
• Las normativas municipales y provinciales en materia de privacidad dependen de dónde se encuentren los registros y quién pueda acceder a ellos: la MFIPPA y la FIPPA en Ontario, la FOIPPA en Columbia Británica y la Ley de Protección de la Privacidad de Alberta. Las evaluaciones de impacto sobre la privacidad se realizan por escrito.
• Los datos son tuyos. Los registros se exportan en el formato acordado, previa solicitud o al finalizar el plazo, y se utilizan exclusivamente para gestionar tu instancia.
• La eliminación es una eliminación provisional con un plazo de conservación, y los plazos de destrucción se establecen en el contrato.

• Una instancia por cliente
• Centros de datos canadienses
• Opción de alojamiento propio
• MFIPPA y FIPPA
• Exportación de datos previa solicitud

El control de acceso se aplica en la capa de consulta.

• Los derechos se conceden por tipo de registro y por operación. El servidor rechaza la consulta.
• Las restricciones a nivel de registro se aplican por encima de los derechos de rol.
• Inicio de sesión único mediante SAML 2.0 y OIDC, incluido Microsoft Entra ID. La URL de inicio de sesión y el certificado de firma de tu proveedor de identidad se pegan en la configuración de la instancia y se aplican al reiniciar el sistema. Por encima de ellos hay una capa de asignación de claims.
• Los grupos de proveedores de identidad se asignan a los roles de Aptli. Si no se configura, no tiene ningún efecto, y la asignación solo concede los derechos que ya tiene el rol.
• Las cuentas del personal utilizan una aplicación de autenticación o SMS. Los códigos de recuperación de un solo uso se generan en el momento de la inscripción y se almacenan en forma de hash.
• Los usuarios externos utilizan una contraseña y un código de un solo uso que se envía por correo electrónico, independientemente del inicio de sesión único interno.
• TLS en tránsito. Las credenciales de integración almacenadas se cifran en reposo con AES-256-GCM.

• Derechos en la capa de consulta
• Restricciones sin precedentes
• SAML 2.0
• OIDC
• Entra ID
• Aplicación de autenticación
• Códigos de recuperación
• AES-256-GCM

Lo que hace falta para cambiar un récord y lo que deja atrás.

• Los cambios se incluyen en una versión con nombre. Compara dos versiones cualquiera una al lado de la otra y descarta una.
• Restaurar una versión confirmada crea un borrador con su estado anterior, que pasa por la misma revisión.
• Las funciones «Deshacer» y «Rehacer» se aplican a toda la sesión de edición del mapa antes de que se guarde nada.
• Las modificaciones sobre el terreno y las propuestas públicas se envían para su revisión antes de incorporarse al expediente. Un revisor las aprueba, las rechaza o las devuelve con comentarios, y el informe final incluye su propio veredicto: «aprobado», «rechazado» o «necesita revisión».
• El registro de auditoría es de solo añadir datos y se puede exportar a formatos CSV, JSON y XLSX. En él se registra qué se ha hecho, quién lo ha hecho y cuándo.
• Los derechos de creación, edición y eliminación se configuran por tipo de registro y por operación. La responsabilidad sobre una clase de activo recae en un rol específico.

• Versiones con nombre
• Deshacer y rehacer
• La aprobación antes de que cuente
• Registro de auditoría de solo adición
• Derechos por tipo

Los sistemas auxiliares se apagan y se eliminan los identificadores antes de que nada salga.

• El asistente está desactivado en una nueva instancia. Un administrador lo activa y selecciona el proveedor y el modelo.
• Los nombres, las direcciones de correo electrónico y los números de teléfono se sustituyen por tokens determinísticos antes de que una solicitud salga de la instancia. La tabla de correspondencias inversa se almacena en tu propia base de datos.
• La plataforma propone algo y la persona lo acepta o lo rechaza. No aplica cambios por sí sola.
• Responde en función de los datos que se le han facilitado explícitamente dentro del mismo ámbito de roles que rige el resto del sistema.
• Puede apuntar a un proveedor autohospedado o regionalizado. La inferencia no tiene por qué salir de la infraestructura que controlas.

• Desactivado por defecto
• Identificadores seudonimizados
• Propone, pero nunca se compromete
• Opción de alojamiento propio

Recupera los datos hasta cualquier momento concreto.

• La base de datos funciona con la copia de seguridad continua de MongoDB Atlas, con recuperación a un momento específico e instantáneas que se realizan a lo largo del día.
• La retención se realiza a diario, semanalmente y mensualmente.
• Las restauraciones se comprueban de forma periódica.
• Los objetivos de disponibilidad se establecen por contrato en función del nivel al que se destinan los fondos de implementación.

• Copia de seguridad puntual
• Instantáneas programadas
• Retención por niveles
• Restauraciones verificadas

Objetivos de gravedad, comprometidos por escrito.

• Los objetivos de gravedad y los plazos de respuesta se establecen en el acuerdo y se comprometen por escrito.
• La suscripción incluye mantenimiento, asistencia técnica y actualizaciones.
• Los informes de errores y las solicitudes de ayuda que se envían desde la aplicación pasan a la misma cola que un ticket.
• La documentación de autoservicio se mantiene al día junto con el producto.

• Objetivos de gravedad establecidos por escrito
• Mantenimiento incluido
• Informes dentro de la aplicación
• Documentación actualizada

Las versiones se comprueban antes de que lleguen a tus manos, y los resultados siguen siendo reproducibles posteriormente.

• Las publicaciones se verifican en rondas estructuradas y fechadas en toda la plataforma, el portal público y el sistema de contenidos.
• Cada ronda es de solo añadir: se realiza una comprobación, se añade una fila con fecha y no se modifican las anteriores. Un resultado sigue siendo reproducible meses después.
• Una norma por escrito que el equipo sigue.

• Rondas de verificación con fecha determinada
• Registros de solo adición
• Norma escrita

Diseñado según la norma AODA. El estado actual y los criterios pendientes se facilitan a petición.

• Se ejecuta un análisis automático en todas las páginas prerenderizadas de cada idioma, y un verificador de contraste estático comprueba los pares de primer plano y fondo.
• La Ley de Accesibilidad de Ontario (AODA), en virtud del Reglamento provincial 191/11, establece el nivel legal según las Pautas de Accesibilidad Web (WCAG) 2.0, Nivel AA. La plataforma se ha desarrollado y auditado según las WCAG 2.2, Nivel AA.
• El estado actual es de conformidad parcial. Los criterios pendientes se registran junto con lo que afecta cada uno y en qué fase se encuentra, y los resultados de la auditoría se facilitan a petición. Una declaración de conformidad firmada se entrega del mismo modo.

• AODA
• WCAG 2.2, Nivel AA
• Barridos automáticos

Las normas a las que debe ajustarse la construcción.

• Cumplimiento de las WCAG 2.2, nivel AA, en el marco de la AODA, en toda la plataforma, el portal público y el sistema de contenidos.
• La residencia de los datos la determina el lugar en el que se ejecuta la instancia. Residencia canadiense para las implementaciones canadienses.

• WCAG 2.2, Nivel AA
• Soberanía de los datos