The DBA Who Pasted a Query Result Into an AI Assistant: Who Is Accountable?

It is 17:40. A database administrator has run a query against production. The result is 4,000 rows and something is inconsistent. An AI assistant is open in the next tab. They copy the result, paste it and type "find the inconsistency in these records". Twenty seconds later the right answer comes back.

This is not the story of someone acting in bad faith. It is the story of a tired, well meaning person who wants to work fast. And it is a serious problem for personal data protection.

The Authority Now Knows This Officially

The Turkish data protection authority has published two guidance documents on generative AI: "Generative AI and the Protection of Personal Data (15 Questions)" in November 2025 and "Use of Generative AI Tools in the Workplace" on 5 March 2026. The starting point of the second is this: employees turn to these tools to draft text, summarise documents, translate, get coding help and research, and they often do so while unknowingly sharing personal data.

The legal consequence is becoming clear: accountability sits with the data controller, not with the employee. If the pasted text contains a customer's name, ID number or health data, the organisation is still the party processing it.

Why This Is a Special Risk for DBAs and Analysts

An ordinary employee pastes an email into an AI tool. A database administrator or analyst pastes structured, bulk data: the output of a table, an error log, a slice of a customer list.

• Volume. An email concerns one person. A query result concerns thousands.
• Displacement. The data leaves any governance process for the first time: no request, no justification, and the recipient is a service outside the organisation.

Five Layers Working Together

No single control solves this. Five layers are needed together, and the first is a job no product can do on the organisation's behalf.

1. Organisational policy. Which AI tools are approved and which data class is never pasted. Writing and communicating this is the organisation's job.
2. Which columns may leave? Let a request be the only way to take data out of production. The request shows which columns the query will return before it runs. Sensitive columns such as ID number, card, IBAN and phone are masked.
3. Masking looks at content too. Masking only a column named "national ID" is not enough. Not every eleven digit number is an ID; real ones must be told apart by validation algorithms such as the national ID checksum, Luhn for cards and mod-97 for IBANs. An order number is not masked needlessly and a real ID number is less likely to slip through.
4. Record the delivery. The result is delivered as an encrypted package and the download password is shown in the portal against a written reason. Who downloaded it, from which address and for what reason is on record.
5. Unmasked data is a separate decision. If a column has to leave unmasked, that needs a second approval and a written reason. "Will this be pasted into an AI tool?" can be added to the approval questions.

The Honest Limit

The product does three things: it reduces what is available to paste (a masked delivery has no ID numbers in it), it leaves a record (who took data, when and for what reason) and it puts unmasked data behind a separate decision. Non sensitive records in a masked file can still be a business secret, but for data protection there is a very large difference between pasting a list of ID numbers and pasting a masked list.

A Five Point Rule for DBAs and Analysts

You can carry this into a policy document or a team meeting as it stands.

1. No result from production is pasted into an AI tool that has not been approved.
2. Even with an approved tool, unmasked ID, card and health data is never pasted.
3. If real data is needed to debug, a masked or synthetic sample is produced.
4. Pasted data is assessed against the retention and training terms of the AI service the organisation uses.
5. When in doubt, ask: "does this data belong to a customer?"

Frequently Asked Questions

Who is responsible for customer data pasted into an AI tool?

The common conclusion of the authority guidance and legal commentary is that accountability stays with the data controller, not the employee. If the pasted text contains a customer's name, ID number or health data, the organisation is still the party processing it.

Does masking prevent pasting into an AI tool?

No. No product can stop the contents of a delivered file from being pasted into an AI assistant. Masking reduces the sensitive data available and puts the delivery on record. Detecting the paste itself is the job of endpoint protection and data loss prevention tools.

Does masking only look at the column name?

No. It looks at both the column name and the content, and the content checks use validated patterns: the checksum for national ID numbers, Luhn for cards and mod-97 for IBANs. An ordinary eleven digit number such as an order number is not masked needlessly, while a real ID number is less likely to slip through.

What happens if unmasked data is needed?

A separate approval and a written reason are required for a column to leave unmasked. This depends on the organisation's policy setting; the default policy requires approval.