La seguridad es cimiento, no feature.
Los datos fiscales son sensibles por definición — los tuyos y los de tu equipo. Por eso la seguridad de Goyo no es feature: es cómo está construido el producto desde la primera línea de código.
Cada cliente, su propia base de datos.
Cada empresa que usa Goyo tiene su propio schema de PostgreSQL
dentro del motor — no una columna tenant_id en tablas compartidas. La separación pasa al nivel del motor de base de datos: una
query escrita contra el schema de un cliente no puede tocar el
schema de otro, aunque alguien lo intente desde el código.
Empresas hermanas (varios RFCs del mismo grupo) comparten schema y
se separan internamente por rfc_id. La frontera fuerte se traza por cliente, donde corresponde.
Esa frontera aplica a todo lo que vive dentro de tu tenant: datos fiscales, datos de tus clientes y proveedores, y datos de tus colaboradores (CURP, NSS, datos bancarios para dispersión, recibos de nómina). Cuando un dato es sensible LFPDPPP, esta es la base estructural que lo protege.
Por qué esto importa · detalle técnico
La mayoría de los SaaS multi-tenant usan row-level isolation: una sola base de datos donde cada tabla tiene una columna tenant_id y la aplicación es responsable de filtrar por ese campo en cada
query. Funciona, pero un bug en un middleware, un raw SQL mal escrito
o un join descuidado puede filtrar datos entre clientes. Toda la disciplina
la carga la aplicación.
Goyo invierte el contrato: el motor de PostgreSQL impone la frontera. Un schema de un tenant no es queryable desde el contexto de otro tenant. La disciplina deja de ser opcional.
Es estructuralmente imposible vía el motor de base de datos que un query del schema A toque el schema B. No depende de que el código esté bien escrito.
Cifrado en cada capa, con llaves separadas por cliente.
Tus datos van cifrados en tránsito y en reposo. Las credenciales fiscales más sensibles llevan una capa adicional.
TLS moderno entre todos los componentes
SSL termina en infraestructura propia en AWS — no en edge de terceros con jurisdicción impredecible.
AES-256 en RDS y S3
Gestionado por AWS. Cifrado transparente a nivel de almacenamiento — nada queda en claro en disco.
Llave dedicada por cliente en AWS KMS
CSDs, e.firma y contraseña de e.firma cifrados con esa llave. La llave nunca sale del motor de AWS — el cifrado y descifrado pasan por IAM y cada operación queda registrada.
Tu e.firma se guarda cifrada, con salvaguardas serias.
La forma honesta de hablar de esto.
Goyo persiste tu e.firma. Lo decimos directo porque el argumento defensivo correcto no es "no persistimos" — es cómo persistimos.
Los archivos .key y .cer se almacenan cifrados con AES-256, con la llave dedicada de tu empresa
en AWS KMS. La contraseña de la e.firma se almacena con el mismo esquema.
Quien tenga acceso a la base de datos sin acceso simultáneo a tu llave
KMS no ve nada utilizable.
Decisión deliberada, no concesión de comodidad.
Goyo automatiza tus operaciones recurrentes con el SAT: descarga masiva mensual, generación de declaraciones, conciliación contra precalculaciones, presentación de avisos. Esas operaciones requieren acceso programático recurrente a tu e.firma.
Sin persistencia controlada, cada operación obligaría a un humano a re-subir el archivo — y la promesa de pólizas que se hacen solas se rompe en la primera ejecución del mes.
No es comodidad. Es lo que necesita el producto para funcionar.
Quién puede iniciar operaciones que la usan:
| 01 | Roles administrativos del cliente | con permiso explícito — típicamente Dueño o Contador. |
| 02 | Agentes automáticos de Goyo | en operaciones programadas (descarga SAT, declaraciones, conciliación). |
| 03 | Agentes invocados desde la app | por un usuario autorizado. |
¿Qué diferencia hay entre la e.firma y los CSDs?
La e.firma es la llave maestra del SAT — sirve para cualquier trámite fiscal, desde renovar el RFC hasta presentar declaraciones. Los CSDs (Certificados de Sello Digital) son llaves específicas para una sola cosa: emitir CFDIs. Su alcance es mucho más limitado.
En Goyo, ambos se guardan con el mismo esquema (AES-256 + llave KMS por cliente). Los CSDs los usa el servicio de timbrado en cada emisión; la e.firma se usa solo cuando una operación con el SAT lo amerita.
Todo en AWS. Nada en jurisdicciones impredecibles.
Goyo corre completo en AWS. No usamos plataformas serverless en ubicaciones que cambian sin aviso, ni edge de terceros donde tus datos pasan por geografías que no controlamos. Los datos viven dentro de un perímetro auditable y conocido.
Componentes adicionales
ECS Fargate (cómputo aplicativo), SES (envío de email transaccional), SQS (colas de procesamiento asíncrono).
Sub-procesadores externos
Más allá de AWS, Goyo trabaja con PACs autorizados por el SAT para timbrado, proveedores de LLM para capacidades de IA, y servicios para mensajería (WhatsApp, SMS). La lista actualizada con su rol y los datos que reciben está disponible bajo solicitud.
Las acciones críticas dejan huella. Y la huella no se borra.
Cada tenant tiene su propia bitácora (audit_log), diseñada para ser inmutable: las entradas se insertan, no se modifican ni se borran. La
aplicación no tiene operación que las altere; el modelo de datos
lo refleja.
Qué queda registrado:
- Timbrado y cancelación de CFDIs
- Complementos de pago
- Cambios en datos fiscales
- Cambios en roles y permisos
- Configuración del tenant
- Acceso y uso de e.firma y CSDs
- Exportaciones masivas
- Inicios y cierres de sesión
Cada entrada incluye quién hizo la acción, cuándo, desde qué IP, y qué cambió (valor antes y después). Tú puedes solicitar la exportación de tu bitácora cuando la necesites. Es información tuya, no nuestra.
Si entramos, lo sabes.
A veces nuestro equipo necesita ver datos de tu tenant — para resolver un caso de soporte, investigar un problema técnico, o ejecutar un cambio que tú nos pediste. Cuando eso pasa, queda registrado.
Nuestro equipo de soporte y customer success puede ver datos de tu
tenant cuando hace falta para resolver un caso. Cada acceso queda registrado automáticamente en cross_tenant_audit. Tú puedes solicitar el log
de quién entró a tu cuenta y cuándo.
Cambiar datos de tu tenant requiere justificación escrita o consentimiento explícito tuyo. Acciones administrativas estándar (suspender por mora, aplicar crédito) tienen su propia justificación documentada por política comercial.
Los módulos publicados por terceros nunca tienen acceso cross-tenant. La capa privilegiada que permite operaciones globales solo está disponible para módulos construidos por nuestro equipo, validado en el momento de publicar.
Lectura registrada, mutación con justificación, marketplace nunca cruza tenants. Sin asteriscos.
La IA hereda tus permisos. No entrena con tus datos.
La inteligencia artificial es central en Goyo, así que lo siguiente no es opcional para nosotros — es la única forma de tener IA en infraestructura fiscal.
Tus datos no alimentan modelos
Nuestros contratos con los proveedores de modelos prohíben usar tus datos para entrenar. Donde el proveedor ofrece Zero Data Retention contractual, lo activamos. La realidad por proveedor se revisa periódicamente.
El asistente solo ve lo que tú puedes ver
No hay bypass vía IA — si tu rol no tiene acceso a nóminas, el asistente tampoco te da acceso a nóminas.
Índice exclusivo de tu tenant
El asistente conoce tu negocio porque tus datos se vectorizan en un índice exclusivo de tu tenant. Los datos de una empresa nunca alimentan respuestas para otra.
El contexto se usa y se descarta
Cuando el asistente sabe qué pantalla estás viendo, ese contexto se usa para responderte y se descarta. No queda persistido.
BYOAI — Para clientes con compliance extremo
En planes superiores podrás conectar tu propio proveedor de LLM (Anthropic, Azure OpenAI, modelos self-hosted) para que las llamadas del día a día consuman tu contrato y tus cláusulas de privacidad, no las nuestras. Goyo AI sigue siendo el motor de extracción de CFDIs, conciliación y agentes — BYOAI es optimización, no reemplazo.
Métodos modernos de inicio de sesión y permisos al detalle.
Cómo entran tus usuarios
OAuth Google & Microsoft
El camino principal. Sin contraseñas que robar.
Magic link por email
Para signup y recuperación.
Domain whitelisting
Restringe a dominios autorizados de tu empresa.
SAML / SSO
Disponible en el plan Empresarial.
2FA heredado
Goyo respeta el 2FA de tu identity provider (Google, Microsoft, SAML).
Cuando inicias con Google o Microsoft, heredas el 2FA configurado en tu identity provider. Lo mismo aplica con SAML/SSO — Goyo respeta las políticas de tu IDP. No re-implementamos lo que tu organización ya tiene resuelto.
Cómo se asignan los permisos
El modelo es recurso.acción con un alcance ortogonal: por sucursal, por RFC, por línea de negocio, o globales. El catálogo base viene con roles predefinidos que puedes
personalizar.
Los roles pueden limitarse por sucursal: un Ventas de la sucursal Norte ve solo Norte. Un Dueño no tiene esa restricción. Un Contador externo puede ver lo fiscal sin entrar a la operación.
Si algo falla, podemos volver al ayer.
Goyo es infraestructura fiscal: cuando algo se rompe, tu operación se rompe. Por eso el sistema está pensado para recuperarse.
-
Backups automáticos
Con retención periódica, programados sin intervención manual.
-
Point-in-time recovery
Reconstruimos el estado de tu base a un momento específico dentro de la ventana de retención.
-
Versionado en S3
Para CFDIs y adjuntos. Recuperar una versión anterior es trivial.
-
Redundancia multi-AZ
Componentes críticos en varias zonas de disponibilidad de AWS. La caída de una AZ no rompe el servicio.
No prometemos cinco nueves de uptime sin un contrato que lo respalde. Lo que sí hacemos: pisos contractuales por plan, histórico mensual público en status.goyo.mx, y comunicación directa cuando algo significativo se rompe. Los planes superiores tienen targets más estrictos — están en el contrato, no en una página de marketing.
Te quedas porque Goyo es mejor, no porque no puedas salir.
Esta es una promesa explícita del producto, no una concesión de la página de seguridad: tus datos son tuyos y los puedes sacar cuando quieras.
Exportación completa
Paquete ZIP estructurado con CFDIs (XML + PDF), pólizas, catálogos (clientes, proveedores, productos en CSV y NDJSON), datos transaccionales, y manifiesto. Disponible bajo solicitud, sin fricción.
API pública
REST + webhooks. Acceso programático a tus datos desde tus propios sistemas, con autenticación por API key con scopes finos.
MCP Server
Para que Claude, ChatGPT, Cursor o cualquier cliente compatible con Model Context Protocol pueda conectarse a tu Goyo y consultar datos heredando los permisos del usuario que autorizó.
Sin formatos propietarios
XML del SAT, PDF estándar, CSV, JSON. Lo que cualquier otro sistema sabe leer.
Marco legal — encargado / responsable
Goyo es encargado del tratamiento de los datos personales que viven en tu tenant; tú eres el responsable. Cuando uno de tus colaboradores, clientes o contactos ejerce un derecho ARCO (acceso, rectificación, cancelación, oposición), tienes las herramientas dentro de Goyo para responder en los plazos legales. El contrato encargado/responsable se firma en el onboarding.
Si encuentras algo, queremos saberlo.
Si descubres una vulnerabilidad de seguridad en Goyo, escríbenos. Respondemos lo antes posible.
Política de divulgación responsable
Te pedimos que nos des la oportunidad de evaluar y corregir antes de publicar el hallazgo. A cambio, tomamos el reporte en serio, te mantenemos informado del progreso, y te damos crédito si así lo prefieres.
Lo que aún no tenemos
No tenemos un programa de bug bounty formal con recompensas monetarias. Lo planeamos cuando el producto madure lo suficiente para que valga la pena de ambos lados. Mientras tanto, valoramos el reporte y respondemos con seriedad — pero queremos ser claros sobre lo que hay y lo que no.