// para quien audita
Seguridad, datos y operación — cómo se sostiene la promesa
En esta página (9 secciones)
Para quién es: para quien quiera auditar el servicio (un creador exigente, un adquirente de pagos, un socio, un abogado). Acá está la parte que no se ve: cómo se protege lo que se promete.
Principio de este documento: la confianza se audita, no se declara. Cada punto dice cómo se verifica.
1 · Credenciales y accesos#
| Qué | Cómo se maneja |
|---|---|
| Tokens y claves (bot, MercadoPago, Google, Cloudflare) | Viven en un archivo .env con permisos 600 (sólo el usuario del servicio), fuera del repositorio y excluidos del respaldo |
| Token del bot de la plataforma | Nunca se reutiliza el bot de mensajería personal del operador. Cada servicio tiene su propio bot |
| Token de cada creador | Se guarda en un archivo aparte (creadores.json, permisos 600) que no entra al respaldo ni al repositorio |
| Quién tiene acceso | Sólo el operador del servicio. Los registros administrativos del bot están restringidos a una lista de administradores |
| Rotación | Ante cualquier sospecha, se revoca y se regenera. Los secretos nunca se comparten por chat ni se pegan en documentos |
| Auditoría del código | Antes de publicar cambios se corren las pruebas de punta a punta y las auditorías automáticas (ver §6) |
Regla dura, escrita: los agentes de IA no manejan credenciales de dinero y no ejecutan acciones sobre dinero. Preparan, informan y documentan; el cobro, la entrega y la devolución los ejecuta código determinístico con pruebas.
2 · Qué datos se guardan y qué no#
| Dato | Se guarda | Detalle |
|---|---|---|
| Pedidos y eventos del canal | ✅ | Qué se compró, cuándo, estado del pago, estado de la entrega. Es lo que hace funcionar la entrega y el soporte |
| Ventas agregadas por creador | ✅ | Para el panel que ve en su chat (día, semana, mes, promedio) |
| Compradores: identidad | ⚠️ Mínima | El identificador que manda la mensajería, para poder entregar y atender reclamos |
| Datos de tarjeta o de cuenta de pago | ❌ | Nunca los vemos: los procesa y los guarda MercadoPago |
| Contraseñas de quien contrata | ❌ | Nunca se piden (ver §3) |
| Contenido del creador con fines de marketing | ❌ | No se usa sin permiso explícito |
| Registro de producto | ✅ de-identificado | Se guarda un identificador no reversible (hash corto) con la necesidad detectada, sin nombre, sin usuario y sin contenido, para mejorar el producto |
Retención y borrado: los datos operativos viven mientras dure el servicio. Con la baja, se borra lo que identifica a los compradores y se conserva sólo el registro contable del honorario, que la ley exige.
3 · Lo que el servicio NO pide nunca#
Lista vinculante: si alguien pide algo de acá en nombre del servicio, es un fraude.
- Contraseñas (Telegram, redes, MercadoPago, banco) · códigos de verificación · token de bot · acceso a la cuenta de mensajería · foto de DNI por chat · pagos fuera de la plataforma o a cuentas personales · cambio del destinatario de los cobros.
4 · Operación (lo que hace que funcione sola)#
- Reconciliación cada 90 segundos: el sistema revisa los pagos contra MercadoPago y destraba entregas que quedaron pendientes.
- Vigilante del bot: si el proceso se cae, se reinicia y queda registrado.
- Modo demo aislado: la demostración pública no puede crear pagos reales — usa un camino separado que simula la pantalla de pago. Es una garantía técnica de que mostrar la demo no mueve dinero.
- Horarios: el canal opera 24/7; la atención humana, lunes a viernes de 9 a 18 (hora de Argentina); reclamos acusados en menos de 24 h hábiles.
- Escalado: cada reclamo abre un caso con número; los casos repetidos se convierten en una prueba automática (ver §6), para que no vuelvan a pasar.
5 · Respaldos#
- Qué se respalda: configuración, documentación, especificaciones, salidas de análisis y los documentos del proyecto. Frecuencia diaria, a un repositorio privado.
- Qué se EXCLUYE a propósito: archivos
.env, bases de datos (*.db), datos de usuarios/compradores, registros de logs, cachés ycreadores.json. - Por qué: un respaldo no debe ser la puerta de entrada a los datos. Se respalda el sistema, no las personas.
- Restauración: el respaldo se prueba a mano (un ciclo de commit + push verificable) antes de confiar en él.
6 · Qué se prueba antes de publicar#
| Prueba | Qué cubre |
|---|---|
| Suite de punta a punta (161 verificaciones) | Los caminos completos: alta, menú, cobro, entrega, reclamo, devolución, panel |
| Recorridos de experiencia (walkthrough por rol) | Lo que hace el comprador y lo que hace el creador, paso a paso |
| Aislamiento de la demo | Que la demo pública no pueda crear pagos reales |
| Especificaciones verificables | Los requisitos escritos (EARS) se validan contra el código: si el requisito no se cumple, la verificación falla |
| Accesibilidad y contraste | Páginas y piezas: WACG y APCA (en fondo oscuro, sólo WCAG da un falso aprobado) |
| Verificación estructural | Cierres de HTML, enlaces muertos, saltos de jerarquía |
| Registro de casos | Cada caso resuelto a mano se convierte en una prueba automática |
7 · Cómo lo verifica alguien de afuera#
Checklist para una auditoría rápida:
- ¿El dinero pasa por la plataforma? No: entra en la cuenta del creador. Se verifica con una compra de prueba.
- ¿Se piden contraseñas? No, nunca. Se verifica leyendo la lista vinculante (§3) y los mensajes reales del bot.
- ¿La demo mueve dinero? No: camino aislado. Se verifica abriéndola y viendo que la pantalla de pago es simulada.
- ¿Se respaldan datos personales? No: el respaldo los excluye por diseño (§5).
- ¿Hay registro de incidentes y de cambios? Sí: cada cambio deja versión y fecha, y los casos quedan numerados.
- ¿Se puede pedir el borrado? Sí, con la baja del servicio (§2).
8 · Incidentes#
| Nivel | Ejemplo | Respuesta |
|---|---|---|
| Crítico | No se puede cobrar o no se entrega a nadie | Aviso inmediato a los afectados + trabajo hasta resolver + explicación escrita de qué pasó |
| Medio | Un camino puntual falla (un tipo de pack, un caso raro) | Caso abierto, workaround y prueba automática cuando se corrige |
| Menor | Texto confuso, error de estilo | Se corrige en el próximo ciclo, con el registro de cambio |
Regla: cada incidente crítico termina en una prueba nueva y en una línea en el registro de cambios. Un problema que se repite es un problema del sistema, no de la persona.
9 · Límites declarados#
- Dependemos de MercadoPago y Telegram: sus caídas o cambios de reglas nos afectan.
- El servicio no garantiza ventas: garantiza el funcionamiento del canal.
- No somos asesores legales ni contables del creador.
- La operación humana tiene horario; el canal no.