Privacy Policy

1. Scope

This Privacy Policy explains what personal data Inteleto (“we,” “our,” or “us”) handles when you visit inteleto.com, create an account, or use the Inteleto platform (together, the “Service”), why we handle it, who we share it with, and the rights you have over it. It applies alongside our Terms of Service.

We designed this Service so that we hold as little personal data as possible. The short version: we store personal data only for authentication, fraud prevention, billing, and tax. We do not sell or share your data. We do not use your data — or anything you upload — to train or improve models or our services.

2. Two different roles

The Service handles two categories of data, and our responsibilities differ for each. This distinction runs through the whole policy.

2.1 Account Data — we are the controller

Data about the people who sign up for and administer an Inteleto account: your name, email address, authentication credentials, billing records, and security logs. We decide why and how this data is processed, so we act as the controller.

2.2 Customer Content — we are the processor

Everything a customer puts into the platform: documents uploaded to knowledge bases, case files, instructions, questions asked of an agent, and the answers and run records produced from them. Those materials may contain personal data about third parties — employees, clients, applicants, counterparties. The customer decides what to upload and why; we only process it to deliver the Service, under the customer’s instructions. For this data we are the processor and the customer is the controller.

If you are an end user of an agent that someone else built on Inteleto — you were invited to a deployment, used a hosted link, or chatted with an embedded assistant — the organization that built that agent is the controller of your data. Direct access and deletion requests to them; we will support them in responding, but we cannot answer for their data on our own initiative.

3. Account Data we collect

We collect only what the Service cannot run without. Concretely:

• Account and identity — name, email address, a salted hash of your password (never the password itself), your organization and role within it, session records, and password-reset and email-verification tokens. Purpose: authentication and access control.
• Security and fraud-prevention logs — IP address, user agent, timestamps, and the outcome of authentication and authorization events. Purpose: detecting credential stuffing, abuse, and unauthorized access, and meeting the record-keeping obligations that apply to us.
• Billing and tax records — subscription status, plan, invoices, billing contact details, and the tax identifiers required to issue an invoice. Payment is processed by Stripe; we never receive or store full card numbers, only the identifiers, brand, and last four digits Stripe returns to us.
• Support communications — the content of messages you send us and our replies, kept so we can answer you and keep a record of what was agreed.
• Operational telemetry — error traces and processing-stage metrics (queue depth, job status, failure counts) used to keep the pipeline healthy. These are about documents and jobs, not about people.

We do not run advertising or cross-site tracking, we do not build behavioural profiles, we do not buy personal data from data brokers, and we do not enrich your account with third-party datasets. We do measure how our public website is used, which is a separate matter covered in section 12.

4. How we use Account Data

We use it for four purposes only. Where data protection law requires us to identify a legal basis, these are the bases we rely on:

• Authentication and delivery of the Service you signed up for — performance of our contract with you.
• Fraud prevention and platform security — our legitimate interest in keeping the Service and its users safe.
• Billing— performance of our contract with you.
• Tax and accounting compliance and responding to lawful requests from authorities — our legal obligations.

Service emails (password resets, security notices, billing and incident notifications) are part of providing the Service and are not marketing. If we ever send marketing email, it will be with your consent and with a one-click unsubscribe.

5. Customer Content: what we do and do not do with it

Customer Content is handled under our customers’ instructions, and those instructions are expressed through product settings rather than through support tickets. Our commitments:

• No training, no model improvement. We do not use Customer Content to train, fine-tune, or evaluate any model, and we do not use it to improve our own services. Our model and embedding providers are contractually bound to the same restriction for data we send them.
• No sale, no sharing. We do not sell Customer Content or personal data, do not share it for advertising, and do not disclose it to anyone other than the sub-processors listed in Section 7 and, where legally compelled, the relevant authority.
• Tenant isolation. Every tenant’s content is segregated. One tenant cannot read another tenant’s documents, cases, runs, or vectors. The only way content leaves that boundary is if the customer explicitly publishes a deployment through a public channel — a deliberate, per-audience act described in Section 6.
• We retain nothing for our own benefit. Retention of Customer Content is the customer’s configuration, not ours (Section 8).
• Staff access is exceptional. Our personnel do not browse Customer Content. Access happens only where strictly necessary to resolve an incident or a support request the customer raised, is limited to a short allow-list of named operators, and is logged.

Document text is extracted by our own in-house engine running on our infrastructure; documents are not sent to third-party OCR services. Text is then converted into search vectors and, when a question is asked, the relevant passages are sent to a model provider to produce an answer. That is the only point at which content leaves our infrastructure, and it goes only to the providers in Section 7 under zero-retention, no-training terms.

6. Public and shared deployments

Inteleto lets a customer deploy an agent to an audience through one or more channels: invited users, an API key, a hosted link, or an embed on the customer’s own site. A hosted or embedded deployment can be reached by people who do not have an Inteleto account, including anonymously.

Nothing becomes public by default. Publishing is an explicit act by the customer, scoped to a named audience and pinned to a specific version. The customer chooses which knowledge is in scope for that audience, and it is the customer’s responsibility to ensure that what they expose is appropriate for the people who will reach it, and to give those people their own privacy notice.

When an end user interacts with such a deployment, we process their questions, the resulting answer, and a minimal technical log on the customer’s behalf, under the customer’s retention setting.

7. Sub-processors and infrastructure providers

We use a small, deliberately short list of providers. Every provider that handles Customer Content or Account Data is bound by a written agreement, processes data only on our instructions, and is prohibited from using it for its own purposes, including training. The one website-analytics vendor works differently and is described under the table.

Microsoft is the one entry above that touches our website rather than the Service. It is governed by Microsoft’s own terms for Clarity rather than by an agreement specific to us, which is why we constrain it at the source: it runs only where consent permits, it is never given Customer Content, and its advertising features are disabled. See section 12 for what it collects.

Model and embedding providers receive only what a specific request requires — the question and the passages retrieved for it — and receive it under zero-retention, no-training terms. They do not receive your account credentials, your billing data, or your corpus as a whole.

Our databases, search index, and queues run on infrastructure we operate; they are not managed third-party services and are not exposed to the public internet. We will update this list before adding a new sub-processor that handles personal data, and customers on a written agreement may ask to be notified of changes.

We also use Telegram to deliver internal operational alerts to our own team. These alerts carry system events, not Customer Content.

8. Retention

8.1 Customer Content — the customer decides

Retention is a per-configuration decision made by the customer, and we honour it literally:

• No retention. If the customer configures no retention, we retain nothing beyond the life of the session needed to actually answer the request. Content is discarded once the interaction ends.
• Fixed period. Content and run records expire automatically after the configured number of months.
• Retained for audit and compliance. Where the customer enables it, questions, answers, evidence, and the full run record are kept as an audit trail — because in regulated work the ability to show why an answer was given is the point. Retained data stays private to that tenant. It is not published, not shared, and not used by us for anything.

On termination of an account, Customer Content is deleted within 30 days, except where the customer has asked us in writing to delete it sooner, or where retention is required by law. Backups age out on their own cycle, within 90 days.

8.2 Account Data — the minimum the law allows

• Account and profile data: for as long as the account is active, then deleted.
• Access logs: 6 months. Security and fraud-prevention logs may be kept for up to 12 months where an investigation requires it.
• Billing, invoicing, and tax records: for the periods tax and commercial law require, generally up to 5 years.
• Support correspondence: up to 24 months.

9. International transfers

The Service is operated from, and our providers process data in, the United States, the European Union, and Brazil. Where personal data crosses a border, we rely on the transfer mechanisms the applicable law provides — including the European Commission’s Standard Contractual Clauses where European data protection law applies, and equivalent contractual protections elsewhere. Data is encrypted in transit throughout.

10. Security

We hold no security certifications today, and we will not claim any until they are audited and issued. What follows is what we actually do.

• Encryption in transit. All traffic to and from the Service uses TLS 1.2 or above, with HTTPS enforced. Traffic between our own services travels over private networks that are not reachable from the internet.
• Encryption at rest. Databases, object storage, the search index, and backups are encrypted at rest with strong industry-standard ciphers (AES-256).
• Credentials. Passwords are stored only as salted hashes using a modern memory-hard algorithm. We cannot read your password, and neither can an attacker who obtains the database.
• Tenant isolation, enforced mechanically. Every query that touches tenant data must carry a tenant filter. This is not a convention we hope developers follow: an automated check runs against the codebase and fails the build if a guarded data-access path can execute without a tenant scope in place. Database indexes are aligned to the same boundary.
• Permission-aware retrieval. An agent can only retrieve from the scopes its deployment allows. The identity a run executes as is resolved server-side from the deployment, never from anything the requester sends.
• Closed data-store surface. Our vector database, document database, and queues are bound to private interfaces and are not published to the public internet. Uploads use short-lived pre-signed URLs rather than shared credentials.
• Least privilege. Administrative diagnostics are restricted to an allow-list of named operators that lives in our deployment configuration and cannot be granted from inside the product — no customer role, and no compromised customer account, can reach it.
• Auditability by construction. Every answer the platform produces is recorded as a run with its inputs, the evidence used, the model version, and the checks that ran. Published versions are immutable, so what a deployment served on a given day can be reconstructed exactly.
• Secrets and change management. Credentials are held in the deployment environment, never in source control; access to production is limited to the engineers who need it and uses key-based authentication.
• Backups. Encrypted, and restorable.

No system is perfectly secure. If we become aware of a breach affecting personal data, we will notify the affected customers, and any regulator with jurisdiction, within the timeframes the law requires. To report a vulnerability, write to (email address shown with JavaScript enabled). We will not pursue legal action against good-faith research that respects our customers’ data.

11. Your rights

Depending on where you live, data protection law — such as the GDPR in Europe, the CCPA in California, or your local equivalent — gives you rights over your personal data. We extend the following to everyone, wherever you are. You may ask us to:

• confirm whether we process data about you, and access it;
• correct incomplete, inaccurate, or outdated data;
• anonymize, block, or delete data that is unnecessary, excessive, or processed unlawfully;
• receive your data in a portable, machine-readable format, or have it transferred to another provider;
• delete data processed on the basis of consent, and withdraw that consent;
• know with whom we have shared your data — Section 7 is the standing answer;
• object to processing based on legitimate interests, and be told the consequences of refusing consent where consent is the basis.

Write to (email address shown with JavaScript enabled) and we will respond within 30 days, or sooner where the law requires it. We may ask you to verify your identity before acting on a request, and we do not charge for it or treat you differently for making one. You also have the right to complain to your local data protection authority.

If your data reached us as Customer Content — because an organization uploaded a document about you or you used an agent they built — send your request to that organization. They control that data; we will assist them, and we will forward your request to them if you contact us instead.

12. Cookies and website analytics

12.1 Essential cookies

We use cookies that are necessary for the Service to work: a session cookie that keeps you signed in, and cookies that protect against cross-site request forgery. They are set only after you sign in, and they expire when the session does. Blocking essential cookies will prevent you from signing in.

12.2 Analytics

We use Microsoft Clarity to understand how our website is used — which pages are visited, where people click and scroll, and where a page confuses them. Clarity records these interactions as a replayable session. We use it to improve the site, and for nothing else.

Analytics cookies are set only if you agree. We ask on your first visit. If you decline — or simply never answer — Clarity still measures the page you are on, but without cookies: each page view is counted on its own and cannot be linked to your other visits. If you agree, a cookie lets those page views be joined into a single visit. You can change your answer at any time through Cookie preferences in the footer of any page; withdrawing consent deletes the analytics cookie. We also honour the Global Privacy Control signal, and treat it as a decline without asking.

What Clarity never sees: the inside of your workspace. Everything rendered within the signed-in product is masked before it leaves your browser, so document text, generated answers, citations, and the contents of your knowledge bases are never transmitted to or stored by Microsoft. Masking is applied by the page itself and cannot be switched off from an analytics dashboard.

We do not enable Clarity’s advertising features. Nothing collected is shared with Microsoft Advertising, used to build a profile of you, or used to target ads on other sites.

13. Automated decisions

Inteleto generates answers with language models, and those answers can be wrong. The platform is built so that every answer carries its evidence and is reviewable, and customers are expected to keep a human in the loop for consequential decisions. We do not ourselves make automated decisions that produce legal effects for you. Where a customer uses the platform in a way that affects individuals, that customer is responsible for the review process and for handling requests to have those decisions reviewed.

14. Children

The Service is a business tool and is not directed to children or adolescents. We do not knowingly collect personal data from anyone under 18. If we learn that we have, we will delete it promptly.

15. Changes to this policy

We may update this policy as the Service evolves. When the change is material — a new purpose, a new sub-processor handling personal data, a change in retention — we will update the date at the top of this page and notify account administrators by email before it takes effect. Continued use after the effective date means the updated policy applies.

16. Contact and company details

For privacy questions or to exercise your rights, write to our data protection lead at (email address shown with JavaScript enabled).

Inteleto is a product of …, the company responsible for the data described in this policy: