Compliance inside the workflow,
not after.
Every AI Workflow Design we graft carries a compliance overlay: four controls that accompany every use case, so from day one you know what you can do, what must be reported and what must be documented. This is what they contain, in full — no scaremongering and no gates.
In most cases you use AI, you don't build it: you're a deployer. The obligations are real but lighter than those of the companies that sell the systems — and we map them for you.
One deadline, though, is fixed: from 2 August 2026 article 50 of the AI Act asks you to tell whoever writes to you that they are talking to an AI. It is the easiest obligation to put in place, and we have written it up in full:
From 2 August you have to tell customers they are talking to an AIHow risky is your AI?
Pick what your AI actually does: we point you to its likely risk level under the EU AI Act and to the obligations that follow — then read the deep-dive below, or talk it through with us.
Banned by the AI Act, private companies included. If a use case lands here you don't mitigate it — you don't do it.
- The use is not permitted: drop it from the project rather than govern it.
Allowed, but with the serious obligations of Annex III and Article 26. This is the demanding band: design it carefully from the start.
- Effective human oversight over the decisions.
- Use in line with the provider's instructions, with input data relevant to the purpose.
- Monitoring of how it performs, and logs kept for at least six months.
- Reporting of serious incidents.
No heavy machinery: transparency obligations only. The person has to know they are interacting with — or reading — an AI output.
- A chatbot has to say it is one.
- Content generated or modified by AI has to be flagged as such.
No specific obligation under the AI Act. This is where the vast majority of an SME's AI sits.
- No formal obligation from the AI Act — sound security practice and data protection (GDPR) still apply.
Educational orientation, not a legal determination nor legal advice. The definitive classification depends on the specific case and has to be checked case by case.
The risk level
The EU AI Act ranks uses of AI by risk level. We place every use case at the right level, so you know in advance which obligations really kick in — and which don't.
-
Minimal and limited
Where most SME workflows fall: internal copilots, content generation, support bots. Light obligations — mainly transparency, like declaring that the user is talking to an AI.
-
High risk — we flag it separately
Recruitment, credit scoring, biometrics: here the heavy deployer obligations kick in — assigned human oversight, relevant input data, log retention, monitoring and incident reporting. If a use case lands here, we flag it distinctly in the catalogue, we don't hide it among the others.
SMEs get dedicated simplifications (reduced technical documentation, consultation channels, regulatory sandboxes). The deadlines on high-risk systems are still moving, and those we re-read at every engagement; article 50's is not — it is 2 August 2026, and it is the only date we print here.
The impact assessment (DPIA)
The GDPR requires a data protection impact assessment (DPIA) when the processing is "likely to be high risk". We check whether your case triggers one before we start.
-
Automated decisions with legal or significant effects on people
-
Special-category data processed at scale
-
Systematic monitoring of publicly accessible spaces
The piece standard templates skip
A generic DPIA covers the GDPR part but ignores AI-specific risks: model opacity, memorisation of training data, drift over time, the right to erasure clashing with an already-trained model. Our assessment carries a section dedicated to these, not just the boilerplate.
Risk labels, not prose
Every use case gets a structured label modelled on the MIT AI Risk Repository, instead of a discursive paragraph. Two axes that combine, so risk becomes traceable and comparable from one workflow to the next.
- How the risk arises
- Who originates it (a person, the AI, something else), whether it's intentional or not, and whether it emerges before or after going into production.
- What kind of risk it is
- Discrimination, privacy and security, misinformation, misuse, human-machine interaction, socioeconomic impacts, system failures.
A concrete example
A sales copilot's hallucinations get labelled as a misinformation risk, originated by the AI, unintentional, emerging after going into production — with its mitigation written alongside. A citable label instead of a sentence.
Italian regulatory oversight
On top of the European layer comes the national one: the Garante Privacy and Italy's principles on artificial intelligence. This is fast-moving territory and enforcement is real, not theoretical — so we re-read it at every engagement rather than take it for granted.
Human oversight stays part of the design
The thread that holds the four controls together: no workflow we graft makes decisions in people's place without a human checkpoint. That's how the overlay stops being a separate chapter and becomes part of the way the workflow is designed.
The analyses behind these controls.
- The EU AI Act for SMEs: what really changes (and what doesn't) Compliance ·
- From 2 August you have to tell customers they are talking to an AI Compliance ·
- AI governance in an SME: the controls that make a use case defensible Compliance ·
- Is the AI vendor you're about to adopt trustworthy? SOC 2, ISO 42001 and what to ask before you sign Compliance ·
- Is AI-written code secure? What the independent studies say — and what to put in the contract Compliance ·
The overlay is part of the design. Not an add-on.
See how it plays out on a real department in the open AI Workflow Design examples, or start from the free assessment to find out where it makes sense to begin.
This page is for guidance only: it does not constitute legal advice or a specific compliance assessment, which we carry out together on your concrete case.