Privacy Policy

1. Overview

Real Time Entertainment and Management, LLC (“RTEAM,” “we,” “our,” or “us”) operates RTEAM.ai, a crowd analytics service for live events. Cameras installed at a venue by our customer send video to our processing systems, which measure how many people are present, how they move between areas of the venue, how long they wait, and the estimated makeup of the audience. At venues that switch it on, they also use facial recognition to tell returning guests from first-time guests and to count how guests move between the venue’s cameras. Organizers see the results as counts and charts on a dashboard.

This policy explains what we process, what we deliberately do not process, how long we keep it, and what rights you have. Section 4 is a list of things this platform does not do, and Section 5.2 sets out the one use it makes of facial recognition, and the limits on it. With a camera-based product, what is excluded matters as much as what is included, and those exclusions are enforced in our software rather than promised in prose.

2. Who This Policy Covers, and Who Is Responsible

This policy covers two groups of people:

• Platform users: event organizers, operators, and staff who hold RTEAM.ai dashboard accounts.
• Event attendees: people present at a venue where one of our customers has deployed cameras. Attendees never interact with our platform and hold no account with us.

Responsibility is split three ways, and we state it plainly rather than leaving it implied:

• For attendee data, the customer is the controller and RTEAM is the processor. The customer decides where cameras point, which areas are measured, whether facial recognition is switched on, which cameras are left out of it, and who sees the results. The customer is responsible for posting notices and obtaining any consents the law requires before cameras are deployed.
• For platform user accounts, RTEAM is the controller. We decide how account and dashboard data is handled.
• For model development, RTEAM acts as a controller in its own right, under a license the customer grants in our Terms of Service. A processor may not quietly repurpose data for its own benefit, so we say so here rather than burying it. See Section 6.

3. What We Process

3.1 Account and Platform User Data

• Name, email address, and password (stored hashed, never in readable form)
• Organization, team membership, and role assignments
• Session cookies and authentication tokens, set as httpOnly
• Multi-factor authentication enrollment, where you enable it
• Dashboard activity and API request logs
• IP address, browser, and device information
• Calendar event titles and times, only if a user chooses to connect a calendar account. This integration is optional and can be disconnected at any time.

3.2 Video From Venue Cameras

Cameras at a customer venue stream video to our processing systems, and record video that is stored so an event can be analyzed or re-analyzed later, including when venue connectivity prevents live analysis.

Video only. No audio is captured, transmitted, or recorded at any point. Our software discards audio where the camera connection is made, and records video with no audio track at all. This is not a setting an operator can turn on.

3.3 What We Derive From Video

Our analysis produces the following about people in view. Everything in this list is an estimate produced by a statistical model, not a measured fact about a person.

• Detection and tracking: the position of each person in the camera image and, where a camera has been calibrated for it, their position on the venue floor. Also their speed, whether they are stationary, and a track that follows them while they remain in view of a camera.
• Face detection: whether a face is visible, used as input to the crowd-level age, gender and expression estimates below. For those estimates, nothing about a face is kept after the frame is scored, and no face is ever stored as a photograph. The one exception is facial recognition for returning guests, described next.
• Facial recognition for returning guests, only at venues that switch it on: each time a camera the venue has not left out follows a person through its picture, up to five views of their face become one face template, a list of 512 numbers. Templates are compared across events to tell returning guests from first-time guests, and within an event to count how guests moved between cameras. This runs on the night’s recording, in a re-analysis after the event, never on live video.
• Estimated gender presentation of the crowd: an aggregate split between men and women, counted from appearance readings rather than from people. No per-person record carries a gender.
• Estimated age mix of the crowd: how those same readings spread across nine bands, being 0-2, 3-9, 10-19, 20-29, 30-39, 40-49, 50-59, 60-69, and 70+. No per-person record carries an age.
• Movement between areas: crossings of entrance and exit lines, entries into and exits from areas an operator has drawn (such as a bar, a food counter, or a queue), and how long a person stayed in each.

From these we compute venue-level results: occupancy, door crossings (came in, went out, guests), queue wait, dwell, the aggregate age and gender mix, and a positivity index: the share of readable faces that appeared to be smiling, counted across a night. These are aggregates; no individual's expression is stored or shown. At venues that switch on facial recognition, we also report returning guests as totals for each event: guests read, their share of the door count, first visits against returning guests, how many guests were read at one, two, three, or four or more events, and, for each camera, how many guests were read there and how many guests moved from it to another camera. Third-party models we license are credited on our attributions page.

3.4 Device and Technical Data

• Camera and venue device identifiers, configuration, and health
• Stream metadata such as timestamps, frame rates, and connection statistics
• The public internet address a venue device connects from, which we resolve once to an approximate city and state so the device can be labeled on the dashboard. This is a coarse guess that resolves to an internet provider location, often a different town. It is looked up about once per device, cached, and never per video frame.

4. What This Platform Does Not Do

The following are design decisions enforced in our software, not merely policy commitments.

• No audio. Sound is never captured, transmitted, recorded, or analyzed. We cannot hear anything at a venue.
• No saved images of faces. We do not extract, save, or store face photographs, cropped face images, or thumbnails. Face imagery exists only inside the venue video recording described in Section 3.2, and is never separated out into a picture of an individual.
• No race or ethnicity. We run no race or ethnicity classifier. That output is never computed, never stored, and never displayed. We hold no record of anyone’s race or ethnicity.
• No emotion recognition. We do not infer emotional state, mood, or sentiment about anyone. A smile is an expression, not a feeling: the software counts how many visible faces were smiling over each minute and keeps only that crowd-level share. No record of any single person carries an expression, and no engagement score is shown.
• No identification by name. We never collect names, contact details, ticket records, payment records, social media accounts, or identity documents. A face template made for returning guests carries none of these, and is never compared with any of them or with any outside database. The platform has no facility to tell anyone who a person is. We hold no identity database and match against none.
• Facial recognition only where switched on, and only on the recording. It is off unless a venue switches it on. It runs only on the night’s recording, at the venue’s cameras except any the venue leaves out, and a face is compared only with templates from the same venue, or from venues that have joined it in a guest group, never with any other venue. Where guests went is reported only as totals between cameras; no single person’s path is shown or exported. Nothing in the platform shows a face, returns a template, or accepts a photograph to search with.
• No watchlists and no surveillance products. We do not build or support watchlists, exclusion lists, or law enforcement identification, and our Terms of Service prohibit customers from attempting to use the platform that way.
• No advertising. We serve no advertising, run no advertising or marketing trackers and no third-party analytics scripts on our platform, and build no advertising profiles. Attendee data is never used for targeted advertising.
• No sale of data. We do not sell, rent, lease, or trade personal data or biometric data, and we do not share it for cross-context behavioral advertising.

5. Biometric Data

This section has two parts. Section 5.1 covers the face readings behind the crowd-level age, gender and expression shares in Section 3.3, for which no template is made and nothing about a face is kept. Section 5.2 covers facial recognition for returning guests, at venues that switch it on. We do not identify anyone by name. Where a privacy law treats the scoring of a visible face for an appearance estimate, or the making of a face template, as biometric processing, including under the Florida Digital Bill of Rights (Fla. Stat. § 501.701 et seq.), the California Consumer Privacy Act as amended (CCPA/CPRA), and the EU and UK General Data Protection Regulation, RTEAM, organized under the laws of the State of Florida, handles that processing as follows.

5.1 Face Readings for Crowd Estimates

• Purpose limitation. Face crops are scored only to estimate the age, gender and expression mix of the crowd as a whole.
• Not stored. For these estimates, no template, face print, or other reusable identifier is written. The crop exists for the inference and is discarded with the frame.
• Aggregate only. The stored result is a crowd total (a share, a denominator, an interval), never a record of one person.
• Protected. Video and analytics results are encrypted in transit and held in access-controlled systems. See Section 10.
• Never sold. We do not sell, lease, trade, or otherwise profit from biometric data, and we do not disclose it to third parties except to the service providers described in Section 9.
• Retention. See Section 8, which includes our destruction schedule.

5.2 Facial Recognition for Returning Guests

Some venues use facial recognition to tell returning guests from first-time guests. It is off by default. It runs at a venue only when RTEAM has made it available and the venue’s owner or administrator has switched it on.

• Where. At every camera in the venue, except cameras the venue leaves out. The same guest’s templates from different cameras are matched to count how many guests moved from one camera to another. The venue sees those counts only as totals; no single person’s path is shown, exported, or reported.
• When. Only on the night’s recording, in a re-analysis after the event. Never on live video.
• What is made. Each time one of those cameras follows a person through its picture, up to five views of their face become one face template: a list of 512 numbers, made by a facial recognition model. No picture of a face is stored.
• What is attached. A guest is a number. No name, ticket, account, or contact detail is attached to a template or to a guest.
• What it is compared with. Templates from other events at the same venue, or at venues that have themselves joined into a guest group. Never any other venue or any outside database.
• What the venue sees. Totals for each event only: guests read, their share of the door count, first visits against returning guests, how many guests were read at one, two, three, or four or more events, how many guests were read at each camera and how many of them were returning, and how many guests moved from one camera to another. Nothing in the platform shows a face, returns a template, shows one guest’s path, or accepts a photograph to search with.
• Protected. Each template is encrypted with AES-256-GCM before it is stored, under a key only RTEAM’s server holds.
• Never sold. Templates are not sold, leased, or traded, and are disclosed only to the service providers in Section 9 that store them encrypted.
• Retention and deletion. See Section 8.

Customers who deploy our cameras are responsible for providing the notices and obtaining the consents required by the law that applies at their venue, before cameras are switched on, and before facial recognition is switched on. Those obligations are set out in Section 6 of our Terms of Service.

6. How We Use Data

• Producing the crowd analytics our customers subscribe to
• Making and comparing face templates to report returning guests and how guests moved between cameras, at venues that switch on facial recognition
• Re-analyzing recorded footage when a customer asks us to correct or complete an event’s results
• Authenticating users and enforcing team and venue access controls
• Operating, securing, monitoring, and troubleshooting the platform
• Meeting our legal obligations and enforcing our agreements

Model development, where we act as a controller

We use recorded event footage and the data derived from it to develop, train, evaluate, and improve the models that perform detection, tracking, and crowd appearance estimates. This is the one purpose for which we act on our own behalf rather than solely on our customer’s instructions, under a license granted to us in the Terms of Service.

A trained model does not contain, store, or reproduce the footage it was trained on, and it does not identify individuals. We do not sell footage or license it to third parties. A customer may object to the use of their footage for model development by writing to us at the address in Section 15, and we will honor that for footage recorded after the request.

7. Legal Bases for Processing

This section applies where the GDPR or UK GDPR governs the processing. For attendee data, the customer, as controller, determines and is responsible for the legal basis. Where RTEAM is the controller, we rely on the following.

• Performance of a contract for creating and operating platform accounts and delivering the service.
• Legitimate interests for platform security, abuse prevention, service monitoring, and model development. For model development we have weighed our interest in accuracy against the interests of the people in the footage, and we rely on the safeguards described throughout this policy: no names are collected, no face template is linked to a name or a contact detail, no race or emotion is inferred, and no output identifies anyone.
• Explicit consent where required for biometric data, which is special category data under Article 9. In the venue setting that consent is obtained by our customer.
• Legal obligation where we must retain or disclose data to comply with law.

8. Retention and Deletion

This is what we do today, stated as it is rather than as an aspiration.

• Account data: kept while the account is open. Deleting your account removes it immediately, along with your profile image. Residual copies may persist in routine backups for up to 90 days.
• Analytics results: counts, charts, and summaries are kept for the life of the customer relationship, so that events can be compared over time.
• Video recordings: kept for the life of the customer relationship, so that an event can be re-analyzed and so that footage can be used for model development as described in Section 6.
• Face imagery: not kept apart from the video recordings. Face crops used for the crowd age, gender and expression estimates, and for face templates, are discarded with the frame.
• Face templates, at venues that switch on facial recognition: kept until the venue deletes them, until the event or the venue’s organization is deleted, or until a retention period set for the venue passes. A venue can delete all of its returning-guest data, or one event’s.
• Operational and security logs: kept while they are useful for troubleshooting, security, and billing. They record system and account activity, not the identity of anyone at a venue.

We do not currently apply an automatic expiry to footage. Instead, data in any category is deleted when a customer relationship ends, or earlier on a verified deletion request from the customer or from an individual exercising the rights in Section 11. Face templates are the exception for requests from individuals: see Section 11. Deletion is carried out by our operations team within the time applicable law requires. If you want a shorter, enforced retention period for your venue, ask us and we will agree one in writing.

Biometric destruction schedule

Some jurisdictions require an operator holding biometric identifiers to publish a retention schedule and destruction guidelines. Where, and to the extent that, such a law applies to a deployment, including the Illinois Biometric Information Privacy Act (740 ILCS 14) and the Texas Capture or Use of Biometric Identifier Act (Tex. Bus. & Com. Code § 503.001), the following applies to that deployment:

• Biometric identifiers are permanently destroyed when the initial purpose for collecting them has been satisfied, or within three years of the individual’s last interaction with the venue, whichever occurs first.
• Where Texas law applies, biometric identifiers are destroyed within one year after the purpose for collecting them expires.
• The purpose is treated as satisfied when the customer’s agreement with RTEAM ends, when the venue stops using the service, or when the customer instructs us to delete the data, whichever comes first.

RTEAM does not currently operate deployments in Illinois or Texas. This schedule is published so that the commitment is on record before any such deployment begins.

9. Service Providers and Disclosure

We do not sell data and we do not share it for advertising. We disclose data only in the following circumstances.

Service providers. We use a small number of vendors to run the platform. We describe them by role rather than by name so that this page does not double as a map of our infrastructure:

• A managed database and authentication provider, which stores account and analytics records and encrypted face templates
• Cloud object storage providers, which hold recorded footage
• A GPU compute provider, whose hardware runs the video analysis, including facial recognition
• A real-time video transport provider, which carries video from the venue
• A message transport provider, which carries analytics results
• Application and infrastructure hosting providers
• An internet address geolocation provider, used only for the coarse device locality described in Section 3.4
• A calendar provider, only where a platform user has connected their own calendar account

Each is bound by a written agreement requiring confidentiality, appropriate security, and use of the data only to provide services to us. A current list of our named service providers is available to customers and to regulators on written request to the address in Section 15.

Legal and regulatory disclosure. We may disclose data where required by law, court order, subpoena, or lawful government request, or where necessary to establish, exercise, or defend legal claims. We do not provide voluntary access to law enforcement and we do not operate the platform as an identification tool for anyone.

Business transfers. If RTEAM is involved in a merger, acquisition, financing, or sale of assets, data may transfer as part of that transaction. The recipient remains bound by this policy, or you will be given notice and an opportunity to exercise your rights before any materially different policy applies.

10. Security

We use administrative, technical, and physical safeguards designed to protect the data we process. Among them:

• Encryption in transit for video, analytics results, and dashboard traffic
• Recorded footage held in cloud object storage that encrypts data at rest, and all stored records held in access-controlled systems
• Separated credentials, so that each component of the platform holds only the credential it needs, and the components that produce analytics cannot read data back out
• Camera passwords are stripped from any record before it can reach a browser, a behavior covered by automated tests so it cannot silently regress
• Role-based access control by team and venue, so an operator sees only the venues they are entitled to
• Multi-factor authentication available on platform accounts, and session cookies that cannot be read by page scripts
• Time-limited links for footage access rather than open URLs
• Face templates encrypted with AES-256-GCM before they are stored, under a key only RTEAM’s server holds
• Automated linting, type checking, tests, and interface checks that must pass before any change ships

No system is perfectly secure. If a breach affects your personal data, we will notify affected parties and regulators as applicable law requires, including the Florida Information Protection Act (Fla. Stat. § 501.171) and, where the GDPR applies, Articles 33 and 34.

11. Your Rights

Depending on where you live, you may have some or all of the following rights. Florida residents hold them under the Florida Digital Bill of Rights (Fla. Stat. § 501.701 et seq.); California residents under the CCPA as amended; residents of the EEA and the UK under the GDPR; and residents of other states under their own comprehensive privacy laws.

• Access: confirm whether we process data about you and obtain a copy.
• Correction: have inaccurate data corrected.
• Deletion: have your data deleted, subject to legal retention obligations.
• Portability: receive your data in a portable, machine-readable format where technically feasible.
• Opt out of sale, sharing, and targeted advertising: we do none of these, so there is nothing to opt out of, but the right stands.
• Opt out of profiling that produces legal or similarly significant effects.
• Withdraw consent where processing rests on consent, without affecting processing already carried out.
• Non-discrimination for exercising any of these rights.
• Appeal a refusal, and, if still unsatisfied, complain to your state attorney general or supervisory authority.

How to exercise them

Platform users should write to the address in Section 15. We will verify your identity through your account.

Event attendees should contact the event organizer or venue, who is the controller of data captured at their event. If you do not know who that is, write to us with the venue, the date, and the approximate time, and we will identify the customer and pass your request to them, or act on it directly where we are permitted to.

An honest limit on attendee requests

Because we never collect names and never link a record to a person’s identity, we usually cannot find an individual’s record from a name, an email address, or a photograph. Records are pseudonymous by design, which is a privacy protection and also a genuine constraint on access and deletion requests. This includes face templates: we cannot find one person’s template, because that would need a photograph of them, and nothing in the platform takes one.

We will not collect additional identifying information from you for the sole purpose of searching for your record, because doing so would create exactly the identity link this platform is built to avoid. Where we cannot identify you in our records, we will tell you so and explain what we did check. This position is recognized by GDPR Article 11 and by comparable provisions in US state privacy laws. Where deletion of a whole venue’s data is what you are asking for, we can act on that through the customer.

12. Children

A camera at a public event captures whoever is present, and at many events that includes children. We state the consequences plainly rather than implying children are excluded.

• Children in view are detected, counted, and age-banded like anyone else. Our age bands begin at 0-2 and 3-9, so young children are visible in aggregate results as an age band.
• No record of a child is linked to a name, a contact detail, or an identity, because the platform collects none of those for anyone.
• We do not build profiles of children, do not target them, and do not use their data for advertising, because we do not advertise at all.

Customers are responsible for the notices and consents that apply to minors at their events. Several jurisdictions require verifiable parent or guardian consent before biometric data may be collected from a minor, and some restrict it entirely. A customer who cannot meet those requirements should not deploy cameras where children are expected.

Separately, RTEAM.ai dashboard accounts are for business use by adults. We do not knowingly create accounts for anyone under 18. If you believe a minor holds an account, contact us and we will remove it.

13. International Transfers

We process data in the United States and may process it in other jurisdictions where our service providers operate. If you are in the EEA, the UK, or another region that restricts international transfers, we rely on appropriate safeguards for those transfers, including the European Commission’s standard contractual clauses and the UK international data transfer addendum, together with the technical and organizational measures described in Section 10. A copy of the relevant transfer mechanism is available on request.

14. Changes to This Policy

We may update this policy. Material changes will be communicated by email or by a prominent notice on the platform, and the effective date at the top of this page will be updated. Continued use of the platform after the effective date constitutes acceptance of the updated policy. Previous versions are available on request.

15. Contact Us

For privacy questions, rights requests, our named service provider list, or a copy of our data processing agreement:

If you are an event attendee rather than a customer, please read Section 11 first, and see our notice for event attendees for a short plain-language summary.