Arquitectura técnica

Este documento ofrece una descripción general técnica de la plataforma AccessPoint para arquitectos de soluciones, ingenieros de ciberseguridad y directores de TI que evalúan el producto para su organización. Se basa en la Guía de Arquitectura de Soluciones de AccessPoint (v2.0.67).

Descripción general de la plataforma

AccessPoint es una plataforma de gestión de acceso a la información y privacidad construida sobre Microsoft 365 y Azure. Comenzó como una herramienta de gestión de solicitudes de acceso del interesado (SAR) y ha evolucionado hasta convertirse en una suite integrada de oficina de ATIP/privacidad que cubre todo el ciclo de vida de las solicitudes y el programa de privacidad en su conjunto. Se ejecuta enteramente dentro del propio inquilino de Microsoft 365 y Azure de su organización: no existen servidores externos, bases de datos ni dependencias de nube de terceros en tiempo de ejecución, y todos los datos permanecen en su entorno, bajo su control.

La plataforma está organizada en módulos que comparten un mismo eje de identidad, RBAC, notificaciones, auditoría e informes:

• Solicitudes de acceso — recepción de ATI/FOIA/GDPR, asignación de tareas a custodios, revisión y redacción de documentos, empaquetado de respuestas e informes estatutarios
• Evaluaciones de privacidad — un motor configurable de evaluaciones PIA/AIA/de seguridad
• Incidentes y vulneraciones de privacidad — recepción, contención, riesgo de daño y flujos de trabajo de notificación de vulneraciones
• Quejas y apelaciones — ciclo de vida de la queja con partes, plazos estatutarios e investigación
• Registro de riesgos de privacidad — riesgos de estilo ISO 31000, planes de tratamiento e indicadores clave de riesgo
• Registros de actividades de tratamiento (ROPA) — registros del artículo 30 del GDPR y exportación del registro
• Registro de compromisos — compromisos de privacidad rastreados con periodicidad y seguimientos
• Asistencia con IA (opcional) — sugerencias y generación de borradores respaldadas por Azure OpenAI que se ejecutan enteramente en la propia suscripción del cliente: resúmenes de documentos, sugerencias de tachado con IA, generación de borradores fundamentada, clasificación de recepción, prellenado de respuestas de evaluación, búsqueda semántica y detección de duplicados, un asistente por caso consciente del estatuto (Ask AccessPoint — citas en las que se puede hacer clic, conversaciones guardadas, un modo Mi carga de casos), respuestas de datos de «Ask AccessPoint», un manual de la jurisdicción que fundamenta las respuestas de procedimiento, traducción automática y un resumen diario — todo opcional por inquilino, registrado solo con metadatos, con divulgación de actividad de IA por registro

Todos los módulos se basan en paquetes de jurisdicción, sin datos semilla estáticos.

Características clave:

• Nativo del inquilino — se implementa como una solución de SharePoint Framework (SPFx) y servicios de Azure PaaS dentro de su inquilino existente
• Sin dependencias de Power Platform — no se requiere licenciamiento de Dataverse, Power Automate ni Power Apps
• Soberanía de datos — todos los datos residen en la geografía configurada del inquilino de Azure
• Sin acceso del proveedor en tiempo de ejecución — el editor no puede acceder a sus datos durante la operación normal
• Licenciamiento de tarifa plana — licenciamiento departamental sin medición por usuario
• Privacidad desde el diseño — los roles de custodio y colaborador están estructuralmente aislados de la información personal del solicitante y del interesado
• Configuración en lugar de código — los tipos de solicitud, los códigos de exención y los campos de selección están basados en datos
• Multilingüe desde el diseño — un sistema de traducción de tres niveles que admite 11 idiomas

Diagrama de arquitectura

Customer's Microsoft 365 Tenant          Customer's Azure Subscription
┌──────────────────────────────┐         ┌─────────────────────────────────────────┐
│                              │         │                                         │
│  SPFx Web Part               │         │  Azure App Service (Linux)              │
│  (SharePoint Online /        │──HTTPS──│  ASP.NET Core 10 Web API               │
│   Teams Personal App /       │  (JWT)  │    ├─ Entra ID JWT validation          │
│   Teams Tab)                 │         │    ├─ Role-based authorization          │
│                              │         │    ├─ PII filter middleware             │
│  Installed from AppSource    │         │    ├─ User upsert from JWT claims      │
│  or Tenant App Catalog       │         │    ├─ License validation middleware    │
│                              │         │    └─ Syncfusion document conversion   │
│                              │         │                                         │
│  SharePoint Tenant Storage   │         │  Azure SQL Database                     │
│  (API URL override,          │         │  (222 tables, 3,410 fields)            │
│   optional)                  │         │                                         │
└──────────────────────────────┘         │  Azure Blob Storage                     │
                                         │  (Document files)                       │
        Microsoft Graph API              │                                         │
        ┌──────────────────────┐         │  Application Insights + Log Analytics   │
        │  Mail.Send           │◄────────│  (Telemetry, diagnostics)               │
        │  User.ReadBasic.All  │         │                                         │
        │  TeamsActivity.Send  │         │  (opt-in) Azure AI Search               │
        │  TeamsAppInstall     │         │  (opt-in) Azure OpenAI                  │
        │  Calendars.Read      │         │  (opt-in) Azure Document Intelligence   │
        │  AiEnterprise…Read   │         └─────────────────────────────────────────┘
        └──────────────────────┘  ← M365 record capture (delegated + app-only Copilot)

Inventario de componentes

Componente	Tecnología	Implementado en	Finalidad
Componente web de SPFx	TypeScript, React 17, Fluent UI 8, SPFx 1.23.2	SharePoint Online / Teams del cliente	Interfaz de usuario para todos los roles
Aplicación de Teams	Manifiesto de Teams v1.19, en sincronía de versión con la solución SPFx y ApiVersion.Current (sellado por CI)	Centro de administración de Teams del cliente	Aplicación personal, pestaña configurable, notificaciones de fuente de actividad con vínculos profundos
API web	C# / ASP.NET Core 10, .NET 10 (~103 controladores, ~124 interfaces de servicio)	Azure App Service (Linux) del cliente	Lógica de negocio, acceso a datos, procesamiento de documentos
Base de datos	SQL Server (DacPac)	Azure SQL Database del cliente	Almacén de datos relacional (221 tablas, 3410 campos)
Blob Storage	Azure Blob Storage	Cuenta de Azure Storage del cliente	Almacenamiento de archivos de documentos
Monitoreo	Application Insights + Log Analytics	Suscripción de Azure del cliente	Telemetría, diagnóstico, alertas
AI Search (opcional)	Azure AI Search	Suscripción de Azure del cliente	Búsqueda de texto completo en el contenido de documentos, además de búsqueda vectorial semántica (índice de documentos + casos); se aprovisiona solo cuando deployAiSearch=true
Azure OpenAI (opcional)	Azure OpenAI Service	Suscripción de Azure del cliente	Asistencia con IA — generación de borradores fundamentada, sugerencias, búsqueda semántica, asistente del caso (Ask AccessPoint); autenticación de identidad administrada (sin claves de API), se aprovisiona solo cuando se implementa Asistencia con IA
Document Intelligence (opcional)	Azure AI Document Intelligence (prebuilt-read)	Suscripción de Azure del cliente	OCR para escaneos solo con imagen que alimenta la búsqueda de contenido, la detección de duplicados, los resúmenes y las sugerencias de tachado; autenticación de identidad administrada, se aprovisiona solo cuando deployDocumentIntelligence=true

Qué opera el editor

Servicio	Finalidad
Realizer Platform	Validación de licencia, proxy de notificaciones de Teams, descubrimiento de la URL de la API de SPFx, el enrutador inteligente de la pestaña personal de Teams y la página Finalizar instalación posterior a la implementación (no se transmiten datos de casos del cliente)
Publicación en AppSource	Distribución del paquete SPFx
Plantilla de implementación	Plantilla Bicep/ARM para el backend de Azure, implementada con un clic desde el portal de Azure en la suscripción del cliente
Paquete de la aplicación de Teams	Distribución del manifiesto de Teams (carga lateral o tienda de aplicaciones de la organización)

Ningún dato del cliente se transmite ni se almacena en ningún servicio operado por el editor.

Módulos funcionales

Todos los módulos se ejecutan dentro de la misma API web / componente web de SPFx y comparten un mismo eje de identidad, RBAC, comentarios, notificaciones, Mi Día, auditoría, horas, flujo de trabajo de revisión e informes. Cada uno está basado en datos mediante Paquetes de Jurisdicción.

Módulo	Resumen
Solicitudes (ATIP/SAR)	Recepción de solicitudes → asignación de tareas a custodios → recopilación → respuesta. Tipos, estados, numeración, calendarios y SLA configurables.
Documentos y redacción	Espacio de trabajo de documentos por facetas: etiquetas, carpetas, familias de correo electrónico, seguimiento de lectura, vistas guardadas, detección de duplicados basada en decisiones, vista previa de Syncfusion, canal de redacción con exenciones e ida y vuelta XFDF, patrones de buscar y tachar, sugerencias de tachado basadas en reglas y con IA, reutilización de tachados de solicitudes anteriores, empaquetado de respuestas con combinación de membrete.
Solicitantes / Contactos	Identidad reutilizable de solicitante de primera clase, control del flujo de recepción, espacio de trabajo de conducta frívola y vejatoria, tarifas y verificación, fusión; consultas; redactor de correspondencia con firewall de información personal.
Evaluaciones de privacidad	Motor configurable de PIA/AIA/evaluación de seguridad: plantillas, cuestionarios de detección, asignación de secciones, puntuación/niveles, registro de riesgos, resúmenes de cierre/regulador.
Incidentes de privacidad / vulneraciones	Recepción de incidentes, contención, riesgo de daño, reglas de notificación de vulneraciones por régimen, remediación.
Quejas y apelaciones	Ciclo de vida de la queja: partes, plazos estatutarios, admisibilidad, investigación, revisión de alegatos.
Riesgos y compromisos	Registro de riesgos ISO 31000 con apetito de riesgo, KRI y tareas de tratamiento; registro de compromisos con periodicidad y seguimientos.
ROPA / Sujetos de privacidad	Programas/sistemas reutilizables con registros del artículo 30 del GDPR y exportación del registro.
Revisiones	Motor configurable de revisión y aprobación secuencial/paralelo, reutilizado en todas las entidades de casos.
Informes y auditoría	Informes fijos, editor de informes personalizados basado en catálogo (paneles de Report Studio), informes estadísticos anuales, paneles de SLA/gestión, libro mayor de auditoría encadenado por hash y exportaciones de auditoría del caso listas para uso judicial.
Asistencia con IA (opcional)	Sugerencias y generación de borradores respaldadas por Azure OpenAI: resúmenes, sugerencias de tachado, generación de borradores fundamentada, clasificación de recepción, sugerencias para custodios, prellenado y comprobaciones de coherencia de evaluaciones, búsqueda semántica y duplicados, un asistente del caso consciente del estatuto — Ask AccessPoint (citas en las que se puede hacer clic, preparación de borradores, conversaciones guardadas) — además de un asistente de cartera/Mi carga de casos, un manual de la jurisdicción sembrado por los paquetes de jurisdicción, informes de Ask AccessPoint, resumen diario y boletín de puesta al día, cartera de riesgos y análisis de conducta. Interruptores por función y por inquilino; registro solo con metadatos (el asistente puede además guardar transcripciones privadas del propietario).
Configuración y plataforma	Importación de paquetes de jurisdicción (1 paquete Universal Baseline + 106 paquetes de jurisdicción, incluidos los estados automáticos de denegación presunta con alcance por tipo y la fundamentación de IA opcional), configuración del inquilino, roles/permisos personalizados, conmutadores de funciones, campos personalizados, tablas de traducción de 11 idiomas.

Modelo de implementación

AccessPoint utiliza un modelo de implementación dividido. El componente web de SPFx se instala desde Microsoft AppSource (o un Catálogo de aplicaciones del inquilino), el paquete de la aplicación de Teams se instala mediante carga lateral o la tienda de aplicaciones de la organización, y el backend de Azure se implementa en la propia suscripción del cliente mediante uno de dos métodos:

• Azure Portal (recomendado) — implementación con un clic de todos los recursos de Azure (App Service, SQL, Blob Storage, Application Insights, además de los recursos opcionales de AI Search / Azure OpenAI / Document Intelligence) mediante ARM/Bicep. La API se implementa mediante zipdeploy durante la implementación de ARM; el código se descarga una vez desde la CDN del editor y se almacena en el App Service del cliente, sin dependencia externa en tiempo de ejecución. Una elección obligatoria de tipo de implementación protege las reimplementaciones: Nueva instalación crea el servidor SQL con prioridad Entra (el principal que realiza la implementación se convierte en el administrador inicial de Entra, con autenticación exclusiva de Entra desde el origen — nunca existe ninguna credencial de SQL), mientras que Actualizar instalación existente conserva la configuración de aplicación del operador y no toca el acceso a la base de datos. El cliente conserva la propiedad completa del grupo de recursos.
• Plantilla Bicep + script de PowerShell (manual) — para organizaciones con control de cambios estricto. Un botón Deploy to Azure o el script Deploy-AccessPoint.ps1 implementa la infraestructura, reafirma la autenticación exclusiva de Entra en SQL (una salvaguarda: la plantilla ya la aplica), concede permisos de Microsoft Graph a la identidad administrada (la alternativa con script a la página Finalizar instalación del editor), configura la anulación opcional de la URL de la API mediante entidad de almacenamiento de SharePoint, y aprueba las solicitudes de permisos de API de SPFx. Cada paso se puede omitir de forma independiente.

Los permisos de Graph normalmente se conceden a través de la página Finalizar instalación del editor: la implementación emite una salida finishSetupUrl que un administrador de Entra del cliente abre para conceder cada permiso de identidad administrada en un único pase idempotente (se vuelve a ejecutar después de las actualizaciones para incorporar nuevos permisos).

La implementación está reforzada en materia de seguridad de forma predeterminada: TLS 1.3, FTPS deshabilitado, autenticación básica de SCM/FTP deshabilitada, HTTP/2 habilitado y Microsoft Defender for SQL activado de forma predeterminada (con opción de exclusión). La API incluye su DacPac de base de datos y lo aplica al iniciar mediante un servicio de migración que utiliza DacServices.Deploy(upgradeExisting: true); no realiza ninguna operación en un esquema ya actualizado, y aplica un delta aditivo y no destructivo tras un cambio de esquema (BlockOnPossibleDataLoss = true, DropObjectsNotInSource = false). El resultado de la migración se expone a través de /api/health. Después de la implementación, un administrador otorga consentimiento para la aplicación empresarial de Realizer (notificaciones de Teams), configura el buzón de envío e importa un paquete de jurisdicción.

Autenticación e identidad

AccessPoint utiliza Microsoft Entra ID como único proveedor de identidad. No existen cuentas de usuario ni contraseñas específicas de la aplicación. El componente web de SPFx obtiene un JWT para la audiencia de la API mediante AadHttpClient; la API valida el emisor, la audiencia, la firma y la caducidad en cada solicitud. Las políticas de MFA y acceso condicional configuradas en el inquilino se aplican en su totalidad.

User (Browser)                SharePoint Online           AccessPoint API
     │                              │                          │
     │  1. Load SPFx web part       │                          │
     │─────────────────────────────►│                          │
     │                              │                          │
     │  2. AadHttpClient.getClient()│                          │
     │  (SPFx acquires token for    │                          │
     │   api://<client-id> audience)│                          │
     │                              │                          │
     │  3. API call + Bearer token  │                          │
     │──────────────────────────────┼─────────────────────────►│
     │                              │                          │
     │                              │  4. Validate JWT:        │
     │                              │     - Issuer (Entra ID)  │
     │                              │     - Audience (api://)  │
     │                              │     - Signature          │
     │                              │     - Expiry             │
     │                              │                          │
     │                              │  5. UserUpsertMiddleware: │
     │                              │     Extract claims →     │
     │                              │     Upsert Users table   │
     │                              │                          │
     │                              │  6. PermissionService:   │
     │                              │     resolve roles +      │
     │                              │     permission grants    │
     │                              │                          │
     │     ◄── JSON response ───────┼──────────────────────────│

Parámetro	Valor
Proveedor de identidad	Microsoft Entra ID (Azure AD)
Protocolo	OAuth 2.0 / OpenID Connect
Tipo de token	JWT Bearer
Audiencia	api://<client-id> y <client-id> (se aceptan tokens v1 y v2)
Emisor	El emisor de cualquier inquilino de Entra — se validan los formatos https://login.microsoftonline.com/{tenantId}/v2.0 (v2) y https://sts.windows.net/{tenantId}/ (v1); la reclamación tid del token determina el alcance por inquilino
Registro de aplicación	Aplicación multiinquilino operada por el editor, consentida por cada inquilino de cliente (sin registro de aplicación por cliente que gestionar ni rotar); ámbito expuesto access_as_user; sin secreto de cliente. El aislamiento entre inquilinos de cliente se aplica mediante la reclamación tid validada más una comprobación de licencia/suscripción

Identidad administrada

El App Service utiliza una identidad administrada asignada por el sistema para autenticarse ante los servicios de backend, de modo que no se almacenan secretos de cliente ni certificados en la aplicación:

• Azure SQL Database — autenticación exclusiva de Entra (el servidor se crea con prioridad Entra; nunca existe ninguna credencial de SQL)
• Azure Blob Storage — DefaultAzureCredential (identidad administrada en producción)
• Microsoft Graph API — ManagedIdentityCredential con permisos de aplicación
• Recursos de IA opcionales (AI Search, Azure OpenAI, Document Intelligence) — exclusivamente con identidad administrada, con la autenticación local/por clave deshabilitada

Azure rota automáticamente las credenciales de identidad administrada.

Autorización y RBAC

AccessPoint implementa un modelo de permisos granular y configurable por inquilino, almacenado en Azure SQL y aplicado en la capa de la API en cada solicitud: un catálogo de códigos de permiso atómicos definido por el producto (por ejemplo, request.modify, document.view, redaction.approve, request.view.pii) se agrupa en roles, y cada acción del controlador está condicionada a un código de permiso.

Tipo de rol	Roles	Notas
Rol de sistema	Administrador (el único rol permanente integrado)	Resuelve con todos los permisos del catálogo — calculado a partir del catálogo, no sembrado en la base de datos — de modo que nunca puede quedar bloqueado; inmutable e imposible de eliminar.
Roles de relación	Revisor, Custodio, Colaborador, Lector, Asesor	Paquetes de permisos definidos por el producto, conferidos automáticamente y por destino según las relaciones de trabajo/colaboración (asignación de custodio, tarea de colaborador, revisión, membresía de asesor/lector). No son asignables directamente, están limitados al registro relacionado y nunca incluyen la PII del solicitante.
Roles de inquilino	por ejemplo, Coordinador de solicitudes (incluido en el paquete Universal Baseline), además de cualquier rol personalizado	Paquetes de permisos totalmente editables, gestionados en Configuración > Roles y permisos. Los roles de coordinador/oficial los define enteramente el inquilino — el Coordinador de solicitudes incluido en el paquete es el rol de facto de oficial de acceso y privacidad.

Rol	Ve la PII del solicitante	Acceso típico	Usuario típico
Administrador	Sí	Todo (todos los permisos del catálogo)	Administrador de TI, propietario del sistema
Coordinador de solicitudes (rol de inquilino)	Sí	Gestiona solicitudes, asignaciones, tachados, correspondencia	Funcionario de acceso y privacidad
Revisor	No	Lectura + señalar/resolver inquietudes de tachado en solicitudes en revisión	Asesor jurídico, control de calidad
Asesor	No	Lectura + ver/señalar tachados (nunca aplicar ni aprobar)	Asesor externo, experto en la materia
Custodio	No	Sus propias asignaciones y sus documentos	Funcionario de registros del departamento
Colaborador	No	Sus propias tareas y sus documentos	Experto en la materia
Lector	No	Solo lectura en las solicitudes asociadas y los documentos compartidos	Supervisión, auditoría

Puntos de aplicación:

1. Atributos [RequirePermission(code)] — un proveedor de políticas dinámico asigna cada acción del controlador a un código de permiso del catálogo
2. PermissionService — resuelve los permisos efectivos de quien realiza la llamada (roles permanentes unidos a las concesiones de relación por destino), con comprobaciones limitadas por objeto a nivel de solicitud/documento/asignación/tarea
3. Comprobaciones de titularidad a nivel de recurso — por ejemplo, un Colaborador solo puede acceder a sus propias tareas; un Custodio, solo a sus propias asignaciones
4. PiiFilterMiddleware — elimina los campos de PII del solicitante de las respuestas JSON para cualquier usuario que no tenga el permiso de ver la PII del solicitante

Todos los puntos de conexión de escritura de la API aplican los permisos del lado del servidor a nivel de controlador. La reclasificación de documentos tiene en cuenta el alcance — quien recopiló un documento es quien puede reclasificarlo —, y una vez cerrada una solicitud, las modificaciones en su grafo de objetos devuelven HTTP 409, con un pequeño conjunto de excepciones deliberadas (correspondencia posterior al cierre, depuración por retención y reapertura). Las asignaciones de roles permanentes tienen un alcance definido (global, de solicitud, de asignación o de tarea), pueden tener una duración limitada de forma opcional, y los roles de relación nunca se escriben como asignaciones permanentes: se derivan por destino a partir de los registros de trabajo subyacentes. Al primer usuario que accede al sistema se le asigna de forma inicial el rol de Administrador, y una salvaguarda del lado del servidor impide eliminar al último Administrador activo.

Residencia y soberanía de datos

Todos los datos residen en el inquilino de Azure del cliente, en la región seleccionada durante la implementación. Ningún dato se transmite ni se almacena en otras regiones, a menos que el cliente configure explícitamente la replicación geográfica de Azure.

Departamentos federales canadienses: para conocer los requisitos de residencia de datos específicos del GC, la asignación de controles ITSG-33 y el cumplimiento de las GC Cloud Guardrails, consulte la Referencia de controles de seguridad de GC.

Ubicaciones de los datos del cliente

Tipo de datos	Ubicación de almacenamiento	Controlado por
Registros de solicitudes, datos de usuario, registro de auditoría	Azure SQL Database	Suscripción de Azure del cliente
Documentos cargados	Azure Blob Storage	Suscripción de Azure del cliente
Telemetría de la aplicación	Application Insights / Log Analytics	Suscripción de Azure del cliente
Activos del componente web de SPFx	CDN de SharePoint	Inquilino de M365 del cliente
Anulación de la URL de la API (opcional)	Entidad de almacenamiento del inquilino de SharePoint	Inquilino de M365 del cliente (el descubrimiento principal es el punto de conexión de descubrimiento de API del editor)
Índices de búsqueda de IA, resúmenes, salida de OCR (opcional)	Azure AI Search / Azure SQL	Suscripción de Azure del cliente

Qué cruza los límites del inquilino

Flujo de datos	Dirección	Qué se transmite	Finalidad
Validación de licencia	API → Plataforma del editor	Token de identidad administrada de Entra (la reclamación tid del token identifica al inquilino), versión de la API y la propia URL base de la API (autorregistro para el descubrimiento del elemento web)	Validar la suscripción activa; la respuesta también incluye la última versión publicada de AccessPoint, de modo que el panel de Configuración inicial pueda mostrar un aviso de "Actualización disponible" (solo números de versión, sin datos de uso ni de casos)
Descubrimiento de la URL de la API	SPFx → Plataforma del editor	Token Bearer (solo la reclamación de ID de inquilino)	Resolver la URL base de la API del cliente cuando no se ha establecido una anulación por entidad de almacenamiento
Notificaciones por correo electrónico	API → Microsoft Graph	Contenido de correo electrónico mediante Mail.Send	Enviar notificaciones desde el buzón compartido
Notificaciones de Teams (opcional — se puede minimizar/eliminar)	API → Plataforma del editor → Microsoft Graph	Tipo de actividad, GUID del destinatario y del inquilino, texto del título/vista previa de la notificación, nombre del usuario que realiza la acción, número de solicitud, ID del registro (vínculo profundo)	Enviar notificaciones de fuente de actividad de Teams (mediante proxy a través de la aplicación empresarial multiinquilino del editor porque sendActivityNotification debe ser llamado por la aplicación propietaria del manifiesto de Teams). Este es el único canal de notificación que sale del inquilino — el correo electrónico y el feed integrado entregan los mismos avisos dentro del inquilino. Consulte Uso compartido de datos de notificación de Teams
Búsqueda de perfil de usuario	SPFx → Microsoft Graph	Consultas de búsqueda de usuarios	Selector de personas, resolución de usuarios

Qué nunca sale del inquilino

• Los registros de solicitudes y la información personal del solicitante
• Los documentos cargados
• El historial de auditoría
• Los datos de configuración (tipos de solicitud, plantillas, numeración)
• Las asignaciones de roles
• Las indicaciones y las respuestas de Asistencia con IA: cuando Asistencia con IA está implementada, el recurso de Azure OpenAI se ejecuta en la propia suscripción y región del cliente; Microsoft no entrena modelos con el contenido, y el contenido de las indicaciones y las respuestas no se almacena (solo los metadatos de uso, para el medidor de presupuesto y la divulgación de la participación de la IA de la exportación de auditoría del caso)
• Las notificaciones integradas en la aplicación y por correo electrónico/Outlook — el feed integrado se sirve desde la propia API del cliente; el correo electrónico se envía desde el propio buzón compartido del cliente mediante Mail.Send. Ninguna de las dos transita por el editor. Solo la fuente de actividad de Teams, que es opcional, envía algún dato fuera del inquilino, y eso también se puede minimizar o eliminar (véase más abajo)

Uso compartido de datos de notificación de Teams (opcional)

De acuerdo con la promesa de soberanía de datos, el único dato del inquilino que sale del límite para las notificaciones es una carga útil opcional de actividad de Teams, y se puede minimizar o eliminar por completo. Cada notificación se entrega en hasta tres canales; dos siempre permanecen dentro del inquilino (el feed integrado, servido desde la API del cliente, y el correo electrónico/Outlook, enviado desde el propio buzón compartido del cliente). La fuente de actividad de Teams es una comodidad: en su modo predeterminado, la API del cliente envía (POST) una pequeña carga útil a la aplicación multiinquilino del editor, que llama a Graph sendActivityNotification (que debe ser invocado por la aplicación propietaria del manifiesto de Teams). El editor no almacena nada de eso y solo registra los GUID del destinatario y del inquilino.

Campos en la carga útil predeterminada de Teams (retransmitida por el editor) y lo que elimina el interruptor Minimizar:

Campo	Contiene	¿Datos personales?	¿Se elimina con Minimizar?
tenantId / recipientUserId	GUID de Entra del inquilino y del destinatario	No — identificadores	No (enrutamiento)
activityType	Enumeración fija del manifiesto (por ejemplo, assignmentCreated)	No	No
previewText / topicText	Vista previa y título (nombre de la asignación/tarea, texto de la notificación)	Potencialmente (texto libre)	Sí → marcador de posición
actorName	Nombre para mostrar del miembro del personal que realiza la acción	Sí — nombre personal	Sí → "AccessPoint"
requestNumber	Código de referencia de la solicitud	No — referencia	No (contexto)
relatedEntity + relatedRecordId	Tipo de registro + GUID (vínculo profundo)	No — identificadores	No (vínculo profundo)

La PII del solicitante nunca está en la carga útil — no existe ningún campo de nombre/correo electrónico del solicitante, y las notificaciones a Custodios/Colaboradores tienen la PII oculta desde el origen en cualquier caso. Dos controles restringen esto aún más:

• Minimizar (Notifications:TeamsMinimalPayload, un interruptor de inquilino) reemplaza previewText, topicText y actorName con marcadores de posición neutros, de modo que los nombres, los títulos y el texto libre nunca salen del inquilino — solo lo hacen los identificadores de enrutamiento/vínculo profundo. No se requiere ningún cambio en el manifiesto.
• Eliminar (Notifications:TeamsRelayMode=Direct) hace que la API del cliente llame ella misma a Graph sendActivityNotification con su identidad administrada, de modo que ninguna carga útil llega al editor. Requiere el rol de aplicación TeamsActivity.Send en la identidad administrada de la API y que el webApplicationInfo.id del manifiesto de Teams apunte a la propia aplicación del cliente; consulte la Guía de implementación.

Modo	Carga útil al editor	La PII/el texto libre sale del inquilino	Esfuerzo de configuración
Retransmisión predeterminada	Sí (los campos anteriores)	Nombres/títulos, a menos que se minimice	Ninguno
Interruptor Minimizar	Sí (solo identificadores)	Ninguno	Un interruptor
Retransmisión directa (autoalojada)	Ninguna	Ninguno	Concesión de identidad administrada + edición del manifiesto
Teams deshabilitado	Ninguna	Ninguno (solo correo electrónico + integrado)	Ninguno

Cifrado

En tránsito

Conexión	Protocolo	TLS mínimo
Navegador → App Service	HTTPS (aplicado, httpsOnly: true)	TLS 1.3
SPFx → App Service	HTTPS (aplicado por el contexto de SharePoint)	TLS 1.3
App Service → Azure SQL	TDS con cifrado (Encrypt=True)	TLS 1.2+
App Service → Blob Storage	HTTPS (identidad administrada)	TLS 1.2+
App Service → Microsoft Graph	HTTPS	TLS 1.2+

El App Service aplica TLS 1.3 como mínimo en la puerta de enlace (se rechazan TLS 1.0/1.1/1.2); las conexiones salientes a los servicios de backend de Azure negocian TLS 1.2 o superior.

En reposo

Almacén de datos	Cifrado	Gestión de claves
Azure SQL Database	Cifrado transparente de datos (TDE)	Claves administradas por Microsoft (predeterminado) o claves administradas por el cliente (CMK)
Azure Blob Storage	Cifrado del servicio de almacenamiento (SSE), AES-256	Claves administradas por Microsoft (predeterminado) o claves administradas por el cliente (CMK)
Application Insights	Cifrado de la plataforma	Claves administradas por Microsoft

A nivel de aplicación

Función	Mecanismo
Tokens del visor de documentos	ASP.NET Core Data Protection (token de estilo WOPI, TTL de 15 minutos, verificación cruzada de inquilino en cada llamada anónima al visor)
Firmas electrónicas de certificación	Hash SHA-256 del firmante y la marca de tiempo, almacenado en campos de auditoría

Privacidad desde el diseño

AccessPoint implementa controles de privacidad estructurales que se aplican en la capa de la API, no solo en la interfaz de usuario.

Middleware de filtrado de información personal

Un middleware a nivel de respuesta intercepta todas las respuestas JSON y elimina los campos de información personal para los usuarios con roles restringidos (custodio, colaborador, lector), del lado del servidor, independientemente de lo que solicite el cliente. Campos eliminados: requestorName, requestorEmail, requestorPhone, requestorAddress, subjectName, subjectDateOfBirth, además de los campos de identidad/contacto del representante y las notas de verificación de identidad.

Ocultamiento de información personal en notificaciones

Cuando se envían notificaciones a custodios o colaboradores, la información personal del solicitante se reemplaza por texto de marcador de posición en el propio contenido de la notificación, incluso si la plantilla de notificación incluye campos de combinación de información personal.

Aislamiento de custodios / colaboradores

• Los custodios solo ven sus solicitudes asignadas y trabajan a partir de instrucciones depuradas
• Los colaboradores solo ven sus tareas asignadas
• Ningún rol puede buscar, explorar ni acceder a solicitudes fuera de su alcance

Registro, monitoreo y auditoría

Application Insights

Toda la telemetría de la API se envía a la instancia de Application Insights del cliente:

Señal	Qué se captura
Trazas de solicitudes	Método HTTP, ruta, código de estado, duración, ID de correlación
Seguimiento de dependencias	Consultas SQL, operaciones de Blob, llamadas a la API de Graph (duración, éxito/error)
Excepciones	Excepciones no controladas con seguimientos de pila
Métricas personalizadas	Tiempos de procesamiento de solicitudes, duraciones de conversión de documentos

Registro de auditoría

AccessPoint mantiene un registro de auditoría integral en la tabla AuditHistory (Azure SQL), que registra el tipo de entidad, el ID de entidad, la acción (Crear, Actualizar, Eliminar, Cambio de estado), el nombre del campo, los valores anteriores/nuevos, un motivo de cambio opcional (capturado en las transiciones de estado como el cierre y la reapertura), el usuario autenticado y una marca de tiempo UTC. Los registros de auditoría son inmutables: no se pueden modificar ni eliminar a través de la API.

Libro mayor de auditoría encadenado por hash

Además del registro de auditoría a nivel de campo, un AuditLedger de solo adición y a prueba de alteraciones (cadena de hash SHA-256) registra las acciones en todos los módulos. La integridad se puede verificar del lado del servidor, y se puede generar una exportación de auditoría del caso (anteriormente «paquete de evidencia») lista para uso judicial para una solicitud.

Concurrencia optimista

Las entidades de alta contención (Requests, Documents, CustodianAssignments) llevan cada una un token de concurrencia ROWVERSION de SQL Server. El cliente repite la versión de fila al actualizar; si otro proceso de escritura ha modificado la fila mientras tanto, el guardado se rechaza con HTTP 409 ("Concurrent edit detected") en lugar de sobrescribirlo silenciosamente.

Registro de depuración por retención

Un único motor RetentionService dispone de los registros que han superado su plazo en cinco registros: solicitudes, evaluaciones, incidentes, quejas y riesgos de privacidad independientes, impulsado por un RetentionPeriodMonths + RetentionStartPoint por tipo (NULL = conservar indefinidamente, el valor predeterminado). Los registros que no deben superar su plazo quedan excluidos por construcción (una evaluación En vigor, un riesgo Aceptado, un riesgo vinculado a un caso), y un registro expirado del que todavía depende otro caso abierto se rechaza del lado del servidor; la elegibilidad se vuelve a evaluar en el momento de la purga. Cuando se purga un registro, el motor elimina los blobs de documentos, los PDF convertidos, las anotaciones y los paquetes de exportación de Blob Storage, además de los registros de la base de datos. La tabla RetentionPurgeLog registra qué se eliminó, cuándo y por quién — EntityName identifica de qué registro proviene, junto con una instantánea de su número, tipo, fecha de cierre y cantidad de documentos —, un rastro de nivel de cumplimiento que sobrevive a la eliminación de los datos y que nunca se purga a sí mismo.

Log Analytics y alertas

Application Insights está respaldado por un área de trabajo de Log Analytics con retención configurable (90 días de forma predeterminada; configurable entre 30 y 730 días). Los datos se pueden exportar a Microsoft Sentinel o a un SIEM existente. La implementación de Bicep incluye dos alertas de métricas predeterminadas en el App Service:

Alerta	Gravedad	Condición	Ventana
Errores del servidor	2 (Advertencia)	Recuento de HTTP 5xx > 5	5 minutos
Latencia alta	3 (Informativo)	Tiempo de respuesta promedio > 5 segundos	15 minutos

Los clientes pueden personalizar los umbrales y agregar grupos de acción (correo electrónico, SMS, webhook) en Azure Portal.