Your Arc Towards
Compliance

By EthicArc  ·  March 2026  ·  8 min read

The privacy compliance function has always been document-heavy, time-sensitive, and prone to human error. Data Subject Access Requests arrive with 30-day deadlines. Records of Processing Activities grow stale the moment a new vendor is onboarded. KPI dashboards get updated manually, quarterly, if at all. AI agents are beginning to change all of that — not by replacing privacy professionals, but by automating the mechanical work that consumes most of their time.

What is a compliance AI agent, exactly?

A compliance AI agent is a purpose-built software component that can perceive inputs (emails, form submissions, database entries, system logs), reason about them in the context of a defined process, and take actions — drafting responses, updating records, flagging anomalies, or escalating to a human reviewer. Unlike traditional automation tools, agents can handle variability: a DSAR that asks for data in an unusual format, a vendor onboarding form with missing fields, a processing activity that does not fit neatly into an existing category.

The key word is configured. These agents are not general-purpose AI systems. The most effective implementations are narrowly scoped, deeply integrated with your existing platforms (OneTrust, ServiceNow, your HRMS), and governed by clear human oversight protocols.

Automating Data Subject Access Requests (DSARs)

DSARs are the compliance function most obviously suited to agent automation. The process is structured, repetitive, and deadline-bound. A well-configured agent can:

• Receive and validate the identity of the requester against defined verification criteria
• Query connected systems — CRM, email archives, marketing platforms, HR systems — to locate all personal data belonging to the individual
• Compile a structured response package, deduplicate results, and flag third-party data that requires separate handling
• Route the compiled package to a human reviewer for final sign-off before dispatch
• Track the deadline and escalate if the response window is at risk

Organisations processing more than 50 DSARs per month typically see a 60–70% reduction in manual processing time after implementation. More importantly, they see fewer missed deadlines and more consistent, auditable responses.

Keeping your RoPA current with automated data discovery

The Record of Processing Activities is arguably the most chronically out-of-date document in most organisations' compliance programmes. It is typically built once, reviewed annually, and quietly drifts further from reality every time a new SaaS tool is procured or a data flow is modified.

AI agents address this by integrating with asset discovery and CMDB systems. When a new application is detected on the network, the agent cross-references it against the existing RoPA, identifies the probable processing activities (based on the application category and vendor), and either auto-populates a draft entry for human review or flags the gap to the data protection team. The RoPA stops being a static document and becomes a living record that reflects the actual state of your data environment.

Surfacing compliance KPIs in real time

Most compliance dashboards are built on lagging indicators: DSAR completion rates for last quarter, audit findings from six months ago, training completion percentages as of last month. By the time the data reaches a board report, it is history.

Agents connected to your compliance platform can surface leading indicators in real time: the number of open DSARs approaching deadline, the percentage of processing activities last reviewed more than 12 months ago, the volume of vendor contracts without a current DPA, the risk score distribution across your AI system inventory. These are the metrics that allow a compliance team to act before problems become incidents.

What organisations need to get right before deploying

Agent deployment is not a plug-and-play exercise. The organisations that succeed with compliance automation share three characteristics:

1. Clean process design first. An agent will execute a flawed process at scale. Before automating any compliance workflow, document the current process, identify failure modes, and redesign it for consistency. Then automate.
2. Meaningful human oversight. Every agent output that affects a data subject or carries regulatory risk should pass through a human review step. The agent accelerates the work; the professional validates the outcome.
3. Integration depth. A DSAR agent that cannot query your actual data systems is a document tool, not a compliance tool. The value comes from integration — which requires IT involvement, API access, and data governance discipline.

The privacy function is not being automated away. It is being elevated. The professionals who thrive in this environment will be those who focus on the judgment, the strategy, and the stakeholder relationships that no agent can replicate.

By EthicArc  ·  March 2026  ·  6 min read

Early-stage companies are not trying to break privacy law. They are trying to build a product, find customers, and survive. Compliance gets scheduled for later — after the next funding round, after the first enterprise customer, after the team grows. By the time later arrives, the problems are expensive.

After working with dozens of startups across Europe, these are the five compliance failures we encounter most often.

1. Treating consent as a checkbox, not a legal mechanism

Consent under GDPR is one of the most misunderstood legal bases in practice. It must be freely given, specific, informed, and unambiguous. Pre-ticked boxes do not count. Bundling consent for multiple purposes does not count. Consent obtained as a condition of using a free service is routinely challenged.

Most startups deploy a cookie banner, add a "I agree to the terms" checkbox on signup, and consider the job done. Neither of those actions constitutes valid GDPR consent for marketing, profiling, or behavioural analytics. When an enterprise prospect sends a security questionnaire — or a regulator comes calling — the gap becomes very visible, very quickly.

The fix: Audit every consent touchpoint. For each one, confirm the legal basis, the specific purpose, and the mechanism for withdrawal. Where legitimate interests is the stronger basis, use it properly with a documented assessment.

2. No Record of Processing Activities

Article 30 of GDPR requires most organisations to maintain a record of processing activities. This is not optional, it is not just for large enterprises, and it is frequently the first document a supervisory authority requests in an investigation. Most startups either do not have one or have a template downloaded from the internet that bears no relation to their actual data flows.

A functional RoPA documents every processing activity: the purpose, the legal basis, the categories of data, the recipients, the retention period, and the technical and organisational security measures. It is a map of your data. If you cannot draw that map, you do not understand your compliance exposure.

3. Vendor contracts without Data Processing Agreements

If you share personal data with a third party that processes it on your behalf — your cloud infrastructure provider, your email marketing tool, your analytics platform, your AI API — you are legally required to have a Data Processing Agreement in place. The GDPR fine for Clearview AI in several European countries was partly anchored in the absence of proper contractual arrangements with data processors.

Startups routinely use 15–30 SaaS tools without checking whether a DPA exists, whether the vendor's standard DPA is adequate, or whether sub-processors are disclosed. When a B2B customer's legal team reviews your security and compliance posture, this list of gaps is exactly what they find.

4. Building AI features without an EU AI Act assessment

The EU AI Act came into force in 2024 and its obligations are phasing in through 2026 and 2027. Startups building AI-powered features — recommendation engines, automated decision tools, risk scoring, content moderation — are already in scope for some of these obligations, particularly around transparency, human oversight, and prohibited practices.

The intersection with GDPR matters too. Automated decision-making under Article 22 GDPR gives individuals the right not to be subject to decisions based solely on automated processing if those decisions produce significant effects. Many AI features in startup products trigger this provision without the team realising it.

5. Assuming a privacy policy is enough

A privacy policy is a transparency document. It tells users what you do with their data. It does not constitute a compliance programme. It does not demonstrate lawful processing, secure systems, staff training, incident response capability, or vendor management. It is one document among many that a compliant organisation needs to maintain.

The encouraging reality is that getting these five things right is not particularly expensive or time-consuming for an early-stage company. The cost of doing it properly at the start is a fraction of the cost of retrofitting it later — or defending an enforcement action.

By EthicArc  ·  March 2026  ·  7 min read

In most organisations, privacy and AI compliance is notionally owned by the legal or DPO function. The technical implementation — data architecture, system access controls, AI model governance, vendor integrations — lives in IT or engineering. Between these two functions sits a gap that is rarely named but almost universally present.

Legal drafts a data retention policy. IT cannot implement it because the policy does not map to how data is actually structured across their systems. IT builds an AI model that processes employee data. Legal is not consulted until the model is already in production. The DPO issues a DPIA template. Engineering has never heard of a DPIA and does not know when or why to complete one.

This is not a failure of individuals. It is a structural problem — and it is the reason most AI compliance programmes look better on paper than they perform in practice.

Why the gap exists

Legal and compliance professionals are trained to think in terms of obligations, risk thresholds, and documentation. They produce policies, contracts, and assessments. Their frame of reference is the regulation.

IT and engineering professionals are trained to think in terms of systems, data flows, and technical constraints. They produce architecture, code, and configurations. Their frame of reference is the product.

Neither of these frames is wrong. But they generate different vocabulary, different timelines, and different definitions of "done." A DPIA is complete when the DPO signs it off. The same DPIA is meaningless if the engineering team that built the system was not involved in identifying the actual risks.

Where it breaks down in AI specifically

AI introduces several dynamics that make the gap worse:

• Model opacity. Many AI systems — particularly those using large language models or complex ML pipelines — are difficult to explain in plain language. Legal needs to understand what the system does in order to assess its compliance risk. Engineering finds it difficult to translate model behaviour into the terms legal needs. The result is often a compliance assessment that describes the intended use rather than the actual operation.
• Data lineage complexity. Training data, inference data, and output data in an AI system may flow through multiple systems, be processed by multiple vendors, and be retained in multiple locations. Tracing that lineage for a DPIA or a DSAR requires technical knowledge that most DPOs do not have and cross-functional coordination that most IT teams are not set up to provide.
• Speed of change. AI systems are updated frequently — model versions, prompt engineering changes, new training data. Each change may have compliance implications. Legal review cycles are not designed for continuous deployment. The compliance posture of an AI system assessed six months ago may bear little resemblance to the system running today.

The organisational interventions that actually work

Closing this gap requires structural changes, not just communication improvements. The organisations that manage it well share several characteristics:

Privacy by design embedded in development workflows

Rather than compliance reviews happening after features are built, DPIA triggers and data classification requirements are embedded into the development process — sprint planning, pull request templates, architecture review boards. Privacy becomes a development concern, not a post-launch one.

Technical DPO capability or a bridge role

Some organisations are solving this by hiring DPOs with technical backgrounds, or by creating a dedicated "privacy engineer" role that sits between the two functions. This person speaks both languages — they understand the regulation and they understand the data architecture. They can translate legal requirements into technical specifications and flag technical risks in compliance terms.

Shared tooling

When legal manages compliance in a document repository and IT manages systems in a CMDB with no connection between them, coordination is manual and unreliable. Compliance platforms that integrate with IT asset management systems — so that a new data processing activity triggers a compliance workflow automatically — remove the dependency on individual people remembering to communicate across functions.

A practical starting point

If you are trying to close this gap in your organisation, start with a single process — DPIA completion for new AI features — and map the current state in detail. Who initiates it? Who contributes to it? Where does information get lost between functions? What decisions are made without the right input? The answer to those questions will tell you exactly where to intervene first.

By EthicArc  ·  March 2026  ·  9 min read

When the EU AI Act was passed, many compliance teams added it to their list of regulations to address — separately from GDPR, with its own workstream, its own timeline, and its own documentation. This is understandable but strategically inefficient. The two regulations share significant ground, and the organisations that navigate both most effectively are the ones that treat their AI and privacy compliance programmes as a single integrated effort.

Where the regulations overlap

The overlap is more extensive than most compliance teams initially appreciate. At a high level, both regulations share:

• Risk-based approaches. GDPR requires Data Protection Impact Assessments for high-risk processing. The AI Act requires Conformity Assessments for high-risk AI systems. The risk assessment methodologies are different in detail but share a common logic: identify potential harms, assess likelihood and severity, implement mitigations, document the process.
• Transparency obligations. GDPR requires you to inform individuals when their data is used in automated decision-making. The AI Act requires transparency when individuals interact with AI systems, particularly in high-risk categories. In many use cases — AI-powered credit scoring, automated recruitment screening, risk profiling — both obligations apply simultaneously.
• Human oversight requirements. Article 22 GDPR gives individuals the right to request human review of automated decisions. The AI Act mandates human oversight mechanisms for high-risk systems. These are distinct rights with distinct mechanisms, but they often require the same organisational capability: the ability to pause, review, and override AI-generated outputs.
• Data governance. High-quality training data is both a GDPR obligation (where training data contains personal data) and an AI Act requirement (for high-risk systems, data governance and training data documentation are explicit requirements). A single data inventory and data classification programme can serve both.

The key distinctions you need to understand

The overlap does not mean the regulations are the same. There are important differences that your compliance programme needs to account for.

The AI Act is risk-category-based. An AI system is classified as unacceptable risk, high risk, limited risk, or minimal risk based on its application domain. Your GDPR obligations, by contrast, apply to any processing of personal data regardless of the system performing it. A low-risk AI system that processes personal data still carries the full weight of GDPR.

The AI Act has supply chain implications that GDPR does not directly address in the same way. Providers of high-risk AI systems — the companies that build and sell them — have obligations that are distinct from those of deployers — the organisations that use them. If you are deploying a third-party AI system in a high-risk category, you have specific due diligence obligations toward your provider that go beyond the standard DPA you would need under GDPR.

The AI Act introduces technical documentation requirements — system architecture, training data descriptions, performance metrics, known limitations — that have no direct equivalent in GDPR. Your legal team alone cannot produce this documentation. It requires engineering input.

Building a unified compliance programme

The practical implication of the overlap is that you can avoid significant duplication of effort by designing your compliance programme to serve both regulations simultaneously. A few concrete examples:

A unified AI system inventory

You need an inventory of AI systems for both regulations. For GDPR, this inventory feeds into your RoPA (where systems process personal data). For the AI Act, it is the foundation of your risk classification exercise. Maintain one inventory, with fields that serve both purposes — rather than two separate registers that drift out of sync.

Integrated impact assessments

For AI systems that process personal data and fall into a high-risk AI Act category, a single integrated assessment document can satisfy the core analytical requirements of both the DPIA and the Conformity Assessment. The risk identification sections overlap substantially. The mitigation measures often address both sets of obligations. The documentation effort is significantly less than running two separate processes.

Aligned transparency notices

When individuals interact with an AI system that processes their personal data, you may need to satisfy GDPR transparency obligations (informing them about automated decision-making) and AI Act transparency obligations (informing them they are interacting with an AI system) simultaneously. Design your user-facing communications to address both — rather than producing separate notices that confuse users and create inconsistencies.

Timeline considerations for 2026

The AI Act obligations that are most immediately pressing for most organisations are the prohibitions on unacceptable-risk AI practices (already in force), the obligations for general-purpose AI model providers, and the transparency requirements for limited-risk systems. High-risk system obligations for most sectors apply from August 2026. Now is the right time to complete your AI system inventory, classify your systems, and build the compliance infrastructure — before the deadlines arrive, not after.

The good news is that if your GDPR programme is reasonably mature, you have more of the foundation in place than you might think. Data inventories, impact assessment processes, vendor management frameworks, and governance structures are all transferable. The AI Act adds new dimensions to these capabilities — it does not replace them.