AI Digital Signage Governance in the EU

Inventory the function, decision and affected audience

Begin with use cases, not vendors. A copy assistant may propose a headline that a campaign team reviews. A generative image tool may create a synthetic person for an advert. A translation model may adapt emergency or wayfinding content. A scheduler may rank content using stock, weather and aggregate performance. Predictive maintenance may estimate player failure. A kiosk assistant may interact directly with customers. Camera analytics may infer attention, age range or emotion. Each function produces different outputs and risks.

Record the intended purpose in operational language. "AI personalisation" is not enough. State what input the system uses, what it predicts or generates, whether the output reaches a person, whether it influences access, price, employment or another decision, and what a human can change. Include the locations and audiences, particularly workers, children, patients or people seeking public or essential services.

Map the model and service chain. A signage CMS may call a third-party model through an API; an agency may generate assets in its own tool; an analytics camera may contain an embedded model; a retailer may fine-tune or materially modify a supplied system. Record model, version, provider, hosting region, data sources, update mechanism and downstream system. A feature can change classification when its intended purpose or integration changes.

Classify role and risk without treating all AI as high-risk

The European Commission describes the majority of AI systems as minimal risk. A system is not high-risk merely because it uses a powerful model, is installed in a public place or affects screen content. Article 6 uses defined routes: certain safety components or products subject to listed Union legislation, and intended purposes listed in Annex III. Annex III covers specific uses in areas such as biometrics, critical infrastructure, education, employment, essential services, law enforcement, migration and justice.

A model that recommends playlist order from aggregate stock and time data will not normally become high-risk solely for that reason. A tool used to assess job candidates on a recruitment kiosk, control access to an essential service or perform certain biometric categorisation may enter a very different route. Some Annex III systems may fall outside high-risk classification under Article 6(3) when they meet its narrow conditions and do not materially influence the decision, but profiling of natural persons prevents reliance on that derogation. Document any conclusion.

Check prohibited practices before high-risk requirements. Depending on purpose and context, manipulative techniques, certain exploitation of vulnerabilities, particular biometric categorisation and emotion recognition uses can be prohibited. For example, the Act restricts emotion recognition in workplaces and education institutions subject to stated exceptions. A marketing feature marketed as "mood-based content" cannot be approved from a generic innovation budget.

Determine the organisation's role. Buying and using a supplied AI system usually points toward deployer duties. Developing and placing a system on the market under the organisation's name, or making a substantial modification or changing intended purpose in defined circumstances, can create provider responsibilities. Map providers, importers, distributors and deployers contractually, but assess the facts rather than accepting a vendor's label.

Apply Article 50 transparency to the use case, not the buzzword

Article 50 contains several distinct transparency duties. Providers of AI systems designed to interact directly with people must enable people to be informed that they are interacting with AI unless that fact is obvious in context. A conversational wayfinding or service kiosk may therefore need a clear disclosure at the start of the interaction. A passive playlist optimiser does not interact directly with the viewer in the same way.

Providers of systems that generate synthetic audio, image, video or text must support machine-readable marking and detection under Article 50(2), subject to the provision's scope, technical feasibility and applicable exemptions or transitional arrangements. This is a provider-level obligation and is not identical to every deployer putting a visible "made with AI" line on every asset.

Deployers of emotion recognition or biometric categorisation systems have a duty to inform exposed people under Article 50(3), alongside applicable data protection requirements. Deployers also have disclosure duties for deepfake content and, in defined circumstances, AI-generated or manipulated text published to inform the public on matters of public interest. The text rule contains an exception where there has been human review or editorial control and a person or entity holds editorial responsibility. A superficial spelling check is not meaningful editorial control.

Therefore, Article 50 is use-case dependent. A human-reviewed product description, a synthetic spokesperson video, an AI chatbot, an emotion camera and an algorithmic schedule require separate analysis. Define where a disclosure appears, what it says, when it is presented, which languages it uses and how it remains perceivable on a physical screen. Do not rely only on metadata when the deployer duty requires a notice understandable to exposed people.

• Identify the precise Article 50 paragraph and responsible role.
• Check whether interaction or artificial origin is already obvious in context.
• Separate provider machine-readable marking from deployer disclosure.
• Document genuine human review and the person holding editorial responsibility.
• Test visibility, timing, language and accessibility on the deployed screen.
• Retain the asset, model version, review and disclosure decision.

Run GDPR and biometric analysis alongside the AI Act

AI Act classification does not replace GDPR. A minimal-risk AI system may still process personal data unlawfully; a high-risk system still needs an applicable data protection basis and controls. Map camera frames, device identifiers, interaction records, prompts, account data, inferred characteristics and model feedback. Establish purpose, necessity, lawful basis, transparency, retention, security, data subject rights, processor arrangements and international transfers.

Distinguish detection, categorisation, verification and identification. A camera detecting that a person is present differs from creating a persistent template to recognise that person. Facial images can be personal data; biometric data processed to uniquely identify a person can be special-category data. Emotion and demographic inference may create additional fairness, accuracy and fundamental-rights risks even where the system claims not to identify anyone.

Screen for a DPIA before public-space monitoring, innovative profiling, large-scale deployment, vulnerable audiences or dataset matching. Use edge processing, immediate deletion of raw frames, non-persistent counts and coarse aggregation where they meet the purpose. Verify the supplier's claim that images never leave the device, including diagnostics, support access and model-improvement flows.

Avoid function creep. A sensor procured for anonymous queue counts should not later activate age, attention or emotion fields through a dashboard toggle without a new classification and privacy review. Likewise, prompts containing customer, employee or unreleased product information should not be submitted to a general model until data use, retention, training and access are contractually understood.

Procure evidence, change control and exit - not just model access

Require a system description, intended purpose, role assessment, model and version information, input and output specification, performance limits, known failure conditions, cybersecurity controls, logging, transparency capability and applicable conformity evidence. For content generation, ask how machine-readable marking is produced and preserved through resizing, rendering and the signage pipeline. For analytics, require a complete data flow and configurable retention.

Define prohibited uses and approved boundaries in the contract and internal policy. A supplier should not activate a new inference, replace the model, expand training reuse or move processing regions without notice and reassessment. Set service obligations for material model changes, security incidents, serious performance degradation, regulatory requests and correction of misleading outputs. Ensure subprocessors and general-purpose model providers are visible.

Test with representative signage inputs. Translation should be evaluated on safety, allergen, pricing and wayfinding terminology, not only campaign copy. Creative tools should be checked for brand, intellectual property, stereotyping and fabricated claims. Analytics should be tested across lighting, viewing angle, crowd density and relevant demographic groups. Record accepted limitations and prevent the output being used beyond them.

Plan exit. The organisation should be able to export necessary records, remove model and API credentials, delete retained prompts or observations, replace an embedded service and preserve evidence needed for audits or incidents. Avoid a design where disabling the AI also prevents basic publishing or device management.

Operate an AI release gate with human authority and literacy

Assign an accountable use-case owner, technical owner, content or decision owner, privacy lead and legal or compliance reviewer as appropriate. The EU AI Act's AI literacy obligation means providers and deployers must take measures suited to the knowledge, context and affected people. Training should be role-specific: a content editor needs to recognise hallucinated claims and synthetic-content rules; an operator needs to understand override and failure; procurement needs evidence and change clauses.

Put a release gate around new use cases and material changes. Confirm purpose, classification, role, Article 50 decision, privacy review, testing, human oversight, disclosure, monitoring and fallback. Give reviewers enough information to challenge the output. A person who must approve thousands of generated variations without time or tools is not effective oversight.

Monitor both technical and human outcomes: incorrect or unsafe copy, translation failures, demographic performance gaps, disclosure defects, overridden recommendations, complaints, incidents and model changes. Set thresholds for pausing a use case and reverting to a non-AI workflow. Preserve model version, prompt or configuration, source data reference, output, reviewer, publication targets and any disclosure so a release can be reconstructed.

Review the register at least when purpose, model, input data, audience, geography, supplier or downstream decision changes. Follow the Commission's current implementation guidance and national authority material. The practical goal is not to label the entire signage estate "AI compliant"; it is to maintain a defensible decision and evidence set for every use.

Official sources and current implementation material

• Regulation (EU) 2024/1689 - official AI Act text, including Articles 4, 5, 6 and 50.
• European Commission: Article 50 transparency obligations - current role, content and timing guidance.
• European Commission: Navigating the AI Act - risk model, high-risk examples and deployer obligations.
• European Commission: high-risk AI system classification guidance - practical classification and current timeline material.
• European Commission: AI literacy - Article 4 operational context.
• EDPB Opinion 28/2024 - data protection considerations for personal data in AI models.