GDPR and the AI Act in one SaaS

This is a case study drawn from a real engagement with a Polish B2B SaaS company of about 180 people. The product is an internal knowledge assistant used by mid-market financial services customers (banks, brokers, factoring companies) to query their own policy documents, contracts, and procedures. The customer asked for help implementing two specific obligations: GDPR Article 32 (security of processing) and AI Act Article 9 (risk management and data governance for high-risk AI systems). Three other obligations in scope (Article 10 data governance, Article 12 logging, Article 14 human oversight) shipped as part of the same programme. The post focuses on 32 and 9 because that is what the customer found hardest to translate into engineering work.

The starting position

The product had been live for 14 months. Inference ran against a US-hosted large language model API. Customer documents left the customer's infrastructure, were tokenised in US-region servers, returned as completions, and were not logged in the customer's storage tier. The customer had a Data Processing Agreement with the model vendor, architecturally correct (mirroring the EU standard contractual clauses) but technically unenforceable: the customer had no way to demonstrate that the inference path did not include the metadata beyond what the vendor's dashboard showed. Two things were true at the same time. The DPA existed, so on paper the system was compliant. The architecture did not match the DPA, so in practice it was not.

What GDPR Article 32 actually requires

GDPR Article 32 is the security of processing article. It lists "appropriate technical and organisational measures": pseudonymisation and encryption of personal data; ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems and services; ability to restore availability and access to personal data in a timely manner in the event of an incident; a process for regularly testing, assessing, and evaluating the effectiveness of those measures.

The Article is principles-based; in an audit that is the problem: every auditor reads it slightly differently. In the engagement, we mapped Article 32 to four engineering controls: (1) encryption at rest (AES-256) and in transit (TLS 1.3), with a 12-month key-rotation cadence and shorter for high-impact surfaces; (2) pseudonymisation of PII before it reaches the model, with a reversible mapping table stored separately from the model context and access controlled by the customer's IAM; (3) a documented incident-response runbook with RTO and RPO on the AI tier, tested quarterly with a tabletop exercise that includes the model-serving tier; (4) an annual third-party penetration test with a dedicated AI-surface scope (prompt injection, retrieval poisoning, model exfiltration). Pseudonymisation is structural, not a control: if PII reaches the model raw, you can have a DPA in place and still fail Article 32.

What AI Act Article 9 actually requires

AI Act Article 9 sits in Chapter III, Section 2, alongside Articles 10 to 15. It is the risk-management article for high-risk AI systems. Article 9(1) requires that a risk-management system be "established, implemented, documented and maintained" as a "continuing iterative process" across the lifecycle of the system. Article 9(2) requires identification and analysis of "known and reasonably foreseeable risks" to health, safety, and fundamental rights. Article 9(3) requires estimation and evaluation of risks that "may emerge" when the system is used as intended and under conditions of reasonably foreseeable misuse. Article 9(5) requires testing "to ensure that the system works consistently and that it is in compliance with the requirements set out in this Chapter." The combination is unusual compared to GDPR: a documented process AND ongoing testing AND a presumption that misuse will happen. Article 9 effectively creates a duty to test for failure modes that have not yet been observed.

What the implementation programme looked like

The programme ran for four months across four sprints.

Sprint 1 - risk register and misuse catalogue. We built the Article 9 risk register as a YAML document in the repository, versioned and reviewable. Five categories (data exposure, model behaviour, regulatory non-compliance, contractual breach, third-party failure) and 23 risks across the as-built system. Each risk had likelihood, impact, residual score after existing controls, and a decision: mitigate, accept, transfer, or avoid. The misuse catalogue required three one-hour workshops with customer-facing and product teams, walking through what a customer might try that we did not intend. The catalogue ended at 17 documented misuse cases, including prompt injection through customer documents, training-data retrieval through crafted sessions, and instructions-for-use bypass attempts.

Sprint 2 - data governance mapping under Article 10 and Article 32 pseudonymisation. The data inventory was rebuilt. Personal data fields were tagged with the basis for processing (contract, legitimate interest, consent). Fields that did not need to reach the model were filtered at the boundary. Fields that needed to be referenced were pseudonymised before crossing. This mapping was the contractual artefact for the customer relationship under GDPR Article 28: without it the data processor cannot demonstrate Article 32 obligations; with it the customer can sign off.

Sprint 3 - inference path change. Inference moved to a private deployment of an open-weights model (Mistral-based, 22B parameters, AWQ-quantised) on customer-dedicated hardware co-located in an EU member state. The DPA with the previous vendor stayed on file as the historical record but the inference path was entirely local. This is the structural Article 9 change: a US-hosted inference path can be defended in a DPA; it cannot satisfy Article 9(5) testing in a fully contained way, because the environment is not under the operator's control.

Sprint 4 - logging, testing, model card. Article 12 logging was a signed JSON event per inference call, 12-month retention. Article 15 testing was wired into CI with a held-out test fixture from customer-approved seeds, re-run on every model or retrieval change. The model card was written, reviewed by the customer's compliance officer, and published to deployer documentation.

What the customer got out of it

A documented risk-management system that survives a procurement cycle (the risk register and misuse catalogue became the answer to "how do you handle AI safety?" in the next three RFPs; cost less than one lost mid-market deal). A model architecture that no longer depends on a third-country inference path: structural fact, not marketing claim, defensible to any EU regulator. An audit-able conformity assessment against AI Act Chapter III, with technical documentation for Articles 9, 10, 12, 14, and 15 in a single repository, reviewed with external counsel. Whether the customer pursues Article 43(1) self-assessment or a third-party conformity assessment depends on system classification, but the same documentation set serves both.

What did not work

Three things, worth naming because they recur. Risk register as a one-off document. The first version was written in sprint 1 and treated as finished; a new model version invalidated three risks six weeks later. The fix: re-run on every model, retrieval, or major schema change. Now part of CI. Mapping Article 32 to a single control. Three teams wanted to claim pseudonymisation satisfied Article 32. It does not; the article is a system property. Pseudonymisation composes with encryption, resilience, and testing. Treating Article 9 as a paper exercise. Article 9(5) testing was the bottleneck in sprint 4. The first attempt reused a marketing benchmark and was rejected. Rebuilt against a held-out test set with documented seeds, which is what supported the conformity assessment. Three weeks not budgeted for.

What this means if you are at a small SaaS

Three principles transfer from this case to the broader population of regulated Polish SaaS companies. Article 32 is structural. Pseudonymisation, encryption, resilience, and testing compose into a single property; if your AI tier does not satisfy all four, the audit fails at the weak point. Article 9 is a process. The risk register and testing are recurring obligations; budget for them and put them in CI. The architecture is the audit trail. For Article 9(5) and Article 15, the deployment diagram and test reports are the evidence. If those are not in a repository under your change management, the audit defence fails before it starts. The EU AI Act enforcement date for high-risk systems is 2 August 2026; the programme above takes three to six months from a clean slate. ArtCode Software runs this same four-sprint programme with regulated SME customers today. If you want a fixed-scope diagnostic of where your system stands on GDPR Article 32 and AI Act Article 9, the AI Readiness Audit is a two-day engagement that produces that map. If you need the implementation programme embedded into your team, the Fractional AI Architect Retainer runs one day a week until the documentation is reviewable.