Data Management Policy

Purpose and scope

This policy states how Kint AI, Inc. (“Kint”, “we”) classifies, protects, keeps and deletes the data that Rollup handles: the Rollup SDK and the services it talks to, the developer dashboard, our website, and our internal systems. It applies to every employee, contractor and provider with access to that data. The Privacy Policy says what we collect and why; this policy says how we look after it.

Developers who integrate Rollup can rely on this policy as the description of our technical and organizational measures under our SDK Terms and data processing addendum.

Roles

For information the SDK handles inside a developer’s app (text derived from photos, location cells, device records, run reports), the developer is the controller or business and we are their processor or service provider. We act only on their documented instructions, which are the SDK’s documented behavior and the developer’s configuration, and we never use that information for our own purposes.

For developer accounts, the dashboard and the website, we are the controller. Where Rollup connects to a third-party platform at a user’s request, such as an AI assistant the user links their Rollup context to, we and that platform each act as independent controllers of what the user chooses to share, as that platform’s terms require.

Design principles

• On the phone first. Photos, videos and the index built from them stay on the phone. Anything that can be computed on the phone is.
• Send the least. Only text leaves the phone, only when a feature needs it, and only the fields that feature needs. Location is sent as cells about one kilometer across, never as coordinates.
• Do not store what we do not need. Questions, templates, derived text, answers and profiles pass through memory and are never written to a database, a log, a queue or a backup.
• Refuse sensitive subjects by design. Health, religion, sexuality, ethnicity, politics, union membership and children are excluded by a filter on the phone, a check on the server and the model’s instructions, and screenshots that hold credentials, financial, health or personal records are withheld on the phone.
• No identity. We never identify people or faces, and the device record carries no name, email, Apple ID or advertising identifier.
• Prove it. The log schema, the infrastructure definitions and this policy are kept consistent, so a reviewer can verify each claim rather than take our word for it.

Data inventory and classification

Every data type we handle is assigned to one of four classes, which set the handling rules in the rest of this policy.

We keep an inventory of every system that stores Confidential or Internal data, with its owner, location, classification and retention period, and update it when a system is added or changed. We keep the records of processing that the GDPR requires for our own processing and for the processing we do for each developer.

Retention and deletion

We keep data only as long as the purpose it was collected for requires, and never indefinitely. The schedule below is enforced by automated deletion where the data lives in our systems and by contract where it lives with a provider.

Deletion paths. A person deletes everything on the phone by deleting the app or revoking photo access; an app deletes the index and the device record with the SDK’s reset. A developer who ends their use of Rollup has their apps’ device records, run reports and account data deleted within 30 days of the request, and we confirm in writing when it is done. Data in a backup is deleted when that backup expires. We keep no copies after that except the records the law requires us to keep.

Data on the phone. The SDK keeps the index in the app’s own container with iOS data protection, excluded from iCloud and computer backups. If an app loses its Rollup access for 30 days, the SDK deletes its index and downloads.

Access control

• Access to production systems and data is granted on the principle of least privilege, to named individuals, for the work they do, and removed on the day a person leaves or changes role.
• Every account on a system that holds Confidential data uses single sign-on or a unique login with multi-factor authentication. Shared accounts are not used.
• Service credentials and signing keys live in a secrets manager or the provider’s environment configuration, are never committed to source code, and are rotated when a person with access leaves or a compromise is suspected.
• We review who has access to each system at least quarterly and record the review.
• Developers reach only their own apps’ data in the dashboard, enforced by row-level permissions in the database. Administrative actions are logged with who took them and why.
• Company devices are managed, with disk encryption, screen lock and automatic updates required.

Encryption and key management

• All traffic between the SDK, the dashboard, the website and our servers, and between our servers and our providers, uses TLS 1.2 or later.
• Data at rest in our database, file storage and backups is encrypted with AES-256 by our providers, who manage the keys in their key management systems.
• Device credentials are encrypted at the application layer with a key held only in our server environment, so a copy of the database alone cannot impersonate an installation.
• Every SDK request is tied to an Apple App Attest key that never leaves the phone’s Secure Enclave, so only genuine installations of approved apps can reach the service.
• Assets the SDK downloads are signed with keys pinned in the SDK, and the SDK refuses anything that does not verify.

Logging and monitoring

Our logs are designed so that Restricted data cannot appear in them. Request logs record the app, the endpoint, the status, timings and counts, and never the question, the template, the derived text, the answer, the profile, the venue names or the location cells. The log schema is reviewed whenever an endpoint changes. Error reporting strips request bodies. We monitor for failed authentication, rate-limit events, unusual usage per app and provider errors, and alert on-call engineers.

Backups and continuity

Our database is backed up automatically by our provider at least daily, with point-in-time recovery, and backups are encrypted and kept for up to 30 days. Because nothing derived from photos is stored, no backup contains it. We test restoring from backup at least twice a year. Our services run on providers with redundant infrastructure; if a provider has an outage, the SDK keeps working on the phone, since search needs no server, and resumes questions and profiles when service returns. Our targets are to restore service within 4 hours and to lose at most 1 hour of stored data in a disaster.

Providers and sub-processors

Before engaging a provider that will handle Confidential or Restricted data, we review its security and privacy practices, including its independent audit reports or certifications, its data processing terms and its sub-processors, and we sign a data processing agreement with it. We engage the model provider only with storage of requests disabled and only under terms that forbid training on our data. We keep an inventory of providers with what each receives and repeat the review at least annually.

Secure development

• All code changes go through pull requests on protected branches, with review and automated tests before they are merged, and deployments come only from the main branch.
• Dependencies are kept current and scanned for known vulnerabilities; critical vulnerabilities are patched within 72 hours, high within 14 days, and the rest within 90 days.
• Every SDK release is signed, versioned and accompanied by a privacy manifest that declares exactly the data types this policy describes, so apps that include it can report it correctly to Apple.
• We arrange an independent penetration test of our services at least annually and fix the findings on the schedule above.
• Security researchers can report vulnerabilities to security@tryrollup.com; we acknowledge reports within 3 business days and do not pursue good-faith research.

Incident response

A security incident is any event that compromises the confidentiality, integrity or availability of data we hold or process, including accidental loss. We keep a written incident response plan with named roles and deputies, severity levels and contact lists, and we exercise it at least once a year.

• Containment and assessment start immediately on discovery, and we keep a record of what happened, what data and whose it affected, and what we did.
• Developers whose users’ information is affected are notified within 48 hours of our confirming the incident, with what we know, what we are doing and a named contact, and we update them as we learn more, so they can meet their own obligations within 72 hours.
• Authorities and individuals are notified where we are the controller as the law requires, including the 72-hour deadline under the GDPR and UK GDPR and state deadlines in the United States, such as 30 days in California.
• Platforms we connect to are notified within the time their terms set, which is 48 hours for Meta Muse.
• Afterwards we write a post-incident review with root cause and corrective actions and track those to completion.

International transfers

Our systems are in the United States. For personal information from the European Economic Area, the United Kingdom and Switzerland, we rely on the European Commission’s standard contractual clauses and the UK International Data Transfer Addendum with our developers and our providers, and we maintain a transfer impact assessment. The strongest safeguard is the design: no images, no names, nothing stored from questions and profiles, and a device record that cannot be tied to a person without the developer’s help.

Requests from individuals and developers

We log every privacy request we receive, verify the requester, and answer within the time the law allows, which is 45 days under US state laws and one month under the GDPR and UK GDPR. Where a developer is the controller, we pass requests about their users to them within 5 business days and help them answer. We do not charge for requests and we do not treat people differently for making one.

Assessments

• We keep a data protection impact assessment for the SDK’s processing and update it when the SDK’s data flows change, and we give developers what they need for their own assessments on request.
• We test the exclusion of sensitive subjects with adversarial prompts before each release of the question and profile services and keep the results.
• We assess every change to what the SDK sends against this policy, the Privacy Policy, the SDK’s privacy manifest and our developer documentation, and we update all four together.
• We have assessed Rollup against the EU AI Act and record our conclusion that it is not a high-risk system; our terms forbid developers from using it in high-risk settings.

Governance

Our founders own this policy and are responsible for its enforcement. Everyone with access to our systems reads it when they join and whenever it changes. We review it at least annually and whenever the service, our providers or the law change, and we publish each version here with its number and effective date. Questions about this policy: security@tryrollup.com.