AI governance becomes tractable for an engineering team when you stop treating it as a document and start treating it as three controls: an inventory of every AI system you actually run, a recorded provider-or-deployer determination per system, and transparency disclosures monitored the way you monitor any other user-facing behaviour. The inventory is the hard part, because AI adoption routinely outruns governance — a model added behind a feature flag is in scope whether or not anyone told the DPO. And because an Article 50 disclosure is a piece of UI, it can be removed in a redesign, which makes it exactly the kind of thing that needs a check rather than a policy.
Start with the inventory, not the framework
Most AI governance advice starts with risk classification. That is the second problem. The first is that nobody has a reliable list of the AI systems the company actually runs, because adoption happens through the normal channels engineers use for everything else: a library added to a service, a hosted model called from a feature branch, a vendor feature that quietly became AI-powered in a release you did not read.
An inventory built from a form that teams fill in when they remember will be incomplete in a way that is invisible until it matters. The signals worth pulling from instead are the ones that already exist — model provider SDKs and API clients appearing in dependency manifests, outbound calls to inference endpoints, spend on AI services in cloud and expense data, and procurement records for vendors whose product description changed.
Provider or deployer, decided per system
The AI Act attaches different duties depending on your role. The provider develops the system or puts it on the market under its own name; the deployer uses it under its own authority. Most organisations are both, across different systems, and the answer can change for a single system when you modify it substantially or ship it under your own brand.
The engineering-relevant consequence is that provider duties tend to be build-time — machine-readable marking of generated output, technical documentation, logging — while deployer duties tend to be runtime and user-facing. Building on someone else's model does not remove the deployer duty, which is the misconception that most often leaves a gap.
Article 50 as a control that can regress
Article 50 sets transparency duties that apply outside the high-risk tier: tell people when they are interacting with an AI system, mark AI-generated or manipulated content in a machine-readable way, disclose emotion recognition and biometric categorisation before use, and label deepfakes and AI-generated text published to inform the public. The disclosure has to be clear and given at the first interaction.
Every one of those is a piece of product behaviour. A disclosure line lives in a component that a redesign can delete. Watermarking is a code path that a refactor can bypass. This is the specific reason to model them as controls with an owner and a check, rather than as a copy task that was completed once. It is also the cheapest category of non-compliance for anyone outside your company to spot, because they only have to open your product.
The GDPR overlay
Almost every AI system in scope also processes personal data, which means the GDPR applies at the same time and asks entirely different questions: on what lawful basis, with what transparency to the data subject, with what rights attached, and whether the processing is high risk enough to require a DPIA before it starts.
Satisfying Article 50 says nothing about any of that. Emotion recognition is the clearest illustration — it engages an AI Act disclosure duty and, simultaneously, a GDPR analysis about special-category data. Running the two as separate registers means describing the same system twice and reconciling them by hand; running them from one data map means the AI classification and the DPIA trigger see the same facts.
A practical sequence
- Build the inventory from signals you already have — dependencies, endpoints, cloud spend, procurement — before asking anyone to fill in a form.
- Record a provider-or-deployer determination per system, with the reasoning, because it decides everything downstream.
- Turn each applicable Article 50 duty into a control with an owner and a check that would notice if the disclosure disappeared.
- Link each AI system to what it processes, so the GDPR obligations derive from the same facts rather than a parallel exercise.
- Re-run discovery on a schedule; the inventory decays for exactly the same reason a manual data map decays.
If you want to see your AI estate discovered from the systems you already run, and the obligations mapped onto it, you can explore it at noru.tech.