EU AI Act Art.4 Role-Specific AI Literacy Training: Product, Engineering, Operations & Support 2026
Post #3 in the sota.io EU AI Act AI Literacy Compliance Series
The most common Art.4 compliance mistake is treating AI literacy as a single checkbox: complete one generic "AI for Everyone" module, record the completion, done. National Competent Authorities will not accept that. The legal standard — "sufficient level of AI literacy taking into account their technical knowledge, experience, education and training, and the context in which AI systems are used" — is explicitly role-contextual.
This post maps that legal requirement to four concrete roles found in every software organisation: Product Managers, Software Engineers, Operations/SRE teams, and Customer Support. For each role we define the minimum curriculum elements, the documentation an NCA will expect, and how to build an evidence package that survives inspection.
Why the Role-Specificity Requirement Has Legal Teeth
Article 4 of Regulation (EU) 2024/1689 (EU AI Act) sets the AI literacy obligation for both providers and deployers. The key phrase is "taking into account their technical knowledge, experience, education and training, and the context in which the AI systems are used on their behalf."
This is not a minimum-hours standard. It is a contextual sufficiency standard. The NCA's question is not "did you deliver training?" but "was the training appropriate for what this person actually does with AI systems?"
Three practical implications:
A product manager who sets risk thresholds for an AI-powered credit scoring system needs different training than a junior support agent who summarises tickets with a GPT assistant. The former must understand AI system limitations, bias risks, high-risk classification criteria under Art.6, and their organisation's obligations under Art.26 (deployer obligations for high-risk AI). The latter needs enough literacy to recognise when AI output should not be passed to a customer without review.
Art.14 (human oversight measures) links directly to literacy. Deployers of high-risk AI systems must ensure that the persons assigned to oversee AI systems have the necessary competence, training, and authority. Without role-specific literacy documentation, you cannot demonstrate Art.14 compliance independently.
Art.26 places active obligations on deployers — including identifying and reporting incidents (in coordination with providers), maintaining logs, and ensuring human oversight. Staff who carry these obligations cannot fulfil them without targeted AI literacy. Generic awareness training does not create the specific competence Art.26 requires.
The sections below define what "sufficient" looks like for each role.
Role 1: Product Management
Product Managers are the highest-stakes literacy target in most software organisations. They define which AI features are built, set risk appetite for AI behaviour, approve AI system configurations, and decide when to expand or restrict AI use in a product.
What Art.4 Requires for PMs
A Product Manager dealing with AI systems must be able to:
- Classify the AI systems in their product as high-risk, limited-risk, or minimal-risk under Art.6 and Annex III criteria.
- Understand the intended purpose limitation: Art.26 requires deployers to use high-risk AI only within the intended purpose as defined by the provider. PMs who configure AI systems outside intended purpose create direct compliance exposure.
- Identify when a proposed AI feature triggers Art.50 transparency obligations (users must be informed they are interacting with an AI system).
- Apply a risk-proportionate approach to AI feature specification — including bias assessment inputs, edge-case behaviour requirements, and human override mechanisms.
Minimum Curriculum Elements for PMs
| Module | Duration | Coverage |
|---|---|---|
| EU AI Act structure & timeline | 2h | Regulation (EU) 2024/1689 scope, high-risk classification, August 2026 enforcement |
| Art.6 + Annex III: High-risk classification | 3h | Classification decision tree, sector-specific lists, borderline cases |
| Art.26 deployer obligations | 2h | Intended purpose, incident reporting, human oversight duties |
| Art.50 transparency requirements | 1h | Chatbot disclosure, deepfake labelling, when exemptions apply |
| Bias and fundamental rights impact | 3h | Discrimination risk, protected characteristics, FRIA basics |
| AI failure modes for PMs | 2h | Distribution shift, hallucination patterns, confidence calibration |
| Total | 13h |
Documentation the NCA Expects
- Training completion records with date, trainer/provider, and module breakdown by PM name
- A log of AI feature decisions made with a risk classification rationale attached
- Evidence that Art.6 classification was reviewed for each AI feature spec
- Incident records if any AI system under PM ownership generated a reportable incident under Art.26(5)
Role 2: Software Engineering
Software Engineers are the builders of AI systems and the primary implementers of AI API integrations, model deployments, and inference pipelines. Their Art.4 obligations focus on what they build and how they document it.
What Art.4 Requires for Engineers
An engineer working on AI systems must be able to:
- Apply the risk management principles of Art.9: identify foreseeable risks during development, implement risk control measures, and document residual risks.
- Implement logging sufficient for Art.12 (record-keeping) and Art.19 (automatically generated logs for high-risk AI systems).
- Understand what constitutes a "substantial modification" that triggers re-assessment under Art.16(d) provider obligations.
- Implement human oversight mechanisms required by Art.14 — including the ability for operators to override, disable, or monitor AI outputs.
The engineering role is also the primary owner of technical documentation under Art.11 for provider-side systems.
Minimum Curriculum Elements for Engineers
| Module | Duration | Coverage |
|---|---|---|
| EU AI Act technical obligations overview | 2h | Art.9, Art.10, Art.11, Art.12, Art.14, Art.15 |
| Risk management system (Art.9) for engineers | 3h | Foreseeable risk identification, testing protocols, residual risk documentation |
| Data governance basics (Art.10) | 2h | Training data requirements, bias testing, dataset documentation |
| Logging and record-keeping (Art.12 + Art.19) | 2h | What to log, retention periods, audit trail format |
| Human oversight in code (Art.14) | 2h | Override mechanisms, confidence thresholds, escalation flows |
| GPAI model integration | 2h | Using foundation models in products, provider chain obligations, transparency pass-through |
| Accuracy and robustness (Art.15) | 1h | Adversarial testing, fallback behaviour, graceful degradation |
| Total | 14h |
Documentation the NCA Expects
- Training records per engineer with module completion and dates
- Technical documentation under Art.11 for each AI system the team developed or substantially modified
- Risk management records showing foreseeable risk identification and control measures
- Test result archives for accuracy, robustness, and bias evaluation
- Log architecture documentation confirming Art.19 compliance for high-risk systems
Role 3: Operations / SRE / Platform Teams
Operations teams run AI systems in production. They are responsible for system availability, performance monitoring, incident detection, and the operational response to AI failures. Under Art.26, they are often the first responders when a serious incident occurs.
What Art.4 Requires for Operations Teams
Operations and SRE staff dealing with AI systems must be able to:
- Identify the signals that constitute a "serious incident" under Art.73 — specifically, where AI system malfunction results in death, serious bodily harm, or significant property damage, or where it causes a breach of fundamental rights.
- Execute the Art.26(5) incident reporting workflow: notify the provider, preserve logs, and where applicable notify the relevant market surveillance authority.
- Maintain operational continuity during AI system downtime in a way that does not create compliance gaps — for example, ensuring fallback processes do not inadvertently make decisions the AI system was restricted from making.
- Interpret Art.72 post-market monitoring outputs: if the provider shares post-market monitoring data, operations teams must understand what to look for.
Minimum Curriculum Elements for Operations Teams
| Module | Duration | Coverage |
|---|---|---|
| EU AI Act for operations: roles and triggers | 1.5h | Deployer obligations under Art.26, which events require action |
| Incident classification and reporting (Art.73) | 2h | Serious incident definition, reporting timeline, authority notification |
| Log retention requirements (Art.12 + Art.19) | 1.5h | Minimum retention periods, what to preserve after incident |
| Human override and fallback procedures | 2h | When to disable AI, how to document the decision |
| Post-market monitoring basics (Art.72) | 1h | What providers must send, how to respond to monitoring findings |
| Total | 8h |
Documentation the NCA Expects
- Training records for all operations staff with named AI systems in scope
- Operational runbooks referencing Art.26 incident response steps
- Incident log showing any AI-related operational events and their classification (serious / non-serious)
- Evidence of log architecture meeting Art.19 requirements for each high-risk AI system in production
- Escalation contact list for provider notification under Art.26(5)
Role 4: Customer Support
Customer-facing support agents increasingly interact with AI-generated outputs — ticket summaries, response drafts, knowledge base retrieval results. Under Art.4, they must be literate enough to recognise when AI output is unreliable and when Art.50 disclosure requirements apply.
What Art.4 Requires for Support Agents
Customer support staff dealing with AI systems must be able to:
- Recognise common AI failure modes relevant to their tools: hallucination in ticket summaries, stale knowledge retrieval, confident but incorrect responses.
- Apply Art.50 transparency obligations: if a customer asks whether they are talking to an AI (and it is a chatbot or voice assistant), agents must know the disclosure requirement applies.
- Know when to escalate AI output for human review — and have a clear escalation path documented.
- Understand basic prohibited practice boundaries under Art.5: they must not use AI output in ways that manipulate, exploit, or deceive customers.
Minimum Curriculum Elements for Support Agents
| Module | Duration | Coverage |
|---|---|---|
| AI basics for support: what your tools actually do | 1h | What LLMs do, why they hallucinate, confidence vs accuracy |
| Art.50 transparency obligations | 1h | When disclosure is required, how to handle "are you an AI?" questions |
| Recognising unreliable AI output | 1.5h | Hallucination signals, knowledge cutoff issues, contradiction detection |
| Escalation and human override procedures | 1h | When not to send AI-generated text, escalation workflow |
| Art.5 prohibited practices — support context | 0.5h | Manipulative AI techniques, subliminal nudging, what not to do |
| Total | 5h |
Documentation the NCA Expects
- Training completion records per agent with module dates
- A written policy document governing permitted uses of AI tools in support workflows
- Escalation log showing cases where AI output was overridden or escalated
- Art.50 disclosure script or written procedure confirming agents know the requirement
Cross-Role Requirements: What Every Staff Member Needs
Regardless of role, there is a baseline Art.4 floor. Every employee who interacts with AI systems in any capacity — even peripherally — needs a minimum general literacy module covering:
- What the EU AI Act is and when it applies (scope: providers, deployers, and their staff)
- What the organisation's AI governance structure is and who the AI compliance contact is
- How to report an AI-related concern or incident internally
- What personal data protections apply when AI processes customer or employee data
This baseline module should be 1.5–2 hours and completed by all staff before any role-specific modules begin.
Building the Role-Specific Evidence Package
When an NCA initiates an inspection, the evidence package for Art.4 compliance must be queryable by staff member and by AI system. A useful format:
/ai-literacy-records/
/by-staff/
[staff-id]-training-log.json # modules completed, dates, systems in scope
[staff-id]-role-classification.md # which Art.4 tier applies to this person
/by-system/
[system-id]-literacy-coverage.md # which roles interact with this system, training verified
/policies/
ai-use-policy-[version].pdf # signed by management, dated
escalation-runbook-[version].pdf # Art.26 incident response
/audit/
last-literacy-gap-assessment.md # dated, gap count, remediation plan
The gap assessment document is particularly important. NCAs expect that you have actively assessed whether your current training achieves "sufficient" literacy — not just that training happened. A dated gap assessment showing you identified shortfalls and addressed them is strong positive evidence.
Infrastructure Note: Where Records Live Matters
Under Art.10 and the GDPR, training records that include personal data (staff names, completion dates, role assignments) are subject to data protection obligations. If your AI literacy records are stored on US-parent cloud infrastructure, you may face a CLOUD Act exposure: the record of who is trained on which AI system is metadata that a US authority could compel disclosure of without EU legal review.
EU-native infrastructure for your compliance records — HR systems, learning management platforms, document stores — closes this gap. The compliance record becomes as sovereignty-compliant as the AI systems it governs.
What Comes Next in This Series
- Post #4: GPAI Tool Integration and Developer Literacy — Copilot, Claude, GPT-4 in Production (Art.4 obligations when using foundation models)
- Post #5: AI Literacy Audit Trail: Documentation Templates and NCA Inspection Evidence Package (complete templates, checklist)
The August 2, 2026 enforcement date means most organisations have fewer than 60 days to complete role-specific training rollouts and produce the documentary evidence that survives an NCA inspection.
EU-Native Hosting
Ready to move to EU-sovereign infrastructure?
sota.io is a German-hosted PaaS — no CLOUD Act exposure, no US jurisdiction, full GDPR compliance by design. Deploy your first app in minutes.