Problem Statement
The goal is to convert complex, role-based data access policies into a clear and plain‑English summary for internal stakeholders. The workflow must turn role descriptions, dataset categories, access rationales, and request/approval processes into an aligned, easy-to-understand policy overview. Outputs should avoid sensitive dataset names, use placeholders, and maintain a clear, responsible tone without legalistic language.
Steps
Collect Roles and Dataset Inputs
INGESTIngest role definitions, dataset categories, access rationales, and request/approval process descriptions provided by the SME. Replace any sensitive dataset names with generic placeholders consistently across the workflow.
Map Roles to Dataset Categories
EXECUTEIdentify which roles map to which dataset placeholders based on rationale. Standardize dataset categories so they can be used to generate a clear access matrix.
Generate Plain-English Policy Summary
EXECUTEDraft a human-friendly summary of the policy, including rationale explanations that avoid legalistic language while maintaining accuracy and clarity.
Define Request and Approval Flow
EXECUTETranslate the provided approval process into an ordered access-request workflow. Ensure clarity and avoid invented steps or unverified legal statements.
Add Audit Guidance and FAQ
EXECUTEProduce simple audit suggestions and a short FAQ addressing common internal questions. Maintain placeholders where needed and avoid referencing sensitive data.
Validate Tone and Constraints
EXECUTECheck the draft for sensitive data, legalistic wording, or overly technical phrasing. Ensure tone remains clear, responsible, and non‑threatening.
Prompt Configurations
Policy Drafting Prompt
You are an AI assistant preparing a plain-English summary of a role-based data access policy. Follow these instructions: - Use a clear, responsible, and non-threatening tone. - Do not include sensitive dataset names; replace them with generic placeholders like Dataset A, Dataset B, etc. - Summarize the policy in five outputs: (1) policy summary, (2) access matrix, (3) request/approval steps, (4) audit guidance, (5) FAQ. - Do not invent rules or legal requirements. Only rely on the input information. - Keep language simple and free of legal terminology. Use only the provided roles, dataset categories, rationales, and procedures. Do not fabricate details.
Example Inputs/Outputs
Roles: Analyst, Manager Datasets: Customer Data (restricted), Operations Metrics (standard) Rationale: Analysts need operational metrics for reporting. Managers may need customer data for escalations. Approval Process: Analysts require manager approval; managers require data governance review.
Policy Summary: This policy outlines which roles can access major dataset categories and why. Analysts may access Dataset A (Operations Metrics placeholder) for reporting needs. Managers may access Dataset B (Customer Data placeholder) when necessary for escalations. Access Matrix: Analyst → Dataset A (allowed), Dataset B (not allowed). Manager → Dataset A (allowed), Dataset B (allowed with review). Request/Approval Steps: Analysts submit a request to their manager. Managers submit requests to the data governance team. Audit Guidance: Review access quarterly, checking that approvals are documented. FAQ: Who approves Analyst requests? Their direct manager. How often is access reviewed? Quarterly.