Face tagging is the process of connecting photos of a face to a person’s identity so those photos can be organized, searched, and managed together. Recently this task is shifting from being done by hand to AI-assisted processes, including facial recognition technologies.
At Portraiteer, one of our core tenets is personal data privacy, and as such, we were the first platform to integrate consent-aware automatic tagging and people organization in photos. We also give both teams who own photos and the individuals pictured within controls to withhold, limit, or revoke tagging when needed. This page explains our product logic behind our approach to consent, one that has set the standard across the DAM industry.
Note: This page is operational guidance, not legal advice. Every organization should confirm its own requirements with counsel, especially if it operates in jurisdictions with biometric privacy laws or across multiple states or countries.
The two motions of facial tagging
In practice, assigning names to faces usually happens in two distinct motions:
First, grouping together faces that appear to belong to the same person.
This is a visual matching and organization step. It doesn't use any names or identifying information other than the picture. This matching step creates groups of faces, each belonging to unknown people.
Second, connecting that grouped face data to a real person’s identity.
This is the identity-labeling step. It is the moment when a cluster of similar faces stops being just an internal visual grouping and becomes “this is Jane Smith” or “these photos belong to this specific attendee.”
These two motions do not carry the same privacy and compliance significance. The more sensitive step is the second one: linking a face or face cluster to a named person, because that is the point where identity-linked tagging begins and where consent controls matter most.
Motion 1: Face clustering and internal review
After photos are uploaded, Portraiteer can help internal studio members, such as contributors and admins, detect faces and surface groups of faces that likely belong to the same person. These faces are not tied to any identity, but rather appear in the Review Pane as suggested people clusters.
At this stage, the primary purpose is helping the internal team do visual sorting. A face or cluster may be visually consistent, but when unreviewed, it has not yet been tied to a specific real-world identity.
Motion 2: Identity-linked labeling
The second motion begins when a studio member says that a specific face, or a suggested group of faces, belongs to a particular person. This is the moment when visual sorting turns into identity-linked labeling.
Portraiteer treats this as the key compliance moment because the workflow has moved beyond “these faces look like the same person” to “this face is this named person.” At this point, we require an explicit tagging-consent basis before the identity-linked label can exist.
Types of Tagging Consents in Portraiteer
1. Studio or proxy authorization
When a new identity is created, Portraiteer asks the internal team to affirm whether it has authorization to use that person’s photos for identity-linked tagging. We think of this as a studio-side authorization layer.
In many event workflows, that authority may come from registration terms, ticketing terms, participation waivers, client contracts, venue rules, or other photo-use permissions collected upstream. Within the product, this studio proxy authorization can serve as one explicit tagging-consent basis.
That studio-side control is not just a green light. It can also function as a kill switch. If the person is a minor, has objected to tagging previously, or should not be tagged for any other reason, the studio can record authorization as withheld or revoked and stop future labeling at the source.
For teams that want a baseline disclosure in event intake flows, a common pattern is to state that event photography may occur, that photos may be used or distributed, and that the organizer may use internal labeling or tagging to manage those photos. The exact wording should be reviewed for the organization’s jurisdiction and use case.
2. Individual consent from the pictured person
Portraiteer also supports direct consent from the pictured individual. Teams can invite that person into a private, authenticated guest portal where they can view their photos and manage tagging consent directly. Within the product, this personal consent can also serve as an explicit tagging-consent basis.
This matters especially for organizations with recurring attendees, members, donors, students, guests, athletes, or others who appear across events over time. In those cases, collecting and maintaining individual preferences directly may provide a stronger and more durable compliance posture than relying indefinitely on internal authorization alone.
What counts as sufficient consent
To label an face as belonging to an identity, Portraiteer requires at least one approved tagging consent basis and no active tagging revocation on file.
The approved consent basis can come from either:
- studio-side proxy authorization, or
- the individual’s direct consent in the guest portal.
This policy allows internal teams to begin organizing photos and delivering value without requiring direct portal consent from every individual before any workflow can begin. In practice, the application accepts studio proxy authorization in place of individual consent in early workspaces, especially for workspaces younger than 1 month old and for identities with fewer than five face labels.
As the number of labels for a person increases beyond five, our product applies more pressure to users to document a comprehensive consent. Once an identity has more than five face labels on file without a corresponding individual consent, Portraiteer begins surfacing nudges that encourage studio members to invite that person into the guest portal to explicitly provide direct personal consent, or to upload files supporting an individual consent. The goal is to reduce compliance risk as identity-linked tagging becomes more extensive, while still keeping the workflow usable for early testers.
This reflects how many teams operate in practice: studio-side authorization may be enough to get started, but the more durable and defensible posture is to add personal consent as the same identities accumulate more tagged photos over time.
What happens when consent is revoked
Any active revocation on file for an identity takes precedence. If either the studio-side authorization or the individual-side consent is revoked, Portraiteer treats that identity as non-taggable.
Operationally, that means all existing face labels for the identity are immediately deleted and all future face labels are blocked, unless and until the tagging revocation is removed.
Why we do not treat all markets the same
Privacy and biometric expectations are not static. Some organizations are still early in building their internal legal and operational infrastructure. Others may already need a much more formal consent, retention, and governance program because of where they operate, who they serve, or how they use identity-linked photo data.
That is why Portraiteer aims to meet teams where they are without pretending every workflow carries the same level of risk. The product can be useful on day one, while still nudging teams toward clearer notice, more direct user control, stronger retention policies, faster response to objections or revocations, and broader use of individual consent as tagging volume grows.
The legal backdrop we keep in mind
Portraiteer is designed with the broader privacy and biometric regulatory landscape in mind.
For example, some jurisdictions place specific requirements on notice and consent before biometric data is collected or used. In the United States, laws such as Illinois’ Biometric Information Privacy Act and Texas’ biometric privacy law are often part of that analysis. In the EU, GDPR may apply a heightened standard where biometric data is used to uniquely identify a natural person.
Separate from biometric laws, photo and media release practices are already common across many institutions. That does not by itself answer biometric-consent questions, but it does show that proxy or institution-managed authorization around photography is already a familiar operational pattern.
Because legal requirements vary by jurisdiction and use case, organizations should evaluate their own workflows with counsel rather than relying on a single universal standard.
Where this is headed
Portraiteer is built for teams that need a workable starting point today and a stronger privacy posture over time.
That means requiring at least one explicit tagging-consent basis before identity-linked labels exist, surfacing alerts when tagging activity outpaces the consent posture on file, encouraging direct individual consent where appropriate, and making revocation immediate rather than theoretical.
We do not think organizations should treat privacy compliance as a static checklist. The legal and operational landscape around biometric and identity-linked data is still evolving, and tomorrow’s expectations may be stricter, clearer, or simply different from today’s.
For that reason, Portraiteer is designed to help teams aim at better principles, not just minimum thresholds. The product should make it easier to build habits that value consent, restraint, transparency, and user control, even while the workflow is already in motion. In our view, that is a more durable approach than optimizing for a fixed set of requirements that may quickly become outdated.