Förifylld PIA-mall i linje med TBS Directive on Privacy Impact Assessment för kanadensiska federala myndigheter som inför AccessPoint
Last updated: August 06, 2026 by Steve
GC:s integritetskonsekvensbedömning (PIA)
Denna sida är en offentlig sammanfattning av integritetskonsekvensbedömningen (Privacy Impact Assessment, PIA) som utarbetats av programvaruutgivaren (Realizer Services Inc.) för AccessPoint, i linje med Treasury Board of Canada Secretariats (TBS) Directive on Privacy Impact Assessment. Den dokumenterar innehav av personuppgifter, informationsflöden, integritetsrisker och skyddsåtgärder inbyggda i produkten.
Utgivarens PIA täcker de tekniska och arkitektoniska avsnitten och är avsedd att hjälpa kanadensiska federala institutioner att färdigställa sin egen PIA. Den implementerande institutionen fyller i de institutionella detaljerna (institutionell översikt, bevarandescheman, avtal om informationsdelning och godkännande) och lämnar in den färdigställda PIA:n till TBS och Office of the Privacy Commissioner (OPC). Den fullständiga PIA:n finns tillgänglig för kunder på begäran — se den avslutande anmärkningen.
För den fullständiga tekniska arkitekturen, se sidan Teknisk arkitektur. För kartläggning av ITSG-33-säkerhetskontroller, se sidan Referens för GC-säkerhetskontroller.
Syfte och omfattning
AccessPoint är en plattform för hantering av tillgång till information och integritet som hjälper myndighetsinstitutioner att administrera program för tillgång till information och integritet i enlighet med Access to Information Act (ATIA), Privacy Act och motsvarande provinsiella/internationella regelverk. Dess primära funktion är hantering av subject access-/tillgång till information-förfrågningar – hela livscykeln från mottagande genom tilldelning, dokumentinsamling, granskning, maskering och paketering av svar.
Utöver förfrågningshantering stöder AccessPoint även det omgivande integritetsprogrammet: integritetskonsekvensbedömningar (PIA/AIA/säkerhetsbedömningar), hantering av integritetsincidenter och personuppgiftsincidenter (inklusive arbetsflöden för anmälan om personuppgiftsincidenter), klagomål och överklaganden, ett riskregister för integritetsfrågor och register över åtaganden, samt register över behandling (ROPA). Dessa moduler behandlar ytterligare kategorier av personuppgifter och omfattas av samma skyddsåtgärder, roller, granskningsliggare och garantier för dataresidens som kärnan för förfrågningshantering.
Affärsprocess: mottagande (en SAO skapar förfrågan) → tilldelning (förvaltare får sanerade instruktioner utan den sökandes personuppgifter) → dokumentinsamling → granskning och maskering → paketering av svar → avslutning (bevarandeklockan börjar).
Berörda individer: sökande; institutionens anställda (SAO:er, administratörer) vars handlingar registreras i granskningsspåret; förvaltare och medarbetare (som inte har tillgång till den sökandes personuppgifter); tredje parter vars personuppgifter kan förekomma i dokument under granskning; registrerade som beskrivs på kategorinivå i ROPA och bedömningar; individer som berörs av en integritetsincident; klagande och parter i klagomål; samt samrådskontakter.
Rättslig grund: insamling och användning vilar huvudsakligen på ATIA (avsnitt 4, 6, 9, 19) och Privacy Act (avsnitt 4, 5, 7, 8(2)(m), samt individens rätt till tillgång).
Inventering av personuppgifter
Insamlade och behandlade personuppgifter
| Dataelement | Känslighet | Källa | Syfte | Lagras i |
|---|---|---|---|---|
| Sökandes fullständiga namn | Medel | Sökande (via mottagande) | Identifiera sökande, korrespondens | Azure SQL |
| Sökandes e-postadress | Medel | Sökande | E-postkorrespondens | Azure SQL |
| Sökandes postadress | Medel | Sökande | Postleverans av svar | Azure SQL |
| Sökandes telefonnummer | Låg-medel | Sökande | Telefonkorrespondens | Azure SQL |
| Sökandes organisation | Låg | Sökande | Statistisk rapportering | Azure SQL |
| Beskrivning av förfrågan | Medel | Sökande | Definiera sökningens omfattning | Azure SQL |
| Personens namn | Medel-hög | Sökande (via mottagande) | Identifiera den person förfrågan avser (kan skilja sig från den sökande) | Azure SQL |
| Personens födelsedatum | Hög | Sökande (via mottagande) | Identitetsverifiering för integritetsförfrågningar | Azure SQL |
| Anställdas namn, e-postadresser, Entra-objekt-ID:n | Låg | Entra ID | Användaridentifiering, aviseringar, autentisering, granskning | Azure SQL |
| Granskningsspår (användarhandlingar) | Låg-medel | Systemgenererat | Ansvarighet, efterlevnad | Azure SQL |
| Dokument under granskning | Potentiellt hög | Institutionens handlingar | Förberedelse av ATIA-svar | Azure Blob Storage |
| Maskerade dokumentversioner | Medel | Systemgenererat | Paketering av svar | Azure Blob Storage |
| Intygandeposter och e-signaturer (maskinskrivet namn) | Låg-medel | Förvaltare | Formellt godkännande av fullständighet | Azure SQL |
| IP-adresser och user agent-strängar (intygande, dokumentåtkomst) | Låg-medel | Systemregistrerat | Forensisk granskning av signerings-/åtkomstkontext | Azure SQL |
| Sökandekorrespondens | Medel | SAO-personal | Korrespondensregister (riktning, metod, datum, anteckningar) | Azure SQL |
| Delegeringsposter | Låg-medel | SAO/administratör | Delegering av handläggaransvar | Azure SQL |
| Samrådsposter och kontaktkatalog | Låg-medel | SAO-personal | Interdepartementalt eller externt samråd | Azure SQL |
| Kontaktkatalog för sökande | Medel | Sökande/mottagningspersonal | Återanvändbar identitet för sökande; förfrågan länkas till en kontakt i stället för att lagra personuppgifter direkt | Azure SQL |
| Sökandens uppförandelogg | Medel | ATIP-personal/systemgenererat | Tillägg-endast, daterade, attribuerade uppförandeobservationer och granskningsutfall — den bevisbärande dokumentationen bakom en bedömning om grundlöst eller trakasserande beteende. Poster redigeras aldrig; borttagning är endast tillgängligt för Administrator och granskningsloggas | Azure SQL |
| Analysmemo för sökandens uppförande | Medel | ATIP-personal (valfritt AI-utkast, granskat av människa) | Skriftlig analys som stödjer eller avstyrker en F&V-bedömning; kan renderas som en formell PDF-post | Azure SQL/Azure Blob Storage |
| Kontakter i leverantörsregistret | Låg-medel | Integritetspersonal | Affärskontaktuppgifter för tredjeparts personuppgiftsbiträden/leverantörer, tillsammans med fakta om DPA/avtal och granskningsintervall | Azure SQL |
| Detaljer om personuppgifter berörda av incident | Potentiellt hög | Integritets-/ATIP-personal | Incidentfakta, kategorier av berörda personuppgifter, skadebedömning, spårning av anmälan om personuppgiftsincident | Azure SQL |
| Parter i klagomål och korrespondens | Medel | Integritets-/ATIP-personal | Identitet för klagande/part och klagomålshantering | Azure SQL |
| Kategorier för register över behandling (ROPA) | Låg-medel | Integritetspersonal | GDPR Article 30-beskrivningar per kategori av registrerad/mottagare — inte enskilda poster | Azure SQL |
| Svar på bedömningsfrågeformulär | Låg-medel | Integritetspersonal/delegater | PIA-/AIA-/säkerhetsinnehåll; kan beskriva personuppgifter som hanteras av ett program | Azure SQL |
| Insamlade Microsoft 365-poster (valfritt) | Potentiellt hög | Förvaltarens egen M365-data | E-post, kalender, OneNote, Teams-chattar eller Copilot-interaktioner som samlats in av förvaltaren som en relevant handling | Azure Blob Storage (konverterade PDF-filer) |
| Extraherad dokumenttext | Potentiellt hög (återspeglar dokumentinnehållet) | Systemgenererat (inklusive valfri OCR av bildbaserade skanningar) | Klartext extraherad för innehållssökning, dubblettidentifiering, maskeringsförslag och AI-grundning | Azure SQL; indexeras valfritt i institutionens egen Azure AI Search-resurs |
| AI-dokumentsammanfattningar (valfritt) | Medel (kan beskriva personuppgifter i dokumentet) | Systemgenererat (Azure OpenAI i institutionens prenumeration) | Cachad maskingenererad sammanfattning per dokument och språk, återgenereras vid innehållsändring | Azure SQL |
| AI-användningsmetadata (valfritt) | Låg | Systemgenererat | Logg med enbart metadata över AI Assist-anrop: funktion, modell, antal token, anropande användare samt mänskliga beslut om godkännande/avvisning. Prompt- och svarsinnehåll lagras aldrig | Azure SQL |
| Hash-kedjad granskningsliggare | Låg-medel | Systemgenererat | Manipulationssäker liggare med endast tillägg över åtgärder i alla moduler | Azure SQL |
Personuppgifter som INTE samlas in
AccessPoint samlar inte in eller behandlar: personnummer (Social Insurance Numbers); finansiell information (bankkonton, kreditkort); hälso- eller sjukvårdsjournaler som strukturerad data (de kan förekomma i dokument under granskning); biometriska data; brottsregisterinformation; platsdata; eller cookies/spårningsidentifierare.
Observera: IP-adresser och user agent-strängar registreras endast i begränsade sammanhang (signering av intygande och loggning av dokumentåtkomst) för forensiska granskningsändamål, enligt listan ovan. Allmänt surfbeteende och enhetsfingeravtryck samlas inte in.
Känsliga personuppgifter i dokument
Dokument som samlas in under ATIA-processen kan innehålla vilken kategori av personuppgifter som helst, inklusive känsliga personuppgifter om tredje parter. AccessPoint lagrar, förhandsgranskar och underlättar maskering av dokument, och extraherar — för att stödja granskningsverktygen — varje dokuments klartext till databasen (med valfri OCR av bildbaserade skanningar via en Azure AI Document Intelligence-resurs inom prenumerationen). Den extraherade texten driver innehållssökning (indexeras valfritt i institutionens egen Azure AI Search-resurs), dubblettidentifiering, mönster-/regelbaserade maskeringsförslag och — när den valfria AI Assist-komponenten är driftsatt — maskingenererade förslag och sammanfattningar. All denna bearbetning sker inom institutionens egen Azure-prenumeration, och varje maskinproducerad maskering eller förslag är ett förslag: klassificering och undantag av personuppgifter i dokument beslutas av utbildade SAO:er med hjälp av de inbyggda granskningsverktygen.
Insamling av Microsoft 365-poster (valfritt, styrt av funktionsväxel): en förvaltare kan samla in sina egna Microsoft 365-poster – e-post i Outlook, Outlook-kalender, OneNote, Teams-chattar, Microsoft Lists eller Copilot-interaktionshistorik – som en relevant handling. Insamling använder alltid den inloggade användarens egen delegerade identitet och är begränsad till den användarens egen data (Copilot-hämtning är enbart app-baserad, eftersom ingen delegerad Graph-behörighet finns, men är alltid begränsad server-side till den inloggade användarens eget Entra-objekt-ID – aldrig hela klientorganisationen). Insamlat innehåll återges som en PDF och går in i det normala gransknings-/maskeringsflödet. Kalenderinsamling exkluderar som standard poster märkta Privat/Personligt/Konfidentiellt.
Analys av flöden av personuppgifter
| Skede | Sammanfattning |
|---|---|
| Insamling | Personuppgifter samlas in enligt ATIA avsnitt 6 (inlämning av förfrågan kräver namn och adress) och Privacy Act avsnitt 4 (insamling relaterad till ett operativt program). Endast personuppgifter som är nödvändiga för att behandla förfrågan samlas in, direkt från den sökande och registrerade av SAO-personal. Fält är konfigurerbara av institutionen. |
| Användning | Den sökandes personuppgifter används uteslutande för att behandla ATIA-/Privacy Act-förfrågan. Endast roller som beviljats behörigheten att visa sökandens personuppgifter (typiskt arketyperna Administratör, SAO och Granskare) kan se den sökandes personuppgifter – Förvaltare och Medarbetare ser dem aldrig (tillämpat server-side genom PII-filtermiddleware). AccessPoint fattar inga automatiserade beslut om individer: den valfria AI Assist-komponenten producerar enbart förslag, redigerbara utkast och skrivskyddade svar, och varje beslut om undantag, maskering, utlämnande och bedömning fattas av utbildad personal. Fasta statistiska rapporter är enbart aggregerade; den anpassade rapportbyggaren exponerar fält på postnivå endast för roller med rapporteringsbehörighet, flaggar synligt personuppgiftsfält i sin katalog, och erbjuder aldrig personuppgiftsfält till AI-funktionen "Fråga AccessPoint". |
| Utlämnande | Svarspaketet tillhandahålls den sökande (ATIA avsnitt 7). Internt utlämnande till personal med rollerna SAO/Granskare är rollstyrt; Förvaltare/Medarbetare får endast sanerade instruktioner. E-post- och Teams-aviseringar till förvaltare/medarbetare innehåller inga personuppgifter om den sökande. Utgivaren tar endast emot klientorganisations-ID, API-version och API:ets egen bas-URL (licensvalidering och identifiering av webbdelen), aviseringsmetadata (mottagarens användar-ID, aktivitetstyp, aktörens visningsnamn, förfrågningsnummer, förhandsgransknings-/ämnestext, referens till relaterad post) och installationsrapporter för jurisdiktionspaket – inga personuppgifter om den sökande. Microsoft behandlar data som underbiträde inom institutionens egen klientorganisation. |
| Bevarande och gallring | En inbyggd funktion för bevarandegranskning tillämpar konfigurerbara bevarandeperioder per posttyp över fem register (förfrågningar, bedömningar, incidenter, klagomål och fristående risker) genom en och samma RetentionService. Radering tar permanent bort posten med dess dokument, uppdrag, uppgifter, intyganden och relaterad historik — omvärderar gallringsbarheten vid raderingstillfället och blockerar poster med ärendeövergripande beroenden — och loggas i tabellen RetentionPurgeLog (som själv aldrig raderas). Azure SQL:s automatiska säkerhetskopior bevarar data i 7–35 dagar beroende på nivå (konfigurerbart långtidsbevarande). |
| Korrekthet | Den sökandes personuppgifter registreras från det ursprungliga förfrågningsformuläret till den återanvändbara kontaktposten för sökande (varje förfrågan länkas till en kontakt); anställdas personuppgifter hämtas från Entra ID och uppdateras vid varje inloggning. Systemet berikar inte poster från externa källor och profilerar inte individer. Det producerar dock härledda representationer av redan innehavt innehåll: extraherad dokumenttext (inklusive valfri OCR), maskinöversättningar av personalens fritextfält (skriver aldrig över en mänsklig översättning), och — när den valfria AI Assist-komponenten är driftsatt — cachade dokumentsammanfattningar samt förslags-/utkastresultat som personalen godkänner eller avvisar. |
Aviseringsvägen illustrerar kontrollen "inga personuppgifter om den sökande till utgivaren":
Event (e.g., assignment created)
│
▼
API Notification Dispatch Service
│
├── PII Filter: strips requestor PI for Custodian/Contributor templates
│
├──► Email: Graph Mail.Send → Institution's shared mailbox → Recipient
│ (via managed identity or institution's app registration)
│
└──► Teams: API → Realizer Platform API → Graph TeamsActivity.Send → Recipient
(sends: user ID, activity type, actor name, request number, preview text — NO requestor PI)
Integritetsriskbedömning
| Risk | Sannolikhet | Påverkan | Åtgärd | Kvarstående risk |
|---|---|---|---|---|
| Obehörig åtkomst till den sökandes personuppgifter | Låg | Medel | Detaljerad, behörighetsbaserad RBAC med server-side tillämpning; Förvaltare/Medarbetare arkitektoniskt uteslutna från personuppgifter; Entra ID MFA; behörighetskontroller vid varje förfrågan. | Låg |
| Personuppgiftsincident via dokumentexponering | Låg-medel | Medel-hög | Kryptering i vila (TDE, AES-256); rollbaserad auktorisering; ingen offentlig dokumentåtkomst; maskeringsverktyg tar bort personuppgifter innan paketering av svar. | Låg-medel |
| Personuppgifter i aviseringar | Mycket låg | Låg | Mallar för förvaltare/medarbetare tar automatiskt bort personuppgifter; SAO-aviseringar innehåller förfrågningsnumret men inte den sökandes identitet; Teams-aviseringar innehåller endast aviseringstyp, förfrågningsnummer och uppgifts-/tilldelningsnamn. | Mycket låg |
| Överföring av personuppgifter till utgivaren | Mycket låg | Låg | Utgivaren tar endast emot klientorganisations-ID och API-adress (licensvalidering) samt aviseringsmetadata – inga personuppgifter, dokument eller förfrågningsdetaljer – och har ingen stående åtkomst till institutionens Azure-resurser. | Mycket låg |
| Personuppgifter utanför kanadensisk jurisdiktion | Konfigurationsberoende | Medel | Data lagras i institutionens Azure-prenumeration i den region den väljer (Canada Central/East rekommenderas); Microsoft Cloud Agreement adresserar dataresidens. | Institutionen bedömer |
| Otillräckligt bevarande/otillräcklig gallring | Låg-medel | Medel | Inbyggd bevarandegranskning med konfigurerbara perioder och raderingsloggning; institutionen anpassar scheman till Library and Archives Canadas gallringsbeslut. | Låg (med korrekt konfiguration) |
| Internt hot (missbruk av behörig användare) | Låg | Medel | Omfattande granskningsspår med användarattribuering och tidsstämplar; rollbaserad åtkomst begränsar exponering; administratörer styr rolltilldelningar. | Låg |
Riskområdespoäng
Enligt TBS:s standardiserade ramverk:
| Riskområde | Poäng | Motivering |
|---|---|---|
| Typ av program eller verksamhet | 2 | Administration av program/verksamhet (ATIA-administration) |
| Typ av personuppgifter | 3 | Kontaktuppgifter och potentiellt känsliga handlingar i dokument |
| Programpartner | 2 | Microsoft (underbiträde); Realizer (ingen åtkomst till personuppgifter) |
| Programmets varaktighet | 4 | Långsiktig/fortlöpande lagstadgad skyldighet |
| Programpopulation | 3 | Externa individer som utövar lagstadgade rättigheter |
| Överföring av personuppgifter | 2 | Krypterad molninfrastruktur inom kanadensisk jurisdiktion |
| Teknik och integritet | 2 | Standardwebbapplikation — ingen övervakning, biometri eller automatiserad profilering. De valfria AI Assist-funktionerna (Azure OpenAI i institutionens egen prenumeration) är enbart förslags-/utkastbaserade — en människa fattar varje beslut, och endast användningsmetadata loggas. Institutioner som driftsätter de valfria AI-komponenterna bör ompröva denna poäng. |
| Potentiell påverkan på individen | 2-3 | Möjlig förlägenhet eller ryktesskada om den sökandes identitet avslöjas |
Övergripande risknivå: Måttlig — standard för ett administrativt program som behandlar personuppgifter om externa individer, begränsad genom starka tekniska kontroller (kryptering, RBAC, filtrering av personuppgifter, datasuveränitet).
Tekniska och administrativa skyddsåtgärder
Autentisering och åtkomstkontroll
| Skyddsåtgärd | Implementering |
|---|---|
| Autentisering | Microsoft Entra ID med JWT-bearer-token. Inga lokala användarkonton eller lösenord. |
| Multifaktorautentisering | Tillämpas genom institutionens policyer för Villkorsstyrd åtkomst (Conditional Access) i Entra ID. |
| Kontinuerlig åtkomstutvärdering | Stöds — tokenvalidering sker vid varje API-förfrågan. |
| Rollbaserad åtkomstkontroll | Detaljerade, klientkonfigurerbara behörighetsroller tillämpade server-side på alla API-ändpunkter. Administratör är den enda inbyggda rollen; klientorganisationer definierar roller som motsvarar arketyperna (Request Coordinator, Granskare, Förvaltare, Medarbetare, Läsare), vanligtvis sådda från ett jurisdiktionspaket. |
| Filtrering av personuppgifter | Server-side middleware tar bort den sökandes personuppgifter från svar för varje anropande som inte har behörigheten att visa sökandens personuppgifter; kan inte kringgås av klienten. |
| Sessionshantering | Tokenbaserad; livslängd styrd av Entra ID-policyer. |
| Bootstrap för första användaren | Den första användaren tilldelas rollen Administratör. Inga standard- eller delade autentiseringsuppgifter finns, och en spärr på serversidan förhindrar borttagning av den sista aktiva administratören. |
Kryptering
| Lager | Implementering |
|---|---|
| Under överföring | TLS 1.3 lägst vid App Service-ingången; TLS 1.2+ på Azure SQL och Blob Storage; FTPS inaktiverat. |
| I vila — databas | Azure SQL Transparent Data Encryption (TDE) med Microsoft-hanterade nycklar. |
| I vila — dokument | Azure Blob Storage AES-256-kryptering; kundhanterade nycklar (CMK) tillgängligt. |
| I vila — hemligheter | Azure Key Vault, åtkomst via hanterad identitet. |
Nätverkssäkerhet
| Skyddsåtgärd | Implementering |
|---|---|
| Enbart HTTPS | All HTTP-trafik avvisas; HTTP/2 aktiverat. |
| CORS | Begränsad till institutionens SharePoint-domän. |
| Hastighetsbegränsning | 600 förfrågningar/minut per autentiserad användare. |
| Säkerhetshuvuden | X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy, Content-Security-Policy. |
| Hanteringsplan | Grundläggande autentisering för SCM/FTP inaktiverad; hantering enbart via Azure-portalen med Entra ID + MFA. |
Övervakning och granskning
| Skyddsåtgärd | Implementering |
|---|---|
| Applikationens granskningsspår | Alla skapa-/uppdatera-/ta bort-åtgärder registreras med användar-ID, tidsstämpel, ändrat fält samt gamla/nya värden. |
| Manipulationssäker granskningsliggare | En hash-kedjad (SHA-256) liggare med endast tillägg registrerar åtgärder över alla moduler; integriteten kan verifieras server-side, och en domstolsklar ärenderevisionsexport (tidigare kallad "bevispaket") kan genereras för en förfrågan. |
| Logg för dokumentåtkomst | Förhandsgransknings- och nedladdningshändelser registreras med användar-ID, tidsstämpel, IP-adress och user agent. Endast infogning. |
| Raderingslogg för bevarande | Alla raderingsåtgärder registreras med användarattribuering. |
| Applikationsövervakning | Azure Application Insights registrerar HTTP-förfrågningar, undantag och beroendeanrop (90 dagars kvarhållning). |
| Larmregler | Konfigurerbara mätvärdeslarm för HTTP 5xx-fel och hög latens. |
| Log Analytics | Centraliserad logglagring med KQL-frågemöjlighet för säkerhetsutredningar. |
Administrativa skyddsåtgärder
Administratörer tilldelar roller via Inställningar; rolländringar träder i kraft omedelbart. En Application Access Policy begränsar Mail.Send till enbart den avsedda delade brevlådan. Konfigurationsändringar tillämpas via versionerade jurisdiktionspaket med granskningsloggning av installationer. Personalutbildning, policy för acceptabel användning och rutiner för hantering av personuppgiftsincidenter fastställs av institutionen.
Tredjepartstjänster och datadelning
| Tjänst | Roll | Mottagna personuppgifter | Dataplats |
|---|---|---|---|
| Microsoft Azure | Underbiträde (IaaS: App Service, SQL, Blob, Key Vault, Application Insights) | All applikationsdata | Institutionens Azure-region |
| Microsoft 365 | Personuppgiftsbiträde (Graph Mail.Send, Teams aktivitetsflöde) och, valfritt, en källa för poster insamlade av förvaltare |
Innehåll i e-post-/Teams-aviseringar; vid valfri insamling, förvaltarens eget M365-innehåll | Institutionens M365-klientorganisation |
| Realizer Services (utgivare) | Programvaruutgivare — ingen roll som personuppgiftsbiträde för kundens personuppgifter | Inga — enbart klientorganisations-ID + aviseringsmetadata + installationsrapporter för jurisdiktionspaket | Utgivarens Azure (Kanada) |
| Syncfusion | Inbäddat bibliotek (inte en tjänst) | Inga — konvertering sker inom institutionens App Service | Institutionens App Service |
| Azure AI Search (valfritt) | Institutionsdriftsatt resurs — index för innehållssökning | Dokumentmetadata, extraherad text och innehållsinbäddningar | Institutionens Azure-prenumeration |
| Azure OpenAI (valfritt — AI Assist) | Institutionsdriftsatt resurs — förslag, utkast, sammanfattningar, översättning | Avgränsade utdrag ur ärendeposter och extraherad dokumenttext vid anropstillfället | Institutionens Azure-prenumeration |
| Azure AI Document Intelligence (valfritt — OCR) | Institutionsdriftsatt resurs — text från skannade dokument | Dokumentsidor som skickas för prebuilt-read-analys | Institutionens Azure-prenumeration |
Valfria Azure AI-tjänster. De tre AI-resurserna ovan är inte utgivartjänster: var och en driftsätts i institutionens egen prenumeration och region, autentiserar enbart med App Service hanterade identitet (API-nyckelåtkomst inaktiverad), och skickar ingenting till Realizer Services. Varje AI-utdata är ett förslag, ett redigerbart utkast eller ett skrivskyddat svar — personalen beslutar; reglage per funktion och klientorganisation samt en månatlig tokenbudget (som helt stoppar all AI-bearbetning) ger styrning; Microsoft tränar inte modeller på datat; och AccessPoint lagrar endast anropsmetadata, aldrig prompt- eller svarsinnehåll. Var Azure OpenAI:s inferens bearbetas beror på den driftsättningstyp som väljs vid driftsättningen (global eller EU-/US-datazon) — institutioner bör bekräfta valet mot sina residenskrav. Ärenderevisionsexporter som genereras för en förfrågan innehåller en redovisning av AI-inblandning (endast metadata), och samma information är synlig i varje posts aktivitetsflöde.
Viktig poäng: Inga personuppgifter om den sökande, inget dokumentinnehåll eller några förfrågningsdetaljer överförs till Realizer Services eller någon extern part. All dokumentkonvertering och maskeringsbehandling sker inom institutionens egen App Service, och den valfria sök-, OCR- och AI-bearbetningen sker inom institutionens egen Azure-prenumeration.
Tillämpliga personuppgiftsbanker
| PIB | Registreringsnummer | Beskrivning |
|---|---|---|
| Access to Information Act and Privacy Act Requests | PSU 901 | Poster relaterade till ATIP-förfrågningar |
| Employee Personnel Records | PSE 901 | Anställdas namn och roller i granskningsspåret |
Institutioner bör bekräfta tillämpliga PIB:er och huruvida nya PIB:er krävs för deras specifika distribution.
Tillgänglighet av den fullständiga PIA:n
Den fullständiga integritetskonsekvensbedömningen – inklusive den kompletta inventeringen av personuppgifter, detaljerad analys av insamling/användning/utlämnande/bevarande/korrekthet, rättslig grund och dataflödesdiagram – finns tillgänglig för kunder och potentiella kunder på begäran. Implementerande institutioner använder den som den tekniska och arkitektoniska grunden för sin egen PIA, och fyller i den institutionella översikten, bevarandescheman, avtal om informationsdelning och godkännande innan de lämnar in den till TBS och Office of the Privacy Commissioner.