EU AI Act Kiosk Vision Documentation: Buyer Checklist

The short answer: before you sign a camera-equipped kiosk contract, demand six documents — (1) a written intended-purpose and role statement, (2) a vision model capability and limitation sheet, (3) the data protection inputs you need for your own assessment, (4) logging, record-keeping and human-oversight evidence, (5) supplier declarations and the conformity file including instructions for use, and (6) a change and re-assessment trigger schedule. Items 1–3 are shortlisting criteria: a supplier who cannot produce them at RFP stage should not reach the final round. Items 4–6 can be written into the contract as conditions with delivery dates.

That framing is deliberate. Most material on this query is written for lawyers or for software buyers: it defines risk tiers, restates penalty ceilings and closes with "consult a lawyer". None of it gives a deployer anything to put in an RFP. This checklist is a procurement artefact — who produces each document, what "acceptable" looks like, and which clause enforces delivery — because the documentation pack is what your sign-off file will be judged against after go-live, not before.

One caveat before the list: what actually applies to you depends on your role and on the system's classification, and neither can be inferred from the word "kiosk". The Act uses a risk methodology to define which systems count as high-risk and therefore carry horizontal mandatory requirements and conformity assessment before being placed on the EU market (as summarised by artificial-intelligence-act.com ). A queue-counting camera and a face-payment terminal are not the same conversation. Your job at this stage is not to classify the system yourself — it is to extract enough written information from the supplier that you and your counsel can.

Step 1 — Pin down intended purpose and your role before requesting anything else

The intended-purpose statement drives everything downstream, because the same camera module used for queue counting, age estimation or face payment sits in different risk conversations. Ask for it as a signed document, not a line in a brochure.

It must state the named use case, the population the system is used on, the operating environment (indoor or outdoor, lighting conditions, expected throughput), what the system must not be used for, and the identity of the named economic operator. A statement that describes only generic "customer insights" is not usable.

Pay particular attention to the role-transfer trap, which is where OEM buyers get caught. If you put your own brand on a unit, materially modify it, or repurpose it beyond the stated intended purpose, you may take on provider-side obligations rather than deployer-side ones. That is a legal question and you should confirm the position with counsel — but the factual basis for that conversation is the supplier's written statement of what the unit is intended to do and who remains the provider. Get it in writing, and get the supplier to state explicitly whether your intended configuration changes the role.

Cross-check the analytics roadmap while you are here. Published summaries of the Act state that AI must not use biometric data — facial recognition, voice recognition, fingerprints — to infer characteristics such as race, political views, religion, sexual orientation or health conditions ( artificial-intelligence-act.com ). If anyone in your organisation is considering demographic inference from kiosk cameras, that idea needs a written legal position before a pilot, not after.

Step 2 — Get a vision model capability and limitation sheet, not a brochure

Ask for the declared task — classification, detection or estimation — and the classes the model outputs. Then make the supplier separate what the model estimates from what the system decides . A kiosk that estimates an age band and flags a transaction for staff review is a different product from one that authorises a sale; the documentation must reflect which one you are buying.

Require the operating envelope: illumination range, camera height and angle, tolerance to occlusion, and queue-density conditions, plus the conditions under which the supplier acknowledges accuracy degrades. Ask directly whether the figures come from internal testing, third-party testing, or are qualitative. Accept the honest answer — "we have not tested at that camera angle" is more useful to you than a confident slide.

Ask where inference runs: on-device, on an edge gateway, or in the supplier's cloud. That single answer changes your data protection inputs, your network architecture and your incident scope, and it is also the natural split point for the rest of the documentation set.

Finally, require the human-override path in writing — what a customer sees when the model is uncertain, and whether a staffed fallback exists at every touchpoint where the model can block a transaction. Then write a demo script and run it yourself on the pilot unit. Treat the limitation sheet as falsifiable rather than as accepted fact.

Step 3 — Assemble the data protection inputs you will feed into your own assessment

You own the data protection assessment; the supplier owns the inputs. Specify what you need: data categories captured, whether images leave the device, retention on device and in transit, sub-processors and hosting regions, and the deletion method. Ask whether the retention default is configurable per site — an indefinite default is a negotiating point you can close at RFP stage but rarely after deployment.

The overlap with GDPR is explicit in published guidance: AI systems involving personal data must also comply with GDPR, with breach penalties cited at up to 4% of global turnover or EUR 20 million ( Trend Micro ). Treat your AI documentation and your GDPR records as one archive with two indexes, not two projects.

Biometric edge cases — age estimation, face payment, re-identification — should be flagged for counsel rather than resolved in a procurement document. What you can do is refuse to accept a prose paragraph in place of a data flow diagram. You cannot validate a flow you cannot draw, and a supplier who cannot draw one has not modelled their own system.

Step 4 — Require logging, record-keeping and human-oversight evidence

List the log fields you need: timestamp, model version, classification output, confidence or threshold applied, override action, and operator identity where a human intervened. Recordkeeping is part of the regulation's transparency design — published guidance frames technical documentation and recordkeeping as mechanisms that enable transparency about how a system operates and the impacts of its operation ( ISACA ).

Then ask the question most supplier answers break on: do logs survive a firmware update, and in what format can you export them? Add retention period and storage location to the same question. Request a redacted screenshot or extract of the oversight workflow your staff will actually use, plus the escalation path when a customer disputes a model decision.

Tie this to dispute handling. If a customer challenges an age decision or a payment failure three weeks later, what evidence can you produce, and within how long? If the answer is "we would have to ask the supplier", your archive has a single point of failure.

Step 5 — Collect the supplier declarations and conformity file, and read the instructions for use

Inventory the file: declaration of conformity, the standards referenced, the CE marking basis where applicable, the instructions for use, and the post-market monitoring plan. Guidance on conformity assessment describes the technical documentation set as covering general descriptions, specifications, development and training data, risk management documentation, testing and validation reports, and a post-market monitoring plan ( Future of Privacy Forum working paper ).

Read the instructions for use as a buyer, not as a lawyer. Published guidance states they should give deployers enough information to use the system appropriately, including human oversight measures, maintenance requirements and the anticipated lifespan of the system ( ISACA ). Compare that anticipated lifespan against your depreciation schedule and service contract. A mismatch is a budget problem you want surfaced before signature, not in year three.

Then verify the paperwork matches reality: the same economic operator, the same model, the same intended purpose as the configuration on your purchase order. Mismatched paperwork is the most common reason a documentation pack fails internal review — and it is entirely avoidable.

On penalties, stated plainly: widely reported ceilings include up to EUR 35 million or 7% of global annual turnover ( Trend Micro ), and a compliance-testing vendor summarises tiered amounts by violation type, including separate levels for prohibited practices, high-risk requirement violations and incorrect information to authorities ( Promptfoo ). These are secondary publishers. This research did not include a verified read of the regulation text itself, and penalty figures should be confirmed against the official journal version before they appear in any board paper.

Step 6 — Write the change and re-assessment triggers into the contract

Name the triggers explicitly: over-the-air model update, new camera or lens, firmware change to inference thresholds, a new use case at the same site, relocation to a different environment, and any change of sub-processor or hosting region.

Require a notification window before any model update ships to your fleet, plus a version register you can reconcile against your archive. An unversioned push silently voids the file you just spent a quarter assembling. Then specify who re-issues what: the supplier re-issues the limitation sheet and instructions for use; you re-run the data protection assessment and refresh the site record.

Add a documentation-on-termination clause. The file must remain available to you for your retention period after the contract ends, or your archive dies with the relationship. And make acceptance conditional: gate final payment or fleet-wide rollout on delivery of the version register, not just on delivery of the initial pack.

Step 7 — Ground the pack in your OEM/ODM supplier qualification

Fold these documentation questions into the same RFP section as MOQ, tooling and lead time. Suppliers who answer commercial terms fluently but stall on documentation are telling you something about the state of their engineering file, and that signal is worth as much as the price.

For payment-capable configurations, ask separately how the payment module's certification scope is documented and whether vision features share any data path with cardholder data. Keep the two evidence trails distinct — merging them creates a review burden you cannot discharge. For cash-accepting and cash-recycling configurations, confirm whether the cash module includes any AI-driven note validation, because that changes which model documentation you need to collect.

Before shortlisting, request a redacted pack for a comparable deployment. The quality of the redaction is itself a signal: a supplier with a mature documentation process can redact cleanly and quickly, while one assembling documents for the first time will either over-redact into uselessness or send something they should not have.

Step 8 — Archive and hand over: build the sign-off record

Use one folder per deployment site, containing the six documents, the version register, the assessment refresh and the named internal owner. Name the sign-off roles — procurement, compliance, IT security, site operations — and the single artefact each one signs, so nobody signs "the pack" in general.

Set the review cadence against the change triggers rather than against the calendar alone. Then test the archive against the three questions an auditor or a customer complaint will generate: what was this system intended to do at this site, what did it actually capture, and who reviewed the decision. If you cannot answer all three in under an hour, the pack is not finished.

One practice worth adopting on the pilot: walk the site yourself, record what the camera actually captures under real lighting and real queue conditions, and compare that recording against the supplier's limitation sheet before you accept it. That comparison is the difference between a filed document and a verified one.

What to do when the supplier cannot deliver

Grade your response. For gaps in items 1–3, pause the shortlisting — those are the documents that determine whether the rest of the pack can even be correct. For gaps in items 4–6, convert them into contract conditions with a fixed delivery date and a consequence attached.

Decline a self-declared "AI compliant" statement with no underlying documents. A declaration without the file is not evidence; it is a sentence.

Narrowing scope is a legitimate fallback. Disabling a disputed analytics feature at the firmware level reduces your risk exposure, provided the change is documented, version-controlled and reflected in the intended-purpose statement. Do not let it happen informally.

Finally, record a written position before go-live. Counsel review, the classification assumption you are operating under, and the open items with owners and dates. A written position taken before deployment is a governance decision; the same position reconstructed after an incident is a defence.

Frequently asked questions

Is a self-service kiosk with a camera automatically a high-risk AI system under the EU AI Act?

No — a camera alone does not determine classification. It depends on the intended purpose and whether the system falls within the high-risk categories. The practical step is to obtain a written intended-purpose statement and have counsel assess it against the Act's risk methodology.

Who counts as the provider versus the deployer when we buy a rebranded OEM kiosk?

It depends on what you do with the unit. Rebranding, material modification or use beyond the stated intended purpose can shift provider-side obligations onto you. Ask the supplier to state their position in writing, then confirm it with counsel before signature.

Does camera-based age verification count as biometric processing?

It can, depending on how the feature works and what it derives. This is a question for your data protection adviser, not for the supplier's sales team. Request the data flow diagram and the model's declared outputs so the assessment has a factual basis.

What can we do if our kiosk supplier cannot provide technical documentation?

Pause shortlisting if the missing items are the intended-purpose statement, limitation sheet or data protection inputs. For logging, declarations and change control, set a contract condition with a delivery date and gate rollout on it. If the supplier still cannot deliver, narrowing the scope at firmware level is a documented option.

Do we need a separate data protection impact assessment for people-counting features?

Whether a separate assessment is required depends on your processing and your supervisory context. What you can insist on regardless is that people-counting documentation states whether images leave the device, the retention default, and how counts are derived.

What has to be re-documented when the supplier pushes an over-the-air model update?

The supplier re-issues the limitation sheet, instructions for use and version register entry; you refresh the site record and re-run your data protection assessment if the data flow or purpose changes. This is why the version register belongs in the contract rather than in a support email.

Get the documentation pack before you shortlist

The pack is three things at once: a selection criterion that removes unsuitable suppliers early, a contract schedule that makes delivery enforceable, and the sign-off artefact your team will rely on after the first kiosk goes live. Treating it as a post-delivery formality is how rollouts end up retrofitting paperwork under time pressure.

If you are specifying a vision-enabled kiosk fleet and need the supplier-side documents described here mapped to your configuration — vision use case, payment module and cash modules included — request the AI Act documentation pack and kiosk spec sheet for your deployment. Our self-service kiosk OEM/ODM aggregation page lists the configurations, datasheets and quote request route so you can compare options against the six-document checklist before you commit. If you already have a pilot site, the fastest next step is a walkthrough: we validate the limitation sheet against your actual lighting, camera angle and queue conditions rather than against a laboratory description.