La ley dentro de nuestro código

Cuando hicimos que Premium se pudiera comprar, dimos por hecho que la parte legal eran unas cuantas páginas de texto en el pie. Nos equivocamos. Algunas obligaciones no se pueden escribir en un texto, porque dictan cómo tiene que construirse una función.

Cuatro ejemplos en los que eso quedó especialmente claro. Por adelantado, para que quede claro qué es esto: una descripción de nuestra implementación, no asesoramiento jurídico. Las normas de abajo son derecho alemán, que es donde opera AlphaCloud.

El botón de cancelación que no puede tener inicio de sesión

El § 312k del Código Civil alemán exige que los contratos celebrados en línea ofrezcan una vía directamente accesible para cancelarlos. De ahí salen requisitos que no puedes añadir después con palabras:

• La página tiene que funcionar sin iniciar sesión
• Tiene que estar en el pie de cada página
• Necesita dos pasos: introducir los datos y luego confirmar con un botón rotulado sin ambigüedad
• Tiene que enviarse una confirmación de recepción en forma de texto

El último punto determina la arquitectura. Una cancelación es una declaración unilateral y surte efecto al recibirse. Así que hay que registrarla y confirmarla siempre, venga de quien venga.

El formulario nunca puede rechazarte

Aquí el enfoque obvio casi nos cuesta un error.

El enfoque obvio: aceptar la cancelación solo si el ID del servidor y el correo coinciden con una suscripción activa. Suena razonable y está mal por partida doble.

Primero, dejaría fuera a un cliente real que se equivoca al escribir su correo o da otra dirección. Su cancelación no se habría recibido, la suscripción se renueva, y él tiene pruebas de que lo intentó.

Segundo, y esta es la parte más desagradable: el propio mensaje de error sería una respuesta. Quien recibe «no se ha encontrado ninguna suscripción» se entera de que ese servidor no paga. El ID de un servidor de Discord no es un secreto, cualquier miembro puede leerlo. El formulario se convertiría en una herramienta para sondear servidores ajenos.

La solución separa dos cosas que parecen una sola:

	Condición
Recepción de la declaración	incondicional, siempre registrada y confirmada
Ejecución de la cancelación	solo si el correo enviado coincide con el del comprador registrado

Todo lo demás va a una cola y lo revisa una persona. Eso está permitido porque el § 312k, apartado 2, permite expresamente pedir datos de identificación. Lo único prohibido es poner un inicio de sesión delante.

Por la misma razón, la respuesta pública solo puede indicar la fecha de fin una vez confirmada la identidad. Si no, la confirmación vuelve a ser un oráculo.

El desistimiento que tiene inicio de sesión a propósito

Justo al lado hay una función que construimos al revés: el desistimiento con reembolso proporcional está detrás de un inicio de sesión.

No es una contradicción. El § 312k trata la cancelación, no el desistimiento, y no existe ninguna obligación de ofrecer un formulario de desistimiento en línea mientras la vía informal siga abierta. La diferencia es la consecuencia: una cancelación actúa sobre el futuro, un reembolso mueve dinero ahora, y no se puede recuperar.

Tres reglas que se derivan de ello y que no suavizamos:

Sin motivo obligatorio. El § 355, apartado 1, concede el desistimiento expresamente sin necesidad de dar motivos. El campo es opcional y tiene que seguir siéndolo, por muy tentador que resulte uno obligatorio para las estadísticas.

Después de 14 días solo se rechaza la vía automática, nunca la declaración. El plazo se amplía hasta doce meses y catorce días si el cliente no fue informado correctamente. Un «demasiado tarde» general podría por tanto ser erróneo.

La protección contra pagar dos veces es pesimista. La marca se pone antes de que se ejecute el reembolso. Si después el reembolso falla, la marca se queda y una persona se hace cargo. Pagar dos veces es el único resultado que no tiene arreglo.

Un MD de Discord no es un soporte duradero

El § 312f, apartado 3, exige una confirmación del contrato en un soporte duradero, y tiene que reproducir el consentimiento dado.

Primero enviamos un mensaje directo de Discord, porque ese es el canal en el que ya están nuestros clientes. Eso no basta. Un MD vive en una plataforma que no controlamos, y no es ni almacenable ni inalterable en el sentido que pretende la norma.

Así que se añadió un correo electrónico, y con él una dependencia incómoda: si las credenciales de correo no están configuradas, el envío solo escribe un aviso en el log y la obligación queda sin cumplir. Una obligación legal que depende de una variable de entorno es un estado del que conviene ser consciente.

Sin IVA, y eso tiene que decirse igual en todas partes

AlphaCloud es una pequeña empresa según el § 19 de la ley alemana del IVA. Los precios son precios finales; nunca se muestra IVA.

Suena a nota al pie y en realidad es una tarea de coherencia en muchos sitios: la página de precios, el diálogo de pago, las condiciones, la política de privacidad, el pie de las facturas y la configuración en el proveedor de pagos tienen que decir todos lo mismo. Durante mucho tiempo tuvimos ahí un «IVA no incluido» que sencillamente era falso.

Y la IA

Desde agosto de 2026 se aplican plenamente las obligaciones de transparencia del Reglamento europeo de IA. Quien habla con un sistema de IA tiene que poder reconocerlo, como muy tarde en la primera interacción.

La frase más importante de esa revisión para nosotros: una página legal en el pie probablemente no basta. La información tiene que darse donde ocurre la interacción, es decir, en el propio mensaje de Discord. Por eso nuestro soporte IA en los tickets se presenta por sí solo y tiene un botón visible para desactivarlo. Nuestra valoración detallada está en transparencia de la IA.

El hilo común

Los cuatro ejemplos tienen la misma forma: la obligación parecía un texto y en realidad era un requisito sobre la estructura. Un inicio de sesión en el sitio equivocado, un mensaje de error que revela demasiado, una confirmación por el canal equivocado, un orden que permite pagar dos veces.

Así que ahora leemos los textos legales como una especificación, y comprobamos también en la otra dirección: ¿hace el código de verdad lo que dicen nuestras condiciones? Precisamente con esa pregunta encontramos dos divergencias reales, y sobre ellas hay un artículo aparte.