Security & compliance — Aski

Version 1.1 · Last updated: August 20, 2026

This page gathers in one place what an IT team or a data protection auditor needs to know before connecting Aski to an ERP: where it runs, what data it touches, how one customer's data is kept apart from another's, and what we do not do. It is the technical companion to the Privacy Policy, which is the binding document.

1. In one line

Aski queries the ERP live, in read-only mode and with the permissions of the user who connects. It does not replicate the customer's database, does not write to it, and does not share it with other customers.

2. Data processing roles

When Aski arrives through an implementation partner, the chain looks like this:

• Controller: the company that owns the ERP and the data in it.
• Processor: the partner or consultancy managing the relationship with that company.
• Sub-processor: Aski, which processes that data solely to answer the queries the user makes.

If your organisation needs a signed data processing agreement or a non-disclosure agreement, write to contacto@aski.dev. If you have your own template, we will review and sign it.

3. How the data travels

1. The app or browser sends the question to our backend over HTTPS.
2. The backend opens a connection to the ERP using the credentials of the user who connected and runs a read query.
3. The ERP returns only the rows for that question.
4. To write the answer in natural language, the AI model receives the question, the ERP schema and a bounded extract of those rows (see section 8).
5. The answer goes back to the user and stays in their conversation history.

The ERP does not move: we do not copy it, replicate it or sync it. If the instance is on-premise, it stays on-premise.

3.1 If the ERP is not reachable from the internet

Many on-premise installations are not published, and they do not need to be. For those cases there is a tunnel: a private-network node (Tailscale) is installed on a machine in the same network where the ERP lives, and the backend goes in through it.

• No inbound port is opened on the customer's firewall. The node establishes the connection outward, the same way a browser does. No public IP, no port forwarding, no publishing the ERP.
• The ERP server is not touched. The node can sit on any machine in that network.
• Each customer joins with their own key, tagged and revocable independently.
• Isolation comes from the private network's rules: only backend → customer node is allowed, and only towards the ERP's ports. Two customers' nodes cannot see each other, and neither one can reach our backend.
• The ERP credentials are entered by the customer in the application, exactly as in a normal connection. They are not shared with us through any channel.
• The link runs as a service separate from the main backend: if that service fails, only tunnelled connections stop responding.

A connection is marked as "via tunnel" one by one, not globally: a connection marked that way always goes through the tunnel and never over the internet, and a normal connection never uses it.

4. Where it is hosted

• Backend and database: Railway (United States).
• Language model: Anthropic — Claude (United States).
• Website and web app: Vercel (United States).
• Backups: daily database backup, retained for 30 days.

The full list of third parties we share any data with, what each one receives and their country is in section 4 of the Privacy Policy. There is an international transfer of data to the United States, and it is declared as such.

5. Isolation between customers

Three layers, in order of importance:

1. We keep no copy of anyone's ERP. There is no shared repository where two customers' data could cross: every query runs live against that customer's instance and returns only the rows for that question. What is stored is the conversation history — the question and the answer as shown, which may include figures or names that were queried — tied to the account of whoever asked.
2. Each connection belongs to a single user. Credentials, conversations and messages are tied to their owner's identifier, and every query is filtered by the authenticated user. No route of our API returns a credential in clear text: it is not shown in the app, not exposed through the API, and does not appear in the admin panel or in the logs.
3. Aski sees no more than the connected user sees. It queries the ERP with that user's credentials, without privilege elevation. If that user cannot see costs, margins or another company's data, neither can Aski.

One precision, because it is the right question to ask: to answer faster, we keep in temporary memory a catalogue of the names and labels of standard Odoo fields shared by instances of the same version and language. That catalogue holds only standard product nomenclature — never custom models, never values, never records — and before use it is intersected again with the instance's real schema, so it can never announce a field that instance does not have.

6. Encryption

• In transit: HTTPS with TLS 1.2 or higher on every leg, app ↔ backend and backend ↔ ERP.
• At rest: the ERP password or API Key is encrypted with AES-256-GCM before being stored. Aski account passwords are stored as bcrypt hashes.
• On the device: encrypted storage with a key managed by the Android Keystore.
• Operational access to the database is restricted to a minimal number of administrators and is audited.

What this does not mean: the key that encrypts the credentials lives on our server, because the backend needs to decrypt them to open the connection to the ERP. As the platform operator, technical access exists. We would rather say so than let you assume otherwise.

7. Read-only and permissions

The only operations the system can issue against the ERP are queries. There is no write function towards the ERP anywhere in the code: it is not a commercial promise, it is a structural limitation. If someone asks for a destructive operation, it is cut before touching the ERP and it is logged.

On permissions the rule is simple: Aski sees what that user sees, no more and no less. The access rules and record rules configured in the ERP remain in charge; Aski opens no new door. And cutting access does not depend on us: just disable that key or the service user in the ERP itself.

On top of that, requests attempting SQL injection or model manipulation (prompt injection), those asking for known sensitive fields and those aimed at restricted models are detected before reaching the AI model, and are logged.

8. What the AI model receives

To write the answer, Anthropic receives the question, the ERP schema (model and field names) and a bounded extract of the records that query returned: up to 20 rows per answer in normal mode and up to 80 rows per query in Deep analysis. That extract may contain business information, such as customer names or amounts.

The full database and the credentials are never sent. Anthropic retains that content for up to 30 days solely for abuse detection, per its terms, and does not use it for training. Neither do we use it to train anything.

9. Retention and deletion

While the account is active we keep the profile, the encrypted credentials, the message history and the billing history. Deletion from the app is immediate and permanent, requires confirmation and re-authentication, and removes the chat history, the credentials, the learned vocabulary, the sessions, the tokens and the associated security log.

Two honest caveats: billing history is kept for five years under Peruvian tax law, with the email anonymised; and a deleted account may remain in backups for up to 30 days, until those copies expire. The full detail is in section 6 of the Privacy Policy.

10. What we do not have

We would rather you hear this from us than find it in an audit:

• We hold no SOC 2 or ISO 27001 certification.
• The pentest we publish is our own, run and recorded by us; it is not an independent third-party audit.
• We do not offer hosting in the European Union or regional data residency: all infrastructure is in the United States.

11. Contact

Data controller:

Jhon Jairo Rojas Ortiz
Email: contacto@aski.dev
Country: Peru

We answer security questions and agreement requests within 7 business days. If your auditor has a questionnaire, send it as is and we will answer it in writing.