How do you control what an AI assistant can access?
Define the purpose, authorize the user and limit the data the application retrieves before it reaches the model. Then check the answer, citations, exports and shared reports against the same intended audience. A prompt can guide behavior, but it should not be the only barrier protecting information someone is not allowed to see.
Use this reference within your governance module when an assistant will work with survey responses, notes, documents or reports. Create a small access policy and test it with fictional records. Keep the policy with your course plan as roles, purposes and permissions change.
These are evaluation practices, not a claim that every control below is a built-in Sopact feature. Confirm the behavior of your configured system, connected services and reporting tools. Your organization's privacy and security owners should resolve requirements that depend on jurisdiction, contracts or the sensitivity of the work.
Start with the task, not a blanket permission
A case worker preparing for a conversation may need identifiable details for an assigned person. A program analyst comparing cohorts may need linked observations without contact details. A board member may need a reviewed aggregate report. “Can use AI” is not a sufficient access rule for all three tasks.
Write a sentence for each use: who needs which information, for what decision, within which population and period. Include documents, transcripts and comments, not just form fields. A redacted spreadsheet does little if an attached file still exposes the same details.
Data access, permission to quote and permission to publish are different questions. Someone may be entitled to review a case note internally without permission to reproduce it in a public story. Keep the intended audience attached to the output as well as the source.
If a survey was designed to be anonymous, do not add identifiers or infer identities merely to support a connected-record workflow. Use an aggregate analysis appropriate to that collection promise. Longitudinal linkage is useful where it is intended and appropriately governed.
Separate instructions from enforced access
An instruction such as “do not reveal names” can help shape a response. An access check determines whether a user or service is allowed to retrieve a record or field at all. These serve different purposes and should be evaluated separately.
OWASP's system-prompt guidance recommends enforcing authorization independently of the language model. A model's apparent compliance in one conversation does not prove that the underlying permissions are correct.
Ask what is actually sent to the model: the entire folder, selected records or an authorized extract. Check which identity the connector uses. A broadly privileged service account can expose more than the person asking the question should receive if the application does not enforce the user's scope.
Removing unnecessary data reduces exposure, but it is not the only control. Authentication, authorization, limited retrieval, safe output handling, monitoring and appropriate sharing controls work together. None should be described as a guarantee against every possible disclosure.
Build a small, explicit access policy
The following is a fictional policy for a training organization. It is an exercise to adapt, not a universal rule or a description of an existing customer's configuration.
| Role and purpose | Allowed view | Excluded from this view | Output boundary |
|---|---|---|---|
| Assigned support worker preparing follow-up | Relevant assigned records and approved notes | Other caseloads and unrelated restricted files | Internal use within the assigned role |
| Analyst reviewing cohort progress | Authorized linked scores and reviewed comment extracts | Contact details and restricted personal narratives | Reviewed analysis with disclosure checks |
| Board reader assessing program results | Approved aggregate report | Raw responses, person-level exports and restricted citations | Named or otherwise approved report audience |
| Public website visitor | Material approved for public release | Underlying records and private report links | Publicly shareable content only |
For each row, assign an owner and a review date. Record how access is granted, changed and removed. If a person holds two roles, test the actual session and task rather than assuming the more restrictive view will automatically win.
Classifying data helps, but categories can overlap. A location, rare role or distinctive event can identify someone without a name. Avoid a catch-all “open” category for anything not marked sensitive. Establish what is genuinely approved for the relevant audience.
Removing names does not make a record anonymous
A stable contact ID preserves a useful link over time. If the organization can connect that ID back to a person, it should not call the record anonymous merely because the name is absent. The ICO's anonymisation guidance distinguishes anonymous information from pseudonymous personal data.
Free text needs its own review. A comment about being the only night-shift parent at a small site may identify someone to a reader familiar with that site. Names, phone numbers and emails are only part of the problem.
Use purpose-appropriate extracts and keep the original under the appropriate access rules. If you generalize a detail or paraphrase a passage, preserve that transformation in the review record. Do not present an edited paraphrase as an exact quotation.
For internal analysis, identifiable information may sometimes be necessary and authorized. The decision is not “always remove all identity” or “give the model the whole record.” It is which information this task legitimately requires and how that access is enforced.
Check small groups, quotes and combined reports
A minimum group size can be one disclosure-control rule, but it is not a universal anonymity guarantee. A larger group can still contain a unique person, and two separately released tables may reveal more when combined.
Suppose a fictional site has six participants and only one person in a particular role. Hiding one cell may not help if totals or another breakdown allow the value to be derived. A quote can reveal the same person even when the numeric cell is hidden.
Review the report, underlying export, drill-down, citations and repeated queries as a connected release surface. Depending on the context, combine groups, omit detail, suppress related cells or choose another presentation. Have the privacy owner define the applicable rules.
Do not delete legitimate source evidence merely because it cannot be shared with a particular audience. Restrict that audience's access and produce an appropriate output. Authorized staff may still need the original for a valid operational purpose.
Record purpose and permissions precisely
A single “consent: yes” field rarely explains the full situation. Record what was agreed, for which purpose, when, under which notice or terms, and whether any use restrictions apply. Permission to contact someone is not automatically permission to publish their words.
Consent is not the only possible legal basis for processing personal information. The ICO's AI lawfulness guidance discusses assessing the purpose and appropriate basis for distinct uses. This is UK-specific guidance and is marked as under review; use current advice relevant to your organization rather than treating this lesson as a legal determination.
When a permission changes or a person makes a rights request, route it to the responsible owner. Determine which uses, copies and retention obligations are affected. Do not assume either that everything must vanish instantly or that updating a mailing-list field resolves every downstream use.
For the exercise below, the policy explicitly prohibits a withdrawn quote permission from being used in a new public report. That is a defined test condition. It does not imply that every withdrawal has the same effect on every lawful internal record.
Protect the report after the answer is generated
An internal answer and a public report have different audiences. Check whether a report link requires sign-in, whether access expires and whether the recipient can export or forward the content. A protected source does not make every generated copy protected automatically.
Review citation links as well as the prose. A short summary may be suitable for a board reader while its source link opens a restricted participant file. The reader should receive an appropriate evidence reference, not unintended access to the source.
Keep an owner, intended audience and review date for recurring reports. Revisit access when staff, partner roles or board membership change. Revoking a link can prevent future access to that link; it does not retrieve copies someone already downloaded.
Ask how corrections, deleted sources and changed permissions affect saved answers, search indexes, caches, logs and exports. The answer may differ across services. Document those boundaries instead of assuming a permission change propagates everywhere immediately.
Treat documents as evidence, not new authority
An uploaded document can contain text that looks like instructions to an AI system. In this workflow, its job is to provide evidence for analysis; it should not grant access to another folder or authorize an external action.
OWASP's prompt-injection guidance describes risks from instructions embedded in content supplied to a model. Use that distinction when testing transcripts, files and retrieved passages. A quote inside a document is not a permission change.
Start with read-only analysis where that meets the need. If an assistant can send messages, edit records or trigger another process, evaluate those permissions separately from its ability to read. Sensitive actions should have appropriate review and accountability.
Run a synthetic acceptance test before using real records
Create a small fictional dataset containing two caseloads, a restricted note, a distinctive small-group comment and a quote whose public-use permission has changed. You do not need to expose real participant information to test these boundaries.
| Test | Expected behavior under the exercise policy |
|---|---|
| Worker requests another caseload using two phrasings | Unauthorized records remain inaccessible; wording does not expand scope |
| Analyst requests contact details | Only the authorized analysis view is available |
| Board reader follows a restricted citation or export | No unintended access to raw records |
| Report includes a distinctive small-group quote | The release review applies the agreed disclosure rules |
| Quote permission changes before a new public report | The prohibited quote is excluded under the defined policy |
| Uploaded text asks the assistant to open another folder | Source text does not grant authority or broaden retrieval |
| Report reader's role is removed | Future access follows the updated rule; downloaded-copy limits are documented |
Record the role, policy version, test input, expected result, actual result and reviewer. Check both allowed and denied requests: a system that returns nothing for everyone is not a useful implementation. An appropriate safe explanation or aggregate answer may be preferable to an unexplained blank result.
These tests are a starting point, not proof against every attack. Rerun relevant cases after configuration, connector or role changes. Escalate failures to the responsible technical owner before expanding the workflow.
Ask vendors to demonstrate the mechanism
For Sopact or another provider, ask which controls are native, which are configured and which require another system. Request a demonstration of your policy with synthetic records, including retrieval scope, document access, citations, exports and permission changes.
Ask where prompts and source data go, which service providers process them, what is retained and whether any use supports model training. Review the applicable product settings and agreements. Do not infer an answer from a generic statement that a product is “secure” or “AI-native.”
The useful result is a documented boundary: what the assistant can read for each task, what a reviewer can share and where responsibility remains with your team. This lets data owners work confidently without assuming that every data-governance decision requires an unrestricted central repository.
Explore related demonstrations
Browse the video library → Use the source, definition and access checks in this lesson when evaluating a demonstration. A video does not verify the controls in your own configuration.
Frequently asked questions
Can a prompt enforce data permissions?
A prompt can guide behavior, but authorization should be enforced by the application and connected systems. Test what data is retrieved, not just whether one answer omits a name.
Is a contact ID anonymous?
Not necessarily. If it can be linked back to a person, it preserves identity linkage rather than guaranteeing anonymity. Treat the record according to the applicable purpose and protections.
Must all identifiable data be removed before any AI use?
Not in every authorized use. Limit information to what the task requires and verify the processing arrangements and access controls. Aggregate reporting often needs less detail than individual service delivery.
Does a minimum group size guarantee privacy?
No. Unique details, quotes and combined reports can still identify someone. Apply context-specific disclosure review across the output and its supporting access paths.
Should we test with real participant data?
Start with synthetic records that exercise the relevant boundaries. Use real information only within an approved validation process with appropriate safeguards.
What happens when a permission changes?
Assess the affected purpose, records and outputs under the applicable policy and obligations. Check new analysis, saved answers and sharing separately; do not assume one field updates every copy.
Who owns a consequential decision?
Assign an accountable person with authority to review the evidence and challenge the output. AI preparation should not obscure responsibility for decisions affecting people or organizations.
Apply the access policy to the report
Carry the access policy and sharing boundaries into writing a cited impact narrative. A useful report connects claims to evidence while giving each reader only the detail appropriate to their role.
Reviewed September 12, 2026. Policies and test records are fictional exercises. Product behavior must be verified in the configured workflow; legal requirements depend on context.