Seguridad y cumplimiento — Aski

Versión 1.3 · Última actualización: 25 de agosto de 2026

Esta página reúne en un solo lugar lo que un equipo de TI o un auditor de protección de datos necesita saber antes de conectar Aski a un ERP: dónde corre, qué datos toca, cómo se separan los de un cliente de los de otro, y qué no hacemos. Es el complemento técnico de la Política de privacidad, que es el documento vinculante.

Descargar la ficha de seguridad en PDF (3 páginas) — el mismo contenido en un documento que puedes adjuntar al expediente de tu auditor.

1. En una línea

Aski consulta el ERP en vivo, en modo solo lectura por defecto y con los permisos del usuario que se conecta. No replica la base de datos del cliente ni la comparte con otros clientes. Escribir en el ERP solo existe en los planes Enterprise Plus y Dedicated, con confirmación explícita del usuario y traza de cada acción (sección 7).

2. Roles en el tratamiento de datos

Cuando Aski llega a través de un socio implementador, la cadena queda así:

• Responsable del tratamiento: la empresa dueña del ERP y de los datos que hay en él.
• Encargado: el socio o la consultora que gestiona la relación con esa empresa.
• Subencargado: Aski, que trata esos datos únicamente para responder las consultas que el propio usuario formula.

Si tu organización necesita un acuerdo de tratamiento de datos o un acuerdo de confidencialidad firmado, escríbenos a contacto@aski.dev. Si tienen un formato propio, lo revisamos y lo firmamos.

3. Cómo viajan los datos

1. La app o el navegador envía la pregunta a nuestro backend sobre HTTPS.
2. El backend abre una conexión al ERP con las credenciales del usuario que se conectó y ejecuta una consulta de lectura.
3. El ERP devuelve solo las filas de esa pregunta.
4. Para redactar la respuesta en lenguaje natural, se envía al modelo de IA la pregunta, el esquema del ERP y un extracto acotado de esas filas (ver sección 8).
5. La respuesta vuelve al usuario y queda en su historial de conversación.

El ERP no se mueve de donde está: no lo copiamos, no lo replicamos ni lo sincronizamos. Si la instancia es on-premise, sigue siendo on-premise.

3.1 Si el ERP no es alcanzable desde internet

Muchas instalaciones on-premise no están publicadas, y no tienen por qué estarlo. Para esos casos existe un túnel: se instala un nodo de red privada (Tailscale) en una máquina de la misma red donde vive el ERP, y el backend entra por ahí.

• No se abre ningún puerto de entrada en el firewall del cliente. El nodo establece la conexión hacia afuera, igual que lo hace un navegador. No hace falta IP pública, ni redirección de puertos, ni publicar el ERP.
• El servidor del ERP no se toca. El nodo no va necesariamente en él. La máquina puede ser cualquiera de esa red que esté siempre encendida, con una condición medida: si el ERP se consulta por HTTPS, esa máquina debe ser Linux o ser el propio servidor del ERP.
• Cada cliente entra con su propia llave, etiquetada y revocable de forma independiente.
• El aislamiento lo dan las reglas de la red privada: solo se permite backend → nodo del cliente, y únicamente hacia los puertos del ERP. Los nodos de dos clientes no se ven entre sí, y ninguno alcanza nuestro backend.
• Las credenciales del ERP las introduce el propio cliente en la aplicación, igual que en una conexión normal. No se comparten con nosotros por ningún canal.
• El enlace corre como un servicio separado del backend principal: si ese servicio falla, solo dejan de responder las conexiones por túnel.

La conexión se marca como «por túnel» una a una, no de forma global: una conexión marcada así sale siempre por el túnel y nunca por internet, y una conexión normal nunca lo usa.

4. Dónde está alojado

• Backend y base de datos: Railway (Estados Unidos).
• Modelo de lenguaje: Anthropic — Claude (Estados Unidos).
• Sitio web y aplicación web: Vercel (Estados Unidos).
• Enlace a ERP internos: Tailscale (Estados Unidos). Solo para las conexiones marcadas «por túnel». Recibe los datos del enlace —nombre de la organización, nombre del equipo y rangos de red internos—, nunca el contenido de las consultas: el tráfico va cifrado de extremo a extremo.
• Copias de seguridad: respaldo diario de la base de datos, con retención de 30 días.

La lista completa de terceros con los que se comparte algún dato, qué recibe cada uno y su país está en la sección 4 de la Política de privacidad. Hay transferencia internacional de datos hacia Estados Unidos, y así está declarado.

5. Aislamiento entre clientes

Son tres capas, en orden de importancia:

1. No mantenemos copia del ERP de nadie. No existe un repositorio común donde los datos de dos clientes puedan cruzarse: cada consulta se ejecuta en vivo contra la instancia de ese cliente y devuelve solo las filas de esa pregunta. Lo que sí queda guardado es el historial de la conversación —la pregunta y la respuesta tal como se mostró, que puede incluir cifras o nombres consultados—, ligado a la cuenta de quien preguntó.
2. Cada conexión pertenece a un solo usuario. Credenciales, conversaciones y mensajes están ligados al identificador de su dueño, y toda consulta se filtra por el usuario autenticado. Ninguna ruta de nuestra API devuelve una credencial en claro: no se muestra en la app, no se expone por la API y no aparece en el panel de administración ni en los registros.
3. Aski no ve más de lo que ve el usuario conectado. Consulta el ERP con las credenciales de ese usuario, sin elevación de privilegios. Si ese usuario no puede ver costos, márgenes o los datos de otra compañía, Aski tampoco.

Una precisión, porque es la pregunta correcta: para responder más rápido, guardamos en memoria temporal un catálogo con los nombres y etiquetas de campos estándar de Odoo comunes a instancias de la misma versión e idioma. Ese catálogo contiene nomenclatura: nombres y etiquetas de campos, y los valores de los campos de clasificación de baja cardinalidad —etapas, categorías, etiquetas—, que es lo que permite entender que «pendiente de revisión» es una etapa y no una fecha. Nunca modelos a medida, nunca registros, nunca cifras. Y antes de usarse se vuelve a cruzar con el esquema real de la instancia, de modo que jamás puede enseñarle a una instancia algo que esa instancia no tenga.

6. Cifrado

• En tránsito: HTTPS con TLS 1.2 o superior en todos los tramos, app ↔ backend y backend ↔ ERP. Excepción declarada — conexiones por túnel: ahí el tramo backend ↔ ERP viaja dentro del túnel cifrado (WireGuard, extremo a extremo) hacia una dirección privada fijada, y el certificado propio del ERP no se valida: uno interno casi nunca tiene certificado de una autoridad pública, y el túnel ya aporta el cifrado y la autenticación de extremo que daría TLS. Si ese ERP habla HTTP plano dentro de su red, ese tramo va sin TLS propio, pero nunca sin cifrar.
• En reposo: la clave o API Key del ERP se cifra con AES-256-GCM antes de guardarse. Las contraseñas de la cuenta Aski se almacenan como hash bcrypt.
• En el dispositivo: almacenamiento cifrado con clave gestionada por Android Keystore.
• El acceso operativo a la base de datos está restringido a un número mínimo de administradores y se audita.

Lo que esto no significa: la clave con la que se cifran las credenciales vive en nuestro servidor, porque el backend necesita descifrarlas para abrir la conexión al ERP. Como operador de la plataforma, el acceso técnico existe. Preferimos decirlo a dejar entender otra cosa.

7. Solo lectura, acciones y permisos

Por defecto, las únicas operaciones que el sistema emite contra el ERP son de consulta. Así funciona en los planes Basic, Pro y Enterprise, y sobre SAP S/4HANA en cualquier plan.

La excepción son las acciones con confirmación, que requieren activación explícita y están disponibles en Enterprise Plus, en los planes SAP y en los Dedicated, y solo sobre Odoo y SAP Business One. No son escritura libre: el sistema solo sabe ejecutar un catálogo cerrado de diez operaciones, siempre sobre un registro concreto:

• Cobranza: enviar un recordatorio de cobro, o enviarlo de una vez a los clientes de una lista.
• Seguimiento: crear una actividad, marcarla como hecha o reprogramarla.
• Aprobación: aprobar un documento o rechazarlo.
• Cartera: cambiar el responsable de un registro, y marcar una oportunidad como ganada o perdida.

Sobre SAP Business One el catálogo se reduce a dos: el recordatorio de cobro y la actividad de seguimiento. El modelo de IA no compone la operación: propone cuál de ellas aplica, y el servidor es quien decide si esa cuenta tiene derecho y si el registro es válido.

Antes de ejecutar, Aski muestra qué va a hacer, sobre qué registro y —si hay envío— a qué destinatario exacto; sin la confirmación explícita del usuario no se ejecuta nada. Cada ejecución queda registrada con quién la pidió, qué se hizo, sobre qué registro y con qué datos exactos, para poder auditarla después. Si alguien pide una operación destructiva o fuera de ese catálogo, se corta antes de tocar el ERP y queda registrado.

Hay una escritura más, fuera de ese catálogo y disponible en cualquier plan con avisos: si al programar un aviso eliges recibirlo en la bandeja de tu propio Odoo, cada entrega crea ahí un mensaje de notificación dirigido a ti. La activas tú al elegir ese canal, no toca ningún registro de negocio y cambias el canal cuando quieras.

Sobre los permisos, la regla es simple: Aski ve lo que ese usuario ve, ni más ni menos. Las reglas de acceso y de registro configuradas en el ERP siguen siendo las que mandan; Aski no abre ninguna puerta nueva. Y el corte de acceso no depende de nosotros: basta con desactivar esa clave o deshabilitar el usuario de servicio en el propio ERP.

Además, las peticiones que intentan inyección SQL o manipulación del modelo (prompt injection), las que piden campos sensibles conocidos y las que apuntan a modelos restringidos se detectan antes de llegar al modelo de IA y quedan registradas.

Con asientos de equipo la regla no cambia: cada persona consulta con su propio usuario del ERP, así que los permisos siguen saliendo del ERP persona por persona. Sumar gente a la cuenta no amplía lo que ninguna de ellas puede ver.

8. Qué recibe el modelo de IA

Para redactar la respuesta, Anthropic recibe la pregunta, el esquema del ERP (nombres de modelos y campos) y un extracto acotado de los registros que devolvió esa consulta: hasta 20 filas por respuesta en modo normal y hasta 80 filas por consulta en Análisis profundo. Ese extracto puede contener información del negocio, como nombres de clientes o importes.

Nunca se envía la base de datos completa ni las credenciales. Anthropic retiene ese contenido hasta 30 días únicamente para detección de abuso, según sus términos, y no lo usa para entrenar modelos. Tampoco lo usamos nosotros para entrenar nada.

9. Retención y borrado

Mientras la cuenta esté activa se conservan el perfil, las credenciales cifradas, el historial de mensajes y el historial de facturación. La eliminación desde la app es inmediata y permanente, exige confirmación y volver a autenticarse, y borra el historial de chat, las credenciales, el vocabulario aprendido, las sesiones, los tokens y el registro de seguridad asociado.

Dos matices honestos: el historial de facturación se conserva cinco años por normativa tributaria peruana, con el correo anonimizado; y una cuenta eliminada puede seguir presente en las copias de seguridad hasta 30 días, hasta que esas copias caduquen. El detalle completo está en la sección 6 de la Política de privacidad.

10. Lo que no tenemos

Preferimos que esto se sepa por nosotros y no por un hallazgo de auditoría:

• No tenemos certificación SOC 2 ni ISO 27001.
• El pentest que publicamos es propio, hecho y grabado por nosotros; no es la auditoría de un tercero independiente.
• No ofrecemos alojamiento en la Unión Europea ni residencia de datos por región: toda la infraestructura está en Estados Unidos.

11. Contacto

Responsable del tratamiento de datos:

Jhon Jairo Rojas Ortiz
Correo: contacto@aski.dev
País: Perú

Respondemos consultas de seguridad y solicitudes de acuerdos en un máximo de 7 días hábiles. Si tu auditor tiene un cuestionario, mándalo tal cual y lo respondemos por escrito.