Understanding Minimal and Limited Risk under the EU AI Act

Posted on October 10, 2025April 9, 2026 by Philipa Jane Farley, Head of Legal and Operations

A Practical Guide for DPOs and In-House Legal Teams

Artificial intelligence has quietly become part of everyday work. From productivity assistants to document summaries and email suggestions, most organisations already use AI without realising it. These technologies bring efficiency, but they also raise important questions for data protection and compliance professionals: how do you manage accountability, explainability, and transparency without overburdening your governance processes?

The EU AI Act offers a clear framework for doing exactly that. It classifies AI systems according to the level of risk they pose to people’s rights or safety. The EU AI Act distinguishes between unacceptable, high, and certain limited-risk systems. The term ‘minimal or no risk’ is commonly used to describe AI systems that fall outside the specific obligations of the Act. For most organisations, the focus will be on the last two categories. They cover the vast majority of AI systems in day-to-day use, tools that enhance productivity rather than make high-stakes decisions.

This article explains what minimal and limited risk systems are, what the EU AI Act expects of organisations that use them, and how DPOs and legal teams can embed proportionate AI governance into existing compliance frameworks.

Understanding the EU AI Act’s Risk Approach

The Act’s design is rooted in proportionality. It does not impose heavy regulation on every AI tool. Instead, it scales obligations according to the potential impact on people.

Unacceptable risk systems are banned altogether. These include manipulative or exploitative AI such as social scoring or subliminal techniques.
High risk systems are strictly regulated and typically found in sectors such as health, employment, education, credit scoring, or law enforcement.
Limited risk systems require transparency measures so that users know when they are engaging with AI.
Minimal risk systems carry no specific legal obligations beyond general laws such as the GDPR and consumer protection rules.

This tiered approach is important because it allows innovation to continue while protecting fundamental rights. For most DPOs and legal teams, the challenge is to translate those tiers into practical governance actions that fit within existing processes rather than duplicating them.

Why Minimal and Limited Risk Matter Strategically

It would be easy to treat these categories as purely technical or compliance-driven. In reality, they sit at the heart of strategic governance.

Accurately classifying AI systems defines how organisations can innovate safely. It helps determine when a full risk assessment is required, when lighter documentation will suffice, and how to prioritise oversight. More importantly, it demonstrates to regulators, partners, and customers that the organisation understands its responsibilities and has a defensible approach to accountability.

This is not simply about avoiding fines. Clear classification also builds trust and confidence among staff and clients. When people know how and why AI is being used, the organisation’s reputation for transparency and ethical practice grows stronger. That is particularly valuable in markets where trust is a differentiator, such as healthcare, finance, and technology.

Minimal Risk AI: Low Impact, High Accountability

Minimal risk AI refers to systems that present little or no potential to affect individuals’ rights or safety. They typically automate small, low-stakes tasks, often in the background, and do not involve profiling or decision-making.

Common examples include:

Grammar and spelling assistants.
Autocomplete and predictive text.
Search or document retrieval tools.
Spam filters and simple categorisation algorithms.

The EU AI Act imposes no direct obligations on these systems, but good governance remains essential. Accountability underpins both the Act and the GDPR. DPOs should ensure that minimal risk systems are visible in governance registers and can be explained if questions arise.

Practical steps for managing minimal risk AI:

Keep a short internal note in your DPIA or processing record identifying the system, its function, and your rationale for minimal risk classification.
Record the supplier, model version, and location of any data processed.
Periodically review the system to ensure that its functionality has not evolved into areas such as profiling or analytics that might alter the risk level.

Minimal risk does not mean no oversight. A one-page record of your reasoning is often enough to show accountability, but it is also a valuable signal of organisational maturity.

The difference between minimal and limited risk is not about technical complexity but about human impact. Once AI begins interacting with people or generating information that could shape perceptions or decisions, transparency becomes the key dividing line.

Limited Risk AI: Where Transparency Becomes the Safeguard

Limited risk systems are those that interact with users directly or generate synthetic content but are not used in sensitive or high-risk contexts. Their primary risk lies in misunderstanding, in that people may not realise they are engaging with AI or may over-rely on outputs.

Examples include:

Chatbots and virtual assistants.
Tools that generate text, audio, or images.
Meeting transcription or summarisation services.
Productivity assistants that draft, summarise, or recommend actions.

For limited risk AI, the EU AI Act focuses on transparency obligations. Transparency obligations for certain AI systems, such as chatbots, emotion recognition, and systems generating synthetic content, are set out in Article 50 of the AI Act. Users must:

Be clearly informed that they are interacting with AI.
Users must be informed that content has been generated or manipulated by AI.
Be able to identify AI-generated or synthetic content from notifications.
Understand the capabilities and limitations of the system.

The goal is not to stop organisations using these tools, but to make sure people know when AI is at work and can interpret its outputs appropriately.

Practical steps include:

Maintain a register of all limited risk AI systems with notes on their transparency measures.
Confirm that user interfaces display clear AI notices or indicators.
Keep vendor documentation that demonstrates compliance with the EU AI Act’s transparency articles.
Incorporate transparency records into your DPIA or a dedicated AI governance appendix.

Transparency is the safeguard for limited risk AI. When users understand when AI is involved, how it works, and what it cannot do, most of the compliance risk disappears.

A Practical Example: Microsoft 365 Copilot

Microsoft 365 Copilot illustrates limited risk AI in action. Microsoft 365 Copilot would typically fall within the limited-risk category when used for general productivity tasks, but classification may change depending on context (for example, HR decision-making could raise the risk level). It operates inside familiar tools such as Word, Outlook, Excel, and Teams, using the organisation’s existing data. Copilot is not creating a new dataset, but it changes how that data is accessed and used.

DPOs can approach Copilot systematically:

Map the data flow. Identify what sources Copilot draws from. Most will already be governed under GDPR.
Determine the risk tier. Copilot’s summarisation and drafting features fall within the limited risk category.
Ensure transparency. Provide staff training and internal guidance making it clear that Copilot uses AI and that outputs require human review.
Verify supplier compliance. Keep copies of Microsoft’s documentation on Copilot’s AI model, transparency commitments, and security measures.
Reassess periodically. If Copilot is later used in HR or decision-making contexts, reclassify it as high risk, if applicable, and expand governance accordingly.

Copilot is a good example of how limited risk AI sits inside existing compliance frameworks. The AI layer does not replace GDPR obligations; it adds a transparency layer on top.

Managing Vendors and Third-Party AI

AI governance does not end with in-house systems. Third-party vendors and cloud providers are increasingly embedding AI functionality into standard software packages. DPOs need to know what these systems are doing and how they fit into the organisation’s risk profile.

Practical supplier governance steps include:

Updating vendor due diligence questionnaires to include AI-specific questions.
Requiring suppliers to disclose whether their systems use AI and, if so, how they classify it under the EU AI Act.
Ensuring contracts contain obligations for transparency and notification of material changes in functionality.
Reviewing third-party privacy notices to check alignment with your organisation’s transparency commitments.

This supplier awareness is critical because many limited risk systems will enter the organisation indirectly through updates or integrated features. A question as simple as “Does this system now use AI?” should become part of routine vendor management.

Combining AI Risk Assessment with DPIAs

AI risk assessments and GDPR DPIAs often apply to the same technology. Running them separately wastes time and risks inconsistency. A combined assessment provides a single, coherent record of compliance.

A practical two-in-one approach looks like this:

Begin with your existing DPIA template.
Add an AI section that determines the system’s risk tier under the EU AI Act.
Cross-reference overlapping controls, such as fairness, accuracy, and human oversight.
Record your rationale for classification and any transparency measures applied.

This combined model makes your documentation more efficient and defensible. It also shows regulators that the organisation is integrating AI governance within established privacy processes rather than treating it as a siloed exercise.

You do not need separate compliance tracks for AI and data protection. A single integrated DPIA with an AI addendum provides a clear, practical, and efficient approach to governance.

Building a Culture of Transparency and Awareness

AI compliance is not just a technical task. It depends on awareness across the organisation. Many risks arise not from deliberate misuse but from lack of understanding about where AI is operating.

DPOs can help by:

Training staff to recognise when systems might use AI and how to disclose it.
Including AI awareness in induction and refresher compliance training.
Providing a clear reporting route for staff who introduce new AI tools or discover them within existing systems.
Encouraging open discussion about AI ethics and bias without creating a culture of fear.

A culture of awareness ensures that AI deployments are surfaced early, documented properly, and reviewed for transparency obligations before they create regulatory problems.

The Case for Public AI Transparency Policies

Every organisation using AI should have a concise AI Transparency Policy available to the public. While not required by the EU AI Act, publishing a short AI transparency statement is a good practice for accountability and public trust. This policy communicates the organisation’s position, shows leadership, and demonstrates accountability in a visible way.

A strong policy should:

Outline what types of AI systems are used and for what purpose.
Describe how each category is governed and classified under the EU AI Act.
Explain how transparency and fairness are maintained.
Provide a contact route for questions or concerns.

For user-facing services, an AI indicator icon or short disclosure note linking directly to the policy can make transparency tangible. This approach mirrors cookie banners and privacy notices, ideally short, accessible, and visible.

Transparency builds confidence. A clear policy and visible AI indicator show that the organisation is proud of its responsible practices rather than hiding them in small print.

Questions to Ask in Governance and Board Meetings

Board and compliance meetings are where accountability becomes visible. Directors and senior managers do not need to be AI experts, but they should know how to ask the right questions. These conversations build oversight and reinforce the organisation’s duty to monitor risk.

Useful questions include:

Do we have a current and published AI Transparency Policy?
Is there an AI systems register, and who maintains it?
What models or third-party tools are currently in use across our environment?
Do we ask suppliers to confirm whether their products include AI components or use third-party models?
Have our DPIA templates been updated to include AI classification and transparency checks?
Who reviews risk classifications and re-evaluates systems as they evolve?
How do we communicate AI use internally to staff and externally to clients or regulators?

Governance is not about knowing every detail of how AI works. It is about asking questions that reveal whether proper control and understanding are in place.

Regularly reviewing these questions in board meetings keeps AI governance aligned with other corporate risks. It also creates an audit trail showing active oversight which is a powerful indicator of accountability.

Roles and Accountability in AI Oversight

AI governance often sits across several functions. DPOs manage data protection, CISOs handle security, legal teams address contractual risk, and IT manages deployment. For many organisations, the best approach is to establish a cross-functional AI governance group.

This group should:

Meet periodically to review the AI systems register and any new implementations.
Ensure consistent interpretation of risk classification.
Align AI oversight with broader risk frameworks such as ISO 27001, NIST AI RMF, or internal ethics committees.
Report key findings to senior management and the board.

A shared model of accountability prevents gaps and ensures that AI risks are addressed from both ethical and operational perspectives.

Looking Ahead: The Future of AI Governance

The EU AI Act is the first comprehensive AI regulation, but it will not be the last. Global frameworks are converging. The NIST AI Risk Management Framework, OECD principles, and upcoming UK AI Assurance Guidance all reinforce similar ideas: risk-based classification, transparency, human oversight, and accountability.

Organisations that build governance structures now, even for minimal and limited risk AI, will be well positioned as new standards evolve. The European Commission’s AI Office, expected to oversee implementation, will likely emphasise documentation and transparency as core indicators of compliance maturity.

Future audits may ask to see your AI systems register, transparency policy, and evidence of staff awareness. Starting small, with minimal and limited risk systems, ensures that governance habits are already in place when oversight becomes more formal.

Bringing It All Together

The EU AI Act provides an opportunity, not a burden. For most organisations, compliance will not mean complex technical changes, but thoughtful governance and clear communication. The EU AI Act entered into force on 1 August 2024, with most obligations, including transparency rules for limited-risk AI, becoming applicable from 2 August 2026.

By classifying systems accurately, integrating AI risk assessment into DPIAs, maintaining a public transparency policy, managing supplier disclosures, and embedding awareness at all levels, DPOs and legal teams can meet the requirements confidently.

Minimal and limited risk AI may seem low on the regulatory ladder, but they represent the foundation of responsible AI use. Transparent documentation, consistent oversight, and honest communication will not only meet compliance expectations but also strengthen trust, with clients, employees, and regulators alike.

Compliance done the right way is not about doing everything; it is about doing the right things properly, documenting them clearly, and being open about how technology is used. That is how ethical organisations turn regulation into a mark of integrity.

Cross-Border Transfers for DPOs

Posted on October 9, 2025April 9, 2026 by Philipa Jane Farley, Head of Legal and Operations

This article accompanies Hour 2: Cross-Border Transfers in our full-day CPD programme on XpertAcademy. Completion of the full one-hour session, including the related learning materials, contributes to the one-hour CPD certificate issued for that session. You can access the course here: CPD Event A: Full-Day Regulatory Privacy Training.

Practical DPO Perspective

Cross-border transfers are often presented as a narrow legal issue: identify the transfer, select a mechanism, insert the clauses, and move on. That is not how this works in practice. For most organisations, the real weakness is not a complete absence of legal awareness. It is that the underlying transfer analysis is often shallow. The organisation may know that international transfers are regulated, but still fail to answer the questions that actually matter:

what is the transfer scenario?
who is receiving the data in practice?
where can it be accessed from?
is the data intelligible in the destination jurisdiction?
what, if anything, do the safeguards materially change?
and can the organisation stand over the position it has taken?

From a DPO perspective, this is where the issue becomes real. Cross-border transfers are not just about Chapter V. They are a practical test of whether the organisation understands its systems, its vendors, its dependencies and its own governance.

The first mistake is often getting the transfer analysis wrong

A surprising amount of poor transfer analysis starts too late. The organisation moves quickly to SCCs, adequacy or template wording before it has properly identified what the transfer actually is. That matters because not all overseas access scenarios are the same.

A temporary employee working remotely while travelling is not necessarily the same as engaging a contractor established in a third country to access internal systems. A cloud platform hosted in the EEA is not the same as a connected service extracting data from that platform and processing it through its own US-based infrastructure. A support arrangement allowing occasional limited troubleshooting access is not the same as routine privileged administrative access from outside the EEA.

Those distinctions are not technical trivia. They shape the legal analysis. For DPOs, the first step is therefore not “Which clauses do we need?” It is “What exactly is happening here?” That means understanding:

who the recipient is
whether they are acting as processor, controller or contractor
whether the data is merely transiting, being stored, or being accessed remotely
whether the access is occasional or routine
whether the recipient can view the data in clear text
whether sub-processors are involved
and whether the organisation is dealing with one transfer or a chain of transfers

If those facts are unclear, the rest of the analysis is likely to be weak. Organisations often map where data is hosted but not where it is accessed from. They identify the main vendor but not the sub-processor chain. They treat a tool as part of an existing compliant environment, even though the add-on service is operating outside that perimeter altogether. They also tend to collapse very different overseas access scenarios into one generic “international transfer” label, which obscures the real legal and operational distinctions.

Consider reviewing whether your transfer mapping distinguishes between:

storage and remote access
employees and third-country contractors
primary vendors and sub-processors
core platforms and connected tools
occasional support access and ongoing operational access
pseudonymised or encrypted data versus data readable in clear text

International transfer exposure often turns on facts that are not visible at policy level. The organisation should distinguish between different access and hosting scenarios rather than treating all overseas processing as a single generic issue. Weak factual analysis leads to weak transfer decisions.

SCCs are often used as a substitute for thinking

Standard Contractual Clauses remain important and, in many cases, necessary. But they are often treated as though they answer more than they actually do.

They do not tell you whether the recipient can access intelligible data.
They do not tell you whether local law may undermine the level of protection expected under EU law.
They do not tell you whether the provider’s support model materially changes the risk.
They do not tell you whether the organisation has understood the actual architecture of the service.

That is why Schrems II mattered so much in practice. It did not make SCCs irrelevant. It made it harder to pretend that contractual wording alone resolves the issue. For DPOs, this is one of the most important mindset shifts. SCCs are not the conclusion. They are the legal vehicle through which the transfer may be supported, provided the surrounding facts and safeguards make that supportable. The real assessment still has to ask:

what legal environment is the recipient subject to?
what categories of data are involved?
can the provider or authorities access the data in intelligible form?
what technical and organisational measures exist?
what changes if those measures fail or are bypassed?

A signed set of SCCs without that analysis is not a strong position. It is often just a neat-looking file. A recurring problem is the belief that if the vendor is well known, the DPA is polished, and SCCs are attached, the organisation has done enough. In reality, that often means the organisation has documented the mechanism without properly assessing the transfer. Some TIAs then repeat generic language about safeguards while saying very little about how the service actually operates, what the provider can see, or what risk remains if the provider handles the data in clear text. Check whether your transfer analysis goes beyond “SCCs are in place”, generic vendor assurances, high-level statements about security, and broad claims of compliance unsupported by service-specific facts.

For example ask instead:

can the recipient access the data in clear text?
what practical difference do the safeguards make?
what do we know about the provider’s support and access model?
if challenged, could we explain why this transfer remains supportable?

Standard Contractual Clauses should not be treated as a substitute for substantive assessment. The presence of SCCs does not remove the need to understand provider access, destination-country risk, intelligibility of the data and the practical effect of safeguards.

A TIA is only useful if it forces the right factual questions

A Transfer Impact Assessment is often described as a compliance requirement. That is true, but it is not the most useful way to think about it. A good TIA is a disciplined way of forcing the organisation to confront the underlying facts of the transfer and to document the judgement it has made. It should ask, at a minimum:

what data is involved?
how sensitive is it?
who receives it?
where do they operate?
what access do they have in practice?
is the data intelligible at the point of access?
what laws in the destination jurisdiction matter?
what measures reduce the exposure?
and what residual risk remains?

That is what makes a TIA valuable. It is not simply an internal paper trail. It is a mechanism for converting abstract legal obligations into a decision the organisation can actually defend. This is particularly important for DPOs because weak TIAs tend to fail in the same way: they contain the right headings, but the wrong depth. They reproduce a compliance vocabulary without showing the reasoning that matters. If a TIA never meaningfully addresses whether the provider can view the data in readable form, whether the provider’s support staff are outside the EEA, or whether the sub-processor chain alters the risk, then it is not doing the real job.

The most common weaknesses are boilerplate analysis, late-stage completion, and poor connection to procurement or design decisions. TIAs are often produced after the commercial decision is already made, using generic wording that could apply to almost any vendor. That gives the appearance of control while leaving the actual decision-making unexamined. Review a small sample of your TIAs and ask:

do they describe the actual service or just the generic transfer issue?
do they identify who can access the data and in what form?
do they distinguish between technical safeguards that genuinely reduce risk and those that do not?
do they record any limits, conditions or follow-up actions?
would the document still make sense to a regulator reading it cold?

A TIA is useful only if it captures the factual and legal reasoning behind the transfer. Boilerplate assessments create the appearance of assurance without showing that the organisation has meaningfully understood the provider, the data exposure or the residual risk.

AI and connected tooling are where organisations most easily lose control

If traditional transfer analysis was already difficult, AI-enabled services have made it harder. The challenge is not simply that AI tools may process data outside the EEA. It is that the processing chain is often less transparent, the sub-processor landscape is broader, and the customer may have less visibility over retention, reuse, support access and model-related processing than they assume. This is where a transfer analysis that looks acceptable on paper can become weak very quickly.

An organisation may believe it is operating inside a controlled environment, for example through an EU-hosted collaboration or productivity suite. But if a connected AI-enabled service extracts transcripts, recordings or other content from that environment and processes it through its own infrastructure, then the original boundary is no longer the key point. The real question becomes what happens once the data leaves that environment, who can access it, and under what conditions.

That is where DPOs need to be particularly careful. In an AI context, the transfer issue is not just where the data goes. It is whether the organisation retains meaningful visibility and control once the data enters that processing environment. That means asking harder questions:

is the tool using third-country infrastructure?
is prompt, transcript or content data retained?
is it available for model improvement, troubleshooting or analytics?
who are the relevant sub-processors?
can humans at the provider access the data?
is the data encrypted only in transit and at rest, or is it still intelligible during processing?
does the organisation understand the real boundaries of the service?

These are not optional refinements. They go to the heart of whether the transfer analysis is credible.

What we repeatedly see is governance lag. AI-enabled tools are deployed because they are useful, fast and embedded into everyday work. The privacy analysis then follows behind, often relying on assumptions that do not survive closer scrutiny. Organisations also tend to overestimate what “EU-based” marketing language means, particularly where the service depends on broader support, model or sub-processing arrangements.

Schedule a review:

which AI-enabled tools or integrations are already active
whether they extract or replicate personal data from existing systems
whether they introduce non-EEA processing or access
whether the service terms permit retention, analytics or reuse
whether your TIAs and vendor reviews are specific to the AI functionality rather than the core platform alone

AI-enabled services can materially weaken transfer visibility and increase accountability burden. Their use may involve non-obvious processing chains, third-country infrastructure, multiple sub-processors and reduced customer control. These tools should be assessed as transfer and governance issues, not just as productivity features.

This is also a third-party oversight issue, and in some sectors a resilience issue

Cross-border transfers are often kept within the privacy silo. In practice, they overlap heavily with vendor governance, outsourcing oversight and, in regulated sectors, broader operational resilience concerns. If a critical or hard-to-replace provider stores or accesses personal data outside the EEA, the issue is not simply whether there is a lawful mechanism in place. It is also whether the organisation has enough visibility, assurance and control over that provider relationship. That is why transfer governance should not sit apart from wider third-party review. A provider may at the same time be:

a material processor of personal data
an important operational dependency
a source of concentration or substitution risk
and a point of exposure because of non-EEA access or sub-processing

Where those issues are reviewed in separate silos, the organisation can end up with a legally tidy but operationally weak position. For DPOs, this matters because the transfer analysis is often only as good as the information the organisation has about the vendor. If that visibility is poor, the privacy conclusion will usually be weaker than it appears. This is particularly relevant in financial services and other regulated environments, where transfer governance may support broader expectations around supplier oversight, dependency management and evidence of control. It does not need to become a DORA article to make that point. It just needs to recognise that the same provider relationship may matter for several governance reasons at once.

A common failure point is fragmentation. Procurement reviews the contract. IT reviews the implementation. Risk reviews continuity. Privacy reviews the DPA. But no one joins that into a coherent view of how the provider actually operates, how dependent the organisation has become, and whether the privacy analysis still holds if service conditions change.

Questions to ask:

which providers are operationally significant as well as privacy-relevant
whether transfer review is linked to vendor governance and oversight
whether changes in hosting, support model or sub-processors are captured and escalated
whether board reporting on critical third parties includes material transfer exposure where relevant

International transfers may also expose wider third-party and resilience weaknesses. Where a provider is operationally important and processes personal data outside the EEA, the organisation needs not only a lawful mechanism but sufficient visibility and control over that dependency.

For DPOs, the real issue is whether the organisation can defend the position it has taken

The mature question in this area is not “Do we know that cross-border transfers are regulated?” Most organisations do. The more important question is whether the organisation can explain, with evidence, why it believes a given transfer is supportable. That requires more than awareness of the law. It requires enough understanding of systems, vendors and governance to connect the legal mechanism to the real operational facts. It requires TIAs that reflect the actual arrangement rather than generic precedent. It requires challenge where the business assumes that a contract or a familiar vendor name resolves the issue. And it requires senior reporting that turns transfer risk into something visible rather than theoretical.

That is why cross-border transfers are such a useful measure of programme maturity. Where the organisation gets this right, it usually indicates something broader: joined-up governance, stronger vendor control, clearer ownership and a privacy programme that can translate legal standards into defensible decisions. Where it gets this wrong, the same pattern usually appears elsewhere too.

The real difficulty is rarely total ignorance. It is fragmented ownership, weak operational visibility and analysis that is neater than it is deep. Privacy teams may know the law, but not have enough visibility into real access patterns, vendor architecture or AI-enabled data flows to challenge the business properly.

To combat this, ask:

who owns transfer mapping in practice?
who signs off TIAs and on what basis?
how are changes in tools, vendors or support arrangements identified?
can the organisation distinguish between compliant documentation and defensible analysis?
could it explain the position clearly to a regulator or auditor if required?

Cross-border transfer compliance is a practical test of governance maturity. It shows whether the organisation can convert legal requirements into evidence-based decisions, meaningful supplier oversight and a position that can be defended if challenged.

Final thoughts

Cross-border transfers are not difficult because the law is obscure. They are difficult because they expose whether the organisation has really understood its own operating model. For DPOs, that is the key point. This is not ultimately about inserting clauses into contracts or reciting Schrems II. It is about identifying where the data goes, who can access it, what the technical and organisational reality looks like, and whether the organisation can justify the conclusion it has reached. That is what makes transfer compliance useful. It does not just test legal knowledge. It tests whether privacy governance is actually working.

This article is intended to support the learning covered in Hour 2 of our XpertAcademy CPD programme. The relevant CPD certificate is issued for completion of the full one-hour session on XpertAcademy, rather than for reading this article on its own. You can return to the course here: CPD Event A: Full-Day Regulatory Privacy Training.