AI in Product Development and Product Management

Introduction: why engineers need law

Regulation (fines, user trust). GDPR, AI Act — phased rollout from 2026. Responsibility lies with companies, but dev/PM are reviewed (architecture, logs, documentation). Poll: “Have you encountered the GDPR/AI Act?”

Basic GDPR principles “translated into code”

Principles: lawfulness, data minimisation, purpose limitation, storage limitation, security. Which fields should not be stored in the database. The PM’s role: to capture these decisions in the requirements.

Users’ rights and what this means for architecture

Rights of access, rectification, erasure, restriction, and data portability; prohibition on purely automated decisions without a human. Product requirements: find a user’s data, export it, delete it. For PMs — reflect this in user stories; for devs — design APIs/scripts.

EU AI Act: how it is structured

The concept of an AI system, a risk-based approach: prohibited, high-risk, limited. What counts as high-risk (credit, HR, biometrics, critical infrastructure, etc.) and why fintech/HR/health are particularly vulnerable. Roles: provider, deployer, integrator — and who bears responsibility.

Obligations under the AI Act in “technical translation”

What is required: risk management, data quality, documentation, logging, human-in-the-loop, post-monitoring. How this breaks down into tasks: a model/feature register, decision logs, descriptions of limitations in documentation, rules on when human review is required. PMs are process owners; devs are implementation owners.

Documentation and artefacts as a “shield” in an audit

Which artefacts are typically reviewed: data flow, system descriptions, records of processing (RoPA), DPIA, logging, descriptions of roles and processes. Why the absence of documentation is treated as the absence of control. How to turn documentation into a standard sprint deliverable (Confluence/Notion + diagrams + repositories).

Q&A and practical steps

Answers to questions. Action items:

1. compile a list of systems where personal data are processed;
2. identify whether there are any high-risk AI scenarios inside;
3. for one key service, sketch a data flow and check whether users’ rights are implementable.

A brief recap of the key idea: law is part of the architecture, not external “oversight”.