Infraestructura gestionada
La plataforma corre en tres capas, cada una administrada por un proveedor especializado con disponibilidad de nivel empresarial:
| Componente | Cómo está desplegado |
|---|---|
| Frontend | Desplegado en Vercel con red de borde global (CDN), HTTPS forzado en todos los dominios y sin secretos de servidor expuestos al navegador. |
| API | Contenedores gestionados en Render, TLS 1.2+ en todas las conexiones y sin acceso directo a la base de datos desde el exterior. |
| Base de datos | Neon Postgres gestionado, cifrado en reposo por defecto, recuperación a cualquier punto en el tiempo (PITR) y backups automáticos diarios. |
Cifrado y protección de datos
Los documentos de evidencia (PDFs, imágenes, constancias) se almacenan en Cloudflare R2 con cifrado en reposo del lado del servidor (SSE). Las URLs de descarga son prefirmadas con expiración corta: ningún archivo es accesible sin un token válido.
Todo el tráfico entre el navegador y los servidores viaja sobre TLS. No se almacenan contraseñas en texto plano: se usa hashing con bcrypt y sal única por usuario.
Qué se verifica en cada documento
Guardar un archivo no es revisarlo. Cada documento que entra pasa por comprobaciones automáticas cuyo resultado queda en el expediente como evidencia, junto al documento y a la decisión que se tomó sobre él.
- Consulta al SAT. Cuando podemos leer el folio fiscal de un CFDI, lo verificamos contra el servicio de consulta del Servicio de Administración Tributaria en el momento en que se carga, para confirmar que el comprobante existe y en qué estado se encuentra. La consulta es informativa: si el SAT no responde, no da una respuesta definitiva o el archivo no permite leer el folio, el documento sigue su curso y así queda registrado.
- Señales de manipulación. El sistema inspecciona el contenedor del PDF: si fue editado después de emitirse, si lo produjo una herramienta de diseño en lugar de un sistema institucional, si trae contenido activo. El resultado es un veredicto para quien revisa, nunca un rechazo automático.
- Folios repetidos. Si un mismo folio fiscal aparece en dos periodos distintos, o bajo dos clientes distintos, se marca como riesgo de autenticidad para que una persona lo mire.
Ninguna de las tres bloquea una carga por sí sola. Las tres alimentan el criterio de la persona que firma la decisión, y esa firma queda registrada con su autor y su fecha.
Aparte de estas tres señales, cada cliente puede activar el rechazo automático para su organización. Viene apagado y solo actúa cuando las reglas comprueban, sin depender de una lectura de IA, que el documento no es el tipo que se pidió o no lo emitió la institución que corresponde. La proveedora recibe el motivo y qué subir, y puede pedir que una persona lo revise desde «Contactar soporte». Nunca rechaza por una señal de manipulación.
Control de acceso por rol
Cada sesión emite un token JWT con vigencia de 24 horas, ligado a un rol específico. Las rutas de API rechazan peticiones sin token válido o con rol insuficiente, no existe escalación silenciosa de privilegios.
Los roles de la plataforma son:
| Rol | Qué puede ver y hacer |
|---|---|
| Cliente admin | Ve y gestiona solo los proveedores de su organización. |
| Proveedor | Accede exclusivamente a sus propios requisitos y carga de evidencia. |
| Revisor CheckWise | Valida documentos en la cola de revisión; no puede modificar datos de cliente ni de proveedor fuera de esa cola. |
| Admin de plataforma | Operación interna de Legal Shelf; acceso auditado y con doble confirmación para acciones destructivas. |
Tras cinco intentos de contraseña fallidos consecutivos, la cuenta queda bloqueada durante 15 minutos. El bloqueo se libera automáticamente o mediante acción del administrador.
Cómo se decide aceptar o rechazar
Dos lecturas revisan cada documento: una determinista, anclada a la evidencia de la página, y un modelo. Lo que cambia no es quién lee, sino cuánto le exigimos a esa lectura según hacia dónde apunte.
Si nos equivocamos, un revisor mira el PDF una vez más.
Si falla cualquiera el eje queda sin confirmar. No acusa a nadie, y tampoco deja pasar el documento: sigue bloqueando la aceptación en un clic.
Si nos equivocamos, un proveedor que hizo todo bien recibe una solicitud de corrección, y el cliente carga con una justificación escrita para revertirla.
La lectura determinista no pasa por esta reja. Cuando encuentra una discrepancia contra lo que la obligación pedía, es concluyente: viene de evidencia en la página, no de una probabilidad.
La consulta al SAT
El QR de un CFDI se puede copiar de un comprobante real, así que no nos quedamos con leerlo: le preguntamos al SAT si ese folio fiscal existe y sigue vigente.
La consulta corre después de que la carga del proveedor ya quedó confirmada, por su propio carril. Nunca detiene una subida y nunca hace esperar a tu proveedor por la latencia o la disponibilidad del SAT.
Vigente
No cambia nada. El documento sigue como lo dejaron las otras lecturas.
Cancelado o no existe
Sube el riesgo de autenticidad y lo manda a revisión humana.
Sin respuesta
Si el SAT no contesta, tampoco cambia nada. La duda no cuenta como falta.
Una respuesta favorable nunca marca un documento como limpio: confirma que el folio existe y sigue vigente, y nada más. La consulta agrega evidencia, no aprueba.
Trazabilidad completa
Toda acción relevante (cambio de estado, aprobación de documento, edición de datos de usuario, acceso a un expediente) queda registrada con actor (usuario o sistema), acción, timestamp y el estado antes y después. Este registro es de solo escritura: no puede modificarse retroactivamente.
En una inspección de la STPS o el IMSS, el equipo CheckWise puede exportar el historial completo de un proveedor, quién cargó cada documento, quién lo aprobó y cuándo, en formato PDF o Excel.
Operaciones de seguridad
- Las dependencias de frontend y backend se monitorean con Dependabot; las actualizaciones de seguridad se aplican en el ciclo de despliegue regular.
- Cada cambio pasa por revisión de dependencias y búsqueda de credenciales expuestas antes de llegar a producción: se analizan las dependencias de Python y de Node en busca de vulnerabilidades conocidas, y se revisa el historial completo del repositorio en busca de secretos.
- La separación de datos por inquilino (tenant isolation) es estructural: las consultas de API filtran por organización. Cada ruta declara explícitamente cómo acota al inquilino, y la integración continua rechaza cualquier ruta nueva que no lo haga o cuyas protecciones dejen de coincidir con lo declarado.
Preguntas de seguridad
Si tu empresa tiene un proceso de evaluación de proveedores de software (vendor risk assessment, cuestionario de seguridad o revisión de contrato de procesamiento de datos), escríbenos. El equipo de Legal Shelf responde en el mismo día hábil desde CDMX.
Para reportar una vulnerabilidad, contáctanos directamente a través del formulario de la página principal con el asunto "Seguridad".