Privacy Policy

1. Who is responsible

The company that operates GridPort is responsible for the personal data described here ("we"). [The operating entity — to be stated before these terms take effect]

For personal data inside the prompts and responses you send through the API, you decide what is sent and we process it on your behalf; the Data Processing Addendum covers that.

2. What we collect

Account data: your email address, your name if you give one, the organisation and projects you create, your role, and the language and timezone you choose. Sign-in data: password hash, second-factor enrolment, session records with a masked IP address and the browser you used.

Request data: for every call we record the time, the model, the key, token counts, latency, cost, the serving route, a masked client IP and the user agent. The prompt and the response are not part of this record unless a project turns content logging on.

Billing data: top-ups, credits, ledger entries and statements. Card and wallet details go to our payment processor; we never see or store a card number.

3. Prompts and responses

By default we do not store prompts or responses. An organisation admin can switch content logging on per project, choose a retention window between one and thirty days, and have sensitive values masked before storage. Reading stored content is a separate permission, and every read and export is recorded in the organisation's audit log.

Turning content logging off stops new capture; existing records age out at the end of their window. Zero-data-retention organisations cannot turn it on at all.

4. Why we process it

To provide the service you asked for, to meter and bill it correctly, to keep the platform secure and to detect abuse, to send you operational messages such as a low balance or a model retirement, and to meet our own legal obligations.

We do not use your content to train models. We do not sell personal data, and we do not share it for advertising.

5. Who else sees it

Inference providers: when a request is routed to a third-party engine, that provider receives the request in order to answer it. Zero-data-retention organisations are routed only to providers that have committed not to retain request content, and routing preferences let you narrow the routes that may serve you.

Infrastructure and payment vendors: hosting, email delivery, abuse prevention and payment processing, each bound by a contract that limits them to acting on our instructions.

We do not publish the list of these subprocessors. Customers can obtain it, with each one's role and location, as described in the Data Processing Addendum.

Authorities: only where we are legally required, and we will tell you unless we are prohibited from doing so.

6. Where it is processed

[Where account and request data are stored — to be stated before these terms take effect]

Requests may be answered by providers in other countries. If you send us personal information collected in a place that restricts transfers abroad, you are responsible for meeting those requirements, such as consent or a standard contract, before you send it.

7. How long we keep it

Request metadata is retained for the reporting and reconciliation window and then rolled up into aggregates. Content, when logged, follows the project window you set. Ledger and invoice records are kept for the period tax law requires. Session and security records are kept for a short investigation window.

When you close an account we delete or anonymise personal data, except records we must keep for accounting and fraud prevention.

8. Your choices

From the console you can view and correct your profile, export your data, your organisation's request log and transactions, choose which notifications you receive, revoke sessions, and close the account and have your data deleted.

If a data protection law applies to you, you can also ask us for a copy of your data, to correct or delete it, or object to a particular use. Write to [Privacy contact — to be stated before these terms take effect] and we will answer within the statutory period.

9. How we protect it

Credentials are hashed and upstream keys are encrypted at rest. API keys are shown once; the console keeps a prefix and, only where an organisation opts in, an encrypted copy that a privileged member can read back after re-authenticating, and every such read is audited.

Access to production is limited and logged, administrative sign-in requires a second factor, and we test restoring backups at least every quarter.

10. Children

The service is for businesses and developers. It is not directed to anyone under 18, and we do not knowingly collect their personal data.

11. Contact

Questions about this policy, or a request about your data: [Privacy contact — to be stated before these terms take effect]. We tell account holders before a materially changed version of this policy takes effect.