Respect privacy limits in public evidence work

Prerequisites: Lectures 2, 4, 8, and 10. You should already know how public evidence forms a source trail, how to sketch a studio view, how preventable confusion differs from harder uncertainty, and why a relevant studio may disappear from a recommendation answer. This lecture adds a working safety line: what evidence belongs in the check, and what should stay out of it.

A teaching example, deliberately small: a studio notices that an AI answer says it “handles company setup for foreign owners.” The phrase is too broad. A junior colleague wants to prove the mistake by uploading a client email thread, a draft invoice, and a scan of a foreign founder’s documents into another AI tool. The intention is good. The move is bad. The folder has the nervous smell of real client work: names, tax codes, signatures, half-sentences from a stressful week.

The safer path is slower and less dramatic. The studio does not need client files to inspect the mistake. It can use the English service page, the Italian service page, the public directory category, the review that says “helped us start invoicing,” and the AI answer itself. That is enough to understand why the answer stretched “starting to invoice” into “company setup.” The private documents would add risk without adding much visibility value.

Keep the client file out of the machine

Data protection boundary is the line keeping checks focused on public, non-confidential evidence rather than client documents or personal data. I use the term as a course habit, not as legal advice and not as a substitute for professional legal interpretation.

For a small Italian accounting studio, this boundary is practical before it is dramatic. The studio handles tax codes, payroll details, identity documents, correspondence, and commercial situations that clients did not publish for marketing or visibility work. An AI visibility check should not turn those materials into prompt ingredients merely because a machine summary was annoying.

The temptation appears most often when the AI answer is close to real work. Suppose an answer says the studio advises on cross-border VAT because it found one English-facing review about invoices for an international client. The partner may think, “I can show the full file and the model will understand.” But visibility work is about public representation. The model’s wrong public description should usually be answered with public evidence: pages, listings, records, review language, and date-stamped answer notes.

A client document may feel like the sharpest proof because it is real. It is also the wrong kind of proof for this job. It may contain personal data, commercial details, and context the public never needed. A clean service sentence on the website can correct the public frame better than a private email thread ever should.

Public evidence is usually enough

In Lecture 2, we treated public evidence as visible material: website pages, listings, chamber records, reviews, profiles, and repeated service phrases. That definition becomes practical here. Most AI visibility checks can be done from the same material an outsider could inspect.

Take Composite Object B, the studio with Italian service pages, one English page, reviews, and a tax-assistance listing. The AI answer says it helps foreign founders “set up companies in Italy.” We do not need a real foreign client file to inspect this. The public source trail already gives us the likely ingredients: an English page with loose “starting in Italy” wording, a review about setting up invoices, and a nearby listing that uses a broader tax-assistance category. The mistake may be preventable confusion, but the evidence for diagnosing it can stay public.

The working note might say: “Claim: company setup for foreign owners. Public fragments supporting the stretch: English page says ‘starting in Italy’; review says ‘set up invoices’; directory category near tax assistance. Public fragments limiting the claim: Italian service page describes recurring accounting for existing small companies. Judgment: English wording may invite a broader interpretation than intended.” No client names. No private documents. No attachments.

This is not timid. It is cleaner.

A studio view, as we used the term in Lecture 4, is the working picture an AI answer seems to hold after compressing public evidence and context. To sketch that view, you need the public facts and the answer behavior. You do not need the back office archive. In fact, private material can confuse the exercise. It may help a model answer one private prompt more accurately while doing nothing to improve the public trail that future users may encounter.

Redaction helps, but it is not a magic cloth

Students sometimes ask whether they can simply redact client files. Redaction can help in narrow internal work, but it is not a general permission slip. A black bar over a name does not remove every clue. A date, a business sector, a town, a tax detail, or a particular wording pattern may still identify a client to someone who knows the local market.

A composite scenario: a studio wants to show that it does not perform formal company incorporation. Someone prepares a redacted engagement letter from a small manufacturer. The name is removed. The VAT number is removed. But the letter still mentions a rare machine type, a small municipality, and a deadline tied to a public tender. In a town where three people know everything by lunchtime, that is not anonymous in any comfortable sense.

The better teaching example uses invented or reconstructed text. Write a non-confidential sample that preserves the shape of the issue without copying the client’s material. For instance: “A foreign-owned small company asked for recurring accounting after registration, not incorporation.” Then compare that sample with the public wording that caused the confusion. The sample clarifies your thinking; the public wording remains the inspection target.

Public availability also needs care. A review, a register entry, or a directory profile may be visible online, but that does not mean every personal detail inside it should be copied into new tools or mixed with extra context. For this course, the habit is simple. Use the least sensitive public evidence that answers the visibility question. If a document was created for a client matter, it starts outside the exercise.

You may later decide, with proper professional judgment and legal advice where needed, that an anonymised internal example is acceptable for staff training. But do not make that the first move. First inspect the public trail.

Names, reviews, and credentials need careful handling

Accounting studios live on trust, and trust often carries personal names. Partner names, professional titles, staff bios, client reviews, and testimonials can all shape how an AI answer describes the studio. The problem is not that names must disappear. The problem is that names should be used for the job they are meant to do.

A partner name on the official website may help separate one studio from another. A formal credential may help anchor identity. A public review may show how clients describe the service. These can all belong in public evidence. But client names, employee personal details beyond professional presentation, and private correspondence do not become fair material merely because they might help explain an AI mistake.

There is a small ugliness here that professional offices know well. A review may mention a client’s problem too vividly. “They saved us when our restaurant missed payroll deadlines after my father’s illness” may sound helpful to a recommendation answer, but it also exposes more than a clean service description should need. The studio may not control every review. For this lecture, the student’s task is to classify the evidence carefully: public review signal, yes; private proof source, no.

Recommendation omission from Lecture 10 can also tempt overexposure. If the studio is left out of an answer, someone may want to publish more client stories, more named examples, more proof of relevance. Slow down. A relevant studio is usually easier to recommend when its public name, place, service fit, and client type are clear together. That can be done without turning client work into public display.

For example, “We provide recurring accounting and payroll coordination for small companies in the province of Treviso” is stronger and safer than a named client anecdote. It gives the machine a handle and gives the human reader a boundary. Good public wording is like a label on a locked drawer: it tells you what is inside without spilling the contents onto the floor.

Write a safe visibility check note

The check note for this lecture has four parts. First, write the AI claim exactly as you saw it, with date, engine, query, and mode if known. Second, list only public evidence that may explain or contradict the claim. Third, mark anything you are tempted to use but should not use. Fourth, write the next public wording question.

A note for Object B might read: “AI claim: studio helps foreign owners set up companies. Public supporting fragments: English page says ‘starting in Italy’; review says ‘set up invoices’; directory category overlaps with tax assistance. Public contradicting fragments: Italian page describes ongoing accounting for existing businesses. Excluded material: client email thread about post-registration accounting. Public wording question: should the English page say ‘after your company is registered’ where appropriate?”

That last question is modest, which is why it works. It does not ask the studio to prove everything to a machine. It asks whether the public wording has left a hinge loose. If the hinge is loose, tighten the public wording. If the public wording is already clear and the answer still drifts, record that without dragging private material into the test.

Another note for Object A might concern a wrong payroll-only description. “AI claim: studio mainly handles payroll. Public fragments supporting the narrow claim: two directories list payroll first; three reviews mention payslips. Public contradicting fragments: service page mentions recurring accounting for small companies. Excluded material: client portfolio showing accounting work. Public wording question: should the opening service sentence place recurring accounting and payroll coordination together?” Again, the studio does not need to display the portfolio.

There will be borderline cases. A staff bio is public, but should every staff detail be repeated in AI prompts? A review is public, but should it be copied into a tool with extra context? A chamber record is public, but does it explain service scope or only identity? These are professional judgment questions. The course gives a conservative habit: use the least sensitive public evidence that answers the visibility question.

By Lecture 11, the course has moved from “why did the model say this?” toward “how do we investigate responsibly?” That shift matters. AI visibility work can make a studio clearer, or it can train people to throw private material at every confusing answer. I prefer the boring path: public facts, careful notes, no client files on the table.

What matters to remember

Data protection boundary: The line keeping checks focused on public, non-confidential evidence rather than client documents or personal data.

GDPR is treated here as a practical caution line for studio evidence work, not as legal advice or a substitute for professional legal interpretation.

Public evidence is usually enough to inspect a wrong AI description, a narrowed service frame, or a recommendation omission.

Redaction can reduce risk, but it does not automatically make client material suitable for AI visibility checks.

The repeated course anchor still applies: four ways an AI answer reshapes a small accounting studio — names the practice, narrows the service, borrows nearby evidence, or leaves the firm unmentioned. Lecture 11 asks how to inspect those shapes without exposing the private files behind the studio’s work.

Check yourself

Describe in your own words why client documents are usually the wrong material for an AI visibility check.

Client documents are usually the wrong material because AI visibility work is about public representation, not proving the full history of a client matter. A client email, invoice, or engagement letter may contain names, tax details, business context, and private circumstances that are unnecessary for diagnosing a public AI answer. The studio can normally inspect the same problem through website pages, directory profiles, reviews, public records, and the answer itself. Using private files may create risk without improving the public evidence trail. The safer habit is to clarify public wording rather than expose private work.

Give an example of a safe public evidence set for checking a wrong “company setup” description.

A safe public evidence set could include the AI answer with its date and query, the studio’s English service page, the Italian service page, the relevant directory category, and any public review language that may have shaped the answer. If a review says “helped us set up invoices” and the English page says “starting in Italy,” those fragments may explain why the model stretched the description toward company setup. The studio does not need to upload a real client file. It can compare public wording and decide whether the English page needs a clearer limit.

How would you distinguish a public review signal from private proof in this lecture’s method?

A public review signal is already visible and can be recorded as part of the source trail, although it should still be handled carefully. It shows how clients publicly describe their experience, such as mentioning payslips, invoices, or deadline help. Private proof is material from inside the studio’s client work, such as emails, contracts, invoices, or identification documents. Private proof may feel stronger, but it is usually unnecessary for AI visibility inspection. The method asks whether public evidence explains the model’s description, not whether private files can prove the studio’s real competence.

When might redaction still be insufficient for a visibility exercise?

Redaction may be insufficient when the remaining details still identify a client or reveal private business context. Removing a name and VAT number does not always solve the problem. A rare industry, a small town, a particular deadline, or a distinctive phrase may still point to the client. In local professional work, people often recognise situations from fragments. For a visibility exercise, the better option is usually to create a non-confidential teaching sample that preserves the issue’s shape, then inspect the public pages and listings that caused the AI answer to drift.

How would you explain the data protection boundary to a busy studio partner?

I would explain it as a simple working line: we inspect AI answers with public, non-confidential evidence first. That means website pages, directories, chamber-style records, reviews, profiles, and the AI answer itself. We do not start by uploading client documents, even when they seem to prove the point. The goal is to improve the public trail that AI systems and potential clients can see. Private files belong to client work, not to visibility checking. Keeping that line saves time, reduces exposure, and keeps the studio’s evidence work professional.