GDPR compliance for AI agents in enterprise back-office operations is more tractable than many ops teams expect, but it requires deliberate design choices that need to be made before the first agent goes live, not after. This post covers the specific obligations that apply when MicroAGI agents process personal data, the choices we made in how MicroAGI is built to support GDPR compliance, and the checklist we follow with EU customers to ensure their deployment meets the requirements.
We are based in Berlin. Our infrastructure runs in Germany and the EU. GDPR compliance is not something we approach as a checkbox for US-designed software; it is our default operating context. That shapes every design decision we make about how data flows through the platform.
When Do AI Agents Process Personal Data?
Not all back-office automation involves personal data. An agent that reads purchase orders, matches line items, and posts to a general ledger account may process no personal data at all. An agent that handles employee expense reports, vendor onboarding, or IT ticket routing very likely processes personal data as part of normal operation.
Under GDPR, "personal data" is any information relating to an identified or identifiable natural person. For back-office workflows, the relevant categories are typically: employee data (names, email addresses, employee IDs, salary information in expense or payroll contexts), vendor contact data (the name and contact details of the person at the vendor company submitting documentation), and any data about customers that appears in support tickets or CRM records.
The legal basis question comes first: under which GDPR Article 6 basis is the processing lawful? For employee data processed as part of HR or finance operations, Article 6(1)(b) (necessary for the performance of a contract) or 6(1)(c) (necessary for compliance with a legal obligation) typically applies. For vendor contact data used to manage a commercial relationship, 6(1)(b) or 6(1)(f) (legitimate interests) usually applies. The basis needs to be documented in your Record of Processing Activities (RoPA) under Article 30.
Article 30: Recording the Agent as a Processing Activity
Every time you deploy a MicroAGI agent that processes personal data, that deployment is a new or updated processing activity that needs to be documented in your RoPA. The record needs to include: the purpose of the processing, the categories of data subjects and personal data, the recipients (including any sub-processors), the data retention period, and the technical and organizational security measures.
For a MicroAGI deployment, the sub-processor relationship is between your organization (controller) and MicroAGI GmbH (processor). We provide a Data Processing Agreement (DPA) under Article 28 for all Enterprise customers. The DPA covers the required provisions: scope and purpose of processing, instruction binding, confidentiality, security measures, sub-processor management, data subject rights assistance, deletion or return of data, and audit rights.
If you are on the Starter or Team plan and need a DPA for GDPR compliance purposes, contact us at [email protected]. We recognize that GDPR obligations do not scale with subscription tier.
Data Minimization and Purpose Limitation
GDPR Article 5 requires that personal data be processed only for specified, explicit, and legitimate purposes, and only to the extent necessary for those purposes. For agent workflows, this has practical implications for how workflows are designed.
An agent that processes vendor onboarding forms should extract only the fields it needs to create the vendor record in the ERP. It should not retain the full scanned vendor registration document in a log that is accessible to everyone with workspace access. The run trace should show that the document was processed and what data was extracted; it does not need to store the full document as an attachment.
We have built configurable data retention policies into MicroAGI specifically because of this requirement. You can configure the platform to automatically purge run trace data after a defined period, with granularity by workflow and data category. The retention period in the trace should match the retention period you have documented in your RoPA for that processing activity.
Data Subject Rights and Agent Workflows
GDPR provides data subjects with rights including the right to access, rectification, erasure, and objection. For agent workflows, the practical implication is that if an employee or vendor asks you to provide all personal data held about them, or asks you to delete their data, you need to be able to act on that request across all systems where their data lives, including the MicroAGI run traces.
MicroAGI provides workspace admins with the ability to search and export run trace data by data subject identifier (typically an email address or employee ID) and to delete trace records for a specific data subject. This supports your response to Subject Access Requests (SARs) and erasure requests without requiring you to contact us for each individual request.
One nuance: run traces that are part of a financial audit trail may have a legal basis for retention that overrides an individual's erasure request. Article 17(3)(b) allows you to refuse erasure when the processing is necessary for compliance with a legal obligation. If you retain run traces as part of an accounting or audit process, document that retention basis in your RoPA and in any response to an erasure request.
Technical and Organizational Measures
GDPR Article 32 requires that controllers and processors implement appropriate technical and organizational measures to ensure security appropriate to the risk. For MicroAGI:
Data in transit is encrypted using TLS 1.3. Data at rest is encrypted using AES-256. All processing and storage occurs on infrastructure in Germany, within EU jurisdiction. Access to customer data within MicroAGI is restricted to personnel who need access for the provision of the service, with access logging. We do not use customer run trace data for model training.
At the organizational level, MicroAGI enforces role-based access controls at the workspace level. Workspace admins control who can view run traces, who can approve flagged steps, and who can modify workflow definitions. All authentication events are logged in the audit trail. Session management includes configurable session timeout and IP allowlisting for Enterprise workspaces.
Cross-Border Data Transfers
If you use MicroAGI agents to process data that includes personal data about EU data subjects, and any of the tools the agent calls are hosted outside the EU, you need to assess whether those tool calls constitute a cross-border data transfer subject to GDPR Chapter V restrictions.
The most common scenario: an agent workflow that calls a US-hosted SaaS API (Salesforce, HubSpot, Zendesk) and passes personal data as part of the API call. Each of these vendors should have Standard Contractual Clauses (SCCs) in their DPA, which provides the appropriate safeguard for the transfer. Before deploying any workflow that passes personal data to a non-EU tool, verify that the tool has an EU-compatible DPA with SCCs in place and that you have executed it.
This is not a MicroAGI-specific requirement. It is a GDPR requirement that applies to any data processing chain that involves non-EU processors. The fact that an AI agent is making the API call rather than a human does not change the transfer assessment.
Our Practical Checklist
For any MicroAGI workflow that processes personal data, we recommend the following before going live:
First, identify the personal data categories processed and the legal basis for processing under Article 6. Second, update your RoPA to include the new processing activity with MicroAGI GmbH as a sub-processor. Third, execute the MicroAGI DPA if you have not already. Fourth, configure data retention periods in the workspace to match your documented retention basis. Fifth, verify that any non-EU tools the workflow calls have EU-compatible DPAs with SCCs. Sixth, test the data subject access and deletion functionality with a test data subject before the workflow processes real data.
None of these steps is particularly complex once you know what they are. The complexity is in knowing that they apply, and in having the organizational processes in place to execute them. If your team needs support with the GDPR aspects of a MicroAGI deployment, we are happy to work through it with you. Contact us at [email protected].
