Short answer: which tablet AI features turn a hardware order into a documentation project
Features that only adapt the device to its user — adaptive brightness, on-device photo denoising, keyboard prediction — are usually not the problem. Features that score, identify, monitor or make decisions about people are: 1:N face identification on a shared fleet, camera-based people counting, fall detection, attention or emotion analytics in classrooms, automated content moderation with real consequences for a student. Those are the rows where you must demand a feature-level mapping, an Annex IV-style documentation pack, a risk-management record and evidence of human-oversight design before you sign.
The decision rule is simple and it is the one thing most spec sheets hide: classification follows intended use, not the chip. The same NPU-equipped board is an ordinary display controller in a signage player and a potentially high-risk system in a patient-monitoring tablet, because the Act classifies AI systems by the risk their use poses to people, not by their hardware. A second rule follows from the first: the obligation attaches to whoever places the system on the market under its own name or trademark, so a white-label programme can move the provider role onto your brand even though the ODM built the board.
Two limits apply to everything below. Final classification is a legal determination for the provider and deployer — this checklist is a supplier-qualification tool, not a legal opinion, and we can map features but cannot certify a classification for you. And where this article quotes a retention period or a penalty figure, those are publisher-reported readings of the regulation, not statements of law; verify them against the regulation text and current Commission guidance before you rely on them in a contract.
Who owns which document: provider, importer, distributor, deployer
Ranking pages on this topic stop at the regulation. The device question is who signs the file. Name four parties in the supply agreement before you discuss features:
- Silicon or module supplier — often owns the model weights, the training methodology and the model card, and will not talk to you directly.
- ODM/OEM — integrates the feature, controls the firmware, and is the only party who can produce a build-specific feature list.
- Brand owner — the name on the box. If your logo ships on the device, you may be the provider for the purposes of the Act, with the documentation burden that implies, even though you never wrote a line of code.
- Deployer — the school, hospital or retail chain actually running the fleet, who must receive instructions for use sufficient to meet its own obligations.
The obligation chain runs through technical documentation and instructions for use, and through a design that lets the deployer implement human oversight — that framing is consistent with the high-level summary of the Act published at artificialintelligenceact.eu. Note what that means commercially: the OEM’s documentation is not finished when it satisfies your engineers; it is finished when it can be handed to a school’s data-protection officer or a hospital’s quality team.
Use this one-line test at the validation meeting: “If our logo is on the box, do we hold the Annex IV pack, or only the OEM’s datasheet?” If the answer is the datasheet, the programme has an unfunded documentation gap.
Feature-by-feature triage checklist for the tablets on your shortlist
Work down the spec sheet and paste every AI-labelled feature into one row — including features the OEM does not label as AI, such as “smart framing”, “scene detection” or “adaptive audio”. The middle column is the question that decides the tier; the right column is the artifact to demand in writing.
| Feature on the spec sheet | What decides the risk tier | Artifacts to demand before PO |
|---|---|---|
| Face unlock | 1:1 verification of the enrolled owner is a different product from 1:N identification across a shared student or staff fleet | Intended-use statement; whether templates leave the device; deletion path on user offboarding; false-accept handling |
| Voice assistant, on-device translation | Whether audio or transcripts leave the device, whether they are stored, and which third-party model is licensed | Data-flow diagram; model name and licence; on-device vs cloud split per function |
| Camera image enhancement | Enhancement for the user’s own photo is a different use from people-counting, demographic inference or queue analytics in retail and signage | Explicit statement that no person-level analytics run in the firmware; feature profile per SKU |
| Fall detection, health-adjacent sensing | Highest-scrutiny category even when marketed as a convenience; intended use is the whole argument | Written intended-use statement; validation and testing procedure; alert escalation and false-negative handling; human review path |
| Content moderation on classroom 1:1 fleets | Automated flagging that triggers disciplinary or safeguarding action involves decisions about people | Moderation policy; false-positive handling; named human review step; logs retention |
| OCR, document scanning in POS or field service | Usually low-scrutiny input processing — unless output feeds a scoring or eligibility decision | Confirmation of what the extracted data feeds into downstream |
| Add your own row | Ask: does it identify, score, monitor or decide about a person? | Same three questions: intended use, data touched, human override |
The Act’s own high-risk use areas are listed in the regulation — biometrics, education and vocational training, access to essential services among them. Do not rely on a supplier’s summary of those categories: read the Annex text and the current Commission guidance, because a feature can sit inside a listed area through its deployment context rather than its packaging.
The documentation pack to request, mapped to Annex IV content areas
You do not need to write Annex IV. You need to recognise whether what you were handed is an Annex IV-style file or a marketing brochure. The content areas a reviewer should look for are the system description and architecture, key design choices with their rationale and assumptions, data requirements, training methodology, validation and testing procedures, and performance metrics — the structure summarised in the peer-reviewed review at PMC11379845. Score each item on the OEM’s response instead of accepting a claim.
| Content area to request | What “supplied” looks like | Score |
|---|---|---|
| System description and architecture | Named subsystems, where inference runs, what is on-device vs cloud | Supplied / partial / refused |
| Key design choices and assumptions | The assumptions the feature was designed under, in writing | Supplied / partial / refused |
| Data requirements | What data trains or tunes the model, and where it came from | Supplied / partial / refused |
| Validation and testing procedures | Test conditions, population tested, evaluation methodology | Supplied / partial / refused |
| Performance metrics | Accuracy benchmarks with the conditions they were measured under | Supplied / partial / refused |
| Human-oversight design | Where a human can intervene, override or stop the feature, and what the deployer must configure | Supplied / partial / refused |
| Accuracy, robustness, cybersecurity statements | Known foreseeable circumstances that degrade performance | Supplied / partial / refused |
Where the OEM trained or fine-tuned the model, request the training and validation methodology. Where a third-party general-purpose model is embedded — increasingly the case in assistants and translation — request the model card and licence terms instead, plus a statement of who documents what. A third-party model in the stack changes the ownership map, not the buyer’s need for the map.
The request format we send to buyers’ compliance teams is deliberately mechanical: one row per AI feature, per firmware build, listing the build ID, the model, the data touched, whether inference is on-device or cloud, and the artifact supplied. It is an operator-described procedure, not a certification — but it produces a document a procurement committee can actually score.
Change control: what an OTA firmware update does to your file
This is the part generic explainers miss, and it is the part that breaks school districts and hospital groups two years after delivery. Technical documentation is expected to exist before a high-risk system ships, and providers are reported to keep it current across updates after deployment, with a retention period on the order of ten years — that reading comes from a vendor guide at openlayer.com and should be confirmed against the regulation text before you write it into a contract.
Practically, you need three clauses:
- A definition of a documentation-triggering change. Model swap, new sensor use, new analytics module, changed retention of captured data. A model swap in the voice assistant is not a security patch.
- A versioned bundle ID tied to each firmware build shipped. When an auditor asks in year three what was on the device, the answer is a document, not a memory.
- A right to withhold release approval. No updated bundle, no OTA approval — the same weight you give sample approval.
Keep the AI documentation bundle linked to, not merged into, the CRA/SBOM file and the battery or digital-product-passport files. They change on different cycles and answer to different reviewers, and merging them means every security patch invalidates a document you did not intend to touch.
Six red flags in an OEM’s compliance response
- A single “EU AI Act compliant” certificate with no feature-level mapping. Compliance is per system and per intended use, not per factory.
- The datasheet offered as technical documentation. Specifications are inputs to documentation, not documentation.
- Refusal to say whether inference is on-device or cloud, or which third-party model is embedded.
- No named person or function accountable for the documentation bundle — only a sales contact.
- “Documents will follow after purchase.” The documentation is expected to exist before the system ships, not during a post-launch audit.
- Penalty-driven reassurance (“fines only hit big vendors”). Publisher-reported exposure is described as up to EUR 35 million or a percentage of global annual turnover depending on the breach, per cybersaint.io — quoted here to illustrate severity only, not as a legal statement for your case.
Deployment scenarios that change the answer
- Classroom 1:1 rollout. Discuss content moderation and any attention analytics with the school’s data-protection officer before the pilot, with the human-review path documented. If you are bidding into a tender, pair this with the artifacts in our education tablet tender supplier checklist.
- Retail POS and self-service kiosks. Camera-based customer analytics may sit on the same SKU family as a plain order-taking unit. Specify firmware and feature profile per SKU, not per model family.
- Digital signage fleets. Audience measurement is the feature that turns a display into a documented AI system.
- Healthcare and care-home use. Treat any sensing feature as requiring the intended-use statement in writing before you accept a sample.
In each case the requirement is the same: get the answer before the pilot, not after. Market certification — CE, ANATEL, BIS, SASO — is a separate track and does not substitute for any of this; our Android tablet market certification guide covers that side, and rolling out managed fleets also needs the provisioning evidence in the zero-touch enrollment pre-provisioning checklist.
Quick answers to the questions procurement teams ask most
Does a tablet with face unlock count as high-risk?
Only if the intended use falls in a high-risk area — 1:N identification on a shared fleet is a different question from 1:1 verification of an enrolled owner. Demand the intended-use statement and the deployment context in writing; the hardware cannot answer this.
Who is the provider when a European brand buys white-label tablets from an ODM?
Very often the brand owner, because the system is placed on the market under its name or trademark. That is why the Annex IV pack must be transferable to you, not merely viewable at the factory.
Is on-device AI treated differently from cloud AI?
The documentation still has to describe where inference runs and what data leaves the device. On-device processing reduces data-protection exposure; it does not remove the documentation duty for the feature itself.
When the OEM cannot answer, close the gap yourself
Log every unanswered feature as an open item with an owner and a date. An unresolved gap is a procurement finding, not a reason to soften the requirement. Route anything that looks like a high-risk classification to your regulatory affairs function or external counsel, and to a notified body where a conformity assessment is in scope. Never fill silence with a verbal assurance — ask for the artifact, or record its absence in the evaluation file.
If you want a starting structure, request the AI feature classification checklist for your shortlisted SKUs and a tablet selection quote. We return one row per AI feature per firmware build, with the artifact status marked, so your compliance team can score the supplier rather than trust a claim. Start from the Snapdragon 685 11.97-inch business tablet or the T616 10.51-inch business tablet as reference configurations, and tell us which AI features are actually in scope for your deployment.
Request the AI feature classification checklist and a tablet selection quote — include your target market, fleet size and the on-device AI features on your requirement list.
