Can we put the neighbors' feedback into an AI tool?

A customer needs an answer. An invoice needs checking. Your team wants to try a new tool. Start with a familiar problem, see what is happening, and choose what you would do. No technical background needed.

  1. Meet the problem
  2. See what is happening
  3. Make a choice
  4. Find out why
  5. Try a small change

All decisions are free without an account or API key. Drafts stay on this device only, not in account sync. Follow-up lessons retain their existing sign-in and plan requirements.

These are made-up (synthetic) stories with feedback written in advance, not live AI results or real customer outcomes. They help you practise, but do not certify your skills.

Rosa organizes a neighborhood activity. A feedback form asks why people miss sessions. Replies include useful scheduling suggestions alongside phone numbers and private family details. Rosa wants to tell the committee which times work best.

The problem: The committee needs a useful pattern, not access to every person's private circumstances.

Picture the situation: The calendar explains the question, the folded replies suggest personal context, and the committee waits for a report rather than individual stories.
An activity calendar and empty chairs sit left. Opaque feedback sheets with telephone and house tokens sit center. A faceless committee waits beside a blank report stand at right; the original replies are not displayed to the committee.

AI-illustrated teaching scene. Follow the arrows from 1 to 3; they show how to read the story, not actions taken by an AI.

  1. Some neighbors miss sessions

    Rosa wants to understand whether different times would help.

  2. Personal feedback arrives

    Replies mix scheduling suggestions with phone numbers and private stories.

  3. The committee needs a report

    Members want to choose meeting times, not read personal case histories.

What would you do?

What should Rosa prepare first?

What to take away

Removing names does not make every story safe to share. Start with the least information needed for the question.

What if something changes?

The counts do not explain why suitable times still fail. The privacy lead approves a restricted helper for this purpose, with private details removed before use, limited access and a clear deletion plan. The committee still receives only reviewed themes.

What use fits that new permission?

  • Use any convenient tool now that summaries are approved
    Why this choice?

    Approval for one restricted helper does not permit sending the replies elsewhere. Keep the agreed access and deletion rules, and ask the privacy lead before changing who receives the information or why.

  • Try the approved helper for reviewed scheduling themes
    Why this choice?

    That can explore the missing pattern within the agreed limits. Check for identifying details before sharing, and stop if private stories appear in the output. Ask the privacy lead what may be kept, shared or deleted.

What to take away

A clearer need and specific safeguards can justify limited help, without granting permission to share the underlying stories widely.

The idea behind this story

Match what you share, who receives it and their permission to the actual need.

What detail might identify a neighbor even after their name is removed?

The technical connection: Purpose-limited processing

Minimization, approved recipients and output review work together. Privacy owners decide permitted use, rights handling and retention; a successful test or a name-removal step does not establish blanket compliance.

Advanced: A useful summary does not require everyone's private details

Choose the least data a task needs, then assess a restricted summary pilot without treating approval as unlimited access.

Privacy and sensitive data sharing · 9 minutes

The problem

Synthetic practice scenario: all quantities and evaluation outcomes are illustrative, not reported research. Fictional outcomes are not guarantees. A service quality team wants to learn why appointments are missed; its notes also contain contact details and private personal circumstances unrelated to the improvement report.

Your initial decision

What information should leave the case-management system for the first report?

  • The fictional report needs category counts, not personal narratives; a restricted internal query can produce them.
  • The proposed external assistant is not approved for these records and has no agreed data-use or retention terms.
  • Removing names alone can leave people identifiable through rare circumstances, dates or combinations of fields.
  • The privacy policy owner decides permitted purposes, recipients and rights handling; the model cannot infer consent.

Compare the alternatives

  • Create reviewed counts inside the approved system

    A minimal aggregate report answers the current question without exporting narratives, but small groups still need disclosure review before sharing.

  • Prepare a restricted summary pilot after approval

    A controlled summary could reveal themes beyond existing categories, but requires purpose review, approved processing and tested minimization first.

  • Remove direct identifiers before external summarization

    Redaction can reduce obvious exposure, but rare details can remain identifying and the proposed recipient is still unapproved for this use.

Mechanism, trade-offs, and evidence

  • Start with the purpose: category counts answer the stated question, so exporting full notes would add exposure without demonstrated need.
  • Data minimization and recipient authorization are separate checks; passing a redaction test does not grant permission to share.
  • NIST provides voluntary risk-management guidance, not a finding that this fictional report complies with every privacy obligation.

Reconsider after a change

The counts conceal recurring scheduling obstacles; the privacy owner approves a purpose-limited internal summarizer with tested filtering, restricted access and a defined retention schedule.

Can the team now learn from narratives within the approved boundary?

  • An independent illustrative test of 100 synthetic notes finds 93 useful theme summaries and flags 7 for restricted human review.
  • The approved processor excludes contact details before model access, blocks external tools and restricts output to the quality team.
  • The privacy owner has set retention, access and rights-handling procedures for this specific purpose; rare details still need disclosure review.
  • Reviewers may correct or withhold themes; outputs must not score individuals or drive eligibility decisions.

Compare the alternatives

  • Keep the counts-only report as the fallback

    Counts preserve the lowest-data option and a stable baseline, but cannot explain the newly observed obstacles hidden inside broad categories.

  • Pilot restricted theme summaries for the approved purpose

    Minimized internal summaries may reveal actionable scheduling themes, but require access enforcement, disclosure review and deletion under the owner's schedule.

  • Use the redacted notes with the external assistant

    An external tool might offer convenient reporting, but the internal approval does not extend to another processor or eliminate re-identification risk.

Mechanism, trade-offs, and evidence

  • The evidence now supports a question that counts cannot answer, and the approved boundary has changed; both matter to the recommendation.
  • Synthetic tests are useful safety probes, not proof that real notes cannot identify someone; monitor disclosures and preserve a restricted review path.
  • Keep rights and retention decisions with the privacy policy owner, and do not turn service-improvement themes into decisions about individuals.

Related technical concepts

Follow-up lessons retain their existing sign-in and plan requirements.

Technical sources

  • AI Risk Management Framework — NIST

    Organizes voluntary risk management around governing, mapping, measuring and managing; it is neither certification nor a return-on-investment study.

  • MCP Security Best Practices — Model Context Protocol

    Describes consent and authorization boundaries for tool integrations; adopting a protocol does not grant access to customer data or actions.

  • Demystifying evals for AI agents — Anthropic Engineering

    Explains tasks, graders, repeated trials and outcome evaluation for agents; use task-specific tests rather than importing reported scores.

Explore the technical decision

Learning together? Pick a story, compare your choices, and talk about what might change your mind. There are no verified team scores or completion records here.

Self-checks and completion records help you reflect; they are not independently verified credentials. Credential availability, assessment, and eligibility are separate.

AI Agents, Explained — free, no login

Explore the cases