EU AI Act vs GDPR: which to pursue first when AI runs on personal data
If your organization deploys or builds AI that processes personal data in the EU, both laws usually apply at once. The GDPR already governs the personal data your system uses, so its obligations come first in practice, and the AI Act adds system-level duties on top. Start with the GDPR, because it applies to the data regardless of what the AI system does. The GDPR requires no audit, attestation or certificate. Its Article 42 certification is voluntary, and it does not reduce your responsibility for compliance. The AI Act's high-risk duties, by contrast, depend on how the system is classified, so your first AI Act task is a documented classification decision for each system.
Prioritize the GDPR if your data flows are not yet mapped, your records of processing are incomplete, or a data protection impact assessment has not been done for the processing. Prioritize the AI Act classification if you are a provider placing a system on the EU market or a deployer of a system that may fall under Annex III. Confirm with counsel whether a given use is high-risk, and note that the 2026 amendment moved the high-risk dates to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I product systems. Check the current text of Regulation (EU) 2024/1689 as amended on EUR-Lex before you set internal deadlines.
Most teams should run one combined assessment process rather than two parallel files. A single intake form can capture the processing purpose, the categories of personal data, the affected people, the bias-detection data, and the provider information you need for your data protection impact assessment. Then map each AI Act deliverable to a GDPR record, so the same evidence serves both. DeployOpen can plan that process, prepare the technical evidence and documentation, and support your internal reviews, but it does not certify your systems or issue audit reports. Independent auditors and supervisory authorities make those determinations, so ask any partner to state clearly what it will deliver.
How the AI Act and the GDPR differ on scope, proof and enforcement
This table compares the two EU laws on what each regulates, who it covers, the proof it produces, its fine tiers and its enforcers. Read it as a map of where the AI Act points back to the GDPR, so you can see which obligations need separate evidence and which can share one assessment file.
| Factor | EU AI Act (Regulation (EU) 2024/1689) | GDPR (Regulation (EU) 2016/679) |
|---|---|---|
| Subject matter | AI systems, classified by risk level | Processing of personal data, regardless of technology |
| Who is covered | Providers, deployers, importers and distributors of AI systems, including non-EU operators whose AI output is used in the EU | Controllers and processors that process personal data of people in the EU or EEA |
| Trigger | Placing an AI system on the EU market, or deploying one in the EU, that falls within a risk category | Processing of any personal data within the Regulation's territorial and material scope |
| Risk model | Four levels: unacceptable (prohibited), high, transparency and minimal or no risk | Risk-based duties scaled to the processing, with DPIAs required for high-risk processing |
| Proof produced | Conformity assessment, technical documentation and registration for certain high-risk systems, mostly by internal control | Records of processing, DPIAs and documented accountability; no audit, attestation or certificate required |
| Certificate available | Conformity assessment is required for some systems, and notified bodies are involved in certain biometric and Annex I cases | Article 42 certification is voluntary, lasts at most three years and does not reduce controller responsibility |
| Maximum fines (highest tier) | EUR 35 million or 7% of worldwide annual turnover for prohibited practices (Article 99) | EUR 20 million or 4% of worldwide annual turnover for breaches of core principles, lawful basis, rights and transfers (Article 83) |
| Maximum fines (middle and lowest tiers) | EUR 15 million or 3% for most operator obligations; EUR 7.5 million or 1% for misleading information to authorities | EUR 10 million or 2% for infringements such as Articles 25 to 39, including security and breach notification |
| Enforcers | National market surveillance authorities; the Commission's AI Office for general-purpose AI model rules and certain AI systems | Independent national supervisory authorities, coordinated by the European Data Protection Board |
Who each law applies to and when
Article 2 applies the AI Act to providers that place an AI system or general-purpose AI model on the EU market, wherever they are established. A provider is the party that develops a system, or has one developed, and places it on the market or puts it into service under its own name. For high-risk systems, most of the heavy obligations sit with the provider, including the conformity assessment that must be completed before the system reaches users.
- Market placement sets reach: Scope follows placing the system on the EU market, so your headquarters location alone does not settle whether the Act applies.
- Risk class sets the procedure: Most Annex III high-risk systems use internal-control conformity assessment under Annex VI, while notified bodies are involved for some biometric systems and Annex I products under Article 43.
- Dates depend on the annex: As amended in 2026, Annex III high-risk rules apply from 2 December 2027 and Annex I product systems from 2 August 2028.
- Standards are still arriving: The first harmonised standard, EN 18286:2026 on quality management, was cited in the Official Journal on 14 October 2026, so confirm which standards your conformity plan will rely on.
Check which annex your system falls under and read the consolidated AI Act text before setting your conformity timeline.
A deployer is an organization in the EU that uses an AI system under its own authority. Deployers carry their own duties even when they buy the system from someone else. Under Article 26, deployers of high-risk systems must use the system according to the provider's instructions, and Article 26(9) requires them to use the provider's information when carrying out GDPR data protection impact assessments.
- Use under your authority: A bank or hospital that configures and runs a vendor's system in its own operations is a deployer, even though the vendor built it.
- Public authorities register: Under Article 26(8), public authority deployers must register under Article 49 and must not use a system that is missing from the EU database.
- Impact assessments: As amended in 2026, Article 27 lets deployers cross-reference or include parts of a GDPR impact assessment, and the AI Office is to supply a questionnaire template. Confirm with counsel whether your use case triggers a fundamental rights impact assessment.
- Operational oversight: Deployer duties include human oversight and monitoring of the system in use, so assign named staff who can act on the system's outputs.
Ask your vendor for the instructions for use and the information you need for your impact assessments before go-live, and put those requests in the contract.
Article 2 also reaches non-EU providers and deployers whose AI output is used in the EU. A company with no EU office can fall under the Act if its system's output reaches people or decisions in the Union. Teams often assume that hosting outside the EU keeps them outside scope, and that assumption deserves a formal check.
- Output used in the EU: The test is whether the AI output is used in the EU, so the location of servers or the parent company does not decide scope on its own.
- Both roles can apply: A non-EU provider may carry provider duties while an EU customer carries deployer duties for the same system.
- Illustrative example: A screening tool hosted in the United States whose scores are used by an EU subsidiary to rank applicants would put the subsidiary in the deployer role (illustrative only).
- Local appointments: Confirm with counsel whether your role requires a representative or other appointment in the EU.
Map each place your outputs are used before you decide which timeline and obligations apply to your organization.
The GDPR does not regulate AI as such. It applies whenever an AI feature processes personal data, and the organization that decides why and how that data is processed is the controller. The GDPR has applied since 25 May 2018, binds all EU Member States directly, and also applies in Iceland, Liechtenstein and Norway under an EEA Joint Committee Decision that entered into force on 20 July 2018.
- Already in force: The GDPR was not amended as of October 2026, so its obligations apply to your AI feature today, alongside the AI Act.
- Controller and processor duties: Chapter IV sets out controller and processor obligations, including security of processing (Article 32) and breach notification (Articles 33 and 34).
- Transfers: Chapter V governs transfers to third countries, which matters when a model provider or hosting partner is located outside the EU.
- Pending changes: Omnibus IV (COM(2025) 501) has a text agreed on 26 June 2026 that awaits Parliament's first-reading vote, and the Digital Omnibus (COM(2025) 837) awaits a committee decision.
Confirm which legal entity is the controller for each AI feature, and track both omnibus procedures so your compliance plan keeps pace with any change.
The AI Act does not apply in one step. Its obligations phase in across several dates, and the 2026 amendment moved the high-risk dates later. The dates below follow Article 113 as amended, but the consolidated text is the document to rely on for contracts and project plans.
- 2 February 2025: Chapters I and II apply, covering definitions, AI literacy and prohibited practices.
- 2 August 2025: The general-purpose AI, governance, notified body and penalty chapters apply, except Article 101.
- 2 August 2026 (as amended): The rest of the Act applies, but the high-risk rules in Chapter III Sections 1 to 3 no longer start on this date.
- 2 December 2027 and 2 August 2028: High-risk rules apply to Annex III systems and Annex I product systems, respectively, in place of the earlier 2026 and 2027 dates.
Ask each vendor which phase applies to their system and when they will provide the evidence that phase requires, and check the consolidated AI Act text for final wording.
Where the AI Act points back to the GDPR
The AI Act does not replace the GDPR for AI deployed on personal data. Several of its provisions route work back into the GDPR data protection impact assessment (DPIA), so start by requesting the provider's information before any personal data enters the system. Article 26(9) requires deployers to use that information for their GDPR DPIAs. As amended in 2026, Article 27(4) and (5) let deployers cross-reference or include parts of a GDPR DPIA in their AI Act documentation, and they require the AI Office to develop a questionnaire template, including an automated tool. Confirm whether that template has been published, and build your DPIA so its sections can be lifted into it without rework.
Article 4a(1) adds data handling duties for bias detection. Where you process special categories of data to detect and correct bias, you must apply pseudonymization and state-of-the-art security, keep access controls strict and documented, avoid transfers to other parties, delete the data once the bias is corrected, and record the reasons for the processing in your GDPR records of processing. Article 50(3) covers deployers of emotion recognition or biometric categorisation systems. They must inform the people exposed and process personal data in line with the GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680, except for systems permitted by law to detect, prevent or investigate crime. The EDPB small business guide states that a DPIA should usually be carried out where processing meets two of nine listed high-risk criteria. A written DPIA must describe the processing, assess necessity and proportionality, identify risks and list mitigation measures.
Fundamental rights impact assessments are a separate AI Act duty where the Act applies, so a completed DPIA does not satisfy them by default. Confirm with counsel which deployers and systems fall in scope, and whether any DPIA content can be cross-referenced under Article 27 without weakening either record. A practical step is to run one assessment file with a mapping table that tags each GDPR DPIA element, each AI Act documentation element and each risk, so reviewers can see which record covers which obligation.
Who assesses each law and what the assessment produces
This table compares who enforces the EU AI Act and the GDPR, how each one's assessment route works, and what paperwork or certificate the process produces. Read it to decide which evidence you must build for AI systems and which evidence is optional.
| Dimension | EU AI Act (high-risk AI systems) | GDPR (personal data processing) |
|---|---|---|
| Assessor | National market surveillance authorities enforce the Act for AI systems. The Commission's AI Office enforces general-purpose AI model rules and, as amended in 2026, is exclusively competent for AI systems built on a provider's own general-purpose model and for AI in very large online platforms and search engines. | Independent national supervisory authorities enforce the GDPR. The EDPB issues guidelines and resolves disputes between authorities through binding decisions. |
| Conformity route | Most Annex III high-risk systems use internal-control conformity assessment under Annex VI. Notified bodies are involved for some biometric systems and Annex I products under Article 43. | No conformity assessment route. The controller must demonstrate compliance through its own records, risk assessments and safeguards. |
| What is issued | Conformity documentation and technical records held by the provider. The first harmonised standard, EN 18286:2026 on quality management, was cited in the Official Journal on 14 October 2026. | No audit, attestation or certificate is required. Article 42 certification is voluntary, issued for at most three years by accredited bodies or supervisory authorities, and does not reduce controller or processor responsibility. |
| Review cycle | Ongoing duties for providers and deployers across the system's lifecycle. Confirm with your counsel which obligations attach to your role as provider or deployer. | Ongoing accountability. Review the data protection impact assessment when processing changes, and expect supervisory investigation on complaint or on the authority's own initiative. |
| Where the two meet | Deployers of certain systems must use the provider's information for GDPR data protection impact assessments (Article 26(9)). Amended Article 27 lets deployers cross-reference or include parts of a GDPR DPIA. | The DPIA is the GDPR document most likely to hold the AI-specific risk analysis. Use it as the shared record, then confirm what the AI Office questionnaire template will ask for. |
| Maximum fines | EUR 35 million or 7% of worldwide annual turnover for prohibited practices, EUR 15 million or 3% for most operator obligations (Article 99). | EUR 10 million or 2% for infringements such as Articles 25 to 39, and EUR 20 million or 4% for core principles, lawful basis, data subject rights and transfer rules (Article 83). |
Where the work overlaps and where it does not
The AI Act and the GDPR both reach the same personal data and the same decisions, so one evidence set can serve both where the Act points back to the GDPR. Each card below names the shared evidence and the gap that stays open, and no official crosswalk should be assumed, since ENISA says its own mapping is not a measure of equivalence.
DPIA and risk assessment
Article 26(9) of the AI Act requires deployers to use the provider's information for GDPR data protection impact assessments, and the 2026 amendment lets deployers cross-reference or include parts of a DPIA in their AI assessment. The shared evidence is one written DPIA that describes the processing, assesses necessity and proportionality, and lists mitigations. The gap is that the AI Act's fundamental rights impact assessment and the GDPR DPIA ask different questions, so confirm with counsel which sections each regulator will accept.
Data governance and bias-detection data
Article 4a of the AI Act allows processing of special category data for bias detection under safeguards, including pseudonymization, documented access controls, no transfer to other parties, and deletion once the bias is corrected. The shared evidence is a single data inventory and records of processing entry that states why the data is processed. The gap is that the Act's safeguards are narrower than the GDPR's general lawful basis analysis, so a separate justification for each bias test is still needed.
Transparency notices
Article 50(3) requires deployers of emotion recognition or biometric categorisation systems to inform the people exposed, while GDPR Articles 13 and 14 set the content of privacy notices. The shared evidence is one notice that covers the AI use and the profiling logic. The gap is timing and content: the Act's notice duty applies to exposed people even where the GDPR information duty is not triggered in the same way, so check each use case against both texts.
Security of processing and AI cybersecurity
GDPR Article 32 requires security of processing appropriate to the risk, and the AI Act sets its own robustness and cybersecurity expectations for high-risk systems. The shared evidence is one set of access controls, logging, testing and incident handling that covers both the data store and the model. The gap is that model-specific threats such as data poisoning and adversarial inputs fall under the Act, not Article 32, so the threat model must be extended beyond the database.
Record keeping and logs
Both regimes ask for records that show what the system did and why. The GDPR requires records of processing under Article 30, and the AI Act requires logs for high-risk systems. The shared evidence is one log store with retention rules that serve an audit of either regime. The gap is that log retention periods and the content of each record differ, so set them by the stricter requirement for each data category and confirm that choice with each regulator's guidance.
Human oversight and Article 22 rights
GDPR Article 22 gives people rights against decisions based solely on automated processing, and the Dutch DPA's 2026 fine against Uber shows that enforcement focuses on this point. The AI Act's human oversight duty for high-risk systems is a design requirement, not a personal right. The shared evidence is documented human review points and override procedures. The gap is that a human reviewer who only rubber-stamps outputs may satisfy one regime and fail the other, so test the review in practice.
How the fines compare and what the Uber case shows about automated decisions
The fine ceilings are the first thing to rank, but they are only a ceiling. Under Article 99 of the AI Act, the maximum is EUR 35 million or 7% of worldwide annual turnover for prohibited practices, EUR 15 million or 3% for most operator obligations, and EUR 7.5 million or 1% for misleading information to authorities, whichever is higher in each case. Under Article 83 of the GDPR, the maximum is EUR 10 million or 2% for infringements such as Articles 25 to 39, and EUR 20 million or 4% for breaches of the core principles, lawful basis, data subject rights and transfer rules, again whichever is higher. A single AI deployment on personal data can therefore face fines under both regimes for different failures. The Commission's AI Office also holds separate powers over general-purpose AI model providers under Article 88, and under Article 75(1) as amended in 2026 it is exclusively competent for AI systems built on a provider's own general-purpose model. If you build on a third-party model, confirm which authority supervises your system and which supervises the model provider.
The Uber decision shows where exposure concentrates. The Dutch DPA fined Uber EUR 824,990,000 for unlawful automated decision-making about drivers and for insufficient information about profiling, under Articles 22 and 13 of the GDPR. The case began from complaints by 171 drivers, and Uber has appealed, so the outcome is not final. For your own systems, the practical lesson is that profiling transparency and the right not to be subject to solely automated decisions carry exposure even when the AI model itself is not in scope of the AI Act's high-risk rules. Check whether any output that ranks, scores or restricts people is decided without meaningful human involvement, and whether the notices you give people explain the logic involved in plain terms.
AI Act and GDPR authorities can act in parallel. A market surveillance authority may examine an AI system's conformity while a data protection authority examines the personal data processing in the same deployment, and neither waits for the other. Ask in your planning which national authority would receive a complaint about each system, and keep the evidence for the two regimes in one file so that a single incident can be answered consistently for both.
How to run one assessment process for both laws
This sequence turns the AI Act and GDPR duties for a single AI system into one inventory, one risk record and one evidence library, while keeping each legal test and its outcome separate.
Inventory AI systems and personal data flows
Start with a register of every AI system in use or in development, including vendor-supplied tools, and map the personal data each one ingests, infers, stores and outputs. Assign an owner for each system, usually the business process owner with a technical lead from platform engineering. The step is done when every system has a named owner, a data flow diagram and a list of the people it affects, such as employees, applicants or customers. Ask providers for documentation of training and input data, because deployers depend on it for later steps.
Classify each system under the AI Act
Determine for each system whether it is prohibited, high risk under the Annex III or Annex I routes, subject only to transparency duties, or outside the Act's regulated categories. Record your role as provider, deployer or both, and whether the system is public-authority use that triggers the registration duty in Article 26(8). Where the classification depends on the intended purpose, document that purpose in writing. Confirm borderline cases with counsel or the relevant market surveillance authority before the classification is final. The output is a dated classification record per system.
Screen each system against GDPR DPIA criteria
For each personal data processing activity, apply the EDPB small business guidance: a DPIA should usually be carried out where processing meets two of nine listed high-risk criteria. Many AI systems that profile people or make decisions about them will meet the threshold, but the screen should be run on the processing itself, not assumed. Where a DPIA is required, the written assessment must describe the processing, assess necessity and proportionality, identify risks and list mitigation measures. The record is complete when each system has a screening result and, where needed, a started DPIA.
Combine provider information with the DPIA
Collect the provider's instructions and technical information and use them as inputs to the GDPR DPIA, as Article 26(9) requires deployers to do. Where the Act permits, cross-reference or include parts of the DPIA in the AI Act deployer assessment, as Article 27(4) and (5) allow after the 2026 amendment. Add a fundamental rights impact assessment where the deployer obligations under Article 27 apply, and reuse the same risk entries so that a risk identified once is tracked once. The check is that every risk in the AI file has a matching DPIA entry or an explicit reason for omitting it.
Set controls for Article 4a and Article 50(3)
Where a system uses bias-detection processing of special categories of personal data, apply the Article 4a safeguards: pseudonymization, state-of-the-art security, strict and documented access controls, no transfer to other parties, deletion once the bias is corrected, and recording the reasons for processing. Where a system performs emotion recognition or biometric categorisation, inform exposed people and process the data in line with the GDPR, Regulation (EU) 2018/1725 and Directive (EU) 2016/680, unless a law permits the use to detect, prevent or investigate crime. Map each control to a named technical owner and test it. The output is a control set with test results attached to each system.
Record processing and transparency in GDPR records
Add each AI processing activity to the records of processing, including the purpose, legal basis, categories of data, recipients, retention and transfers, and include the Article 4a reasons where bias-detection data is involved. Update the privacy notices and the Article 50 disclosures so that people are told when they interact with an AI system or are subject to emotion recognition. Confirm with the privacy team that each notice matches the classification in step two. The step is done when every system in the inventory has a matching record entry and notice.
Define evidence owners and review triggers
Build one evidence library with a folder per system, holding the classification, DPIA, provider documents, control tests, records entries and notices. Assign an evidence owner for each item and a reviewer from legal or privacy. Set review triggers, such as a material model change, a new data category, a new purpose, a serious incident or a change in the regulator's guidance, and record who decides when a review is needed. A single library reduces duplicated work, but it does not remove the separate legal duties under each law, so each obligation keeps its own sign-off. The output is an owner map and a trigger list approved by the accountable executive.
Confirm unclear scope with the regulator or counsel
Where the AI Act classification, the Article 27 duties or the GDPR screening result is unclear, record the question, the facts assumed and the proposed answer, then confirm it with counsel or the relevant supervisory or market surveillance authority before relying on it. Ask the authority which body is competent for each system, since national market surveillance authorities enforce the Act for AI systems, while national supervisory authorities enforce the GDPR. The step closes when each open question has a documented answer, a named approver and a date, and the outcome has been fed back into the inventory and classification records.
What buyers ask before hiring help with EU AI Act and GDPR work
Is there a certificate for GDPR or the EU AI Act?
No certificate exists for the GDPR. The GDPR requires no audit, attestation or certificate, and Article 42 certification is voluntary, issued for at most three years by accredited certification bodies or supervisory authorities. It does not reduce the controller's or processor's responsibility for compliance. The AI Act works through conformity routes instead. Most Annex III high-risk systems use the internal-control conformity assessment in Annex VI, while notified bodies are involved for some biometric systems and Annex I products under Article 43. Confirm which route applies to each system before scoping the work. DeployOpen prepares systems, controls and evidence for these assessments but does not issue audit reports, attestations or certifications. Independent auditors, certification bodies and the provider's own conformity documentation fill those roles.
What drives the cost of AI Act and GDPR work?
Cost depends on who is paid for which work. External fees usually cover inventory, classification, impact assessments and evidence preparation. Your counsel bills for legal review, and your staff spend time providing system and data facts. The one-time work is the first inventory and assessment. Monitoring, re-assessment and documentation updates recur as systems change. Main cost drivers are:
- The number of AI systems in scope and how many use personal data
- The sensitivity of the personal data and whether special categories or emotion recognition are involved
- Classification disputes, where the team and the regulator may read a use case differently
- Documentation maturity, meaning how much system and data documentation already exists
- Whether a notified body is involved in the conformity route
Ask any provider to price each driver separately in the written scope.
How long does an AI Act and GDPR assessment take?
The supplied dates set legal deadlines, not the length of your work. The GDPR has applied since 25 May 2018. The AI Act entered into force on 1 August 2024, and the rest of the Act applies from 2 August 2026. As amended in 2026, the high-risk rules apply from 2 December 2027 for Annex III systems and from 2 August 2028 for Annex I product systems. Your timeline depends on the number of systems, how much documentation exists, whether classification is contested and whether a notified body is involved. DeployOpen agrees timelines, milestones and deliverables in writing before fixed-scope work starts. Confirm the calendar against those deadlines and your own release schedule in that written scope.
What does our staff need to provide for this work?
Three groups of people carry most of the work. System owners describe each AI system's purpose, users, affected people, model versions and where outputs are used. Data owners identify the personal data each system uses, the lawful basis, retention periods, recipients and any transfers outside the EU. Legal review confirms the risk classification, transparency notices, data protection impact assessment sign-off and any position taken on automated decisions. Security staff add access controls and logging details. Providers of third-party AI systems must also supply their documentation, because deployers rely on that information for GDPR impact assessments under Article 26(9). Name one accountable person per group before work starts and agree how many hours each will give.
Can our team do AI Act and GDPR work without outside help?
A team with legal capacity, a clear system inventory and existing privacy documentation can do much of the work alone, especially for a small number of systems with no contested classification. Outside help is more useful when classification is disputed, when notified bodies are involved, when documentation is thin or when many systems share the same data. For the GDPR impact assessment, the EDPB's small business guide says a DPIA should usually be carried out where processing meets two of nine listed high-risk criteria. A written DPIA must describe the processing, assess necessity and proportionality, identify risks and list mitigation measures. Check each point against your own records before deciding who writes it.
What should a fixed-scope quote for this work include?
A fixed-scope quote follows from a written scope, and DeployOpen does not publish a price list. Ask the quote to list:
- The named AI systems and personal data flows in scope, with a method for adding systems later
- The AI Act obligations and GDPR articles covered, and the classification method used
- The data protection impact assessment scope and the records of processing to be updated
- Each deliverable, its acceptance criteria and the milestone dates
- The client staff, legal review and vendor documentation the work depends on
- Exclusions, including that no audit report, attestation or certificate is issued
- How changes from the 2026 amendments and later guidance are handled
Ask separately whether ongoing monitoring is quoted as a retainer.
Which fines apply if an AI system mishandles personal data?
Two regimes can apply at once. Under GDPR Article 83, maximum fines are EUR 10 million or 2% of worldwide annual turnover for infringements such as Articles 25 to 39, and EUR 20 million or 4% for breaches of principles, lawful basis, data subject rights and transfer rules, whichever is higher. Under AI Act Article 99, maximum fines are EUR 35 million or 7% for prohibited practices and EUR 15 million or 3% for most operator obligations, whichever is higher. Enforcement differs: national supervisory authorities enforce the GDPR, and national market surveillance authorities enforce the AI Act. In one example, the Dutch DPA fined Uber EUR 824,990,000 under Articles 22 and 13 for unlawful automated decision-making and insufficient information on profiling. Uber has appealed.
How DeployOpen scopes readiness for the AI Act and GDPR together
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, and prepares systems, controls and evidence for compliance assessments. For EU AI Act vs GDPR work, we scope one shared assessment process so the AI system records, data protection impact assessment inputs and access controls are built once and documented for both regimes. DeployOpen does not issue audit reports, attestations or certifications.
How we scope
- Written scope lists which AI systems, personal data flows and deployer or provider roles are in and out of the engagement.
- We confirm with your legal and privacy teams which GDPR records and impact assessments the AI work must feed into.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We configure logging, access controls and data handling for AI systems hosted in your cloud, data center or air-gapped network.
- We map provider documentation and deployer obligations to the controls and records your team already maintains for GDPR.
- We test the configured controls and record the results so reviewers can trace each requirement to its evidence.
How we hand over
- You receive documented controls, configuration records and a single assessment file covering both the AI Act and GDPR items.
- Runbooks explain who in your organization owns each review step, each record and each periodic update.
- Handover includes a list of open items that your counsel, notified bodies or supervisory contacts must confirm.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover updates to the shared assessment when the AI Act or GDPR guidance changes for your use cases.
- Your independent auditors and regulators remain responsible for any assessment, attestation or supervisory decision.
Sources and further reading
- Regulation (EU) 2024/1689 (Artificial Intelligence Act), EUR-Lex ↗
- Regulation (EU) 2024/1689, consolidated text as amended by Regulation (EU) 2026/1744 (27 July 2026), EUR-Lex ↗
- Regulation (EU) 2016/679 (GDPR), Articles 51, 65, 68, 70, 83 and 99, EUR-Lex ↗
- EDPB data protection guide for small business: Be compliant ↗
- EDPB national news: Dutch DPA fines Uber EUR 824 990 000 (8 October 2026) ↗
- AI Act, Shaping Europe's digital future (European Commission) ↗
