Professional secrecy in AI practice has become a design question

You must now treat professional secrecy as a design requirement, not a policy statement. If you deploy AI in a role bound by confidentiality—legal practice, healthcare, notarial work—you carry the duty to demonstrate, through architecture and traceable controls, where client or patient data does and does not flow.

The prompt is an analysis of 28 August 2026 of professional secrecy as a design requirement in AI systems, which argues that confidentiality in the AI context is no longer solely about how you handle case files, but about how you set up systems technically and organisationally. The CCBE's technical guide for lawyers and the joint note by CNIL and CIANum on agentic AI both anchor professional secrecy through visible architecture: secure environments, limited and separated memory layers, traceable agent actions and human control points. In our assessment, this shift from policy to design means you cannot discharge your confidentiality obligations through caution alone; you must be able to demonstrate, for each workflow, which technical and organisational measures prevent client or patient data from reaching public AI interfaces, where that data is stored, which contracts and safeguards underpin those choices, and how output enters your case file or record via human control.

What does professional secrecy now require you to document?

Professional secrecy in the AI context rests on three pillars: data flows, contracts and verification. For each AI tool you use, you must analyse where personal, confidential or client-related data enters the system, where it is stored, which third parties can access it, and whether it enters any training process. You must hold contracts that spell out these terms and give you the right to audit them. You must then verify, through traceable processes, that those contracts and technical measures are actually in place and working.

The CCBE makes this explicit for lawyers: you may not enter confidential data into generative AI interfaces without appropriate technical and organisational safeguards. The CNIL and CIANum note extends this logic to agentic AI, where persistent memory functions and complex data flows put users' control over personal data under pressure. In both cases, the standard is the same: you must be able to show your working.

Which failure modes does this architecture guard against?

• Data leakage to training systems — confidential information reproduced or inferred from model outputs because the AI system retained it.
• Loss of user control over agent actions — data subjects unable to understand which agent collected which data, where it is stored or to whom it has been passed.
• Unverified AI output in case files or records — decisions or recommendations entered into professional records without human review or sign-off.
• Opacity of data flows — no traceable record of which data entered which system, which agents or services intervened, or which safeguards were applied.
• Absence of emergency stop mechanisms — no way to halt high-risk operations or prevent further data use once a breach or misuse is detected.

What concrete controls must you be able to demonstrate?

1. Analyse and document data flows for each AI tool — record which data classes each workflow touches, where they originate, which AI systems they enter, and which third parties can access them.
2. Establish contracts that specify storage, training and audit rights — hold written agreements that prohibit training on your data, specify where data is stored, and give you the right to verify compliance.
3. Implement technical separation between confidential data and public AI interfaces — route only anonymised or pre-processed content to external AI models; keep confidential data on infrastructure under your control.
4. Trace and log all agent actions and data use — maintain a verifiable record of which data entered which system, which agents or services intervened, and which human controls were applied.
5. Establish kill-switch mechanisms for high-risk operations — design workflows so that when a privacy check fails or a risk threshold is breached, data is not forwarded and the operation halts.

How does this apply across professions?

This logic is not limited to law. Healthcare professionals face the same pressure. A systematic review of international guidelines for AI in healthcare shows that privacy, security, patient autonomy and confidentiality recur structurally. Health data is designated as particularly sensitive, and using AI for diagnostics or decision-making is only responsible when there are strong safeguards for data minimisation, secure infrastructure, transparency about data use and mechanisms through which healthcare professionals can understand and control decisions. Civil-law notaries operate under similar confidentiality obligations and face the same architectural demands.

What role can tooling play in this?

A verification layer can make visible how professional secrecy is safeguarded in each AI-supported step. Such a layer supports insight into which AI tools and agents have been used, which data classes fall under professional secrecy, where that data technically does or does not flow to, which human controls and kill-switch mechanisms have been applied, and how log and evidence chains provide insight into the AI-supported work. However, tooling cannot replace professional secrecy or set the standards; it can only make visible how those standards are applied. The professional final judgement always remains with you. Professional secrecy in AI practice has thereby become above all a design question: not to be solved with cautious prompts, but through a confidentiality-safe, auditable architecture in which data flows, memory layers and control points are visible and verifiable.