Proptech AI and EU AI Act Compliance: What Counts as High Risk

This page answers one question for proptech teams: of the AI you actually ship, tenant screening, automated valuation, access control, lettings chatbots and building management, which parts sit inside Annex III high risk, which sit under Article 50 transparency only, and which sit outside the regulated categories altogether. Enforcement powers have been live since 2 August 2026 and national market surveillance authorities are already exercising them, so the classification work is not a planning exercise.

What the Act lists, and what it does not

There is no property or real estate category in Annex III. Nothing in the Act regulates proptech as a sector. Classification turns entirely on function, and the relevant entries sit in two places: point 1 on biometrics and point 5 on access to essential private and public services.

Tenant screening

Annex III point 5(b) covers AI systems intended to be used to evaluate the creditworthiness of natural persons or to establish their credit score, excluding systems used to detect financial fraud. Recital 58 is explicit that creditworthiness assessment determines access to essential services including housing. If your screening product scores an applicant's ability to pay rent, ingests credit bureau data, income verification or payment history, and returns a score, a band or an accept/decline recommendation, it is a high-risk system. The wrapper being a lettings workflow rather than a lending workflow changes nothing.

Screening that does not evaluate creditworthiness is a harder call. Right to rent document checks, reference chasing and identity verification against a submitted document are not credit scoring and are not separately listed. Where it tips over is composite scoring: the moment a model blends affordability signals with behavioural or demographic features to produce a single tenant suitability score, treat it as 5(b) and classify accordingly.

Do not expect the Article 6(3) exemption to rescue a screening product. The exemption lets an Annex III system escape high-risk status where it performs only a narrow procedural task, improves the result of a completed human activity, detects decision patterns or deviations, or carries out a preparatory task. Article 6(3) also states that the exemption never applies where the system performs profiling of natural persons. Tenant scoring is profiling. The route is closed.

Valuation models

An automated valuation model that prices a building is not in Annex III. Every entry in point 5 concerns the assessment of natural persons. A model that estimates what a two bedroom flat is worth assesses an asset, not an applicant, and no listed category captures it. Portfolio yield forecasting, rent benchmarking, refurbishment cost estimation and capital expenditure prediction sit outside the high-risk regime on the same reasoning.

Two caveats. If the valuation output is a component inside a lender's creditworthiness pipeline, the lender's system is high risk and you will be asked for documentation, data lineage and performance evidence through contract even though your own component is not separately classified. And if you ever extend a valuation model to score the occupant rather than the property, you have built a different system with a different classification.

Access control and biometrics

This is where proptech most often trips. Annex III point 1(a) covers remote biometric identification systems and expressly excludes systems used for biometric verification where the sole purpose is confirming that a person is who they claim to be. A turnstile where a resident presents their face or fingerprint to confirm a claimed identity is one to one verification and is excluded. A lobby camera that matches faces against a database of enrolled or unknown persons without them presenting themselves is remote biometric identification and is high risk.

Article 5 bites harder than Annex III here, and has applied since 2 February 2025. Emotion inference in workplace settings is prohibited under Article 5, which rules out office occupancy or wellbeing products that infer stress, attention or mood from camera feeds of employees. Biometric categorisation that infers race, political opinions, trade union membership, religious beliefs, sex life or sexual orientation is prohibited. Untargeted scraping of facial images from the internet or CCTV to build or expand recognition databases is prohibited. Any access control vendor that enriched its gallery this way is already exposed.

Building management

Annex III point 2 covers safety components in the management and operation of critical digital infrastructure, road traffic and the supply of water, gas, heating and electricity. An HVAC optimiser or energy management system inside a single commercial building is not supplying electricity or heating to the public and is generally outside this entry. A control system operating a district heating network is a different matter and needs a proper assessment.

Provider or deployer

If you build the screening or access product and place it on the market under your own name or trade mark, you are the provider and you carry Articles 9 to 15, 17, 49 and the conformity assessment. If you are a letting agency, build operator or asset manager running someone else's tool, you are the deployer under Article 26.

Article 25 is the trap. A deployer becomes a provider, with the full provider obligation set, if it puts its own name or trade mark on the system, makes a substantial modification, or changes the intended purpose so that the system becomes high risk. White labelling a third party screening engine into your platform makes you the provider of a high-risk system.

Deployers of Annex III point 5(b) creditworthiness systems also fall within the Article 27 fundamental rights impact assessment duty. That applies to letting agencies and build to rent operators running tenant credit scoring, not only to public bodies.

What the obligations concretely require

• Risk management (Article 9): a documented, iterative process running across the lifecycle, not a one off risk register entry.
• Data governance (Article 10): training, validation and test sets examined for bias. For tenant screening this means testing outcome rates across protected characteristics and proxies such as postcode, benefit income and tenancy history gaps, and recording what you found.
• Technical documentation (Article 11) and logs (Article 12): automatic recording of events over the system's lifetime. Deployers must keep logs under their control for at least six months unless other law requires longer.
• Human oversight (Article 14) and Article 26(2): oversight assigned to named people with the competence, training and authority to override a decline. A letting negotiator who cannot overturn a model output does not satisfy this.
• Conformity assessment and registration: for Annex III point 5(b) the route is internal control under Article 43(2). Biometric systems under point 1 may require a notified body. Registration in the EU database follows under Article 49.
• Transparency (Article 50): lettings chatbots must disclose they are AI. Providers of systems generating synthetic image, audio or video content must mark outputs in a machine readable format, which reaches virtual staging and AI generated listing imagery, and deployers of deep fake imagery must disclose it. These duties have been enforceable since 2 August 2026.

The dates that bind

• 2 February 2025: Article 5 prohibitions and the Article 4 AI literacy duty have applied since this date.
• 2 August 2026: enforcement powers, Article 50 transparency and Article 53 GPAI obligations became enforceable. All in force now.
• 2 December 2027: standalone Annex III high-risk obligations apply, following the Digital Omnibus provisional agreement of May 2026, which is still pending formal adoption. This is the next hard date, 416 days away.
• 2 August 2028: Annex I embedded high-risk obligations apply.

Actions for the next quarter

1. Write a function level inventory, not a product level one. List every model and rule set, its output, who it assesses and what decision it informs. A single platform typically contains one high-risk function, tenant scoring, and six that are not.
2. Audit your biometric estate against the one to one test. For every camera and reader, record whether the subject presents themselves to confirm a claimed identity or is matched passively. Document the answer per site. Remove any emotion inference from employee facing deployments now, that obligation is not waiting until 2027.
3. Run a bias test on tenant screening outcomes before you are asked. Pull twelve months of decisions, measure decline and score distribution across protected characteristics and known proxies, and keep the output. Article 10 evidence takes months to assemble retrospectively.
4. Check your contracts for Article 25 exposure. Any screening engine you resell under your own brand makes you the provider. Decide deliberately whether you want that, and if not, change the branding and the contract.
5. Start the Article 27 assessment if you operate tenancies directly. Build to rent and managed portfolio operators deploying credit scoring need the fundamental rights impact assessment, and it depends on information only the provider holds.

Most proptech platforms turn out to have a narrower high-risk footprint than their teams assume, usually one screening function and occasionally a biometric one, with valuation and operations work sitting outside Annex III entirely. The value is in proving that boundary with documentation rather than asserting it. If you want a first pass classification across your product surface, the free screener at https://www.getactcomply.com/check walks through the Annex III entries function by function and tells you which ones your systems touch.