If you build software that processes faces, your architecture just got a regulatory dependency. The EU AI Act does not treat all biometric systems the same. It draws a hard line between verifying someone is who they claim to be and identifying an unknown person against a database. That distinction is now a legal constraint on your code.
This is not a compliance problem for the legal team to handle after the fact. It affects how you design your vector database, what your API returns, and whether your CI/CD pipeline needs a compliance check stage. Developers working on computer vision projects are only now realising how deep the changes go.
The technical fork that matters
Facial recognition breaks into two categories. One-to-one verification asks a single question: is this person who they say they are? You compare two face embeddings and return a similarity score. That is how you unlock your phone or verify a passport photo. The technical implementation is a straightforward comparison between two feature vectors.
One-to-many identification searches a face against an entire database. It asks: who is this person? That is what surveillance systems, OSINT tools, and law enforcement investigation software do. It is also where the EU draws the most aggressive line. Identifying someone in a crowd is categorised differently from verifying that someone is who they claim to be.
Under the EU AI Act, one-to-many identification in publicly accessible spaces is classified as unacceptable risk and banned outright. One-to-one verification is generally lower risk. If you are building the second kind, your technical choices around vector databases and search algorithms like HNSW or FAISS may soon require a Quality Management System if deployed within the EU. That is a significant shift for developers who have never had to think about compliance at the algorithm level.
Human oversight as a design pattern
The Act mandates human oversight for high-risk systems. This is not a checkbox or a confirmation dialog. The system must be interruptible. Your API cannot simply return a match: true boolean and call it done. It needs to surface the raw Euclidean distance, confidence intervals, and enough context for a human to override the AI decision. The raw data behind the match becomes part of the required output.
For developers building investigation tools, this changes the interface contract entirely. You need a UI that presents side-by-side comparisons with supporting metadata, not just a score. The human operator must remain the decision-maker with the tools to make an informed call. This is not just good UX anymore. It is the regulatory standard, and it applies whether your users are in Europe or not if your software is used there.
The cost of non-compliance
High-risk systems require registration in an EU database and extensive technical documentation covering training data, predictive logic, and error rates across demographic groups. Fines can reach 35 million euros or 7 percent of global revenue, whichever is higher. For solo developers and small firms, that documentation burden is the real barrier, not the technical implementation.
This is why the market is shifting away from black-box enterprise tools toward focused, auditable alternatives that provide face comparison without surveillance features. By building comparison models where the user provides both inputs and the application simply computes the similarity, developers can deliver enterprise-grade accuracy without crossing into unacceptable risk territory.
What this means for your build
The safest path is to keep the human in the decision loop and avoid mass surveillance architectures entirely. Build systems that give investigators the data they need and let them make the final call. If you are already building biometric software, ask whether your API could pass a human-in-the-loop audit today. If the answer is no, the EU AI Act just made that question urgent.